CydandClaude Fable 5
c170f1535c
Bench falsified the v1 retransmit (testlogs/riomash-patched-62500-retx): resends tracked NAKs 1:1 (321/321) yet lamps still stuck/missed — under mash bursts the NAK arrives after a newer command is already "latest", so the wrong packet was resent; and total shreds never NAK at all. Now commands are stop-and-wait: ONE in flight (_commandGate), resolved by ACK, NAK, or AckTimeout (50ms); NAK/timeout retransmits THE SAME packet up to CommandRetransmitLimit (2), then drops (idempotent - the next state update supersedes). Attribution is exact by construction and timeouts catch silent shreds. Control-byte replies bypass the gate so board traffic is never delayed; a request's own reply (analog/version/ check) also resolves the wait, so request/reply exchanges never burn the timeout even if the board sends no explicit ACK. 7 tests (same-packet resend, timeout retry+drop, ACK completion, serialization, reply-resolves-request, stray-NAK no-op, disable); 282 green. Mash summary now reports NAK/timeout resends. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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: an AMD AM27C512-150 (64K x 8 UV EPROM, 150ns — the image fills it exactly). sha25660a88718835c654b6135dbec7721c40ef99dca07df2ad4b57eedeb24037a5f73. For the eventual patched burn: a pin-compatible Winbond W27C512 (electrically erasable, TL866-friendly) drops straight into the socket; the original AMD chip gets labeled and preserved unmodified.
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 longJSRinit chain — textbook HC11 bring-up. - Vector table (
$FFD6-$FFFF, big-endian):$FFFERESET →$C000$FFD6SCI (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..$DB3Dstubs.
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.
Patched images (built by make_patch.py; see RIOv4_2-ANALYSIS.md)
RIOv4_2_patched.bin— the reply-latch wedge fix, 23 bytes changed. sha2563fc8170caf60e2580641724ff995176c93c4f2e706f31487beded8233142493f.RIOv4_2_patched_31250.bin(make_patch.py --baud31250) — wedge fix- SCI retuned 9600 → 31250 baud (one more byte,
$D62B: 30→02). sha2569f866cf353d04906e1d3e3847b6375eaae251c987b656f68f093e61ba1bd545b. Bench/RIOJoy-only until the native games get baud patches; needs an FTDI-class adapter (16550s can't make 31250). Test tools take--baud 31250.
- SCI retuned 9600 → 31250 baud (one more byte,