Fix debugger

[joajfreitas]

ToDo:

• print from memory location: pu8, pu16, pi8, pi16
• print register
• next
• help
• watchpoints
• list

Implemented:

• Reintroduce debug events

[joajfreitas]

@pineman I'm am once again trying to understand why the debugger cannot be a wrapper around the cpu. We've moved the debugger inside the cpu but that means that we have to "push" all the information to the debugger now.

When the functionality of the debugger is small this not an issue, since not that much information is needed. But when we actually want good print functionality then things get a bit harder.

[joajfreitas]

I also don't understand why actually pausing the cpu is implemented in fpt-egui. To me it would obviously be either the responsibility of Gameboy or LR35902 and PPU.

[pineman]

my question is just why can't "the debugger" just be a bunch of methods of the cpu/gameboy or on the cpu/gameboy. seems much easier? and we can worry about boundaries later when we actually know what we've built.

but I'm fine with whatever as long as it works and the client can still have a decent api. it needs to be able to run individual cycles, at least. It could be argued though that running individual instructions could be good enough (timing-wise) as long as the ppu can be kept in sync

[pineman]

on pausing, what do you mean? the client needs to, at least, be able to toggle pausing itself and check if the gb is paused or not. what changes exactly do you suggest?

[pineman]

I had also implemented watchpoints, did that get deleted as well? I believe it was just a trigger on set_mem8

two more features that would be great to have:

• step over
• continue until current loop is done

[joajfreitas]

my question is just why can't "the debugger" just be a bunch of methods of the cpu/gameboy or on the cpu/gameboy. seems much easier? and we can worry about boundaries later when we actually know what we've built.

but I'm fine with whatever as long as it works and the client can still have a decent api. it needs to be able to run individual cycles, at least. It could be argued though that running individual instructions could be good enough (timing-wise) as long as the ppu can be kept in sync

To me at least, when a single component becomes very large, it also becomes impossible for me to understand. Sometimes its harder when the "communication" between components is also very complex, however in general smaller components are easier to "grok"

[joajfreitas]

on pausing, what do you mean? the client needs to, at least, be able to toggle pausing itself and check if the gb is paused or not. what changes exactly do you suggest?

I agree the functionality itself makes a lot of sense. However, it is still surprising to me that the pausing of the gameboy is directly implemented in the fpt egui. To me it would make sense that the gameboy would offer the capability, but implement it internally.

This was so surprising that I spent around 1 hour until I thought of going to look inside fpt-egui for the pause functionality.