GBA emulation


You'd be amazed how bad some commercial code is ;)

Oh, I don't think I'd be surprised.. but people who write emulators for a living are not exactly common place. Especially people who write recompilers.

I'd agree that getting the interpreter working first makes sense, that gives us a working base to then get the recompiler working on - if it's even necessary to do so: interpreted GBA emulators seemed to do the job on fairly ancient PCs that I'm fairly certain the Pandora is faster than.

From previous experience, VBA isn't the fastest of emulators, but it's pretty accurate and there's a proper linux version that's worth at least checking out.

The interpreter should at least sort of be enough, and if you run the recompiler on ROM code you won't have a lot of the problems. Normal GBA games execute around 60% of their instructions in Thumb code, and that usually is running from ROM. There are some exceptions where a ton of time is spent in IWRAM, for instance soft rendered 3D games.


gpSP compiles for Linux PCs too.. or at least it probably does, I haven't tried it in a long time. But it has been ported to a lot of ARM Linux platforms already. I don't really know why there are problems now, it's probably just some nuance having to do with invalidating cache on Pandora.


I don't really know which emulator you're thinking of and what PC specs, but you shouldn't overestimate Pandora - a similarly clocked Pentium 3 can probably usually trounce it. VBA is pretty slow, but in my experience the other PC GBA emulators weren't an awful lot faster.
 
Oh, I don't think I'd be surprised.. but people who write emulators for a living are not exactly common place. Especially people who write recompilers.
Well, businesses need to run legacy applications somehow. A lot of them are willing to pay for getting their old software working (some of this is 15 to 20 years old, some older still) instead of just writing new software.

The interpreter should at least sort of be enough, and if you run the recompiler on ROM code you won't have a lot of the problems. Normal GBA games execute around 60% of their instructions in Thumb code, and that usually is running from ROM. There are some exceptions where a ton of time is spent in IWRAM, for instance soft rendered 3D games.


gpSP compiles for Linux PCs too.. or at least it probably does, I haven't tried it in a long time. But it has been ported to a lot of ARM Linux platforms already. I don't really know why there are problems now, it's probably just some nuance having to do with invalidating cache on Pandora.
Ok, this is promising. If I can get hold of current source for gpSP I'll experiment on x86 linux here with the interpreter.

I don't really know which emulator you're thinking of and what PC specs, but you shouldn't overestimate Pandora - a similarly clocked Pentium 3 can probably usually trounce it. VBA is pretty slow, but in my experience the other PC GBA emulators weren't an awful lot faster.
I seem to remember playing GBA games on old and slow AMD Durons pretty well. I don't know how they compare to the Pandora, only that the Pandora seems to run XFCE a lot better than significantly better PC hardware in the videos I've seen.
 
Last edited by a moderator:
Well, businesses need to run legacy applications somehow. A lot of them are willing to pay for getting their old software working (some of this is 15 to 20 years old, some older still) instead of just writing new software.

But do businesses need to run 15-20 year old software with a recompiler..?

Ok, this is promising. If I can get hold of current source for gpSP I'll experiment on x86 linux here with the interpreter.

You can go ahead, but I don't think it'll buy you an awful lot.

I seem to remember playing GBA games on old and slow AMD Durons pretty well. I don't know how they compare to the Pandora, only that the Pandora seems to run XFCE a lot better than significantly better PC hardware in the videos I've seen.

Even the slowest 600MHz Duron probably smokes a 500MHz Cortex-A8. You would be gravely mistaken to compare UI performance to emulator performance, but I'm sure you already know that.
 
VBA is really, really, reaaaaally slow ...


I can't even play GB games on XFCE without overclocking to 700/750MHz.


GBA games are fine above 700MHZ in minimenu with background killer from what I experienced.


Didn't managed to get gpsp working so i can't tell for this emulator (i don't remember why).
 
But do businesses need to run 15-20 year old software with a recompiler..?
No, some of it is a lot more recent. The more recent stuff is the stuff I can't really go into.

You can go ahead, but I don't think it'll buy you an awful lot.
It'll still give me some time to familiarise myself with the code, and it doesn't hurt to get a head start.

Even the slowest 600MHz Duron probably smokes a 500MHz Cortex-A8. You would be gravely mistaken to compare UI performance to emulator performance, but I'm sure you already know that.
Fair enough. The UI videos are the only comparison I really have at the moment as I don't have a Pandora yet. The only other device I have that's Cortex A8 based is an iPhone 4, and that's not very helpful to use in a comparison.
 
VBA is really, really, reaaaaally slow ...


I can't even play GB games on XFCE without overclocking to 700/750MHz.


GBA games are fine above 700MHZ in minimenu with background killer from what I experienced.


Didn't managed to get gpsp working so i can't tell for this emulator (i don't remember why).

I hope that's due to inefficient coding. GBA games should be able to run fine on the Pandora at 500MHz if it's using the DSP. I'm guessing that VBA is just a dirty port, right?
 
Is everyone an expert at what should and shouldn't run at what now? ;p "Dirty" port or "good" port, VBA is slow.


At any rate it's not going to be using the DSP, nothing is using the DSP.
 
I know this question has been asked several times in the past, but does anyone have idea how difficult it would be to fix the gpSP crash bug in the last castle in Zelda: Minish Cap?


I actually tried debugging this on the GP2X just to find out where it was crashing and found that I was in over my head. When I would load a savestate and enter the room in which the game crashes, it would actually cause gdbserver on the GP2X to crash as well. I don't think that generally thats supposed to happen, so I gave up.
 
It's due to BIOS and/or open bus loads not giving the expected values. I thought I fixed it for ARM but apparently I hadn't.
 
At any rate it's not going to be using the DSP, nothing is using the DSP.
We've got all these CHIPS but can't USE THEM. Do we have a driver for the processor yet? Maybe that's why it's running so slow.
 
We've got all these CHIPS but can't USE THEM. Do we have a driver for the processor yet? Maybe that's why it's running so slow.

We don't have kernel support for using the DSP yet, largely because there hasn't been a consensus on which framework to use. All of them have problems and involve compromising something or other.


Even if it were in place, it's not easy to write good code for the DSP in general, and it's even harder to usefully parallelize tasks in an emulator at a large enough fidelity such that you can offload it to another processor. Look at GP2X, few emulators used the second ARM9 core and afaik it was only used for audio at that. Platforms like GBA don't need a lot of resources to emulate audio, so moving it to a DSP gives you almost nothing.


Doing all of this with a quick and dirty port is unheard of. VBA is definitely not designed to leverage DSPs and whatever.


It's theoretically possible to utilize the DSP to good effect in assisting with rendering of 2D and 3D graphics for various platforms. But Pandora is way more than powerful enough for GBA emulation, this really isn't necessary. I'll say it again, VBA is running slow because VBA is slow.


BTW, this is just nitpicking, but these cores aren't on different chips, everything is one die, one package..
 
Ok, I've "borrowed" a friend's beagleboard to start experimenting. So far, gpSP compiles and segfaults when I start it. ^o)

# Golden Sun: The Lost Age (U)


# Probably the most horrifically coded GBA game in existence.
I like this comment though.
 
Back
Top