I,Robot and the Xicor X2212 NVRAM

  I was having an odd problem with my I,Robot not saving high scores (or
anything to NVRAM, including the joystick calibration data) and I had
started typing out this monster email to the list trying to state what
the problem was in hopes of finding a solution. Well, luckily, I dug in
a little deeper and solved it before sending the huge email. I figured I
would put this info up here as I learned lots of interesting things
along the way.... alas, this is also a huge email but at least it has a
solution now.

This sort of applies to all the Atari games that used the Xicor X2212
NVRAM but this specific problem I had is sort of focused on I,Robot (and
Firefox). I will talk about why the other games are a little different
down below.

First, I have to state that I was trying to fix a noisy switching power
supply on this I,Robot prior to noticing that my NVRAM data was not
saving. I went through and replaced all the electrolytic caps on the
Switching Power Supply and like any old school tech, where possible, I
put in larger value caps (both voltage and capacity) to just make that
supply as ripple free as possible.

Now, some info on how Atari used the X2212 NVRAM's in their circuits....
the NVRAM is an interesting little beast.

The X2212 basically works via two layers of memory, the underlying
Non-Volatile storage area and an RAM storage area that sits on top. The
idea being that the NVRAM can throw all it's data into RAM and the game
CPU can interact with it as needed (reading and writing as much as
needed) without using the costly '/STORE' which degrades the underlying
Non-Volatile storage a little each time it is used (the original stock
NVRAM's had about 1000 'stores' in their life, then you would have to
replace the chip. Later, Xicor made versions that had a longer
lifespan). Upon boot, the game CPU asserts the /RECALL line which loads
all the Non-Volatile data into the RAM area for use. Then, when the game
CPU seems fit, it can tell the NVRAM (by asserting the /XSTORE line) to
save the current RAM snapshot in NVRAM and that data becomes permanent.

Atari did something pretty ingenious since at this point, they started
storing all kinds of data in NVRAM... normal game settings, accounting
info and even game uptime data. If you think about it, how would you go
about storing the game uptime if you didn't want to commit the working
RAM layer to the NVRAM every second? (remember, commiting working RAM to
NVRAM takes one lifecycle off the NVRAM storage count).

well what Atari did was configure some logic around the NVRAM so that
directly before the +5V supply dissappeared due to the game being turned
off. It basically triggered the /STORE line *right before* the supply
faded away. Since the datasheet for the X2212 says the store command
will take less than 10ms, then the /STORE line simply needs to be
asserted 10ms before the main +5V supply drops out of operating range
for the logic IC's.

On all the Atari games except I,Robot (and Firefox's that use the Atari
Switching Power Supply) this logic is part of the game PCB and it is
pretty foolproof.

Unfortunately, on I,Robot and the Firefox's that used the Atari
Switching Power Supply, they offloaded this circuit to the switching
power supply and piped it to the game PCB via the harness. This move
made a few more links in the chain of sending that final /STORE
assertion to the NVRAM. Also unfortunate, was that the Atari Switching
Power Supply had a slew of problems.

Side note: For some great bedtime reading, check out Jed Margolin's
stories relating to Firefox at
http://www.jmargolin.com/firefox/firefox.htm. Jed really loathed the
Atari Switching Power Supply (for good reasons). Also, excellent
information can be found on Scott's Atari Document Archive relating to
Amplifone development (technically, the Atari Switching Power Supply was
under the Amplifone project team) and some more Firefox notes about
power supply flaws and flakiness at http://www.atarigames.com.

So, back to my specific issue. The way that the switching power supply
determines if the power is disappearing is that it compares the voltage
at the PWM controller reference voltage (this voltage is generated
directly off the feedback of the driver stage and has very little load)
against the voltage at the +5V output (to the game PCB's). Since the
final +5V output is later in the switching power supply circuit *and*
it has more capacitance on it, that voltage will maintain longer than
the PWM controller reference voltage. This is where they get the 'hint'
that power is about to disappear.

I mentioned that I had gone through my switching power supply and
recapped it. Well, in short , that messed all this up completely.
Especially since I started putting in larger caps. I specifically put a
really big cap on the PWM +12V supply as I was getting lots of switching
noise on it and I was *trying* to minimize it by putting in more
filtering capacitance. What that was doing was holding the reference
voltage up longer so the reset to the PCB reset line was never being
asserted, and hence, NVRAM was not having the /STORE assertion and not
saving the RAM to the NVRAM before power disappeared.

So, in summary when having memory problems on I,Robot or Firefox (with SPS)

1. You have connectivity between J6-6 on the power supply to the game
PCB pin 4
2. Your reset signal is being asserted from the power supply.
3. You have the stock caps in the switching power supply.
4. You have a good NV2212 NVRAM (they do run out of life)

Some additional notes...

I found this post from Clay about the X2212.... way at the bottom past
the flaming of Clay...

http://www.tomshardware.com/forum/80992-13-dissatisfied-customer-clay-cowgill-multig

It talks about the newer X2212's being potentially unreliable. I do have
some X2212's from Mark C (arcadechips.com) and they seem to work fine in
my I,Robot now that I have my other problems sorted out.

Also, with switching power supplies, 'upgrading' capacitance is actually
bad. Switching power supplies technically need less filtering
capacitance since the AC ripply frequency is higher.

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Sat Dec 18 05:00:33 2010