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.
; 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
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.
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.
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.)
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).
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.
Quote from: Wannado on 21/Nov/2015 07:38:53 PM
Have you tested the game in the real SNES recently, to see if the battery is still working?
Yes.
Quote from: MasterOfPuppets on 22/Nov/2015 05:00:54 PM
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.
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 (http://gbdev.gg8.se/wiki/articles/The_Cartridge_Header#0149_-_RAM_Size) 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).
Quote from: Wannado on 29/Nov/2015 10:12:14 PMI'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.
Quote from: Aleron Ives on 30/Nov/2015 09:01:10 PM
... 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.
Quote from: Amitari on 16/Nov/2015 07:32:10 PM
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.
Quote from: Wannado on 01/Dec/2015 11:25:02 PMI'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.
Quote from: Aleron Ives on 02/Dec/2015 07:48:29 PM
... 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.
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.
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.
Quote from: Nori on 06/Dec/2015 05:19:18 PM
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.
In general, there's always some risk. But in this case, I was talking about a firmware modification that I have
not released yet, and about a specific type of GB cartridges (note that the OP (http://forum.retrode.org/index.php/topic,313.msg2075.html#msg2075) refers to SNES and GB games). The whole story started in replies #3 (http://forum.retrode.org/index.php/topic,313.msg2078.html#msg2078) and #7 (http://forum.retrode.org/index.php/topic,313.msg2083.html#msg2083) of this thread.
The currently released firmware versions, including the recent v0.18d-beta3, do not detect the SRAM in MBC2 GB cartridges, and so they do not enable it. That has probably prevented corruption of MBC2 SRAM so far.
Access to SRAM on other GB (Classic) cartridge types seemed to work in my (few) tests.
So if I try the cart and the save loads fine all is alright? Are there signs when the save is corrupt or does this mean it might work fine but it may have altered aspects of the save such as items or other elements? Sorry if this sounds very noobish I'm not an engineer and not familiar with how all this works.
Quote from: Nori on 07/Dec/2015 05:51:53 AM
So if I try the cart and the save loads fine all is alright? Are there signs when the save is corrupt or does this mean it might work fine but it may have altered aspects of the save such as items or other elements? Sorry if this sounds very noobish I'm not an engineer and not familiar with how all this works.
We're not saying the Retrode
will corrupt some saves, but we do say
we can't guarantee you will never lose data (since there is no way on earth to guarantee that from a technical point of view). Look in the manual; you agreed to live with this possibility (however faint it may be) by using the device.
If the save loads fine, still doesn't mean it will still be there next time. Make regular backups.
I see. Thanks for the tip. It's a fantastic device.
Test game sounds like Final Fantasy Adventure (/Seiken Densetsu/Mystic Quest).
I think MBC2 also has a write-lock function?
I know in emulators, saving in Aretha I (Japanese-only RPG) seems to only work in BGB, and only if RAM lock emulation is enabled in the accuracy settings. Otherwise when trying to load a savefile causes terrible game-breaking corruption (I think in some emus, even saving the game causes the corruption to happen instantly).
I recently managed to get SRAM writing to work on the MBC2 chip. Due to confusion about which bit of a port was assigned to which cartridge pin, the Retrode was pulling /RD and /WR low at once when trying to write, causing the write to fail on MBC2.
The corruption remains, but I found out what is causing it: When trying to disable SRAM (so as to protect it from corruption), the value supposed to be written into the respective control register ends up in SRAM itself.
It is possible that this corruption also happens on games with other MBCs, not only MBC2.
I'm confident I'll be able to fix this soon. Then I'll prepare another firmware release.
I fixed the SRAM corruption bug, and I confirmed that it was not limited to MBC2 games. It seems to corrupt only few bytes though, and if you're lucky, your savegame does not use those.
This bug fix is included in v0.19 beta, which will hopefully be published soon.
Quote from: Wannado on 05/May/2016 05:28:04 PM
I fixed the SRAM corruption bug, and I confirmed that it was not limited to MBC2 games. It seems to corrupt only few bytes though, and if you're lucky, your savegame does not use those.
This bug fix is included in v0.19 beta, which will hopefully be published soon.
Great to hear!