# Findings — session 1 (2026-08-23) All numbers here are MEASURED unless marked ESTIMATE or FOLKLORE. --- > **THE DELIVERY RATE HAS NO WORKING FIGURE — retired session 18 (USER > DECISION).** Sections below written before session 18 name a "4 Mbps" pipe > constant and score tables against it. **Read every one of those as history.** > It was never a bus measurement: user-supplied, no provenance, 10% of SCSI-1's > asynchronous rating (FINDINGS 42.1), and FINDINGS 49.5 caught the shipping > candidate exceeding it while nothing in the tree was comparing the two. > > It is now gone as a default from every analysis tool and from > `tools/bench/stream.lua` — `--bus` / `--kbps` / `DLX_STREAM_KBPS` are > **required arguments** with no fallback, so no table can be scored against a > rate its own output does not state. The one survivor is `GATE_SPAN_KBPS` in > `tools/bench/check.sh`, which is a **container recipe**, not a delivery claim: > the gate container was encoded with it and every per-block and span constant > in FINDINGS 41/43/45/49 is fitted to that container, so changing it is a > re-encode plus a re-measurement, not an edit. > > **What to use instead:** `tools/analysis/19_ring_stream.py` reports the > **zero-prefill pipe** — the rate a medium must clear for a container to need no > prefill. That is a requirement to measure a BlueSCSI against, not a constant to > design on. For the session-14 candidate it is **513.2 KB/s**. ## 1. Source material `DRAGONS_LAIR.iso` — 16 GB, UDF 2.x, **decrypted** (no AACS dir). Loop-mounted read-only at `/media/reala-misaki/BDROM` via `udisksctl loop-setup -r -f`. (7-Zip cannot read UDF 2.x; use the loop mount.) - **224 `.m2ts` streams**, 1920x1080, **MPEG-2, progressive, 23.976 fps** - Size histogram: 47 <5MB, 138 5-50MB, 22 50-150MB, 14 150-400MB, 3 >400MB - The 185 sub-50MB streams are the **arcade branching scenes already split into individual clips** — we get scene boundaries for free. - Big streams are full-feature playthroughs: 00215 (1376s), 00216 (1151s), 00223 (566s) - Typical scene clip ~60s (00203/00205/00199), some ~100s (00164/00212) **Gotcha:** clip durations vary wildly. Always read `format=duration` and seek relative to it. Seeking to a fixed offset silently yields 0 frames on short clips. --- ## 2. GVRAM layout [verified — see HARDWARE.md for source] **One 16-bit word per pixel position in EVERY color mode.** Bit depth does not change VRAM bandwidth; it only subdivides the word. `addr = page_base + y*1024 + x*2` — adjacent pixels are 2 bytes apart in all modes. Consequence: low bit depth buys **no speed**. 16-color mode is strictly worse than 256-color (same bus traffic, 1/16 the palette). Page-alias writes are hardware auto-masked, so 16-color needs no software read-modify-write — but it's still one word-access per pixel. **Chosen: 256 colors, 256x192 active area.** In 256-color mode P0=low byte, P1=high byte of each word. Sacrificing page 1 as a double-buffer lets a `move.l` cover two pixel positions, enabling `movem.l` bursts (12 regs = 48 bytes = 24 pixels). Identical blit cost to 65536-color mode but **half the on-disk data**. --- ## 3. Content measurements (8 scenes sampled, 5s each at 40% into each clip) | metric | mean | p90 | |---|---|---| | pixels changed / frame | 20.1% | 30.2% | | **blit cost** | **~64k cycles** | **~97k cycles** | | naive delta+RLE frame size | 15.5 KB | 19.6 KB | Budget is **833,333 cycles/frame** @ 12fps on a 10MHz 68000. ### => THE CPU IS NOT THE BOTTLENECK. I/O IS. Blit uses **under 8%** of budget. The naive row-span+RLE codec achieves only **3.2:1**, giving **365 KB/s / 470 MB** at 24fps (~183 KB/s / 235 MB at 12fps). Per-scene variance is extreme: static dialogue ~30 KB/s, action ~700 KB/s. Any codec needs a hard bitrate ceiling, not just a good average. ### "Shot on twos" — ASSUMPTION FAILED Dedupe found **zero** duplicate frames across all 8 scenes (`uniq=120/120`, 24.0 fps effective). This Blu-ray is a restoration where every frame is unique. We do NOT get halved data for free. **Decimation to 12fps must be explicit.** A weak alternation signature does exist (even-index pairs 40.7% vs odd 27.5%, ratio 1.5x, with occasional true-duplicate pairs at 0.03-0.19%), but it is irregular — Bluth mixed ones and twos; action is animated on ones. --- ## 4. MEASUREMENT TRAPS — read before trusting any pipeline number Three separate false results were produced and caught this session. All three looked plausible. Guard against them: 1. **Per-frame Floyd-Steinberg dithering destroys temporal coherence.** Error diffusion is chaotic: a +/-1 input change cascades across the row and produces a completely different index pattern. First run reported 31.5% pixels changed with near-zero variance (median 31.6, p90 32.3, max 32.7) while source mean-abs-diff was 0.09 — i.e. visually identical frames. That flat variance is the tell: **real animation has scene-dependent variance; noise does not.** Use no dithering (cel art is flat) or ordered/Bayer (spatially fixed, temporally stable). 2. **Temporal denoise smears motion.** `hqdn3d=4:3:6:4` — the `6:4` are temporal params. It flattened real motion, which then measured as "no motion" and produced an absurd 0.8 fps / 4 MB result. **Use spatial-only: `hqdn3d=4:3:0:0`.** 3. **Exact-match dedupe fails on a noisy source.** MPEG-2 grain means near-duplicate frames differ by +/-1 and are never bit-exact. Use a threshold on "% pixels differing by more than N levels", and pick the threshold from the observed distribution, not a guess. A 2% threshold ate genuine animation when mean consecutive change was only 0.9%. **Sanity rule: if a result has suspiciously low variance, or is suspiciously good, it is probably an artifact of the measurement, not a property of the content.** Scripts kept in `tools/analysis/` — 01 and 02 are marked BROKEN deliberately as regression references; 03 and 04 are the correct ones. --- ## 5. Storage interface — the SASI/SCSI split > **SUPERSEDED IN PART.** The claim below that DMA means streaming "costs > essentially no CPU" is **wrong** — see 19. The bandwidth figures here are > folklore; the working figure was **4 Mbps = 488 KB/s** (21), and **42.1 > retires that too**: it was never a bus figure. The 50-pin SCSI-1 5 MB/s below > is the correct bus rating. What binds is not the pipe but `W`, the clocks the > DMA steals per word — and this section's 8 clk/word is a bracket midpoint, > not a measurement (39.7, 42.6). [Yasuma, X68030 internal SCSI controller] - Interface: **SCSI-1**, 50-pin, 5 MB/s bus spec - Controller: **Fujitsu MB89352** SPC - Transfer mode: **DMA** (via **HD63450** DMAC) - Bus: X68000 original bus, **16-bit @ 10MHz** **Even on the X68030, SCSI runs at 10MHz 16-bit DMA.** Storage bandwidth does NOT scale with CPU — the controller sits on the original bus. HD63450's 12.5MHz official ceiling is why the X68030 runs at 25MHz. An "HSCSI" TSR forces PIO/FIFO transfer instead of DMA but was marginal even at 25MHz. Because it's DMA, **streaming costs essentially no CPU** — this stacks with the 8% blit utilisation. The 68000 really is nearly idle. ### Model split — IMPORTANT **The 10MHz models (original X68000, ACE, PRO, EXPERT) use SASI, not SCSI.** Built-in SCSI starts at the X68000 **Super** (1990) and continues through XVI, Compact, X68030. SCSI on earlier machines needs the **Sharp CZ-6BS1** board in an I/O slot (MAME models this: `-exp1 cz6bs1`). | target | bandwidth | naive codec (365 KB/s) | VQ codec (~30 KB/s) | |---|---|---|---| | SASI (stock ACE/EXPERT) | ~300-500 KB/s FOLKLORE | infeasible | comfortable | | SCSI (Super+, or CZ-6BS1) | ~1 MB/s FOLKLORE | tight but viable | trivial | Derived bounds (ESTIMATE): 16-bit @10MHz with 4-clock bus cycle = 5 MB/s absolute ceiling; HD63450 single-address DMA ~8 clocks/word => ~2.5 MB/s practical ceiling, before SCSI-1 async handshake and drive latency. **No measured benchmark was obtained — see STATUS.md.** The ~300-500 KB/s and ~1 MB/s figures are folklore-grade; I could not find a primary measurement. --- ## 6. Codec decision: vector quantization (Cinepak-style) Given ~8x CPU headroom and an I/O ceiling, spend CPU to buy bandwidth. - Split frame into 4x4 blocks, encode each as a 1-byte index into a per-scene codebook - Decode = 16-byte copy from a lookup table: nearly free - A **full** frame = 256*192/16 = **3,072 bytes** — a hard 16:1 floor before delta - Add block-level delta on top; action scenes ~2-3 KB/frame - => roughly **30 KB/s, ~40 MB total**, with a *deterministic* bitrate ceiling Divergence from the SNES project (below): use a **per-scene codebook with delta updates**, not a per-frame rebuild. We trade adaptivity for bandwidth because we have 2MB RAM to keep a codebook resident and CPU to spare. **Risk not yet evaluated:** 4x4 VQ with a 256-entry codebook will visibly soften detail. Bluth's fine ink linework is what suffers. Prototype and eyeball before committing. --- ## 7. Comparison: astrobleem/SNES-SuperDragonsLairArcade Reached the **same core architecture independently** — "512 tiles per frame" is vector quantization (8x8 codebook + tilemap). Good validation. But: the SNES PPU has **no bitmap mode**, so tiles are forced on them by display hardware. The X68000 has a real linear framebuffer, so VQ is a *compression choice* we can tune or drop per-scene. **MSU-1 is a bandwidth cheat we don't have.** It's a modern flash-cart coprocessor giving memory-mapped streaming the real SNES never had. Their budget: 512 tiles x 32 bytes (4bpp 8x8) + tilemap ~= 18 KB/frame => **~430 KB/s** at 23.976fps. That's *higher* than the 365 KB/s we'd reject on SASI. (ESTIMATE: my arithmetic on their stated tile budget, not a measured figure.) Where we're ahead: 256 simultaneous colors from a 65536 palette vs their 4bpp sub-palettes needing a tile-aware palette optimizer plus a spatial smoothing pass to hide 8x8 palette seams. That problem doesn't exist for us. Plus 68000@10MHz vs 65816@3.58MHz, and 2MB vs 128KB. **Most valuable thing in that repo is NOT the codec — it's `data/events/`:** 516 chapter definitions across 29 scenes as XML, plus `data/chapter_event_inventory.md`. That's the arcade scene graph and input-timing structure, entirely hardware-independent — the whole game-logic layer we'd otherwise reverse-engineer from the arcade ROM. **TODO: check their license before planning to reuse it.** Their 516 chapters are finer-grained than our 224 Blu-ray streams, so mapping their event table onto our footage means subdividing streams by timecode. Caveat: all of the above is from README/repo-tree summaries, not their source. --- --- # Findings — session 2 (2026-08-23) ## 8. CORRECTION to session 1: halving the framerate does NOT halve the bitrate > **PARTLY SUPERSEDED.** The framerate correction stands. The > "changed-spans + deflate = 247 KB/s" figure is a **compression upper bound, > not a shippable design** — deflate decode does not fit the 68000's frame > budget. See 17.2. Session 1 measured 365 KB/s for naive delta+RLE at 24 fps and wrote "(~183 KB/s at 12fps)". **That extrapolation is wrong.** Decimating to 12 fps roughly doubles the per-frame delta, so the *rate* stays nearly flat. Re-measured directly on 12 fps decimated frames (4 scenes, 66 frames): | codec (all LOSSLESS w.r.t. the 256-colour frame) | B/frame | KB/s @12 | 22 min | ratio | |---|---|---|---|---| | raw 8bpp 256x192 | 49152 | 576 | 743 MB | 1.0:1 | | session 1 row-span + RLE | 29055 | 340 | 439 MB | 1.7:1 | | XOR vs prev + deflate | 30196 | 354 | 456 MB | 1.6:1 | | **changed-spans + deflate** | **21110** | **247** | **319 MB** | **2.3:1** | | changed-spans + LZMA | 18759 | 220 | 283 MB | 2.6:1 | Session 1's own RLE re-measured at 12 fps gives **340 KB/s, not 183**. Any plan that assumed 183 KB/s was based on a bad number. Deflate-class entropy coding on top of the span payload is worth **1.4x** over hand-rolled RLE, and LZ decode is cheap on a 68000 (byte copies), so the lossless floor is ~247 KB/s / 319 MB. That is **infeasible on SASI** and **tight but real on SCSI**. ## 9. Flat 4x4 VQ at k=256 is NOT acceptable — confirmed by eye The risk flagged in 6 is real. At k=256, 4x4: | scene | palette-only PSNR | after VQ | VQ loss | |---|---|---|---| | 00010 | 38.35 | 29.68 | 8.67 dB | | 00020 | 39.90 | 32.67 | 7.22 dB | | 00146 | 35.25 | 29.35 | 5.89 dB | | 00181 | 41.92 | 32.87 | 9.05 dB | Visually: Dirk's face disintegrates, teeth and eyes turn to mush, ink outlines break into 4-pixel stair-steps, colour bleeds across block boundaries. ![flat 4x4 VQ failure](images/flat_vq_failure_00010.png) *Left: 1080p source. Middle: 256-colour palettised 256x192 — the quality ceiling, and it is excellent. Right: flat 4x4 VQ at k=256. This is the result that killed the flat-VQ architecture.* **Crucially, the 256-colour palettised frame itself looks excellent.** Flat cel art with a per-scene median-cut palette and no dithering is near-transparent (35-42 dB). So the palette is not the problem and 256 colours is not the problem — **block VQ is**. The quality ceiling we should hold ourselves to is the palettised frame, not the 1080p source. ## 10. Hybrid VQ (Cinepak V1/V4 + SKIP) — this is the codec Per 4x4 block, choose by rate-distortion: SKIP (reuse previous frame), V1 (one 4x4 codeword, 1 byte), or V4 (four 2x2 codewords, 4 bytes), with a 2-bit-per-block mode header. `lam` is the lagrangian rate knob. Measured, k1=k4=256, 4 scenes (mean of the per-scene table in the session log): | lam | PSNR | loss vs palette | SKIP% | V1% | V4% | B/frame | KB/s @12 | |---|---|---|---|---|---|---|---| | 0 (max quality) | 33.9 | 4.9 | 30.8 | 18.5 | 50.8 | 7574 | 88.8 | | 200 | 31.9 | 5.9 | 44.0 | 37.6 | 18.4 | 4183 | 49.0 | | 1000 | 31.6 | 7.3 | 47.4 | 47.7 | 4.9 | 2841 | 33.3 | | 5000 | 25.5 | 13.3 | 55.6 | 44.4 | 0.0 | 2134 | 25.0 | At a **matched ~30 KB/s** the hybrid beats flat 4x4 VQ by ~1 dB, and unlike flat VQ it keeps scaling: at 89 KB/s it reaches within **4.9 dB of the palette ceiling**, which flat VQ cannot reach at any bitrate. Note V4% collapses to 0 at lam=5000 — that is the knob doing exactly what it should: under a hard ceiling, detail blocks are the first thing sacrificed. ## 11. Codebook size sweep (flat 4x4, for reference) > **SUPERSEDED.** The k=1024 result below is an artifact of a rate model that > charged 1 byte for a 10-bit index. k=256 ships. See 14. | block | k | PSNR | loss | key B | changed% | KB/s @12 | codebook RAM | |---|---|---|---|---|---|---|---| | 4x4 | 256 | 30.46 | 8.39 | 3072 | 52.7 | 28.5 | 8K | | 4x4 | 1024 | 32.89 | 5.96 | 3840 | 56.6 | 35.6 | 32K | +2.4 dB for 24K more RAM and 7 KB/s. With 2 MB of RAM, a 1024-entry codebook is cheap and clearly worth it. (RAM figure is the word-expanded form the blitter wants: k * 16 px * 2 bytes.) ## 12. Source framing — OPEN The Blu-ray is **full-frame 1920x1080 16:9 with no pillarboxing**. The arcade original is 4:3. The extractor currently centre-crops 1440x1080, which is the arcade-faithful choice but discards image the 2006 remaster added. Options are `crop` (default), `squash`, `wide` in `tools/encoder/extract.py`. **Not yet decided; needs an eyeball comparison against arcade reference.** ## 13. Stream inventory correction Session 1 said "typical scene clip ~60s". Sampled directly: the ~3-5 MB streams are **1.2-1.7 s** clips — these are the individual arcade death/action moments, which is exactly the granularity the game logic needs. Some 60 s streams (e.g. 00203) are **menu screens, not content**. Any survey must classify menu vs content before averaging, or the bitrate numbers are diluted by static menus. ## 14. A FOURTH false-good result — and the correction Add this to the 4 list. The mechanism was new but the shape was identical. **The false result:** flat and hybrid VQ both showed **+2.4 dB for k=1024 over k=256** at an apparently similar bitrate, which made a 1024-entry codebook look like an obvious win. The k=1024 quality ladder rendered from that run looked great at "45 KB/s". **The bug:** the rate-distortion model in `vq_hybrid.encode()` charged **1 byte** per codebook index unconditionally. A 1024-entry codebook needs a **10-bit index, stored as 2 bytes**. So every k=1024 measurement understated the V1 and V4 payload by exactly 2x, *and* the lagrangian mode decision was choosing V4 on the belief that four codewords cost 4 bytes when they cost 8. **After charging the true index cost** (`idx_bytes` is now explicit and defaults from the codebook size), matched-bitrate comparison on scene 00020: | KB/s | k=256 (1-byte idx) | k=1024 (2-byte idx) | |---|---|---| | ~32-42 | **33.87 dB** @ 32.5 | 28.91 dB @ 42.3 | | ~44-52 | **34.80 dB** @ 44.1 | 35.13 dB @ 52.5 | | ~72-86 | **35.87 dB** @ 72.2 | 36.51 dB @ 86.0 | k=1024 buys +0.3 to +0.6 dB for +19% bitrate — a wash at best — and at the low end where the SASI profile lives it is **5 dB worse**, because the 2-byte index floor dominates once V4 is priced out. **k=256 with 1-byte indices is the shipping choice.** It is also the better decoder: a plain `move.b` index with no alignment case, and an 8 KB codebook instead of 32 KB. **The general lesson, again:** the comparison was not wrong about VQ, it was wrong about *cost*. When a knob looks like a free win, check that the rate model is charging for it. Same failure family as 4.1-4.3: a plausible number produced by a pipeline that was not measuring what it claimed to measure. ## 15. Rate-distortion curve of the shipping codec (k=256, corrected) Scene 00020 (Dirk screaming, close-up face — the hardest case for linework), and 00146. Includes the 2-bit-per-block mode header. No entropy coding yet. | lam | 00020 PSNR | 00020 KB/s | 00146 PSNR | 00146 KB/s | SKIP | V1 | V4 | RAW | |---|---|---|---|---|---|---|---|---| | 25 | 38.68 | 182.2 | 31.04 | 193.5 | ~37% | ~24% | ~13% | ~26% | | 100 | 35.87 | 72.2 | 29.04 | 72.5 | ~41% | ~34% | ~21% | ~4% | | 300 | 34.80 | 44.1 | 28.28 | 44.4 | ~44% | ~42% | ~14% | 0% | | 800 | 33.87 | 32.5 | 27.77 | 36.1 | ~46% | ~48% | ~5% | 0% | | 2000 | 27.57 | 25.5 | 24.88 | 30.2 | ~50% | ~49% | ~1% | 0% | Palette ceilings: 00020 = 39.90 dB, 00146 = 35.25 dB. ![quality ladder](images/quality_ladder_00020.png) *The shipping codec across the rate knob. Top: source, palette ceiling, lam=25. Bottom: lam=100 (`scsi` profile), lam=300 (`sasi` profile), lam=800. Both shipping profiles hold Bluth's linework; the failure only starts past lam=800.* Two things to read off this table: - **The cliff is between lam=800 and lam=2000.** That is where V4 is priced out entirely and detail blocks have nowhere to go. Do not ship past lam~800. - **RAW is doing real work at high bitrate** (26% of blocks at lam=25) and vanishes by lam=300. It is what makes the top of the curve reach the palette ceiling, and it costs the decoder nothing — RAW is the cheapest mode to blit. ## 16. Licences cleared for the game-logic layer Both checked this session: - **astrobleem/SNES-SuperDragonsLairArcade — MIT**, "Copyright (c) 2026 Chad Doebelin". `data/events/` holds 516 XML chapter definitions with timing and event data. Reusable with attribution. - **icculus/DirkSimple — zlib.** Independent from-scratch reimplementation of the game logic in Lua, scene/timing tables in `game.lua`. Also permissive. Having **two independent permissively-licensed transcriptions** of the arcade scene graph is better than one: they can be diffed against each other to catch transcription errors before any of it is committed to 68000 tables. ## 17. The profiles were set far too low — and entropy coding is a CPU trap > **PARTLY SUPERSEDED.** 17.1's diagnosis (the profiles were not derived from > hardware) and 17.2's CPU analysis both stand. But 17 reasoned against a > misread bandwidth of 4 MB/s; the correct figure was taken as **4 Mbps = > 488 KB/s**, so the "ship pixel-exact if SCSI sustains >=800 KB/s" conclusion > in 17.5 was withdrawn. See 18 and 21. > > **17.5 IS REINSTATED BY 42.3.** The 488 KB/s figure that withdrew it was > itself unsourced, and the delivered stream is 837.4 KB/s at 0.29 dB off the > palette ceiling — 17.5's threshold and 17.5's conclusion, arrived at from the > other end five sessions later. Its reasoning was sound; only its bandwidth > number was wrong, and it was wrong in the direction that made it look wrong. Prompted by the user asking why the SCSI profile was only 75 KB/s. It should not have been. Two separate errors, one of them serious. ### 17.1 The profile bitrates were not derived from the hardware at all They were read off the knee of the rate-distortion curve and then presented as though bandwidth-driven. Against the (folklore) bus figures from 5: | profile | was | bus figure | utilisation | |---|---|---|---| | `sasi` | 45 KB/s | ~300-500 KB/s | **12%** | | `scsi` | 75 KB/s | ~1 MB/s | **7%** | Nothing justified leaving 90% of the pipe unused. Raised to `sasi` 110 KB/s (lam=60) and `scsi` 280 KB/s (lam=10), which is 35% and 28% utilisation — still conservative, because the bus figures are folklore. ### 17.2 CPU is NOT the reason to stay low — but entropy coding would be Budget is 833,333 cycles/frame at 12 fps. At session 1's measured ~6.5 cycles per GVRAM pixel write: | work | cycles | % of budget | |---|---|---| | blit 20.1% of pixels (session 1's 24fps figure) | 64k | 7.7% | | blit 40% of pixels (the same content at 12fps) | 128k | 15.3% | | **blit the FULL frame, every frame** | **319k** | **38.3%** | | deflate decode, ~30 KB/frame output | 1,800k | **216%** | | LZ4/LZSS decode, ~30 KB/frame output | 450k | **54%** | Two conclusions, and the second one corrects 8: - **Raising the VQ bitrate is nearly free on CPU.** Even a full-frame pixel-exact blit fits in 38% of budget, and VQ decode is table copies — RAW, the mode that dominates at high bitrate, is the *cheapest* mode to blit, not the dearest. - **The 247 KB/s "lossless changed-spans + deflate" figure in 8 is a compression upper bound, NOT a shippable design.** Deflate's Huffman decode is bitwise and costs about 2.2x the entire frame budget on a 68000. Even byte-oriented LZ4 at 54% leaves too little beside a 38% blit. **Do not plan on entropy coding.** All profile bitrates are raw payload. This inverts session 1's "the CPU is idle, I/O is the ceiling" for the *decode* path specifically: the blit is cheap, but any bit-oriented decompressor is not. VQ is the right architecture precisely because its decode is a table copy. ### 17.3 The hybrid at lam=0 IS the lossless codec Measured, un-entropy-coded raw payload, and deflated for reference only: | scene | lam=0 raw | lam=0 deflated | lossless changed-spans+deflate | PSNR | |---|---|---|---|---| | 00020 | 442.1 KB/s | 274.5 KB/s | 267.3 KB/s | 39.90 = ceiling | | 00146 | 467.6 KB/s | 223.2 KB/s | 219.1 KB/s | 35.25 = ceiling | The hybrid at `lam=0` converges to within 3% of the purpose-built lossless coder. That confirms the architecture unifies: there is no separate lossless path to maintain, just the same bitstream with the knob open. ### 17.4 Full curve in raw (shippable) bytes | lam | 00020 PSNR | 00020 KB/s | 00146 PSNR | 00146 KB/s | RAW% | |---|---|---|---|---|---| | 0 | **39.90** (exact) | 442.1 | **35.25** (exact) | 467.6 | ~76% | | 10 | 39.38 | 248.1 | 32.27 | 305.2 | ~44% | | 25 | 38.68 | 182.2 | 31.04 | 193.5 | ~26% | | 60 | 36.94 | 108.0 | 29.61 | 103.1 | ~10% | | 150 | 35.31 | 55.6 | 28.63 | 56.1 | ~1% | | 300 | 34.80 | 44.1 | 28.28 | 44.4 | 0% | ### 17.5 This makes the blocked disk benchmark critical-path Session 1 judged it "NOT on the critical path" because VQ at 30 KB/s was correct whether SASI did 300 or 600 KB/s. That reasoning no longer holds. The profiles now sit at 110 and 280 KB/s, close enough to the folklore ceilings that the error bars matter, and **if SCSI sustains >=800 KB/s the correct `scsi` profile is lam=0 — pixel-exact video.** Whether this port ships transparent or lossy on SCSI is now waiting on one measurement. ## 18. Peak-to-mean burstiness — the mean was hiding the problem > **SUPERSEDED — DO NOT ACT ON THIS SECTION.** The peak-vs-sustained comparison > below is the **wrong test**. With a ring buffer the correct test is cumulative > demand vs cumulative supply, and both profiles pass it with **zero required > prefill**. `scsi` at lam=10 ships. See 21. The per-frame peak numbers > themselves are still valid data; only the conclusion drawn from them is wrong. Prompted by the user clarifying that the bandwidth figure is **4 Mbps = 488 KB/s**, not 4 MB/s. That is ~8x tighter than what 17 was reasoning against, and it changes the answer. Per-frame instantaneous rate (video + 7.8 KB/s audio), 12 fps: | scene | lam | mean | p90 | **max** | peak/mean | max as % of 488 KB/s | |---|---|---|---|---|---|---| | 00010 | 60 | 95.0 | 127.3 | 138.8 | 1.46 | 28.4% | | 00010 | 10 | 198.9 | 266.1 | 284.0 | 1.43 | 58.2% | | 00020 | 60 | 115.8 | 155.4 | 222.3 | 1.92 | 45.5% | | 00020 | 10 | 255.9 | 391.2 | **470.8** | 1.84 | **96.4%** | **The `scsi` profile as committed in f0f2f80 does not fit 4 Mbps.** Its mean is a comfortable 52% of the pipe, but it peaks at 96.4% — and a frame that arrives late is a *dropped frame*, not a slow one. Sizing a real-time stream on the mean is the mistake; peak/mean is 1.4-1.9x on 1.2-1.7s clips and will be worse across a full scene. Two ways out, and only one is good: - Size for the peak: `lam=25`, mean 194 KB/s. Costs a full step of quality. - **Rate-control to the mean and carry a leaky bucket:** `lam=10` fits, and buys back +0.7 dB (00020) / +1.2 dB (00146). `ratectl.py` was written in session 2 but **never wired into `encode.py`**. This demotes that from a loose end to the highest-value unfinished work in the repo. ## 19. Cycle-stealing DMA is not free DMA — 5 was wrong FINDINGS 5 concluded "because it's DMA, streaming costs essentially no CPU — this stacks with the 8% blit utilisation. The 68000 really is nearly idle." The HD63450 steals bus cycles from the 68000 at roughly 8 clocks per 16-bit word: | stream | words/s | clocks/s | CPU stolen | + full-frame blit | |---|---|---|---|---| | 110 KB/s | 56,320 | 450,560 | 4.5% | 42.8% | | 250 KB/s | 128,000 | 1,024,000 | 10.2% | 48.5% | | 450 KB/s | 230,400 | 1,843,200 | 18.4% | 56.7% | | 488 KB/s | 249,856 | 1,998,848 | 20.0% | 58.3% | At the rates the profiles now use, streaming costs **10-20% of the machine**. Still affordable — nothing here breaks — but **bandwidth and CPU are one budget, not two**, and any future headroom argument has to spend from both. The "nearly idle" framing should not be reused. (The 8 clocks/word figure is session 1's ESTIMATE from HD63450 timing, not a measurement. It is the weakest link in this table.) ## 20. Where the profiles should come from `tools/encoder/profile_gen.py` now derives lam from a bandwidth figure rather than from the shape of the RD curve, accounting for audio, peak/mean, and reporting DMA steal. Full benchmarking methodology — and why MAME cannot answer the bandwidth question — is in `docs/BENCHMARK.md`. The 4 Mbps figure itself is **user-supplied and its provenance is not recorded**. Every profile now hangs off it, so it is worth pinning down. ## 21. Correction to 18 — the peak test was the wrong test 18 flagged that `scsi` "does not fit 4 Mbps" because a frame peaked at 96.4% of the sustained rate. **That was the wrong comparison**, and the user was right to push back. It measured instantaneous frame demand against a sustained rate as if they had to match frame-by-frame. They do not: the disk keeps filling *during* the frame, and any shortfall is absorbed by a ring buffer. The correct test is whether **cumulative** demand ever outruns cumulative supply. Simulated at a constant 488 KB/s fill, 12 fps, using the real per-frame sizes: | scene | lam | mean KB/s | worst frame | **required prefill** | stall tolerance @256KB | |---|---|---|---|---|---| | 00010 | 10 | 198.9 | 23.67 KB | **0.0 KB** | 15.4 frames | | 00020 | 10 | 255.9 | 39.23 KB | **0.0 KB** | 12.0 frames | | 00146 | 10 | **313.0** | 42.10 KB | **0.0 KB** | 9.8 frames | | 00181 | 10 | 211.1 | 25.25 KB | **0.0 KB** | 14.6 frames | | (all) | 60 | 95-116 | 11-19 KB | **0.0 KB** | 26-32 frames | Fill delivers **40.69 KB per frame time**. Only one measured frame exceeds that (00146, 42.10 KB) and it is recovered by the following frame. **No scene needs any prefill at all**, and a 256 KB buffer — 12.5% of RAM — carries ~1 second of stall tolerance at `lam=10`, which is orders of magnitude more than an SD-backed seek requires. `scsi` at `lam=10` stands. The hardest scene sampled (00146) runs 313 KB/s mean, 64% of the pipe, with zero underrun risk. ### Why SD-backed changes the sizing rule The deployment target is BlueSCSI / SCSI2SD, not a period spinning drive. That was noted as a caveat in 5 but its consequence was not carried through: - The sustained rate is a **bus-limited constant**, not an average over variable seek latency. There is no long tail to leave margin for. - Seek is ~microseconds, so branch-point stalls are a non-issue against a buffer measured in whole seconds. - Therefore we can size much closer to the ceiling than spinning-disk practice would suggest. Conservative margins here are cargo-culted from a constraint this deployment does not have. **The SASI/SCSI split is about BUS PROTOCOL, not media.** SD emulation removes seek latency from both, but a SASI bus is still slower than a SCSI one. Two profiles remain the right design; both are now predictable constants rather than distributions. ### What rate control is actually for now Its value drops from load-bearing to **insurance**. Intra-scene peaks are a non-problem. But we have measured **4 clips of 1.2-1.7s** out of 224 streams, and 00146 already runs 23% hotter than 00020. A sustained action sequence could plausibly exceed the pipe where a 1.7s clip does not. Rate control gives a *deterministic ceiling* across content we have not measured yet — which was the original reason for choosing VQ over a lossless delta in the first place. Still worth wiring in. No longer a blocker for shipping `scsi` at `lam=10`. ## 22. The display path, measured — first real frame on the X68000 Everything before this section was Python-side or a headless `-video none` run. This is the first time pixels reached an emulated X68000 screen, and it produced four hardware facts and one blocker that no amount of reasoning would have found. **Scope — read this before quoting the result.** The X68000's *video* hardware did the rendering: CRTC, GVRAM page decoding and the 15-bit+I palette lookup are all genuinely emulated, which is why the output is bit-exact against the hardware's colour math. But the pixels were written into GVRAM by a MAME Lua script calling `SP:write_u16()` — the host poking emulated memory. **No 68000 instruction was executed to draw this frame.** The equivalent is proving a framebuffer works by writing to it from a debugger. It says the display path is correct; it says *nothing* about whether the 68000 can fill that framebuffer in time. Lua writes cost zero 68000 cycles, so the 38% full-frame blit estimate that the entire CPU budget rests on remains completely unvalidated. That is next step (2), the decoder skeleton, and it is untouched. Reproduce: ``` python3 tools/bench/prep_frame.py tmp/frame.bin 0 cd tmp && SDL_VIDEODRIVER=dummy mame x68000 -bios ipl10 -video soft -window \ -sound none -nothrottle -plugins -autoboot_script ../tools/bench/show_frame.lua \ -snapshot_directory ./snap -snapview native -seconds_to_run 6 ``` ### 22.1 The blocker: CRTC R20 bit 11 hides the graphics layer The IPL leaves **CRTC R20 (`$E80028`) = `0x0B16`**. Bit 11 is *"G-VRAM set to buffer"*, and MAME's `x68k_v.cpp` bails out of `draw_gfx()` on it outright: ```c if (m_crtc->gfx_layer_buffer()) // if graphic layers are set to buffer, they aren't visible return false; // x68k_crtc.h: bool gfx_layer_buffer() const { return BIT(m_reg[20], 11); } ``` While that bit is set, GVRAM writes still land and read back correctly — which is exactly what makes it so misleading. Six separate attempts at the video controller (`$E82400/$E82500/$E82600`) rendered black with every register reading back the intended value. **The video controller was never the problem.** `R20` bits 9-8 select the colour setup, and this determines how `$C00000` is decoded: `0x0300` = 65536c (16 bits/word), `0x0100` = 256c (low byte), `0x0000` = 16c (4 bits). Set `R20 = 0x0116` for our mode. ### 22.2 Monitor contrast: the IPL leaves it at 14, not 15 `$E8E001` bits 3-0 are monitor contrast; MAME does `m_screen->set_brightness(contrast * 0x11)`. The IPL leaves it at **14**, which scales all output to 14/15 = 93.3%. Every rendered colour came out ~7% dark until this was set to 15. **The player must write `$E8E001 = 15` at startup.** Contrast `0` blanks the screen entirely (`x68k_v.cpp:661`) — that is the cheap fade-to-black for scene transitions, no palette animation required. ### 22.3 Palette format CONFIRMED (was previously an assumption) `PALETTE(config, m_gfxpalette).set_format(2, &x68k_state::GGGGGRRRRRBBBBBI, 256)` ``` bit 15..11 10..6 5..1 0 GGGGG RRRRR BBBBB I <- I is a shared LSB for all three channels ``` Expansion is `pal6bit((field << 1) | I)`, i.e. `(v << 2) | (v >> 4)`. With contrast at 15, **all 256 entries render exactly as this predicts** — the frame is pixel-identical, not merely close. GVRAM line stride is confirmed as 512 words = 1024 bytes, matching `HARDWARE.md`. ### 22.4 A new quality ceiling: the 15-bit palette costs 38.88 dB > **Superseded by 23.3.** The 38.88 dB figure assumed the shared LSB `I` is > always 1. Choosing `I` per palette entry by minimum error lifts the ceiling to > **40.81 dB** on the same frame. The conclusion below ("`scsi` is close to > display-transparent") is therefore weaker than stated — there is ~2 dB more > headroom than this section claims. Section 3 called the 256-colour palettised frame "the real quality ceiling". That was measured in 24-bit RGB. The hardware palette only stores 5 bits per channel plus a shared LSB, so there is a **second** quantisation below it: | stage | PSNR | |---|---| | 24-bit palettised source -> X68000 15-bit+I display | **38.88 dB** | | `scsi` profile codec error (00020, FINDINGS 15) | 39.4 dB | The codec's error at `scsi` is **the same order as the display's own error**. On real hardware `scsi` is therefore close to display-transparent, and pushing `lam` below 10 buys quality the monitor cannot show. This bounds how much the `scsi` profile is worth raising — it does not change the profiles themselves. Caveat: measured on one frame (00020 f0001). It is a property of the palette, not the content, so it should generalise, but it has not been checked across scenes. ### 22.5 Why the first frame appears twice GVRAM is a 512-pixel-wide page while the IPL's CRTC is still in its 768-wide text timing, so the layer repeats at exactly x=512. This is correct hardware behaviour, not a bug. The player sets its own CRTC mode and the wrap disappears. No CRTC timing table has been written yet — the harness deliberately keeps the IPL's timing so that no invented CRTC values are in play. ## 23. A real CRTC mode: 256x192 inside 256x256 (session 4) Session 3's harness borrowed the IPL's 768x512 text timing and invented no CRTC values, which is why the frame repeated at x=512 (22.5). This session derived a real 256x256 mode table from MAME 0.277 source and verified it by snapshot. Table: `tools/bench/crtc_mode.lua`. Regression test: `tools/bench/verify_frame256.py`. ![256x256 mode](images/x68k_256x256_mode.png) *Left: palettised source. Right: the emulated X68000's native 256x512 raster — 256 dots wide, 512 scanlines carrying 256 double-scanned graphics rows, with the 192-row picture letterboxed in true black.* ### 23.1 The table, and why it needed no guessing `refresh_mode()` in `x68k_crtc.cpp` selects the dot clock as `(reg20 bit4 ? 69.55199MHz : 38.86363MHz) / div`, with `div` from a ladder keyed on `reg20 & 0x1f`. Three entries matter: | `reg20 & 0x1f` | div | dot clock | mode | |---|---|---|---| | `0x16` | 2 | 34.776 MHz | IPL's 768 wide, 31.5kHz | | `0x11` | 3 | 23.184 MHz | 512 wide, 31.5kHz | | `0x10` | 6 | 11.592 MHz | **256 wide, 31.5kHz, graphics double-scanned** | The IPL's `R00 = 137` gives `m_htotal = (137+1)*8 = 1104` dots, and `34.776e6 / 1104 = 31500.0 Hz` **exactly**. Holding the same line rate at div 6 needs `11.592e6 / 31500 = 368` dots `= 46` chars, so `R00 = 45`. `368 = 1104/3` exactly, so every horizontal register is the 768-mode value divided by three, and the active window divides without remainder: `(124-28)/3 = 32` chars `= 256` dots. **No horizontal value was recalled or estimated.** Only the blanking split rounds: the 768 mode is sync/back/front = 14/14/14 chars, `/3 = 4.67` each, and the closest integer triple summing to `46-32 = 14` is 5/5/4. | reg | value | meaning | |---|---|---| | R00 | 45 | H total, 46 chars = 368 dots -> 31500.0 Hz | | R01 | 5 | H sync end (3.45 us) | | R02 | 10 | H display begin -> `hbegin = 81` | | R03 | 42 | H display end -> `hend = 336`; inclusive width `336-81+1 = 256` | | R04 | 567 | V total, 568 scanlines -> 55.46 Hz | | R05 | 5 | V sync end | | R06 | 40 | V display begin -> `vbegin = 41` | | R07 | 552 | V display end -> 512 scanlines = 256 double-scanned rows | | R08 | 27 | H sync adjust (MAME stores it and never reads it) | | R20 | `0x0110` | display (not buffer), 256-colour, 31.5kHz, 256x256 | **The vertical registers are NOT halved**, which is the one thing that looks wrong and is not. The CRTC still generates a 568-line raster; "256 lines" is a graphics-layer double-scan applied in `draw_gfx()` (`x68k_v.cpp:401`), not a change to the raster. Halving R04 would ask the monitor for 110 Hz. MAME emits a `visarea larger then reg[20]` logerror for this; it is cosmetic. Total blanking time is identical to the 768 mode (112 dots at 11.592 MHz = 336 dots at 34.776 MHz = 9.66 us), which is the property a real monitor cares about — so this table should be safe on hardware, though that is untested. ### 23.2 MAME's double-scan is phase-shifted by one raster line `get_gfx_pixel()` indexes `m_gfxbitmap.pix(scanline / divisor, pixel)` using the **absolute** scanline, and `vbegin = 41` is odd. So in the native 256x512 snapshot the identical row pairs are `(1,2), (3,4), ...` and row 0 is a lone half-line. Even rows are graphics rows 0..255. This cost a false failure before it was understood; the regression test now asserts the shifted pairing explicitly so a change in MAME's behaviour is visible rather than confusing. ### 23.3 The shared LSB `I` must be chosen per palette entry — worth 1.96 dB Session 3's `pack()` hardcoded `I = 1`. That is not free: `I` is shared by all three channels and each renders as `pal6bit((field << 1) | I)`, so with `I = 1` the darkest reachable value is `pal6bit(1) = 4`, and **true black does not exist**. Choosing `I` per entry to minimise summed squared error over R,G,B: | rule | ceiling vs 24-bit palettised (00020 f0001) | entries with I=0 | |---|---|---| | `I = 1` fixed (session 3) | 38.85 dB | 0 | | `I` per entry, min squared error | **40.81 dB** | 102 / 256 | Nearly **2 dB for free**, and 102 of 256 entries want `I = 0` — this is not a corner case. It supersedes the ceiling in 22.4 and means `scsi` has about 2 dB more headroom before it hits the display than that section claimed. The encoder does not yet do this. `tools/encoder/` still emits 24-bit palettes and the packing happens Lua-side; whatever eventually writes X68000 palette words must use the per-entry rule. ### 23.4 Letterboxing requires a reserved black palette entry GVRAM cleared to zero displays **palette entry 0**, and a free mediancut palette puts a real image colour there — on 00020 f0001 it was `(206,192,176)`, used by 210 image pixels, so it cannot simply be repurposed. A 256x192 picture in a 256x256 mode has 64 blank rows, so the palette must be built with **255 colours plus a reserved black at index 0** (`prep_frame.py --reserve-black`). Combined with 23.3, entry 0 also needs `I = 0` or the bars sit at RGB (4,4,4). Cost: one of 256 entries. Measured quality effect: none visible — the ceiling figure in 23.3 is already measured on the 255-colour palette. ### 23.5 What is still not proven GVRAM was again filled from Lua. **No 68000 instruction has drawn a pixel yet**, and the 38% full-frame blit estimate underpinning the CPU budget remains unvalidated. What this section adds is that the *target mode* is now real, so 68000 code has a defined geometry to write into: 256 words per visible row, a 1024-byte line stride, and rows 32..223 of a 256-row page. --- ## 24. The blit, measured on the 68000 — the 38% estimate was wrong (session 5) **The first 68000 instructions in this project to draw a pixel.** Everything in 22 and 23 was GVRAM filled from Lua, which costs zero 68000 cycles. This section replaces the estimate that the whole CPU budget rested on with a measurement. Harness: `tools/bench/blit.s` + `tools/bench/blit.lua`. Four variants of a full-frame 256x192 paint, each looped to run ~4 emulated seconds, timed from `machine.time` between two flag writes by the 68000 itself. | variant | what it does | cycles/frame | % of a 12fps frame | |---|---|---:|---:| | **V1** | `movem.l` blit from a word-expanded RAM frame (96KB read + 96KB write) | **446,286** | **53.6%** | | V2 | naive `move.b`/`move.w` per pixel from a byte source | 1,284,174 | 154.1% | | **V3** | write-only floor — registers preloaded, no source read at all | **225,789** | **27.1%** | | **V4** | the same 96KB of writes issued in **4x4 block order** | **637,971** | **76.6%** | The 12fps budget is 833,333 cycles (10.0 MHz confirmed from `x68k.cpp:1133`, `40_MHz_XTAL / 4`). ### 24.1 The numbers are cross-checked against hand-derived cycle counts Every variant was predicted from the MC68000 timing tables *before* the run (`MOVEM.L` M->R `(An)+` = 12+8n, `(d16,An)` = 16+8n; R->M `(An)` = 8+8n, `(d16,An)` = 12+8n) and then measured: | | predicted | measured | error | |---|---:|---:|---:| | V1 | 447,744 | 446,286 | 0.33% | | V2 | 1,284,096 | 1,284,174 | 0.006% | | V3 | 225,792 | 225,789 | 0.001% | | V4 | 640,704 | 637,971 | 0.43% | This agreement is the point. A MAME timing number on its own would be worth little given how many false-good results this project has produced (FINDINGS 4); two independent derivations landing within half a percent is worth something. The residual error is the frame-granularity of the measurement — Lua gets no cycle counter (`luaengine.cpp` exposes `machine.time` and nothing from `device_execute_interface`), so timing resolution is one video frame, 18.03 ms. ### 24.2 SCOPE: these are instruction cycles, and therefore a LOWER BOUND MAME's `gvram_w`/`gvram_r` (`x68k_crtc.cpp:501,595`) contain **no timing at all** — no wait states, no `adjust_icount`. GVRAM in MAME is as fast as main RAM. Real X68000 GVRAM stalls the CPU on access, so every figure above is a floor, not a prediction. **Do not quote these as hardware numbers.** Interrupts were masked (`SR = $2700`) so the IPL's timer and VBL handlers could not steal cycles into the measurement; a real player will take interrupts on top. ### 24.3 The 38% estimate is dead — a full-frame blit is 53.6% The realistic "decode into a RAM frame, then blit it" design costs **53.6% of the frame budget before decoding a single block**, and that is the zero-wait- state floor. The estimate the CPU budget has been carrying since session 1 was 38%. It was optimistic by 41%. The cause is visible in the V1/V3 gap: **reading the source frame is exactly half the total cost** (221,952 of 446,286 cycles). The 68000 pays 8 cycles per longword read and 8 per longword written, and in 256-colour mode a pixel occupies a whole word of address space, so a frame is 96KB of traffic in each direction rather than 48KB. ### 24.4 The high byte of every GVRAM write is discarded — confirmed from source `gvram_w` case `0x0100` writes `data & 0x00ff` with `mem_mask 0x00ff`. So in 256-colour mode the CPU cannot pack two pixels into one word, and the odd bytes of a word-expanded source frame never need clearing — V1 exploits this by leaving them uninitialised. This is why 96KB, not 48KB, is the irreducible write traffic. ### 24.5 The architecture question, and where it turns over > **Superseded by FINDINGS 28.1/28.2 (session 7).** The two-path plan below is > incoherent — the compose path needs a RAM reference the direct path never > writes — and its two costs are both *copies*, so they were never comparable to > a decode. The "76.6% x non-SKIP fraction" model is also 2.03x optimistic: > the four block modes cost 300/448/400 cycles, not one figure. One path ships. V4 prices the access pattern a decoder that writes codewords **straight into GVRAM** actually has: 4 rows of 8 bytes at a 1024-byte stride per 4x4 block. The same 96KB of writes costs **76.6%** in block order versus 53.6% row-linear — the stride destroys the `movem.l` burst, 208 cycles per block against a theoretical best of ~150. But a decoder never writes every block: SKIP blocks cost **nothing at all**, and the previous frame is already sitting in GVRAM, so **no RAM reference frame is needed for SKIP to work**. So the two designs scale differently: - **compose-in-RAM then blit** — flat 53.6%, independent of how much changed - **decode-direct-to-GVRAM** — 76.6% x (fraction of non-SKIP blocks) **They cross at 70% of blocks changed.** Below that, writing straight into GVRAM wins, and it also drops the 96KB RAM reference frame entirely. Above it, the flat blit wins. **This makes the non-SKIP block fraction the single most important unmeasured number in the project.** It is already computable from the encoder — it is a by-product of the mode decision in `vq_hybrid.py` — and it has never been reported. Measure it before writing any decoder inner loop, because it selects which inner loop to write. ### 24.6 The frame the 68000 drew is pixel-exact V1's output was snapshotted and passes `verify_frame256.py` unchanged: `256x512 native, double-scan exact, active 256x192 pixel-exact, letterbox true black`, 40.81 dB. So 68000 code drives the mode of FINDINGS 23 correctly, and 23.5 is now closed. --- ## 25. The sustained action sequence, found and measured (session 5) STATUS has carried "a *sustained* action sequence is the one thing that could still break the bitrate" as the open risk since session 2. Every clip measured before this was 1.2-1.7 s. This section closes it: **it does break the profiles, though not the bus.** ### 25.1 The two largest streams on the disc are not game footage A survey that sorts 224 streams by size and encodes the biggest would have measured **live action**: | stream | size | what it actually is | |---|---:|---| | 00216 | 3777 MB | the feature with a **burned-in picture-in-picture commentary** | | 00215 | 3475 MB | the commentary itself, full-screen live action | | **00223** | **1802 MB** | **clean animation, 9.4 min — the one to use** | The PiP in 00216 is burned into video stream 0, not a selectable secondary stream, so there is no ffmpeg flag that recovers a clean frame from it. This extends FINDINGS 13's menu-vs-content warning: the classification needed is **content / menu / bonus**, and bonus material is the one that looks most like content by every cheap metric (size, duration, bitrate). ### 25.2 Picking the worst window by measurement, not by eye `tools/analysis/07_motion_survey.py` scans a whole stream at 96x72 and reports the highest-mean sliding window of inter-frame absolute difference. On 00223: ``` 6793 frames @12fps = 566.1s motion energy mean 9.40 median 5.60 p90 21.70 max 112.39 hottest sustained 10s window: t = 539.4s (2.01x stream mean) quietest 10s window: t = 144.2s (0.19x stream mean) ``` The 10.6x spread between the quietest and hottest sustained windows is the whole argument for not sampling clips by hand. `t = 539.4s` is the Singe endgame. ### 25.3 Both profiles overshoot on that window — rate control is now required Encoding those 120 frames at the shipping profiles, with the fixed `lam` the CLI currently uses: | profile | target | measured | overshoot | PSNR | palette ceiling | |---|---:|---:|---:|---:|---:| | `sasi` | 110 KB/s | **129.6 KB/s** | **+18%** | 27.82 dB | 31.33 dB | | `scsi` | 280 KB/s | **373.8 KB/s** | **+34%** | 30.81 dB | 31.33 dB | | *(00020 baseline, `sasi`)* | 110 KB/s | 108.0 KB/s | -2% | 36.94 dB | 39.90 dB | **This reclassifies rate control from insurance to a requirement.** STATUS has had "wire rate control into `encode.py`" at priority 3-4 since session 2 with the note "no longer a blocker (FINDINGS 21)". That was true of the clips measured then. It is not true of this one. `ratectl.encode_rate_controlled()` already exists and builds a per-frame lam ladder; it has simply never been hooked up. Note what did **not** break: 373.8 + 7.8 = 381.6 KB/s is still under the 488 KB/s working figure, so FINDINGS 21's ring-buffer conclusion survives — but at 78% of the pipe sustained over ten seconds rather than the comfortable margin implied by 1.7 s clips. ### 25.4 The palette ceiling is content-dependent, and on hard content it binds The 256-colour scene palette costs **31.33 dB** on this window against **39.90 dB** on 00020 — 8.6 dB worse. Fire, lava and smoke gradients are exactly what a 256-entry mediancut palette handles worst. This inverts an assumption the project has been carrying. FINDINGS 23.3 put the X68000 display ceiling at 40.81 dB and treated it as comfortably clear of the codec's own error. On this content the **scene palette (31.33 dB), not the display hardware (40.81 dB), is the binding constraint** — and `scsi` is already within 0.51 dB of it. Spending bits to close that last half-dB is spending them against a ceiling that is not the display's. ### 25.5 `scsi` collapses to RAW under stress Mode distribution on this window is qualitatively different from anything measured before: | profile | SKIP | V1 | V4 | RAW | |---|---:|---:|---:|---:| | `sasi` (lam=60) | 45.6% | 16.3% | 24.2% | 13.9% | | `scsi` (lam=10) | 26.2% | 5.5% | 7.1% | **61.2%** | | *00020, `sasi`* | 46.9% | 24.1% | 17.8% | 11.2% | At `lam=10` the rate-distortion decision finds literal pixels cheaper than any codeword for 61% of blocks — the codebooks are simply not describing this content. That is the mechanism behind the +34% overshoot in 25.3, and it is a rate-control problem, not a codec-structure problem: the RD decision is behaving correctly for the lam it was given. ### 25.6 The decoder needs BOTH display paths, chosen per frame > **Superseded by FINDINGS 28.1 (session 7).** Mixing the paths displays stale > pixels on 70 of these 120 frames. The "median 37.0%, capped at 53.6%" below is > the cost of an incorrect player; every coherent version is dearer, and plain > direct-to-GVRAM is the cheapest of them. Applying FINDINGS 24.5's crossover to the real per-frame distribution: | | median non-SKIP | p90 | frames over the 70% crossover | |---|---:|---:|---:| | `sasi`, Singe window | 48.4% | 82.8% | 36 / 120 (30%) | | `scsi`, Singe window | 70.8% | 92.4% | 64 / 120 (53%) | | `sasi`, 00020 | 54.0% | 88.8% | 3 / 14 (21%) | Neither path wins outright: **30-53% of frames want the flat blit and the rest want direct-to-GVRAM.** A player that implements both and picks per frame — the mode headers are parsed before any pixel is written, so the count is free — pays a median of **37.0%** of the frame budget and is capped at **53.6%**. A player that implements only direct-to-GVRAM pays up to 76.6% and would miss frames on the scene cuts. So the answer to 24.5 is "both", and the selection is a one-line comparison against a block count the decoder already has in hand. ### 25.7 What this does not measure One 10 s window of one stream, at fixed lam, with `_paint` still a Python loop. The full-disc survey is still not done, and the numbers above are the *worst* window rather than a distribution over content. What has changed is that the worst case is now a measurement rather than a worry. --- ## 26. Rate control is unsound as written — found before wiring it up (session 5) FINDINGS 25.3 promoted rate control from insurance to a requirement. Reading `ratectl.py` before wiring it into `encode.py` turned up a correctness bug that would have produced exactly the kind of plausible-looking wrong result this project keeps catching (FINDINGS 4, 9, 14, 18). ### 26.1 The lam ladder desynchronises the encoder from the decoder `H.encode()` is **temporally recursive**: SKIP blocks are copied from the previous *reconstruction*, and `prev = out` closes the loop (`vq_hybrid.py:84-109`). A frame's output therefore depends on every frame before it in that same run. `encode_rate_controlled()` runs `H.encode()` once per lam over the **whole sequence**, building a ladder of independent temporal chains, then picks each frame from whichever rung fits the budget. When frame *f* comes from rung *i* and frame *f-1* was emitted from rung *j != i*, the SKIP blocks in *f* reference a reconstruction **the decoder never saw**. Measured on the Singe window (`tools/analysis/09_ratectl_drift.py`, 120 frames, 5 rungs, target 110 KB/s): | | | |---|---| | rung switches | **67** over 120 frames | | frames whose emitted output differs from what the encoder recorded | **111 / 120** | | worst frame | **21,339 px = 43.4% of the frame** | | encoder-vs-decoder agreement, worst frame | 27.1 dB | | reported PSNR overstatement | **0.36 dB** | The 0.36 dB is the least interesting number here. The encoder is reporting quality for a reconstruction that will never exist, and 43% of a frame differing is a visible artefact whatever the mean says. **The fix is structural, not a tuning change:** `H.encode()` must become frame-drivable — take `prev` and one lam, return one frame — so rate control can feed back the frame it actually emitted. The current whole-sequence signature is what makes the ladder tempting in the first place. ### 26.2 The ladder spans 250x past the shippable range `lam_hi=2e5`, but FINDINGS 15 puts the quality cliff between lam=800 and lam=2000 and says do not ship past lam~800. Every rung above ~800 is unshippable, so a frame that only fits at lam=9457 has not been rate-controlled, it has been destroyed. Cap `lam_hi` at 800 and let a frame that cannot fit overrun the bucket — a visible overrun is a better failure than silent garbage. ### 26.3 The ladder is far too coarse where it matters With `steps=5` the geomspace lands on 1 / 21 / 447 / 9457 / 200000, and **only two rungs were ever chosen**. The budget is 8,721 B/frame; the two straddling rungs deliver 23,183 B (lam=21) and 3,071 B (lam=447) — a **7.5x** gap across the operating point. Rate control cannot land near a target it has to jump over. The module docstring already describes the right approach — *"per frame we binary-search lam to land inside a byte budget"* — but the implementation is a fixed precomputed ladder. Doc and code disagree; the doc is correct. ### 26.4 What does work The leaky bucket lands the mean where it should: **109.1 KB/s against a 110 target**, with 32% of frames over the per-frame budget and banked by the bucket. That mechanism is sound and worth keeping. It is the per-frame lam *selection* underneath it that needs rebuilding, not the bucket. ### 26.5 Cost note before starting Each rung is a full-sequence encode and `_paint` is still a Python per-block loop, so a 5-rung run over 120 frames takes minutes. **Vectorise `_paint` first** — it is already on the list for the full-disc survey and it makes the rate-control work practical rather than merely faster. ## 27. Rate control, rebuilt and wired in (session 6) FINDINGS 26 stopped the session-5 rate controller before it shipped: it picked frames out of independently-encoded whole-sequence runs, so 111 of 120 frames referenced reconstructions the decoder would never see. The fix was structural, as 26.1 said it had to be. It is now wired into `encode.py` and **on by default** for a profile. ### 27.1 The encoder is frame-drivable, and the drift is zero by construction `vq_hybrid` now exposes one frame at a time — `frame_ctx(m, f, prev)` / `decide(ctx, lam)` / `paint(m, ctx, mode)` — and `encode()` is a thin loop over that API. Rate control drives the same three calls and feeds back **the frame it actually emitted** as the next frame's `prev`. There is no ladder to pick from, so the desync has no way to occur. `tools/analysis/09_ratectl_drift.py`, unchanged in what it asserts: | | session 5 | session 6 | |---|---|---| | frames whose emitted output differs from what the encoder recorded | 111 / 120 | **0 / 120** | | worst frame | 21,339 px (43.4%) | **0 px** | | reported PSNR overstatement | 0.36 dB | **0.00 dB** | This is the harder case for that test on purpose: it runs with `lam_lo=1.0`, so lam moves on 117 of 119 frame boundaries. Under the old ladder, 67 rung switches were enough to corrupt 111 frames. ### 27.2 Both overshoots are closed, and they cost under 1 dB The Singe window (FINDINGS 25.3), which is the worst sustained window on the disc. Totals include the 7.8 KB/s ADPCM allowance: | profile | target | fixed lam (session 5) | rate-controlled | quality cost | |---|---|---|---|---| | `sasi` | 110 KB/s | 137.4 KB/s (**+25%**) | **109.5 KB/s** | 27.82 → 27.22 dB (−0.60) | | `scsi` | 280 KB/s | 381.6 KB/s (**+36%**) | **280.0 KB/s** | 30.81 → 29.90 dB (−0.91) | Zero frames hit the lam=800 cliff at either profile, so nothing was destroyed to get there (26.2's failure mode did not trigger). `sasi` needed lam to reach 183 at worst against a floor of 60; `scsi` reached 58.7 against 10. The controller is working an order of magnitude below the cliff, which is where the search range being capped at 800 rather than 2e5 stops mattering at all — and that is the point: a range that never needs its top is a range you can trust. `scsi` still sits **1.43 dB** from the scene palette ceiling of 31.33 dB (FINDINGS 25.4), against 0.51 dB before. The ceiling, not the codec, is still what bounds this content. The percentages differ from 25.3's +18%/+34% because those compared video payload against the total target; the table above compares like with like (total against total). The payload figures are unchanged: 129.6 and 373.8 KB/s. ### 27.3 Rate control makes the display path cheaper, not dearer The decoder-architecture numbers of FINDINGS 25.6 were measured on the fixed-lam encoder. Re-measured under rate control, on the same window, with the player picking the cheaper of compose-then-blit and direct-to-GVRAM per frame: | profile | median display cost | frames above the 70% crossover | |---|---|---| | `sasi` fixed → RC | 37.0% → **36.6%** | 30.0% → 26.7% | | `scsi` fixed → RC | 53.6% → **47.1%** | 53.3% → 35.8% | Raising lam moves blocks to SKIP and V1, which is fewer blocks to write. The "implement both paths, pick per frame" conclusion is unaffected and the cap is still 53.6%. ### 27.4 The quality floor barely matters; the prefill matters, wrongly Two knobs were measured rather than guessed. **`--rc-floor`** decides whether a quiet frame may spend more than the fixed-lam profile would. On the Singe window it is worth nothing — 109.5 vs 110.0 KB/s and **0.00 dB** — because no frame on that window is quiet enough for the bucket to saturate. The default is `profile` (never spend more than session 5 would), so rate control cannot regress content that already fits. **`--prefill`** models how full the player's buffer is at scene start. It is tempting and it is a trap, so it defaults to 0: | clip | prefill 0.0 | 0.5 | 1.0 | target | |---|---|---|---|---| | Singe, 120 fr, `sasi` | 109.5 | 112.9 | **116.3** | 110 | | Singe, 120 fr, `scsi` | 280.0 | 289.1 | **298.2** | 280 | | 00020, 14 fr, `sasi` | 92.0 | **115.8** | **115.8** | 110 | | 00020, 14 fr, `scsi` | 224.8 | **255.9** | **255.9** | 280 | (`scsi` on 00020 is the one cell where prefill looks harmless: the clip fits under 280 either way. That is the content being easy, not the knob being safe.) Prefill buys a permission to overshoot of exactly `bucket / nframes`. At 8 frames of bucket over 120 frames that is 6.2% — measured — and on a 14-frame clip the bucket is larger than the clip, so rate control switches itself off and reproduces fixed-lam exactly (lam never leaves its floor: min = median = max = 60). **A prefill that makes a target look met has disabled the controller.** ### 27.5 The 00020 undershoot is a clip-length artefact, not a bug At prefill 0 the 14-frame 00020 clip lands at 92.0 KB/s against a 110 ceiling — 0.66 dB given away for nothing. That is the leaky bucket's startup transient: the first `bucket_frames` frames cannot draw on a bank they have not accumulated. It is bounded by `bucket / nframes`, so it is 6% on a 10-second window and 20% on a 1.2-second one. The lesson is the one FINDINGS 25.3 already taught in a different costume: **a 1.2-second clip cannot be used to judge rate control.** Real scenes are tens of seconds. Do not tune the bucket against 00020. Worth recording separately: fixed-lam `sasi` on 00020 delivers 115.8 KB/s — the supposedly easy clip was **already 5% over its target**, which nothing had noticed because the profile table quotes its PSNR and not its bitrate. ### 27.6 FINDINGS 26.5's cost premise was wrong in both halves 26.5 said a rate-control experiment was minutes because `_paint` is a Python per-block loop, and told the next session to vectorise it first. Vectorising it was correct and it is **17.1x faster**, but it was never the bottleneck, and the ladder was never minutes. Measured per frame, 256x192: | | ms | |---|---| | `VQ.assign` x2 — codeword search | **22.83** | | SKIP error against `prev` | 1.40 | | `decide` — argmin at one lam | 0.06 | | `paint`, vectorised | 0.29 | | `paint`, old per-block loop | 4.93 | `_paint` was 14% of a frame. A 5-rung ladder over 120 frames was ~18 s of encoding, not minutes — the "few minutes" in the drift test's docstring was `H.build`'s k-means (51 s), which no amount of vectorising `_paint` would have touched. What actually makes per-frame rate control affordable is that `VQ.assign`'s output depends on **neither `lam` nor `prev`**, so it is computed once per frame and a lam search only re-runs the 0.06 ms argmin: | | | |---|---| | 12-step per-frame lam search, 120 frames, symbols cached | **0.31 s** | | the same search by re-running whole-sequence encodes | 49.10 s | That is a 158x difference, and it is the reason the controller can afford a real bisection instead of a 5-rung ladder — which was the actual defect in 26.3. The cache holds **one frame**. At ~133 KB of intermediates per frame, caching the sequence would cost 900 MB on a 9.4-minute stream to save nothing: every caller works a frame at a time. --- ## 28. The 68000 decoder exists, is pixel-exact, and does not fit (session 7) `src/player/decode.s` parses DLX1 and draws frames on the emulated X68000. It is **pixel-exact across a 120-frame sequential run** of the worst sustained window on the disc (`tools/bench/verify_decode.py`), exercising all four block modes and the full temporal recursion — the last frame is only right if every frame before it was. It is also **too slow**. On that window, at the shipping `sasi` profile: | | non-SKIP blocks | measured cost | |---|---:|---:| | cheapest frame | 15.4% | 31.5% of a 12fps frame | | median frame | 47.8% | 73.8% | | p90 frame | 82.5% | **116.4%** | | worst frame | 100.0% | **135.8%** | | mean over the window | 47.8% | **81.7%** | **31% of frames miss the 833,333-cycle budget**, and like every figure since FINDINGS 24 these are instruction cycles against zero-wait-state memory, so they are a floor. This is the first time CPU, not disk, is the binding constraint — FINDINGS 21 retired the bandwidth worry, and this replaces it. ### 28.1 The dual-path plan of 24.5/25.6 was incoherent, and is withdrawn FINDINGS 24.5 specified two display paths chosen per frame on the non-SKIP count, and 25.6 costed the mix at "median 37.0%, capped at 53.6%". Two of its premises cannot both hold: - compose-in-RAM-then-blit exists to make the blit **row-linear**, so it must assemble a **full** frame in RAM. The pixels it does not decode this frame — the SKIP blocks — can only come from a RAM copy of the previous reconstruction. - decode-direct-to-GVRAM's stated advantage is that **"no RAM reference frame is needed"**, because the previous frame is already in GVRAM. So every direct frame silently invalidates the reference the next compose frame reads. Simulated on the Singe window at the crossover the plan specifies (`tools/analysis/10_pathmix_drift.py`): **70 of 120 frames display pixels no correct player would display**, first at frame 2, worst frame 18.8% of the screen. This is FINDINGS 26 in different clothing — two code paths disagreeing about what "the previous frame" means — and it is the **sixth** false premise this project has caught before it shipped. Every coherent repair is worse than not mixing at all: | strategy | median | p90 | max | correct | |---|---:|---:|---:|---| | mix per frame, as specified | 36.6% | 53.6% | 53.6% | **no** | | mix, direct also writes the RAM reference | 53.6% | 68.4% | 81.4% | yes | | mix, re-read GVRAM into RAM on each switch | 36.6% | 107.2% | 107.2% | yes, 13 frames miss | | compose only | 53.6% | 53.6% | 53.6% | yes | | **direct only** | **36.6%** | 62.5% | 76.6% | yes | (Costs in that table are 24.5's own model, for like-for-like comparison; 28.2 replaces the model itself.) **24.5 also compared the wrong two things.** Its 53.6% and 76.6% are both *copies* measured in `blit.s` — neither includes decoding. A real compose path costs decode-into-RAM **plus** the 53.6% blit, so it is strictly dearer than decoding straight into GVRAM, whatever the block mix. There was never a crossover to find. **The decoder therefore implements one path, direct-to-GVRAM**, and drops the 96 KB RAM reference frame entirely. ### 28.2 The four block modes do not cost the same, and V4 is the expensive one 24.5's model — "76.6% of a frame x the non-SKIP fraction" — prices every non-SKIP block as one `movem.l` burst. Measured separately, with synthetic single-mode frames (`tools/bench/prep_dlx.py`): | mode | cycles/block | vs the 24.5 model (207.8) | |---|---:|---:| | SKIP, in an all-SKIP header byte | 13.3 | model says 0 | | SKIP, inside a mixed byte | ~45 | model says 0 | | V1 (one 4x4 codeword) | **299.9** | 1.44x | | V4 (four 2x2 codewords) | **448.2** | 2.16x | | RAW (16 literal indices) | **400.4** | 1.93x | Applied to the real per-frame histograms (`tools/analysis/11_cpu_budget.py`), the model reproduces all four frames timed on the 68000 to within **1 percentage point**, and shows 24.5 to be **2.03x optimistic at the median**. Where the cycles actually go over the window: | mode | % of blocks | % of cycles | |---|---:|---:| | SKIP | 46.4% | 9.2% | | V1 | 19.8% | 26.1% | | V4 | **25.2%** | **49.7%** | | RAW | 8.5% | 15.0% | **V4 is a quarter of the blocks and half the cycles.** It costs 1.49x a V1 block while the mode decision in `vq_hybrid.py` charges it only its 4x payload bytes. The lagrangian trades distortion against *bytes*; on this machine it now has to trade distortion against *cycles* as well. ### 28.3 The container is big-endian but not aligned, and that is an address error The DLX1 header docstring says every multi-byte field is big-endian "so the 68000 reads them with a plain `move`". Alignment is the other half of that sentence and the container does not have it: frame records are `[u32 length][768-byte mode header][payload]` laid end to end with arbitrary payload lengths, so record boundaries land on odd addresses. `move.l (a0)+,d0` at an odd address is an **address error** on a 68000 — not a slow read. The first run decoded frame 0 perfectly, consumed exactly its 8,715 payload bytes, then read frame 1's length at `$03220F` and vectored into the IPL at `$FF059A`, where it sat for 59 emulated seconds looking like an infinite loop. It was found by dumping PC and the address registers, not by reading the source: the code was correct, the data layout was not. The decoder now rounds each record start up to 4. **The container should carry the padding itself** so a streaming player can DMA records into place: measured cost on this window is **199 bytes over 120 frames — 1.66 B/frame, 20 B/s** against a 110 KB/s budget. Until `encode.py` does it, `prep_dlx.py` realigns at load time. ### 28.4 The measurements agree with hand-derived MC68000 timings As in FINDINGS 24, each figure was derived from the instruction timing tables before being believed. A V1 block, summing dispatch, index decode, the indexed `movem.l` load and four `movem.l` stores, plus its quarter share of the header loop: **298.5 cycles derived against 299.9 measured — 0.5%.** RAW derives to 396 against 400.4 measured (1%). V4 derives to 415 against 448 (7%, the gap being in the indexed two-register `movem.l`, the mode this decoder uses most heavily). So these are 68000 cycles, not a MAME artefact. ### 28.5 A full frame does not fit at 12fps in ANY mode An all-V1 frame — the cheapest possible way to redraw all 3,072 blocks — costs **921,187 cycles, 110.5% of the budget**. All-V4 is 165.2% and all-RAW 147.6%. So the ceiling is structural, not a tuning problem: **at 12fps on a 10MHz 68000 no more than ~88% of the screen can change in one frame**, however cheaply it is coded. Scene cuts change 100% of it. Either a cut gets one late frame (the outgoing content is unrelated, so this may be free to the eye), or cuts have to be spread across two frame times, or the framerate has to come down — at 10fps the budget is 1,000,000 cycles and an all-V1 frame fits. ### 28.6 What this does not measure One 10 s window of one stream at one profile, and MAME still models no GVRAM wait states. The `scsi` profile will be worse: FINDINGS 25.5 has it collapsing to RAW under stress, and RAW is 1.93x the old model's block. Nothing here has been run on `00020` or on quiet content, where the median frame is far cheaper. ### 28.7 The profiles are an I/O axis; the CPU limit is the clock `sasi` and `scsi` are two points on one rate-distortion curve, chosen against **disk bandwidth**. They say nothing about CPU, and the locked target CPU is a stock 10MHz 68000 for both. So both have to fit the same 833,333 cycles: | | sasi | scsi | |---|---:|---:| | stock / Super, 10 MHz | median 74.4%, **31% of frames miss** | median 94.9%, **42% miss** | | XVI, 16.67 MHz | median 44.6%, 0% miss | median 56.9%, 0% miss | Clocks confirmed from MAME 0.277 `x68k.cpp:1133/1194/1200`: `x68000` and `x68ksupr` are **both** `40_MHz_XTAL/4` = 10 MHz, and only `x68kxvi` is faster at `33.33_MHz_XTAL/2`. The Super has SCSI at 10 MHz, so a faster bus does not imply a faster CPU — the XVI column above is headroom, not a target. `sasi` is the cheaper profile, but choosing it is not a fix: it still misses 31% of frames. The cycle ceiling has to be enforced in the encoder either way. **How much of the miss is the encoder's to fix.** Re-coding every non-SKIP block as V1 — the cheapest mode, quality ignored — is the floor any mode assignment can reach: | | frames that miss | recoverable by re-coding | impossible at 12fps | |---|---:|---:|---:| | `sasi` | 37/120 | 26 | **11** (from 89.8% non-SKIP up) | | `scsi` | 51/120 | 39 | **12** (from 91.9% non-SKIP up) | So a cost-aware mode decision can reach about **three quarters** of the misses. The remaining ~10% of frames are 28.5's ceiling in practice: past ~90% non-SKIP no mode assignment fits, because the blocks have to be drawn at all. Those frames need a structural answer — a late frame at a cut, a cut spread over two frame times, or a lower framerate — not a better encoder. ### 28.8 V4 costs more cycles than RAW, so it is CPU-dominated by it 448.2 against 400.4 cycles. RAW is also pixel-exact where V4 is lossy, so V4's only advantage is that it costs 4 payload bytes instead of 16. **On the CPU axis V4 is strictly dominated**, which inverts the mode preference the byte lagrangian has: an encoder short of cycles but not of bytes should buy RAW wherever it would have bought V4, and gain quality doing it. That escape is only open to the byte-rich profile. `scsi` already spends 41.3% of its blocks on RAW (FINDINGS 25.5 saw it "collapse to RAW under stress" and read that as a failure; on the CPU axis it is the cheap direction). `sasi` at 110 KB/s cannot afford it, so its only lever is V4 -> V1 -> SKIP, every step of which costs quality. **The CPU constraint therefore bites harder on `sasi` in quality terms even though it bites less in cycles.** Caveat: this ordering is a property of *this* decoder, not of the codec. V4's cost is four indexed `movem.l` lookups; pairing sub-block rows into `movem.l d0/d2,(a4)` would save ~16 of 448 cycles, which narrows the gap to RAW without closing it. --- ## 29. Trading bytes for cycles: the bus has 4x the headroom the CPU has (session 7) > **ALSO SUPERSEDED IN PART BY 38.** "The bus has 4x the headroom the CPU has" > is about the SCSI pipe. The 68000's LOCAL bus is a different resource and the > decoder occupies 86.7% of it, so trading cycles for bytes is not free in the > currency that turned out to bind. 29.6's DMAC idea is costed in 39. > > **SUPERSEDED IN PART BY 30, which measured it.** The mode survives and the > conclusion holds, but every number in this section moved: a span costs 43.7 > cycles + 9.152/pixel *only* in an encoder-assisted format (the obvious > decoder is 97.9 + 10.46), spans beat V1 from runs of 4 blocks and not 2, and > the re-priced trade-off is 52.0% median / 10 misses, not 43.0% / 8. Read 30's > tables over 29.3's. 29.5's other three items are still open, and 29.6 stands. > > **STATUS AT THE TIME: DERIVED, NOT MEASURED.** No 68000 had executed a span > decoder. The per-pixel figure it rests on *is* measured (FINDINGS 24 V1) but > at full row width; the per-span overhead was hand-derived. FINDINGS 4 is why > it was labelled and then tested rather than believed. FINDINGS 28 leaves the project CPU-bound while the **bus sits 4x idle**: `sasi` spends 110 KB/s of a 488 KB/s pipe. That asymmetry is exploitable, because the codec was designed when bytes were the scarce thing and every one of its decisions trades cycles to save them. ### 29.1 The decoder pays per changed PIXEL; the disk pays per BYTE Per-pixel costs, all measured: | what | cycles/pixel | source | |---|---:|---| | write-only floor (no source read) | 4.59 | FINDINGS 24 V3 | | **row-linear copy from word-expanded RAM** | **9.08** | FINDINGS 24 V1 | | block-order copy, same bytes | 12.98 | FINDINGS 24 V4 | | V1 codebook block | 18.74 | FINDINGS 28.2 | | RAW, byte literals unpacked to words | 25.03 | FINDINGS 28.2 | | naive per-pixel byte expansion | 26.13 | FINDINGS 24 V2 | Two structural facts fall out. **The 1024-byte stride costs 43%** — the same bytes cost 12.98 cycles/px in 4x4 block order against 9.08 row-linear, because the stride breaks the `movem.l` burst. And **unpacking bytes to words costs more than the write itself**: 25.03 against 9.08. So the two cheapest things a decoder can be handed are *word-expanded* pixels in *row-linear runs* — and both cost bytes on disc, which is what we have. ### 29.2 Codebooks are a byte optimisation that now costs cycles A word-expanded literal 4x4 block, `movem.l (a0)+,d0-d7` straight from the stream buffer into GVRAM, derives to **~240 cycles** — cheaper than V1's measured 299.9, and pixel-exact. V1 is dearer *because* it is compressed: it pays an index decode and an indexed `movem.l` that a literal does not, and then does exactly the same four writes. It buys 31 bytes and spends 60 cycles. **Every codebook mode is CPU-dominated by a literal.** V4 was already dominated by RAW (28.8); with word-expanded literals available, so is V1. The VQ codebook earns its place only while bytes are scarce. ### 29.3 Row-linear literal spans, priced against the real mode maps Replace the per-block escape with a per-row **span**: `(x, count, word-expanded pixels)`, decoded with `movem.l` bursts. A run of L horizontally adjacent dirty blocks becomes 4 spans of 4L pixels, deriving to `4 * (50 + 4L * 9.08)` cycles against `300L` for V1 — **cheaper for any run of 2 blocks or more**, at 32 bytes per block instead of 1. Applied greedily (buy the best cycles-saved-per-byte until the bus budget is gone) to the *unchanged* mode maps of the `sasi` Singe window: | | today | + literal spans | |---|---:|---:| | median frame | 74.4% | **43.0%** | | p90 frame | 115.1% | **83.6%** | | worst frame | 136.2% | **106.2%** | | frames missing the budget | **37/120** | **8/120** | | bitrate | 101.7 KB/s | 453.2 KB/s (bus 488) | And the fit is structural rather than lucky: **spans get cheaper exactly where blocks get expensive.** A span amortises its overhead over a long run, and long runs are what a high-change frame is made of. The frames that miss today are the frames spans help most. ### 29.4 This reopens 28.5, which said a scene cut cannot fit 28.5 concluded that no mode assignment fits a 100%-changed frame at 12fps, because the cheapest full redraw available — all-V1 — is 110.5%. That was true of *the mode set the codec has*. Adding a byte-expensive, cycle-cheap mode changes the arithmetic: mixing a fraction `x` of the frame as spans against V1 for the rest, - CPU needs `x >= 0.19` - the 40,977 B/frame bus budget allows `x <= 0.39` **The interval is not empty.** A scene cut fits at 12fps if roughly a quarter to a third of it arrives as word-expanded row-linear literals. 28.5's "structural ceiling" was a ceiling of the bitstream, not of the machine. ### 29.5 What has to be measured before any of this is believed 1. **Span cost on the 68000.** The 50-cycle per-span overhead is derived, and the 9.08 cycles/px is measured at *full row width* with 12-register bursts — a short or oddly-aligned span cannot burst as well, so short spans are flattered here. Extend `tools/bench/blit.s` with a span variant and measure it against run length. **This is the load-bearing number.** 2. **Re-run the ring-buffer simulation at ~450 KB/s.** FINDINGS 21's zero required prefill was established at 110 and 280 KB/s against a 488 KB/s pipe. At 453 the margin is a tenth of what it was, and 21's own caveat was that the test is cumulative — it needs redoing, not extrapolating. 3. **Confirm the 4 Mbps figure**, which is user-supplied with no recorded provenance and which this design would run at 93% of. It has been a "would be nice" since session 1; a design that leans on it makes it load-bearing. 4. **Confirm DMA, not PIO** (STATUS priority 5). At 453 KB/s a PIO fallback puts the transfer cost on the CPU we are trying to relieve. Cheapest check available and now the most consequential. ### 29.6 The other lever, not yet costed: let the DMAC do the copy The X68000 has an HD63450 DMAC (4 channels, `x68k.cpp:1046`). Channel 3 is ADPCM — confirmed, `adpcm_drq_tick` asserts `drq3_w` — but memory-to-memory transfer on a free channel would take the GVRAM copy off the CPU entirely, leaving it only the parsing. This is the one idea here that could move the budget without spending a single extra byte. It cannot be settled in MAME: like the SCSI/SASI devices (BENCHMARK.md), the HD63450 is a functional model, so a timing number out of it would measure the emulator's scheduler. It needs hand-derivation against the datasheet plus real hardware — the same three-tier approach the disk benchmark already documents. ## 30. The span, measured: the mode survives, and it is an encoder format (session 8) FINDINGS 29 priced a new decoder mode at `4 * (50 + 4L*9.08)` cycles and marked the whole section DERIVED. This is the measurement. `tools/bench/blit.s` gained two span variants, `tools/bench/prep_spans.py` generates one stream per span length, `tools/bench/span.lua` times them, and `tools/bench/span.sh` runs the lot, and the whole thing takes about 25 seconds. Same scope as every 68000 figure since FINDINGS 24: instruction cycles against MAME's zero-wait-state GVRAM, interrupts masked. A **lower bound**, not a prediction. ### 30.1 What was measured Twelve `v5` configs and eleven `v6` configs, each cutting the **same** 256x192 frame into spans of a different length, so the work differs only in how finely it is cut. Regressing `cycles = A*spans + B*pixels` over a set reads the per-span overhead and the per-pixel cost straight off. Every config draws the whole picture, the picture is cleared before each run and snapshotted after, and all 23 snapshots are checked pixel-exact by `tools/bench/verify_frame256.py`. A config cannot time fast by writing nothing. | | per span | per pixel | fit error | |---|---:|---:|---:| | **v5** — decoder handed `(x, npix)`, works the copy out | **97.9** | **10.459** | ±1.4%, and only on spans that are a whole number of bursts | | **v6** — encoder hands it an address and a jump | **43.7** | **9.152** | **±0.3% over all 11 lengths** | | *29's assumption* | *50.0* | *9.080* | — | **29's arithmetic was right about a format nobody had written yet.** v6 hits it almost exactly; v5 — the obvious decoder, and the one 29 was describing — is 2.24x dearer per span and 14% dearer per pixel. ### 30.2 Why the difference is a format difference, not an optimisation v5's record is `(x, npix)`, so the decoder computes the destination, divides `npix` into 16-pixel bursts, and handles the 0..15 remainder: about 122 cycles of arithmetic and branching per span before a single pixel moves. All of it is known at encode time. v6's record is `{u32 absolute GVRAM address, u16 jump displacement}` and nothing else. The displacement jumps into an unrolled chain of eleven 24-pixel copy units, so a span of any supported length is straight-line code with no loop, no remainder, and no address arithmetic — `move.l (a0)+,a2` / `move.w (a0)+,d0` / `jmp v6ch(pc,d0.w)`, then `movem.l` pairs. GVRAM is at $C00000 on every X68000, so absolute destinations are a legitimate thing to bake into a stream. Two consequences of that format, both cheap: - **Span lengths are multiples of 24 pixels** and a run pads up to it. The padding costs bytes and its own pixels, nothing else, and it is *correct on screen*: a literal span carries true pixels of the current frame, so painting a clean neighbour is a no-op visually. - **A span may overrun the visible 256 pixels of its row by up to 23.** Free: the line stride is 1024 bytes and only the first 512 are displayed, so the overrun lands in the invisible half of the line. ### 30.3 The remainder path is where a short span actually dies v5's cost per span, measured, against its length: | span | 4 px | 8 px | 12 px | 16 px | 20 px | 24 px | 32 px | |---|---:|---:|---:|---:|---:|---:|---:| | cycles/span | 180.3 | 240.9 | 296.3 | 261.8 | 347.7 | 401.9 | 430.7 | | cycles/pixel | 45.08 | 30.11 | 25.46 | **16.36** | 17.65 | 17.27 | **13.46** | A 12-pixel span costs *more* than a 16-pixel one. Everything below the 16-pixel burst width goes through `move.l`/`move.w` at roughly 10 cycles a pixel plus the per-span overhead, and 29's warning that "short spans are flattered" was correct — but the fix is to pad them up to a burst, not to avoid them. v6 has no remainder path at all, which is most of why its fit is linear to 0.3%. ### 30.4 Registers are the reason the per-pixel cost moved FINDINGS 24's 9.08 cycles/pixel came from a fixed blit with 12 registers free for `movem.l` and no live state. A span decoder keeps a stream pointer, a destination and counters live, so v5 can spare only 8 registers per burst — 32 bytes instead of 48 — and pays 10.46 cycles/pixel for it. v6 gets back to 12 registers precisely because the encoder holds the state instead, and lands at 9.152. **The per-pixel figure is a function of how much the decoder has to remember**, which is not something the FINDINGS 24 measurement could have shown. Two smaller results, both cheap and both worth having on the record: - **Odd-`x` alignment is free.** Spans starting at an odd pixel run their bursts at `addr mod 4 == 2` and cost 259.0 cycles/span against 261.8 aligned — inside the timing granularity. The 68000's 16-bit bus does not care, as expected; now it is measured rather than assumed. - **A full-row span is 154 cycles per 4x4 block**, the floor this mode can reach, against V1's measured 299.9. ### 30.5 Re-pricing: the trade holds, and it is smaller `tools/analysis/12_span_tradeoff.py` now runs on measured constants. Same greedy (buy the best cycles-saved-per-byte until the bus budget is gone), same unmodified mode maps, same Singe window: | | today | 29 (derived) | **30 (measured)** | |---|---:|---:|---:| | `sasi` median frame | 74.4% | 43.0% | **52.0%** | | `sasi` worst frame | 136.2% | 106.2% | **108.7%** | | `sasi` frames missing | 37/120 | 8/120 | **10/120** | | `sasi` bitrate | 101.7 KB/s | 453.2 | **448.0 KB/s** | | `scsi` median frame | 94.9% | 69.4% | **74.6%** | | `scsi` frames missing | 51/120 | 18/120 | **25/120** | And the break-even moved. Cycles per 4x4 block in a run of L blocks, v6, with each of the run's 4 spans padded to a whole 24-pixel unit: | L | 1 | 2 | 4 | 8 | 16 | 64 | |---|---:|---:|---:|---:|---:|---:| | cycles/block | 1053 | 527 | **263** | 242 | 176 | 154 | So a run beats all-V1 (299.9) **from L=4 up**, not from L=2 as 29.3 claimed, and runs of 1-3 blocks all cost the same 1053 cycles because they pad to the same single unit. A cost-aware mode decision should not offer a span below 4 blocks at all. ### 30.6 29.4 survives: a scene cut still fits at 12fps Mixing a fraction `x` of a 100%-changed frame as full-row spans against V1 for the rest, on measured costs (154 cycles and 33.4 bytes per block): - CPU needs `x >= 0.196` - the 40,977 B/frame bus budget allows `x <= 0.373` The interval is not empty — narrower than 29.4's 0.19..0.39, same conclusion. FINDINGS 28.5's "a scene cut cannot fit" was a ceiling of the bitstream, not of the machine, and that now rests on a measurement. `12_span_tradeoff.py` prints this arithmetic and will say so if it ever stops being true. ### 30.7 What this does NOT settle The three remaining items of 29.5 are unchanged and are now **more** load-bearing, because the measured design runs at 448 KB/s of a 488 KB/s pipe rather than 453: re-run the ring-buffer simulation at that rate, confirm the 4 Mbps figure's provenance, and confirm DMA rather than PIO. A PIO fallback would put a 448 KB/s transfer back on the CPU this mode exists to relieve. Also unmeasured: **the parse cost of a span-heavy stream**. Every figure here times the copy. The 68000 also has to read the mode map and dispatch: the re-priced `sasi` stream buys 8773 spans across 120 frames, a mean of 73 a frame, and each one's three-instruction dispatch is inside the fitted 43.7 — but the mode-map walk that decides a span exists is not. `decode.s` does not implement spans yet. ## 31. The mode decision can see cycles now, and it costs 0.26 dB (session 8) FINDINGS 28 left the decoder missing 31% of frames at `sasi` and 42% at `scsi` while the mode decision minimised `D + lam*R` — distortion against BYTES — on a machine whose binding budget is CYCLES. This is the second controller. `vq_hybrid.decide(ctx, lam, mu)` now minimises `D + lam*bytes + mu*cycles`, and `ratectl.encode_rate_controlled(cycle_budget=...)` bisects `mu` per frame against 833,333 cycles with the `lam` bisection nested inside it. `tools/analysis/13_cpu_ratectl.py` measures what it costs. ### 31.1 The result Worst sustained window, 120 frames, same targets, same quality floors: | | PSNR | KB/s | CPU median | CPU max | frames missing | |---|---:|---:|---:|---:|---:| | `sasi` bytes only | 27.22 dB | 109.5 | 74.4% | 136.2% | **37/120** | | `sasi` + cycle ceiling | **26.95 dB** | 109.4 | 81.5% | 110.6% | **1/120** | | `scsi` bytes only | 29.90 dB | 280.0 | 94.9% | 146.6% | **51/120** | | `scsi` + cycle ceiling | **29.27 dB** | 278.6 | 99.6% | 110.6% | **1/120** | **36 of 37 misses at `sasi` for 0.26 dB, 50 of 51 at `scsi` for 0.62 dB.** The bitrate does not move: the byte controller still binds, and mu changes *which* modes are bought rather than how many bytes. `sasi` pays less quality than `scsi` because it had less to give up: it was already short of bytes, so the cycle-cheap directions it takes (V4 -> V1, and blocks it can afford to hold) were near where the byte lagrangian already sat. 28.8 predicted the shape of this and got the sign right. Mode mix, `sasi`, bytes-only -> with the ceiling: SKIP 46.4 -> 47.1%, V1 19.8 -> 23.0%, **V4 25.2 -> 20.3%**, RAW 8.5 -> 9.6%. At `scsi` the V4 collapse is dramatic — **15.0 -> 5.3%**, with RAW taking it at 41.3 -> 43.2%, which is 28.8's inversion happening in practice: RAW is dearer in bytes and cheaper in cycles, so a byte-rich profile buys its way out of V4. Only **46 of 120 frames need any mu at all** at `sasi`; the median frame is decided at mu=0 and is unchanged from session 6. ### 31.2 The one frame that cannot fit is the intra frame, not a hard case Both profiles miss exactly one frame, both at 110.6% — the all-V1 floor of FINDINGS 28.5 — and in both it is **frame 0**. It has no previous reconstruction, so every block must be coded, which is the definition of a 100%-changed frame. A scene cut mid-stream is the same thing. That is the correct behaviour rather than a failure, and it is worth being explicit about why: at `MU_CLIFF` a block only becomes SKIP if holding the previous reconstruction costs less than ~28,665 units of distortion. A frame with nothing on screen worth holding stays fully coded and is emitted **late on purpose**, exactly as a frame that will not fit at `LAM_CLIFF` is emitted over budget. Freezing a cut to make a deadline is the worse failure. ### 31.3 28.7 was too pessimistic, and the reason is instructive 28.7 estimated that only ~three quarters of the misses were the encoder's to fix — 26 of 37 at `sasi` — because re-coding every non-SKIP block as V1 still missed 11 frames. Measured, the controller fixes **36 of 37**. The gap is that 28.7's floor held the SKIP set fixed and asked "how cheap can the blocks we already decided to draw be?". The real decision can also **move a block to SKIP**, paying distortion for it, and above ~90% non-SKIP that is the only lever left. So 28.7's floor was a floor for a fixed SKIP set, not for the mode decision. Two conclusions of 28.7 stand: the profiles are an I/O axis and both must fit the same 10 MHz budget. ### 31.4 SKIP is not a constant, and the way out is two cost functions A SKIP block costs 13.25 cycles when all four blocks sharing its header byte are SKIP (one `tst.b` clears the group) and ~45 in a mixed byte, so its price depends on its neighbours — which a per-block lagrangian cannot see. Picking one number is a real trade: 45 overcharges clustered SKIPs and pushes the encoder away from the mode that saves the most cycles, 13.25 undercharges isolated ones and lets frames overrun. The resolution is that **the budget check does not have to use the same cost function as the mode decision**. `decide()` uses 13.25 purely to *rank* modes within a block, where the choice only scales the incentive (the V1-SKIP gap moves 12% between the two candidates). The controller scores whole frames with `vq_hybrid.cycles()`, the exact clustered rule, validated to 1 point against the 68000 — so the bisection converges on what the machine will really do, whatever the ranking constant was. That function is now defined once and imported by `11_cpu_budget.py`, rather than living in two places that can drift apart. ### 31.5 Both controllers are gated against decoder drift The mu controller varies the mode map frame to frame exactly as the lam controller does, so it is exposed to the FINDINGS 26.1 failure — an encoder reporting a reconstruction the decoder will never produce. `09_ratectl_drift.py` now runs **both** configurations and both report 0/120 drifting frames, 0.00 dB overstatement. The CPU ceiling is on by default in `encode.py` (`--no-cpu-fit` restores session 7 behaviour). ### 31.6 With spans on top, the window fits completely Re-running the span pricing of FINDINGS 30 against a cost-aware container — lever B first, then lever A on what it leaves: | `sasi` | bytes only | + cycle ceiling | + ceiling + spans | |---|---:|---:|---:| | median frame | 74.4% | 81.5% | **56.8%** | | worst frame | 136.2% | 110.6% | **91.5%** | | frames missing | 37/120 | 1/120 | **0/120** | | bitrate | 101.7 KB/s | 101.6 | 449.3 KB/s | The intra frame lands at 91.5% — spans are what make a full redraw fit, which is 30.6's arithmetic arriving in a real container. That row is still a **model** of a bitstream nothing implements; the two levers have never run on the 68000 together, and the ring-buffer question of 30.7 gets sharper at 449 KB/s. ## 32. SASI is dropped, and the reason is capacity, not bandwidth (session 9) **USER DECISION**: drop the `sasi` profile. A SASI volume on this machine is limited to 40 MB, and the game does not fit in one. That ends the two-quality-mode decision of session 2. `scsi` is now the only profile, and `encode.py --profile` has one choice. The retired 110 KB/s rate point is not deleted from the record, for the reason in 32.3. ### 32.1 How much video there actually is Measured off the source Blu-ray rather than recalled: the unique scene footage is streams `00000`-`00201`, **1366.6 s = 22.8 min**. The longer streams (`00215` 1376 s, `00216` 1152 s, `00223` 566 s) are compilations of the same material and are not additional content — 00223 is the window every codec measurement in this project has been taken on. Total across all 224 streams is 88.3 min, which is the figure to *not* quote. 22.8 min agrees with the ~22 min of laserdisc footage the arcade original is usually credited with, which is the cross-check that the compilations really are duplicates. At the rates this codec has actually produced, including the 7.8 KB/s audio allowance: | stream | rate | whole game | |---|---:|---:| | retired 110 KB/s profile | 109.4 KB/s | **146.0 MiB** | | `scsi`, measured (FINDINGS 31) | 278.6 KB/s | **371.8 MiB** | | `scsi` + spans (MODEL, 31.6) | 449.3 KB/s | **599.6 MiB** | ### 32.2 Where the 40 MB actually comes from It is not a bus-addressing limit. MAME 0.277's `src/mame/sharp/x68k_hdc.cpp` builds the SASI LBA from a 6-byte Group-0 CDB as `(cmd[1] & 0x1f) << 16 | cmd[2] << 8 | cmd[3]` — **21 bits of 256-byte blocks, so 512 MiB is addressable per unit**. `call_create` makes a 20 MB image (`0x13c98` blocks) because that is what a period drive was. So the 40 MB ceiling is a **Human68k / IPL volume-format and period-drive limit**, not something the SASI command set imposes. That distinction does not rescue the profile: four units at 40 MB is 160 MiB, and 146.0 MiB of video would consume essentially the entire SASI address space of the machine at the *lowest* rate this codec has ever produced, leaving nothing for Human68k, the player, or the game's own data. *Scope: the 21-bit CDB and the 256-byte block are read out of MAME's implementation. The 40 MB volume figure is the user's, and is consistent with Human68k's SASI partitioning; it has not been measured here.* ### 32.3 The rate point may come back, under a different name Dropping SASI removes an interface, not a bitrate, and the two are on different axes — the profile axis has been I/O bandwidth only since FINDINGS 28.7. The awkward part is that **capacity and bandwidth now pull in opposite directions**: - the only period medium with room for 371.8 MiB (let alone 599.6) is **CD-ROM** at 540-650 MB, and - a **1x CD-ROM sustains ~150 KB/s**, which is *below* the surviving 280 KB/s profile and much nearer the rate that was just retired. A SCSI hard disk has the bandwidth but has to be large for the era at 372 MiB. **The user's call was to ship `scsi` as the only profile now and settle the medium when the pipe is measured** — the blocked disk benchmark (`docs/BENCHMARK.md`) and the DMA-vs-PIO check of FINDINGS 29.5. **Correction to the framing above, found after that call was made.** The medium is less open than this section first presented it. FINDINGS 21.2 already committed the deployment target to **SD-backed SCSI (BlueSCSI / SCSI2SD)**, in session 2, and that is the premise the whole 488 KB/s constant rests on. On SD there is no capacity problem at any rate this codec produces — an SD card is gigabytes — and no seek tail either. So: - **Capacity does not choose between the survivors.** It killed SASI, whose 40 MB ceiling is a Human68k volume-format limit that SD emulation does not lift, and it does not bind on SD-backed SCSI at all. - **CD-ROM is the one that capacity rules out**, not in. With spans the stream is 487.1 KB/s = **650.1 MiB** for the whole game, past a CD's ~620 MiB usable — and 487 KB/s is more than 3x a 1x CD-ROM's ~150 KB/s. A CD-ROM delivery would mean giving up the span lever *and* re-deriving a profile around 150 KB/s. So the open question is not "which medium" but the one FINDINGS 29.5/30.7 already had: **confirm the 488 KB/s figure's provenance, and confirm DMA**. `profile_gen.py` exists precisely to re-derive a profile from a measured bandwidth once there is one. ### 32.4 What MAME says about the SCSI path that survives Read out of MAME 0.277 while settling 32.2, and directly relevant because the medium decision is now the thing gating the profile: **The CZ-6BS1's DMA is real and fully modelled.** `x68k_scsiext.cpp` wires the MB89352's DREQ to the expansion slot and replaces the data register at `$EA0015` with DMA-aware glue: on a DMA cycle (`m_slot->exown()`, driven by `m_hd63450->own()`) a read goes to `spc->dma_r()` and #DTACK is negated until DRQ asserts. `x68k.cpp:1114` closes the loop the other way (`out_dtack_callback -> hd63450_device::dtack_w`). That is a genuine DMAC-driven transfer with hardware flow control, on the **stock `x68000` driver** — the one MAME marks working. This is the configuration FINDINGS 29.5 asked about, and the answer for this board is **DMA, not PIO**. **The internal SCSI of the Super/XVI/030 is NOT modelled that way**, and it is a trap. `x68k.cpp:1176` reads, verbatim, `// TODO: duplicate DMA glue from CZ-6BS1`. So MAME's internal SCSI is PIO-only. A benchmark run on `x68ksupr` would measure a PIO fallback the real machine does not have — on top of those drivers already being MACHINE_NOT_WORKING (FINDINGS 28.7). **Benchmark `x68000 -exp1 cz6bs1`, not `x68ksupr`.** **CD-ROM is a first-class SCSI device on the internal bus** — `x68k.cpp:1168` puts an `NSCSI_CDROM` at ID 6 by default — but the CZ-6BS1 card's own device list offers `harddisk` only. So the CD-ROM delivery route of 32.3 is emulatable, but not on the board whose DMA is modelled, without a source change. None of this is a transfer RATE. `docs/BENCHMARK.md`'s split still holds and is worth restating because 32.3 defers a decision to a measurement: MAME can settle whether the path works and whether it is DMA, and **cannot** settle KB/s, because its device models are functional rather than transfer-timing accurate. The rate half of the medium question needs derivation or real hardware, not a longer MAME run. ## 33. The container carries its own alignment: DLX1 -> DLX2 (session 9) The encoder gap left open since session 7 (FINDINGS 28.3, STATUS item 4) is closed. `encode.py` now emits **DLX2**, which pads every frame record up to a 4-byte boundary — the first one included, by padding the codebook tables so `off_frm` is aligned. `dlx.py` reads both versions; DLX1 containers stay readable because every measurement in FINDINGS 28-31 was taken on one. Measured on the same 120-frame window: | | record starts not 4-aligned | padding cost | |---|---:|---:| | DLX1 (through session 8) | **94/120** | 0 (the loader added 180 B) | | DLX2 (now) | **0/120** | 160 B = 1.33 B/frame = **16 B/s** | 16 B/s against 278.6 KB/s is 0.006% of the stream. The thing it buys is not speed: an odd `move.l (a0)+` on a 68000 is an **address error**, which vectors into the IPL and presents as an infinite loop, not as a slow read. That is the bug that cost session 7 an afternoon. `tools/bench/prep_dlx.py` still realigns at load time and now says whether it had to — `0/120 record starts unaligned -- the container carries its own padding` on a DLX2 input. It is kept rather than deleted because it is what makes the session 7-8 containers decodable, and those are the containers the published timings belong to. **Cross-check that this changed nothing else:** re-encoding the `scsi` window with the DLX2 writer reproduces FINDINGS 31.1 exactly — 29.27 dB, 278.6 KB/s, median 99.6% / max 110.6% of a 12fps frame, 1/120 frames missing. The padding is additive; it does not touch the mode decision. ## 34. The cost model, checked against the machine on a cost-aware container (session 9) STATUS item 1. Everything in FINDINGS 31 was the validated cost MODEL (`vq_hybrid.cycles`) applied to a container it had never been checked against — the 1-point validation of 28.2 belongs to the *session 7* stream. This is the cost-aware container timed on the emulated 68000, same harness, same scope (instruction cycles, zero-wait-state GVRAM, interrupts masked; a LOWER BOUND). | anchor | non-SKIP | model | measured | error | |---|---:|---:|---:|---:| | min non-SKIP | 15.4% | 254,683 cyc / 30.6% | 262,751 / 31.5% | **-3.07%** | | median | 53.2% | 681,199 / 81.7% | 690,251 / 82.8% | **-1.31%** | | p90 | 75.7% | 832,116 / 99.9% | 834,213 / 100.1% | **-0.25%** | | max non-SKIP | 100.0% | 921,293 / 110.6% | 921,187 / 110.5% | **+0.01%** | | whole 120-frame mean | — | 649,089 / 77.9% | 657,081 / 78.8% | **-1.22%** | The model holds, and its error is **signed**: it under-predicts by 1-3% on light frames and converges to exact on heavy ones. That is the right direction to be wrong in for a ceiling controller — the bisection is tightest where the model is most accurate — but it means the median frame is ~1 point dearer than FINDINGS 31 reports, not cheaper. The four synthetic single-mode frames reproduce session 7 exactly: all-V1 110.5%, all-V4 165.2%, all-RAW 147.6%, all-SKIP 4.9%. Those are properties of `decode.s`, not of the container, so agreeing across two different streams is the cross-check that the harness is measuring what it claims. ### 34.1 The 23-minute "hang" was the buffering trap again The session-8 note said this run "was still going at 12 minutes of CPU". It was re-run here and sat at 99.9% CPU for **23 minutes** with a 0-byte log, then was killed. Re-launched under **`stdbuf -oL`** with `-seconds_to_run 60`, the identical plan completed in about **25 seconds of wall time** and printed every line as it went — MAME reports `Average speed: 528.72% (52 seconds)`, so the whole plan needs ~52 emulated seconds and the machine runs it at 5x realtime. The lesson is the one already in STATUS, one level deeper: it is not enough to write MAME's output to a file instead of a pipe. **A file is block-buffered too**, so a long MAME run is unobservable until it exits, and an unobservable run that is merely finishing looks exactly like one that is wedged. Session 8 lost the measurement to that, and session 9 lost 23 minutes to it before spending 25 seconds getting the answer. **`stdbuf -oL` on every MAME job that prints progress.** ## 35. The CPU budget has never had the disk in it (session 9) > **TESTED BY 38 AND IT STANDS.** Session 10 first argued that the flat > subtraction here is too pessimistic -- that the disk DMA could hide in bus > cycles the CPU was not using -- and scored the same window at 53/120 instead > of 84/120. **That was wrong.** A 68000 has no cache and a two-word prefetch > queue, so it stalls as soon as another master takes the bus; DMA time is > additive, which is exactly what this section assumed. The 84/120 stands and > 38.3 now reproduces it. **Raised by the user: "PIO is such a CPU killer. DMA is not. I'm concerned about us drawing the wrong conclusions."** The concern is correct, and it is larger than the labelling question of 32.4. This is the seventh false premise this project has caught, and the most expensive one. Every CPU figure in FINDINGS 24 through 34 is measured against **833,333 cycles per frame**, the full 10 MHz clock divided by 12 fps. Nothing has ever been subtracted from it for moving the bitstream off the disk. The decoder has been scored as though the data arrives for free. ### 35.1 What the transfer actually costs `profile_gen.py` has carried `DMA_CLOCKS_PER_WORD = 8` since session 2 (FINDINGS 5, an **ESTIMATE** from HD63450 timing, never measured) and prints a "DMA steal" line — but that line was only ever compared against the 38.3% *blit* figure of FINDINGS 17, which FINDINGS 24 superseded and which was never the decoder cost. It was never debited from the decoder budget. At the rates that matter, on a 10 MHz 68000: | stream | DMA @ 8 clk/word | PIO, unrolled (~12 clk/B) | PIO, byte loop (~20 clk/B) | |---|---:|---:|---:| | `scsi`, 278.6 KB/s | **11.4%** | 34.2% | 57.1% | | `scsi` + spans, 487.1 KB/s | **20.0%** | 59.9% | **99.8%** | The PIO columns are hand-derived floors, not measurements: a byte from an I/O register plus a store is 16 cycles on a 68000 before any loop overhead. They are here to size the risk, and the size of the risk is that **PIO at the span rate consumes the entire machine**. ### 35.2 What that does to the conclusions of FINDINGS 31 Debiting the DMA steal — the *cheap* case, the one we are hoping for: | | KB/s | steal | budget left | median | p90 | worst | fits? | |---|---:|---:|---:|---:|---:|---:|:--| | `scsi` today | 278.6 | 11.4% | 738,238 | **112.4%** | 112.9% | 124.8% | **no** | | `scsi` + spans | 487.1 | 20.0% | 667,070 | **98.3%** | 102.8% | 114.3% | **no** | FINDINGS 31's headline — "1 frame of 120 misses" — is measured against a budget with no I/O in it. With DMA debited the surviving profile does not fit at all: the *median* frame is over. And 31.6's "with spans the window fits completely" becomes a worst frame of 114.3%, because **the span lever buys cycles by spending bandwidth, and the bandwidth comes back out of the CPU as steal.** Spans still help — 112.4% -> 98.3% at the median, 14 points — but they no longer close the gap on their own. ### 35.3 Why this is not settled by the DMA finding of 32.4 32.4 established that the CZ-6BS1's DMA *path* exists and is modelled. Three things it does not establish, and all three are load-bearing: 1. **DMA vs PIO is a property of OUR player, not of the board.** The hardware supports DMA; if the player reads through IOCS and IOCS does PIO, we get PIO and the table above. `docs/BENCHMARK.md` item 4 already proposed driving the MB89352 registers directly for exactly this reason — that is now not an optimisation but the difference between fitting and not. 2. **8 clocks per word has never been measured.** It is now the single most load-bearing unmeasured number in the project: at 8 the port is marginal, at 12 it is dead, at 4 it is comfortable. It comes from a datasheet reading in session 2 and nothing has checked it since. 3. **MAME cannot settle it.** Its device models are functional, not transfer-timing accurate (BENCHMARK.md), and it models no GVRAM wait states either — so a MAME run can confirm the transfer is a DMA cycle and cannot price it. This needs derivation from the HD63450 and MB89352 datasheets, or real hardware. ### 35.4 What this does and does not overturn It does **not** overturn the decoder measurements: 300/448/400 cycles per block and the model validation of FINDINGS 34 are properties of `decode.s` and stand unchanged. What it overturns is every statement of the form "N frames of 120 miss the budget", because the budget was wrong. Those all need re-running against `833,333 * (1 - steal)` once `steal` is a measurement rather than a datasheet estimate. It also sharpens the framerate question of STATUS item 5 considerably. At 10 fps the budget is 1,000,000 cycles and the same DMA steal is proportionally smaller per frame, which is now a much stronger argument for 10 fps than "one late frame per cut" ever was. ### 35.5 `11_cpu_budget.py` now debits it, and 10 fps absorbs it The tool takes `--io dma|pio|none` (default **dma**) and prints the budget it is actually scoring against. On `tmp/rc_fr_singe_scsi_cpufit.dlx`: | `--io` | budget left | median | worst | frames missing | |---|---:|---:|---:|---:| | `none` — the pre-session-9 premise | 833,333 | 99.6% | 110.6% | **1/120** | | `dma` (8 clk/word, estimated) | 738,234 | 112.4% | 124.8% | **84/120** | | `pio` (12 clk/B, floor) | 548,036 | 151.4% | 168.1% | **120/120** | `--io none` prints a warning naming FINDINGS 35, so the old number cannot be produced by accident. **At 10 fps and DMA the same container goes back to 1/120** — median 93.7%, worst 104.0%. That is conservative, because it holds the 12 fps byte rate: a real 10 fps encode carries ~17% fewer bytes per second, so the steal falls too. This changes what the framerate decision (STATUS item 5) is *for*. It was a quality question about one late frame per scene cut. It is now the lever that pays for the disk, and on current estimates it is the difference between a stream that fits and one that misses 70% of its frames. ## 36. A `scsi` window does not fit in the machine the test rig emulates (session 9) Swapping the decoder gate onto the surviving profile's container made it fail — `frame 119 not pixel-exact: 49,005 px differ`. That is not a decoder bug and not the DLX2 change. **The container does not fit in RAM.** `tools/bench/decode.lua` loads the entire stream into emulated memory at `STREAM = 0x30000`, and the locked target is a stock **2 MB** machine: | container | stream | ends at | verdict | |---|---:|---:|---| | session 7-8 `sasi` | 1,108,888 B | 0x13EB98 = 1.25 MB | fits | | `scsi` cost-aware | 2,840,860 B | 0x2E591C = 2.90 MB | **overruns 0x200000 by 940 KB** | The loader wrote 940 KB past the top of memory, the decoder then parsed whatever that reads back as, and the run neither completed its sequential pass nor drew the right picture. Every 68000 decode verification before session 9 was done on a container small enough to fit by accident — the `sasi` profile was a third the bitrate, so nobody met this. **This is a property of the test rig, not of the player.** The shipping player streams from disk into a ring buffer and holds seconds of video, not minutes. But it does bound what the rig can prove: at 278.6 KB/s, a 2 MB machine holds about **6.7 seconds** of stream, so the strongest test in the tree can only ever audit a prefix of a window. The fix keeps the test honest rather than making it pass: - `prep_dlx.py` truncates the frame list to what fits, **prints that it did**, and takes `--ram` / `--all-frames`. On the `scsi` window it keeps **80 of 120** frames. - `verify_decode.py` takes `--nframes` so the reference decoder replays exactly the prefix the 68000 decoded, instead of running 40 frames ahead of it. - `check.sh` reads the count back out of `decode_meta.lua` and passes it through, and now **fails loudly if the sequential pass did not complete** — the missing `snapshot taken` marker — instead of reporting a pixel diff against a half-drawn screen. That guard is what turned this from a mystery into a five-minute diagnosis. Verifying a prefix is still a real test: SKIP blocks make every frame a claim about the one before it, so frame 79 is only correct if all 80 were. What is lost is coverage of the last 40 frames, and the honest way to get it back is to gate on more than one window rather than to pretend one pass covers everything. **The timing confirms the diagnosis.** Truncated to 80 frames the pass completes in **8 emulated seconds** and the frame is pixel-exact; the model predicts ~6.6 s for 80 frames at this container's cost, so that is the expected number. The 120-frame run that overran RAM could not finish the same work in **44**. A decoder reading garbage does not run slowly for an interesting reason — it was parsing lengths out of unmapped memory and walking wherever they pointed. Any "the decoder is 4x slower than the model on RAW-heavy streams" conclusion drawn from that run would have been entirely false, which is the third time in this session that an unobservable run nearly produced a wrong finding. ## 37. A second emulator, and MAME is not running the core we thought (session 10) Every 68000 cycle figure in FINDINGS 24-35 came from one instrument. This is a second one, run against byte-for-byte the same `decode.bin` and the same container. `tools/bench/c68k/` links **px68k's C68K core** into a headless harness: a hand-built X68000 memory map, no SDL, no ROMs, no emulated machine. The decoder touches nothing but RAM, the control block and GVRAM, so the machine around it was never part of the measurement. ### 37.1 What the two instruments actually are **MAME 0.277's `M68000` is not Musashi.** `src/devices/cpu/m68000/m68000.lst` plus `m68000gen.py`: it is the microcode core, where timing emerges from the modelled micro-sequence and 4-clock bus cycles. C68K is a static per-instruction cycle table (`ORI_CLOCKS_*` / `EA_CLOCKS_*` in `c68kmacro.h`), hand-transcribed from the Motorola manual by a different author. Those are two different ways of arriving at a number, which is what makes the agreement worth something. It would be worth much less if both were tables. ### 37.2 The harness is self-validating It decodes all 80 frames and dumps the screen; `verify_c68k.py` checks it against `tools/encoder/dlx.py` **pixel for pixel, on palette indices**. That is the licence for the cycle numbers: the harness rebuilds px68k's memory model from scratch -- byte-swapped RAM (`mem_wrap.c:420`), GVRAM word writes that discard the high byte -- and any of it being subtly wrong would still print plausible cycles. It could not print a pixel-exact 80-frame temporal recursion. It does. **`decode.s` is now pixel-exact under two independent CPU cores.** ### 37.3 The numbers ``` anchor MAME C68K delta MAME C68K of a 12fps frame min non-SKIP 42.8% 600982 620760 +3.29% 72.1% 74.5% median 65.2% 841038 869036 +3.33% 100.9% 104.3% p90 72.9% 836124 856872 +2.48% 100.3% 102.8% max non-SKIP 100.0% 921187 923090 +0.21% 110.5% 110.8% synthetic all-SKIP 40729 40946 +0.53% 4.9% 4.9% synthetic all-V1 921187 923090 +0.21% 110.5% 110.8% synthetic all-V4 1376881 1420754 +3.19% 165.2% 170.5% synthetic all-RAW -- 1273298 -- 152.8% ``` The `all-RAW` cell is empty because MAME's timed pass did not reach it. That is an operational fact worth recording: with `-video soft -nothrottle` this box runs `x68000` at about **0.033x realtime**, so `decode.lua`'s eight anchors plus two full passes — ~48 emulated seconds — cost ~25 minutes of wall clock, and two runs were killed by their own `timeout`. The C68K harness does the same work in seconds because it emulates a CPU and not a machine. **Anchor MAME runs by wall clock, not by `-seconds_to_run`.** **Cycle-table error is bounded at 3.3%, and it runs against us** -- C68K reads high on every anchor. Nothing here rescues FINDINGS 35. The disagreement is mode-dependent (all-V1 +0.21%, all-V4 +3.19%), so it localises to the V4 path's indexed two-register `movem.l`, not to a systematic clock difference. **FINDINGS 28.8 is confirmed independently**: under C68K, V4 (170.5%) still costs more than RAW (152.8%). That conclusion inverts the encoder's mode preference, so having it from a second core matters more than most. ### 37.4 What it does not settle px68k has no bus-timing model anywhere in `x68k/*.c` -- grep it. Neither instrument charges GVRAM wait states, so this is **the same lower bound, measured twice**. It bounds cycle-table error. It says nothing about the distance to a real X68000; that is still BENCHMARK.md Tier 3. ### 37.5 One trap, recorded because it will catch the next person C68K is 64-bit-unsafe by construction: its `MOVEM` macros do `src = (UINT32)(&D0)` -- they truncate the host address of the register file and dereference it -- and `C68k_Set_Fetch` keeps the opcode-fetch base in a `UINT32`. Under the default PIE the binary loads near `0x555555550000` and the first `movem` segfaults. The Makefile builds `-no-pie` and the harness mmaps its arena `MAP_32BIT`. Both are load-bearing, not tidiness. ## 38. The bus, measured: the project is bus-bound, not CPU-bound (session 10) > **This supersedes part of 29 and part of 35.** FINDINGS 29's "the bus has 4x > the headroom the CPU has" is true of the SCSI pipe and false of the 68000's > local bus, and they are different resources. FINDINGS 35's flat CPU debit for > the disk charges the CPU for bus cycles it was not going to use. Everything since FINDINGS 24 has been costed in CPU clocks. The 68000 has another budget nobody had counted: its **memory bus**, one 4-clock cycle at a time, carrying instruction prefetch as well as data. ### 38.1 Two sources that check each other `tools/bench/c68k/c68k_bench` counts every Read/Write callback the C68K core makes -- exact, because C68K splits a long access into two word calls, which is what the 16-bit bus does. It cannot count **instruction prefetch**: C68K reads opcodes straight through a host pointer with no callback, and MAME exposes no fetch count either. So `tools/analysis/15_bus_occupancy.py` derives prefetch by walking `decode.s`'s straight-line paths in `tools/bench/decode.lst` and multiplying by each frame's mode histogram. The same walk also predicts the data half -- and that half is measurable: ``` measured mean 66,700 data bus cycles/frame derived mean 66,672 error -0.04% mean, 0.06% worst ``` The walk reproduces the measurement, so its prefetch figure stands on the same footing. `15_bus_occupancy.py` exits non-zero if that check ever stops holding. ### 38.2 The result ``` mean median worst frame bus slots in a frame 201,497 211,013 230,772 data accesses 66,672 68,044 105,216 instruction prefetch 108,002 110,982 122,910 total bus cycles 174,674 181,998 193,248 bus OCCUPANCY 86.7% 86.8% 88.3% slots left for a DMAC 26,823 26,618 21,115 ``` **The decoder occupies 86.7% of its own bus, and prefetch is 62% of that.** A data-only count understates occupancy by about 2x, which is exactly the mistake an instrumented emulator would lead you into. Per mode, bus clocks against measured clocks: V1 204/299.9 (68%), V4 308/448.2 (69%), RAW 316/400.4 (79%), and the v6 span **9.0/9.152 (98%)**. ### 38.3 What that does to the frame budget -- and one wrong turn The first thing done with 86.7% was to argue that FINDINGS 35's flat CPU debit for the disk is too pessimistic: the decoder leaves ~26,800 bus slots a frame idle against the disk's ~23,000, so score it as contention, `frame = max(CPU clocks, 4 x bus cycles)`, and the window misses 53/120 rather than 84/120. **That is wrong, and the MC68450 manual is what says so.** A 68000 relinquishes the bus on BGACK and cannot execute without it -- no cache, a two-word prefetch queue that empties immediately. Worse, the DMAC does not interleave at operand granularity by default: limited-rate auto-request hands it the bus in *bursts* of `2(BT+4)` clocks out of a sample period of `2(BT+BR+5)`, taking `2^-(BR+1)` of the bandwidth in slabs (MC68450 sect 5.2.3.2, Fig 5-2). During a slab the CPU is stopped. So **DMA time is additive to CPU time**, which is what FINDINGS 35 assumed all along. `14_dmac_chain.py` reproduces its 84/120 exactly in the `today` column. What 86.7% *does* say is worse than the thing it appeared to rescue: **there is almost no room to overlap anything.** The 13.3% of bus slots the decoder leaves idle are single gaps inside a `movem`-heavy loop, not windows a bus master can be handed. Any design whose case rests on DMA hiding under CPU work on this machine should be assumed dead until measured on hardware. The measurement still earns its place: it is what prices the span painter against a DMAC in 39, and it is the reason the answer there came out the way it did. ### 38.4 What is not counted Bus arbitration. The 68000's BR/BG/BGACK handover costs cycles a cycle-steal DMA cannot avoid, and the disk debit here embeds it only insofar as FINDINGS 5's 8 clocks/word already does. Also: no GVRAM wait states, as everywhere since 24. Both make the real occupancy **higher** than 86.7%, not lower. ## 39. The DMAC chain against the span: the datasheet says no (session 10) FINDINGS 29.6 named "let the DMAC do the copy" the one lever that could move the budget without spending a byte, and left it uncosted. This costs it, and the answer is **no** -- but only after the constants came from the MC68450 manual rather than from bus arithmetic, which is the whole lesson of the section. ### 39.1 They are the same container v6's record is `{u32 absolute GVRAM address, u16 jump displacement}` = 6 bytes. An MC68450/HD63450 **array-chaining entry** is `{u32 memory address, u16 transfer count}` = 6 bytes. Set the channel dual-address, direction device->memory, Sequence Control counting both addresses up: MAR reloads per entry (the GVRAM destination), DAR walks the stream buffer, MTC is the span's word count. **The chain array IS the span table.** Every byte figure in FINDINGS 30 carries over, and this is not a fork in the format -- the encoder emits the same thing either way, only the executor changes. That much is real and survives everything below. ### 39.2 The first answer was wrong by a clock Session 10 first derived the DMAC's cost from bus arithmetic: moving a pixel is a read cycle plus a write cycle, 2 bus cycles, 8 clocks, against v6's measured 9.152 -- a 12.6% edge. On that basis the design scored 1/120 frames over budget against v6's 10/120 and looked decisive. The datasheet does not agree. **MC68450 Fig 4-25 sheet 4**, dual address / operand size WORD / device size 16 bits, D->M or M->D: `{WORD READ, WORD WRITE}` = **9 CLOCKS**. Confirmed by the long-operand row, two of each for 18. And **Fig 4-25 note 2** says why: the DMAC's reads take four clocks and its **writes take five**. The 68000 writes in four. | per pixel | clocks | source | |---|---:|---| | DMAC, dual-address word, two 16-bit ports | **9.000** | MC68450 Fig 4-25 sheet 4 | | v6 `movem` chain | **9.152** | MEASURED, FINDINGS 30 | **1.7%.** One clock on every DMAC write is the entire difference between a 12.6% win and a rounding error. Per span, sequential array chaining costs **36 clocks** (Fig 4-25 sheet 1: three word reads for the 6-byte entry, plus reload) against v6's measured 43.7 -- the DMAC's one genuine edge, and it is 7.7 clocks. ### 39.3 Scored additively, as 38.3 requires ``` today v6 span v6 fine tail DMAC chain bitrate KB/s 270.8 479.2 479.9 479.9 frame, median 108.1% 99.3% 96.5% 95.0% frame, worst 114.7% 112.0% 111.4% 110.3% frames missing 84/120 55/120 18/120 12/120 blocks spanned/frame 0 727 839 845 ``` `today` reproduces FINDINGS 35's 84/120 exactly, which is the check that the scenario lines up. ### 39.4 What the DMAC actually buys, and who else can sell it `v6 fine tail` is the decomposition. v6 pads every span up to 24 pixels because its copy is an unrolled chain of 12-register `movem` units; adding a second, finer chain of 2-register units caps the padding at 3 pixels instead of 23, for the price of some more unrolled code and **nothing per span**. Priced conservatively (a 4-pixel unit costs 56 clocks against a full unit's 220 for 24, so it is dearer per pixel and paid at most once a span): | | frames over | |---|---:| | v6 as built | 55/120 | | **v6 with a finer chain tail -- software only** | **18/120** | | DMAC chain | 12/120 | **86% of the DMAC's advantage over v6 is the 24-pixel padding quantum**, and that is a property of v6's unrolled chain, not of the CPU. The residual is 1.7% a pixel and 7.7 clocks a span, worth 6 frames of 120. Break-even against all-V1 moves the same way: v6 as built needs a run of 4 blocks, v6 with the finer tail needs 3, the DMAC needs 1. ### 39.5 The verdict **Fix the quantum in software.** Six frames of 120 does not buy a reserved DMAC channel, a two-region container layout, and a dependency on transfer timing that cannot be verified in either emulator on this box. The `v6 fine tail` figure is itself DERIVED and should be measured with `span.sh` before it is believed -- that is a day's work in a tool that already exists, against a hardware dependency that needs an actual X68000. Keep 39.1 on the record. If a later measurement moves the DMAC's per-pixel cost below 8 clocks -- for instance if GVRAM tolerates a four-clock DMAC write in a way the datasheet's typical-system assumption does not model -- the container does not have to change to take advantage of it. ### 39.6 What else would have to be true, if it is ever revisited - **A free channel.** Four exist; channel 3 is ADPCM (`adpcm_drq_tick` asserts `drq3_w`) and the SCSI stream needs one. - **Two regions per frame.** Chaining fetches entries from an array while DAR walks the pixel data, so the span table and the literal words cannot be interleaved as v6 interleaves them. - **The mode-map walk stays on the CPU.** 39.3 charges it; FINDINGS 30.7 flagged that 12_span_tradeoff.py did not. ### 39.7 A number the datasheet settled on the way past FINDINGS 5's **8 clocks/word** for the SCSI DMA has been an unsourced estimate since session 1 and STATUS has called it the most load-bearing unmeasured number in the project. Fig 4-25 sheet 3 gives single-address `W/B READ` 4 clocks and `W/B WRITE` 5; a device->memory disk transfer is one memory write. So it is **5 clocks/word if the DMAC holds the bus** and about **12 if it arbitrates per word** (front-end 5 best case / 8 worst, sect 4.5.2.1; back-end 2, sect 4.5.2.2). The feature list's "up to 5 Megabytes per Second at 10 MHz, no wait states" is the held-bus case: 2 bytes per 4-clock cycle. **8 is the midpoint of a bracket the datasheet supports, not a guess.** Which end applies depends on how the MB89352 drives REQ and whether cycle-steal-with- hold is used, which is a design decision the player has not made yet -- and it is worth 7 clocks a word on a 480 KB/s stream, so it is worth making deliberately. --- ## 40. The finer chain tail, measured: v7 (session 11) FINDINGS 39.4 attributed **86% of the DMAC array-chain's advantage over v6** to one thing that is not a property of the DMAC at all -- v6's 24-pixel padding quantum -- and derived that fixing it in software would take the `scsi` window from 55/120 frames over budget to 18/120. It labelled that figure DERIVED and said it should not be believed until `span.sh` measured it. This measures it. ### 40.1 The result `tools/bench/blit.s` gains **v7**: v6's 24-pixel coarse chain with a second, finer chain appended. Measured over thirteen span lengths by `tools/bench/span.sh`, every one of which drew a **pixel-exact** frame: ``` cycles = 66.0 per span + 9.143 per COARSE pixel + 9.978 per FINE pixel ``` fitting all 13 lengths to within **0.2%** -- and the fit is not flattered by its own configs, because the three-term model was identified on span lengths chosen so that every fine remainder a real span can have (0, 4, 8, 12, 16, 20) appears. v5 and v6 re-measure to 97.9 + 10.459 and 43.7 + 9.152, reproducing FINDINGS 30 exactly, so the harness has not drifted underneath the new variant. | clocks per 4x4 block, run of L blocks | L=1 | L=2 | L=3 | L=4 | L=8 | L=64 | |---|---:|---:|---:|---:|---:|---:| | v6 as built | 1053 | 527 | 351 | 263 | 241 | 154 | | **v7** | **424** | **292** | **248** | **226** | **183** | **151** | | DMAC chain (datasheet) | 288 | 216 | 192 | 180 | 162 | 146 | **Break-even against all-V1 (299.9) moves from L=4 to L=2 blocks.** 39.4 predicted L=3; the measurement is better than the derivation. ### 40.2 The scoring, and a derivation that was right for the wrong reasons Rescoring the same `scsi` window with `14_dmac_chain.py`, the same additive model, the same mode maps: | | frames over budget | |---|---:| | today | 84/120 | | v6 span as built | 55/120 | | **v7, MEASURED** | **18/120** | | DMAC chain (datasheet) | 12/120 | **18/120, exactly the derived figure.** That agreement is a coincidence of two cancelling errors, and it is worth writing down because a match this clean would otherwise be read as confirmation: - 39.4 assumed a **2-register `movem` tail**, derived at 56 clocks per 4 pixels = 14.0 clocks/pixel. The real tail costs **9.978** -- 29% cheaper. - 39.4 assumed the second entry point costs **nothing per span**. It costs **22.3 clocks** (66.0 against v6's 43.7), because it is a second `move.w (a0)+,d0` and a second `jmp`. The per-pixel win and the per-span loss are within a frame of each other over this window. **The conclusion survives; the reasoning behind it did not.** ### 40.3 The instruction the derivation should have picked A 2-register `movem` is the obvious "smaller unit of the same thing", and it is the wrong instruction. Per 4 pixels: | tail unit | bus cycles | clocks | per pixel | |---|---:|---:|---:| | `movem.l (a0)+,d0-d1` + `movem.l d0-d1,(a2)` + `lea` | 14 | 56 | 14.0 | | **2 x `move.l (a0)+,(a2)+`** | **10** | **40** | **~10.0** | `movem` pays two instruction words and a `lea` to move what two of the plainest instructions on the machine move with post-increment on both sides. v7's fine unit is therefore **one `move.l (a0)+,(a2)+` = 2 pixels**, which also makes the padding quantum **2** rather than 4 -- and a span is a run of 4x4 blocks, so its length is always a multiple of 4 and **the padding is exactly zero**. 39.4's "caps the padding at 3 pixels" was pessimistic by three pixels. The derived bus model predicts the measurement well once the right instruction is in it: 5 bus cycles = 20 clocks per 2 pixels = 10.0/pixel against 9.978 measured, and 54 bus cycles = 216 clocks per 24 against 9.143*24 = 219.4. ### 40.4 Where the fine displacement lives, and why it is not in the record Two chains need two entry points, and the second one has to survive the coarse copy. Holding it in a register would cost a payload register -- v6's whole reason for a 24-pixel unit is that it has exactly 12 free (`d0-d6/a1/a3-a6`). So it is not in the span record. **It is in the stream**, after the coarse pixels and before the fine ones. The coarse chain falls out into `move.w (a0)+,d0 / jmp v7fh(pc,d0.w)`, and at that instant `d0` is dead payload and `a0` is pointing exactly at it. The decoder holds nothing extra across the copy and keeps all 12 registers. The record is still `{u32 absolute GVRAM address, u16 coarse displacement}`; the container costs **2 more bytes per span**, which `14_dmac_chain.py` charges. ### 40.5 The verdict, now measured rather than argued **FINDINGS 39.5 stands: fix the quantum in software, drop the DMAC.** v7 takes back **37 of the 43 frames** the DMAC chain would, using an instruction sequence that needs no reserved channel, no two-region container, and no transfer timing that neither emulator on this box can verify. 39.1 still holds if that ever changes: the chain array and the span table are the same six bytes. ### 40.6 The 13-minute run that measured nothing `span.sh` ran for 13 minutes producing an empty log and zero snapshots, and the same MAME command with a shorter `-seconds_to_run` completed the identical work in 30 seconds. The cause is still not identified. What matters is that **the run was unobservable in both directions**: MAME's stdout did not reach the log until exit even under `stdbuf -oL`, and the snapshots -- the one artefact that would have shown progress -- may themselves only land at exit. So the bisection that resolved it did not chase the hang. It **shrank the stimulus** instead: `tmp/spans_meta.lua` carries byte offsets into a blob that `prep_spans.py` writes once, so deleting config lines from the metadata runs any subset in seconds against the same unmodified stream file. v5 alone, v7 alone and the full set at a shorter run all completed; the wedge never reproduced. This is the fourth instance of the pattern FINDINGS 34.1 named, and it is the first where **the instrument was unobservable but the thing being measured was fine**. `span.sh` now runs at `-seconds_to_run 200`, measured at 30 s wall for all 36 configs, and asserts the snapshot count against the number of configs in the generated metadata rather than a literal 23 -- so adding a config can no longer silently weaken the pixel-exactness gate. ## 41. v7 is in the player, and the model it is scored by was 18% wrong (session 12) > **41.2's FRAMING IS SUPERSEDED BY 42.** This section ends by naming the rate > point as a fork the user must choose. There is no fork: the span pass > saturates at ~837 KB/s on its own, and the 488 KB/s ceiling it is scored > against here was never a bus figure (42.1). The measurements below stand; the > "two byte budgets" mechanism of 41.2 is what made 42 findable. FINDINGS 40 measured v7 in `tools/bench/blit.s` and left it there. This builds it into `src/player/decode.s`, defines the container that carries it, and scores what the encoder actually delivers rather than what a selection model predicts. Three things came out of it that were not on the list. ### 41.1 The decoder, and the format `src/player/decode.s` gains `paint_spans`, which is `blit.s` v7 verbatim -- the same instruction sequence, deliberately, because the 66.0/9.143/9.978 fit was measured on that sequence and a tidier rewrite would silently invalidate it. The container is **DLX3**: the span section sits between the 768-byte mode header and the block payload, because that is the only place the 68000 can reach without first parsing something of variable length. ``` u32 payload length 768 B mode header spanned blocks read SKIP u16 nspans nspans * { u32 GVRAM address, u16 coarse disp, c*48 B, u16 fine disp, f*4 B } block payload V1 -> 1 B, V4 -> 4 B, RAW -> 16 B ``` Every span record is a multiple of 4 bytes (4+2+48c+2+4f), so the section needs no internal padding and the block payload starts aligned. `a1`, the mode-header cursor, is one of v7's twelve payload registers, so it goes on the stack across the pass: two long accesses a frame, against the 24 pixels a register buys per chain unit. **Pixel-exact under both CPU cores on the first run**, over a container where every frame carries 128-216 spans painting up to 38% of the picture, with full temporal recursion. `tools/analysis/16_span_roundtrip.py` is the new gate and it is in `check.sh`: encode, write the container, read it back with the reference decoder, compare to what the encoder recorded. It asserts it emitted enough spans to have tested anything -- a round-trip over a span-less container is green by vacuity, which is FINDINGS 40.6's lesson about the snapshot count. ### 41.2 There are TWO byte budgets, and conflating them hides the whole win The first measured span encode looked like a regression: at the `scsi` profile spans fired on 5 of 120 frames and bought almost nothing. The cause is not the codec. **The lam search had already spent the byte allowance**, so the span pass inherited a few hundred bytes of room. FINDINGS 40's 18/120 was never scored at 280 KB/s. `14_dmac_chain.py` defaults to `--bus 488` -- the PIPE -- and gives each frame 40,977 bytes. The profile's is 23,228. **Those are two different budgets and only one of them is hardware.** The profile is a chosen quality rate point; the pipe is a ceiling. Bytes between the two buy a better picture if spent on `lam`, the 68000's deadline if spent on spans, and nothing at all if left unspent. So the encoder now takes both: `--kbps` sets the quality target and `--span-kbps` the ceiling the span pass may draw on, flat per frame and not banked, because a pipe cannot be saved up. The quality bucket is credited with the BLOCK payload only -- charging it the span bytes drives it to its floor on the first spanned frame and starves every later frame of quality for a budget the spans were never drawing on. Spans also run BEFORE `mu`, and that ordering is the point. Both controllers make a frame decode in time; `mu` pays in quality and a span pays in bytes, and a span carries literal source pixels so it *removes* that run's quantisation error. Spending bytes we already have beats spending picture. | 120-frame `scsi` window | KB/s | over budget | PSNR | |---|---:|---:|---:| | no spans | 278.3 | 86/120 | 29.27 dB | | spans, profile budget only | 280.0 | 77/120 | 29.23 dB | | **spans on the 488 KB/s pipe** | 487.7 | **34/120** | **29.63 dB** | Scored with `17_span_delivered.py`, which reads the emitted span section and prices exactly those spans -- no selection model at all -- in 14's additive model: block decode + span painting + disk DMA. ### 41.3 The blit.s fit transfers into the player, to 0.2% `prep_dlx.py` gained two synthetic all-SPAN frames (full-row runs, and 4-block runs at the break-even). They price v7 inside `decode.s` against the constants `span.sh` fitted in `blit.s`: | | predicted | MAME | C68K | error | |---|---:|---:|---:|---:| | all-SPAN-64 (192 spans x 256 px) | 505,636 | 506,533 | 506,824 | +0.18% | | all-SPAN-4 (3072 spans x 16 px) | 734,193 | 735,133 | 735,304 | +0.13% | Per 4x4 block that is **151.2 and 225.6 clocks, against FINDINGS 40's table of 151 and 226**. The mode costs what it was said to cost, in the real decoder, on two emulators. ### 41.4 The rig had been writing past the top of RAM `prep_dlx.py` truncated the real frames to a RAM budget and then appended its synthetic timing frames ON TOP, 26 KB past the 0x200000 top of a 2 MB machine. Survivable while it lasted, because the modes it overran are data-independent: reading junk payload costs a V1 or a RAW block exactly what reading pixels costs, so the anchors timed correctly by luck. **A span is not data-independent.** Its two jump displacements come out of the stream, so an out-of-RAM span record jumps into open bus. The synthetic frames are now built first and their size comes out of the budget, with an assertion that the stream ends below the top of RAM. ### 41.5 C_SKIP_MIXED was never measured, and it was 18% low Chasing a 3% gap between the model and the measured decode turned up the one constant in `vq_hybrid`'s cost table that came from a derivation rather than a measurement: **the cost of a SKIP block sharing its header byte with a coded block.** It was 45.0 from session 7 to session 12. It is **55.0**. Every other constant comes from a synthetic frame of a single mode, and there was no such frame for a mixed SKIP, *because one cannot exist* -- the byte has to hold a coded block for the SKIP to be mixed at all. So `prep_dlx.py` now emits four frames that bracket it, (3 SKIP + 1 V1), (1 SKIP + 3 V1), and the same pair with RAW, each pair solving for the SKIP cost and its partner's together: | | MAME | C68K | |---|---:|---:| | mixed SKIP, from the V1 pair | 55.03 | 56.50 | | mixed SKIP, from the RAW pair | 55.83 | 56.50 | | V1, solved back out | 300.66 | 300.50 | The partner solves back to its own anchored value to 0.2%, which is what says the pair is measuring the SKIP rather than absorbing it. 55.0 is taken because every other constant in the table is MAME's. **The header bytes ROTATE through all four positions, and that is load-bearing.** `decode.s` reaches a block's mode bits with `lsr.b #6/#4/#2` and no shift at all for the last one, so a block costs 52/48/44/34 clocks of dispatch depending on where in its byte it sits. A fixed pattern like 0x01 pins every SKIP to the three expensive slots and every V1 to the free one, and solving two such equations returns a number that describes no real frame. The first attempt did exactly that, and a single-parameter fit against real frames then "confirmed" 87.7 -- collinear with the span term, and wrong. With the constant corrected the model predicts the measured decode of a real spanned container to **-0.06% on the mean and 0.09% worst frame**, against -2.99% and 4.30% as it stood. It matters more than 10 clocks a block sounds, because **a span marks its run SKIP**: a spanned container is made largely of mixed SKIPs, so this is the dominant population in exactly the frames spans are judged on. It is imported now, not copied, in `spans.py` and `14_dmac_chain.py`. *Incidental, and it resolved a false lead:* RAW and V4 read 3.2-3.5% higher on C68K than on MAME, on mixed and pure frames alike. That is FINDINGS 37's known table spread, not a property of mixed bytes -- but comparing a C68K-derived solve against a MAME-derived anchor made it look like one for an hour. ### 41.6 Frames-over-budget is not a safe headline any more The delivered 34/120 against 14's simulated 18/120 is a **1.4% difference in mean frame cost** (786,381 clocks against 774,356). The metric is that sensitive because the rate controller *aims* at the deadline: 55 of 120 frames land within 5% of it, and shifting every frame by 1% moves the count from 25 to 47. | every frame shifted by | -3% | -2% | -1% | 0 | +1% | +2% | +3% | |---|---:|---:|---:|---:|---:|---:|---:| | frames over budget | 18 | 21 | 25 | **31** | 47 | 61 | 63 | This was a fair metric when nothing controlled to the budget. It is now a measurement of where the controller aims, and any cost-model error is amplified into a large count change -- which is how 41.5's 18% error stayed invisible. **Report the cost distribution; quote the count only with its sensitivity.** Add this to the §4 measurement traps. ## 42. The rate point dissolves: bytes are nearly free, and one constant decides everything (session 13) Session 12 ended by naming the rate point as "the first real fork since the profile was set" and asking the user to choose one. **The question turned out to be mis-posed, and the user is what posed it correctly**: challenged on where the 488 KB/s constant came from, the answer is that it never came from the SCSI bus at all, and the bus has roughly eight times that in it. Once bytes are that cheap the rate point is not a choice, it is a saturation point the encoder finds on its own -- and what actually decides whether the game runs is **the number of clocks the SCSI DMA steals per word**, which is still unmeasured and now worth more frames than every optimisation since FINDINGS 24 combined. ### 42.1 The 488 KB/s constant was never a bus figure FINDINGS 18/21 recorded it as a user-supplied "4 Mbps" with no provenance, and 29.5 item 3 has carried "confirm the 4 Mbps figure" as an open item ever since. Checked against the standard: **SCSI-1 (ANSI X3.131-1986) is an 8-bit bus at ~1.5 MB/s asynchronous and 5 MB/s synchronous** -- MB/s, not Mbps. The working constant is 10% of the asynchronous rating and 3% of the deployment target's (FINDINGS 21.2 committed to SD-backed SCSI in session 2). So the pipe was never the binding resource on the I/O side. What binds is that **a delivered byte is charged to the 68000's frame budget**, because the DMAC stalls the CPU rather than overlapping with it (38.3). The pipe's units are KB/s; the real currency is clocks. ### 42.2 The cheapest way to put a pixel on this screen is to not code it Per pixel, in frame-budget clocks, with `W` the SCSI DMA's clocks per word: | | wire bytes | paint | disk debit | total | |---|---:|---:|---:|---| | v7 literal span | 2 | 9.143 | `W` | `9.143 + W` | | RAW block | 1 | 25.03 | `W/2` | `25.03 + 0.5W` | | V1 block | 0.25 | 18.74 | `W/8` | `18.74 + 0.125W` | A span pixel costs **two** wire bytes, not one: X68000 GVRAM in 256-colour mode is one pixel per WORD with the high byte discarded (`spans.py:44`, and it is the memory model both emulators are pixel-exact against), so the span path is a straight `movem` copy that cannot pack. That 2x on bytes is exactly what buys 9.143 clocks/pixel. **A span beats a RAW block for any `W < 31.7`**, i.e. everywhere in the 5..12 bracket of 39.7, and by a factor of nearly 2. The codec's expensive modes exist to save bytes, and bytes have stopped being the scarce thing. The budget is 833,333 clocks for 49,152 pixels = **16.95 clocks/pixel**. A full-frame literal therefore needs `9.143 + W` to fit under ~16.1 after span and all-SKIP overhead: **lossless fits iff `W` is about 6.5 or less.** ### 42.3 Measured: the span pass saturates at ~935 KB/s, 0.13 dB off the display Encoded with `--kbps 280` held fixed and `--span-kbps` swept, so every column below has the same quality target and differs only in what the span pass was allowed to draw on. Scored with `17_span_delivered.py` over the emitted span sections: | container | KB/s | span px | PSNR | over @5 | @8 | @12 | |---|---:|---:|---:|---:|---:|---:| | `s12_280_off` | 278.6 | 0% | 29.27 dB | 76/120 | 86/120 | 109/120 | | `rc_fr_singe_scsi_span` (the gate) | 487.7 | 26.6% | 29.63 dB | 11/120 | 34/120 | 78/120 | | `s13_280p700` | 693.8 | 48.3% | 30.28 dB | 16/120 | 28/120 | 63/120 | | `s13_280p1000` | 815.4 | 60.2% | 30.93 dB | 7/120 | 20/120 | 64/120 | | `s13_280p1500` | 837.4 | 62.3% | 31.04 dB | **0/120** | 21/120 | 63/120 | | `s13_lossless` (`--kbps 2000`) | 934.6 | 70.4% | **31.19 dB** | **0/120** | 47/120 | -- | **`s13_280p1500` and `s13_280p2200` are byte-identical files.** The span pass stops finding spans worth taking at ~837 KB/s; asking for more bytes returns the same container. The rate point is not a choice between quality and deadline any more, it is a saturation the encoder reaches by itself. Three results worth separating out: 1. **0/120 is the first time anything in this project has fitted 12fps on every frame.** It is also the best picture yet: 31.19 dB against a **31.33 dB palette ceiling**, 0.13 dB off exact for this display. 2. **`mu` is never spent.** At span budgets >= 1000 KB/s, 0/120 frames need the CPU-fit lagrangian at all. The 0.62 dB FINDINGS 31 paid to make frames decode in time is refunded in full -- spans buy the deadline with bytes, and a span is pixel-exact, so the trade is quality-positive in both directions. 3. **Quality and deadline stopped competing.** Every earlier section on this project trades one against the other. Above ~800 KB/s more bytes improve both at once, until the span pass runs out of runs worth spanning. ### 42.4 So the whole result now hangs on `W`, and only on `W` Read the columns of 42.3 sideways rather than down. At 934.6 KB/s: | `W`, clocks/word | median frame | worst | over budget | |---:|---:|---:|---:| | 5 | 83.0% | 91.0% | **0/120** | | 6 | 87.6% | 97.0% | **0/120** | | 6.5 | -- | -- | crossover | | 7 | 92.2% | 103.0% | 21/120 | | 8 | 96.8% | 109.0% | 47/120 | Moving `W` across its datasheet bracket costs more frames than moving the rate from 280 to 935 KB/s wins. **`W` is now the most load-bearing unmeasured number in the project**, displacing the 4 Mbps figure it just retired. ### 42.5 MAME settles which end of the bracket applies, and cannot settle the number STATUS has carried "benchmark `x68000 -exp1 cz6bs1`, never `x68ksupr`" since session 10, and the note reads as a hardware claim. **It is not one, and the user was right to challenge it.** Both machines use the same MB89352 SPC -- `x68k.cpp:834` maps it at `$E96020`, `x68k_scsiext.cpp:83` at `$EA0000` -- and neither needs a driver because SCSI IOCS is in ROM. The difference is an emulation gap: `x68k.cpp:1176` is literally `// TODO: duplicate DMA glue from CZ-6BS1`. The external board's glue is modelled, and reading it answers the mode question: - `x68k_scsiext.cpp:110-136`: a transfer is a DMA cycle when `m_slot->exown()` -- the HD63450's **OWN** -- is asserted, so the DMAC holds the bus and the 68000 is off it. It single-address reads the data register at `$EA0015` and **negates `#DTACK` whenever `DRQ` is not ready**, stalling rather than arbitrating away. - `x68k.cpp:1114-1115, 1122-1123`: the slot's DTACK feeds `hd63450::dtack_w` and the DMAC's `own()` feeds back to the slot. So the modelled CZ-6BS1 path is **cycle-steal with the bus held** -- the 5 clocks/word end of 39.7's bracket, not the ~12 arbitrated end. That is the end where everything above fits. **But MAME cannot give the constant, and asking it for one would be reading back a hand-set table.** `x68k.cpp:1047-1048` configures the DMAC with `set_clocks(attotime::from_usec(2), from_nsec(450), from_usec(4), ...)` and `set_burst_clocks(...)` -- wall-clock attotimes, not the MC68450's per-operand cycle counts. Same lesson as FINDINGS 39: the datasheet supplies constants, the emulator supplies structure. Use MAME to confirm which handshake the player's code actually provokes; use Fig 4-25 for what it costs. ### 42.6 Where the wait actually comes from, and why flash is the right premise With DTACK gating the cost decomposes: W = 5 clocks (MC68450 single-address write, Fig 4-25 sheet 3) + however long the drive makes the DMAC wait for DRQ The 5 is silicon and fixed. **The rest is the device**, and it is where 8 and 12 came from -- 8 was taken as a bracket midpoint in FINDINGS 5, not measured. A period spinning SCSI-1 drive supplies a real wait; SD-backed SCSI with a modern controller collapses it toward zero and leaves the floor. The deployment target has been SD since session 2 (21.2), so **the favourable end of the bracket is the one the actual hardware is on** -- which is what makes 42.3's 0/120 worth taking seriously rather than filing as a best case. This is a better-founded version of the user's argument than the bus rating was. The bus rating is true and irrelevant; the wait term is what their premise actually buys. ### 42.7 What is NOT established Stated plainly, because 42.3 is the most favourable table this project has ever produced and that is exactly when it should be distrusted: 1. **No 68000 has decoded a 70%-span container.** Every figure in 42.3 is the additive cost model. That model is validated to -0.06% mean / 0.09% worst on spanned containers (41.5), but the heaviest one ever *run* is the gate's 26.6%. The rig loads the stream into a 2 MB machine, so a 934.6 KB/s stream is about **5 frames** -- getting coverage back needs a different rig (stream-in-chunks, or a larger machine as a deliberately-labelled non-target), not a longer pass. This is FINDINGS 36's lesson pointing at a new wall. 2. **`W` is unmeasured**, and 42.4 is the whole result's sensitivity to it. 3. **The ring buffer has never been simulated near this rate.** 98 KB/frame of span payload against 2 MB with no double buffer; `09_buffer_sim.py` last ran at 110 and 280 KB/s (29.5/30.7). 4. **Capacity is fine but should be stated:** 934.6 KB/s x 1366.6 s = **1.22 GB** for the whole game. Irrelevant on SD, fatal on anything period. This closes CD-ROM permanently rather than parking it (32.3). 5. **Span selection is still greedy after `lam`** (STATUS item 2, 39.3). At saturation that probably leaves something on the table rather than costing anything, but it has not been checked at this rate. 6. **The `--kbps 2000` container is not a shippable configuration**, it is a probe: it lets `lam` fall to its floor and asks what the span pass does with an unbounded budget. `s13_280p1500` at 837.4 KB/s is the honest candidate. ### 42.8 FINDINGS 17.5 was right, and was withdrawn for the wrong reason Session 4 concluded: **"ship pixel-exact if SCSI sustains >=800 KB/s."** Session 5 withdrew it, because 17 had reasoned against a misread 4 MB/s and the correction to 4 Mbps = 488 KB/s put 800 out of reach. The correction was to the wrong direction of the error. 4 MB/s was indeed a misread of the bus, but 488 KB/s was not a measurement either -- and the bus really does have ~1.5-5 MB/s in it (42.1). **The delivered stream is 837.4 KB/s at 0.29 dB off the palette ceiling**: 17.5's threshold, and 17.5's conclusion, reached from the opposite end five sessions later by a route that never cited it. Worth recording as a methodology result rather than a curiosity. The project's habit of appending corrections rather than editing history is what made this recoverable at all -- but 17.5 spent five sessions marked "not available" because a number nobody had sourced was allowed to retire a conclusion that had been reasoned properly. **A correction is only as good as the constant behind it**, and this is the second time that constant is the one at fault (compare 39: bus arithmetic retired the DMAC's first costing, and the datasheet retired the retirement). ## 43. The disk debit was denominated per word, and the SPC is a byte-wide port (session 14) Session 13 made `W` -- the clocks the SCSI DMA steals -- the one binding unknown in the project, and 42.4 showed the whole result swinging on where in a 5..12 bracket it landed. **The bracket was in the wrong unit.** `W` was charged per WORD of delivered stream, and the MB89352 is an 8-bit port: the DMAC pays per BYTE. The debit is 2x what every table since FINDINGS 5 has charged, the favourable end of the bracket was never physically reachable, and 42.3's 0/120 does not survive. The result is not lost, but it is re-anchored 41% lower in rate and 1.85 dB lower in picture, and it had to be re-encoded rather than re-scored -- because the encoder was making its decisions in the wrong units too (43.6). ### 43.1 The floor argument needs no datasheet A 68000 bus cycle is four clocks minimum. The SPC delivers one byte per bus cycle. Therefore **no DMA of this device can cost less than 4 clocks/byte = 8 clocks/word**, before a single clock of DMAC overhead, the write cycle that puts the byte in RAM, or any wait the drive imposes. The retired bracket's own midpoint, 8 clocks/word, is that floor exactly; its favourable end, 5 clocks/word, is **2.5 clocks/byte -- 62% of a single bus cycle**. It implied a 4 MB/s DMA on a 10 MHz bus, on a SCSI-1 link 42.1 had just established runs at 1.5 MB/s asynchronous. The number that retired the 4 Mbps figure should have retired this one in the same paragraph. Independent cross-check, of the kind this project files as folklore rather than measurement: BlueSCSI-class throughput on an X68000 is discussed at 0.7-1.7 MB/s. 5 clocks/byte is a 2 MB/s ceiling and 9 is 1.11 MB/s; 2.5 clocks/byte is 4 MB/s, which no one has ever reported on this machine. ### 43.2 The datasheet, per byte, for the transfer this actually is Device-to-memory, 8-bit device, MC68450 Fig 4-25, all while the DMAC owns the bus (note 2: reads 4 clocks, writes 5): | how the DMAC is programmed | clocks per BYTE | source | |---|---:|---| | single address, D->M | **5.0** | sheet 2 | | dual address, byte, no packing | **9.0** | sheet 4, the note on the 9-clock word case | | dual address, byte packed to word writes | **16.5** | sheet 3: 14 clocks then 19, per two bytes | Byte packing is *dearer*, not cheaper: the FIFO path carries 10 clocks of inter-cycle overhead per operand where the unpacked path carries none. To this, per period of bus ownership, add front-end overhead of **5 clocks best case (Fig 4-23) or 8 worst (Fig 4-24)** and back-end of **2 (4.5.2.2)**. Amortised over a sector that is noise; taken per operand it would add 7-10 clocks to every byte. **That is what actually rules out arbitrating per byte** -- not the OWN pin (43.3). **Which row applies is a wiring question, and it is worth 4 clocks on every byte of the game.** Single-address needs the SPC's DACK driven from the bus's `#EXACK` (pin B37, and the bus really does have it, `x68kexp.h`). MAME models the dual-address row: an `exown`-gated byte read of `$EA0015` written to memory with `space.write_byte` (`x68k_scsiext.cpp:110-121`, `hd63450.cpp:383-385`), and it has no DACK path at all, so **MAME cannot settle this one either way.** ### 43.3 42.5's reading of the OWN pin was over-read 42.5 concluded from `x68k_scsiext.cpp`'s `m_slot->exown()` gate that the modelled path is "cycle steal with the bus held", i.e. the 5-clock end. It does not say that. `hd63450.cpp:366,447` asserts `m_own(0)` before **every** `single_transfer` and negates it after, in every request-generation mode, and `x68kexp.h:131` inverts it. So `exown()` distinguishes **a DMAC access from a CPU access** -- DMA versus PIO -- and says nothing about hold versus arbitrate. The check was answering a different question than the one asked of it. Two things about the board do survive, and they are the useful half: 1. **The glue's flow control is a stalled bus cycle, not a released bus.** When `DRQ` is low the board negates `#DTACK` and the DMAC waits mid-cycle (`hd63450.cpp:449`, `if (!m_dtack) return;` -- the operand does not advance). There is no path by which it hands the bus back inside a word. So whatever the drive makes it wait, it waits **holding the bus**, which is why the wait term of 42.6 is charged to the frame budget in full. 2. **MAME has no DRQ line from the expansion slot to the DMAC.** `x68kexp.cpp` has no such callback; DMAC channel 0 is wired to the FDC and channel 3 to the ADPCM (`x68k.cpp:1052-1053,159`). The real bus has `#EXREQ`/`#EXACK` (B36/B37), so external-request modes exist on hardware and are simply absent from the model. **Any request-generation experiment run in MAME would be measuring the gap, not the board.** ### 43.4 What it costs, on the containers session 13 already had `17_span_delivered.py` and `14_dmac_chain.py` now take `--disk-clk-byte`; `--disk-clk-word` is kept and halves it, so session 13's tables reproduce exactly. Frames over the 12fps budget, 120-frame `singe` window: | container | KB/s | 2.5 c/B (s13) | 5 c/B | 9 c/B | 16.5 c/B | |---|---:|---:|---:|---:|---:| | `s12_280_off` | 278.6 | 76/120 | 100/120 | 118/120 | 120/120 | | `rc_fr_singe_scsi_span` (the gate) | 487.7 | 11/120 | 71/120 | 119/120 | 120/120 | | `s13_280p1000` | 815.4 | 7/120 | 45/120 | 120/120 | 120/120 | | **`s13_280p1500`** (s13's candidate) | 837.4 | **0/120** | 44/120 | 120/120 | 120/120 | | `s13_lossless` | 934.6 | **0/120** | 87/120 | 120/120 | 120/120 | **Nothing session 13 emitted fits at any point in the real bracket.** The mechanism is 42.2's own table read at the right price. Per pixel, with `c` the clocks per delivered byte: v7 literal span 2 bytes 9.143 + 2c RAW block 1 byte 25.03 + c V1 block 0.25 B 18.74 + 0.25c A span beats RAW for `c < 15.9` -- still true everywhere real. But **a span beats a V1 block only for `c < 5.48`**, and that crossover sits between the single-address row and the dual-address row of 43.2. The span pass is not robust to the wiring question; it is decided by it. The encodes in 43.6 confirm the prediction: spans paint 30.7% of the picture at `c=5` and 3.9% at `c=9`. ### 43.5 A frame's cost is now, to three figures, its byte count On `s13_280p1500` at 5 clocks/byte, `corr(bytes, total frame clocks) = 0.989`, and the disk term's p10..p90 spread (281k..464k clocks) is most of the frame total's (713k..966k). Frames that miss carry 87,203 bytes on average against 61,295 for frames that fit. **Which breaks the rate controller's bucket.** It banks bytes across 8 frames because the player's ring buffer can hold them -- true, and irrelevant now: those bytes are also clocks, and FINDINGS 28 established there is no double buffer to decode ahead into, so **a frame that borrows bytes from the bucket borrows clocks it cannot bank.** Byte smoothing was free when bytes were free. It is now a direct source of deadline misses. ### 43.6 The encoder was never told a byte costs anything either This is why the session could not just rescore. `ratectl.py` bisected `mu` against 833,333 cycles of DECODE, with no disk term, and `spans.select()` admitted a run "only if the span beats the blocks it replaces on cycles ALONE" -- explicitly ignoring the bytes it adds. Both now work in one currency: - `ratectl.DISK_CLK_BYTE` (default **5.0**, `encode.py --disk-clk-byte`) is charged inside the CPU ceiling, so every fit test is `decode + c*bytes`. - `spans.select()` admits and ranks on **net** clocks, `(clocks won) - c*(bytes added)`. At `c=0` both reduce exactly to the old rules, and `--disk-clk-byte 0` re-emits `s13_280p1500` byte for byte (8,501,948 B, 31.04 dB) -- so the change is the price, not the codec. Re-encoded honestly, 120-frame `singe` window, 12 fps: | | KB/s | PSNR | loss vs ceiling | over budget | span px | |---|---:|---:|---:|---:|---:| | s13's claim (2.5 c/B) | 837.4 | 31.04 dB | 0.29 dB | 0/120 | 62.3% | | **`s14_d5_all1500`, single address** | **496.7** | **29.19 dB** | 2.14 dB | **1/120** | 30.7% | | `s14_d9_all1500`, dual address | 255.0 | 28.50 dB | 2.83 dB | **1/120** | 3.9% | **The one frame over is frame 0** in both -- the intra frame, which FINDINGS 28.5/31 already established is emitted late on purpose because there is nothing on screen to hold. **Every other frame lands at or under 100.0%**: the controller now binds exactly on the joint budget. `17_span_delivered.py`, which shares no code with the encoder's own accounting, reproduces both rows to the digit. Two smaller results fall out: 1. **`--spans all` is now the better rule, and `--spans need` the worse one** (275.8 KB/s, 28.92 dB, 2/120). `need` stops as soon as the frame fits and leaves profitable clock savings unbought; once profitability is measured in one currency, spending every profitable byte *is* the optimum. My recommendation is to make `all` the default; that is my inference, not a measurement. 2. **`--span-kbps` has stopped binding.** 700 and 1500 produce identical files. Session 13's saturation was the byte ceiling running out; this one is the span pass running out of runs that pay, which is a property of the codec rather than of a chosen number. ### 43.7 What this withdraws - **42.3's 0/120 and "quality and deadline stopped competing".** They compete again, and harder than before: a byte now buys picture and spends deadline. - **42.3's "`mu` is never spent"** and the refund of FINDINGS 31's 0.62 dB. `mu` is spent on 103 of 120 frames at `c=5` and 118 at `c=9`. - **42.8's revival of 17.5** ("ship pixel-exact if SCSI sustains >=800 KB/s"). The stream that fits is 496.7 KB/s and 2.14 dB off the palette ceiling, so 17.5's threshold is not met and its conclusion does not return. The methodology point in 42.8 stands and now applies to itself. - **`docs/BENCHMARK.md`'s "~8 clocks/word => ~2.5 MB/s practical ceiling".** The ceiling is 2 MB/s at best (5 clocks/byte) and 1.11 MB/s dual-address. - **FINDINGS 5's 8 clocks/word**, retroactively, wherever it was used: every I/O debit in the project before this section was charged at half rate. ### 43.8 What is NOT established 1. **Single-address versus dual-address is a hardware fact this tree cannot check.** It is worth 242 KB/s and 0.69 dB, and MAME models only the dual row (43.2). It needs the CZ-6BS1 schematic or a real board -- and note it is the *board's* wiring, not our code, so unlike every previous item on this list it is not a design decision we get to make. 2. **The 5 and the 9 are datasheet floors with the drive wait set to zero.** 42.6's argument that SD-backed SCSI collapses that term is unchanged and still unmeasured. 3. **Front-end and back-end overhead are excluded**, which assumes at least a sector per period of bus ownership. If the player ends up taking the bus per operand, add 7-10 clocks to every byte and nothing fits at all. 4. **Still no 68000 has decoded any of these containers** (42.7 item 1). The new ones are lighter in spans than the gate, so that gap is narrower than it was, but it is the same gap. 5. **The bucket has not been fixed**, only diagnosed (43.5). ### 43.9 The unit was never written down The error is one substitution -- bytes/2 for bytes -- and it survived from FINDINGS 5 through nine sessions, two cost-model rewrites, a datasheet reading that corrected the *value* of the same constant (39.7), and a section devoted to distrusting the table it produced (42.7, which lists six things 42.3 did not establish and does not list its own denominator). What let it hide: `W` was carried as "clocks per word" in three tools and a half-dozen tables, and **the device's port width was never in the same sentence as it.** The 8-bit-ness of the MB89352 was known -- it is visible in `install_device(..., 0x00ff00ff)` and in every register map in the project -- but it lived in the I/O notes while `W` lived in the budget arithmetic. The rule this project already had (FINDINGS 33: a design that counts only CPU shows a win the I/O it created takes away) needed one more clause: **check what the unit is denominated in, on the device that supplies it.** A per-word debit for a byte-wide port is a factor of two, and a factor of two is the difference between this game running and not. --- ## 44. The byte-side rate controller is inert, and both inconsistencies in it are worth under 2% (session 15) STATUS's item 2 asked for the leaky bucket to be fixed: 43.5 diagnosed it as banking bytes that are now clocks, across a player with no double buffer to bank clocks in, and called it "a direct source of deadline misses". The diagnosis is correct as a mechanism. **It is not a source of anything at the operating point this project actually recommends**, and neither is the second, larger-looking inconsistency found next to it. Both are now implemented, both measure as a wash or a regression, and **both ship off by default** -- `--joint-decide` and `--joint-bucket` turn them on. Everything below is the 120-frame `singe` window, `--profile scsi --kbps 280 --span-kbps 1500`, `c = 5` clocks/byte, 12 fps, scored both by the encoder and by `17_span_delivered.py`, which shares no code with it. ### 44.1 The mode decision was the last place a byte was free 43.6 charged the disk inside the rate controller's fit test and inside `spans.select()`, but `vq_hybrid.decide()` still minimised `D + lam*bytes + mu*cycles` with `cycles` meaning DECODE cycles only. So while `mu` was enforcing a joint budget from above, the per-block lagrangian underneath it still believed delivery was free. **That inverts FINDINGS 28.8.** RAW is 400.4 cycles against V4's 448.2, so with a free byte, raising `mu` buys cycles by moving V4 -> RAW -- which is exactly what 28.8 observed and what session 8's `0c` recorded as V4 collapsing. Priced per delivered byte, a RAW block costs `400.4 + 16c` and a V4 block `448.2 + 4c`: | c, clocks/byte | V1 | V4 | RAW | |---:|---:|---:|---:| | 0 | 299.9 | 448.2 | **400.4** | | 2.5 (the retired 5 clk/word) | 302.4 | 458.2 | **440.4** | | **3.98** | 303.9 | **464.3** | **464.3** | | 5 (single address) | 304.9 | **468.2** | 480.4 | | 9 (dual address) | 308.9 | **484.2** | 544.4 | **The crossover is c = 3.98 and 43.1's floor argument is c >= 4.** A 68000 bus cycle is four clocks and the SPC hands over one byte per cycle, so RAW's cycle advantage does not exist on any real machine: it was spending 12 clocks of bus to save 47.8 of CPU. The escape hatch was an artefact of the same free byte that FINDINGS 43 found everywhere else. ### 44.2 And correcting it changes almost nothing `decide()` now takes `byte_clk` and prices a payload byte at `lam + mu*byte_clk`. At `byte_clk = 0` it is the old decision exactly, and the containers of session 14 re-encode to the same MD5. | `--spans all`, c=5 | KB/s | PSNR | mean frame clocks | over budget | worst | |---|---:|---:|---:|---:|---:| | the shipped decision | 496.7 | **29.19** | **740,049** | 1/120 | 112.9% | | `--joint-decide` | 482.5 | 29.17 | 745,438 | 1/120 | 112.9% | It **buys 6,058 clocks of disk with 17,207 clocks of block decode** -- a net 5,389 clocks a frame in the wrong direction. Scored at c=4 and c=9 it is the marginally worse container at every price, so this is not a bet on which row of 43.2 wins. The reason is scale, not sign: at the `mu` the controller actually settles on (median 0.74-0.91) the added byte price is `mu*c` ~ 4 against a `lam` floor of 10, and the RAW/V4 decision is dominated by V4's distortion term rather than by either. RAW moves 16.0% -> 15.7% of blocks. **The inconsistency was real, the correction is right, and the effect is 0.02 dB.** ### 44.3 The bucket does not bind, and at `--spans all` nothing on the byte side does Before fixing the bucket, measure whether it is loaded. It is not: | `--spans all`, c=5 | KB/s | PSNR | over budget | container | |---|---:|---:|---:|---| | `--bucket-frames 8` (shipped) | 496.7 | 29.19 | 1/120 | baseline | | `--bucket-frames 32` | 496.7 | 29.19 | 1/120 | **byte-identical** | | `--bucket-frames 1` (no banking at all) | 498.0 | 29.19 | 1/120 | +1.3 KB/s | | `--rc-floor open` (lam floor 1.0) | 503.7 | 29.21 | 1/120 | +0.02 dB | **`lam` never leaves its floor of 10.0 on any of 120 frames**, in any of these, and quadrupling the bucket emits the same bytes. With `--spans off` at 259.3 KB/s under a 280 KB/s target, a 1-frame bucket and an 8-frame bucket are again byte-identical. The block coder at the profile floor simply lands under the per-frame byte budget, so there is nothing for the bucket to lend and nothing for the lam bisection to do. **The rate this project reports is set by the span pass and by `mu`; `--kbps` and the bucket are not the levers.** The one place the bucket does cost something is the mode 43.6.1 recommends abandoning: at `--spans need` it is worth exactly one frame of 120. ### 44.4 The cap, and why capping only half a frame is worse than not capping `--joint-bucket` caps what the bucket may lend at what the frame's clock budget can still absorb after its own block decode -- `(cycle_budget - cycles(mode0)) / c`, priced at the mode map the un-banked budget buys, and never below that budget. The bucket then smooths only what is left after the disk is paid, which is what STATUS item 2 asked for. | c=5 | KB/s | PSNR | median frame | over budget | |---|---:|---:|---:|---:| | `need`, shipped | 275.8 | 28.92 | 99.8% | 2/120 | | **`need --joint-bucket`** | 302.1 | 28.91 | 99.9% | **1/120** | | `all`, shipped | **496.7** | **29.19** | **87.9%** | 1/120 | | `all --joint-bucket` | 506.4 | 29.18 | 89.6% | 1/120 | | `all --joint-bucket`, cap extended to the span section | 273.7 | 28.88 | 99.4% | 1/120 | **It RAISES the bitrate at `--spans all`**, which is the tell: capping the block payload does not remove those bytes, it moves them into the span section, which draws on its own flat pipe (41.2) and is not under the cap at all. So the third row is the honest reading of "the per-frame ceiling should be joint and hard" -- and it is the worst container here, losing 0.30 dB and 233 KB/s for no change in the frames-over count, because the cap starves the pass that was buying the deadline in the first place. There is no per-frame ceiling on the whole frame record anywhere in this encoder, and **44.3 is why adding one has not been urgent**: the joint budget is enforced after the span pass by `mu`, which is a controller that pays in picture, and the byte-side ceiling it would replace is not binding. ### 44.5 An encode is 95% k-means, and that is now 2.7x faster, exactly Prompted by the user observing that this should not take a minute a scene. Profiled, a 120-frame encode was 60.6 s of which 60.8 s was two k-means runs (the rest of the encoder, rate control and the span pass included, is about a second). `VQ.assign` was all of it, and three things were on the floor, none of which changes a label: | | 1,474,560 2x2 blocks, k=256 | |---|---:| | as written | 1.83 s | | `C.T` materialised once (a view makes BLAS re-copy it per chunk) | 1.02 s | | chunk 8192 -> 2048 (the `(chunk,k)` temporary, cache not memory; 32768 is 2.80 s) | 0.81 s | | 8 threads over the chunk loop (numpy releases the GIL in both matmul and argmin) | **0.31 s** | Partitioning rows cannot change an `argmin`, so the labels are bit-identical to the serial ones and every container this encoder emits still hashes the same -- which is the assertion, not the hope: `s14_d5_all1500` re-encodes to `d13d142b...` on both sides of the change. Whole encode 60.6 s -> 29.4 s, `H.build` 60.9 -> 22.2 s. What is left is `np.add.at` in the centroid update (~5 s of 22), and taking it costs the bit-exactness, so it stays. At 0.18 s/frame the 22.8 minutes of unique scene footage is ~50 minutes of codebook training, single machine, single pass. ### 44.6 What this does NOT establish 1. **It does not re-open the c=5 vs c=9 question** (43.8.1), which is still the largest open number and still a hardware fact this tree cannot check. 2. **The 1/120 is the same 1/120** -- frame 0, the intra frame, emitted late on purpose. Nothing here moved it, and 43.8's five caveats all stand. 3. **`--spans all` remains a recommendation, not a measurement** (43.6.1), and 44.3 sharpens why it matters: it is the only lever on this side of the encoder that does anything. 4. **The pixel-exact gate now covers 37 of 120 frames**, down from 80 in session 10 (FINDINGS 36) -- the span-heavy container outgrew the 2 MB machine. The strongest test in the tree audits under a third of the window it names. That makes STATUS item 3's chunk-streaming rig load-bearing rather than optional. 5. **Two fixes, both correct, both defaulted off.** The pattern worth keeping is that the second one was found by asking whether the lever was loaded before pulling it, and 44.3 took four encodes to establish -- against a session that could have been spent making a bucket cap work. ### 44.7 No decoder at all: what a literal frame costs, and where it dies Asked by the user: does streaming raw preprocessed frames straight into video memory save the CPU? On clocks, yes -- completely. It dies on the medium, and the arithmetic is worth writing down because it also retires the last line of 42.2 still standing in the wrong units. **Two versions, and the split is the answer.** A frame is 256x192 = 49,152 pixels; 256-colour GVRAM is one pixel per WORD with the high byte discarded (42.2, `spans.py:44`, and the memory model both emulators are pixel-exact against), so a literal frame is **98,304 bytes of GVRAM writes** against a budget of 833,333 clocks = **16.95 clocks/pixel**. *1. The CPU paints it.* This is what a v7 span already is -- literal GRB555 words, preprocessed offline, copied by `movem` -- at `9.143 + 2c` clocks/pixel: | | clocks/pixel | vs 16.95 | |---|---:|---| | c = 3.906 | 16.95 | breakeven | | **c = 4.0**, the 43.1 floor | **17.14** | **misses by 1.1%** | | c = 5.0, single address | 19.14 | misses by 13% | | c = 9.0, dual address | 27.14 | misses by 60% | **A CPU-painted full-frame literal does not fit at any physically reachable price**, and it misses at the floor itself. This supersedes 42.2's "lossless fits iff `W` is about 6.5 or less", which was denominated per WORD: 6.5 clocks/word is 3.25 clocks/byte, below the 4-clock floor, so that threshold was never reachable either. FINDINGS 43 withdrew the tables downstream of the unit error but not this line; it is withdrawn here. *2. The DMAC writes device -> GVRAM and the CPU is not in the loop.* The 9.143 disappears and a pixel costs only its two wire bytes: | c | clocks/frame | % of budget | wire | 22.8 min of game | |---:|---:|---:|---:|---:| | 4.0 | 393,216 | 47.2% | 1,152 KB/s | 1.61 GB | | **5.0** single address | **491,520** | **59.0%** | 1,152 KB/s | 1.61 GB | | 9.0 dual address (the row MAME models) | 884,736 | **106.2%** | 1,152 KB/s | 1.61 GB | | 16.5 packed | 1,622,016 | 194.6% | 1,152 KB/s | 1.61 GB | **At c=5 it fits, with 41% of the frame budget left and no decoder at all.** It is defeated by delivery, not by the 68000: 1,152 KB/s is ~79% of SCSI-1 asynchronous (42.1) with nothing left for audio or seeks, and 1.61 GB is 2.3x the 0.70 GB the shipping 496.7 KB/s container already needs -- which is itself already past a CD-ROM. At c=9 it does not fit the clocks either. **The waste is specific and it is the same one the span path pays.** Because the high byte is discarded, half of every byte pulled off the disk is thrown away by the hardware on arrival: two bytes of disk per byte of picture. That 2:1 is why a span pixel costs `2c` and why 43.4's span-vs-V1 crossover sits at c=5.48. The codec is not there to save CPU -- 44.7 shows the CPU can be removed outright -- it is there to save the wire. **The one thing that would change this answer** is a packed write path into 256-colour GVRAM, two pixels per word. That halves the wire to 576 KB/s and 806 MB and puts a decoder-free player back in play. **It is NOT established either way.** The tree's basis for one-pixel-per-word is that MAME and px68k are both pixel-exact against that model, which is evidence about two emulators, not about the CRTC and the palette hardware. It is the same class of question as 43.8.1 -- a service manual or a real board settles it, an emulator cannot, and both emulators here would model a packed path identically wrong if it exists. Note this is a different transfer from the one FINDINGS 39 costed and rejected. 39 priced **memory -> GVRAM** (the DMAC replacing v6's `movem` chain out of a RAM stream buffer) and it lost by a clock. This is **device -> GVRAM**, with no RAM staging and no CPU, and it loses to the disk instead. ## 45. The strongest test in the tree was short by 83 frames, and the fix was the rig's memory (session 16) STATUS item 1 said the pixel-exact gate "needs the chunk-streaming rig, not a longer pass." It needed neither. It needed a bigger emulated machine, and the reason that was not obvious is worth more than the fix. ### 45.1 The constraint was the rig's, and the gate does not measure timing `prep_dlx.py` preloads the whole container into emulated RAM at `STREAM=0x30000` and `check.sh` ran the machine at `-ramsize 2M`, so the span-heavy gate container -- 5,261,814 B of stream, ending at 0x534BF6 -- was truncated to the prefix that fit. That was **37 of 120 frames**, down from 80 in session 10 (FINDINGS 36) as the container grew. The 2 MB was carried over from the timing rig, where it is correct: the locked target is a stock 2 MB machine. But `check.sh` runs this gate under `DLX_VERIFY_ONLY=1`, which **drops the cost anchors entirely** and asserts only pixel-exactness. A verify-only pass makes no claim about the target's memory, so it was never the 2 MB that was load-bearing here -- and preloading a whole container is unlike the shipping player at *any* size, because the player streams from disk into a ring buffer and never holds a window at once. `RIG_RAM=6` in `check.sh` (MAME's x68000 accepts 1M-12M) covers all 120 frames. ### 45.2 The raise is licensed by measurement, not by convenience Raising the emulated RAM to make a test pass is exactly the move that should be distrusted, so it was checked rather than asserted. The full timing pass -- not verify-only -- was run at `-ramsize 2M` and `-ramsize 6M`, and the **five synthetic anchors come out bit-identical**: | synthetic frame | 2M | 6M | |---|---:|---:| | all-SKIP | 40,729 | 40,729 | | all-V1 | 921,187 | 921,187 | | all-V4 | 1,376,881 | 1,376,881 | | all-RAW | 1,229,883 | 1,229,883 | | all-SPAN-64 | 506,533 | 506,533 | They sit at **different addresses** in the two layouts -- the synthetic block is placed after a 37-frame stream in one and a 120-frame stream in the other -- and still cost the same, so MAME's cycle model does not depend on `-ramsize` over this range. Every per-block constant in FINDINGS 24/30/41 is measured from these frames and is therefore unmoved by the change. ### 45.3 The 37-frame prefix was a biased sample, and the quiet end was missing The gate is now 120/120 pixel-exact on **both** cores -- MAME's 68000 and px68k's C68K. (The C68K harness never had a RAM ceiling at all: its arena is 16 MB and `RAMTOP` is defined but unused, so it was short only because it reads the blob `prep_dlx.py` truncated.) What the extra 83 frames show is that the prefix was not representative: | anchor | 37-frame prefix | full 120 | |---|---:|---:| | min non-SKIP | 25.1% of blocks, 61.9% of budget | **15.2%, 53.6%** | | median | 45.4%, 79.7% | **41.1%, 81.1%** | | p90 | 52.3%, 93.1% | **48.5%, 91.1%** | | max non-SKIP | 62.5%, 91.8% | 62.5%, 91.8% (same frame) | | C68K sequential-pass mean | 693,886 cyc, **83.3%** | **641,444 cyc, 77.0%** | The prefix **overstated the mean cost of the window by 8.2%**. It caught the worst frame -- the max is the same frame in both -- but it never saw the quiet end: the true minimum is 15.2% non-SKIP against the prefix's 25.1%, and 53.6% of budget against 61.9%. The distribution the anchors exist to sample was cut off at one end, which is the failure mode FINDINGS 25.6 warned about in a different guise: a prefix is not a sample. Note the direction. The prefix was **pessimistic**, so nothing downstream of it was flattered, and no headroom claim in this tree was resting on the missing frames. That is luck, not design. ### 45.4 What this does NOT establish 1. **The streaming path is still untested, at either RAM size.** The rig preloads; the player streams into a ring buffer. This gate proves the decoder is pixel-exact over a whole window, and says nothing about the ring buffer, the chunk boundaries, or the disk. The chunk-streaming rig STATUS item 1 called for is still unbuilt -- it was just never what the 37/120 needed. 2. **The 2 MB target is unchanged.** `RIG_RAM` is the emulated machine's memory for a verify-only pass. `span.sh` and the session-7 timing reproduction still run at 2M, and the shipping player's memory budget is untouched. 3. **The truncation guard stays.** `prep_dlx.py` still truncates and announces it, and `check.sh` still reads the count back and greps for `TRUNCATED`. A heavier container, or a lowered `RIG_RAM`, brings it straight back. 4. **The moved anchors are a re-measurement, not a regression.** No constant changed; the frames the anchors point at did. ## 46. The 256-colour mask is defeatable, and a packed path is back in play (session 16) STATUS item 2 asked whether 256-colour GVRAM has a PACKED write path -- two pixels per word rather than one pixel per word with the high byte discarded. It **The first answer was no and it was wrong** -- or rather, it was right about the default write path and missed the register that turns the masking off. 46.1-46.3 record what was established and what was measured, and are kept as written. **46.5 is the correction and it is the important part of this section.** ### 46.1 The answer is no, and the sub-word fields are PAGES, not pixels Three independent lines, none of them a service manual (see 46.4 on evidence class): 1. **A community hardware guide** (x68000-dev-guide, `docs/graphics.md`): "each pixel occupies exactly one word (2 bytes), regardless of the color mode." In 256-colour mode the word packs **2 pages** -- page 0 is mask `$00FF` at the `$C00000` alias, page 1 is mask `$FF00` at `$C80000`. 2. **A Japanese retro-computing writeup** (wizforest), independently: 1 word = 1 dot in every display mode, and in 256-colour mode only the lower 8 bits of a 1 MB region are valid. It states the masking as the well-known nuisance it was, at a *different* depth: "16色モードでは 16bit を書き込んでもハード的に マスクされてしまって 4bit しか書きこまれない" -- in 16-colour mode a 16-bit write is hardware-masked down to 4 bits. 3. **px68k's write path**, which is the mechanism the other two describe: ```c case 1: /* 256 colors */ if ( adr<0x100000 ) if ( !(adr&1) ) { /* the other byte of the word: discarded */ ... if (adr&0x80000) adr+=1; /* the $C80000 alias IS the other byte */ adr &= 0x7ffff; GVRAM[adr] = data; ``` **The decisive detail is that both pages derive `line` identically**, from `(adr&0x7ffff)>>10` -- 1024 bytes per scanline for 512 pixels. Page 0 and page 1 are the two bytes of one word **at the same screen coordinate**. The same holds in 16-colour mode, where `page = (adr>>17)&0x0c` selects one of four nibbles of the word: four pages, one coordinate. There is **no graphics mode in which one 16-bit word holds two horizontally adjacent pixels.** ### 46.2 The near-miss is worth writing down so it is not re-derived Page 1 has its own scroll register, so scrolling it one pixel relative to page 0 would put its byte at screen x+1 while page 0's sits at x -- two adjacent screen pixels from one word. It does not work, and the arithmetic is why: page 1 stores a byte for **every** coordinate, not every other one, so to let page 0 show through on alternate columns you must write page 1's transparent index there. That is the same byte count. 1024 bytes per row still buys ~512 screen pixels. The 2:1 is structural, not an addressing accident. **So FINDINGS 44.7 stands unchanged.** The decoder-free player still needs 1,152 KB/s and 1.61 GB, and is still killed by the medium. The `2c` span pixel, the c=5.48 span-vs-V1 crossover, and every figure resting on two disk bytes per picture byte are unmoved. ### 46.3 But the text plane is 4bpp PLANAR, and that is 4x denser on the wire The tax is a property of the *graphics* planes. The X68000's text plane is not laid out that way at all -- px68k's `TVRAM_Write` addresses **four planes at `0x20000` stride**, each 0x20000 = 131,072 B = 1024x1024 **bits**. That is 4bpp planar: **0.5 bytes per pixel**, against 2.0 for 256-colour graphics. The wire arithmetic, and it is only arithmetic: | surface | B/pixel | frame (256x192) | at 12fps | 22.8 min of game | |---|---:|---:|---:|---:| | 256-colour graphics, literal (44.7) | 2.0 | 98,304 | 1,152 KB/s | 1.61 GB | | **shipping DLX3 container, compressed** | -- | -- | **496.7 KB/s** | **0.70 GB** | | **4bpp planar text plane, literal** | **0.5** | **24,576** | **288.0 KB/s** | **0.40 GB** | **An UNCOMPRESSED 16-colour frame is 42% cheaper on the wire than this project's compressed 256-colour stream**, and it needs no decoder at all -- the planar conversion is an encoder-side transform, so the disk delivers plane words that go straight out. On clocks it is not close either: 24,576 bytes/frame is `24,576c`, which at c=5 is 122,880 clocks = **14.7% of a 12fps budget**. **It was measured the same session, and it is dead.** `tools/analysis/18_text_plane_16col.py` over the 120-frame `singe` window, PSNR against the 24-bit source, generous to the 16-colour side on every axis the hardware allows -- per-frame palettes (the text palette is 16 entries; reloading it is 16 words a frame, nothing against 833,333 clocks) which the 256-colour path *cannot* use, because its codebooks are indices into a scene-wide palette: | | mean PSNR | min | max | |---|---:|---:|---:| | 256 colours, scene palette (the tree's) | 31.33 | 27.08 | 34.08 | | 256 colours, per-frame palette | 34.08 | 32.19 | 38.32 | | 16 colours, scene palette | 23.17 | 17.36 | 25.87 | | **16 colours, per-frame palette** | **25.49** | 22.99 | 28.48 | **256 -> 16 costs 5.84 dB at each side's best.** Against the shipping container's **29.19 dB at 496.7 KB/s**, a 16-colour literal delivers **25.49 dB at 288.0 KB/s** -- **3.70 dB worse for 58% of the bitrate.** A codec that buys 3.70 dB for 1.72x the bytes is doing its job; the wire saving does not pay for the colours. **Closed.** The user's call was to drop the 16-colour direction outright, and the number agrees with it, so the text plane is not pursued. FINDINGS 7's 256-colour claim stands, and it now stands on a measurement rather than on preference. Two honest notes on that measurement: - **The dither row is void.** A Floyd-Steinberg run was included and came out *bit-identical* to the undithered one, which means PIL ignored `dither=` under `MEDIANCUT` rather than that dither is free. It is left out of the table. It does not change the conclusion -- dither lowers PSNR by construction, and the lead was already 3.70 dB short. - **Everything else about the path stayed unestablished and now stays that way**: TVRAM wait states (every `c` in this tree is a GVRAM figure), the text plane's geometry and priority against the graphics planes, and the fact that a planar word spans 16 pixels of one bitplane, so VQ blocks and v7 spans -- both chunky -- would not survive the change unaltered. None of it was worth measuring once the colour cost came in. ### 46.4 Evidence class, stated plainly 46.1 is **secondary documentation plus an emulator's mechanism**, not primary. No service manual, CRTC databook, or real board was consulted. What changed since 44.7 is the *kind* of evidence: 44.7 rested on MAME and px68k both being pixel-exact against one-pixel-per-word, which is evidence about two emulators that could be identically wrong. Now two independent documents describe the same mechanism -- sub-word fields are pages sharing a coordinate -- and px68k's code implements exactly that mechanism, including the `$C80000` alias landing on the adjacent byte. Agreement on a mechanism is much harder to get wrong by accident than agreement on an output. It is still not a board. STATUS item 3 (single- vs dual-address, 43.2/43.3) is unaffected by any of this and remains the largest open hardware fact. ### 46.5 CORRECTION: CRTC R20 bit 11 turns the masking off 46.1 concluded there is no packed write path. That conclusion was drawn from px68k's `GVRAM_Write` and two documents describing the default behaviour, and it **missed a register bit that both emulators implement**. MAME's `x68k_crtc_device::gvram_w` shows it first: ```c if (m_reg[20] & 0x0800) /* "G-VRAM set to buffer" */ { if (offset < 0x40000) m_gvram_write_callback(offset, data, mem_mask); /* FULL WORD, unmasked */ } else switch (m_reg[20] & 0x0300) { case 0x0100: /* 256 colour */ if (offset < 0x40000) m_gvram_write_callback(offset, data & 0x00ff, 0x00ff); else if (offset < 0x80000) m_gvram_write_callback(offset - 0x40000, (data & 0x00ff) << 8, 0xff00); ``` The `case 0x0100` arm confirms 46.1 exactly -- `offset - 0x40000` is the **same word, other byte**, and `data & 0x00ff` throws the CPU's high byte away on both aliases. But the `m_reg[20] & 0x0800` arm bypasses the depth switch entirely and writes the full 16 bits. **px68k has the identical bit**, which is what makes this a mechanism and not a MAME quirk: `if (CRTC_Regs[0x28]&8)`, commented `65536モードのVRAMアクセス （Nemesis用）` -- "65536-mode VRAM access, for Nemesis". px68k's `CRTC_Regs` is byte-indexed, so `[0x28]` is the **high byte of R20** and bit 3 of it is bit 11 of the register. Same bit, same effect, two independent implementations, and a named shipping game that used it. **So the 2:1 tax is a property of the default write path, not of the memory.** ### 46.6 A contiguous packed layout, derived and NOT yet tested The second thing 46.1 missed is that the two 256-colour pages have **independent scroll registers**. px68k's `Grp_DrawLine8(int page, int opaq)` indexes `GrphScrollX[page*8]` and `GrphScrollY[page*8]`, selects the byte within the word with `add esi, ecx` (page 0 -> low, page 1 -> high), and takes an `opaq` flag -- so the pages composite with transparency and can be offset from each other. 46.2 dismissed interleaving on byte count, and that dismissal assumed a 1-pixel scroll. **Scrolling by 128 instead makes the used words contiguous**, which is the whole difference: - GVRAM row stride is fixed at 1024 bytes = 512 words (`shl esi, 10`). - Write words 0..127 of each row, **unmasked, full 16 bits** (R20 bit 11). - Page 0, unscrolled: `page0[i]` displays at screen column `i` -> columns 0..127. - Page 1, X-scrolled by **+128**: `page1[i]` displays at column `i+128` -> columns 128..255. - Page 1 opaque and above page 0, so page 0's stale storage at 128..511 is covered; page 1's storage at 128..511 displays at 256..383, which is off the edge of the **real 256x256 mode this project already uses** (FINDINGS 23). **128 contiguous words carry 256 pixels: 1.0 byte per pixel, against 2.0.** No transparency mask to maintain, no stride for a DMAC to skip, and the writes are `movem`-shaped. If it holds, it is exactly the halving 44.7 named: | | B/pixel | frame | at 12fps | 22.8 min | |---|---:|---:|---:|---:| | 256-colour, default masked path | 2.0 | 98,304 | 1,152 KB/s | 1.61 GB | | **packed via R20 bit 11 + page scroll** | **1.0** | **49,152** | **576 KB/s** | **0.81 GB** | **This is a derivation, not a result.** What is CONFIRMED is the register bit (both emulators, plus a named game) and the per-page scroll and opacity (px68k's draw path). What is DERIVED and untested is the layout above: whether R20 bit 11 coexists with 256-colour *display* rather than forcing the 65536-colour interpretation, whether the video controller's priority and transparency registers can put page 1 over page 0 the way this needs, and what the 256-wide screen does to page 1's off-edge storage. **Unlike 43.2 and 43.8.1, this one the tree CAN answer.** It is a display-model question, both emulators implement the mechanism, and the rig already screenshots and compares pixel-exactly (`tools/bench/verify_frame256.py`). It is a register setup and a snapshot, not a service manual -- and if it holds it halves the wire for every path in this project, the shipping codec included. ## 47. The packed layout works on both emulators, and they disagree about what it costs (session 16) 46.6 derived a 1.0 byte/pixel layout and did not test it. It has now been built and run on **both** emulators. **It renders correctly on both.** The two disagree on two register semantics, and one of those disagreements decides whether the thing is usable. ### 47.1 The write path, measured directly `tools/bench/probe_packed.lua` writes one word and reads the two page aliases back, under MAME: | R20 | wrote | raw word | page 0 (low byte) | page 1 (high byte) | |---|---|---:|---:|---:| | 0x0110, bit 11 = 0 | `AB5C` | `005C` | `5C` | `00` | | **0x0910, bit 11 = 1** | `AB5C` | `AB5C` | `5C` | **`AB`** | **That is the 2:1 tax, and its off switch, in one table.** Masked, the CPU's high byte is destroyed. In buffer mode one word write lands two picture bytes. 46.5's reading of `gvram_w` is confirmed by experiment, not just by code. ### 47.2 The packed layout renders correctly, on both `tools/bench/show_frame256_packed.lua` (MAME) and `tools/bench/gvpack` (px68k): - page 0, opaque bottom, unscrolled -> screen columns 0..127 - page 1, transparent top, X-scroll **384** -> columns 128..255, because column `c` fetches `page1[(c+384) & 511]` - words 0..127 of each row carry both halves: `(right << 8) | left` - words 128..511 zeroed **once** -- page 1's storage at 384..511 sits under columns 0..127 and must read 0 so the opaque page 0 shows through. Static setup, not per-frame payload. - the blob is built `--pack-transparent`: index 0 is the transparency key, so it never appears in the picture and black lives at 255. | | result | palette ceiling | |---|---|---:| | MAME, `verify_frame256.py` | **256x192 pixel-exact, letterbox true black** | 40.83 dB | | px68k, `verify_gvpack.py` | **256x192 index-exact, letterbox on 255** | 40.83 dB | **Per-frame payload: 128 words/row x 192 rows = 24,576 words = 49,152 bytes for 49,152 pixels. 1.0 B/pixel, against 2.0.** `tools/bench/gvpack` links px68k's real `x68k/gvram.c` -- the address decode, the bit-11 write path, the page-byte selection, the scroll wrap and the index-0 transparency test are px68k's own code, the way `tools/bench/c68k` links its CPU core. The only mirrored part is `windraw.c`'s twelve-line page-ordering dispatch, which is SDL-bound; it is quoted verbatim in `pick_order()`. **Four negative controls, because a test that cannot fail proves nothing:** | control | expected | got | |---|---|---| | ordinary unpacked 2.0 B/px path | pass | pass | | packed, **bit 11 OFF** | fail | fail: right half is 24,576 px of index 0 | | packed, **page-1 scroll removed** | fail | fail: 49,073 px differ | | packed, priority `vc1=0x00` | fail (per MAME) | **PASS on px68k** -- see 47.3 | ### 47.3 Disagreement 1: the priority register, when the fields are equal Video controller R1 (`0xE82500`) decides which page composites on top. | `vc1` | MAME | px68k | |---|---|---| | `0x0000` | page 1 **not shown** -- right half black, 24,576 px differ | page 0 on top **transparently** -- renders correctly | | `0x0002` | page 1 on top, **correct** | page 1 on top, **correct** | They agree at `0x0002` and that is what the layout uses, so the result stands on a setting both model identically. But the packed layout's correctness rests on a register the two emulators do not model the same way, and neither is authority. ### 47.4 Disagreement 2: does buffer mode BLANK the display? -- and this one decides it `tools/bench/probe_bit11_blank.lua` is the known-good 256-colour test with **one line added**, setting bit 11: - **MAME: the screen goes fully black.** Max channel 0, zero non-black pixels. Buffer mode is a write *window*, not a display mode -- which is why the working test clears bit 11 after painting. - **px68k: it does not blank.** `Grp_DrawLine8` never reads `CRTC_Regs[0x28]`, and `gvpack --keepbuffer` renders the frame correctly with the bit still set. **This is the question the packed path lives or dies on.** If MAME is right, the graphics layer is blanked for the whole time the CPU or DMAC is painting, and a 12fps full-frame player would show black for whatever fraction of each frame the paint takes. If px68k is right, the packing is free. Both are plausible readings of "G-VRAM set to buffer", and px68k's own comment -- `65536モードのVRAMアクセス （Nemesis用）` -- says the bit exists for a game that blasted graphics through it, which is at least consistent with the write-window reading. **It is a hardware fact, and it is now the cheapest high-value one outstanding** -- cheaper than 43.2, because a single real board plus the two-line probe above settles it, and because the answer moves more numbers. ### 47.5 What it would be worth, DERIVED Arithmetic on measured constants, not measurements. **Every line below is void if 47.4 goes MAME's way**, and the mode-decision cost model (44.3, 43.1) would need re-deriving from scratch either way. | | default masked | **packed** | |---|---:|---:| | bytes/frame into GVRAM | 98,304 | **49,152** | | word writes/frame | 49,152 | **24,576** | | wire at 12fps | 1,152 KB/s | **576 KB/s** | | 22.8 min of game | 1.61 GB | **0.81 GB** | | DMAC device->GVRAM, c=5 | 59.0% of budget | **29.5%** | | CPU-painted literal, c=5 | 19.14 clocks/px (**misses** by 13%) | **9.57 (fits, 44% spare)** | | CPU-painted literal, c=9 | 27.14 (**misses** by 60%) | **13.57 (fits)** | The CPU-painted row is the one that overturns something. 44.7 concluded "a CPU-painted full-frame literal does not fit at any physically reachable price, and it misses at the floor itself." Packed, one `movem` word carries two pixels, so the per-pixel cost becomes `(9.143 + 2c)/2 = 4.571 + c` -- and it fits at c=5 **and** at c=9. That conclusion is withdrawn, conditionally on 47.4. ### 47.6 What this does NOT establish 1. **Correctness was tested, cost was not.** Both harnesses write GVRAM directly -- MAME through Lua's address space, `gvpack` by calling `GVRAM_Write`. Neither runs 68000 instructions, so no clock in 47.5 is measured. The `movem` shape of the packed writes is an assumption. 2. **The DMAC has not been near this.** 44.7's device->GVRAM transfer in buffer mode is untested, and 43.2's single- vs dual-address question sits underneath every `c` in 47.5. 3. **One frame, not a stream.** A static frame was painted and snapshotted. Nothing here exercises per-frame toggling of bit 11, and if MAME is right about blanking, that toggling is the whole problem. 4. **The codec was not considered.** VQ blocks and v7 spans address chunky pixels; under the packed layout a word spans two columns 128 apart. Whether the existing codec survives that is untouched -- 47 is about a literal frame. 5. **Two of 46.6's three assumptions held, one was wrong.** R20 bit 11 does coexist with 256-colour display (after clearing it), and the off-edge storage behaves. The priority guess was wrong: 46.6 assumed page 0 on top; it is page 1. ## 48. The blanking disagreement is not symmetric, and the paper trail favours MAME (session 17) 47.4 filed the blanking question as two emulators disagreeing, and called both readings of "G-VRAM set to buffer" equally plausible. **They are not equally plausible, and the two implementations are not making the same kind of statement.** Nothing here is a board, so 47.4 is not closed -- but the prior moves, and it moves against the packed layout. ### 48.1 px68k is silent, not dissenting `grep -a` matters here: `x68k/gvram.c` carries EUC-JP comments, so a plain `grep` treats it as binary and reports **no matches at all** for any pattern. Read with `-a`, R20's high byte appears in exactly one file: $ for f in x68k/*.c x11/*.c; do n=$(grep -ac "CRTC_Regs\[0x28\]" $f); ... x68k/gvram.c: 6 and all six are the address decode -- lines 150/153/158 inside `GVRAM_Read`, 211/221/225 inside `GVRAM_Write`, where `CRTC_Regs[0x28]&8` is R20 bit 11 and line 211 carries the comment `65536モードのVRAMアクセス（Nemesis用）`. **No px68k display code reads the bit anywhere.** `Grp_DrawLine8` and `x11/windraw.c` never consult it. So px68k does not model buffer mode as non-blanking; it does not model the display side of buffer mode **at all**. Its "no" is an omission. MAME's "yes" is the opposite -- a deliberate, commented claim, made twice: x68k_v.cpp:407 if(m_crtc->gfx_layer_buffer()) // if graphic layers are set return false; // to buffer, they aren't visible x68k_v.cpp:766 if((m_video.gfx_pri == priority) && !m_crtc->gfx_layer_buffer() && ... and the parallel bit 12 is modelled the same way for the text layer (`x68k_v.cpp:756`, `!m_crtc->text_layer_buffer()`). Someone implemented a semantic on purpose. **An assertion and a silence are not a tie.** ### 48.2 The register table names the bit "for display / for buffer" Sharp's own R20 bit map, transcribed on Data Crystal's X68k IOMAP: | bit | name | %0 | %1 | |---|---|---|---| | 12 | T-MEM | `表示用` | `バッファ用` | | **11** | **G-MEM** | **`表示用`** | **`バッファ用`(bit 10〜8 は無効)**
`(G-VRAM が 65536 色表示時と同じ構造になる)` | | 10 | SIZE | 512x512 | 1024x1024 | | 9-8 | COL | %00 16 / %01 256 / %11 65536 | | Two things in that one row: 1. **The bit is named "for display" against "for buffer"** -- not "16-bit write" or "unmasked access". The naming is MAME's reading. 2. **`bit 10〜8 は無効` -- the colour-mode field goes invalid.** COL is what the display side decodes a plane structure from. A layer whose colour mode is undefined has nothing to render with, which is a *mechanism* for blanking rather than a restatement of it. The counter-reading survives, and it is the parenthetical: the doc says the structure becomes the 65536-colour one, and does **not** say the screen goes dark. That is why this is a shifted prior and not a result. ### 48.3 The cost of the MAME branch, DERIVED, and it is not a partial blank 47.4 left "measure what fraction of a frame the paint takes" as the fallback. Bit 11 only has to be set across the GVRAM writes, so the blank interval is the paint, not the frame. The measured blit is **53.6% of the frame budget** (session 9) unpacked; packed halves the word count, so the floor is ~27% and the ceiling ~54% depending on how much of the blit is stores. **Either end is fatal for this content.** The graphics layer would be visible between roughly half and three-quarters of each frame at 12fps, with the black interval locked to frame rate -- a 12 Hz strobe over the whole picture, not a tear or a partial band. And the packed layout has **no page left to flip to**: both 256-colour pages carry picture, which is the entire point of it. There is no version of the MAME branch where the packing is merely expensive. ### 48.4 px68k cannot testify about SCSI at all (bears on 43.2) Checked while looking for a second opinion on single- vs dual-address. **px68k does not emulate the MB89352.** `x68k/scsi.c` is 81 lines: it synthesises a 64-byte fake CZ-6BS1 boot ROM at `$EA0020` (the `Human68k` signature, the IOCS `$F5` vector, `move.b d1,$e9f800`) and traps the IOCS call on the host. Its own header says so -- `SCSI IOCS を特殊処理で対応。SPCはエミュレートしない`. So the "second emulator" method that settled 46/47 **is not available for 43.2**, and never was. MAME models the dual-address row and has no DACK path; px68k models no SPC. Item 2 needs the CZ-6BS1's `scsiexrom.bin` (8 KB, CRC `7be488de`, absent here) disassembled for its DMAC DCR programming -- or a schematic. It does not need another emulator. **And the field to read is now pinned to the primary source.** MC68450 datasheet (Motorola ADI1216, Jul-89 printing), section 3.6.1 -- the DCR field order is `XRM | DTYP | DPS | PCL`, MSB to LSB, and DTYP is the answer in one two-bit field: | DTYP | datasheet text, verbatim | addressing | |---|---|---| | `00` | `M68000 Compatible, Explicitly Addressed` | **dual** | | `01` | `M6800 Compatible, Explicitly Addressed` | **dual** | | `10` | `Device with ACK, Implicitly Addressed` | **single** | | `11` | `Device with ACK and RDY, Implicitly Addressed` | **single** | and 3.6.1.2 states the equivalence outright rather than leaving it to be inferred: > For M68000 type devices, the DMAC will use a **dual address transfer > protocol** by running M68000 type bus cycles to transfer data to or from the > device registers and a second bus cycle to complete the operand transfer from > or to memory. [...] In the remaining two device protocols, the DMAC asserts > the acknowledge signal to **implicitly address the device during a single > address transfer** while it is explicitly addressing a memory location. So 43.2's 5.0-vs-9.0 clocks/byte is decided by two bits in one byte the CZ-6BS1's boot ROM writes at init. (Bit *positions* within DCR are the conventional 7-6/5-4/3/2-0 split; the datasheet's own bit-number row did not survive OCR, so treat the positions as unconfirmed and the field order and encodings as quoted.) **MAME confirms the negative half of this from the other side:** `hd63450.cpp` contains **no DTYP handling at all** -- the only device-shape field it decodes is `ocr & 0x30` (operand size). It cannot express an implicitly-addressed device, which is why 43.2 was right that MAME settles nothing here. ### 48.5 One thing the hunt did confirm independently px68k's `kaiseki.txt` (the author's own analysis notes, 2014/2/14), on GVRAM structure, unprompted and predating any of this: 256色の場合は、Page0の(0,0), Page1の(0,0), Page0の(1,0), Page1の(1,0)... と交互に並ぶ。 Page 0 and page 1 bytes alternate within the word at the *same* coordinate. That is 46.1's page-not-pixel finding from a third source, and it is the premise the packed layout is built on. **The layout's premise is solid; only its visibility is in doubt.** ## 49. The streaming path, built and run: contiguity is the constraint, and the shipping rate does not fit the pipe (session 18) STATUS item 3 has been open since session 7, and 45.4.1 stated the gap in as many words: **the gate proves the decoder is pixel-exact over a whole window and says nothing about how the bytes get to it.** `tools/bench/decode.lua` preloads 5,261,814 B of container into emulated RAM and lets `a0` walk through all of it. The shipping player never holds a window at once. That rig is now built. `src/player/stream.s`, `tools/bench/prep_stream.py` and `tools/bench/stream.lua` decode the gate container **out of a bounded ring**, with a modelled SCSI pipe as the producer, and the container living in a HOST file rather than in emulated RAM. ### 49.1 The result: pixel-exact from a ring one twentieth the size of the stream | ring | machine | wraps | mean hole | result | |---|---|---:|---:|---| | 256 KB | **stock 2 MB** | 18 | 14.7 KB (5.7%) | **120/120, final frame pixel-exact** | | 128 KB | stock 2 MB | 37 | 10.6 KB (8.3%) | 120/120, pixel-exact | | 96 KB | stock 2 MB | 54 | 15.6 KB (16.2%) | 120/120, pixel-exact | | 80 KB | stock 2 MB | 60 | 8.9 KB (11.2%) | 120/120, pixel-exact | | 64 KB | stock 2 MB | 107 | 23.4 KB (36.6%) | 120/120, pixel-exact | | 48 KB | stock 2 MB | 111 | 8.9 KB (18.5%) | 120/120, pixel-exact | Verified by `tools/bench/verify_decode.py`, the same comparison that gates `decode.s`: the last frame against `tools/encoder/dlx.py`'s reconstruction, and because a SKIP block is a claim about the previous frame still being in GVRAM, the last frame is only right if all 120 were. **A side effect worth naming: the rig's RAM ceiling is gone.** FINDINGS 44.6.4 audited 37/120 frames because the container did not fit 2 MB, and 45 raised `RIG_RAM` to 6 MB to fix it. The streaming rig holds ~256 KB of stream and reads the rest from the host, so **a stock 2 MB machine runs the whole window** — and the machine it runs on is now the machine the player targets, rather than a rig-shaped one. ### 49.2 The constraint is CONTIGUITY, and a byte-counting simulation cannot see it `09_buffer_sim.py` asked whether cumulative supply ever falls behind cumulative demand, in bytes, and FINDINGS 21 answered "zero required prefill". That test is necessary and not sufficient. The block loop and the span chain read the stream with a monotonically increasing `a0` and **no bounds check anywhere** — `move.l (a0)+,d0`, `lea MODEB(a0),a0`, eleven unrolled `movem.l (a0)+`, a `move.b (a0)+` per block index. None of it survives an address that wraps mid-record. So the ring needs the **whole next record resident AND contiguous**, not merely enough bytes by the deadline. Those are different conditions and only the second one is a byte count. `tools/analysis/19_ring_stream.py` models the ring's addresses rather than its occupancy. ### 49.3 `aligned` beats `split`, and it is not close Two policies can give the reader a contiguous record. Both columns below are for **`s14_d5_all1500`**, the shipping candidate, in a 256 KB ring — the costs scale with the container's record sizes, so they must be quoted per container: | policy | mechanism | RAM cost | CPU cost | |---|---|---:|---:| | **`aligned`** | producer refuses to start a record it cannot finish; leaves a hole, restarts at 0 | 23.4 KB mean hole = **9.1%** of the ring | **0** | | `split` | records wrap; ring's first MAXREC bytes mirrored into a shadow past its end | 0 | **46,394 clk/frame = 5.57% of the frame budget, forever** | For the lighter gate container `rc_fr_singe_scsi_span` the same trade is **5.7% of the ring against 3.64% of the frame budget** — same direction, same verdict, smaller numbers. The decoder already spends **77.0% of the budget on the mean frame and 91.1% at p90** (FINDINGS 45). `split` puts p90 at **96.7%**. RAM is the thing this machine has 2 MB of; clocks are the thing it has none of. `aligned` also needs a per-record **index** on the fill side — and a branching laserdisc game needs one anyway to seek to a branch point. **The policy that costs no clocks reuses a structure the player cannot avoid.** The third option — teach the block loop to wrap its own reads — is the expensive one, and not because of the branch. A bounds test lands *inside* the instruction sequences FINDINGS 30.4 and 40 fitted their constants to, so it does not cost a compare: it costs **every span and per-block figure in the tree being re-measured**. ### 49.4 Two independent implementations agree exactly The Python simulation predicts the ring's behaviour from record sizes alone; the Lua producer drives a real 68000 through MAME. They agree to the digit, and at two ring sizes rather than one -- so it is not a coincidence of a single tiling: | ring | | wraps | mean hole | usable ring | |---|---|---:|---:|---:| | 256 KB | `19_ring_stream.py` (from record sizes) | 18 | 14.7 KB | 94.3% | | 256 KB | `stream.lua` (driving the 68000) | **18** | **14.7 KB** | **94.3%** | | 128 KB | `19_ring_stream.py` | 37 | 10.6 KB | 91.7% | | 128 KB | `stream.lua` | **37** | **10.6 KB** | **91.7%** | They share no code. This is the same class of check as FINDINGS 46's — agreement on a *mechanism* rather than on an output. ### 49.5 The shipping candidate does not fit the 488 KB/s pipe, and nothing was checking `s14_d5_all1500` is the session-14 candidate: **29.19 dB at 496.7 KB/s** (43.6). The pipe constant this tree has simulated against since session 2 is **488 KB/s**. Those two numbers have never been put side by side. wire demand 496.7 KB/s - pipe 488.0 KB/s = 8.7 KB/s OVER, on the MEAN This is **not a burst a ring absorbs**. The deficit grows 744 B per frame for as long as the scene runs — 87 KB over the 120-frame window, **523 KB per minute of play**. No ring size fixes a sustained overrun, and quoting the window's 118.4 KB "required prefill" for it would be the most flattering possible way to state it. **Why it was never caught.** 42.1 established that 488 was never a bus figure and that the binding resource is *clocks*, not KB/s — so the rate controller was built to bind on `decode + c*bytes` and has **no pipe term at all**. That was a defensible decision. What was not decided is that FINDINGS 21's buffer sizing, and its "zero required prefill", would keep standing on a constant the design had stopped enforcing. Item 4 has been open since session 7 for exactly this reason. **The useful output is a requirement on the medium, not a verdict.** Since 488 is unmeasured folklore and the intent is to measure a BlueSCSI directly, the tool reports the threshold to measure *against*: | container | wire | **zero-prefill pipe** | vs 488 | |---|---:|---:|---:| | `s14_d5_all1500` (the candidate) | 496.7 KB/s | **513.2 KB/s** | +5% | | `rc_fr_singe_scsi_span` (the gate) | 446.1 KB/s | **451.4 KB/s** | -8% | **513.2 KB/s is now a hardware acceptance test**, and it is 33% of SCSI-1's asynchronous rating and 10% of its synchronous one (42.1). It is very likely met; it has never been shown to be met. ### 49.6 The rig measures ARRIVAL, and the first version of it measured the wrong thing `stream.s` has no frame clock — it asks for the next record the instant it finishes the last. So it outruns any finite pipe, and its spin counter reports **91 of 120 frames "stalled" at a pipe the same run shows is fast enough**. A shipping player waits for vblank and spends that same time idle. Reporting that count as an underrun would have been a false finding of exactly the shape this project keeps filing. The rig now records the emulated time at which each record becomes **resident** and checks it against a 12 fps deadline, which is a question about arrival alone and does not need the decoder paced: | pipe | decoder waited | **records late** | worst | **required prefill** | |---|---:|---:|---:|---:| | unlimited | 0/120 | **0/120** | — | 0 | | 520 KB/s | 85/120 | **0/120** | — | 0 | | 488 KB/s | 91/120 | **1/120** | 4.9 ms (0.06 fr) | 2.3 KB | | 460 KB/s | 97/120 | **2/120** | 9.7 ms (0.12 fr) | 4.4 KB | The 2.3 KB at 488 against the simulation's 0.0 KB is a modelling difference, not a disagreement: the Lua producer delivers in **whole records**, the simulation in **512-byte sectors**, and whole-record granularity is the more conservative of the two by up to one record's worth of latency. ### 49.7 What this does NOT establish 1. **The DMAC's clock debit is not modelled.** The pipe here is a constant byte rate on the emulated clock. It is honest about *arrival order and residency*, which is what a ring manages, and says nothing about the clocks the DMAC steals from the 68000 while it delivers (43.2, and `W` is still undecided). **A zero-late result from this rig means "the bytes were in time", NOT "the frame fits".** 2. **Buffer stall-tolerance at a branch point is still untested.** Because the decoder free-runs, the ring never backs up, so the ring-size sweep in 49.1 tests *wrap correctness* at each size and **not** the buffering that a seek needs. At 64 KB the mean hole is 36.6% and effective capacity is one record — it is single-buffered, and it passes anyway. Do not read 48 KB as a viable player buffer. 3. **The producer is not an MB89352.** No sector-level command overhead, no arbitration, no seek. `19_ring_stream.py` quantises to 512 B; the rig does not. 4. **The hole is a tiling effect and is not monotonic in ring size** — 96 KB wastes more than 80 KB does. It depends on how record sizes tile the ring, so a ring should be sized against the *measured* hole for the container it will carry, not against a fraction. 5. **An unexplained cross-emulator gap, left open rather than explained away.** The ring pass decodes the gate container at **561,532 cycles/frame under MAME**. FINDINGS 45's figure for the same container is **641,444 cycles/frame, and it is px68k's C68K core**, not MAME's -- so the two are not comparable and the 12% between them is not evidence of anything yet. Getting MAME's own full-pass number for this container needs a `decode.lua` timing run that did not complete inside 25 minutes on this host; it was killed rather than left to race another MAME job, which is how session 18 lost its first attempt at it. **No figure in this section rests on the comparison.** Whoever picks it up: run `decode.lua` on `rc_fr_singe_scsi_span.dlx` with nothing else touching `tmp/`, and compare its "full 120-frame pass" against 561,532. If they agree, the C68K/MAME delta is the thing to explain; if they do not, `stream.s`'s frame loop is. 6. **`decode.s` is unchanged, and provably.** The block loop and span chain were moved to `src/player/frame.i` and the constants to `geom.i` so both front-ends assemble from literally the same bytes; `decode.s` still assembles to the same **1,296 bytes** it did before the split, and `prep_dlx.py` still emits a byte-identical blob after the loader maths moved to `tools/bench/dlxload.py`. Both are asserted in `check.sh`. ## 50. The pipe constant is retired (session 18, USER DECISION) **USER DECISION, after 49.5: remove the delivery-rate constant from the repo as a live number.** 42.1 established in session 13 that it was never a bus figure — a user-supplied "4 Mbps" with no recorded provenance, 10% of SCSI-1's asynchronous rating — and 29.5 item 3 had carried "confirm the 4 Mbps figure" as an open item since session 7. It was never confirmed. It was also never removed, and 49.5 is what that cost: the shipping candidate ran 8.7 KB/s over it for five sessions with nothing in the tree comparing the two. ### 50.1 What was actually wrong was the DEFAULT, not the number The number being unmeasured was known and written down. What kept it load-bearing was that **six tools defaulted to it** — `12_span_tradeoff.py`, `14_dmac_chain.py`, `16_span_roundtrip.py`, `17_span_delivered.py`, `19_ring_stream.py` and `tools/bench/stream.lua`. A default is how a figure gets into a table without appearing in the sentence that reports the table. Every span figure in FINDINGS 30–41 was scored against it; none of them had to say so. **All six now take a REQUIRED argument with no fallback.** A tool that cannot run without being told the rate cannot quietly assume one, and a result that had to name its rate to exist is a result whose provenance travels with it. A small confirmation of the same point fell out of doing it: writing the new help text broke `--help` on four of the tools -- the text said "10%" and argparse read it as a format spec -- and **nobody would have noticed**, because none of these tools had ever been run with `--help` in this tree. The removal was the first thing that made them state their own arguments out loud. That is the transferable part: **an unmeasured constant is not made safe by documenting that it is unmeasured.** 42.1 documented it perfectly and it went on silently underwriting tables for five more sessions. It is made safe by deleting the default. ### 50.2 What survives, and why it is not the same thing `GATE_SPAN_KBPS` in `tools/bench/check.sh`. The gate container was **encoded** with it, and every per-block and span constant in FINDINGS 41/43/45/49 is fitted to that container. Changing it is a re-encode plus a re-measurement of all of them, not an edit. It is a **container recipe, not a delivery claim**, and check.sh says so at the point of use. The distinction is the whole reason it can stay: nothing reads a medium's throughput out of it. ### 50.3 What replaces it: a requirement, not a constant `19_ring_stream.py` reports the **zero-prefill pipe** — the rate a medium must clear for a given container to need no prefill at all: | container | wire demand | **zero-prefill pipe** | |---|---:|---:| | `s14_d5_all1500` (the candidate) | 496.7 KB/s | **513.2 KB/s** | | `rc_fr_singe_scsi_span` (the gate) | 446.1 KB/s | **451.4 KB/s** | Its rate sweep is now anchored to each container's own wire demand (0.90x to 2.00x) rather than to a fixed list of absolute rates, so it privileges no constant and stays meaningful for any container. **This is a number to MEASURE A MEDIUM AGAINST, not one to design on**, which is the difference that mattered. The BlueSCSI has never been benchmarked on this machine and the intent has always been to measure it directly; it now has a threshold to be measured against. ### 50.4 What this does NOT do 1. **It does not measure anything.** The delivery rate remains unknown. The tree is now honest about that rather than carrying a placeholder — which is a smaller claim than it sounds, and the right one. 2. **It does not re-derive the tables that were scored against the old figure.** FINDINGS 30–41's span figures stand as measured *at that rate*; what changed is that nothing new can be scored there without saying so. Anything that needs a delivery rate to mean something is now waiting on a measurement, and should be. 3. **It does not touch the gate container**, so the green light and every constant fitted to it are unmoved. `./tools/bench/check.sh` is **ALL GREEN** after the removal. ## 51. Pacing the decoder: seek slack is accumulated, not owned (session 19) STATUS item 4, open since session 7 in one form or another and sharpened by 49.7.2. `tools/bench/stream.lua` decodes 120 frames out of a bounded ring and the pass is pixel-exact at every ring size down to 48 KB — and that result could not be read as a statement about buffering, because `src/player/stream.s` has no frame clock. It asks for record *i* the instant it finishes record *i-1*, so it outruns any finite pipe, the ring never backs up, and the producer's overlap test is never the thing that refuses a placement. **A ring-size sweep under those conditions tests wrap correctness at each size and nothing else.** The rig now has a frame clock. `PACE`/`PACEON` (`$18034`/`$18038`) are written by the producer — vblank or an MFP timer in the player — and frame *i* may not start before tick *i*. `PACEON=0` leaves the loop free-running and is what the green light's wrap gate still uses, so 49's figures are unmoved. ### 51.1 The ceiling: what a ring is worth once it is full Every cell below is a full 120-frame decode on MAME's 68000, pixel-verified against `tools/encoder/dlx.py`, on the gate container (`rc_fr_singe_scsi_span`, 446.1 KB/s wire, 36.5 KB mean record). "Ceiling" is the largest number of whole records resident and unconsumed, i.e. **the frames the decoder could still draw with delivery stopped dead**. Pipe `0` is unlimited, which isolates the ring's own capacity from the rate. | ring | unlimited | 460 KB/s | 488 KB/s | 520 KB/s | 600 KB/s | |---:|---:|---:|---:|---:|---:| | 64 KB | 2 | 2 | 2 | 2 | 2 | | 96 KB | 3 | 3 | 3 | 3 | 3 | | 128 KB | 5 | 4 | 4 | 4 | 4 | | 192 KB | 6 | 4 | 5 | 5 | 5 | | 256 KB | 8 | 4 | 7 | 7 | 7 | | 384 KB | 11 | 4 | 10 | 11 | 11 | | 512 KB | 15 | 4 | 11 | 14 | 14 | **64 KB carries two frames and 96 KB carries three.** 49.7.2 warned that 48 KB was single-buffered and passing anyway; this is the number, and it says the small end of that sweep was measuring nothing about delivery. ### 51.2 Tolerance is `ceiling - 1`, and it was falsified rather than asserted `DLX_CUT_AT`/`DLX_CUT_FR` stop the pipe dead at a chosen tick, as a seek does. At 256 KB and 520 KB/s, with **7 records resident**: | cut | underruns | |---:|---:| | 2 frame times | 0 | | 6 | **0** | | 7 | **1** | | 8 | 1 | | 10 | 1 | **Seven resident records buy six frame times, not seven** — 500 ms, not 583. The last one is spent covering the pipe's restart: a 36.5 KB record takes ~0.9 frame times to place at 512 KB/s of video, so the record due immediately after the cut is still arriving when its slot opens. A design that reads the resident count as its stall budget is over by one record, every time. Every cut run stayed **pixel-exact**, including the ones that underran. That is the expected shape and worth stating: under-delivery makes a frame LATE, not wrong — `waitrec` spins and the decode is byte-identical when it resumes. A rig that reported corruption here would be reporting its own bug. ### 51.3 The result that bears on a branching game Slack is not a property the buffer has. It is **accumulated out of the surplus between the pipe and the wire demand**, and a seek spends all of it. | ring | pipe | ceiling | play needed to reach it, from empty | |---:|---:|---:|---:| | 256 KB | 488 KB/s | 7 fr (583 ms) | **4.83 s** | | 256 KB | 520 KB/s | 7 fr | 2.83 s | | 256 KB | 600 KB/s | 7 fr | 1.67 s | | 512 KB | 520 KB/s | 14 fr (1.17 s) | **8.42 s** | | 512 KB | 600 KB/s | 14 fr | 8.42 s | **A bigger ring raises the ceiling and lengthens the climb to it.** The fill rate is `pipe - wire`, which is set by the encoder and the medium; the ring only sets where the climb stops. So the question a branch point asks is not "is the buffer big enough" but "has there been enough play since the last branch point to refill it" — and at 488 KB/s with a 256 KB ring the answer is **4.83 seconds of play**. Two branch decisions closer together than that and the second one has no buffer to spend, at any ring size. Dragon's Lair's decision points are seconds apart. This is the first statement in this tree about back-to-back branches, and it is a consequence of the delivery model, not of the decoder. ### 51.4 Which resource is binding, said out loud The producer now counts its refusals separately. A **rate** refusal (no credit for a whole record) means a bigger ring buys nothing; a **ring** refusal (the decoder still owns those bytes) means a faster pipe buys nothing. From the decoder's side the two are identical — "no new record" — and they have opposite fixes. **At 460 KB/s every ring from 192 KB to 512 KB reports RATE-BOUND with a ceiling of 4 and never fills inside 120 frames.** 460 is 13.9 KB/s over the container's 446.1 wire demand; that surplus fills 146 KB in the whole 10-second window. Any ring larger than that is dead RAM in this scene. The zero-prefill pipe for this container is 451.4 (49.5) — **clearing the arrival deadline and being able to absorb a seek are different requirements, and the gap between them is large.** ### 51.5 An independent implementation agrees, within one record `tools/analysis/20_seek_slack.py` is the same model written from record sizes in Python, sharing no code with the Lua producer — the 49.4 pattern. Over all 35 cells of the grid: - **35/35 of the rig's ceilings fall inside the sim's bracket**, and 33/35 sit at the top of it. The bracket is one record wide and is reported as a range rather than a number, deliberately. At these rates the pipe delivers almost exactly one record per frame slot, so "records resident at slot *i*" differs by one depending on whether the sample is taken before or after that slot's delivery. Sampled after, the sim matched the rig's ceiling in 33/35 cells; sampled before, it was exactly one low in 33/35. Picking the sampling point that matched, and then reporting the match as a cross-check, would have been fitting the model to the measurement. Both are returned and the caller prints the range. ### 51.6 Two rig defects the pacing exposed Both were in the producer, both were invisible while the decoder free-ran, and both would have made the first paced result wrong in a plausible direction. 1. **The `RD_PTR` cross-check was really a test of how often `reap()` ran.** It asserted, for every record it retired, that the decoder's released-to pointer equalled that record's end. `RD_PTR` is a single pointer and names the end of record `tail-1`; retiring several records in one pass — normal the moment the decoder is paced and the pipe stops — made it fire a false MISMATCH on the earlier ones. It now asserts on `tail-1` only, which is the invariant that actually holds. 2. **`reap()` was skipped for the duration of a cut.** The cut returned early from `produce()`, so the ring looked full for the whole seek and the producer could not restart against space the decoder had long since released. A seek stops delivery; it does not stop the decoder. Only credit and placement stop now. ### 51.7 What this does NOT establish 1. **The pipe is still a model and the medium is still unmeasured.** Every rate in 51.1 is a chosen input, not a measurement — FINDINGS 50 stands, and `pace_run.sh` requires the rate for the same reason. The columns are a sensitivity table; none of them is a claim about a BlueSCSI. 2. **The DMAC's clock debit is still not modelled** (49.7.1). A paced decoder makes the ring's behaviour honest and does nothing about the clocks the DMAC steals while it fills. "Survives a 500 ms cut" means the bytes were there, not that the frames fit. 3. **One container, one scene.** The ceilings are in whole records, so they move with record size; a scene with heavier frames has a lower ceiling in the same ring. Nothing here is a universal per-KB figure and the tools take the container as an argument for that reason. 4. **The pace gate costs the rig a `tst.l`/`beq.s` per frame** — `stream.s` is 1,418 bytes against 1,396. It is outside `src/player/frame.i`, so every per-block and span constant in FINDINGS 24/30/40/41 is untouched, and `decode.bin` is still 1,296 bytes at the same MD5 (asserted in `check.sh`). 5. **Seek TIME itself is not modelled.** The cut is a chosen duration. What a real seek costs on the target medium is part of the same unmeasured question as the rate, and it is the other half of what item 1 buys. --- ## 52. The DMAC configuration was never a mystery: it is in the IPL ROM (session 20) ROADMAP called the ADPCM stream "the largest unpriced risk left in the project" and asked for one cheap thing first — **put the audio DMA on the bus and see what it does to the 86.7%.** Doing that needs a clocks-per-byte figure for the audio channel, and the tree did not have one: `11_cpu_budget.py` charged audio bytes `--dma-clocks-per-byte`, the *disk's* rate, defaulting to 5 and described in its own help text as "single-address, bus held, no drive wait". That is a description of the SCSI channel, and it is the favourable end of ROADMAP B3, an open question worth 242 KB/s. **Audio was being charged the disk's guess.** It did not have to be a guess for either of them. The X68000's IPL ROM programs all four HD63450 channels itself, and **the ROM is on this machine** — MAME boots the player rig with `-bios ipl10`. `tools/analysis/21_iplrom_dmac.py` reads the configuration out of the image and decodes the MC68450 register fields. It is a gate, not a report: every value is (address, expected bytes, meaning), eight sites, and a mismatch or an unrecognised ROM revision exits non-zero rather than decoding some other code. It is in `check.sh`, needs no emulator, and runs in milliseconds. **NAME THE LAYER.** This is not a measurement of a running machine and not real hardware. It is the shipping ROM image (IPL 1.0, md5 `7fd4caab…`, 131,072 B), read statically — evidence about what Sharp's engineers configured this board to do, from the vendor, for these exact devices. Field layouts are SOURCED from MC68450, Motorola, Jul 1989, the document `buscost.py` already cites. ### 52.1 What the ROM programs Boot, `$FF0CCA`–`$FF0C58`: a ten-pair table at `$FF0D8E` initialises channels 0 and 1, then two inline runs do channels 2 and 3. | ch | device | DAR | DCR | decoded | |---|---|---|---|---| | 0 | FDC | `$E94003` | `$80` | dual address, 8-bit port, cycle steal **without hold** | | 1 | **SASI** | `$E96001` | `$80` | dual address, 8-bit port, cycle steal without hold | | 2 | IOCS `_DMAMOVE` | per call | `$08` | dual address, **16-bit** port, burst | | 3 | **ADPCM** | `$E92003` | `$80` | dual address, 8-bit port, cycle steal without hold | Per transfer, `$FF9A82` (ADPCM play) and `$FF9944` (SASI): **OCR = `$32`** for memory→device, `$B2` for device→memory. Both decode to `SIZE = 11` (byte), `CHAIN = 00` (none) and — the load-bearing field — **`REQG = 10`, external request: one operand per device request.** ### 52.2 Audio is dual-address and cannot hold the bus. 16..19 clocks a byte. `DTYP = 00` is *explicitly addressed*, so every ADPCM byte is a memory read followed by a device write: 4 + 5 = **9 clocks** (Fig 4-25 sheet 4, note 2 — already in `buscost.py` for the span work). `XRM = 10` is cycle steal without hold and `REQG = 10` is external request, so **the DMAC arbitrates for the bus once per byte and hands it straight back.** There is no burst to amortise the front-end (5..8 clocks, §4.5.2.1) and back-end (2, §4.5.2.2) over. The audio byte costs **16 clocks best case, 19 worst** — not 5. ### 52.3 The byte rate, derived rather than restated `ratectl.AUDIO_KBPS = 7.8` had no derivation next to it, and ROADMAP flagged it as exactly the kind of figure that cost the project a 2x error in FINDINGS 43. It survives, with a correction of units: 15.6 kHz is the MSM6258V's 8 MHz clock ÷512 = **15,625 samples/s**, 4 bits each, two to a byte = **7,812.5 B/s**. The 7.8 is that in *decimal* kB; `11_cpu_budget.py` was multiplying it by 1024, so it read 2.4% high. Harmless, and now derived from the sample rate in `buscost.ADPCM_BYTES_PER_S` instead of typed in. **The request count does not halve.** 7,812.5 B/s is 7,812.5 DMA requests/s, because the port is 8 bits and the operand is a byte. That is the FINDINGS 43 trap in the other stream, and it does not spring: nobody had denominated audio per word. ### 52.4 So: what the audio does to the bus. Almost nothing. 651.0 B/frame at 12 fps × 16..19 clocks = **10,417..12,370 clocks of 833,333 — 1.25% to 1.48% of the frame.** The decoder's measured mean is 68.5% of the frame period on the gate container, so audio takes about **4% of what the decoder leaves**, and about 1.7% of it on the worst frame (which is already at 110.8% and misses with or without audio). **P6's bus risk does not materialise.** The concern was sound and the answer is that a second DMA consumer at 7.8 kB/s is not what a bus at 88% occupancy is short of. The debit was 3.2x..3.8x understated, and it is still small. ### 52.5 THE ONE THAT MOVES SOMETHING: the disk channel is programmed the same ch1, SASI, `DCR = $80`, `OCR = $B2` — **dual address, 8-bit port, cycle steal without hold, external request.** Byte by byte, full arbitration each time. ch0 (FDC) too. Sharp programs every explicitly-addressed 8-bit device on this board identically, and by 52.2's arithmetic that is **16..19 clocks per delivered byte**. **A CORRECTION TO THIS SECTION AS FIRST WRITTEN, made in the same session.** It cited 42.4's sensitivity table — `W <= 6` fits 0/120 frames, `W = 8` misses 47/120 — as though those figures were in clocks per BYTE. **They are per WORD, and FINDINGS 43 voided them**: 43 is the section that caught `W` being charged per word to a byte-wide port, and it says in terms that 42.3's 0/120 was never physically reachable. Quoting them here would have re-imported the exact 2x unit error 43 exists to have corrected, one section after using the same trap as a warning. They are struck, and nothing below depends on them. In the corrected unit the ladder is a per-byte cost of the DMAC's own configuration, and it is the ladder `buscost.py` already carries: | configuration | clk/byte | |---|---:| | single address, bus held | 5 | | dual address, bus held | 9 | | single address, arbitrated per byte | 12 | | **dual address, arbitrated per byte — what the ROM programs** | **16..19** | `15_bus_occupancy.py` sweeps it on the gate container (37,403 B/frame, measured mean decode 570,958 clocks): | W clk/B | video clk/frame | % of frame | CPU + audio + video | |---:|---:|---:|---:| | 5 | 187,017 | 22.4% | 92.2% | | 8 | 299,228 | 35.9% | 105.7% | | 12 | 448,842 | 53.9% | 123.6% | | **16** | 598,455 | 71.8% | **141.6%** | | **19** | 710,666 | 85.3% | **155.0%** | **This table is the statement, and it is not corroborated by 42.4.** The resemblance between the `W = 8` row here and 42.4's 47/120 is a coincidence of two different units on two different containers at two different rates, and calling it a cross-check — as this section did when first written — was manufacturing agreement out of a unit error. **This does not close B3.** `scsiexrom.bin` drives an MB89352, not the SASI port, and a different ROM may configure it differently. What changed is the prior and the framing: 42.6 says the handshake "is ours to choose, not to receive", and that is still true — but **nothing in this tree has shown a cheaper configuration is reachable for an explicitly-addressed 8-bit port, and the vendor's own answer is the expensive one.** Holding the bus, which is what separates 9 from 16..19, is a *requirement on the player's DMAC programming* rather than a range the hardware hands us. It is now the largest open number in the project, ahead of the rate. ### 52.6 Audio outranks the disk at the arbiter CPR: FDC 0, **ADPCM 1**, SASI 2, `_DMAMOVE` 3 — lower is higher priority. With the ROM's arrangement, when both channels want the bus in the same slot ADPCM is served first. An audio byte is never the thing that waits; **a video byte is.** Relevant to 51's underrun analysis, which models delivery as a smooth rate. ### 52.7 What this does NOT establish 1. **Static read of a ROM image, not a running machine.** No emulator executed this code for the purpose; the claim is about bytes in the shipping image. Real hardware would confirm the registers, not the timings. 2. **The timings are datasheet, not measured.** 9 clocks for the transfer and 5..8 / 2 for the arbitration come from MC68450 Fig 4-25 and §4.5.2. They are the same source `buscost.py` already rests on for the span work, and they have never been checked against a board. 3. **IPL 1.0 is a pre-SCSI machine.** ch1 is SASI. B3 stands. 4. **Our player is not obliged to copy the ROM.** It programs these registers itself. 52.5 is a prior and a warning, not a measured ceiling — and the experiment that would settle it is P4, not another reading. 5. **Nothing here is an audio implementation.** P6's other risks — extraction, encode, container interleave, the second stream's effect on `wire` and hence on 51.3's refill climb — are untouched. Only the bus question is answered. 6. **The frame-period accounting assumes the DMAC does not overlap the CPU** (`buscost.DMA_OVERLAPS = False`), which is FINDINGS 35's premise: no cache, a two-word prefetch queue. A stolen bus cycle is a stopped 68000. --- ## 53. The loader moves onto the 68000, and a scene change finally has a price (session 21) ROADMAP P1 and P2. Since session 1 the two load-time transforms have been done **host-side**, in `tools/bench/dlxload.py`, with the rigs pushing the *result* into emulated RAM: the codebooks expanded to word-per-pixel form (CB1 to 32 B an entry, CB4 to 8 B) and the 24-bit palette packed to `GGGGGRRRRRBBBBBI` with the shared LSB chosen per entry. That was the right call while the inner loop was what was being measured — charging a once-per-scene cost to the per-frame path would have flattered or damned it for no reason — but **a player has no host.** `src/player/load.i` does both on the 68000, out of the raw container header as it comes off the disc. `tools/bench/loadgate.s` is its front-end, the way `decode.s` is `frame.i`'s. **NAME THE LAYER.** Everything here is **emulated**: MAME 0.277 `x68000`, `-bios ipl10`, stock 10 MHz / 2 MB, cross-checked on px68k's C68K core. Nothing has run on real hardware. ### 53.1 It reproduces dlxload.py exactly, on both cores `dlxload.py` stays the reference — what changed is **where the transforms run, not what they produce** — so the gate is byte-for-byte, not "close enough": - **CB1 8,192 B, CB4 2,048 B, palette 512 B: identical.** A wrong codebook byte is a wrong colour in every block that uses that codeword, in every frame of the scene, and a wrong shared LSB is a *slightly* wrong colour, which is exactly the sort of defect that gets attributed to the codec. - **The palette half is read back out of the palette registers at `$E82000`**, not out of a RAM shadow, so "the words reached the hardware" is part of what passes. - **The darkest-entry index agrees too** (255 on the gate container). It comes out of an `argmin` whose tie-break has to match numpy's — first index at the minimum wins — and it is what the letterbox is filled with. - **Both CPU cores produced the same 10,752 bytes**, and the same as the host. `tools/bench/load_run.sh` runs it and `check.sh` gates it. ### 53.2 What it costs, measured on two cores | stage | MAME clocks | C68K clocks | Δ | data bus (C68K) | |---|---|---|---|---| | scratch tables (boot only) | 52,919 | 61,622 | +16.4% | 6.5% | | **P1** codebook expansion | 92,609 | 95,304 | +2.9% | **43.2%** | | **P2** palette entries | 97,019 | 97,348 | +0.4% | 14.3% | | BOOT: all three | 246,957 | 253,614 | +2.7% | 23.2% | | **SCENE CHANGE: P1 + P2** | **189,627** | 192,322 | +1.4% | 28.6% | **A scene change costs 18.96 ms of 68000 time — 22.8% of one 12 fps frame.** Boot costs 24.70 ms. Bus occupancy is data accesses only (C68K does not see prefetch), so it is a lower bound; the expansion is the bus-heaviest thing here because it is a pure copy, and it still runs alone. **The stages are exactly additive on the exact core.** `P1 + P2 - SCENE = 330` clocks, and `tables + P1 + P2 - 2x330 = 253,614 = BOOT`, to the clock — 330 is the front-end's own per-pass overhead. On MAME the same identity closes to 1.8%, which is one tick of its host clock over the 0.99 s run. Two instruments, two granularities, one arithmetic. (That tick was written here as 1/55.46 s and is **1/56.69 s** — MAME's raster, not the hardware's, 54.5. 17.64 ms over 990 ms is 1.78%, so the sentence was right and the label was wrong.) ### 53.3 The scratch tables are scene-independent, so they are not in the scene path Packing a palette entry needs the squared error of both choices of the shared LSB, per channel. That is three table reads and a sign test here, out of three tables — the 6-bit-to-8-bit rendering the CRTC performs, its square, and the per-channel error difference — and **not one of them describes the scene.** They describe the machine. `pal_tables` is therefore a separate entry point from `pal_pack`, built once at boot: **5.29 ms saved on every scene change**, 22% of what a naive port of `dlxload.py` would have charged per scene. ### 53.4 The two cores disagree only where the multiplies are, and C68K is wrong in kind The table build is the only code in this tree that multiplies, and it is the only stage where the two cores disagree by more than 3%. **px68k's C68K charges a flat 50 clocks for `MULU` and `MULS`** regardless of the operand (`c68kmacro.h:1869/1883`, `RET(50 + EA_CLOCKS_...)`); the 68000 charges **38 + 2n**, n counting bits in the source. For the 576 multiplies this code executes, the real total is 24,192 clocks against C68K's 28,800: **the flat rate explains 4,608 of the 8,703 clock gap, and 4,095 clocks — 7.7% of the stage — are NOT explained.** Recorded as open rather than rounded away; the residual is somewhere else in the two cycle tables and this stage is not worth the hunt. **The consequence is general and belongs in the reader's head:** where a future measurement contains multiplies, C68K over-charges them, and it is the second opinion this tree leans on for every cycle figure. Nothing else in `src/player/` multiplies — index scaling is `lsl.w #5`/`#3` by construction — so no figure in FINDINGS 24-52 is affected. ### 53.5 Where the cost actually lands: the scene change, priced `tools/analysis/22_scene_load.py`, cycle counts parsed out of the rig's own log rather than pasted in as constants. Three costs in three units, and **the third is the one that compounds**: - **BYTES.** The header region is **5,920 B** (palette 768 + CB1 4,096 + CB4 1,024 + 32) and it must arrive before frame 0 can be decoded. It is not part of any frame record, so **no rate table in this tree has ever counted it.** - **CLOCKS.** 189,627, from 53.2. - **ACCUMULATED SLACK.** Those bytes are bytes the pipe did not spend filling the ring, so they cost play-time at the surplus rate `pipe - wire` — the currency FINDINGS 51.3 established a branch point spends. | pipe KB/s | header ms | + load ms | total | frame slots | surplus KB/s | slack cost | |---|---|---|---|---|---|---| | 451.4 | 12.81 | 18.96 | 31.77 | 0.38 | 5.3 | **1.099 s** | | 488 | 11.85 | 18.96 | 30.81 | 0.37 | 41.9 | 0.138 s | | 513.2 | 11.27 | 18.96 | 30.23 | 0.36 | 67.1 | 0.086 s | | 600 | 9.64 | 18.96 | 28.60 | 0.34 | 153.9 | 0.038 s | (Rates are explicit arguments with no default, FINDINGS 50. `wire` is 446.1 KB/s on the gate container, audio included.) **Two readings, and the second is the finding.** First: the whole fixed cost of a scene change is **about a third of one frame slot** — it is not what makes a branch point expensive, the seek and the refill climb are. Second: **the slack cost is hypersensitive to the rate**, because it is divided by a surplus that goes to zero. At 488 KB/s the header lengthens the climb by 138 ms; at 451.4 KB/s — the *arrival-deadline* rate for this same container, 49.5 — the same 5,920 bytes cost **1.1 seconds of play**. The header is cheap only where the pipe already has room, which is the same place everything else in this project is cheap. ### 53.6 The alternative that was not taken The encoder could ship the codebooks pre-expanded and P1 would not exist. That trades **9.26 ms of 68000 time for 5,120 more bytes in every scene header** — 10.5 ms of pipe at 488 KB/s, and 5,120 bytes that lengthen the climb again by the arithmetic above. **Derived, not measured**, from the two figures either side of it. It is close to a wash in milliseconds and it is not a wash in *kind*: the CPU is idle during a seek and the pipe is the resource this project is short of. The transform stays on the 68000. ### 53.7 What is still open in P2 **The encoder still does not reserve a black entry** (23.4), so the letterbox gets the palette's closest thing to black — index 255 here — rather than a true black with `I = 0`. That half of P2 is encoder-side, it changes the container, and it moves every constant fitted to the gate container, so it is a re-encode plus a re-measurement rather than an edit. `load.i` is ready for it: it reads whatever the palette section holds and reports the darkest index either way. --- ## 54. The frame clock moves onto the 68000, and the 12 fps frame turns out never to have existed (session 22) ROADMAP P3, and the item was phrased "needs MFP timer or VBL" — which quietly assumes one of those can do it. Neither can, and finding out why produced a better clock than either and a correction to an instrument the whole tree reads. `src/player/clock.i` is the clock; `src/player/clockgate.s` and `tools/bench/clock.lua` measure it; `tools/analysis/23_frame_clock.py` enumerates the space it was chosen from and prices its cadence. Two new stages in `tools/bench/check.sh` gate it. **Layer: MAME 0.277's emulated X68000, not real hardware.** The MFP, the CRTC and the interrupt sequence are all the emulator's. Where the emulator and the registers disagree — and they do, 54.5 — the code is built on the registers. ### 54.1 No MFP timer can tick at 12 Hz, and none can tick as slowly as a frame The MC68901's timer clock on this board is 16 MHz / 4 = 4 MHz (`sharp/x68k.cpp:1027-1028`), its prescaler ladder is `{4, 10, 16, 50, 64, 100, 200}` (`machine/mc68901.cpp:173`) and its data register is 8 bits. So: * the **slowest** tick a single timer can produce is 4e6/(200·256) = **78.125 Hz**, which is 6.5× faster than a 12 fps frame — a software divider is required whatever the source; * **4e6/12 = 333,333.33 is not an integer**, so no prescale/data pair divides to 12 Hz at all. `23_frame_clock.py` walks all 7 × 256 of them and finds zero. A timer clock is therefore not "the simple option". It is a divider *plus* an interrupt rate 3.6× higher than the raster's, at an arbitrary phase against the scan. ### 54.2 The raster cannot do it by whole division either — and the fix is exact V-DISP is on MFP GPIP4 (`x68k.cpp:1139`), and the same pin is Timer A's event input (`mc68901.cpp:167`, `GPIO_TIMER = {GPIP_4, GPIP_3}`); its interrupt is channel 6, `IR_GPIP_4 = $40` (`mc68901.cpp:76`). The raster is 31,500/568 = **55.4577 Hz** exactly. Every whole divide misses: | Timer A event count | fps | error | |---:|---:|---:| | 4 | 13.8644 | +15.54% | | 5 | 11.0915 | −7.57% | 12 fps needs **4.6215 refreshes per frame**. So the divider keeps a remainder: ``` each V-DISP: acc += fps*VTOTAL ; 12*568 = 6816 if acc >= 31500: acc -= 31500 ; PACE += 1 ``` Long-run rate is `fps·VTOTAL/VTOTAL` = **12.000000 fps exactly**, with a remainder that never accumulates. Both constants are **read out of the CRTC at init** — `R04+1` for VTOTAL, `R20` bit 4 checked for the 31.5 kHz mode — so the clock is derived from the registers that generate the raster it counts, and the two cannot drift apart. The accumulator peaks at 38,316, so it is 16-bit arithmetic on a 68000; `clk_init` refuses rather than overflow (the ceiling is fps < 59.9 at this VTOTAL). **Measured over 3,000 refreshes: 3,000 interrupts, 649 ticks, where 649.1429 were exactly due — an error of −0.14 ticks, i.e. the remainder still held.** The gate is stated in ticks and not in ppm on purpose: a remainder-keeping divider is off by at most one tick over *any* window, so quoting ppm would let a longer window advertise a tighter clock for nothing. ### 54.3 It costs 181.35 clocks per V-DISP — 838 per frame, 0.10% of the budget The host cannot time this: MAME's Lua sees the machine once per screen frame, 17.64 ms, and the interrupt costs microseconds. So the **68000 times it itself**. `clockgate.s` runs a one-instruction loop for a window of 3,000 refreshes with the clock off and again with it armed: ``` clock off: iters0·L = clocks in the window -> L clock on: iters1·L + ints·H = clocks in the window -> H ``` `L` is **calibrated, not looked up** — the point is to price the clock on the machine rather than against `buscost.py`, which is the table being checked. | | | |---|---:| | loop iteration, calibrated over 13,926,121 of them | **38.000002 clocks** | | per V-DISP interrupt, over 3,000 | **181.35 clocks** | | per 12 fps frame (4.6215 interrupts) | **838 clocks = 0.1006%** | `L` landing on a whole number to seven digits is the check that licenses the subtraction, and it is also an independent confirmation of `buscost.py`'s model: `addq.l #1,(xxx).L` is 3 instruction words + 4 data accesses = 7 bus cycles = 28 clocks, plus 10 for the `bra.s`. **The 181.35 decomposes exactly.** By the same model the handler body is 130 clocks on a V-DISP that emits no tick and 164 on one that does; over the measured 649/3,000 mix that is 137.355, leaving **43.99 clocks for the interrupt exception sequence** — the textbook 44, measured here rather than recalled. For comparison, the cheapest exact MFP-timer clock would interrupt 16.7 times a frame instead of 4.6: **3.6× the cost, for a tick with no fixed relationship to the scan.** ### 54.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, and the short slot is **13.4% under it**. With the per-frame decode costs (`tmp/c68k_frames.csv`, 120 frames of the gate container) run through the actual divider and the actual pace gate: | tick source | short slot | frames over it | no idle left | |---|---:|---:|---:| | nominal 1/fps model (no raster has it) | 833,333 | 1/120 | **1/120** | | the host tick, as `stream.lua` really emits it | 705,590 | 10/120 | **4/120** | | the 68000's clock, hardware raster | 721,270 | 10/120 | **4/120** | | the 68000's clock, MAME's raster | 705,590 | 10/120 | **4/120** | **The cadence was already there and nothing had named it.** `stream.lua`'s tick is `floor((t - t_rel) * fps)` — which *looks* uniform and is not, because Lua only sees the machine at frame boundaries, so its ticks land on refreshes and its gaps are the same two whole numbers. Every host-paced result in FINDINGS 49 and 51 already carried a 4/5 cadence. **P3 did not introduce it. It moved who produces it onto the machine and made it visible.** **A short slot is not a dropped frame.** The pace gate says only "not before tick i", so a frame that overruns spends the next frame's idle and the clock recovers itself; the cost is one frame presented a refresh late. What the table counts is frames with no idle left, and the difference between the nominal row and the raster rows — **1 against 4** — is the entire price of the cadence on this container. **The expensive frame is frame 0, at 923,146 clocks = 111% of the nominal budget**: the first frame of a scene has nothing to SKIP against, so it is the whole picture in one slot. Most of what follows it in those counts is that transient draining. It also means the cost lands **at a scene change**, next to FINDINGS 53.2's 18.96 ms of loader and the seek — not spread over the window. `src/player/stream.s` now counts this itself (`LATEFR`/`LATEMAX`/`LATE1ST`), and the rig's count matches the offline model **exactly**: 4/120, first at frame 1, on both tick sources. The counter sits ahead of the wait loop and the free-running path executes none of it, so FINDINGS 49's figures are untouched. ### 54.5 MAME's raster runs 2.22% fast, and the whole tree has been sampling it `x68k_crtc.cpp refresh_mode()` computes the frame period as `(scr.max_x * scr.max_y)` dots over the dot clock, with `scr.max_x = m_htotal - 8` — one character cell short, and an **inclusive rectangle bound used as a count**. In the 256-wide mode that is 360 where the registers say 368, so MAME's refresh is fast by **368/360 = 1.02222**: * registers: 31,500/568 = **55.4577 Hz** * MAME, measured by `clock.lua` over 3,000 frames: **56.6901 Hz** The two agree to six digits with `clock_69m()/6 / (360·568)`, so this is the mechanism and not a coincidence. Consequences, and the third one is why it is worth this much space: 1. **Every "1/55.46 s granularity" note in this tree was wrong** — it is 1/56.69 s, 17.64 ms. Corrected in `decode.lua`, `load.lua`, `span.lua`, `blit.lua`, `loadgate.s` and `check.sh`, with the derivation put once in `crtc_mode.lua`. No conclusion changes: 53.2's "one tick over the 0.99 s run" is 1.78% at the corrected figure and was quoted as 1.8%. 2. **68000 cycle figures are untouched.** The CPU clock is 40 MHz/4 and has nothing to do with the screen. Nothing in FINDINGS 24–53 moves. 3. **A raster-paced player runs 2.22% fast under MAME**, so the rig measures 12.267 fps where the hardware would give 12.000. `clock.lua` reports both and de-skews, and `clock_run.sh` prices the interrupt against the **hardware** refresh count — charging the player the emulator's extra interrupts would overstate the cost by that same 2.2%. **Do not "fix" 55.4577 to match the measurement.** It is the hardware's, derived from the dot clocks, and it is what the divider is built on. ### 54.6 What had to be turned off, and why it is in the file The rigs launch the 68000 at `SR=$2700` into a machine the IPL ROM has already booted, so the MFP arrives with whatever IOCS enabled on it and vectors pointing into IOCS. Lowering the mask without disarming it would vector into code we did not put there. `clk_init` writes `IERA = IERB = 0` first — which on the MC68901 clears the matching pending bits with them (`mc68901.cpp REGISTER_IERA/B`, `m_ipr &= m_ier`) — then arms GPIP4 alone, takes the falling edge (AER bit 4 clear: the **start of vertical blanking**, which is when a player would present), and drops to `SR=$2500`. Levels 1–5 stay masked, so the DMAC (IRQ3) and the SCC (IRQ5) cannot get in. `VR` is written with **S clear**, so an acknowledge clears the pending bit by itself and the handler needs no end-of-interrupt write. The handler saves only the **low word** of `d0`, because every operation in it is a word operation — which is legal precisely because `clk_init` proved the accumulator fits 16 bits. `decode.s` and `frame.i` were checked for stack tricks before the mask was lowered: the only `a7` use in either is one `move.l a1,-(sp)` pair, so an interrupt cannot corrupt decoder state. The 120-frame self-paced decode being pixel-exact is the test of that, and it is gated.