284. Validation cpu writes ppu memory then render

VALIDATION: CPU writes PPU memory, then Console renders background framebuffer.

Lesson 284 of 356 · tests/chapter_05_rendering_pipeline/test_284_VALIDATION_cpu_writes_ppu_memory_then_render.py

No new implementation should be required for this test if the previous CPU, PPU, bus, and rendering steps are complete.

Why this validation exists

The emulator now has two important paths

CPU/PPU write path:
    CPU program writes PPUADDR/PPUDATA
    -> PPU memory changes

Rendering path:
    Console.render_background_framebuffer()
    -> reads current PPU memory
    -> returns Framebuffer

This test verifies those paths observe the same PPU state.

End-to-end path

CPU executes STA $2006/$2007
    -> CpuBus routes $2000-$2007 to PPU registers
    -> PPUADDR selects PPU memory address
    -> PPUDATA writes through PpuBus

Console.render_background_framebuffer()
    -> reads nametable/palette/pattern memory from console.ppu
    -> renders pure Framebuffer data

Tiny CPU program behavior

write $01 to PPU $2000
    nametable[0] = tile ID 1

write $0F,$01,$02,$03 to PPU $3F00-$3F03
    background palette 0 maps color index 3 to NES color $03

Synthetic CHR setup

CHR data is prepared directly in PPU memory for this validation. This keeps the test focused on CPU writes to nametable/palette RAM and the rendering path. For Mapper000/CHR ROM, CHR graphics normally come from the cartridge.

Expected result

top-left framebuffer pixel uses get_nes_rgb_color($03)

Important invariant

CPU writes and Console rendering must use the same PPU instance.

Out of scope

  • pygame display
  • real ROM fixture
  • CHR ROM loading through cartridge
  • sprites
  • scrolling
  • OAMDMA

Run this lesson

uv run pytest tests/chapter_05_rendering_pipeline/test_284_VALIDATION_cpu_writes_ppu_memory_then_render.py -v