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.
Simple method for more reliable battery backup saves
Moderators: B00daW, Moderators
Simple method for more reliable battery backup saves
Useless, lumbering half-wits don't scare us.
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.
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.
Useless, lumbering half-wits don't scare us.
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
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
OBJECTION !!!!
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.
So you DID have one of them destroyed, just not both at a time.
I just saved in both save slots every time. I never had both deleted at once.
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.
In fact if the saves are this small you'd almost want to reduce the size a little further and use passwords.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
Useless, lumbering half-wits don't scare us.
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:The user is supposed to use multiple save slots for multiple saves, not for security backups of his only save.
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.Bregalad wrote:In fact if the saves are this small you'd almost want to reduce the size a little further and use passwords.qbradq wrote:Personally my approach is to reduce the save file to be very small (say 32 or 64 bytes)
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.
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.
Useless, lumbering half-wits don't scare us.
DQ1 had a 20 character "spell of restoration". This reflects a few compromises:Bregalad wrote:Dragon Warrior is based on the japanese game Dragon Quest which did use passwords.... so no big gap sorry.
- 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.
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.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 ?
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.
Video game publishers want each player to buy his own new copy. Otherwise, more PC games would support spawn installations.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.
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)
Lemmings 2: 264 characters (A-Z) per password (entered as 12 separate passwords of 22 characters each)
Maniac Mansion: 104 characters (66 possible characters)
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
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.
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.
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.
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.