Alternatives to battery save

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

Moderator: Moderators

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

Alternatives to battery save

Post by tepples »

So I want to develop an original NES game that can save the player's progress across power cycles. I brainstormed several ways to go about it:

I could design the game not to need any data saved across power cycles, but I thought I wanted to get away from single-screen puzzle games.

I could use a password system, but that can't really save more than 32 bits without being annoying. (See, for example, 48-character passwords in The Lord of the Rings for Super NES.)

I could hack up an existing SNROM cartridge. But a lot of those either are higher-value games like Dragon Warrior 2 or Final Fantasy or lack the passive components needed for a battery, and I'd have to find them in lots and pay to have them shipped to whatever replicator I end up with, and the supply of those will eventually run out.

I could make a new cartridge functionally identical to SNROM, with SRAM and a battery. I asked bunnyboy about this a few months ago, but he said he'd never done battery save before on his MMC1 ReproPak board, and it'd probably be expensive in terms of parts (board with mapper, case, CIC, PRG EPROM, two RAMs, passives, and a battery).

Around the same time, Memblers suggested using a parallel flash memory for the PRG ROM and reserving half of that for saving. But saving to flash is a read-modify-write operation, and a lot of 5V flash chips have erase blocks noticeably bigger than the 1 KiB I have available ($0400-$07FF) after subtracting the zero page, the stack, and the buffer containing the data that needs to be saved in the first place.

A bunch of GBA and DS games use 3.3V serial EEPROM. A 5V one could be shoehorned into a batteryless SNROM-clone or even a discrete board with a 4-NAND for decoding $6000-$7FFF. But a lot of data sheets for 5V serial EEPROMs state that they are "not recommended for new design".

I could have it run only in emulators and on the PowerPak. This would have the advantage of letting players trade saved games on the Internet. This would rely on PayPal donations to encourage me to continue development.

Or I could just go the Cave Story/MM9 route and develop for SDL instead.

Have you any idea which is most viable?
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

For completeness:

Have player leave his NES on between runs.

Have player record his items and position, and enter them directly (honor system).

Use a NVSRAM with internal battery, in a normal WRAM-supporting board.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

This would rely on PayPal donations to encourage me to continue development.
If your only motivation is cash, then you could as well stop there.

Other than that, your best bet is without a doubt to make your game MMC1 compatible. If you ever want to make cartridges of it, which would be likely only if you get to a far point in the development of your game, there sure will be a solution, and you shouldn't avoid this because "it's expensive", because distributing a ROM on the net isn't expensive. Yes the powerpak is expensive but you buy it once and don't need to buy it again. You'd be repeating the error Nintendo did when they made Metroid use 64 letters case sensitive passwords which is extremely annoying instead of battery saves.

Some Famicom games uses serial EEPROMs too you'd want to look for that. But even if make a cartridge with them - you'd have "saved" money but your thing will not be very compatible with emulators.

If you want somehting purely hardware and not emulable, the best option would be a serial memory card that plugs in controller #2 or bottom connector, and would be accessible trough $4016/7. It could handle memory for dozen of games and be reliable, like Memory Cards for Playstation consoles.
Useless, lumbering half-wits don't scare us.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

A bunch of GBA and DS games use 3.3V serial EEPROM. A 5V one could be shoehorned into a batteryless SNROM-clone or even a discrete board with a 4-NAND for decoding $6000-$7FFF. But a lot of data sheets for 5V serial EEPROMs state that they are "not recommended for new design".
Microchip's I²C EEPROMs shouldn't be too limited life, and because of heavy investment by the automotive industry should remain 5V for a while, Also, they have a large number of 5V-compatible micros which could be programmed to pretend to be an I²C or SPI EEPROM.

Also, using a 3.3V I²C EEPROM (because it's open collector) should be as simple as adding a zener diode.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

I'm not necessarily looking for cash in the short term. I'm just looking for something that will keep me from defecting to the PC or another more general, more CV-relevant platform like Android or XNA. I have a feeling that a completed commercial product on my CV will open more doors once I do join the video game industry; see a previous topic about this.

Another possibility: Use a flash memory that allows reprogramming in smaller units than erasing (e.g. 16 KiB erase, 1 KiB program). Report capacity to the user based on two or three blocks less capacity than the memory actually has. Once only one empty block remains, "defragment" the memory by finding the erase block with the most entries that have been marked as deleted, copying that to the free block, and finally erasing the source block.
Ian A
Posts: 115
Joined: Sat Feb 27, 2010 8:32 am
Location: Maine

Post by Ian A »

I think it depends on the type of game you're making. The design of it makes a huge impact on what to pick.

If progress is more linear (i.e. one level after another, certain items are required to beat a level, therefore if you've beaten the level, you have said items) you're probably fine just with a password system.

I guess I'm more of a 'If you build it, they will come' type of guy, though.
ReaperSMS
Posts: 174
Joined: Sun Sep 19, 2004 11:07 pm

Post by ReaperSMS »

I assume you mean 32 bytes, as it should be pretty trivial to cram 32 bits into a 6-7 character password.

Metroid and Castlevania 2 cram about 200 bits into theirs I think, maybe a bit more.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

ReaperSMS wrote:I assume you mean 32 bytes, as it should be pretty trivial to cram 32 bits into a 6-7 character password.
A password with 8 characters might carry 32 payload bits and 8 error detection bits:

Code: Select all

p 4 $ $ w 0 r d
^
0 1 2 3 4 5 6 7
8 9 b c d f g h  <- 5 bits per character
j k L m n p q r
$ t v w x y z -
It's good for a game about as complex as Mega Man series (8 levels doable out of order, 16 pickups) or even a fairly railroaded action RPG with a 1-character party (8-bit sqrt(cash), 8-bit sqrt(experience), 4-bit weapon, 4-bit chapter, 8 subgoals per chapter). But a password much longer than that, like the one in Metroid (NES) or LOTR (SNES) or the old save bonus of Golden Sun (GBA), isn't so practical to use after every play session, and it'd be impossible to save the state of something like Harvest Moon or Videomation in a password.

The "honor system" that blargg mentions is equivalent to a long password.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

tepples wrote: Another possibility: Use a flash memory that allows reprogramming in smaller units than erasing (e.g. 16 KiB erase, 1 KiB program).
With the 29F family chips, I've never seen any require programming more than a single byte at once. I used that aspect of it on the NSF loading routine for Squeedo, I left some key addresses in the program as $FFFF, to be filled out later when the right value was known. It appeared that writing $FF when it's blank is the same as leaving it blank.

I'm not sure what flash chip to recommend, I haven't looked around at what's available now and I don't know what size you would need, either. I still have a bunch of 29F040s if that would be usable (512kB / 64kB erase sectors).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

A 29F010 or 29F040 might work. The program would occupy half of the eight sectors, and the rest would rotate among these functions:
  1. User data
  2. More user data
  3. Revisions to user data, as they are written
  4. Area that will get erased and filled with a copy of sector a, b, or c, whichever has most deleted revisions
The user would see only enough capacity to fill two of these four sectors.

But a mapper designed for use with a 29F040 would need either a fixed bank at $E000-$FFFF or a good reset detector to reset the program bank so that a CPU reset never starts the program counter in a freshly erased sector.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Isn't it dangerous to put the program and the saves in the same chip? I mean, couldn't a crash or bad connection accidentally cause parts of the program to be overwritten? A corrupted save is already bad enough, but a corrupted program is much worse! Is there a way to prevent against that?
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

I may feel harsh but making a nes game is maybe not the right way to "get into the industry" with the current climate of off sourcing jobs to India and China.

If your goal is to be a programmer and not a designer, you need skill that be used now. But I guess we all have the right to dream, myself included ;)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

tepples: A reset detector shouldn't be needed, we can use pull-up resistors either on the memory chip or on the logic inputs so there's a known state immediately. But you will want a little reset vector code in the data banks (if there isn't a fixed one, in case the user resets while it's in there). Doing something like UNROM might not be too bad, if 32kB banks are a problem.

tokumaru: There is a fairly lengthy unlock command before an erase command can be given, and the same thing for programming, so it should never happen randomly. If there's some kind of intermittent connection that would be bad news, but it would take a miracle for it to not crash and also send a valid command to the wrong bank.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

I just finished a demo of password generation, entry, and validation.

The NVSRAM that blargg mentioned is $7.50 each, compared to $2.50 each for an ordinary 62256.

The method of splitting a 29F040 between game and save would appear to need a custom mapper that places its registers below $6000 so as to distinguish flash writes from mapper writes.

On #nesdev, someone suggested Ramtron FRAM. But parallel FRAMs are considered obsolete according to Ramtron's web site, and I²C FRAMs appear to need mapper support (even if only an open-collector latch so that the CPU can bit-bang it).


EDIT (2017): Mirrored as an attachment
Attachments
password_save.zip
(17.6 KiB) Downloaded 208 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

What are you really hoping for? Something that's compatible with the current NES save conventions (i.e. some kind of NVRAM memory-mapped in $6000-$7fff) or a cart with a cheaper way of holding the save data? Because you seem to be getting stuck on wanting both.

Regardless: Microchip and Atmel both say they'll be making 5V compatible SPI EEPROMs for the foreseeable future.
Post Reply