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.

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

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

What sort of cycle times do you need?

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 6/29/2021 10:19 AM, 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.

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

> This has come up because the NVRAM that is currently being used is getting hard
> to find at prices under $7 to $9USD.

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

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

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

> 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

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

> we can use batteries until the current shortage in NVRAM is over, but that
> isn't as much fun.

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.

> Also, we need to get past the doom & gloom crap I'm seeing here.

On 2021/06/29 10:22 a.m., Phil Hobbs wrote:
> 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.
>>
>
> What sort of cycle times do you need?
>
> Cheers
>
> Phil Hobbs
>

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 :-#)#

--
(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 1:19 PM, 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.
>
> John ;-#)#
>

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

<https://www.mouser.com/Alliance-Memory/Semiconductors/Memory-ICs/SRAM/_/N-4bzpt?P=1z0z63xZ1yzswq7&Ns=Pricing%7c0>

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.

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!

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

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! :> )

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.

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! :> )

On 6/29/2021 3:10 PM, Don Y wrote:

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

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

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

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

On 6/30/2021 1:44 AM, Rob wrote:
> 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.

Please reread his description of the problem and my description
(above) of how to implement that with flash.

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

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

The cache isolates the implementation from the need to do byte
accesses to the flash. "Updates" (made by the host *CPU* -- not
MCU) are transferred by the modules *MCU* from that cache into
the flash while the module is still acting as a RAM.

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

There's nothing to stop you from doing exactly that -- in a plug-in
*module* (with it's own MCU, as was indicated in the OP). "When
it is time to do so" can be determined by watching Vcc falling
(it's not hard to get an MCU and FLASH that will continue to
operate at 3.3V -- while the system that is hosting it will
crap out once Vcc falls below ~4.5V)

The downside is the cycle time of the *MCU* wrt the cycle time
of the *CPU* to which it is (surreptitiously) interfacing. The
MCU needs to recognize an access (by the CPU) to it's contents
and then fetch (or store) the associated data -- all before
the next *CPU* bus cycle (which could, potentially, access
a location emulated by the MCU as well!

Busses tended to run at ~1-2MHz in those sorts of pieces.
And, often were "shared" with some other "processor/sequencer"
(e.g., CPU gets access on one half of the cycle while video
controller has access on other half -- because the frame buffer
resided *in* the CPU's memory space).

So, you have a ~250-500ns budget and a 500ns-1000ns cycle time.
Worst case, you're handling a two-byte access (reads/writes
to two successive addresses for 16b datum) in two successive
bus cycles (without the "breathing room" of an intervening
opcode fetch cycle)

I used a 647180 many years ago as a "smart peripheral" on a
32016 system; it provided a UART by which diagnostic information
could be exchanged, an idiot indicator to signal system health
to the user, some smart sequencing to control the main CPU's
reset as well as allowing the field to be reset (and held so)
until the main CPU was *known* to be functional and a "smart"
watchdog that could challenge the CPU at any time and, if
unsatisfied with the reply, bring the system to a safe state
(you don't want 10HP motors running and thousands of pounds of
steel in motion without "supervision"!)

To do so, the address decoding logic would deliberately "stall"
any access directed to the '7180 -- giving it time to read the
CPU's address signals imposed on it's DIOs, decode the intended
operation and then signal the address decoder to resume the
bus cycle.

This allowed the boot ROM for the main CPU to be implemented
inside the onboard EPROM of the '7180. Access was slow but
this only happens at IPL and, once that code transferred itself
to system RAM, things could run at full (bus) speed. Thereafter,
only deliberate access to the peripheral feaatures implemented
in the '7180 would incur that cost.

[It also allowed me to "spoon feed" memory contents to the
'7180 and, thus, the main CPU -- by transmitting the
address the CPU had impressed on the '7180's DIOs out via
the UART for "emulation" outside the system (e.g., a PC
could emulate the ROM inside the '7180). So, you could
execute arbitrary diagnostics on a live system, without
having to directly access the (validated) codebase]

But, most arcade pieces used processors with fixed bus timings.
Any that supported the dynamic introduction of wait states
would do so via the address decoding logic (i.e., when THIS
address range is accessed, add a wait state). The "WAIT"
signal (e.g., DTACK) wouldn't be available at the pins of
the "memory device". So, a drop-in replacement would have
to live with the timing imposed by the system for that
particular "component site".

Unless you drop in a replacement (daughter card) for the CPU
carrying your "emulator" and intercept those accesses ON the
daughter card.

> This behavior would then be implemented in software, rather than in
> a hardware emulation.

On 6/29/2021 10:58 PM, John Robertson wrote:

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

Ah! YOU aren't doing the retrofits but are targeting "John Does" who will
do it for their own arcade pieces! That's a different nut to crack (cuz
those folks will be pissed if your solution breaks their piece (even if
it does so because of the user's ineptitude!)

It also means you have to leverage any "connection points" that might have
been present in the initial build -- e.g., socketed components (unless you
are replacing entire boards). AND, do so in a way that the original
"connector" might not have intended (e.g., gas-tight sockets and machined
pin sockets have different wear capabilities than "real" connectors)

> It has to be simple enough that folks who know next to nothing about
> electronics can replace the CMOS RAM with this device.

So, I suggest you rethink their motivation for doing so.

NVRAM typically held settings and high score tables.

Most software will install a default set of settings if the stored
settings appear corrupt. So, the hassle of having to walk through
all of those isn't a real detriment (unless you've customized
YOUR settings -- the very least being "free play"). And, it's
a one-time event (until the next NVRAM failure).

The bigger issue is the high score table as vanity plays a
role, there. It takes a long time to "reset" a previous high
score -- you actually have to play the game and ACHIEVE that
score in order to effectively enter it into the NVRAM.

Now, hear me out...

High scores aren't *written* to NVRAM often. (Nor are configuration
changes!). So, imagine you could initialize that RAM with "stored
values" and let it handle the "real-time" transactions with the
host CPU. I.e., reads go directly to the RAM as do writes. The
MCU only gets involved at power-up (at which point it has to copy it's
nonvolatile/flash based "stored values" into the RAM chip before
the RAM chip is accessed) and at power down (when it would have to
capture any *changed* values in the RAM back into its nonvolatile
store).

I'm assuming the NVRAMs you are encountering have just lost
their "nonvolatility" characteristic. I.e., "defaults" that
are restored to them persist during normal operation.
Changes made to their contents (high scores, settings)
are retained -- AS LONG AS POWER ISN'T CYCLED.

I.e., you already HAVE a working "RAM chip". No need to
REPLACE it with another!

So, (assuming the NVRAM is socketed on the main board),
have the user pull the NVRAM from the main board to
make that socket site available for your daughter card.
But, instead of discarding the "defective" NVRAM, the
user plugs it into a socket on the daughter card.

[This may be a false economy -- it may be cheaper to
buy a replacement device soldered down on your daughter
card and discard the original device; I leave it to you
to sort out the costs/risks of each approach]

Now, you need to be able to isolate the RAM chip from the
main CPU's bus for brief period at power-up and power-down.
You essentially want a dual-ported RAM but don't want
to pay for that capability as you're not using it heavily.

The simplest way of doing this would be to hold the main
CPU in RESET while you jam your MCU's signals onto the
RAM's pins. A flying lead could suffice. But, there's
no guarantee that the bus isn't buffered outside the CPU
and RESET won't be guaranteed to tristate those buffers.

You could add another set of buffers on the daughter
card that your MCU controls -- and let the MCU tristate
it's outputs when it has enabled those "pass thru" buffers..
The buffers add some propagation delay. But, you can replace
the "slow" NVRAM with a faster SRAM to easily reclaim that
lost time. (and, as you no longer need to select the
RAM for low standby current -- as you would in a BBSRAM
solution -- you can opt for performance instead of power
efficiency)

You're still hard-pressed to beet the $7 price you mentioned.
And, still have some timing issues to ensure the RAM is
"ready" before it's first access (you have some time as
the CPU won't typically be looking for its parameters
until after POST).

A "many pin" FPGA might be a better solution as the MCU
is really just acting as a simple sequencer in this approach.

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

You can't put a CR2032 in a holder and let the user just slip a new
coin in place of the old?

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

Put an idiot light on your board that says "battery has failed, replace
battery before calling for service!"

> Silly me, I like stuff to keep running!

One reason my pintables are EM models. (actually, the nostalgia aspect
is the bigger draw -- there's nothing like the sound of a score motor
and the hope/worry that it will fail to stop at the end of its intended cycle:
"Woohoo! 37,000 bonus!!" And, the periodic maintenance is almost
therapeutic!) Pinball machines shouldn't play music :(

In article <oJ6dndqjVsA1E0b9nZ2dnUU7-UmdnZ2d@giganews.com>,
John Robertson <spam@flippers.com> 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!

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.

>
>John :-#(#
>

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Rhydian wrote:
> 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".  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.
>

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

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 30-Jun-21 3:30 am, Don Y wrote:
> On 6/29/2021 10:19 AM, 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.
>
> Are you thinking that the CPU could intercept the read/write accesses to
> the
> "original device" and emulate them via its flash?  Not likely.
>

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.