brm@Neon.Stanford.EDU (Brian R. Murphy) (11/17/90)
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? -Brian
root@zswamp.fidonet.org (Geoffrey Welsh) (11/17/90)
Brian R. Murphy (brm@Neon.Stanford.EDU ) wrote: >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? I have seen an article in the Transactor, but I don't remember which issue. There is a page near the back of Raeto Colin West's "Programming the PET/CBM" (COMPUTE!), and it's reprinted in the "Complete Commodore Inner Space Anthology" (Transactor's all-purpose reference book). The 6510 and 8502 seem to act exactly as the 6502 did, but you should be aware that programs which use the reserved op codes won't work on processors like the 65C02 and 65816. This is why PaperClip won't work with the 4 MHz speedup board for the C64. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
po87553@korppi.tut.fi (Pasi 'Albert' Ojala) (11/18/90)
In article <1990Nov16.214729.27679@Neon.Stanford.EDU> brm@Neon.Stanford.EDU (Brian R. Murphy) writes: >.. >undocumented op-codes do on the 6502, 6510, and 8502? I recall seeing >.. >I saw this, and wondered whether anyone had done the same for the 6510 >and 8502. Would these be the same? > > > -Brian These undocumented op-codes aren't the same. For example some programmers used these ml-commands in their games --> they crashed on c128.. It's the same with 6502, op-codes do match, but undocumented commands do not. I have a documentation about 6510's op-codes (including 'undocumented' codes), so if you can't get it anywhere else, mail me. Pasi Ojala, Sysop Of Pasbox ps. currently I'm on the army, so it might take upto 3 weeks to get an answer. ++++++++++++++++++++++++++++++++++++++++++++++++++++ + Pasi Ojala The smaller .signature you have+ +po87553@tut.fi the more frieds you get. + ++++++++++++++++++++++++++++++++++++++++++++++++++++
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (11/18/90)
In article <1990Nov17.163800.12713@funet.fi> po87553@korppi.tut.fi (Pasi 'Albert' Ojala) writes: >>I saw this, and wondered whether anyone had done the same for the 6510 >>and 8502. Would these be the same? >> -Brian > > These undocumented op-codes aren't the same. For example some programmers >used these ml-commands in their games --> they crashed on c128.. >It's the same with 6502, op-codes do match, but undocumented commands do not. >I have a documentation about 6510's op-codes (including 'undocumented' codes), >so if you can't get it anywhere else, mail me. > The 6502, 6510, and 8502 are all internally the same as far as instruction processing goes, so the illegal opcodes generate the same effects on all three CPU's. The reason that many games crashed on the 128 is that they would often accidentally twiddle some memory locations that differ between the 64 and 128 (such as $D030, which does nothing on the C64 and can switch to 2 MHz-no-video mode on the C128). I believe I have a list of opcodes that were generated by an Apple hacker on the Apple ][ (6502 processor). I will attempt to locate them and post them up here.
po87553@korppi.tut.fi (Pasi 'Albert' Ojala) (11/18/90)
In article <1990Nov17.185259.10564@evax.arl.utexas.edu> cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >The 6502, 6510, and 8502 are all internally the same as far as >instruction processing goes, so the illegal opcodes generate the same >effects on all three CPU's. The reason that many games crashed on the >128 is that they would often accidentally twiddle some memory locations >that differ between the 64 and 128 (such as $D030, which does nothing on >the C64 and can switch to 2 MHz-no-video mode on the C128). >.. I will surely disagree. The real reason for crashing was the fact that undocumented commands did't work on 8502 at all. At least all these so called undocumented op-codes were 'accidents' produced by the other commands and the processor design. I am sure that both 6502 and 8502 differ significantly in their inner design. Most of the commands were JAM-operations anyway ($02 etc.).. An if I am wrong... this is what I believe in.. Pasi Ojala, Sysop Of Pasbox ++++++++++++++++++++++++++++++++++++++++++++++++++++ + Pasi Ojala The smaller .signature you have+ +po87553@tut.fi the more frieds you get. + ++++++++++++++++++++++++++++++++++++++++++++++++++++
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (11/18/90)
In article <1990Nov17.211343.17356@funet.fi> po87553@korppi.tut.fi (Pasi 'Albert' Ojala) writes: > >I will surely disagree. The real reason for crashing was the fact that >undocumented commands did't work on 8502 at all. At least all these so >called undocumented op-codes were 'accidents' produced by the other >commands and the processor design. I am sure that both 6502 and 8502 >differ significantly in their inner design. > The differences between the 6502 and 8502 are that the 8502 has an I/O port at address $00/$01, and the 8502 can run at 2 MHz rather than just 1 MHz. There was no need to redesign the way the processor works at all, so all instructions are processed exactly the same way, right down to the "bugs" in the hardware (ie, JMP ($xxFF) has the same incorrect result on both processors).
50723995@ucs.uwplatt.edu (Bill Zwicky) (11/18/90)
In article <1990Nov17.211343.17356@funet.fi>, po87553@korppi.tut.fi (Pasi 'Albert' Ojala) writes: > In article <1990Nov17.185259.10564@evax.arl.utexas.edu> cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >>The reason that many games crashed on the >>128 is that they would often accidentally twiddle some memory locations >>that differ between the 64 and 128 (such as $D030, which does nothing on >>the C64 and can switch to 2 MHz-no-video mode on the C128). >>.. > > I will surely disagree. The real reason for crashing was the fact that > undocumented commands did't work on 8502 at all. At least all these so > called undocumented op-codes were 'accidents' produced by the other > commands and the processor design. I am sure that both 6502 and 8502 > differ significantly in their inner design. > > Pasi Ojala, Sysop Of Pasbox There has never been a need for serious design changes between the 6502, 6510, and 8502; the 6510 is a 6502 with a built-in parallel port, and the 8502 is a 6510 that can run a 2 MHz. (Trust me; if a co. doesn't need to make changes, they won't) I've run numerous games on my 128, and I know several of them use undocumented opcodes, but still run fine. The only progams that have failed to work are ones that jump into 2 MHz mode, then try to do something that can't cope with the speed (ie. try to access the serial bus). |) / Bill Zwicky / |/ |)itman / 50723995 @ UWPlatt / o Left-handed widget / 50723995 @ UCS.UWPlatt.EDU / '
root@zswamp.fidonet.org (Geoffrey Welsh) (11/20/90)
>In article <1990Nov17.185259.10564@evax.arl.utexas.edu> >cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >>The 6502, 6510, and 8502 are all internally the same as far as >>instruction processing goes, so the illegal opcodes generate the same >>effects on all three CPU's. Pasi 'Albert' Ojala (po87553@korppi.tut.fi ) wrote: >I will surely disagree. The real reason for crashing was the fact that >undocumented commands did't work on 8502 at all. At least all these so >called undocumented op-codes were 'accidents' produced by the other >commands and the processor design. I am sure that both 6502 and 8502 >differ significantly in their inner design. I don't think that I will reveal any deeply-kept secrets when I say that PaperClip II used undocumented op codes in its descrambling (copy protection) routine... the same codes used by the 64 version, which were in turn from 6502-derived tables. Similarly, DesTerm 128 used 6502-derived op codes for its descrambling. They behaved predictably. Since Steve Douglas, Matt Desmond, and I have all been able to use 6502 undocumented ops on the 6510 and 8502, I'm willing to state with some confidence that most of the useful codes work identically (or at least, very similarly) on all three CPUs. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
kentsu@microsoft.UUCP (Kent SULLIVAN) (11/29/90)
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
josh@cditi.UUCP (Josh Muskovitz) (12/13/90)
In article <59424@microsoft.UUCP>, kentsu@microsoft.UUCP (Kent SULLIVAN) writes: > My friend Noel Nyman has done quite a bit with undocumented opcodes. The > following is from him. [lots of good text deleted] >... 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. [more deleted] > 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. [more deleted] > 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 I may be wrong, but the way I remember it, Commodore put out the first PET2001 well before Apple released the Apple ][. I don't count the Apple I, since it never really made it into production. The rest of what you said sounds right, though. I remember experimenting with undocumented ops on my PET eons ago. Also, Raeto West's book, Programming the PET/CBM was (at the time of first publishing) the VERY VERY VERY best book of info on this great machine. All of the information may not be original, but for the most part, it's all in there. I still regret giving up my PET and all of the info I collected over the years. If anyone has a working machine (hopefully with a floppy drive, at least) and is sick of it, perhaps we can work something out. I still have my war-torn original poster proclaiming "PET -- Unleash One Today". *sniff* Josh Muskovitz Computer Design, Inc. (but only until the end of the month) Grand Rapids, MI josh@uunet!cditi