h3 says 2 units per guest frame, units-per-second-measured says
time-integrated at 56.8 units/s, and my own page says 1 unit per present.
All three rest on real data and one mechanism explains all of them: the
clock advances one unit per VBLANK, and presents can be dropped without the
clock caring.
That accounts for the corpus's steps of +17/+34/+51 (1, 2, 3 vblanks
between two logged presents), for the same animation spanning 21 labels in
one capture and 33 in another -- which a strict per-present clock cannot
produce -- for h3's three plate steps of 23, and for my own 14 consecutive
steps of 17 in a run that dropped almost nothing.
My "1 unit per present" was nearly right and named the wrong clock. At
--framerate_limit=30 Xenia vblanks at 30 Hz and the guest presents ~30/s,
so presents and vblanks coincide and the test could not tell them apart. It
correctly refuted time-integration; it could not locate the tick.
Solid: the RATE follows the vblank rate. 255 declared units take 4.26/4.16 s
at a 60 Hz vblank and 8.45 s at 30 Hz -- 59.8/61.3 against 30.2 units/s. A
time-integrated clock predicts 4.25 s in both. So a console at 60 Hz gives
60 units/s, and the port's value stands on a third independent route.
Not solid: per-vblank vs per-present. My step samples are ~12 per run,
which cannot separate them, and I say so rather than reading 18% vs 0% of
two events as support. The load-bearing observation for the mechanism is
the corpus's 21-vs-33, not mine.
The discriminating experiment is named and not run: log Xenia's
D1MODE_V_COUNTER beside each present and check every step is exactly
17 x (vblanks elapsed).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
c114b6239d