Put the ring on the 68000, and find the disc stops whenever the player is not asking

ROADMAP P5. The loader moved in session 21 and the frame clock in 22; the ring
producer was the last policy living outside the machine. src/player/ring.i does
`aligned` placement, the descriptor ring, a prefill, 51.2's slack rule and a
seek, and the host keeps only the transport.

It needed a container change. `aligned` asks whether the next record fits
before the end of the ring -- a length asked BEFORE the record is fetched -- and
every reader in this tree answered that by walking the frame stream, which is
exactly what a player streaming off a disc cannot do. DLX4 carries nframes u16
record lengths in the scene header. Frame payloads are byte-identical to the
DLX3 encode, so no fitted constant moves; the scene header goes 5,920 to 6,164 B.

The producer reproduces the host's tiling exactly: 18 wraps, 14.7 KB mean hole,
pixel-exact, a third independent implementation of the same policy.

What it exposed is bigger than the item. A channel only moves bytes while it has
a request and only the CPU can issue one, so the disc stands still between
records by an amount the PLAYER sets, not the medium -- and no host-filled run
could see it. At 488 KB/s in a 256 KB ring a one-deep request queue gives away
6.8% of the pipe and underruns 59 of 120 frames; two-deep gives away 3.4% and
underruns none. The container's whole surplus over the wire is 8.7%, so the
player's own loop was spending most of the slack a branch point saves up.
Prefill is the weaker lever: six records of it still leaves 24 underruns.

Three silent bugs are recorded in FINDINGS 55.7 -- all produced wrong pixels or
a desync rather than a fault -- plus a rig one: MAME renders a screen line by
line, so snapshotting the frame the decoder finished in captures a tear that
reads exactly like a decoder bug.

check.sh gains the machine-owned ring and a seek with the decode after it.
decode.bin is unchanged at 1,296 B and a host-filled run executes none of the
new code, so every FINDINGS 49/51 figure stands. ALL GREEN before and after.

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

docs/ROADMAP.md

@@ -157,7 +157,10 @@ period from `htotal - 8`), so the tree's "1/55.46 s granularity" was 1/56.69 s
 throughout. No 68000 cycle figure moves — the CPU clock is unrelated to the
 screen — but anything paced by the raster does. 54.5.
 
-**P4. Real transport.** Drive the MB89352 instead of a host file. The `W`
+**P4. Real transport.** Drive the MB89352 instead of a host file. **Session 23
+added a second axis to it:** `W` is the clocks stolen per delivered byte, and
+55.3 measured that the player's own request loop gives away 3-7% of the pipe
+before `W` is even asked about. A transport design has to answer both. The `W`
 handshake — clocks stolen per delivered byte, bracketed 5..12 by MC68450 Fig
 4-25 — is listed in "Decisions locked" as UNDECIDED and as the thing that
 decides the project: `W<=6` fits 0/120 frames, `W=8` misses 47/120. It is a
@@ -178,11 +181,36 @@ first job rather than its last.
 clocks per WORD and FINDINGS 43 voided it; 52.5 cited it in byte units when
 first written and strikes it.
 
-**P5. Seek and branch.** Per-record index (the `aligned` producer needs one
-anyway, 49.3), prefill policy, and the accumulated-slack rule from 51.3 made
-explicit in the player rather than implied by the rig.
+~~**P5. Seek and branch.**~~ **DONE, session 23 — FINDINGS 55.**
+`src/player/ring.i` fills the ring on the 68000: `aligned` placement, the
+descriptor ring, a prefill policy, 51.2's slack rule as arithmetic the player
+can run (`ring_may_seek`), and a seek that quiets the channel and re-addresses
+the stream out of the index. It reproduces the host producer's tiling exactly —
+18 wraps, 14.7 KB mean hole, pixel-exact — and the host now AUDITS every
+placement instead of making it.
+
+The index is a **container change**: DLX4 carries `nframes` u16 record lengths
+in the scene header, because `aligned` needs a record's length before it fetches
+it and walking the stream is precisely what a player cannot do. Frame payloads
+are byte-identical to the DLX3 encode; the scene header goes 5,920 to 6,164 B.
+
+**What it exposed is bigger than the item.** A channel only moves bytes while it
+has a request and only the CPU can issue one, so the disc **stands still between
+records** by an amount set by the player's loop rather than by the medium — and
+no host-filled run could see it. At 488 KB/s in a 256 KB ring, a one-deep
+request queue gives away **6.8% of the pipe and underruns 59 of 120 frames**; a
+two-deep one gives away 3.4% and underruns none. The container's whole surplus
+over the wire at that rate is 8.7%, so the player's own loop was spending most
+of the slack 51.3 accumulates. **Prefill is the weaker lever** — six records of
+it still leaves 24 underruns at depth 1 — and the fix costs no clocks and no
+bytes. 55.3, 55.4.
+
+**P5a (open, and it belongs with P4).** The two-deep queue is modelled as two
+mailbox slots. On the machine it is two DMAC channels or one channel with a
+chained descriptor array, and which of those is affordable is a `W` question.
 
 **P7. Boot.** The player as an executable loading from the SCSI volume.
+Buildable, and empty until P4: there is nothing to boot from yet.
 
 ---