breakpoints in code (ca65, VICE)

[Dvorak]

Hello everyone,

edit; perhaps this should be in the programming section. I saw 'newbies' and I figured that it would be best here for some reason.

I've been delving into the realm of 6502 assembly recently, and my code has gotten so large that it's becoming rather difficult to debug. I have coded in x86 assembly and there is an instruction which acts as a breakpoint (int c3?) for debuggers upon execution.

Does anyone know an equivalent which works with VICE? Or perhaps a old school form of debugging? I would prefer to abstain from needle-and-haystack methods. I would use the BRK instruction but that brings you to the monitor, but I'm running on top of BASIC and I don't have any knowledge of software interrupts (yet. Maybe it's time?)

Thanks.

[BigDumbDinosaur]

Dvorak wrote:

Hello everyone,

edit; perhaps this should be in the programming section. I saw 'newbies' and I figured that it would be best here for some reason.

I've been delving into the realm of 6502 assembly recently, and my code has gotten so large that it's becoming rather difficult to debug. I have coded in x86 assembly and there is an instruction which acts as a breakpoint (int c3?) for debuggers upon execution.

Does anyone know an equivalent which works with VICE? Or perhaps a old school form of debugging? I would prefer to abstain from needle-and-haystack methods. I would use the BRK instruction but that brings you to the monitor, but I'm running on top of BASIC and I don't have any knowledge of software interrupts (yet. Maybe it's time?)

Thanks.

Firstly, welcome to our 6502 world.

BRK is the "traditional" means by which a running machine language program is interrupted for debugging purposes. On the NMOS MPUs and the 65C02, BRK is the only software interrupt available. It is customary for the BRK handler to go into a machine language monitor, which would dump the registers and await input.

Although almost all 6502 assemblers treat BRK as a one byte instruction, it actually is a two byter, as the 65xx family double-increments the program counter when BRK is executed. The byte following BRK is called the signature and can be any value.

Dunno if this information helps you.

[Dvorak]

Interesting that the BRK instruction increments PC by 2. I was wondering why PC was never at the BRK point itself! This will help me a decent amount. Would you happen to know why the BRK instruction increments PC?

It seems like BRK is half of what I want (convenience-wise), but it will do. I was wanting something which would pause the code, then allow me to step through it using VICE's monitor, but I'm becoming uncertain as to whether or not something like that actually exists. Thanks!

edit; found this on a 6502 instruction set sheet: "BRK causes a non-maskable interrupt and increments the program counter by one. Therefore an RTI will go to the address of the BRK +2 so that BRK may be used to replace a two-byte instruction for debugging and the subsequent RTI will be correct. " I take it this has something to do with the stack?

[BigDumbDinosaur]

Dvorak wrote:

Interesting that the BRK instruction increments PC by 2. I was wondering why PC was never at the BRK point itself! This will help me a decent amount. Would you happen to know why the BRK instruction increments PC?

The reason is mostly historical and had to due with BRK's dual use as a means of hooking in patches in PROMs in early systems and as a means of invoking operating system services, analogous to INT <int number> in x86 assembly language.

Quote:

It seems like BRK is half of what I want (convenience-wise), but it will do. I was wanting something which would pause the code, then allow me to step through it using VICE's monitor, but I'm becoming uncertain as to whether or not something like that actually exists. Thanks!

VICE, being software, cannot single-step a program. If you ever decide to try your hand at building a 6502 contraption you can incorporate the circuitry needed to single-step under hardware control.

Quote:

edit; found this on a 6502 instruction set sheet: "BRK causes a non-maskable interrupt and increments the program counter by one. Therefore an RTI will go to the address of the BRK +2 so that BRK may be used to replace a two-byte instruction for debugging and the subsequent RTI will be correct. " I take it this has something to do with the stack?

When BRK is executed, the 6502 will push the program counter (PC) and status register (SR) to the stack (located in the range $0100-$01FF) and then jump through the hardware vector at $FFFE-$FFFF. RTI will reverse the stack operations, reloading PC with the address that was pushed and restore the stack copy of SR as well. Since the execution of BRK double-increments PC, the return address is the address of the BRK instruction plus two.

Worthy of note is that the $FFFE-$FFFF vector is the same one taken when a hardware interrupt request (IRQ) occurs. The 6502 indicates the type of interrupt by setting the B bit in the stack copy SR if the interrupt was caused by a BRK instruction, or by clearing the B bit if the interrupt was caused by an IRQ. Hence the type of interrupt has to be determined in software by fetching a copy of SR from the stack and masking for the B bit. The B bit is meaningless otherwise.

[GARTHWILSON]

Dvorak wrote:

I've been delving into the realm of 6502 assembly recently, and my code has gotten so large that it's becoming rather difficult to debug.

That's always a challenge. From whatever point you're at, advancing to bigger and bigger projects continues the challenge. One thing I found extremely helpful was to do the structure macros to get rid of the spaghetti that's typical of assembly language. I have an article on it, with source code for the C32 assembler, at http://wilsonminesco.com/StructureMacros/index.html . There are longer pieces of example code near the bottom of my article on simple methods to do multitasking on systems that don't have the resources to run a multitasking OS, or where hard realtime requirements may rule one out anyway, at http://wilsonminesco.com/multitask/index.html . Andrew (BitWise) and Anton Treuenfels here on the forum have their own assemblers that provide structures "right out of the box."

Quote:

I would use the BRK instruction but that brings you to the monitor, but I'm running on top of BASIC and I don't have any knowledge of software interrupts (yet. Maybe it's time?)

In my first big 6502 project (late 1980's), I had a subroutine that basically did the same thing, and labeled it BREAK. You could put JSR BREAK in anywhere you wanted, and it let you look around at the registers, status, program counter, variables, etc., and then continue the program when you exited the subroutine. It did not use BRK. I have an article on 6502 interrupts though (including software interrupts) at http://6502.org/tutorials/interrupts.html . (Enjoy my out-of-date cartoons!)

Quote:

I take it this has something to do with the stack?

Interrupts always involve the stack.

[BigEd]

BigDumbDinosaur wrote:

Dvorak wrote:

It seems like BRK is half of what I want (convenience-wise), but it will do. I was wanting something which would pause the code, then allow me to step through it using VICE's monitor, but I'm becoming uncertain as to whether or not something like that actually exists. Thanks!

VICE, being software, cannot single-step a program.

Nonsense! Of course VICE can single-step. See http://vice-emu.sourceforge.net/vice_11.html#SEC245
Using the emulator facilities is a great way to explore program behaviour.

Dvorak wrote:

edit; found this on a 6502 instruction set sheet: "BRK causes a non-maskable interrupt and increments the program counter by one. Therefore an RTI will go to the address of the BRK +2 so that BRK may be used to replace a two-byte instruction for debugging and the subsequent RTI will be correct. " I take it this has something to do with the stack?

As noted above, yes, an interrupt pushes the machine state including the PC onto the stack, so that an eventual RTI can continue exactly where the program had got to. It's much like a subroutine call, with two differences: the status register is pushed, and the PC value pushed is the actual return address (whereas an RTS will increment the PC before fetching the next instruction.)
See this simulation.

Cheers
Ed

[BigDumbDinosaur]

BigEd wrote:

BigDumbDinosaur wrote:

Dvorak wrote:

It seems like BRK is half of what I want (convenience-wise), but it will do. I was wanting something which would pause the code, then allow me to step through it using VICE's monitor, but I'm becoming uncertain as to whether or not something like that actually exists. Thanks!

VICE, being software, cannot single-step a program.

Nonsense! Of course VICE can single-step. See http://vice-emu.sourceforge.net/vice_11.html#SEC245
Using the emulator facilities is a great way to explore program behaviour.

Hmm...the version of VICE I have here doesn't have that feature.

[Aslak3]

This is just theory, I have never implemented this myself and have no idea if this is actually possible.

Assuming the program under debug was running out of RAM, couldn't single stepping be accomplished by poking a BRK into the "next" instruction, stashing the overwritten byte somewhere so the code stream can be stitched back together? Of course the BRK handler would need to know the number of bytes required by the "current" instruction.

Sorry if this is already covered elsewhere. I'm only pondering this from principles. Have only vague practical experience with software interrupts.

[BigEd]

Yes, you can almost do that. You have to cope separately with branches and other operations which disturb the progression of the program counter. I think at least one of the Apple monitors did exactly that.
Edit: no, it didn't quite do that. It copied the instruction-to-be-executed into RAM and ran it there, unless it was a special case. See the routine STEP here.

Code: Select all

FA43: 20 D0 F8  372  STEP     JSR   INSTDSP    ;DISASSEMBLE ONE INST

[White Flame]

The nice thing about VICE breakpoints and single stepping is that it also displays the VIC line & cycle counter for you (under the 'r' command), for either measuring performance or trying to hit cycle-specific machine effects.

The only thing that sucks about it is the actual windowed interface, at least on Windows. On Linux, the monitor shows up on the terminal that x64 was launched in, so you can scroll & copy/paste as usual. (in whatever version I happen to have)

[Dvorak]

BigEd wrote:

Yes, you can almost do that. You have to cope separately with branches and other operations which disturb the progression of the program counter. I think at least one of the Apple monitors did exactly that.
Edit: no, it didn't quite do that. It copied the instruction-to-be-executed into RAM and ran it there, unless it was a special case. See the routine STEP here.

Code: Select all

FA43: 20 D0 F8  372  STEP     JSR   INSTDSP    ;DISASSEMBLE ONE INST

Fairly interesting idea, I'll explore that a bit later. Thanks.

White Flame wrote:

The nice thing about VICE breakpoints and single stepping is that it also displays the VIC line & cycle counter for you (under the 'r' command), for either measuring performance or trying to hit cycle-specific machine effects.

The only thing that sucks about it is the actual windowed interface, at least on Windows. On Linux, the monitor shows up on the terminal that x64 was launched in, so you can scroll & copy/paste as usual. (in whatever version I happen to have)

I didn't know about the cycle counter, or that on nix the monitor allowed scrolling.. thanks!