⚠️ Clean-Room / Educativo

Este proyecto es educativo y Open Source. No se copia código de otros emuladores. Implementación basada únicamente en documentación técnica y tests permitidas.

Hard Reset: Forzando la Realidad

Fecha: 2025-12-22 Step ID: 0232 Estado: Draft

Resumen

El análisis de logs demostró que el fix del Opcode 0x08 (Step 0231) no se aplicó en el binario ejecutado: el PC solo avanzaba 1 byte en lugar de 3, indicando que el código nuevo no se estaba ejecutando. Esto sugiere un problema de persistencia de DLLs antiguas en Windows. Procedemos a una limpieza agresiva de los artefactos de compilación y añadimos un log de confirmación ("marcador radiactivo") dentro del opcode para verificar su ejecución.

Concepto de Hardware

Este paso no trata sobre hardware del Game Boy, sino sobre el proceso de compilación y enlace dinámico en Windows.

El Problema de las DLLs Bloqueadas:

En Windows, cuando Python carga una extensión compilada (archivo .pyd, que es una DLL con extensión diferente), el sistema operativo bloquea el archivo en memoria mientras el proceso Python esté activo. Si intentas recompilar mientras Python tiene el módulo cargado:

  • El compilador puede fallar silenciosamente al sobrescribir el archivo.
  • O puede escribir en una ubicación diferente, dejando el binario antiguo activo.
  • O puede generar un error de "acceso denegado" que se ignora si no se verifica.

El Marcador Radiactivo:

Para confirmar que el código nuevo se está ejecutando, añadimos un printf muy visible dentro del opcode. Si este mensaje aparece en la consola, sabemos con certeza que el código C++ nuevo está activo. Si no aparece, el binario antiguo sigue ejecutándose.

Implementación

Añadimos un log de confirmación dentro del case 0x08 para verificar que el código se ejecuta.

Modificación en CPU.cpp

Añadimos un printf al inicio del case 0x08:

case 0x08:  // LD (nn), SP
    {
        // --- Step 0232: DEBUG DE VIDA ---
        printf("!!! EJECUTANDO OPCODE 0x08 EN C++ !!!\n");
        // --------------------------------
        
        uint16_t addr = fetch_word();
        mmu_->write(addr, regs_->sp & 0xFF);
        mmu_->write(addr + 1, (regs_->sp >> 8) & 0xFF);
        cycles_ += 5;
        return 5;
    }

Limpieza Manual de Binarios

Proceso crítico antes de recompilar:

  1. Cerrar todas las ventanas de Python/Viboy para liberar los archivos bloqueados.
  2. Eliminar la carpeta build/ que contiene artefactos de compilación antiguos.
  3. Eliminar cualquier archivo .pyd en la raíz o en src/.

Comandos en PowerShell:

# Cerrar procesos Python primero
Get-Process python | Stop-Process -Force

# Eliminar carpeta build
Remove-Item -Recurse -Force build

# Eliminar archivos .pyd
Get-ChildItem -Recurse -Filter *.pyd | Remove-Item -Force

Archivos Afectados

  • src/core/cpp/CPU.cpp - Añadido printf de debug en case 0x08

Tests y Verificación

Para validar que el código nuevo se está ejecutando:

  1. Cerrar todas las ventanas de Python/Viboy
  2. Limpiar binarios: Eliminar carpeta build/ y archivos .pyd
  3. Recompilar: .\rebuild_cpp.ps1 (debería tardar más al reconstruir desde cero)
  4. Ejecutar: python main.py roms/tetris.gb
  5. Verificar: Buscar el mensaje !!! EJECUTANDO OPCODE 0x08 EN C++ !!! en la consola

Resultado Esperado:

  • Si ves el mensaje !!! EJECUTANDO OPCODE 0x08 EN C++ !!!, el código nuevo está activo.
  • El "Francotirador" debería mostrar que el PC salta correctamente de 2B17 a 2B1A (3 bytes de avance).
  • Si no ves el mensaje, el binario antiguo sigue activo y necesitas repetir la limpieza.

Validación de módulo compilado C++: El printf se ejecuta directamente en el núcleo C++, confirmando que el código compilado es el correcto.

Fuentes Consultadas

  • Documentación de Python sobre extensiones C/C++: Building C and C++ Extensions
  • Conocimiento general sobre bloqueo de archivos DLL en Windows y problemas de compilación de extensiones Python.

Integridad Educativa

Lo que Entiendo Ahora

  • Bloqueo de DLLs en Windows: Los archivos .pyd (DLLs de Python) se bloquean en memoria mientras el proceso Python está activo, impidiendo su sobrescritura.
  • Marcadores Radiactivos: Añadir logs muy visibles dentro del código crítico permite confirmar que el binario nuevo se está ejecutando.
  • Limpieza Agresiva: Eliminar manualmente los artefactos de compilación fuerza una reconstrucción completa desde cero.

Lo que Falta Confirmar

  • Confirmación Visual: Verificar que el mensaje de debug aparece en la consola.
  • Corrección del Desalineamiento: Verificar que el PC ahora avanza correctamente (3 bytes en lugar de 1).

Hipótesis y Suposiciones

Hipótesis Principal: El binario antiguo estaba bloqueado en memoria y no se actualizó durante la recompilación. Con la limpieza manual y el marcador radiactivo, podremos confirmar que el código nuevo se ejecuta y que el fix del opcode 0x08 funciona correctamente.

Próximos Pasos

  • [ ] Ejecutar la limpieza manual de binarios
  • [ ] Recompilar desde cero
  • [ ] Verificar que el mensaje de debug aparece en la consola
  • [ ] Confirmar que el PC avanza correctamente (3 bytes) después del opcode 0x08
  • [ ] Si el fix funciona, remover el printf de debug para limpiar el código