re: the plate delay was on the disc all along -- my instruction is refuted

The port caught this with arithmetic off the disc, and it was right: build 2 has
a keyframe group of its own, so "when build 4 has settled, wait 2.13 s, then
composite build 2" puts the plate at settle + 2.13 + 3.97 s. Confirmed build 2's
group here independently of their message: `ptbtn00.t32` reaches a=255 at t=238.

The reconciliation needs no free parameter. Both builds run on ONE clock, started
together, and the premise that fails is `rest.t`:

  rest.t is NOT when a screen settles. It is the last HOLD keyframe before the
  exit. ptlogo1 rests at t=251 and stops moving at t=42.

The title's visible build-in ends at t=118, where pteff01, pteff02.prm and
ptlogoall_eff end their ramps together. 238 - 118 = 120 units = 2.000 s, against
a measured 2.138 and 2.132. So the interval the two runs agreed on to 6 ms was a
DECLARED one and I handed over a wall-clock reading of it.

That reading is 6.7% long, and the corpus already knew why: 120 units in 2.135 s
is the game presenting at 28.06 / 28.14 fps against a nominal 30, and the idle
title was independently measured at 28.5 fps before these runs. Corroborated from
inside the same two runs -- first pixels -> settle is 1.643 s and 2.131 s, a 30%
spread, while settle -> plate is 2.138 and 2.132. Frames are dropped during the
build-in, not during the hold, which a change in the game's own timing could not
do.

So the port authors nothing here. What is unchanged: ScreenView still has to draw
two builds at once and the boot's end state is still not plate-free.

Not settled, and said so on the page: which reading of the keyframe times is
right (it moves the plate by 2 units and I cannot separate them from these
traces), and my settle landmark to better than +/-5 units.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
This commit is contained in:
sylph-decoder
2026-08-29 12:43:41 +00:00
parent c1f3608b07
commit 5b0a6e6666
4 changed files with 131 additions and 21 deletions

View File

@@ -618,6 +618,29 @@ neighbourhood, not just the line.
the `GP_STAGE_CLEAR` child the same scan named `8AX`. With the name decoded the
count is **10 148 of 10 148**. [`ratc-child-names.md`](structures/ratc-child-names.md)
## UI timing (2026-08-29)
* "a screen has SETTLED at its `rest.t`" → **refuted.** `rest.t` is the last
*hold* keyframe before the exit, not the end of motion. Build 4's `ptlogo1`
rests at `t=251` and stops moving at **`t=42`**; the title's visible build-in
ends at `t≈118`, where `pteff01`, `pteff02.prm` and `ptlogoall_eff` end their
ramps together. Believing `rest.t` put a port's plate 3.97 s late —
[`title-plate-delay-measured.md`](title-plate-delay-measured.md).
* "the `PRESS Ⓐ` plate is composited a measured 2.13 s after the title settles,
and the port should author that" → **the measurement stands, the instruction
was refuted by the port.** Build 2 has a keyframe group of its own; both builds
run on **one clock started together** and the plate's declared `t=238` supplies
the timing, so nothing is authored. `238 118 = 120 units = 2.000 s`, of which
2.13 s was a wall-clock reading stretched by Canary presenting at ~28.1 fps.
⚠️ General lesson: **a wall-clock duration off this emulator is ~6 % long**, so
a measured interval that lands near a round number of units probably *is* that
number of units.
* "a music bank has three sub-waves" → **refuted; it was our reader.** The third
is the bank header, emitted because `to_xma_riffs` derived a leading packet
stream's start as `first_riff % 2048` — valid only for a header shorter than
one packet. 28/28 disc-wide —
[`structures/slb-bank-header-not-a-wave.md`](structures/slb-bank-header-not-a-wave.md).
## The oracle harness and the container (2026-08-29)
* "the decoder container has no disc" → **refuted the same day.** The container