According to the Video Arcade Preservation
Society, Tempest is the 2nd most collected video game. This is despite the
fact that these games are 20 years old now (which makes them officially
"antiques" and it is obvious that they
were not designed for this sort of longevity.

The purpose of this guide is mainly to help anyone troubleshooting
problems on the Tempest main/aux board set. It also hopes to preserve
one of the best examples of economy in design and programming of all
time.

Note that I have no connection with Atari or anyone else. I am just a
collector and have managed to figure out what I have here by reading the
schematic and fixing a few broken board sets. If you break your game
because of what I say here, don't sick your lawyers on me, please. The
stuff in this document may be totally incorrect.

Much of this document is either inadequate due to my (still) limited
understanding of the workings of Tempest. Additional information is
always welcome.

Note! I don't mind answering question or helping folks
via e-mail, but before you write me asking what might be wrong with your
Tempest, please at least go through the flowchart
first. It
probably will tell you just what to do.

You may wish to consult a schematic while viewing this document. They
are available here.

Memory map

0000-07FF

RAM (P2, R2, P4, R4)

0800-080F

Color RAM (low nibble only)

0C00

bit mapped register. Low bit to high bit:

Right Coin

Center Coin

Left Coin

Slam

Test switch

Diag step pad

HALT (from Vector State Machine)

3 kHz square wave

0D00

DIP switch N13

0E00

DIP switch L12

2000-2FFF

Vector RAM (J3-M4)

3000-3FFF

Vector ROM (N/P3 & R3)

4000

bit mapped register. Low bit to high bit:

Right coin counter

Center coin counter

unused (left coin counter)

Video invert X

Video invert Y

bit 5-7 unused

4800

Vector State Machine GO

5000

Watchdog clear

5800

Vector State Machine RESET

6000-7FFF

aux board

6000-603F

EEPROM Write

6040

EEPROM Control

6050

EEPROM Read

6040

Mathbox status (high bit, read only)

6060

Mathbox read

6070

Mathbox read

6080-609F

Mathbox write

60C0-60CF

POKEY #1 (B/C2)

60D0-60DF

POKEY #2 (C/D2)

60E0

bit mapped register. Low bit to high bit:

1 player start LED

2 player start LED

use 2nd player controls (for cocktail games. See also video inverts)

SAEN 2,3 (a debugging signal on the small connector on the aux
board)

bits 4-7 unused

9000-DFFF

Program ROM (D1-R1)

E000-FFFF

Copy of top 8K of ROM (for 6502
reset/interrupt vectors)

Microprocessor and CPU support systems

The best place to start is the brains of the system: The 6502A running
at 1.5 MHz.

The top 32K of the memory map belongs to ROM. Not all of that space
is used, however. The actual program resides from 9000-DFFF. The
6502, however, requires reset vectors to be present at FFFA-FFFF,
so they simply put a 2nd image of the top 8K of ROM from E000-FFFF
(A4 gate 2 accomplishes this). If you wanted to hack the board to supply
your own program, the way to accomplish it would be to take A0-A11 and
D0-D7 from one of the ROM sockets, grab AB12 from A/B1 and A13 and A14
from B3, and apply all of them to a 27C256. You can even just ground
the /CS pins on the ROM, since it is E2's job to keep the ROMs off the
bus except for when the CPU is reading from them (that isn't really
its job, but it can serve that purpose easily enough).

The 6502 treats memory from 0000-01FF specially. 0000-00FF is the
"zero page," which is used in the (nn,X) and (nn),Y addressing
modes. 0100-01FF is the CPU stack (the stack pointer is only one byte
wide). Therefore it is important to put RAM in those locations, and
Atari did just that. There is 2K of RAM at the bottom of the memory
map that is private to the CPU.

Atari was liberal in their use of bus buffer chips. Most of the address
bus is obtained from A/B1 and B/C1. There are no less than 4 data bus
buffers: E2 is for the ROMs, F2 is for most of the main board and H2
is for the aux board. In addition, H3 is a bridge between the Vector
State Machine and the F2.

The CPU clock is itself derived from a 12 MHz crystal oscilator.
This 12 MHz source is divided by the counter at C4 to provide
a 6 MHz, 3 MHz and 1.5 MHz clocks. This is divided still further
by B4 to provide a 3 kHz clock for the watchdog, the
SINP register at 0C00 and the aux board (it also supplies a 24 kHz
clock for the main edge connector, aparently for no reason).

The power-on reset circuit is the only part of the system that makes
use of the +10.3 v unregulated power input. It does this mainly so
K11 can get power before the rest of the circuit. If you're running
Tempest off a switching supply, just hook the +10.3 unreg input to
a +12 source. The draw will be very, very small, so watch out for
supplies that die on under-draw conditions. The
watchdog is comprised of counter D4, which is fed from the 3 kHz
source. D4 divides the signal by 256, which means that a properly
running program must access location 5000 at least once every 80
msec or so in order to avoid being reset.

B3, J2, half of C1, P7 and J5 form most of the address decoding. The
first level of address decoding (half of B3) is used to cut the bottom
half of the memory map into 4 pieces. The top piece is allocated to the
aux board, the next piece down is itself cut into 4 pieces: The
coin counter register, VSM GO, Watchdog clear and VSM RESET. The 2nd
from the bottom is vector memory, and the bottom piece is again cut
into four pieces (with P7): 2 pieces of CPU RAM, the color RAM,
and the top piece is cut again into 4 pieces for the read registers
for the coin inputs and the 2 banks of main option switches.

Half of B3, J2 and half of C1 are used to select which ROM to read when ROM
is selected. One gate from A4 is used to mirror the top 8K of ROM for the
reset vectors.

Aux board

The aux board is fed 8 address lines and the aux board address select
signal and a copy of the data bus (from H2). It is also fed a 6 MHz,
3 MHz and 3 kHz clock, and a copy of the CPU phase 2 clock.

The two halves of B4 are responsible for the first pass at cutting up
the address space. One half of B4 only selects when a write takes
place, the other on any access.

The write side cuts the address range into 4 parts, the bottom two go
to the EEPROM write latch and the EEPROM control register, respectively.

The other half of B4 divides the bus again into quarters. The top
quarter is again cut in 4 by half of B5. The top sixteenth is unused.
The next one down selects the start LED and FLIP register. Next is
POKEY #2 and POKEY #1, the last sixteenth in the top quarter is unused.

The next quarter down (80-BF) goes to the Mathbox.

The third quarter down is split into quarters again. The top one is
labeled YHI, the next one YLO. Those two go to the Mathbox. The third
is the EEPROM read register, and the last one (40) is the Mathbox status
register.

Mathbox

I haven't got the slightest idea how the Mathbox works. Its purpose is
to do the 3D computations necessary for the perspective view of the
game.

This little tidbit comes from Gregg Woodcock:

The [...] 4 socketed 40-pin chips on the math box (at locations E2,
F/H2, J2 and K/L2 on Tempest) are called "transistor array"s by the
manual and the chips themselves carry only the Atari part number
137004-001 on them in an attempt to hide their true identity (to keep
people from making illegal copies of the game?) They are really 2901
bit-slice ALUs, which were very popular and are fairly commonly
available. They were made by AMD and a number of other vendors. In a
technical sense the part really is a transistor array, but calling it
that serves no purpose other than obfuscation. These go bad every now
and then and will generate an "M" on the self-test screen. NOTE: the
"M" is a generic "M"ath box failure indicator and does not necessarily
indicate that an ALU is bad; lots of failures cause the "M" indicator to
appear but one of the most frequent causes is bad ALUs (Note: The most
frequent cause I've seen is the interboard cable failing. Check that
first, as it's a lot easier to fix -- Nick). The cheapest
place I have found for these is:

B.G. Micro, Inc 800.276.2206 (AMD2901 ALUs $1.50 each)

For reference, B.G. sells two kinds of "2901" chips so be careful not
to order the 14 pin chips ($0.55 each) because you can't use them.

EEPROM

The EEPROM is a 64x8 one. It requires a -25 volt erase power supply,
which is supplied by K3 and its associated cirtuitry.

Any write to the EEPROM Write area (6000-603F) latches the address
pins for the EEPROM. So a do-nothing write must take place before you
can read a location within the EEPROM.

Reading the EEPROM read register gates the EEPROM data pins onto the
bus. It will also gate the write register if it is not disabled with
the correct settings of the control register.

The bottom 4 bits of the control register location are latched by J3.
The outputs of J3 go to the control pins of the EEPROM.

Unfortunately, I can find no data on the EEPROM chip they used, so I can't
divine how the control signals are used.

POKEYs

I am not all that sure of the internals of the POKEYs, but their wiring
is straightforward enough.

The FLIP signal obtained from the coin counter register is used to
feed D6, which is used as a player 1/player 2 control arbitrator.
If the cocktail signal is grounded (POKEY 1, P4), then the program
will assert the X and Y invert signals and FLIP whenever it's player
#2's turn in a 2 player game.

The encoder wheel output is a pair of sine waves (square waves will
work too) 90 degrees out of phase. The direction of the phase shift
indicates which direction the control is being turned. If the knob
seems to be operating backwards, swap the two outputs. The 4
inputs (potentially from two knobs) are squared off by E6. D6
then selects which pair to use. C6 is used to convert the two
out of phase square waves into a simple clock and direction
signal (note that in doing so it introduces an error. The first
"click" in the opposite direction from the last movement may
register as a click in the wrong direction. Fortunately, the
knob is very sensitive and the software reduces the sensitivity
so that this error is lost as noise). This is fed into an up/down
nibble counter, which forms 4 inputs to POKEY #1. FIRE and ZAP
go to POKEY #2 (again, after being chosen with D6). The
1- and 2-player start buttons, DIP switches at D/E2, and the
cocktail signal all go to the POKEYs, thusly:

POKEY #1, P0-P7:

encoder counter bit 0

encoder counter bit 1

encoder counter bit 2

encoder counter bit 3

/COCKTAIL

D/E2 switch 1

6 and 7 unused

POKEY #2, P0-P7:

D/E2 switch 2

D/E2 switch 3

D/E2 switch 4

FIRE

ZAP

Start 1

Start 2

7 is unused

The audio outputs go to K6, which creates a differential signal
after mixing the two together.

Vector State Machine

If the CPU is the brains of Tempest, the Vector State Machine (VSM) is its
heart.

In a nutshell, the VSM is itself a microprocessor, except that it is
a fairly simple one and it is optimized for its job: generating
deflection outputs for vector graphics displays. It has a program
counter. This is used to access vector memory and fetch opcodes
and execute them. The opcodes even include jump and subroutine call
instructions (yes, it has a subroutine stack).

The VSM has a 12 bit address bus. Half of this space is given to the
Vector RAM, half to the Vector ROMs. The VSM and CPU interleave control
of this address space. The CPU fills in the vector RAM with opcodes to
do whatever drawing is called for, then it accesses the VSM GO location.
This starts the VSM running. The CPU then polls the HALT bit waiting for
the VSM to finish drawing (it is, of course, free to do actual work
during this time as well).

There was an excellent article posted to RGVAC giving the
opcode list for the vector state machine.

The rest of this section is still under construction.

Monitor

This section is still under construction.

Power supply & audio amp

This section is still under construction.

Diagnosing Tempest

The rest of this document tries to show how I would go about repairing a
Tempest board set. This section presumes that the monitor and power
supply are working (it makes this presumption since there already exist
lots of stuff in the Wiretap archives about
repairing these sections).

Incidently, the most frequent repairs I have seen needed on Tempest
machines are:

Replacing the 32,000 uF capacitor in the main DC power supply

Replacing the 6 chassis mounted transistors in the monitor

Fussing about with the interboard cable

Applying a Zannen "fix it" kit to the HV supply in the monitor

Tracking down and replacing blown chips on the main board

Start at the Start field below. Each field you come to will have some
action to take. In many cases that action will have an expected result
and/or a series of links containing possible outcomes. Select the
outcome that seems to apply best. If there is no applicable link (or
no link at all), then you have reached the end of the flowchart. If you
find and repair a fault, you should start at the begining again. In my
experience it is not uncommon to find boards with many faults -- a single
fault will take a board set out of service, then it will get substandard
storage because it is a "dead" board and get worse and worse.

The procedure

Start

Set all of the DIP switches on the main board on except for N13 #7
and all of the switches on K10/11 (turn them off). Turn all of the DIP
switches on the aux board off. Turn the test switch off. Make sure all
the harnesses are connected and apply power.

At this point the game should be set for free play and should be in
attract mode. Both of the LEDs in the start buttons should be blinking,
the LEDs on the main and aux boards should be on and the LED on the
monitor deflection board should be off.

Test Mode

Turn the game off, flip the test switch on, then turn the game back on.
You should get a big white rectangle that's cut in half. There should be
lots of 0s and 1s in the bottom half and nothing in the top half. There
should also be a digit in the bottom half that changes with the
spinner.

No Video

Close the slam switch a few times. If the logic board is working,
you will be cycling (blindly) through the test screens. On one of
them the game will test the audio circuitry, hopefully making a
series of four decending tones.

Disabling the watchdog helped

The watchdog circuit is in question at this point. Using a logic probe
or a scope, look for pulses on J5, pin 10. If you see them there, then
the address decoder is generating WDCLR correctly. Look for the pulses
again on K9 pin 12, K9 pin 11, and D4 pins 2 and 12.

Check the power supply

At this point it would be a good idea to check the power supply.
Make sure that the +5 volt supply is ripple-free and within 2% as
measured on the main and aux boards. If it isn't, then check the +5
volt supply on the audio/regulator board. If it is higher than
5.5 volts, then check the wiring between the audio/regulator board and
the main/aux boards for a voltage drop. Otherwise, adjust the pot on the
board until the voltage on the main board is +5.

Ripple in the power supply

The first thing to check is the primary +10.6 unreg supply. Disconnect
the primary DC output cable from the primary power supply (the metal box
in the bottom of the case where the transformer and most of the fuses
sit). Look for ripple on the 10.6v output. If you see any, replace the
big capacitor mounted in the primary supply. If you don't see any with
no load, then check for ripple with the main/aux boards disconnected,
but with the DC output cable connected. If there is no ripple in either
the +5 or +10.6 supplies at that point, then it is possible that there
is an overdraw condition, but this is a bit unlikely (a dead short
should be blowing fuses).

If you see ripple in the +5 supply but not in the 10.6 supply, then
you'll need to debug the regulator circuit on the audio/regulator
board.

CPU or ROM trouble

At this point it looks like the CPU is just not running correctly. Using
a scope or a logic probe, look for pulses on CPU pin 37. If they're not
there, then check the clock generator circuitry. Next, check for them on
pin 39. If they're not there, then the CPU may be dead. Check also for
square waves on all of the address and data lines (A15 may be mostly
high). Check E2 pins 1 and 2 to make sure the ROM-to-data bus gateway is
working, then check the ROMCS lines and the contents of the ROMs
themselves.

It is possible that the CPU is ok and that both the VSM and the audio
are bad. But if the game can't make video or sound, it's going to be
a bitch to debug.

RAM error

Hit the RESET button and count the number of low, short beeps (or short
blinks on the start LEDs) that take place before the first long beep.
Each short beep counts a working RAM chip. The first long beep
flags the bad one. If the bad RAM chip
is one of the first four, then it is the CPU's private RAM that is in
question. If it is one of the last 8, then it is the VSM's RAM.
If it is the first, second, fifth or sixth RAM then also look for
trouble in the path between the CPU and either the private RAM or the
VSM RAM (as the case may be).

Self Test Gets Errors

The self-test is complaining about something specific being broken.
If failures are indicated on the aux board, I strongly suggest you check
and resolder the molex connectors for the interboard cable, and the
cable itself.

Mathbox error

The mathbox has failed diagnostics. You might try making sure the
interboard cable is working. If it is and if the mathbox is truly
broken, then I have no idea how to help.

EEPROM error

The EEPROM chip has failed diagnostics. Turn the test switch off, then
back on again to get into the bookkeeping screen. Use the encoder to
erase the scores and times and repeat the self test. If it still fails,
then you probably have to replace the EEPROM chip.

ROM error

One or more of the ROMs has failed diagnostics. Ignore the numbers in the 2nd
row. The failing ROM(s) can be identified by the number(s) in the top row
of the display:

Bad bus buffers

If a ROM or RAM chip is flagged as bad, it may be that the buffer chips
between the CPU and that chunk of ROM or RAM are bad. This is
particularly a possibility if the chip(s) containing the first byte
of a particular section (private RAM R2 or P2, program ROM D1,
vector RAM M3 or M4 or vector ROM N/P3) show up as bad.

At this point you presumably replaced the device. You did use a
socket, right? Remove the device and run the game with the device
missing. Check the address and data pins of the device to make sure
none of them are 'stuck.' With the self test going, most if not all of these
lines should show activity. Trace any stuck pins back to the device
side of any buffers and see if there's activity on the opposite side
of the buffer. If so, then the buffer is likely to be the problem.

Tune the Video

You should be in the self-test mode on the first screen. Momentarily
close the SLAM switch and you should see a rectangle with diagonal lines
in it and a character set near the bottom.

Adjust the X and Y center pots to center the pattern

Adjust the X and Y size pots to put the rectangle roughly within
half an inch (1 cm or so) of the edge of the tube

Adjust the X and Y BIP pots so that the corners of the diagonal
boxes rest exactly on the large rectangle

Adjust the X and Y linearity pots so that the diagonal lines are
straight. When this is done the size pots may have to be
readjusted.

Check R, G and B outputs

You should be in the 2nd self-test screen (diagonal crosshatch) still.
Operate the SLAM switch twice. The 4th self-test screen is a color test
screen. You will see 7 groups of vertical lines. The three groups on the
left will be (top to bottom) magenta, cyan and yellow, the three on the
right will be (again, top to bottom) green, blue and red.
The group in the center will be white. Within each
group of lines there are 6 lines. The leftmost should actually not be
visible. The 2nd from the left should be barely visible (adjust the
brightness control on the monitor if this is not so).

Bad R, G or B outputs

One or more of the color outputs are not working. Using a scope or a
voltmeter, trace back from the color outputs to the three color output
transistors (Q2-Q4) and to the intensity D-to-A network near H9.

Monitor bias/drive adjustments

Find the neck board on the monitor. On the top (as the monitor is
mounted in the game. It's really on the left side) of the neck board
going from left to right you should see the red drive, red bias, green
drive and green bias pots. On the bottom again from left to right is the
blue drive and blue bias pot.

Adjust the three bias pots until the 5th line from the right (it is
longer than the rest) is pure white. Adjust the three drive pots until
the right most line is pure white.

Monitor purity adjustments

You should be on the 4th self-test screen. Close the SLAM switch to
advance to the 5th screen, the convergence/purity crosshatch. Using
a voltmeter or scope rotate the encoder until only the green color
output is active (red and blue should be 0).

Loosen the yoke-retaining clamp so that the yoke can move. Slide the
yoke toward the back. Remove any glue that may be holding the purity
ring magnets in place, and rotate one or both purity rings in a line so
that they face opposite directions from each other.

Slowly slide the yoke toward the front of the CRT until the pattern
displayed is an overall pure green. Tighten the yoke retaining clamp
lightly, making any slight physical adjustments to the yoke to maintain
a pure green pattern. Rotate the yoke to level the pattern on the face
of the CRT.

Turn the encoder wheel to the red and blue patterns, and slightly
readjust the yoke for a uniform and pure pattern for each color. Tighten
the yoke retaining clamp to prevent yoke shift or rotation.

To make fine adjustments to the purity, turn the purity magnets for the
best overall purity of each color. Reglue the purity magnets with a
small amount of glue.

Proceed to convergance...

Converge the tube

If you are on the 4th self-test screen, close the SLAM switch to advance
to the 5th screen, the convergence/purity crosshatch.

Rotate the encoder until magenta (red and blue) is displayed. Adjust the
tabs on the center pair of adjusting magnets so that the red and blue
lines are superimposed, making magenta (do this at the center of the
screen).

Turn the encoder wheel until white (red, green and blue) is displayed.
Adjust the tabs on the back pair of adjusting magnets so that the green
lines up with the magenta, amking white (again, at the center of the
screen).

Encoder doesn't move

Check the two outputs of the encoder itself. You should see two
sinewaves 90 degrees out of phase (the phase shift depends on which way
you turn the encoder). Check to make sure the sine waves arrive at
E6 on the aux board. Then make sure square waves make it from E6 to
D6, which selects which set of controls to use for cocktail games.
Next, check C6, which is the flip-flop that changes the two sets
of square waves into a direction and clock pair. If that doesn't
help, check to make sure that the counting is taking place on the
input to POKEY #1. If it is, then the POKEY is suspect. If not, then
the counter is.

Encoder moves only one direction

One of the outputs of the encoder is CLK, the other is DIR. There is
a D flip-flop on the aux board that turns the two out-of-phase
square waves into a direction and clock signal. If the encoder is
stuck moving in only one direction, it is because the DIR output is
not making it to or past the flip-flop. Check both outputs of the
encoder to make sure you get sine waves as you turn it. Similarly
make sure that the sine waves arrive at the aux board. Then check
E6, which is in charge of squaring the sine waves, then D6 which
selects which set of controls to use for cocktail games. Lastly
check the flip-flop at C6.

Problems with the buttons

Use a voltmeter or a scope to check and see if pressing the button
grounds the input on the board. If not, check the wiring. If it does,
then follow the signal through the input chips until it either stops
changing or you hit a data bus.

Problems with the sound

The 3rd self test screen is a large + sign and an audio test.
In the self-test mode, use the SLAM switch until you see the +.

You should hear four descending tones. The tones should be continuous,
one tone moving straight to the next, each about a second long. Each
tone is actually made of two identical tones, one coming from each of
the two POKEY chips. You may therefore hear a slight imperfection in
each tone half way through. This is normal.
If there aren't four tones or they aren't descending or they
aren't ajoining, then the test has failed.

SLAM switch stuck

Check the slam switch. It is on the coin door near the top on the side
where the lock is. It is a small metalic strip with a weight on the end.
There is a second small strip of metal. When someone kicks the machine,
the weight will move, making the two strips of metal touch. During
gameplay, this will cause the machine to emit a loud sound for a couple
seconds (an alarm of sorts). If the slam switch is stuck closed, this
sound will be constant.

Trouble with the POKEYs

It would appear that there is something wrong with one or both of the
POKEY chips on the aux board (B/C2 or C/D2). POKEYs are still
commercially available, though they're not getting any easier to
find as time goes on. To be sure, try power cycling the machine
into self test again and make sure you don't get indications of a
mathbox error. If you get mathbox and POKEY trouble, check the
interboard connection cable.

You can also try swapping B/C2 and C/D2. If the letter changes from
either P or Q to the other letter, then the associated POKEY chip is
bad (P is B/C2, Q is C/D2).

No audio at all

Listen very closely to the speaker and crank up the volume (don't
do this when the game is either making noise or could decide to start
making noise). Do you hear either digital noise or white noise that
increases or decreases in volume with the control?

Audio output dead

Dead audio preamp circuitry

Trace the audio from the POKEY outputs to the output of the
aux board. The fault is in that area.

Possible VSM analog power problems

The most common cause of an inability to tune the video properly
is the power supplies to the analog vector section of the main
board. Check the +15, -15 and +6.8 volt power loops and make sure
they are absolutely correct. Any variance beyond 2% or so
is a Bad Thing.

VSM Digital faults

This, unfortunately, is the hard part. It would appear that you have
a problem with the vector state machine. Debugging it is going to be
rather painful.

If when entering the test mode an error in ROM N/P3 is detected, the
game will make a continuous tone. It does this because it may not be able
to generate characters from the character set and therefore it may not
be possible to see the self-test screen. If you get indications of a RAM
error and this continuous tone, you can almost be sure that something
is either wrong with the VSM data or address busses in the area of the ROM
and RAM or the CPU-to-VSM interface. You might try removing one or more
of the components called into question. If the game starts acting better
with components removed, then look at the chip select lines for those
parts for possible shorts (this technique won't work for the first pair
of VSM RAM chips, but it will for the other ones, since the test
patterns on the whole are less than 1K of vector operations).

If the VSM ROM and RAM check out as ok (likely you can only deduce this
because of dead silence upon entering the self test, but audio changes
when pressing buttons or the SLAM switch) then the state machine itself
or perhaps the program counter/stack section may be bad.

Use the SLAM switch and advance to the self test screen that has a four
tone audio test pattern. Do you see a large "+" sign (it may be
distorted into a vertical line and a pair of horizontal lines that go to
the right and left of the vertical line)?

VSM ROM suspect

VSM Analog faults

One or both of the deflection outputs is stuck at this point. I will
presume it is the Y deflection that's not working. You will have to
adapt a bit if X is the problem.

Turn the brightness up on the monitor SLIGHTLY until you over-ride the
spot killer. Don't leave it like this very long! It is very
bad for the tube to not be deflecting the beam a lot. You should now
see the screen "crunched" into a flat line. Wiggle the Y centering
pot. Does the line move up and down?

Trace deflection signals

You'll have to trace the deflection signal from the voltage
multiplier (C13) back to the D-to-A converters to find the
fault.

Be sure to carefully check the resistances on C13's pins. C13 is an
analog multiplier. If the resistance between pin 5 and 6 (for example)
is infinite, then the chip will multiply the input by zero!

You can pretty safely ignore A/B13 and A/B12. They provide a small
correction signal to C12 and C13 to compensate for the tube's roundness,
but even if these chips are out of circuit the video on the whole should
still be visible.

Bad ROM revision

The faults described in the previous question are caused by bugs in the
game code.

The "implosion" is actually a feature of later revisions of the monitor.
Extra capacitors were added so that if an input were "pegged" to a
particular voltage, the circuitry would "drag" the input back down to
zero. In combination with the spot killer, this circuitry would better
protect the tube from bogus inputs by not leaving the deflection
amplifiers "on full blast". At the same time that this revision was made
to the monitors, Atari made changes to the intermission screen to add
extra "black" vectors to insure that the "cursor" would visit the bottom
half of the screen and avoid tripping the new amplifier protection
circuitry. 15 years later, however, you don't always get the game board
that came with the monitor, and if the game doesn't draw the extra
vectors, you'll see this effect.

Both of these bugs are fixed by installing new x17 and x22 ROMs.

Of all of the versions of Tempest I have seen, there have only been 3
differences:

Between version 2 and 3, ROM 2 had two bytes change (actually, this
change occurred at the same time that Atari went from 2K to 4K ROMs,
so this change is actually in the 2nd half of the new 4K ROM 1).

Between version 1 and 2, ROM 3 had two bytes change.

Between version 1 and 2 a rather massive code change happened in
ROM 8.

I am not sure which changes affected which behavior. There is certainly
no harm in installing v3 versions of ROMs 2, 3 and 8 in any machine you
happen across.