makestuff
commented
4 years ago There is a description of how the breakpoints work here: https://hackaday.io/project/1507-usb-megadrive-devkit.
If that doesn't answer your question, I doubt I can be of much help - I haven't touched the UMDK code for many years, and I can't remember the details. Luckily it's open-source though, so you can at least study the code.
One thing that does jog my memory: if you look at the 2nd video, I start the game running first, and then start the debugger. When the debugger starts, it interrupts the running game. It does this by temporarily replacing the first opcode of the VBlank routine with the opcode of the ILLEGAL instruction, after first redirecting the illegal instruction vector to point at the monitor program. See here for the relevant code. So at that point, the game will have already executed its memory-checksum. Notice that there's a similar bit of code in the handler for the gdb "continue" command: if you tell gdb to continue execution, only two things can stop it: (1) it hits an existing breakpoint (which are also implemented using temporary insertion of an ILLEGAL instruction at the breakpoint address), or (2) you hit
I'm working on a software solution that provides the same features as your hardware one. https://github.com/dashxdr/gen is the project. I added a gdb server but when I connect gdb to it and try to set a breakpoint gdb just does it by putting a trap #15 at the location. The problem is genesis games usually checksum the rom at the start so the modified instruction wrecks the checksum.
I want gdb to use hardware breakpoints, and I can implement that on my end, but gdb stubbornly uses only the trap #15 approach. How do you get gdb to use the elaborate breakpoint handlers you implemented? Your code doesn't even properly respond to the qSupported query...
Thanks for any suggestions!