Answers question 1 of the 2026-09-02 play-test: interpolate or hold. It
interpolates, piecewise-linearly, evaluated once per present at one unit
per present.
palogo_sqex_eff gives 28 distinct alphas over 28 consecutive presents,
changing on 26 of 27 adjacent pairs. It is not one slope, and the disc says
why: that element declares 0:a=0 -> 15:a=255 -> 30:a=212 -> 45:a=0, three
segments with three gradients. Predicted -2.87 and -14.13 per unit against
measured modal steps of -3 (x6) and -14 (x9). The declared keyframes
predict the per-frame steps, which makes this a prediction rather than a
description.
So the port must lerp: hold-to-next-key would emit 3 states where the game
emits 28. And "eased" is the wrong description -- there is no easing
function, the envelope only looks eased because consecutive declared
segments have different gradients.
Alpha lives in the per-vertex k_8_8_8_8 colour, rewritten into a fresh
vertex buffer every frame. Not a PS constant (ps_c[n=0] on 1048/1048), not
a blend factor, not a texture swap.
🔴 And the game's splash is ALSO mostly frozen. Measured with the same
statistic the play-test used on the port: the game moves 21.2% and 27.8%
against the port's 16.4%, and its longest frozen run is 3.34 s against the
port's 3.20 s. The publisher declares 205 of 255 units -- 80% -- as a flat
hold at full opacity.
That refutes the play-test's second clause. "A fade does not hold one
picture for 3.20 s" -- this one does, for 3.34 s. Its first clause stands:
26 states for a 45-unit build-in is too few, the game gives 49 and 51.
The deficit is the state count, not the freeze: ~100 against 26. Acting on
the second clause would have sent the port to remove the one part of its
splash that is already right.
Not answered: which function does it. This is the behaviour; the
image-side half of question 1 is still open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Ran --framerate_limit=30 against predictions committed beforehand. Every
discriminating row went to the frame-based column:
frame-based time-based (mine) measured
presents/s ~27 ~27 28.4
modal alpha step 17 unchanged 34 doubled 17 UNCHANGED
units/s ~30 halved ~60 unchanged 30.2 / 30.3
publisher dwell ~8.5 s ~4.2 s 8.450 s DOUBLED
developer dwell ~7.0 s ~3.5 s 6.923 s DOUBLED
Both controls passed first. The limiter took effect (28.4 presents/host-s
against 51-55, interval mass moving from one 60 Hz vblank to two, 422 of
468), and all 8/8 splash quad rects are identical so nothing but the frame
rate differs.
So the UI clock advances exactly 1 unit per presented frame. The step is 17
on every quad at 28.4, 51.4 and 54.8 presents/s, and 255*1/15 = 17 with the
declared T=15. units/second = presents/second, and seconds are not a
property of the game.
The port's 60 stands: the guest presents once per 60 Hz vblank
unconstrained, and 1 unit per present at 60/s is 60 units/s. Same answer as
my first position, finally with a tested mechanism instead of an inference.
This withdraws units-per-frame-is-not-a-constant.md in its central claim.
My "a time-based clock is immune to dropped frames so the dwell is stable"
was a real prediction and it failed -- the dwell doubled. The four-run
agreement I read as evidence was four runs at similar frame rates.
h3-units-per-frame-measured.md's +34 is now the anomaly rather than the
rule: 34 per label at 27.2 labels/s against 17 per present at 28.4
presents/s. Both cannot be presents. Not asserting it is wrong, only that
one of them must explain the disagreement.
Three of my four positions came from inference over a measured quantity;
this one came from changing an input and watching what moved. The
opportunistic comparison pointed exactly the wrong way because nothing
controlled what else differed between those captures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
The port raised this as load-bearing and it is answered, without a speed
factor.
I expected to find the three cold boots slow and argue contamination. They
are not. My capture reproduces them: publisher 4.263 s against 4.297 /
4.604 / 4.370, developer 3.457 s against 3.508 / 3.503 / 3.366. Four runs
agree, so that defence is unavailable and I am not using it.
The flaw is in the comparison. 2.125 s is the publisher's declared
ANIMATION length; 4.3 s is how long the SCREEN is up, and the screen holds
after the timeline ends. Measured as counts in one capture: the publisher
is on screen for 219 presents and animates for about 128 of them. The
falsifier would have found a contradiction at any units-per-second.
The decisive number needs no speed factor: 51.4 presents per host-second on
the publisher splash, 53.8 on the developer. Xenia's limiter marks vblank
at 60 Hz and caps presents there. A 30 fps guest presents every second
vblank, at most 30 per second, and a slow emulator can only make intervals
longer. 51.4 > 30, so a 30 fps guest cannot produce this. A 60 fps guest
can: 51.4 is 86% of 60, matching the vblank histogram's 14% drops.
So 60 units/s is refuted by a count against a hard limit rather than by a
duration against a fitted factor -- the argument the 2.13 s reconciliation
could not make.
The dwell corpus stands in its own terms. Those seconds are the screen's
dwell on this emulator, reproducible, and were never a statement about
units per second.
Recording what I got wrong on the way: I first segmented the atlas eras as
"both splashes then the title" and briefly had a 2x discrepancy that would
have let me declare the dwell corpus contaminated. The segmentation was
wrong, and the durations matching the corpus to 1% is what exposed it. A
convenient answer from an unchecked segmentation is the same trap as a
clean answer from an unguarded assumption.
Reach unchanged: still one boot for the hash ratio.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Answered against the pre-registration committed before the capture, with a
content hash added to the draw logger.
The buffer rotates three times faster than the content changes: 177
presents carry 3 base addresses but only 102 distinct content hashes, and
the modal run is exactly 2 presents per decoded frame. Consecutive presents
with changed content = 0.5739, inside the pre-registered R band of
0.40-0.60.
That is precisely the failure that invalidated my first answer this
morning. The base address changed every present, which I measured and read
as one decode per present. The content did not.
ADV.wmv is authored at 30.000 fps, so 2 presents per movie frame is 60
presents/s, and 2 units/present x 60 = 120 units/s.
Both controls pass, and they are the ones the withdrawn version lacked --
its two guards tested how I READ the buffer, neither tested whether a
buffer change meant a decode.
Control 1, a static texture must hash constant: the splash atlas changes
once, at an era boundary, and never within an era -- 1 change in 403
samples. Noting that I first wrote this control as "must be constant" and
it read FAIL; stated that way it was wrong, because a re-upload is real
content change and the control has to separate temporal from alternating.
A control that is too strong gets waved away, which is its own failure.
Control 2, the movie luma hash must not be constant: 102 distinct.
Consequence: the plate's t=236 is 1.97 s, not 3.93 s, and the port shows it
~1.96 s late. That is play-test finding 3, and "about two seconds" is the
size the human reported. Every declared duration in seconds across the
corpus is half what we have been quoting; unit counts are untouched.
The 2.13 s third route is explained by emulator speed, and that explanation
is labelled POST-HOC and is not offered as support -- fitting a speed
factor to close a gap is what this corpus keeps losing claims to.
Reach: one boot. This number has moved twice today and a second independent
boot should come before the port rewrites a timeline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Published this morning, withdrawn the same day. The measurement was real;
the inference was not established.
My own pre-registration named three ways the instrument could lie and
guarded two. The third -- "the guest may be frame-locked to its own
presentation rather than to the movie clock" -- is the one that occurred,
and a perfect 1.0000 is exactly what it produces: a triple buffer rotating
once per present gives run-length 1 at ANY frame rate. So the measurement
cannot separate a 30 fps guest decoding one movie frame per present from a
60 fps guest rotating a buffer per present.
The methodological error is the part worth keeping. I wrote the guard down,
saw a result so clean it had no tail, and read the cleanness as strength. A
clean result on an instrument whose key assumption is unguarded is not
confirmation -- the cleanness may be the failure mode's own signature. Both
guards I did build tested how the buffer was READ; neither tested whether a
buffer change means a decode.
What surfaced it: the draw log carries a per-frame gtick marker I had not
noticed. It is host time rescaled (Clock::QueryGuestTickCount is
host_tick_count * guest_tick_ratio, scalar 1.0), so it is a wall clock and
cannot be read as a rate -- but its SHAPE has no phase. Xenia locks vblank
to 60 Hz, and the present interval is ONE vblank 71.7% of the time and two
24.6%. A guest hard-locked to 30 fps presents every second vblank and would
put the mass at 2.
I am NOT replacing it with 120. Three routes now disagree: the withdrawn
movie cadence says 60, the vblank cadence says ~120, and
title-plate-delay's 120 declared units in 2.13 s measured twice to 6 ms
says ~56. Two of the three must be wrong and I do not know which.
Publishing 120 would repeat the mistake this commit withdraws.
The port is told to keep 60 for now, and told plainly that it is an
authored value rather than a measured one.
The settling experiment is named: hash the movie luma plane's CONTENTS per
present rather than its base address, which separates "the buffer rotated"
from "a frame was decoded".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
The blend bit has been decoded against RB_BLENDCONTROL0 since 2026-08-31,
but ui_layout::blit could not draw it, and said so in a comment citing a
refutation that is <render-vs-capture> -- this renderer disagreeing with
itself while it had a stale keyframe association, no leaf geometry and no
rotation.
The consequence the port raised: verify-screen compares two renderers, so a
renderer that structurally cannot express a declared field makes the check
incapable on every screen that uses it -- 12 of 16 -- and the tolerance
silently excuses all of them. A quiet check is worse than a failing one.
Both equations come off the game's own pixel shader, which premultiplies
(oC0 = rgb*A, A), so only the blend register differs: 0x07010701 gives
rgb*A + dst*(1-A), 0x01010101 gives rgb*A + dst. Additive therefore
saturates rather than wrapping, and a transparent or black source is the
identity -- neither is a choice.
No plumbing needed: t8ad::parse already stores +0x04 as T8adImage::flags.
Four controls, pinned against arithmetic per the rotation precedent. The
fourth is the only one that can fail for the right reason: the first three
pass just as well if blit ignores the flag and draws everything additive,
so the discriminator flips only the blend on one sprite and requires two
different answers, each equal to its own equation. That is the same failure
class as the port's non-inverting latch check and my own backward scan that
resolved every guard to "internal".
120 passed, 0 failed on the full lib suite.
67 sprites over 14 screens were being drawn with the wrong blend, including
10 of 18 on the title and ptbtn00f, the PRESS (A) plate's highlight.
R1: tools/stale-instrument render-vs-capture lists 8 claims that died to
this instrument, including both legs of the rest() pair and "the plate-free
title capture may be too early to be settled", which sits on play-test
finding 3. None is re-derived here; this only records that the instrument
no longer exists in that form.
Also corroborates the port's H5: pgloading_loop5 is an ELEMENT resolving to
sprite pgloading_ring.t32, which is additive. I could not find loop5 as a
sprite in any pak and nearly reported a false contradiction from the
element/sprite name split.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Answered against the pre-registration committed before the capture.
Units per second was the last open number on the PRESS (A) plate, and both
prior measurements of it were wall-clock readings off an emulator that runs
the guest slow by an unknown factor. They disagreed by 2.9x, because a 30 Hz
guest at full speed and a 60 Hz guest at half speed look identical on a wall
clock.
The ruler here is not a clock. ADV.wmv declares 30.0000 fps in its own ASF
header, so a decoded movie frame is a tick the emulator's speed cannot
stretch. Presented frames per decoded movie frame is guest_fps/30 with no
wall clock in the chain.
predicted H_A 30 fps -> 60 units/s -> 1.0
H_B 60 fps -> 120 units/s -> 2.0
measured 1.0000
Both pre-registered guards pass. Guard 2: a perfect repeating 3-buffer
cycle, 52 uses each (exactly 156/3), 2 chroma planes per luma on 156 of 156.
Guard 1: run lengths are 156 runs ALL of length 1 -- no smear, so the
dropped-movie-frame bias that would have pushed the answer toward 120 is
measurably absent rather than argued away.
So H_A. The port keeps its 60 and changes nothing.
REFUTES the live H3 hypothesis that 120 units/s explains the play-test's
late plate. That hypothesis was well-formed and attractive precisely because
it would have explained the complaint, which is why it needed a ruler that
is not a clock.
Which means finding 3 still has no cause. The strongest remaining candidate
is decoded rather than speculative: the plate's declared onset is t=214, not
t=236 -- a 22-unit fade, matching the T=22 the oracle confirmed by measuring
+23 alpha per presented frame on that element.
The pre-registered control could NOT be run: this logger build emits vb=
addresses, not vertex contents, so there was no alpha to check +34 against.
A weaker control is substituted and labelled -- the splash shader/blend
census, which validates the log's structure (what this measurement uses) and
not alpha extraction (which it does not).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
input-pad-read-path.md says of the word the C_PAD_DECODER reads: "There is
no shift and no remap on the way in -- the bit positions are XINPUT's own."
That is wrong. sub_8220D500 rebuilds the word out of XINPUT_GAMEPAD before
anything else sees it, into the game's own numbering.
bits 0-3 A B X Y
bits 4-7 left stick UP DOWN LEFT RIGHT (+/-20000 of 32767)
bits 8-11 right stick UP DOWN LEFT RIGHT
bits 12-15 D-pad UP DOWN LEFT RIGHT
bits 16-17 START, BACK
bits 18-19 LB, RB
bits 20-21 LT, RT -- digital, threshold >220 of 255
bits 22-23 L3, R3
Extracted mechanically from the image, no row typed by hand. The control is
the shape of the result: the 24 assignments land on bits 0..23, each used
exactly once, none repeated. A misdecode does not produce a bijection over a
contiguous range, and coincidence does not put the stick and D-pad
directions in the same order in two aligned nibbles.
So every mask in that page's tables names the wrong button. The 0xE000 x18
site, read there as "B | X | Y", is "D-pad DOWN | LEFT | RIGHT" -- eighteen
sites testing a menu cursor, which is what 18 sites should be.
And its headline negative is REFUTED: "LB and RB are not menu inputs" is
false. They are bound at config fields this+0x70 and this+0x84, LT/RT at
+0x74/+0x80. The negative was searched for 0x0100/0x0200 -- LB and RB in
XINPUT's numbering -- in a word where they live at 0x40000/0x80000. Right
function, right buttons, wrong bit positions, so it could only come back
empty. A negative is only as good as the numbering it was searched in.
Also decodes the ring record: +12 HELD, +16 PRESSED, +20 RELEASED, +28/+32
raw trigger bytes. Edge and level are one struct four bytes apart, which
displaces that page's guess that press-vs-hold was split between GetState
and the XamInputGetKeystrokeEx queue.
The superset claim in that page survives and is untouched: sub_82457038
really does compare every XINPUT_GAMEPAD field, and it really is
XINPUT-layout. This page depends on it.
Not decoded: which output bit means which ACTION, and per-screen sets. 5 of
18 output-bit sites did not resolve to a pad guard, so the output map is a
lower bound -- in particular "START is not tested" is NOT claimed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Three sections, the correction first.
The rate is per-GamePart: title ~57, splash ~35-40. I gave them 56.8 an hour
ago and said the reach was the title; the splashes now have their own number
with T read off the disc. The hold is what makes it safe to hand over -- 160
declared units in 4.514 guest seconds, with no T, no alpha slope and no
interpolation in the arithmetic, agreeing with the same screen's ramp which
shares none of its algebra. Told them a splash played at 60 runs 1.5-1.7x
too fast, which is a TIMELINE cause for the complaint we had both filed
under blur. Classified measured, not decoded, and told them not to extend
either number to any other screen.
The R1-re-opened 'declared timeline reproduces the captured splash' settles
in favour of the timeline: 39/50 exact under truncation, worst error one
alpha level in 255, nothing off by more than one. So their export's splash
keyframes are right and the rate was the defect.
Refutation attempt on their H5, recorded whether it survived or not: it does
not. build_12 and build_15 have identical declaration bodies, so identical
statistics is one fact rather than two coincidences -- as do 0/1, 2/3 and
11/14, while 4/7, 5/8, 6/9 and 10/13 genuinely differ. Also recorded the trap
I hit first: the dump header carries the build number, so the compared text
contained the label distinguishing the subjects and every pair read as
different. A self-comparison control caught it.
Two results, one of which corrects me.
1. The R1-re-opened 'declared keyframe timeline reproduces the captured
splash' resolves in FAVOUR of the declared timeline. Instrument is a disc
keyframe table against the guest's vertex stream -- no renderer in the chain,
which is what the 'our-reader' tag demanded. Calibration-free test: is each
captured alpha an exact member of the declared piecewise-linear value set at
integer t? 39/50 exact under truncation, 30/50 under rounding, and the worst
error under either rule is ONE alpha level in 255. All 11 non-exact samples
are low by exactly 1 and all are on falling segments. The old refutation
rested on 'still at a=255 nine frames after its declared a=32' -- under the
fixed layout a=32 is at t=206, four units from the end of a 210-unit
timeline. That was the off-by-one association.
2. The unit->seconds rate is PER-GAMEPART, which corrects what I told the
port an hour ago. Title ~57 units/guest-second; splash ~35-40. The splash
figure is confirmed two ways that share no algebra: a 15-unit ramp (T read
off the disc, not borrowed) and a 160-unit HOLD, which is a declared
duration with no T, no alpha slope and no interpolation in it.
And my 'the borrowed T=15 does not apply' was wrong in the other direction:
the disc says T=15 plainly. What failed was the premise of a single global
rate, not the T. Noted at the foot of that page rather than by editing it.
The trap worth recording: all four elements give 650-679 alpha/s, agreeing
to 2%, which reads exactly like one clock. It is a coincidence -- T differs
22 vs 15 and the rates differ 57 vs 37, and the ratios nearly cancel. A
quantity that looks constant across screens is not evidence of one clock
when the thing that would vary is inside it. The hold breaks the tie.
For the port: a single keyframe_units_per_second cannot be right, and a
splash played at 60 runs 1.5-1.7x too fast -- shorter, sharper fades than
the game's, which is the direction the play-test reported.
The capture reached the title AFTER the harness stopped classifying, so the
plate's ramp was in the log with tick stamps after all.
ptbtn00: alpha 11->231 over 334.4 guest ms = 657.9 alpha/s. With its
independently attested T=22 that is 56.8 units per guest second, inside the
pre-registered 55-65 band. The final step of every ramp is excluded because
it clamps at 255 and reports more elapsed time than it consumed -- including
it drags the plate to 633.0 alpha/s, a 4% error entirely inside the clamp.
Control passes at 1.15%: ptcopyright gives 650.4 alpha/s, and at one shared
clock that makes its own segment T=22.25. Two elements agreeing on a rate
AND independently landing on a round declared length is stronger than either.
Why my earlier 29.9 was wrong, and it is the failure the page predicted: it
used T=15 borrowed from a row that is about A element with a 15-unit fade,
generalised to splash B's quads, which is not what that row says. At 56.8 the
splash elements' implied T is 23-34, none of them 15. And the step quantum
does not rescue 15: splash steps are multiples of 17 = 255/15, which is what
made 15 look confirmed, but at T=28.5 a step of 17 is simply TWO units of
8.9. A quantum fixes T only if you already know the step is one unit.
60 is NOT refuted -- 5.6% away against ~5% quantisation resolution -- so the
port keeps it. But this DOES eliminate the unit constant as a cause of a late
plate: at 56.8 units/s t=236 lands at 4.15 s against the port's 3.93 s, so
the port is fractionally early.
The Port asks whether the blend is evaluated on sRGB-encoded values or
linearised and re-encoded. It is answered by one register field I already
log, and the answer is the same on every draw of two full captures.
RB_COLOR_INFO.color_format is k_8_8_8_8 (0) on 2402/2402 splash draws and
33779/33791 draws of the boot-through-title capture; the other 12 are
k_32_FLOAT and k_16_16_FLOAT and are not colour passes. k_8_8_8_8_GAMMA (1)
appears ZERO times, and color_exp_bias is 0 everywhere so nothing stands in
for a gamma either.
The mechanism is Canary's own source, not our inference: k_8_8_8_8_GAMMA is
the ONLY colour format around which a piecewise-linear gamma<->linear
conversion is applied (spirv_shader_translator.h:510 PWLGammaToLinear /
LinearToPWLGamma, render_target_cache.h:720, dxbc_shader_translator_om.cc).
With k_8_8_8_8 there is none, so the blender operates on the stored values
as they are.
So a renderer that linearises before blending and re-encodes after is doing
a different operation -- and the difference is gamma-shaped and exactly zero
on unblended pixels, which is the divergence signature the port reports.
Also renamed my units-per-second pre-registration off the 'h4' prefix: the
Port's BLOCKED.md numbers this blend-space question H4 and two different H4s
in one corpus is how a citation goes wrong.
Three rows the port is blocked on:
H3 -- 2 units per guest frame, measured on the plate's own ramp against a
pre-registration. Their 5 excluded by >2x, and the reason named: an alpha
step is not a clock rate without the element's declared T, and my own
splash-quad-timeline.txt published alpha against frame with no T column.
That file now warns at its head.
The title settle anchor is t~160, not t=118 -- it is ptcopyright, the last
build-in element and the only glyph one. Said plainly that this is the
reading under which their clock:'shared' collapses, and that a consequence
is not a counter-argument.
Told them NOT to change their 60 units/s yet: units/second is untouched by
this and two of my own captures disagree ~2.9x on frames->seconds.
The pad: sub_82457038 reads every field of XINPUT_GAMEPAD, 14/14 loads
verified against the image, plus a second keystroke-queue path. Flagged as
the superset the game can SEE, not the per-screen set, so it is used to
check a binding table and not to write one.
The Port asked which of two of my measurements to believe, 55 units/s vs
~150, a factor of 2.7 off one game. Measured on the plate's own declared
ramp, against a pre-registration committed first.
PREDICTED 11 frames at 2 units/frame, 4.4 at the Port's inferred 5, +/-1.
MEASURED 10 labels, and three consecutive gap-free steps of EXACTLY 23,
which is 255*2/22 on the nose. 5 units/frame is excluded by >2x.
Why the splash read as 5: an alpha step is not a clock rate. For a linear
segment d(alpha)/frame = 255*(units/frame)/T. Splash B's quads step 34 with
a declared T=15; the plate steps 23 with a declared T=22; ONE clock, two
steps 1.5x apart. And the Port's intervals start at each quad's first
submission, which on splash A is already alpha=85 -- not the element's t
where alpha=0, and biased by a different amount per element because T
differs. My own splash-quad-timeline.txt published alpha against frame with
no T beside it, which is the column that makes the conversion possible; it
now carries the warning.
The other half: the 'title settled' anchor is ptcopyright reaching full
alpha -- the last build-in element and the ONLY glyph one, which is what a
glyph counter settling means. Calibrated on the plate's own ramp it lands at
t~168 (t~176 at a flat 2.0/label). The Port's candidates are 118 and 160, 42
units apart: this is 8-16 units from 160 and 50-58 from 118. It is 160.
Instrument fact that bounds all of it: labels with zero draws exist, ~1 in 5,
and the clock does NOT advance a fixed amount across them -- across label
5376 the plate moved +82 where three adjacent labels each moved +23. So an
empty label is a real advance, not a logger artefact, and spans that cross
one are approximate. The conclusion rests on the gap-free steps.
Also recorded: the sweep leaves never settle. They translate monotonically
through every label examined and are still moving when the plate arrives, so
'settled' can only mean the build-in elements are done.
NOT answered, and it is what the port actually needs: units per SECOND.
units/s = (units/frame) x (guest fps); this pins the first at 2 and says
nothing about the second, and 2x30 vs 2x60 differ by exactly the ~2 s the
human reported. My own title-plate-delay-measured.md's 2.13 s does not
reconcile with this capture's 20 labels for the same two anchors -- a real
~2.9x disagreement, now localised to frames->seconds rather than
units->frames. Settling it needs the guest's own frame counter, which
neither capture read.
Play-test finding 4 asked, in order: is there a pass, what is it, where do
its parameters come from, only then what curve. All four, from GPU state.
1. NO post-process pass. Over all 1 048 draws of frames 4..226 (both boot
splashes): rt0=[tile=0 fmt=0 exp=0] on 1048/1048, pitch=1280 msaa=0 on
1048/1048, edram_mode only ever kColorDepth or kCopy, resolve dests only
the two alternating front buffers, and NO texture base anywhere in the
capture equals a resolve destination. The only texture bound in the whole
splash region is the sprite page 0x11A50000. No blur, no bloom, no fade
quad over a resolved image, no tone curve, no resolve-and-resample.
2. What it is: per frame, a full-screen replace triangle (the clear), a
full-screen black quad through the ordinary blend, ONE batched sprite
draw carrying every visible element (indices 4/8/12/24), and the two
presentation resolves.
3. Where the parameters come from: NOT the constant banks -- the splash
pixel shaders read zero float constants, ps_c[n=0] on 1048/1048, taken
off each shader's own float_bitmap. NOT immediates. The fade is the
per-vertex k_8_8_8_8 colour in a vertex buffer the guest rewrites every
frame.
4. The curve falls out of 3 and is the corpus's existing 34/frame law,
reproduced on an independent capture. Not claimed as new.
And the composite is ORDINARY SOURCE-OVER, confirmed from the shader ucode
rather than inferred from the blend register: the register reads
ONE/ONE_MINUS_SRC_ALPHA, which looks premultiplied, and is -- because the
shader premultiplies. The two together are src*A + dst*(1-A). So the 'more
pronounced' fade is neither a blend difference nor a pass.
The likely mechanism instead: the developer splash submits SIX quads, three
logos plus three slightly-larger companions that lead them by 8 frames and
are gone 79 frames early. Two over-blended copies of the same art at
different scale is a halo, on screen only during the entry.
Refutation attempt, recorded: REFUTED.md's re-opened rest() pair states its
settling condition as 'a draw capture of the developer splash naming which
of the three glows is submitted at rest'. This is that capture. All three
companions ARE submitted in all 21 frames -- so no rule that hides one
describes this stream -- but they are NOT interchangeable: Q6 leaves the
plateau on its own -5.6/frame decay while Q4 and Q5 hold 255. The one-byte
sibling difference is drawn.
Trap recorded with the evidence: censusing the whole 600-frame log finds six
640x360 textures sampled ~330 times each, which reads exactly like a
half-resolution blur chain. They are the attract movie's chroma planes and
first appear at frame 234, after both splashes. Restricting the window is
what separates them.
Evidence: docs/re/data/splash-draw-pass-census.txt,
docs/re/data/splash-quad-timeline.txt, docs/re/data/shaders/*.ucode.frag.
Logger: canary sylpheed-re d90d14e02.
Reverses two of my own pages. t32-blend-mode-not-on-disc.md said the mode is not
on the disc; ui-blend-mode-measured.md classified it measured and told the port
that which field selects it was unknown. Both were honest and neither is current.
Bit 0x02 of +0x04 set means the game draws that sprite ADDITIVE
(RB_BLENDCONTROL0 = 0x01010101); clear means premultiplied alpha-over.
Fit: 35 elements over three screens, 16 set/additive and 19 clear/alpha-over,
zero errors, every label read out of the guest command stream rather than off a
render.
Control: of every bit of the first twelve header words, exactly one separates
those 35 without error. Nothing ties with it -- which is precisely what the
+0x08 = 0x8050 candidate failed.
Within-pair: ptbtn00 0x0110 alpha-over against ptbtn00f 0x0112 additive, same
screen, same bundle, adjacent draws, one bit apart. And other f variants are
bit-clear and alpha-over, so it is not 'focused variants are additive'.
Out of sample: a prediction committed at 088df91, before its capture, on a
different archive -- GP_OPTIONS entry 19, 3 additive of 16, falsified if any
other element drew additive. The game drew exactly po_menu_eff01/02/03 additive
and nothing else.
This revives a claim REFUTED.md killed. The refutation said blending those
sprites additively worsens every measure against the capture -- a claim about
our renderer, made while that renderer had a stale keyframe association, no leaf
geometry and no rotation. Recorded as a revival with its evidence;
check_refuted.py passes with 0 unmarked assertions.
Two other readings of the same bit stay refuted and are explicitly not revived:
'the name contains eff' and 'premultiplied storage'. Those were the bit's
meaning; this is its effect.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port asked for the sweep strips' vertex alpha as a function of position. It
is not a runtime curve to sample: ptloop01/ptloop02's nested leaves declare four
keyframes each, with x, alpha, rotation, scale and time.
pteff03 loop 600u x -639 -> 1521, alpha 255 -> 128 -> 255, rot +30, sy 600 %
pteff03a loop 720u x 1721 -> -839, alpha 0 -> 128 -> 255, rot -45, sy 800 %
Checked against three sessions of GPU draws: both signs right every time, and
magnitudes within ~15 % of the declared slopes.
The independent bit worth having: across sessions the measured alpha spans
45..242, and only pteff03a declares alpha below 128 -- pteff03's ramp never
leaves [128,255]. The strip measured at 45 is the 1303-tall one, which the AABB
geometry says is pteff03a for a completely different reason. Two identifications
agreeing.
Stated as limits rather than buried: this cannot separate the two declared
slopes, which are 25 % apart against a quantisation of 6.4 px and one alpha
level over 3-4 frames; and absolute phase is unchecked because the AABB-left to
element-x mapping under rotation and pivot is not established.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
REFUTED.md kills this claim: 'T8aD +0x04 bit 0x02 selects an additive blend ->
mine, and refuted. Blending those sprites additively worsens every measure
against the capture.' That refutation rests entirely on our renderer, which the
corpus's own rule calls a hypothesis under test. The blend is now measured off
the GPU, so the claim can be tested against the oracle.
35 elements over three screens, every label an RB_BLENDCONTROL0 value read from
the command stream: 16 bit-set and additive, 19 bit-clear and alpha-over, zero
false positives, zero false negatives.
The control that makes it a decode rather than a coincidence: of every bit of
the first 12 header words, EXACTLY ONE separates those 35 elements without
error. Nothing ties with it. A perfect partition on a small sample is worthless
if half the header partitions equally well, which is the mistake +0x08 = 0x8050
was.
And the pair no confound survives: ptbtn00 = 0x0110, ptbtn00f = 0x0112 -- the
PRESS (A) plate and its own highlight, same screen, differing in exactly this
bit, drawn alpha-over and additive respectively.
Committed alongside is a PREDICTION for GP_OPTIONS, written before the capture
that tests it: a different archive, a different element set, and a MIXED
prediction -- po_menu_eff01/02/03 additive, 592 elements alpha-over. Falsified
if those three draw alpha-over or anything else draws additive. The developer
splash was considered first and rejected as a test: both its elements predict
alpha-over, so it can fail but cannot discriminate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The four elements the port measured as the worst on EXTRAS, and which appeared
in no draw, were in a draw all along: the 24-index additive batch holds six
quads and Canary printed the first two. Cap raised to 64, screen re-captured,
all six named. Same draw as ptframe3, whose state was already measured -- the
one-way implication doing real work.
pteff10 is identified too, and it needed the resting SCALE: it ships as 409x144
and is drawn at 200 % x 500 % = 816x720. The matcher's 'try 1x and 2x' rule
could not name it at any scale and reported a near miss against something else,
which is a failure wearing the clothes of an answer. Candidates are now the
declaration's pivot*2 scaled by the resting keyframe as well as the texture at
1x and 2x, and the tolerance is the log's own NDC print quantisation rather than
a chosen number.
Flagged rather than buried: pteff10 measuring additive is in tension with the
port measuring it nearly exact under alpha-over. Both can be true for a dim
semi-transparent glow over a dark background, and it is the one row a rendering
check does not corroborate.
Also stated: the three full-screen alpha-over draws are NOT individually
identified -- four elements declare 1280x720 -- so the label on those rows is a
candidate, not an identification.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two more emulator runs close two of the three reach limits on the blend page.
THE TITLE (entries 4 + 2 composited). Everything alpha-over except the two
rotated sweep strips and -- the finding -- ptbtn00f, the PRESS (A) plate's
focused variant, which is ADDITIVE while its own base ptbtn00 is not. That is
what the documented plate pulse is made of, and a port drawing both alpha-over
cannot reach the pulse's peak by any pacing.
And ptlogo_back2 / ptlogo_back2eff are ALPHA-OVER. They are frame-shaped, large,
dark and 94 %/87 % transparent -- every surface property the menu's ptframe* have
-- so 'frame-shaped and mostly transparent implies additive' is refuted on the
one screen that could test it.
THE MENU replicates draw for draw in two further sessions; the one-session
caveat is retired.
THE VERTEX CAP was 8 = two quads, so a batched draw reported its first two
elements and dropped the rest. Raised to 64. This is why ptframe4, pteff21,
pteff22 and pteff23 looked like elements the game never draws: EXTRAS' 24-index
additive draw holds six quads and the log printed two.
THE SWEEPS are on screen on the main menu in every captured frame, stepping
~0.03 NDC per frame in opposite directions with their vertex alpha ramping, at
different phases in two sessions. The leaf group runs on the menu. What that
does not say is how much they contribute.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The declaration entry's kind word (+0x28) and its focus/nav index (+0x2C) are the
same fact twice: kind & 0x2 is set iff the focus index is >= 0. Checked over 24
UI paks and every parseable build in each -- 1062 focusable elements, 14431 not,
zero exceptions. The test is two-sided, so it would fail if any focusable element
lacked the bit or any non-focusable element carried it.
Consequence: kind == 0x3002 is not the test for a button. It catches 778 of 1062
and misses 284 (26.7 %) at 0x2, 0x2002, 0x3003, 0x73002, 0x73003 -- including
ptbtn00.rat on GP_TITLE's PRESS (A) plate, which is 0x73002. And 0x3000, 817
elements, looks like a button and is not focusable.
This is also the refutation attempt on sylpheed-port's kind census. Their claim
-- every decoration 0x0, every button 0x3002 -- is exactly right on the two
screens they checked, reproduced here independently, and fails one build over on
the title they have not run yet.
The other kind bits are reported as observed structure and explicitly not
claimed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes the one route t32-blend-mode-not-on-disc.md left open: the executable's
draw path. Canary's UI draw capture now logs RB_BLENDCONTROL0 per draw, and the
game was driven to the main menu and to EXTRAS with F10 at each.
The title-side UI uses two blend states and ONE pixel shader:
0x07010701 src=ONE dst=1-SRC_ALPHA alpha-over (premultiplied)
ptbase, pteff05, the fade quad, ptmsg, ptmsg2, pttitle, buttons
0x01010101 src=ONE dst=ONE ADDITIVE
ptframe1, ptframe2, ptframe3, pteff20, both rotated sweep strips
Two controls, both run before the result was read:
* the NDC->pixel conversion that identifies a draw by its quad size reproduces
1134 and 1303 px for the two rotated sweep strips -- numbers measured by a
different tool in a different session -- on BOTH screens. The tool prints
PASS/FAIL and disclaims its own output on FAIL.
* pixel shader 0xE59B2B3DA4AA9008 is used with BOTH states, 12 draws additive
and 18 alpha-over. ptframe1 and ptbase run the same shader; only the blend
register differs. So this is a blend result, not a shader result.
This confirms the port's independent measurement -- it solved the composite per
pixel from two backgrounds and found additive halves alpha-over's error on both
frames -- by a route with nothing in common with it.
So the blend is no longer authored: 'any blend you choose is authored' was true
of the disc and is not true of the game. What is still unknown is which field
selects it; elements sharing a mode are batched into one draw call, so the
selection happens before the draw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port measures four elements as rendering too dark against the capture --
ptframe1/2 on the main menu, ptframe3/4 on EXTRAS -- with the shortfall
correlating +0.77/+0.80 with the BACKGROUND and only +0.24 with the element's
own contribution. That is the signature of a blend that scales what is already
there. It asked whether the disc selects one.
Three examples, one negative, wider than the one I gave last iteration:
* frame_alpha_census -- every T8aD sprite on builds 5 and 6 by alpha. It
REFUTES the port's own sharpener: 'neither frame has a single fully-opaque
pixel, against ptbase's 99.1 %' is true, and pteff10 (max alpha 130, 100 %
partial, no opaque pixel) is measured by the port as NEARLY EXACT. So being
wholly semi-transparent is not what makes the frames special.
* frame_vs_accurate_words -- all 12 T8aD header words for both screens, plus a
per-BIT sweep of +0x04 and +0x08. NO word and NO bit puts the four frames on
one side and pteff10 on the other. It also kills my own remaining candidate a
second time: +0x08 = 0x8050 is shared with pteff21/22/23 on EXTRAS.
* frame_keyframe_unknowns -- the keyframe record's fade, tint, rotation and its
two unexplained signed words. unknown_4 and unknown_8 are ZERO on every
keyframe of both screens, so they carry nothing here; no frame takes a value
of any field that another element does not.
Reach: the 60-byte declaration entry, the T8aD header word-wise and bit-wise,
and the keyframe record. Four elements, two screens. Not the executable's draw
path, which is the next commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port mapped the menu's edge residual at 64 px tiles and handed over
coordinates without names, which is the division I proposed: the map is theirs, the
element inventory is mine.
Under the hot band at x 384..704, y 64..256 sit ptframe1.t32, ptbtn01.rat (the NEW
GAME button) and pteff12.t32, an effect element -- all three hot under BOTH
coordinate readings, so the answer does not depend on whether their tiles are in
design or capture space. ptbtn02 is hot in design space only.
So the hot region is not one element but three of different kinds overlapping, which
is consistent with their null: they looked for two families of tile and found one
continuous population, so the region has no character of its own.
This names what is there, not what is wrong -- their map already excludes local
displacement in these tiles. Also records their control limit: a +2 px displacement
reads back +0.839 because the slope saturates, so any slope they report is a floor
on the displacement and never a ceiling.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The ja capture of DIFFICULTY is taken. EN and JP differ in 1.82 % of pixels, in four
bands and nowhere else: the heading (DIFFICULTY -> 難易度選択), a 2 px ring shift, the
BACK label (-> 戻る) and the footer. EASY/NORMAL/HARD do not appear in the differing
set -- the Japanese release leaves the three difficulty names in Latin script.
So 2/3 are a language pair, and the disc agrees quantitatively: 2.77 % of bytes
differ against 1.82 % of pixels on screen. This closes the item left open when I
withdrew 'an EN/JP pair' as a bare assertion, and it is now measured rather than
inferred from the disc's convention.
The JP screen also opens on NORMAL like the English one, and the sweep reproduced
the reset finding in Japanese.
Reach: one JP boot, one screen. It does not generalise -- GP_TITLE 4/7 is already
known to differ by more than text.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port checked the JP layout from their export: the disc declares identical
button rows for EN and JP on main_menu and extras. Recorded separately rather than
merged with mine, because they are different quantities -- their rows are declared
rest positions, my 225.5 is a runtime ring row on a surface offset ~65 px from
design space. Either could have disagreed, which is what makes them independent
legs, after a week of finding legs that were not.
Neither is evidence for GP_DIALOG 2/3; both are about GP_TITLE.
Also records the mid-run substitution: I diagnosed a detector failure from a log
line showing glyph 11654 when the capture was one read away and showed the detector
working. A log line is a summary someone wrote, and reading it as the observation is
the same substitution as trusting a harness note.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The run was launched to settle whether GP_DIALOG 2/3 are specifically EN and JP. It
did not reach DIFFICULTY: the reach probe's round trip failed at the final A, the
game sat off-menu at glyph 11654, and the sweep then timed out without pressing NEW
GAME.
Not a detector problem, which is what I assumed while watching. The JP menu detects
perfectly at glyph 320 against English's 327, both inside the 250..420 band; the
11654 is a later phase.
What it did establish: the locale took, and this is the first JP main-menu capture
in the corpus. JP initial focus is 新規 -- NEW GAME, top item, ring y 225.5, the same
item and row as six English boots. And the ring rows match English exactly, so the
JP build places its buttons where the English one does. That is language-pair
structure at the MENU, which is not the dialog pair the question is about.
Locale restored and verified at language = 1 by the trap, on a failing exit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port turned my point -- that a static record still declares a cycle, so a
nonzero +0x08 against a largest time of 0 is a real disagreement -- into a check on
the screens they ship. Re-derived from my reader and it reproduces exactly: 65
nested records in GP_TITLE, 20 declaring a cycle with every pose at t == 0, and 0 of
those with any element carrying more than one pose.
A record whose elements each hold a single pose renders identically looped or held,
so holding them still is correct and now measured.
It includes ptbtn11/12/13, EXTRAS' buttons in both language entries, each declaring
120 units with one pose per element. Had any carried two poses, a menu button the
disc says animates would have been held still on the one submenu the port's P5 gate
walks.
Reach: GP_TITLE only; 1530 static records exist disc-wide against the 20 here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two things, both from reading the image.
The record layout is {id, name_ptr, handler}, not {handler, id, name_ptr} as first
published -- the same three fields shifted by one word, so every record was credited
with the previous record's handler. Caught by a control dump: under the old
alignment record 0 had a 'handler' of 0x10000000, not a code address. ids and names
are unaffected and DLG_SELECT_DIFFICULTY is still id 2000; only the attribution
moved. Corrected histogram over 70 records: 0x821D0808 x43, 0x821D05D8 x24,
0x821CFD80 x3.
And the id-to-pak-entry join is not reachable this way. All three handlers load the
same global at 0x828E2B14 and two take addresses at 0x828E45E0/4640/467C, and every
one of those sits inside a 364 601-byte contiguous zero run -- BSS, populated only
at runtime. Controlled: the dialog table itself reads non-zero through the same
arithmetic, so the addressing is right and the data is genuinely absent.
Reach stated: this closes one route, not the question. 'Not in the image' is not
established -- 'not reachable from the dialog handlers' is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port has found four retractions that never reached their source and I found
one. A register cannot catch the general class, since it holds only claims already
retracted. Tried to build something that does not need the retraction.
Attempt one, flagging tools whose cited page is newer, gave 126 candidates and no
signal -- pages are appended to constantly. Attempt two, narrowing to pages that
later received a commit whose subject marks a correction, gave 43. Sampled three
and all three are false positives: each tool cites its page for one fact while the
correction concerns another.
The proxy fails structurally -- co-citation is not co-reference -- so it is not
published. Reach: 3 of 43 sampled, rate not established, only shown low enough that
the report is not worth reading.
What found all five real instances was a person reading a sentence for its own sake.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The two adjacent pairs with identical element sets split. 0/1 are the same 59 810
bytes stored twice -- a duplicate, not a language pair. 2/3, the DIFFICULTY build,
differ in size and in 2.77 % of bytes from offset 0x1BB while sharing every element
name, which is what a language pair looks like.
Control: entries 10/11, known to be two different dialogs, differ in 54.90 % of the
common prefix, so the comparator separates unrelated dialogs.
Supported, not proven, with the untested step named: I have not captured DIFFICULTY
in ja. That the two are ENGLISH and JAPANESE rests on the disc's convention, not on
a capture of this screen. This partially restores a claim I withdrew, at lower
strength than the original phrasing.
Also records a refutation attempt on the port's BGM_103 exclusion: it survives and
is tighter than they stated -- of 32 census rows, exactly one bank carries EITHER
wave size, not merely both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port re-ran my closing of the 37 and one of its two legs fails. I wrote
that sprite counts differ between adjacent stage-title dialogs; 12/13 is equal,
thirteen each, and it is visible in my own printed output which I generalised from
the 10/11 example beside it. Our absolute numbers also disagreed because we counted
different things and I did not say which I meant.
The conclusion is untouched -- the stage numbers settle it alone. The shape is the
point: the leg carrying no weight is the one that went unchecked, which is the
EN/JP pair failure one step out, committed while writing up that very failure.
Also records that a conclusion with two supports reads as better evidenced than one
with a single support, so a decorative support makes the appearance of redundancy
itself misleading.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Both agents left the language reading standing for the 37 pairs that differ without
a button-count mismatch, and both observed that nothing rewarded closing it. Two
scans closed it, against my own reading.
All 39 equal-button-count pairs share button names and rows exactly, which does not
settle it -- two dialogs sharing a button template look identical by that test. What
differs does settle it: pzstg10 against pzstg02, pzstg11 against pzstg03, pzstg12
against pzstg13. These are the DLG_STAGE_TITLE01..16 dialogs and an adjacent pair
carries two different stages, with different sprite counts, which is a different
amount of text rather than a translation of the same text.
So the whole 63 is explained by one fact -- adjacent entries are unrelated dialogs
-- with no residue. The 2 identical pairs remain unexplained but are no longer
anomalous against a hypothesis, because the hypothesis is gone.
Recorded about process rather than the disc: a bound nobody is incentivised to test
is exactly where a convenient claim survives, and the next reader cannot tell
whether a bound was respected or merely never revisited.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port refuted the untested reading I recorded yesterday with a count, and I
reproduced it: 26 of 65 adjacent GP_DIALOG pairs differ in BUTTON COUNT, which two
languages of one dialog cannot. The names agree once read rather than counted --
ranking_NEXT against ranking_JUMP, py_ranking against pzeff, pzstg10 against
pzstg02.
So adjacent entries are unrelated dialogs, the 63 never needed the language
reading, the 2 matching pairs need no special account, and the 140:70 ratio is a
counting coincidence -- the same fact my halves-pairing zero was showing from the
other side.
Preserving their caution: this does not establish that 0/1 and 2/3 ARE language
pairs. Identical element sets is equally consistent with a duplicate, and for the
37 pairs differing without a button-count mismatch the language reading is
unsupported rather than refuted.
Withdraws a delivered claim: I called entries 2/3 'an EN/JP pair' in HANDOFF. The
DIFFICULTY identification does not rest on it -- unique geometry plus the capture
does -- but it was stated as fact and was not one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
GP_DIALOG has exactly 140 entries against the table's 70 records, a 2:1 ratio that
would make the unbound join an ordering question. It does not hold: adjacent
pairing gives identical element-name sets on 2 of 65 pairs, halves pairing on 0.
GP_TITLE's language pairs share element sets exactly, so identical sets are the
signature there; in GP_DIALOG almost nothing matches.
Residual and unexplained: the only two adjacent pairs that DO match are entries 0/1
and 2/3, and 2/3 is the DIFFICULTY build.
A reading I am not asserting: dialog text may be baked into language-specific
sprites, which would explain the 63 by construction but leaves the 2 needing their
own explanation. Not tested.
The join stays unbound; positional ordering is now ruled out, which narrows where
to look next.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Chasing the reach I recorded this morning found the binding it said was missing.
Every DLG_ string in the image is pointed at by one aligned word at a 12-byte
stride: {u32 handler, u32 id, u32 name_ptr}, spanning 0x820A0A2C..0x820A0D68 with
three distinct handlers. Complete -- 70 names, 70 records, none unmatched -- and the
ids are banded and monotonic with a single gap at 24. Read from the image directly.
Refutation attempt on the shared reach, which both agents had recorded: 'another
four-button dialog with the same rows would be indistinguishable'. Scanned every
build in every pak for four buttons within 6 px of 259/329/399/469. Control found
both incumbents; zero rivals exist anywhere on the disc. So the geometric
identification is unique disc-wide, which is stronger than what either of us
claimed.
Still unbound: id 2000 to a pak entry. The tie remains uniqueness plus the oracle
capture, not a pointer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes a negative of mine whose failed assumption I had named: I searched for an
8-record btn-named build in an archive of its own, assuming DIFFICULTY's four items
pair with f variants the way GP_TITLE's screens do. It has its own prefix and is
not a GamePart screen at all.
Three independent routes agree. The image lists DLG_SELECT_DIFFICULTY among the
DLG_* dialog names at 0x820A41BB, and GP_DIFFICULTY appears zero times. GP_DIALOG
entries 2/3 are the only builds there with pcbtn00..03 -- four buttons at design
rows 259/329/399/469, spacing 70, an EN/JP pair. And my capture of the running
screen puts its four rows within 4 px of those, with spacing 70.5/69.5/70.0 against
the disc's 70/70/70.
Reach stated: the entries are identified by button count and geometry, not by a
binding from the DLG_ name to a pak entry. No such binding was found.
Also notes the consequence for Q6's count-match: NEW GAME opens a DIALOG from an
external archive, which still matches the count but is not the same category as
OPTIONS or TUTORIAL opening a GamePart.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Re-ran the peer cross-scan with their known-positive assertion and my earlier count
was wrong. Third phantom reader in one session: a second parse of the same file in
the same minute returned a clean table with total 0, because their register rows
are bare phrases and that parse searched each row for a quoted string. My first
parse worked only by falling back to the whole line.
Real count: 11 occurrences of their 12 registered claims in my corpus. Three of
them are in the file I wrote to report on their claims -- so I produced the relay
loop they described while documenting it, and the effect is now measured rather
than asserted.
New: a cross-convention collision. '1 of 3 streams' is a dead claim in their
register and a live warning in mine -- both my occurrences read that the warning
STANDS. Not a revival; two corpora using the same words for different propositions.
That is the strongest argument yet for keeping cross-agent checks advisory, and it
is an instance rather than a worry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
They asked in the right form after their own 'latent, not active' turned out to be
a stale-copy artefact. My version: zero of my registered claims appear in their
files, from my tree AND from their branch head, controlled with a live probe
because a zero from a broken reader looks identical.
Then the part they left to me. My first reader of their register was broken and
returned a false zero: I regexed quoted strings out of their script and got 63
phantom phrases. The register is a heredoc of 12 rows. Parsing it properly finds 3
of their claims in my files, across 4 locations -- one of which is my stale copy of
their own BLOCKED.md and not mine to judge.
None is a live revival. Every one sits on a page whose subject is the corrections
themselves, which is what they predicted without asserting.
Their restraint is the transferable part: their first fix counted the six as
failures, applying their [refuted] convention to a corpus that marks corrections
its own way.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Serves Q6's open question. boot-config-and-gamepart-registry.md records a
count-match for the title part's event numbers -- four menu items load an external
archive, EXTRAS stays inside GP_TITLE -- explicitly as an observation rather than a
decode. Half of it is disc-checkable and now has support.
Every button record in all 16 GP_TITLE entries: ptbtn00 (the plate), ptbtn01..05
(main menu), ptbtn11..13 (EXTRAS). No fourth button screen, so no DIFFICULTY build,
and DIFFICULTY is what NEW GAME opens. The other four destinations have their own
paks -- GP_OPTIONS, GP_SAVE_LOAD, GP_TUTORIAL -- while EXTRAS' two children are
GP_MISSION_SELECT and GP_MOVIE_THEATER, so EXTRAS is internal and its children are
not.
Still NOT a decode of the event numbers: the shape the count-match asserts is real
on the disc, but nothing shows a given event is a given row.
Negative recorded with its reach: DIFFICULTY's build is not located. I searched for
an 8-button-record build on the assumption its four items pair with f variants, as
GP_TITLE's screens do. They may not, so the negative is narrower than 'not found'.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
No new boot was spent: six runs had already captured the first menu entry of a
fresh boot, and all six read NEW GAME. Three of them follow a session that ended
with the cursor on EXTRAS or OPTIONS, which is what makes it a test of persistence
rather than a repeated observation.
Reach stated rather than implied: every session ends with the emulator KILLED, so a
game that writes menu state on a clean shutdown would never get the chance. This
measures 'does not survive a killed session'.
Refutation attempt on the port's extras/initial_focus: ptbtn11 -- it SURVIVES.
ptbtn11 is the top button on the EXTRAS build, with the main menu as a control
where ptbtn01 is top and is known to be NEW GAME.
Incidentally corrects ring_row.py's stated calibration. It cited capture_y = 49.5 +
1.060*design_y, fitted against menu_focus.py's row centres, which are NOT the
disc's button rows -- the disc says 162/242/322/401/482, spacing 80, and
menu_focus.py drifts up to 17 px against them. Re-fitted: 64.82 + 0.9919*design_y,
residuals under 0.7 px. No item assignment changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
DIFFICULTY is the screen that separates the readings: it opens on NORMAL, second of
EASY/NORMAL/HARD/BACK. Reproduced on a fresh boot rather than inherited from the
2026-08-29 capture. After one confirmed DOWN to HARD, B out and A back in, it
returns to NORMAL -- in-cursor 1.0 from opened against 93.9 from where left.
So reset targets a per-screen opening default that need not be the first item. The
other four submenus could not settle it because on each of them the opening item IS
the first, so both readings predict the same observation.
sylpheed-port's refusal to promote 4/4 to a rule was right on the evidence: a
generalisation from those four would have got this fifth screen wrong.
The probe never presses A inside a submenu, so it cannot reach SELECT DATA and the
guest throw at PC 0x82307128 -- recorded in the tool's source.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
LOAD GAME, TUTORIAL and OPTIONS all reset on re-entry, joining EXTRAS. With the
main menu persisting, the rule is four of four submenus resetting and one
exception -- the opposite of what a single screen had suggested.
Fourth attempt, and every control in it is a previous failure: the decision uses
the cursor's own region so no per-screen geometry is assumed (sweep 1 read the main
menu's gutter on screens whose cursors are elsewhere); the back-on-the-menu test is
the narrow ring row (sweep 2 died when a crash dialog defeated whole-frame
comparison); absolute row checks after every press (a constant offset passes a
differential control); and a two-sided self-test that constructs both verdicts,
which had already caught a rule I broke myself.
Screens confirmed by eye and committed as evidence, because an earlier run was
fooled about which screen it was on. LOAD GAME's 21.6 is explained by its list
scrolling rather than moving a ring.
Still not separated: resets-to-named-item vs resets-to-top-item. None of these
three has an opening item that is not its first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The rework was sound and controlled. The run died because I edited and
deliberately broke the sweep script while its own run was in flight, and the sweep
read the script at its start, which fell in that window.
The self-test refused to run: constructed PERSISTS came back RESETS. Without it the
sweep would have reported RESETS for all three screens -- confident, uniform and
fabricated. First save, on the day it was written.
Three further self-inflicted faults recorded: a competing x11grab during a
measurement (the concurrency confound the port warned of), a pkill -f that can kill
the running sweep's own capture, and a restore that sat as the last line of a
timed-out command so it never ran. The process fix is to commit the tool before
running it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The mission's third classification is 'undecodable, with reach', and a negative
written about the subject when it is about the method is the failure that put 'an
individual SE's audio is not extractable yet' at the head of a page whose own later
section located the waves.
The tool failed its control -- the one known instance -- twice. First the pattern
required a sentence-ending period, and headings do not end in periods, so it matched
nothing in any heading and a clean report would have been vacuous. Then the scoring
hid it, because 'yet' was in my list of scope words. It is not one: 'yet' and 'so
far' are temporal hedges naming no instrument, no search and no place looked, which
is exactly what made that heading read as bounded.
With the control passing, the two amplifier files are clean: every INDEX and HANDOFF
hit read, all legitimate. 130 unscoped candidates remain unread corpus-wide, and the
regex has a high false-positive rate -- recorded as reach, not as a clean bill.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
I told them two BLOCKED rows were stale. One was. Their skip row reads '(a)
ANSWERED, (b) still open' and cites Q9; (b) is a different question and the 🟡
carries it correctly. I read an emoji and inferred a status, which is the same
error as leaving a stale row live -- and the error this audit is about. They
pushed back rather than accepting it, which was right.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
INDEX is read every iteration and is the first thing a new reader meets, and I had
admitted three times to never auditing it. Found by accident: I was about to spend
a boot measuring whether A skips a movie because INDEX said 🟡, when movie-binding.md
had it settled since 2026-08-28 with a three-boot baseline and a delivery counter,
and HANDOFF carried it correctly. The staleness was in the index alone.
Three stale rows fixed: movie skippability, SE audio extractability, and B leaving
the main menu. Five other hits read and left alone -- index and page were talking
about different clauses.
One of the three should have been caught by check_refuted.py: REFUTED holds the
same dead claim with a different second clause, and the register matches exact
wording. Its docstring documents that weakness; this is the first live instance.
Also flags a within-page contradiction not fixed here: menu-audio-cues.md line 81
still heads a section saying SE audio is not extractable, which its own line 189
refutes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port asked whether my capture or extraction paths seek with -ss before -i.
Reproduced on this disc's own movies: a 4.0 s audio request returns 4.597 s (ADV)
and 4.256 s (S00A), with correlations of -0.03 and -0.34 at zero shift, so the
windows are different content rather than shifted. The 4.597 matches their 4.6.
But the VIDEO seek here is exact -- container-seek frame at 20.0 s is byte-identical
to the frame from a full decode with no seek. So the trap is a property of the audio
stream, not of -ss placement as such.
The Explorer has two -ss sites, both video, and its audio path (decode_audio_wav)
never seeks -- so it is not affected. Read only; the viewer is the human's tool and
was not modified.
My own instrument failed twice first: a vstats line read as a timestamp, then
showinfo reporting frames from before an output-side -ss discard. The pixel
comparison needed no interpretation and settled it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Route 1, the port's hardware-consumption reference: I wrote 'no /dev/snd, no ALSA
and no PulseAudio'. The first two hold; the third is false -- I checked only
/run/user/*/pulse and concluded absence from one path, while pactl reaches a server
at /tmp/pulse-*. The route is still blocked, accurately: the only sink is a
module-null-sink, which is software-timed, so there is no hardware rate here.
Route 2, varying host load: void. The 60 Hz and 30 Hz captures disagree by 2.8x, so
neither is a guest rate, and x11grab achieved 17.5 of 60 requested fps -- the
capture path is itself starved and cannot sample a ~28 fps guest.
Records the concurrency confound against my own practice: this session ran cargo
builds alongside emulator boots at least twice, and the older fps and dwell figures
cannot now be audited for it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The estimator had to recover the plate's known 2.53 s period and returned 0.599 s,
its own search floor, meaning no peak was found. plate-pulse-measured.md already
records that this fast-rise/slow-decay waveform defeats sinusoid fitting;
autocorrelation fails for the same reason, so the trap was written down and I
walked into it.
I also reimplemented the title gate without its twelve-sample hold, so the window
straddled the build-in -- the signal ranges 0..5433 where the plate never goes
below 159. And no Looped Data lines were captured at all: Apu logging was on, but
those lines appear only on a wrap, and BGM_103's first wrap is ~96 s after the
music starts against a 90 s window.
The audio-clock result from committed data stands and is unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
