Hacking Game slow-downs, reason?

[lsp_kill]

Hey,
I experience (of course^^) some slow-downs in different games on my original (yes it is) R4 (with YSMenu) and I often heard it is because of the SD-cards reading-speed.
Average SD-cards like mine (a 2GB Kingston, formatted with Panasonic SDFormatter) got a reading-speed of about 10mb/s, but there are cards on the market up to 15mb/s (for SDHC I found even 30mb/s, but the R4 can't read them).

So I just wanted to know if buying (and using) a new SD-card with a reading-speed of about 15mb/s would reduce the slow-downs or if the R4 wouldn't read faster even if I buy a faster one?
If it's the second I would have to buy a flash-card with internal flash-memory, but that would be much more expensive than a faster SD-card.

I would be very thankful if someone could gimme a helpful answer.

And please, don't flame the R4 here like in much other threads, thank you.^^

Yours sincerely,
lsp_kill

 

[BoxShot]

Well yes most slow downs have to do with the micro sd card your using with your R4. Other cases could be the firmware runs the games slow. (actually I think that's rare?) Then again I might be wrong since this is as far as I know.

 

[FAST6191]

Real reason: see slowest link in the chain "theory".

At the most basic level the job of the R4 (or any other flash cart) is to translate the commands sent by the DS into read requests for the memory card. This translation can be slow (and can be alleviated somewhat by things like DMA routines or stuff like the EZ5's "hybrid mode") and the reading can be slow.

As most people are not up for hacking the R4 (if it is even possible, it might just be cheap electronics: see GBA slot 2 supercards on GBA games) the easiest way is to buy a faster memory card or hack the game (music is usually a good thing to target seeing as it is somewhat inconsequential and being largely uncompressed and it places some serious demands on reading).
It also did not help that most of the R4's time was the introduction/cheaper 2 gig era and people persisted in buying cheap and nasty memory.

 

[lsp_kill]

Thanks for your answers.

the job of the R4 (or any other flash cart) is to translate the commands sent by the DS into read requests for the memory card

And that's nearly my main question.

Isn't the R4 able to translate the commands fast enough (R4's fault) or isn't the SD-card able to read fast enough (SD-card's fault)?
What's the reason for the slow-downs?

 

[FAST6191]

In short is it and it is not
yes the r4 could stand to be faster* however it can also play otherwise unaltered roms at a perfectly acceptable speed if given a decent memory card*2.

Alas the SD spec makes no real mention of speed levels (this unlike SDHC which even then can be debated: latency vs "steady read" rate) and neither do cart makers. It mirrors the situation in writable DVDs/CDs very nicely: sure they all burn but that is not the only factor.

*other carts, via various methods/design choices be they in software or hardware, can use SD cards the R4 could not or or perhaps more accurately play games without the speed issues.

*2 as is often referenced DS cards are an order of magnitude cheaper than GBA era devices (leaving aside issues of size and underlying technology GBA carts could be well over $100 USD) and as a consequence many now have them where they did not before. This combined with the dropping prices and in some respects standards of SD memory this means many cards are less than optimal for the fairly high demands of the R4.

In short short this means the time penalty for the r4 and the time penalty for the slower SD cards contributes fairly equally and the easiest way to alleviate some of the issues is to get a faster SD card.

 

[lsp_kill]

Very big thanks for this detailed answer, FAST6191. No questions left.

Going to order the fastest affordable non-sdhc SD-card which I can find now (couldn't find a faster one than 15mb/s yet).

Btw: Are there any known incompatibilitys with any brands with the R4?

 

[Lacius]

Try reformatting the SD card and messing with the different allocation unit sizes.