Atari 2600 TIA Collision Latches Power Raiders of the Lost Ark’s Sprite Detection
Inside an 8 KB F8-bankswitched classic: per-pixel latches, 76-cycle scanlines, and the emulator workflows that explain every hit, pickup, and wall slide
You can feel it the moment Indy brushes a wall or his on-screen “hand” snaps an artifact off a pedestal: Raiders of the Lost Ark on the Atari 2600 lives and dies by hardware-level collisions. Not bounding boxes. Not math-heavy physics. The game leans on the TIA’s collision latches—tiny flip-flops set when on-screen pixels meet at precisely the same instant during a scanline. Those latches silently power every hit, pickup, and slide in a 1982 game squeezed into 8 KB of ROM and 128 bytes of RAM.
That’s not nostalgia; it’s a design dictated by the hardware. The 2600’s 6507 CPU has 76 cycles to service each scanline while the TIA draws the TV image. Game logic that isn’t perfectly timed risks tearing the display. Collision detection had to be “free” during drawing and cheap to consume later. Raiders obliges with a model that’s definitive on this system: pixel-true, pairwise, latched-until-cleared, and independent of draw priority. Understanding it clarifies how emulators replicate behavior, how hacks stay compatible, and what a faithful remake would need to emulate—or replace—in a modern engine.
The constraints that dictated Raiders’ collision strategy
Raiders is an 8 KB cartridge using F8-style bankswitching—a common 2600 scheme that toggles between two 4 KB banks inside the 6507’s tiny 4 KB visible address space. System RAM is just 128 bytes. The TIA draws video directly; the game’s “kernel” must set up sprite positions and playfield data scanline-by-scanline, within 76 CPU cycles per line. Most actual game logic, including collision decisions, runs in the non-visible periods: vertical blank and overscan.
Those constraints make software collisions impractical. Per-sprite bitmasks or swept bounding box checks would cost cycles and code space the game doesn’t have—and would complicate the scanline-timed kernel. Meanwhile, Raiders must also juggle two joysticks: one moves Indy; a second manipulates the on-screen “hand,” a cursor-like interactor for items. That division neatly maps to the TIA’s limited set of drawable objects and its hardware collision system.
How TIA collision latches work—and why they’re definitive
The TIA provides collision detection in hardware. When two opaque pixels from different TIA object classes overlap on the same color clock during active display, a corresponding latch sets. The CPU reads these latches via dedicated addresses and clears them explicitly via a single reset register. Critically, latches reflect physical overlap, not what appears visually in front; display priority does not suppress collision detection.
The collision registers:
- CXM0P ($30): Missile 0 with Player 0/1
- CXM1P ($31): Missile 1 with Player 0/1
- CXP0FB ($32): Player 0 with Playfield/Ball
- CXP1FB ($33): Player 1 with Playfield/Ball
- CXM0FB ($34): Missile 0 with Playfield/Ball
- CXM1FB ($35): Missile 1 with Playfield/Ball
- CXBLPF ($36): Ball with Playfield
- CXPPMM ($37): Player 0 with Player 1 and missile–missile
Latches are cleared by writing to CXCLR ($2C). Semantically, each bit means “since the last clear, at least one overlap occurred.” There’s no location, no count, and no temporal order in that frame—just yes/no for that pair.
Why this is definitive on the 2600 is simple: collision checks happen entirely in the TIA while the CPU “races the beam.” After the visible portion, the CPU needs only a handful of reads to know which object kinds touched at any point that frame.
Mapping Indy, the “hand,” and the world to TIA objects
A 2600 game has five movable object types—two players (P0, P1), two missiles (M0, M1), and a ball (BL)—plus the chunky, mirrored playfield (PF). Raiders uses them in a way consistent with both its design and contemporary 2600 practice:
- Indy and large NPCs: Player sprites (P0/P1). Collisions with terrain and the ball show up in CXP0FB/CXP1FB; player–player overlaps register in CXPPMM.
- The “hand” cursor: a missile or the ball. Many 2600 titles co-opt a missile or the ball as a pointer because the hardware can position it independently and its collisions are exposed in the same CX registers. With Raiders’ second-joystick hand, detecting “cursor touching item” or “cursor over an environmental affordance” falls out of CXM0P/CXM1P (missile–player), CXM0FB/CXM1FB (missile–playfield/ball), or, if the ball is used for the cursor, via the FB-related bits in the player/missile registers and CXBLPF for ball–playfield.
- The world: Playfield for walls, barriers, and room silhouettes. Blocking, slide-along-walls behavior, and doorway triggers derive from player/missile/ball versus playfield collisions—the CXFB registers and CXBLPF.
This mapping lets the draw kernel do the expensive part—generate pixels; the TIA sets latches passively; and Raiders interprets a few bits per frame to tell what happened.
Filtering, ordering, and making sense of ambiguous overlaps
The TIA tells you only that a collision happened “at least once since the last clear.” If Indy brushed a wall and simultaneously overlapped a ball-based highlight, CXP0FB will light both bits—but the CPU can’t tell which happened first or where. Display priority also doesn’t matter: a collision can register even if a sprite is drawn “behind” another due to priority settings.
Raiders deals with that minimalism in software:
- Clear at the right time: Write CXCLR just before the screen segment where interactions matter or at the start of the visible frame, so latches only capture relevant contacts.
- Read once per frame: During vblank/overscan, read CXM0P…CXPPMM and mask out irrelevant bits depending on game state (e.g., ignore missile–PF if the hand is disabled in a room).
- Apply a fixed priority: Decide hazards before pickups before environment, or any deterministic ordering that makes sense. Since the hardware supplies no event list, the game imposes policy: lethal hits trump everything; pickups require both contact and an “intent” state; environment bounces or clamps position last.
That policy is what players feel as consistent, predictable interaction even when multiple overlaps are ambiguous under the hood.
Binary contact, thresholds, and scanline edge cases
There’s no adjustable radius or “proximity” on the 2600—contact is binary and pixel-precise. To avoid flickery misfires, games often gate on persistence: require the same latch to be set across multiple consecutive frames, or only when movement intent matches (e.g., only pick up if the hand overlaps an item and the player presses the second joystick’s action). Raiders’ hand-and-item dynamic practically demands this kind of additional gating.
A few edge cases matter:
- One-scanline grazes: A single-line overlap sets the latch that frame. If the game doesn’t filter, grazing a hazard for one line looks like a hit. Multi-frame checks help smooth glancing contacts.
- Sub-pixel horizontal placement: HMOVE fine positions and HMPx’s 4-bit signed offsets mean latches correspond to true on-screen offsets, not coarse byte-grid steps. That makes collision detection precise without extra CPU work.
- Vertical sparseness: If art alternates scanlines or is drawn especially thin, fewer opportunities exist for pixel overlap, which can make interactions feel less “sticky.” Core actors are typically drawn on every relevant scanline to minimize frame-internal “tunneling.”
In other words: collisions are exact to the pixels you see, line-by-line, with all the strengths and quirks that implies.
Resolution and timing: where Raiders actually handles collisions
A stable kernel cannot afford mid-frame surprises. The 2600 gives you 76 cycles per visible line to set up next-line graphics; blowing that budget risks lost sync. Raiders defers resolution to the safe zones:
- Clear latches once per frame, often early.
- Draw the visible frame while TIA sets collision latches automatically.
- During vblank/overscan, read CX registers once, apply software filtering and ordering, then resolve.
Resolution itself is budget-conscious: clamp-or-slide for player-versus-wall, revert-only-the-offending-axis if a move would penetrate the playfield, then process items and cosmetic triggers. The result is that familiar “slide along walls” feel, born as much from necessity as design.
Why latches win on performance and memory
On a system with 128 bytes of RAM and 8 KB of ROM, the TIA’s collision latches are an efficiency windfall:
- They’re essentially free while drawing. The TIA sets them as pixels are composed.
- Cost to consume is tiny. The CPU reads a handful of addresses in vblank/overscan and writes a single clear.
- They preserve kernel stability. No mid-frame loops or math-heavy tests intruding on the 76-cycle budget.
Contrast that with software collisions: per-scanline bitmask tests for each sprite pair or a coarse tile grid would explode ROM and cycles. Continuous collision detection to prevent frame-internal tunneling—common in modern engines—is redundant on the 2600 because overlaps are evaluated at the granularity the screen is drawn.
Quirks and regional notes that affect perception, not logic
A few realities shape how players perceive collisions without changing the underlying logic:
- NTSC vs. PAL: Line counts, palette, and cadence differ by region, but the TIA’s collision semantics are identical. If PAL feels a hair “looser” or “stickier,” it’s due to total frame timing and visual differences, not a change in how latches set.
- Hidden hits: Because collision ignores draw priority, an overlap can register even if an object is visually occluded by another with higher priority. It’s a classic 2600 footgun and can surprise during hacks or when debugging unexpected hits.
- Stale latches: Forgetting to clear via CXCLR carries collisions across frames, yielding phantom pickups or walls that seem permanently “solid.” It’s the first thing to check when behavior goes odd.
These aren’t bugs in emulators or ROM revisions; they’re endemic to how the TIA works.
Testing and debugging in 2026: Stella, Gopher2600, and Distella
Today’s toolchain makes Raiders’ collision machinery transparent—without touching the ROM:
- Stella’s debugger exposes the collision registers live. You can set breakpoints on CX reads/writes, watch CXM0P…CXPPMM flip as the frame advances, and even “break when CXP0FB!= 0” to land on the exact vblank code that handles Indy-versus-walls. Stepping frame-by-frame turns those abstract latches into concrete decisions.
- Gopher2600 emphasizes cycle-accurate TIA behavior and per-scanline object placement. That’s perfect for validating when an overlap could happen, especially with tight kernels or graphics that only light certain lines.
- Distella disassembles the Raiders ROM. Searching for reads from $30–$37 and writes to $2C pinpoints collision handling and the game’s resolution order. These anchors are where hacks either succeed—by respecting timing and state—or crash into invisible constraints.
Together, these workflows mirror best-practice guidance from classic programming guides while adding modern observability. They also underline a key point: running the original ROM in emulation preserves collision behavior exactly because the logic lives in the TIA model, which emulators reproduce per pixel and per scanline.
Emulation, ROM hacks, and what a modern remake would actually do
Run Raiders under Stella or Gopher2600 and you get the same per-pixel, latched-until-cleared collision system, with the same timing. Emulators replicate the TIA’s composition pipeline and latch behavior; the ROM’s reads and clears occur in the same places relative to the frame. The practical upside in 2026 is better tooling, not different gameplay.
ROM hacks that tweak art, colors, maps, or small rules but retain the original engine inherit identical collision semantics. They still read CXM0P…CXPPMM and write CXCLR in the same frame windows and are bound by the same “since-last-cleared” ambiguity. Hacks that repurpose the hand, flip which player renders Indy, or redesign rooms must respect this pairing and timing or face puzzling glitches: invisible hits from priority independence, or phantom states from missed clears.
A from-scratch remake with the “Raiders2600” label would face a choice. If it embeds the original ROM and a 2600 core, collisions reduce to the TIA model by design. If it doesn’t, it must replace latches with software:
- Broad-phase AABB for player-versus-world, with narrow-phase bitmask tests for precise pickups.
- Swept/continuous checks to prevent tunneling at higher speeds—unnecessary on the 2600 because overlaps happen scanline by scanline.
- Layer/mask filtering to echo TIA’s pairwise scheme but with richer control.
- A fixed-timestep simulation to stabilize responses—similar in spirit to the frame-locked cadence of the original.
The result could feel remarkably similar, especially with clamp-and-slide resolution and deterministic event ordering, but it would be a reimplementation rather than reuse of the original mechanism.
A concise verdict on Raiders’ collision model
Raiders of the Lost Ark on the Atari 2600 is a case study in letting hardware do the heavy lifting. The TIA’s per-pixel collision latches—set the instant two classes of pixels overlap, indifferent to draw priority, and latched until explicitly cleared—drive a full spectrum of interactions: walls that push Indy aside, hazards that take precedence, and a second-joystick hand that “touches” treasures.
Three design decisions make it work:
- Embrace binary, per-frame truth: a handful of CX bits read once in vblank/overscan and a disciplined software order to resolve ambiguity.
- Keep logic out of the kernel: draw during the 76-cycle budget; think during blanking.
- Spend cycles where they count: no software pixel tests; clamp-and-slide resolutions that are stable and cheap.
For emulators and hacks, the mandate is simple: preserve the latch semantics and timing and everything falls into place. For a remake, the target is clear: replicate per-pixel contact and deterministic resolution, or ship the original ROM inside a faithful core.
The enduring lesson is that constraints breed clarity. Raiders’ collision model is not only period-correct—it’s a masterclass in getting decisive, per-pixel interactions for free, then doing just enough in software to make them feel like adventure. 🎮
Appendix: Collision register quick reference
| Register | Pair(s) latched |
|---|---|
| CXM0P ($30) | Missile 0 with Player 0/1 |
| CXM1P ($31) | Missile 1 with Player 0/1 |
| CXP0FB ($32) | Player 0 with Playfield/Ball |
| CXP1FB ($33) | Player 1 with Playfield/Ball |
| CXM0FB ($34) | Missile 0 with Playfield/Ball |
| CXM1FB ($35) | Missile 1 with Playfield/Ball |
| CXBLPF ($36) | Ball with Playfield |
| CXPPMM ($37) | Player 0 with Player 1; missile–missile |