GBA emulation


tejster24

Still Fresh
Joined
Feb 22, 2010
Messages
11
Hi everyone,


I'm a late first-batcher, and my question is - what's the state of GBA emulation on the Pandora at the moment?


I've searched and can only find a very old youtube video of an ancient VBA port to a Pandora dev board...


Are games running, if so how well and do you need to overclock?


I'm interested in the Golden Sun series primarily.
 
It's as good as (if not better than) it is on the Wiz. And that's got really good GBA emulation.
 
The emulator list says it's still VBA (although only a five month old port). It also says VBA games run a little slow (at what speed, I don't know) - but I'd have thought Golden Sun wouldn't be ruined by the occasional slowdown.
 
The emulator list says it's still VBA (although only a five month old port). It also says VBA games run a little slow (at what speed, I don't know) - but I'd have thought Golden Sun wouldn't be ruined by the occasional slowdown.
the gpSP.pnd work rather well (it's gpSP for wiz wrapped with ginge)
 
The emulator list says it's still VBA (although only a five month old port). It also says VBA games run a little slow (at what speed, I don't know) - but I'd have thought Golden Sun wouldn't be ruined by the occasional slowdown.

Golden Sun is REALLY slow to emulate, It will probably be one of the last games to run full speed.
 
I really hope its flawless by the time I get mine, though I see no reason why it shouldn't be. I remember playing GBA on my hacked PSP and DOWNCLOCKING it to 166mhz!!
 
I really hope its flawless by the time I get mine, though I see no reason why it shouldn't be. I remember playing GBA on my hacked PSP and DOWNCLOCKING it to 166mhz!!
Agreed. I see absolutely no reason why any game on GBA would be slow, even on ~200 MHz :blink: :


1) Frequency of the original machine is just 16.8 MHz !


2) The original CPU is ... try to guess ... ARM also. ( Same arch - no arch emulation is supposed to take place. The version of CPU shouldn't matter, as the original ARM revision is a lot older then the one we are using in the Pandora. )


3) From point 2, I can't understand why the code can't be run natively, other then that ARM used in GBA is backwards-incompatible with ours.
 
Agreed. I see absolutely no reason why any game on GBA would be slow, even on ~200 MHz :blink: :


1) Frequency of the original machine is just 16.8 MHz !


2) The original CPU is ... try to guess ... ARM also. ( Same arch - no arch emulation is supposed to take place. The version of CPU shouldn't matter, as the original ARM revision is a lot older then the one we are using in the Pandora. )


3) From point 2, I can't understand why the code can't be run natively, other then that ARM used in GBA is backwards-incompatible with ours.

What you're suggesting doesn't work for a lot of technical reasons that I've talked about a lot in the past and don't feel like going into now. Suffice it to say, you have to at the very least check every memory access to emulate the address space of the GBA correctly, so there's a ton of overhead added.. both being ARM doesn't actually help that much. More importantly, you're talking about GBA as if it's just a CPU. It's not. It has, for instance, a pretty capable 2D video chip that takes quite a lot to emulate.


Games like Golden Sun have a lot of slowdown because they have a lot of self-modifying code which doesn't play well with the recompiler in gpSP. These would be especially impossible to virtualize. But something can be done better than what has been done.
 
OK, thanks everyone.


I understand the technical implications of emulating hardware - I've worked on PC virtualisation before, and I wrote a GB emulator for fun once.


When I get my Pandora (and I refuse to guess when that will be), would there be any opportunities to help improve the available GBA emulators? Is source code available? I know I can get source for VBA, don't know about gpSP.
 
Yeah the source code is available. I'm personally not going to touch it because I'd much rather work on a new emulator (but it's not so likely that I'd make the source available again, unfortunately)


Do you have anything in mind for improvement?
 
I can't really say what I'd improve until I know what's there already, that'd just be stupid.


My aims would be to improve compatibility and speed for games I want to run (if they have problems), at least to start with. Something I'd love to do would be implement link-play of some sort, but I don't know how people plan to work ad-hoc multiplayer with the Pandora.


I'm also interested to experiment with the dynarec - I've not actually done one on ARM before.
 
Last edited by a moderator:
I gave golden sun a try under GpSp and whilst not fully compatible, as it randomly quit from time to time, it seemed to run very nicely at stock speed. I didn´t have any battles but the wandering around the village at the start, the menus and dialog text bubbles etc were all just fine.
 
I can't really say what I'd improve until I know what's there already, that'd just be stupid.


My aims would be to improve compatibility and speed for games I want to run (if they have problems), at least to start with. Something I'd love to do would be implement link-play of some sort, but I don't know how people plan to work ad-hoc multiplayer with the Pandora.


I'm also interested to experiment with the dynarec - I've not actually done one on ARM before.

No offense, but isn't saying you'd improve things in general at least as bad..? It's great if you'd like to try helping but you should probably wait and see what you can do first before saying things like improving performance.. Like I said, the main speed traps in games like Golden Sun are related to the self-modifying code strategy and any improvement requires substantial change to the way it's handled. I did a bunch of code to this end in 2008 but it wasn't totally stable and extremely difficult to debug.


Link emulation is a really tricky thing for GBA emulation and isn't something that has been done all that well on any platform. You'll most likely get much better results out of emulating multiple GBAs at multiple endpoints and synchronizing inputs instead of transferring the link data itself. But gpSP isn't very well suited for that.


What sort of recompilers have you done before?
 
Last edited by a moderator:
I can't really say what I'd improve until I know what's there already, that'd just be stupid.


My aims would be to improve compatibility and speed for games I want to run (if they have problems), at least to start with. Something I'd love to do would be implement link-play of some sort, but I don't know how people plan to work ad-hoc multiplayer with the Pandora.


I'm also interested to experiment with the dynarec - I've not actually done one on ARM before.
If you're going to look at gpSP, you might like to try getting it to run natively on the Pandora before starting on any improvements. Pickle and I had a crack at it a while back and never managed to get it going. I can however set you up with something that compiles, at least.


I dare say that compiling VBA against Notaz's SDL with hardware scaling would give a bit of a performance boost, too. Something I've been meaning to do for a while but never got around to...
 
First off, I hope I didn't come off as arrogant or offensive in my posts above. I'm not trying to imply that I'm a better programmer or that your code is bad etc, it's just that sometimes a second pair of eyes spots something that the first misses.

No offense, but isn't saying you'd improve things in general at least as bad..? It's great if you'd like to try helping but you should probably wait and see what you can do first before saying things like improving performance.. Like I said, the main speed traps in games like Golden Sun are related to the self-modifying code strategy and any improvement requires substantial change to the way it's handled. I did a bunch of code to this end in 2008 but it wasn't totally stable and extremely difficult to debug.


Link emulation is a really tricky thing for GBA emulation and isn't something that has been done all that well on any platform. You'll most likely get much better results out of emulating multiple GBAs at multiple endpoints and synchronizing inputs instead of transferring the link data itself. But gpSP isn't very well suited for that.


What sort of recompilers have you done before?
Well, yes, it probably is just as bad ;)


I was just throwing out general things I'd like to do, but I'd want to go over the code before I made any massive decisions.


I know link emulation is tricky - and the fact that every built-in communication method on the Pandora is wireless is going to add unpredictable latency to the list of issues.


I've previously worked on a PPC to x86/x86_64 dynamic recompiler, along with 68000 and Z80 interpreters (for commercial use). I'd go into details but I'm restricted by NDAs. They don't interfere with me releasing code for something like this though - I asked.

If you're going to look at gpSP, you might like to try getting it to run natively on the Pandora before starting on any improvements. Pickle and I had a crack at it a while back and never managed to get it going. I can however set you up with something that compiles, at least.


I dare say that compiling VBA against Notaz's SDL with hardware scaling would give a bit of a performance boost, too. Something I've been meaning to do for a while but never got around to...
My biggest problem is that I have nothing I can actually test on until I get my Pandora. I was just really trying to find out what's done so far - I couldn't find much on GBA emulation, but I was finding lots on SNES, PSX, N64 etc.


Once I get my Pandora I'm willing to give this a go though.
 
Actually if you have commercial experience with recompilers then you probably can do better than gpSP.. I have a mountain of things that I'd try differently. It's all really a function of time, though. Just want to give you a heads up as to what you might expect looking at it.


I agree with SteveM that a native port of gpSP is the best first move right now. I would go so far as to say that you might want to try getting a version with the interpreter instead of the recompiler going, so you won't have to deal with the extra slowdown and crashes in the SMC heavy games like Camelot ones. Or you could do a hybrid that falls back to the interpreter for RAM code. But the problems Pickle and SteveM had with porting it probably had to do with recompilation (code flushing).


The guy doing the Android port looked into it and found that Golden Sun 2 is triggering an SMC condition that gpSP isn't even catching, so it could end up crashing no matter what. So running the interpreter in RAM is probably the best thing. It can possibly be optimized a little - the ARM interpreter only uses an 8-bit switch as opposed to the 12-bit one on VBA, but I'm concerned that that one might hurt icache a lot more. Even if VBA's ARM interpreter beats gpSP's, it'd still be worth it to leverage gpSP's renderer which is much faster.


Another thing is that Golden Sun 2 output 64KHz audio which isn't supported in gpSP.. I worked around it on the code on my harddrive at some point and could probably contribute that as a patch.
 
I'm uploading a video of the gpSP emulator..... well uploading a video of the gp2x version running on the pandora. that one running full speed.


the Visual boy advanced emulator has to run about 800 mhz before it's full speed, so i didnt want to spend any time on that one.


I couldnt test the pandora version of the gpSP because somehow I couldent get that one to work (hmm didnt spend too much time on it)


The video will be ready in about 20-30 min
 
Last edited by a moderator:
Actually if you have commercial experience with recompilers then you probably can do better than gpSP.. I have a mountain of things that I'd try differently. It's all really a function of time, though. Just want to give you a heads up as to what you might expect looking at it.


I agree with SteveM that a native port of gpSP is the best first move right now. I would go so far as to say that you might want to try getting a version with the interpreter instead of the recompiler going, so you won't have to deal with the extra slowdown and crashes in the SMC heavy games like Camelot ones. Or you could do a hybrid that falls back to the interpreter for RAM code. But the problems Pickle and SteveM had with porting it probably had to do with recompilation (code flushing).


The guy doing the Android port looked into it and found that Golden Sun 2 is triggering an SMC condition that gpSP isn't even catching, so it could end up crashing no matter what. So running the interpreter in RAM is probably the best thing. It can possibly be optimized a little - the ARM interpreter only uses an 8-bit switch as opposed to the 12-bit one on VBA, but I'm concerned that that one might hurt icache a lot more. Even if VBA's ARM interpreter beats gpSP's, it'd still be worth it to leverage gpSP's renderer which is much faster.


Another thing is that Golden Sun 2 output 64KHz audio which isn't supported in gpSP.. I worked around it on the code on my harddrive at some point and could probably contribute that as a patch.
You'd be amazed how bad some commercial code is ;)


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.

I'm uploading a video of the gpSP emulator..... well uploading a video of the gp2x version running on the pandora. that one running full speed.


the Visual boy advanced emulator has to run about 800 mhz before it's full speed, so i didnt want to spend any time on that one.


I couldnt test the pandora version of the gpSP because somehow I couldent get that one to work (hmm didnt spend too much time on it)


The video will be ready in about 20-30 min

Thanks for the video. There are some interesting draw bugs on the GP2X version of gpSP before you change the scaler - is this just because of the fact that it's running on a higher screen resolution? I assume it doesn't do that on an actual GP2X. It's encouraging though, it seems to run most of these games at a good speed already.
 
Back
Top