Search

[torne]

Have you looked to see what changes the supercard software makes, if you disable all the explicit patching options (for saving etc)? I've not had a chance yet as I only got the card yesterday. i.e. actually diagnosing what causes them to run slower. Possibly it's overriding the wait state settings in the rom to allow for the SC's slow ram? If that's it (I have no idea, but I'll look later if I get time), then you could simply not patch them if you had faster ram.

The old Visoly carts used to only support the slower wait state settings - games that cranked the ws down crashed, often on boot. It might be a similar issue - will see what I can determine.

[Mavromatis]

I think by replacing the RAM chip on the supercard will NOT solved the supercard Speed problem.  Because all GBA ROMs must be patched in a manner for them to work or work around the supercard problem.  These Patched ROMs will NOT work with VisualboyAdvance also.

I owned both supercard and M3 adapter.  All .GBA files must be patched before they can be copied and run from supercard.  or you will get white screen.  WHY? because they are patched to accomodate the supercard.

Interesting, but SC can run clean roms (w/o patch). And nothing differs. Never tried M3 but heard that it uses the restart thing also. How can you add a key combination to a game to return to the menu w/o changing it? I don't think that firmware can do that but not sure.

However, there's nothing technically stopping you from replacing the save code in the game with code that saves direct to SD/CF. GBA games all use one of the various versions of the Nintendo backup library to access their save memory, whether it's SRAM, EEPROM or Flash - and all of these libraries can be recognised and their entry points found in the rom (that's how flash/eeprom -> sram patches work for other flashcarts)

This can be solved with a hardware edit probably. Adding a fake flash and/or eeprom to route the data to cf/sd or even a real one to save in. But this wouldn't be cheap nor easy to do.

So.. with that in mind, how receptive is romman to getting help, does anyone know? I'm intending to have a look at this, but it'd be significantly easier with some details from the developer. If not, then I guess I'll just be back to sticking the firmware into IDA and disassembling it..

Well you must ask him. I hope he's receptive. Because any firmware improvements would be accepted with joy at the moment.

[torne]

How can you add a key combination to a game to retıurn to the menu w/o changing it? I don't think that firmware can do that but not sure.

It can't, but it may be possible to make it less intrusive than patching the vblank interrupt routine. A physical button on the cart that asserts the cart IRQ line might work, as the game won't be taking cart IRQs under normal circumstances and thus intercepting it shouldn't cause any slowdown. It's a much better idea to just avoid having to trap at all by modifying the *right* part of the game, though

In DS mode you could trivially intercept SRAM writes by setting the ARM9's access domains to mark SRAM as read-only, then handling the data abort - but of course DS games don't write to SRAM of their own accord. You can use this technique as a general trap mechanism for DS mode, though - replace the operation you want to patch with an access to an unreadable/unwritable address then use the data abort vector as a trap handler. Much less intrusive than patching the interrupt vector as games in normal operation shouldn't be causing data aborts.

This can be solved with a hardware edit probably. Adding a fake flash and/or eeprom to route the data to cf/sd or even a real one to save in. But this wouldn't be cheap nor easy to do.

You don't need to do that unless you really have a fetish for clean roms - patching a flash/eeprom game to use SRAM is trivial, since there are only a finite number of backup libraries supported by Nintendo, and is already done by most flashcart software. The SC software probably already does this (its SRAM is just not battery backed, so dies shortly after you remove power). Adding battery backup to the SRAM would be a much easier and cheaper hardware hack (though not trivial), and would enable you to replace the quick-power-off technique with doing it at your leisure (you still would have to enter the menu to save the SRAM off to SD/CF, as there isn't room to store the saves for all games in there, and it has no bankswitching hardware).

Well you must ask him. I hope he's receptive. Because any firmware improvements would be accepted with joy at the moment.

The changes I would need to make would be to the patching util (or possibly just replacing the patching util with another program entirely). Changing the firmware doesn't actually win you anything worth having at this point, as once it hands control over to a game that's it, it's simply not running any more.

[Mavromatis]

A physical button on the cart that asserts the cart IRQ line might work, as the game won't be taking cart IRQs under normal circumstances and thus intercepting it shouldn't cause any slowdown.

This wouldn't be better then on/off switch. How m3 handles that problem? Does it have such a switch or just a patch in the game?

[torne]

This wouldn't be better then on/off switch. How m3 handles that problem? Does it have such a switch or just a patch in the game?

A cart IRQ switch would do it without interrupting the power (guarenteeing SRAM preservation), and it wouldn't be so fiddly as powercycling (especially on the DS with its pushbutton powerswitch). But yeah, it leaves a little to be desired.

Unless the M3 has done something really, really clever, which I find unlikely (I've yet to see anything really really clever from any flash kit, GBA or DS).. then they're doing it by patching the game. Even if it takes clean dumps on the card, as a number of people have implied, it could patch them as it loads into SRAM (the number of savegame libraries is such that a neat little algorithm that detects them while it's copying is well within the DS's capabilities - you probably wouldn't even notice it being any slower as the bottleneck is the 16-bit address-strobed cart bus) to achieve the same ends.

Ultimately you'd have to examine the hardware and whatever firmware it might have in quite some detail to work out exactly how it works..

[memyselfandi]

i'm not sure that a firmware upgrade could fix that because Romman would have done it before :?  :idea:

[torne]

A patch util update can fix save support causing slowdown (by applying a smarter patch), and it's not been done because devising a smarter patch is nontrivial. It's not that hard, though

[torne]

OK, I've just done a binary comparison of a few roms before and after running them through the supercard utility (with all patching options turned off, so it won't save..etc but it shouldn't introduce any extra slowdown).

It changes one word of data, wherever it finds it: it changes 0x04000204 to 0x00000000. It just happens that 0x04000204 is the address of the GBA's wait state control register, just as I predicted

This means that the game doesn't change the wait state settings (unless it's been tricksy and has synthesized that address instead of loading it from a literal pool, but code generated by a normal ARM compiler wouldn't do that, only insane asm coders like yours truly go for synthesis of complex constants). This means, in turn, that if the game's original cart was intended to run at any wait state setting faster than 4/2 (the default), it's being throttled down and is likely to run slowly in action-intensive parts. Almost all commercial games use 3/1 waitstates on their carts, and I am told (though have never checked) that some games set it to 2/1 (and have correspondingly faster ROM in the cart).

This is the reason why most (though not all) clean dumps produce a white screen: once they set a faster wait state setting than the cart can handle, reads from the cart are likely to be corrupt, and the game won't get very far. A few games leave the waitstates set to 4/2 and thus should work as clean dumps on the SC.

So, the solution to the general slowdown problem (as opposed to the additional slowdown caused by the savegame support, which can be worked around with sufficient effort) is to replace the SRAM with a faster chip, then take out the part of the patching util that removes the waitstate setting. Games will then go ahead and set the waitstate setting they want, and will not crash if the chip is fast enough

The fact that the patcher does this (without mentioning it) suggests, unfortunately, that romman knows full well that the SRAM is too slow and put in this patch to turn the visible problem (games crash) into a less visible one (games sometimes run too slow).

[Ramin]

Wow... good findings, you guys.

I wonder if we can put the whole problem-to-solution issue into a clear format, get someone to translate it to Chinese, then send it to Romman, if he'll address the issue.

As cool as the M3 used to sound, it really doesn't seem to sport a whole lot more than the SuperCard, especially since one-by-one all those alleged features that the official website says it has are turning out to not be 100% true.

If anybody, it is us, the supporters of the SuperCard, that can help Romman out of this rut.

[torne]

The real problem with the speed is the fact that the RAM is too slow.. and he already knows about that, you can be sure, as he has specifically worked around it in the patching software. Slower ram is cheaper, and people took some time to notice at all..

[Rion]

Is this the kind of SRAM?

http://www.maplin.co.uk/family_free_delivery/SRAM.htm

[torne]

That's SRAM, but the supercard doesn't really have SRAM for its main memory as discussed in this thread: http://www.scdev.org/forum/viewtopic.php?t=261
The Hynix RAM chip in the SC is SDRAM, and as such is attached to the GBA port via a programmable logic controller that deals with the differences between SDRAM and SRAM. Replacing the chip will thus be difficult as even if a faster SDRAM is substituted and the clock changed to match, the controller will probably not 'like' the result..

It might have a real SRAM chip for saving, though - I've not dissected it yet. Replacing this to store larger saves (if it's not big enough already) would probably not work either as the controller probably doesn't expose enough address lines to it..

[keen31]

great info torne, when i first started researching the supercard and the "slowdown" issues, this is exactly the stuff i was looking for.

so, in theory, since SC has inferior chips and cant handle the correct waitstate settings it has to patch them to be acceptable, thus causing slowdown... and thats why SC patched roms (even with no options enabled) still run slow on an M3... and from there you could assume that the M3 has chips (or whatever mix of hardware) that can handle roms correctly, so in a cold facts comparison, the M3 is superior (equipment wise) since it is not limited or bottle-necked or throttled to function correctly.

i still have yet to purchase either, but the more i come to understand the bottom line on SC (hardware limitations specifically) the more im convinced that it will never be able to break through the glass ceiling it created for itself.

anyway, thanks again for the sound technical info. very much appreciated.  

[torne]

Yes, you have it. If the M3 can run the same games as the SC without slowdown, when all other patching (saving etc) is disabled, then it just plain must have faster RAM and thus the SC will almost certainly never catch up. I am investigating possible ways of *reducing* the slowdown, but it will probably never go away. So far, from people's descriptions (I don't have one), this RAM speed issue is the M3's only hardware advantage, and all its other features are purely software and thus could be duplicated on the SC.

[[Jez]]

Anything you could do to reduce the slowdown would be apricated by the GBA masses, If theres anything this retard can do to help let me know