Using Flash RAM to replace obsolete CMOS RAM

What sort of cycle times do you need?

Cheers

Phil Hobbs

Are you thinking that the CPU could intercept the read/write accesses to the "original device" and emulate them via its flash? Not likely.

Is it true NVRAM (e.g., MNOS devices) or BBSRAM?

That's actually 2K bits (512x4) or 2Mbits (256Kx8).

"Programming" *in* the module, you're not talking about butchering the code in the games...

You could make a "dead bug" module that plugs in place of the existing device. No CPU, just a bit of write-protect logic (to safeguard the contents as power fails). This is how we developed games (in the 70's) without having to constantly burn EPROMs. (we called them "pigs" as in "piggyback" -- as you'd stack two 2Kx8 devices and some logic to emulate a 4KB EPROM)

We didn't worry about spanning power outages so you would have to add a coin cell to maintain the device's contents.

These boards all run pretty much under 5mhz, most are <1mhz. Access times are typically around 100ns with older (mid-late 70s - 5101 for example) parts around 250ns.

John :-#)#

Alliance still has some 256k, 512, 1Mbit 70ns srams available in DIP for like $3.50 - $5:

It is not "Flash RAM"! It is "NOR Flash". You can use that to store firmware or read-only data, you cannot write and read single bytes like in a normal RAM but only large blocks of data can be erased and then re-programmed much like an EEPROM.

Thanks for pointing that out.

That type of part is useless for my needs then.

Oh well, back to the drawing board!

John :-#(#

No, you use RAM (in the MCU) to cache data from the FLASH, reading *and* writing. You then move *updated* data from the cache back into FLASH to give you the non-volatility.

This lets you live with the page updates imposed by the FLASH as well as adapt to its limited durability (R/W cycles).

Easy peasey.

The problem is that you can't easily have the MCU respond to activity at the rate that the "host" CPU undertakes (you can't "wait state" the host CPU because NVRAMs don't have "wait" signals -- unless you are emulating FLASH! :> )

apologies for the second post; nntp client returned fail on first!

If you need a RAM with non-volatile storage without a keep-alive battery, have a look at ferroelectric RAMs. They are not as complicated to write as the Flash memories.

Those FRAM or MRAM are getting pricey (over $7USD) and availability appears to be a problem. So I was looking for an alternative that didn't use batteries...

John :-#)#

They never really got beyond a few niche uses.

I worked on HP's version of MRAM, back in the late 90s. Their USP was that it used tunnelling magnetoresistance rather than giant magnetoresistance (as used in HDD heads etc). It was still at the experimental stage when the IP was sold to Micron, I never heard any more of it after that.

At the time it was predicted to completely displace Flash from the market due to its fast cycle time (similar to DRAM) and no wearout mechanism. The biggest problem we saw with the prototypes was the sensitivity to external mag fields, that might have been what killed the idea.

I still have one of the prototype chips somewhere, on a fancy wooden plaque. Fun times.

People have used FERAM to replace Dallas battery backed RAMs in Tektronix 24x5B scopes.

IIRC you have to be careful about the relative timing of two signals, especially during power down.

You may have a look at the FRAM as used in MSP430 chips. They use magnetic memory like the core memory of old, and are just permanent. They are on chip in the TI chips. Dunno whether you can purchase the memory separately. Maybe the control is complicated such that total integration is the only wat.

Groetjes Albert

My magram friends at IBM used to worry about density, because below a certain cell size everything turns paramagnetic.

Cheers

Phil Hobbs

For the lower memory requirments (32KB) I think a high frequency microcontroller (400MHz+) could intercept accesses and serve from its RAM, writing the RAM to flash when it detects loss of power.

Synchronizing signals could be iffy unless the microcontroller clock can be synchronized to the original hardware clock.

Such microcontrollers don't come cheap though.

Sylvia.

One approach might be to use normal static RAM with a small uC attached and sufficient capacitance to keep the uC running long enough to copy the RAM contents to flash, maybe in the uC itself, maybe not. On power up the uC would refill the RAM. You'd probably need to MUX the RAM I/O.

This could be transparent to the host. You might need to delay the host's power on reset.

I think he already has circuitry for CMOS RAM so unless it is one of those devices with built-in battery, the whole backup thing is already on the circuit board and he only needs to emulate the RAM.

When the unreasonable price is only because of a rarely used package (DIP-28?) it could be considered to use an SMD-to-DIP adapter PCB.

SMD devices are already being used - they are soldered to a sub-board which then does the DIP requirements as needed.

John :-#)#