RIO: firmware v4.2 dump (Toshiba TMP68HC11) + first-look analysis

RIOv4_2.bin dumped from our own board EPROM (64KB, code $C000-$FFFF).
Vector table confirms 68HC11: RESET->$C000, SCI serial interrupt->$D630 =
the protocol state machine entry for the planned disassembly. Board patch
plan steps 1-2 done (RIO-NOTES.md updated); next: disassemble from the
SCI handler, find the reply-path wedge (button/event path survives it),
patch, burn to a fresh EPROM, preserve the original.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

emulator/RIO-NOTES.md

@@ -210,6 +210,16 @@ No firmware source or image exists in the archive (searched sda4 + CODE
 for *.HEX/*.A51/*.S19/*.ROM and for the protocol constant names — only
 PCSPAK.ASM, the game side, matches).
 
+**UPDATE 2026-07-04: steps 1-2 DONE.** The board's MCU is a **Toshiba
+TMP68HC11** (read off the chip) and the user dumped the EPROM:
+`emulator/rio-firmware/RIOv4_2.bin` (v4.2, 64KB image, code in
+$C000-$FFFF). First-look analysis in `emulator/rio-firmware/README.md` —
+reset vector $C000, **SCI serial interrupt vector → $D630** (the protocol
+state machine's entry point for step 3's disassembly). Also new evidence
+for the wedge shape: a button press revives a mute board (event path
+alive, reply path dead), so step 4 should look for a reply-path-only dead
+state reachable from the SCI handler.
+
 ## Crash-on-advance fixed: arena terrain shadows
 
 With the RIO in sync the sim advances and the game crashed dereferencing the

emulator/rio-firmware/README.md

@@ -0,0 +1,38 @@
+# RIO board firmware
+
+- **`RIOv4_2.bin`** — RIO cockpit I/O board firmware **v4.2**, dumped
+  2026-07-04 from one of our own boards' EPROM (64KB / 27C512-class image).
+  sha256 `60a88718835c654b6135dbec7721c40ef99dca07df2ad4b57eedeb24037a5f73`.
+
+## First-look analysis (from the image alone, confirmed on hardware)
+
+- MCU: **Toshiba TMP68HC11** (read off the chip; the code fingerprint
+  agrees — 6800-family opcodes with writes into the 68HC11 internal
+  register block at `$10xx`).
+- Memory map: image is FF up to **0xC000**; 16KB of code occupies
+  `$C000-$FFFF` (EPROM mapped at the top of the HC11 address space).
+- Startup at `$C000`: `SEI; LDS #$8000; STAA $1024 (TMSK2);
+  STAA $1022 (TMSK1); ...` then a long `JSR` init chain — textbook HC11
+  bring-up.
+- Vector table (`$FFD6-$FFFF`, big-endian):
+  - `$FFFE` RESET → `$C000`
+  - **`$FFD6` SCI (serial) → `$D630`** — the entry point of the board's
+    receive/protocol interrupt handler. The suspected board-side
+    DISABLE_AND_DIE-style wedge (see RIO-NOTES.md: the board mirrors the
+    game's PCSPAK state machine, and mash-stress leaves the reply path
+    dead while the button/event path stays alive) is reachable from here.
+  - `$FFE4` → `$C1B2`, `$FFE6` → `$C18E` (timer output-compares); most
+    other vectors → `$DB07..$DB3D` stubs.
+
+## Why this exists
+
+The remaining RIO reliability issue is board-side: under button-mash
+stress the board's reply/analog state machine wedges (RX dead, TX alive;
+a button press or power cycle revives it), reproduced identically on two
+different USB serial adapters. The game-side half of the protocol was
+binary-patched for tolerance (BTL4OPT patches v2-v4); the board firmware
+is the other half. Plan (RIO-NOTES.md "Board firmware patch plan"):
+disassemble as 68HC11 from `$C000` with the vector entries as roots, find
+the SCI state machine (protocol constants FC=ACK FD=NAK FE=RESTART
+FF=IDLE, idle-reload-4 patterns), patch the early-ACK/error wedge path or
+widen its window, burn a new EPROM, keep this original safe.