How do you set a breakpoint?

[BruceRMcF]

How do you set a breakpoint, in either the monitor or the debugger?

IN the VICE monitor, I go "break 33" and it sets a breakpoint at location $0033, then I go "g 810" to start the ML hard start that the Basic stub does a SYS to, and then I start seeing where my Forth inner interpreter is in the compiled code it is interpreting.

The monitor instructions seem to assume you are used to the Final Cartridge III, and the debugger instructions seem to assume you are used to some Microsoft debugging tool, which seem a bit narrow assumptions of background experience

I tried to set that break point with the -debug command line switch, loaded and ran XFORTH.PRG ... and saw the two lines printing from COLD (which is fine, that's farther than I could get the xscpu64 emulator on VICE to do, since I evidently don't have the correct ROM to do something so primitive as printing to the screen) ... and I know full well that that is well into the compiled CODE word and since it shows up, shows that the compiled TYPE word executed, but no break point. I saw something about using F9 in the debugger, but after setting the memory display to start at $33 and hitting F9, nothing.

I saw something about using the STP command and it will go into the debugger. I put that in as a "!BYTE $DB" (though in the NEXT routine that called the JMP (..) instruction in the zero page), loaded, ran, nothing.

I tried a BRK instruction in the NEXT routine. Loaded, ran, nothing.

So how do you insert breakpoints that bring up either the monitor or the debugger?

[TomXP411]

If you're going to use the STP instruction to break into the debugger on the emulator, you need to use the -debug command line switch to enable debugging.

The emulator's documentation explains this, along with how to use the debugging screen.

https://github.com/X16Community/x16-emulator

[BruceRMcF]

"explains this" might be a bit generous ... "indicates" or "suggests" perhaps.

I reckon that the -debug flag is working, since it says that is needed to bring up the displays with F12, and going to the code with the d command, it shows "dbg" where I placed the STP code. It just doesn't stop.

So if STP doesn't work, how are breakpoints set inside the debugger?

The "explanation" says F9:
"sets the breakpoint to the currently code position"

Nowhere does it say how to tell what the currently code position is from the display. I don't see anywhere that it says how to see what breakpoint(s) have been set.

Or if all of that is supposed to be reserved to people who have used this style of debugger/monitor before, how are breakpoints set for the in-system monitor? If set-up code is required to have the Monitor come up when the code hits a BRK, I would be happy to include that in the set-up to the Forth system.

[Stefan]

I've been using the STP command as long as I can remember. It has always worked for me with the official emulator.

The simplest test I can come up with is this:

• Start the emulator with the -debug switch

• Type POKE $1000,$DB

• Type SYS $1000

As soon as code execution encounters a STP instruction ($DB), the emulator opens the debugger on the right side of the window. Does this not happen on your computer?

[JimmyDansbo]

I don't remember how I learned to use the emulators debugger. Most of it comes from the "documentation" of the emulator, but I seem to recall that I was also looking at the source code of the emulator to figure out how to use the debugger.

debugger.jpg (463.31 KiB) Viewed 1106 times

The program counter is usually the same in both places I have marked with red in above picture, but if you are in the debugger and write:
d xxxx
where xxxx is an address, you can change the codeview to start from that address. After that you can press F9 and get the breakpoint (marked with blue) set.

In your source, you should be able to just add the stp opcode, if your assembler supports it, otherwise .byte $db as you have mentioned your self. If the emulator is started with the -debug option, it will automatically enter the debugger on the code just after the stp ($db) opcode has been read.

[BruceRMcF]

I've been using the STP command as long as I can remember. It has always worked for me with the official emulator.

The simplest test I can come up with is this:

• Start the emulator with the -debug switch

• Type POKE $1000,$DB

• Type SYS $1000

As soon as code execution encounters a STP instruction ($DB), the emulator opens the debugger on the right side of the window. Does this not happen on your computer?

That works.

I loaded XFORTH.PRG. I've got the disassembly starting at $854 which is the !byte $DB location in the NEXT routine. It says "dbg". I've got the memory display starting at $854, it shows $DB.

I just ran XFORTH.PRG. The opening message from COLD displays. It has to have passed by $854 multiple times to get that far ... COLD is:

Code: Select all

L_COLD:		!WORD L_DOTS
		!BYTE 4
		!TEXT "COLD"
COLD:		JSR ENTER
	!WORD UINIT,U0,NINIT,CMOVE

; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;	!WORD LIT,$80,COUNT,INTERPRET
; This was the CP/M command line
; Passing a string to be interpreted
; is not yet supported
;
	!WORD XSQUOTE
	!BYTE 51
	!TEXT "XFORTH02, 2 JUN 2025"
	!BYTE $0d	; CX16 return
	!TEXT "BASED ON Z80 CAMELFORTH V1.01"
	!BYTE $0d
	!WORD TYPE
	!WORD ABORT       ; ABORT never returns

And TYPE is:

Code: Select all

L_TYPE:		!WORD L_UMAX
		!BYTE 4
		!TEXT "TYPE"
TYPE:		JSR ENTER
	!WORD QDUP,QBRANCH,TYP4
	!WORD OVER,PLUS,SWAP,xdo
TYP3:	!WORD II,CFETCH,EMIT,xloop,TYP3
	!WORD BRANCH,TYP5
TYP4:	!WORD DROP
TYP5:	!WORD EXIT

... so JMP NEXT would have been executed at least 12+3*51 times, or else I would not be seeing the welcome message on the X16 display.

[BruceRMcF]

I don't remember how I learned to use the emulators debugger. Most of it comes from the "documentation" of the emulator, but I seem to recall that I was also looking at the source code of the emulator to figure out how to use the debugger.
debugger.jpg
The program counter is usually the same in both places I have marked with red in above picture, but if you are in the debugger and write:
d xxxx
where xxxx is an address, you can change the codeview to start from that address. After that you can press F9 and get the breakpoint (marked with blue) set. ...

I've never seen anything in that breakpoint except "----". Using "d 33" and hitting F9 was the second thing I tried, to try to replicate "break 33" in the VICE monitor, after "x16emu.exe -debug 33" didn't work, nor 0033. Should it have been "-debug $33"?

[BruceRMcF]

While F9 still doesn't do anything, this time, "-debug 33" worked.

Is there interference between -debug and any of the other command line options? This time I set it without trying to auto-run the program ... I believe that I was likely doing other things on the command line the first time I tried it.

[BruceRMcF]

A few days later

Somehow now the BRK breakpoints are working to bring up the Monitor.

The Monitor is overall nicer to work with than the debugger, since I can execute commands to look at the zero page locations with the IP, W and V vectors, the high byte data stack, the low byte data stack and the hardware stack being used as the return stack, and just re-execute them at the next break point, rather than having to enter those four memory locations in sequence each time and remember what the others one showed rather than having them all on screen at once.

Plus my eyes don't ache from eyestrain using the Monitor, which is always a benefit.

The only thing is that as an inserted break-point based Monitor, the Monitor doesn't have the "z" function, so I still have to use eyestrain mode if it is necessary to single step through a Forth primitive (as opposed to a compiled Forth routine) ... but hopefully as bugs are fixed in primitives, more and more time will be spent single-stepping through compiled Forth code with "g".

I figure by having a break point set at the start of a target word, and NOP's in the correct position in NEXT and EXIT, the system can run up to the target word and then the NOPs replaced by BRKs to step through the compiled code.

[BruceRMcF]

I've confirmed that I was placing the breakpoints where they weren't going to be triggered -- I got clever saving a clock cycle in the more common case of not stepping over a page boundary, by branching out to the separate page boundary cross code, and put the break point in the page boundary cross code.

So I was confirming the existing of the $DB byte in a routine that was repeatedly called, but in a part of the routine that would only have been called once in executing compiled code that crossed a page boundary -- as neither COLD nor TYPE did.

It remains a puzzle that F9 does not set the breakpoint ... perhaps my F9 key is broken, and I've never noticed because I never use F9.