In my last Vintage post I talked about the first commercially available fully assembled PCs and ended with the Space Invaders video game console. In this blog post I’m going to talk about a few other video games.
Galaga
I spent so many quarters on Galaga that I probably bought the company owner his/her yacht. I went searching around the Web looking for schematics (which didn’t take too long) and stumbled onto this site (click here). The schematic for Galaga is a PDF that you can download by clicking here. When I first opened the schematic I immediately noticed that the CPU board contained three Z-80 CPUs. These guys were serious! At that time, this game probably cost a lot to manufacture.
You can learn a lot about the original video game from people who collect and repair these games. Here’s a website that has some interesting material on Galaga: Galaga Information. The best site on the design of the game is at the Computer Archeology site. This site has the assembly code from the EPROMs used by all 3 CPUs and indicates that CPU1 and 2 control the game while CPU3 is the sound processor. All three processors share 8k of static RAM (using 2147 memories).
There are custom chips on the boards that are used for various functions. One function is the bus driver chips that interface between each CPU and the common data bus.
There are three of these chips used and I’m assuming that the logic connecting to them is used to interlock between the three so that only one can access the main bus at a time. What I’m uncertain of is how the bus is shared. There is a 6Mhz clock signal that is fed into all three chips, so maybe each CPU gets 1 or 2 clock cycle each turn? The Z80 chips are normally clocked at 1Mhz, so it would make sense to run the bus at 3x or in this case 6x the CPU frequency and then do a round-robin. Each CPU can be programmed as though it had complete control of the address and data bus.
For information on the custom chips, I found this site: The Defender Project.
Finally, here’s a blog describing an arcade emulator that Paolo Severini built using javascript:
Defender
This video game was a horizontal shooter game with a video resolution of 360 x 240 pixels at 16 colors from a palette of 256 total colors (according to the manual, which can be found here). Here’s a snippet of the color RAM circuit:
The TTL 7489 is a 16 bit memory used to store the palette information. You can see where the 8 outputs from the ram (4 bits from each chip) feed the analog Red, Green and Blue circuits used by the monitor. It appears that the blue gets the least amount of control with only 2 bits, or 4 levels, while the Red and Green receive 3 bits or 8 levels of information. The 74LS257 at the left of the circuit diagram is a multiplexer. The job of that circuit is to allow the microprocessor to access the 7489s (and use the MPU data bus to load data) or allow the video circuitry to access the memory to display on the video monitor. The microprocessor can only write to the memory during a monitor blanking operation.
At the top of the Red, Green, Blue amplifier circuits is another transistor. This transistor shuts off the power to all three amplifiers and is controlled from the horizontal blank signal. If you’re not familiar with the old video tubes, basically, there is a beam of electrons that are fired at the front of the screen. The inside of the tube is coated with phosphor and it glows when electrons hit it. The beam is “steered” by magnets on the neck of the tube. The beam is moved in a horizontal line pattern starting from the top left of the screen and ending at the bottom right. When the beam returns to light up the next line of phosphor, it has to be shut off, otherwise an angled beam would be drawn on the screen. The beam is also shut off when it returns to the top left from the bottom right.
Unlike Galaga, Defender uses only one CPU and it’s a 6809 processor. The game program is stored in ROM like other video game boards (no need for a hard drive). There are two versions of Defender and both versions contained 26k of ROM (in different configurations of 4k and 2k ROM chips). There are three banks of RAM used for video memory and scratch pad memory. All RAM used is the 4116 dynamic RAM organized as 16k by 1 bit. If you look at the schematic it appears that banks 1 and 2 are just 8 chips (4L-4S), but the diagram represents two chips per location (5L-5S). Bank 3 is wired a bit different from banks 1 and 2. The data bus is connected through a multiplexer.
The video RAM is fed into 4 8-bit serial shift registers. All three banks of memory go into these shift registers at one time.
The TTL 74165 is a parallel load, serial out shift register circuit. According to the circuit above, 6 bits are loaded at a time into each shift register. Two bits from each bank per shift register.
If you read through the manual, you’ll stumble onto the E and Q generator. These are 1Mhz clock signals that are out of phase from each other. The purpose is to interleave the CPU and video access to the video memory. During one clock cycle the CPU (call MPU in the manual) can read and write to the memory banks. During the other clock cycle, the video timing circuit reads the memory banks into the shift registers.
Here are some other sites with information about Defender:
Asteroids and Battlezone
The unique aspect of these two games is that they use vector graphics. If you don’t know what vector graphics are, you can think of it as a bunch of lines drawn on a screen instead of a grid of pixels. The maximum number of lines that can be drawn on the screen depends on the speed that lines can be drawn in 1/60th of a second, which is the refresh rate of the video screen. The circuitry for generating the images seems pretty simple: Run down a list of 2D vectors and output the x,y coordinates to the screen. Video tubes operated on a X and Y or horizontal and vertical magnets that “steer” the electron beam to the phosphor coating in the front. The circuitry to run this is a bit more complicated. Basically the vector graphics are driven by a digital to analog circuit that is independent of the CPU. This circuit calculates all the intermediate values of x and y for each line that is rendered on the screen. There is a state machine that performs all of this logic, which is detailed in this document: The hitch-hacker’s guide to the Atari Digital Vector Generator. The last page shows the states:
The DVG was a special purpose processor built out of discrete TTL components in order to run a vector graphics system. The DVG had 7 operation codes:
- VCTR – draw long vector
- LABS – load absolute x,y coords
- HALT
- JSRL – jump to subroutine
- RTSL – return from subroutine
- JMPL – jump
- SVEC – draw short vector
There is also a “Z” axis circuit. This determines if the beam is on or off and there are also different intensities to represent different shades. Both games are black and white, so there is no color. Here’s the intensity scaling circuitry:
The intensity has a range from 1volt to 4 volts and can be any of the 16 shades in-between. Scale0 through Scale3 are bits of a 4-bit word. The bottom part of the circuit above is the blanking circuit. This is controlled by the BLANK signal, or the BVLD which means beam valid. If either signal indicates that the beam should be off, then Q8 will turn on and force Q9 to turn off and block any signal coming from the intensity circuit.
You can get a more detailed (and clean) schematic and description of the DVG by clicking here.
There’s an interesting article on the making of asteroids by Ed Logg, Howard Delman and Lyle Rains, the people who created the game (click here). You can click here to download the schematics for Asteroids and click here to download the schematics to Battlezone. If you want to know more about the software side of Asteroids you can go to the Computer Archeology site. This site shows the data that the ROMs contained describing the vector shapes of things like the asteroids, the flying saucer, the ships, etc:
The CPU used for both games is the faster 1.5Mhz 6502A. Only a single CPU is used for the game. There is a small amount of RAM using 2114 static RAM chips. There are two sets of ROMs used. One set contains the vector shapes as described above (4k) and the other ROMs contain the program to run the game (8k?).
When these video games were designed, microcomputers were not very powerful and it required a PDP-11 to create the program that would be used by Asteroids and Battlezone. This program was punched onto a paper tape and then loaded into an emulator. Paper tape was like a cheap floppy disk. Networks were not very common in the late 70’s, early 80’s, so a cheap method of copying programs was needed. While PC began to use 5 1/4″ drives, there was also an 8″ drive that came out (the 8″ came out in the mid-70’s just before the 5 1/4″ drive). Here is a very interesting article about the day to day work environment at Atari while working on coin-op arcade games: Pay No Attention to those Folks Behind the Curtain. This article also includes emails from Jed Margolin, who worked for Atari and Atari Games for 13 years.
For those who have never seen paper tape or punch tape readers, they were used by the military in the 80’s. The machine could punch 8 holes wide (there are other tape formats) to represent a byte of data:
The image above is from the crypto museum. When the machine punched the tape the little holes were punched out at high speed like a paper punch tool. This leaves a bunch of round circle “holes” that go into a collection bucket for emptying. That bucket is called the “bit bucket”:
By Retro-Computing Society of Rhode Island – Own work, CC BY-SA 3.0
Nice Post…
I’m having very interesting information regarding bowling alley in India and Arcade Game Machine Provider in India!