re: the boot splash black gap is ~9 units, measured in draws not luminance

The port found its boot had no black frame between the publisher and developer
splashes and authored 12 units by analogy with the menus' transition quad. On
the boot path that analogy has nothing behind it -- palogo_eff0.prm is a single
static keyframe, so the splash bundles declare no fade quad.

I had agreed with the dismissal that hid the defect: told the residual was
0.03 s against a bound built from two measured ranges plus jitter slack, I said
it said more about the bound than the game. The real gap was 0.2 s.

Measured in the draw stream, which separates true black from a fade tail where
luminance cannot: palogo_sqex is drawn to frame 125 at alpha 7, frames 126-129
submit NO sprite quad at all, and the developer fades in at frame 130 from
alpha 34. Four presented frames, the only such run in the sequence.

Converted with the disc as its own clock rather than a frame rate -- this run
presented at 13.1 fps against 28 elsewhere -- palogo_sqex declares alpha >= 1
for 239.8 units and is drawn in 105 frames, giving 2.284 units per presented
frame, which the title capture independently corroborates at 2.231. So the gap
is ~9.1 units (0.152 s), against the 12 authored; +-1 frame is 6.9-11.4. And
the true black is SHORTER, since both boundary frames still carry picture.

Second finding: the developer splash is ONE composited 525x259 quad at the
bounding box of its three declared logos, none of whose individual sizes is
ever submitted. That is why an earlier pass reported "developer splash: 0
frames".

Declaration sites ruled out: the splash bundles (no fade quad) and the
top-level +0x08 (a family constant, 300/60, slack 12-226 units). The
executable is NOT looked at and is named as the next place rather than
claimed.

Also answers the port's sweep question: +0x08 canNOT settle it, because
ptloop01/ptloop02 have zero slack and a zero-slack record cannot distinguish
"loops" from "runs once and stops". The oracle settles it for the TITLE -- the
sweep oscillates over its whole range and resets hard to the same start, once
in dwell 1 and twice in dwell 2, so it does not park. The MENU is unmeasured
and stays open.

Tooling: GRACE and NOTAP knobs for ui_draw_capture.sh. The script taps A on
"the screen changed a lot", which is also true of a fading splash -- a first
run tapped through the publisher and the developer never appeared. The
instrument was perturbing what it measured.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/re/INDEX.md

@@ -172,3 +172,4 @@ files, which is how the same ground got covered twice.
 | [`structures/ui-record-loop-length.md`](structures/ui-record-loop-length.md) | Where a looping record's cycle restarts — and the `PRESS Ⓐ` plate's real period | ✅ **decoded**: a nested record is itself a RATC bundle and its header **`+0x08` is the loop length**; its keyframes need not fill it, and the slack is a hold at the final pose. Disc-wide over **1 781** timed nested records: 92.3 % declare exactly their last keyframe time, **7.7 % declare more**, and **0 declare less** — the falsifier (a cycle cannot restart before its own last pose) never fires. 🔴 **The plate's `ptbtn00f` is 105 units of ramp inside a 120-unit cycle, so it holds dark for 15 units** — the port was shipping **105**, and the answer is **120**. ✅ Falsification test against the running game, using a pacing factor measured *independently* on the focus ring (declared 120 → **2.177 s**, factor **1.0885**): to reach the corpus's measured 2.12–2.34 s, 105 units needs a factor of **1.211–1.337** (🔴 excludes the ring's) while 120 needs **1.060–1.170** (✅ contains it). Different elements, different bundles, separate runs — tied only by both declaring 120. ⚠️ Says where a cycle *ends*, not which records cycle. ❔ the **top-level** `+0x08` (300 on every `GP_TITLE` entry, elements ending at 244–269) is a different question, untouched |
 | [`structures/ui-focus-record-pulse-census.md`](structures/ui-focus-record-pulse-census.md) | Every focus record whose glow pulses, and where `rest()` puts it | ✅ **decoded**, disc-wide: **1 130** focus records, **2 664** timed elements, **210 with a varying alpha** — of which **202** have `rest()` == the **peak** (burns bright forever) and **8** land **mid-ramp**. By pak: `PILOTLOG` 116, `MOVIE_THEATER` 54, `HANGAR_ARSENAL` 30, `LEADERBOARD` 8, **`GP_TITLE` 2**. 🟡 Bounds rather than refutes the port's "34 in the export, 2 varying, nothing to fix" — correct, and correct *because* `GP_TITLE` has 2; the pathology sits in the screens a wider port needs next. 🔴 The 8 mid-ramp ones are the worse mode: `py_ranking_btn01f` swings 255→127→255 and `rest()` returns **244**, neither extreme, which looks entirely plausible and nothing reports it. ✅ Control: `ptbtn01f` is genuinely constant (255 throughout) and is **not** flagged; two hits verified keyframe by keyframe. ⚠️ A pulsing element has no resting pose — the question is malformed, not mis-answered; `pose_at(t)` inside the record's declared cycle ([`ui-record-loop-length.md`](structures/ui-record-loop-length.md)) is the only well-formed query. ⚠️ 210 is a **floor**: focus records are matched by the `Xf.rat` name rule, and varying scale/rotation/position is not counted |
 | [`structures/ui-title-buildin-measured.md`](structures/ui-title-buildin-measured.md) | The title's build-in and the plate glow, read out of the guest's own draw stream | ✅ **measured** (Canary, `ARM=early` draw capture): the decoded *mechanism* is observed, not just its end state. **The five flashes fire in a six-frame window and are absent from all 155 other sampled frames**; `ptlogo_back2eff1` is drawn in exactly 2 frames at **t = 54.0** against a decoded peak of **t54–56**, and `ptlogo1` first appears at **t = 42.2** against a decoded **t42** — with units/frame taken from the **glow's period alone**, a different element. The two holders (`ptlogo_back2eff`, `ptlogo_back2`) are continuous from frame 134. ✅ The glow's per-vertex colour alpha IS its fade alpha: **observed range 0…80 against a decoded peak of 80**, exact and unfitted; **period 51.158 presented frames** over 20 cycle starts; fitting the decoded ramp gives RMS **13.16** against **38.18 reversed** (2.9×), so the asymmetry is real and correctly directed. Structure: the settled title is 10–11 draws naming no sprite — which is why arming at the title sees nothing. ⚠️ Frame **107** is a 27-draw spike between the movie's last frame and the title's first; calling it "the composite" was an **over-read** — it binds **no texture** and only 4 of its 27 draws log geometry. The second title entry has no such frame. ⚠️ The two entries are the same animation at **different sampling phases** (only 4 of 46 aligned frames match), which is what makes the `eff3` result robust. 🔴 **The game does not draw `ptlogo_back2eff3` at all** — reproduced over **two** title entries 5 800 frames apart, and three alternative explanations tested and failed: *phase* (its window is **6 units** against a **2.23-unit** step, so it cannot be missed — frames 133/134 sit at t=60.1/62.3 inside it and draw `eff2` and `eff4` instead), *an unlogged draw* (exactly 2 blind draws/frame, always the same full-screen-triangle shader, present when no wipe is active), and *a bad position guess* (dropping position entirely, **zero** quads anywhere have a width within ±30 of 408; the spectrum jumps 262 → 748). Draw counts across both entries: eff1 **4**, eff2 **3**, eff3 **0**, eff4 **6**. 🔴 **The port draws `eff3` at t=60–62 and the console does not.** ❔ Why is not established — nothing in its element record differs from its neighbours. ⚠️ An earlier "sub-frame phase" explanation and the advice that drawing all five "shows more sweep than the console" are both **withdrawn**. ⚠️ What a frame-by-frame build-in comparison *will* show is disagreement about which flash lands in which frame — 2 units/submitted frame against this run's 2.231 units/presented frame — and neither side is wrong. 🔴 **Trap:** matching a bound texture's dimensions to a sprite fails both ways — it missed every flash *and* read the intro movie's 640×360 YUV planes as `ptbase2`. ✅ A regression of five events' observed frames against their declared times (residuals ≤0.9 frames) recovers the intercept at frame **106.1** when the composite spike, not in the fit, is frame **107**. ⚠️ Per-vertex alpha = fade alpha holds for the **glow** and does not generalise — `eff4` reads 255/127/254 on consecutive frames. ❔ Frame rate not recorded, so nothing is in seconds; the glow's period implies a **114**-unit cycle against a declared 120, unexplained; `eff5` vs `ptlogo_back2eff` not separated |
+| [`structures/boot-splash-gap-measured.md`](structures/boot-splash-gap-measured.md) | The black gap between the two boot splashes | ✅ **measured** in the guest's **draw stream**, which separates true black from a fade tail where luminance cannot: the publisher's last sprite is frame 125 (alpha 7), then **frames 126–129 submit NO sprite quad at all**, then the developer fades in at alpha 34. **The gap is 4 presented frames.** Converted with the disc as its own clock — `palogo_sqex` declares alpha≥1 for **239.8 units** and is drawn in **105** frames → **2.284 units/frame** (the title capture independently gave 2.231) — that is **~9.1 units ≈ 0.152 s**, against the **12** the port authored; ⚠️ and the true black is *shorter*, since both boundary frames still carry picture. ✅ Second finding: the **developer splash is ONE composited 525×259 quad** at the bounding box of its three declared logos, none of whose individual sizes is ever submitted. ❌ Not declared on the disc: `palogo_eff0.prm` is a single static keyframe, and the top-level `+0x08` is a **family constant** (300 / 60) whose slack ranges 12–226 units. ❔ The executable is **not** looked at — named, not claimed. 🔴 The instrument was perturbing the measurement: the capture script taps Ⓐ on "screen changed a lot", which is also true of a fading splash — it tapped through the publisher and the developer never appeared. `GRACE=1` and `NOTAP=1` knobs added |

docs/re/data/boot-splash-gap-draws.csv

@@ -0,0 +1,234 @@
+# Every sprite quad submitted during the boot splashes, from the guest's
+# own draw stream. Capture: ui_draw_capture.sh GRACE=1 NOTAP=1 ARM=early,
+# 2026-08-29. Full-screen quads (w>=1250) are omitted.
+# frames 126..129 carry NO sprite quad at all -- that is the black gap.
+frame,x,y,w,h,vertex_alpha
+2,301,317,685,90,119
+3,301,317,685,90,153
+4,301,317,685,90,187
+6,301,317,685,90,246
+7,301,317,685,90,240
+9,301,317,685,90,229
+10,301,317,685,90,223
+11,301,317,685,90,220
+12,301,317,685,90,214
+13,301,317,685,90,211
+14,301,317,685,90,183
+15,301,317,685,90,155
+16,301,317,685,90,127
+17,301,317,685,90,98
+18,301,317,685,90,70
+19,301,317,685,90,56
+20,301,317,685,90,28
+21,307,331,666,65,255
+22,307,331,666,65,255
+23,307,331,666,65,255
+24,307,331,666,65,255
+25,307,331,666,65,255
+26,307,331,666,65,255
+27,307,331,666,65,255
+28,307,331,666,65,255
+29,307,331,666,65,255
+30,307,331,666,65,255
+31,307,331,666,65,255
+32,307,331,666,65,255
+34,307,331,666,65,255
+35,307,331,666,65,255
+37,307,331,666,65,255
+38,307,331,666,65,255
+39,307,331,666,65,255
+40,307,331,666,65,255
+41,307,331,666,65,255
+42,307,331,666,65,255
+43,307,331,666,65,255
+44,307,331,666,65,255
+45,307,331,666,65,255
+46,307,331,666,65,255
+47,307,331,666,65,255
+48,307,331,666,65,255
+49,307,331,666,65,255
+50,307,331,666,65,255
+51,307,331,666,65,255
+52,307,331,666,65,255
+53,307,331,666,65,255
+54,307,331,666,65,255
+55,307,331,666,65,255
+56,307,331,666,65,255
+57,307,331,666,65,255
+58,307,331,666,65,255
+59,307,331,666,65,255
+60,307,331,666,65,255
+61,307,331,666,65,255
+62,307,331,666,65,255
+63,307,331,666,65,255
+64,307,331,666,65,255
+65,307,331,666,65,255
+66,307,331,666,65,255
+67,307,331,666,65,255
+68,307,331,666,65,255
+69,307,331,666,65,255
+70,307,331,666,65,255
+71,307,331,666,65,255
+72,307,331,666,65,255
+73,307,331,666,65,255
+74,307,331,666,65,255
+75,307,331,666,65,255
+76,307,331,666,65,255
+77,307,331,666,65,255
+78,307,331,666,65,255
+79,307,331,666,65,255
+80,307,331,666,65,255
+81,307,331,666,65,255
+82,307,331,666,65,255
+83,307,331,666,65,255
+84,307,331,666,65,255
+85,307,331,666,65,255
+86,307,331,666,65,255
+87,307,331,666,65,255
+88,307,331,666,65,255
+89,307,331,666,65,255
+90,307,331,666,65,255
+91,307,331,666,65,255
+92,307,331,666,65,255
+93,307,331,666,65,255
+94,307,331,666,65,255
+95,307,331,666,65,255
+96,307,331,666,65,255
+97,307,331,666,65,255
+98,307,331,666,65,255
+99,307,331,666,65,255
+100,307,331,666,65,255
+102,307,331,666,65,255
+103,307,331,666,65,255
+105,307,331,666,65,255
+106,307,331,666,65,255
+107,307,331,666,65,255
+108,307,331,666,65,255
+109,307,331,666,65,255
+110,307,331,666,65,255
+111,307,331,666,65,255
+112,307,331,666,65,255
+113,307,331,666,65,249
+114,307,331,666,65,243
+115,307,331,666,65,231
+116,307,331,666,65,198
+117,307,331,666,65,181
+118,307,331,666,65,165
+119,307,331,666,65,148
+120,307,331,666,65,115
+121,307,331,666,65,81
+122,307,331,666,65,65
+123,307,331,666,65,31
+124,307,331,666,65,15
+125,307,331,666,65,7
+130,378,155,525,259,34
+131,378,155,525,259,51
+132,378,155,525,259,85
+133,378,155,525,259,119
+134,378,155,525,259,136
+135,378,155,525,259,153
+136,378,155,525,259,170
+137,378,155,525,259,221
+138,378,155,525,259,255
+139,378,155,525,259,255
+140,378,155,525,259,255
+141,378,155,525,259,255
+142,378,155,525,259,255
+143,378,155,525,259,255
+144,378,155,525,259,255
+145,378,155,525,259,255
+146,378,155,525,259,254
+147,378,155,525,259,220
+148,378,155,525,259,186
+149,378,155,525,259,152
+151,378,155,525,259,84
+152,378,155,525,259,50
+153,378,155,525,259,33
+154,390,162,499,241,255
+155,390,162,499,241,255
+156,390,162,499,241,255
+157,390,162,499,241,255
+158,390,162,499,241,255
+159,390,162,499,241,255
+160,390,162,499,241,255
+161,390,162,499,241,255
+162,390,162,499,241,255
+163,390,162,499,241,255
+164,390,162,499,241,255
+165,390,162,499,241,255
+166,390,162,499,241,255
+167,390,162,499,241,255
+168,390,162,499,241,255
+169,390,162,499,241,255
+170,390,162,499,241,255
+171,390,162,499,241,255
+172,390,162,499,241,255
+173,390,162,499,241,255
+174,390,162,499,241,255
+176,390,162,499,241,255
+177,390,162,499,241,255
+179,390,162,499,241,255
+180,390,162,499,241,255
+181,390,162,499,241,255
+183,390,162,499,241,255
+184,390,162,499,241,255
+185,390,162,499,241,255
+186,390,162,499,241,255
+187,390,162,499,241,255
+188,390,162,499,241,255
+189,390,162,499,241,255
+190,390,162,499,241,255
+191,390,162,499,241,255
+192,390,162,499,241,255
+193,390,162,499,241,255
+194,390,162,499,241,255
+195,390,162,499,241,255
+196,390,162,499,241,255
+197,390,162,499,241,255
+198,390,162,499,241,255
+199,390,162,499,241,255
+200,390,162,499,241,255
+201,390,162,499,241,255
+202,390,162,499,241,255
+203,390,162,499,241,255
+204,390,162,499,241,255
+205,390,162,499,241,255
+206,390,162,499,241,255
+207,390,162,499,241,255
+208,390,162,499,241,255
+209,390,162,499,241,255
+210,390,162,499,241,255
+211,390,162,499,241,255
+212,390,162,499,241,255
+213,390,162,499,241,255
+214,390,162,499,241,255
+215,390,162,499,241,255
+216,390,162,499,241,255
+217,390,162,499,241,255
+218,390,162,499,241,255
+219,390,162,499,241,255
+221,390,162,499,241,255
+223,390,162,499,241,255
+224,390,162,499,241,255
+225,390,162,499,241,255
+226,390,162,499,241,255
+227,390,162,499,241,255
+228,390,162,499,241,255
+229,390,162,499,241,255
+230,390,162,499,241,255
+231,390,162,499,241,255
+232,390,162,499,241,255
+233,390,162,499,241,255
+234,390,162,499,241,255
+235,390,162,499,241,255
+236,390,162,499,241,254
+237,390,162,499,241,243
+238,390,162,499,241,231
+239,390,162,499,241,198
+240,390,162,499,241,165
+241,390,162,499,241,131
+242,390,162,499,241,115
+243,390,162,499,241,81
+244,390,162,499,241,48
+245,390,162,499,241,23
+246,390,162,499,241,7

docs/re/structures/boot-splash-gap-measured.md

@@ -0,0 +1,110 @@
+# The black gap between the boot splashes — measured in draws, not luminance
+
+**Classification: measured.** Xenia Canary, `ui_draw_capture.sh GRACE=1 NOTAP=1
+ARM=early`, 2026-08-29. Evidence:
+[`boot-splash-gap-draws.csv`](../data/boot-splash-gap-draws.csv).
+
+## Why this was open
+
+The port found that its boot had **no black frame at all** between the publisher
+and developer splashes, and authored **12 units** (0.200 s) by analogy with the
+menus' transition quad. On the boot path that analogy has nothing behind it:
+`palogo_eff0.prm` is a **single static keyframe**, so the splash bundles declare
+no fade quad at all.
+
+🔴 **And I had agreed with the dismissal that hid it.** Told that the residual was
+0.03 s against a bound built from two measured ranges plus jitter slack, I said it
+said more about the bound than the game. It did not — the underlying gap was 0.2 s
+and the port had been missing it since P3. A plausible explanation for a small
+number is exactly how a real defect stays hidden.
+
+## The measurement
+
+Luminance cannot separate the outgoing screen's fade tail from true black. The
+**draw stream** can: it says exactly which frames submit a sprite quad at all.
+
+| frames | what is submitted |
+|---|---|
+| 2 – 20 | `palogo_sqex_eff` (685×90) — the publisher's glow |
+| 21 – 125 | `palogo_sqex` (666×65) — the publisher wordmark, fading to alpha **7** |
+| **126 – 129** | 🔴 **nothing — 4 frames with no sprite quad at all** |
+| 130 – 153 | the developer splash, fading in from alpha **34** |
+
+**The gap is 4 presented frames**, and it is the only such run anywhere between
+the first and last sprite of the sequence.
+
+## Converting it without a frame rate
+
+The run's presented rate is not usable — measured at **13.1 fps** while the title
+was up, against the corpus's 28 fps for other runs, and it is not stable enough to
+convert a 4-frame interval.
+
+So the **disc's own timeline is the clock**. `palogo_sqex` declares alpha ≥ 1 from
+t ≈ 15.06 to t ≈ 254.9 — **239.8 units** — and is drawn in **105 frames**:
+
+> **2.284 units per presented frame**, from the same screen in the same capture.
+> (The title capture, independently, gave 2.231.)
+
+| | units | seconds at 60 units/s |
+|---|---|---|
+| if the gap were 3 frames | 6.9 | 0.114 |
+| **measured — 4 frames** | **9.1** | **0.152** |
+| if the gap were 5 frames | 11.4 | 0.190 |
+| *the port's authored value* | *12* | *0.200* |
+
+**The measured gap is ~9 units, and 12 is at or just past the top of the
+quantisation range.** ⚠️ And the true black is *shorter* than this, not longer:
+the last publisher frame still carries alpha 7 and the first developer frame
+alpha 34, so both boundary frames contain some picture that this count treats as
+black.
+
+## ✅ A second thing the draw stream shows: the developer splash is ONE quad
+
+The developer bundle declares three logos — `palogo_gamearts` at (390,164),
+`palogo_seta` at (521,316), `palogo_anima` — and **none of their sizes is ever
+submitted**. What is submitted is a single **525×259 quad at (378,155)**, which is
+the bounding box of the three. The game composites them and blits the group.
+
+This is why an earlier pass reported "developer splash: 0 frames" — it was
+matching individual logo sizes that the game never draws.
+
+## Is the gap declared anywhere? Not that I can find
+
+* ❌ **In the splash bundles.** `palogo_eff0.prm` is one static keyframe
+  (`t0 a255`). No fade quad, no gap.
+* ❌ **In the top-level header `+0x08`.** It is a **family constant** — 300 for
+  every title/splash entry in `GP_TITLE`, 60 for the loading bundles — and the
+  slack against each bundle's last keyframe ranges from **12 to 226 units**
+  (the main menu's is 220, i.e. 3.7 s). It cannot be a declared gap.
+* ❔ **In the executable — not looked at.** The corpus has the boot phase machine
+  at `this+132`; whether a dwell or gap constant sits near it is untested. That is
+  the next place, and I am naming it rather than claiming reach I do not have.
+
+So the port is right to author this, and should author **~9 units** rather than 12.
+
+## Reach
+
+⚠️ **One boot, one machine.** The 4-frame count is quantised and the ±1 frame is
+the dominant uncertainty (6.9 – 11.4 units).
+
+⚠️ The units-per-frame calibration assumes the guest's animation clock advances
+uniformly across the gap, which is the same assumption the rest of this corpus's
+frame→unit conversions make.
+
+## 🔴 The instrument was perturbing what it measured
+
+`ui_draw_capture.sh` taps Ⓐ whenever the screen changes a lot, to skip the attract
+movie. **That trigger is also true while a boot splash is fading.** A first run
+classified the publisher splash as a movie at t = 3 s, tapped through it, and the
+developer splash never appeared. Two knobs now exist and a boot run needs both:
+
+* `GRACE=1` — the fixed 8 s wait before arming meant an `ARM=early` capture always
+  missed both splashes, which run at ~1.2 – 9.5 s of guest time;
+* `NOTAP=1` — no input at all.
+
+## Reproducing
+
+```bash
+GRACE=1 NOTAP=1 FRAMES=9000 MAXDRAWS=5000000 ARM=early \
+  tools/re-capture/ui_draw_capture.sh 300 /tmp/uicap-boot
+```

docs/re/structures/ui-record-loop-length.md

@@ -121,6 +121,35 @@ visible in the draw stream as the frames where the game submits no draw at all.
   hold; it is what a four-sample wall-clock measurement of a ~2 s period in this
   emulator looks like.
 
+## ❔ What this field does NOT settle: do the `ptloop` sweeps loop?
+
+Asked by the port, hoping `+0x08` would decide it. **It does not.**
+
+`ptloop01.rat` declares `+0x08` = **600** with keyframes reaching exactly t=600;
+`ptloop02.rat` declares **720**, keyframes to t=720. **Slack zero** — and a
+zero-slack record is precisely the case this field cannot discriminate: "loops at
+600" and "runs once for 600 and stops" produce the identical header. 92.3 % of
+records on the disc are in that state.
+
+✅ **The oracle answers it for the title, and the answer is that they keep
+moving.** Tracking the sweep quad across two title dwells in a draw capture:
+
+| | sweep draws | x range (NDC) | backward jumps to the start |
+|---|---|---|---|
+| title dwell 1 (frames 138–1220) | 1008 | −3.02 … −0.33 | **1** (frame 1161) |
+| title dwell 2 (frames 5963–7025) | 908 | −3.02 … +0.42 | **2** (frames 6370, 6822) |
+
+The x position oscillates across the whole range for the entire dwell and resets
+hard to the same start value (−2.38). A run-once-and-park would show one traverse
+and then a constant x. **It does not park.**
+
+⚠️ **This is the TITLE, and the port asked about the MAIN MENU.** Both declare
+`ptloop01`/`ptloop02` with the same 600/720, but I have not captured the menu, and
+the port's own evidence — an idle menu capture matching best with the sweeps
+off-screen — points the other way. Either the menu's sweeps behave differently, or
+"best match" is doing badly at detecting an absence, which the port said itself.
+**Unresolved for the menu; measured for the title.**
+
 ## Reach
 
 ⚠️ **This says where a cycle ends, not that every record cycles.** 92.3 % of