re: the guest presents at 60 fps -- 120 units/s, and the port's plate IS ~2 s late

Answered against the pre-registration committed before the capture, with a
content hash added to the draw logger.

The buffer rotates three times faster than the content changes: 177
presents carry 3 base addresses but only 102 distinct content hashes, and
the modal run is exactly 2 presents per decoded frame. Consecutive presents
with changed content = 0.5739, inside the pre-registered R band of
0.40-0.60.

That is precisely the failure that invalidated my first answer this
morning. The base address changed every present, which I measured and read
as one decode per present. The content did not.

ADV.wmv is authored at 30.000 fps, so 2 presents per movie frame is 60
presents/s, and 2 units/present x 60 = 120 units/s.

Both controls pass, and they are the ones the withdrawn version lacked --
its two guards tested how I READ the buffer, neither tested whether a
buffer change meant a decode.

Control 1, a static texture must hash constant: the splash atlas changes
once, at an era boundary, and never within an era -- 1 change in 403
samples. Noting that I first wrote this control as "must be constant" and
it read FAIL; stated that way it was wrong, because a re-upload is real
content change and the control has to separate temporal from alternating.
A control that is too strong gets waved away, which is its own failure.

Control 2, the movie luma hash must not be constant: 102 distinct.

Consequence: the plate's t=236 is 1.97 s, not 3.93 s, and the port shows it
~1.96 s late. That is play-test finding 3, and "about two seconds" is the
size the human reported. Every declared duration in seconds across the
corpus is half what we have been quoting; unit counts are untouched.

The 2.13 s third route is explained by emulator speed, and that explanation
is labelled POST-HOC and is not offered as support -- fitting a speed
factor to close a gap is what this corpus keeps losing claims to.

Reach: one boot. This number has moved twice today and a second independent
boot should come before the port rewrites a timeline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/data/movie-decode-vs-rotate.txt

@@ -0,0 +1,20 @@
+# DECODE vs ROTATE -- does the guest decode a new movie frame every present?
+# Answered against movie-decode-vs-rotate-preregistration.md, committed first.
+
+movie luma draws: 177   frames 422..599
+presents carrying a movie luma draw: 177
+distinct BASES:   3  {'11890000': 59, '11700000': 59, '11570000': 59}
+distinct HASHES:  102
+
+CONTROL 2 -- the movie luma hash must NOT be constant: PASS
+
+consecutive presents with CHANGED luma content: 101/176 = 0.5739
+   pre-registered:  D decode-per-present  ~1.00 (accept >=0.90) ->  60 units/s
+                    R rotate-per-present  ~0.50 (accept 0.40-0.60) -> 120 units/s
+
+run lengths (consecutive presents showing the SAME content):
+   1 present(s):   29  #############################
+   2 present(s):   72  ##################################################
+   4 present(s):    1  #
+
+VERDICT: R -- rotate per present. Guest 60 fps. 120 UNITS/S.

docs/re/guest-frame-rate-resolved.md

@@ -0,0 +1,112 @@
+# ✅ The guest presents at **60 fps** — **120 units/s**, and that is the plate-late cause
+
+**Status: ✅ measured**, against
+[`movie-decode-vs-rotate-preregistration.md`](movie-decode-vs-rotate-preregistration.md),
+committed **before** the capture. Instrument: ⟨capture⟩ — the real game in Canary
+with a texture **content hash** added to the draw logger for this question.
+Data: [`data/movie-decode-vs-rotate.txt`](data/movie-decode-vs-rotate.txt).
+
+⚠️ **This is my third position on this number today.** The first (60 units/s) was
+withdrawn by me; this reverses it. What is different is not confidence — it is
+that the instrument now tests the thing that was assumed before, and the control
+that would expose the failure passed. Read the controls before the verdict.
+
+---
+
+## The result
+
+| | predicted | measured |
+|---|---|---|
+| **D** decode per present ⇒ 30 fps ⇒ 60 units/s | ≥ 0.90 | — |
+| **R** rotate per present ⇒ 60 fps ⇒ **120 units/s** | 0.40–0.60 | **0.5739** |
+
+```
+movie luma draws                    177   (presents 422..599)
+distinct BASES                        3   59 uses each  <- rotation
+distinct CONTENT HASHES             102   <- decodes
+consecutive presents, content changed  101/176 = 0.5739
+
+run lengths (presents showing the SAME content):
+   1 present :  29
+   2 presents:  72   <-- the mode
+   4 presents:   1
+```
+
+**The buffer rotates three times faster than the content changes.** 177 presents
+carry only 102 distinct frames, and the modal run is **exactly 2 presents per
+decoded frame**. That is `R`.
+
+📌 **And this is precisely the failure that invalidated my first answer.** The base
+address changed every present — which is what I measured and read as "one decode
+per present". The content did not. A base-keyed census cannot see the difference;
+a content hash can, and it says the guest presents **twice per decoded movie
+frame**.
+
+`ADV.wmv` is authored at 30.000 fps ⟨disc⟩, so 2 presents per movie frame is
+**60 presents per second ⇒ 2 units/present × 60 = 120 units/s.**
+
+## The controls, both of which had to pass
+
+**Control 1 — a static texture must hash constant.** The splash sprite atlas
+(1280×768) is uploaded once per splash and sampled throughout. If its hash moved
+between presents, the hash would be racing the writer and nothing else could be
+read.
+
+```
+h=54D8DB4A2249A978  frames   1..219   n=218
+h=478C1E9F56EE5485  frames 224..409   n=186
+hash changes between consecutive samples: 1 of 403   ranges disjoint: True
+```
+
+**PASS**, and in the informative way: it changes **once**, at an era boundary —
+a genuine re-upload between the two splashes — and never within an era. ⚠️ I first
+wrote this control as *"must be constant"* and it read as FAIL. Stated that way it
+was wrong: a re-upload is real content change and the control has to distinguish
+*temporal* change from *alternating* change. Recorded because a control that is
+too strong gets waved away, which is its own failure mode.
+
+**Control 2 — the movie luma hash must NOT be constant**, or I am hashing the
+wrong bytes and would manufacture `R`. **PASS**: 102 distinct hashes.
+
+**These are the controls the withdrawn version lacked.** Both of its guards tested
+how I *read* the buffer; neither tested whether a buffer change meant a decode.
+
+## 🔴 What this means for the play-test
+
+> **The plate's `t = 236` is 1.97 s, not 3.93 s. The port shows it ~1.96 s late.**
+
+That is finding 3, and *"about two seconds"* is the size a human reported. Two of
+the play-test's four named candidates were eliminated earlier (the ramp is drawn;
+the onset is a completion) — **the survivor is the unit→seconds constant**, which
+is where the play-test put it first.
+
+Everything downstream of `units/s` moves with it: every declared duration on every
+screen is **half** what the corpus has been quoting in seconds. Unit *counts* are
+untouched, and so is `2 units per present`.
+
+## Reconciling the third route — and this part is POST-HOC, labelled as such
+
+`title-plate-delay-measured.md` measured 120 declared units at **2.13 s**, twice,
+agreeing to 6 ms ⇒ ~56 units/s. At 120 units/s that interval is **1.00 s** true,
+so that run's emulator was at ~47 % speed. Plausible — its own harness documents
+`screenshot` costing **10.8 s while xenia is running** — and this capture
+independently measured only **44.5 presents per host-second** against a 60 fps
+guest, i.e. 74 % speed with a far lighter harness.
+
+⚠️ **But I fitted a speed factor to close a gap, which is what this corpus keeps
+losing claims to.** It is an *explanation*, not evidence, and it is not offered as
+support for 120. The support for 120 is the hash ratio and its two controls.
+
+## Reach, and what is still not settled
+
+⟨capture⟩, **one boot**, one movie region, this emulator. The ratio is inside its
+band and both controls pass, but this number has now moved twice and **a second
+independent boot is the obvious next step before the port rewrites a timeline.**
+
+* ❔ **Whether Canary's cadence equals a real console's.** The vblank interval
+  (one vblank 71.7 %, two 24.6 %) is consistent with a 60 fps guest, but it is
+  host time. A 360 vblanks at 60 Hz and the game presents every vblank here;
+  that it would do the same on hardware is an inference.
+* ❔ **The clock origin** — untouched, and still the other half of finding 3. A
+  common offset survives everything measured here, because every quantity above
+  is a ratio or a count.