6502 vs. 6800 (was Re: kits, definitions, prices...)

From: Eric Smith <eric_at_brouhaha.com>
Date: Thu Oct 8 16:52:27 1998

Cameron Kaiser <ckaiser_at_oa.ptloma.edu> wrote about undefined 6502 opcodes:

> Consider LAX zero page mode, one of the best known undocumenteds.
>
> $A5 LDA $zp
> 10100101
>
> $A6 LDX $zp
> 10100110
>
> --> logical OR: 1010111 ($A7) --> LAX $zp
>
> Interestingly, there's no immediate mode:
>
> $A9 LDA #imm
> 10101001
>
> $A2 LDX #imm
> 10100010
>
> --> logical OR: $10101011 -> $AB expected opcode, doesn't work.

Well, of course that one won't work. You obviously can't just OR any two
opcodes together and expect it to work. If you study the way they are
arranged, you will see there are no defined instructions of the form XXXXXX11.
However, many of these opcodes perform (or attempt to perform) both of the
functions of the corresponding instructions XXXXXX01 and XXXXXX10. So $AB
would be expected to perform a function that is a composite of $A9 and $AA,
not $A9 and $A2.

Since the control logic doesn't really expect to be used this way, some
of these combinations do something sensible and others don't. Best results
occur when the XXXXXX01 and XXXXXX10 instructions use the same addressing
mode.

> The most interesting and catastrophic instruction is DIE, which hangs the
> CPU irrevocably (something like $F00FC7C8 on a Pentium, I guess :-): $02,
> $12, $22, $32, $42, $52, $62, $72, $92, $B2, $D2 and $F2, but not $82, $A2,
> $C2 or $E2. The instruction's position in the set suggests it's a two byte
> instruction that doesn't properly advance the PC, so the CPU is caught in an
> infinite loop.

I fail to see how $x2 instructions are expected not to advance the PC. A
logic analyzer reveals that these instructions take an immediate operand
of infinite length. They start reading consecutive bytes from the address
after the PC, and don't stop until reset is pressed.

This function is intended for manufacturing test, and is more commonly known
an HCF (Halt and Catch Fire). A few years ago there was a flame war on
alt.folklore.computers where moron was trying to convince everyone that if
you left the 6502 running this instruction, your CPU would literally heat
up to the point of damage and potentially causing an actual fire. Since you
can actually run a 6502 in this state for days on end without an abnormal
heating of the chip, I assume that this claim was a little-known urban
legend (or urban legend wannabe) that someone based on a too literal
interpretation of the unofficial 'HCF' name.

> One useful thing is that the undocumented opcodes seem to activate silicon
> sections simultaneously, i.e., they take no additional cycles to do their
> additional jobs. Primitive multitasking? ;-)

With the possible exception of undocumented instructions for manufacturing
test, like HCF, the way these come about is due to the logic minimization
of the control logic. If they don't care what function an undefined opcode
performs, they can simplify the logic equations for the documented functions.

This is nothing new to microprocessors; many mainframes and minicomputers
had undefined opcodes which customers experimented with. 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.

Eric
Received on Thu Oct 08 1998 - 16:52:27 BST