Step 0473: Solo Evidencia — ¿Se Ejecuta STOP? ¿KEY1 se Arma? ¿Sale del Hotspot PC?

Resumen

Step 0472 implementó STOP/KEY1 pero no está validado: siguen frames planos. Step 0473 obtiene evidencia real de si STOP/KEY1 se ejecuta en ROMs reales y si el juego sale del hotspot PC. Cero features nuevas, solo ejecución de rom_smoke con métricas ya implementadas en Step 0472 y decisión automática basada en los datos.

Resultado: ✅ Evidencia obtenida. ❌ Speed-switch NO se está intentando en ninguna de las ROMs probadas (tetris_dx.gbc, mario.gbc). ❌ key1_write_count == 0 y stop_executed_count == 0 en todos los frames. ✅ Conclusión automática (Caso 1): El problema NO es STOP/KEY1; es otra condición (init loop, otro IO, etc.). El fix STOP/KEY1 no entra en juego porque el juego no intenta hacer speed switch.

Contexto

El Step 0472 NO está validado como solución:

• Siguen frames planos (7 blancos + 1 negro)
• El pipeline presenta frames (FPS/tiempo corre), pero el juego no está llegando a generar un framebuffer con contenido
• El fix STOP/KEY1 puede estar bien "en test", pero no sabemos si se está ejecutando en ROM real

Prioridad absoluta: No más código hasta tener evidencia de si el juego ejecuta STOP/KEY1 y sale del bucle.

Implementación

Cero código nuevo. Solo se usó la instrumentación existente de Step 0472:

• 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, IE, IF (CPU/MMU)
• fb_nonzero (PPU)
• PC hotspots top3 (de Step 0470)

Se ejecutó rom_smoke_0442.py con --frames 240 para:

• tetris_dx.gbc
• mario.gbc

Snapshots cada 60 frames (frames 0, 60, 120, 180) con todas las métricas listadas.

Resultados

Tabla Resumen por ROM

Snapshots Detallados

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

Decisión Automática

Caso 1: Speed-switch NO se está intentando ✅ CONFIRMADO

Condición:

• key1_write_count == 0 y stop_executed_count == 0 en todas las ROMs y todos los frames

Interpretación:

• El juego no está intentando hacer speed switch
• El fix STOP/KEY1 no entra en juego (no se ejecuta)
• Conclusión: El problema NO es STOP/KEY1; es otra condición (init loop, otro IO, etc.)

Próximo paso: Investigar qué condición está bloqueando (PC hotspots, IO reads, etc.)

Observaciones Adicionales

• tetris_dx.gbc: Progreso parcial detectado (fb_nonzero=6409 en frame 180, PC hotspots cambian ligeramente pero siguen dominantes)
• mario.gbc: Sin progreso (fb_nonzero=0 en todos los frames, PC hotspots muy estables: 0x12A0, 0x129D, 0x12A2)
• Ambas ROMs tienen IE=0x00 sostenido (confirmando hallazgo de Step 0470)
• Ambas ROMs tienen IME=0 sostenido

Conceptos de Hardware

CGB Speed Switch: Mecanismo opcional que algunos juegos CGB usan para cambiar entre velocidad normal (4.19 MHz) y doble velocidad (8.38 MHz). El proceso requiere:

1. Escribir a KEY1 (0xFF4D) con bit0=1 para preparar el switch
2. Ejecutar STOP (opcode 0x10) para activar el cambio
3. El hardware togglea bit7 (indica velocidad actual) y limpia bit0

No todos los juegos CGB usan speed switch. Si un juego no escribe a KEY1 ni ejecuta STOP, el fix de Step 0472 no entra en juego. El problema debe ser otra cosa (init loop, espera de IO, etc.).

Tests y Verificación

Comando ejecutado:

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

Resultado: ✅ Snapshots obtenidos para ambas ROMs. ✅ Métricas STOP/KEY1 disponibles en todos los frames. ✅ Decisión automática aplicada (Caso 1 confirmado).

Validación Nativa: Validación de módulo compilado C++ mediante ejecución real de ROMs.

Archivos Afectados

Ninguno (solo ejecución de instrumentación existente de Step 0472).

Logs generados:

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

Próximos Pasos

Dado que Caso 1 está confirmado (speed-switch NO se intenta), el siguiente paso es investigar qué condición está bloqueando:

• PC hotspots muy estables (0x12A0, 0x129D, 0x12A2 en mario.gbc) → posible init loop
• IE=0x00 sostenido → confirmando hallazgo de Step 0470 (IE writes lost or overwritten)
• IME=0 sostenido → interrupciones deshabilitadas
• JOYP writes presentes en tetris_dx.gbc pero no en mario.gbc → posible diferencia en init sequence

Step 0474 debería investigar:

• ¿Por qué IE permanece en 0x00 aunque hay writes? (Step 0470 identificó el problema pero no lo resolvió)
• ¿Por qué PC hotspots son tan estables? (posible init loop esperando condición que nunca se cumple)
• ¿Qué IO reads/writes están ocurriendo en los hotspots? (instrumentación de Step 0470 puede ayudar)