RE: 6502 illegal opcodes

We used to talk about  a "catch fire and burn" opcode in the CMOS version,
but details remain fuzzy after so many years.

Bil

-----Original Message-----
From: owner-cbm-hackers@musoftware.de
[mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Segher Boessenkool
Sent: Wednesday, November 09, 2011 8:56 AM
To: cbm-hackers@musoftware.de
Subject: Re: 6502 illegal opcodes

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

       Message was sent through the cbm-hackers mailing list