bentonh@sri-unix (11/04/82)
Some time ago there were some postings of clever processor
mnemonics. Among them was one which seemed to be halfway
serious.
I was wondering about none other then the infamous
HCF - Halt and Catch Fire, of the 6502 uP.
Does anyone know if there really was (is) such an op-code
that would cause the processor to lock up and get hot? If
so, was it ever corrected? Did it occur on both the MOS-Technology
as well as the Rockwell versions, and what was the op-code?
Left un-reset, could it cause permanent damage?
Any information is certain to be quite amusing. Thanks.
Benton Holzwarth
...teklabs!tekid!bentonhmartin (11/16/82)
One of the unused opcodes on the 6502 used to do interesting things if executed. The processor would get very hot and start drawing lots of current. The only out was to turn off the power - reset didn't work. This only happened on early processors, I think from both manufacturers. It has since been fixed. Sorry, I don't know what the opcode is/was - but anyone with an oldish 6502 system may know. Martin Harriss pyuxjj!martin
wagner (11/17/82)
I am not aware of any permanent damage that they could cause, but there are several opcodes on the 6502 that cause it to go away and not recover, except by reset. Michael Wagner, UTCS
kline (11/17/82)
#R:tekid:-55400:uicsovax:3700045:000:196 uicsovax!kline Nov 17 12:08:00 1982 KIM-1's with 6502's from MOS Technology locked up in an unresettable state on opcode 02H. I never noticed the CPU getting hot, though. Charley Kline, ...decvax!pur-ee!uiucdcs!uicsovax!kline
pdh (11/18/82)
The HCF (Halt and Catch Fire) instruction did indeed exist, but not on the
6502. The very early versions of the 6800, being a relative power burner,
if you took into account the (relatively small) die size, would execute this
opcode by locking into a tight loop (of microcode, I presume), which could
not be exited without powering down the chip; not even RESET would work
reliably. Left unattended, it would be theoretically possible for the
chip to overheat in spots and cause silicon damage, but I'm not sure if
this actually happened with the 6800.
Another microporcessor heat peculiarity: A friend tells me that the early
versions of the 6809, in the plastic package, could literally "melt down"
and burn out, because the chip ran too hot for the epoxy-resin packages.
To avoid the problem, you had to buy the ceramic package...
Peter Henry
{ucbvax!}hplabs!pdhCSvax:Physics:hal (11/18/82)
#R:tekid:-55400:pur-phy:7800001:000:479
pur-phy!hal Nov 17 08:22:00 1982
There was an undocumented opcode in the 6800 which was dubbed HCF
(Halt and Catch Fire). I don't know about its thermal properties but
it caused the 16 address lines to cycle as a 16 bit counter running at
the full clock frequency. The processor was unresponsive to any further
signals, including NMI and RESET. The only way to stop it was to remove
power. Maybe I can locate the opcode at home tonight; it was in an early
issue of BYTE.
Hal Chambers
pur-ee!pur-phy!halgreep@Su-Dsn@sri-unix (11/19/82)
This reminds me of something similar, which was for real. The pdp-15 (successor to the pdp-9, which came after the pdp-7, which followed the pdp-4, which was the offspring of the pdp-1 (all of which came before the pdp-11)) had a standalone diagnostic called the "hot memory test". It would put a one-word loop (jump to self) in memory and let it run for a while to see if the core (yes, they used core in those days) would keep working after getting warm. The thing would time out after 110 ms by sending a character to the console (model 33 tty) and looping until the interrupt occurred. I don't think 110 ms was long enough to cause spontaneous combustion of the memory, however. At least I never smelled any smoke. Speaking of bogus upcodes, there was a list of a couple of dozen at one place where I worked, and we often added our own. Many of them were of the "skip" class, often used with minis of that era, e.g. SFM (skip on full moon). Two others that I remember, which referred to specific people (whose names I will hide here for obvious reasons) were: SDS - skip if dumber than Smith NOP - skip if dumber than Jones The latter got its mnemonic because it could never happen.
wyse (11/20/82)
My office mate says he a microprocessor (he thought it was the 6800) had an opcode that when it was executed did something similar to Halt and Catch Fire, but with a purpose. Apparently when this was executed the chip started counting on the address lines and also (he thought) on the data lines starting at 0 and incrementing. There was no way out of it except to cycle power. Since this behavior was so regular it probably wasn't an accident. Speculation is that this was done for testing purposes as a first pass rejection/acceptance test for newly produce chips. Neal Wyse ihuxp!wyse
malcolm (11/22/82)
#R:tekid:-55400:pur-ee:6700006:000:480 pur-ee!malcolm Nov 16 10:07:00 1982 The Half and Catch Fire (HCF) instruction on the 6809 is one of the most useful for hardware debugging. When I first bring a processor up I give it a HCF and then watch the address lines cycle. They increment once for each processor cycle. This means that an entire 65k cycle is displayed 15 times a second. Works out pretty well for checking out addressing errors. I know which end of my soldering iron gets hot!!!! Malcolm Slaney Purdue EE Dept.