Put the data phase on the DMAC, and find auto-request is charged by time

ROADMAP P4a. src/player/dma.i programs HD63450 channel 1 and takes the SCSI DATA
IN phase off the CPU; src/player/dmagate.s reads the same 2,048 B at LBA 1000
three ways -- PIO, the channel with the bus held, the channel stealing cycles --
and all three are byte-exact against the host's copy of the volume.

The evidence never reads $EA0015, because 57.3 established that it cannot: with
the DMAC's OWN asserted MAME cannot tell a CPU-driven byte there from a
DMAC-driven one. The discriminator is the CPU's own progress. MTC is sampled by
the INSTRUCTION AFTER the one that starts the channel, and held it reads 0 of
2,048 -- the whole transfer happened between two instructions, because the 68000
did not execute in between -- against the full count and 426 loop trips for the
stealing configuration. Put the stealing registers in the held slot and every
byte still arrives and tools/bench/dma_run.sh goes RED, which is what says the
counter can come out different; 58.3's vacuous "UNDERRUNS: 0/120" is the trap
being avoided. tools/analysis/27_dmac_config.py decodes the four register bytes
out of the player's own source, with the MC68450 field tables now in one copy
(tools/analysis/mc68450.py) shared with 21_iplrom_dmac.py, so the player's
configuration and the IPL ROM's 16..19 clk/B one are the same decoding.

Three bounds on the apparatus, read out of MAME 0.277 rather than inferred: the
CZ-6BS1 has NO request line to the DMAC (its flow control is DTACK), so external
request cannot be run; single address cannot be run either, because only channel
0 has device callbacks; and only burst is modelled as held. Of the four rows of
the W ladder exactly one -- dual address held -- has a code path here, and it is
the one demonstrated. W did not move by one clock, for the third session running.

What outlives the emulator is the currency. Every W in this project is clocks per
DELIVERED byte, which presumes the device asks; an auto-requested channel spends
its share of the bus whether or not a byte is there, so a record costs what it
costs to ARRIVE -- halve the delivery rate and the CPU cost of the same record
doubles. tools/analysis/28_autorequest_cost.py prices it from MC68450 3.8 and
5.2.3.3.2, gating its formulas against Table 5-3's sixteen rows first. At 37,405
B and an explicit 460 KB/s: max rate costs the whole 95.3% of a frame the record
takes to land, and of the GCR's four bus shares only BR=00, 50%, carries the
rate -- 10.61 clk/B, 47.6% of a frame, against 40.4% for the W=9 row and 391.8%
measured for PIO. The GCR is a design lever nothing in this tree had named.

59.4 changes what is left. sc_in_data now REFUSES a windowed read when the data
phase is the channel's (SCE_WINDOW), because a channel writes a contiguous run
and cannot drop the 300 B in front of a record. 117 of 120 records need one, so
sector-aligned records have gone from a preference in ROADMAP's re-encode bundle
to the precondition the transport enforces -- and that bundle is now the only
thing between this tree and M2.

One collision, recorded because the procedure is the finding: DM_USE first sat at
$18300, which is ring.i's XF_SLOT mailbox, and the P4b stage -- untouched by this
work -- went red on a run that never reached its snapshot. check.sh was ALL GREEN
before any of this, which is what made that red unambiguous. ALL GREEN after too,
with one new stage. decode.bin is unchanged at 1,296 B and the same MD5.

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

docs/ROADMAP.md

@@ -8,6 +8,10 @@ Amended end of session 24: G1 done (FINDINGS 56).
 Amended end of session 25: P4 HALF done (FINDINGS 57).
 Amended end of session 26: P4b done, P4a is the last open item before M2
 (FINDINGS 58).
+Amended end of session 27: P4a done at the transport level; THE RE-ENCODE
+BUNDLE under P2 is now the only thing between this tree and M2, because 59.4
+made sector-aligned records a precondition the transport enforces rather than a
+preference (FINDINGS 59).
 
 **THE COMPLETION TARGET IS M3, THE VERTICAL SLICE** (USER DECISION): one scene
 tree — a decision point, two outcomes, a death clip — with audio, streaming from
@@ -34,7 +38,7 @@ these units:
 | **68000 clocks** | measured, and the rate controller binds on them. |
 | **Delivery rate** | **no working figure, deliberately** (FINDINGS 50, USER DECISION). Every tool REQUIRES an explicit rate. |
 | **Seek time** | **no figure at all, and never had one.** 51.3/51.4 made it matter. |
-| **W, clocks stolen per delivered byte** | 5 single-address held, 9 dual held, 12 single arbitrated; the IPL ROM's own disk channel is **16..19** (52.5). **The largest open number in the project.** |
+| **W, clocks stolen per delivered byte** | 5 single-address held, 9 dual held, 12 single arbitrated; the IPL ROM's own disk channel is **16..19** (52.5). **The largest open number in the project.** Session 27 added the row underneath it: with **no external request line** on the card (59.2) the channel is auto-requested and is charged **by time rather than by byte**, so at 460 KB/s a 50% bus share costs **10.61 clk/B** and a smaller share cannot carry the rate at all (59.3). |
 
 ---
 
@@ -135,7 +139,9 @@ own; together they are one:
   2. `--spans all` as the default (E2, and it is the loaded lever on the byte
      side);
   3. re-derive span selection jointly with `lam` (E3);
-  4. **sector-align every record (58.3, new in session 26)** — +0.43% on the
+  4. **sector-align every record (58.3; PROMOTED TO A PRECONDITION in session
+     27, 59.4 — `sc_in_data` refuses a windowed read under the DMAC, so this is
+     what the channel is waiting for)** — +0.43% on the
      wire, zero clocks, and it is what lets P4a's DMA channel write straight
      into the ring with no window and no bounce copy. Until then the letterbox gets the palette's
 closest thing to black (index 255 on the gate container); `load.i` reports
@@ -173,8 +179,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. P4b DONE, session 26 — FINDINGS 58. P4a OPEN, and it is
-now the ONLY thing between this tree and M2.**
+**P4. Real transport. P4b DONE, session 26 — FINDINGS 58. P4a DONE at the
+transport level, session 27 — FINDINGS 59. What is now between this tree and M2
+is THE RE-ENCODE BUNDLE under P2, because the channel refuses a windowed read
+(59.4) and 117 of 120 records need one.**
 ~~Drive the MB89352 instead of a host file.~~ `src/player/scsi.i` selects a SCSI
 target and issues READ(10) on the 68000, with no IOCS and no host in the
 transfer path: **4,096 B from LBA 0 and 2,048 B from LBA 1000, both byte-exact**
@@ -189,14 +197,45 @@ wants the real ROM's bytes** and is untouched by this.
 
 **What is left is the half that decides the project**, and it is now two pieces:
 
-**P4a. A DMAC configuration that HOLDS THE BUS.** Unchanged as the first job,
-but 57.3 changes how it can be shown: `x68k_scsiext.cpp` glues `$EA0015` so that
-a write is discarded when `exown()` is asserted and DRQ is low, and on this
-machine `exown()` is asserted at idle. Every transfer therefore runs the SPC in
-DMA mode with the CPU moving the bytes through the DMAC's own door — and **MAME
-cannot then distinguish a CPU-driven byte from a DMAC-driven one at that
-address**. "The DMAC held the bus" needs evidence that does not come from
-watching `$EA0015`.
+~~**P4a. A DMAC configuration that HOLDS THE BUS.**~~ **DONE at the transport
+level, session 27 — FINDINGS 59.** `src/player/dma.i` programs HD63450 channel 1
+and takes the DATA IN phase: **the same 2,048 B off the disc three ways — PIO,
+held, stealing — all three byte-exact.** 57.3's warning was met rather than
+worked around: the evidence never reads `$EA0015`. **MTC is sampled by the
+instruction after the one that starts the channel, and held it reads zero of
+2,048** — the whole transfer happened between two instructions, because the
+68000 did not execute in between — against the full count and 426 CPU loop trips
+for the stealing configuration. Put the stealing registers in the held slot and
+every byte still arrives and the gate goes **red**, which is what says the
+counter can come out different (58.3's vacuous-counter trap, avoided
+deliberately).
+
+**Three bounds on the apparatus, read out of MAME's source and not inferred**
+(59.2): the card has **no request line to the DMAC** (its flow control is
+DTACK), so external request — the mode the `W`=5 and `W`=12 rows assume —
+cannot be run; **single address** cannot be run either (only channel 0 has
+device callbacks); and **only burst is modelled as held**. Of the four rows of
+the ladder exactly one, dual address held, has a code path here, and it is the
+one demonstrated. The slot pinout has `#EXREQ` at B36, so a real card plausibly
+drives it — **that is now B3's sharpest form**.
+
+**What is left of P4a is downstream of the container, not of the DMAC** (59.4):
+`sc_in_data` **refuses** a windowed read when the data phase is the channel's,
+because a channel writes a contiguous run and cannot drop the 300 B in front of
+a record. So putting the channel behind `ring.i`'s mailbox waits on the
+re-encode bundle.
+
+**P4c (new, and it is a DESIGN CHOICE the tree had not named).** Auto-request is
+charged **by time, not by byte** — the channel spends its share of the bus
+whether or not a byte is there, so halving the delivery rate DOUBLES the CPU
+cost of the same record. The MC68450's GCR sets that share: `BT`/`BR`, four
+values, 50/25/12.5/6.25%. `tools/analysis/28_autorequest_cost.py` prices it
+against an explicit rate; at 460 KB/s **only the 50% share carries this
+container**, at 10.61 clk/B and 47.6% of a frame per record, against 40.4% for
+the `W`=9 row and 391.8% measured for PIO. **If B3 comes back saying the real
+card drives `#EXREQ`, the ladder applies and this is the fallback; if it does
+not, this IS the cost model** and the GCR pair is a number the player has to
+choose.
 
 ~~**P4b. `scsi.i` behind `ring.i`'s `XF_*` mailbox.**~~ **DONE, session 26 —
 FINDINGS 58.** `src/player/xfer.i` answers the mailbox with a real READ(10) per
@@ -239,7 +278,9 @@ writes a contiguous run and cannot drop bytes. The three ways out price as
 avoid), or **+0.43% wire and zero clocks** (sector-aligned records in the
 container). The last one wins on both axes and is a **re-encode**; see the
 bundle under P2. **P4a should be attempted against a sector-aligned container,
-not against this one.**
+not against this one.** *(Session 27: it was, in the only sense that mattered —
+the transport now REFUSES the windowed case rather than being trusted not to
+reach it, so the bundle is a precondition rather than a plan. 59.4.)*
 
 *(original item, still the standing description of the `W` question:)*
 Drive the MB89352 instead of a host file. **Session 23