6502.org • View topic - Single step (ram) with BRK

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programming

All times are UTC

Single step (ram) with BRK

Page 1 of 2

[ 18 posts ]

Go to page 1, 2 Next

Previous topic | Next topic

Author

Message

barnacle

Post subject: Single step (ram) with BRK

Posted: Thu Feb 09, 2023 8:48 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

I'm currently thinking this through, but do I have the right sequence of steps here?

at initial breakpoint address, steal the existing instruction and tuck it away somewhere safe
replace the instruction first byte with a BRK
wait for the BRK to trigger the interrupt
...
in the interrupt, having checked the B flag, do the register view or whatever you need to see the status. Probably await some user instruction to do the single step (or escape)
look at the stack to see where we came from
subtract two to point (the return is always two past the interrupt, right?) back to the original instruction address and put that back on the stack
replace the original instruction
calculate the length of the original instruction
using that value, grab the next instruction, store that, and replace it with a BRK
rti to execute the current instruction
repeat until bored

Did I miss anything? The processor status is pushed, I think, on a BRK so I need to check the order of the stack, but other than that I think I have everything.

Neil

Top

hoglet

Post subject: Re: Single step (ram) with BRK

Posted: Thu Feb 09, 2023 8:53 pm

Joined: Sun Jun 29, 2014 5:42 am
Posts: 352

barnacle wrote:

Did I miss anything? The processor status is pushed, I think, on a BRK so I need to check the order of the stack, but other than that I think I have everything.

Special handling of JSR, RTS, JMP and taken branch instructions?

Dave

Top

barnacle

Post subject: Re: Single step (ram) with BRK

Posted: Thu Feb 09, 2023 8:59 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

Ack, yes. Thank you; they'll need some consideration.

The 'calculate the length of the instruction' bit to calculate the next BRK becomes 'calculate the address of the next instruction to execute'.

Neil

Top

hoglet

Post subject: Re: Single step (ram) with BRK

Posted: Thu Feb 09, 2023 9:20 pm

Joined: Sun Jun 29, 2014 5:42 am
Posts: 352

barnacle wrote:

The 'calculate the length of the instruction' bit to calculate the next BRK becomes 'calculate the address of the next instruction to execute'.

And this is further compilcated because some JSR instructions will head off into ROM, as might some JMP instructions. The latter are particularly problematic.

Dave

Top

barnacle

Post subject: Re: Single step (ram) with BRK

Posted: Thu Feb 09, 2023 9:30 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

Though perhaps simplified as I'm looking at an 'all RAM' system. Otherwise, one might have to trace through ROM until you hit something in RAM again. A naive approach might be to execute a call to ROM - the next BRK is where the call returns to - but that doesn't resolve the JMP issue (direct or indirect).

More thinking...

Neil

Top

teamtempest

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 10, 2023 2:48 pm

Joined: Sun Nov 08, 2009 1:56 am
Posts: 398
Location: Minnesota

Don't let the perfect get in the way of the good. If you can get something useful working now, you can worry about extending it later.

Top

barrym95838

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 10, 2023 4:50 pm

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA

I'm a fan of studying prior art for my own use. The pertinent section starts around address $FA43 and continues for 200 bytes or so.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Top

kernelthread

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 10, 2023 5:46 pm

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166

barnacle wrote:

Assuming you're debugging an application program in RAM, control transfers to ROM would either be system calls or program termination. A system call would usually be a JSR, so you would put the BRK after the JSR and do a "step over" operation, assuming you're not trying to debug the system call itself. A JMP to ROM could be program termination (in which case no need to step) or it could be a tail call to a system function. In the latter case the return at the end of the system function will return to the top address on the stack, so that would be a candidate for where to put the next BRK.

Top

barnacle

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 10, 2023 6:05 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

I think it might be nice to work on the 'step into' 'step over' approach; one tries to follow the program flow and one waits until the return with the other. As it's a manual operation, it might be thought that the user will know when he's trying to go out of userland and into possible rom, but it might be nice to check, or blacklist certain addresses.

barrym95838 wrote:

I'm a fan of studying prior art for my own use. The pertinent section starts around address $FA43 and continues for 200 bytes or so.

Ah, but where's the fun in that?

I need to sort out the disassembler first (which coincidentally has a routine which calculates the instruction length) but for some reason at the moment my multiply by seven routine to index into a table has decided to multiply by seven and a half.

Neil

Top

barrym95838

Post subject: Re: Single step (ram) with BRK

Posted: Sat Feb 11, 2023 1:58 am

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA

Split your table into seven pieces ... problem solved! :lol:

Regarding "fun" factor, Woz authored some fascinating balls of twine during the late 1970s, and I love trying to pick them apart to see if some of the magic is still available.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Top

rudla.kudla

Post subject: Re: Single step (ram) with BRK

Posted: Wed Feb 15, 2023 1:06 pm

Joined: Tue Apr 20, 2010 4:02 pm
Posts: 33

If you just need the size of instruction, maybe a part of my simple relocation routine may be of use for you. It can tell you addressing mode of the instruction (no OP code though, so not really usable for disassembler). It uses just 32 byte table.

Attached is full routine that uses this to perform simple

Code:

;6502 code relocation routine

;Address mode
;0 -  none
;1 -  immediate,relative  #x
;2 -  zero page   ZP; ZP,X; ZP,Y; (ZP,X); (ZP),Y
;3 -  abs         adr; adr,X; adr,Y

;argument size in bytes
;   0 - none
;   1 - byte
;   2 - two bytes
;argument decoding (if there is one)
;   0 - immediate
;   1 - absolute address (either ZP or ABS)
;   2 - relative address (BEQ, ...)
;   3 - indirect address (either ZP or ABS) ABS only for JMP
;address register
;   0 - none
;   1 - X
;   2 - Y

;+---+---+---+---+---+---+---+---+
;|       |  reg  | arg_t | size  |
;+---+---+---+---+---+---+---+---+


I_SIZE_MASK = %11

I_ZERO = 0
I_BYTE = 1
I_WORD = 2

I_ARG_IMM = (0 << 2)
I_ADR     = (1 << 2)
I_ARG_REL = (2 << 2)
I_IND     = (3 << 2)      ;indirect is adr+relative

I_X = (1 << 4)
I_Y = (2 << 4)
I_A = (3 << 4)

;--- modes
I_IMPL = 0
I_IMM = I_BYTE + I_ARG_IMM
I_ZP  = I_BYTE + I_ADR
I_ZPX = I_BYTE + I_ADR + I_X
I_ZPY = I_BYTE + I_ADR + I_Y

I_ABS  = I_WORD + I_ADR
I_ABSX = I_WORD + I_ADR + I_X
I_ABSY = I_WORD + I_ADR + I_Y

I_REL  = I_BYTE + I_ARG_REL            ;todo - we should have rel

I_INDX = I_BYTE + I_IND + I_X
I_INDY = I_BYTE + I_IND + I_Y


         org $2000


ptr = $A0
adr = $A2
code = $a4



decode
      ldy #0
      lda (ptr),y
      iny
      tax
      and #%00011111
      bne regular
      txa
      ;%xxx00000 -> %000xxx00
      lsr
      lsr
      lsr
      ora #%11      ;add 3

regular
      tax
      lda instr_mode_table,x

      ;--- now we have our addressing mode

      and #I_SIZE_MASK

      ;--- and this is the size
      rts



instr_mode_table
;                                   this column is used for special purpose
      .byte 0,      I_INDX, I_IMM,   I_IMM
      .byte I_ZP,   I_ZP,   I_ZP,    I_ABS
      .byte I_IMPL, I_IMM,  I_IMPL,  I_IMPL
      .byte I_ABS,  I_ABS,  I_ABS,   I_IMPL
      .byte I_REL,  I_INDY, 0,       0
      .byte I_ZPX,  I_ZPX,  I_ZPX,   I_IMM
      .byte I_IMPL, I_ABSY, I_IMPL,  I_IMM
      .byte I_ABSX, I_ABSX, I_ABSX,  I_IMM

Attachments:

reloc.asm [3.7 KiB]
Downloaded 39 times

Last edited by rudla.kudla on Thu Feb 16, 2023 7:18 am, edited 1 time in total.

Top

barnacle

Post subject: Re: Single step (ram) with BRK

Posted: Wed Feb 15, 2023 4:41 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

Thanks, I'll look into that. At the moment I have an existing disassemble-one-instruction routine which returns the length of the instruction so I get it for free

But I have other things to do first!

Neil

Top

Dr Jefyll

Post subject: Re: Single step (ram) with BRK

Posted: Thu Feb 16, 2023 10:09 pm

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada

(Edit: misguided first paragraph deleted :oops:

)

Quote:

The processor status is pushed, I think, on a BRK

Yes, for a BRK or for an NMI or IRQ, PC is first to get pushed and P is last, so P will be what's most accessible on stack. Remember, though, that the BRK bit exists only in the P byte pushed to stack. Unlike most bits of P, the BRK bit is never stored within the CPU.

Hoping this is clear.. Probably you've already gotten these details straight in the week that's elapsed since you first posted.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Top

barnacle

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 17, 2023 5:53 pm

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 857
Location: Potsdam, DE

Well I might have done, if little things like 'life' wouldn't insist on getting in the way!

The disassembler is about done; just need to make the right things happen when the opcode is invalid, and that's most of the bits in place for the line by line assembler so that shouldn't take too long (hah!) and then I can get on with this bit (though there's some circuit investigation going on in parallel...)

I'm considering a kind of double-layer system with multiple breakpoints (seven seems likely, plus the 'next instruction); I can replace two bytes at the breakpoint with the first being a BRK instruction and the second an ident 0-7 with 0 being reserved for the single step. The BRK interrupt triggers replacement of the bytes from the store, and depending on a command, either simply runs until another existing breakpoint, runs a single instruction, or if the instruction is a call runs until the call returns. Somewhere in there it will obviously spit out the current processor status, of course.

Neil

Top

kernelthread

Post subject: Re: Single step (ram) with BRK

Posted: Fri Feb 17, 2023 6:19 pm

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166

barnacle wrote:

I can replace two bytes at the breakpoint with the first being a BRK instruction and the second an ident 0-7 with 0 being reserved for the single step.

Replacing more than 1 byte won't work in the general case. It breaks in the instance where a breakpoint is placed on a 1-byte instruction and the code contains paths which branch to the instruction following the one with the breakpoint.

Top

Page 1 of 2

[ 18 posts ]

Go to page 1, 2 Next

Board index » 6502.org Users Forum » Programming

All times are UTC

Who is online

Users browsing this forum: No registered users and 17 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum