Put the palette on the channel, and find one start paints a whole frame

ROADMAP K1, the packed player's one open structural item.  A frame is a picture
AND a palette, and no run in this tree had pointed a DMA channel at the palette
registers.  dmagate.s runs 7-9, gated by dma_run.sh and check.sh:

  7. 512 B off the disc into $E82000, bus held -- byte-exact in 256 register
     words, read back OUT OF the registers by the 68000;
  8. the SAME transfer aimed at RAM -- byte-exact at $2C000, and 256 of 256
     palette words still read the poison the CPU wrote, which is what attributes
     run 7 to the channel's MAR rather than to the readback path;
  9. ONE array-chained start across two kinds of destination -- the palette and
     six picture rows at the 1,024 B line stride, 2,048 B byte-exact.

So a packed frame is one channel start: a 193-entry array, palette first, CPU
halted from the first byte to the last.  The array is scene-constant, because
the packed layout spends both 256-colour pages and there is no page to flip.
What is left on the CPU per frame in the video path is the channel start and the
READ(10) -- no per-frame PAINT, which is not the same claim as no per-frame CPU.

The destination is POISONED first (62.1).  Runs 4-6 wrote into RAM that was zero
and GVRAM that was stale against a record that is mostly pad; "it matches the
disc" was weaker than it read as.  The host counts whether the poison actually
discriminates instead of assuming it: 511 of 512, and the gate refuses under 500.

And it opened a hardware item (62.4, ROADMAP B4).  MAME maps the palette to
palette_device over memory_array, whose write16 is a plain COMBINE_DATA -- RAM
that honours mem_mask, with no handler that could refuse a byte write.  Unlike
GVRAM's 256-colour arm there is nothing here to be wrong about, so the run
bounds the model and not the board.  What a real palette register does with a
byte write is unmeasured.  A negative costs 0.28% of a frame and nothing else.

29_packed_player.py now also prints the two rows with the per-frame palette
charged -- 55.7% of a frame on the chain, 582 KB/s -- alongside the picture-only
figures the codec comparison is quoted against.

check.sh ALL GREEN before (tmp/check_s30_start.log) and after
(tmp/check_s30_end.log).

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

README.md

@@ -240,6 +240,22 @@ the frame. The packed player is at 55.2% today. **The codec is kept on disk and
 not built on**, because B2 is unanswered and 48.1's prior leans against packing —
 if buffer mode blanks, it is the only thing left (48.3).
 
+**And a frame is now one channel start.** Session 30 asked the packed player's
+one open structural question: a frame is a picture *and* a palette, and nothing
+had ever pointed a DMA channel at the palette registers. It writes them —
+512 B off the disc byte-exact into 256 registers at `$E82000`, read back out of
+the registers by the 68000 — and **one array-chained start crosses from those
+registers into GVRAM**, which is the shape of a whole frame: a palette entry and
+192 row entries, walked by the channel with the CPU halted throughout. The array
+is scene-constant, because the packed layout spends both 256-colour pages and
+there is no page to flip. What is left on the CPU per frame in the video path is
+the channel start and the disc read; there is no per-frame *paint*. **What it
+does not settle is the board** — MAME models the palette as plain
+`COMBINE_DATA` storage with no handler that could refuse a byte write, so the
+run bounds the model and not the hardware, and "does a real palette register
+take a byte write" joins the hardware list as B4. A negative answer costs 0.28%
+of a frame and nothing else (FINDINGS 62).
+
 **The scene graph is in, and the worst gap between two decision points is
 zero.** `tools/import/scenegraph.py` imports the arcade scene graph — 40 scenes,
 516 sequences, 906 input windows — and 5.4% of the game's 612 branch transitions