Date   : Tue, 10 Sep 2002 19:30:52 +0100
From   : "Richard Gellman" <ricky@...>
Subject: Re: 65C102 thousand dollar question

>> I'm having a problem with second processor emulation.
>
>> Something keeps trying to execute opcode &FC on a regular basis.
>
>> Unfortunately, this is not a valid opcode :)
>
>> &FC is NOP Abs,X on the 6502 (undocumented), but behaves differently on
the
>> 65C102.
>>
>> I've tried a few tests, and with simple data in A, X, and Y, the
>> instruction doesn't seem to do anything.
>
>Where abouts is this magic &FC? There are an awful lot near the top of ROM
>in the vector tables.
>
>The only instructions that I know got added to the 65C102 over the 6502 are
>PHX,PLY,PHY,PLX,BRA,STZ,TRB,TSB and RMB/SMB to reset and set memory bit and
>BBS/BBR to branch on given memory bits being clear or set.
>
>I've checked the opcodes for all but the RMB/SMB and BBS/BBR so it's not
>those,and dasmx 1.30 (though supporting the 65C102) doesn't understand it.
>I input 0xFC 0x01 0x01 0x01 and got
> db &FC <-shame
> ora (&0001,x)
>
>Sprow.

*sheepish grin*

Turns out it was a bug in my own code. heh.
What was happening was the DEC instruction was miscalculating the value when
crossing 0.

The &FC resulted because the relocator loop that was running didn't stop at
the right time, and overwrote itself with spurious data, causing the
&FC opcode to appear several times.

Interesting that it doesn't seem to cause any problems for a 65C102..

-- Richard