Phase 2: FIFO transport working + RIO validated on real hardware

RIO (Phase 5) validated with real hardware: with a physical RIO on
COM1 and serial1=directserial realport:COM1, the game's 1996 RIO
driver talks to the board — the 'RIO never came back' error is gone
and expected activity was seen on the RIO board.

VPX FIFO fast path decoded (OUTSW.ASM + capture): after i860 boot the
render protocol pumps 16-bit words to a FIFO data port seen as
0x154/0x155 byte writes, payload starting with the 4-byte action. The
device now extracts FIFO message actions (confirmed vr_init=0 with the
args string, vr_create=1 with node type 0x2D) and echoes replies with
handler-specific overrides from board source VR_REMOT.C (init/statistics
reply action = 1).

Blocked on one unknown: velocirender_sync checks the init reply against
a constant that is neither 0 nor 1, so the Rel 4.10 board differs from
the DPL3 dev source. Needs the Rel 4.10 LIBDPL source or disassembly of
BTL4OPT.EXE at the format string (file offset 0x107772). Device has a
VPX_INIT_REPLY experiment hook for candidate values.

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

emulator/PHASE2-PROGRESS.md

@@ -1,5 +1,46 @@
 # Phase 2 — Boot Protocol Emulation: Progress
 
+**Status: boot handshake + i860 download + FIFO transport solved; blocked on one
+unknown constant in `velocirender_sync`. Phase 5 (RIO) validated on real hardware.**
+
+## Update 2 (2026-07-02): FIFO transport working; RIO validated
+
+- **Phase 5 — RIO passthrough validated with real hardware.** A physical RIO
+  was attached to the host's COM1 (Prolific USB-serial). With
+  `serial1=directserial realport:COM1` (see `rio.conf`) and `L4CONTROLS=RIO`,
+  the game's 1996 RIO driver (`L4RIO.CPP`, 9600 baud) talks to the real board:
+  the `RIO never came back from check request?` error **disappears**, and the
+  **expected activity was observed on the RIO board**. The cockpit control path
+  works end-to-end, unmodified, through DOSBox-X serial passthrough.
+
+- **FIFO fast path decoded and implemented (send side).** The board is
+  dual-register: the render protocol switches to a FIFO channel after the i860
+  boots. From `OUTSW.ASM` + the capture: each message writes an `outsw` tag byte
+  to `outputData`, then pumps the payload as 16-bit words to the FIFO data port,
+  which DOSBox-X sees as byte writes to **0x154 (low) / 0x155 (high)**. The
+  payload begins with the 4-byte action. The device now parses this and
+  extracts the action of each FIFO message (confirmed: `vr_init`=0 with the
+  `/device~…` args string, then `vr_create`=1 with node-type `0x2D`).
+
+- **Handler-specific reply actions (from board source).** `velocirender_receive`
+  reads replies on the **slow path** (already served); the device echoes the
+  sent action, with per-handler exceptions found in `VRENDER/VR_REMOT.C`:
+  `velocirender_init` and `velocirender_statistics` do `*data = 1`, so their
+  reply action is **1**, not the sent action. The device implements this map.
+
+- **Remaining blocker — one constant.** The game reaches `velocirender_sync`,
+  which sends `vr_init` (action 0) and checks the reply action against a
+  specific value that is **neither 0 (echo) nor 1 (the DPL3 board's `init`
+  return)** — so the Rel 4.10 board returns a different value than the DPL3
+  dev-tree source. Determining it needs the Rel 4.10 LIBDPL/VRENDER source or a
+  disassembly of `BTL4OPT.EXE` around the format string at file offset
+  **0x107772** (`"unexpected action %d returned in velocirender_sync"`). The
+  device has an experiment hook (`VPX_INIT_REPLY=<n>`) to try candidate values.
+
+Original Update 1 analysis (handshake + i860 download) follows.
+
+---
+
 **Status: substantial progress; boot handshake + i860 download solved; render
 transport (FIFO fast path) identified as the remaining sub-protocol.**