TeslaRel410/emulator/PHASE0-RESULTS.md

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 (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 — 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.