joeloda@aicchi.UUCP (Joseph D. Loda) (02/21/85)
Does anyone out there have a listing of undocumented 6502 opcodes? From
talking to several people, I have discovered:
- That these opcodes function differently depending upon the chip
manufacturer.
- That some issue of "Compute" magazine had a listing of these at some
point in time.
Many thanks in advance; I'll sleep better with one more curiousity
satisfied :-).
--
Joe Loda
Analysts International (Chicago Branch)
(312) 882-4673
..!ihnp4!aicchi!joelodaliang@cvl.UUCP (Eli Liang) (02/22/85)
> Does anyone out there have a listing of undocumented 6502 opcodes? From > talking to several people, I have discovered: > > - That these opcodes function differently depending upon the chip > manufacturer. > > - That some issue of "Compute" magazine had a listing of these at some > point in time. > > Many thanks in advance; I'll sleep better with one more curiousity > satisfied :-). > > -- > Joe Loda > Analysts International (Chicago Branch) > (312) 882-4673 > ..!ihnp4!aicchi!joeloda There is a back issue of Byte which also mentioned the undocumented opcodes. The wierdest opcode yet though is one a friend told me about. It may be apochryphal so I think I will disclaim it right off. Supposedly, the original 6502 had an undocumented test instruction (one of the x2H opcodes, I think it was 12H) which would tie up the cpu and run internal checks on the processor such as run through the address/data lines lightning fast, until it was reset or a NMI occurred. Well, this testing had a nasty side effect.... The chips would get so hot doing this that after it was let run for a few hours, the chip would either just fail, or every long once in a while something catastrophic would happen and the chip would start smoking or actually catch on fire! It was thus descriptively named the HCF (Hold and Catch Fire) instruction. Supposedly, the Source or Compuserve had a 3 part article a few years ago describing this fascinating instruction. Perhaps there is someone on the net who worked on the design of the 6502 and could affirm or deny, once and for all whether the HCF instruction has ever existed or exists. -eli -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eli Liang --- University of Maryland Computer Vision Lab, (301) 454-4526 ARPA: liang@cvl, eli@mit-mc, eli@mit-prep CSNET: liang@cvl UUCP: {seismo,rlgvax,allegra,brl-bmd,nrl-css}!umcp-cs!cvl!liang
cdshaw@watrose.UUCP (Chris Shaw) (02/24/85)
The HCF instruction actually did exist in the early version of the Motorola 6800. This "instruction" was undocumented, as well, but I read an article in an ancient BYTE (1978 or so) that documented the undocumented goodies of 6800, and this was one of the instructions. It doesn't strike me as too likely that HCF could have occurred on 2 processors, and given reputations of all the CPU makers around I would vote Motorola as being most likely to screw up like this. Chris Shaw
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (02/26/85)
Opcodes like HCF (halt and catch fire) go back far farther than the 6502.
I've seen this on lists of bogus op codes 15 years ago and were old then.
The majority of them date from the days of the first mass produced computers
(i.e. hundreds rather than a few hand-built copies) where assembler was the
only way and the machines were full of ideosyncrasies in efficient
operation--like the 1401 which had an opcode to read a card, punch a card
and print a line simultaneously, in part because the machine had no
interrupts.
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPAdevoz@zurton.UUCP (02/27/85)
I wouldn't put much stock in a HCF instruction, considering the VAST number of 6502 based machines. Think about it. With the amount of "hacking" done on these, surely large numbers would have accidently executed HCF instructions and burst into flames. (hee hee hee). I do support the theory that there may be an instruction, or types of instructions, that, when executed, causes a Degradation of the Instruction Set, killing off many instructions, and maiming others. If you program in 6502 you know exactly what I mean. A sample of Destructive Op Codes: DHXI - Destroy Half of the X Index register DHYI - Destroy Half of the Y Index register AWID - Always Wander Into Decimal mode There are more. Supposedly during chip testing of the first few million devices, the original manufacturer wrongly executed these instructions, limiting the power of the 6502 forever, or until the 65816 arrives. (Ahhhh, the price of compatibility). ddddddddeeeeeeeevvvvvvvvvoooooooozzzzzzzzzz
dudek@utai.UUCP (Gregory Dudek) (03/04/85)
I tried to execute some of the unused 6502 opcodes and found one that seems to conform to the described HCF specs. That is, the processor seems to hang up and doesn't go anywhere until it gets a reset. Of course, I didn't let it sit there long enough to find out if the processor would self-destruct. If anybody is willing to satisfy our curiosities, the op-code was $12. As noted, the presence of the HCF instruction may depend on the chip manufacturer. Unfortunately, I forgot to check who made mine. Greg Dudek
liang@cvl.UUCP (Eli Liang) (03/07/85)
> I tried to execute some of the unused 6502 opcodes and found one that > seems to conform to the described HCF specs. That is, the processor > seems to hang up and doesn't go anywhere until it gets a reset. > Of course, I didn't let it sit there long enough to find out > if the processor would self-destruct. If anybody is willing to > satisfy our curiosities, the op-code was $12. As noted, the presence > of the HCF instruction may depend on the chip manufacturer. Unfortunately, > I forgot to check who made mine. > Greg Dudek This is the exact instruction which I mentioned in my previous article. $12. I think that there must be some truth in the HCF instruction for the 6502. -eli -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eli Liang --- University of Maryland Computer Vision Lab, (301) 454-4526 ARPA: liang@cvl, liang@lemuria, eli@mit-mc, eli@mit-prep CSNET: liang@cvl UUCP: {seismo,allegra,brl-bmd}!umcp-cs!cvl!liang
pc@unisoft.UUCP (Paul Campbell) (03/08/85)
<munch> Actually the HCF opcode implements the smiley face operator ( :-) :-) Paul Campbell ucbvax!unisoft!paul
john@x.UUCP (John Woods) (03/08/85)
> $12. I think that there must be some truth in the HCF instruction for the
As I have heard it, the "HCF" instruction which is often found in 6800s and
6502s is intended for QA at the factory: the intent is that you feed the chip
the magic instruction, and watch what happens: it is supposed to count on the
address lines, from 0 to 65535, forever. This [roughly] validates the address
drivers as well as much of the internal logic. Those who have been looking
for the HCF instruction on their favorite micros might watch the address
lines to see if this is true.
--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA
Sorry, I don't feel deep right now.paul@unisoft.UUCP (Paul Campbell) (03/10/85)
<munch> Seriously this time .... the 6800 has a similar opcode which is in there for chip testing ... when you execute it the chip goes into a strange mode where its microcode loops cycling its address lines thru the whole address space reading all of memory. The only way of getting out of this is to reset the chip, maybe the HCF instruction is similar? Paul Campbell ucbvax!unisoft!paul
john@hp-pcd.UUCP (john) (03/14/85)
<<<< I once found a bunch of undocumented opcodes in the 6502 in my KIM-1 by looking for patterns in the opcodes. None of the original 6502 opcodes ended in 11 (as in XXXXXX11). It turns out that executing these instructions would perform both a XXXXXX01 and a XXXXXX10 instruction. For example a A7 would load X from Page Zero (A6) AND load A from Page Zero(A5) at the same time. There were also some store instructions that could OR two registers and store them in memory in one instruction although I hate to think what was going on inside the chip for that one. I am sure that if a HCF was a opcode 12 that it must have been a special case instruction. Its class and grouping is what you would have suppected a ASL (ind),Y to be if it existed. John Eaton !hplabs!hp-pcd!john