GP2X Gba Emu And Static Translation


Nope, I'm still working on this. The other project shares quite a bit of IBA source code (so working on one helps the other as well). Other than that, when I get tired of working on one I switch to working on the other. They take up %50-%50 of the development time.
Besides, gpSP is by far a more suitable emulator compared to VisualBoy and the guys working on it have a lot more experience with GP2X programming than I. For this reason I decided not dedicate all my time to IBA as I had been doing previously.
Also the DBP compiler is a project I was working on before I started working on IBA, not the other way around.
 
dwelch said:
Do a search for static recompilers. It is/was a yahoo groups thing. Graham Toal did a very nice writeup that summed up what a number of us were doing at the time on the subject.

The ARM in ARM mode is beautiful, one 32 bit word per instruction, no more, no less, easy to disassemble, easy to convert the disassembly to C.
Hi David! I didn't find out about this project until *way* too late - is it still being worked on? I wish the guy writing this had come and join us on static-recompilers, it would have made for a good discussion.

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.

By the way I found this today by accident - I was searching for a GBA Rom disassembler because the very same thought had occurred to me (that a GBA -> GP2X translator ought to be trivial) and I was going to see what a GBA rom looked like to see what was involved with it.

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?

Glad to see you're still keeping your hand in, David. I've not been doing so much myself this year, but I'm starting to pick up where I left off, especially with a couple of weeks of free time coming up at the Christmas hols.

regards

Graham
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
Back
Top