⚠️ Clean-Room / Educational

This project is educational and Open Source. No code is copied from other emulators. Implementation based solely on technical documentation and permitted tests.

Hard Reset: Forcing Reality

Date:2025-12-22 StepID:0232 State: draft

Summary

Log analysis showed that the Opcode 0x08 fix (Step 0231) was not applied in the executed binary: the PC only advanced 1 byte instead of 3, indicating that the new code was not being executed. This suggests a persistence problem for old DLLs in Windows. We proceed to a cleaning aggressive build artifacts and add a confirmation log ("radioactive marker") inside the opcode to verify its execution.

Hardware Concept

This step is not about Game Boy hardware, but about thebuild and link process dynamic in windows.

The Problem of Blocked DLLs:

On Windows, when Python loads a compiled extension (file.pyd, which is a DLL with a different extension), the operating system locks the file in memory while the process Python is active. If you try to recompile while Python has the module loaded:

  • The compiler may fail silently when overwriting the file.
  • Or you can write to a different location, leaving the old binary active.
  • Or it may generate an "access denied" error that is ignored if not checked.

The Radioactive Tracer:

To confirm that the new code is running, we add aprintfvery visible inside the opcode. If this message appears in the console, we know for sure that the C++ code new is active. If it doesn't appear, the old binary continues running.

Implementation

We add a confirmation log within thecase 0x08to verify that the code runs.

Modification in CPU.cpp

We add aprintfat the beginning ofcase 0x08:

case 0x08: // LD (nn), SP
    {
        // --- Step 0232: LIFE DEBUG ---
        printf("!!! RUNNING OPCODE 0x08 IN 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;
    }

Manual Binary Cleaning

Critical process before recompiling:

  1. Close all Python/Viboy windowsto release locked files.
  2. Delete the folderbuild/which contains old build artifacts.
  3. Delete any file.pydat the root or insrc/.

Commands in PowerShell:

# Close Python processes first
Get-Process python | Stop-Process-Force

# Delete build folder
Remove-Item -Recurse -Force build

# Delete .pyd files
Get-ChildItem -Recurse -Filter *.pyd | Remove-Item -Force

Affected Files

  • src/core/cpp/CPU.cpp- Added debug printf incase 0x08

Tests and Verification

To validate that the new code is running:

  1. Close all Python/Viboy windows
  2. Clean binaries:Delete folderbuild/and files.pyd
  3. Recompile: .\rebuild_cpp.ps1(should take longer when rebuilding from scratch)
  4. Execute: python main.py roms/tetris.gb
  5. Verify:Find the message!!! RUNNING OPCODE 0x08 IN C++!!!on the console

Expected Result:

  • If you see the message!!! RUNNING OPCODE 0x08 IN C++!!!, the new code is active.
  • "Sniper" should show that the PC jumps correctly from2B17to2B1A(3 bytes forward).
  • If you don't see the message, the old binary is still active and you need to repeat the cleanup.

Compiled C++ module validation:printf runs directly in the C++ core, confirming that the compiled code is correct.

Sources consulted

  • Python documentation on C/C++ extensions:Building C and C++ Extensions
  • General knowledge about DLL locking on Windows and Python extension compilation issues.

Educational Integrity

What I Understand Now

  • DLL blocking in Windows:.pyd files (Python DLLs) are locked in memory while the Python process is active, preventing them from being overwritten.
  • Radioactive Markers:Adding highly visible logs within critical code allows you to confirm that the new binary is running.
  • Aggressive Cleaning:Manually removing build artifacts forces a complete rebuild from scratch.

What remains to be confirmed

  • Visual Confirmation:Verify that the debug message appears in the console.
  • Misalignment Correction:Verify that the PC now advances correctly (3 bytes instead of 1).

Hypotheses and Assumptions

Main Hypothesis:The old binary was locked in memory and was not updated during the rebuild. With manual cleanup and the radioactive marker, we can confirm that the new code is executed and that the opcode 0x08 fix works correctly.

Next Steps

  • [ ] Run manual binary cleanup
  • [ ] Recompile from scratch
  • [ ] Verify that the debug message appears in the console
  • [ ] Confirm that the PC advances correctly (3 bytes) after opcode 0x08
  • [ ] If the fix works, remove the debug printf to clean up the code