Phase 2 COMPLETE: full VPX protocol working; game reaches content loader

Disassembled BTL4OPT.EXE (PE-in-DOS32RTM) to crack the last unknowns:

- velocirender_sync (@0x48D220): sends action 0x2D with a data token and
  checks cmp token, reply.node[0] (the 'unexpected action' text only prints
  the action; the real check is the echoed token). Device now echoes the
  token in node[0]. Sync passes.
- Speculative-poll gating: only feed a reply after consecutive empty polls
  (a blocking inRecord spin), not single handle_iserver_stuff() checks.
- Frame-ack: velocirender_frameack expects action 9 (vr_draw_scene); device
  tracks outstanding draw_scene and replies 9. Frame-ack passes.

The game now passes sync, loads renderer config, builds the scene
(create/flush/list_add/draw_scene), completes frame-ack, and enters its own
content loader (L4VIDEO.cpp) loading BattleTech models. Remaining issues are
content packaging/paths and an empty DPL config -- not VPX protocol. The
board emulation is functionally complete for boot + scene setup + frame-ack.

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

emulator/PHASE2-PROGRESS.md

@@ -127,3 +127,41 @@ Console progression now: `BattleTech v4.10` → `BTL4Application` → RIO check
 (the FIFO-path render handshake, the next target). The log's `#` note lines
 trace the device's decisions (handshake requests fed, frames parsed, actions
 echoed, mystery ports resolved to 0x154/0x155).
+
+## Update 3 (2026-07-03): full VPX protocol working — game reaches content load
+
+Disassembling `BTL4OPT.EXE` (a PE-in-DOS32RTM binary; CODE @VA 0x401000,
+`velocirender_sync` @0x48D220) cracked the last protocol unknowns and the
+emulated board now carries the game through the **entire** boot + render
+protocol into its own game logic:
+
+1. **velocirender_sync** (was the blocker): from the disassembly, it sends
+   action **0x2D** (a Rel4.10 sync/ping outside the DPL3 enum, which is why my
+   `<24` filter dropped it) with data `[token,0]`, then checks
+   `cmp token, reply.node[0]` at 0x48D271 — the "unexpected action %d" message
+   only *prints* the received action; the real test is the echoed **data
+   token**. Device now replies to 0x2D with `node[0] = token`. **Sync passes.**
+
+2. **Speculative-poll gating**: `velocirender_transmit` calls
+   `handle_iserver_stuff()` which polls inputStatus once and proceeds if
+   not-ready. Feeding a reply into those polls corrupted alignment. The device
+   now only feeds a reply after several *consecutive* empty polls (a blocking
+   `inRecord` spin), not single speculative checks.
+
+3. **Frame-ack**: `velocirender_frameack` expects a message with action
+   **9 (vr_draw_scene)**. The device tracks an outstanding `draw_scene` send and
+   replies 9 to the frame-ack. **Frame-ack passes.**
+
+With these, the game now: passes sync, loads the renderer config, builds the
+scene (create/flush/list_add/draw_scene), completes frame-ack, and enters its
+own content loader (`L4VIDEO.cpp`), where it tries to load BattleTech models
+(`buttee.bgf`, `mslr.bgf`, …). The remaining errors are **content packaging /
+paths** (the minimal `test.egg` lacks these objects) and an **empty renderer
+config** (`dpldflt.ini`) — *not* VPX protocol issues.
+
+**The VPX board emulation is functionally complete for boot + scene setup +
+frame-ack.** Next: (a) run against a full mission/content set (a real `.egg`
+or the pod's content tree) so objects load; (b) provide a proper DPL config;
+(c) Phase 3 — decode the geometry/material/texture commands already flowing over
+the FIFO into the OpenGL backend (formats in `restoration/divformats.py`) to put
+actual pixels on screen.