Skip navigation
NintendoAge
Welcome, Guest! Please Login or Join
Loading...

Tech Talk Hardware question How does writing to battery-backed WRAM cause problems?

Jun 19, 2015 at 12:14:36 AM
a0r10n (0)
avatar
(Toriningen ) < Cherub >
Posts: 13 - Joined: 06/18/2015
Washington
Profile
In the case that I have battery-backed WRAM, I happen to know that writing to it too often is discouraged, because if the NES is turned off at the wrong time, data gets corrupted. But, does this only apply to that data that was being written, or could I write to other parts of my WRAM without destroying the whole thing (if the power was cut)?


Edited: 06/27/2015 at 01:46 PM by NintendoAge Moderator

Jun 19, 2015 at 3:02:41 AM
chowder (2)
avatar
(Rob H) < Eggplant Wizard >
Posts: 253 - Joined: 02/13/2014
England
Profile
I've only just started working with battery backed WRAM, so I might be misunderstanding, but I'm not too sure what you're asking. You can use WRAM with or without a battery, if it's not battery backed it effectively just acts as more RAM and the contents are lost on reset. Are you referring to the save data problem when powering the system off without holding down reset?

As far as I'm aware, you can't save parts of WRAM, the whole 8K block ($6000-$7FFF) is saved if a battery circuit is present on the cart.

Jun 19, 2015 at 3:18:03 AM
Memblers (3)
avatar
(Joey Parsell) < Eggplant Wizard >
Posts: 247 - Joined: 05/12/2008
Indiana
Profile
The cart should have some hardware dedicated to protecting the RAM from getting corrupted during power-down, if it doesn't, you have to hold the reset button. So yes, on the coding side you only need to worry about the data that you're writing to. But depending on how you're using it, corrupting one byte could effectively ruin the whole RAM. This type of failure can be avoided by keeping a backup copy (or multiple copies) of your data, and only working on a temporary copy during gameplay. You really should have a way to validate your data before you load it, like a CRC or checksum. I've been working on a small code library that would handle all this stuff, for WRAM and FlashROM, hopefully I'll have it released before too long.

-------------------------
 

Jun 19, 2015 at 8:47:56 PM
a0r10n (0)
avatar
(Toriningen ) < Cherub >
Posts: 13 - Joined: 06/18/2015
Washington
Profile
I planned on having battery-backed RAM, but only using part of it for save data. I felt it would be convenient if I could use the parts of the WRAM for things other than save data. But I'm worried about ruining everything if the power goes out. If only what I'm currently writing is lost, that's fine. I just don't want the things I actually want to save to get corrupted too.

Jun 19, 2015 at 11:28:57 PM
Guntz (115)
avatar
< Master Higgins >
Posts: 8279 - Joined: 05/07/2011
Canada
Profile
If you really need WRAM just for engine purposes, not for file saving, it's possible to have two 8KB WRAM chips in one cartridge. Some RPGs did that.

Jun 20, 2015 at 2:49:06 AM
Memblers (3)
avatar
(Joey Parsell) < Eggplant Wizard >
Posts: 247 - Joined: 05/12/2008
Indiana
Profile
In most cases you'll be fine, if the user holds reset while powering down, or if the board has hardware to disable RAM on power failure. But there are still more unpredictable factors, like what can happen if the NES has a dirty connector, or the NES gets bumped while it's on. If CPU runs some garbage as code, it only takes one stray write to hose your data.

The solution I would recommend, if preserving the data is important enough, is doing a CRC on the save data, and storing multiple copies in RAM. If the CRC fails, there's a good chance you can load one of the backups.

Like Guntz mentioned, MMC6 is one mapper that has battery-backed RAM dedicated to saving (much smaller though, and built-in to the mapper). From what I understand, games like Star Tropics would enable the backup RAM only when saving data, so it's RAM is almost always disabled. I would imagine a game like Genghis Khan (which has 2 8kB RAMs) does something similar. It's always possible to throw hardware at the problem, just costs a bit more to make the cart. For a "modern" NES game, I would recommend using FlashROM to save. It's much harder to corrupt, because every write requires an unlock sequence. There's still the problem of a user powering down while a write is happening, but little else to worry about.

If you're in the early stages of development, it's probably better to worry about a more robust save system later on, it's something that should be easy to change, if you have a little bit of a system to it. I'd say basically to only write your actual save data all at once, and when manipulating it, do it on a temporary copy in another part of RAM. You'll be able to get it working, data corruption in SRAM is just a fact of life (at work I repair/refurb a Z80-based system with a similar setup, and see it all the time), every NES game dealt with it in some way, except I guess the few that threw more hardware at the problem.

-------------------------