Saving to battery-backed CHR RAM

[lidnariq]

Sivak mentioned that SRAM was expensive. I wonder how much a tiny EEPROM would have been to use?

As far as I can tell, once you're using RAM at all anywhere in the system — and for modern homebrews that's probably CHR RAM — you should just increase its size and battery-back it instead to get saving capability. The cost of the battery, diodes, resistors and capacitor to battery back a SRAM is (~10+2+2+3+1)¢ in quantity and will take 2-4 bits of bankswitching registers; the cheapest EEPROM solution I could find was (13+2+1+1)¢, I²C, 128b, and will take 2 bits out of the bankswitching register.

Incidentally, Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.

[rainwarrior]

Oh, so it's just for saving data, not as general purpose RAM. Interesting.

[tokumaru]

Even if you use only 8KB of battery-backed CHR-RAM without anything fancy such as bankswitching you could give up a few tiles and the space for saving data instead.

[3gengames]

Even if you use only 8KB of battery-backed CHR-RAM without anything fancy such as bankswitching you could give up a few tiles and the space for saving data instead.

Yeah, and he probably only needs 1 tile, 2 max. 1 tile is 16 bytes which should be more than enough for his game. Don't have to remember much.

[tokumaru]

Yeah, 2 tiles should be enough for most games that are not RPGs or any kind of detailed world simulation.

[tepples]

True, one tile is worth about four 8-character passwords. But given what I've seen in Shiru's init code and even some of my own code,* the problem with putting tiles and saves in the same bank of CHR RAM is the possibility of a bug in the VRAM loading routines causing loss of saves. One might solve that by using a 62256 and switching to the bank with the saves only when loading or saving, much like how SOROM and ETROM have a separate chip for the saves, or SXROM and EWROM have four banks.


* Concentration Room 0.02 palette updates may overwrite VRAM on the first frame of a game due to the address increment being set at the wrong point in the subroutine.

[3gengames]

I don't see how bad programming can be used as excuse not to do something. That's pretty disgusting if you're that terrible of a programmer you shouldn't be programming anything.

[tokumaru]

I don't see how bad programming can be used as excuse not to do something.

I have to agree with this. It's like saying "you can't jump in my game because my jump physics are crap". If there's a bug with your VRAM routines, fix them. The complexity and cost of adding another chip is hardly a good alternative to actually fixing bugs.

[Denine]

I don't see how bad programming can be used as excuse not to do something.

I agree. If something is invalid, improve and fix it.

if you're that terrible of a programmer you shouldn't be programming anything.

I Disagree. The greatest failure is when you don't try at all.
If you are bad programmer, just improve, lern new techniques, make some demos "for yourself only" and then try again. Just don't give up saying "I'm just born as bad programmer".
Remember MOE?.
I spent about a year to improve my skill so(for example)map isn't read form $2007(MOE does that) for collision. I don't need to turn rendering off at bottom of screen to update on screen tiles(because of badly written NMI).
ETC.
By looking at MOE one might say. "Please DON'T make anything anymore, it'll suck anyway." But I improved, and in new game(currently waiting for Hardware tests) coding part is better.
Even worst programmer can improve if he really wants it.

[Memblers]

Sivak mentioned that SRAM was expensive. I wonder how much a tiny EEPROM would have been to use?

As far as I can tell, once you're using RAM at all anywhere in the system — and for modern homebrews that's probably CHR RAM — you should just increase its size and battery-back it instead to get saving capability.

I think it's worth noting that while SRAM standby power consumption is generally low, it does vary. On the (admittidly, older) chips I've looked at previously, the part number will have an L for low power, and LL for extra low power (this is what you'd want for battery backup, ideally). Throwing any random SRAM on there, the battery might not last as long as one would hope. So, it's possible one would be paying a higher price for SRAM, if they wanted the longest battery life.

[zzo38]

For this and other purposes, I have idea to make an extended .NES format where there is one mapper number assigned to make a custom defined mapper, including zero or more audio expansions, ROM, RAM, disk, nametables, mirroring, and whatever else. I can try to make a better idea and we can work together too, in another thread, to figure this out.

[lidnariq]

I think it's worth noting that while SRAM standby power consumption is generally low, it does vary. On the (admittidly, older) chips I've looked at previously, the part number will have an L for low power, and LL for extra low power (this is what you'd want for battery backup, ideally). Throwing any random SRAM on there, the battery might not last as long as one would hope. So, it's possible one would be paying a higher price for SRAM, if they wanted the longest battery life.

Good reminder; currently on Digikey the cheapest options are a high speed 61c256 (350uA standby, 10ns cycle time), and a "slower" 62c256 (15uA, 45ns). Fortunately they're the same cost ($112.90/100) but it is necessary to be careful and check.

[tepples]

One might solve [the possibility of save corruption] by ... switching to the bank with the saves only when loading or saving

if you're that terrible of a programmer you shouldn't be programming anything.

We're all terrible programmers. "All have sinned and fall short of the glory of God," as Paul wrote in Romans 3:23. You and I both know this: as you pointed out to me later, you too have released imperfect software. And it's a lot harder to patch a cartridge after release than to patch, say, a downloadable Android game. On some platforms, even a downloadable game can run into problems, as Microsoft charges tens of thousands of dollars for certification of a patch to an Xbox Live Arcade game. (See the recent Slashdot story about Fez.)

So the right thing is to do one's best not to be terrible, but also to take reasonable steps to mitigate the effects of being unintentionally terrible. That's why I suggested using the extra banks in the RAM chip that one's already using to build in extra memory protection mechanisms as a layered defense. There are a lot of ways to do this, including some that involve no additional cost:

Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.

If you have 16 banks available (128 KiB SRAM divided by 8 KiB visible to the PPU at once), and your game uses one or two, then why not store the saves in a bank that nothing else uses?

Another mitigation is to have both password and battery save within the same game. For example, after completing a chapter, a game could give the player a password to restart the game from that chapter in case a freak glitch wipes out the player's saves, although with a somewhat underpowered party. It wouldn't be much different from the "bronze password" in Golden Sun for Game Boy Advance that summarizes the stats of a completed game at a reduced level of detail so that the character could be imported to the sequel.

If there's a bug with your VRAM routines, fix them.

I agree that one should learn from one's mistakes. Jonah at first shied away from preaching in Nineveh but ended up learning from his sins and delivering a very powerful prophecy. Likewise, after having denied three times in one morning that he knew Jesus, Simon Peter became a strong advocate for the faith.

But one still can't fix what's already shipped. Case in point: The original Super NES console, revision 1/1/1, has a defect that freezes the CPU if a DMA copy finishes too close to an HDMA. Nintendo fixed this for the more common 2/1/3, but games still had to work around the bug in 1/1/1 by not using DMA copy at the same time as HDMA. Likewise, after 3gengames reported Concentration Room's VRAM corruption bug to me, I isolated the problem and prepared a patch to fix the defect within the hour. But it still took years to discover this problem, as it had eluded me until long after I had already shipped Concentration Room 0.02 as part of the MGC 2011 multicart. Had I planned on battery-backed CHR RAM from the start of a project, I'd probably catch such an obviously reproducible bug quickly, but a similar bug that's harder to trigger might slip past the testers and end up in the shipped product. Furthermore, defensive programming techniques that allow programs to run correctly even in unanticipated environments are especially helpful when developing for a PC or an Android device.

Besides, how would one test a game that uses this method? The only iNES mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that I don't believe anything really supports yet) is 168, used only for RacerMate Challenge, and that's marked "planned" on retrousb.com. That too uses two CHR RAM chips, only one of them battery-backed. Do any emulators support adding battery-backed CHR RAM to a more common board through the NES 2.0 header?

(You may have seen my avatar change a few times in the past couple weeks. If you want, I can post an explanation of my avatar images elsewhere.)

EDIT: Explanation

[infiniteneslives]

Besides, how would one test a game that uses this method? The only iNES mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that I don't believe anything really supports yet) is 168, used only for RacerMate Challenge, and that's marked "planned" on retrousb.com. That too uses two CHR RAM chips, only one of them battery-backed. Do any emulators support adding battery-backed CHR RAM to a more common board through the NES 2.0 header?

(You may have seen my avatar change a few times in the past couple weeks. If you want, I can post an explanation of my avatar images elsewhere.)

Sorry for the plug but testing something like this is the main goal of the NESDEV1. Let's just hope things go as planned for the release

And yes I did notice the avatar changes and was curious to their meaning if you're willing to share elsewhere.

EDIT: oh, and nice to see your back Tepples

[fam]

Maybe use a 1 color font palette {bg, bg, font, font} and put data on one half of those characters