Gpsp (gba Emulator) V09-2xb_1 Released


DaveC said:
fusion_power said:
I started with Advance Wars on GP2X (good game! ) but I noticed, that it was unusualy slow. Crappy sound, crappy FPS. I checked the ROM header and it was the correct US rom "AWRE01" so it should be compatible with the rom-config-file. But then I noticed, that there seems to be 2 Versions of the rom and I was right.
I was playing "Advance Wars (U) (V1.1) [!].gba" and this was the wrong revision I think. With "Advance Wars (U) (V1.0) [!].gba" crappy Sound was gone and FPS were much better. The revision 1.1. seems to have the idle_loop on another place (but it has such a loop to when I read the VBA debugger correctly :lol: )
I hope someone will fix the other revisions of this rom somedays so we can even play the EU Version of this game. :)




Better yet would be if the emu didn't have to rely on the ROM header and config file. It seems tricky to make sure the ROM you have matches the ROM on that list. I don't know if that is possible but if it is that would make things alot simpler.

Thats true. But somehow these loops and code glitches have to go out from the roms. Me for myself is always on the side of the performance, so everything what improves FPS is always welcome for me. :) Even such Rom-sensible Emulators. But I hope for a better solution for GPSP someday.
 
Last edited by a moderator:
fusion_power said:
Thats true. But somehow these loops and code glitches have to go out from the roms. Me for myself is always on the side of the performance, so everything what improves FPS is always welcome for me. :) Even such Rom-sensible Emulators. But I hope for a better solution for GPSP someday.
Yeah speed is very important, especially for me with my lame 240 MHz unit with terrible battery life :p

I was just hoping the emu could somehow "know" what to do when it comes across this dodgy code kind of like how a real GBA does. Real GBAs don't slow down with these loops and glitches. It can be kind of hard to make sure every ROM matches exactly what is in this config file thing. I know I have alot of stuff that doesn't match like Astro boy for example as the sound is a stuttery mess and the framerate is poor. I am not quite sure even how to fix it. Maybe search for the correct ROM by um "finding" and trying them all until one is a match? Or maybe finding some header utility that displays the header, then editing the config to make them match? Then what do you do when you have a game that isn't even on that list like all Japanese or Euro games? I would hope that there is a better way eventually.
 
Last edited by a moderator:
DaveC said:
fusion_power said:
Thats true. But somehow these loops and code glitches have to go out from the roms. Me for myself is always on the side of the performance, so everything what improves FPS is always welcome for me. :) Even such Rom-sensible Emulators. But I hope for a better solution for GPSP someday.
Yeah speed is very important, especially for me with my lame 240 MHz unit with terrible battery life :p

I was just hoping the emu could somehow "know" what to do when it comes across this dodgy code kind of like how a real GBA does. Real GBAs don't slow down with these loops and glitches.


Many video games, especially the 2D type are highly dependant on screen vsync for their timing. Say, for simplicity sake, the main part of code is executed as soon as the screen starts drawing. This is done to keep screen updates in sync with the output device.

Anyway, the main CPU has to be doing something all the time. It doesn't just sit around doing nothing if there is nothing to do. For example a GBA has a CPU clocked at ~17Mhz, that's 17,000,000 instructions a second. The frame rate of the GBA is 60FPS, therefore it has to execute 17,000,000 / 60 = 283333 instructions every frame. It might be able to complete whatever it needs to do in only 200,000 instructions. What does it do for the remaining 83,333?

One example is an Idle Loop. It waits around until the frame is complete. In this case, it might enter a very simple check/loop situation continuously checking when the end of the frame is reached. And it does this check and loop many, many times.

gpSP uses information in game_config.txt to locate where these kind of loops occur to skip this code rather than accurately emulating these needless loops (and thus slowing the rest of the emulation down).
If you want accurate emulation you would want to execute it but one a 250Mhz (or so) machine you don't have these luxuries.

So how do you easily detect this? Well the easiest and possibly quickest way is NOT to detect it; rather know where it occurs. This means that some one has to discover where they are and provide the necessary information. ie. game_config.txt
Other emulators have done this kind of thing in the past - PCEAdvance: the PC Engine emulator for the GBA is one that comes to mind.

Detecting these kind of loops on the fly could possibly also done. I think some of the MAME CPU emulators can do this.

There are probably other methods but I think having a database is a good way of doing this for now.
 
Last edited by a moderator:
all i wish for now is that the volume can be turned down as you can`t do that on my gp2x for some reason. Does anyone else have that problem ?
 
morcar said:
all i wish for now is that the volume can be turned down as you can`t do that on my gp2x for some reason. Does anyone else have that problem ?
Are you sure about that? I thought so at first, too, but then I realized that it does turn down the volume when I press vol-, only very little, and it does not repeat. So to lower the volume, you'd need to press vol- several times (whilst avoiding pressing middle, since that brings up the menu). Once I figured that out, my ears was a lot happier :)
 
Last edited by a moderator:
slaanesh said:
So how do you easily detect this? Well the easiest and possibly quickest way is NOT to detect it; rather know where it occurs. This means that some one has to discover where they are and provide the necessary information. ie. game_config.txt
Other emulators have done this kind of thing in the past - PCEAdvance: the PC Engine emulator for the GBA is one that comes to mind.

Detecting these kind of loops on the fly could possibly also done. I think some of the MAME CPU emulators can do this.

There are probably other methods but I think having a database is a good way of doing this for now.
This works fine for games that match that list exactly. What to do about the ones that don't though? There are allot, and the ones I have seem to fall into that catagory unfortunatly ;) If the emu can't detect on the fly maybe there could be some kind of utility that does it once and then adds an entry into that list maybe? That does sound like work though. What do you think would be a good solution for these other ROMs?
 
Last edited by a moderator:
If someone want to search for this rom config entries, I need fixes for Advance Wars European version...ok lets take ALL european versions of games to fix. ;) The GPSP Rom config seems to like only US versions much. Maybe someone has time and mood and a clue how to do this. I have VBA and know the debug-window but I have no clue what I have to insert in the config file. ^^""
 
There was another thread somewhere hear which discussed exactly how to do this. You need a PC GBA emulator (I think it was Visual Boy Advance) and a little knowledge of what to look for. :)
 
slaanesh said:
There was another thread somewhere hear which discussed exactly how to do this. You need a PC GBA emulator (I think it was Visual Boy Advance) and a little knowledge of what to look for. :)
I know. I had read this thread and I found some of these code glitches like described, but I have no clue WHAT numers exactly I have to insert in the rom-Config file. So I hope others were more sucsessful than me. :)
 
Last edited by a moderator:
DaveC said:
slaanesh said:
So how do you easily detect this? Well the easiest and possibly quickest way is NOT to detect it; rather know where it occurs. This means that some one has to discover where they are and provide the necessary information. ie. game_config.txt
Other emulators have done this kind of thing in the past - PCEAdvance: the PC Engine emulator for the GBA is one that comes to mind.

Detecting these kind of loops on the fly could possibly also done. I think some of the MAME CPU emulators can do this.

There are probably other methods but I think having a database is a good way of doing this for now.
This works fine for games that match that list exactly. What to do about the ones that don't though? There are allot, and the ones I have seem to fall into that catagory unfortunatly ;) If the emu can't detect on the fly maybe there could be some kind of utility that does it once and then adds an entry into that list maybe? That does sound like work though. What do you think would be a good solution for these other ROMs?


What do you mean by games falling under that category? Do you mean different regions or versions of the games there, or different games altogether? Because if you mean different games then chances are good that they don't belong in that list. For alternate versions/regions of what's on there the best solution is to get someone to just find them and add them.

Detecting idle loops statically would be very difficult to flat out impossible a lot of the time. Dynamic analysis might give some good hints but if it messes up it could break the game.

It's true other emulators do automatic idle loop detection, but it's either because the games use very simple idle loops, or they use very standard ones (so there's a few specific patterns that all games use). A lot of the ones I've seen in GBA games are very complex, they'll make function calls inside them for instance. They're not usually like the vcount polling loops you see in demos.

EDIT: I looked at how PicoDrive does it (notaz, please tell me if I'm wrong), and I saw two methods employed:

One thing it does is checks to see if an I/O register is being polled a lot, and if it is, stops the CPU until an event occurs. This doesn't involve checking the code at all (which is expensive for an interpreter).

Unfortunately most GBA games seem to have their idle loops poll local memory that's modified due to interrupts, rather than by reading I/O registers. Another downside is that this would make reading I/O registers a lot slower (right now they get mapped straight to a memory region), but since they're only really read a lot when polling happens anyway that might not matter. Another issue with this is that far more GBA games need proper horizontal synchronization, for HIRQ, HDMA, polling, or vcount trigger, and GBA games also have fairly high resolution timers. This means that event periods can get pretty small, so there isn't a lot of room to check for things falling into loops.

Another thing it does is checks to see if it's in a two instruction loop where the registers don't change.

GBA idle loops just aren't this simple, most of the time. This kind of loop also can't be statically determined, it'd have to be checked in an interpreter. PicoDrive only seems to check if it fell into a loop like this at certain intervals (although I'm not sure how those two extra instructions are compensated for)..

I did encounter one idle loop in a GBA game once that can be easily detected at runtime, a branch to itself. I think this was the only game I saw that did this though. I might more closely look at some of the games to see if there are any simple patterns I can detect.
 
Last edited by a moderator:
Exophase said:
DaveC said:
slaanesh said:
So how do you easily detect this? Well the easiest and possibly quickest way is NOT to detect it; rather know where it occurs. This means that some one has to discover where they are and provide the necessary information. ie. game_config.txt
Other emulators have done this kind of thing in the past - PCEAdvance: the PC Engine emulator for the GBA is one that comes to mind.

Detecting these kind of loops on the fly could possibly also done. I think some of the MAME CPU emulators can do this.

There are probably other methods but I think having a database is a good way of doing this for now.
This works fine for games that match that list exactly. What to do about the ones that don't though? There are allot, and the ones I have seem to fall into that catagory unfortunatly ;) If the emu can't detect on the fly maybe there could be some kind of utility that does it once and then adds an entry into that list maybe? That does sound like work though. What do you think would be a good solution for these other ROMs?


What do you mean by games falling under that category? Do you mean different regions or versions of the games there, or different games altogether? Because if you mean different games then chances are good that they don't belong in that list. For alternate versions/regions of what's on there the best solution is to get someone to just find them and add them.


All of the above. Different regions (there are some Japanese games that aren't available as a US version), games that aren't on the list at all, alternate versions.

It sounds complicated to get around it though. I guess it is best to only include the stuff that is on the list, and forget about the rest. I suppose there are enough games that are on the list, I can do without the teenage girl mah-jong games I suppose :p
 
Last edited by a moderator:
DaveC said:
All of the above. Different regions (there are some Japanese games that aren't available as a US version), games that aren't on the list at all, alternate versions.

It sounds complicated to get around it though. I guess it is best to only include the stuff that is on the list, and forget about the rest. I suppose there are enough games that are on the list, I can do without the teenage girl mah-jong games I suppose :p
Okay, but yet again I need to remind you that most games don't HAVE idle loops and therefore don't benefit from having an entry in the list...
 
Last edited by a moderator:
this emulator is great--sonic battle indeed played flawlessly for a few rounds, i'll abuse it more on the train. and the menu system and key config for this emulator are great, and it writes battery .savs! quite impressive.

is there any chance this emulator will play gbc games? i wish there was an emulator this good for gbc so i could rock lsdj :)
 
Exophase said:
DaveC said:
All of the above. Different regions (there are some Japanese games that aren't available as a US version), games that aren't on the list at all, alternate versions.

It sounds complicated to get around it though. I guess it is best to only include the stuff that is on the list, and forget about the rest. I suppose there are enough games that are on the list, I can do without the teenage girl mah-jong games I suppose :p
Okay, but yet again I need to remind you that most games don't HAVE idle loops and therefore don't benefit from having an entry in the list...


That is fine. I just have to test and keep only the games that work well. It is odd but some games run very poor like AstroBoy at 240 MHz. It is choppy and has alot of stuttery sound. I thought it may be due to it not matching the list. Other games run great at fullspeed with good sound though. I will just pick those to play, as I said there are enough that run well. Thanks again for the great work on this and the informative blog entries too :)

Have you ever thought of ditching the CPU tweaker thing (it is kind of annoying anyway) and parameterize it so that you can set clock speed on a per game basis? I think that would be nice as some games need more OC than others.
 
Last edited by a moderator:
DaveC said:
Have you ever thought of ditching the CPU tweaker thing (it is kind of annoying anyway) and parameterize it so that you can set clock speed on a per game basis? I think that would be nice as some games need more OC than others.
Yes. Hopefully next release will be like that, but I don't know how I'll handle RAM tweaking (I don't think an all or nothing option is good, I've gotten problems with the "ideal" settings)
 
Last edited by a moderator:
I asked this on another thread, but didn't get a clear response, perhaps Exophase, or someone else could answer it:

Why does full screen on gpsp look a bit choppy? It doesn't look that way on the PSP, nor did it when I did full screen on visual boy for the GP2X.

Thanks,
 
I can answer that I think. It's because there are no scaling filters available as of yet. Postprocessing of the output image is very heavy on the cpu. That's why you can pretty much see all the pixels doubled.
 
GPM2k6 said:
I asked this on another thread, but didn't get a clear response, perhaps Exophase, or someone else could answer it:

Why does full screen on gpsp look a bit choppy? It doesn't look that way on the PSP, nor did it when I did full screen on visual boy for the GP2X.

Thanks,
PSP has hardware accelerated bilinear filtering. I can't speak for VBA, but it's probably one of two things (or a combination of both), the aspect ratio being maintained (something I just haven't bothered to fix yet) or some software filters being used (which are way too slow for me to care about).
 
Last edited by a moderator:
Back
Top