Forums

Using Flash RAM to replace obsolete CMOS RAM

Started by John Robertson June 29, 2021
In article <sbg5kb$o1v$1@dont-email.me>,
Don Y  <blockedofcourse@foo.invalid> wrote:

>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! :> )
This might be a place where a dual-core processor could be of use. Dedicate one to watching the bus pins and responding to reads and writes (using the memory buffer), and use another to periodically flush the synchronized data out to the flash. You _might_ be able to get this running fast enough, depending on the speeds of the various CPUs and the memory bus. Using an A/B scheme on the flash would be beneficial. Never overwrite your "known good" copy of the data - instead, write an updated data set to a second bank, then rewrite a single flag area so that the next boot gets the new copy.
On 6/29/2021 3:21 PM, Dave Platt wrote:
> In article <sbg5kb$o1v$1@dont-email.me>, > Don Y <blockedofcourse@foo.invalid> wrote: > >> 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! :> ) > > This might be a place where a dual-core processor could be of use. > Dedicate one to watching the bus pins and responding to reads and > writes (using the memory buffer), and use another to periodically > flush the synchronized data out to the flash. You _might_ be able to > get this running fast enough, depending on the speeds of the various > CPUs and the memory bus.
Read cycles would be the limiting factor. There, your "module" would have to SENSE the start of a cycle, capture the address desired and deliver the associated data -- within the "read access time" of the NVRAM being replaced/emulated. For write cycles, you have a full *bus* cycle time (until the next read/write cycle can begin) -- but, have access to the data *later* in the cycle. One possible redeeming approach would be if your accesses ALL could fit on a single page in the flash; just defer the actual "write" until some later point in time (ideally, just as you sense power fading -- so, you only consume one write cycle per power cycle, extending the life of the flash). Given that modern technologies tend to consume less power than their ancestors, you might be able to do this as Vcc is falling...
> Using an A/B scheme on the flash would be beneficial. Never overwrite > your "known good" copy of the data - instead, write an updated data > set to a second bank, then rewrite a single flag area so that the next > boot gets the new copy.
You're still stuck with a reduced number of write cycles. FLASH works best if you cache the contents in "system memory" and only do the write-back to the actual device "when you must" (i.e., just before shutting down). And, you're fighting a "couple of dollars" as your total budget. Doesn't seem like a winning proposition! BBSRAM is the way to go... and "hope" for long enough retention.
On 2021/06/29 3:37 p.m., Don Y wrote:
> On 6/29/2021 3:21 PM, Dave Platt wrote: >> In article <sbg5kb$o1v$1@dont-email.me>, >> Don Y&nbsp; <blockedofcourse@foo.invalid> wrote: >> >>> No, you use RAM (in the MCU) to cache data from the FLASH, >>> reading *and* writing.&nbsp; 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!&nbsp; :> ) >> >> This might be a place where a dual-core processor could be of use. >> Dedicate one to watching the bus pins and responding to reads and >> writes (using the memory buffer), and use another to periodically >> flush the synchronized data out to the flash.&nbsp; You _might_ be able to >> get this running fast enough, depending on the speeds of the various >> CPUs and the memory bus. > > Read cycles would be the limiting factor.&nbsp; There, your "module" > would have to SENSE the start of a cycle, capture the address desired > and deliver the associated data -- within the "read access time" > of the NVRAM being replaced/emulated. > > For write cycles, you have a full *bus* cycle time (until the next > read/write cycle can begin) -- but, have access to the data *later* > in the cycle. > > One possible redeeming approach would be if your accesses ALL > could fit on a single page in the flash; just defer the actual > "write" until some later point in time (ideally, just as you > sense power fading -- so, you only consume one write cycle > per power cycle, extending the life of the flash).&nbsp; Given that modern > technologies tend to consume less power than their ancestors, > you might be able to do this as Vcc is falling... > >> Using an A/B scheme on the flash would be beneficial.&nbsp; Never overwrite >> your "known good" copy of the data - instead, write an updated data >> set to a second bank, then rewrite a single flag area so that the next >> boot gets the new copy. > > You're still stuck with a reduced number of write cycles. > > FLASH works best if you cache the contents in "system memory" > and only do the write-back to the actual device "when you must" > (i.e., just before shutting down). > > And, you're fighting a "couple of dollars" as your total > budget.&nbsp; Doesn't seem like a winning proposition!&nbsp; BBSRAM > is the way to go... and "hope" for long enough retention.
Perhaps I should look around at other MRAM - https://www.everspin.com/parallel-interface-mram Assuming there is stock anywhere that is. John :-#)# -- (Please post followups or tech inquiries to the USENET newsgroup) John's Jukes Ltd. MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 (604)872-5757 (Pinballs, Jukes, Video Games) www.flippers.com "Old pinballers never die, they just flip out."
On 6/29/2021 4:41 PM, John Robertson wrote:
>> And, you're fighting a "couple of dollars" as your total >> budget. Doesn't seem like a winning proposition! BBSRAM >> is the way to go... and "hope" for long enough retention. > > Perhaps I should look around at other MRAM - > > https://www.everspin.com/parallel-interface-mram > > Assuming there is stock anywhere that is.
I don't know the *specifics* of your present need... But, IIRC, past comments suggest that you are often faced with "bandaging" some old bit of kit (pintables AND videos?). *I* would look at the sorts of issues that have bit you in the past (cuz they will still be biting you if you continue to "support" those pieces) and try to guess what *similar* problems might bite you going forward. E.g., you're likely not going to have problems finding *substitutes* for hammer drivers (e.g., solenoids on pintables). But, you might have problems with some of the more esoteric devices (e.g., the CVSDs used on Williams sound boards?). *If* you can see some common thread in all of this, you might consider making a small daughter card with the intent of mounting it in place of the CPU (main CPU, sound CPU, etc.). Add a small FPGA so you can redirect any address decoding away from offboard resources (like the NVRAM) and route it, instead, to some "functionally compatible" -- but entirely *different* component -- residing on the daughter card. Yeah, you may have to make different "CPU flavors" of that card (e.g, 6809, Z80, etc. depending on which game vendor you're dealing with) but that's probably a small chore given that every "module" will be functionally equivalent. [E.g., for a Z80-based game, a resource may reside in I/O space while on a 68K it sits "somewhere" in the normal address space -- hence the appeal of the FPGA as a "programmable interconnect"; it can sit on different signals on a 68K daughter card than it does on a 6809!] This isn't going to save you any money over the original implementation. But, would allow you to leverage existing board sets instead of having to recreate each (no idea of the quantities you are addressing).
On 2021/06/29 5:50 p.m., Don Y wrote:
> On 6/29/2021 4:41 PM, John Robertson wrote: >>> And, you're fighting a "couple of dollars" as your total >>> budget.&nbsp; Doesn't seem like a winning proposition!&nbsp; BBSRAM >>> is the way to go... and "hope" for long enough retention. >> >> Perhaps I should look around at other MRAM - >> >> https://www.everspin.com/parallel-interface-mram >> >> Assuming there is stock anywhere that is. > > I don't know the *specifics* of your present need... > But, IIRC, past comments suggest that you are often faced > with "bandaging" some old bit of kit (pintables AND > videos?). > > *I* would look at the sorts of issues that have bit you > in the past (cuz they will still be biting you if you > continue to "support" those pieces) and try to guess > what *similar* problems might bite you going forward. > > E.g., you're likely not going to have problems finding > *substitutes* for hammer drivers (e.g., solenoids on pintables). > But, you might have problems with some of the more esoteric devices > (e.g., the CVSDs used on Williams sound boards?). > > *If* you can see some common thread in all of this, you might > consider making a small daughter card with the intent of > mounting it in place of the CPU (main CPU, sound CPU, etc.). > Add a small FPGA so you can redirect any address decoding > away from offboard resources (like the NVRAM) and route > it, instead, to some "functionally compatible" -- but entirely > *different* component -- residing on the daughter card. > > Yeah, you may have to make different "CPU flavors" of that card > (e.g, 6809, Z80, etc. depending on which game vendor you're > dealing with) but that's probably a small chore given that > every "module" will be functionally equivalent. > > [E.g., for a Z80-based game, a resource may reside in I/O > space while on a 68K it sits "somewhere" in the normal address > space -- hence the appeal of the FPGA as a "programmable > interconnect"; it can sit on different signals on a 68K > daughter card than it does on a 6809!] > > This isn't going to save you any money over the original > implementation.&nbsp; But, would allow you to leverage existing board > sets instead of having to recreate each (no idea of the quantities > you are addressing).
I have some 'get-well' sub-boards in mind for a few games. One we (a friend and I) are working on is a FPGA sub-board replacement for three 6530s used in one pinball brand back in the mid 70s. There seem to be thousands of these games left so well worth the investment in time. Have a second one for a Z-80 based pinball game that is pretty simple, a GAL, some NVRAM, and a fat EPROM will take care of all the boards used in this manufacturers time (1976 to 1985ish). As for the NVRAM/MRAM/FRAM/BBRAM, I'm trying to have something that is plug-in compatible, and costs less than $25USD while still allowing for a small profit. It has to be simple enough that folks who know next to nothing about electronics can replace the CMOS RAM with this device. For a while the Cypress FRAM chips were cheap and so the replacements for these CMOS RAM were likewise easily affordable, but as the price inches up it reaches a point where people will go to batteries and that just leaks to board destruction when folks forget to replace the batteries. Or service calls - again, who needs these? A simple device that eliminates any battery is far preferable to coin or other lithium battery devices. Every one of these I've seen over the past years all fail leading to frustrated customers paying for service that was preventable. Silly me, I like stuff to keep running! John ;-#)# -- (Please post followups or tech inquiries to the USENET newsgroup) John's Jukes Ltd. MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 (604)872-5757 (Pinballs, Jukes, Video Games) www.flippers.com "Old pinballers never die, they just flip out."
On 30.6.21 0.20, John Robertson wrote:
> On 2021/06/29 12:29 p.m., Rob wrote: >> John Robertson <spam@flippers.com> wrote: >>> I have a project in mind using small Flash RAM and a cheap CPU to >>> substitute for the old TTL level CMOS RAM used on arcade games. >>> >>> This has come up because the NVRAM that is currently being used is >>> getting hard to find at prices under $7 to $9USD. >>> >>> Something like the M25P05-AVMN6P (512k or 64K x 8) or similar chips are >>> $0.20 in single quantities. >> >> It is not "Flash RAM"! >> It is "NOR Flash".&nbsp; 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 :-#(#
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. -- -TV
On 2021/06/29 11:47 p.m., Tauno Voipio wrote:
> On 30.6.21 0.20, John Robertson wrote: >> On 2021/06/29 12:29 p.m., Rob wrote: >>> John Robertson <spam@flippers.com> wrote: >>>> I have a project in mind using small Flash RAM and a cheap CPU to >>>> substitute for the old TTL level CMOS RAM used on arcade games. >>>> >>>> This has come up because the NVRAM that is currently being used is >>>> getting hard to find at prices under $7 to $9USD. >>>> >>>> Something like the M25P05-AVMN6P (512k or 64K x 8) or similar chips are >>>> $0.20 in single quantities. >>> >>> It is not "Flash RAM"! >>> It is "NOR Flash".&nbsp; 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 :-#(# > > > 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 :-#)# -- (Please post followups or tech inquiries to the USENET newsgroup) John's Jukes Ltd. MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 (604)872-5757 (Pinballs, Jukes, Video Games) www.flippers.com "Old pinballers never die, they just flip out."
On Wed, 30 Jun 2021 00:15:45 -0700, John Robertson wrote:

> On 2021/06/29 11:47 p.m., Tauno Voipio wrote: >> On 30.6.21 0.20, John Robertson wrote: >>> On 2021/06/29 12:29 p.m., Rob wrote: >>>> John Robertson <spam@flippers.com> wrote: >>>>> I have a project in mind using small Flash RAM and a cheap CPU to >>>>> substitute for the old TTL level CMOS RAM used on arcade games. >>>>> >>>>> This has come up because the NVRAM that is currently being used is >>>>> getting hard to find at prices under $7 to $9USD. >>>>> >>>>> Something like the M25P05-AVMN6P (512k or 64K x 8) or similar chips >>>>> are $0.20 in single quantities. >>>> >>>> It is not "Flash RAM"! >>>> It is "NOR Flash".&nbsp; 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 :-#(# >> >> >> 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.
On 29/06/21 18:19, John Robertson wrote:
> I have a project in mind using small Flash RAM and a cheap CPU to substitute for > the old TTL level CMOS RAM used on arcade games. > > This has come up because the NVRAM that is currently being used is getting hard > to find at prices under $7 to $9USD. > > Something like the M25P05-AVMN6P (512k or 64K x 8) or similar chips are $0.20 in > single quantities. > > The size of CMOS RAM we are replacing ranges from 512 x 4 (yeah, 512 bits) up to > 256K x 8 (perhaps the AT25SF041B-SHB-T?). > > Granted this will take a bit of programming but I don't know if it is possible > to start with before I want to invest any time/money into this project. I mean > we can use batteries until the current shortage in NVRAM is over, but that isn't > as much fun. > > Also, we need to get past the doom & gloom crap I'm seeing here.
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.
Don Y <blockedofcourse@foo.invalid> wrote:
> On 6/29/2021 2:20 PM, John Robertson wrote: >> On 2021/06/29 12:29 p.m., Rob wrote: >>> John Robertson <spam@flippers.com> wrote: >>>> I have a project in mind using small Flash RAM and a cheap CPU to >>>> substitute for the old TTL level CMOS RAM used on arcade games. >>>> >>>> This has come up because the NVRAM that is currently being used is >>>> getting hard to find at prices under $7 to $9USD. >>>> >>>> Something like the M25P05-AVMN6P (512k or 64K x 8) or similar chips are >>>> $0.20 in single quantities. >>> >>> 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! > > 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.
His issue is that he would like to remove a non-volatile RAM chip (maybe one of those RAM-with-integrated-battery devices) from a working system and replace that with a circuit that replaces the working of that RAM chip with something emulated with Flash memory. That will not be easy as the system expects to see normal RAM, because Flash is not byte-writable (and NOR Flash is even worse than NAND Flash). Of course, when re-designing the whole system one would use volatile RAM and such a Flash chip alongside another, use the RAM to store the data at runtime and have the Flash as background storage where some part of the RAM is copied whenever the system knows that is time to do so (e.g. after some parameter change, or in an arcade game e.g. when the highscore table has been updated). This behavior would then be implemented in software, rather than in a hardware emulation.