[Coco] 6309 Weirdness ??

[Robert Gault]

 ><snip>
> I can confirm some of this on my Coco3. But there is a gotcha!
> 
>  org $7000
> start ldx #-1
>  addr x,pc
>  nop
>  stx $400
>  rts
> Word at $400=$ffff
> 
>  org $7000
> start ldx #-3
>  addr x,pc
>  stx $400
>  rts
> Word at $400=$fffd.
> 
> Now if the above were true then the following should work.
>  org $7000
> start ldx #-2
>  addr x,pc
>  bra next
> next stx $400
>  rts
> Crash!!!!! Same explanation and this code should work. Since it doesn't, 
> something else must be happening.
> 
> The following doesn't work either.
>  org $7000
> start orcc #$50
>  ldx #-2
>  addr x,pc
>  bra next
> next stx $400
>  andcc #$af
>  rts
> Crash!!!!!
> 

Here may be the final piece to the puzzle. The above code should have 
worked if Darren's explanation was complete. Now look at the following code.

  org $7000
start ldx #-2
  addr x,pc
  brn next
next stx $400
  rts
Word at $400=$fffe

The only change from the original examples is 'bra next' to 'brn next'. 
I think this indicates that after the addr x,pc instruction, the address 
of the next instruction and the contents of regPC DO NOT MATCH. When the 
6309 must calculate where to branch by adding the bra data to regPC, the 
result is incorrect and the wrong instruction is executed. When bra is 
changed to brn, there is no branch and the result of the address 
calculation is not used. RegPC gets back into sync after this and the 
6309 correctly executes the stx instruction.

Will it be possible to determine the actual value in regPC as opposed to 
the instruction actually fetched, maybe. There is a clue in the 
following code.

  org $7000
start ldx #0
  addr x,pc
  bra next
next stx $400
  rts
Word at $400=$0000

  Now the code again uses the bra opcode so the next instruction run 
after 'addr x,pc' was either 'bra next' or 'stx $400'. There is no other 
possibility or $400 would not contain the correct data.
  Change the code again
  org $7000
start ldx #0
  addr x,pc
  tfr pc,x
next stx $400
  rts
Word at $400=$7008

  Now this result is completely unexpected. Here the value for regPC is 
exactly correct and you would expect that if regX were changed to +2 the 
instruction 'tfr pc,x' would be skipped. Instead the code crashes.
  For all our data to fit a theory, the following seems to be required. 
For the correct instruction to be fetched, the contents of regX must be 
the negative value of the length of the next instruction. However, that 
leaves an incorrect value in regPC until the fetched instruction is 
executed when regPC gets corrected.
  For the unique case of 'tfr pc,x' any value of regX other than $0000 
causes a crash with the above code. That suggests regPC gets altered 
(corrected) during the execution of 'tfr pc,x' resulting in the wrong 
addresses being used by the 6309.