Saving to battery-backed CHR RAM

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
lidnariq
Posts: 9705
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Post by lidnariq » Mon Jul 09, 2012 11:36 am

In [url=http://nesdev.com/bbs/viewtopic.php?p=96647#96647]this post about Battle Kid[/url], Dwedit wrote: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.

User avatar
rainwarrior
Posts: 7843
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Post by rainwarrior » Mon Jul 09, 2012 11:41 am

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

User avatar
tokumaru
Posts: 11870
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Jul 09, 2012 12:23 pm

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
Formerly 65024U
Posts: 2277
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Wed Jul 11, 2012 5:09 am

tokumaru wrote: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.

User avatar
tokumaru
Posts: 11870
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Wed Jul 11, 2012 6:20 am

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

tepples
Posts: 22056
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Jul 11, 2012 6:57 am

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.
Last edited by tepples on Wed Jul 11, 2012 7:04 am, edited 1 time in total.

3gengames
Formerly 65024U
Posts: 2277
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Wed Jul 11, 2012 7:02 am

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.

User avatar
tokumaru
Posts: 11870
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Wed Jul 11, 2012 11:00 am

3gengames wrote: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
Posts: 398
Joined: Wed Feb 17, 2010 5:42 pm

Post by Denine » Wed Jul 11, 2012 1:16 pm

3gengames wrote: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.

User avatar
Memblers
Site Admin
Posts: 3886
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Thu Jul 19, 2012 11:50 pm

lidnariq wrote:
In [url=http://nesdev.com/bbs/viewtopic.php?p=96647#96647]this post about Battle Kid[/url], Dwedit wrote: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
Posts: 1075
Joined: Mon Feb 07, 2011 12:46 pm

Post by zzo38 » Fri Jul 20, 2012 10:15 am

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.
[url=gopher://zzo38computer.org/].[/url]

lidnariq
Posts: 9705
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Post by lidnariq » Fri Jul 20, 2012 12:07 pm

Memblers wrote: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
Posts: 22056
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Jul 25, 2012 7:27 am

3gengames wrote:
tepples wrote: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:
lidnariq wrote: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.
tokumaru wrote: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

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives » Wed Jul 25, 2012 11:45 am

tepples wrote: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 :)

Post Reply