TeslaRel410/emulator/PHASE1-RESULTS.md

Phase 1 — Interface Discovery: Results

Status: complete. A custom DOSBox-X build with a VPX link-adapter logging device captured the game's outbound boot conversation from the shipped binary. The register map is confirmed and the first protocol stage is fully characterized: the game resets the transputer and streams the entire VRENDMON.BTL monitor over the link, byte for byte.

Instrument

emulator/src/src/hardware/vpxlog.cpp — a DOSBox-X device (built into libhardware, called from VPXLOG_Init() next to GLIDE_Init() in sdlmain.cpp) that claims the C012 register range and logs every access. It answers status reads so the game keeps transmitting:

• outputStatus (0x153) → always ready (bit0 = 1)
• inputStatus (0x152) → no inbound data (bit0 = 0)
• inputData (0x150) → 0xFF (open-bus), logged if read

Enabled only when the VPXLOG environment variable names a log path, so the build behaves like stock DOSBox-X otherwise. Built from source with MSYS2 mingw64 (build-mingw-sdl2 --enable-debug=heavy); the device compiles and links cleanly (VPXLOG_Init present in the final dosbox-x.exe).

Reproduce:

set VPXLOG=C:\VWE\TeslaRel410\emulator\vpxlog.txt
emulator\src\src\dosbox-x.exe -conf emulator\capture.conf
python emulator\analyze_capture.py emulator\vpxlog.txt emulator\image

Confirmed register map (matches sda4/DPL3/LINKIO.C)

Base 0x150 (from the shipped DPLARG /device 0x150):

Port	Register	Observed use
0x151	outputData	W — every payload byte
0x153	outputStatus	R — polled (bit0) before every payload byte
0x160	resetRoot	W — reset pulse (see preamble)
0x161	analyseRoot	W — asserted low once at reset
0x152	inputStatus	W — one init write during reset
0x150	inputData	not yet exercised (monitor never booted to reply)

inputData/inputStatus reads will appear in Phase 2 once the emulated monitor answers and the game starts reading responses.

Access summary (one capture, ~30 s, game killed while it waited for the monitor)

R  outputStatus  85298      poll-before-send, one per payload byte
W  outputData    85298      the monitor image
W  resetRoot         3      reset pulse: 0, 1, 0
W  analyseRoot       1      0
W  outputStatus      1      0  (init)
W  inputStatus       1      0  (init)

Reset preamble (exact, from the capture)

seq 0  W analyseRoot  0x00     deassert analyse
seq 1  W resetRoot    0x00     reset low
seq 2  W resetRoot    0x01     assert reset
seq 3  W outputStatus 0x00     init
seq 4  W inputStatus  0x00     init
seq 5  W resetRoot    0x00     deassert reset  -> transputer starts, listens on link
seq 6  R outputStatus 0x01     ready -> begin download

The download — exact match

The 85,298 bytes written to outputData are byte-for-byte identical to VRENDMON.BTL (verified by analyze_capture.py). The first byte is 0xF0 (240) — the transputer boot-from-link primary-bootstrap length — confirming VRENDMON.BTL is a standard bootable transputer image (.BTL = bootable). The game's own header (sda4/BTLIVE/SETENV.BAT) names it: DPLARG=/tranny~.\vrendmon.btl~....

So protocol stage 1 is now precisely known:

1. Reset the transputer with the preamble above.
2. Stream VRENDMON.BTL (the /tranny file) to outputData, polling outputStatus bit0 before each byte. No handshake bytes are interleaved — it is a straight boot-from-link download.

After the last byte the game waits for the freshly-booted monitor to respond. Our passive logger never answers, so the capture ends there. Driving the game further (i860 code/data segment download via /i860 vrnostex.mng, then the version handshake in VR_COMMS.C) is Phase 2, which requires the device to actually behave as the transputer monitor rather than just log.

Production reference: ALPHA_1

A dump of a working production cockpit (ALPHA_1) was added at ALPHA_1/ (git-ignored). It contains the real pod boot chain (AUTOEXEC.BAT → PARAMETR.bat Rel410 BT POD SLOW SVGA → Novell client + odipkt packet driver + NetNub + VGL_LABS\go.bat) and both games under ALPHA_1/REL410/BT and .../RP. Its BT resource is version 1.1.0.6 and its VRENDMON.BTL is byte-identical to the BTRAVINE build used for this capture — so this Phase 1 result is valid for the exact software that ran in the cockpit. ALPHA_1 is the authoritative image for subsequent phases (it also carries the RP side and the production launch/network configuration).

What Phase 1 retires from the risk list

• Register map / framing uncertainty → resolved from the shipped binary, not just the DPL3 sources. Confirmed base 0x150, C012 layout, poll-before-send.
• "Protocol drift" between DPL3 sources and the linked LIBDPL → the observed behavior matches LINKIO.C exactly; stage 1 has no surprises.
• Hidden bulk-transfer / interrupt path → none seen; the download is plain polled single-byte outp to 0x151. (outsw/ok_to_fifo were not used for the monitor download.)