Gpsp 0.9-2xb


I am using firm 2.1.1 and freezes are not happen so often.
Maybe 1 or 2 locks up after 4 days of playing like 2 hours every day.
 
Froze only once yesterday while playing Pokemon Leaf Green about 2 hours. This version looks much more stable than Gpsp-xa, and in-game saves now works! Cool, so i can swith now from v.9008.

By the way, speed and sound have been improved greatly, thanks for your hard work.

Forgot to mention, I am on FW 3.0.0 MK2
 
DaveC said:
A few other bugs I noticed. Everytime you start the emu it shows an unscaled screen in the upper left. I go into the menu and it says "scaled" but it is not. I change to "unscaled" and it centers it. It doesn't save my settings either, I have to do it every time.
Yes, but you just have to return to the menu short and go back ingame, and the screen is centered again. You don't need to change something in the screen-config. ;)

Yes, auto-Frameskip still is a little bit choppy here and there, maybe this could be solved with finer steps. FS 0.5, 1, 1.5, 2...
I mean FS 0.5 is XXX.XXX.XXX (X -frame, . -skip)
FS 1 : X.X.X.X.X
FS 1.5: XX.XX.XX.XX
FS 2 : X..X..X..X
 
Last edited by a moderator:
Has anyone tested Fire Emblem on it? I ask as the gPSP version for the psp seems unable to play it. It'll go as far as the first battle, but will crash in the same place half way through each time. It'd be great to have this roaming around.
 
Yes, it freezes after 15-20mins of playing!

(FW 3.0.0, CPU 266MHz, no memory tweaks)
 
If some people could list the following (both for people with constant freezing and less constant)

How frequently it freezes;
What games you're using, include size in MB;
Audio buffer size;
Whether or not you're using savestates from previous versions;

Also, if some people who get freezing regularly in a certain game with their settings could try leaving it by itself for several minutes to see if it freezes on its own. It may be helpful to assign "fast forward" to one of the buttons and press it, this may or may not run it faster than real time (it'll run with very high frameskip and desync sound to push it as fast as it can).. actually I haven't tested fast forward on the GP2X version so someone should confirm that that works too.

BTW, Driver 2 Advance is one of those GBA games that has a heavy case of "IWRAM thrashing", which brings the recompiler to knees, forcing it to constantly recompile code. I have a different strategy in mind that might alleviate the cost of this, but I haven't worked out the data structure issues behind it yet.

I'm kinda surprised people want to play this game, it looks pretty ridiculous ^^ Especially the player who looks like an Atari 2600 figure in 3D. I know GBA isn't a dedicated 3D platform but this is probably the worst looking 3D game for it.
 
Hey Exophase;

Not sure if this will be of any help, but heres what I've come up with;

Advance Wars (I THINK this is a 16mb game, but am at work so can't confirm right now)

the freezing occurs anything between the first couple of minutes upto about an hour into play. Strangely, it seems to happen more frequently when I have finished a turn or am using a special power, though this may be coincidence.

Audio Buffer - default, 2048.

I was using save states from a previous version, but I have now moved on, and so they are from the current release (does this matter?)

funnily enough, if its frozen once, and I reboot, it seems fine from then on in.

Next time it happens I'll see if it recovers itself after a couple of minutes.
 
Try using a larger audio buffer size and see if it freezes as much. By the way, I meant to try leaving it running by itself when not frozen to see if it freezes. Once it freezes there's no way it'll resume again.
 
Baldur's Gate Dark Alliance - 8mb, 2048 sound buffer, old savestates(v9008). Gp2x at default setting and at 240mhz OC.

I have no idea of the frequency, I'll continue playing on this version just for the purposes of beta testing and I'll report back. will also test with a bigger audio buffer.

Hope you get the info you need to fix it up.

Edit; I just noticed that there are .cfg files in the roms folder - these for me would also be from the old version. I assumed that the comments about the game config referred to game_config.txt... Might these cause problems (I suspect not but just in case).
 
fusion_power said:
Yes, auto-Frameskip still is a little bit choppy here and there, maybe this could be solved with finer steps. FS 0.5, 1, 1.5, 2...
I mean FS 0.5 is XXX.XXX.XXX (X -frame, . -skip)
FS 1 : X.X.X.X.X
FS 1.5: XX.XX.XX.XX
FS 2 : X..X..X..X
How do you skip 1/2 of a frame? ;)
 
Last edited by a moderator:
Well I loaded up a 9008 savestate, and its been sitting about 20 minutes now (idle) no crashing. I removed the v9008 game specific cfg too, just to complicate things. I have frameskip off, 240mhz, left the audio buffer as it was for the moment... I think I might go play it a bit now.. seeing as that would be more entertaining - and random internet browsing has bored me...
 
DaveC said:
fusion_power said:
Yes, auto-Frameskip still is a little bit choppy here and there, maybe this could be solved with finer steps. FS 0.5, 1, 1.5, 2...
I mean FS 0.5 is XXX.XXX.XXX (X -frame, . -skip)
FS 1 : X.X.X.X.X
FS 1.5: XX.XX.XX.XX
FS 2 : X..X..X..X
How do you skip 1/2 of a frame? ;)

No, I just name it so. I don't know if FS work this way but FS 0.5 would just skip every 3. or 4. frame just to smooth everything while auto-FS is on... ^^""

Random freezes:
I played the whole Metroid Fusion game on GPSP and now the 2. time and the freezes are absolutely not reproduceble. Sometimes I can play hours and nothing happens, then it crashes after some second's/ minutes of play. Doesn't matter if I use Savestates or SRAM states or start a new game. (Like Castlevania COTM )
266MHz; Audio 2048; RAM-Tweaks on
It would be an improvement if the emulator wouldn't crash the whole GP2X. :lol: Even with Wrapper on from Gmenu it hangs my Handheld - no other program has this skill. ^^
 
Last edited by a moderator:
And ... just as I was thinking I must have imagined last night, it crashed, after about an hours gaming. I'll try and up the audio buffer size now, I guess...

Hmm I've proved nothing, my battery is nearly dead - should have started with fresh ones I guess. Gonna go for another gaming blitz on fresh ones see how I go.
 
This may not be a preferable alternative to turning it off, but if it does freeze you can probably kill it by telnetting in.

My current thoughts are that the crashing is related to a psychological connection between yourself and the GP2X. Apparently the GP2X is engineered to most accurately prove you wrong. Try thinking pessimistic thoughts the entire time and it might not crash.
 
Exophase said:
My current thoughts are that the crashing is related to a psychological connection between yourself and the GP2X. Apparently the GP2X is engineered to most accurately prove you wrong. Try thinking pessimistic thoughts the entire time and it might not crash.
You might be onto something there!

Now if I could just find an emo kid to test it for me... :p
 
Last edited by a moderator:
Exophase said:
This may not be a preferable alternative to turning it off, but if it does freeze you can probably kill it by telnetting in.

My current thoughts are that the crashing is related to a psychological connection between yourself and the GP2X. Apparently the GP2X is engineered to most accurately prove you wrong. Try thinking pessimistic thoughts the entire time and it might not crash.
Seems to be working, its been running about three hours now... Oh no! That's not pessimistic thinking!! Agh!! Good thing I turned it off - better that way, no disappointment... :)

I did switch the audio buffer to 4096mb, so maybe that helped. Certainly worth a try. Maybe some kind of memory leak?? I have no idea... I think that's the extent of my specific testing for now. I will continue using this version despite the stability problems, more useful frustration may emerge...
 
Last edited by a moderator:
gpSP uses a circular buffer for sound. The emulator advances one pointer into a buffer (not the one whose size is specified, that's another sound buffer), the callback thread advances another. If the pointers are too far apart, waiting is done until they catch up.

With the sound buffer too small there might be a deadlock occuring between the two. I recommend higher audio buffer sizes (4096 probably gives better performance anyway, if at the cost of a little lag)
 
raising my overclock seems to have solved it, if that makes any sense :p

so maybe it WAS my ram latencies, even though i tried lots of different combinations, and they're pretty conservative (either at or above defaults)?

i do notice more lag in the audio now, before i could set the buffer to whatever and there was never a lag (that i noticed), now one seems to creep up on me as i'm playing. it's all very fishy, i'd say. i kind of want to blame the cpu tweaker, although when i was pressing start to bypass it i was still getting crashes...does anyone know if pressing start bypasses the ram timings?

edit: maybe i'm dumb and pressing start just applies all the settings anyway?
 
I've found that an audio buffer of 2048 bytes is a good compromise between speed and latency.

I haven't looked at the code, but was wondering how many fragments this is split into?
If the fragment size is constant then increasing the buffer would allow for more fragments, which would mean less chance of stuttery sound but increased latency (as each fragment is basically a one frame delay in playing time).

Is this correct?
 
slaanesh said:
I've found that an audio buffer of 2048 bytes is a good compromise between speed and latency.

I haven't looked at the code, but was wondering how many fragments this is split into?
If the fragment size is constant then increasing the buffer would allow for more fragments, which would mean less chance of stuttery sound but increased latency (as each fragment is basically a one frame delay in playing time).

Is this correct?
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, which means that's not a particularly good choice for a buffer size, IMO (I think on the PSP version anything less than 2940 doesn't even work). 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. But you can see that the frame rate doesn't divide well with any buffer size, and even if it did the audio updates are still asynchronous (running in another thread, no way around this that I know of).

Anyway, larger buffer size should do what you said, less chance of stuttery sound and increased latency, only not an integer number of frames. But if you're consistently not running fullspeed then the sound WILL break, increasing the buffer size is only delaying the inevitable. If it spikes up in usage then goes below full usage an increased buffer size can help, and larger buffer means slightly less overall CPU usage because the audio thread is called less frequently for larger workloads.

I'm actually considering trying an auto frameskip algorithm that works around the audio buffers instead of video + timing..
 
Last edited by a moderator:
Back
Top