Strange Problem Gp2x

[Flavor]

This kinda sucks. I tried the lock thing again, and this time I got a pause. I think it wasn't as long, but there was still pausing. Also, it's worth noting that this test was on another SD card.

I'll try to determine if GP2X is actually mounting it read-only or not.

I even noticed a change in the audio quality after the pause. It's perplexing.

 

[ThorC]

I get it too, the audio change as well, and find it equally mysterious. However it doesn't seem to happen with everything for me.

After solid playing, I have never experienced it in Quake, in Duke3D, in gnuboy or OutcaST

 

[Flavor]

I logged in over my USB Serial Gadget. Indeed mount reports that the card (even when locked) is in read/write state. I was even able to write a new file to the card when it was supposedly locked.

 

[fishybawb]

I've been playing all kinds of things today, and haven't noticed the problem you're describing on anything... Could someone tell me a specific emu/game that it happens on so I can have a look?

 

[Flavor]

I've been playing all kinds of things today, and haven't noticed the problem you're describing on anything... Could someone tell me a specific emu/game that it happens on so I can have a look?

​

I notice it on the unreleased game that I'm currently working on, so that's not an option for you to test.

Though, I have been told that it is dependant on your SD card. Some SD cards are faster and thus don't notice a pause when they're written to. Torpor said it didn't do it with his Panasonic, but it does on his Toshiba.

I have a Kingston 1gb and a Viking 256mb. I've seen pauses with both of them.

 

[nickspoon]

I've been playing all kinds of things today, and haven't noticed the problem you're describing on anything... Could someone tell me a specific emu/game that it happens on so I can have a look?

It might not do that with your SD, if that's what's causing the problem...

EDIT:

I have a Kingston 1gb and a Viking 256mb. I've seen pauses with both of them.

I think that may be the problem, then. Both Viking cards and Kingston cards are made by Toshiba. GPH Linux uses some weird SD drivers to handle Toshiba cards and make them compatible with its firmware (these weren't used in 1.2.0, hence no support for Toshiba cards).

 

[ThorC]

I've been playing all kinds of things today, and haven't noticed the problem you're describing on anything... Could someone tell me a specific emu/game that it happens on so I can have a look?

​

The most easy way to reproduce it for me is with NK's NES emu, and also the first thing I ever noticed the problem with. A minute or so after starting, it'll pause for a second, and when it resumes you'll notice the sound sounds different (althogh I cant quite pinpoint how).

 

[fishybawb]

Well my SD's an old 128MB one, so I doubt it's especially speedy! Hmm... very strange.

Edit: OK, I'll give NKNES a whirl

 

[Flavor]

The most easy way to reproduce it for me is with NK's NES emu, and also the first thing I ever noticed the problem with. A minute or so after starting, it'll pause for a second, and when it resumes you'll notice the sound sounds different (althogh I cant quite pinpoint how).

​

That's almost exactlly what I've noticed with the game I'm working on.

 

[nickspoon]

I edited my post above, I believe it's a problem with Toshiba-manufactured cards (which include many other brands including Viking and Kingston, afaik).

 

[Flavor]

I think that may be the problem, then. Both Viking cards and Kingston cards are made by Toshiba. GPH Linux uses some weird SD drivers to handle Toshiba cards and make them compatible with its firmware (these weren't used in 1.2.0, hence no support for Toshiba cards).

Hmmm, I have v1.2.0, and both the Kingston and Viking cards that I have work.

 

[nickspoon]

Funny, I have a Viking 1GB card (with the sticker peeled off to reveal it was actually a Toshiba), and it didn't work with 1.2.0. They fixed it in 1.2.1.

 

[Flavor]

I somewhat stumbled upon the fact that calls to SDL_Delay() seem to increase this pausing problem.

Many games use SDL_Delay() to lock the game at a specific speed so that it runs nicely on faster processors.

The side-effect is that it gives up control to other processes. On most systems, this is a good thing, but on a console, you would usually want your app to keep control. Once you call SDL_Delay(ms), you are supposedly guaranteed that you will wait AT LEAST that number of MS, but if some other process gets the CPU, you may end up waiting longer than you wanted to.

In my new game (that I just submitted to GP2X-2006), I removed the call to SDL_Delay and it doesn't pause as often, and the pauses are shorter.

I still think it has to do with writing to the SD, but when I was calling SDL_Delay() I think it was almost like an invitation saying, "okay, Linux, do your thing, now" instead of just letting the OS do its thing whenever.

 

[Flavor]

One thing you can try is build a small shell script to renice the task. eg:

nice -20 yourapp.gpe

which will stop other tasks from interrupting yours.

This may be more worth re-visiting now that I have removed SDL_Delay().

SDL_Delay would somewhat circumvent the nice setting because nice would give your app all the CPU, but SDL_Delay() would just give it away again.