Commit Graph
11 Commits
Author SHA1 Message Date
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
CydandClaude Fable 5 e13575d3ac Phase 2: FIFO transport working + RIO validated on real hardware
RIO (Phase 5) validated with real hardware: with a physical RIO on
COM1 and serial1=directserial realport:COM1, the game's 1996 RIO
driver talks to the board — the 'RIO never came back' error is gone
and expected activity was seen on the RIO board.

VPX FIFO fast path decoded (OUTSW.ASM + capture): after i860 boot the
render protocol pumps 16-bit words to a FIFO data port seen as
0x154/0x155 byte writes, payload starting with the 4-byte action. The
device now extracts FIFO message actions (confirmed vr_init=0 with the
args string, vr_create=1 with node type 0x2D) and echoes replies with
handler-specific overrides from board source VR_REMOT.C (init/statistics
reply action = 1).

Blocked on one unknown: velocirender_sync checks the init reply against
a constant that is neither 0 nor 1, so the Rel 4.10 board differs from
the DPL3 dev source. Needs the Rel 4.10 LIBDPL source or disassembly of
BTL4OPT.EXE at the format string (file offset 0x107772). Device has a
VPX_INIT_REPLY experiment hook for candidate values.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 23:41:49 -05:00
CydandClaude Fable 5 f236d15d51 Phase 2 progress: boot handshake + i860 download solved; FIFO path mapped
The VPX responder device now drives production BattleTech v4.10
through the full transputer/i860 boot, far past the Phase 1 wall:

- iserver boot handshake solved: feeds 3 well-formed 'version' (tag 42)
  iserver requests, satisfying startup_handshake()'s 3 transactions.
- i860 download solved: parses the outbound framed renderer messages
  (vr_860args/code/data/bss) and absorbs them, staying byte-aligned.
- echo-action reply model validated against board source
  (VRENDER/VR_REMOT.C reply() echoes the received action); device
  tracks and echoes the last outbound action generally.

Remaining sub-protocol identified and characterized: after i860 boot
the host switches to a FIFO fast path (OUTSW.ASM: 0x40 tag + REP OUTSW
16-bit words to FIFO port 0x154/0x155, gated by ok_to_fifo at 0x160).
The current build stops at velocirender_sync because the device only
implements the slow byte path. PHASE2-PROGRESS.md documents the exact
next steps (FIFO transport + render loop -> Phase 3 OpenGL backend).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 23:18:45 -05:00
CydandClaude Fable 5 e3c090695d Phase 1 complete: captured VPX boot conversation from shipped binary
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>
2026-07-02 22:46:20 -05:00
CydandClaude Fable 5 f680ed0585 Phase 0 complete: DOS game boots to VPX link protocol on Windows 10
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>
2026-07-02 19:33:34 -05:00
CydandClaude Fable 5 f7ebde2e0b Add VPX emulation implementation plan for Windows 10 cockpits
emulator/PLAN.md: run the unported DOS Rel 4.10 games in the
surviving cockpits via a DOSBox-X fork with an HLE device
impersonating the Division VPX board at its C012/B004 link
interface (I/O port 0x150 per BTLIVE SETENV.BAT), rendering the
frame stream in OpenGL. Cockpit RIO (COM1) and plasma (COM2) pass
through to the game's original serial drivers (L4RIO.CPP).
Eight phases with acceptance criteria, evidence table, protocol
appendices, risks, and test strategy. Gauge displays deferred.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 19:09:33 -05:00
CydandClaude Fable 5 326d29b72a Extract all recoverable Division scenes; add Scene Archive gallery
Cracks the DIV-BIZ2 binary format (BGF/BMF) using Division's own
reader source (DPL3/BIZREAD.C) as reference: block stream, 14 vertex
layouts, pmesh/strip connectivity, LOD nesting, embedded materials.
Adds SVT raw-texture decoding, 1995-dialect VGF support (implicit
CONNECTION_LIST, header SCALE), and a whole-drive scene audit.

108 of 241 scenes on the Glaze drive are recoverable; 26 are curated
into restoration/vwe-archive.html, a self-contained WebGL gallery:
Star Trek, Hull Pressure, BattleTech (incl. the polar-map mech
lineup), Red Planet's Mars-canal raceway, and the Canyon demos.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 18:03:12 -05:00
CydandClaude Fable 5 5e9f191e0b Add TREK.SCN restoration: converter and WebGL viewer
Parses the DIV-VIZ2 formats (VGF geometry, VMF materials, TGA
textures, SPL splines, SCN scenes) from the STDAVE directory of the
Glaze drive and re-renders VWE's unreleased 1996 Star Trek pod
scenes in a self-contained WebGL page: the Enterprise-D among
drifting starfields (TREK.SCN) and the Klingon flyby (KLNGVID.SCN).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 15:19:52 -05:00
CydandClaude Fable 5 ce1b4ca9de Document the Glaze developer drive findings in HISTORY.md
Records the contents of the recovered VWE developer hard drive
(git-ignored sda4/): pod lab infrastructure, Division renderer
source with i860/Pixel-Planes 5 code, runnable game builds, and
unreleased projects (Star Trek prototype, Hull Pressure, Renegade
Legion, and the Starship Troopers pitch that became DisneyQuest's
Invasion!). Includes a source-completeness analysis showing the
engine libraries are rebuildable but most game-logic sources are
absent from this release cut.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 14:50:38 -05:00
CydandClaude Fable 5 ae768d3849 Ignore sda4/ developer hard-drive dump
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 13:59:18 -05:00
CydandClaude Fable 5 fdd9ac9d97 Initial import: Tesla Release 4.10 (Tesla:BattleTech & Tesla:Red Planet)
Archival snapshot of the Virtual World Entertainment Tesla cockpit
software, 1994-1996: MUNGA engine and L4 pod layer source (Borland
C++ 5.0), BT/RP game code, and game content (models, audio, maps,
gauges, Division renderer data). Includes third-party libraries:
Division dVS/DPL graphics, HMI SOS audio, WATTCP networking.

Files are preserved byte-for-byte (.gitattributes disables all
line-ending conversion). README.md documents the layout, target
hardware, and toolchain.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 13:21:58 -05:00