It is currently Sat Nov 25, 2017 4:37 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Mon Jul 12, 2010 7:12 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 7:56 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 8:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7275
Location: Chexbres, VD, Switzerland
Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 8:47 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 10:39 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 12:10 pm 
Offline

Joined: Sat Feb 27, 2010 8:32 am
Posts: 115
Location: Maine
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 1:59 pm 
Offline

Joined: Sun Sep 19, 2004 11:07 pm
Posts: 154
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 4:08 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 5:33 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
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).


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 7:25 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 7:51 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10120
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 8:00 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1518
Location: Fukuoka, Japan
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 ;)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 12, 2010 8:09 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 22, 2010 11:22 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 22, 2010 7:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group