Sylpheed/docs/re/clock-origin-blocked-boot-has-no-title.md

❔ The clock origin is not measurable from a boot capture — the title is not in one

Status: ❔ blocked, with the reach stated. 2026-09-01. Instrument: ⟨capture⟩ ×3. Recorded rather than worked around, per "do not improvise around a blocker".

---

What I set out to do

The clock origin is the last surviving candidate for play-test finding 3. Every quantity in today's account is a ratio or a count, and a common offset survives all of them — if the port's clock starts at a different moment from the game's, every interval matches and the screen still arrives late.

Now that the clock is known to advance 1 unit per present, the origin is directly measurable as a count: observe the plate at a known declared alpha (the 214 → 236 ramp gives t to within one unit), count presents back to the first present on which the title draws anything, and the difference is the title's clock value at its own first draw. Zero means the clock starts when the screen does; anything else is the offset a port must author.

No capture I have contains the plate, or the title at all.

What the boot actually does, measured three times

capture	publisher splash	developer splash	first movie frame
boot 1	presents 1…219 (219)	224…409 (186)	422
boot 2	1…228 (228)	234…418 (185)	429
--framerate_limit=30	1…244 (244)	250…453 (204)	463

Two splashes, then the attract movie. There is no title segment. The two UI-drawing segments are the publisher and developer splashes — identified by their quad rects and by dwells matching boot-order-and-splash-dwell.md — and the next thing to draw is the movie's luma plane.

📌 This is not a new failure; it re-frames an old one as expected. The corpus records "three runs, two locales, two launch paths, ~35 minutes of emulator time, no interactive title", and treats it as an unexplained blocker. The reason is plainer than it looked: MISSION.md's own boot order is splash → intro video → title, ADV.wmv is 137.7 s ⟨disc⟩, and a 600-present capture at ~50 presents/s is ~12 s. The title is on the far side of a two-minute movie. A capture that never reaches it is behaving correctly.

⚠️ These runs use NOTAP=1, which is what the splash work needed and is exactly what prevents skipping the movie.

What would settle it, and neither is free

1. Tap Ⓐ to skip the movie, then capture the title. ui_draw_capture.sh already taps while a movie plays when NOTAP is unset. The risk is documented in that script's own header: a stray Ⓐ on the title sends the guest into the save-data probe, which crashed it on 2026-08-18.
2. Capture through the whole movie — ~137 s at ~50 presents/s is ~6 900 presents, against the 600 these runs used. FRAMES and MAXDRAWS both scale; the log would be ~15 MB, which is fine.

Option 2 needs no pad input and cannot crash the guest, so it is the one to run. I did not run it: it is a single capture but a long one, and I would rather pre-register the origin prediction first than start a 3-minute capture at the end of an iteration.

The prediction, so the next run is not exploratory

Under 1 unit per present, if the title's clock starts on its first drawn present, then the plate's a = 17 (first ramp step, t = 215) must land 215 presents after the title's first draw, and a = 255 at 236. Any consistent shortfall is the origin offset, in units, directly.

⚠️ And there is a second reading to keep open: the corpus's two 2026-08-29 runs measured settle → plate at 2.13 s with the title persisting long enough to show it, which these untapped runs do not. Whether the boot title and the post-movie title are the same screen with the same clock is not established, and the origin may differ between them.

Reach

⟨capture⟩ ×3, one machine, English locale, NOTAP=1, 600 presents. The negative is specific: within the first ~460 presents of boot, the title does not draw. It says nothing about what happens after the attract movie, which is precisely where the answer is.