Files
psxrecomp/runtime
Alex Vanderveen 287d9a1c22 probe: actually FILL the register array, and refuse a capture that did not take
Every register came back 0x00000000 — including $sp, which cannot be zero in
running code. The struct had gpr[32] and the JSON emitted it; nothing ever
wrote to it. The patch that added the fill did the replacement in memory and
never wrote the file, and the next edit re-read from disk without it. Two
thirds of a change, compiling and running and reporting 32 zeros.

Zero then flowed all the way downstream without anything objecting: 0 minus the
load offset masks to 0x1FFFFFF4, which looks like an address, so colour_inputs
read "psx-runtime's table" from unmapped memory and reported a difference
against the oracle. The same document carried "differing_bytes": 0 and
"source_identical": false — the read had come back short, so zip() compared
nothing while the buffers still differed.

Three guards, because one bad value crossed four steps unchallenged:

  * probe_registers refuses a capture where every register is zero and says so,
    rather than returning zeros as data
  * plausible_pointer() rejects anything that is not a RAM address before it is
    used as one, including the masked underflow that got through
  * the comparison refuses unequal read lengths instead of reporting a
    difference between a buffer and nothing

Scratchpad is deliberately not a plausible table pointer: $sp lives there, and
accepting it would compare the wrong region while looking entirely reasonable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 12:55:58 -04:00
..
2026-08-15 14:46:26 -07:00
2026-08-13 10:37:18 -04:00
2026-07-29 03:18:10 -04:00