El Francotirador: Cazando el Bucle Infinito

Resumen

El "Estetoscopio" (Step 0222) reveló que la CPU está atrapada en un bucle infinito en la dirección de memoria 0x02B4, con el fondo apagado (LCDC Bit 0 = 0) y la VRAM vacía. Para entender qué condición de salida no se está cumpliendo (probablemente esperando V-Blank o un estado específico de hardware), implementamos un trazado condicional que solo se activa cuando el PC está en el rango 0x02B0-0x02C0. Esta instrumentación quirúrgica nos permitirá ver las instrucciones del bucle y los valores de los registros sin saturar la consola con logs masivos.

Concepto de Hardware

Cuando un juego de Game Boy se inicia, típicamente sigue este flujo:

1. Inicialización de hardware: Configura registros de I/O (LCDC, BGP, etc.)
2. Espera de V-Blank: Muchos juegos esperan el primer V-Blank antes de copiar gráficos a VRAM
3. Copia de gráficos: Transfiere tiles desde ROM a VRAM
4. Activación del fondo: Enciende el LCDC Bit 0 para mostrar el fondo

El problema que estamos enfrentando es que el juego está atascado en el paso 2: está esperando V-Blank, pero nuestro emulador no está generando V-Blank correctamente, o el juego está leyendo un registro de hardware (como STAT o LY) que no está actualizándose como espera.

El registro LY (Line Y) en la dirección 0xFF44 indica la línea de escaneo actual (0-153). Cuando LY alcanza 144, la PPU entra en modo V-Blank. Muchos juegos hacen polling de este registro en un bucle como:

wait_vblank:
    LDH A, (0x44)    ; Lee LY
    CP 0x90          ; Compara con 144 (0x90)
    JR NZ, wait_vblank  ; Si no es 144, vuelve a esperar

Si LY nunca alcanza 144 (porque la PPU no está avanzando), el juego se queda atascado en este bucle infinitamente. El "Francotirador" nos permitirá ver exactamente qué instrucciones se están ejecutando y qué valores están comparando.

Implementación

Implementamos un bloque de debug condicional en el método step() de la CPU que solo imprime información cuando el PC está en el rango problemático (0x02B0-0x02C0). Esto nos permite ver:

• PC: La dirección de memoria actual (para ver el flujo del bucle)
• Opcode: La instrucción que se está ejecutando
• AF: El registro AF (contiene flags y acumulador, útil para ver comparaciones)
• LY: El valor actual de la línea de escaneo (crítico para detectar si V-Blank está funcionando)

Modificación en CPU.cpp

Se añadió un bloque condicional justo antes del fetch del opcode:

// --- Step 0223: EL FRANCOTIRADOR (Debug Quirúrgico) ---
// Solo imprimimos si el PC está en la zona caliente del bucle infinito (0x02B0 - 0x02C0)
// Esto nos dirá qué está comprobando el juego sin saturar la consola.
if (regs_->pc >= 0x02B0 && regs_->pc <= 0x02C0) {
    uint8_t opcode_preview = mmu_->read(regs_->pc);
    uint8_t ly_value = (ppu_ != nullptr) ? ppu_->get_ly() : 0;
    printf("[SNIPER] PC: 0x%04X | Opcode: 0x%02X | AF: 0x%04X | LY: %d\n", 
           regs_->pc, opcode_preview, regs_->get_af(), ly_value);
}
// -----------------------------------------------------

Decisiones de diseño

• Rango de memoria: Elegimos 0x02B0-0x02C0 porque el "Estetoscopio" detectó que el PC estaba en 0x02B4. Incluimos un rango para capturar todo el bucle, no solo una instrucción.
• Información mínima: Solo imprimimos PC, Opcode, AF y LY. Esto es suficiente para identificar el bucle sin saturar la consola.
• Verificación de PPU: Verificamos que ppu_ no sea nullptr antes de llamar a get_ly() para evitar crashes.
• Sin límite de impresiones: A diferencia del trace anterior (Step 0205) que limitaba a 200 instrucciones, este no tiene límite porque solo se activa en un rango muy pequeño de memoria, por lo que no saturará la consola.

Archivos Afectados

• src/core/cpp/CPU.cpp - Añadido bloque de debug quirúrgico "El Francotirador" en el método step()

Tests y Verificación

Para validar esta implementación:

1. Recompilar: Ejecutar .\rebuild_cpp.ps1 para recompilar la extensión Cython con el nuevo código C++.
2. Ejecutar: python main.py roms/tetris.gb
3. Observar salida: La consola debería mostrar líneas como:

   [SNIPER] PC: 0x02B4 | Opcode: 0xE0 | AF: 0xXXXX | LY: XX
   [SNIPER] PC: 0x02B6 | Opcode: 0xFE | AF: 0xXXXX | LY: XX

4. Análisis esperado:
   • Si vemos Opcode: 0xF0 (LDH A, (n)) seguido de Opcode: 0xFE (CP d8) con LY constante: El juego está esperando V-Blank pero LY no avanza.
   • Si vemos Opcode: 0xF3 (LDH A, (0x41)) seguido de comparaciones: El juego está esperando un modo específico de STAT.
   • Si vemos que LY cambia pero el bucle continúa: El juego está esperando otra condición (posiblemente un flag de interrupción).

Validación de módulo compilado C++: El código se compila en la extensión Cython, por lo que cualquier error de compilación se detectará durante rebuild_cpp.ps1.

Fuentes Consultadas

• Pan Docs: LCDC Register - Registro de control del LCD
• Pan Docs: STAT Register - Registro de estado del LCD
• Pan Docs: LY Register - Registro de línea de escaneo Y
• Pan Docs: CPU Instruction Set - Conjunto de instrucciones del LR35902

Integridad Educativa

Próximos Pasos

• [ ] Ejecutar el emulador y recopilar el log del "Francotirador"
• [ ] Analizar el patrón de instrucciones para identificar el bucle exacto
• [ ] Verificar si LY está avanzando o estático
• [ ] Si LY no avanza: Investigar por qué la PPU no actualiza LY
• [ ] Si LY avanza pero el bucle continúa: Investigar la condición de salida del bucle
• [ ] Implementar la corrección necesaria basada en los hallazgos