how does 6502 single step work

Modding and Technical Issues

Moderator: Moderators

Post Reply
bills442
Vic 20 Amateur
Posts: 69
Joined: Mon Aug 07, 2006 5:12 pm

how does 6502 single step work

Post by bills442 »

I've been trying to figure out ( just curious ) how single step mode in HesMon for the vic 20 works. I know the 6502 has the ability to signal when it is fetching an instruction and I know you can halt the processor ... but doesn't there need to be external hardware onboard to allow such 'single stepping'?

Was there such hardware on all the popular 8 bits from the day ( Apple, Atari Commodore )

I'm familiar with how single step works on an 8086 for example.

How does HesMon's 'step' command work? Is is hardware generating an interrupt, or is it doing some incredibly clever software trick, like copying the code and writing a BRK, then jumping to it?

Thanks!
callan
Vic 20 Newbie
Posts: 16
Joined: Fri Oct 05, 2012 1:02 am

Re: how does 6502 single step work

Post by callan »

bills442 wrote:I've been trying to figure out ( just curious ) how single step mode in HesMon for the vic 20 works. I know the 6502 has the ability to signal when it is fetching an instruction and I know you can halt the processor ... but doesn't there need to be external hardware onboard to allow such 'single stepping'?

Was there such hardware on all the popular 8 bits from the day ( Apple, Atari Commodore )

I'm familiar with how single step works on an 8086 for example.

How does HesMon's 'step' command work? Is is hardware generating an interrupt, or is it doing some incredibly clever software trick, like copying the code and writing a BRK, then jumping to it?

Thanks!
HESMON was just a ROM, no fancy hardware.
I always assumed it just intelligently copied the code into the back-end of the stack, and ran it in there, with a BRK after the instruction.

Callan
bills442
Vic 20 Amateur
Posts: 69
Joined: Mon Aug 07, 2006 5:12 pm

Post by bills442 »

I was trying to imagine what you are describing, but it seems doing this for instructions that modify the program counter would be difficult. You couldn't put a BRK after a branch instruction, unless you rewrote that instruction to go somewhere you could control, same with JMP ?
User avatar
buzbard
Vic 20 Devotee
Posts: 213
Joined: Sun Jul 03, 2005 9:10 am

Post by buzbard »

I'm not saying this is what happens but I imagine this might work.

What if HesMon doesn't actually "execute" each of the opcodes?

It would be fairly easy to just analyze the few bytes of each instruction and change "internal" copies of the program counter, stack pointer, status register, accumulator, etc.
Ray..
User avatar
TLovskog
Vic 20 Enthusiast
Posts: 194
Joined: Fri Mar 25, 2011 3:16 pm
Location: Kävlinge, Sweden

Post by TLovskog »

The below is only true if my 30 year old memories while disassemble hesmon to remove the copy protection serves me right.

As I recall hesmon uses the NMI and a timer to achieve this.
When you issue the (W)alk or (Q)uick Trace command it sets up the NMI routine for the job and sets the VIA#1 timer to timeout after just a few clock ticks. Enough to do Start the Walk/Quick Trace.
The CPU then only have time to execute the next op-code before the timer times out and a NMI is issued. Control is then handed over to the NMI routine. This routine checks for breakpoints and either waits for a key press or continuous. After the house work the VIA timer is again set and return from NMI interrupt is executed. The CPU now executes another op-code, timer times out and another NMI is fired.
BR
Thomas Lövskog
FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Post by FD22 »

Hmm. Presumably the cart sets the VIA timer to different values though, to accommodate the variability of instruction lengths? Since the CPU will not interrupt the currently-executing instruction if it has just one or two cycles left, the cart would have to be doing an in-place disassemble-and-emulate to determine how many cycles the next instruction would take and setting the timer to an appropriate value so that the NMI fires during the last two cycles...
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

No need to have the NMI in any specific cycle of the instruction. An instruction will never be interrupted in the middle so if the NMI trigger event occurs after 1 cycle into any instruction the actual NMI routine will be executed after that particular instruction.
FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Post by FD22 »

Yes, that's true - my thinking is coloured slightly at the moment because I'm working on a new process for establishing a cycle-exact stable raster. I'm coming at it from the point of view of needing to know exactly how many cycles of the current instruction (anywhere from zero to seven) still have to be executed before the IRQ takes effect.

So, yeah - set the VIA timer to 2 (plus any latency between setting the timer and executing the instruction under examination) and you're guaranteed to get an IRQ or NMI after the next instruction, whatever it is.
bills442
Vic 20 Amateur
Posts: 69
Joined: Mon Aug 07, 2006 5:12 pm

Post by bills442 »

You guys rock. Thanks TLovskog,

That sounds like the secret I was trying to imagine. I knew they must be doing something clever! You guys are amazing, having disassembled the ROM back in the day. heh heh.

Did any of the popular 6502 platforms from back in the day have an actual hardware single step mode? I thought I read the KIM did?
User avatar
TLovskog
Vic 20 Enthusiast
Posts: 194
Joined: Fri Mar 25, 2011 3:16 pm
Location: Kävlinge, Sweden

Post by TLovskog »

Yes. KIM-1 did a semi hardware trick. On the 6502 there is a signal called SYNC. That will go HIGH whenever the CPU is fetching an opcode. KIM-1 tied that to the NMI signal (through a switch and gate). Every opcode fetch would then generate an NMI interrupt and you could display PC, Registers, etc.

The ROM containing the KERNEL was masked out though, so that always run as normal.

Other suggestions including my own home brew 6502 stuff used SYNC + RDY (RDY beeing a signal to halt the processor).
BR
Thomas Lövskog
Post Reply