CydandClaude Fable 5
e3c090695d
Built DOSBox-X from source with a custom VPX link-adapter logging device (vpx-device/vpxlog.cpp) and captured the game's outbound boot sequence. Findings: - Register map confirmed against LINKIO.C: outputData 0x151, outputStatus 0x153 (polled bit0), resetRoot 0x160, analyseRoot 0x161. - Reset preamble captured exactly (analyse=0, reset 0->1->0 + status inits). - The game streams 85298 bytes to outputData that are BYTE-FOR-BYTE identical to VRENDMON.BTL; first byte 0xF0 = transputer boot-from-link primary-bootstrap length. Protocol stage 1 (reset + monitor download) fully characterized; no hidden bulk/interrupt path. - Production cockpit dump ALPHA_1 added (git-ignored): its BT is v1.1.0.6 with a VRENDMON.BTL byte-identical to the captured stream, so this result reflects the exact cockpit software. ALPHA_1 is the reference image going forward (carries RP + production pod/network boot chain). Adds analyze_capture.py, capture.conf, PHASE1-RESULTS.md. DOSBox-X source tree and capture artifacts are git-ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
115 lines
5.1 KiB
Markdown
115 lines
5.1 KiB
Markdown
# 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.)
|