Cese el Fuego: La Ejecución Final

Resumen

El debug quirúrgico del "Francotirador" (Step 0223) confirmó que la CPU estaba funcionando correctamente. El bucle de espera de V-Blank (LY < 144) es comportamiento normal del hardware. La aparente congelación se debía a la latencia introducida por los logs de consola. Se retiró toda la instrumentación de debug (Francotirador y Estetoscopio) para permitir que el emulador ejecute a velocidad nativa (60 FPS) y supere los bucles de espera en una fracción de segundo.

Concepto de Hardware

En la Game Boy real, la CPU ejecuta a 4.19 MHz, lo que significa que un frame completo (144 líneas visibles + 10 V-Blank) se completa en aproximadamente 16 milisegundos. Durante la inicialización, muchos juegos esperan V-Blank antes de copiar gráficos a VRAM porque es el único momento "seguro" en que la PPU no está leyendo VRAM activamente.

El bucle típico de espera de V-Blank es:

loop:
    LDH A, (0xFF44)  ; Leer LY (línea actual)
    CP 0x90          ; Comparar con 144 (V-Blank)
    JR NZ, loop      ; Si no es 144, repetir

Este bucle es completamente normal y se ejecuta en una fracción de segundo en hardware real. Sin embargo, cuando añadimos logs de consola (`printf`) dentro del bucle, cada instrucción tarda milisegundos en imprimir, haciendo que el bucle que normalmente dura 16ms se convierta en minutos. Esto crea la ilusión de que el emulador está "congelado" cuando en realidad está funcionando correctamente, solo que a cámara super-lenta.

La solución es eliminar toda la instrumentación de debug del bucle crítico de emulación. El código C++ debe ejecutarse sin I/O de consola para mantener el rendimiento nativo. Una vez que el emulador corre a velocidad real, los bucles de espera se completan instantáneamente y el juego procede normalmente.

Implementación

Se eliminó toda la instrumentación de debug del bucle crítico de emulación:

Componentes modificados

• CPU.cpp: Eliminado el bloque del "Francotirador" (Step 0223) que imprimía logs cuando PC estaba en 0x02B0-0x02C0. También se comentó el include de ``.
• viboy.py: Comentado el bloque del "Estetoscopio" (Step 0222) que imprimía signos vitales cada 60 frames.

Decisiones de diseño

Se optó por comentar el código en lugar de eliminarlo completamente para facilitar futuras depuraciones si es necesario. Los comentarios explican por qué se retiró la instrumentación y qué confirmó el diagnóstico.

Regla de oro: En el bucle crítico de emulación (método `step()` de la CPU), no debe haber I/O de consola. Cualquier log debe estar fuera del bucle o ser condicional y muy limitado.

Archivos Afectados

• src/core/cpp/CPU.cpp - Eliminado bloque del Francotirador y comentado include de cstdio
• src/viboy.py - Comentado bloque del Estetoscopio

Tests y Verificación

Validación de la limpieza final:

• Recompilación: Ejecutar .\rebuild_cpp.ps1 para recompilar la extensión Cython sin los logs.
• Ejecución: Ejecutar python main.py roms/tetris.gb y verificar que:
  • No aparecen logs de [SNIPER] en la consola
  • No aparecen logs de [VITAL] en la consola
  • El juego carga y muestra la pantalla de copyright de Tetris (o el logo de Nintendo cayendo)
  • El emulador mantiene 60 FPS estables
• Validación visual: Confirmar que los gráficos se cargan correctamente y el juego es jugable (aunque sin sonido aún).

Resultado esperado: El emulador debe ejecutar a velocidad nativa, completando los bucles de espera de V-Blank en milisegundos en lugar de minutos, permitiendo que el juego proceda normalmente a cargar y mostrar gráficos.

Fuentes Consultadas

• Pan Docs: System Clock, Timing, LCD Timing
• Pan Docs: V-Blank Interrupt, LY Register

Integridad Educativa

Próximos Pasos

• [ ] Implementar APU (Audio Processing Unit) - Canal 1 (Onda cuadrada con Sweep)
• [ ] Implementar APU - Canal 2 (Onda cuadrada con Envelope)
• [ ] Implementar APU - Canal 3 (Wave RAM)
• [ ] Implementar APU - Canal 4 (Ruido LFSR)
• [ ] Mezcla de canales y salida a 44100Hz/48000Hz
• [ ] Sincronización de audio con emulación (Ring Buffer)