Session 3 left the harness on the IPL's 768x512 text timing because no CRTC
values had been derived and guessing them was the failure mode to avoid. This
derives them from MAME 0.277's divisor ladder instead, and the derivation is
self-checking: the 256-wide mode runs at div 6 against the 768 mode's div 2, so
htotal is exactly 1104/3 = 368 dots and every horizontal register divides by
three with no remainder. Only the blanking split rounds. Verified by snapshot:
native 256x512, active area pixel-exact, x=512 wrap gone.
Two things fell out that change numbers elsewhere:
- The palette's shared LSB I must be chosen per entry, not hardcoded to 1.
Doing so lifts the display ceiling from 38.85 to 40.81 dB and is the only way
to reach true black at all, since pal6bit(1) = 4. 102 of 256 entries want
I = 0, so this is not a corner case. Supersedes FINDINGS 22.4; scsi has ~2 dB
more headroom than that section claimed. The encoder does not do this yet.
- Letterboxing costs a palette entry: GVRAM cleared to zero shows entry 0, and
a free mediancut palette puts a real image colour there. 255 colours plus a
reserved black, via prep_frame.py --reserve-black.
MAME's graphics double-scan is phase-shifted one raster line (it halves the
absolute scanline and vbegin is odd), which produced a false failure before it
was understood; the regression test now asserts the shifted pairing explicitly.
Still Lua-side. No 68000 instruction has drawn a pixel; the 38% blit estimate
remains unvalidated. What this buys is a defined geometry for the decoder to
write into: 256 words per row, 1024-byte stride, rows 32..223.
Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
prosolis
34f9ee341d