Measure the span: the mode survives, and it is an encoder format

FINDINGS 29 priced a literal-span mode at 4*(50 + 4L*9.08) cycles and labelled
the whole section DERIVED. Session 8 step 0 was to measure it before optimising
over the mode set it implies. Two variants in blit.s, one stream per span length
from prep_spans.py, timed by span.lua, driven by span.sh in ~25 s:

  v5, handed (x, npix) and left to work the copy out:  97.9/span + 10.459/px
  v6, handed an address and a jump displacement:       43.7/span +  9.152/px
  29 assumed                                           50.0/span +  9.080/px

So 29's arithmetic was right about a format nobody had written. The difference
is not tuning: v5 spends ~122 cycles a span computing a destination, dividing
npix into bursts and handling a 0..15 remainder, all of which the encoder knows
at build time. v6's record is {u32 absolute GVRAM address, u16 jump
displacement} into an unrolled chain of 24-pixel copy units -- no loop, no
remainder, no arithmetic -- and it fits 11 span lengths to 0.3%.

Three things that measurement showed and derivation could not:

  - The per-pixel cost is a function of REGISTER PRESSURE. FINDINGS 24's 9.08
    was a fixed blit with 12 registers free; v5 can spare 8 and pays 10.46; v6
    gets 12 back only because the encoder holds the state.
  - Short spans die in the remainder path -- a 12-pixel span costs MORE than a
    16-pixel one -- and the fix is padding, not avoidance.
  - Odd-x alignment is free (259.0 vs 261.8 cycles/span), as a 16-bit bus
    implies but nobody had checked.

Re-priced against the unchanged mode maps, sasi: median 74.4% -> 52.0% (29 said
43.0), misses 37 -> 10/120 (29 said 8), 448.0 KB/s. Break-even moved from runs
of 2 blocks to runs of 4. 29.4 survives: a scene cut needs x >= 0.196 of the
frame as spans and the bus allows x <= 0.373, so it fits at 12fps.

All 23 timing configs are also checked pixel-exact, so none of this was timed
against a decoder that quietly skipped work.

FINDINGS 30. Next: lever B, the cost-aware mode decision.

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

README.md

@@ -37,12 +37,17 @@ tools/analysis/  measurement scripts, numbered in the order they were written
                  demonstrates that the two-display-path plan of FINDINGS
                  24.5/25.6 corrupts 70 of 120 frames (FINDINGS 28.1).
                  11 scores a container against the MEASURED per-mode block
-                 costs without needing MAME.
+                 costs without needing MAME; 12 prices the literal-span mode of
+                 FINDINGS 30 against those same mode maps, and prints whether a
+                 scene cut still fits at 12fps.
 tools/bench/     MAME Lua injection harness + 68000 benchmark sources.
                  `check.sh` re-runs both display regression tests (~40 s).
                  `blit.s`/`blit.lua` time the full-frame GVRAM blit on the
                  68000 itself (FINDINGS 24) — not part of check.sh, because
                  wall timings would make the green-light check host-sensitive.
+                 `span.sh` (prep_spans.py + span.lua + blit.s v5/v6) measures
+                 the literal-span mode the same way (FINDINGS 30, ~25 s); it
+                 also asserts all 23 timing configs drew a pixel-exact frame.
                  `crtc_mode.lua` is the single source of truth for CRTC R00-R08
                  and R20 — do not write CRTC values anywhere else.
                  `prep_dlx.py`/`decode.lua`/`verify_decode.py` load, time and