Save files dumped with Retrode 2 doesn't work

[Amitari]

When I dump savefiles from a SNES or GB-cartridge, the savefile doesn't contain any actual data, the game starts as if the savefile didn't exist. I've tried to make sure that the emulator loads it, but it seems like it's empty. When I try to dump the save from a GBA-cartridge, the Retrode doesn't even load the savefile. Here's my RETRODE.CFG.

Code Select Expand


; Retrode .18d - Config
; Remove any line to revert setting to factory default

[HIDMode] 1 ; 0: Off; 1: 4Joy+Mouse; 2: 2Joy; 3: KB; 4: iCade
[blinkControllers] 1


[nesMode] 0          ; 1: NES gamepads; 0: SNES

[filenameChksum] 1   ; checksum in filename? 0,1
[detectionDelay] 5   ; how long to wait after cart insertion/removal
[sramReadonly] 1     ; write protect SRAM?
[segaSram16bit] 1    ; use 16bit words for SRAM?
[sramExt] srm
[snesRomExt] sfc
[segaRomExt] bin
; Override autodetect:
[forceSystem] auto
[forceSize] 0
[forceMapper] 0
; Optional plug-ins:
[n64RomExt] n64
[gbRomExt] gb
[gbaRomExt] gba
[smsRomExt] sms
[ggRomExt] gg


[Matthias_H]

Have you looked at the srm-files using some other tool like a hex editor (like HxD)? If there really is no data in there, then we'd have to look for the problem on the Retrode's side; otherwise, it's more likely to be an emulator configuration issue.

[Amitari]

After having experimented a bit more with the SNES-cartridge (Super Mario World), it appears that the save file output is random every time. The first time, it had one save file created, but no levels were cleared. On another try, 6 levels were cleared. I know this isn't what the savefile actually is like. Also, when I read a Gameboy or Gameboy Advance cartridge, no savefile appears at all.

[Wannado]

Please check if all the contacts of the cartridge, Retrode and plug-in are clean and free of dust.

Super Mario World has always worked for me, the save file reading fine. Have you tested the game in the real SNES recently, to see if the battery is still working?

I have a couple of GB Classic games though, where the save file also doesn't show up. I'll try and debug that sometime soon. (Note that I have one GB game with a dead battery. Ironically, the save file does show up for that game.)

[MasterOfPuppets]

Might the Retrode be set to 3.3v? Also, I don't' think the Retrode supports GBA saves yet (please correct me if I'm wrong).

[Wannado]

You are right, MasterOfPuppets. The Retrode does not support GBA saves yet. Only GB Classic (and maybe GB Color, I'm not sure) saves are supported so far.

[Amitari]

Have you tested the game in the real SNES recently, to see if the battery is still working?

Yes.

Might the Retrode be set to 3.3v? Also, I don't' think the Retrode supports GBA saves yet (please correct me if I'm wrong).

No, I made sure to have it set correctly. The cartridges I tried on were GBC, not GBA.

[Wannado]

I made some progress today, regarding the missing save files of my GB Classic games. Those games all use the MBC2 chip, which has a very small built-in RAM. This is a special case the Retrode firmware does not handle yet. GB Color and GB Classic seem to share most of their technology, so this might also apply to your GBC games.

Detecting this case is simple, but in my tests, I saw a strange effect which I want to investigate further before releasing the change. So far, I tested two cartridges. For each, I copied the save file multiple times, resetting or unplugging the Retrode in between. And for each, all copies were equal except the first. Only one or two bytes were different. In one case, this was visible in game, an item was missing in the first copy. I'm not entirely sure which copy is correct.

Also, writing to the save file had no effect on MBC2 RAM (tried on one cartridge, several times; [sramReadonly] 0, of course).

On a side note, we are currently preparing a new beta release, v0.18d-beta3. It may or may not receive this change (see the respective readme.txt for the list of changes).

[Aleron Ives]

I'm not entirely sure which copy is correct.

Well, at least that's easy to verify. Load the game on real hardware and see whether the item is present or not to verify which save is the correct copy.

[Wannado]

... Load the game on real hardware and see whether the item is present ...

I should and will do this, but it will not necessarily tell me which copy is correct.

There are two possible outcomes:
A: The item is present, like in the second and subsequent copies. Then either those copies are correct (and the first copy just had a read error), or MBC2 RAM was accidentally modified when the Retrode made the first copy. That latter case is why I want to investigate this further.
B: The item is not present, like in the first copy. Then I'd be very surprised, because it would mean that all the subsequent, identical copies had identical read errors. In that case, all copies, even the first, might be wrong.

I'm expecting A, also because for the other cartridge, it was again the first copy that differed from the others. And finally I'm almost sure that I tried to keep that item up to that point, and that I succeeded.

But B is still possible, and I had not considered this before, so thank you for making me think again.

I'll also play that other game a little to create a new save where I know all the details, and see what happens when copying it.

[Wannado]

After having experimented a bit more with the SNES-cartridge (Super Mario World), it appears that the save file output is random every time.

Since SMW saves do not contain any personal data AFAIK, could you post a few of the "randomized" save files? I'd like to compare them to my proper save file and look for regularities that might give us a clue where the problem lies.

[Aleron Ives]

I'll also play that other game a little to create a new save where I know all the details, and see what happens when copying it.

If it's possible for the Retrode to erroneously alter the SRAM while dumping it, then it seems to me that you'll need to verify every save on real hardware before you let the Retrode touch it in order to get a baseline of what the correct save should look like for that game. The alternative would be to dump the save with a known good dumper and then compare its output to that of the Retrode.

[Wannado]

... then it seems to me that you'll need to verify every save on real hardware before you let the Retrode touch it in order to get a baseline ...

Of course, it would have been wise to take another look at the save before dumping it. But I thought I'd recognize everything, having played the game only a few weeks before. Too bad I can't remember if I had kept that item.

After playing the game again, however, I do know that the save is corrupted. Said item is present - permanently. It should be single-use, but I can use it over and over again.

It's very likely that SRAM was altered in the other cartridge as well. However, the difference is in an unused area of 8x4 bits that was likely filled with ones. Now the last four bits are zero. The game itself does not write there, so even restarting the game and overwriting the save did not change this. (For the new save, I have written down all the details before dumping. Also, I've stored the same save in both slots the game provides. In the dump, all details are correct, only those four bits are different in the first save slot.)

I think I'll try and fix writing first (no idea yet, still doing research). Once I can fill SRAM with arbitrary data, verification of the dump becomes very easy.

[Nori]

Are you saying the Retrode can corrupt some saves? O_O
I've had zero problems with snes so far and I've used it on almost 20 games with saves.

[Aleron Ives]

Different games have different SRAM configurations, and if your game uses an exotic SRAM that the Retrode firmware doesn't support yet, then yes, the Retrode might dump the save incorrectly or corrupt the SRAM on the cart.