Eric Smith <eric(a)brouhaha.com>
Cameron Kaiser <ckaiser(a)oa.ptloma.edu> wrote
about undefined 6502 opcodes:
> [lot deleted]
Exact hit Eric.
This is nothing new to microprocessors; many
mainframes and minicomputers
had undefined opcodes which customers experimented with.
Yes, but as a rule, mainframes and most minis catch undefined
opcodes in a special exeption. Even the Intel x86 (starting
from with the 80186) throw an Int 06 on invalid
opcodes.
As with the
microprocessors, there was never any guarantee that the undefined opcodes
on any two otherwise equivalent machines would peform identically. With
microprocessors, though, there tend to be fewer design changes made after
introduction than there were for mainframes. AFAIK, all NMOS 6502 CPUs
have the same behavior for all undocumented instructions. Some of the
NMOS deriviatives have different behavior though.
Jep, the web article used by Cameron as reference is
based on the Commodore 8502 used in the C64. Just
lucky that Commo used the original MOS design for
the 8502 :). Other 6502 compatible Processors, that
didn't use the original design have different operations
at the undefind opcodes. Eventualy this led to some
problems Apple II programms encountered on individual
clones or Apples with upgraded CPUs. Especialy when
one switched for any of the CMOS types (65C02, 65SC02,
65G02, 65S02), becuse they used some of the free Opcodes
for new/enhanced operations (like bitmaipulation etc.).
Undefined opcodes ar implementation dependend like
internal function of an operating system are version
dependand. Just remember how ridicoulus the CPU detection
algorythms on the x86 are since there was no standard
cpu type command. Some of the enhanced chips can only
be detected usind complex tryal and error strategies.
I remember that a general purpose detector could take
some seconds to determinate the CPU thru exeptions,
timeouts, busfaults and arithmetic checking.
And now try to distinguish the different 6502s. I have
never seen any programm to perform this.
Funy thing: History repeats with DirectX - Microsoft
didn't include any version checking in DirectX 3.0
so, for example, if you want to use the enhanced sound
functions later on, you have to perform time consuming
operations to finaly find the needed function resulting
in an error (or worse, depending on the function just
performing diferent).
Gruss
H.
--
Ich denke, also bin ich, also gut
HRK