Tracing 0x800E2718..0x800E2C60 across 2 frames of the effect recorded
nothing, consistently. That is a real result -- the table is STATIC
while the effect plays, which removes the phase caveat from the finding
that psx-runtime holds 216 distinct colour words there where DuckStation
holds 5, at the same addresses, 1067/1712 bytes differing.
But the old message said 'nothing wrote to this range... the code that
fills it is not running', which reads as 'nothing ever writes this' and
sends you looking for a missing writer. A table filled once at scene
load is simply not written during the effect that reads it.
--watch N traces free-running so the fill can be caught by walking into
the scene with the trace already armed. The empty-result messages now
distinguish the two cases, and the watched one names the remaining
possibility: a DMA fill writing RAM directly is not visible to a trace
built on CPU store hooks.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"the effect is not on screen on psx-runtime, so this code never ran. Currently
drawing: PolyFT4 x584, PolyF4+semi x184, PolyG3+semi x176, PolyFT3 x151" — the
diagnostic added last commit, doing its job on the first run. The effect simply
was not up when the tool looked.
That is the real problem, and it is not a diagnostic problem. Every tool here
needs the effect RUNNING, and requiring it to be on screen at the instant a
button is clicked means racing a transient animation. Losing that race produces
a different-looking failure in each tool — no writes recorded, no candidate
fired, no table found, the block was not reached — four symptoms, one cause,
none of them naming it. Running lockstep beforehand appeared to help only
because it takes long enough for the effect to come round again.
So the tools wait. Press the button first, then trigger the effect; each polls
the display list until its class appears, up to two minutes, and each side is
waited for INDEPENDENTLY in its own thread. That last part matters: it removes
the need to hold two emulators inside the same effect simultaneously, which was
never realistic by hand.
Wired into scale_trace, packet_writers, range_writers and colour_inputs — every
tool that needs the effect. Timing out reports what WAS drawing, because "wrong
scene" and "tool is broken" look identical otherwise. A transient DebugError
mid-poll does not abort the wait: the emulator can be mid-pause, and one failed
poll is not a reason to stop waiting for something that has not happened yet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The colour investigation reached a REGION rather than a structure. With the
effect off, 0x000E0BF8..0x000E6628 is byte-identical between the two emulators
and completely static; with it running they differ. So the base colour data
agrees and the divergence is in what the effect WRITES there — which makes
"what writes this range" the next question, and packet_writers could not ask it
because it assumes a packet layout to classify fields.
Same instrument without that assumption: point it at any span and it reports
which instructions store there, how many times, over what address span, and
with what values. The span matters because a store walking an array is a
different thing from one hitting a single field, and the values matter because
a writer storing the same constant everywhere is clearing while one storing
varied values is computing.
Same two disciplines as packet_writers, for the same reasons. Tracing happens
over a bounded number of STEPPED frames, since the game rebuilds its buffers
constantly and a free-running trace attributes writes to whatever the addresses
meant at some other moment. Code is captured while parked, because these are
overlay addresses and the same PC decodes differently once another overlay
loads.
It also refuses to report an empty trace as a result: if the class that drives
this code is not on screen it says so and names what is drawing instead, rather
than returning no writers and letting that read as "nothing writes here".
The Studio prefills the range from whatever Compare colour inputs last
measured, so it does not have to be copied by hand between panes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alex Vanderveen