[Solved] Issue with dumping Game Boy saves (Retrode 2, v0.19-beta)

[Wren]

First, I'd like to thank the Retrode developers for providing this great tool to the community. I've used it to successfully back up my Genesis and SNES games and saves and relive some fond memories from my earlier years in the process.

More recently, I started dumping my Game Boy games using the Retrode 2 (firmware v0.19-beta) and the GB plugin. I've had no problems with dumping the ROMs themselves (almost all verified with http://datomatic.no-intro.org/), but have had mixed luck with SRAM data. I was able to retrieve saves for the following games without issues:
- Pokemon Red / Blue / Yellow
- Final Fantasy Adventure
- Final Fantasy Legend I / III
- Pokemon Pinball

However, I noticed some problems with the saves for the following games (not sure if it matters, but the first three are regular Game Boy and the last three are Game Boy Color):
- Final Fantasy Legend II
- The Legend of Zelda: Link's Awakening
- Metroid II
- Revelations: The Demon Slayer
- Lufia: The Legend Returns
- Dragon Warrior I & II

Specifically, for the first five games above, no valid saves were detected when using the dumped save files in an emulator (Visual Boy Advance). For the sixth game, Dragon Warrior I & II, some saved games were detected while other save slots were marked as corrupt. I had tested Dragon Warrior I & II in my Game Boy prior to dumping with the Retrode, and had been able to load my old saves fine then. However, after the first dump, testing in the Game Boy resulted in the same message I got when I tested the dumped save in an emulator, with some of the save slots being marked as corrupt.

At that point I went back and re-dumped the above games several times, disconnecting the Retrode in between each dump. For the six games with problems, I was unable to get consistent dumps of the save files. I wrote a Perl script to do some comparisons, and noticed that there does seem to be some consistency in which bytes get corrupted when dumping, while other bytes are preserved. (Analyzing the dumps for Dragon Warrior I & II has provided the most insight on this so far, because it appears that the game will zero out the SRAM data for a corrupted save slot when it first detects it.) I also tested the other games on my Game Boy, but no saves were detected on the catridges after dumping (I verified that saves existed for both The Legend of Zelda and Metroid II prior to the first dump).

I've tried re-flashing the firmware to v0.19-beta and setting sramReadonly to 0, but that does not seem to have had any effect. Has anyone else had similar problems when dumping Game Boy saves? An earlier forum post mentioned an SRAM corruption issue, so I'm wondering if maybe that wasn't fully resolved with the v0.19-beta firmware. I'd be happy to provide SRAM dumps and run additional tests if that would be helpful.

On a related note, if this is being caused by an SRAM corruption bug, I would be interested in getting details on the bug itself. My hope is that this information would allow me to figure out a way to recover my save data from the existing dumps, or at least indicate that such a goal is futile (it probably is, but I figure it can't hurt to ask).

Thanks!

[Wannado]

Sad to hear your saves have been corrupted. Please help me find out why.

- For all games you listed (both affected and unaffected), please open each (dumped) ROM file in a hex editor and tell me the value at offset 147 hex. That byte identifies the MBC used in the game.
- You said that you noticed some consistency in the corruption. Please provide me with details about which offsets have been affected, and how.


Recovery may be possible under certain conditions. The fewer bytes have been overwritten, the better the chances. It would also help if the game stored a checksum in each save slot.


The GB SRAM corruption bug that I found and fixed had only affected a few bytes in my experiments, often unused bytes at the end of a save slot. The changes I made (to fix this and other GB related bugs) could now possibly have caused a new bug with a larger effect, but I'm not sure yet.

I did of course test my changes, but I only have a few GB games with SRAM:
- The Legend of Zelda: Link's Awakening (dead battery, but keeps written data if I just reset the Retrode (which also clears the host's disk cache))
- Super Mario Land 2: 6 Golden Coins
- Mystic Quest (alternate title of Final Fantasy Adventure)
- F-1 Race
- Kid Icarus: Of Myths And Monsters

The first two have MBC1 (value 3 at 147 hex), the last three have MBC2 (value 6). Hence I could not test MBC3 or MBC5.

The games all worked for me, including Link's Awakening, which in your case lost its saves. This puzzles me.

I once accidentally used Link's Awakening with 3.3 volts, which may be the reason for the dead battery (if not those 25 years). Since you mentioned Genesis and SNES, but no GBA or N64 games, I guess you are using those regular GB/GBC games with 5 volts, right?

Dirty pins may cause problems, but it seems unlikely in your case (six affected games, all ROMs read fine).


I'm running out of time for today, but I'll have more time tomorrow. I'll try and do some experiments.

[Wannado]

The following page says that the GB pulls /MREQ (also called /CS in other documents) low "when making a memory access (e. g. with the LD operation), but not when it fetches instructions":
http://fms.komkon.org/GameBoy/Tech/Carts.html

So /CS is usually high when reading ROM, low when reading/writing RAM. But what about writing MBC registers? Does anybody know for sure whether /CS is low on all LD operations, even those not targeting RAM (but MBC registers)?

(Maybe the corruption I tried to fix is a "known" side effect of GB operation, which the games work around by not using the single corrupted byte for game data. We would then need to know which byte each particular game is allowing to be corrupted...)

[Wren]

Thanks for the reply, Wannado, and no worries about the save corruption - it'll give me an excuse to replay those games if I can't recover the saves.

Regarding voltages, yes, I have been dumping at 5 volts.

Details from the ROM dumps are below; I have included bytes 0x0140 through 0x014f (output from xxd) in case the header data contains any other information that might be useful here:

Games with good SRAM dumps
--------------------------
Pokemon Red
- Offset 0x147 stores 0x13
- 0000140: 0000 0000 3031 0313 0503 0133 0020 91e6

Pokemon Blue
- Offset 0x147 stores 0x13
- 0000140: 0000 0000 3031 0313 0503 0133 00d3 9d0a

Pokemon Yellow
- Offset 0x147 stores 0x1b
- 0000140: 4f57 0080 3031 031b 0503 0133 0097 047c

Final Fantasy Adventure
- Offset 0x147 stores 0x06
- 0000140: 5453 5500 0000 0006 0300 01c3 00d0 d9f2

Final Fantasy Legend I
- Offset 0x147 stores 0x06
- 0000140: 0000 0000 0000 0006 0200 01c3 00ff be66

Final Fantasy Legend III
- Offset 0x147 stores 0x03
- 0000140: 0000 0000 0000 0003 0302 01c3 00cc e1a6

Pokemon Pinball
- Offset 0x147 stores 0x1e
- 0000140: 5048 4580 3031 031e 0502 0133 0046 da60


Games with corrupted SRAM
-------------------------
Final Fantasy Legend II
- Offset 0x147 stores 0x03
- 0000140: 0000 0000 0000 0003 0302 01c3 00cd d970

The Legend of Zelda: Link's Awakening
- Offset 0x147 stores 0x03
- 0000140: 0000 0000 0000 0003 0402 0101 026a 3aee

Metroid II
- Offset 0x147 stores 0x03
- 0000140: 0000 0000 0000 0003 0302 0101 0097 581f

Revelations: The Demon Slayer
- Offset 0x147 stores 0x1b
- 0000140: 4c42 4580 4542 031b 0502 0133 0027 ebce

Lufia: The Legend Returns
- Offset 0x147 stores 0x1b
- 0000140: 4c43 45c0 4539 001b 0603 0133 0018 41d2

Dragon Warrior I & II
- Offset 0x147 stores 0x1b
- 0000140: 4544 4580 4234 031b 0602 0133 0064 2349


For the corruption issues, so far I've mostly looked at Dragon Warrior I & II because several save slots were preserved in the dumped save files and because the game appears to zero out a save slot after identifying it as corrupted. In this particular case, the first 100 or so bytes of the dumped SRAM files seem to fluctuate between several different values, though I am fairly certain that these values should all be zero (save slot 1 occupies bytes 0x0000 -- 0x03ff, which should have been reset to zero when I tested the cartridge in a Game Boy after the first dump). Below is a comparison of several SRAM dumps for DW I & II that I did in the following format:

Code Select Expand


[<number of unique values>] <byte address>: <dump1 value> <dump2 value> ...


Code Select Expand


[2] 0x0000: e9 e9 c9 c9 e9
[2] 0x0001: 4b 0a 4b 4b 4b
[2] 0x0002: 88 88 88 99 88
[3] 0x0003: 73 63 73 71 73
[3] 0x0004: fe fa fe 7e fe
[3] 0x0005: de ba de de 9e
[2] 0x0006: ba aa ba ba ba
[2] 0x0007: fd fd fd 7d fd
[4] 0x0008: 10 18 10 51 11
[3] 0x0009: 58 ba 38 58 38
[2] 0x000a: 8c 8c 8c 9d 8c
[2] 0x000d: a5 a5 a5 c5 a5
[2] 0x000e: 96 8e 96 96 96
[3] 0x0011: 55 4f 55 55 5d
[2] 0x0012: 84 84 84 c4 84
[3] 0x0013: ee ae ee c6 ee
[2] 0x0014: 72 72 72 70 72
[2] 0x0016: 8b 8b 8b 09 8b
[3] 0x0018: 30 b0 30 70 30
[3] 0x0019: cb eb cb 4d cb
[2] 0x001a: 5d 4d 5d 5d 5d
[2] 0x001b: a7 a7 a7 27 a7
[2] 0x001c: 15 37 15 15 15
[3] 0x001d: be ae be bf ae
[2] 0x001e: 88 88 88 98 88
[2] 0x0020: b8 b8 b8 bc bc
[3] 0x0021: ef ee ef 6f ef
[4] 0x0022: 71 79 71 55 75
[3] 0x0023: 51 b3 d1 51 d1
[3] 0x0024: 73 72 73 77 73
[3] 0x0025: a1 a3 a1 e1 a1
[3] 0x0026: b6 be b6 34 b6
[2] 0x0027: 3a 3a 3a ba ba
[2] 0x0028: 00 00 00 78 78
[3] 0x0029: f9 fb f9 f1 f9
[3] 0x002a: d2 c2 d2 d0 d2
[3] 0x002b: a0 a8 a0 b0 a0
[2] 0x002c: cf cf cf cd cf
[3] 0x002d: 2c ac 2c 2d 2c
[2] 0x002e: 65 6d 65 65 65
[3] 0x0031: dc cc dc 5c dc
[3] 0x0032: 7a fa 7a 72 7a
[2] 0x0033: bb bb bb b1 bb
[2] 0x0034: e0 e2 e0 e0 e0
[2] 0x0035: 2e 2e 2e 3e 2e
[3] 0x0036: 45 4c 45 55 45
[2] 0x0037: 0f 0f 0f 2f 2f
[3] 0x0039: 6a 6a 6a 63 6b
[2] 0x003a: a0 a0 a0 94 a0
[2] 0x003b: 88 88 88 81 88
[2] 0x003c: f3 f3 f3 73 f3
[3] 0x003d: 40 42 40 50 40
[2] 0x003e: 03 03 03 53 53
[2] 0x003f: 00 00 00 07 07
[2] 0x0041: 02 02 02 06 06
[2] 0x0042: a2 a2 a2 e2 a2
[2] 0x0043: 3f 3f 3f 37 3f
[3] 0x0044: d0 90 d0 d1 d0
[2] 0x0045: 5d dd 5d 5d 5d
[2] 0x0047: 00 00 00 05 05
[2] 0x0049: 68 68 68 78 78
[3] 0x004a: 73 f3 73 71 73
[2] 0x004b: ea ea ea ca ea
[2] 0x004c: ca ca ca c8 ca
[2] 0x004d: b0 b0 b0 b4 b0
[2] 0x004e: 02 02 02 1b 1b
[2] 0x0051: d8 d8 d8 dc dc
[2] 0x0054: d2 d2 d2 d0 d2
[2] 0x0055: 3a 3a 3a 3b 3a
[2] 0x0056: 04 04 04 3c 3c
[2] 0x0059: 00 00 00 c0 c0
[2] 0x005a: ce ce ce df df
[2] 0x005b: 1a 1a 1a 12 12
[2] 0x005d: 02 02 02 23 23
[2] 0x005e: 00 00 00 01 01
[2] 0x0062: 2c 2c 2c 6c 6c
[2] 0x0063: f2 f2 f2 f6 f2
[2] 0x0065: 1c 1c 1c dd dd
[2] 0x0066: 00 00 00 05 05
[2] 0x006a: 80 80 80 b0 b0
[2] 0x006b: 1a 1a 1a 7b 7b
[2] 0x006c: 20 20 20 61 61
[2] 0x006d: 00 00 00 20 20
[2] 0x0072: 00 00 00 74 74
[2] 0x0074: 10 10 10 71 71
[2] 0x0075: 00 00 00 09 09
[2] 0x007b: 00 00 00 12 12
[2] 0x0082: 00 00 00 40 40
[2] 0x0083: 00 00 00 10 10
[2] 0x0084: 00 00 00 04 04
[2] 0x1bfa: 00 00 00 80 80
[2] 0x1bfb: 00 00 00 ae ae
[2] 0x1bfc: 00 00 00 15 15
[2] 0x1bfd: 00 00 00 88 88


I'm planning on looking at the other games a bit more closely and doing similar comparisons for them as well; I'll try to get that organized and posted in the next day or so. If another format would be more helpful for analysis, just let me know and I'll modify my Perl script appropriately.

[Wren]

I spent some time looking at the Metroid II saves by doing a series of save dumps with some intermittent testing of the game in a Game Boy. The Retrode was completely disconnected in between each dump. Dumps 3 through 6 were created in sequence, and each dump differs from the others in only a few bytes (no valid saves were identified in any of the dumps). Dumps 7, 8, and 9 were created the next day, and all are identical to dump 6 (a rare occurrence in my testing so far). The differing bytes are reported below in the same format used in the preceding post:

Code Select Expand


[2] 0x0038: 37 37 35 35 35 35 35
[2] 0x0cc7: 84 84 04 04 04 04 04
[2] 0x1fc7: bd 3d 3d bd bd bd bd


After this, I played the game in a Game Boy and created a save in slot 1. Then I created dumps 10 through 16, which differ in only a handful of bytes reported below:

Code Select Expand


[2] 0x001b: 5e 56 56 56 56 56 56
[2] 0x002a: 7b 73 73 73 73 73 73
[2] 0x0038: 37 35 35 35 35 35 35
[2] 0x044a: 13 12 12 12 12 12 12
[2] 0x0c0f: d4 d4 d4 d4 54 d4 d4
[2] 0x0c27: e3 f3 f3 f3 f3 e3 e3
[2] 0x0c47: 7d 7d 7d 5d 5d 5d 5d
[2] 0x1daf: 9c 9c 9c 9c 9c 9c 1c
[2] 0x1fc7: bd 3d bd bd bd bd bd


No saved games were found when testing dump 10 in an emulator (I didn't test the other dumps, though). Additionally, dump 10 differs from dump 9 on 74 bytes (details are provided in the attached file).

After this I retested the game in a Game Boy, created another save in slot 1 (no save was found there), and created dumps 17 through 23. Differences between these dumps are reported below:

Code Select Expand


[2] 0x001b: 5e 5e 5e 5e 5e 56 56
[2] 0x0038: 35 37 37 37 35 37 35
[2] 0x0c47: 5d 5d 5d 5d 5d 5d 7d
[2] 0x0d5f: 5d 5d 5d 5d 5d 55 55
[2] 0x1daf: 9c 9c 9c 9c 9c 1c 9c
[2] 0x1fc7: bd bd bd bd 3d bd bd


Dump 17 differs from dump 16 on 82 bytes; details between all of the dumps are presented in an attached file.

I verified that the battery in the cartridge is intact by creating a save using the Game Boy, powering off and disconnecting the cartridge for 15 minutes, and then testing in the Game Boy again.

I also did similar tests for The Legend of Zelda: Link's Awakening and Final Fantasy Legend II. For Zelda, subsequent dumps differed on approximately 380 or so bytes; across 15 dumps, the number of inconsistent bytes is 1116. For FFLII, subsequent dumps differed on approximately 350 bytes, with a total of 1073 inconsistent bytes across 16 dumps.

I did not attempt to create any new saves in the Game Boy in between dumps for either game, though I did load the games several times to verify that no saves were detected. Some testing in an emulator seems to indicate that any existing data in a slot will only be overwritten upon writing new save data to that slot (in contrast to Dragon Warrior I & II, which seems to zero out an invalid save upon detection). As such, I am hesitant to create new saves for either game.

Detailed comparisons of these dumps are attached.

[Wannado]

Wow, Wren, thanks for doing all those tests and analyses!

Believe it or not, the data you posted really gave me a new idea. Such a mix of stability and randomness, along with the corruption of the stored data, might occur if the Retrode's attempt to read the RAM is seen by the cartridge as an attempt to write it.

In such a case, neither the cartridge RAM nor the Retrode would be driving the data bus. Instead, both would be reading a value determined by the remaining voltage on each data line, external interference affecting that, and the individual properties of each digital input.

Such a situation could be caused by a software bug or by a defect on the plug-in.

Please open (unscrew) your GB plug-in's shell and look at the row of solder joints of the connector pins (on the PCB side where the connector itself is placed). Do they look really tidy and shiny, or is there an excessive amount of solder, a short circuit, etc.?
For example, there might be crosstalk from pin 2 (clock) to pin 3 (/WR).

[Wren]

Glad to hear that the data proved useful!

I'm travelling at the moment and don't have access to my GB plug-in, but I will be able to inspect it sometime next week. I did take the plug-in apart prior to use in order to file down the plastic case where the GB cartridge plugs in (it was a very tight fit initially), and didn't notice anything unusual on the board itself. However, I wasn't looking particularly closely, so I may have missed something.

With regards to the possibility of this being a hardware defect, it seems like that would cause problems with save data across all cartridges instead of just some of them, unless there are physical differences between the cartridges themselves as well. Is there anything I should look for on the cartridges to test this?

[Wannado]

- I'll take another, closer look at the data this weekend. Maybe it will prove even more useful.

- I remember having to file down the plastic case as well.

- Regarding the (still possible) hardware defect, the explanation I gave in my previous post wasn't entirely correct. I forgot that, when reading from the GB cartridge, the Retrode enables pull-ups on its data lines, which should stabilize the data lines even if not driven by the cartridge.

The data you posted hence indicates that the lines are being driven.

But a defect might, for example, cause the /WR input voltage to drop to something around 2.5 volts - neither high nor low logic level - for long enough to confuse the cartridge's logic into doing strange things, such as modifying its RAM randomly.

Different cartridges may respond differently to such violations of their specification. There are always subtle physical differences, but probably nothing visible in this case.

[Wren]

I took a look at my Game Boy plugin adapter and didn't notice any excess solder on the connector pins. However, the far right pin (when viewed from the top) appears to be set back slightly compared to the others; this pin is also not aligned with the others where the cartridge plugs in. I've attached a few pictures to help illustrate this. I'm not sure if this is normal or a manufacturing defect.

[Nori]

Not sure this helps but I backed up Metroid II (US ver.) recently and it worked. I didn't try writing it back though.

[Wannado]

...; this pin is also not aligned with the others where the cartridge plugs in. ...

I'm quite sure that the misalignment visible on gb-pins-small.jpg is a manufacturing defect. Inside the cartridge slot of my GB plug-in adapter as well as that of my Game Boy, all pins do align. I guess you should contact the merchant about a replacement for your adapter.

The bent pin cannot properly connect to the cartridge. Since it's the ground pin, this means that the cartridge's power supply grid is unpowered. Because of the voltages applied to the various I/O pins (control signals, address bus, data bus), current still flows through the cartridge, but in unintended ways.

I'm amazed that so much still worked that way - bankswitching, reading the ROMs and even a number of RAMs. But it's not surprising that several RAMs got messed up.

However, the far right pin (when viewed from the top) appears to be set back slightly compared to the others; ...

The detail visible on the two larger images is probably OK. It looks the same on my adapter. The intention may be to make sure that the ground pin connects first when inserting a cartridge. (Nevertheless, I advise against hot-plugging cartridges.)



@Nori: Thanks for the information - it does help!

[Wren]

Thanks for the replies Wannado and Nori! After Wannado's confirmation that the pin mis-alignment is a manufacturing defect, I took a closer look at it. The pins appear to be shaped like the following (rendered in crude ASCII art):

Code Select Expand


(Top of plugin)

  |
/
\

(Back --> Front)


When a cartridge is inserted, it connects with the pins on the left side in the above diagram, and puts pressure on the pins themselves. On my plugin, the far right pin doesn't sit flush with the others, resulting in a bad connection as Wannado noted.

Rather than attempting to get a replacement from the seller (Dragonbox), I decided to see if I could fix the issue myself. (My reasons for this being: (1) not wanting to have to ship the item back to Dragonbox, (2) lack of optimism that a replacement would be available, given that the plugin is currently out of stock, and (3) a mix of impatience and curiosity.) On my plugin, I was able to move the far right pin back into alignment with the others by pressing it lightly with a toothpick (not the most scientific of instruments, but effective). The pin moved quite freely back into position, but when I inserted a cartridge, the pressure from the cartridge caused the pin to move back out of alignment. To resolve this, I created a small shim from the toothpick and stuck it behind the pin to hold it in place when a cartridge is inserted (picture attached).

I probably voided whatever warranty I may have had on the plugin by doing this, but it seems to have corrected the problem. I re-dumped all of the games that weren't working, and was able to get consistent dumps out of them. The save files, while still corrupted from the earlier dumps, were at least all the same after repeated dumps. In addition, I was able to get a ROM dump from Lufia: The Legend Returns that matched the No-Intro database (the earlier dump had an incorrect MD5 sum but worked in an emulator; the only difference between the two ROMs was the first byte: 0xe3 vs. 0xc3 (correct)). All other ROM dumps were correct even with the defect.

I also tested the plugin on the cartridges that had been working before and got the same save data from them. While the save data seems to be intact, it's hard to know if any of it was subtly corrupted even though the dumps were all consistent. It does seem odd that there was such variable performance across the cartridges from the same pin defect.

Lastly, I dumped the remaining Game Boy / Game Boy Color games that I had and everything seems to have gone smoothly there. Save data is consistent and intact on the cartridges and works in an emulator, and ROMs match the No-Intro database. So this issue can be marked as resolved.

I am still interested in potentially recovering the corrupted saves, but am less optimistic about that given the source of the problem (had it been from the firmware, there might have been more predictability in the corruption). Any thoughts or insights on how the hardware defect might have corrupted the save data would be greatly appreciated. If I make any progress on this, I'll post it here, but it may be a while before that happens as I won't have a lot of spare time over the next several months.

Thanks again Wannado and Nori for your comments and assistance!

[Wannado]

While it's good to hear that you got it working, I'm still a bit concerned about the defective pin. If it was moving so "quite freely", it might break off eventually, even if it's now supported by the toothpick shim.

I am not a lawyer, and I do not speak for DragonBox (and neither for Matthias' company), but in my opinion, your particular actions in this case should not suffice to void warranty. Also, the seller/manufacturer could still have some units reserved as warranty replacements. So I think you should try and contact DragonBox about the matter.

About marking the issue as resolved: Please try "Modify" on the OP and edit its title accordingly.

About the corruption: I'm not surprised by the "variable performance". I guess that the effect depended on the individiual physical properties of each RAM cell etc., and maybe even environmental conditions (heat, radio interference, ...). While the fluctuations occurred only in limited areas, it is possible that the whole RAM was corrupted - only most of it in a reproducible, non-fluctuating way.

Maybe you could gain some insight by creating fresh saves with an emulator and comparing them to the dumps. Of course, due to the different levels of game progress, the saves will be hard to compare...

[Wren]

Thanks, Wannado - that's a good point about the pin's fragility being a longer-term issue. I will see about the replacement options that may be available. I've also modified the title to mark the issue as solved.

That's also a good suggestion for attempting recovery. I've made some progress along those lines by mapping out where each individual save slot resides in the Dragon Warrior I & II save file. Figuring out what information is stored inside each save slot is the next step...