Post-Diagnostic Cleaning: Reversing the "Checkerboard Test"

Summary

The Step 0202 "Checkerboard Test" has been a resounding success. The checkerboard pattern we saw on the screen is irrefutable proof that our C++ → Cython → Python rendering pipeline works perfectly. The diagnosis is now final: the blank screen problem is due to empty VRAM, not a rendering failure.

Now that we have validated the data pipeline, we need to restore the normal rendering logic of the PPU so we can investigate why the VRAM remains empty. This step consists of reverting the temporary changes from the "Checkerboard Test" and returning to the implementation that reads from VRAM.

The expected result is that the screen becomes white again, but this time with the absolute certainty that the problem is not in the rendering, but rather that the CPU is not executing the routine that copies the logo data from the ROM to the VRAM.

Engineering Concept: Post-Diagnostic Cleaning

Temporary diagnostic tools are incredibly powerful, but it is crucial to remove them once they have served their purpose to restore normal system behavior. The "Checkerboard Test" has given us the answer we needed: the data pipeline works. Now we need the PPU to try reading from VRAM again so we can investigate why that VRAM is empty.

The Chess Board: Our Most Important Milestone

The checkerboard pattern we saw on the screen is, in some ways, more beautiful even than the Nintendo logo. It is not the result of a game emulation; is theirrefutable proof that our architecture works. Every dark and light square we saw is confirmation that:

• The C++ framebuffer is being written correctly.
• The pointer is being passed correctly through Cython.
• HememoryviewPython is reading the data correctly.
• Pygame is rendering the pixels on the screen.

The Definitive Diagnosis:

With the "Checkerboard Test", we have isolated the problem with surgical precision. The diagnosis is definitive:

• The blank screen we saw is due to the VRAM being empty, not a rendering problem.
• The real culprit is that the CPU, for some reason, is not executing the code routine that copies the Nintendo logo data from ROM to VRAM.
• CPU is stuck in a logic loopbeforereaching that point, or the copy routine never runs.

Why load from top to bottom?because ourrender_scanline()is called for each line (L.Y.from 0 to 143), drawing the board progressively.

Why does it disappear and reload?Because our framebuffer cleanup synchronized withLY=0(Step 0200) is working perfectly. Every timeL.Y.is reset to 0 to start a new frame, the framebuffer is cleared to white, and the chessboard starts drawing again from line 0.

Implementation

The implementation consists of restoring the normal rendering logic of the PPU, removing the "Checkerboard Test" code and returning to the implementation that reads from VRAM.

Modification in PPU::render_scanline()

Insrc/core/cpp/PPU.cpp, we restore the original background rendering logic:

• We removed the "Checkerboard Test" code that generated the checkerboard pattern.
• We restore the logic that reads the LCDC, SCY, SCX registers.
• Restored tilemap and tile data address calculation.
• We restored reading tile IDs from the tilemap.
• We restored tile data decoding from VRAM.
• We restored writing the color index to the framebuffer.

The restored code is similar to what we had before Step 0202, but now with the certainty that the data pipeline works correctly.

Modified components

• src/core/cpp/PPU.cpp: Restored normal rendering logic inrender_scanline().

Design decisions

The decision to restore normal logic is obvious: the diagnostic test has served its purpose. Now we need the PPU to try reading from VRAM again so we can investigate why that VRAM is empty. The next diagnostic step will be to instrument the MMU to monitor writes to VRAM and understand why the CPU is not copying the logo data.

Affected Files

• src/core/cpp/PPU.cpp- Restored normal rendering logic inrender_scanline()

Tests and Verification

The verification consists of confirming that we return to the previous state: a blank screen, but this time with the certainty that the problem is not in the rendering.

1. Recompiling C++ module:

   .\rebuild_cpp.ps1

2. Running the emulator:

   python main.py roms/tetris.gb

3. Expected Result:The screen should bewhite. This will confirm that the PPU is attempting to read from a VRAM which, as we now know, is empty.

Native Validation:Compiled C++ module validation.

Sources consulted

• Bread Docs:LCD Timing, Background Rendering
• Implementation based on general knowledge of LR35902 architecture and software engineering practices (post-diagnostic cleanup).

Educational Integrity

Next Steps

• [ ] Instrument the MMU to monitor writes to VRAM
• [ ] Check if the CPU is executing the logo copy routine
• [ ] Understand why VRAM remains empty