Operación Sniper: Disección de Bucles Críticos

Resumen

Este Step implementa un sistema de "Sniper Traces" (trazas de francotirador) para capturar instantáneas precisas del estado de la CPU en puntos críticos del código de Pokémon Red. El objetivo es entender por qué el juego está atrapado en bucles de espera en las direcciones 0x36E3 (limpieza de VRAM) y 0x6150/0x6152 (espera del flag 0xD732).

Se añadió instrumentación quirúrgica que imprime el estado completo de la CPU (registros, opcodes, banco ROM, flags de interrupción) solo cuando el PC coincide con direcciones críticas, limitando la salida a 50 trazas por dirección para evitar saturación. Además, se implementó un "trigger" que detecta cualquier intento de escritura en 0xD732, permitiendo identificar qué código intenta modificar este flag de sincronización.

Concepto de Hardware

Los juegos de Game Boy utilizan patrones de sincronización basados en "busy loops" (bucles ocupados) y flags en WRAM para coordinar el código principal con las ISR (Interrupt Service Routines). Cuando el código principal necesita esperar a que una interrupción complete una tarea (por ejemplo, copiar datos a VRAM durante V-Blank), establece un flag en WRAM y entra en un bucle que lee ese flag repetidamente hasta que la ISR lo modifica.

En el caso de Pokémon Red, el juego espera en PC ≈ 0x6150 a que la dirección 0xD732 cambie de valor. Si este flag permanece en 0x00, el bucle nunca termina y el juego se congela. La causa puede ser:

• ISR no se ejecuta: La interrupción que debería modificar 0xD732 nunca se dispara o no se procesa correctamente.
• Banco ROM incorrecto: El código está leyendo instrucciones de un banco de ROM equivocado debido a un error en el MBC, causando que el bucle se ejecute incorrectamente.
• Condición de hardware no detectada: El juego espera un cambio de estado en un registro de hardware (STAT, LY, etc.) que no se está actualizando correctamente.

Los "Sniper Traces" permiten capturar el estado exacto de la CPU en el momento del "crimen" (cuando el PC está en una dirección crítica), proporcionando suficiente información para desensamblar mentalmente los opcodes y entender qué condición está verificando el juego.

Implementación

Se implementaron dos sistemas de instrumentación complementarios:

1. Sniper Traces en CPU.cpp

Al final del método step() (antes del cierre de la función), se añadió un bloque de diagnóstico que detecta cuando el PC coincide con direcciones críticas:

• 0x36E3: Rutina de limpieza de VRAM
• 0x6150: Bucle de espera del flag 0xD732
• 0x6152: Continuación del bucle de espera

Cuando se detecta una de estas direcciones, se imprime una traza completa que incluye:

• PC y banco ROM actual (para verificar que estamos leyendo el código correcto)
• Los 3 bytes siguientes (opcode actual + 2 bytes siguientes) para desensamblar la instrucción
• Estado completo de registros: SP, AF, BC, DE, HL
• Registros de interrupciones: IE (0xFFFF) e IF (0xFF0F)

Se usa una variable estática sniper_limit para limitar la salida a 50 trazas por dirección, evitando saturar la consola con logs masivos.

2. Trigger D732 en MMU.cpp

En el método write() de la MMU, se añadió un trigger que detecta cualquier intento de escritura en la dirección 0xD732. Este trigger imprime:

• El valor que se intenta escribir
• El PC desde el cual se realiza la escritura
• El banco ROM actual

Esto permite identificar qué código intenta modificar el flag y si hay algún intento de escribir un valor distinto de 0x00 que no se está completando correctamente.

3. Getter de Banco ROM

Se añadió el método público get_current_rom_bank() en MMU.hpp y MMU.cpp para permitir que la CPU acceda al banco ROM actualmente mapeado en el rango 0x4000-0x7FFF. Este método retorna bankN_rom_, que es el banco efectivamente mapeado en ese rango según el estado actual del MBC.

Componentes creados/modificados

• src/core/cpp/CPU.cpp – Bloque de Sniper Traces al final de step().
• src/core/cpp/MMU.cpp – Trigger D732 en write() y método get_current_rom_bank().
• src/core/cpp/MMU.hpp – Declaración pública de get_current_rom_bank().

Decisiones de diseño

Límite de trazas: Se limita a 50 trazas por dirección para evitar saturar la salida, pero es suficiente para capturar múltiples iteraciones del bucle y verificar si el estado cambia.

Opcodes siguientes: Se leen 3 bytes (opcode actual + 2 siguientes) porque muchas instrucciones de Game Boy son de 2-3 bytes, permitiendo desensamblar mentalmente la instrucción completa.

Trigger sin límite: El trigger D732 no tiene límite de impresiones porque es crítico saber TODOS los intentos de escritura en este flag, incluso si son muchos. El usuario puede redirigir la salida a un archivo si es necesario.

Archivos Afectados

• src/core/cpp/CPU.cpp – Bloque de Sniper Traces (líneas ~2248-2260).
• src/core/cpp/MMU.cpp – Trigger D732 (líneas ~552-556) y método get_current_rom_bank() (líneas ~749-752).
• src/core/cpp/MMU.hpp – Declaración de get_current_rom_bank() (líneas ~120-130).

Tests y Verificación

Comando de prueba:

python main.py roms/pkmn.gb

Resultados obtenidos:

• Total de trazas capturadas: 52
• Trazas [SNIPER]: 50 (todas en PC:36E3)
• Trazas [TRIGGER-D732]: 1 (desde PC:1F80)

Análisis de PC:36E3 - Rutina de Limpieza de VRAM

Opcodes capturados: 22 0B 78

Desensamblado:

• 0x22: LD (HL+), A - Escribe A en (HL) e incrementa HL
• 0x0B: DEC BC - Decrementa BC
• 0x78: LD A, B - Carga B en A

Patrón observado:

• BC: Decrementa de 2000 → 1FFF → 1FFE... (contador de iteraciones)
• HL: Incrementa de 8000 → 8001 → 8002... (puntero VRAM)
• A: 00 (escribe ceros en VRAM)
• Banco ROM: 1 (correcto)

Interpretación: Esta es una rutina de limpieza de VRAM que escribe 0x00 en todas las direcciones desde 0x8000 en adelante, usando BC como contador (2000 iteraciones = 8KB de VRAM).

Hallazgo Crítico: Interrupciones Deshabilitadas

Estado de interrupciones capturado:

• IE (0xFFFF): 00 - TODAS LAS INTERRUPCIONES DESHABILITADAS
• IF (0xFF0F): 01 - V-Blank pendiente (bit 0 activo) pero no se procesa porque IE=0

Consecuencia: Las ISR (Interrupt Service Routines) no se pueden ejecutar, lo que explica por qué el flag 0xD732 nunca cambia: la ISR que debería modificarlo no se ejecuta.

Análisis de 0xD732

Escritura detectada: [TRIGGER-D732] Write 00 from PC:1F80 (Bank:1)

• Solo hay UNA escritura desde PC:1F80 con valor 00
• El flag nunca se modifica después
• Esto confirma que ninguna ISR está modificando este flag (porque IE=0)

PC:6150/6152 - Bucle de Espera

Trazas capturadas: 0

El juego NO está llegando a estas direcciones durante la ejecución capturada, lo que sugiere que se queda atascado ANTES de llegar al bucle de espera.

Conclusión del Análisis

Causa raíz identificada:

1. El juego deshabilita todas las interrupciones (IE=0x00)
2. Hay una V-Blank pendiente (IF=0x01) que no se puede procesar porque IE=0
3. El juego espera que una ISR (probablemente V-Blank) modifique 0xD732 a un valor distinto de 0x00
4. Como IE=0, la ISR nunca se ejecuta, y el flag nunca cambia
5. El bucle de espera se vuelve infinito

Fuentes Consultadas

• Pan Docs: Memory Map, Interrupts
• Pan Docs: CPU Instruction Set
• Implementación basada en conocimiento general de arquitectura LR35902 y técnicas de debugging de emuladores.

Integridad Educativa

Próximos Pasos

Análisis completado: ✅

• [✅] Ejecutar python main.py roms/pkmn.gb y recopilar las trazas [SNIPER] y [TRIGGER-D732].
• [✅] Analizar los opcodes impresos para desensamblar mentalmente las instrucciones en direcciones críticas.
• [✅] Verificar si el banco ROM reportado coincide con el esperado (Banco 1, correcto).
• [✅] Identificar qué código intenta escribir en 0xD732 (PC:1F80, solo una vez con valor 00).
• [✅] Determinar qué condición de hardware o interrupción está omitiendo el emulador (IE=0, interrupciones deshabilitadas).

Próximos pasos identificados:

• [ ] Buscar dónde se deshabilita IE: Analizar el código antes de PC:36E3 para encontrar dónde se escribe 0x00 en 0xFFFF.
• [ ] Verificar el bucle de espera: Desensamblar el código en 0x6150/0x6152 para confirmar que lee 0xD732.
• [ ] Implementar corrección: Si el juego debería tener IE habilitado, corregir el código que lo deshabilita incorrectamente, o verificar si el juego debería habilitar IE antes del bucle de espera.