re: the clock origin is blocked -- a 600-present boot capture has no title in it
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:
81
docs/re/clock-origin-blocked-boot-has-no-title.md
Normal file
81
docs/re/clock-origin-blocked-boot-has-no-title.md
Normal 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.
|
||||
Reference in New Issue
Block a user