docs/SEGMENT_AWARE_CODE.md §5.7, §7. The synthetic probe gains an overlay
phase that loads code the way a game loads an overlay. After the three
probe_run sequences it:
- leaves the critical section the BIOS started it in, because the kernel's
CD driver waits on CD interrupts;
- reads its own EXE file back from the disc through the BIOS file calls
(B0:32 open, B0:34 read, B0:36 close; the kernel DMAs the sectors) into
RAM at 0x000A0000;
- calls the copy of a position-independent ov_run there through KUSEG,
KSEG0 and KSEG1, timing each run with Timer 2.
It records the T2 deltas and ov_getpc links at R+0x28-R+0x3C, and the file
descriptor and byte count at R+0x40/0x44. In the runtime that code is
CD-DMA'd RAM code. Capture records its entries with their segments, and
compile_overlays.py builds a shard per segment.
The phase replaces the `j .` spin with a `j` of the same size, so every
earlier label keeps its address. The static probe code and every result
word it wrote before are unchanged, and so are its probe_run cycle-watch
hits on Beetle and native. Beetle on both BIOSes: T2 56 / 56 / 82 and links
0x000A0A2C / 0x800A0A2C / 0xA00A0A2C, the same shape as probe_run.
The ledger gains the regression guard overlay-segment-shards (§5.7). It
builds the capture record overlay_capture.c writes for the probe's
disc-loaded ov_run (schema v3), splits it with capture_segment_views(), and
compiles each view as the fragment pass does, with compile_overlays.py's own
helpers and the real recompiler. It requires:
- every PC each shard bakes, and its names, to be in its segment;
- the manifest's S and F records;
- ov_run's straight run to cost Beetle's fetch-model cycles: line leaders
cached at KUSEG and KSEG0, +4 per fetch at KSEG1.
KNOWN_GAPS stays empty.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shokunin
fdc354543d