According to the Video Arcade Preservation Society, Tempest is the most collected video game, with almost twice as many Tempests in collectors' hands as the runner-up. 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.
| 0000-07FF | RAM (P2, R2, P4, R4) |
| 0800-080F | Color RAM (low nibble only) |
| 0C00 | bit mapped register. Low bit to high bit:
|
| 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:
|
| 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:
|
| 9000-DFFF | Program ROM (D1-R1) |
| E000-FFFF | Copy of top 8K of ROM (for 6502 reset/interrupt vectors) |
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.
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.
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.
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.
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:
The audio outputs go to K6, which creates a differential signal after mixing the two together.
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.
Incidently, the most frequent repairs I have seen needed on Tempest machines are:
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.
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.
Does closing the slam switch do anything?
Disable the watchdog
Find the test loop on the main board that says
WDDIS. Take a piece of wire and tie this location to ground. Now power up the
game and press RESET a few times.
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).
Beep to RAM table:
Self Test Passes
At this point it appears your game has passed its
self-test. If you're still having problems, then it's something far less severe.
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:
| 0 | N/P3 |
| 1 | R3 |
| 2 | D1 |
| 3 | E1 |
| 4 | F1 |
| 5 | H1 |
| 6 | J1 |
| 7 | K1 |
| 8 | L/M1 |
| 9 | M/N1 |
| A | P1 |
| B | R1 |
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.
Spot Killer
The spot killer has activated indicating either X or Y
deflection is not occuring properly. Take a scope or a voltmeter and look for
+/- 6 volt swings on the X and Y out loops on the main board.
Monitor faults
Your monitor appears to be broken. Check the archives
on Wiretap for help with your monitor
Problems with gameplay
Turn the test switch off and try to reproduce
the fault.
Unknown problem
If you get to this point, then I don't know what is
wrong. Drop me a line and
I'll be happy to help you further.
DIP switches
There must have been something wrong with the DIP
switch settings you were using. Check the archives on Wiretap for the correct DIP
switch settings.
Problems with the controls
You should be in the first screen of the
self test.
Push each button on the control panel. Each one should change one of the 0s into a 1. Do the same with the coin inputs.
Rotate the encoder and watch the hex digit. Rotated clockwise the digit should decrease. Rotated counterclockwise the digit should increase.
Problems with the video
At this point you should be in the 2nd
self-test screen (diagonal crosshatch) and it should be tuned correctly.
What color are the lines?
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 amplifier dead
Check the audio/regulator board inside the
cabinet. The main audio output amplifier is located there and is suspect.
Audio output dead
Using either a small amplified speaker or a scope,
check for audio on the two audio out loops of the aux board.
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
Try replacing N/P3 and R3.
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.
Check deflection output amp
It appears that the final output amp of
the deflection section (D/E13) is bad. Also check C13, the analog multiplier.
Transient faults
Does the video seem to "implode" during the
intermission between players in a two player game?
or
Does the game do weird things, like give lots of free games or go bonkers after the end of a game whose score matches a particular pattern?
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.