⚠️ 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.

Operation Silence

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

Summary

After the "Hard Reset" (Step 0242), it was confirmed that the junk code is gone and we now see a legitimate memory scan loop (`INC HL`, `CP FD`). However, the debug instrumentation (`printf` per statement) is massively slowing down the emulator, making it impossible to know if the loop terminates naturally. All heavy instrumentation (Sniper and Radioactive Marker) is removed to allow execution at native speed (60 FPS) and use the GPS monitor (Step 0240) to verify progress.

Hardware Concept

Observer Effect: In quantum physics, the act of observing a system can alter its behavior. In emulation, something similar happens: debugging instrumentation (logs, `printf`, traces) consumes CPU time and can slow down the emulator up to 1,000 times, preventing the game from reaching its natural speed (60 FPS). This can cause loops that would normally finish in milliseconds to take minutes or even hours.

Performance in the Critical Loop: The emulation loop (`step()`) runs millions of times per second. Each `printf` or I/O call can consume microseconds or milliseconds, multiplying by millions of executions. A single `printf` per instruction can slow the emulator from 60 FPS to less than 1 FPS, making it impossible to determine if the game is running correctly or is simply slow due to instrumentation.

GPS Monitor as an Alternative: Instead of instrumenting each instruction, we can use an external monitor (GPS) that shows the status of the CPU periodically (for example, every second). This provides enough diagnostic information without slowing down execution, allowing the emulator to run at native speed.

Implementation

All heavy instrumentation blocks in `CPU.cpp` are removed to allow execution at native speed. The GPS monitor (Step 0240) provides enough information for diagnosis without slowing down execution.

Modified components

  • src/core/cpp/CPU.cpp: Removed Sniper block (Step 0241) and Radioactive Marker (Step 0242). Deleted#include <cstdio>.

Design decisions

Complete removal of instrumentation: All `printf` are removed from the critical loop, including Sniper (which logged every instruction in the range `0x2B20-0x2B30`) and Radioactive Marker (which logged every execution of opcode `0x08`). This allows the emulator to run at native speed (60 FPS) without interference.

GPS monitor as the only diagnostic source: The GPS monitor (implemented in Step 0240) periodically reports the status of the CPU (PC, SP, IME, IE, IF, LCDC, LY) without slowing down execution. This provides enough information to determine if the emulator is working correctly or if it is stuck in a loop.

Cleaning includes: `#include <cstdio>` is removed as no `printf` or standard I/O function is used in the code.

Code removed

// Removed: #include <cstdio>

// Removed: Sniper Block (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());
// }

// Removed: Radioactive Tracer (Step 0242)
// printf("!!! RUNNING OPCODE 0x08 IN C++ !!!\n");

Affected Files

  • src/core/cpp/CPU.cpp- Removed all debugging instrumentation (Sniper and Radioactive Tracer). Deleted#include <cstdio>.
  • docs/bitacora/entries/2025-12-22__0243__operacion-silencio.html- Log entry
  • docs/bitacora/index.html- Updated with new entry
  • REPORT_PHASE_2.md- Updated with Step 0243

Tests and Verification

The verification is carried out by running the emulator at native speed and observing the GPS monitor:

  • Command executed: python main.py roms/tetris.gb
  • GPS monitor: Observe the GPS logs (every second) to verify if the PC changes or remains fixed.
  • Expected validation:
    • If the PC changes drastically (leaves the `0x2Bxx` zone and goes to `0x02xx`, `0x2Cxx`, etc.):SUCCESS- We have passed initialization.
    • If the PC stays stuck at `0x2B24` for more than 5-10 seconds:Logical Infinite Loop- Memory never has `0xFD`.
  • Performance: The emulator should run at 60 FPS with no visible slowdowns.

Sources consulted

Note: This step is mainly about performance optimization and debugging instrumentation removal. It does not require consultation of specific hardware documentation.

Educational Integrity

What I Understand Now

  • Observer Effect in Emulation: Debug instrumentation can massively slow down the emulator, making it impossible to determine if the game is running correctly or is simply slow due to the instrumentation.
  • Performance in the Critical Loop: Each `printf` or I/O call in the emulation loop is multiplied by millions of executions, slowing down the emulator up to 1,000 times.
  • GPS Monitor as an Alternative: An external monitor that displays the CPU status periodically provides enough information for diagnosis without slowing down execution.

What remains to be confirmed

  • Scan loop behavior: Does the memory scan loop (`INC HL`, `CP FD`) terminate naturally or is it a logical infinite loop?
  • WRAM memory status: Is the WRAM memory initialized correctly or does it contain only zeros, causing the loop to never find the `0xFD` marker byte?

Hypotheses and Assumptions

Working Hypothesis: It is very likely that the WRAM memory is initialized to zeros (`0x00`) by our MMU. If the game looks for `0xFD` and doesn't find it, it will scan all the memory and then... what? Will it turn around? Will it crash? We need to let the emulator run at native speed to see if it passes this scan.

Next Steps

  • [ ] Recompile the C++ extension:.\rebuild_cpp.ps1
  • [ ] Run Tetris:python main.py roms/tetris.gb
  • [ ] Observe the GPS logs (every second) to verify if the PC changes or stays fixed
  • [ ] If the PC changes drastically:SUCCESS- We have passed initialization
  • [ ] If the PC stays stuck at `0x2B24` for more than 5-10 seconds: Investigate why the WRAM does not contain the `0xFD` marker byte