re: the rate is 56.8 units per guest second -- both predictions hold, control passes

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.
This commit is contained in:
sylph-decoder
2026-09-01 17:11:19 +00:00
parent 1ac388b0c1
commit d67aaaf30b
3 changed files with 108 additions and 1 deletions

View File

@@ -0,0 +1,26 @@
# The animation clock's RATE, in GUEST seconds, off the title's build-in.
# Capture 2026-09-01 (tickcap), augmented draw logger with the guest timebase
# (50 MHz, guest_time_scalar_=1.0). No host wall clock enters any number here.
# The LAST step of a ramp is excluded everywhere: it clamps at 255 and so
# reports more elapsed time than it actually consumed.
## ptbtn00 (the plate)
ramp (label, alpha): (6709,11), (6710,46), (6711,69), (6712,92), (6713,115), (6715,162), (6716,185), (6717,197), (6718,231), (6719,255)
steps (Δα, ms): (35,31.5), (23,46.0), (23,22.7), (23,69.4), (47,49.4), (23,46.9), (12,35.3), (34,33.2), (24,51.0)
unclamped span: α 11 → 231 (Δα=220) over 334.4 guest ms
-> 657.9 alpha per guest second
-> declared T=22: **56.8 units per guest second**
## ptcopyright
ramp (label, alpha): (6675,34), (6676,57), (6677,69), (6678,92), (6679,115), (6680,139), (6681,162), (6683,231), (6684,255)
steps (Δα, ms): (23,47.8), (12,30.0), (23,33.2), (23,46.1), (24,24.6), (23,68.9), (69,52.4), (24,45.5)
unclamped span: α 34 → 231 (Δα=197) over 302.9 guest ms
-> 650.4 alpha per guest second
-> T not independently attested; at the plate's rate this implies T = 255·rate/(Δα/Δt)
## CONTROL (pre-registered): two independent elements, same screen, same run
ptbtn00 (the plate): 657.9 alpha/s
ptcopyright: 650.4 alpha/s
agreement: 1.15 %
-> they share one ramp length as well as one clock; at the plate's T=22
ptcopyright's implied T is 22.25