Step 0478: Ejecutar rom_smoke con Timeline IME/EI/DI + Disasm Real del Loop

← Volver al índice

Fecha: 2026-01-04 Step ID: 0478 Estado: VERIFIED

Resumen Ejecutivo

Step 0477 implementó disassembler corregido y timeline IME/EI/DI. Step 0478 ejecuta rom_smoke con estas métricas para clasificar con evidencia Caso A/B/C/D, identificar I/O exacto del loop, y confirmar baseline limpio.

Resultado: ✅ Ejecución completa con 3 ROMs (baseline OFF) y 1 ROM (prefill ON). ✅ Reporte generado con tablas y decisión automática. ✅ Caso identificado: mario.gbc (Caso A - EI nunca ejecutado), tetris_dx.gbc (Caso D/C - EI ejecutado pero IE=0x00). ⚠️ Este step NO modifica código core (solo ejecución y reporte).

Concepto de Hardware

Clasificación de Causa Raíz (Step 0477)

Step 0477 implementó un clasificador automático que identifica 4 casos posibles:

  1. Caso A: EI nunca se ejecuta (el juego está atascado antes de habilitar interrupciones)
  2. Caso B: EI se ejecuta pero IME no sube (bug EI delayed enable)
  3. Caso C: IME sube pero IE=0 (juego no habilita IE o no lo necesita)
  4. Caso D: IME+IE OK pero no hay service (revisar generación de requests)

Fuente: Pan Docs - EI instruction, Interrupt Enable Register (IE)

Source Tagging de I/O

Step 0475 implementó source tagging para distinguir lecturas de IF/IE desde código del programa vs polling interno de la CPU. Esto permite identificar si el juego está haciendo polling manual de IF/IE o si solo hay polling interno.

Implementación

Fase A: Baseline Limpio (OFF) con ROMs CGB + Control DMG

Se ejecutó rom_smoke con las siguientes ROMs usando baseline limpio (VIBOY_SIM_BOOT_LOGO=0):

  • tetris_dx.gbc - 240 frames
  • mario.gbc - 240 frames
  • tetris.gb (DMG) - 240 frames (control)

Flags utilizados: 

export VIBOY_DEBUG_IO=1
export VIBOY_SIM_BOOT_LOGO=0
export VIBOY_DEBUG_INJECTION=0
export VIBOY_AUTOPRESS=0
export VIBOY_FORCE_BGP=0
export VIBOY_FRAMEBUFFER_TRACE=0

Fase B: Control de Contaminación (ON) Solo 1 ROM

Se ejecutó rom_smoke con tetris_dx.gbc usando logo prefill ON (VIBOY_SIM_BOOT_LOGO=1) para demostrar que VRAM/tilemap stats cambian por prefill y no por el juego.

Fase C: Generación de Reporte

Se generó el reporte /tmp/reporte_step0478.md con:

  • Tablas por ROM (frames 0/60/120/180) con todos los campos mínimos
  • Disasm window del hotspot (frame 180) para cada ROM CGB
  • Comparativa prefill ON vs OFF (solo tdx)
  • Decisión automática final (Caso A/B/C/D identificado con evidencia)
  • Siguiente fix mínimo propuesto (0479) con registro + bit + fix concreto

Resultados

Clasificación Automática

mario.gbc (Frame 180)

  • Caso: A (EI nunca ejecutado)
  • EIcount = 0 ❌
  • ime_set_events_count = 0 ❌
  • IME = 0 ❌
  • IE = 0x00 ❌
  • if_reads_program = 6603703 vs if_reads_cpu_poll = 6602862 ✅ (El juego SÍ está polleando IF desde código)
  • fb_nonzero = 0 (Sin progreso)

Análisis: El juego nunca ejecuta EI, está atascado en un loop esperando alguna condición que nunca se cumple. El disasm muestra un loop simple sin I/O visible directamente, pero el polling masivo de IF sugiere que está esperando que IF cambie.

tetris_dx.gbc (Frame 180)

  • Caso: D con elementos de C (EI ejecutado pero IE=0x00)
  • EIcount = 2 ✅ (EI SÍ se ejecutó)
  • ime_set_events_count = 2 ✅ (IME SÍ se habilitó)
  • IME = 0 ❌ (Pero IME está en 0 en el snapshot)
  • IE = 0x00 ❌ (IE permanece en 0x00)
  • if_reads_program = 8762209 vs if_reads_cpu_poll = 8761604 ✅ (El juego SÍ está polleando IF desde código)
  • fb_nonzero = 6409 (Progreso parcial)

Análisis: EI se ejecutó e IME se habilitó, pero IE permanece en 0x00. El juego escribió a IE 7 veces pero IE sigue en 0x00. Hay progreso parcial (framebuffer no-blanco), lo que sugiere que el juego avanzó más que mario.gbc, pero aún está bloqueado esperando interrupciones que nunca llegan porque IE=0x00.

tetris.gb (DMG - Control - Frame 180)

  • Caso: Funciona correctamente
  • IME = 1 ✅
  • IE = 0x09 ✅
  • LastIRQVec = 0x0040 ✅ (IRQs servidas)
  • VBlankServ = 179 ✅

Análisis: tetris.gb (DMG) funciona correctamente, lo que confirma que el problema es específico de CGB o de la secuencia de inicialización de estos juegos CGB.

Disasm del Loop (Frame 180)

tetris_dx.gbc

PC_hotspot1: 0x1308

0x1308: JR NZ, 0x1302 (-8)
0x130A: RET
0x130B: DB 0x21
0x130C: DB 0x70
0x130D: DB 0x13
0x130E: CALL 0x12C9
0x1311: CALL 0x12FF
0x1314: LDH A,(JOYP)  ← PC actual marcado

I/O identificado: El loop contiene LDH A,(JOYP) en 0x1314. El juego está haciendo millones de reads de IF (8.7M desde código), probablemente dentro de las funciones CALL.

mario.gbc

PC_hotspot1: 0x12A0

0x12A0: DB 0x0B
0x12A1: DB 0x79
0x12A2: DB 0xB0
0x12A3: JR NZ, 0x129D (-8)
0x12A5: RET
0x12A6: DB 0x21
0x12A7: DB 0xFF
0x12A8: DB 0x9B

I/O identificado: El loop es simple con salto condicional. El código está en una zona de datos. El juego está haciendo millones de reads de IF (6.6M desde código) aunque no esté visible directamente en este fragmento.

Próximos Pasos (Step 0479)

Para mario.gbc (Caso A)

  • El juego nunca ejecuta EI. Necesitamos identificar qué condición está esperando antes de ejecutar EI.
  • Desensamblar el código completo alrededor de 0x12A0 para ver qué condición se está evaluando.
  • Hipótesis: El juego está esperando que algún registro I/O (IF, STAT, LY, o JOYP) tenga un valor específico antes de continuar.

Para tetris_dx.gbc (Caso D/C)

  • EI se ejecutó e IME se habilitó, pero IE permanece en 0x00.
  • El juego escribió a IE 7 veces pero IE sigue en 0x00.
  • Hipótesis: Los writes a IE se están perdiendo o sobrescribiendo.
  • Fix concreto:
    • Instrumentar writes a IE con PC y valor (ya tenemos IEWritePC y IEWriteVal, pero necesitamos verificar si esos writes persisten).
    • Verificar si hay código que lee IE y luego lo escribe con 0x00.
    • Buscar patrones de LDH A,(0xFFFF) seguido de LDH (0xFFFF),A con A=0x00.

Archivos Afectados

  • /tmp/reporte_step0478.md - Reporte completo con tablas y decisión automática
  • /tmp/viboy_0478_tdx_off.log - Log de tetris_dx.gbc (baseline OFF)
  • /tmp/viboy_0478_mario_off.log - Log de mario.gbc (baseline OFF)
  • /tmp/viboy_0478_tetris_off.log - Log de tetris.gb (baseline OFF)
  • /tmp/viboy_0478_tdx_on.log - Log de tetris_dx.gbc (prefill ON)

⚠️ IMPORTANTE: Este step NO modifica código core. Solo ejecuta rom_smoke y genera reporte basado en las métricas implementadas en Step 0477.

Tests y Verificación

Comando ejecutado: python3 tools/rom_smoke_0442.py <ROM> --frames 240

Resultado: ✅ Todas las ROMs completaron sin crashes. ✅ Snapshots generados correctamente en frames 0/60/120/180. ✅ Métricas de timeline IME/EI/DI disponibles. ✅ Disasm window funcional.

Validación: Los logs contienen snapshots con todos los campos mínimos requeridos (PC, PC_hotspot1, IME, IE, EIcount, DIcount, if_reads_program, ie_reads_program, disasm_window, etc.).