Put the transport on the 68000, and find PIO costs 87 clocks a byte

ROADMAP P4b. src/player/xfer.i answers src/player/ring.i's XF_* mailbox with a
real READ(10) to a real MB89352 in place of tools/bench/stream.lua's modelled
transport: 120 records, 4,488,588 B, pixel-exact out of a 256 KB ring, with a
real mid-stream seek in a second pass. The tiling is the SAME 18 wraps and
14.7 KB mean hole that 49.4's host producer and 55.4's modelled transport
produced -- a third transport, same placement, which is the assertion that
ring.i could not tell which side of the seam answered it.

What it costs is the finding. tools/bench/xfer_cost.sh subtracts the same 120
frames run twice and gets 87.28 clocks per delivered byte, against the 68000's
own cycle table for the loop, which says 87.15 -- 0.2% apart, so the cost is the
instruction stream and not MAME's device model, and it is the first number this
rig has produced that survives leaving the emulator. That is 391.8% of a 12 fps
frame; the machine's own V-DISP clock agrees from the other end at 2.57 fps.
Against the ladder, W=5 held is 22.4% of a frame and W=19 is 85.3%, so P4a is
worth 4.6x the worst DMA configuration in this tree and 17.5x the best -- where
before this session it was worth 9 against 19. W itself did not move by a clock.

"UNDERRUNS: 0/120" is vacuous with a synchronous transport, and stream.lua now
prints that argument next to the zero: a frame cannot start before its record
has landed because the decoder IS the transport. The counter that means
something is NO IDLE, 119/120 with a worst overrun of 441 whole ticks. Same
class of error as 49.7.2's free-running ring passing at 48 KB.

58.3: a record is not a sector -- 117 of 120 start part way into one, and
reading whole sectors into the ring corrupts the neighbours rather than wasting
bytes (49.2, no bounds check). scsi.i reads the covering sectors and stores only
the window, which is free in PIO and stops being free the moment P4a succeeds.
tools/analysis/26_sector_align.py prices the three ways out and sector-aligned
records win on both axes: +0.43% wire and zero clocks, against +1.34% and a
bounce copy at +5 clk/B. ROADMAP now carries a four-item re-encode bundle and
P4a should be attempted against a sector-aligned container.

check.sh gains two stages and was ALL GREEN before and after. decode.bin is
unchanged at 1,296 B and the same MD5.

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

tools/bench/scsi_run.sh

@@ -35,25 +35,10 @@ set -e
 cd "$(dirname "$0")/../.."
 DLX=${1:-tmp/rc_fr_singe_scsi_span.dlx}
 
-# The container's frame records, laid out as a disc.  prep_stream.py already
-# writes exactly this file for the ring rig, so the SCSI volume and the host-file
-# pipe carry byte-identical bytes and a difference between the two rigs cannot be
-# a difference in what they are reading.
-[ -f tmp/stream_disk.bin ] || python3 tools/bench/prep_stream.py "$DLX" > /dev/null
-if [ ! -f tmp/dlxdisk.chd ] || [ tmp/stream_disk.bin -nt tmp/dlxdisk.chd ]; then
-  python3 - <<'PY'
-d = open("tmp/stream_disk.bin", "rb").read()
-n = (len(d) + 511) // 512
-open("tmp/dlxdisk.img", "wb").write(d + b"\0" * (n * 512 - len(d)))
-print(f"  disc image: {len(d)} B of records -> {n} sectors")
-PY
-  rm -f tmp/dlxdisk.chd
-  chdman createhd -i tmp/dlxdisk.img -o tmp/dlxdisk.chd -ss 512 > /dev/null 2>&1
-fi
-
-mkdir -p tmp/p4roms/x68k_cz6bs1
-[ -f tmp/p4roms/x68k_cz6bs1/scsiexrom.bin ] || \
-  head -c 8192 /dev/zero > tmp/p4roms/x68k_cz6bs1/scsiexrom.bin
+# The container's frame records, laid out as a disc, and the blank card ROM.
+# Both are tools/bench/mkvol.sh's, shared with tools/bench/pace_run.sh so the
+# SCSI rig and the host-file ring rig cannot be reading different bytes.
+bash tools/bench/mkvol.sh "$DLX"
 
 tools/vasm/vasmm68k_mot -Fbin -o tmp/scsigate.bin src/player/scsigate.s > /dev/null