CydandClaude Fable 5
943219345a
Second operator report, same day: "what is that yellow orange artifact on the
display, it too shows up here and in bt411 but not in the original" -- a
solid vertical bar beside the RANGE readout on the colour head.
It is the same defect as 5.3.83's MFD bleed. Not a similar one: the same
676 pixels.
HOW IT WAS CAUGHT. 5.3.83 shipped a fix that could not be verified, because
the fix makes something INVISIBLE and the A/B rig's boot cockpit already
showed zero MFD extras -- the unfixed build looked perfectly clean. So this
commit adds a POSITIVE CONTROL instead of another argument:
BT_TRANS_PROVOKE fills the colour head's uninitialised
translationTable[64..255] with 0xFF00 -- every high-byte head bit --
rather than the zero the fix installs. Any draw that indexes the tail
then lights ALL the mono heads at once.
On the boot cockpit that lights exactly 1030 pixels: Eng1/Eng2/Eng3 +1030
each, Mfd1 +684, Mfd2 +704, Mfd3 +1074, Comm +676, against 0 extras with the
fix. The bug was firing the whole time. Our heap simply happened to hold
zeros in that tail -- the same luck the shipped binary has been having, which
is exactly why the operator sees the artifact and the A/B rig does not.
THE OFFENDER, NAMED. oormask.py renders which pixels those are and prints
their horizontal run lengths. The mask is a glyph cluster plus 52 runs of
13px -- a SOLID 13x52 BAR at screen (526,228)-(538,279). Solid means a
rectangle in the source art, so decode the art:
BTSEC1.PCX, the colour head's own 480x640 background, contains exactly
ONE out-of-range value in the entire image: index 254, exactly 676
pixels, a solid 52x13 rectangle at (199,526)-(250,538).
The sec port is configured at ROTATION 270, mapping source (x,y) ->
screen (y, 479-x). That puts the rectangle at screen x 526..538,
y 229..280. Measured mask: x 526..538, y 228..279. Same rectangle, to
the pixel.
ONE READ, TWO SYMPTOMS. translationTable[254] is never written (
BuildSecondaryTranslation fills only 1<<numberOfBits = 64 entries), and
DrawPoint ORs the result in unmasked. Whatever the heap left there decides
which symptom the operator sees:
low 6 bits set -> a coloured block on the COLOUR head, beside the RANGE
readout. The yellow-orange bar.
high 8 bits set -> garbage in the MFD / ENG / COMM planes. The bleed.
Both reports, one uninitialised int. It also explains the "not in the
original" asymmetry without needing the original to differ in code: it does
not differ, it is just getting zeros there. And it explains BT411 showing it
too -- both reconstructions inherit the read from the archive.
5.3.83's zero-fill therefore cures both, and turns a heap-lottery into a
guarantee. Still not DIRECTLY observed cured, because no rig we have was
showing the artifact to begin with; that honesty is recorded in the file
header rather than smoothed over.
ALSO IN: oormask.py, barbox.py, vis_provoke.conf, and a README section on
positive controls -- when a fix replaces garbage with a benign value, build
the variant that replaces it with a maximally LOUD value, because that turns
"I see no difference" into a number and separates "the fix works" from "this
screen never exercised the path".
METHOD NOTE, recorded in the README because it nearly cost the fix: three
grabs of one running instance score IDENTICALLY, so the within-boot noise
floor is zero -- and that is the wrong floor. Judging a rebuild needs the
ACROSS-boot floor (~6px on the MFD heads). A single bad grab, caught
mid-draw, read as a 2700px regression and nearly got a correct change
reverted.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
- 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. - Every
.CPPhere has a.NOTES.mdsidecar 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.CPPitself stays clean 1995 style — no modern annotations inside. - Assert line numbers are constraints. The binary's
Fail()sites record the original file+line (BTL4APP.CPP:400etc.); 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. - Layout mirrors the original tree:
BT/(bt.lib, 36 TUs) andBT_L4/(btl4.lib, 13 TUs + BTL4.CPP), matching the survivingBT.MAK/BTL4.MAK.
What drives the work
- The per-TU manifest:
C:\VWE\BT411\reference\BT410_SOURCE_MANIFEST.md(tooltools/manifest410.py; method logphases/phase-03-bt410-source-manifest.md). - The decomp:
C:\VWE\BT411\reference\decomp\all\part_*.c(+section_dump.txtstrings). - 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:
- 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. - The dependent headers (
mechsub,mechmppr,btl4mppr,emitter+mechweap,btplayer,projtile,missile) ship WITH their TUs against the staged MECH.HPP. - 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).
Link campaign (build410, 2026-07-19)
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).