How did old NES games use their SRAM? How would you use it?
Moderator: Moderators
This thread is relevant to my interests.
I, ideally, wanted to use 32k of SRAM for my game, but was wondering what the hell to do with all that space... I guess I could compress the living shit out of stuff and store it there iif I needed to.
I think that some games store multiple copies of a save in the SRAM to check and see if the save's been corrupted or anything, but I'm not too sure. I think one of the Dragon Warriors does this maybe?
I, ideally, wanted to use 32k of SRAM for my game, but was wondering what the hell to do with all that space... I guess I could compress the living shit out of stuff and store it there iif I needed to.
I think that some games store multiple copies of a save in the SRAM to check and see if the save's been corrupted or anything, but I'm not too sure. I think one of the Dragon Warriors does this maybe?
Yeah, you could compress stuff that would normally be uncompressed in the ROM, and make better use of the storage space you have available.Ian A wrote:I guess I could compress the living shit out of stuff and store it there iif I needed to.
That's probably a good idea. You can use hashes/checksums to detect currupt saves, and as long as one of the copies is OK you can restore the saved data.I think that some games store multiple copies of a save in the SRAM to check and see if the save's been corrupted or anything
Personally, I don't plan on using SRAM anytime soon. Most of the things I want to do can work with just 2KB of RAM and passwords.
One use I can think of for banked SRAM is to use the banks for different subsystems. One bank could be reserved for your map and objects, another for the sound engine (to store uncompressed music and SFX data), a third for your battle system (for a JRPG) or your menu system or other user interface stuff, and the fourth for save files.
With 8K reserved for save files I can think of a lot of cool things you could do. You could allow every map to remember a lot about it's state. You could keep a running counter of how many of each type of enemy has been defeated. Or you could just allow the user to have 16 save slots, each with a double backup
Also, passwords = the stuff you scrape off your shoe after walking 20 dogs in the park
With 8K reserved for save files I can think of a lot of cool things you could do. You could allow every map to remember a lot about it's state. You could keep a running counter of how many of each type of enemy has been defeated. Or you could just allow the user to have 16 save slots, each with a double backup
Also, passwords = the stuff you scrape off your shoe after walking 20 dogs in the park
Doesn't Final Fantasy use PRG-RAM to decompress tile maps when entering each area?
I do recall that Final Fantasy on Wonderswan and likely other FF games on other platforms would have many save slots even though only two were visible as it would have a checksum for each save and if one was corrupted it would go to the previous save for that slot.
Given the number of games that just have non-battery backed RAM shows how useful it can be so it's no surprise the majority of the memory isn't actually for saves.
The Startropics games actually use their SRAM probably almost exclusively for saving since I assume to cut cost they have a much smaller amount of SRAM than any of cartridges.
I do recall that Final Fantasy on Wonderswan and likely other FF games on other platforms would have many save slots even though only two were visible as it would have a checksum for each save and if one was corrupted it would go to the previous save for that slot.
Given the number of games that just have non-battery backed RAM shows how useful it can be so it's no surprise the majority of the memory isn't actually for saves.
The Startropics games actually use their SRAM probably almost exclusively for saving since I assume to cut cost they have a much smaller amount of SRAM than any of cartridges.
8k saves seems to be the standard for NES, SNES and PS1 games.
Systems that uses EEPROM or Flash based saves seems to usually save on a different chip than the one the game is programmed on. At least it's the case on the GBA and on those Bandai NES games with EEPROM saves.
Personally I like the idea of Flash / EEPROM based saves as it is MUCH less likely to loose your saves. I've lost my saves on NES/SNES/GBA games quite a few times, without even the batteries being dead. You just don't know why this happens.
Having only one slot sorts of sucks because you can't lend the game to your brothers/cousins/friends, and if you want to replay the game you have to erase the old save.
Not to mention what happens if you save while being stuck (even though I think a game should be programmed so that it's hard/impossible to do that).
Systems that uses EEPROM or Flash based saves seems to usually save on a different chip than the one the game is programmed on. At least it's the case on the GBA and on those Bandai NES games with EEPROM saves.
Personally I like the idea of Flash / EEPROM based saves as it is MUCH less likely to loose your saves. I've lost my saves on NES/SNES/GBA games quite a few times, without even the batteries being dead. You just don't know why this happens.
In my opinion this is pretty stupid. The programmers could as well give more slots to the player, and let him manage his saves.I do recall that Final Fantasy on Wonderswan and likely other FF games on other platforms would have many save slots even though only two were visible as it would have a checksum for each save and if one was corrupted it would go to the previous save for that slot.
Having only one slot sorts of sucks because you can't lend the game to your brothers/cousins/friends, and if you want to replay the game you have to erase the old save.
Not to mention what happens if you save while being stuck (even though I think a game should be programmed so that it's hard/impossible to do that).
Probably, but it's different. The amount of SRAM is smaller but it's very well protected, unlike early MMC1 games where the save could be a goner any time, no matter if you push the reset button or not.The Startropics games actually use their SRAM probably almost exclusively for saving since I assume to cut cost they have a much smaller amount of SRAM than any of cartridges.
Useless, lumbering half-wits don't scare us.
Because 1. one may need the extra RAM, and 2. the only donor carts are Japan-only games by Bandai. In theory, one could use SOROM and replace the second PRG RAM with an EEPROM of some sort. But that would still probably cost more than devoting the first, say, 64 KB of a 256 KB SNROM or 512 KB SUROM to saves.drk421 wrote:Unless you need the extra RAM for your game, why not use a serial EEPROM like some Genesis games?
[devils-advocate]Bregalad wrote:Having only one slot sorts of sucks because you can't lend the game to your brothers/cousins/friends
You're not supposed to lend it. You're supposed to buy a new copy for them.
[/devils-advocate]
I must have been tired at the time. No idea where I got "two" from. I'm pretty sure FF on wonderswan and other consoles generally have 3 or 4 save slots plus hidden backups to deal with possible save corruption.Bregalad wrote:In my opinion this is pretty stupid. The programmers could as well give more slots to the player, and let him manage his saves.I do recall that Final Fantasy on Wonderswan and likely other FF games on other platforms would have many save slots even though only two were visible as it would have a checksum for each save and if one was corrupted it would go to the previous save for that slot.
Having only one slot sorts of sucks because you can't lend the game to your brothers/cousins/friends, and if you want to replay the game you have to erase the old save.
Not to mention what happens if you save while being stuck (even though I think a game should be programmed so that it's hard/impossible to do that).
EEPROM sounds nice for saving but there will be a limited write cycle life and then the chip itself needs replacing which is not as easy as replacing a battery unless you have a standardized EEPROM that is cheap and socketed to the board so it is just a matter of lifting the dead one out and inserting a fresh chip. The idea of backing up saves via a sort of memory card device is nice though.
No I meant an IC socket soldering to the PCB so the user could simply remove an expired serial eeprom or similar eeprom chip when it runs out of write/erase cycles. A bunch of games saving to SD cards put into their own cartridges would be strange unless you actually needed to save some huge amount of data.