Files
TeslaRel410/restoration/source410
CydandClaude Fable 5 4cf09917ce BT410 5.3.57: the crash is deterministic, and the real blocker is the load gate
The previous commit's attribution was wrong and is corrected in the roadmap.

WRONG: 'the crash is the skeleton walk's' rested on 0 crashes in 2 runs with
the walk disabled -- a 25% coin flip presented as evidence.  The oldest
preserved dump has no [skl] line and ends on the old 'couldn't figure out how
to MakeEntityRenderables' fallback, so it predates the walk and faults
identically.

WRONG: 'it lands at different points each time'.  Every dump carries the same
numbers to the byte (cr2 7000FA64, EIP 66D9).  What varies is how far the log
gets, not where the fault is.

Resolving the address through btl4opt.map names it exactly:
EulerAngles::operator=(const LinearMatrix&)+0x19, a read through the matrix
reference.  A binary scan finds all three call sites of that operator pass a
stack local, so the 1.79GB pointer still has no static explanation -- that is
now its own open item rather than a guess.

Two theories killed cleanly by the new BT_STACK_LOG probe and a binary scan:
ESP drift (drift=0 over 2002 frames; exactly one callee-cleans function exists
in the whole binary) and an undersized stack (our PE and the shipped one have
identical 1MB/8K geometry).

What the probe found matters more: the application is parked in state=2, which
is LoadingMission, not WaitingForLaunch.  Priority 0 is where the interest
manager queues renderer events during load, the gate needs that priority empty,
and it never empties -- so the mission never launches and the renderer holds a
blank screen by design.  The fault arrives ~30s into that wait.  Runs that DO
launch never print a single [launch] line.  So 'crashes half the time' and
'hangs during load' are one event seen twice.

A 15x disagreement between two clocks looked like a reconstruction slip --
BTL4.CPP passes GetTicksPerSecond() where ApplicationManager wants a frame
rate.  Checked against the shipped binary before touching it: same instruction
sequence, same kind of static float pushed.  Authentic.  Documented so nobody
'fixes' it.

Also swept every subsystem DefaultData against its real C++ base.  Fifteen
chain past their immediate parent, but fourteen skip only classes that add no
handlers and no attributes, and no class's attribute-ID base disagrees with its
index chain -- so there are no gap slots there.  The one real defect: Generator
is a HeatSink but chained to Subsystem::MessageHandlers, so it ignored every
ToggleCooling message.  Fixed (compiles next build).

Tooling: podrun.sh stages the build over BTL4REC.EXE, exports the host-side VPX
board env -- without which the run dies at the iserver handshake rather than
merely rendering nothing -- and archives every run's log, marking it -CRASH
when it faulted.  Before this the only preserved dump was an accident, on a rig
where each run costs four minutes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 21:41:38 -05:00
..

source410 — literal reconstruction of the missing BT 4.10 game source

Everything in this directory is RECONSTRUCTED, not recovered. The authentic surviving source lives in CODE/ and is never mixed with this tree. The goal here is an archival-grade recreation of the d:\tesla_bt\ translation units that exist only inside BTL4OPT.EXE (the shipped 4.10 binary), written in the 1995 VWE house style against the 1995 MUNGA/MUNGA_L4 engine headers that DID survive.

Ground rules

  1. Never copy a reconstructed file into CODE/ — the assembled buildable tree (originals + reconstructions) is produced by a script into a build directory, so provenance stays unambiguous file-by-file.
  2. Every .CPP here has a .NOTES.md sidecar carrying the evidence: the binary address map, decomp references, which sibling sources supplied each idiom, and every judgment call with its tier ([T1] decomp-proven … [T4] style guess). The .CPP itself stays clean 1995 style — no modern annotations inside.
  3. Assert line numbers are constraints. The binary's Fail() sites record the original file+line (BTL4APP.CPP:400 etc.); reconstructed files are shaped so those calls land on their recorded lines. A file that can't meet its line constraints yet says so in the sidecar.
  4. Layout mirrors the original tree: BT/ (bt.lib, 36 TUs) and BT_L4/ (btl4.lib, 13 TUs + BTL4.CPP), matching the surviving BT.MAK/BTL4.MAK.

What drives the work

  • The per-TU manifest: C:\VWE\BT411\reference\BT410_SOURCE_MANIFEST.md (tool tools/manifest410.py; method log phases/phase-03-bt410-source-manifest.md).
  • The decomp: C:\VWE\BT411\reference\decomp\all\part_*.c (+ section_dump.txt strings).
  • The port's semantic reconstructions: C:\VWE\BT411\game\reconstructed\ (WinTesla-hosted; each literal file here re-hosts one back onto the 1995 engine APIs).
  • Style/idiom exemplars: surviving CODE/BT/*.CPP, CODE/RP/RP_L4/*.CPP, CODE/RP/MUNGA*/** (the 1995 engine source itself).

Status (2026-07-19)

Compile verification is LIVE: ./compile410.sh --sweep (BC4.52 + the authentic OPT.MAK flags; the period compiler is the reviewer). backdate.py mechanizes WinTesla→1995 header back-dating (donors: C:\VWE\BT412\engine\MUNGA\*.h).

item state
THE WHOLE TREE COMPILES (2026-07-19) 11/11: all 10 surviving originals + the BTL4APP.CPP pilot build clean under BC4.52 + authentic OPT flags (./compile410.sh --sweep)
BT/BTCNSL.HPP + BT/BTSCNRL.HPP reconstructed — console wire IDs recovered from the binary (Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1]; TeamScore=12 [T4 GUESS — verify]); see BTCNSL.NOTES.md
BT_L4/BTL4APP.CPP (pilot reconstruction) compiles (18.5KB obj); 12/12 functions, Fail() at recorded line 400
Staged header family (13: mech/mechsub/heat/powersub/mechweap/emitter/mechmppr/btplayer/projtile/missile + btl4mppr/btl4vid) [T3] interface-proven by every surviving consumer; layouts parked in reserved[] blocks — see STAGED-HEADERS.NOTES.md + MECH-LAYOUT.md
MUNGA backfills (VDATA, ROTATION, VECTOR2D, AUDREND, APP, LAMP, GAUGREND, GAUGE) compile-proven (BACKFILLS.NOTES.md)

Next work package — the mech-family, REVISED (round-3 finding, 2026-07-19): the plan to "reconstruct mech.hpp first" was the wrong order. A full read of the port's mech.hpp shows it is a hybrid (1995 skeleton + Recon proxies + port-only members + relocated fields), and substantial regions of the binary's 0x854-byte Mech object remain UNMAPPED — the port declares "the remaining members up to sizeof==0x854" in its mech2-4 slices. A literal MECH.HPP that precedes those TU reconstructions would be fiction. Corrected order:

  1. MECH.HPP is the CAPSTONE, grown incrementally with each mech-family TU reconstruction (mech.cpp → mech2-4 → subsystem TUs), starting as an interface + known-ordered members with explicit reserved[] filler for unmapped regions (sidecar-tracked), tightened as each TU pins its slice.
  2. The dependent headers (mechsub, mechmppr, btl4mppr, emitter+mechweap, btplayer, projtile, missile) ship WITH their TUs against the staged MECH.HPP.
  3. The blocked originals (BTTOOL, GAUSS, PPC, BTREG) and the BTL4APP pilot compile green as those land — BTREG last (it includes the whole game-header world). Offset oracles for every stage: BT411 CLASSMAP.md, decomp-reference.md §3, and the port headers' static_assert-locked members.

Toolchain — IN HAND (2026-07-19)

Borland C++ 4.52, archived at ../../BORLAND/BC45/, chosen by byte-match: the fleet's own CODE/RP/CW32.LIB is identical to 4.52's (and not 4.5's). BCC32/TLINK32/TLIB/MAKE run natively on Win11. The shipped BTL4OPT.EXE recipe is CODE/BT/OPT.MAK (plain bcc32, -DLBE4;DEBUG_LEVEL=0;DEBUG_STREAM=cout, -5 -a4 -ff -k- -V -Jg -x- -RT- + the full -O set, PCH btopt.csm; link -Tpe -ax with c0x32.obj + dpmi32.lib + cw32.lib = Borland PowerPack DPMI32, not Phar Lap TNT). Compile verification of reconstructed TUs is therefore possible file-by-file; the current blocker for full closure is the 1995 engine header gap (vdata.hpp first — only the drifted WinTesla VDATA.h survives, in BT412/engine). Include order for builds: CODE/BT/* over CODE/RP/*, -DNO_PRECOMPILED_HEADERS until the mech-family headers are reconstructed. Remaining gap: TASM32 (JOYSTICK.ASM only).

source410/build410.sh assembles BTL4OPT.EXE: merged-engine mass compile (152/152 green — the ENTIRE surviving engine compiles), BT TUs (11/11), tlib libs (munga 1.25MB / mungal4 with the prebuilt-1995 objs / bt / btl4), then the authentic tlink32 link rooted by a probe main (build scaffold). First true link run: 52 unresolved externals (UNRESOLVED-LEDGER.txt) = the measured remaining gap. Kill-lists: l4gauge.cpp back-date (14 widget statics), the missing-engine-body back-date wave (~24: rotation, player, team, l4app, explode, dropzone, terrain, cultural, subsystm-statics, netclient...), the prebuilt RANDOM.obj fold, and the staged game-TU statics blocks (MECH.CPP et al. — each TU file opens with its binary-evidenced Derivation/SharedData statics and grows into the full body). Link-lib arbitration: SOS = SOSDBXC+SOSMBXC (the 32-bit Borland-flat variants; SOSMW*=16-bit), WATTCP excluded (it belongs to the 16-bit NetNub TSR — the game talks to it via shared memory), filestrm = the RP-era pair (BT-tree pair is post-4.10 drift; override layer).