Is that with code running on the ARM to emulate an ARM or is some ARM code running natively? It would seem if instructions ran natively that the speed would be much better wouldn't it? That gives hope for future possibilities.
It seems if this "port" runs at that speed something that was made more specific for the GP2X hardware would be able to theoretically get closer to full speed right?
This is with a port of the C++ source.
I've actually taken a look into this. The general problem is that you're talking about virtualizing the GP2X in the same manner that software like VMWare or Xen works for the Intel x86. Note that even though the CPU is of the same RISC architecture, pretty much everything else is different.
Assuming it's even possible:
1) You'd have to really understand the CPU architecture differences between the GBA and the GP2X.
i.e. the ARM920t and the ARM7 something? I've read from the arm site that it's compatible, but I didn't go into details. There's the obvious issue of memory management and BIOS calls though, which should'be be virtualizable, but will probably require patching the binary code once again. I believe this is partially the approach that VMware takes.
2) You would probably have to massage the binary a bit for the 16 bit mode instructions, or replace, or something..
3) You'd have to figure out how to do the timing for the environment (i.e. video rendering, sound rendering)
You can blindly do 60Hz in the background, but I don't really know what that will do.
If you try to do synchronization, then all your binaries will probably have to be massaged in such a way that you might as well emulate it.
This amongst many many other things must go right for this scheme to work.
I actually put the 940 to use on this port, and it definitely makes a difference.
I was able to get close to a 2x speed up. Of course I did some serious profiling on the code before hand to see which part was sensible to parallelize.
Care to explain a little further what kind of functions or parts of the emu you have moved onto the 940?
I've been thinking about GBA emulation as well, but from a different angle (writing from scratch for the gp2x hardware, but running under Linux)
The graphics rendering. I don't know if Visualboy's approach to rendering is that efficient, but it sure does tons of work on each scanline. So I shared all the state required to do rendering in the 48-64 meg region, and basically let the 940 do it's thing. I don't know the GBA architecture well, but from the code it looks like layer/color/rotation/font/general rendering functions. From my profiling, it appears that close to 50% cpu time is spent doing this. Now granted, it's possible that Visualboy's implementation made many speed sacrifices for compatbility and code clarity reasons, so this may not be the true (optimal) performance breakdown.
