Missile Command

Embedding

Missile Command is a single MOS 6502 at 1.25 MHz (10 MHz / 8) driving a bitmapped raster display: 256×231 visible pixels, three colours per pixel from an eight-entry palette. This build vendors a self-hosted machine (no CDN): a JavaScript port of Mike Chambers' public-domain Fake6502 core, our model of the Atari bus / bitmap video / palette hardware, and the original Atari program ROMs, driven from a host-owned loop so the debugger can control it.

Boot. The 12 KB of program ROM loads at $5000–$7FFF. The board only decodes 15 address bits (global mask $7FFF), so the 6502's reset vector at $FFFC folds down to $7FFC; the CPU starts at $7B4B and drops straight into attract mode:

var m = new MissileMachine(); // loads ROM, builds 6502 + bitmap video
m.reset();                    // pulls the reset vector at $FFFC (-> $7FFC -> $7B4B)
// one frame: 4 IRQ slices (~240 Hz), clocked off 32V, then render the bitmap
for (var s = 0; s < 4; s++) { m.tickTrackball(); m.cpu.irq(); runCycles(4800); }
m.renderTo(ctx, W, H);

The machine is plain objects. Everything the host and debugger need is a field or method on the machine or its CPU:

Video. RAM $0000–$3FFF is the frame buffer: 256 lines of 64 bytes, 4 pixels per byte. The bottom 32 lines carry a scattered 3rd colour bit. Each frame the loop runs one display's worth of 6502 (four IRQ slices), then renders the bitmap straight from that RAM; the zero page and stack live in the top, undisplayed, lines exactly as on the real board.

Debugger integration

The debugger drives a host-owned run loop: because the 6502 interpreter runs one instruction at a time, the loop can pause, single-step and check breakpoints between any two instructions. window.EMU_BOOT.transport exposes the controls the shared debugger calls:

• pause / resume / isPaused -- stop or restart the requestAnimationFrame loop.
• stepInsn(n) -- call cpu.step() exactly n times and redraw, so a single step advances the PC by one instruction.
• step(n) -- advance n whole frames (each with its four IRQ slices).
• breakpoints -- a Set of PC values. When non-empty the loop runs instruction-by-instruction and pauses before executing a watched address; when empty it runs a frame at speed, so an idle debugger costs nothing.
• watchpoints -- every framebuffer / RAM write funnels through one poke(); it flags a hit when a watched address is written and the loop pauses on it. Registers are ordinary JavaScript and the RAM map is exposed side-effect-free (the POKEY RNG and the VBLANK bit are computed only on the live read path, never on dbgRead).

Extending the core for MADSEL. Missile Command's video is the interesting bit: the game plots pixels with LDA/STA (zero-page,X), and the hardware's "MADSEL" logic reinterprets that operand access as a pixel address into video RAM (a read-modify-write that changes just the addressed pixel). We reproduce it with a one-flag extension to Fake6502: indx() raises cpu.madsel after computing the 16-bit pointer, and the machine's read/write callback consumes it on the single operand access that follows, routing it through vramMadRead/vramMadWrite (2 colour bits at addr>>2, plus the scattered 3rd bit for the bottom of the screen). A neat trick for this hardware: put a write watchpoint on a frame-buffer byte and single-step -- you catch the exact instruction that lights a pixel, whether it arrived by a direct RAM store or a MADSEL plot.

The plug-in (missilecmd-debug.js) reads these hooks and calls EmuKit.defineMachine with the 6502 register set bound to the shared mos6502 disassembler, three memory chips (the CPU bus, the program ROM and the bitmap frame buffer), and an on-screen gamepad (trackball D-pad + three base fires + coin/start).

Architecture

Missile Command (Atari, 1980) is a raster board unlike its tilemap siblings: a single MOS 6502 at 1.25 MHz painting a full bitmap. Modelled here as plain JavaScript objects:

• CPU -- a port of Fake6502 (NMOS 6502 with BCD, which the score uses), reaching memory only through the machine's memRead/memWrite, so the bus and I/O live in one place. Partial address decode is modelled by masking every normal access to 15 bits, which folds the CPU vectors into ROM.
• Video -- a 256×231 bitmap held in RAM $0000–$3FFF (64 bytes per line, 4 pixels per byte, 2 colour bits packed as bit p and bit p+4). The bottom 32 lines gain a 3rd colour bit stored in a scattered low-RAM region. Colour is an eight-entry write-only palette RAM (1 bit each of R, G, B).
• MADSEL -- the pixel plotter: (zp,X) operand accesses are re-routed to a pixel-addressed video path (vramaddr = pixaddr >> 2) with per-pixel read-modify-write masks, exactly as the board's write-mask PROM dictates (computed analytically here and verified against the dumped PROM).
• Bus / I/O -- the frame-buffer RAM, two 8-way DIP banks (game options via the POKEY pot pins, pricing at $4A00), the trackball counter port and its direction lines, the three fire buttons, coin/start latches, the CTRLD / flip-screen output latch, and the POKEY (random-number register modelled; sound stubbed).
• ROMs -- 12 KB of 6502 program (six 2 KB mask ROMs) plus a 32-byte write-mask PROM (reproduced analytically).

The one piece of timing the game truly needs is its IRQ, clocked off 32V about four times per 60 Hz frame; the host loop reproduces exactly that -- four IRQ slices per frame -- and renders the bitmap at the end of each frame.