r43 debugger doesn't stop at breakpoint

[Daedalus]

Down to me. When i wrote it, the emulator was in a very alpha state, so it is deliberately not deeply integrated into the emulation to minimise risk.

One of the issues is you have one source of keys (the PS/2 scan codes) but two targets - the emulator & debugger and the target application. What this means in practice is that debugging the keyboard stuff by "normal" means is difficult.

I love the debugger, it's an indispensable tool I couldn't live without... I find it mentally taxing to use in that there are pretty severe constraints that are applied by reality, like the inability to have "debug code" with symbolic information embedded in the application being debugged... but that's going to be hard to do in a system with a 64K memory constraint. One of the mental gymnastics I find hard is when I need to step past a macro to get to the code I want to debug on the other side, it has no way to know this is a macro... so I must recognize the end of the macro so I know I'm back in the code I want to debug.

And of course, if I blow it, and go too far, I have to start all over.

The one best thing that would make this process easier is if there were more memory monitors! I constantly need 2, and occasionally want a third one. So I have to write down the memory addresses I want to switch in and out...

But I'm just not that smart. It was already all I can to just jump from section of code to section of code in my code editor, juggling that and remembering what memory addresses I need to switch to means I screw up a lot and have to restart the whole process.

The one current memory monitor is far larger than I need, if I could break that into 3 of them prior to starting stepping through the code, I could be looking at the relevant local data, whatever global data that code needs, and whatever zero page data that code needs all at once. Then I could just focus on where the code is executing from.

[Ender]

So if works if you put the breakpoint in the command line, and it works if you add the breakpoint AFTER you run the program, but it fails if you set the breakpoint while still in the BASIC screen.

Hmm, that's very strange. It shouldn't matter whether you've loaded the program or not. When you set a breakpoint, you're simply telling the emulator, when the cpu executes at this address, pause. It doesn't matter what's actually there.. Could you upload the prg so I could try?

[Daedalus]

I tested the debug breakpoint in R43, and it worked when I started the emulator with x16emu -debug 1100, that is a breakpoint at $1100.

It also worked when I started the emulator with x16emu -debug 3a000, a breakpoint in bank 3, address $a000.

Looking at the emulator source code, it parses the number after -debug as follows:

• The number is interpreted as a HEX value
• If number is less than a000, the breakpoint is set to that address with no bank
• If the number is equal to or greater than a000, bits 0..15 are the breakpoint address and bits 16... are the breakpoint bank

Ender... I just noticed this as I was testing it to be sure it was still broken (It is.)
judging from this earlier post, the "extra digits" in the breakpoint are the BANK id to break at. Look at this screen shot: There's the breakpoint it's trying to break at... look at the memory dump. Is that right?
Edited to add: When I set the breakpoint from the makefile, or while the program was running, there were no leading 0's in the breakpoint, only the 4 digit address.

Break point bug.png (33.18 KiB) Viewed 3523 times

[Daedalus]

I also tried placing the breakpoint at the program's entry point, that didn't work. Then I put an RTS as the first instruction to execute... it didn't break, but exited immediately as expected.

What I was trying to test with that was the possibility that I was stomping on the bank setting.
I noticed the first 4 bytes of RAM were : 01 04 14 0f But when I set the breakpoint (While still in BASIC) they were 01 00 00 00.

To my knowledge, I've never touched addresses 00 or 01, but I use 02/03 all the time to do indirect indexed addressing.

[Ender]

Thanks for pointing this out, I think I've found the issue. The behavior is supposed to be that when you're in lower memory (i.e. < $A000), the bank doesn't matter, so internally it is set to -1, and the bank part is not displayed next to BRK. However, in your example it is shown that it considers the bank 0, so if the bank happened to not be 0 when it hit that address, it would not break, even though the bank shouldn't matter for lower memory. This was because I missed a few spots in the logic for where it sets the bank (there are many). I'm honestly not sure how I didn't catch this when I was testing... I know I tried several tests involving setting a breakpoint with F9 and then running a program. I guess I was just lucky (or unlucky) that the bank happened to match when it hit that address.

Anyways, I'm going to submit a PR with the fix soon.

[Ender]

Just FYI, the PR for this was accepted in the x16community emulator repo. You can grab a build of the newest change from the links at the bottom here https://github.com/X16Community/x16-emu ... 5121431340 (requires being logged in to github).