Williams 6809 (Defender, Robotron, Joust…)¶
The great American early-80s arcade platform: the Motorola 6809-based Williams hardware, with its bitmap display (framebuffer, no tiles) and its speech synthesis (CVSD). Defender, Stargate, Robotron: 2084, Joust, Sinistar, Bubbles, Splat!, Blaster. No DIP switches: everything is set in the operator menu (CMOS).
Identification¶
| Field | Value |
|---|---|
| Manufacturer | Williams Electronics |
| Years | 1980 (Defender) → 1983 (Blaster); Joust 2 1986 |
| Type | ROM-board platform; bitmap display |
| Connector type | Williams harness (not JAMMA) |
| Settings | CMOS/NVRAM operator menu (coin door) — no DIP |
Architecture¶
| Block | Chip | Clock | Role |
|---|---|---|---|
| CPU | Motorola MC6809E | 1 MHz (12 MHz / 12) | game logic |
| Sound CPU | Motorola M6808 (separate sound board) | ~0.9 MHz (then 3.12 MHz) | drives the sound |
| Sound | MC1408 DAC + HC55516 (CVSD) | music/SFX via DAC + digitised speech (Sinistar "I hunger!", Robotron…) | |
| Video | bitmap framebuffer in RAM (bank-switched with ROM) | pixel ~8 MHz | ~292×240, 16 colours, no classic hardware tiles/sprites |
| Accelerator | "Special Chip" (DMA blitter) — SC1/SC2 | fast block copies (software sprites); absent on Defender & Stargate | |
| I/O | 6821 PIA | inputs, sound, counters |
Specificity: Williams works in bitmap (the CPU/blitter writes pixels directly into video RAM), whereas most hardware of the era is tile + sprite based. Hence the so characteristic look (Robotron, Sinistar) and the high CPU load — the "Special Chip" blitter precisely offloads those copies (except on the first two, Defender/Stargate, which don't have one).
Notable games¶
Defender (1980), Stargate / Defender II (1981), Robotron: 2084 (1982), Joust (1982), Sinistar (1982), Bubbles (1982), Splat! (1982), Blaster (1983), Joust 2: Survival of the Fittest (1986, late variant).
Settings: the operator menu (no DIP)¶
No DIP switches — everything is in CMOS
The Williams 6809 hardware has no DIP bank: coinage, difficulty, lives, free play, bookkeeping and high scores live in a CMOS/NVRAM set via the operator menu (accessed with the coin-door buttons). It's the equivalent of a soft-dip (like on Neo-Geo MVS or Cave's EEPROM menu). See the general DIP convention.
Common faults & preservation¶
| Symptom | Likely cause | Lead |
|---|---|---|
| Lost settings / scores, "factory settings" | Flat / leaking CMOS battery | Replace the battery; clean the corrosion (possible trace damage) |
| Frozen graphics / missing blitter | Dead Special Chip (SC1/SC2) | Blitter diagnosis; community substitutes (Special Chip repro) |
| No speech (SFX OK) | CVSD HC55516 stage | Sound board diagnosis |
| Corrupted bitmap image | Video RAM / bank switching | RAM test, contacts |
| No image | Power, 6809, harness | Base diagnosis |
CMOS battery leak = corrosion
As on many battery-backed boards of this era, a leaking CMOS battery eats the traces. Removing / relocating the battery (holder or external coin cell) is a good preservation practice.
- Emulation: MAME (
williams/williams.cpp). - FPGA / MiSTer: cores exist for the Williams 6809 games (Defender, Robotron: 2084, Joust, Sinistar, Stargate, Bubbles, Splat!, Blaster) — a hardware rebuild of the 6809 + framebuffer + Special Chip blitter.
Conversions¶
- Same hardware, swappable games: the collector scene does ROM swaps between games on the same base (e.g. Robotron ↔ Joust ↔ Stargate), even multigame boards. Check the presence/compatibility of the Special Chip for the target game (blitter games won't run on a board without an SC).
- No suicide or encrypted protection: the CMOS only holds settings.
- ⚠️ Do not host ROMs — method only.
EPROM repair¶
6809 program in 2532 / 2716 EPROMs (2 KB), many of them (Defender, Robotron, Joust, Stargate, Sinistar, Bubbles). The blitter (Special Chip) and decode PROMs are part of the hardware. Period components (1980-82).
Modernisation & mods¶
The common ground for every JAMMA board
Video, power, control panel and upscalers depend on the cabinet rather than the board: everything is centralised in Modernising a cabinet. To run the board outside a cabinet (at home, on a display): supergun.
- Battery 🟢: a save battery is fitted (settings/counters/RTC). ⚠️ On this platform, a dead battery does NOT kill the game — it is a leaking battery that corrodes traces. Check and replace it before it leaks → save batteries.
- Storage 🟡: the game lives in EPROM/mask ROM on the board. Changing or restoring a game means reprogramming the EPROMs (and, for a mask ROM, using a pinout adapter) → EPROM method.
- Media preservation: replacing the original storage, multicarts, ODEs and modern options by family → PCB preservation hub.
- Scan rate 📺: a TMS34010-based board: the screen configuration is programmed by the game in the graphics controller and does not appear in the driver — not measured here. In practice these boards stay at standard ~15 kHz. (Derived from the architecture documented above.) → tri-sync and upscalers.
- FPGA / emulation: see the Emulation & FPGA section below.
Repair (technician)¶
- "Special Chip" (SC1/SC2 DMA blitter): slow/corrupt graphics = the blitter (absent on Defender/Stargate) → test it; a rare part (donor / repro).
- Separate sound board (6808 + MC1408 DAC + HC55516 CVSD): silent digitised voice (Sinistar "I hunger!", Robotron) = the CVSD stage; music = the DAC.
- Watchdog: these boards reset if the CPU crashes → a reset loop = 6809 / RAM.
- CMOS battery (high scores) that leaks → remove/replace before it corrodes (backup batteries). Capacitors: recap.
→ Methods: PCB fault-finding · Recap · EPROM · Backup batteries
Photos / assets¶
(To add: Williams ROM board, sound board, Special Chip, CMOS battery.)
Sources & attribution¶
- MAME —
williams/williams.cpp(MC6809E @ 1 MHz, M6808 sound, MC1408 DAC + HC55516 CVSD, bitmap framebuffer, Special Chip blitter absent on Defender/Stargate, game list) — https://github.com/mamedev/mame/blob/master/src/mame/williams/williams.cpp - Wikipedia — Williams Electronics / Defender / Robotron: 2084 — CC-BY-SA — https://en.wikipedia.org/wiki/Robotron:_2084
Review & corrections
How this space is used
Spotted a wrong value, an outdated procedure, a chip reference that does not match your board? Say so here, with what you observed (model, board revision, serial number, measurement). Every report is cross-checked against a source before anything changes — an unverifiable correction is published as “reported by …, not cross-checked” rather than silently applied.
Reading is open to everyone; posting requires signing in with Discord. Reports from the wiki's declared reviewers are handled first; anyone else's are read too, but go through a human before anything is changed.