Phase 2 progress: boot handshake + i860 download solved; FIFO path mapped

The VPX responder device now drives production BattleTech v4.10
through the full transputer/i860 boot, far past the Phase 1 wall:

- iserver boot handshake solved: feeds 3 well-formed 'version' (tag 42)
  iserver requests, satisfying startup_handshake()'s 3 transactions.
- i860 download solved: parses the outbound framed renderer messages
  (vr_860args/code/data/bss) and absorbs them, staying byte-aligned.
- echo-action reply model validated against board source
  (VRENDER/VR_REMOT.C reply() echoes the received action); device
  tracks and echoes the last outbound action generally.

Remaining sub-protocol identified and characterized: after i860 boot
the host switches to a FIFO fast path (OUTSW.ASM: 0x40 tag + REP OUTSW
16-bit words to FIFO port 0x154/0x155, gated by ok_to_fifo at 0x160).
The current build stops at velocirender_sync because the device only
implements the slow byte path. PHASE2-PROGRESS.md documents the exact
next steps (FIFO transport + render loop -> Phase 3 OpenGL backend).

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

emulator/PHASE2-PROGRESS.md

@@ -0,0 +1,88 @@
+# Phase 2 — Boot Protocol Emulation: Progress
+
+**Status: substantial progress; boot handshake + i860 download solved; render
+transport (FIFO fast path) identified as the remaining sub-protocol.**
+
+The VPX device (`vpx-device/vpxlog.cpp`, env `VPX_RESPOND=1`) now drives the
+production **BattleTech v4.10** (ALPHA_1 image) through the entire transputer/i860
+boot sequence — far past the Phase 1 wall — and reaches the live renderer
+protocol. Each layer below was solved by reading the normative sources on the
+drive (`sda4/DPL3/VR_COMMS.C`, `DPL_HOST.C`, `VRENDER/VR_REMOT.C`, `LINKIO.C`,
+`OUTSW.ASM`) and iterating against the running binary.
+
+## Solved
+
+### 1. iserver boot handshake
+After the monitor (`VRENDMON.BTL`) download, `boot_xputer()` calls
+`startup_handshake()`, which does **3 iserver transactions** (Phil's comment in
+`VR_COMMS.C`: "the C run-time boots up and does 3 iserver transactions"). Each
+is a `receive_protocol()` read of a 4-byte little-endian length/route word
+(bit31=iserver, low16=payload length) + payload, answered by `iserver_action()`;
+only success is checked. The device feeds **3 well-formed iserver "version"
+requests** (tag 42, no request-content dependency) and the handshake completes.
+
+### 2. i860 renderer download
+`boot_860()` then streams the i860 image (`VRNOSTEX.MNG`) as framed renderer
+messages on the slow byte path: `vr_860args` (21), `vr_860code` (18, ×118),
+`vr_860data` (19, ×37), `vr_860bss` (20, ×9). The device parses the outbound
+frame stream (`[length_word:4][action:4][data]`, `nb = length_word & 0xffff`)
+and absorbs them, staying byte-aligned throughout.
+
+### 3. The echo-action reply model (validated against board source)
+Renderer request/reply calls (`velocirender_create`/`delete`/`flush`/`sync` in
+`DPL_HOST.C`) send an action and require the **same action echoed back**. The
+board side confirms this exactly: `VRENDER/VR_REMOT.C remote_velocirender()`
+replies with its `data` buffer whose first word is still the received action
+(`reply()` → `dN_send`). The device tracks the last outbound action and echoes
+it; this is the general model for every render call, not a one-off.
+
+## The remaining sub-protocol: the FIFO fast path
+
+After the i860 boots, the host stops using the slow byte path and switches to a
+**FIFO fast path** for the render protocol. This is why the current build still
+stops at `velocirender_sync` — the device only implements the slow path
+(0x150–0x153).
+
+Discovered mechanics (from the capture + `OUTSW.ASM` + `LINKIO.C`):
+
+- The VPX board is **dual-register**: beyond the C012 slow link
+  (0x150 inputData / 0x151 outputData / 0x152 inputStatus / 0x153 outputStatus),
+  there is a **FIFO data port** reached at **0x154/0x155** (observed) and an
+  `ok_to_fifo` status at **0x160**.
+- `send_FIFO_protocol()` / `velocirender_transmit()` (when `use_fifo`) call the
+  assembly `outsw()` (`OUTSW.ASM`): it writes a `0x40` "use fifo" tag byte, then
+  `add dx,3` and `REP OUTSW` — pumping the message as **16-bit words** into the
+  FIFO port. In the capture these land as alternating byte writes to 0x154/0x155
+  and decode to the init/args string (e.g. `/device~0x150~/video~svga~…`).
+- The host switches to `use_fifo` once the board asserts `ok_to_fifo`
+  (`fifo_ok_status()` reads 0x160 bit0); see the commented wait loop in
+  `boot_xputer()`.
+
+### Next step (concrete)
+Extend the device to implement the FIFO transport:
+1. Answer `ok_to_fifo` (0x160 bit0) at the right time so the host enables `use_fifo`.
+2. Accept FIFO writes: the `0x40` tag, then word-stream data at the FIFO port
+   (0x154/0x155). Reassemble into `[length_word][action][data]` messages
+   (same framing as the slow path).
+3. Serve FIFO reads for replies: `velocirender_receive()` in FIFO mode reads the
+   reply (length_word + `[action][node]`) from the FIFO/status ports. Echo the
+   sent action (model already validated), returning meaningful node handles for
+   `vr_create` so later `vr_delete`/geometry ops have valid remotes.
+4. Then the render loop (`vr_draw_scene` + frame-ack, `velocirender_frameack()`)
+   — the Phase 3 boundary, where geometry/material/texture commands can be
+   decoded into the OpenGL backend (formats already implemented in
+   `restoration/divformats.py`).
+
+## Reproduce
+
+```
+set VPXLOG=C:\VWE\TeslaRel410\emulator\vpxresp.txt
+set VPX_RESPOND=1
+emulator\src\src\dosbox-x.exe -conf emulator\respond.conf
+```
+
+Console progression now: `BattleTech v4.10` → `BTL4Application` → RIO check →
+(handshake, i860 download succeed) → `unexpected action N in velocirender_sync`
+(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).