Talk:Halt and Catch Fire

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.

Those old Palms[edit]

The early palm I or IIs (I don't recall which) had a processor by the name of dragon-something in them. The clock could be set in software, and, if set high enough, would actually cause the device to get so hot that it melted. A security device company created by the man David Rensin (now owning Reality Mobile) created secure mission devices for the US gov't that made use of this as a security feature, if the passcode was entered incorrectly 3 times. This was deployed in bosnia and resulted in one bosnian soldier losing his finger as it was burned off by the melting palm pilot. The guy who built this explained it to, so I don't know how much of this is sourcable/attributible or not. Also, it might still be classified (or at least parts of it). —Preceding unsigned comment added by (talk) 14:36, 15 July 2008 (UTC)

Interesting. I had a Palm III ("Dragonball", btw; an embedded CMOS version of the good old Moto 68000 as found in various home PCs, all of whom suffered the most overheating risk from their PSUs) and found some freeware overclocking software for it. The higher speeds (somewhere around 150-200% of design speed) caused some instability and hang-ups, but I don't remember it actually overheating/melting etc. I mean, it's still in the back of the cupboard and fires up (ahem) quite happily if I put a pair of AAAs in... I think you may have been led around the verbal houses by a squaddie - I've found they're exceptionally good at it ;)
(However, part of me DOES want to believe that various unlucky code-hackers have fried their Commie PETs by entering certain UDCs into their programs, as I've heard of elsewhere - though there seems to be no mention of it here) (talk) 13:46, 14 October 2009 (UTC)
I don't think there's any doubt that people destroyed the PET monitors in that way. Not to mention breaking Commodore drives by playing tunes on them, and so on... But the PET monitor bug is not a Halt and Catch Fire. - Richard Cavell (talk) 12:34, 10 July 2010 (UTC)

Odetics video jukebox?[edit]

I just added this:

In the early 1980s Odetics made a 6800-based video jukebox that would occasionally enter test mode when subjected to static electricity on the coin slot. The system reset was connected to the NMI (non-maskable interrupt) pin instead of the RST (reset) pin, based on the assumption that the 6800 always responds to NMI. 6800 test mode, however, only responds to RST, not NMI. No damage occurred, but the screen would display garbage and the mechanism would move back and forth until the power was turned off and then on.

...which is based on my own memory. How do I properly attribute it? —Preceding unsigned comment added by Guymacon (talkcontribs)

You don't. Original research and personal recollections aren't appropriate content. -- Mikeblas 05:31, 13 April 2007 (UTC)
(Not being argumentitive, just making sure I understand the rules) If I publish my original research or personal recollections and someone adds them, that's OK? I assume that publishing them and adding them myself would fall under the rule above; what if I asked one of my coworkers who was there to publish his personal recollections and then I added them? Guymacon 22:29, 26 May 2007 (UTC)
Usually, not. If you're self publishing (like on your blog or website), then absolutely not. If you're writing in a reviewed journal, then it's okay. -- Mikeblas (talk) 18:19, 4 February 2008 (UTC)
I don't think the material is relevant to Halt and Catch Fire. It might well belong in Category:Hardware bugs somewhere. But I think that it's irrelevant, regardless of whether it's original research/sourced. - Richard Cavell (talk) 12:32, 10 July 2010 (UTC)
I strongly disagree. While the information should be excluded because it is original research (I originally wrote the above as a newbie Wikipedian who had not yet learned that), how is a real world example of a product malfunctioning because of the Motorola 6800 HCF/0xDD Halt and Catch Fire opcode not relevant to Halt and Catch Fire? Guy Macon 15:01, 10 July 2010 (UTC)
Was the jukebox executing HCF? According to what you said, you caused an interrupt. - Richard Cavell (talk) 02:17, 11 July 2010 (UTC)
Yes, the jukebox was executing HCF. Specifically, when it experienced static electricity on the coin slot, the data bus from the program ROM would feed the 6800 a bogus instruction instead of the instruction in the ROM. Sometimes that instruction was HCF, and of course once it executes HCF it keeps executing HCF forever, never getting back to the program it is supposed to run..
The interrupt situation was a separate issue involving getting out of HCF mode. Normally a 6800 executing HCF will stop executing HCF when the RST (reset) line resets the 6800. The jukebox had a reset button, and IIRC it also had a watchdog, either one of which would have exited HCF if only the designer had connected the reset button / watchdog to the reset line. Alas, he decided to connect it to NMI (non-maskable interrupt) instead of RST, reasoning that a 6800 cannot ignore NMI just as it cannot ignore RST, and indeed I could find nothing in the databook indicating otherwise. Alas, HCF (which was not documented in the databook) ignores NMI, so the attempt to reset was ineffective.
The situation that got me involved in this was that some kids in the UK discovered that they could use a hand-held piezoelectric "gun" that was sold as a way of eliminating static charges on vinyl records to zap the coin slot, causing an internal error that gave them free plays. The problem was that every once in a while the static electricity would cause a different error by invoking HCF. At that point the jukebox would go crazy with random garbage on the screen and the mechanism moving back and forth aimlessly. While this was going on, the reset button did nothing. Needless to say, figuring out what was wrong with our hardware was quite a challenge for me.
Too bad this is all my personal recollection and thus not suitable for inclusion in the HCF article, but I understand why we have that rule and fully agree with it. Guy Macon 16:45, 11 July 2010 (UTC)

MIPS-X HSC is a joke[edit]

Just thought I should point out that the halt and spontaneously combust instruction in the manual is a joke. Billgordon1099 (talk) 16:27, 7 October 2008 (UTC)

"..." (talk) 13:47, 14 October 2009 (UTC)
Yeah. I emailed Paul Chow and got a reply from him confirming that it's a joke. We'll put it back in that it's a joke and hope it stays there this time. - Richard Cavell (talk) 12:33, 10 July 2010 (UTC)

This "joke" opcode is listed as uncited. Here's a link to a PDF copy of the MIPS-X programmer's guide, but it's URL is Google-obfuscated. - The HSC "opcode" is documented on page 68. Segin (talk) 02:58, 26 August 2010 (UTC)

The Google-obfuscated URL above brings up the same PDF found several other places:

All PDF copies that I could find (including the one referenced in this article) contain the same opcode (4.58. hsc - Halt and Spontaneously Combust) and the same claim that it only exists on a special NSA version of the processor. It would be nice if the email from Paul Chow confirming that it's a joke was published somewhere so we can reference it. Guy Macon 16:56, 28 August 2010 (UTC)

Re: "We'll put it back in that it's a joke and hope it stays there this time", unless you can supply a citation, it should be removed. Guy Macon 15:27, 7 December 2010 (UTC)

Macs can be told to turn off their fans[edit]

Once the particulars are published, should this be added? It's likely not a single CPU instruction, so it might be out of scope for this article. davidwr/(talk)/(contribs) 20:11, 26 February 2014 (UTC)

Yeah, it's probably a reasonable addition to another or a new article, but not here. The HCF instruction has nothing to do with literally "catching fire", it's just hyperbole about instructions that make the CPU hang and run at full power. -- intgr [talk] 21:20, 26 February 2014 (UTC)
Disagree with this conclusion. This is very narrow tech-centric thinking that would not be broadly shared. See explanation below. (talk) 13:40, 10 October 2015 (UTC)
I also disagree. The idea of a CPU catching fire, either intentionally for security reasons, or accidentally due to bad design or reliance on vacuum tubes etc., is quite plausible. - Richard Cavell (talk) 23:46, 25 December 2016 (UTC)

Not encyclopedic[edit]

Has no one written, independently, about this concept and term? In all of the O'Reilly and other technical book series out there, are there no descriptions and mentions of it? Ignoring such sources, this article presents an example of much that is wrong with wikipedia. It is written by technologists, for technologists, based on their interpretation of original technical documents (therefore constituting policy-prohibited [original research?] based on primary sources, as the appearing tags imply). This simply is not encyclopedic, and as it stands, is a damaging example that others might follow. It is all the more unfortunate, given the fact that a high profile television program referencing the title term is now popular, drawing more people to explore the concept. (talk) 13:13, 10 October 2015 (UTC)

More specifically:

"It originally referred to a fictitious instruction in IBM System/360 computers, but later computer developers who saw the joke created real versions of this instruction for some machines."

without any citation could be written by someone that wants to re-write history or something worse.

The section "Motorola 6800" says:

"an undocumented assembly mnemonic HCF"

Since it was not documented, it had no official name. If there is anything official calling the operation Halt and Catch Fire then that should be cited.

The section "Other CPUs" says nothing about any processor catching fire literally or figuratively yet uses the mnemonic HCF as if there is some relevance.

Section "In early CPUs" says "on their next model" so that section describes something that only happened in the laboratory (during development), right? Sam Tomato (talk) 06:49, 16 March 2017 (UTC)

Z80: Accurate?[edit]

On the Zilog Z80, executing DI (disable interrupts) followed by HALT (wait for an interrupt) results in the CPU staying frozen indefinitely, waiting for an interrupt that cannot happen.

Shouldn't an NMI still terminate the HALT instruction even in DI mode? -- (talk) 09:52, 27 June 2017 (UTC)

Of course, and that's what the next paragraph already says.
You would though need hardware which generated NMIs, not just INTs. Andy Dingley (talk) 10:37, 27 June 2017 (UTC)

80286 opcode 0F 04[edit]

This article currently says "The 80286 has the undocumented opcode 0F 04, causing the CPU to hang when executed. The only way out is CPU reset."

According to Talk:X86 instruction listings#Opcode 0F 04 on 80286 this may not be entirely accurate. --Guy Macon (talk) 18:32, 10 January 2018 (UTC)

Go to and search for 0F 04 --Guy Macon (talk) 18:35, 10 January 2018 (UTC)