CydandClaude Fable 5
f680ed0585
Baseline boot test under DOSBox-X confirms the emulation architecture empirically. Key findings: - Borland 32RTM/DPMI runtime works under DOSBox-X (risk retired). - BTLIVE ships a version-mismatched BTL4.RES (1.0.1.2 vs EXE 1.0.1.4); BTRAVINE (1.1.0.6) is self-consistent and matches this repo's source (BTL4VER.HPP), so it is the development image. - With the matched image the game boots through the resource check and BTL4Application construction, polls the RIO on COM1, then reads the VPX link at port 0x150, gets 0xffffffff, and fails rcv_protocol with 'length 65535 too big' — the exact VR_COMMS.C path the plan predicted. Adds emulator/baseline.conf (repro) and emulator/PHASE0-RESULTS.md. Working binaries (dosbox-x/, image/) are git-ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
122 lines
5.2 KiB
Markdown
122 lines
5.2 KiB
Markdown
# 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.
|