V = Voltage
To find the Voltage as a function of the current we move things around so that:
I *dt = C * dV If we integrate each side:
dt C* dV
which we can rewrite as:
dV = 1/C *dt
The result is that
V = dt + V0 where V0 is the initial voltage before we applied the current.
This means that:
1. If the current through a capacitor is zero, the voltage across the capacitor stays wherever it was.
V = 1/C * 0t + V0 = V0 2. If we supply a constant current through the capacitor:
V = 1/C *t + V0 which means we get a very nice, perfectly-linear ramp starting from the initial voltage V0.
Let's look into producing a current source.
If we try a simple circuit with a voltage and a resistor (Figure 13) starting with VC = 0, the current is initially
I = V/R .
However, as soon as VC starts to rise, the voltage across R is now (V-VC), so that the current is
I = (V-VC)/R , which is less than V, so that the voltage rise is now slower than when we started. The longer we go, the slower it gets. It is not a very good ramp. See Figure 13b.
Without going through its derivation, the formula is:
VC = V * ( 1- e**(-t/R*C) ) The rise time for this RC circuit is defined as the time it takes for VC to reach 63.2% of its final value.
This number wasn't chosen arbitrarily.
When t = R*C,
VC = V * ( 1- e**(-t/R*C) )
= V * (1-e**(-1) )
= V * (1-0.368)
= V * 0.632 (The value R*C is called the Time Constant of the circuit.)
Therefore, we need a really good current source such as the one in Figure 14.
An ideal op-amp has infinite gain and its inputs require zero current. Since there is no current flowing into the negative input to the op amp, all the current through C will be the same as the current through R. Since the op-amp has infinite gain, the voltage across between op-amp's positive and negative inputs will be zero, assuming the op-amp's output is less than infinite. By referencing the op-amp's positive input to ground, the voltage at the negative input will be zero.
Therefore the current through R is Vin/R, which will be same current flowing through C, so we have a voltage controlled current source, and applying a step voltage at Vin will cause Capacitor C to produce a nice linear ramp at Vout. The circuit inverts the polarity of the input, so a positive voltage at Vin produces a negative ramp at Vout and a negative voltage at Vin produces a positive voltage at Vout. Officially, this circuit is an Integrator because the output is the sum (over time) of all the input voltages.
If we already have a current we can skip Resistor R.
As it turns out, most DACs produce a current output. However, because most DACs have a limited drive capabilty (and want to see a low circuit impedance) most DACs use an op-amp on their outputs.
The circuit for a DAC connected to an Integrator is shown in Figure 15.
Notice that we have also added two resistors. DACs require a reference voltage (or current). That's what R1 is for.
R2 is to provide the offset current to convert the Unipolar DAC to one that provides a Bipolar output, which is why, in all of Atari's schematics, it's called the BIP. This method was covered in the section on Digital Vector Generators.
By the way, the DACs used in the earlier sections were assumed to have voltage outputs in order to avoid unnecessary detail. If we wanted a DAC with a voltage output that did not integrate the values we would replace the Capacitor with a Resistor and end up with the circuit shown in Figure 16.
Referring back to Figure 15, we now have a DAC that produces a bipolar output current that is the product of
Digital Inputs (in two's complement) * Vref * K where K is a constant that represents the conversion gain and depends on what's in the DAC.
This output current determines the slope of the ramp produced by Capacitor C.
We are almost ready to draw some vectors. The problem is in starting and stopping the ramp. If we don't do a good job starting and stopping the ramp, the vectors will look pretty bad.
If we give the DAC a digital input of zero, the output current will be zero and Vout will stay where it is. Unfortunately, the DAC takes too long to change its current for this to work. The DAC also produces glitches when it changes.
The method used in all of Atari's Analog Vector Generators (with the exception of TomCat) was to switch the DAC reference on and off.
In Figure 17 we have chosen Resistors R1 and R2 to scale the Reference Current for the DAC as well as the Bipolar Offset Current for the Op-Amp.
How well this method works depends on :
1. How well the turn-on and turn-off characteristics of the DAC match.
2. How fast the vectors are drawn. The faster the vector is drawn, the more time it spends in the turn-on and turn-off periods, and therefore the more noticeable the turn-on and turn-off periods are.
In BattleZone the vector drawing speed was slow enough that the vectors look good.
By the time we got to Star Wars, the vector speed (and monitor speed capability) had increased to the point where the vectors looked really bad. We kept devising circuits to match the turn-on and turn-off characteristics of the DAC but the Programmers just drew the vectors faster in order to get more of them on the screen.
There is another problem.
The charge stored in the capacitor is a history of all the charge that has ever been stored in it, including all the turn-on and turn-off mismatches. In other words, the errors keep adding up.
If allowed to continue, objects would not end up where they are supposed to be on the screen. Eventually, the outputs would drift completely out of control.
The simplest method, and the one chosen, was to periodically discharge the capacitor, as shown in Figure 18.
This was done with an LF13201 Analog Switch. Analog switches like the 4016 and 4066 require that the control signal have a range somewhat greater than the analog signal to be controlled. That means if you want to control a signal that goes between -10V and +10V the control signal must switch between (a little bit more than) -10V and +10V. If you are controlling it with a TTL signal, it means making a level translator. (Asteroids has one.) The LF13201 contains the TTL level translator. It's more expensive, but worth it.
Now, we need to talk about capacitors.
Capacitors are more complicated than you may think. Not all capacitors work equally well in this application. In fact, there are very few capacitors that are acceptable here.
There are several properties of capacitors at work.
One is Leakage. It's like there is a resistor across our capacitor that causes it to discharge all by itself. This would cause the position of the beam to drift to the center so it isn't where it is supposed to be. Leakage is a function of the type and quality of the dialectric used.
Another is Inductance whichwill make the response of the Integrator change according to the vectors we are drawing. The Inductance of a capacitor depends on the construction of the capacitor. For example, take a capacitor whose plates are made by taking two foil strips of conducting material (such as aluminum) with a dialectric between them and rolling them up with an additional dielectric so that adjacent layers don't short out. If the connections to the plates are made on only one end, the other end will have the entire length of the plates between it and the capacitor terminal. The length of the plates will have inductance. However, if the capacitor terminals are connected to each layer at the sides of the roll the distance of each segment of the plates will be much shorter.
This is shown in Figures 19a, 19b, 20a, and 20b. In the interests of clarity I have shown only one plate.
Another property of capacitors is Series Resistance. Like Inductance, Series Resistance will make the response of the Integrator change according to the vectors we are drawing. Again, this is caused by the construction of the capacitor as well as the shape of the plates and the material used in the plates. A capacitor constructed as in Figures 19a,19b will have a higher Series Resistance than the one in Figures 20a, 20b.
By the way, the official term for Series Resistance is Equivalent Series Resistance (ESR) and is an important
specification of capacitors used in high frequency switching power supplies. When the current that is charging and discharging the capacitor goes through the Equivalent Series Resistance it produces heat. The greater the ESR, the greater the heat produced. You can't escape Ohm's Law.
The final capacitor property we will consider is related the phenomenon known as Charge Redistribution.
To start with, when you charge a capacitor to a particular voltage, the charges stored in the dielectric do not uniformly distribute themselves throughout the dielectric; they favor the positive plate. After all, the charges are electrons which have a negative charge.
And when you discharge a capacitor, the charges do not immediately redistribute themselves throughout the dielectric. This is why, when you think you have discharged a capacitor, you can come back a short time later and a small amount of charge has magically reappeared. No, the capacitor has not been recharged by the atmosphere, or the aether, or by phlogiston.
I did the following experiment with a 1000uF 25V electrolytic capacitor. First I connected a DVM across it to verify that it was fully discharged and that the DVM was not injecting current into it. The reading was 0.000V .
Next I connected a 9V transistor battery across it, observing polarity. The reading was 9.38V (it was a new battery.) When I disconnected the battery the voltage began to droop very slowly due to capacitor leakage.
I shorted the capacitor for about three seconds, then removed the short.
The results are shown in Figure 21. It reached a peak of about 0.34 Volts after 30 minutes.
When we discharge the capacitor in our Integrator we want it really discharged. Some capacitors do better than others for reasons that are not clear.
Mylar Capacitors were used in BattleZone, but did not work very well in Star Wars, which had a faster drawing speed. The capacitors that worked the best for us in Star Wars were Polycarbonate Capacitors.
Polycarbonate is a clear and colorless amorphous thermoplastic notable for its high impact resistance. In addition to its use in capacitors it is used in glazing, safety shields, and CDs. (An excellent Web site for the properties of materials is http://www.goodfellow.com/.)
Polystyrene capacitors are also considered high quality capacitors but they worked poorly in the Integrator.
The properties of polystyrene are similar to polycarbonate but for reasons that are unknown the polystyrene capacitors exhibited problems that appear to be the result of charge redistribution.
Finally, the issues of Leakage, Inductance, and Series Resistance are not confined to the capacitor itself.
They can also be caused by circuit design and layout. The circuit layout can also screw things up if there is crosstalk from another signal trace.
It doesn't always end there, either. One time I was asked to look at a prototype AVG board for another project which was producing really nasty vectors. The digital circuitry had been checked and was ok. We ended up unsoldering all the parts in the Integrator and connecting them together off the board in the air. That fixed the problem and we concluded that the material used in the PC Board was contaminated. The next run of prototype boards was ok.
We can now start and stop a ramp whose slope is determined by a 10-bit digital word. We can also discharge the Integration capacitor to center the beam.
This is analogous to the Digital Vector Generator where we can start and stop a ramp produced by a Binary Rate Multiplier which clocks a counter that feeds a DAC whose output is deglitched by a Sample-and-Hold.
There are several differences.
1. The Digital Vector Generator produces vectors consisting of points at discrete coordinates. While the Analog Vector Generator has discrete values representing the length of a vector, the values in-between are continuously and infinitesimally changed (subject to the restrictions of living in a Quantum Universe). Thus, there is no stairstepping.
2. The Digital Vector Generator can set the position to any coordinate by loading it into the counter. The Analog Vector Generator can only center the beam and draw a blank vector to the desired position. (The ability of the Digital Vector Generator to load the counter was mostly unused since the fastest the XY monitors could move the beam was about the same as the fastest drawing speed.)
3. The Binary Rate Multipliers in the Digital Vector Generator require inputs in Sign/Magnitude form, while the Analog Vector Generator uses Two's Complement values.
4. The Counters in the Digital Vector Generator require different clock frequencies to make different X and Y values, while in the Analog Vector Generator the X and Y values automatically produce analog ramps of the proper ratio.
Since we are always working with changes in vector length, they are referred to as Delta values. Delta is the Greek symbol used to represent Difference and, if your character set supports it, is represented by the Greek symbol or which is where we get the Latin letter 'd' .
At this point we are faced with some of the same issues for the Analog Vector Generator as we were with the Digital Vector Generator, namely, how fast to draw the vectors. This has already been discussed in the section on Digital Vector Generators.
Faced with the same insatiable need to feed data to the DACs we turned to the same solution, the custom processor made out of SSI and MSI having at its heart, the Vector Generator State Machine. The basic theory of State Machines has also been covered in the section on Digital Vector Generators.
The Vector Generator State Machine Revisited
The Vector Generator State Machine used in the Analog Vector Generator follows the same general form as the one used in the Digital Vector Generator. Some of the differences are due to the differences between the analog circuitry in the Analog Vector Generator and the digital circuitry used in the Digital Vector Generator.
Some of the differences are related to the type of game the Analog Vector Generator was designed to run.
For example, because the trio of games scheduled to use the new Analog Vector Generator were 3D games where the vectors are the result of 3D transformations performed during program run-time, vector normalization must also be performed during program runtime. Therefore, the Analog Vector Generator performs vector Normalization as part of its operation. (The trio of games consisted of Malibu Grand Prix, BattleZone, and Red Baron.)
Another feature in the AVG used in these games is a Window circuit that allows the programmer to set a window. Vectors that are drawn outside the window are blanked. This was used in BattleZone to keep game vectors out of the radar display.
The way it works is quite elegant. (No, I didn't design it. I think Howard Delman did.) The programmer draws a vector (which can be drawn at zero brightness) to the desired position of the Lower Right Corner of the Window, and issues an HST Command. This operates Sample-and-Hold #1. The programmer then draws a vector to the desired position of the Upper Left Corner of the Window and issues an LST Command, which operates Sample-and-Hold #2.
The outputs of these Sample-and-Hold circuits are used with two sets of Comparators. One set of Comparators compares the current X position to see if it is Less than the X value of Sample-and-Hold #2 as well as Greater than the X value of Sample-and-Hold #1. At the same time, the other set of Comparators compares the current Y position to see if it is Less than the Y value of Sample-and-Hold #2 as well as Greater than the Y value of Sample-and-Hold #1.
If all these conditions are true, then we are inside the Window, and we refrain from blanking the vector.
The Window circuit is active all the time; it cannot be disabled. For a full screen display you simply set the Window to the full screen. This would generally be done anyway to keep the Spot Killer in the XY Monitor happy.
The Window circuit was used in BattleZone and Red Baron. No doubt it would have been used in Malibu Grand Prix if the game had been produced.
Note that the Window circuit could have been used in the Digital Vector Generator.
One circuit that was used in the Analog Vector Generator that could not have been used in the Digital Vector Generator is the Linear Scaling circuit.
Referring back to Figure 18, in the Analog Vector Generator the current X and Y positions are contained in the Integrator Capacitors. If we change VREF we will scale the vectors beginning from that starting point; we do not affect that starting point. (In the Digital Vector Generator, changing VREF would also scale the starting point.) Thus, in the Analog Vector Generator changing VREF will change the linear scale of an object without changing its position.
Figure 23 shows how VREF is controlled using an 8-bit DAC.
However, this method of linear scaling does not change the vector drawing time, so that a vector that is linearly scaled takes the same amount of time to draw as a vector that has not been, thereby wasting vector drawing time. In order to scale an object over a large range, the procedure is to use Linear Scaling down to 1/2; then
bump the Binary Scaling by 1 and restore Linear Scaling to 1.0 . (Binary Scaling does adjust the vector drawing time.) This combined use of Linear and Binary Scaling was used in Star Wars to blow up the Death Star along with one other trick that will be explained later.
The final part of the Analog Vector Generator circuit, which was used in all of the XY games, selected either the regular X and Y signals or inverted versions of the signals. Sometimes it was just a jumper on the board; sometimes it was under software control. This allowed maximum flexibility in doing cocktail games where players sitting across from each other took turns or games in which the monitor was viewed through a mirror.
BattleZone, Red Baron, and Malibu Grand Prix
BattleZone was the first game to earn $500/week on field test. The company gave a party to commemorate this accomplishment. The game was hit of the Amusement and Music Operators Association (AMOA) show in the Fall of 1980 and was released in November 1980. (There was another game at the show that attracted very little attention at the time called Pac Man.) BattleZone sold about 25,000 units.
Red Baron was released in May 1981. It didn't do quite as well as BattleZone; it sold about 300 units. One of those units was in an airport when Wild Bill Stealey and Sid Meier played it and decided they could do better, so they went on to found Microprose.
Malibu Grand Prix was a driving game where you drove around a track. It was loosely modeled after the Malibu Grand Prix go-kart driving centers owned by Warner Communications, Atari's parent at the time. The game was fun to drive; the problem was that as you better at it your playing time went down. In a desperate attempt to salvage it, it was given Sprint steering, from the game of the same name. In a real car, as long as the steering wheel is turned, the car continues to turn. In Sprint steering, the position of the wheel determines the position of the car. It's ok (kinda) in a third person game like Sprint. In a First Person game it's a disaster. Malibu was canceled shortly thereafter.
BattleZone and Red Baron were the first to use the Analog Vector Generator. Starting with them we used a new DAC, the AM6012 by AMD., which was used in all of the Analog Vector Generators until TomCat. Towards the end of TomCat, AMD stopped making the part. Fortunately, there was another part, the DAC32HP made by Precision Monolithics Inc. (PMI). Normally the Components Group evaluated parts to be added to the Approved Vendors List (AVL) but since this was an especially critical part I was asked to evaluate it, which I did, and gave it my blessing. Later, Analog Devices acquired PMI, and they still make the DAC312HP.
The Data Sheet for the DAC312 is here (PDF 270KB). Like the AD561J used in the Digital Vector Generator, the DAC312HP is generally considered difficult and expensive to find. And, like the AD561J, the DAC312HP can be purchased through Analog Devices' Web site (www.analog.com). The DAC312HP costs $6.75 (1's), $5.40 (25's), and $4.50 (100's). (PDF 87KB).
BattleZone and Red Baron both used another item of some interest, the Math Box, which did the arithmetic for the 3D math (multiplies, adds, and divides). The Math Box was built around the AMD 2901 Bit Slice which contained an Arithmetic/Logic Unit, a 16-deep dual port RAM, two registers, and a multiplexer. Each one was only 4-bits but had hooks so that it could be expanded. Four were used to produce a 16-bit machine and they were controlled by another State Machine. The Math Box hardware was designed by Dan Pliskin and programmed by Mike Albaugh. At one time Bit Slices were very attractive to people designing their own computers but have largely been replaced by FPGAs, sometimes implementing the 2901 architecture.
The working title for BattleZone was First Person Tank and then Future Tank. At one time it was to be called Moon Tank. The BattleZone team was as follows:
Project Leader: Morgan Hoff
Programmer: Ed Rotberg (Game Play, also the tank treads)
Hardware Engineer: Jed Margolin (3D algorithms, Object Digitization, Hardware Sounds, "Moon")
Technician: Doug Snyder (also hardware design)
Bit Slice Math Box: Mike Albaugh and Dan Pliskin (For his work Albaugh received U.S. Patent 4,404,629
issued 9/13/83 Data Processing System With Latch For Sharing Instruction Fields)
Analog Vector Generator Design: Howard Delman
Design of 3D Objects: Harry Jenkins and Roger Hector
Volcano: Owen Rubin
Moon : (me). At the time, the game was going to be called Moon Tank which meant that the object in the sky would be the Earth, so I looked in my Almanac and used the East coast of Australia as a model.
Radar: At one of the early game reviews, Gene Lipkin objected to the radar because it looked like the radar in Subs. Since Subs had not been a successful game, Gene was afraid people would associate the radar with Subs, thereby dooming Battlezone. To give it a different appearance, Ed changed the radar so that it scanned from side to side. It looked so dumb that Gene relented and allowed us to restore the original radar.
Engine Sound: (me). I used two counters with slightly different counting periods and summmed several outputs to produce a somewhat disreputable waveform. Since the counters had different periods they produced a beat note when summed. As the frequency of the counters was increased, the beat note also increased. This is what makes the engine throb. The clock was generated by a 555 and had only two frequencies. To control the frequencies I used a circuit to shift the 555's threshhold voltage. This was done with a slow ramp so that the engine sound changed smoothly changed speeds.
Other BattleZone facts:
At one time, early in the game's development, it was configured to permit two people to play head-to-head on one monitor. This was made possible by the Window Blanking circuit. The two-player version was dumped, possibly because the resulting screen size for each player was considered too small.
Battlezone was the first game to use a new development system: the Blue Box and White Box duo. The Blue Box was programmed in Forth and controlled the emulator/analyzer in the White Box. It also had an external 8" floppy disk drive as well as a serial port for connecting to the VAX. Unfortunately, it did not have a full featured editor/assembler. Editing/assembling/linking was originally done on the department's PDP11
Model 20s which placed the output file on an 8" floppy, which could then be loaded by the Blue Box.
Later, when we got the first VAX, the Blue Box could be used as a terminal and the VAX was used to edit, assemble and link the program, and the output could be downloaded into the Blue Box/White Box.
The Blue Box was especially fond of reporting Comm Error 60 when it got confused, which was often.
The Blue Box/White Box replaced the Black Box. With the Black Box system, programed were edited, assembled, and linked on the PDP11 Model 20s, and a paper tape was produced. The Black Box used its Paper Tape reader to load the program.
A few months after BattleZone was released we received a letter from a fan who knew someone who knew someone who had seen someone drive up into the mountains, find a castle, and get a zillion points.
It was news to me. And to Ed.
There was also a rumor that U.S. Army Recruiters used to hang around arcades and when they saw a likely-looking candidate playing BattleZone, would go up to him and ask, "How would you like to drive a real one?"
And finally, I want to mention Doug Snyder. Although he was officially a Technician, he was a skilled hardware engineer. Eventually he was promoted to Hardware Engineer and went on to design the Slapstic Security IC, Growth Motion Object Hardware (used on the G1 board in Hydra and Pit Fighter), as well as many other things. (Between Morgan, Doug, and Howard, there wasn't a whole lot of hardware for me to design in BattleZone.)
Tempest came out in October 1981 and added color. However, the game used the Wells-Gardner Color XY Monitor which did not have pincushion correction, so the pincushion correction circuitry was put on the Tempest PC Board. (This is covered in The Secret Life of XY Monitors.)
Tempest did not have the Window circuit, either because it was not needed by the game or because the board space was needed by the pincushion correction circuitry.
Tempest also used the 2901 Math Box for its 3D calculations.
Space Duel and the Gate Array Space Duel (February 1982) had the pincushion correction circuitry, no Window circuit, no Math Box, and not even Linear Scaling. But it did have something new: the AVG Gate Array, formally known as the Vector Generator Stack and PC Processor. This was a gate array designed by Dean Chang that contained the Program Counter, the Memory File Stack, and the Stack Counter. Figure 24 shows what's in it, followed by the specification of the part. All XY games produced after Space Duel had the Gate Array.
Gravitar (June 1982) had Pincushion Correction and Linear Scaling.
Black Widow was released in February 1983. I don't have a manual so I don't know what's in it.
1.0 SCOPE 1.1 General - This procurement specification defines the requirements for an integrated circuit gate array using Complementary MOS (CMOS) process technology.
1.2 Functional Description The gate array is designed to be the Stack/Stack Jointer and Program Counter for the analog vector generator circuit used in vector type games. The Program Counter (PC) has 14 Bits with Carry Out. The Stack is three levels deep and stores the upper thirteen bits (AVGI - AVGI3) of the Program Counter. (Refer to Figure 2). When the gate array receives control signals from the analog vector generator it executes the JMP, JSR, and RTS Instructions. See attached detail timing diagrams for proper operation. The normal gate array operation is an Increment PC (INC PC) operation which is controlled by ST3 and ST2 signals supplied by external hardware. For the JMP Instruction, /STROBE_2 loads the PC with address data on DVYO- DVY12. For the JSR Instruction, /STROBE_O stores the current PC data onto the Stack, /STROBE_1 Increments the Stack Pointer and /STROBE_2 Loads the PC with DVYO - DVY12 data. For the RTS Instruction, /STROBE_1 Decrements the Stack-Pointer and /STROBE_2 Loads the PC from Stack Outputs. ST2 (LOW) Enables normal Increment PC operation. On the next rising edge of ST3, AVGO will go back to HIGH. The rising edge of AVG0 will increment PC's AVG1 - AVGI3 outputs.
The Stack Pointer is designed to count in the 0, 1, 2, 0, 1, 2 ... etc. sequence, however, since power on can cause the Stack Pointer value to be 3, it is recommended that a "dummy" JSR Instruction be generated before using a real JSR Instruction.
The vector generator circuit has nine instructions with each instruction consisting of either 2 bytes or 4 bytes of data. The op-code field of each instruction resides in the second byte. Since the op-code must be fetched before any instruction parameter field, the Program Counter was specifically designed with AVG0-AVG13 following a 1, 0, 3, 2, 5, 4 ... etc. count sequence. During an instruction op-code fetch cycle, AVG0 is HIGH. After an instruction op-code is fetched, ST2 goes LOW which causes AVG0 to go LOW after the next ST3 clock. This allows the vector generator to fetch the Instruction parameters for current instruction. As long as AVG0 is LOW, the next ST3 clock will bring AVG0 back to HIGH. This LOW to HIGH AVG0 transition will increment AVGI - AVGI3 and consequently the Program Counter will be ready for the next instruction fetch.
Quantum (November 1982) was not designed by Atari. It was one of the two games that came out of a legal settlement with General Computer Corporation of Cambridge, Mass. (The other game was Food Fight.) GCC got into the game business by reverse engineering the Missile Command program and coming out with a new and improved version. Unfortunately, their version still said 'Missile Command' and they got sued. (They were also accused of including some code from the original Missile Command in their ROMs.) Fortunately for them, Atari had an amazing habit of suing people, winning the lawsuit, and paying the (losing) defendants a bunch of money.
Quantum used a 68000, which those of us at Atari had wanted to use ever since it had come out, but were not allowed to because "it was too expensive" and "the 6502 was good enough" and we didn't have a development system for it. Grrr.
Quantum used the Vector Generator Gate Array, Pincushion Correction, and Linear Scaling. My interest in Quantum came when I started TomCat, which I will cover more fully later.
I was at AMOA the year Quantum made its debut. In fact, my booth duty was with Quantum. Quantum was not exactly ready for Prime Time and had a habit of crashing about every 12 minutes, so every 10 minutes I would casually reach into the Quantum cabinet and reset the machine.
After Quantum was released we were eventually allowed to use the 68000. (We used a variant of the 68000, the 68010)
Unfortunately, the move to the 68010 did not happen in time for me to use it in Star Wars.
The Star Wars game came about because I wanted to do a 3D space war game. I mean, I really wanted to do a 3D space war game. It's why I went to work for Atari. Even before going to Atari I had already worked out the math for 3D that did not use Homogeneous Coordinates. The use of Homogeneous Coordinates just gets in the way of understanding what is really going on in 3D.
At my job interview I handed my interviewer (Dave Stubben, the Chief Engineer of Coin-Op) a game description of what I wanted to do. He said that he couldn't promise me that I would be assigned to any particular game. Nonetheless, when I was offered a job, I accepted it. Atari brought me out to Sunnyvale for a second trip so I could find a place to live. (I rented an apartment.)
I almost didn't get to Atari. It was Friday afternoon and the Movers were scheduled to come on Tuesday (Monday was New Years Day). I received a call from Atari's Director of Personnel (Phyllis Pearson). It seems Atari was in some kind of financial difficulty and had just laid off some engineers in the Consumer Division and it had been decided that my job should go to a laid-off Consumer Engineer. I explained that the Movers were scheduled to come on Tuesday, that the day after that I would have no place to live because I had already given up my apartment, and that I was in some financial difficulty myself from having rented an apartment in Sunnyvale. Phyllis said she would see what she could do, and later called back with the good news that they had decided that I was too far in the pipeline for them to flush me (or words to that effect).
I arrived at Atari in early 1979. The first game I was assigned to was Sebring, a driving game that was started ostensibly to use up a supply of old 25" color monitors. It was a sitdown game with a curved projection mirror
made from silvered Plexiglas. Since the curve was set by stuffing a flat mirror into wooden guides, it was optically rather poor, and gave the player a headache. (This was the Mechanical Group's idea of how to make a cheap mirror.) The monitor was mounted on top of the cabinet.
Sebring was a first person game, using the stamp hardware that was used back then. I was the Hardware Engineer, Paul Mancuso was the Technician, and the Game Designer/Programmer/Project Leader was Owen Rubin, one of the great game designers. Owen came up with several innovations that were copied by later generations of driving games:
1. The player drove around a circular track; the hardware made it look like the objects that were farther away were smaller.
2. The player saw the front of his own car, which shook as the car was driven.
3. There were other cars on the track which the player had to get around.
4. The player started the game by starting the engine, which started with a bang, a hardware bug that we liked, so we kept it in.
Paul and I put a large speaker in the front of the seat, between the player's legs which gave the player a nice buzz from the engine sound. Years later, this feature was used by others, who patented it. (Grrr).
Although Sebring did well in field test, it was cancelled because, supposedly, the vender who made Atari's cabinets didn't want to make it. (Perhaps he wanted too much money.)
I believe there was only one prototype, last seen in Paul's possession. I wonder if he still has it.
Another early game was Tube Chase in its XY incarnation. Owen Rubin was the programmer on that one, too. The problem with doing Tube Chase in XY is that there was no way to do hidden line removal. which makes traveling through a tube confusing. Later, Tube Chase was done on Dave Sherman's new circle generator hardware, which drew circles without a bit map. Although Owen finished the game and it did ok on Field Test, by then Atari had several games ready that were considered really hot, so Tube Chase was put on hiatus. Later, it was licensed to Centuri who produced it as Tunnel Hunt. Owen took to referring to Tube Chase as "The Game That Wouldn't Die."
Then came BattleZone, which used a stripped-down version of the 3D math I had developed for my space war game.
Finally, I was given permission to start my game, which I called Warp Speed. Greg Rivera was the programmer; Ed Rotberg was the Project Leader. Then Ed , along with Howard Delman, left Atari and started their own company Vidia, which was later bought by Nolan Bushnell and folded into Sente.
Greg and I needed a project leader and selected Mike Hally. Usually the project leader selects the team. In this case the team selected the project leader.
We went through several technicians until we got Erik Durfey. (It appears that the previous techs didn't want to spend their time on a game that was a guaranteed loser.) Later we acquired an additional programmer, Norm Avellar
At some point Atari Consumer started working with Lucasfilm. I suggested to Dave Stubben that Warp Speed would be a good platform for a Star Wars game. Apparently, he agreed.
Star Wars was field tested around May 1983 and went into production in July. The Star Wars AVG had Linear Scaling and the AVG Gate Array. Here is the Vector Generator Instruction list (PDF 49KB ).
There was something different about the AVG, though.
In order to have the Death Star explode the way we wanted it to, it wasn't enough to draw lots of concentric circles. We wanted to defocus the beam to fill it in. We briefly considered adding a vacuum tube to the monitor to control the Focus Voltage. Fortunately, the lead time for the part was too long. So what I did was to give the Vector Generator the ability to overdrive the monitor's color inputs. Overdriving the inputs causes the CRT to draw more current than it normally uses and drags down the High Voltage., which changes the normal ratio of Focus Grid voltage to Anode voltage, which defocuses the beam. This relationship is explained in The Secret Life of XY Monitors.
Star Wars is different from previous XY games in other ways as well.
The Main Processor is a Motorola 68B09E which I chose because its instruction set is slightly more advanced than the 6502 and because I couldn't use a 68000.
There are three LEDs on the PC Board solely for diagnostic purposes, which Greg and Norm used during development to indicate when certain events were taking place. I think the game was released with them still programmed.
There is a hardware Linear-Feedback-Shift-Register (Pseudo-Random Number Generator) for generating random numbers for star creation. While this function could have been implemented in software, it would have eaten up processor time.
The amount of math that was needed for the game was more than could be done with the Bit-Slice Math Box used in BattleZone, Red Baron, and Tempest, so I designed a new one. The basic function in the 3D math we used is a matrix multiply of the form:
This can be broken down into three operations of the form: