TeslaRel410/emulator/PHASE2-PROGRESS.md

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).