Re: 6502 illegal opcodes

From: Segher Boessenkool <segher_at_kernel.crashing.org>
Date: Wed, 9 Nov 2011 14:55:55 +0100
Message-Id: <A2A8A08D-9A03-4E52-BFF0-DA0171D98C0F@kernel.crashing.org>
>> Which list do you recommend?  I find all of them quite broken.
>
> i think the ones most coders use today are (in this order)
> http://unusedino.de/ec64/technical/aay/c64/ibmain.htm and
> http://www.oxyron.de/html/opcodes02.html (which actually uses XAA,  
> interesting
> :))
>
>>>> (*) Oh and of course the STX abs,Y and STY abs,X (9e and 9c) insns,
>>>> those
>>>> are naughty!
>>>
>>> SHY and TAS you mean =)
>>
>> SHY and SHX.  I simply call them STY and STX, because that is what  
>> they
>> _are_, they just have a little problem :-)  They weren't left out  
>> of the
>> opcode map "just because", right :-)

Taking SHX abs,Y as example...  Your first reference says:

"Operation: M <- (X) /\ (PCH+1)

Note: Sometimes the "/\ (PCH+1)" drops off. Also page boundary crossing
won't work as expected (the bank where the value is stored may be equal
to the value stored). Warning: This opcode is said to be unstable!"

The second reference says:

"SHX {adr} = stores X&H into {adr}

note: sometimes the &H drops off. Also page boundary crossing will not
work as expected (the bank where the value is stored may be equal to the
value stored)."

and it also lists the insn as unstable.

Neither of these is correct :-)

If the two bytes of the address in the instruction are LO and HI, the
instruction does (i.e. you have 9e LO HI):

Set T := X AND (HI+1)

If LO+Y < 256:
    store T at [HI : LO+Y]
otherwise:
    store T at [T : LO+Y]

(The reason this happens is that the cycle the X value is put on the
data pins is the same cycle the corrected HI+1 value is put on the
high address pins.  And they go over the same internal bus (SB).  When
there is no carry from LO+Y, the value is not actually put on the
address pins, but it moves everywhere else internally, so the stored
value is still affected).

> uhm well, i am a software guy so i only know it from programmers  
> point of view
> =) which is "make sure no badline hits while the opcode runs".  
> wether it is BA
> or maybe the adress put on the bus by the vic, or whatever else...  
> you can
> probably tell better than me :)

My point is that as far as I can see RDY has no influence whatsoever
on SHX execution (other than eat cycles, of course); only XAA and LAX
(8b and ab) are influenced by data on the data bus during not RDY.

But don't trust my word on it, see what real hardware tells you :-)


Segher


       Message was sent through the cbm-hackers mailing list
Received on 2011-11-09 14:00:13

Archive generated by hypermail 2.2.0.