# Phase 0 — Baseline Boot Test: Results

**Status: complete.** The DOS game boots on Windows 10 (via DOSBox-X) all the
way to the VPX link protocol and fails exactly where the plan predicted,
confirming the emulation architecture end-to-end.

## Environment

- **Emulator:** DOSBox-X `v2026.06.02`, MinGW 64-bit build (the standard build,
  *not* the `-osfree` variant — that one disables the built-in DOS shell and
  cannot run an autoexec). Extracted to `emulator/dosbox-x/`.
- **Host:** Windows 10, cockpit-class PC.
- **Toolchain present** for later phases: MSYS2 mingw64 (`gcc`/`g++` at
  `C:\msys64\mingw64\bin`).

## Game image selection — a version-matching gotcha

The first image (from `sda4/BTLIVE`, the "release" install) **fails a version
check before reaching the renderer**:

```
BattleTech v1.0.1.4
Error - Resource file btl4.res v1.0.1.2 is obsolete?
```

The `BTL4OPT.EXE` in BTLIVE is newer than its `BTL4.RES`. The resource version
is the **first 4 bytes** of `BTL4.RES`:

| Install | BTL4.RES version | Notes |
|---|---|---|
| `sda4/BTLIVE`   | `1.0.1.2` | **mismatched** — EXE expects 1.0.1.4 |
| `sda4/BTDAVE`   | `1.1.0.4` | self-consistent |
| `sda4/BTRAVINE` | `1.1.0.6` | self-consistent; **matches repo source** |

`BTRAVINE`'s `1.1.0.6` matches this repository's
[`CODE/BT/BT_L4/BTL4VER.HPP`](../CODE/BT/BT_L4/BTL4VER.HPP)
(`MAJOR_DATA_VERSION 1`, `MINOR_DATA_VERSION 6`), so **BTRAVINE is the
development image**: its EXE, RES, content, and this repo's source are all the
same build. (For production deployment we will revisit whether to ship the
BTLIVE content set with a rebuilt/renumbered RES; not a blocker for emulator
work.)

The image is assembled at `emulator/image/` from `sda4/BTRAVINE`, plus the
Borland 32-bit runtime (`32RTM.EXE`, `DPMI32VM.OVL`) which every launch needs.

## Baseline result (stock DOSBox-X, no VPX device yet)

Config: [`baseline.conf`](baseline.conf) — replicates the pod environment
(`L4CONTROLS=RIO,KEYBOARD`, `VIDEOFORMAT=svga`, the production `DPLARG` with
`/device 0x150`), serial ports disabled, then runs `btl4opt.exe -egg test.egg`.

Console output:

```
32rtm.exe -x
32rtm version 1.5 Copyright (c) 1992-94 Borland International
32rtm resident
btl4opt.exe -egg test.egg
BattleTech v4.2
BTL4Application::BTL4Application
RIO never came back from check request?
Protocol error : length 65535 too big, length_word 0xffffffff
+++ERROR : rcv_protocol fail during iserver handling, xmits=0
```

### What each line proves

1. **`32rtm resident`** — the Borland DPMI/32-bit protected-mode runtime loads
   and runs under DOSBox-X. (Resolves the "DPMI/32RTM incompatibility" risk in
   the plan: **low → none**.)
2. **`BTL4Application::BTL4Application`** — the game passed the RES version
   check and constructed its top-level application. We are *past* startup
   validation and into hardware bring-up.
3. **`RIO never came back from check request?`** — the game polled the **RIO on
   COM1** (`L4CONTROLS=RIO`, driver `CODE/RP/MUNGA_L4/L4RIO.CPP`). Serial was
   disabled in this probe, so no reply — expected. Confirms the COM1 control
   path is live and exercised at boot. (Phase 5 will pass COM1 through to the
   real RIO.)
4. **`Protocol error : length 65535 too big, length_word 0xffffffff`** — the
   game read the 32-bit length/route word from the **link adapter at I/O port
   0x150** and got `0xffffffff`. DOSBox-X returns `0xFF` for reads of unmapped
   I/O ports, so the C012 status register (`0x152`) always reads "ready" and
   the data register (`0x150`) always yields `0xFF`; four such reads assemble
   `0xffffffff`. `VR_COMMS.C` computes `nb = length_word & 0xffff = 65535` and
   rejects it — *the exact code path and constant named in the source we
   documented in the plan.*
5. **`rcv_protocol fail during iserver handling, xmits=0`** — the iserver/boot
   handshake failed with zero successful transmits, and the game aborts.

## Conclusion

The failure is **precisely** the plan's predicted Phase 0 outcome: the game
runs unmodified on Windows 10 and reaches the VPX board's link protocol, failing
only because no board answers at port 0x150. Two architectural assumptions are
now empirically confirmed rather than inferred:

- The host↔board interface really is the polled link adapter at **0x150**, and
  the game's failure is a clean protocol read of `0xffffffff` — exactly what an
  emulated C012 FIFO must instead answer correctly.
- The **RIO-on-COM1** control path executes at boot and will be satisfied by
  DOSBox-X serial passthrough (Phase 5).

## Reproduce

```
cd emulator
dosbox-x\mingw-build\mingw\dosbox-x.exe -conf baseline.conf
```

(The game runs, prints the above, and pauses. `image/` must contain the
BTRAVINE build + `32RTM.EXE`/`DPMI32VM.OVL`.)

## Next: Phase 1

Build a DOSBox-X I/O device claiming ports `0x150–0x157` that **logs every read
and write** and returns configurable C012 status/data, so we can capture the
game's exact boot conversation (reset → transputer monitor → i860 segments →
version handshake) from the *shipped binary* and confirm the register map
against `LINKIO.C`. This requires building DOSBox-X from source (MSYS2 mingw64
is present); the device is a self-contained `IO_RegisterReadHandler` /
`IO_RegisterWriteHandler` module.