Análisis Extendido y Técnicas Alternativas

Resumen

Implementación de técnicas alternativas de análisis para identificar cuándo se cargan los tiles en Pokémon Red. El análisis del Step 0295 confirmó que el código de carga NO existe en los primeros 12 segundos (todos los accesos son limpieza desde PC:0x36E3). Se implementaron monitores adicionales para rastrear cambios de estado, transiciones de pantalla, timeline de accesos VRAM y dump inicial de VRAM.

Objetivo: Ejecutar análisis extendido (30-60 segundos) y detectar patrones que indiquen transiciones a fases del juego donde se cargarían tiles.

Concepto de Hardware

Fases de Inicialización del Juego

Los juegos de Game Boy típicamente tienen múltiples fases de inicialización:

1. Boot/Reset: Inicialización básica del hardware
2. Logo de Nintendo: Si hay boot ROM, muestra el logo
3. Pantalla de título: Menú principal del juego
4. Menús: Selección de opciones
5. Pantalla de juego principal: Donde se renderiza el juego

Los tiles pueden cargarse en diferentes fases según la pantalla que se vaya a mostrar. Es posible que el código de carga no exista en la fase inicial (primeros 12 segundos) y aparezca más tarde.

Pre-carga de Tiles

Algunos juegos pre-cargan tiles básicos durante la inicialización, mientras que otros cargan tiles dinámicamente cuando cambian de pantalla. Los tiles pueden estar comprimidos en la ROM y descomprimirse antes de cargarse a VRAM.

Verificar el estado inicial de VRAM después de cargar la ROM permite determinar si el juego espera datos pre-cargados o si la carga es responsabilidad del código del juego.

Transiciones de Pantalla

Los cambios de pantalla suelen ir acompañados de:

• Cambios en scroll (SCX/SCY)
• Cambios en tilemap
• Carga de nuevos tiles
• Cambios en paleta

Detectar estos cambios permite identificar momentos donde podrían cargarse tiles.

Saltos de Código y Cambios de Estado

Los saltos grandes en el Program Counter (PC) pueden indicar transiciones a nuevas rutinas o fases del juego. Cambios significativos en registros (ej: HL) también pueden indicar cambios de contexto.

Fuente: Pan Docs - "Video RAM (VRAM)", "Scroll Registers (SCX/SCY)", "Tile Data", "CPU Instruction Set"

Implementación

Se implementaron cuatro monitores adicionales y una función de dump para análisis extendido:

Monitor [STATE-CHANGE] - Cambios de Estado del Juego

Detecta cambios de estado que podrían indicar transiciones a nuevas pantallas o fases donde se cargarían tiles.

• Saltos grandes: Detecta instrucciones JP nn (0xC3) o CALL nn (0xCD) con saltos mayores a 0x1000 bytes
• Cambios en HL: Detecta cambios significativos en el registro HL (más de 0x1000 bytes de diferencia)
• Límite de muestras: Reporta hasta 50 saltos grandes y 30 cambios en HL para evitar saturación

Ubicación: src/core/cpp/CPU.cpp - Función CPU::step()

Monitor [SCREEN-TRANSITION] - Transiciones de Pantalla

Detecta patrones que indican transiciones de pantalla, que podrían ser momentos donde se cargan nuevos tiles.

• Verificación periódica: Verifica cambios en SCX (0xFF43) y SCY (0xFF42) cada 1000 instrucciones
• Detección de cambios: Reporta cuando SCX o SCY cambian de valor
• Límite de muestras: Reporta hasta 20 transiciones para evitar saturación

Ubicación: src/core/cpp/CPU.cpp - Función CPU::step()

Monitor [TIMELINE-VRAM] - Timeline de Accesos VRAM

Crea un timeline de accesos a VRAM con marcas de tiempo relativas para identificar patrones temporales.

• Integración con [VRAM-ACCESS-GLOBAL]: Se reporta cuando se detecta un acceso a VRAM
• Tiempo relativo: Calcula tiempo aproximado en segundos desde el inicio (basado en instruction_counter)
• Formato: [TIMELINE-VRAM] T+~Xs | PC:0xXXXX | Write XXXX=XX | DATA/CLEAR
• Límite de muestras: Reporta hasta 200 muestras para evitar saturación

Ubicación: src/core/cpp/CPU.cpp - Dentro del bloque de [VRAM-ACCESS-GLOBAL]

Función dump_vram_initial_state() - Dump Inicial de VRAM

Crea un dump detallado del estado inicial de VRAM después de cargar la ROM para verificar si hay datos pre-cargados.

• Tile Data: Dump de los primeros 128 bytes (8 tiles) en formato hexadecimal
• Tile Map: Dump de los primeros 64 bytes del tilemap en formato hexadecimal
• Formato: Dirección hexadecimal seguida de 16 bytes por línea

Ubicación: src/core/cpp/MMU.cpp - Función MMU::dump_vram_initial_state()

Llamada: Se llama automáticamente desde MMU::load_rom() después de cargar la ROM

Decisiones de Diseño

• Límites de muestras: Todos los monitores tienen límites para evitar saturación de logs y contexto
• Verificación periódica: [SCREEN-TRANSITION] verifica cada 1000 instrucciones para balancear detección y rendimiento
• Integración con monitores existentes: [TIMELINE-VRAM] se integra con [VRAM-ACCESS-GLOBAL] para no duplicar lógica
• Dump inicial: Se ejecuta una sola vez al cargar la ROM para no afectar rendimiento durante ejecución

Archivos Afectados

• src/core/cpp/CPU.cpp - Añadidos monitores [STATE-CHANGE], [SCREEN-TRANSITION] y [TIMELINE-VRAM]
• src/core/cpp/MMU.cpp - Añadida función dump_vram_initial_state() y llamada desde load_rom()
• src/core/cpp/MMU.hpp - Añadida declaración de dump_vram_initial_state()

Tests y Verificación

La implementación se validó mediante:

• Compilación exitosa: La extensión Cython se compiló sin errores
• Validación de módulo compilado C++: Los monitores están integrados en el bucle de ejecución

Próximos pasos de verificación:

1. Ejecutar el emulador durante 30-60 segundos con Pokémon Red
2. Redirigir la salida a un archivo de log
3. Analizar los logs para identificar:
   • Si aparecen accesos con datos después de 12 segundos
   • Si se detectan cambios de estado que indiquen transiciones
   • Si hay datos pre-cargados en VRAM
   • Si el timeline muestra patrones temporales

Comando de ejecución sugerido:

python main.py roms/pkmn.gb > debug_step_0297_extended.log 2>&1

Comandos de análisis sugeridos (PowerShell):

# Buscar accesos con datos después de 12 segundos
Select-String -Path "debug_step_0297_extended.log" -Pattern "\[TIMELINE-VRAM\].*T\+~1[2-9]|T\+~[2-9][0-9]|T\+~[0-9][0-9][0-9].*DATA" | Select-Object -First 50

# Buscar cambios de estado
Select-String -Path "debug_step_0297_extended.log" -Pattern "\[STATE-CHANGE\]" | Select-Object -First 50

# Buscar transiciones de pantalla
Select-String -Path "debug_step_0297_extended.log" -Pattern "\[SCREEN-TRANSITION\]" | Select-Object -First 20

# Ver dump inicial de VRAM
Select-String -Path "debug_step_0297_extended.log" -Pattern "\[VRAM-INIT-DUMP\]" | Select-Object -First 100

Fuentes Consultadas

• Pan Docs: Video RAM (VRAM)
• Pan Docs: Scroll Registers (SCX/SCY)
• Pan Docs: Tile Data
• Pan Docs: CPU Instruction Set

Integridad Educativa

Próximos Pasos

• [ ] Ejecutar análisis extendido (30-60 segundos) con Pokémon Red
• [ ] Analizar logs para identificar accesos con datos después de 12 segundos
• [ ] Verificar si se detectan cambios de estado que indiquen transiciones
• [ ] Verificar si hay datos pre-cargados en VRAM (dump inicial)
• [ ] Analizar timeline de accesos VRAM para identificar patrones temporales
• [ ] Determinar si el juego carga tiles más tarde o si necesita intervención del emulador
• [ ] (Opcional) Crear script para analizar datos de tiles en ROM