Newsgroups: rec.games.video.arcade.collecting
From: davidhan@csn.org (David Hanes)
Subject: Re: Need repost of Batllezone + HP Catbox story...
Date: Mon, 18 Jul 1994 23:12:18 GMT


: About 1/2 year ago or so somebody posted a big story about using an HP
: signature analyzer to debug a Battlezone problem.  If you saved that
: article, would you please followup this article and repost it
: (especially if you are the person who first posted it)?  I have part
: of the post below but don't have the guts or attribution...

Here's the repost of the article:
----------------------------------------------------------------

To follow up on what Steve started, I thought I'd post some
information about my latest project, and how I went about fixing
it.  This note also contains some information about using a
signature analyzer to isolate problems.

I had picked up a non-working cabaret BattleZone this summer
(thanks Rick!), and began serious work on it in October.

With a new game, I usually like to start with the power supply
and work up from there.  So I began by unplugging all of the boards
in the game, and testing all of the power supply voltages that I
could.  These all looked good, so I plugged in the audio/regulator
board and checked some more voltages, they too looked good.
I plugged in the vector generator and the aux boards and powered
the game up, and, as expected, I found the spot killer LED was
active.  Shortly after this, I noticed that the regulator board was
very hot, and I found that the +5 regulator was not working
properly, (probably due to a bad card-edge connection, which I later
cleaned).  I fixed the power supply, and then installed a working
board set (thanks again Rick!) in the machine to check out the
monitor.  With the good board set, the spot killer LED was off,
and I could hear the deflection coils running, but there was no
picture.  I immediately noticed 2 things, first the filament wasn't
glowing.  Second, there was no "cracking" sound when the monitor
was turned on, which I figured meant that there wasn't any
high-voltage either.  I checked all of the transistors on both
the EHT unit and the X-Y deflection board, and they were all ok.
I measured the voltages on the EHT unit and found that +90 and
+400V were present, which indicates that the EHT unit is working.
There are only two things that could prevent the 12 KV from not
being present, while +90 and +400 were ok.  The first is the
flyback transformer, and the second is the high-voltage diode
which goes in-line between the flyback transformer and the second
anode connection.  I was hoping that it wasn't the flyback that
failed, and started looking for a replacement high-voltage diode.
I called both Atari and Electrohome, and the part was not available from
either of them.  I finally found someone who knew who the
manufacturer of the original part was, and gave me their phone
number.  If anyone needs that part, the replacement part number is
H1812, and it is available from a company called "Solid State"
(201) 429-8700.  (This company has a $50 minimum order).

I installed the new high-voltage diode, and that fixed the
high-voltage problem.  I couldn't figure out why the filament wasn't
glowing though, as the filament voltage comes pretty much directly
from the power supply transformer.  The 6.3 VAC was ok at the power
supply, and there are only a few components in its path to the
picture tube (all of which checked out ok).  I began to worry about
the tube itself, so I took it into a local TV repair shop, and they
tested it out for me.  Fortunately, the tube itself was ok, so I
knew I had to look further.  I finally tracked down the problem to an
intermittant connection in the wiring harness.  So now I had the
monitor up and running with the borrowed board set.  Now it was time
to start working on the boards themselves.

I started by putting the game into self-test mode (via the switch on
the coin door), which unfortunately didn't tell me much.  The game
beeped, but it was neither the "low" nor the "high" beep that
is normally emitted with the RAM test.  The game kept endlessly
spitting out a long, low beep.  I had already verified the EPROM
contents, so I began to probe around with my logic probe.

With the probe I found that roms 2 & 4 weren't being accessed at
all, so I suspected an addressing circuitry problem.  I replaced
1 component which I thought might be causing the problem, but it
had no effect on the game.

Then I ran across an interesting article in an old StarTech journal,
which described some useful tips concerning signature analysis.
A signature analyzer (also called a "CAT" box by Atari) is basically
a device which reads a data stream of 0's and 1's and converts that
stream into a 4-digit displayable number.  (The signature analyzer
has an LED display on the front of it.)  In order for the signature
analyzer to be of use, the device that you are debugging has to be
designed for use with a signature analyzer.  (Atari was probably the
best at this, as several of their games were designed to be debugged
with a signature analyzer.).  In any case, the documentation about
the particular game, will tell you how to hook up the signature
analyzer to the circuit board, etc.  The idea behind signature
analysis is that by putting the board into a known state, there will
be a repeatable pattern of 0's and 1's (a signature) on particular
points on the circuit board.  The manufacturer then publishes the
signatures taken from a known-good board (usually these are printed
directly on the schematic).  If you have a non-working board, you
hook up the signature analyzer and begin probing various points on
the schematic, looking for a bad signature.  If you find a signature
which doesn't match what the manufacturer published, you work
backwards from that point, trying to find a point where a
component's input signatures are good, but it's output signature is
bad.  If this is the case, you've probably located the failed part.

Unfortunately, Atari only designed their math/aux board to be
debugged in this manner.  So, I figured it wouldn't help me in
trying to isolate the problem with the vector generator board.

Anyway, this article also described how to make a "NOP test fixture"
for the 6502.  In order to use this test fixture, you take the
CPU out of the game board, and put it into the test fixture, then
you put the whole fixture back into the board.  The fixture basically
hardwires a "NOP" instruction on the CPU's data lines, which forces
the processor to loop through its entire address space, doing nothing
but executing NOP instructions.  You then use a signature analyzer
to see if the signatures on the CPU's address lines match what they
are supposed to be (the article also published signatures for the
6502 processor).  The article explained that in many cases the
test fixture could be used to test the addressing circuitry in a
game, even games which weren't specifically designed to be used
with signature analysis.

This sounded interesting, so I built and installed the test fixture
in the BattleZone and found that the signatures matched their
published values, which made me start looking into other areas
which could cause the board to get into a bad state.

I noticed that when the game was first reset, roms 2 and 4 were being
accessed, but only for the first second or two.  I suspected that
perhaps the RAMs on the board weren't working, and were therefore
causing the board to get into a weird state.  I replaced both of the
program RAMs (2114's), and that solved the problem with the main
board.

I was getting close, but the math/aux board was displaying an "H"
in the upper right hand corner of the display (when the self-test
mode was on).  According to the Atari documentation, this indicates
a "high byte" error on a math board response.  The first thing that
I did was to verify that the problem was actually in the math board
by swapping math boards with the known-good set.  Again, the
borrowed board worked fine, so I knew the problem was in my math
board.  I checked some obvious things, like removed/re-inserted
all socketed chips on the math board, and checked the connections
on the wiring harness between the two boards, but it didn't help.

Fortunately, Atari did design the math/aux board to be debugged with
a signature analyzer.  Their documentation described how to build
a wiring harness just for this purpose.  After making the harness,
I hooked up my signature analyzer to the game and began to probe
around.  Within an hour or so I had found a component (B1) which
had valid signatures on it's input lines, and a bad signature on
it's output line.  After replacing B1 with the one from the
known-good board, the math board was working correctly too!  If
anyone knows how to program the chip at location B1, please let me
know.  I know the contents of this chip used to be in the wiretap
archive, but I don't know anything about this particular component
(all I know is that it's not an EPROM!).

Now I just have to clean the game up, put it back together, and
wait for some centerring bellows so I can fix the control handles.
It's been a long project, but quite a lot of fun too!

Sorry that this article got so long, I didn't expect to be so
wordy!  In any case, I hope it was of interest to you.  Drop me some
email or post if I can help with anything.

Dave

P.S.  I don't read email from this account very often, so 
you may want to send any email to:
   davidhan@cms.gr.hp.com