NES TDD

284. Проверка: CPU пишет в память PPU, затем рендеринг

ПРОВЕРКА: CPU записывает в память PPU, затем Console рендерит фоновый framebuffer.

Урок 284 из 356 · tests/chapter_05_rendering_pipeline/test_284_VALIDATION_cpu_writes_ppu_memory_then_render.py

Для этого теста не должно потребоваться никакой новой реализации, если предыдущие шаги по CPU, PPU, шине и рендерингу завершены.

Зачем нужна эта проверка

Теперь у эмулятора есть два важных пути

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

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

Этот тест проверяет, что оба пути наблюдают одно и то же состояние PPU.

Сквозной путь

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

Поведение небольшой программы CPU

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

Синтетическая настройка CHR

Данные CHR подготавливаются напрямую в памяти PPU для этой проверки. Это позволяет сосредоточить тест на записях CPU в nametable/палитру RAM и на пути рендеринга. Для Mapper000/CHR ROM графика CHR обычно поступает с картриджа.

Ожидаемый результат

top-left framebuffer pixel uses get_nes_rgb_color($03)

Важный инвариант

Записи CPU и рендеринг Console должны использовать один и тот же экземпляр PPU.

Вне рамок этого шага

  • отображение pygame
  • реальный образец ROM
  • загрузка CHR ROM через картридж
  • спрайты
  • скроллинг
  • OAMDMA

Запустить этот урок

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