The install-slot range work is only trustworthy if a second title can
reproduce it, and the two tools that produced its evidence lived in one
game repo with that game's paths baked in. Moved into the framework and
generalised: every path defaults off --project-root (cwd) and the BIOS
profile's out_stem, and the exe is found by globbing the build tree,
because its name is derived from the window title and so differs per
title. Run either from a game project root.
kernel_patch_diff.py boots headless and diffs live kernel RAM against
the ROM copy it came from, joining each differing word to the compiled
kernel bodies. It reads the emitted PsxKernelPatchRange table, so it
separates a DECLARED patch (the verifier skips it, the body still runs
native) from one that genuinely unblesses a body. Without that split its
verdict line calls every declared range "these interpret", which is
exactly backwards once the ranges work. This is the tool you use to find
ranges for a new image or a new Psy-Q release.
kernel_patch_ab.py answers "what did declaring them buy". It boots the
same binary twice to the same frame, once with the ranges live and once
with PSX_KERNEL_PATCH_RANGES=0, which drops them and restores the
whole-body bless memcmp. Holding the binary constant holds the overlays,
the codegen and the disc constant too, so only the bless verdict moves.
Headless runs uncapped, so it normalises per frame rather than comparing
raw totals at different frame counts.
Two things it gets right that cost real time to learn:
- It does NOT discount the A0/B0/C0 vectors from the headline. An earlier
version did, reasoning that they interpret on both sides and would mask
the result. True on one title, false in general: on Mega Man X6 with
OpenBIOS the B0 vector burns 2,361,470 instructions over 1,180,735
entries with the ranges off and vanishes entirely with them on, because
a clean bless verdict lets the vector body dispatch native. Discounting
it hid a 130 insn/frame win. Kernel and all-interp are the headline;
the bodies/vectors split is printed underneath as diagnosis.
- It fails fast on a wedge, detected as a frame counter that stops
advancing while the debug server still answers, instead of burning the
whole timeout. That is how a dispatch key inside a declared range was
caught spinning the dispatch loop at frame 0.
debug_client.query grew an optional timeout so these can use it instead
of carrying their own transport; the 10 s default is too short for
dirty_ram_stats and a whole-window read_ram.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kevin