Back to Nick's Games Page
New! Visit the Video Game Forum to discuss anything tempest related.
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.
| 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.
Does closing the slam switch do anything?
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.
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.
Beep to RAM table:
| 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 |
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.
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.
What color are the lines?
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.
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...
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).
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.
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).
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)?
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?
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.
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.