(back to project page)

Missile Command Video Memory

Missile Command's display has some unusual characteristics. The display width is a friendly 256 pixels wide, but the height is an odd 231 lines (4:3.61 ratio). It uses a typical indexed color scheme, with an 8-entry palette. Most of the screen has 2 bits per pixel and so can only show 4 at a time, but the last 32 lines of the screen support 3 bits per pixel, so all colors can be shown. The colors in the palette can be changed on the fly, providing low-cost color-cycling animation for highlights and explosions.

While many other contemporary games used sprites or vector generators or other hardware tricks to speed up rendering, Missile Command just plots pixels into a frame buffer. It does, however, have one trick up its sleeve.

Most instructions that access RAM will see the 2bpp pixel buffer from $0640 to $3fff, with the 3rd bit stored from $0200 to $05ff. When an instruction whose opcode has the bit pattern %---00001 takes more than 5 cycles, however, the hardware asserts the MADSEL (Multiplexed Address Select) signal. This remaps the memory access so that addresses from $1900 to $ffff provide a linear view into the frame buffer, with one byte per pixel (%XY0----- for 2-bit areas, %XYZ----- for 3-bit areas).

To trigger MADSEL accesses, the code will use indexed indirect addressing mode instructions, i.e. "LDA (zp,X)" and "STA (zp,X)". These have opcodes $81/$a1, and always take 6 cycles on the 6502. Almost all rendering in the game is done with MADSEL mode, the only exceptions being clearing parts of the screen and scrolling the text at the bottom while in attract mode.

MADSEL is slower for bulk writes, like erasing the screen, because it changes one pixel per byte rather than 4 or 8. When setting individual pixels it's faster, because the address calculation is simpler and it isn't necessary to read the existing pixels and mask away the bits that don't change before setting the new value.

Colors

In the normal (non-MADSEL) view of video memory, the 2bpp RAM area stores 4 pixels per byte, split across the high and low nibbles. If the bits in the first byte are %ABCDEFGH, then the color index for the pixel at X=0 would be %00000DH0, X=1 is %00000CG0, etc. This means the 2bpp areas use the even-numbered entries in the palette.

The 3rd pixel bit is a bit more convoluted. There are 8 pixels per byte, but the memory map puts the first 16 lines in the even-numbered bytes, and the last 16 lines in the odd-numbered bytes. Within a byte %ABCDEFGH, X=0 would use bit H, X=1 would use bit G, etc. The value is combined with the 2bpp data as the low bit, allowing use of the odd-numbered palette entries.

The color palette is 3-bit RGB. The values have the form %----RGB-, where 0=on and 1=off. This yields:

Missile Command is available in a "cocktail" cabinet, for which players sit on opposite sides during a 2-player game. This requires rotating the screen 180 degrees, which can be done by flipping the graphics vertically and horizontally. The vertical flip must be done in hardware because of the 3bpp color zone, but the horizontal flip is done in software. (Not everything is flipped; for example, the city backdrop will be mirror-imaged for cocktail player 2.)

Palette Usage

While playing the game, most elements appear in one of four colors: one for the background, two for "stable" foreground elements, and one that is updated on every frame. (The palette entry is simply incremented. Because colors are xxxxRGBx, it changes visibly every other frame, so it's actually cycling at ~30Hz.) The set of palette entries that cycle is determined by a bit mask (stored at $ec).

The colors in the palette are determined by the wave number. On the first wave, the background is black, the incoming missile trails are red, and player missile trails are blue. On the 3rd wave, the incoming missile trails are green instead.

The color assignments used for wave 1 are:

The list of colors used for each wave can be found on the wave guide page.

The code that draws explosions is careful to preserve the 3rd bit. This prevents explosions from eroding the city backdrop. Because the cities are drawn with odd-numbered palette entries, explosions that cover a city briefly obscure it (because palette entries 4 and 5 are cycling at the same rate), then replace the city colors (3/7) with the background color (0/1). This leaves the city outline in the city-backdrop color, creating the sense of wreckage rather than an explosion-shaped hole. The code that draws the missile head and trail does not do this, so you'll see a small divot in the city outline where the missile hit.

The code that erases the crosshairs will restore the previous contents, unless it appears that something drew over the crosshairs (based on the pixel color). This is why you can move the crosshairs over things, like the text at the start of the wave or the flashing target 'X', without erasing it from the screen.

Video Memory Line Start Addresses

This table shows the location in memory where line N starts. The "Addr" column shows the MADSEL-mode address, while "Bit2" and "Bit3" show the address in "normal" address decoding mode.

The software treats line 0 as being at the bottom of the screen. This makes the calculation of the base address trivial. For the 256-bytes-per-line mode, you simply take the line number, exclusive-OR it with $ff, and use that as the high byte of the pointer (the bottom line starts at $ff00). For the 64-bytes-per-line mode, you set up the pointer the same way, then divide by 4 (the bottom line starts at $3fc0). Accessing the 3rd pixel bit in "normal" memory is more complicated, but that's done infrequently, with the address hard-coded into the instructions.

Copyright 2021 by Andy McFadden