Files
psxrecomp/tools
Alex Vanderveen 2a078ca8d7 DIAGNOSTIC BUILD: instrument why the sector ring starves the guest
Not a fix. The game is expected to still render wrong; this answers one
question that three ring attempts could not, because all three differed
only in the notification path and all three failed with byte-identical
numbers (lost=70, pended=80, the same per-LBA repeat counts). Identical
results across different notification code proves the notification was
never the cause.

The remaining suspect is deliver_read_sector_without_irq(). It raises NO
INT1 by design -- it exists purely to refill the buffer so an in-flight
multi-sector DMA keeps draining. With one buffer the refill lands in the
buffer the DMA is reading and the transfer flows seamlessly. With a ring
it lands in a NEW slot, and nothing moves the read pointer there, so the
DMA starves mid-transfer and the guest retries: exactly the duplicated
Setlocs and 2-7 repeated sector reads observed.

ring_starved counts drains that found their slot exhausted while another
slot held unread data. Non-zero confirms it outright and the fix follows
(the no-IRQ refill must advance the read pointer: it is a continuation of
a drain in progress, not a new notification). Zero kills the hypothesis
and the ring line of attack stops.

ring_norq_refill and ring_read_moves give the supporting picture.
ring_probe.py reads the verdict; a build without the counters reports
no-instrumentation rather than a misleading zero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-24 12:55:58 -04:00
..
2026-08-12 16:49:03 -04:00
2026-08-14 02:41:50 -04:00
2026-08-21 21:38:56 -04:00
2026-07-29 03:18:10 -04:00
2026-07-29 03:18:10 -04:00
2026-08-19 23:35:17 -04:00
2026-08-19 23:35:17 -04:00
2026-07-29 03:18:10 -04:00
2026-08-19 22:50:13 -04:00
2026-07-29 03:18:10 -04:00
2026-08-14 02:41:50 -04:00