65816 COP instruction

[BigDumbDinosaur]

Jmstein7 wrote:

Just read it. But, it doesn't explain how to get the signature byte. Does that just go into the ether?

C'mon, man, figure it out. The signature is in RAM or ROM, which means it can be read by code in the ISR. Review what gets pushed to the stack as COP is executed. Everything you need to find and load the signature is right there. Hint: stack pointer relative addressing is your friend. This is nothing more than basic assembly language programming.

[Martin A]

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.

[Jmstein7]

Quote:

C'mon, man, figure it out. The signature is in RAM or ROM, which means it can be read by code in the ISR. Review what gets pushed to the stack as COP is executed. Everything you need to find and load the signature is right there. Hint: stack pointer relative addressing is your friend. This is nothing more than basic assembly language programming.

Quote:

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?

[BigDumbDinosaur]

Jmstein7 wrote:

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

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

Give it a little more thought. You don't want to do anything to the stack copy of PC, right? If you do, things will blow up when you try to exit your ISR and return to the foreground.

I'll give you two clues: 1) You will be interested in the value of PB that was pushed; and 2) a 16-bit index register is also your friend.

Quote:

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

In principle, S-R indirect indexed is only slightly different than direct page indirect indexed. All that is different is defining where the pointer is located. If it's on direct page, you write LDA (<ptr>),Y, and <ptr> is an actual address. If it's on the stack, you write LDA (<offset>,S),Y, <offset> being relative to the current stack pointer. If SP = $C000 and <offset> = $04, then the pointer to the desired data is at $00C004. The result is LDA (<offset>,S),Y effectively becomes LDA ($00C004),Y.

[Jmstein7]

BigDumbDinosaur wrote:

Jmstein7 wrote:

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

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

Give it a little more thought. You don't want to do anything to the stack copy of PC, right? If you do, things will blow up when you try to exit your ISR and return to the foreground.

I'll give you two clues: 1) You will be interested in the value of PB that was pushed; and 2) a 16-bit index register is also your friend.

Quote:

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

In principle, S-R indirect indexed is only slightly different than direct page indirect indexed. All that is different is defining where the pointer is located. If it's on direct page, you write LDA (<ptr>),Y, and <ptr> is an actual address. If it's on the stack, you write LDA (<offset>,S),Y, <offset> being relative to the current stack pointer. If SP = $C000 and <offset> = $04, then the pointer to the desired data is at $00C004. The result is LDA (<offset>,S),Y effectively becomes LDA ($00C004),Y.

Inside the ISR

Code: Select all

 LDY  $01
 LDA  (1,S),Y 
 

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?

[GARTHWILSON]

Jmstein7 wrote:

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

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.

[BigDumbDinosaur]

Jmstein7 wrote:

Inside the ISR

Code: Select all

 LDY  $01
 LDA  (1,S),Y 
 

Will this work?

What does 1 represent in your instruction's operand?

Quote:

I’m on my phone, making this is a bit awkward and clumsy, so my apologies

Just as toilets are lousy drinking fountains, phones are lousy computers.

Quote:

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

Stack-relative addressing works the same in both modes. Speaking of which...

The 65C816 is really meant to be used in native mode. Emulation mode exists because "compatibility" with the 65C02 was an Apple requirement so Apple ][ software could be run on the ][GS. There is no reason to run in emulation mode, even if you never use 16-bit registers.

Both Garth and I have long recommended that the start of the reset handler in a 65C816 unit put the MPU into native mode and leave it there:

Code: Select all

reset    sei                   ;make sure IRQs are off
         clc                   ;switch MPU to...
         xce                   ;native mode

I do that in my POC units' firmware: the above sequence is the start of the reset handler. Except very early in the development of POC V1.0, when I was debugging the hardware, I have not used emulation mode at all.

[Jmstein7]

BigDumbDinosaur wrote:

Jmstein7 wrote:

Inside the ISR

Code: Select all

 LDY  $01
 LDA  (1,S),Y 
 

Will this work?

What does 1 represent in your instruction's operand?

Quote:

I’m on my phone, making this is a bit awkward and clumsy, so my apologies

Just as toilets are lousy drinking fountains, phones are lousy computers.

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.

[barrym95838]

Jmstein7 wrote:

Inside the ISR

Code: Select all

 LDY  $01
 LDA  (1,S),Y 
 

Will this work?
Then store A wherever?

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.

[Jmstein7]

Quote:

Code: Select all

reset    sei                   ;make sure IRQs are off
         clc                   ;switch MPU to...
         xce                   ;native mode

Wait, SEI? Why are we turning off interrupts?

Quote:

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.

That is VERY funny - I actually laughed out loud when I read that. Thank goodness I wasn't drinking anything at the time.

[GARTHWILSON]

Jmstein7 wrote:

Wait, SEI? Why are we turning off interrupts?

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.

[Jmstein7]

GARTHWILSON wrote:

Jmstein7 wrote:

Wait, SEI? Why are we turning off interrupts?

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.

[BigEd]

(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.)

[Jmstein7]

BigEd wrote:

(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?

[barrym95838]

Jmstein7 wrote:

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.