Simple method for more reliable battery backup saves

Simple method for more reliable battery backup saves
by Bregalad on 2011-05-08 (#77833)

It's a known fact that battery backup saves are prone to accidental corruption or erase of the chip.

I think there is 3 ways the SRAM could be somehow affected negatively :

1) The power switching circuit is faulty when switching from battery to power supply or battery from power supply
2) The chip is enabled and accidentally written to while the power is turned off, as the processor might go crazy during this time.
3) The battery is dead / delivers insufficient voltage to retain data.

There is no workarround for 3, but 1) can be easily fixed with a large-sized capactity on the SRAM line, making it go to slow transitions from normal voltage and battery voltage. Old boards such as NES-SNROM-03 does lack this capacity, resulting in frequent saves loss, but NES-SNROM-05 added it and I think it's much more reliable.

Then there is problem 2). Nintendo didn't bother to fix is, and ask the user to press reset when turning the power off as a workarround for that (since the CPU will be resetted, it won't go crazy and write to SRAM when being shutting down).
However it's not easy to ALWAYS press reset when turning the power off, especially if you use a fronloader with a bad connector and that require you to turn the console on and off a few times before you get the game working.

I think Nintendo are very lazy because this could have easily been fixed with a simple analog circuit (that is the point of my post) :
Use a zenner diode for a stable voltage reference (for example 3.3 V), this voltage will be constant for small variations of VCC.

Then use a resistor divider for another voltage reference slightly higher than the other (for example 3.5 V), but this time this reference will be directly proportional to VCC.

Finally use a voltage comparator, and if the second reference is lower than the first, this means the voltage is dropping and that the SRAM must be disabled (this also works when enabling the power by the way). Since 8k SRAM chips have two enables, it's easy to tie one enable to the comparator and the other to actual logic.

So with a couple of common electric parts would easily solve this problem and greatly improve saving reliability. But no, Nindendo didn't do that. What cheap ass they are.

I think modern MMCs such as MMC5 and MMC6 might have a similar circuit internally, but the MMC1 and 3 definintely dont.

by MottZilla on 2011-05-08 (#77883)

I guess I was always lucky because the only time a cartridge ever lost my save games was when I was doing the crooked cartridge glitch on Zelda 64. Never on any of my NES or SNES games did I ever hold reset when powering off. Yet I never lost any saves.

by Dwedit on 2011-05-08 (#77900)

I can confirm that repeatedly inserting and removing a GB cartridge in a GBA after powering on will erase saves.

by MottZilla on 2011-05-08 (#77913)

You're not supposed to remove the cartridge with the system running though. It's no surprise if you remove the cartridge randomly it'll cause problems.

by Bregalad on 2011-05-09 (#77928)

Yes I was talking about turning the system on/off wile the game is inserted (you are supposed to do that and only that). It happened me only one time for a SNES game and a couple of time for Gameboy and GBA games, but it happens all the time on the toploader NES (especially with old SNROM-03 boards).

I think a big difference is that NES games are acessing SRAM basically all the time because the system RAM is so small, and games use SRAM for a lot of other things than saving. If you turn the system off while the CPU is attempting to write anything to SRAM (even if it's something unrelated to game saves) chances are that there will be problems affecting the actual saves, and corrupting them.
The circuit I mentioned would probably fix this.

by tepples on 2011-05-09 (#77930)

MottZilla wrote:
You're not supposed to remove the cartridge with the system running though.

Rare forgot this sometime in the Nintendo 64 era.

As for save corruption on power loss, how many writes are actually made while the CPU is losing power?

by qbradq on 2011-05-09 (#77934)

The only time I've ever lost saves (on my Yobo anyway) was on Crystalis, but it only happened when my two-year-old yanked the power wart out of the wall. It only happened ten or twelve times

I just saved in both save slots every time. I never had both deleted at once.

Back in the day I never lost a save in Zelda 1 or 2 on my toaster and top loader. I never unplugged the power during play, but the power did go out several times while I was playing. I always used surge protectors though.

Personally my approach is to reduce the save file to be very small (say 32 or 64 bytes) with a built-in CRC. Then I make several copies of the save file when the user saves, thereby giving me a little bit of protection. Not that I've released anything that uses this

by Bregalad on 2011-05-09 (#77936)

OBJECTION !!!!
Quote:

I just saved in both save slots every time. I never had both deleted at once.

So you DID have one of them destroyed, just not both at a time.

Same happened to me with FF3, I always used all 3 save slots, and it really wasn't rare than one of all 3 was destroyed (especially the first). I never got more than one at once, but this means it's frequent than one of them is corrupted, which is not acceptable.

The user is supposed to use multiple save slots for multiple saves, not for security backups of his only save.

Quote:
Personally my approach is to reduce the save file to be very small (say 32 or 64 bytes) with a built-in CRC. Then I make several copies of the save file when the user saves, thereby giving me a little bit of protection. Not that I've released anything that uses this

In fact if the saves are this small you'd almost want to reduce the size a little further and use passwords.

by tepples on 2011-05-09 (#77937)

Bregalad wrote:
The user is supposed to use multiple save slots for multiple saves, not for security backups of his only save.

Unless of course you're playing Dragon Warrior, which I've been told makes its own security backups. So do Pokémon series, Animal Crossing series, and several other more recent games that have only one save file.

Bregalad wrote:
qbradq wrote:
Personally my approach is to reduce the save file to be very small (say 32 or 64 bytes)

In fact if the saves are this small you'd almost want to reduce the size a little further and use passwords.

There's a big gap between a 32-byte save of a Dragon Warrior-style backup plan and the 4-byte save of a practical (8 character) password. A 4-byte save needs a lot more railroading: OK for Mega Man, but not for certain RPGs.

by Bregalad on 2011-05-09 (#77938)

Dragon Warrior is based on the japanese game Dragon Quest which did use passwords.... so no big gap sorry.

About games using a single slot I find that a bit stupid, especially for console games. Does game developers assume nobody have brothers and sisters who would also play the game ? Not to mention that it's pretty common to borrow cartridges, so you'd have to have at least one slot for the owner of the cartridge, and one slot for people borrowing it.

by tepples on 2011-05-09 (#77940)

Bregalad wrote:
Dragon Warrior is based on the japanese game Dragon Quest which did use passwords.... so no big gap sorry.

DQ1 had a 20 character "spell of restoration". This reflects a few compromises:
Japanese can get away with that because katakana (or hiragana? I can't find screenshots on the web) has more characters than Latin. This gives about 1 extra bit per character.
Doesn't save HP or MP, which could be workable if all save points offer healing.
Doesn't save chest contents.
DQ2 had a 52 character password. That's up there with the 48 character password of The Lord of the Rings for Super NES, which I found unwieldy, or the 61-character "silver" password of Golden Sun, but not as bad as the 260-character "gold" password of Golden Sun.

Quote:
About games using a single slot I find that a bit stupid, especially for console games. Does game developers assume nobody have brothers and sisters who would also play the game ?

Completion of the endgame (after having beaten the Elite Four) in a Pokémon game is impossible without linking two different editions of the same game: Red to Blue, Gold to Silver, Ruby to Sapphire, Diamond to Pearl, Black to White, etc. The idea is that mom buys Pokémon Black Version for Meg and Pokémon White Version for Oliver.

Animal Crossing series does it differently: each of four player characters has his own save file, but the town itself also has a save file, and anything one player does in the town is reflected in other players' views of the town.

Quote:
Not to mention that it's pretty common to borrow cartridges, so you'd have to have at least one slot for the owner of the cartridge, and one slot for people borrowing it.

Video game publishers want each player to buy his own new copy. Otherwise, more PC games would support spawn installations.

by Dwedit on 2011-05-09 (#77942)

Lemmings 2 on Sega Genesis has really nasty passwords, I used to think that Maniac Mansion (Japanese Version) had the worst passwords, but I think Lemmings 2 beats it.
Lemmings 2: 264 characters (A-Z) per password (entered as 12 separate passwords of 22 characters each)
Maniac Mansion: 104 characters (66 possible characters)

by MottZilla on 2011-05-09 (#77945)

On Final Fantasy 3, while I'm not sure but based on other FF games, it actually does maintain hidden save slots you cannot see. While there are 3 slots you can see it actually has others in memory which it falls back on if CRC checks fail.

If your theory is correct about NES and accessing SRAM while powering off causes it, then in theory using SRAM only for game state backup and only accessing it at very minimal times should eliminate the problem. But I seem to recall Zelda executes alot of code from SRAM. So maybe it is more likely to effect games which actively write to SRAM. Zelda probably doesn't write to it during gameplay.

by tepples on 2011-05-09 (#77947)

Then you could organize the save data as six save slots in three pairs: current and last known good. I wonder if the NES has the CPU power to encode and decode Reed-Solomon coding for extra protection.

by drk421 on 2011-05-09 (#77952)

Off topic, but the post about plugging in carts while a system was on...

I once plugged in a cartridge into a Commodore 128 while it was on. After removing the cartridge and powering off and on typing on the keyboard would print out the incorrect characters that corresponded to the keys. (Eg, typing a "z" might print out a "@").
Even after powering on and powering off, it took pressing the key a number of times before it finally printed the correct character. To this day, I have no idea how or why it did that.

by kyuusaku on 2011-05-09 (#77954)

If you don't have a lot of information you can save the game's state three times and on reset clean the states by repairing the odd state out of sync with the other two, or in the case of no matching states clear them all.

I guess it's an implementation of this: http://en.wikipedia.org/wiki/Triple_modular_redundancy

by socram8888 on 2011-05-10 (#77979)

Or they could have used a 134a Power Down Chip as they did on the Gameboy

Sega did this too on his SRAM-based MegaDrive cartridges

by TmEE on 2011-05-10 (#77984)

Sonic3 on MD keeps 2 copies of each save slot in its memory. When one goes bad the other is used to restore the bad one, when both go bad you're out of luck

by Bregalad on 2011-05-10 (#78000)

kyuusaku wrote:
If you don't have a lot of information you can save the game's state three times and on reset clean the states by repairing the odd state out of sync with the other two, or in the case of no matching states clear them all.

I guess it's an implementation of this: http://en.wikipedia.org/wiki/Triple_modular_redundancy

This looks a pretty good way to restore corrupted saves. Although 2 saves with some CRC check would do the trick as well, with the same reliability, since you can restore the data as long as only one save is faulty in both cases, so you'd better store the data twice than 3 times for the degree of security.

Although I'd rather have a pretty good way to not get them corrupted !

If the chances of getting a save corrupted is 5% (it actually is almost that high on NES I suspect), the chances that at least one of two saves are safe is (1-(1-5%)^2) = 0.25 %
This might seem OK at first gland but it your save would still be erased in average every 400 play sessions which is still desirable.
I'd consider better invest some $0.70* for more parts and a more reliable backup cricuitery, so that there is like 0.0001 % of loosing the saves, and no need to store the data twice.
In this configuration you'd typically loose data only if the battery is dead or if there is a power shortage at the exact same time you're saving your game.

* On Futurlec.com, a zenner diode is $0.10, resistors are $0.10 each ($0.30) and a voltage comparator can cost about $0.30
There is also non-voltatile RAM controller chips for $2.75, but there is only one type of them so you never know when they'll stop making them (considering battery backed SRAM is mainly obsolete today with the arrival of FlashROM and MCUs with the sleep ability that can keep their RAM's content intact). This chip would also substitute the SRAM power circuit usually involving two diodes and one resistor (which can be considering costing $0.30, for a total of $1.00, as opposed to the chip which costs $2.75).