Using Flash RAM to replace obsolete CMOS RAM

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