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 FramebufferThis 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 dataTiny 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 $03Synthetic 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