Gpsp 0.9-2xb

[White Demon]

@ White Demon:

Mario Kart Super Circuit (U) @ 250 Mhz & Ram Timings & mmuhack.o & Auto-Frameskip:2

Title screen: 53-60FPS
Selection screen: 40-44FPS
Character Selection screen: 35-37FPS
Race Start (rotate): 60FPS
Race: 33-37FPS
Race Finish/Placing Review: 45-54FPS

I don't see how these values seem to indicate anything but highly playable and also very enjoyable.
Granted the race is the slowest bit but the average FPS here was 35-36FPS which is my opinion is sufficiently smooth.

I've never said anything for or against how it runs in this version by itself. After playing it with autoframeskip @ 2 for a while now (since yesterday) it seems to run quite well, well enough to continue playing this way (at least once I got past the Snow Land circuit). What I've been noting all along is the emulation of the game runs slower than the previous version.

Here are the test results I originally posted on page 2 of this thread, taking from the in game fps display (not on any menus, but when actually racing)

Tested at 260mhz, with no ram timings

mario kart
settings: manual fs1
fps 0.9-2xa: 50(30)
fps 0.9-2xb: 42(30)

If you want to see this for yourself, then load up your Mario Kart rom in v0.9-2xa first, with manual fs1, Then do the same in 0.9-2xb, again with manual fs1. You will see the difference. Note DO NOT use auto when doing these tests, as it will produce incorrect results.

Exophase's efforts to increase compatibility are to be commended, and hell, if all I wanted was an emulator with no slowdown at all I'd go and play the PSP version. As it stands I actually prefer to play the GP2X version and the autoframeskip will quite certainly help me in some games now, where needed. It's just that I don't like people who have not tested this against the previous version refusing to believe the results of someone who has.

 

[slaanesh]

The GBA audio is internally resampled to 44.1KHz, and the frame rate is at 60Hz, so there are 735 samples per frame (2 bytes per sample, 2 channels brings it to 2940 bytes). Note that this is higher than 2048 bytes

Interesting.

In other emulators, reducing the sample rate can considerably increase performance. ie. CPS2EMU has the option of using 11025, 22050 and 44100. Setting to 22050 is probably the best compromise between quality and performance. MAME GP2X uses 16500 which is actually better still as I don't notice that much difference between 22050 and 16500. It certainly would be nice to have it as an option to increase performance.

What do you think?

Okay, well I tried 4096 bytes earlier today and I did notice a more constant FPS rate when in autoframeskip mode. I guess I can stick to that.

I think that on GP2X the buffer size has to be a power of 2, although this is only going by the settings zodttd allows.

Does the code make a call to ioctl(fd, SSNDCTL_DSP_SETFRAGMENT, &frag);?

I was looking through CPS2EMU source code and does set the size hint in this way.
Fragments sizes always need to be to the power of 2.

 

[Exophase]

I've never said anything for or against how it runs in this version by itself. After playing it with autoframeskip @ 2 for a while now (since yesterday) it seems to run quite well, well enough to continue playing this way (at least once I got past the Snow Land circuit). What I've been noting all along is the emulation of the game runs slower than the previous version.

Here are the test results I originally posted on page 2 of this thread, taking from the in game fps display (not on any menus, but when actually racing)

Tested at 260mhz, with no ram timings

mario kart
settings: manual fs1
fps 0.9-2xa: 50(30)
fps 0.9-2xb: 42(30)

If you want to see this for yourself, then load up your Mario Kart rom in v0.9-2xa first, with manual fs1, Then do the same in 0.9-2xb, again with manual fs1. You will see the difference. Note DO NOT use auto when doing these tests, as it will produce incorrect results.

Exophase's efforts to increase compatibility are to be commended, and hell, if all I wanted was an emulator with no slowdown at all I'd go and play the PSP version. As it stands I actually prefer to play the GP2X version and the autoframeskip will quite certainly help me in some games now, where needed. It's just that I don't like people who have not tested this against the previous version refusing to believe the results of someone who has.

You do realize your speed quotes directly contradict slaanesh's, right? He claims to have gotten auto-frameskip ~ 33-37 drawn at 250MHz with RAM timings on, which is significantly better than your results at 260MHz; I doubt the RAM timings alone would make that much of a difference. I've done benchmarks in the middle of the first track (Mario Circuit) and the raw speed of 0.9-2xb is faster.

I don't see how it's fair to claim auto frameskip produces "incorrect results." It has no affect on the fps rate calculation, it reports fps based literally on how much time has passed since the last polling and how many frames were actually drawn. Now, auto frameskip may be skipping more than it has to in certain circumstances, but the printout isn't lying.

Besides making sure you have mmuhack.o, I would recommend using the exact CPU_SPEED config file from 0.9-2xa. You'd have to give much more specific results too. You should make a savestate and let other people try it and determine if they get the same values with the same clock speed.

 

[White Demon]

You do realize your speed quotes directly contradict slaanesh's, right? He claims to have gotten auto-frameskip ~ 33-37 drawn at 250MHz with RAM timings on, which is significantly better than your results at 260MHz; I doubt the RAM timings alone would make that much of a difference. I've done benchmarks in the middle of the first track (Mario Circuit) and the raw speed of 0.9-2xb is faster.

I don't see how it's fair to claim auto frameskip produces "incorrect results." It has no affect on the fps rate calculation, it reports fps based literally on how much time has passed since the last polling and how many frames were actually drawn. Now, auto frameskip may be skipping more than it has to in certain circumstances, but the printout isn't lying.

Besides making sure you have mmuhack.o, I would recommend using the exact CPU_SPEED config file from 0.9-2xa. You'd have to give much more specific results too. You should make a savestate and let other people try it and determine if they get the same values with the same clock speed.

You see, your reponse to mine supposedly claiming that autoframeskip produces incorrect results. Did you even read that part of the post? I was saying that in relation to the test I posted there for Slaanesh to try. Read it again:

If you want to see this for yourself, then load up your Mario Kart rom in v0.9-2xa first, with manual fs1, Then do the same in 0.9-2xb, again with manual fs1. You will see the difference. Note DO NOT use auto when doing these tests, as it will produce incorrect results.

That is the exact test my results came from. I was also running the SNOW LAND circuit from the STAR CUP, which seems to tax the emulation more than other tracks.

If doing a raw speed test like that, how the hell is autoframeskip going to give accurate results? Slaanesh's test has been done using autoframeskip to give 'real world' results, ie how it would perform when actually playing the game. And there's no comparison with any other version listed in his results either.

OK then, I decided to do the same test that Slaanesh did, and for thoroughness I did it at 250 & 260. I also put the ram timings in, which I found on a previous gpsp thread. If these are incorrect please list what the correct settings are.

QUOTE

CAS 2
tRC 6
tRAS 4
tWR 1
tMRD 1
tRFC 1
tRP 2
tRCD 2



And yes I do have the mmuhack.o file (I have stated as such previously you know)

So, with that in mind, here are my results.

Mario Kart Super Circuit (U) @ 250 Mhz & Ram Timings & mmuhack.o & Auto-Frameskip:2
I was running the PEACH CIRCUIT from the MUSHROOM CUP.
I took the number that was listed in the brackets, this is the correct number to get right?

title screen 55 - 60 left on title screen for more than 30 seconds
selection screen 33 - 44
character select 28 - 35
race start (rotate) 60
race 25 - 32
race finish 35 - 43

Everything is comparable with Slaanesh's results, right up until the race. Then the results are worse than his. And I'm running it in the exact same way he is, with no settings different.

Next test, @ 260mhz.

Mario Kart Super Circuit (U) @ 260 Mhz & Ram Timings & mmuhack.o & Auto-Frameskip:2
I was running the PEACH CIRCUIT from the MUSHROOM CUP.

title 41 - 60 left on title screen for more than 30 seconds
selection screen 34 - 45
character select 34 - 37
race start (rotate) 58 - 60
race 27 - 37
race finish 38 - 44

Seems comparable, but the race finish/placing review on mine is still slower @ 260 than his at 250.

So how the hell can Slaanesh's results be better when I've set everything up exactly the same?

OK, now I really would like Slaanesh to do my test.

1. Set your GP2X up the same as mine (ie no ram timings @ 260. If your GP2X can not go to 260 tell me and I'll do another test at 250 as well).
2. Load up 0.9-2xa and run mario kart. Make sure to set the frameskip to manual fs1.
3. Make sure to select the STAR CUP, so that the results are gathered from the SNOW LAND circuit.
4. Note the AVERAGE results of the fps display IN THE RACE ONLY. Don't look at the number in the brackets, as that will always show 30. Get the other number.
5. Load up 0.9-2xb, set up exactly the same, and run exactly the same test.

If you STILL can't understand, here is how this test should be set up in both versions of gpsp:

Mario Kart Super Circuit (U) @ 260 Mhz & no ram Timings & mmuhack.o & manual frameskip:1

I'll be interested to see the results of him doing my test, based on my results when running his test.

 

[Exophase]

You see, your reponse to mine supposedly claiming that autoframeskip produces incorrect results. Did you even read that part of the post? I was saying that in relation to the test I posted there for Slaanesh to try. Read it again:

Yes I read your post entirely and understood whatever it was you were trying to say, I don't need you to repeat yourself.

If doing a raw speed test like that, how the hell is autoframeskip going to give accurate results? Slaanesh's test has been done using autoframeskip to give 'real world' results, ie how it would perform when actually playing the game. And there's no comparison with any other version listed in his results either.

Autoframeskip will show you the performance that gpSP is at LEAST capable of attaining, so it's a perfectly valid lower limit on the benchmark. By seeing how many frames it had to skip you determine how fast it ran. Let me make this abundantly clear to you. An fps rating of 60(30) in auto frameskip is significantly faster than 42(30) with frameskip 1 on. In the first case 30 rendered frames got you 100% performance, in the second case 30 rendered frames only got you 70% performance, which is 43% worse. When the rendered frame amounts vary you can't compare them as directly, but I guarantee you that 60(27) (the lower end of what you reported) is still much faster than 42(30).

You're asking how someone could get different results from you. Isn't it obvious when you haven't even established which track you're testing? You said yourself that some are more demanding than others, this should go without saying. The results you just posted are also a ton better than the 42(30) you originally claimed.

The entire point here is that you've been saying that 0.9-2xb is slower than 0.9-2xa, and you keep repeating one citation to demonstrate this but you're not taking the comparison between the two seriously. It would help if you actually repeated the exact same tests you did for 0.9-2xb (under the same variables!) under 0.9-2xa and then looked at speed. Because I've done raw benchmarks (see my blog if you don't know what I mean) and 0.9-2xb has been consistently faster.

 

[slaanesh]

Okay I've conducted the tests as per White Demon's instructions and have found that it IS indeed slower with the way he'd set it up.
I scored between 46-52(30) with 0.9-2xa and 41-44(30) with 0.9-2xb.

I'd said that 0.9-2xb was faster than 0.9-2xa and White Demon had said the opposite and we were both correct with our own tests.

However, I'm still going to stand by my comments. I am a fan of autoframeskip and if implemented correctly (like gpSP) will always provide better results than a manually set frameskip.
I also think 0.9-2xb is faster especially using the setup I originally described. The only tweak I've made now, based on Exophase's explanation of the workings of the sound system is to use a 4096byte sound buffer.

 

[Exophase]

Okay I've conducted the tests as per White Demon's instructions and have found that it IS indeed slower with the way he'd set it up.
I scored between 46-52(30) with 0.9-2xa and 41-44(30) with 0.9-2xb.

I'd said that 0.9-2xb was faster than 0.9-2xa and White Demon had said the opposite and we were both correct with our own tests.

However, I'm still going to stand by my comments. I am a fan of autoframeskip and if implemented correctly (like gpSP) will always provide better results than a manually set frameskip.
I also think 0.9-2xb is faster especially using the setup I originally described. The only tweak I've made now, based on Exophase's explanation of the workings of the sound system is to use a 4096byte sound buffer.

The only possible explanation for autoframeskip performing that much better than manual frameskip is that manual frameskip is broken, not that the emulator is slower. That I'll have to look into.

Try running in in fast forward and see if the performance stays the same or improves.

 

[cHEM]

Regarding the freezing, I am now using the modified ram-timings, and 4096 sound buffer, and, so far, everything seems to be performing better. so thumbs up here.

Funnily enough, I needed to make BOTH these modifications before things improved, if anything, just increasing the sound buffer seemed to make the crashing more prolific, it crashed 3 times in a row within about 20 minutes yesterday with this change (ingame saves only, no save states), which its never done before.

Edit: Scrap that.. just been playing for about 35 minutes and it locked up again.. Just as I was stomping home with a major victory! ah well! it does seem *better*, however.

 

[ste_167]

You need more pessamistic thoughts! I've not had a lock-up yet!

 

[greenmikey]

in reguards to crashing..I was using firmware 2.0 and getting crashes in zelda: minish cap and others; after an upgrade to 2.1.1 I have yet to crash after a few hours of play.

River city ransom ex resets the whole emu when story mode is selected. I'll have to go through and test other games after my firmware upgrade to see what goes haywire still.

 

[Rivroner]

Maybe firmware makes the difference.
I am using 2.1.1 too

 

[Zeladin]

And so am I.. on 2.1.1. Still I haven't done much more gp2x/gbaing since my 3hr test...

 

[rokdcasbah]

Regarding the freezing, I am now using the modified ram-timings, and 4096 sound buffer, and, so far, everything seems to be performing better. so thumbs up here.

Funnily enough, I needed to make BOTH these modifications before things improved, if anything, just increasing the sound buffer seemed to make the crashing more prolific, it crashed 3 times in a row within about 20 minutes yesterday with this change (ingame saves only, no save states), which its never done before.

Edit: Scrap that.. just been playing for about 35 minutes and it locked up again.. Just as I was stomping home with a major victory! ah well! it does seem *better*, however.

sounds like the problem i had. it turned out to be the ram timings. i had assumed that if the ram timings were bad then the unit would crash as soon as you applied them (which is the case most of the time) but it is possible to get some timings that will chug along and then shut like rusty gears. once i screwed around with them even more, gpsp started running really smooth, with no breakup in the audio whatsoever...but a tiny bit of lag, but i like the lag because it lets me know there isn't a crash on the horizon

 

[greenmikey]

I've done some testing..all at 240mhz with optimal ram timings and 8,192 audio

super mario advance: while playing mario 2..extreme slowdow happens while the screen scrolls up or down

Megaman battle network 4 red sun or whatever its called does not even launch, it freezes the emu

Grand theft auto advance: resets emu after selecting your name

Kirby and the magic mirrior (something like that) smooth like butter other then slowdown while going through mirriors (dosen't effect gameplay)

Sonic Advance 2 is smooth

zelda: minish cap is great playing.

River city ransom EX- locks up when begining game kicks out of emu back to menu

Shining force advance (dont remember name) Seems decent, i'm not certain because although I love this game I hate the short bullshit in the begining having to talk to everyone so I had about 20 seconds in battle. Turn based shouldnt make a difference speed wise reguardless.

there were a TON more but I work is calling...

I'm not sure that fast forward really works..I only tried it on one game and it didnt seem to be useful.

Volume changes are too small, I have to hit the button like 3261267 times to get the volume to lower.

Thanks for this exophase, you have done some great work.

If anyone was too lazy to test something, I'm sure I can find it and do the work for you

 

[Tobriand]

Re: Slow crashes, I remember my GP32 used to be in that boat (the first one which I lost) - it would play at 166MHz, but only for 10-15 minutes, then would shut off. Then if you turned it back on and tried again it would only last 5 minutes or so usually, unless it was very cold. Lasted longer if it wasn't writing to the whole screen. My next GP32 was one of those rare ones that could go up to ~220Mhz, though, which I was most pleased about. Wonder if there's every any chance of a GP32 port of GPsp... if only "because it would be cool"...

 

[slaanesh]

The GP32's lack of RAM is the biggest problem here. If it had even 16MB of RAM I think it might work, but it doesn't... so....

 

[White Demon]

Okay I've conducted the tests as per White Demon's instructions and have found that it IS indeed slower with the way he'd set it up.
I scored between 46-52(30) with 0.9-2xa and 41-44(30) with 0.9-2xb.

I'd said that 0.9-2xb was faster than 0.9-2xa and White Demon had said the opposite and we were both correct with our own tests.

Thanks for running that test. I also ran one final test, with 0.9-2xa, auto fs2, and all other settings the same, and guess what - the previous version ran slower with these settings. So whatever. I don't really think I care anymore. It seems to run fine on the new version, so I'll just go with that.

Time for me to stop screwing around and get in some serious sessions with Metroid Fusion (I think auto fs1 should suffice for that. Sorry, just thinking out loud).

Maybe firmware makes the difference.
I am using 2.1.1 too

I doubt that. I'm on firmware 2.0, no crashes here.

 

[greenmikey]

Maybe firmware makes the difference.
I am using 2.1.1 too

QUOTE

I doubt that. I'm on firmware 2.0, no crashes here.



What make of gp2x are you using..I had problems crashing on 2.0 with my first edition with 2.1.1 it was fine. I don't remember what hardware differences between the models there are but it might just be a small quirk.

I am about 90% sure that my firmware upgrade was the changing factor in my current lack of crashes. Although I guess it is possible that I had a slightly bad flash on my old 2.0 firmware but im not going back to make sure

 

[Zeladin]

QUOTE
I am about 90% sure that my firmware upgrade was the changing factor in my current lack of crashes. Although I guess it is possible that I had a slightly bad flash on my old 2.0 firmware but im not going back to make sure

Of course it could just be unstably unstable... I was playing again last night, no crashes. Looks like this could be a very elusive bug.

So things to try now;
increase sound buffer to 4096mb
switch off optimized ram timings?
Be paranoid.*
Use FW 2.1.1?
Use fresh batteries

If there's anything else... Hopefully some of those things might help Exophase track down the problem too.
I wondering about manual FS... I was using it before, and I switched to autofs as it seemed like FS1 wasn't needed all the time...

*Seems to work best.

 

[Exophase]

I've done some testing..all at 240mhz with optimal ram timings and 8,192 audio

super mario advance: while playing mario 2..extreme slowdow happens while the screen scrolls up or down

Which version (country code) of the game are you using? Could you do me a favor and try the USA (U) version - assuming you have game_config.txt around it should run much better. Or if you'd prefer I could find the idle loop for whichever version you're using (I'm assuming the E version)

I'll look into the other games too, except GTA which I know is a weird timing issue (at the very worst I can add a manual hack for the game to get around it), and I can change the volume (and make it remember it in the config file).