[Coco] 6309 Weirdness ??

[Darren A.]

Okay, I am giving up on this one. Obviously, using the PC register in any of 
the new inter-register instructions is, to say the least, problematic.  I 
think my documenation for these instructions will say something like:

"Specifying the PC register as either the source or destination produces 
undefined results."

I'm not quite sure what the solution should be for MESS emulation.

I agree with Robert that these probably should have been treated as illegal 
instructions and invoked the trap.  Of course, Hitachi never sanctioned the 
use of any new features, so its quite possible they didn't bother to 
bullet-proof everything.

Darren

---


>From: Robert Gault
>Reply-To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>Subject: Re: [Coco] 6309 Weirdness ??
>Date: Thu, 17 May 2007 09:56:54 -0400
>
> ><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.
>

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507