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.

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.

_________________Life is complex: it has both real and imaginary components.

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.

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.

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.

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.

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).

A 29F010 or 29F040 might work. The program would occupy half of the eight sectors, and the rest would rotate among these functions:

User data

More user data

Revisions to user data, as they are written

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.

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?

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.

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).

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.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum