....After months of use and abuse, I can report that it actually works without issue, but requires glue logic.
Okay, let's back up a second, what am I talking about?
No doubt the backup battery in some of your SNES cartridges have gone dead, not allowing your saves to last beyond power off, or, in some cases, the game refuses to run at all.
Obviously encountering this myself, I thought to look up any sort of nonvolatile memory that acts somewhat like the SRAM chips (probably in about 2004). I gave up the first time because I realized the 5V FeRAM series of chips could never be a drop-in replacement because of the need to strobe the Chip Select signal. So I kind of gave up then and there...
Earlier this year, I renewed my interest in the SNES console and in making some sort of programmable cartridge for my own use. At this point I had a deep hatred for coin cell batteries. So I figured, what the hell, go for it, and use the Ramtron FM1808 32KB chip.
The trick is that since the memory performs destructive read and writeback, it needs a more organized bus access than purely asynchronous like SRAM does. The falling edge of Chip Select latches the address, and then either a read or write can be performed. Or, you can have it set up for a read or write, and then drop chip select (That second way is what ends up working for me on my board).
Attached in the next post is a simplified schematic of a 8 meg flash chip, the F-RAM, and a functional logic gate configuration set up for LoROM. I don't actually have those switches, but I guess I'm drawing it this way to show conceptually how to map to the different sizes of battery RAM.
With some buffering after the CE signal, I connected an access light LED, and in some cases an audible logic probe. Playing different games, I noticed that they are in general very well behaved about accessing the battery RAM (Again, the fear was that it would be reading constantly from the battery RAM, and wear it out like nothing).
Some specifics:
F-Zero just generally reads everything at the beginning, and doesn't touch it unless you place in the rankings in time trial mode, and it's a tiny little write.
Zelda LTTP is kind of weird, in that on the title and file select screen, it keeps reading from the memory, but in short bursts with plenty of time in-between. Once the actual game gets going it does something even more interesting: every time your character's name is mentioned, it reads it directly from the save ram. It's funny how they were either lazy or went to the trouble to save a few bytes of system ram.
SimCity works just like you'd expect. Nothing goes on at all, except a little check at the beginning, and activity only when SAVE or LOAD is selected. Or with the "fax" when you win a scenario which is understandable.
Final Fight Guy HATES having any sort of save-ram in the memory map. I'm almost halfway interested in what it is actually writing to the chip. Are there any other smallish sized games that care about the RAM being in the memory map? I haven't come across many others.
I just really like the concept of having the game save act normally, and having it accident proof. What I'm saying is that I don't like the concept of trying to constantly dump to SD or CF Card either.
My other question is, is if anyone knows if there are any non-special chip commercial game releases (not translation patches) that treat the battery RAM area as a scratchpad memory, that as a result is constantly being changed? I can't see use like that being much of an advantage, so it's probably rare.
Anyways, I can probably put up some grainy pictures of my rat's-nest SD programmable cart in a day or two.
I remember seeing Sekien Densetsu 3 triggering the "Sram Check and Save" feature of ZSNES in various places while the game was running, and that was when I wasn't saving the game. I mainly noticed it when you played the flute to ride on the turtle.
whicker wrote:
Zelda LTTP is kind of weird, in that on the title and file select screen, it keeps reading from the memory, but in short bursts with plenty of time in-between. Once the actual game gets going it does something even more interesting: every time your character's name is mentioned, it reads it directly from the save ram. It's funny how they were either lazy or went to the trouble to save a few bytes of system ram.
One fellow's laziness is another's efficiency. OLD MAN from Pokemon anyone?
Quote:
Final Fight Guy HATES having any sort of save-ram in the memory map.
Copy protection perhaps?
Quote:
Are there any other smallish sized games that care about the RAM being in the memory map?
Low G Man is the canonical example for NES, but I can't think of any on Super NES.
Quote:
My other question is, is if anyone knows if there are any non-special chip commercial game releases (not translation patches) that treat the battery RAM area as a scratchpad memory, that as a result is constantly being changed?
I'd like to see you try Mario Paint.
Quote:
One fellow's laziness is another's efficiency. OLD MAN from Pokemon anyone?
Can you explain what you mean by this?
In Pokemon, there's a place early in the game where an old man teaches you how to catch pokemon using pokeballs.
The game copies your name to an area in memory used for storing which pokemon appear, then temporarily changes your name to OLD MAN to run the cutscene. Then it restores your name.
Normally, the area in memory for storing which pokemon appear is replaced as soon as you stop on grass. However, there are some places where it is possible to get into fights without that data getting replaced. So suddenly, you get into fights with glitch pokemon that don't exist, like MissingNo.
Ah I see, I knew about the missingno thing just didnt know about the old man part. Cool to know
So FeRAM has a finite number of writes or both reads and writes since reads destroy the data held and it must be rewritten? How many reads/writes is the expected life time on them? It's a shame there is a limit at all. That's always bothered me about Flash memory too.
FRAM has between around 10^10 and 10^16 write-erase cycles, flash is somewhere between 10^4 - 10^7
yeah, I mean, unless you sit in a tight loop reading or writing the same location over and over again, it's really hard to hit that kind of a limit, but that's what I'm searching for.
With the assumption of 10^12 reads of a given byte, 60 times a second, it'll take 528 years to fail.
If you read a solitary byte a half a million times a second, it'll take 23 days.
Mario Paint results:
Scan for checksum when it first comes out of reset, just before the title screen appears, like any other Nintendo developed game I've seen.
Reads the battery RAM as the main canvas appears. Don't know why. It's not like it saves the mouse speed.
When spinning through the palette on top: whenever it encounters the user-made stamps it reads from the battery RAM. Can repeatedly left and right click and it will keep doing it.
Subscreens like the music editor, the animation editor, the path editor, don't do anything with battery RAM, neither does Flyswatter.
The "special stamp" editor screen only does something when either SAVE or LOAD is selected the first time, and then obviously does the read or write when clicking on the user-made stamps in the palette.
Undo does not cause an access. Even if it's a severe undo like reverting a flood-fill.
And here's again something interesting: It's that fricken creepy robot screen. For SAVE it doesn't do anything with battery RAM until after the countdown has been sitting on 12. Basically, it only writes in one big burst from 11 down to 0. And that is the very fast part.
When you click on the Start button in LOAD, it's immediately grabs the data from battery RAM, as the sound effect is playing, then counts down.
There's got to be some sort of Work-RAM to PPU character and color palette memory translation going on chewing up all of those cycles.
Reading the ram doesn't make it fail, it's the write/erase that causes problems.
I don't think anyone would update saves in a tight loop, would be a bit costly if you want some kind of error protection... however someone could have used it as extended ram (much like the gba-port ram on nintendo ds) but i don't see why to worry about that
btw I just read the
datasheet for FM18L08, don't think it's any good for your application (256Kbit, ~3.3V) but "Unlimited Read/Write Cycles" sounds nice even thou it has only "45 year Data Retention"
whicker wrote:
Subscreens like the music editor, the animation editor, the path editor, don't do anything with battery RAM, neither does Flyswatter.
I was concerned about what appears to be a copy of the toolbar tiles in the SRAM file. What happens if you repeatedly toggle the toolbar?
Quote:
Undo does not cause an access. Even if it's a severe undo like reverting a flood-fill.
That's because the canvas and the undo buffer are both stored in internal RAM in their entirety.
Quote:
And here's again something interesting: It's that fricken creepy robot screen. For SAVE it doesn't do anything with battery RAM until after the countdown has been sitting on 12. Basically, it only writes in one big burst from 11 down to 0. And that is the very fast part.
I think it's actually doing tile compression. Two 256x176x4-bit buffers (ordinary canvas and animation canvas) take 44 KiB put together, bigger than the game's SRAM.
hyarion wrote:
Reading the ram doesn't make it fail, it's the write/erase that causes problems.
... however someone could have used it as extended ram (much like the gba-port ram on nintendo ds) but i don't see why to worry about that
btw I just read the
datasheet for FM18L08, don't think it's any good for your application (256Kbit, ~3.3V) but "Unlimited Read/Write Cycles" sounds nice even thou it has only "45 year Data Retention"
The flavor of FeRAM I'm using has destructive read, which isn't unheard of. Magnetic donut core memory did the same kind of thing.
I was more or less worried about seeing if any game did use it as extended RAM.
Like you say, newer chips are better, and with the higher endurance number for virtually all practical uses will allow them to claim "unlimited", but unfortunately are 3.3 volts. I was using the FM1808, no L, which is a 5 volt part. It was the size and the 5 volts that made it a good fit. The datasheet for the FM1808-70-PG talks about the need for CE strobing.
tepples wrote:
I was concerned about what appears to be a copy of the toolbar tiles in the SRAM file. What happens if you repeatedly toggle the toolbar?
Nothing. but I notice a delay in the toolbar appearing when coming back from the stamp editor about equal to the save RAM access it does. But then if I disable the chip, there's no graphical corruption other than the special stamps when I draw on the canvas.