gtoal said:
For the case of running GBA code on the GP2X my recommendation would be to NOT go the C route but to generate 1:1 ARM assembler instead. Most instructions should be identical, there should only be a few that need tweaking for different screen layouts, peripheral addresses, operating system calls etc. In fact I would expect the code to be so similar that David's earlier post suggesting that you just run the actual GBA binary and catch the odd reference by using the MMU seems to me a strong contender.
You might be familiar with VMWare's binary translation paper. Unfortunately ARM does not provide the same facilities that x86 does making the resulting translation much bulkier. The biggest issue is that there's no safe place to spill registers to without taking up a register. Once you do that then you need some kind of register allocation to manage everything. The other issue is that it's good to be able to count cycles in emulated games. It's not strictly necessary to make all GBA works properly but a few are timing sensitive, and many that aren't have idle loops. External timers can be used but generating interrupts with these is problematic because you need the GBA's current PC value to be able to return to (if you try faking this anything that examines the PC can go bad). Not counting cycles might have some merit as an approach but it's risky.
Using the MMU would be great, but the problem there is that you need complete access to it to map the entire address space as you please, and you can't hide the emulator from the emulated address space (VMWare is able to do this thanks to segmentation on x86). There are probably some safe spots in the GBA's address space that will work for most if not all games, so I don't think that in particular will be an issue. What is an issue is that Linux gets in the way too much. You might be able to take over the complete address space but I'd be worried about it being able to recover correctly (especially if you map several virtual pages to the same physical locations, which is necessary to emulate mirroring). Dropping Linux isn't an easy option because many drivers would have to be rewritten (I personally would need a NAND driver) and again it'd be hard to start back up when you're done.
gtoal said:
So what's the status of this project? Did anything ever come of it? I followed what I thought was a link to a website for it but it seems to have been domain squatted. Is the project dead? Is there any salvageable code left over?
I haven't heard of anything coming of it. If you want you can look at my GBA emulator, gpSP. It uses an ARM/Thumb->ARM dynamic recompiler. It's far from perfect (some things I've improved privately, and I have a lot of further ideas) but it's at least sort of what you're asking for. I do think using the MMU would be great, if you'd like to do some research on hacking that I welcome you to.
By the way, just in case you're wondering, virtualization is not possible. There are several potentially minor issues but one major one will keep most games from working correctly - instruction cache.
Sadly emulating GBA's video subsystem is quite demanding, typically more demanding than emulating the CPU. That too can be further optimized, but I had really weird issues with GP2X (which were mysteriously negating some great initial results I was seeing) and then stopped. I'll probably pick it up again later.
