Gpadvance Source Code?


calc84maniac

Member
Joined
Mar 19, 2009
Messages
332
I'm wanting to port GPAdvance to another ARM9 platform (namely the TI-Nspire). I actually came up with the general MMU hack idea on my own, and a Google search lead me here. I decided it might be better not to reinvent the wheel if there's already a pretty good code-base out there (and a quick look at the docs for the ARM920T seems to show that the MMU is identical to the one in the ARM926EJ-S). But the CVS is down, and probably has been for years, and the source in the sourceforge downloads seems pretty outdated. Does anyone still have a copy of the newest source?

Edit:
Found a non-broken link after more research. It can be found here if anyone else needs it.
 
Thanks for the link.

I'm curious about your goals and expectations regarding this project. I've been a pretty vocal detractor to the approach for various reasons; for GPAdvance in particular this line from the 1.47 changelog basically sums it up:

"- cache is disabled (poor performances but better compatibility)"

It's difficult to determine exactly what percentage of games can run OK without violating cache coherency in ARM9. The problem comes from code loaded from ROM and stored in IWRAM to be executed more quickly. This by itself isn't automatically an issue since ARM9's cache is not write allocating. You expect that code that gets loaded into data cache then written to a different location will leave data cache, and hence get properly loaded into instruction cache when it's executed. The problem probably comes when new code is loaded that either overwrites old code or is added near old code (same cache line) such that part of instruction cache becomes stale. The problem will also happen if the code that's written to is already in data cache for some reason. Finally, actual self modifying code will almost always pose a problem, and GBA games do resort to self modifying code if not somewhat infrequently.

Whatever the actual causes of the problem, we know that it was enough of a big deal for them to turn off cache despite GPAdvance still being fairly early in development and having a lot of other compatibility inhibitors. With cache disabled RISC CPUs an ARM9 will be really slow - one test has shown a 200MHz GP2X to give a Dhyrstone score of only 3DMIPS, a figure down from ~200 with cache on.

If given a choice between virtualization with cache disabled and a recompiler I'd definitely go with the latter, and not just for performance reasons. Virtualization inhibits clock counting, so if you're on a platform that can't naturally sustain real-time performance by a wide margin then you're liable to start causing crashes instead of just slow emulation.

The other problem is that GPAdvance is using video emulation code from VBA, which is very slow. For most games you would have to have a very high frameskip to negate this. Of course, on a 90MHz ARM9 you'd struggle with rendering performance no matter how efficient the code was.
 
That leads me to ask:

Would gpSP run within the GP32's 8MB of RAM? There's probably about 7MB available to the user.
The biggest problem would be cartridge sizes - most are 4MB; is that right?
So for an average 4MB cart we are looking at about 3MB of run space. :/
 
slaanesh said:
That leads me to ask:

Would gpSP run within the GP32's 8MB of RAM? There's probably about 7MB available to the user.
The biggest problem would be cartridge sizes - most are 4MB; is that right?
So for an average 4MB cart we are looking at about 3MB of run space. :/

Most GBA games are 8MB, with a pretty large number at 16MB and a few at 32MB. Dynamic recompilation is bad on platforms where you're highly RAM limited because of the extra overhead.
 
Last edited by a moderator:
I'm more interested in this from a technical demonstration point of view.

In this case ignoring carts > 4Mb.

Assuming the executable is ~1Mb, cart is <=4Mb, is 2Mb of run space sufficient for gpSP?
 
Ooh, that would be very interesting to try out.

Not to mention, some of the homebrew firmwares support larger ram chips (up to 32M? iirc) if one were willing to take the risk of soldering it on the board.
 
Yeah, I ended up deciding to write my own code anyway. I don't like trying to decipher other people's code, especially when it's for another device with its own libraries and stuff. I am capable of writing optimized ARM code anyway :)

Oh, and on a side note, the TI-Nspire can be clocked up to 150MHz -- but the TI-OS only runs at 90MHz.

Edit:
Also, I am glad I discovered that this CPU supports switching to high vectors :D

Edit2:
Isn't it also possible to disable cache per sector? If it becomes a problem, I can simply not use cache for the Work RAM and leave it on for my emulator code, the cartridge, and VRAM.
 
Back
Top