On May 27, 2014, at 1:15 PM, Henk <henk.gooijen at hotmail.com> wrote:
-----Oorspronkelijk bericht----- From: Tony Duell
Sent: Tuesday, May 27, 2014 8:08 PM
To: cctalk at
classiccmp.org
Subject: Re: Catch and Halt Fire - Drama set in early days of personal computing
Halt and Catch Fire is not a real computer
instruction that caused a race
condition that made the computer stop working. I imagine a bunch of
teenagers are scouring Intel technical manuals looking for the Code 2 Duo
equivalent of HCF.
I thought there was at least one microprocessor (Motorola 6800?) where an
undocumented instruction would cause the processor to simply do memory
cycles at the fasted posible rate, address incrementing each time, and
the procesosr ignored all inputs apart from reset.
While the machine did not catch fire, the system was essentailly locked
up until the hardware reset.
-tony
As usual, Tony is correct.
I remember that the 6800 has an undocumented (illegal) opcode
that did cycle through all addresses at clock speed. IIRC, it was also
mentioned in a BYTE article (when BYTE was still a joy to read).
Actually, the HP 2114/2115/2116 series of minicomputers could get into an
"infinite indirect loop" that could be really fun to break out of. No
undocumented
features.
If an instruction did an indirect memory reference and the referenced
memory location had bit 15 set (which indicated further redirection) the
instruction won't complete until it fetches a word with bit 15 clear. A bug
where a word refers to itself (with bit 15 set) or back further in the chain
would result in an "infinite indirect loop". This was unbreakable since
interrupts are only processed at the completion of an instruction. A reset
was the only way to break out of it.
TTFN - Guy