DRW wrote:
Yes, I'm talking about the battery save. My next game has battery savestates
It is completely false to use the word savestate for this. Please stop, you'll only be confusing people, NES-related vocabulary is already enough confusing/confused as it is. Savestates is an emulator-only thing. You're refering to battery saves.
As for your question, Final Fantasy II and Final Fantasy 3 uses a simple 16-byte checksum, calculated with the adc instruction. If the checksum is wrong, the save is considered to be "empty", but I don't think it'll be erased (I could be wrong), just that loading from it is impossible and trying to do so will trigger a new game.
Unlike most games, Dragon Quest games explicitly tells you when a save file is corrupt and there's even a music dedicated to that. I however do not know how the checksum mechanic works.
It is unfortunately mysterious why save corruption happens but it happen all the time, and that regardless whether reset is pressed or not when turning the console off. Note that turning the hardware off is only one of the possible cause for corruption, turning it on and having software glitches are two of the other possibilities when it comes to possible SRAM corruption, also having bad cart contacts too (this is typically the case with 72-pin frontloaders).
I do not know if any game duplicates the data, but it would make sense to do so, especially since save game data typically uses only a small part of the available 8k SRAM. With FInal Fantasy III I had to systematically save my data in two slots or even all 3 slots, to be sure at least one of those would be preserved. It happened quite regularly that one of the slot was erased, but never (so far) all slots simultaneously. So yes, SRAM corruption indeed does not appear on the whole chip at once.
If you are serious about analysing the problem I'd recommend you write tests program to test exactly that and see which parts of SRAM are corrupted and how.
As for the idea to add redundancy to allow recovery, CD ROMs use a row/column XOR based method that only adds some redundancy (about 20% ?) but allows to fix read errors most of the time. Maybe this would be interesting to apply that to NES saves (it's just an idea, perhaps it doesn't work the same way).
For example, if the save file is 1k ($400 bytes), you can make it virtually of 32 "lines" and 32 "columns" of bytes, and have the XOR of each row/column stored. This adds only 64 bytes of data (6.25% of total size), and if only one single byte is corrupted, it can be recovered. The drawback is that if more than one byte is corrupted, this does not work anymore.
Quote:
and you are very unlucky if those random instructions happens to be writes in the cart RAM area.
Trust me you don't need to be
very unlucky, just plain unlucky, for that to happen.