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)


I noticed that there have been some edits and reverts recently concerning periods inside or outside of quotation marks. Here are the official rules:

Guy Macon 04:51, 22 May 2010 (UTC)

Burning the address lines:[edit]

The section on the 6800 references a claim from he Jargon File that claims:

"HCF: H-C-F n. Mnemonic for `Halt and Catch Fire', any of several undocumented and semi-mythical machine instructions with destructive side-effects, supposedly included for test purposes on several well-known architectures going as far back as the IBM 360. The MC6800 microprocessor was the first for which an HCF opcode became widely known. This instruction caused the processor to {toggle} a subset of the bus lines as rapidly as it could; in some configurations this could actually cause lines to burn up."

The problem is that the 6800 address bus doesn't have the capability to case "lines" to burn. This is true whether you interpret the claim as actually burning traces on the board or as burning out the drivers on one of the devices connected to the address bus. The "It has been claimed" part is certainly true, but the actual claim is false. Microprocessor address buses don't work that way. Guy Macon 15:21, 10 July 2010 (UTC)

It's conceivable that rapid switching of an address bus could cause it to suffer some physical damage. If the engineer is competent, this would not happen in a production system but you could imagine a test setup that would allow this to happen. Lord knows I've destroyed a few ICs by failing to properly consider the power going through their pins. - Richard Cavell (talk) 02:22, 11 July 2010 (UTC)
It is not conceivable that rapid switching of the address bus could cause a 6800 microprocessor to suffer physical damage. Rapid switching of the address bus is normal operation. It switches equally rapidly when executing HCF or when executing the program in ROM. In fact, you can write a program using no illegal opcodes that causes the exact same switching pattern on the address bus that HCF causes; simply put the NOP (no-operation) instruction in every ROM location. The Jargon File is wrong. Guy Macon 17:05, 11 July 2010 (UTC)
If I remember correctly, the HCF instruction on the Motorola 6800 not only put the address bus into counter mode, but it also tri-stated some of the control lines, most importantly the R/W control line. Depending upon the particular system the chip was used in, and how it was designed, it's indeterminate what value the R/W line would take on. On some systems, it was pulled into write mode (passively, via a pull-down resistor), but on other systems, it was allowed to float. The biggest problem is that it could very well float into "no-man's land" in between a low and a high logic level. Certain digital chips do NOT like to have their input floating in no-man's land, since that can cause the pull-up and pull-down transistors in a totem pole output stage to both turn on simultaneously, resulting in a vast increase in the current consumption of the chip. I don't know if this would be enough to cause a chip to melt down and/or fail, but it's conceivable that it could happen. (talk) 18:55, 31 October 2013 (UTC)Dave

Halt and Catch Fire on 6809?[edit]

Recently Phatom87 deleted the paragraph that claims that the Motorola 6809 had a HCF instruction - a claim that has been sitting with a a citation needed tag since 2008. This is, of course, The Right Thing To Do; information on Wikipedia needs to be verifiable.

I just tried to dig up a reference establishing the claim, but I was not able to find a source that meets Wikipedia standards. There are plenty of references, but most/all of them cite Wikipedia as the source.

I did find two USENET posts from 1997 and 1998 that discuss the opcodes, and nobody on the comp.sys.m6809 newsgroup disputed that they existed on the 6809. This makes me believe that the 6809 did indeed have HCF. Can anyone find a reference that is better than a USENET post?

Here are the newsgroup posts:

From: aland[at] (Alan DeKok)
Subject: Re: RESET *
Date: 1998/10/26
Message-ID: <712vnr$>#1/1
X-Deja-AN: 405353239
Sender: aland[at]
References: <> <>
Organization: Striker Software
NNTP-Posting-Date: Mon, 26 Oct 1998 18:04:13 EDT
Newsgroups: comp.sys.m6809

In article <>,
Steve Noskow <snoskow11woksons[at]> wrote:
>In article <>, willmcd96[at]
>(WillMcD96) wrote:
>> What in the world is the MC6809's RESET( 62)'s function???
>    You got me and Motorola on this one.  If you are saying 62 is the
>opcode (decimal), there is no op code decimal 62 which is $3E.  It is
>unused.  The hardware reset pin is #37, so I can't figure out what you're
>looking at.

  Opcode $3E is the unofficial RESET opcode.  Yes, it does a reset.

  There's also the unofficial HCF opcodes $15, $16, $17, $18, where
the CPU Halts, and Catches Fire.  Not literally, mind you, but it does
go utterly bonkers.

  Then there's STA immediate ($87), which doesn't work due to the
read-next-byte-at-PC feature of the 6809.  The STX immediate ($97)
works, but only stores the low byte of X, and leaves the high byte

  Most other opcodes are the same as their nearest legal relatives.
This is because the 6809 uses bit encoding for the instructions.  So
$40 (COMA?) is really binary '0100000X', and is thus the same as $41.
(to pick a number more or less at random).

  Alan DeKok.

From: Ian Glading <icgelec[at]>
Subject: Re: What do instructions $14 and $15 REALLY do?
Date: 1997/01/01
Message-ID: <>#1/1
X-Deja-AN: 207146210
distribution: world
references: <58ivu6$>
organization: I.C.G. Electronics
mime-version: 1.0
newsgroups: comp.sys.m6809

In article <58ivu6$>, Bruce Tomlin <btomlin[at]>
>Being both an old time 6809'er  <snip>
>But the $14 and $15 instructions have always defied my analysis, because I
>don't have anything to record what the bus is doing when they're running. 

Believe it or not I find these instructions (or at least I believe its
them) very usefull. I have allways known them as HCF (halt and catch
fire)and understood this to be a motorola in house test mode. The
address bus becomes a ripple counter so the thing cycles through memory
doing read cycles. This is handy if you are trying to fix a dead board
as it means you can verify the address decoding etc. The trick is to get
a processor which has crashed anyway into this mode, shorting out a
couple of address lines with the scope probe usually works !
        One final thing in this mode the damn thing masks the NMI !
   |      ---     ---       Email:  Ian[at]
   |     |       |          Phone:  01733 557447
   |     |       |          Fax:    01733 893275
   |     |       |   |      Snail:  I.C.G. Electronics  
   | .    --- .   --- .             35 Second Drove Industrial Estate
   E L E C T R O N I C S            Fengate, Peterborough, U.K. PE1 5XA

Guy Macon 23:56, 7 September 2010 (UTC)

I just added the above references. I would like something better, but it is clear from the above (and from personal research which, of course, I can't use as a source) that the HCF instruction does indeed exist on the 6809. On an unrelated note; the Show preview button does not show what the numbered reference looks like. Is there a way to preview this to make sure the reference is formatted correctly without saving the edit? Guy Macon 15:59, 6 October 2010 (UTC)
wrt seeing references before saving, you can temporary add a {{reflist}} template and later remove it before saving. Alternatively the wikiEd script provides an enhanced "quick preview" function that automatically shows references. -- intgr [talk] 17:21, 6 October 2010 (UTC)

Amongst the urban legends of the early computer games industry there was talk of a game that shipped for the Dragon ( not sure if it was 32 or 64 or if thats relevant ! ) that had a copy protection element that triggered a HCF instruction if the game was hacked. i remember it because there was then a court case for all the people who then went and bought a legit version of the game and claimed that it had destroyed their computer. The games company lost. As far as I know the chipset on the dragon is this very processor. So for what its worth I had heard that there is indeed an HCF on this chipset, but from a completely different angle. If you could trace the game and the court case then i think that it would be verified. — Preceding unsigned comment added by (talk) 21:46, 28 July 2014 (UTC)

It has been claimed...[edit]

The statement "It has been claimed that in some configurations, a 6800 CPU could actually cause the address lines to literally burn when placed in this mode" is unsupported by the reference to the Jargon File, which is a work of humor and satire. As has been discussed elsewhere on this page, you can write a program using legal opcodes that causes the exact same switching pattern on the address bus that HCF causes. I am going to wait a while to see if anyone defends it or rewrites it into something that the reference supports, and if not I intend to delete the claim. Guy Macon 03:40, 13 January 2011 (UTC)

MIPS-X HSC[edit]

Hi everyone,

I want to begin a discussion of the MIPS-X documentation that describes a "halt and spontaneously combust" instruction. I have personally communicated with the author of the documentation, who confirms that the instruction is not real - it is a joke. I have posted the conversation, with Paul's permission, here.

People take Wikipedia seriously, and the way things are, Wikipedia's citation policies cause us to include incorrect information. Can we find some way of resolving this? - Richard Cavell (talk) 03:26, 25 October 2011 (UTC)

As your correspondence notes, the standard is verifiability, not truth. Personal correspondence isn't verifiable, even if it were, Chow may have reasons to lie about it. My suggestion is that you, or a journalist, publish a small line item in a reliable online computing news outlet, and then cite that. Currently the article uses a very passive description of the reliability of the instruction manual... I'd suggest characterising the manual's inclusion of the instruction further, "claims" is a good indication that the verifiable source may be disconnected from the truth; "jokes" is an even greater characterisation. Fifelfoo (talk) 04:10, 25 October 2011 (UTC)
I've removed this section as it seems to be problematic in terms of significance and weight, and doesn't contribute to the understanding of HCF. Fifelfoo (talk) 03:15, 28 November 2011 (UTC)

Execute operator[edit]

It's "execute operator", not electrocute! It's a pun! If you're a programmer you'll understand it. (talk) 16:18, 30 October 2012 (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)

Early sources[edit]

The earliest source I can find for HCF is this 1967 issue of Datamation magazine. Apart from a snippet, it's not online and I have no access to any archives that might have it. Anyone else have access?

It's also mentioned in this 1968 journal, Modern Data Systems.

Another mention is in the 1971 book The architecture and engineering of digital computer complexes, Volume 1. Looking at Worldcat's entry for it, there is a copy at a university in Alberta, Canada and five European libraries. Anyone have access to any of those libraries? TJRC (talk) 21:03, 20 March 2014 (UTC)

Two details on Motorola 6800 opcodes[edit]

An unattributed remark in Motorola_68000#Instruction_set_details says that "Most 68000 assemblers used the '$' symbol for hexadecimal, instead of '0x' or a trailing H," and Motorola_6800#Example_code shows the use of the dollar-sign symbol. I know it's a fine point, but shouldn't the Halt_and_Catch_Fire#Motorola_6800 section of this article follow that practice? It currently uses "0x" instead of "$" in its opcode.

Also, references 2 and 3 both indicate that the HCF instruction was implemented in two opcodes, which (to use the dollar-sign form) are at $9D and $DD. I suggest changing the text to read "The 6800 HCF opcodes are $9D and $DD" or similar. But this is a fine point too.

I'm a new user and am asking these questions instead of making the edits myself for the sake of caution. --John E. Branch Jr. (talk) 15:15, 3 June 2014 (UTC)

HP 97 Printhead[edit]

My first exposure to the concept of Halt Catch Fire was the HP 97 printing calculator. THere were internal OPcodes to turn on and to turn off the printhead heater. With the advent of synthetic programming one could (usually accidentally) destroy the printer by turning the printhead on but not off again. The only reference I found is

Does this qualify as an HCF under the definitions for this page? There is high heat involved; the machine in question is damaged.

Jim W Davis (talk) 21:11, 3 July 2014 (UTC)

This is not a reliable source and it doesn't really go with the theme of the article. "Halt & Catch Fire" is not about anything literally catching fire, it's just a tongue-in-cheek reference to opcodes that make the CPU unresponsive. IMO not relevant. -- intgr [talk] 07:48, 4 July 2014 (UTC)

ping of death[edit]

should this be refenced in the article list?

--Patbahn (talk) 04:47, 13 July 2014 (UTC)

At most, in the See also section; but I'm on the fence as to whether it belongs, even there. TJRC (talk) 18:10, 13 July 2014 (UTC)
HCF is a software bug that destroys hardware. ping of death is nominally software that crashes hardware. There is of course the click of death. the see also could be appropraite --Patbahn (talk) 03:07, 5 September 2014 (UTC)
Agreed, I don't think it belongs. But HCF is not about destroying hardware, but simply making the hardware unresponsive until a reset: "The expression "catch fire" is intended as a joke; the CPU does not literally catch fire, but it does stop functioning."; "It has been claimed that in some hardware configurations, the unrelenting driving of the address lines caused them to smoke or burn. It is likely that the term "catch fire" is intended more as a metaphor for the unresponsive behavior of the CPU when placed in this state; there are no known examples of erratic behavior" -- intgr [talk] 08:33, 5 September 2014 (UTC)