Put the frame clock on the 68000, and find that the 12 fps frame does not exist

ROADMAP P3 said "needs MFP timer or VBL" and neither can do it.  The MFP's
timer clock is 16 MHz/4, its prescalers stop at 200 and its data register is 8
bits, so the slowest tick any single timer can make is 78.125 Hz -- 6.5x faster
than a frame -- and 4e6/12 is not an integer, so no setting reaches 12 Hz at
all.  The raster has no whole divide near 12 either: 4 refreshes is 13.86 fps
and 5 is 11.09.  tools/analysis/23_frame_clock.py walks all 7x256 timer settings
rather than asserting it.

src/player/clock.i takes the V-DISP falling edge on MFP GPIP4 -- the start of
vertical blanking, which is when a player would present -- and adds fps*VTOTAL
per edge to a 16-bit accumulator, emitting a tick at 31,500 and keeping the
remainder.  The long-run rate is fps*VTOTAL/VTOTAL = 12.000000 fps exactly, and
both constants are read out of the CRTC at init, so the clock is derived from
the registers that generate the raster it counts.  Measured over 3,000
refreshes: 3,000 interrupts, 649 ticks where 649.1429 were due.

It costs 181.35 clocks per V-DISP, 838 per frame, 0.1006% of the budget -- timed
by the 68000 itself, because the host's granularity is 17.64 ms and the
interrupt is microseconds.  The loop's own cost was calibrated rather than
looked up and landed on 38.000002 clocks, which both licenses the subtraction
and confirms buscost.py's model; the 181.35 then decomposes exactly, leaving
43.99 clocks for the interrupt exception -- the textbook 44, measured.

THE ONE THAT MOVES SOMETHING: 12 fps on a 55.4577 Hz raster is 4.6215 refreshes,
so a frame is shown for 4 refreshes (72.13 ms) or 5 (90.16 ms), 37.9% of them
short.  The 833,333-clock budget every figure in this project is priced against
is the MEAN slot, and the short one is 13.4% under it.  The cadence was already
in the tree unnamed: stream.lua's tick is sampled at frame boundaries, so its
gaps were always 4 or 5, and every host-paced result in FINDINGS 49/51 carried
it.  P3 moved who produces it onto the machine and made it visible.  It is not a
dropped frame -- the pace gate lets an overrun eat the next frame's idle -- and
on the gate container it costs 4 frames of 120 their idle against 1 for the
nominal model, most of that the frame-0 transient at 111% of budget.  stream.s
counts it now, and the rig matches an offline model of the divider exactly.

Also struck: MAME's raster runs 2.22% fast.  refresh_mode() builds the frame
period from scr.max_x*scr.max_y with scr.max_x = m_htotal - 8, one character
cell short and an inclusive bound used as a count, so it runs at 56.6901 Hz
where the registers say 55.4577 -- agreeing to six digits with the arithmetic.
Every "1/55.46 s granularity" note in this tree was wrong and is 1/56.69 s,
corrected in six files with the derivation put once in crtc_mode.lua.  No
conclusion changes and no 68000 cycle figure moves; the CPU clock is unrelated
to the screen.  But anything paced by the raster runs fast under MAME, so the
rig reports both rates and prices the interrupt against the hardware's.

decode.s and frame.i are unchanged; decode.bin is still 1,296 B at the same MD5.
The pace gate's wait loop is byte-for-byte the one FINDINGS 51 measured and the
free-running path executes none of the new code.  check.sh gains two stages: the
clock's own measurement, and 120 frames decoded pixel-exact with nothing outside
the machine deciding when a frame may start.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

docs/STATUS.md

@@ -1,3 +1,117 @@
+# Status & next-session handoff — end of session 22 (2026-08-24)
+
+## Session 22: the frame clock moves onto the 68000, and the 12 fps frame turns out not to exist
+
+**Green light first and last: `./tools/bench/check.sh` was ALL GREEN before any
+of this and ALL GREEN after**, 120/120 on both cores, no `TRUNCATED`, plus two
+new frame-clock stages.
+
+**ROADMAP P3 is DONE. FINDINGS 54.** P3 was one of the two items session 21's
+handoff called buildable here, and it is the one that touches every other number
+in the project — because the tick is what the word "frame" in "% of a frame"
+means.
+
+**1. Neither of the two sources P3 named can do it, and the enumeration is the
+finding.** The MFP's timer clock is 16 MHz/4 = 4 MHz, its prescalers are
+`{4,10,16,50,64,100,200}` and its data register is 8 bits, so the **slowest tick
+any single timer can make is 78.125 Hz** — 6.5x faster than a frame — and
+**4e6/12 = 333,333.33 is not an integer**, so no setting reaches 12 Hz at all.
+The raster has no whole divide near 12 either: 4 refreshes is 13.86 fps and 5 is
+11.09. `tools/analysis/23_frame_clock.py` walks all 7x256 timer settings rather
+than asserting it. 54.1, 54.2.
+
+**2. The clock is the raster with a remainder, and it is exact by construction.**
+`src/player/clock.i` takes the V-DISP falling edge on MFP GPIP4 — the start of
+vertical blanking, which is when a player would present — and adds `fps*VTOTAL`
+per edge to a 16-bit accumulator, emitting a tick at 31,500 and keeping the
+remainder. Long-run rate is `fps*VTOTAL/VTOTAL` = **12.000000 fps exactly**.
+Both constants are **read out of the CRTC at init**, so the clock is derived from
+the registers that generate the raster it counts. Measured: **3,000 interrupts,
+649 ticks where 649.1429 were due**. The gate is stated in ticks, not ppm — a
+remainder is off by at most one tick over any window, so ppm would let a longer
+window advertise a tighter clock for free. 54.2.
+
+**3. It costs 181.35 clocks per V-DISP; 838 per frame; 0.1006% of the budget.**
+The host cannot time this — its granularity is 17.64 ms and the interrupt is
+microseconds — so **the 68000 times it itself**: a one-instruction loop over a
+3,000-refresh window, run with the clock off and on, with the loop's own cost
+calibrated rather than looked up. The calibration landed on **38.000002 clocks**
+per iteration, which is both the check that licenses the subtraction and an
+independent confirmation of `buscost.py`'s model. The 181.35 then decomposes
+exactly, leaving **43.99 clocks for the interrupt exception** — the textbook 44,
+measured rather than recalled. A timer-based clock would have cost 3.6x this at
+an arbitrary phase against the scan. 54.3.
+
+**4. THE ONE THAT MOVES SOMETHING: there is no 83.33 ms frame, and there never
+was.** 12 fps on a 55.4577 Hz raster is 4.6215 refreshes, so a frame is shown for
+**4 refreshes (72.13 ms) or 5 (90.16 ms)**, 37.9% of them short. The
+833,333-clock budget every figure in this project is priced against is the
+**mean** slot; the short one is **13.4% under it**, and 10 of the gate
+container's 120 frames do not fit it.
+
+**And the cadence was already in the tree, unnamed.** `stream.lua`'s tick is
+`floor((t - t_rel) * fps)`, which looks uniform and is not: Lua only sees the
+machine at frame boundaries, so its ticks land on refreshes and its gaps were
+always 4 or 5. **Every host-paced result in FINDINGS 49 and 51 already carried
+this cadence.** P3 did not introduce it; it moved who produces it onto the
+machine and made it visible.
+
+**It is not a dropped frame.** The pace gate says only "not before tick i", so an
+overrun eats the next frame's idle and the clock recovers itself; the cost is one
+frame presented a refresh late. On the gate container that is **4 frames of 120
+with no idle left, against 1 for the nominal model** — and the expensive one is
+**frame 0 at 111% of budget**, because the first frame of a scene has nothing to
+SKIP against. So the cost lands **at a scene change**, next to 53.2's 18.96 ms of
+loader and the seek. `stream.s` counts this itself now, and the rig's count
+matches an offline model of the divider **exactly**: 4/120, first at frame 1, on
+both tick sources. 54.4.
+
+**5. An instrument correction the whole tree was reading.** `x68k_crtc.cpp
+refresh_mode()` builds the frame period from `scr.max_x * scr.max_y` with
+`scr.max_x = m_htotal - 8` — one character cell short, an inclusive bound used as
+a count. **MAME's raster is fast by 368/360 = 2.2222%**: 56.6901 Hz measured
+against the registers' 55.4577, agreeing to six digits with the arithmetic. So
+every "1/55.46 s granularity" note in this tree was wrong and is **1/56.69 s**;
+corrected in six files with the derivation put once in `crtc_mode.lua`. **No
+conclusion changes and no 68000 cycle figure moves** — the CPU clock is unrelated
+to the screen — but anything *paced* by the raster runs 2.22% fast under MAME, so
+`clock.lua` reports both rates and de-skews, and the interrupt is priced against
+the hardware refresh count. 54.5.
+
+**New in the tree:** `src/player/clock.i` (the clock) and
+`src/player/clockgate.s` (its measurement front-end); `tools/bench/clock.lua`,
+`clock_cost.py`, `clock_run.sh` (the rig); `tools/analysis/23_frame_clock.py`
+(the enumeration and the cadence pricing). `stream.s` gains `CLKON` and a
+late-frame counter ahead of the wait loop; `stream.lua` gains `DLX_PACE=2` and
+takes its deadlines from the ticks the machine actually emitted rather than from
+a host model; `pace_run.sh` gains `DLX_PACE` selection, with the default tag left
+alone so `pace_sweep.sh` still finds its logs. `check.sh` gains two stages: the
+clock's own measurement, and 120 frames decoded pixel-exact with nothing outside
+the machine deciding when a frame may start.
+
+**`decode.s` and `frame.i` are unchanged.** `decode.bin` is still 1,296 B at the
+same MD5. The pace gate's wait loop is byte-for-byte the one FINDINGS 51
+measured, and the free-running path executes none of the new code, so every
+FINDINGS 49 figure stands.
+
+**Still open in P2:** unchanged — the encoder does not reserve a black entry
+(23.4), so the letterbox still gets the palette's closest thing to black.
+
+**Next:** P5 (per-record index, prefill policy, the accumulated-slack rule in the
+player rather than the rig) is buildable here and is now the last M2 item that
+is. G1 (import the scene graph) still needs fetching, and is still the one that
+would let this tree ask what the worst gap between consecutive decision points
+is. P4 still decides the project and still cannot be measured here.
+
+**A question 54.4 raises and does not answer:** every rate-control and budget
+figure in this project is fitted to an 833,333-clock frame, and 37.9% of frames
+get 721,270. Whether the encoder should be fitted to the SHORT slot instead of
+the mean is a re-encode plus a re-measurement — the same class of change as the
+reserved black entry — and it should be decided with P5's numbers in hand, not
+before.
+
+---
+
 # Status & next-session handoff — end of session 21 (2026-08-24)
 
 ## Session 21: the loader moves onto the 68000, and a scene change gets a price
@@ -68,7 +182,8 @@ what this project is short of. **Derived, not measured.** 53.6.
 gains a `--loadraw` mode, which also makes its flag-watch address a variable
 rather than a constant. `check.sh` gains a stage that gates byte-exactness on
 both cores, and deliberately does **not** gate the cycle counts — MAME's clock
-is 1/55.46 s and a wall timing would make the green light host-sensitive, the
+is 1/56.69 s (1/55.46 when that was written; 54.5) and a wall timing would make
+the green light host-sensitive, the
 same reason `blit.s` and `span.sh` are not in it.
 
 **`decode.s` and `stream.s` are unchanged.** Nothing in the per-frame path was