Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!kentsu From: kentsu@microsoft.UUCP (Kent SULLIVAN) Newsgroups: comp.sys.cbm Subject: Re: Undocumented 6502/6510/8502 instructions? (LONG) Message-ID: <59424@microsoft.UUCP> Date: 29 Nov 90 06:57:10 GMT References: <1990Nov13.043708.23063@DMI.USherb.CA> <1990Nov13.162259.981@vax5.cit.cornell.edu> <4125.27440883@cc.nu.oz.au> <1990Nov16.214729.27679@Neon.Stanford.EDU> Reply-To: kentsu@microsoft.UUCP (Kent SULLIVAN) Distribution: na,comp Organization: Microsoft Corp., Redmond WA Lines: 116 In article <1990Nov16.214729.27679@Neon.Stanford.EDU> brm@Neon.Stanford.EDU (Brian R. Murphy) writes: >Can anyone give me a reference to a description of what the >undocumented op-codes do on the 6502, 6510, and 8502? I recall seeing >a list for the 6502 in a magazine somewhere, but don't remember where >I saw this, and wondered whether anyone had done the same for the 6510 >and 8502. Would these be the same? My friend Noel Nyman has done quite a bit with undocumented opcodes. The following is from him. Kent Sullivan Microsoft Corporation ----- The 6502 executes about 146 documented instructions. These are represented by one byte operations codes or "opcodes". There are 256 possible opcodes. MOS (now Commodore) chose not to document the other 110 opcodes. Although a few sources refer to them as "pseudo-opcodes", they're most commonly called "undocumented opcodes". My first exposure to the undocumented opcodes came from an article by Joel Shepherd in COMPUTE! ("Extra Instructions", October 1983). He showed that about half of the undocd codes are either NOP's or cause the processor to crash. The remaining codes have some curious properties, frequently executing several instructions at the same time. Several months later, Chris Newman (Reflexive Software) was developing what turned out to be the ultimate block editor, DISK MAINTENANCE. He wanted to add optional disassembly of undocd opcodes, and asked me to do the research. I found some of Shepherd's descriptions were incorrect and others were incomplete. I used Shepherd's four letter mnemonics, but Chris changed them to a three letter system to conform with the standard documented opcodes. I also found early 1980's references to the undocd codes by a Dr. Dobbs columnist who suggested their possible use in a special assembler for adding comments that would be retained in the object code. He was adamant that they NOT be used to execute their curious instructions. Jim McLaughlin published an article in The TRANSACTOR on the subject in 1985 ("Hidden Op-Codes", volume 6, issue 03). He covered much the same material as Shepherd, and made the same errors. I sent a letter to TANSACTOR with my comments on McLaughlin's article and some sample code. Raymond Quirling sent a similar letter, and both were published in volume 6, issue 05. Our two charts were not the same, though it's hard for the casual reader to see that. There are no standard mnemonics, and everyone uses a different set of letters for the same undocd code. Ray and I compared notes, and I agree in general with his conclusions. He also supplied me with the only example I've seen of undocd opcodes used in a real program. Paper Clip uses them as part of its dongle copy protection scheme. "The Complete Commodore Inner Space Anthology" published by TRANSACTOR, and "Programming the PET/CBM" by Raeto West give brief charts of the undocd codes. The Anthology chart is a virtual repeat of Shepherd's work. West presents them in a more organized chart, and leaves out the really strange codes. Schnedler Systems publishes a 6502 disassembler that provides for optional mnemonics. Although this feature was designed to support the 65C02, it can be used with an undocd opcodes list, also. Note that the 65C02 is a superset of the 6502 opcodes. Most of the undocd codes have been replaced with real codes in the newer processor. Any program that uses the undocd codes will not run on a 65C02. The C64 TurboMaster from Schnedler Systems, which speeds the C64 to about 4MHz, uses the 65C02 processor. When TRANSACTOR was still publishing, I considered doing a full treatment on the undocd codes. It occurred to me that, since the 6502 was used in the Apple line before Commodore made computers, someone in that community may have worked with undocd codes also. A call to Apple put me in touch with Bob Sander-Cederlof who at one time published an Apple oriented technical journal. His March, 1981 "Apple Assembly Line" (volume 1, issue 6) contains probably the best and most definitive chart I've seen. A year before Rae West, two years before Shepherd, Sander-Cederlof had pinned down all the quirks and curiosities the rest of us have "discovered". When I talked with him, Sander-Cederlof suggested that anyone really interested in this subject should probably get in touch with Bill Mensch, the designer who created the 6502. He would certainly be the best source for why the instruction set has undocd opcodes. A year ago he was working at Western Design Center in Phoenix, AZ. TRANSACTOR folded, and I lost interest in the project, so haven't tried to contact Mensch. A comment frequently encountered in undocd opcode articles is the danger in using them. The usual reason given is that newer versions of the chip may execute the codes differently. To test that, I and several others, ran sample code on PET's and VIC20's (6502), the C64 (6510), a Plus4 (1756) and a few Apple II's (6502). Although these weren't exhaustive tests, everything worked identically on all machines. MOS licensed two other manufacturers, Rockwell and Synertek, to make 6502's. After several years of searching, I've finally found 6502's from both companies, which was what got me started on the idea of a TRANSACTOR article. But, I haven't tested the opcodes on them. Sander- Cederlof's tests were made on a Synertek chip produced in 1977. When Quirling's letter appeared in TRANSACTOR, I had a C128 (8502 processor). While testing his chart against mine, I discovered that the 8502 did execute one undocd opcode differently than the 6510 in my C64. But, I've lost the notes on that, and don't remember now which opcode it was. Ray Quirling's letter to TRANSACTOR starts out "People who investigate undocumented opcodes deserve all the headaches they get!" After many hours chasing after what appears to be useless (though interesting) 65XX trivia, I tend to agree. These codes do some crazy things, in all 13 addressing modes. Some even change the stack pointer, making for interesting effects if you use JSR's to test them. The codes that tripped up Shepherd and McLaughlin use the high byte of the data address, increment it, form a product with a register, and store the result using absolute indexed Y addressing. If, after all that, you still decide to pursue this subject, good luck. It will be frustrating and fun. If you find anything interesting, let me know and we'll compare notes. Noel Nyman (11/90) Geoduck Developmental Systems (in association with Dr. Evil Labs) PO Box 58587 Seattle WA 98138 USA