Operación Silencio

Resumen

Tras el "Hard Reset" (Step 0242), se confirmó que el código basura ha desaparecido y ahora observamos un bucle de escaneo de memoria legítimo (`INC HL`, `CP FD`). Sin embargo, la instrumentación de depuración (`printf` por instrucción) está ralentizando masivamente el emulador, impidiendo saber si el bucle termina naturalmente. Se elimina toda la instrumentación pesada (Francotirador y Marcador Radiactivo) para permitir la ejecución a velocidad nativa (60 FPS) y usar el monitor GPS (Step 0240) para verificar el avance.

Concepto de Hardware

Efecto Observador (Observer Effect): En física cuántica, el acto de observar un sistema puede alterar su comportamiento. En emulación, algo similar ocurre: la instrumentación de depuración (logs, `printf`, trazas) consume tiempo de CPU y puede ralentizar el emulador hasta 1,000 veces, impidiendo que el juego alcance su velocidad natural (60 FPS). Esto puede hacer que bucles que normalmente terminarían en milisegundos tarden minutos o incluso horas.

Rendimiento en el Bucle Crítico: El bucle de emulación (`step()`) se ejecuta millones de veces por segundo. Cada `printf` o llamada a I/O puede consumir microsegundos o milisegundos, multiplicándose por millones de ejecuciones. Un solo `printf` por instrucción puede ralentizar el emulador de 60 FPS a menos de 1 FPS, haciendo imposible determinar si el juego está funcionando correctamente o simplemente está lento debido a la instrumentación.

Monitor GPS como Alternativa: En lugar de instrumentar cada instrucción, podemos usar un monitor externo (GPS) que muestre el estado de la CPU periódicamente (por ejemplo, cada segundo). Esto proporciona suficiente información para diagnóstico sin ralentizar la ejecución, permitiendo que el emulador corra a velocidad nativa.

Implementación

Se eliminan todos los bloques de instrumentación pesada en `CPU.cpp` para permitir la ejecución a velocidad nativa. El monitor GPS (Step 0240) proporciona suficiente información para diagnóstico sin ralentizar la ejecución.

Componentes modificados

• src/core/cpp/CPU.cpp: Eliminado bloque del Francotirador (Step 0241) y Marcador Radiactivo (Step 0242). Eliminado #include <cstdio>.

Decisiones de diseño

Eliminación completa de instrumentación: Se eliminan todos los `printf` del bucle crítico, incluyendo el Francotirador (que logueaba cada instrucción en el rango `0x2B20-0x2B30`) y el Marcador Radiactivo (que logueaba cada ejecución del opcode `0x08`). Esto permite que el emulador corra a velocidad nativa (60 FPS) sin interferencias.

Monitor GPS como única fuente de diagnóstico: El monitor GPS (implementado en Step 0240) reporta periódicamente el estado de la CPU (PC, SP, IME, IE, IF, LCDC, LY) sin ralentizar la ejecución. Esto proporciona suficiente información para determinar si el emulador está funcionando correctamente o si está atrapado en un bucle.

Limpieza de includes: Se elimina `#include <cstdio>` ya que no se usa ningún `printf` ni función de I/O estándar en el código.

Código eliminado

// Eliminado: #include <cstdio>

// Eliminado: Bloque del Francotirador (Step 0241)
// if (regs_->pc >= 0x2B20 && regs_->pc <= 0x2B30) {
//     uint8_t opcode = mmu_->read(regs_->pc);
//     printf("[SNIPER] PC:%04X | OP:%02X | A:%02X | HL:%04X\n", 
//            regs_->pc, opcode, regs_->a, regs_->get_hl());
// }

// Eliminado: Marcador Radiactivo (Step 0242)
// printf("!!! EJECUTANDO OPCODE 0x08 EN C++ !!!\n");

Archivos Afectados

• src/core/cpp/CPU.cpp - Eliminada toda la instrumentación de depuración (Francotirador y Marcador Radiactivo). Eliminado #include <cstdio>.
• docs/bitacora/entries/2025-12-22__0243__operacion-silencio.html - Entrada de bitácora
• docs/bitacora/index.html - Actualizado con nueva entrada
• INFORME_FASE_2.md - Actualizado con Step 0243

Tests y Verificación

La verificación se realiza mediante ejecución del emulador a velocidad nativa y observación del monitor GPS:

• Comando ejecutado: python main.py roms/tetris.gb
• Monitor GPS: Observar los logs del GPS (cada segundo) para verificar si el PC cambia o se queda fijo.
• Validación esperada:
  • Si el PC cambia drásticamente (sale de la zona `0x2Bxx` y va a `0x02xx`, `0x2Cxx`, etc.): ÉXITO - Hemos superado la inicialización.
  • Si el PC se queda fijo en `0x2B24` durante más de 5-10 segundos: Bucle Infinito Lógico - La memoria nunca tiene `0xFD`.
• Rendimiento: El emulador debe correr a 60 FPS sin ralentizaciones visibles.

Fuentes Consultadas

• Pan Docs: Game Boy Pan Docs - Referencia general de arquitectura LR35902

Nota: Este paso es principalmente sobre optimización de rendimiento y eliminación de instrumentación de depuración. No requiere consulta de documentación específica de hardware.

Integridad Educativa

Próximos Pasos

• [ ] Recompilar la extensión C++: .\rebuild_cpp.ps1
• [ ] Ejecutar Tetris: python main.py roms/tetris.gb
• [ ] Observar los logs del GPS (cada segundo) para verificar si el PC cambia o se queda fijo
• [ ] Si el PC cambia drásticamente: ÉXITO - Hemos superado la inicialización
• [ ] Si el PC se queda fijo en `0x2B24` durante más de 5-10 segundos: Investigar por qué la memoria WRAM no contiene el byte marcador `0xFD`