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.&nbsp; On power
>>> up the uC would refill the RAM.&nbsp; You'd probably need to MUX the RAM I/O.
>>>
>>> This could be transparent to the host.&nbsp; 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).&nbsp; 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.&nbsp; There's lots of development cost and labor cost
> in making arcade pieces.&nbsp; 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.&nbsp; [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!]&nbsp; 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).&nbsp; 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.&nbsp; 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.&nbsp; If you use a FLASH device, you
> can tolerate a low number of write cycles by simply only updating the
> FLASH on power fail.&nbsp; 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 :-#)#

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

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

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

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

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

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

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