• Welcome to SCdev.org. Please log in.

Welcome to the new SCdev forums!

Saving games that use >64kb

Started by torne, September 22, 2005, 03:31:10 PM

Previous topic - Next topic

torne

Pokemon, and several other games, have 1024kbit flash saves (128KB). No matter what options I select in the patching util, saving from one of these games never actually saves more than 64kb of data, so the save always ends up corrupted. In the case of Pokemon you can keep playing anyway, ignoring the 'corrupt' message, but this leaves me sceptical about what would happen if I kept playing for long enough to get lots of items/pokemon/etc. I have the 'enable more saver' (sic) option turned on, but all this seems to do is allow you to save 64kb to one of four different banks - if you go through the normal save process like this with pokemon, then dump the save file back to the PC and hexdump it, everything beyond the first 64kb is blank.

Is there some option that I'm missing here, or some other way of patching them that will work? Does the Supercard even *have* more than 64kb of savegame SRAM?

If nobody knows I guess I'll have to go back to doing it the old fashioned way.. writing something to test various bits of the SRAM address space for writability, and disassembling the firmware ;)

Dudu.exe

we have to wait the next update...   we think SC will save directly on SD / CF  not using at all the sram... but we need to wait.

torne

Well, I'll experiment with SRAM to see how much the SC actually has - if it's got more than 64kb physically present and it's just not saving all of it, that can be easily fixed by hacking the firmware/patches/whatever. If it only actually has 64kb that would explain why it doesn't save more than that...

sneef

Quote from: "Dudu.exe"we have to wait the next update...   we think SC will save directly on SD / CF  not using at all the sram... but we need to wait.

i think the "next update" is for saving DS games to SD/CF, not GBA games...

we're talking about SRAM, not EEPROM

torne


[Jez]

Try "Enable more Saver" option, I think that allows for bigger saves

torne

No, it doesn't - I said this in my original post. It creates a 256kb save file, but the supercard uses this as four seperate 64kb save banks - i.e. it lets you have 4 different 64kb saves for the same game, not one larger save.

cory1492

torne, if you find something about bankswitching with the SC let me know (I suck right now at disasm) I could really use the info... but so far as I know there is only 64k memory (someone in the forum had some chip ID specs, not sure if they mentioned that though)

My only though on it is this: does the SC have (poorly done/limited if it does) patching so when you do normal in game saves it writes the sav to the CF/SD .sav file instead of SRAM? Could it be thats what  the bigger .sav file is for (wrather than just giving a place to dump the SRAM to)

torne

Quote from: "cory1492"torne, if you find something about bankswitching with the SC let me know (I suck right now at disasm) I could really use the info... but so far as I know there is only 64k memory (someone in the forum had some chip ID specs, not sure if they mentioned that though)
I suspected this might be the case - if so then Pokemon or other >64kb save games will never be able to save until someone implements direct-to-CF/SD save patching.

QuoteMy only though on it is this: does the SC have (poorly done/limited if it does) patching so when you do normal in game saves it writes the sav to the CF/SD .sav file instead of SRAM? Could it be thats what  the bigger .sav file is for (wrather than just giving a place to dump the SRAM to)
No, it doesn't. I've experimented quite a bit with the patching software (including disassembling it too, mmm, I sure do love reverse engineering horrible win32 apps, suuure..). The options in the supercard PC software actually mean the following:
Enable Save - Create a 64kb .sav file. No patching to the rom is done.
Enable more Saver - Create a 256kb .sav file (by copying the 64kb one four times into the same file). This is used for four different 64kb saves for one game, not for >64kb saves. No patching to the rom is done.
Enable saver Patch - Patch EEPROM/flash saving games to save to SRAM, same as many other flashcarts do. Games that already save to SRAM are not modified by this option. This is done using dadycool's srampatch utility, which is in the Supercard program directory (without giving any credit, naughty naughty). This does not cause any slowdown (in fact, saving to SRAM is *faster* than saving to flash/EEPROM).
Enable Restart - Patch game's interrupt handler to listen for the Supercard's special key combinations. This is the option that causes the slowdown. It's done in quite a quick and dirty fashion - append a chunk of code onto the end of the rom, replace the entry point, then change every point where the interrupt handler address appears to go via the extra code. Note that it is trapping *ALL* interrupts, not just vblank. Absolutely every single interrupt that is enabled goes through the Supercard code. (a more sophisticated method would likely have to use a different patch for each game). This also implies that if a game was a full 256Mbits (32mbyte) the Supercard software would be unable to patch it as there would be nowhere to insert the additional code. No games are that large at this time, though many of the GBA videos are.
Enable Real Time Save - Create the realtime save file. The chunk of code added onto the end of the rom is larger when realtime saving is enabled.
Enable more Real Time Saver - Create a larger realtime save file with room for four different saved states. (this does not save more state information, it simply lets you have four different save states on one game, same as the more save option). No additional patch.
Enable Compress - Compress the rom. The decompression code is probably in the firmware, and activated by checking the file extension. I've not checked, as I haven't had time to fully disassemble the firmware yet.
Add coercive Resart - Use a different method of patching the restart code in - not sure of the details of this one yet. Will have to compare the roms.
Enable add text file - Appends up to 100kb of text to the end of the rom, along with code to view it.
Enbable Cheat - Patches various parts of the rom a la Action Replay etc in order to take control regularly and overwrite various parts of memory according to what cheats are loaded.

All the code that is capable of writing to SD/CF is *appended* to the ROM, and is only ever called when you press the magic key combinations. However, if I can disassemble this code and determine the required voodoo to talk to the card, then it's perfectly possible to write a save patching utility that will patch roms to save directly to the SD/CF without any need for a (slow) interrupt hook. This will eliminate the slowdown caused by "Enable Restart" (but not the slowdown caused by the ram being too slow), and if done correctly will enable saving games with >64kb saves.

The chunk of code in question isn't really that big (as these things go) and I have some extremely excellent tools to rip it open with. What I don't have is a lot of free time, so we'll have to see how it goes.

Hopefully Romman's tool, if and when it's released, will support saving GBA games directly to CF/SD as well as DS games. I'm more interested in GBA games at this point. If I can get GBA games working perfectly, and DS games still don't work well enough, I'll move onto that. ;)

MasterMan

Torne, thanks for your concern with this matter. I'm sure if you get the hang of fixing the way SC patch the roms, it will be a major improvement for all of us.

In a message to romman i sugested the possibility SC would save to CF/SD without a key combo, maybe a little pause in game, like "Please wait, now saving". An event triggered by a change in the SRAM.
I dunno if it would work. I just see how the SNES emulator on Dreamcast (DeamSNES) works. When you save ingame, it detects the event and writes to the memory card, w/o prompting for it.
Of course RTS would still need a key press, but... dunno.

BTW, i hope to see good news from you.
img]http://img510.imageshack.us/img510/3610/siggcncg7.jpg[/img]


[=[__]=] DS Black (JAP) : FlashMe v6 : PassMe 2
[+[__]::] SuperCard CF : 1 GB SanDisk CF + 128MB DaneElec CF

torne

Quote from: "MasterMan"Torne, thanks for your concern with this matter. I'm sure if you get the hang of fixing the way SC patch the roms, it will be a major improvement for all of us.
I've found where the triggers are for cart ram map switching and am in the process of decoding what the different values mean. ;)

QuoteIn a message to romman i sugested the possibility SC would save to CF/SD without a key combo, maybe a little pause in game, like "Please wait, now saving". An event triggered by a change in the SRAM.
I dunno if it would work. I just see how the SNES emulator on Dreamcast (DeamSNES) works. When you save ingame, it detects the event and writes to the memory card, w/o prompting for it.
Of course RTS would still need a key press, but... dunno.
It might be impossible, depending on how the cart's hardware is put together and if the CPLD is reprogrammable. There may be no way for the cart to know when SRAM is written to. Also, even if there is, it's hard to communicate this to the processor in a fashion that enables it to do something about it: likely the ram write notification would have to be via the cart irq line, which would require the interrupt handler of the game to still be patched.

Patching the save routines to save directly to the CF/SD instead of via SRAM shouldn't be hard for him to do since he presumably has the specs for his cart ;)

QuoteBTW, i hope to see good news from you.
I'd have disassembled more by now but dude, I am so high.