lomont.org

(Also lomonster.com and clomont.com)

Robotron 2084 notes

Intro

Oct 2011

 

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

Oct 2011

 

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?