Análisis Selectivo de Logs

Resumen

Análisis selectivo de los logs de diagnóstico del emulador para identificar la causa raíz del problema de pantalla verde/blanca en Pokémon Red. Se analizaron los monitores activos ([VRAM-VIBE], [VRAM-TOTAL], [DMA-TRIGGER], [BGP-CHANGE], [HANDLER-EXEC], [VBLANK-TRACE]) y se identificaron dos problemas críticos: VRAM está siendo escrita solo con ceros (0x00) y BGP se pone temporalmente a 0x00 durante la ejecución.

Concepto de Hardware

VRAM (Video RAM) y Carga de Gráficos: VRAM (0x8000-0x9FFF, 8KB) es la memoria de video de la Game Boy. Contiene dos áreas principales: Tile Data (0x8000-0x97FF, 384 tiles de 16 bytes cada uno) y Tile Maps (0x9800-0x9FFF, 2 mapas de 32x32 tiles). Para que la pantalla muestre gráficos, el juego debe cargar datos de tiles en la sección Tile Data y luego configurar el Tile Map para referenciar esos tiles. Si VRAM está vacía (solo ceros), el PPU leerá tiles vacíos y renderizará una pantalla en blanco o con un solo color.

BGP (Background Palette) y Mapeo de Colores: BGP (0xFF47) es un registro de 8 bits que mapea índices de color (0-3) a otros índices (0-3). Cada par de bits representa un mapeo: bits 0-1 para índice 0, bits 2-3 para índice 1, etc. Si BGP = 0x00 (00000000), todos los índices se mapean a color 0 (blanco/verde), lo que causa una pantalla monocromática. El valor estándar es 0xE4 (11100100), que es un mapeo identidad.

DMA (Direct Memory Access) y OAM: OAM (Object Attribute Memory, 0xFE00-0xFE9F) contiene los atributos de los sprites (posición, tile ID, paleta, etc.). El juego puede copiar datos a OAM usando DMA, que transfiere 160 bytes desde una dirección fuente a OAM en 160 ciclos. Si los sprites no se renderizan, puede ser porque OAM está vacío o porque los tiles referenciados no existen en VRAM.

Fuente: Pan Docs - "Video RAM (VRAM)", "LCD Control Register (LCDC)", "Background Palette (BGP)", "OAM DMA"

Implementación

Se realizó un análisis selectivo de los logs de diagnóstico usando grep/Select-String para buscar patrones clave en el archivo `informe3_actualizado.md` (más de 200MB). Se analizaron los siguientes monitores:

Monitores Analizados

• [VRAM-VIBE]: Escrituras en VRAM con valores != 0x00 y != 0x7F (datos de gráficos reales)
• [VRAM-TOTAL]: Todas las escrituras en VRAM sin filtros (hasta 500 eventos)
• [DMA-TRIGGER]: Activación de OAM DMA
• [BGP-CHANGE]: Cambios en el registro de paleta de fondo
• [HANDLER-EXEC]: Ejecución del handler de V-Blank (hasta 500 instrucciones)
• [VBLANK-TRACE]: Rastreo del vector de V-Blank (0x0040)

Hallazgos Críticos

1. VRAM Solo Recibe Ceros

Resultado: 500 escrituras detectadas, todas con valor 0x00.

Todas las escrituras provienen del mismo PC: 0x36E3 (Bank:1) y ocurren en el rango 0x8000-0x8030 (Tile Data Area). Esto sugiere que el juego está limpiando/borrando VRAM en lugar de cargar gráficos.

Ejemplo de log:

[VRAM-TOTAL] Write 8000=00 PC:36E3 (Bank:1)
[VRAM-TOTAL] Write 8001=00 PC:36E3 (Bank:1)
[VRAM-TOTAL] Write 8002=00 PC:36E3 (Bank:1)
...

2. BGP Temporalmente a 0x00

Resultado: 3 cambios detectados, uno problemático.

BGP cambia de 0xE4 a 0x00 en PC:0x1F6A y se restaura a 0xE4 en PC:0x1F85. Si esto ocurre durante el renderizado, causará pantalla verde/blanca porque todos los colores se mapean a índice 0.

Secuencia de cambios:

[BGP-CHANGE] 0xFC -> 0xE4 en PC:0x0000 (Bank:1)  // Inicialización
[BGP-CHANGE] 0xE4 -> 0x00 en PC:0x1F6A (Bank:1)  // PROBLEMA
[BGP-CHANGE] 0x00 -> 0xE4 en PC:0x1F85 (Bank:1)  // Restauración

3. Aspectos Positivos

• DMA: 49 activaciones detectadas, funcionando correctamente
• Handler de V-Blank: 49 ejecuciones detectadas, funcionando correctamente
• LCDC: Valor constante 0xE3, configuración correcta
• V-Blank Trace: 49 rastreos detectados, funcionando correctamente

Problema Raíz Identificado

El problema principal es que VRAM está vacía (solo ceros). Cuando el PPU renderiza, lee tiles vacíos y aplica la paleta, resultando en pantalla verde/blanca. El problema secundario es que BGP se pone temporalmente a 0x00, lo que agrava el problema.

Archivos Afectados

• ANALISIS_LOGS_STEP_0288.md - Análisis ejecutivo con hallazgos detallados
• informe3_actualizado.md - Archivo de logs analizado (más de 200MB)

Tests y Verificación

El análisis se realizó mediante búsqueda de patrones en los logs usando herramientas de línea de comandos:

• Comando ejecutado: grep -i "\[VRAM-VIBE\]" informe3_actualizado.md
• Resultado: 0 matches (crítico: no hay escrituras de datos de gráficos reales)

• Comando ejecutado: Select-String -Path "informe3_actualizado.md" -Pattern "\[VRAM-TOTAL\]" | Measure-Object
• Resultado: 500 escrituras detectadas, todas con valor 0x00

• Comando ejecutado: grep -i "\[BGP-CHANGE\]" informe3_actualizado.md
• Resultado: 3 cambios detectados, uno problemático (0xE4 -> 0x00)

Validación: Los monitores de diagnóstico implementados en pasos anteriores (0285-0287) funcionan correctamente y proporcionan información valiosa para el diagnóstico.

Fuentes Consultadas

• Pan Docs: Video RAM (VRAM)
• Pan Docs: LCD Control Register (LCDC)
• Pan Docs: Background Palette (BGP)
• Pan Docs: OAM DMA

Integridad Educativa

Próximos Pasos

• [ ] Step 0289: Implementar monitor de lectura de VRAM ([VRAM-READ]) para capturar qué direcciones lee la PPU
• [ ] Step 0289: Implementar inspector de Tilemap ([TILEMAP-INSPECT]) para verificar qué tile IDs se están usando
• [ ] Step 0289: Implementar inspector de Tile Data ([TILEDATA-INSPECT]) para verificar si los tiles contienen datos != 0x00
• [ ] Step 0290: Implementar monitor de cambios en LCDC ([LCDC-CHANGE]) para verificar la configuración del LCD
• [ ] Step 0290: Implementar monitor de aplicación de paleta ([PALETTE-APPLY]) para verificar cómo se aplica BGP durante el renderizado
• [ ] Step 0291: Aplicar correcciones basadas en los hallazgos de los pasos anteriores