Robotron 2084 notes
A few years ago I bought a Robotron 2084 upright arcade machine. Out of curiousity to understand the various nuances and bugs in the game, I disassembled the code and commented it. I planned to add a few features, such as a pause button, since I can play indefinitely and wanted a way to save games. Other features I am considering are harder modes, adding new enemy types, showing numerical counts of men left, and many others. However all the additions are still far off.
This page is about Robotron 2084, internals, algorithms, ROM hacking, and whatever else I find time to post.
Sound analysis 1
Over the weekend I returned to playing with the disassembly, and decided to
understand how the sound works. Sound is created by a second CPU on what
is called the
Williams sound board;
you can find schematics online. This board is used in the Williams games for
Defender, Stargate, Robotron, Joust, Bubbles, Blaster, Sinistar (with
added speech components). The board uses a Motorola 6808 (or 6802) CPU,
has 128 bytes of RAM (addressed 0-127), 2K of ROM at addresses
0xF000-0xFFFF (more ROM in later games), and a simple 256 level D/A converter
that runs the speaker output, written to by
writing to address $400. The CPU runs at 894750 cycles per second, so
sound is produced at this many samples per second.
The sound program consists of many parameterized routines that share the lower RAM. The architecture is that a Interrupt ReQuest (IRQ in 6808 docs) is generated each time the game CPU sends a command to the sound CPU via a shared 6821 PIA chip. The PIA has a 6 bit wide bus, resulting in a technical limitation of only being able to send commands in the range 0-$3F to the sound board.
The IRQ handling routine resets the stack, killing any sounds already running (with the exception of a weird method to layer some sounds, not to be discussed here today). It then filters the command 0-$3F to various sound algorithms. Often multiple commands result in the same algorithm, but with different parameters.
For fun, I carefully cycle reconstructed one of the parametrized sound algorithms in C#. It works by running various loops whose lengths are functions of the parameters. As 6808 instructions execute, their cycle counts add delays, effectively copying the current sound level over and over again to a queue, to be played back at the rate of 894750 samples per second. Here is a single parametrized sound generator algorithm. Note some values of the input might cause infinite loops or other problems, so be prepared.
This code takes 7 byte parameters and one 16-bit parameter, and generates a sample at 894750 samples per second. To convert the raw data to a WAV for playback, perform decimation (or downsampling) to reduce to a easier to use rate, such as 44.1khz, and save the data as WAV or whatever format you desire. Here are some parameter sets found used in the game (click each to hear generated 44.1khz WAV files)
And there you have the precise algorithm for a few of the Robotron, Defender, Stargate, etc. sounds. Hopefully one day I'll write up more of them for everyone to enjoy.
Note to lawyers: the above code is not Williams code, but completely new code I wrote. The sound files posted are not recorded from Williams arcade machines nor are they generated using any Williams hardware. They are generated mathematically from the original code I wrote above. Interesting, huh?