Step 0473: Evidence Only — Is STOP Executed? Does KEY1 Arm? Does it leave the Hotspot PC?

Summary

Step 0472 implemented STOP/KEY1 but it is not validated: flat frames continue. Step 0473 gets real evidence of whether STOP/KEY1 runs on real ROMs and whether the game exits the PC hotspot.Zero new features, only execution ofrom_smokewith metrics already implemented in Step 0472 and automatic decision based on data.

Result:✅ Evidence obtained. ❌ Speed-switch is NOT being attempted on any of the tested ROMs (tetris_dx.gbc, mario.gbc). ❌key1_write_count == 0andstop_executed_count == 0in all frames. ✅Automatic conclusion (Case 1): The problem is NOT STOP/KEY1; is another condition (init loop, another IO, etc.). The STOP/KEY1 fix does not come into play because the game does not try to speed switch.

Context

Step 0472 is NOT validated as a solution:

• Flat frames continue (7 white + 1 black)
• The pipeline presents frames (FPS/time running), but the game is not generating a framebuffer with content
• The STOP/KEY1 fix may be fine "in test", but we don't know if it is running on real ROM

Absolute priority: No more code until we have evidence of whether the game executes STOP/KEY1 and exits the loop.

Implementation

Zero new code. Only the existing instrumentation from Step 0472 was used:

• stop_executed_count, last_stop_pc(CPU)
• key1_write_count, last_key1_write_value, last_key1_write_pc(MMU)
• joyp_write_count, last_joyp_write_value, last_joyp_write_pc(MMU)
• PC, IME, I.E., I.F.(CPU/MMU)
• fb_nonzero(PPU)
• PC hotspots top3 (de Step 0470)

It was executedrom_smoke_0442.pywith--frames 240for:

• tetris_dx.gbc
• mario.gbc

Snapshots every 60 frames (frames 0, 60, 120, 180) with all metrics listed.

Results

Summary Table by ROM

Detailed Snapshots

tetris_dx.gbc

Frame=0 | PC=0x1305 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=60 | PC=0x1305 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=120 | PC=0x1303 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=180 | PC=0x1383 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=6409

mario.gbc

Frame=0 | PC=0x129D | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=60 | PC=0x12A0 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=120 | PC=0x12A0 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0
Frame=180 | PC=0x12A0 | STOP_count=0 | KEY1_write_count=0 | KEY1=0x00 | fb_nonzero=0

Automatic Decision

Case 1: Speed-switch is NOT being attempted ✅ CONFIRMED

Condition:

• key1_write_count == 0andstop_executed_count == 0in all ROMs and all frames

Interpretation:

• The game is not trying to speed switch
• The STOP/KEY1 fix does not come into play (it is not executed)
• Conclusion: The problem is NOT STOP/KEY1; is another condition (init loop, other IO, etc.)

Next step: Investigate what condition is blocking (PC hotspots, IO reads, etc.)

Additional Observations

• tetris_dx.gbc: Partial progress detected (fb_nonzero=6409 at frame 180, PC hotspots change slightly but still dominant)
• mario.gbc: No progress (fb_nonzero=0 in all frames, PC hotspots very stable: 0x12A0, 0x129D, 0x12A2)
• Both ROMs haveIE=0x00sustained (confirming finding of Step 0470)
• Both ROMs haveIME=0sustained

Hardware Concepts

CGB Speed ​​Switch: Optional mechanism that some CGB games use to switch between normal speed (4.19 MHz) and double speed (8.38 MHz). The process requires:

1. Write to KEY1 (0xFF4D) with bit0=1 to prepare the switch
2. Execute STOP (opcode 0x10) to activate the change
3. Hardware toggles bit7 (indicates current speed) and clears bit0

Not all CGB games use speed switch. If a game does not write to KEY1 or execute STOP, the fix in Step 0472 does not come into play. The problem must be something else (init loop, IO wait, etc.).

Tests and Verification

Command executed:

export PYTHONPATH=/media/fabini/8CD1-4C30/ViboyColor:$PYTHONPATH
export VIBOY_DEBUG_PPU=0
python3 tools/rom_smoke_0442.py roms/tetris_dx.gbc --frames 240 | tee /tmp/viboy_0473_tetris_dx.log
python3 tools/rom_smoke_0442.py roms/mario.gbc --frames 240 | tee /tmp/viboy_0473_mario.log

Result: ✅ Snapshots obtained for both ROMs. ✅ STOP/KEY1 metrics available in all frames. ✅ Automatic decision applied (Case 1 confirmed).

Native Validation: Validation of compiled C++ module through real execution of ROMs.

Affected Files

None(existing instrumentation execution of Step 0472 only).

Logs generated:

• /tmp/viboy_0473_tetris_dx.log
• /tmp/viboy_0473_mario.log

Next Steps

Given thatCase 1is confirmed (speed-switch is NOT attempted), the next step is to investigate what condition is blocking:

• PC hotspots very stable (0x12A0, 0x129D, 0x12A2 in mario.gbc) → possible init loop
• IE=0x00 sustained → confirming finding of Step 0470 (IE writes lost or overwritten)
• IME=0 sustained → interrupts disabled
• JOYP writes present in tetris_dx.gbc but not in mario.gbc → possible difference in init sequence

Step 0474you should investigate:

• Why does IE stay at 0x00 even though there are writes? (Step 0470 identified the problem but did not resolve it)
• Why are PC hotspots so stable? (possible init loop waiting for condition that is never met)
• What IO reads/writes are happening on the hotspots? (Step 0470 instrumentation can help)