PPU1

Role in the SoC

PPU1 is the "video / LCD" half of the PPU. The two PPU blocks are split as follows:

• PPU1 (this page): the BG/WIN (background/window) part of the pipeline, the pixel serializers, the palettes and the pixel mux, the LCD driver interface, the H/V counters, the register decode and most of the PPU registers.
• PPU2: the part closer to Objects and OAM ("sprites"): OAM scan, sprite X arithmetic, mode generation. PPU2 outputs the object attributes to PPU1 (obj_color, obj_prio, sprite_x_flip, sprite_x_match, ppu_mode2) and receives the render timing from PPU1 (oam_addr_ck, oam_rd_ck, oam_xattr_latch_cck, obj_prio_ck, ppu_mode3, the H/V counter values).

Both parts communicate closely with a bunch of signals: PPU1 generates the VRAM addresses (nma/n_ma), the CPU-visible register access indicators (ff42, ff43, ff46, fexx, FF40_D1..3), and the LCD driver outputs.

The netlist is a flat gate-level Verilog: 916 cells, 128 assign statements, 64 ports (the only hierarchical cell is the const cell g867). The cell inventory:

Signals

Netlist

Annotated Design

TBD.

Functional blocks

The netlist is organized into the following functional blocks (instance numbers refer to HDL/soc/ppu1.v):

1. Register decode (address decoder)

The decoder is a row of 13 five-input NANDs g788..g800 that turn the low address bits into per-register access strobes. The qualifier w267 (from g753/g909) is high only for the $FF4x register window:

w267 = ffxx & a[6] & !a[7] & !a[5] & !a[4]

i.e. "FFxx area, bits 7:4 = 0100" (the $FF40–$FF4B block). Each NAND then decodes bits a[3:0] (inverted/true forms w266/w265, w563/w264, w793/w263, w235/w162 produced by g97..g100 and g147..g150):

The decoded strobes are AND-ed with ppu_rd (w59) / ppu_wr (w152) by g685..g727, producing the per-register read/write enables (w232, w597, w58, w84, w260, w920, w72, w914, w955, w647, w855, ...). These enables select, via the tristate drivers (notif0/notif1), which value is driven onto the data bus d on a CPU read, and which latch bank captures d on a CPU write.

2. PPU registers

All PPU registers are level latches (latchr_comp / latchnq_comp) capturing the data bus d, cleared by the hard-reset tree (w138/w246/w249 = n_ppu_hard_reset). Read-back is done by notif0 tristates enabled by the corresponding read strobe (the read value is the inverted hold on d).

STAT read value. The mode bits 0–1 are computed on the fly from the PPU mode handshakes: bit 0 from !ppu_mode3/VBlank state (g854, g782), bit 1 from !(ppu_mode2 | ppu_mode3) (g865, g781); bit 2 is the LY==LYC flag (g859, from the nor_latch g906); bits 3–6 are the interrupt enable latches; bit 7 is 0. (Exact per-bit polarity depends on the inverse-hold bus convention and should be confirmed by simulation.)

3. H counter (LX)

The H counter (the LCD X / "LX" counter, h[7:0] output to PPU2) is a binary counter with an AND carry chain, clocked by the fetch clock w44:

• bits 0–3: g308 (h0, d=!q), g321 (h1, d = h1^h0 via g840), g306 (h2, d = h2^(h0&h1) via g844/g720), g307 (h3, d = h3^(h0&h1&h2) via g866/g719), all clocked by w44, reset by w495 = !h_restart & n_ppu_reset;
• bits 4–7: g292 (h4), g290 (h5), g291 (h6), g323 (h7), all clocked by w375 = !h3 (ripple extension of the counter), with the same AND-carry increment (g721, g697, g842, g843, g841, g892–g894, g871).

The counter is reset by h_restart (from PPU2, at the end of the line) via g779/w495.

Special values. g799 (NAND5 on h0,h1,h2,h5,h7) detects LX = 167 (0xA7) — the end of the mandatory BG/WIN fetch window; the result (w619→w618) together with sprite_x_match (g143, g707) is captured by g313 into w615, which sets the mode-3 latch (block 6). The SCX fine-scroll comparison (block 6) also uses the H counter.

4. V counter (LY)

The V counter (v[7:0] output) is a pure ripple counter: v0 (g336, clock w416), v1 (g337, clock !v0), v2 (g261, clock !v1), v3 (g262, clock !v2), v4 (g263), v5 (g264), v6 (g335), v7 (g265); all reset by w256 = !(w407 | w406) (g770/g771).

• Line clock. The base clock w416 (also exported as vclk2 and driving the LCD CPL) comes from the sprite-selection logic (block 10): g281 latches the "sprite processing complete" condition w727 on the OAM clock half w968. Thus the V counter increments once per scan line.
• Reset at LY=153. g910 (AND4 on v7,v4,v3,v0) detects LY = 0x99 = 153 (the last line of VBlank); g333 latches it into w407, which forces w256 low and resets the counter. g911 (NOR8 on all V bits) detects LY = 0; g334 latches it into w420, which produces the LCD S (start-of-frame) signal (g822).
• VBLANK. g725 (AND of v4 and v7) produces vbl (w953), i.e. "LY ≥ 144": this is the VBLANK indicator sent to PPU2 and, via g332 (dffr on w174) and g86/g826, the ppu_int_vbl interrupt (block 14).

5. Window logic

The window (WIN) logic decides when the window layer is active (in_window = w145, output to PPU2):

• Vertical match (LY == WY): the WY latches (block 2) are compared with the V counter by the XNORs g734–g737 and g744–g748, combined by g802/g803 (NAND5) into w958/w423;
• Horizontal match (LX == WX): the WX latches are compared with the H counter by the XNORs g730–g733, g622–g623 and g801, combined by g838 into w942;
• The window latch g872 (nor_latch) is set by w532 (the window-start condition, see block 6) and cleared by w334 (g754: !(w538 & !h_restart & n_ppu_reset)), so the window is active from (LY == WY and LX == WX) until the end of the line. g516 outputs in_window = !w146. The LCDC window-enable bit 5 (w538) participates in the reset term, disabling the window when the bit is 0.

6. BG/WIN fetch cycles (mode-3 sequencer)

This block generates the mode-3 fetch phases and the fetch clock:

• Fetch enable. w143 (g898) = !(stop_oam_eval | w891 | w144) is the main "fetch allowed" signal (async set/reset for the fetch flip-flops).
• Fetch sequencer. The complementary-clock flip-flops g258–g260, g274, g338, g315 (clocks w464/w317/w463/w462/w288) step through the fetch phases; their state (w465/w467/w461/w854) is decoded by g749/g47/g48/g459/g460 into the two half-cycles of the buffer cycle:
• w211 = tm_bp_cys (tile-map / buffer-page cycle), latched by the NAND-latch g876 (set by w143, reset by w656 = mode3 & w316);
• w210 = tm_cy (tile-map cycle) = !w458 & w211 (g687);
• w209 = bp_cy (buffer-page cycle) = w458 & w211 (g683); w458 = !w459 = !(w461 & w221).
• Mode 3 indicator. w230 = ppu_mode3 is the inverted output (nq) of the NOR-latch g874 (s = w614, r = stop_oam_eval). Because the output is taken from nq, the indicator is deasserted (0) while w614 = !n_ppu_reset | w615 is high — i.e. during PPU reset or after the fetch-complete marker w615 (LX = 167 & no sprite match, latched by g313) — and it is re-asserted when stop_oam_eval finishes the OAM-scan phase. ppu_mode3 serves as the async reset of the fetch flip-flops (g260, g271, g275, g293, g314, g322, g328–g331, g276) and gates the buffer-cycle latch g876. g875 latches the window-start condition w519 = h0 & h3 → w520.
• Fetch clock (register clock). w44 = w626 | w9 (g831): w9 is the fetch-window latch g881 (set by !mode3, cleared when the SCX fine-scroll compare fires w803&w804), and w626 = !(w498 & w499 & w908) is the sprite-fetch gate (w908 = !(sprite_x_match | w496 | ppu_clk), w499 = sprite-fetch latch g871). w44 drives the low half of the H counter and all 48 shifter flip-flops — the "pixel/fetch clock" of the line.
• SCX fine scroll. The 3-bit ripple counter g277–g279 (base clock w502 = !(w628 & carry), reset w501) is compared with the SCX low bits FF43_D0..2 by the XNORs g738–g740; g916 (AND4 with the fetch-window latch w9) produces w506, which (via g184, g329, g271) yields the w803/w804 pair that closes the fetch window — the SCX fine scroll (SCX % 8) determines how many initial pixels are shifted before the visible line starts.

7. VRAM address generation

The VRAM address bus nma[12:0] (and the external inverse-hold form n_ma[12:0] to the pads, via not2 inverters g474–g481, g485–g486, g518–g519, g579–g582) is driven by four mutually exclusive sources, selected by tristate notif0/notif1 banks:

Tile-map counter (g299–g302, g309; ripple clocks w379/w566/w564/w583/w274, reset w273) and tile-data counter (g294–g298, g310–g312; ripple clocks w634/w639/w384/w575/w124/w794/w638/w382, reset w383) are 5–6 bit counters that address the tile map and the tile data during the mode-3 fetches; their resets w273 = !w334 and w383 = !(vbl | !n_ppu_reset) (from g833) clear them at the start of each line.

Address register (g882–g889, eight dffr_comp with complementary clock w311/w312 from g470/g471): captures an 8-bit value from the md bus (during the sprite/OAM phase — the sprite's tile index) and re-emits it on nma[4..12] during the buffer-page cycle, forming the VRAM address for the sprite tile data fetch.

ppu1_ma0 (g501) outputs the address LSB (MA0) separately to PPU2.

8. BG pixel shifter

• VRAM data capture. g445–g449 and g466–g468 (8× latch_comp, enable w119) capture the 8 md bus bits at the tile-data fetch phase. w119 is decoded from the fetch sequencer state (g7/g9/g208/g749/g47/g48 etc.): the capture is active while a fetch is in progress and the sequencer is in the right phase.
• Serialization. The captured byte feeds the DFFSR shift chains (block "shifter" below): the set/reset inputs of the DFFSRs are NAND combinations (g339–g346, g358–g363, g443–g444) of the captured bits and their inverses (g1–g10, g470–g471), so the data is shifted out one pixel per w44 clock edge. This is the BG pixel shifter (serial 2bpp pixels "BG_TILE0..7" in @msinger's bg_px_shifter schematic).

9. Sprite pixel path

• X-flip muxes. g890–g897 (8× mux, select w122 = sprite_x_flip & sp_bp_cys from g705) produce both the normal and the byte-reversed order of the 8 md bits (e.g. g890: d1=md0, d0=md7; g891: d1=md7, d0=md0). This implements the sprite X flip.
• Sprite data latches. The two 8-bit banks g450–g458/g462/g465 (enable w34) and g453/g455/g457/g459–g461/g463–g464 (enable w307) hold the normal and the flipped byte (w34/w307 are complementary enables derived from the sprite fetch state g190–g193/g166/g690/g691/g203/g904). The selected byte enters the DFFSR shift chains — this is the sprite pixel shifter (sp_px_shifter).
• Priority / OBJ enable. The shifted sprite pixels and the attributes obj_color (w198) / obj_prio (w523) from PPU2 are merged by the combinational cloud g348–g351, g375–g420, g425–g444, g680–g681, g694–g695, g700, g728–g729, g769, g836, g905: the OBJ enable bit FF40_D1 (w822) gates the object pixel output (w439/w694 → w438 → w435), and the result w104 is fed to the pixel mux (block 11).
• Sprite buffer page control. sp_bp_cys (w123 = !(w648 | !mode3), g489, g835, g783) and the read strobe n_sp_bp_mrd (w548 = !(w205 & w123), g702, g52) coordinate the sprite buffer page fetches with the arbiter.

10. Sprite selection (ring counter)

The seven toggle flip-flops g282–g285, g316–g317, g319 (reset w405 = !(w416 | !n_ppu_reset) from g770) with their cross-coupled clocks (w403/w404/w674/w703/w925/w926, base clock w509 = OAM clock half w862) form a ring / Johnson counter that steps through the sprite processing slots. The four NAND7s g784–g787 decode the ring state into the sprite-select/priority conditions, combined by g907 (NAND4) into w929, latched by g318 into w666 — the LAST_SPRITE marker that ends the LCD clock-pulse generation (n_lcd_cpg, see block 12). w416 (the ring-complete decode latched by g281) serves as the V-counter line clock vclk2 (block 4) and the LCD CPL source. This block is the physical home of the sprite-slot selection that @msinger draws as sprite_control / sprite_store / sprite_x_prio.

11. Palettes + pixel mux (LD0/LD1 serializer)

The palette registers (block 2) and the shifted pixel streams meet in the seven AOI-style AND-OR (aon2222) cells g804–g810, which form the pixel mux and the final serializer:

• g804/g805 combine the BG pixel stream (from w104 and the shift-phase selectors g756–g763, w110/w111/w454/w455) with the BGP bits → w937/w767 (BG color);
• g806/g807 combine the object-0 stream with the OBP0 bits → w768/w939;
• g808/g809 combine the object-1 stream with the OBP1 bits → w781/w2;
• g810 combines the four STAT interrupt enable bits with the mode/LYC conditions → w650 = ppu_int_stat (block 14).

The two OR3s g814/g815 merge the three color sources into the two serial pixel lines: w525 = w767|w768|w781 and w3 = w937|w939|w2; g482/g483 (not2) output them as the LCD data lines n_lcd_ld0 / n_lcd_ld1. Each aon2222 pairs (bit1, bit0) of a 2bpp pixel and the four pairs of a stage correspond to four pixels, so the block serializes the fetched 2bpp tile data into the two data bits of the LCD driver, one pixel per phase — exactly the "pixel_mux" of the schematic.

12. LCD driver timing

The LCD driver control signals are generated from the counters and the frame/fetch state:

All outputs are active-low (not3/not2 output buffers, n_ prefix).

13. OAM parse clocks (mode 2)

During Mode 2 (OAM scan) PPU1 generates the timing for PPU2's OAM read sequence:

• g303–g304 (two dffr dividers on the PPU clock phases w363/w362, reset w148) and g315 produce the OAM clock phases: w288 = ppu_clk/2, w286/w287 (the two half-phases), and w862 = ppu_clk/4 (used as the base clock of the sprite ring, block 10);
• oam_addr_ck = w492 (g499), oam_rd_ck = w285 (g498), oam_xattr_latch_cck = w360 (g130, from g361 = !(w287|w288)), obj_prio_ck = w291 (g494, from w290 = w239|w240 at g832/g751);
• oam_mode3_nrd = w337 (g135): low while the OAM is read during Mode 3 — w338 = w225 & w239 (g722), w225 = !(w594|w522|w226) (g903);
• oam_mode3_bl_pch = w223 (g141): w224 = w205 & w225 (g709) — the OAM bitline precharge disable, slightly longer than oam_mode3_nrd (see the comment in the netlist, issue #328).

14. Interrupt outputs

• ppu_int_stat = w377 (g827): w650 from the AND-OR cell g810 = (en0&c0)|(en1&c1)|(en2&c2)|(en3&c3) — the four STAT interrupt enable latches (block 2) AND-ed with their conditions (the latched LY==LYC flag w546, the VBlank state w175, and the mode/fetch conditions w775 = !vbl & vclk2, w651) and OR-ed together: the STAT interrupt request.
• ppu_int_vbl = w378 (g826): w175 — the VBlank flag captured by g332 (dffr on w174), i.e. vbl delayed by one clock.

15. Reset and clock generation

• Soft reset: n_ppu_reset = w148 = w81 & w82 (g497, g412) = LCDC.7 & n_ppu_hard_reset — the PPU is held in reset whenever the LCD is disabled (LCDC.7 = 0) or the hard reset is asserted. w148 resets the counters (H, V, TM, TD), the fetch sequencer and the mode latches; its inverse w406/w421/w644 feeds the LCD-driver logic.
• Hard reset tree: n_ppu_hard_reset → w136/w137/w138, w246, w249 (buffered/inverted) clears all register latches.
• Constant: g867 (const) produces w14 = 0 and w47 = 1 (used e.g. in the tile-data address bits 11–12, block 7).
• Fetch/register clock: w44 (block 6) — the "4 MHz"-ish gated PPU clock that drives the H counter and the shifters.
• PPU clock domains: ppu_clk (w365), n_ppu_clk (w317), the divided clocks w363/w362, and the OAM clock halves w288/w862.

16. DMA interface

• fexx: fexx = w817 (g514) = !ffxx & arb_fexx_ffxx (g371, g181) — the FExx (VRAM/OAM) vs FFxx (register) area indicator sent to PPU2.
• n_dma_phi2_latched: w74 (g500) from the NOR-latch g873 (set by w150 = !n_dma_phi via g137, reset by w151 = fexx & ppu_wr via g723) — the latched inverted DMA clock 2 sent to PPU2.
• vram_to_oam / CPU address mux: the DMA transfer signal w571 participates in w236 = vram_to_oam | ppu_mode3 (block 7), letting the CPU address drive nma during DMA, and in the fetch-enable logic.

Clock domains

Map

Verified by the PPU testbench (issue #390)

The joint testbench (HDL/soc/icarus/ppu, see waves.md) runs the real PPU1+PPU2 netlists together with behavioral VRAM/OAM models and confirmed:

• the per-line rhythm: 456 clock ticks per scanline, mode 2 (OAM scan) ≈ 80 ticks, mode 3 (BG fetch) starts right after mode 2, LY increments once per line, h_restart pulses at line end;
• the BG fetch pipeline: in mode 3 PPU2 places the scroll-adder results on nma (map row (V+SCY)>>3 at nma[9:5], column (H+SCX)>>3 at nma[4:0], vertical fine (V+SCY)&7 at nma[3:1] — see PPU2, block 2), PPU1 captures the tile-map byte and then the two tile-data bytes at the row given by LY&7 ($8010-style tile*16 + row*2 addressing with the tile index from the map byte), and the pixel serializer emits 160 LD0/LD1 samples per line matching the VRAM content through the palette mux; the scroll adders were verified end-to-end by the tb_ppu_scroll test (SCY=1 → map row (LY+SCY)>>3; SCX=8 → first fetched map column SCX>>3);
• register write/read through the CPU bus: LCDC/SCY/SCX/BGP store the written values, ppu_rd/ppu_wr are produced by PPU2 from soc_rd/soc_wr, LY read-back tracks the V counter;
• the WIN layer: with LCDC.5/6 + WY/WX programmed (window covering the screen), the tile-map fetches switch to the window tile map ($9C00 with LCDC.6=1) — the WY/WX compare and in_window muxing of this page's block 5 are verified by tb_ppu_window.

Open questions

• The exact division of labor between PPU1 and PPU2 for the sprite logic: PPU1 contains the sprite pixel data path, the X-flip, the ring counter and the LAST_SPRITE detection, while PPU2 owns the OAM scan itself. The PPU2 side is now analysed in PPU2 (mode-2 scan engine, 10-slot sprite store, compare); the OAM-port byte organisation and the store↔slot schedule are still being pinned down by the sprite testbench (see PPU2 open questions).
• The precise dot-level timing of the fetch phases (how w44 pulses map to the 2-dot VRAM access rhythm) is not fully derived here; the testbench shows one tile-map + two tile-data fetches per 8-pixel group but the exact sub-dot schedule remains to be written up.
• The dffr_comp bank g882–g889 is interpreted as the sprite tile-index/address register; its exact capture source (during mode 2 via md, or during mode 3) should be confirmed with a waveform dump of the sprite-fetch test. (Round-22 probe: no async reset (nr1 = w47 = const1) and the cells hold x during operation because they are clocked with undefined data; forcing them to 0 does not change the inert obj_prio_ck.)
• The role of the ring counter's seven flip-flops vs the 10-sprite store of the DMG (the ring is probably reused for groups of sprites) needs verification.

Suspected netlist issues (reported to the author, NOT fixed here)

• g652 (ppu1.v:1837) — latchr_comp with the $FF40 write enable (ena w84), data D7 (w79) and reset w82; its output w149 is read only by g305. Looks like a duplicate capture of LCDC.7 next to g656 (which drives w81); probably an intentional layout copy, but it is not documented in the register table above.

• STAT read-back encoding (frame test, round 15): during LY==LYC the LYC-coincidence interrupt fires, but reading $FF41 returns bits with bit7=1 and bit2=0 (e.g. 0xC2/0xC3) - i.e. bit 7 is not 0 as expected and the coincidence flag reads 0 while the interrupt condition is true. Either the read-back polarity for bits 2/7 is inverse-hold (the d-bit drivers g859/g854 etc. feed nq sources) or bit 2 is only asserted briefly; worth an author check (ppu1.v STAT read path, block 2/14). Netlist detail (round 16): bit2 read = q of g906 (nor_latch s=w546, r=w737 = hard-reset | STAT-write); w546 = g280 dffr sampling the live LY==LYC compare (w736) on the /4 OAM clock w509; the compare equals 1 for the whole line, so the observed 0 is unexpected given the LYC interrupt fires from the same flag - needs an author check.

• g325/g326 (ppu1.v:1510-1511) — the w530 window dividers of the sprite-process ring reset term have no async reset (nr1 = w47 = const1). In the testbench they power up deterministic (dmglib dffr cells declare initial val = 0); the no-reset "init-0" probe (round 22, tb_ppu_ring_init0) pins every no-reset trigger to 0 - even when clocked with x - and shows obj_prio_ck is still silent, i.e. the missing reset is a real silicon concern (undetermined power-up, no garbage recovery), not the cause of the inert sprite path (see waves.md).

References

• DMG-CPU Schematics by @msinger — schematic pages ppu_decode, background, bg_win_cycles, bg_px_shifter, sp_px_shifter, palettes, pixel_mux, lcd, sprite_*, ff41_stat correspond to the blocks above.
• DMG-CPU B Map by @msinger
• DMG-CPU Cells Reference by @msinger
• Pan Docs: Scrolling — SCY/SCX semantics and the "low 3 bits of SCX read once per scanline" behavior that matches the SCX fine-scroll comparator.
• Game Boy hardware research by @Gekkio