Files

T

CydandClaude Fable 5 939ea17d17 Phase 2 COMPLETE: full VPX protocol working; game reaches content loader

Disassembled BTL4OPT.EXE (PE-in-DOS32RTM) to crack the last unknowns:

- velocirender_sync (@0x48D220): sends action 0x2D with a data token and
  checks cmp token, reply.node[0] (the 'unexpected action' text only prints
  the action; the real check is the echoed token). Device now echoes the
  token in node[0]. Sync passes.
- Speculative-poll gating: only feed a reply after consecutive empty polls
  (a blocking inRecord spin), not single handle_iserver_stuff() checks.
- Frame-ack: velocirender_frameack expects action 9 (vr_draw_scene); device
  tracks outstanding draw_scene and replies 9. Frame-ack passes.

The game now passes sync, loads renderer config, builds the scene
(create/flush/list_add/draw_scene), completes frame-ack, and enters its own
content loader (L4VIDEO.cpp) loading BattleTech models. Remaining issues are
content packaging/paths and an empty DPL config -- not VPX protocol. The
board emulation is functionally complete for boot + scene setup + frame-ack.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-03 00:04:33 -05:00

README.md

Phase 1 complete: captured VPX boot conversation from shipped binary

2026-07-02 22:46:20 -05:00

vpxlog.cpp

Phase 2 COMPLETE: full VPX protocol working; game reaches content loader

2026-07-03 00:04:33 -05:00

README.md

VPX device — DOSBox-X integration

Our original source for the emulated Division VPX link adapter. Kept here under version control because the DOSBox-X source tree itself (emulator/src/, ~490 MB) is git-ignored.

vpxlog.cpp — Phase 1 logging device. Impersonates the INMOS C012 link adapter at I/O base 0x150, answers status reads so the game keeps transmitting, and logs every access to $VPXLOG. (Phase 2 will grow this into a responding transputer-monitor + i860-loader + frame-stream renderer, or fork into a separate vpx.cpp.)

Applying to a DOSBox-X source checkout

Tested against DOSBox-X v2026.06.02, MSYS2 mingw64.

Copy the device in:

cp emulator/vpx-device/vpxlog.cpp  emulator/src/src/hardware/vpxlog.cpp

Add it to the hardware build — in src/src/hardware/Makefile.am, append vpxlog.cpp to libhardware_a_SOURCES (we inserted it after glide.cpp).
Call the init — in src/src/gui/sdlmain.cpp, declare void VPXLOG_Init(); next to the other *_Init() prototypes and call VPXLOG_Init(); right after GLIDE_Init(); in the machine bring-up sequence.

Build:

cd emulator/src
./build-mingw-sdl2 --enable-debug=heavy

Output: src/src/dosbox-x.exe.

Running

set VPXLOG=C:\VWE\TeslaRel410\emulator\vpxlog.txt
emulator\src\src\dosbox-x.exe -conf emulator\capture.conf
python emulator\analyze_capture.py

With VPXLOG unset the device is inert and the build behaves like stock DOSBox-X.