Hypothesis: our BT_* logging inflates the load window, the window is the
exposure, so a quiet run should load faster and fault less. Both halves
wrong. pod_render_quiet -- which differs from pod_render_rec by exactly the
six BT_* logging vars -- faulted 3/3, same signature, against ~25-40% for the
logged conf.
That is the strongest evidence yet that the residual is a timing-sensitive
HOST bug rather than anything about our data: writing to COM3 changes when
interrupts land relative to the DPMI host's handler-chain walk, and nothing
about our attribute tables or renderables could plausibly be modulated by
whether we print to a serial port. Interrupt phase can.
Two immediate consequences: pod_render_rec is the LESS fault-prone rig, so
use it; and the 'shipped survives' baseline weakens further, since shipped
also writes plenty to COM3 and so sits on the suppressed side of the same
effect on top of its shorter window.
The wall-clock numbers also correct an earlier assumption: 150-275s
boot+load, not ~60s. The 60s figure was the load DRAIN in game ticks; DOS
boot, two diagnose passes and card init dominate the rest.
Next is clearly emulator-side: the host keeps no EBP frames (the frame walk
returned one bogus entry), so naming the routine that owns the chain needs a
breakpoint-style trace of entries to 0x66CF with the head node, diffing a
clean run against a faulting one.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
