Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II Emulation » Applewin debugger breakpoint
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Applewin debugger breakpoint [message #410160] Wed, 21 July 2021 14:12 Go to next message
Anonymous
Karma:
Originally posted by: 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
Re: Applewin debugger breakpoint [message #410162 is a reply to message #410160] Wed, 21 July 2021 17:01 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
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/de7f35e6bd91e2ebe3 8edb0342ee05a6a99cce45/source/Debugger/Debug.cpp#L1859

Hope this helps.
Re: Applewin debugger breakpoint [message #410163 is a reply to message #410162] Wed, 21 July 2021 17:05 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
P.S.

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

https://github.com/AppleWin/AppleWin/blob/de7f35e6bd91e2ebe3 8edb0342ee05a6a99cce45/source/Debugger/Debug.cpp#L7435

It doesn't trigger on breakpoints.
Re: Applewin debugger breakpoint [message #410181 is a reply to message #410160] Thu, 22 July 2021 11:22 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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
Re: Applewin debugger breakpoint [message #410196 is a reply to message #410181] Thu, 22 July 2021 17:12 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
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.
Re: Applewin debugger breakpoint [message #410197 is a reply to message #410196] Thu, 22 July 2021 17:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: 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
Re: Applewin debugger breakpoint [message #410201 is a reply to message #410197] Thu, 22 July 2021 19:12 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
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.
Re: Applewin debugger breakpoint [message #410202 is a reply to message #410197] Thu, 22 July 2021 19:13 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
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.
Re: Applewin debugger breakpoint [message #410203 is a reply to message #410201] Thu, 22 July 2021 19:14 Go to previous message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
The second one is because the file loads to $400+, overwriting screen holes that the ROM is using for cursor position and aux state.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: mb-audit: a Mockingboard test suite for emulators
Next Topic: Hiding columns in AppleWin debugger 1.27.0.0 and later.
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 07:35:20 EDT 2024

Total time taken to generate the page: 0.01946 seconds