Verificación Step 0291 - Análisis de Monitores

Resumen

Ejecución del plan de verificación del Step 0291 para analizar los monitores de diagnóstico implementados. Se ejecutó el emulador con Pokémon Red durante 15 segundos y se capturaron los logs de los cinco monitores: [VRAM-INIT], [TILE-LOAD-EXTENDED], [CLEANUP-TRACE], [BLOCK-WRITE], y el contador de frames en PPU. El análisis revela que el juego nunca carga datos de tiles reales en VRAM, solo se detectan escrituras de limpieza (0x00) desde la rutina en PC:0x36E3. Ninguna de las hipótesis iniciales es correcta, lo que indica que el problema es más fundamental.

Concepto de Hardware

En el hardware real del Game Boy, la VRAM (Video RAM) contiene valores aleatorios al encender el sistema. Los juegos típicamente limpian VRAM antes de cargar sus propios datos de tiles. La carga de tiles puede ocurrir:

• Durante la inicialización: Antes del primer frame visible (durante V-Blank o con LCD apagado)
• Durante V-Blank: Cuando VRAM es accesible (entre frames)
• En bloque: Usando loops de copia que escriben tiles consecutivos

Los tiles se cargan escribiendo datos de 2 bits por píxel (formato 2bpp) en el rango 0x8000-0x97FF. Cada tile ocupa 16 bytes (8 filas × 2 bytes por fila). El tilemap (0x9800-0x9FFF) contiene índices de tiles que referencian estos datos.

Fuente: Pan Docs - "Video RAM (VRAM)", "Tile Data", "Tile Map"

Metodología de Verificación

Se siguió el plan de verificación del Step 0291 para ejecutar el emulador y analizar los logs de forma controlada, evitando saturar el contexto con archivos grandes.

Compilación

• ✅ Código compilado sin errores (solo warnings menores de Cython)
• ✅ Módulo Cython generado correctamente

Ejecución

• ROM: roms/pkmn.gb (Pokémon Red)
• Duración: 15 segundos
• Log capturado: debug_step_0291.log (~100MB)
• Tamaño: 100,139,008 bytes

Análisis Controlado

Se utilizaron comandos PowerShell con límites para evitar saturar el contexto:

• Select-String con -First N para limitar resultados
• Measure-Object para estadísticas
• Análisis por muestras, no archivo completo

Resultados del Análisis

1. [VRAM-INIT] - Estado Inicial de VRAM

Resultados:

[VRAM-INIT] Estado inicial de VRAM: 0 bytes no-cero (0x8000-0x97FF)
[VRAM-INIT] VRAM está completamente vacía (solo ceros)
[VRAM-INIT] Checksum del tilemap (0x9800): 0x0000

Conclusión: ✅ Estado inicial correcto. VRAM está vacía al inicio, como se espera.

2. [TILE-LOAD-EXTENDED] - Timing y Carga de Tiles

Resultados:

• Total de escrituras capturadas: 1000 (límite del monitor)
• Escrituras con DATA: 0
• Escrituras con CLEAR: 1000 (100%)
• Durante Init:YES: 100 escrituras
• Durante Init:NO: 900 escrituras
• PC de origen: Todas desde PC:0x36E3

Ejemplos:

[TILE-LOAD-EXT] CLEAR | Write 8000=00 (TileID~0) PC:36E3 Frame:6 Init:YES
[TILE-LOAD-EXT] CLEAR | Write 8001=00 (TileID~0) PC:36E3 Frame:6 Init:YES
[TILE-LOAD-EXT] CLEAR | Write 8064=00 (TileID~6) PC:36E3 Frame:6 Init:NO

Conclusión: ❌ CRÍTICO: El juego nunca carga tiles reales. Solo limpia VRAM escribiendo 0x00.

3. [CLEANUP-TRACE] - Rutina de Limpieza VRAM

Resultados:

• Total de trazas: 200 (límite del monitor)
• PC principal: 0x36E3
• Opcodes detectados:
  • 0x22 (LD (HL+), A) - Escritura con incremento (mayoría)
  • 0x0B (DEC BC) - Decremento de contador
  • 0x20 (JR NZ) - Salto condicional (loop)
  • 0x7A (LD A, D) - Carga de registro
  • 0xD5 (PUSH DE) - Push a stack

Conclusión: ✅ La rutina de limpieza funciona correctamente. Es un loop que escribe 0x00 en VRAM. El problema es que no hay código que cargue tiles después.

4. [BLOCK-WRITE] - Cargas en Bloque

Resultados:

• Total de detecciones: 1
• Detección única: [BLOCK-WRITE] Posible carga de tile en bloque: 0x8001-0x8010 desde PC:0x36E3

Conclusión: ❌ El juego no usa carga de tiles en bloque. La única detección es parte de la rutina de limpieza.

Evaluación de Hipótesis

Hipótesis 1: Timing - Los tiles se cargan antes del frame 0

Estado: ❌ RECHAZADA

Evidencia: No hay escrituras de datos durante Init:YES ni en ningún momento. Todas las escrituras son de limpieza (0x00).

Hipótesis 2: Borrado - Los tiles se cargan pero luego se borran

Estado: ❌ RECHAZADA

Evidencia: No hay escrituras de datos (solo CLEAR). No hay secuencia DATA → CLEAR. Solo hay escrituras CLEAR desde el inicio.

Hipótesis 3: Métodos Alternativos - El juego usa métodos no detectados

Estado: ❌ RECHAZADA

Evidencia: [BLOCK-WRITE] solo detectó 1 carga (y es limpieza). No hay cargas en bloque de datos reales.

Hipótesis 4: Estado Inicial - VRAM debería tener datos desde el inicio

Estado: ❌ RECHAZADA

Evidencia: VRAM está vacía al inicio (correcto según hardware). El problema es que no se cargan tiles después de la limpieza.

Nueva Hipótesis: Problema Fundamental

Dado que ninguna de las hipótesis iniciales es correcta, el problema es más fundamental. Posibles causas:

• El juego no llega a la rutina de carga de tiles: Posible bug en la emulación que impide que el juego avance.
• El juego usa un método de carga que no estamos detectando: DMA o carga desde ROM directamente a VRAM.
• Problema de sincronización o timing: El juego espera un estado específico antes de cargar tiles.
• El juego espera que los tiles estén en la ROM: Algunos juegos usan tiles embebidos en la ROM.

Archivos Afectados

• test_step_0291_verification.py - Script de verificación que ejecuta el emulador con timeout
• debug_step_0291.log - Log completo de ejecución (~100MB)
• ANALISIS_STEP_0291_VERIFICACION.md - Documento de análisis completo

Tests y Verificación

La verificación se realizó ejecutando el emulador con Pokémon Red y analizando los logs de los monitores implementados en el Step 0291.

• Compilación: ✅ Código compilado sin errores
• Ejecución: ✅ Emulador ejecutado durante 15 segundos
• Logs capturados: ✅ 100MB de logs generados
• Análisis: ✅ Los cinco monitores generaron salida
• Validación: ✅ Análisis completo de cada monitor usando muestras controladas

Comando ejecutado: python test_step_0291_verification.py

Resultado: Logs capturados correctamente, análisis completo realizado.

Fuentes Consultadas

• Pan Docs: "Video RAM (VRAM)" - Estado inicial y estructura de VRAM
• Pan Docs: "Tile Data" - Formato de tiles (2bpp) y rango de direcciones
• Pan Docs: "Tile Map" - Estructura del tilemap y checksum

Integridad Educativa

Recomendaciones

1. Implementar monitor [PC-TRACE]: Rastrear el PC después de la rutina de limpieza para confirmar si el juego continúa ejecutando código.
2. Verificar otros puntos de entrada a VRAM: Asegurar que todas las escrituras en VRAM se detectan, incluso si pasan por otros métodos.
3. Analizar el código del juego: Desensamblar la ROM de Pokémon Red para encontrar la rutina de carga de tiles.
4. Implementar monitor [REG-TRACE]: Rastrear cambios en registros críticos (LCDC, STAT, etc.) para verificar condiciones de carga.
5. Comparar con emulador de referencia: Ejecutar Pokémon Red en un emulador de referencia para verificar comportamiento esperado (solo para verificación, no para copiar código).

Próximos Pasos

• [ ] Implementar monitor [PC-TRACE] para rastrear ejecución después de limpieza
• [ ] Verificar otros puntos de entrada a VRAM
• [ ] Analizar desensamblado del juego para entender cómo carga tiles
• [ ] Implementar monitor [REG-TRACE] para rastrear cambios en registros críticos
• [ ] Verificar comportamiento con emulador de referencia