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