Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#1 2023-12-27 20:46:28

itarato
New member
From: Canada
Registered: 2019-03-19
Posts: 3

Debugging technique for an emulator - CPU instruction test not stop

I'm writing an GameBoy DMG emulator. I was testing the base components (CPU / video / interrupts / memory) with the recommended CPU-instruction testing rom: https://github.com/retrio/gb-test-roms/ … pu_instrs. I was able to make all individual tests (https://github.com/retrio/gb-test-roms/ … individual) pass - which I assume because of the display presenting "passed" for all. However running the grouped version of the test (https://github.com/retrio/gb-test-roms/ … _instrs.gb) fails the following way: it presents "OK" for all tests, but it never stops. Normally it suppose to present 11 cases, but in my case it just keeps going to infinite: ...11: OK, 12: OK, 13: OK ...

Obviously I'm not asking to debug my code, but more about debugging techniques on how to catch this one.

Finding bugs with the individual tests was easy:
- run a reference emulator parallel (eg BGB) and compare PC / opcode, see where it differs and fix
- worst case lookup the assembly of the test (eg https://github.com/retrio/gb-test-roms/ … terrupts.s), find the opcode and break there and step-by-step evaluate

However for the merged test rom the difficulties are:
- no source assembly
- lot of code runs with PC in the WRAM which is real time (re)written by the execution

I'm re-reading the references several times but at this point I'm banging my head against the wall.

Wonder if someone could confirm if my assumptions are right:
- I assume I don't need 100% PPU implementation on the rendering part, but I do need the PPU timing, interrupts and IO registers working correctly
- I assume I don't need the following units for this test: joypad, sound, serial port

Some things I'm not sure:
- comparing my code with BGB the machine cycle counting seems to have a <1% diff - is that a big issue?
- I've noticed some unused bits are read differently. For example 0xFF07 TAC reads 0xF8 on empty state due to all unused bits giving a 1. But let's say the flag register keeps unused bits to 0. Not sure if I've found all that needs to be 1 for unused - and whether that's important.

In any case, I'd really appreciate some tips how could I debug this.

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson