Extended Verification and Analysis of Monitors

Summary

Extended run of the emulator for 5 minutes with the monitors implemented in Step 0301 active, capture of generated logs, and analysis of results to verify if the green stripes reappear and what changes occur when they appear. The analysis used only samples and log statistics to avoid cluttering the context.

Critical result: The green stripes appeared after 5 minutes, but the monitors did NOT detect changes to the index 0 palette, inself.palette, nor in rendering mode. It was identified that the debug palette uses colorsgreenfor indices 1 and 2, not gray, which explains why the stripes look green when the framebuffer has values 1 or 2.

Hardware Concept

Extended Verification in Emulation

Some problems in emulation only appear after a certain runtime. This may be due to:

• Race conditions: Sync issues appearing after many iterations.
• Gradual memory corruption: Bugs that cause slow corruption that accumulates over time.
• Dynamic changes in state: The game or emulator changes its behavior after a certain time.
• Late initialization issues: Components initializing incorrectly after a delay.

Extended verification (5-10 minutes) is crucial to detect these problems that do not appear in short tests.

Log Analysis with Samples

Extended run logs can be extremely large (millions of lines). To avoid cluttering the context To keep the analysis efficient, sampling techniques are used:

• Temporary samples: First N records, last N records, every X records.
• Aggregated statistics: Counts, averages, unique values ​​instead of listing everything.
• Pattern Search: Search for specific events instead of reading the entire log.

This allows you to identify patterns and problems without processing huge files.

Debug and Index Mapping Palette

The PPU framebuffer containscolor indices(0-3), not RGB colors directly. The renderer maps these indices to RGB colors using a debug palette:

• Index 0: Mapped to white(255, 255, 255)- correct
• Index 1: Mapped to(136, 192, 112) - IT'S GREEN, NOT GRAY
• Index 2: Mapped to(52, 104, 86) - IT'S GREEN, NOT GRAY
• Index 3: Mapped to black(8, 24, 32)- correct

If the framebuffer has values ​​1 or 2, they will be displayed as green because of this palette. The problem is that after ~5 minutes, the framebuffer starts having values of 1 or 2 instead of just 0.

Fountain: Pan Docs - "Background Palette (BGP)", "Tile Data", "Framebuffer"

Implementation

The emulator was run for 5 minutes with Pokémon Red, capturing all the logs indebug_step_0302_extended.log. Then the logs of the 3 monitors were analyzed implemented in Step 0301 using PowerShell commands with sampling to avoid cluttering the context.

Analysis Commands Executed

# Count records from each monitor
Select-String -Path debug_step_0302_extended.log -Pattern "\[PALETTE-USE-TRACE\]" | Measure-Object
Select-String -Path debug_step_0302_extended.log -Pattern "\[PALETTE-SELF-CHANGE\]" | Measure-Object
Select-String -Path debug_step_0302_extended.log -Pattern "\[CPP-PPU-TOGGLE\]" | Measure-Object

# Log samples
Select-String -Path debug_step_0302_extended.log -Pattern "\[PALETTE-USE-TRACE\]" | Select-Object -First 20
Select-String -Path debug_step_0302_extended.log -Pattern "\[PALETTE-USE-TRACE\]" | Select-Object -Last 20

Monitor Results

• [PALETTE-USE-TRACE]: 105 records - All show white palette(255, 255, 255)for index 0 throughout the execution
• [PALETTE-SELF-CHANGE]: 0 changes -self.palettenever changed
• [CPP-PPU-TOGGLE]: 0 changes -use_cpp_ppunever changed (always true)

Critical Finding

The monitors detected NO changes when the green streaks appeared at 5 minutes. This suggests that:

• The problem is NOT in the index 0 palette (it was always white)
• The problem is NOT inself.palette(never changed)
• The problem is NOT in the rendering mode (always C++ PPU)

Additional research: Reviewed the renderer code and found that the debug palette use colorsgreenfor indices 1 and 2, not gray. If the framebuffer has values 1 or 2, They will display as green.

Affected Files

• debug_step_0302_extended.log- Extended execution logs (generated, NOT read in full)
• ANALYSIS_STEP_0302_VERIFICATION.md- Executive analysis document (new)
• src/gpu/renderer.py- Revised to identify debug palette (lines 496-497)
• docs/bitacora/entries/2025-12-25__0302__verificacion-extendida-analisis-monitors.html- This entry (new)
• docs/bitacora/index.html- Updated with entry 0302
• REPORT_PHASE_2.md- Updated with Step 0302

Tests and Verification

The verification was carried out through extended execution and log analysis:

• Extended run: 5 minutes of execution with Pokémon Red
• Monitor analysis: 105 [PALETTE-USE-TRACE] records analyzed with samples
• Visual verification: User confirmed that the green stripes appeared after 5 minutes
• Code analysis: Renderer code review identified green palette for indices 1 and 2

Analysis command executed:

Select-String -Path debug_step_0302_extended.log -Pattern "\[PALETTE-USE-TRACE\]" | Measure-Object
# Result: Count: 105

Sample logs:

[PALETTE-USE-TRACE] Frame 0 | use_cpp_ppu=True | debug_palette[0]=(255, 255, 255) | self.palette[0]=(255, 255, 255)
[PALETTE-USE-TRACE] Frame 5000 | use_cpp_ppu=True | debug_palette[0]=(255, 255, 255) | self.palette[0]=(255, 255, 255)
# All records show white palette

Sources consulted

• Pan Docs: "Background Palette (BGP)", "Tile Data", "Framebuffer"
• Best debugging practices in emulation: Log analysis with sampling

Educational Integrity

Next Steps

• [ ] Step 0303: Fix debug palette changing green colors to true gray for indexes 1 and 2
• [ ] Step 0304: Implement framebuffer monitor to track what indices the framebuffer has in each frame
• [ ] Step 0305: Analyze PPU C++ code to identify where values ​​1 or 2 are written to the framebuffer
• [ ] Step 0306: Check for memory corruption or bugs in the C++ PPU that appear after a certain time