Talk:Halt and Catch Fire (computing)/Archive 1

Archive 1

Punctuation

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

http://en.wikipedia.org/wiki/Wikipedia:MOSQUOTE#Punctuation_inside_or_outside

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

It has been claimed...

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

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

It's "execute operator", not electrocute! It's a pun! If you're a programmer you'll understand it.

92.40.253.26 (talk) 16:18, 30 October 2012 (UTC)

Burning the address lines:

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.129.42.208.184 (talk) 18:55, 31 October 2013 (UTC)Dave

Early sources

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

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)

Halt and Catch Fire on 6809?

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:

http://groups.google.com/group/comp.sys.m6809/msg/65030934ed15ed2b

http://groups.google.com/group/comp.sys.m6809/msg/65030934ed15ed2b?dmode=source

From: aland[at]zzz.striker.ottawa.on.ca (Alan DeKok)
Subject: Re: RESET *
Date: 1998/10/26
Message-ID: <712vnr$87d@cpu1751.adsl.bellglobal.com>#1/1
X-Deja-AN: 405353239
Sender: aland[at]cpu1751.adsl.bellglobal.com
References: <19981023112040.15743.00000055@ng125.aol.com> <snoskow11woksons-261098100453@muc12-1.pgac.cog.nut.com>
Organization: Striker Software
NNTP-Posting-Date: Mon, 26 Oct 1998 18:04:13 EDT
Newsgroups: comp.sys.m6809

In article <snoskow11woksons-261098100453@muc12-1.pgac.cog.nut.com>,
Steve Noskow <snoskow11woksons[at]liame.tom.com> wrote:
>In article <19981023112040.15743.00000055@ng125.aol.com>, willmcd96[at]aol.com
>(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
intact.

  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.

http://groups.google.com/group/comp.sys.m6809/msg/7956eba6b219a5ec

http://groups.google.com/group/comp.sys.m6809/msg/7956eba6b219a5ec?dmode=source

From: Ian Glading <icgelec[at]icgelec.demon.co.uk>
Subject: Re: What do instructions $14 and $15 REALLY do?
Date: 1997/01/01
Message-ID: <2b9XBBARFryyEw2A@icgelec.demon.co.uk>#1/1
X-Deja-AN: 207146210
distribution: world
x-nntp-posting-host: icgelec.demon.co.uk
references: <58ivu6$cph@crl12.crl.com>
organization: I.C.G. Electronics
mime-version: 1.0
newsgroups: comp.sys.m6809


In article <58ivu6$cph@crl12.crl.com>, Bruce Tomlin <btomlin[at]crl.com>
writes
>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]icgelec.demon.co.uk
   |     |       |          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 188.29.16.225 (talk) 21:46, 28 July 2014 (UTC)

ping of death

should this be refenced in the article list?

https://en.wikipedia.org/wiki/Ping_of_death

--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. https://en.wikipedia.org/wiki/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)

HP 97 Printhead

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

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv021.cgi?read=220860

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)

I disagree entirely with @Intgr:'s analysis rejecting @Jim W Davis:'s suggestion of this source. Including it would markedly improve the article, for a couple of reasons. First, this is a better quality source than most in the article, because most are technical material that are primary sources requiring editor OR to draw conclusions, rather than secondary sources stating interpretation of primary information (so the editor does not have to interpret). Hence, this source is closer to WP guidelines and policies than most sources appearing. Second, the origin of the term, though referring to the broadly fictional notion that opcode can make the CPU unresponsive, likening this unresponsiveness to "catching fire," the fact that code/designs could exist that actually lead to such physical destruction cannot be seen as immaterial. A Road Runner-esque actual news event about someone strapping a jet engine to their back and leaping from a cliff would, as I just did, reference the fictional, imaginary, virtual. The relevance is clear, and would be expected by nontechnical readers (though in the new text appearing, the distinction intgr perceives should be explained). But again, find secondary sources. Apart from this museum source (better), this article's sourcing from references in technical manuals (worse!) violates WP guidelines/policies, see below. 73.210.154.39 (talk) 13:30, 10 October 2015 (UTC)

Thanks for your edits to the article! Sorry, I find your talk page posting difficult to follow and I may have misunderstood what you're saying. But let me explain my thinking:

I very well believe that there have been devices that can catch fire from some combination of instructions — I am not refuting that. But this article does not talk about devices catching fire — it's talking about the term "Halt and Catch Fire". That forum page doesn't even mention "Halt and Catch Fire" or "HCF" in any form, so there is no connection from that source to this topic.

As for whether it's a reliable source, see WP:USERGENERATED "self-published media—whether books, newsletters, personal websites, open wikis, blogs, personal pages on social networking sites, Internet forum postings, or tweets—are largely not acceptable. This includes any website whose content is largely user-generated"

If you disagree, please offer some policy-based argument why it should be reliable and describe the connection from that forum posting to the "Halt and Catch Fire" subject.

The solution to a badly source article isn't adding more bad sources. Sometimes WP:STUBIFYing is the right answer. -- intgr [talk] 15:25, 13 October 2015 (UTC)

Macs can be told to turn off their fans

• Messmer, Ellen (2014-02-26). "RSA security attack demo deep-fries Apple Mac components; at RSA conference, CrowdStrike demonstrates explosive PC/Mac attack". Network World. The cyberattack demonstration "frying the machine" was done by targeting the machine's [an Apple OS X computer] APC embedded controller through a fake firmware update devised by CrowdStrike that spiked the CPU and turned off the fans.

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. 73.210.154.39 (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)

Those old Palms

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 218.108.29.104 (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) 193.63.174.10 (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?

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 (talk • contribs) 19:54, 18 March 2007 (UTC)

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

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)

"..." 193.63.174.10 (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. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.8740&rep=rep1&type=pdf - 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:

ftp://reports.stanford.edu/pub/cstr/reports/csl/tr/86/289/CSL-TR-86-289.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.8740&rep=rep1&type=pdf

http://www.docstoc.com/docs/43286461/MIPS-X-INSTRUCTION-SET-and-PROGRAMMERS-MANUAL

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)

Not encyclopedic

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 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. 73.210.154.39 (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)

80286 opcode 0F 04

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 http:// self.gutenberg.org/articles/eng/X86_instruction_listings and search for 0F 04 --Guy Macon (talk) 18:35, 10 January 2018 (UTC)

I am the author of some of the comments on Talk:X86 instruction listings#Opcode 0F 04 on 80286. My findings (confirmed by others on that talk page) indicate that the instruction is legal and privileged. It's been a while but I'm willing to post the code on Github so other people with old 286 computers and too much time can help crack this puzzle. --DiederikH (talk) 00:44, 30 October 2018 (UTC)

The more published information about these old processors the better. There are important details about how ENIAC and EDVAC worked that are already lost to history. --Guy Macon (talk) 04:53, 30 October 2018 (UTC)

Z80: Accurate?

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? --132.199.99.50 (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)

But that shouldn't count as HCF, since that is perfectly normal operation and what you would expect. In fact, a similar instruction sequence (CLI/HLT for the x86, for instance) would do much the same: Hang the processor in place (barring NMI's and SMI's); as would CLI followed by a jump to self, or similar. The point is that there are numerous ways of freezing a processor, all of them perfectly legal according to the documentation. It's only an HCF if that behaviour results from an instruction sequence, which, according to the documentation, should do nothing of the sort; or, in modern processors, if such freezing can be instigated from unprivileged code (by whatever means). — Preceding unsigned comment added by 79.168.82.183 (talk) 07:15, 5 December 2018 (UTC)

Previous Article

So, what I read here years ago, about how some early system - maybe IBM 360 or earlier - having a "Halt" instruction that was actually "Jump To Self" which executed repeatedly and could theoretically/humorously "catch fire" by overloading the CPU, was just junk? If it was even passingly valid - even just the part about "jump to self" - it should still be included. 75.105.30.170 (talk) 06:55, 12 January 2020 (UTC)

Got a source for that? See WP:V. --Guy Macon (talk) 10:08, 12 January 2020 (UTC)

My source would have been this page, except that part is gone now. What was the source for it when it was here? I can't tell which "version" or "change" it was, on the history page. 75.105.30.170 (talk) 00:29, 13 January 2020 (UTC)

So, what was the source of that part when it was present? If it came from personal experience of some engineer, which is no longer considered adequate for wiki, that's a problem. Especially following your comment "There are important details about how ENIAC and EDVAC worked that are already lost to history." Very little of that was likely published, which seems to mean that you would no longer accept such details even if presented. And makes me wonder if maybe my donation last year was a mistake. 75.105.30.170 (talk) 01:15, 16 January 2020 (UTC)

We cannot evaluate that previous version if we cannot see it. You can go to the page history and try to find it. You might, for example, check the page as of January of every year from when it was created in 2003 and see if you can find it. Once we have the name of a specific mainframe we can search for citations. We do want to include info on any old mainframes that had something similar to halt and catch fire, but it needs to be verifiable.

Finally, your donation comment is not going to get you anywhere. Your donations went to the Wikimedia Foundation (WMF), which has zero say over the content of Wikipedia other than things that are actually illegal. Wikipedia content is 100% from unpaid volunteers. The relationship between the volunteers and the WMF ranges from working together on some things while eying each other warily to the occasional civil war. Nobody reading this gives a rat's ass whether you donate to the WMF. --Guy Macon (talk) 14:18, 16 January 2020 (UTC)

I see it here https://en.wikipedia.org/w/index.php?title=Halt_and_Catch_Fire&diff=928362137&oldid=818263799 at the bottom of the notations on the left side (at least as I see it) under === In early CPUs === I'm not even a volunteer contributor and don't really know how to find exactly where and when it was removed. But it kinda looks like there are supporting citations. 75.105.30.170 (talk) 06:27, 18 January 2020 (UTC)

Thanks! Good detective work. the article used to say:

In early CPUs

One apocryphal story about the HCF instruction in an actual early CPU goes back to the late 1960s, when computers used magnetic core memory. The story goes that in order to speed up the core memory on their next model the engineers increased the read/write currents in the very fine wires that were threaded through the cores. This worked fine when the computer was executing normal programs, since memory accesses were spread throughout memory. However, the HALT instruction was implemented as a "Jump to self". This meant that the same core memory location was repeatedly accessed, and the very fine wires became so hot that they started to smoke—hence the instruction was labeled "Halt and Catch Fire".

References

Looking at that citation, the only relevant section involving core is this:

From: rick@oresoft.UUCP (Rick Lahrson)

Message-ID: <37@oresoft.UUCP>

Date: Mon, 25-May-87 02:52:46 EDT

Organization: Oregon Software, Portland OR

A small step was taken toward this end back in the early sixties, in IBM's System/360 model 30 CE school. Seems one of the better students had time enough to pore over the schematics and discover which cores (remember core memory?) were located just beneath the overtemp sensor. He wrote a small program that did nothing but abuse those particular cores by writing ones and zeroes alternately to them, until they heated up, and the temperature sensor shut down the machine.

First, of course, the program printed out "Programmed Power Down" on the console. Caused a lot of bewilderment among the students and instructors. Especially since the big feature being touted about the S/360 was that it was so oriented to multiprogramming that it didn't even have a HALT instruction.

Now all we have to do is find a better source than someone telling a story on USENET in 1987. --Guy Macon (talk) 09:29, 18 January 2020 (UTC)

As noted earlier in the comment I quoted "The more published information about these old processors the better. There are important details about how ENIAC and EDVAC worked that are already lost to history. --Guy Macon (talk) 04:53, 30 October 2018 (UTC)" some of this stuff is not going to be found anywhere else but in stories told by people who were there. Expecting that anything to be put in Wikipedia must have been published somewhere else first, seems very unrealistic especially for "prehistoric" things like this. Where else do you expect to find "important details about how ENIAC and EDVAC worked," just for one example? I don't mind if such items are described as "(possibly) apocryphal" but that's not a good reason to exclude such details when no other source or verification might ever be possible. And much more recent examples are possible too. I programmed Qantel (NOT Quantel) computers for years, and I doubt any published "authoritative" sources are available for those systems either. Even though those systems existed in the 70s and 80s, everything seems to have disappeared and people like me could be the only source of information you'll ever find on them. That is, if anyone ever wanted to put together a good article on Qantel. 75.105.30.170 (talk) 05:47, 19 January 2020 (UTC)

By the way, I would be happy to provide a great deal of information about those Qantel systems, including how they were programmed, if anyone wanted to put together a thorough article on them. But I'm not really familiar enough with how wiki formatting works (nor am I particularly interested in learning how), to do it myself. 75.105.30.170 (talk) 05:54, 19 January 2020 (UTC)

Expecting that anything to be put in Wikipedia must have been published somewhere else first may seem unrealistic to you, but that's how we do things, and we are not going to change. I also have a lot of knowledge that would be make for interesting additions to various articles (I was on the engineering team that created the first plug-compatible 30-30 Winchester hard drive) but none of that knowledge is usable on Wikipedia. Our policies at WP:V and WP:OR explain why. --Guy Macon (talk) 07:08, 19 January 2020 (UTC)

I thought Wikipedia was supposed to be more than just an aggregator of other sources. What a shame. 75.105.30.170 (talk) 10:48, 19 January 2020 (UTC)

Oh and that goes back to my earlier comment too about donation. It wasn't some kind of threat, the point was that if Wikipedia only had information that already exists elsewhere, then nobody really needs Wikipedia. All they need is google search. And it's also inexplicably naïve to rely on other "published" sources that can - and do - disappear over time. The internet is not really forever, although many people seem to think so. Nothing exists online that isn't hosted by someone. And if that someone goes away or just changes what they host, well then guess what, all their 'published' material is gone too. Including what you link to. I find that all the time. The remaining mystery is why nobody goes through and removes all the stuff that is no longer 'published' elsewhere. If that's really your standard, then someone - probably a lot of someones - need to be doing that. 75.105.30.170 (talk) 10:51, 21 January 2020 (UTC)

This is getting off the topic of improving the Halt and Catch Fire Wikipedia page, so I will make this my last comment.

You have shown zero understanding of the differences between an encyclopedia, and aggregator, and a search engine. Wikipedia is not "just an aggregator of other sources". We reject most sources as failing WP:RS. Nor is Wikipedia dependent on online sources. Many of our sources are in published books and scientific journals. Nor is Wikipedia dependent on online sources staying online. As soon as we cite an online source the Internet Archive saves the web page we cite, and if it ever goes offline we simply change the link to the archived version. And if you had bothered to find out how, you would have tagged those dead links you ran into with template:deadlink. Nor is Wikipedia a search engine. We don't present a bunch of indiscriminate information the way Google does.

Here are some links in case you wish to correct your ignorance concerning what Wikipedia is and does:

You are not the first person who makes nine edits to Wikipedia, mostly withing a ten day period, then confidently lectures someone who has been here fourteen years and who has made 50,000 edits about how Wikipedia is doing everything wrong. And you won't be the last. If you think you can do a better job of running an online encyclopedia, go ahead. We will allow you to use the same wiki software we use for free, and you have permission to copy any and all Wikipedia articles to give your new encyclopedia a good start. See [1] for instructions. Until you prove that you can do a better job of running an online encyclopedia than we can, nobody cares what you think about how we do things. --Guy Macon (talk) 14:15, 21 January 2020 (UTC)

If one is interested of saving computer lore that isn't in violation of copyright or commercial agreements, Internet Archive seems to be a site that hosts such things. If IA isn't interested, there may be other websites that would be interested in hosting whatever 75.105.30.170 wants to save. Dhtwiki (talk) 00:56, 22 January 2020 (UTC)

TIS-100 spoilers

I think the reference to the game TIS-100 under the subsection Assembly language mnemonics should be reworded. As it is, it states that the hidden opcode is HCF. This can be seen as a spoiler to the game, since running this hidden opcode is one of its achievements. Perhaps it could be reworded to simply say the game has an achievement called HALT_AND_CATCH_FIRE that requires the player to "Crash the TIS-100 with the hidden opcode", per the achievements page.

I had never heard of opcodes before playing the game myself. And as I went through the wiki pages on it, I just stumbled across the puzzle's solution. Also, I am new to Wikipedia editing, so I'm not sure what should I do. Then I decided to post here first intead of just editing the main article. Hope someone sees this =)

Dashiell Qwerty (talk) 00:14, 29 April 2021 (UTC)

Dashiell Qwerty, see WP:SPOILER ~Kvng (talk) 16:02, 1 May 2021 (UTC)

Hi Kvng. I've been severely ill for the past weeks. Sorry for not replying sooner. Also, thank you for indicating WP:SPOILER. I've read lots of those pages, but I still feel overwhelmed by the sheer amount of them.

Coming back to the discussion on topic, I still feel like the page should be edited. As said in the guideline page, "spoilers" shouldn't be ommited when it's relevant for an encyclopedia page. However, I don't think the specfic piece of information "HCF is a hidden opcode in the game TIS-100" is relevant to the Halt and Catch Fire page. Rather, I'd argue that the game allusion to Halt and Catch Fire is relevant to the article. So the setence could be reworded to say: "In TIS-100, a 2015 puzzle video game made by Zachtronics, there is an achievement called HALT_AND_CATCH_FIRE for crashing the machine with a hidden opcode." And the following page could be used as a source, since the statement in the article doesn't give any: https://steamcommunity.com/stats/370360/achievements

I also realized that the name of the game studio is outdated. It goes by only Zachtronics nowadays, or Zachtronics LLC. I'm sorry to say I couldn't find a source for when the name was changed yet, so I don't know if the name still was Zachtronics Industries back then. Off-topic, but hey it's really fun to get involved in a collaborative effort. I just want to make clear that this is my interpretation of the guidelines, but perhaps I am misguided. I'm still getting used to this. Dashiell Qwerty (talk) 14:28, 11 May 2021 (UTC)

Dashiell Qwerty, I'm glad you're feeling better. Those changes don't seem controversial. Feel free to make them and we'll see how it looks. ~Kvng (talk) 15:33, 11 May 2021 (UTC)