nesdev.org

I was just thinking about the logistics of making a NES RPG. In NES terms, 8k is a ton of space. I suppose that's easy to say until you start filling it up, but you really ought to be able to accomplish a lot with it.

And then I got to thinking about games that supported it, and how the majority really couldn't have needed most of it for saving. I'm not much of a source diver to determine the exact nature of these things, but I know some people have and I wondered if someone could shed a little light on the typical use of SRAM.

For example, look at Kirby's Adventure - it has save data, but doesn't save your score, health, current ability, or even number of lives. It saves which levels you've completed (and whether you found all the level's secrets) but doesn't save whether or not you've already played a minigame. If we're generous and assume it saves a byte of data for every level, and there are about 40 levels and 3 save slots, that comes out to a whopping 120 bytes. Out of 8k.

Or look at a typical RPG of modest size. Let's say 8 bytes for a party member's name, 16 bytes for his attributes (strength, current HP, experience points). 8 more bytes of hidden stats and miscellaneous flags (poisoned etc.) and 16 bytes for his inventory (8 items plus flags for states like "equipped"). 48 bytes per character x 8 party members = 384 bytes. Then 32 bytes to support 256 chests and another 32 for 256 game flags ("talked to king," "killed the boss"). Finally add 128 bytes for things I didn't take into account like the party's room/x/y location and the status of minigames. Even playing fast and loose and being really generous, that's still only 576 bytes. You could almost squeeze that into regular RAM along with the rest of the game. Most RPGs probably used a lot less, considering they didn't often save information like the party's x/y position. To my knowledge Final Fantasy was one of very few games that let you save anywhere on the world map, even though it should be an easy thing to do.

So how do games use that 8k? Do they keep a backup or two of save data in case of corruption? Do they primarily just use it for more working RAM, decompressing large amounts of data and tables there? Are my estimates just way off?

Did any game really use all/most of it for saving vital information? I can imagine Dragon Quest 4 might have, that was an extremely complex game...

And do you have any ideas for how you would personally use SRAM to be sure you take good advantage of it? You could save a complex 32x32 map with 2 bytes of data per tile in just 2k, and that's before compression. Saving custom levels should be trivial, especially for games like Excitebike that use big meta-chunks. You could also back up the entire state of the game several times over.

I dunno, just kind of intrigued by the amount of SRAM in general.

There are some games whose saves won't fit in 8192 bytes. SimCity is one of them; as I understand it, SimCity for NES was ported to Super NES precisely because of replication cost to use MMC5 and a larger SRAM. In this article, I investigated compression schemes to try to get an Animal Crossing town to fit, but I failed.

You could ask how non-battery-backed games, such as Metroid, Super Mario Bros. 2, and Super Mario Bros. 3 use their SRAM. M.C. Kids uses it to allow for more destructibility in levels, so that they wouldn't have to restrict level geometry to allow, say, only one destructible item per column of the map.

In some cases, it's possible to fit an entire saved state into 32 bits, short enough for a convenient 8-character password. A fairly railroaded action RPG might arrange its state thus:

8 bits: sqrt(cash)
5 bits: character level
3 bits: experience to get to the next level, in units of (XP[i + 1] - XP) / 8
4 bits: chapter
12 bits: event flags relevant to this chapter

The fact that some games have battery-backed SRAM doesn't mean that they have to use it exclusively for saving. I'm pretty sure most games use it mainly as extra RAM, for level maps or similarly large data.

Most of the time, 8KB is too much for save data, but since Nintendo already used 8KB RAM chips for CHR-RAM it was probably easier/cheaper for them to use the same chip than to go with something smaller.

tokumaru wrote:Most of the time, 8KB is too much for save data, but since Nintendo already used 8KB RAM chips for CHR-RAM it was probably easier/cheaper for them to use the same chip than to go with something smaller.

I bet this is the case. But I think the OP's point is that if you have it, why not use it? It really does seem like a lot of games with battery RAM could have done so much more with it.

I actually really want to use Battery RAM for my game, as it will be rather long. From what I understand that will cause issues when (and if) I want to mass reproduce it on a real cart.

cartlemmy wrote: But I think the OP's point is that if you have it, why not use it?

I'm pretty sure many games do. I know I wouldn't ignore all that RAM if it was available to me.

Honestly, I'm still not sure what would be a good way to use the extra RAM, be it battery-backed or not. To me it looks like a lot of the games with extra RAM could have been made without it if they were designed that way. I can't think of any good examples of games that absolutely need the extra RAM to exist.

I actually really want to use Battery RAM for my game, as it will be rather long.

The fact that your game is long doesn't necessarily mean that you need a lot of space to represent states. For platformers, passwords are usually enough.

From what I understand that will cause issues when (and if) I want to mass reproduce it on a real cart.

It will just be more expensive, I guess.

tokumaru wrote:The fact that your game is long doesn't necessarily mean that you need a lot of space to represent states. For platformers, passwords are usually enough.

True, there will be quite a few items and power-ups, and the hero's current position in the world... But each item could be represented by 1 bit and the position by 1 byte (Won't have more than 256 areas). So it's feasible.

I kind of like passwords like that too, because if the player figures out what bits do what, it is easy to pick and choose what items are set. A sort of exposed Game Genie code.

cartlemmy wrote:I kind of like passwords like that too, because if the player figures out what bits do what, it is easy to pick and choose what items are set. A sort of exposed Game Genie code.

Heh, I think I wouldn't like to have players manipulating passwords in my game... I'd probably use some sort of hashing to prevent codes from being modified so easily. Of course a programmer could reverse engineer it, but regular players probably wouldn't figure it out.

tokumaru wrote:Heh, I think I wouldn't like to have players manipulating passwords in my game...

Yeah, I could see that. For some reason I like the idea of letting them mess around with it.

cartlemmy wrote: I actually really want to use Battery RAM for my game, as it will be rather long. From what I understand that will cause issues when (and if) I want to mass reproduce it on a real cart.

You mean mass produce, right? heheh (sorry, just seems like the word 'reproduction' has been taking on all sorts of new meanings lately).

The big annoying thing with a battery is that it's really easy to lose your save data.. you pretty much need an NVRAM controller, otherwise you have to do the "hold reset when powering off" thing.

I would advise using FlashROM for save data. Then you don't need a battery or RAM write protection, and to top it off, the Flash data should persist longer than a battery's lifetime (which is plenty long, but still). No extra parts needed because the PRG-ROM is the FlashROM. There's not a mapper available currently that supports it, but I've designed/built some in the past and will be making another one here shortly. And it will be available for productions, large or small.

Memblers wrote:There's not a mapper available currently that supports it, but I've designed/built some in the past and will be making another one here shortly. And it will be available for productions, large or small.

Now, that sounds really cool. Would I go about developing it like normal WRAM?

cartlemmy wrote:Now, that sounds really cool. Would I go about developing it like normal WRAM?

No, FlashROM is very different from RAM. FlashROM would have to be used strictly for saving/restoring data, because it's slower to write to (you can't freely write to any address you want, you have to write to sectors or something) and they can be rewritten a limited number of times (the number is large, like several thousand times, but it's still limited).

Memblers wrote:No extra parts needed because the PRG-ROM is the FlashROM.

I worry about that a bit. I fear that the program might crash and somehow end up overwriting parts of the program itself... Losing your saved data is already bad enough, but losing the actual game is much worse.

Yeah using it would be the same, with the exception that you would reserve part of the PRG-ROM to be used for saved data. 4kB or 8kB might be the smallest amount of ROM you "lose", out of 512kB (or 256kB).

I will supply code with it that would verify and copy data between the WRAM and FlashROM. It would create sort of a simple filesystem, and automatically erase/rewrite the 4kB sectory when it's "full".

tokumaru wrote: and they can be rewritten a limited number of times (the number is large, like several thousand times, but it's still limited).

The SST Flash with 4kB sectors says 100K rewrites. A calculator check shows that someone could save 16 times a day, every day for 17 years straight. It's the erasing that limits the endurace actually, it's programmable randomly on any individual byte, so it's possible to really drag out the lifetime of a sector by saving smaller amounts and only erasing when needed.

The AMD chip I was using before said 1 million erases, but it had 64kB sectors and isn't made anymore.

Memblers wrote:No extra parts needed because the PRG-ROM is the FlashROM.

I worry about that a bit. I fear that the program might crash and somehow end up overwriting parts of the program itself... Losing your saved data is already bad enough, but losing the actual game is much worse.

Yeah, understandably. There is a chip erase command that will erase the whole chip, but it would be virtually impossible to trigger it accidentally (requiring a sequence of I think 6 writes with specific address/data - same with sector erase command). When erasing a sector, you would just have to be absolutely sure the correct bank is selected (determined by using the mapper bankswitch like normal registers and where you write the command to).

The AMD chip I used before offers a write-protect feature for individual sectors. The SST one doesn't seem to, but I think the chances of erasing the wrong bank are pretty small.

You can use ROM, But that'd only be good for things that aren't updated every frame, more like 10 times a play or something small. Because if it saves AND uses the SRAM at the same time, the Flash would be pretty much useless and overkill. IMO, just sticking to the SRAM+Battery is better since it can double as a RAM. That's kinda the whole point of the RAM I'd think.


Although, it'd be interesting to see a FlashROM in a cart too. Or do as I think was said some time ago, use s serial flash ROM and make a "memory card" that plugs into the expansion port/controller port and use that. That'd be far better IMO. More games can use it if they wanted, and it'd be cheaper than including a Flash ROM in every cart.

The idea with flash + non-battery-backed PRG RAM is that the program and the save data can sit on the same chip, much as with FDS games.