I became interested in video games in the middle 1970s while I was a radio engineer at WUOM (Ann Arbor).

I developed my first project using a KIM-1 single board computer, which had a 1 MHz 6502, two 6522 PIAs, and 1K Byte Program RAM.

It also had a built-in hex keypad and a six-character LED readout. A serial  port permitted the use of a teletype. (Real video terminals were very expensive.)

Program (hex) code could be entered using either the serial port or the hex keypad.

Fortunately, there was a way of storing the program: a standard audio cassette recorder. It worked surprisingly well. Well, at least it was better than entering the program hex code every time you wanted to run a program.

I had an Ann Arbor Terminals video display unit that did 16 lines of 32 characters. Dynamic RAM was just coming out and was expensive, so the unit used MOS dynamic shift registers for screen character storage. The data in the screen memory specified the character to read out from the character ROM.  At the end of each display line the dynamic shift registers had to quickly shift through the remaining stages to get back to the first character at the beginning of the current character line.

With the shift register method, one of the factors that limit the number of characters you can put on a line is the speed of the shift registers.

Perhaps an example is in order.

Sixteen lines of thirty-two characters yield 512 total characters.

Assume you are at the end of character line 1 (character 32) and are displaying the first scan line in the character.

On the next scan line you need to display the second scan line of character 1. Thus, you have to clock the shift register 512-32 = 480 times to get back to character 1.

This has to happen during Horizontal Blanking which is 12.5 us for NTSC.

(By the way, memory was way too expensive to use a display buffer unless you were building simulators for the military.)

Complementing my Ann Arbor Terminals Display Unit was a keyboard I built from a kit from Southwest Technical Products, the people who introduced the Altar Computer. They also gave Bill Gates his start. The keyboard used diodes to decode the key matrix and thus had zero-key rollover. (If you pressed two keys at the same time you got scrambled data.) The keyboard had only parallel data output so I added a General Instrument UART.

After using my video terminal for a few days, I went back to the hex keypad. It was faster.

Because memory was too expensive for a frame buffer and processors were too slow to do much with one anyway, I used what was known as the "stamp" technique. (I called a stamp a "matrix" .)

I started with a standard NTSC sync generator IC (National Semiconductor's MM5320) and used counters to indicate the horizontal and vertical position of the beam. (The X and Y Display Address Registers)

In order to get a square matrix I needed to use a bit clock (6.4 MHz) that could not be easily derived from the master sync clock which was needed in order to produce NTSC compatible color, which is derived from 14.31818 MHz.  (14.31818 / 4 = 3.579545, which is the color burst.)  I used a specially ground crystal, not realizing that the clock for the MM5320 could have been divided down from 14.31818 Mhz.

I generated the 6.4 MHz bit clock by using a separate RC oscillator using an inverter with a Schmitt trigger input. To prevent a one-bit jitter I used horizontal blanking to disable the oscillator, hence the use of a 7432 Quad Two-Input NAND gate with Schmitt trigger inputs). That way the oscillator always started oscillating from the same state at the beginning of each line. Hence, no jitter

A pair of comparators compared the horizontal and vertical position counters with a set of horizontal and vertical latches (the X and Y Matrix Address Registers). When the horizontal position counter matched the horizontal position latch and the vertical position counter matched the vertical position latch I started the readout of the contents of an EPROM. There was other circuitry to cause an 8 x 8 matrix (stamp) to be displayed.

I used one of those new-fangled  EPROMs  the 1702A. After designing a number of 8 x 8 space ship matrices in different orientations I sent a typed list to a company I found in an ad in Popular Electronics. They sent me back a programmed 1702A.

The game I developed was a two-person space war game. There were two versions: one with gravity, one without. The one without gravity was more fun.

Each player had their own control, which was a piece of PVC conduit with switches mounted to correspond where your fingers are, and with several LEDs to indicate fuel status.

I mounted a small speaker in one end of the control. The square wave produced by my sound generator ( a 565) combined with the acoustic filtering of the tube to make it sound like a beginner's clarinet.

This project resulted in U.S. Patent 4,179,124  ELECTRONIC VIDEO GAME.
 

The noise generator used a Linear-Feedback-Shift-Register (LFSR).  A LFSR is a shift register where the outputs of two or more of the stages are linearly combined and fed back to the input. If you are using a digital shift register the possible values are '0' and '1' . Furthermore, if you are only using two stages, the digital adder reduces down to a single Exclusive-Or gate.

The interesting thing about using only two feedback stages is that there are shift register lengths which, if you use the proper stages for feedback, produce a maximal length sequence. This means that for a shift register of length 'n' the LFSR cycles through (2**n)-1 states before repeating the sequence. All states are produced except for the special case where all stages are '0' .

The sequence produced by a LFSR appears to be random. It isn't, if only for the fact that if you knew the number of stages, the feedback taps used, and the initial state, you can predict with absolute certainty what the next sequence will be. Also, a mathematician could probably analyze the sequence and tell you it is not random. That is why it's called a pseudo-random sequence and a LFSR is frequently called a pseudo-random number generator.

Despite this, when you listen to the bit stream, it sounds like good old white noise.

If you think LFSRs might be good for encrypting data, you are right. You can take a data bit stream, Exclusive-Or  it with the bit stream from a LFSR. To decode it you again Exclusive-Or it with the bit stream from a LFSR. However, this only works if you know the correct size of the original LFSR, the taps used, and the initial state of the LFSR. If you have everything except the initial state you are generally out of luck. Of course, you could try to guess. A 16 bit LFSR has (2**16)-1 (65535) possible different initial states. That doesn't mean you will have to try all 65535. You might get lucky and get it on the first one. A 32 bit LFSR has more combinations. (You do the math on this one.)

The DES standard uses several LFSRs and has a 56-bit key. DES is way obsolete. Current encryption methods use 64 or even 128 bits.

Remember when I said that a LFSR always produces the same sequence when started from the same initial state?

Well, if you always set the LFSR to the same initial state at the same time corresponding to a point in a raster you always get the same pseudo-random sequence.

When added to the video this shows up as a stationary random pattern which can represent 'stars'. By decoding the outputs of the LFSR you are able to select the density of the star field.

What's even better, if you move this initialization point in the raster along a horizontal scan line, the star field moves horizontally along with it.

What's more, if you move the initialization point to the next scan line, the star field also shifts down one scan line.

Thus, you can generate a star field with nicely random stars that you can scroll both horizontally and vertically. Remember, this is all done without a frame buffer, just a simple LFSR.

In addition, the stars in the star fields can have different brightnesses. There are two ways to do this.

1. Decode some more bits in the LFSR output and use them, along with some resistors to make a simple DAC.

2. Use these bits to select the pulse width of the dots that represent the stars.

This works because of the following. The bandwidth limitation of a video signal means that there is a minimum length line that will be shown at full brightness. If the width of the line is less than this minimum size, the line on the screen will not become shorter, it will remain at the minimum length, and only become dimmer.

This work resulted in U.S. Patent 4,159,293  RANDOM DOT GENERATOR FOR RASTER SCAN VIDEO DISPLAYS.
 

When I sent my patent applications around to companies in the Video Game industry no one was interested in them. However, Atari asked me if I wanted to work for them. At that time I wanted to do a 3D space war game so I brought a game proposal (197 KB PDF) to my job interview. When they offered me a job in the Coin-Op Division I accepted.

I worked for Atari and then one of its successor companies (Atari Games) for 13 years, designing hardware for coin-operated video games.

The first game that I worked on that was produced was BattleZone (1981). However, since I did not receive any patents for my work on the project, perhaps I will discuss it (and Army BattleZone) some other time.

The next game I worked on was the 3D space war game that brought me to Atari. The game was Star Wars (1983). Again, I did not receive any patents for my work on the project.

After Star Wars, I got conned into joining the Firefox project late in the game (late 1983). Even after all this time no one likes to talk about Firefox. The only good thing about the project was that I met Clint Eastwood.

After Firefox I worked on a new XY flying game called TomCat (1984). Despite its advanced features it never made it out of the lab because XY had been pronounced 'dead'. The advanced features included a 68010 main processor, a Texas Instruments TMS32010 DSP, a clock/calendar IC,  as well as a parallel game link that allowed several games to be linked together. I have the only prototype plus the parts to put another one together.

In 1986 I joined a project team working on a driving simulator game that ended up being called Hard Drivin'  (1989).

The core project team consisted of Rick Moncrief, Max Behensky, Stephanie Mott, Jed Margolin (that's me), and Erik Durfey. There was also a large supporting cast. If you press the Abort Switch on a Hard Drivin' while it is in Attract Mode you will see the list.

Although Hard Drivin'  was a raster polygon game I was able to use many of the things I had learned and developed for TomCat.

Hard Drivin'  used a 68010 main processor, a Texas Instruments TMS34010 Graphics Signal Processor for the graphics engine, an Analog Devices ADSP-2100 DSP for graphics math, and another TMS34010 solely to do the calculations for the car model. This is what made Hard Drivin' drive like a car. Although the TMS34010 was intended as a graphics engine, it was actually a very useful 32-bit processor with a nice host interface. It also had a C Compiler.

When used as TI intended, the TMS34010 used for the graphics engine would not have been fast enough for the game. It had a 16-bit memory data bus, so the number of pixels you could fill in one memory operation depended on how many bits per pixel you used. If you had 4 bits per pixel you could fill a maximum of 4 pixels per memory operation. Four bits per pixel were not enough. And even then it was too slow.

To speed things up I took advantage of memory granularity. VRAMs were originally 64K x 1. Then they were 64K x 4. Those were the ones I used. In order to have enough memory for screen buffers that were  512 x 384 x 8 bits I needed 32 VRAMs. (The TMS34010 also used the VRAM memory for its program.)

So I paired them up as 16 banks of 64Kx8.

By telling the TMS34010 that there was only one bit per pixel it could select 16 pixels per memory operation. In this mode, the actual color came from an 8-bit color register.

That required one memory organization.

However, making the pixels come out in the right order when shifted out of the VRAM shift registers required a different organization.

In addition, since the TMS34010 also used the VRAM for program storage, it required yet another memory organization.

Fortunately, the TMS34010 had a huge memory space, so I switched the memory organization according to the memory space used.

Programs used one memory space, polygon creation used another, and Graphic Display used a third. The memory organization was changed dynamically according to the address being selected. (I guess you would call it a dynamic dynamic memory.)

The first prototype used a handful of buffers. Later, Don Paauw put everything in a gate array, along with enough security features the keep the pirates occupied for awhile.

Hard Drivin' had a separate Sound Board with a 68000 (not a 68010), a TMS32010 DSP, and lots of room for EPROMs for wave tables.

It appears that the schematics for the Sound Board (987 KB PDF) never made it into the game manual, so I am posting them here.
 

Race Drivin' was produced in 1990 and was a major upgrade with more tracks and a more accurate car model as a result of an upgraded DSP. The new DSP (an AT&T DSP32C) is faster and has floating point. (The TMS34010 does not.) And further, because Max had programmed the car model in C, he was able to port it to the new DSP in an afternoon.

Race Drivin' came with the ability to link two games together. All you have to do is connect them together with a Null modem Cable and make the appropriate selection in the Operator Screens in Self-Test. (Some early production Race Drivin's don't have the link capability; they would just need a few EPROMs in order to link.)

Race Drivin' Panorama came out around 1991. It had three displays to present the player with a wrap-around view. This was done by using three hardware sets. The Center Hardware simply used the game link to tell the two side displays where to look.
 

The last game I worked on at Atari Games was Steel Talons (1992) which used the lower cost Hard Drivin' hardware that I developed for Hard Drivin' Compact and Race Drivin' Compact.
 

The patents that came out of this work (which list me as a co-inventor) are as follows:

[Behensky, Moncrief, Margolin, and Mott]  5,005,148    April  2, 1991   Driving Simulator With Moving Painted Dashboard
 

[Moncrief, Mott, Behensky, and Margolin]  5,354,202   Oct 11, 1994    System and Method for Driver Training
 

[Moncrief, Mott, Behensky, and Margolin]   5,577,913 Nov 26, 1996 System and method for driver training with multiple driver competition
 

One more thing. These games all use a 48Z02 Zeropower RAM and a 48T02 Timekeeper RAM.

The 48Z02 Timekeeper is a 2K x 8 RAM with a lithium battery packaged together. The 48T02 is a 2K x 8 RAM plus a realtime clock/calender with a lithium battery packaged together. They are used to store a variety of things, including control calibration and operator settings.

If you own one of theses games, the batteries have probably long since died. When that happens it is necessary to calibrate the control every time you power-up the game, which is a real pain.

The easiest solution is to buy new ones. They are currently available from Mouser Electronics (www.mouser.com) .

If, by the time you need them they are no longer available there is a way to replace the batteries. It's not easy. This is how.
 

If you have made it this far you deserve a bonus.

U.S. Patent 2,455,992 issued December 14, 1948  to Goldsmith, et al. is entitled CATHODE-RAY TUBE AMUSEMENT DEVICE and may be the first video game patent. The work was done at Allen B. Du Mont Laboratories which was famous for its oscilloscopes and was an early television pioneer. (They even had their own TV network.)

The way it works is that targets, such as pictures of airplanes, are physically placed on the screen.

The beam of the electrostatically deflected CRT is moved around the screen.

When the beam passes through a target, the player presses a switch which causes the beam to be defocused, making a large spot. There doesn't seem to have been any "collision detect" or "scoring" circuitry.

The game used vacuum tubes since the transistor wasn't invented until later in the year, and when the transistor was announced it did not attract very much attention. In any event, the early transistors were not what you would call "high performance."

The game didn't use a computer. In 1948 the most powerful computer in the world was the ENIAC (Electronic Numerical Integrator and Computer) designed by John V. Mauchly and J. Presper Eckert for the Aberdeen Proving Ground, part of the U.S. Army Ordnance Department. It seems that when the Allies invaded North Africa in November of 1942, the firing tables for their artillery pieces were off because the ground was much softer than the ground used to calculate the original tables. (Sand will do that.)  ENIAC was all electronic; the memory used vacuum tubes, 17,468 in all. (Previous computers used mechanical wheels and gears.) It was unveiled in February 1946 and was a huge success. Although it was used mainly to calculate firing tables for artillery, it was also used in weather prediction, the design of wind tunnels, and in studies for the design of thermal ignition for nuclear weapons.

In 1948 both TV and FM Radio were just getting started again, their early commercialization having been being put on hold during the Second World War.

In the final analysis, Goldsmith's video game was just too far ahead of its time.
 

As an additional bonus I am posting the minutes from a game planning meeting that my department had in February 1983.

Note 1: The Create-a-Monster Game was originally proposed by Mike Albaugh. It probably couldn't have been done with the technology available back then. Possibly, it could be done now. The 'Net might be a good place for it.

Note 2: The Star Wars game wasn't produced until August 1983.