Defender Hardware
This article is about the hardware of the Defender arcade machine from 1981, with emphasis on the sound board, which was originally designed by Eugene Jarvis for a pinball machine. The chips that make up the sound hardware and how they work together is described, and finally, there is a short analysis of the theoretical limits of the sound hardware in terms of sample rate and waveform duration, and how these constraints motivate custom sound algorithms over sample playback.
Defender Hardware
The main CPU of Defender is a Motorola 6809 CPU. It is an 8-bit processor with 16-bit arithmetic instructions, and the original version ran at 1 MHz. The processor was first produced in 1978, and was used in many of William's arcade machines, including 'Robotron: 2084' and 'Joust' (both from 1982). It was also used in the TRS-80 computer and the unique vector-based home console, the Vectrex.
The MC6809 was based on its predecessor, the MC6800, which we will discuss in more detail in the following. MC6800 code can be assembled into equivalent MC6809 machine code.
Looking at the MAME source documentation (src/mame/drivers/williams.cpp), we can learn a little bit about the graphics.
Here is an excerpt from the MAME source listing the part of the memory map related to graphics:
0000-9800 Video RAM
...
c000-c00f color_registers (16 bytes of BBGGGRRR)
These values are in hexadecimal, if we translate to decimal, we get:
$9800 B = 38912 B
That's 38 KB of video RAM. We have a 16 color palette, and have to use 4 bits per pixel to index into the 16 colors, so every byte of video RAM can define the colors for 2 pixels:
pixel count = 38912 B * 2 pixels/B = 77824 pixels
In MAME, the resolution of Defender is 292 x 240, which is 70080 pixels, which would fit in the 38 KB video RAM with 3 KB to spare.
Now, let's take a look at the sound board.
Defender Sound Hardware
Defender was created by Eugene Jarvis, Larry DeMar and Sam Dicker.
Jarvis started working with the Williams sound hardware on the 1979 pinball game 'Laser Ball'. When comparing the instruction manual for 'Laser Ball' (page 23) with the owner's manual for 'Defender' (page 28), it is clear that they have the exact same sound hardware.
The sound board for 'Laser Ball' is a CPU running a program from ROM, reacting to interrupt signals from the game, switching sound rendering subroutines according to which sound should be played, and the active subroutine directly outputting 8-bit samples to a D/A converter, which is amplified and connected to a speaker. It's just about the simplest version of a digital sound card you can imagine.
However, unlike some dedicated sound hardware, the processor in charge of rendering audio is a general purpose CPU, and not a processor that is specifically designed for digital signal processing. This CPU was a Motorola MC6802, a 1977 variant of the MC6800 from 1974. The MC6800 is 8-bit and runs at 1 MHz.
We can compare the sound hardware of this 1979 pinball machine to well-known audio hardware of this time. One of the first commercially available digital sampling systems, the amazing Fairlight CMI, was introduced in 1979. It was used by many famous composers of the 1980s such as Peter Gabriel, and came with a hefty price tag. It was based on two Motorola 6800 CPUs. The same year also saw the release of the Lexicon 224 digital reverb, famously used to create the iconic futuristic soundscapes in 'Blade Runner'. The Lexicon 224 was based on an Intel 8080 CPU (8 bit, 2 MHz).
Using a general purpose CPU meant that rendering algorithms could be written from scratch, without any algorithmic limitations except for memory and CPU speed. Different sounds could use different synthesis algorithms, and this can be heard when playing 'Laser Ball' and subsequent Williams arcade games using similar hardware.
Indeed, the 'Defender' sound ROM contains 10 different synthesis algorithms. This wealth of custom synthesis algorithms is somewhat unique to this era of game hardware, as the dedicated sound hardware that would become standard later, such as Yamaha's FM chips, or dedicated sample playback hardware, would often be limited to variations over a single algorithm.
Another type of device where developers would write their own synthesis algorithms is the PC speaker-based home computers, such as the ZX Spectrum and early DOS PCs. Clever programmers, such as Tim Follin, would write amazing sound routines for these machines throughout the 1980s.
In the following, the sound board and how it works will be explained in detail.
The Dirty Details
The 'Laser Ball' and 'Defender' sound board looks like this:
It consists of:
- a Motorola MC6802 CPU (a MC6800 with 128 B of built-in RAM, and built-in clock, with CPU operations running at 1 MHz),
- a Motorola MC1408 8-bit D/A converter (DAC),
- a Motorola MC6821 Peripheral Interface Adapater (PIA),
- a Harris 7641 2 KB Programmable ROM (PROM)
The MC6802 CPU is running a program directly from ROM, using the built-in 128 bytes of RAM for working memory. When the game code running on the MC6809 CPU requests to play a sound on the sound board, it will set a special value determining which sound to play and then send an interrupt to the sound hardware.
In detail, the steps of that process are:
- The index of the sound effect is written by the main MC6809 CPU to the 'SOUND SELECT INPUTS', and stored by the PIA.
- The main MC6809 CPU triggers an interrupt in the sound board MC6802.
- The interrupt causes special code to be run on the MC6802. This code reads the 'SOUND SELECT INPUT' from the PIA.
- The MC6802 jumps to a section of code corresponding to the 'SOUND SELECT INPUT' value.
- From that point on, the MC6802 code will write 8-bit values to a special address $0400, that the PIA sends directly to the MC1408 D/A converter
- The MC1408 turns the 8-bit value into a current, which directly controls a speaker.
The MC6802 will continue to output 8-bit values to the D/A converter until a new interrupt is sent from the MC6809.
To motivate the need for synthesis over sample playback on this hardware, the limitations of this hardware is investigated in the following.
Limitations
In the Defender sound board, we have a 1 MHz 8-bit CPU with 128 B RAM and 2 KB ROM that outputs 8-bit mono samples directly to a DAC. We may ask ourselves what the limitations of such a system is, does it output samples at a high enough rate to reproduce legible sounds? And would it be able to reproduce sampled waveforms?
Dealing with the first question, the sample rate output by this sound board is variable, determined by the speed of the subroutine that outputs sound samples. The MC6800 was certainly fast enough to render a single voice of a virtual synthesizer in real-time, and as another article will show, it is also fast enough to render multiple voices at the same time. A theoretical limit to the sample rate can be determined from the fastest possible algorithm that outputs varying samples to the DAC. I am not an expert MC6800 programmer, but something reasonably close to the fastest possible algorithm would look like this:
ldaa #$00 ; Value = 0
staa $0400 ; Output value to DAC
ldaa #$ff ; Value = 255
staa $0400 ; Output value to DAC
...
It's a non-looped algorithm where the samples are written directly as constants in the code. Not very space-efficient, but should be close to perfectly optimized. Here, the special address $0400 is used, which is the address that the PIA of the Defender sound board maps to the DAC. So, when writing a value to address $0400, we output directly to the DAC.
The algorithm can be analyzed for CPU cycles of the instructions:
ldaa #$00 ; [2 cycles]
staa $0400 ; [5 cycles]
ldaa #$ff ; [2 cycles]
staa $0400 ; [5 cycles]
...
That's 7 cycles per sample output. The MC6802 runs at a clock speed of 1 MHz, so we have:
1 MHz 1000000 cycles/s
------------ = ---------------- ~ 142857 smp/s
7 cycles/smp 7 cycles/smp
A sample rate of over 140000 Hz is more than enough for high-quality audio, but of course, with more complex subroutines, the sample rate is reduced greatly.
The sound board is obviously able to output an 8-bit sampled waveform at a very high rate, but the big problem at this point is memory. The 128 B built-in RAM of the MC6802 doesn't really allow for any recognizable sampled sound, e.g. if we assume that we use 8-bit samples (which takes up 1 B of memory per sample) and a reasonable sample rate of 20 KHz, we get:
128 smp 128 smp
------- = ----------- = 0.0064 s
20 KHz 20000 smp/s
That's 6 ms of audio. If we were able to use the entire 2 KB ROM for sample data, we get:
2 KB = 2048 B
2048 smp 2048 smp
-------- = ----------- = 0.1024 s
20 KHz 20000 smp/s
This makes it clear why this audio hardware doesn't play sampled waveforms. Even when using the entire ROM for sample data, we would only get a tenth of a second of audio out of it (at 20 KHz sample rate). Memory constraints makes algorithmic audio much more attractive, which in turns makes the audio implementation that more interesting to study.
References
