Add NES PPU (Graphics): Nametables, Sprites, Palette, Rendering

Topic Overview

The NES PPU

The Picture Processing Unit renders 256x240 frames from nametables, pattern tables, palettes, and sprites. CPU emulators stay blind without PPU timing; many ROM tests fail on scanline timing alone.

Background and Sprites

Key structures:

• Nametables: 2 KiB VRAM tile maps (with mirroring modes)
• Pattern tables: 8 KiB CHR-ROM/RAM tile graphics
• OAM: 64 sprite entries (y, tile, attr, x)
• Registers: \`PPUCTRL\`, \`PPUMASK\`, \`PPUSTATUS\`, \`OAMADDR\`, scroll and addr ports

Rendering walks scanlines, fetches background tiles, evaluates sprite 0 hits, and outputs pixels through a palette lookup.

For example, writing \`0x80\` to \`PPUCTRL\` enables NMI at vblank, which games use to update tiles safely.

\`\`\` vblank -> NMI -> game updates OAM/nametable -> next frame \`\`\`

Design Notes

Nametable mirroring mode depends on the cartridge mapper wiring, not just PPU registers. Vertical versus horizontal mirroring changes which physical VRAM backs each name table address.

For This Exercise

This exercise asks you to implement PPU register stubs and a framebuffer renderer. You will simulate vblank timing and draw background tiles so CPU test ROMs can progress past boot.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Model the NES PPU (picture processing unit) closely enough to render a frame:

• 2-bitplane tiles in the pattern table;
• a 32×30 nametable with its packed attribute table;
• palette RAM with its mirrors;
• fine scrolling;
• 64 sprites in OAM, with flipping, priority, the 8-per-line limit, and sprite 0 hit.

Print regions of the 256×240 frame as NES colour numbers.

Input

One command per line (; starts a comment):

cCopy
Loading…

Every table starts zeroed, except OAM, which is filled with $FF (off-screen).

Rules

• Pixel value: bit (7-x) of plane 0, plus 2 × the same bit of plane 1, for row y. Value 0 is transparent.
• Attributes: byte $23C0 + (ty/4)·8 + tx/4 covers 32×32 px. Within it, the 16×16 quadrant (top-left, top-right, bottom-left, bottom-right) uses bits 0-1, 2-3, 4-5 and 6-7. attr prints attribute $ADDR = $VV.
• Palettes: background palette p's colour v is at $3F00 + 4p + v. Sprite palettes live at $3F10, using bits 0-1 of ATTR. Every value-0 pixel shows the backdrop $3F00. $3F10/$3F14/$3F18/$3F1C mirror $3F00/$3F04/$3F08/$3F0C for both reads and writes.
• Scroll: screen (x, y) shows world pixel ((x + SX) mod 256, (y + SY) mod 240).
• Sprites: an 8×8 sprite appears on lines Y+1 .. Y+8 and columns X .. X+7. ATTR bit 6 flips it horizontally, bit 7 vertically, and bit 5 puts it behind a non-transparent background pixel.
  • Per line, only the first 8 sprites in OAM order that cover it are drawn. The first line with more sets overflow: sprite overflow on line L (N sprites).
  • Among the drawn sprites, the lowest OAM index with a non-transparent pixel wins that pixel, even if it is behind the background.
• Sprite 0 hit: the first pixel, in scan order, where sprite 0 and the background are both non-transparent (not at x = 255). Print sprite 0 hit at x=X y=Y or sprite 0 hit: none.

Output

cCopy
Loading…

• peek prints $ADDR = $VV. Other addresses print peek $ADDR: unmapped in this model.
• Errors: each command prints its usage line:
  • tile: N (0-255) and 16 hex bytes
  • nt: X (0-31) Y (0-29) TILE...
  • attr: MX (0-15) MY (0-14) PALETTE (0-3)
  • palette: ADDR ($3F00-$3F1F) COLOURS..., or palette: colours are 00-3F (the colours before the bad one are kept)
  • sprite: N (0-63) Y TILE ATTR X
  • render: X Y W H (at most 32x32, inside 256x240)
  • unknown command X

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Render per scanline, as the PPU does: the background first, then sprite evaluation for that line, then sprite pixels.
2. Decode the attribute byte by shifting. Don't store a separate per-tile palette.

Hidden tests cover sprite flips, behind-background priority, sprite 0 hit, scrolling, the 8-sprites-per-line limit with overflow, palette mirroring, and every usage error.