Save data corruption on flashcarts?

[Vectrex2809]

Currently, I'm about to finish one of my NES projects and it seems like save game data gets sometimes corrupted when using it on a flashcart according to my gametesters (See pictures on how it looks like and how it's supposed to look like). The save game data that's causing problems is the player name and the arrow positions which are supposed to be kept if the game is turned off. To quote one of my gametesters - "I am seeing another possible issue though. This has happened twice to me now. Not sure if it is the powerpak or not, but I will run the game for hours upon hours at a time and have no problems. I will turn off the game for a day or so, and then when I turn it back on the screen where you make your name, choose the music, and that good stuff trips out. The letter options for the name are shapes, symbols, and what looks like heiroglyphics. The arrows where you choose the music, see high score and stuff, are above the options, and can go all the way to the left and right side of the screen.
you can continue off that screen, but the name you chose are the same shapes and symbols.

I can remove the file from my powerpak and put the one you gave me back on, and it works fine again until you turn it off for awhile, and then it does it again".
Also, when I play my game on NEStopia for mac, the baterry backed WRAM works flawlessly, however, it doesn't on FCEUX for Windows (Using Parallels Desktop), at least when you close the emulator. The game data just resets...

How it's supposed to look like





How it looks like on a PowerPak


Here's some of my code. It's from an outdated version of my game but it is essentially the same in later versions (Don't have my src with me, sorry)

Code: Select all

  LDA wramcheck
  BNE NoReset
  LDX #$00

Reset_VRAM:		;Resets VRAM if needed

  LDA #$00			;Puts zeros on all VRAM vatiables in the $6000 range
  STA $6000,x
  INX
  CPX #$00
  BNE Reset_VRAM

  LDA #$7F
  STA playername
  STA playername+1
  STA playername+2
  STA playername+3
  STA playername+4
  STA playername+5
  STA playername+6
  STA playername+7

  LDA #$8F
  STA music
  LDA #$D5
  STA scores
  LDA #$11
  STA ok

  INC wramcheck

NoReset:

This is the WRAM reset routine. the wramcheck variable is only supposed to go back to zero when you do a specific task.

Don't know if you need more code. I'm sorry but I don't have my SRC with me since I'm on a vacation

[tokumaru]

Only one byte working as a flag to indicate the validity of WRAM? You shoul implement a chacksum or something stronger.

Also, are you only using $6000-$60FF?

[koitsu]

Yeah, a proper CRC check should be used. What I've seen done in commercial games (SNES/SFC titles, however) is that they use a portion of battery-backed SRAM for the actual data, but write it to multiple locations along with a CRC stored with the data. E.g. $6000-60FD would be your data, with the CRC of all data in $60FE-60FF, then $6100-61FD would be a copy of the same data in $6000-60FD and CRC in $61FE-61FF, etc...

This allowed some redundancy in case some of the areas of SRAM had issues, e.g. if CRC for $6000-60FD didn't match, try the next "section", yadda yadda. How much redundancy you want is up to you, but I imagine 3 copies would be enough.

[Sik]

If I recall correctly that was mentioned in the SNES manual.

[Vectrex2809]

There's not too much save game data in the game indeed. To tell you the truth, I was thinking about using WRAM for the name entry screen and the high scores only. I'll try to implement a checksum, but I was also thinking about dropping the save feature since there's not too much data to be saved...

[Vectrex2809]

Also, just wondering. Is there some relation with such data corruption and the infamous "Hold reset while turning off unit" message with the Legend of Zelda and other battery-backed games?

[thefox]

Some older PowerPak mappers may have problems with WRAM corruption, although I'm not sure if that applies here.

[Sik]

Depends entirely on the mapper I believe. Some mappers pay attention to whether the CPU is writing or not (those are safe) but some (most?) just check if the CPU accesses a given address, regardless of whether it's read or write (those are not safe).

[thefox]

Depends entirely on the mapper I believe. Some mappers pay attention to whether the CPU is writing or not (those are safe) but some (most?) just check if the CPU accesses a given address, regardless of whether it's read or write (those are not safe).

The bug I was referring to was PowerPak-specific, specifically this: viewtopic.php?p=89777#p89777

[Sik]

I was talking in general, the reason many NES games tell you to hold down the reset button while turning off is because they have risk of the mapper allowing writes to save RAM during the unstable period while it shuts off, potentially corrupting the data in it.

[koitsu]

"Hold reset on NES" subject has already been discussed before (2nd thread relates to SNES but see tokumaru's post for relevancy; best guess is same thing as what's stated in previous thread):

viewtopic.php?f=9&t=10949
viewtopic.php?f=5&t=11962

Stay focused! :-)

[thefox]

I was talking in general, the reason many NES games tell you to hold down the reset button while turning off is because they have risk of the mapper allowing writes to save RAM during the unstable period while it shuts off, potentially corrupting the data in it.

This doesn't apply to PowerPak though, because PowerPak has no battery backing for the SRAM (it's saved to the CF card while the system power is on), so the save data never has a chance of getting corrupted due to powering the system off.

[Pokun]

That's good to know. On the contrary the Everdrive uses battery backed SRAM which contains the save data until another game is loaded in which case it's copied to the SD card (If you play the same game again the next time you turn on it's never copied though). So I guess holding reset is needed on the Everdrive.

What mappers doesn't require holding reset? I remember reading in a Swedish Nintendo magazine that Nintendo worked on a way to protect the save data, but I never heard of a game that used that.

[tepples]

The "Why Game Paks Never Forget" article in Nintendo Power states that MMC5 contains improved protection circuitry that doesn't require holding Reset.

And perhaps MMC6, which has independent write protection for both banks and whose SRAM size is too small to use as work RAM, might be less sensitive to bus noise during power loss.

[Pokun]

I see. Figures it was MMC5.