fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the clock origin is blocked -- a 600-present boot capture has no title in it

Browse Source 
The clock origin is the last surviving candidate for finding 3, and now
that the clock is known to advance 1 unit per present it is directly
measurable as a count: observe the plate at a known declared alpha, count
presents back to the title's first draw, and the difference is the title's
clock value at its own first draw.

No capture I have contains the title. Three captures agree on what the boot
does: publisher splash (219/228/244 presents), developer splash
(186/185/204), then the attract movie at 422/429/463. Two splashes, then
the movie. There is no title segment.

This re-frames an old blocker as expected rather than mysterious. The
corpus records "three runs, two locales, two launch paths, ~35 minutes of
emulator time, no interactive title" as unexplained. MISSION's own boot
order is splash -> intro video -> title, ADV.wmv is 137.7 s from the disc,
and 600 presents at ~50/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.

Two ways to settle it. Tapping A skips the movie but risks the save-data
probe that crashed the guest on 2026-08-18, per the capture script's own
header. Capturing through the whole movie needs ~6900 presents against the
600 used here, needs no pad input and cannot crash the guest, so that is
the one to run.

Not run this iteration, deliberately: I would rather pre-register the
origin prediction than start a long capture at the end of an iteration. The
prediction is stated on the page so the next run is not exploratory -- the
plate's a=17 must land 215 presents after the title's first draw if the
clock starts there, and any shortfall is the offset in units.

Reach: the negative is specific. Within the first ~460 presents of boot the
title does not draw. It says nothing about after the attract movie, which
is where the answer is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-01 19:44:33 +00:00
parent e0e4998aea
commit 696ed29664
1 changed files with 81 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
docs/re/clock-origin-blocked-boot-has-no-title.md Normal file
View File

@@ -0,0 +1,81 @@
# ❔ 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.