Applewin debugger breakpoint

[Andrew Roughan]

I have set BPX $4938 and debugger is entered when this address is reached.
I have some patch code loaded in memory at $8e00 and so I execute that with
8e00g
The patch code overwrites content of 4938 and several more locations and
finally JMPs to 4938.

I would expect the debugger to be re-entered at this second execution of
4938.
But it is not. It merrily continues.
I even set another BPX at 493A but that does not stop it either.
My patch is executed fully and the code at 4938 has also executed.

What’s going on?

Thanks
Andrew

[Michael AppleWin Debugger Dev]

On Wednesday, July 21, 2021 at 11:12:09 AM UTC-7, Andrew Roughan wrote:
> I have set BPX $4938 and debugger is entered when this address is reached.
> I have some patch code loaded in memory at $8e00 and so I execute that with
> 8e00g
> The patch code overwrites content of 4938 and several more locations and

The debugger G command behaves differently then what you are are expecting. It comes in 2 forms:

* ####G does NOT enable breakpoints.
* You must use G <addr> if you want it to stop at that address

i.e. It runs until THAT address is triggered. It ignores other breakpoints.

If you type HELP G or HELP GG the debugger will print off these instructions:

G, Run at normal speed [until PC == address]
G, Run at full speed [until PC == address]

Here is a small demo:

<F7>
BPC
00:60
300:A9 C1 8D 00 04 60
310:4C 00 00
BPX 0
BPX 300
BPX 305
<F7>
CALL 768

The first BP @ $300 is hit as expected.

If use G to continue the second BP @ $305 will be triggered.

Finally, one more G to exit.

If you then re-trigger the original breakpoint via ...

CALL 768

... but this time we use 300G the 2nd BP @ $305 will NOT be triggered. You must re-enter the debugger to re-enable breakpoints.

Thus for your code, when your BP @ $4938 is hit and you want to execute the code at $8E00 and re-hit the BP at $4938 you must use change the PC first and THEN use G.

R PC 8E00
G

Then the breakpoint of $4938 will be hit again.

Also, if you want your breakpoints to be hit, normally it is better to use <F7> to exit the debugger then to use G.

Lastly, you'll probably want to examine the source code for the CmdGo()

https://github.com/AppleWin/AppleWin/blob/de7f35e6bd91e2ebe38edb0342ee05a6a99cce45/source/Debugger/Debug.cpp#L1859

Hope this helps.

[Michael AppleWin Debugger Dev]

P.S.

The code for the first form, ####G, is here:

https://github.com/AppleWin/AppleWin/blob/de7f35e6bd91e2ebe38edb0342ee05a6a99cce45/source/Debugger/Debug.cpp#L7435

It doesn't trigger on breakpoints.

[fadden]

On Wednesday, July 21, 2021 at 11:12:09 AM UTC-7, Andrew Roughan wrote:

> I would expect the debugger to be re-entered at this second execution of
> 4938.
> But it is not. It merrily continues.
> I even set another BPX at 493A but that does not stop it either.

Wacky... I did exactly the same thing yesterday afternoon. I wrote it off as one of life's little mysteries and just stomped a JMP instruction into other code that I knew would be executed.

In the past, when things have gotten jammed up, I've used "E000G" from the debugger to get back to a BASIC prompt. It worked, so I assumed it just did the equivalent of "R PC xxxx ; G".

Here's a fun one (might only work in v1.29.7.0) after booting a DOS 3.3 disk in "enhanced //e" mode:
]CALL -151
<F7>
E000G
PR#6
...and enjoy the show! (video: https://youtu.be/VMJ_qpNGgvg?t=8)

Here's one I still haven't dug into: https://youtu.be/efTsPxFFt0Y

[Michael AppleWin Debugger Dev]

On Thursday, July 22, 2021 at 8:22:55 AM UTC-7, fadden wrote:
Here's a fun one (might only work in v1.29.7.0) after booting a DOS 3.3 disk in "enhanced //e" mode:
> ]CALL -151
> <F7>
> E000G
> PR#6
> ...and enjoy the show! (video: https://youtu.be/VMJ_qpNGgvg?t=8)

Hmm, that even works in v1.29.16.0 and booting ProDOS 2.4.1 as well. Going to have to try that on real hardware ...

> Here's one I still haven't dug into: https://youtu.be/efTsPxFFt0Y

That one is even stranger!? I left a comment on the YT video but if you could post a small repro. so we can test it out on real hardware that would be much appreciated. Thanks.

m.

[fadden]

On Thursday, July 22, 2021 at 2:12:28 PM UTC-7, Michael AppleWin Debugger Dev wrote:
> > Here's one I still haven't dug into: https://youtu.be/efTsPxFFt0Y
> That one is even stranger!? I left a comment on the YT video but if you could post a small repro. so we can test it out on real hardware that would be much appreciated. Thanks.

I found that one while working on the Phantoms Five disassembly. I haven't investigated it at all; just thought "huh, that's weird" and forgot about it until today. You can get a disk image with the files here: https://6502disassembly.com/a2-phantoms-five/p5-disk.zip

[peter....@gmail.com]

The first one is because the enhanced IIe uses banked $Cxxx space for keyboard support, and it's sometimes still active when you PR#6.
I think that real hardware does it, too.

[peter....@gmail.com]

[peter....@gmail.com]

The second one is because the file loads to $400+, overwriting screen holes that the ROM is using for cursor position and aux state.