LCD-on → First WODU

The end-to-end path from the CPU's LCD-enabling write to the first H-Blank, and how it maps onto CPU-observable timing (scanline and frame timing).

The end-to-end path

The full path from ff40_d7↑ (the LCD-enabling write's effect) to the first H-Blank condition on the first scanline — SCX=0, no sprites, no window (dmg-sim measurement):

With two dot-of-M-cycle invariants: the write's ff40_d7↑ lands at +2.020 dots into its M-cycle (the CUPA position), and the first WODU↑ lands at +1.556 dots into its M-cycle. Both are CPU-prelude-invariant — ps-identical across five LCD-on events in three radically different instruction streams (quickboot's mid-boot enable, a test ROM's own enable, and a post-HALT interrupt-handler enable, twice) — the instruction stream between the write and the first WODU is irrelevant to the PPU cascade.

The first-scanline Mode 2 measured from the write spans ~78.5 dots rather than 80 — not a Mode 2 shortening, but the dot-0 reference shifted by the write phase (+2.020) and divider startup (+0.480); each subsequent Mode 2 is exactly 80 dots.

SCX extension (measured at SCX ∈ {0,1,2,3,7}): the entire +1-dot-per- SCX&7 shift lands in the startup pipeline; every other stage is SCX-invariant to picosecond precision. Total: 251.536 + (SCX & 7) dots, giving a first-WODU M-cycle phase of (1.556 + (SCX & 7)) mod 4.

Mapping to CPU observables

For the canonical LDH (LCDC),a; xor a; inc a; inc a; … prelude, walking the wall-clock M-cells from the write pins everything: 63 CLK9 edges separate the write's M-cycle from WODU's, placing the first WODU at dot 1.556 of cell M65 with inc#61 in flight — handler-entry A = 61, matching the hardware-verified ROM expectation.

Per-SCX, the in-flight instruction and one further mechanism — a one-M-cycle dispatch slip when the WODU-driven int_pending settles past the dispatch-trigger setup boundary (first-WODU phases 2.556/3.556 — see interrupt dispatch) — combine into the hardware-verified expectations:

Skip-boot note