The first live run produced the decisive timeline -- the 216-colour
content arrives from CD-ROM DMA (0x8001FE80, ch3) at the scene load, so
the savestate theory is dead and the table holds raw disc data -- but a
Ctrl-C at the end lost the report, because it only saved on clean exit.
Every transition now flushes immediately.
Also runs against DuckStation: it has no wtrace, so transitions report
unattributed there -- which is all the oracle side needs, since the
question is WHERE ITS TIMELINE DIVERGES from native's: does DS's copy of
the region also become 216 raw colours after the CD load and then get
overwritten to ~5 by a later step that native never runs, or does DS's
CD load deliver different data in the first place?
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
slice_check overturned two things at once: all 256 colour words ARE
rewritten every frame, and the writes themselves carry 152 distinct
values -- so the colour routine reads a per-vertex source table, and
vertex_taps' uniform loads were just its 64 probe slots landing on the
first few quads. That reinstates the finding withdrawn earlier: the
table at 0x800E25F0..0x800E2C60 is one per-vertex array, DS's $s4
(0x800E2C04) is inside it, native's copy holds ~216 distinct colour
words against DS's ~5, and DS renders correctly from its copy.
Write-tracing the table never fires, and CD-ROM DMA was checked: ch3
moves words through psx_write_word, so a disc load WOULD be traced.
What is not traced is anything that memcpys RAM wholesale -- savestate
and rewind restores above all. The user syncs the two emulators by
lining up savestates: if native's state file carries the corrupt table,
no writer exists in this session at all.
So watch the data, not the writers: poll the region's fingerprint while
the user plays in from as far back as possible, report every content
transition with the distinct-colour count either side, and attribute it
against the armed write trace. A transition with traced stores names the
writer; one with none is a wholesale restore, and the corruption rides
in the state file that was loaded.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alex Vanderveen