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.