Talk:Halt and Catch Fire
|This is the talk page for discussing improvements to the Halt and Catch Fire article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing||(Rated Start-class)|
|The following references may be useful when improving this article in the future:
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 188.8.131.52 (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) 184.108.40.206 (talk) 13:46, 14 October 2009 (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.
- 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)
- 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)
- 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
- "..." 220.127.116.11 (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:
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
- 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. 18.104.22.168 (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)
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. 22.214.171.124 (talk) 13:13, 10 October 2015 (UTC)
"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.
- 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.
- 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
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)