6502.org

I was 1/2 way through typing that you need to retive the return address off the stack, and adjust that back 1 byte. But I see BDD has beaten me to it.

Well, that would be:
-program counter + 2
-status register

So, could I really just decrement the stack PC by one and read that address?

Stack relative indirect indexed addressing is very confusing; I've never used it.

Also, in furtherance of this discussion, and elsewhere in the archives of the forum, I read that, on the hardware side, you can trap COP instructions by qualifying an enable with VPA = 1, VDA = 1, and the op code. Is that true?

Inside the ISR Will this work?
Then store A wherever?
I’m on my phone, making this is a bit awkward and clumsy, so my apologies

Do I need to be out of emulation mode to make this work?

In one of the pages of the 6502 stacks treatise, I show, in 6502 code, what the 816's stack-relative indirect indexed addressing mode does, about 80% of the way down the page, where you'll see in big letters, "stack-relative indirect indexed addressing." Pretty neat.

Indeed!

Anyway... "1" represents the relative address, or location, from where I think you would find the data just pushed on to the stack. I could be, and probably am, wrong. I know you guys can do this in your sleep, which is incredible per se. Remember, I'm just the student, here.

I have very limited experience with this addressing mode, but I'll go out on a limb and say that the chances that A contains your signature byte are at best one in 256.

Let me venture further out on that limb and offer:

• An ISR doesn't immediately trash registers without saving them somewhere, but I suppose a COP handler could get away with it.
  LDY $01 is probably a typo, because none of us have any idea what is contained in direct page location $01.
  (1,S) doesn't contain an address because you forgot to skip over your saved P register.
  (2,S) should hold something you can work with, but it's pointing one byte after your signature byte, which is a slight pain.
  If you're in native mode you may be able to make Y 16-bits and load it with #$FFFF to give you the negative one offset you need to reach the signature byte. This might be the best way on a 65c802, or a 65c816 when you know the COP-caller came from the same program bank as your data bank. (Does (d,S),Y cross to a higher bank? dunno ...)
  In emulation mode, you're probably better off copying the return address from the stack to direct page and decrementing it there before trying to grab the signature byte with a LDA (DPP).

I'm far from an experienced '816 user, so I may have royally goofed ... corrections and criticisms are warmly welcomed.

Wait, SEI? Why are we turning off interrupts?
That is VERY funny - I actually laughed out loud when I read that. Thank goodness I wasn't drinking anything at the time.

If it gets there from the hardware reset line, the SEI won't be necessary as it's an automatic part of the reset sequence; however, if you jump there from software for any reason, you'll want to ignore interrupts until things are set up properly again. I've never done it that way myself.

Ahhhh. Got it.

(obligatory notice: there's a variety of opinions on how to use the '816, and it will depend on the situation. Don't take anyone's word on a One True Way, because that's always a simplification. We should note that the second post in this thread takes a very different view on how COP can be handled: not as a software interrupt but as a co-processor decoded instruction.)

Ed, can you elaborate? How does one handle COP as a co-processor decoded instruction?

Page one of this thread touches on some ideas, but I have no direct knowledge of anyone actually implementing these ideas in real life.

Naturally, you need some hardware goodies to get the '816 and the co-processor to play nicely with each other, and some software goodies to tell them how to play, but that's about as much as I can offer at this stage of the game.