On 6/30/2021 9:03 PM, Sylvia Else wrote:
> 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.

In some designs, it was common for the bus cycle to be closely related
to the CPU clock (e.g., the Moto family 8b processors). But, you're still
forced to work with the bus control signals (RD/WR/CS/OE) and not the
clock, directly. Recovering the clock from them -- without knowing exactly
how the site is pinned -- would add another cost.

E.g., if RD is gated by CS, you may only see the signal rarely. OTOH, if
it isn't gated, you will see it on damn near every bus cycle, even if
not targeting that site.

I think an FPGA would be an easier solution.

> Such microcontrollers don't come cheap though.

That's the problem; you're fighting a cost and performance constraint that
you really can't put a handle on (at least the OP hasn't canvased ALL of
the potential applications and summarized their requirements, here).

CPUs *seem* like they are fast -- until you actually start counting
clock cycles required to implement a particular sequence of opcodes.

And, there's no way you can "request" a couple more (unlike the 647180
design I mentioned)

On 29/06/2021 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.
>
> John ;-#)#

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.

--
Cheers
Clive

Clive Arthur <clive@nowaytoday.co.uk> wrote:
> On 29/06/2021 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.
>>
>> John ;-#)#
>
> 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.

On 7/1/2021 4:30 AM, Rob wrote:
> Clive Arthur <clive@nowaytoday.co.uk> wrote:
>> On 29/06/2021 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.
>>>
>>> John ;-#)#
>>
>> 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.

Devices of that era did not use "fancy" NVRAM *modules* (with built-in
battery). Instead, the nonvolatile aspect was provided by additional
circuitry on the board -- a backup power source, diode switch to allow
Vcc to override that, and some gating circuitry on CS that was also
powered from the backup power (often just a transistor used as a switch
because it used less power than a gate).

[Cost is a key issue. There's lots of development cost and labor cost
in making arcade pieces. And, the *normal* market window for a particular
"model" can be as short as 90 days!]

Often, the designer relied on entropy instead of adding additional circuitry
to truly "safely" protect the device's contents (i.e., assume it won't be
accessed often; assume power cycles are infrequent; assume the chance of
a particular write cycle being cut short are effectively zero; use independent
checksums on the different parts (uses) of the device so you can maximize
your chance of recovering useful data in the event Murphy strikes.

Common RAMs used would be 256x4 (5101), 2Kx8 devices (2016), 8Kx8 devices
(6264, 2064), 32Kx8 devices (62256) -- even if used in 8Kx8 (or smaller)
sites, etc. [there was a time when moto sold 32Kbit DRAMs -- 64Kbit
devices that had a faulty cell in one half of the device (or the other);
if we couldn't otherwise get 16Kb devices -- and didn't want to pay for
a REAL 64Kb device -- the 32Kb orphan was a great option!] They'd be
chosen for low standby current but what-it-was-is-what-it-is!

If the OP is seeing demand for a "replacement module", it is likely
indicative that some aspect of the backup circuitry is failing (these
machines are 30-40 years old, now). Batteries.

The current user will likely be some Jamoke who bought a machine for his
basement/garage/game room and has the technical aptitude of a bowl of
petunias. You wouldn't trust him patching a board, unsoldering devices,
etc.

But, replacing a SOCKETED component is something he can be taught
to do -- CAREFULLY ("buyer assumes all risks").

So, you want to sell him a device that is truly nonvolatile and
doesn't require "maintenance" on his part (replacing batteries).
And, you don't want him to be able to make a bad decision in any
of that maintenance (e.g., buying the wrong battery chemistry,
inserting a battery BACKWARDS, etc.)

A 2021 design can leverage the reduced standby currents of more
modern devices to extend the service interval between battery
changes.

Or, as the OP hopes, rely on a different technology, altogether,
to provide that data persistence.

BUT, whatever you do has to LOOK like a CMOS RAM of that era,
physically and electrically. If you use a FLASH device, you
can tolerate a low number of write cycles by simply only updating the
FLASH on power fail. 10,000+ power cycles takes a really long time!

You just need a way of making it LOOK like a RAM, "most of the time".

On 2021/07/01 4:30 a.m., Rob wrote:
> Clive Arthur <clive@nowaytoday.co.uk> wrote:
>> On 29/06/2021 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.
>>>
>>> John ;-#)#
>>
>> 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 :-#)#

On 2021/07/01 5:33 a.m., Don Y wrote:
> On 7/1/2021 4:30 AM, Rob wrote:
>> Clive Arthur <clive@nowaytoday.co.uk> wrote:
>>> On 29/06/2021 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.
>>>>
>>>> John ;-#)#
>>>
>>> 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.
>
> Devices of that era did not use "fancy" NVRAM *modules* (with built-in
> battery).  Instead, the nonvolatile aspect was provided by additional
> circuitry on the board -- a backup power source, diode switch to allow
> Vcc to override that, and some gating circuitry on CS that was also
> powered from the backup power (often just a transistor used as a switch
> because it used less power than a gate).
>
> [Cost is a key issue.  There's lots of development cost and labor cost
> in making arcade pieces.  And, the *normal* market window for a particular
> "model" can be as short as 90 days!]
>
> Often, the designer relied on entropy instead of adding additional
> circuitry
> to truly "safely" protect the device's contents (i.e., assume it won't be
> accessed often; assume power cycles are infrequent; assume the chance of
> a particular write cycle being cut short are effectively zero; use
> independent
> checksums on the different parts (uses) of the device so you can maximize
> your chance of recovering useful data in the event Murphy strikes.
>
> Common RAMs used would be 256x4 (5101), 2Kx8 devices (2016), 8Kx8 devices
> (6264, 2064), 32Kx8 devices (62256) -- even if used in 8Kx8 (or smaller)
> sites, etc.  [there was a time when moto sold 32Kbit DRAMs -- 64Kbit
> devices that had a faulty cell in one half of the device (or the other);
> if we couldn't otherwise get 16Kb devices -- and didn't want to pay for
> a REAL 64Kb device -- the 32Kb orphan was a great option!]  They'd be
> chosen for low standby current but what-it-was-is-what-it-is!
>
> If the OP is seeing demand for a "replacement module", it is likely
> indicative that some aspect of the backup circuitry is failing (these
> machines are 30-40 years old, now).  Batteries.
>
> The current user will likely be some Jamoke who bought a machine for his
> basement/garage/game room and has the technical aptitude of a bowl of
> petunias.  You wouldn't trust him patching a board, unsoldering devices,
> etc.
>
> But, replacing a SOCKETED component is something he can be taught
> to do -- CAREFULLY ("buyer assumes all risks").
>
> So, you want to sell him a device that is truly nonvolatile and
> doesn't require "maintenance" on his part (replacing batteries).
> And, you don't want him to be able to make a bad decision in any
> of that maintenance (e.g., buying the wrong battery chemistry,
> inserting a battery BACKWARDS, etc.)
>
> A 2021 design can leverage the reduced standby currents of more
> modern devices to extend the service interval between battery
> changes.
>
> Or, as the OP hopes, rely on a different technology, altogether,
> to provide that data persistence.
>
> BUT, whatever you do has to LOOK like a CMOS RAM of that era,
> physically and electrically.  If you use a FLASH device, you
> can tolerate a low number of write cycles by simply only updating the
> FLASH on power fail.  10,000+ power cycles takes a really long time!
>
> You just need a way of making it LOOK like a RAM, "most of the time".

Hi Clive,

Nice to hear from you!

Yes, looking like a RAM only when needed is the goal. There have been
some interesting suggestions to explore, plus the folks who said why
other directions are mostly pointless is also appreciated.

John :-#)#