I wrote: Cameron Kaiser wrote: Actually they had already designed the 6502, for use in new designs where pin compatability with the 6800 was less important. The 6502 only needed a single-phase clock input rather than the two-phase non-overlapping clock required by the 6800, which made it somewhat easier to design with. Apparently Motorola didn't consider the 6502 to be as much as a threat, since it wasn't a drop-in replacement. We have a winner. According to my docs, Sept. 1975. I've always wondered whether the ROR was originally planned but just didn't work on the first silicon, or whether it was added to the design later. I haven't tried running ROR on my 6501 or early 6502s to see what happens. Eric

I've always wondered about the internal construction of the 6502. Sure, you can look at a list of illegal instructions but the list doesn't tell you why the instructions do what they do, only what they do. I've also always wondered how the opcodes were allocated. (Perhaps to avoid being sued for 6800 compatibility?) In some cases, there is almost but not quite a pattern, and switching the opcodes around would make the pattern MORE apparent instead of less. (The register-transfer instructions are a good example.) So, does anyone have a copy of the 6502 mask designs lying around? :) And did Chuck Peddle ever show up at the VCF? He would be THE person to ask (OK, maybe Steve Wozniak would know too). -- Derek

The "family" idea bothers me. I've seen charts of "How the 6502 decodes instructions" in various books -- they break the instructions down based on the first and last few bits, in other words into families. They then list the remaining bits with their corresponding opcodes. The problem is that even the legitimate opcodes fit into more than one family (according to the rough schemes in the books). Clearly the 6502 has one exact way of decoding instructions and one well-defined way of reacting to the undocumented opcodes. Of course I don't know what that way is, but it's there. The books are just making a rough model of the chip. I'm thinking about medieval philosophers. Their arguments were limited by a whole slew of assumptions, religious beliefs, etc., and they had to shoe- horn the ideas they worked with into the constraints imposed on them. Their philosophy wasn't _bad_, but from a different and remote vantage point it seems profound and simple at the same time and somewhat bizarre. (I could be very wrong about this, since I just have a few terms like "scholasticism" floating around in my head. Can anyone suggest a good book?) It would be really impressive to create a chip with enough flexibility in the opcode set to accommodate shades of meaning or a grammar of instructions. But the 6502 isn't that chip, even if it seems that way. Are there any simple reverse-engineering techniques (like looking at an open package under a microscope)? And how many 6502's fit on the head of a pin? [Chuck Peddle] Boy, you have all *kinds* of irons in the fire. -- Derek

Cameron Kaiser <ckaiser(a)oa.ptloma.edu> wrote about undefined 6502 opcodes: 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. 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. 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