From 5d72bda77dc4f3e145911999a1595dc22f14b1c2 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 19:37:41 +0000 Subject: [PATCH] re: PRE-REGISTER the forced-frame-rate test of the time-based clock The time-based-clock claim rests on two captures that happened to run at different speeds. Nobody has changed the frame rate on purpose and watched. --framerate_limit=30 halves Xenia's vblank ceiling. Predictions committed before the run: quantity frame-based time-based (my claim) presents/s ~27 ~27 modal alpha step 17, unchanged 34, DOUBLED units/s ~30, halved ~60, unchanged splash dwells ~8.5 / ~7.0 s ~4.2 / ~3.5 s, unchanged Accept time-based only if the step lands in 30-38 AND the dwell stays within 10% of 4.2/3.5 s. If the step stays 17 and the dwell doubles, the claim is refuted, the clock is frame-based, and the port's 60 is unsupported again. The control is the present rate itself, read FIRST: a doubled step also appears if the limiter did nothing, so if presents/s does not fall to ~27 neither prediction is tested. Second control: the eight splash quad rects must be unchanged, or something other than the frame rate differs between runs. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/time-based-clock-preregistration.md | 66 +++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 docs/re/time-based-clock-preregistration.md diff --git a/docs/re/time-based-clock-preregistration.md b/docs/re/time-based-clock-preregistration.md new file mode 100644 index 00000000..787f16fe --- /dev/null +++ b/docs/re/time-based-clock-preregistration.md @@ -0,0 +1,66 @@ +# Pre-registration — force the frame rate, and see which quantity moves + +**Committed BEFORE the capture.** 2026-09-01. The designed falsification of +[`units-per-frame-is-not-a-constant.md`](units-per-frame-is-not-a-constant.md), +which currently rests on two captures that happened to run at different speeds +rather than on one made to. + +--- + +## The claim under test + +> The UI clock advances by **elapsed time**, not by frame count. `units/present` +> is an artefact of the presentation rate; **`units/second ≈ 60` is the +> invariant.** + +Evidence so far, all opportunistic: + +| capture | presents/s | modal Δα | ⇒ units/present | ⇒ units/s | +|---|---|---|---|---| +| `h3` | 27.2 | **34** | 2.0 | 54.4 | +| boot 1 | 51.4 | **17** | 1.0 | 51.4 | +| boot 2 | 54.8 | **17** | 1.0 | 61.3 / 60.3 (from dwell) | + +Two of the three ran at nearly the same rate. **Nobody has yet changed the frame +rate on purpose and watched.** + +## The experiment + +`--framerate_limit=30`. Xenia's limiter (`graphics_system.cc`) then marks vblank +at 30 Hz instead of 60, halving the ceiling on presents. + +## 🔴 The predictions, stated now + +| quantity | frame-based clock | **time-based clock (my claim)** | +|---|---|---| +| presents/s | ~27 | ~27 | +| **modal Δα per present** | **17, unchanged** | **34, doubled** | +| **units/s** | **~30, halved** | **~60, unchanged** | +| publisher splash dwell | ~8.5 s, doubled | **~4.2 s, unchanged** | +| developer splash dwell | ~7.0 s | **~3.5 s, unchanged** | + +**These diverge on every row but the first.** I accept the time-based reading only +if the modal step lands in **30–38** *and* the dwell stays within 10 % of 4.2 / +3.5 s. If the step stays at 17 and the dwell doubles, **my claim is refuted and +`units/s` is 30 at this limit**, which would mean the clock is frame-based after +all and the whole rate question reopens with the port's 60 unsupported again. + +⚠️ Note which way the risk runs: a doubled step is the result that *confirms* me, +and it is also what a frame-based clock would show if the limiter did not actually +take effect. **So the control is the present rate itself** — if presents/s does +not fall to ~27, the flag did nothing and neither prediction is tested. That is +the first number I will read, before the step. + +## Second control + +The splash **quad geometry** must be unchanged — same eight NDC rects. If the +rects move, something other than the frame rate changed between runs and the +comparison is not clean. + +## What this cannot settle + +Whether the console's rate is 60. Everything here is measured under Canary's +limiter; the claim being tested is only that the clock is *time*-driven and that +its rate is ~60 units/s **as this emulator runs it**. A time-based clock is +immune to dropped frames, which is why that is worth something — but it is not +the console.