The Battlezone Multi-Million-Point Score Glitch

Code-level elimination analysis, evidence review, and a hardware-fault hypothesis

Executive summary

Battlezone has a rare, well-attested glitch in which the score suddenly jumps to a value in the millions — documented examples include 2,600,000 and 4,537,000 — sometimes within the first minutes of a game. A complete review of the disassembled program found no software path capable of producing the jump: the scoring arithmetic adds only small BCD constants, the interrupt handler clears the decimal flag on entry, every indexed store into zero page is bounded, and the one structural overflow candidate (the visible-object list) is geometrically unreachable. The eyewitness record shows the glitch correlates with moments of maximum simultaneous activity: overlapping kills, multiple explosions, rapid firing, and interfering sound effects.

The conclusion drawn here is that the glitch is not a program bug at all. It is a hardware-level fault: a single write cycle, issued during the period of peak write traffic to the zero-page bytes adjacent to the score, lands on the score bytes because of an electrical disturbance coincident with the machine's peak acoustic and electrical activity. One corrupted byte at address $B9 reproduces the entire observed phenomenology, including the "wave after wave of missiles" frenzy reported by witnesses. This hypothesis explains why the glitch has never been reported in MAME, why Atari's own engineers could never reproduce it on the bench, and why it occurred on brand-new machines in 1980-81 as well as on collector-owned machines decades later. It also yields concrete, falsifiable experiments for triggering the glitch deliberately on original hardware.

1. The documented record

The glitch is not folklore. The record includes:

• A photographed 4,537,000 score (biltronix.com, retold on 6502disassembly.com): the player's shot hit a saucer and a second shot hit an incoming missile "so close to being at the same time that the sounds of the hits interfered with each other and suddenly the crazy high score appeared."
• A 1981 account from a then-new machine at the Rye Town Hilton: the game abruptly became "a blitz with wave after wave of missiles and saucers, no tanks," ending after a couple of minutes with 2,600,000 points.
• A collector's photo album of glitch scores, all different values, all in the millions, gathered in the Museum of the Game forums.
• Ed Rotberg, the game's programmer: "The scoring glitch was an extremely rare bug that we were never able to recreate in our testing. We knew it was real, but all our efforts to find it or recreate it failed. It did not come up during development, but shortly after the game had been shipping."

Two facts in this record carry particular weight. First, the common thread across accounts is simultaneity — multiple hits, explosions, and sound effects landing at nearly the same instant. Second, the glitch appeared on new production machines circa 1980-81, so any explanation that depends on component aging is wrong. Aging may plausibly raise the incidence on surviving machines, but the mechanism must have been present on day one.

A forum photograph of an in-game screen showing a millions-range score established a further constraint: the zero-page score bytes themselves are corrupted during play, not merely the high-score table copy.

2. How Battlezone keeps score, and why one byte explains everything

The score is a two-byte BCD value at zero-page addresses $B8 (low) and $B9 (high), displayed with three zeros appended, so the on-screen score is the BCD value times 1,000 and rolls over at 10,000,000. Legitimate scoring events are tiny: 1,000 points for a slow tank, 2,000 for a missile, 3,000 for a supertank, 5,000 for a saucer, added as immediate BCD constants in decimal mode ($5FF6-$601B, $611C-$6131). Reaching one million legitimately takes on the order of an hour.

An arbitrary byte written into $B9 therefore instantly displays as millions — a byte whose high BCD digit is 2 through 8 (roughly 44% of random values) yields the reported 2-8 million range, and no glitch score can exceed 9,999,000, matching every photograph.

The same single byte also explains the reported gameplay chaos. CreateEnemyUnit ($69C2) tests $B9 directly: any nonzero value means "score over 100K," which switches enemy generation to a roughly 50% missile spawn rate, and the missile-aggression logic ($667E) likewise goes to its harshest setting. A player whose $B9 is corrupted mid-game gets exactly what the 1981 witness described: an instant millions score followed by an expert-level missile and saucer blitz. The frenzy is not a second symptom; it is the game responding faithfully to the corrupted score.

3. What the code analysis eliminated

Every candidate software mechanism was traced to a dead end:

This agrees with, and extends, McFadden's own assessment ("I haven't spotted the bug; there's nothing obviously wrong in the scoring code") and with Atari's failure to reproduce it in development.

One latent hazard deserves note even though the software never arms it: TxfrmObject ($5D4A) looks up a mesh pointer by object type with no range check, takes the mesh's first byte as a vertex count, and writes four bytes of screen coordinates per vertex, marching up zero page ($5DCF-$5DF5). A single corrupted type byte below $80 in the visible-object list becomes a wild pointer with up to 255 apparent vertices — a store sweep across the whole zero page, score included. The renderer is thus an amplifier: it can convert one externally corrupted byte into bulk corruption, but it cannot generate the first bad byte itself.

4. The emulation record, and why it matters

No occurrence of the glitch in MAME has ever been reported, so far as an extensive search of the forum record and the disassembly project's discussion shows — this in a game emulated since the 1990s and played by people specifically hunting the glitch. One forum member built a MAME savestate that reproduces the canonical trigger scenario exactly — a shot in flight toward a saucer, a missile inbound, a second shot killing the missile moments after the saucer dies — and replayed it repeatedly with varied timing. No glitch.

This is the decisive diagnostic. MAME executes the 6502's instruction semantics perfectly and models none of the machine's electrical behavior: no address-line settling, no write-enable timing margins, no supply-rail droop, no connector noise. A bug in the program would reproduce under emulation, and a timing-sensitive program bug would have been found by savestate replay. A fault in the electrical layer can never appear in MAME no matter how long it runs. The prediction follows: no amount of MAME testing will ever reproduce this glitch, and continued failure to reproduce it there is itself evidence for the hardware explanation.

The same logic covers Atari's bench: development and test machines exercised the identical program on hardware operating well inside its electrical margins, in a lab rather than a loud arcade cabinet at full volume.

5. The proposed mechanism: one disturbed write cycle

5.1 Why write traffic is the exposure window

A glitched read cycle is transient — the CPU consumes one wrong byte, and the error washes out or crashes into the watchdog. A glitched write cycle is persistent: the data is committed to the wrong cell and stays there. The probability of durable corruption therefore scales with the rate of write cycles targeting the neighborhood, multiplied by the per-cycle fault probability. The moments witnesses describe — shots in flight, simultaneous kills, overlapping explosions — are precisely when the program's write traffic to the bytes adjacent to the score is at its maximum.

5.2 The address adjacency

The zero-page layout puts the score directly above the most write-intensive gameplay bytes:

$A8-$AF   projectile positions   (rewritten 4x per frame per shot in flight)
$B0-$B7   projectile velocities  (rewritten on every shot fired)
$B8-$B9   SCORE (BCD)
$BA-$BB   enemy score
$BD       cannon-sound counter   (written at the instant of every shot)

A single address-bit error during one of those stores lands an arbitrary byte on the score: bit 3 maps $B0/$B1 onto $B8/$B9; bit 4 maps $A8/$A9 onto $B8/$B9. The written data — a projectile coordinate or velocity byte — is effectively random, which matches the observation that every photographed glitch score is different.

5.3 The fault classes

On the program-RAM SRAMs of this era (1K x 4 parts of the 2114 class), the address must remain stable for the entire time write-enable is asserted; a nanoseconds-wide disturbance on one address line mid-write commits the data to the wrong row. Candidate disturbances, all available on a new machine:

1. Address-path upset during the write-enable window — crosstalk between bus traces, ground bounce from simultaneously switching TTL outputs, or a marginal socket/connector contact moving under vibration.
2. Decoder runt pulses — the TTL address-decoding chain producing a runt chip-select during an address transition, coinciding with write-enable.
3. Supply-margin write corruption — the +5 V rail sagging during peak current draw; SRAM write margins degrade measurably with supply droop.
4. Mechanical vibration — the cabinet's own speaker output at explosion volume shaking marginal contacts; Atari fitted a slam switch precisely because mechanical shock is an electrical event on these machines.

The simultaneity correlation now does double duty. Overlapping explosion, cannon, and engine sounds are the peak current event for the discrete sound circuits and the peak acoustic/vibration event for the cabinet — at exactly the moment rapid firing maximizes write traffic beside the score. The witnesses' "the sounds of the hits interfered with each other" is not a cause; it is a timestamp marking the electrical peak.

5.4 Survivorship: why the score is what gets noticed

A disturbed write is roughly equally likely to land anywhere in active memory. Most targets produce either an invisible one-frame hiccup (projectile state, sound counters, positions — all rewritten within frames) or a crash that the watchdog converts into an unexplained reset nobody photographs. $B8/$B9 is the only long-lived, player-visible state in the neighborhood: a hit there is displayed in foot-high vector digits, persists to game over, enters the high-score table, and (via Section 2) announces itself with a missile blitz. The reported incidents are the visible tail of a larger fault population.

6. Deliberately triggering the glitch on original hardware

The hypothesis is falsifiable. Ordered from least to most invasive:

1. Instrumented monitoring (evidence-grade, non-invasive). Clip a logic analyzer onto the program RAM's address, data, and write-enable pins, triggering on any write to $00B8/$00B9 outside the legitimate store addresses (the scoring routines and the game-start reset). Play loudly and aggressively. A single capture of a write reaching the score from a non-scoring instruction — with the CPU-side address disagreeing with the RAM-side address — proves the mechanism outright.
2. Gameplay protocol. Maximize the known correlates: volume pots at maximum, saucer on screen, first missile inbound (one early saucer kill reaches the missile threshold quickly), continuous rapid fire timed so saucer and missile deaths overlap. This recreates the canonical scenario while the electrical and acoustic stress is highest.
3. Supply-margin stress. Run the logic +5 V rail at the low end of tolerance (or inject brief controlled droop synchronized to the explosion sound trigger) while executing the gameplay protocol. This widens the fault window without modifying the game.
4. Vibration stress. Mechanical excitation of the PCB/harness area (or simply speaker volume plus cabinet resonance) during the same protocol, targeting marginal contact behavior.
5. Direct fault injection (definitive). An interposer on the RAM socket that forces a one-cycle disturbance on address bit 3 or 4 during a write to $B0-$B7, or an instrumented emulator modified to inject single-address-bit write faults. Predicted result on demand: an arbitrary millions score, followed immediately by the missile/saucer frenzy and, if the value lands in vis_obj_type, transient screen garbage from the renderer amplifier.

Item 5's prediction is the clean test of the whole account: if injecting one address-bit write fault reproduces the full phenomenology — and the forum record says it should, down to the "hyper frenzy" — the case is closed.

Conclusion

The controlling findings are three:

• The program cannot produce the glitch. Every software path to the score bytes is bounded and clean, which is why forty years of code reading, Atari's own testing, and MAME savestate replay have all come up empty.
• The phenomenology is fully explained by one corrupted byte. An arbitrary value in $B9 simultaneously produces the millions-range score, the sub-10M ceiling, the differing values across incidents, and the missile-blitz aftermath that witnesses treated as a separate mystery.
• The trigger is electrical. A single write cycle disturbed — by supply droop, contact noise, or bus crosstalk — during the moments of maximum simultaneous activity, when the program is hammering the bytes directly beneath the score and the machine is at its acoustic and electrical peak. The glitch's presence on factory-new machines rules out aging as a necessary condition; the margins involved were thin from the first day of production.

The practical consequences:

• The glitch will never be observed in MAME, and searching for it there is wasted effort.
• It can plausibly be provoked on original hardware with a logic analyzer, a loud cabinet, and patience — or demonstrated on demand with one deliberately disturbed address bit.

Sources: 6502disassembly.com Battlezone disassembly and bug notes, Museum of the Game: "Scoring Millions of Points in Battlezone in Seconds", Museum of the Game: "That BZ high score glitch thing mystery", historicalsource Battlezone repository, local disassembly C:\Users\david\bz\bz-asm.txt.

Appendix A. Red Baron as a control experiment

Red Baron (Atari, 1980-81) runs on the same board family as Battlezone — the same aux MathBox, the same $0000-$03FF program RAM in 2114-class parts, the same watchdog. If the disturbed-write mechanism is real, it should operate on Red Baron at a broadly similar physical rate. Red Baron therefore tests the survivorship claim of Section 5.4: whether glitch lore tracks fault visibility rather than fault incidence. This appendix examines Rich Moore's original shipped source (historicalsource/red-baron, linked 14-SEP-81).

A.1 The score and its electrical neighborhood

Red Baron's score is a two-byte BCD value at zero-page $A9/$AA (confirmed against the assembler's own load map: the allocation places SECCNT at $AC, exactly where the map records it). The single-address-bit adjacency that exposes Battlezone's score exists here too:

A disturbed write should land on Red Baron's score about as readily as on Battlezone's. The exposure is the same; what differs is everything downstream.

A.2 Why the same fault is invisible in Red Baron

No impossible-score signature. The score is displayed as its two BCD bytes with one appended zero — five digits, ceiling 99,990, wrapping at 100K (the Twin Galaxies record of 447,860 implies tracked rollovers). A corrupted high byte that happens to be valid BCD (~44% of random values) produces a score that is always within the legitimately reachable range, and may even be a decrease. Battlezone's three appended zeros turned the same fault into a millions-range impossibility; Red Baron's display cannot show an impossible number at all.

No gameplay side channel. Battlezone's enemy generator reads the score high byte, so corruption announced itself with the missile frenzy. Red Baron's difficulty (GMLEVL) derives from OBJKLD, the objects-killed counter — never from SCORE. The only consumer of the score high byte is the bonus-life compare, so the worst gameplay symptom of a corrupted score is an unearned extra life.

Non-BCD corruption reads as a broken machine. The digit renderer (VGHEX) masks each nibble and indexes an alphanumeric character table whose entries 11-16 are the letter glyphs A-F. A corrupted nibble in the $A-$F range (~56% of random bytes) displays as letters in the score — and because the high-score compare is a binary SBC, such a value can enter the EAROM-backed high-score table and persist. An operator seeing "4C370" calls a technician, not a newspaper.

The rest of the fault population presents as resets. Red Baron has the same watchdog, and its surviving folklore is exactly what survivorship predicts: repair threads about machines resetting (e.g., Museum of the Game: "TECH: Red Baron resetting"), and — so far as searching the forum record shows — no glitch-score mythology whatsoever, against Battlezone's forty years of it.

A.3 The confound

Red Baron's sound is pure POKEY — RBSOUN.MAC is titled "WAS T2SOUN," Tempest's sound driver — while Battlezone used discrete analog explosion generators. Battlezone's overlapping-explosion moments were plausibly a genuine peak-current event; Red Baron's synthesized audio is electrically tamer. Red Baron may therefore also have a lower underlying fault rate, not merely lower visibility, and the lore record alone cannot separate the two effects. Both point the same direction, which makes the prediction unrisky: this is a consistency check, not a sharp test.

A.4 Result and predictions

Red Baron fails to falsify the hypothesis and sharpens it. Every channel that made the Battlezone event legible — the millions display, the frenzy side channel, the impossible-score signature — is structurally absent in Red Baron, so the same physical fault would be invisible or read as ordinary hardware failure. The absence of Red Baron glitch lore is what the survivorship model requires.

The appendix adds one new falsifiable prediction: if disturbed-write corruption is real on this board family, a small number of Red Baron machines circa 1981-82 should have displayed letter glyphs in the score or in the EAROM high-score table. A period service bulletin, a collector's report of letters in a Red Baron score display, or a surviving EAROM dump containing non-BCD entries would each be direct evidence. The sharp test remains the logic-analyzer capture of Section 6, on either machine.

Sources: historicalsource red-baron repository (key files: RBARON.MAC zero-page allocation and SCOREM; RBINT.MAC DIGITS; VGAN.MAC character table; RBARON.MAP symbol confirmation), Twin Galaxies Red Baron thread, Museum of the Game: "TECH: Red Baron resetting", local clone C:\Users\david\bz\redbaron-src.