14

This question... Can a USR command damage a ZX Spectrum? ... has leaded me to wonder if there was once a microcomputer that could actually be damaged by software.

More specifically:

Is there a case that a microcomputer, using its default shipped hardware configuration (i.e. no added interfaces and the like), could be permanently damaged (requiring service to return to working order) just by writting a program and letting it execute it?

I'm not talking about damage to elements connected to it (such as the monitor, a disk drive or a printer), but to the computer itself.

  • Could have sworn this has been asked before but I can't find it. Perhaps it was closed as too broad... Actually, come to think of it, I think I might have wanted to ask the question and then decided not to. Oh, my brain. – Muzer Feb 7 '17 at 9:48
  • 1
    A story, read on the interactive help system of Turbo C, comes to my mind: /* Emits a 7-Hz tone for 10 seconds. True story: 7 Hz is the resonant frequency of a chicken's skull cavity. This was determined empirically in Australia, where a new factory generating 7-Hz tones was located too close to a chicken ranch: When the factory started up, all the chickens died. Your PC may not be able to emit a 7-Hz tone. */ int main(void) { sound(7); delay(10000); nosound(); return 0; } – mcleod_ideafix Feb 8 '17 at 0:08
  • 1
    IIRC, Amiga could damage some analog monitors through setting wrong beam timings and drawing outside the screen area - essentially sending the electron beam into circuitry. – SF. Feb 8 '17 at 8:54
  • 1
    "Sending the electron beam into circuitry" Whaaaaat? Are you serious? – mcleod_ideafix Feb 8 '17 at 9:27
  • 1
    This sort of legend is where we get the legendary "HCF" (Halt and Catch Fire) assembler opcode, a cousin of the similarly legendary "FSM" (Fold, Spindle, Mutilate) opcode. – Columbia says Reinstate Monica Feb 26 '17 at 2:49

12 Answers 12

18

This was, and often still is, a deliberate design feature of safety critical computers.

The Harmon VHLC, which is a 80186-based solid state interlocking used for railway signalling has been around since the late 1980s. Its two CPUs cross-check each other every 39ms to make sure that they are at the same point in the program and agree on the value of certain key registers. If one processor decides that the other processor is misbehaving, it can write to a memory mapped I/O address that switches 110V into the 5V input. This is a deliberate ploy to kill the misbehaving processor so that the system fails safe.

This technique of multiple processors cross-checking each other is common practice if designing to Safety Integrity Level 4, as defined by CENELEC.

  • 4
    That logic escapes me a bit - Why would frying the main board with a 110V relay that needs to work properly be any safer than simply switching the power off? I know the part with cross-checking CPUs in safety-critical systems, but the "110V-part" has a strong smell of urban legend (no offense intended) – tofro Feb 7 '17 at 9:29
  • 3
    @tofro, it isn't an urban legend, I wrote software for that machine. I agree it was a bit violent. More modern systems tend to be 2oo3 rather than 2oo2 and will deliberately trip a fuse on the rogue processor. – Chenmunka Feb 7 '17 at 9:47
  • 3
    @tofro: You disconnected the 110V so that it wouldn't actually fry, then pulled down one of the I/O points on one of the backplanes so that one of the processors took a different branch. You heard a relay click and got an appropriate message in the log file. – Chenmunka Feb 7 '17 at 11:01
  • 5
    Wow, amazing. This kind of behaviour is inconceivable in avionics. Computers cross-check their outputs, eventually disengage when disagreeing, but deliberately putting a component into a non predictable state (will it burn, emit flames, corrosive vapours, propagate the 110V to some outputs and make a chain reaction ?) is unheard. – TEMLIB Feb 7 '17 at 22:28
  • 4
    I am struggling to work out how a given processor knows that it isn't the misbehaving one. That could have very disastrous consequences. – wizzwizz4 Mar 5 '17 at 19:08
9

My teacher asked me the question back when I was in college. My answer was to write in assembly a simple command that asked the hard drive arm to read well beyond what it was allowed. This caused the hardware to burn out making the hard drive inoperable. Hard drives now have a safety precaution built in to avoid this scenario.

  • 2
    Welcome to Retrocomputing! Hope you stick around and continue to share your knowledge. – JAL Feb 10 '17 at 21:44
  • The OP did specifically exclude peripherals such as a "disk drive" in the question. Also, I find it hard to believe that even a primitive disk drive would be so dumb as to try to move the arm sufficiently to physically burn out hardware. (Compare how to actually detect whether a floppy disk drive on an IBM PC is 40 or 80 tracks: go in and out 50 or so tracks, and see if you hit the physical stop.) – a CVn Mar 11 '17 at 14:10
  • This answer would be much improved if you can provide some kind of citation for your claim that this was possible, and state an architecture or platform on which it was possible. As it stands, this really sounds like nothing more than what you thought up in school with no clear basis for it being true. – a CVn Mar 11 '17 at 14:12
  • 1
    @MichaelKjörling the Commodore 1540/1 has only one physical limit on the drive head stepping out of range: it rams against a piece of plastic. That's why they make that aggressive clicking noise when there's any sort of disk error — there's also no track zero detection so it's making absolutely sure it's at track zero without trusting what's on the disk. It's also why so many of them quickly develop head alignment issues. This is alluded to e.g. in vintagecomputer.net/commodore/… on the second page of content. – Tommy Mar 12 '17 at 23:12
  • 1
    If you asked the old stepper motor hard drives to seek a cylinder beyond what they were capable, you could make them continually reset and bang the arm against the stop until it broke. With the advent of voice coil drives that no longer was an issue. – Brian Knoblauch Jul 11 '17 at 16:03
8

It's not particularly "retro", but many x86 computers in the early Pentium IV era could be permanently damaged in a matter of weeks by setting the operating voltage and frequency too high. This would cause the CPU to run hot and literally cook itself.

Earlier computers used jumpers rather than software controls for these settings, and later computers had better safeguards and thermal management.

  • This doesn't remotely qualify under the terms of the OP but, when I was at college, we had to build a microcomputer with a Z80, some breadboard and lots of wire. One group plugged their EPROM in the wrong way around and it started glowing (you could see the silicon through a transparent window) when they applied power. Another group plugged their Z80 in the wrong way round. A small piece of the plastic packaging hit the ceiling when they applied power. – JeremyP Mar 13 '17 at 10:41
  • @Jeremy Though that is a result of a soft brain in control, not software in control... – rackandboneman Jul 17 '17 at 0:20
7

Certain models of the Commodore PET had a Killer Poke.

If you poked a particular value to a particular location, then the video circuit would damage the integrated CRT.

  • 1
    Hmm. Peripheral devices were explicitly excluded. – tofro Feb 7 '17 at 6:14
  • PC's could do the same: just switching to a video mode the CRT is not display capable caused all sort of suspicious and presumed dangerous noises in it. I'm asking about damaging the computer itself (the logic board) – mcleod_ideafix Feb 7 '17 at 6:41
  • 6
    @tofro I guessed that the CRT in a Commodore PET didn't really count as a peripheral since it's built in to the machine itself. – Wilson Feb 7 '17 at 10:37
  • Now, the CRT is definitely not the logic board as poninted out above by original poster – tofro Feb 7 '17 at 10:53
  • 3
    It had a better Killer Poke. Toggling a certain location between 0 and 1 repeatedly in a loop would switch power to its tape recorder on and off, with a brief surge which normally would be entirely harmless - but due to the process repeating hundreds of times per second, a triac responsible for that would overheat and the computer could catch fire! – SF. Feb 8 '17 at 8:49
4

You could kill the BBC Micro's cassette relay (and those of many other computers with cassette relays) by writing code to toggle them in a tight loop.

  • Ditto the Electron. But that didn't stop some games using quick switches of the cassette relay as an extra sound effect. – Tommy Mar 12 '17 at 23:16
4

Some retro computers such as the ZX Spectrum and Amstrad CPC did not fully decode I/O addresses. Instead they used a single address line to select each I/O chip, so it was possible (by using an invalid I/O address) to enable two or more chips at the same time. If the two chips are putting different data on the bus then they are shorting each other out, which could damage their bus drivers.

Amstrad CPC I/O devices enter image description here

  • Does the short circuit actually damages the computer? It happens for a very short period of time (less than a microsecond) and if the drivers colliding are NMOS devices, the short circuit does not damage them. – mcleod_ideafix Mar 11 '17 at 12:02
  • I wasn't brave enough to find out (back then computers were expensive, and who would want to deliberately destroy their pride and joy?). It only happens for a 'very short time' but in a tight loop (eg. INIR) the duty cycle may be significant. If both devices are NMOS then it's probably OK. However these computers had expansion buses that took third-party expansions, some of which used high current bus drivers (eg. Kemston joystick interface). It's probably more of a concern for modern DIYers who are working on these retro machines. – Bruce Abbott Mar 11 '17 at 16:42
  • My original question states "default configuration, without any added devices", so if the CPC has NMOS chips inside it, it shouldn't be of any harm. – mcleod_ideafix Mar 12 '17 at 14:52
  • DMA controllers and all the way you could misconfigure them are probably worth looking at... – rackandboneman Jul 17 '17 at 0:23
3

As I explained in my answer to Can removing a cartridge from an NES (or any other cartridge-based game system) damage the hardware or software?, the NES can be damaged by software.

The 2CO2 PPU in the NES normally reads the background color from palette index 0, but this isn't hard-wired into the chip -- it actually reads the palette index of the background from four EXT pins. These pins are grounded on the NES, forcing the palette index to 0, but an arcade board using the 2CO2 or a similar chip could connect these pins to another PPU.

Bit 6 of PPUCTRL selects whether the PPU should run in master or slave mode. If the PPU is in master mode, it reads the palette index from the EXT pins as explained above, but in slave mode, it outputs the palette indices it is currently drawing to the EXT pins.

This way, the images from two PPUs can be layered. The slave PPU draws one image, and the master draws another image on top of that and outputs the combined images.*

The NES didn't use that feature, but the hardware still exists in the PPU. If the PPU is set to slave mode, it will attempt to output the background palette index to the EXT pins. If it outputs a 1 to any of these pins, it will cause a short from Vcc, through the PPU, and to ground (because the EXT pins are grounded), possibly damaging the PPU.


*: The image generated by the slave PPU can only use colors from the background palette of the main PPU because there are only 4 EXT pins, not 5.

  • But would it be exactly a short? Isn't there some kind of a pull-up resistor preventing a literal short-circuit? – DmytroL Feb 18 '17 at 11:45
  • @DmytroL Nope; the pin goes directly to ground and the PPU connects it directly to 5V. – NobodyNada - Reinstate Monica Feb 18 '17 at 15:29
  • Sounds like a typical case of "that component [resistor] costs $0.0003 apiece in large quantities; do we really need it?". – a CVn Mar 11 '17 at 14:15
2

Borderline case: In the 8086/80286 it was possible to set values under software control that would damage, beyond use, the video adapter. Not, technically, "the computer itself", yet not connected to it like a printer, monitor, etc. I don't know if it was possible at levels higher than Assembly or not, but at that level it was possible. Also, IIRC, it was only possible with the VGA and higher boards, not with the MDA and CGA boards. How Intel solved it I don't know, but when I tried to do the same on and 80386 it failed to work.

  • I suspect that if what you say is true, then it had less to do with the CPU and more to do with the specifics of the video board. Remember that VGA introduced an analog output signal (MDA, CGA, EGA were all digital to the monitor); driving the DAC outside of its design limits could probably be interesting. A cheap video board might not cater to that case, expecting that everyone plays by the rules... – a CVn Mar 11 '17 at 14:18
  • That's why I only called it a "borderline" case. It's the only example I have personal knowledge of that came close to what the OP asked. – Gypsy Spellweaver Mar 11 '17 at 21:46
  • Probably more like setting registers in a way that cause a bus conflict as described above. – rackandboneman Jul 24 '17 at 22:10
2

Damaging the computer itself is hard to imagine, but damaging peripherals is much easier. Back in the early days of Linux (94-95), configuring the X11 server (that put graphics on the screen) required you to define video modes by specifying them in terms of clock rates listed in a text based configuration file. Unfortunately, this was not at all intuitive, and you ran the risk of damaging at least some monitors that didn't have adequate internal safeguards. This resulted in the XFree86 HOWTO having this friendly bit of language as a disclaimer (Emphasis mine):

You shouldn't use monitor timing values or ModeLine values for monitors other than the model that you own. If you attempt to drive the monitor at a frequency for which it was not designed, you can damage or even destroy it.

-- http://web.mit.edu/linux/redhat/redhat-4.0.0/i386/doc/HTML/ldp/XFree86-HOWTO-4.html

At the time I first set this up, I was a full time college student that'd just spent around $1,200 on a then state-of-the art Sony 17 inch monitor (GDM-17SE1).

Starting up X11 for the first time was more than a bit nerve wracking.

(Edit: One additional bit of damage you could do wasn't hardware... but you could make the argument that it's worse. When Microsoft first introduced write buffering to the smartdrv disk cache, it would sometimes defer writes for longer than it probably should have... including to file location metadata. Combine this with the lack of memory protection, and it should not be a surprise that at least one errant memory write from software I was developing crashed the system before the cache was flushed and corrupted virtually the entire contents of the disk.)

  • 1
    I fried a Hercules monochrome monitor, attached to a PC. I had written a "boss key" type screen saver program--purely as an exercise, of course--and a bug caused it to set the video controller's registers incorrectly. The screen looked "real funny" for a second, then the image contracted to a point and the monitor's magic smoke made a little "pop" noise as it escaped. – Wayne Conrad Jul 20 '17 at 18:52
2

Maybe what you're looking for is the semi-mythological halt-and-catch-fire instruction?

Several of the Motorola processors had an instruction or two that put the CPU itself into a HALT state, but cycled the address lines from 0 to 65535 endlessly. This was great for testing, since you could check for address decode errors and such quite easily.

The only way out was hard reset or cycling power.

These were jokingly called "HCF" by some engineers, but, of course, it would take a poorly designed bit of hardware to actually be damaged permanently by it.

The wikipedia page

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

has a little bit more on the subject of invalid op codes putting the CPU into a state requiring power cycling or hard reset. It mentions one possible (apocryphal) scenario in the pre-microprocessor world, of a magnetic core design that might burn the control lines.

Thinking of the sort of things a hobbiest might build, one could imagine something like improperly designed dynamic RAM circuits or even data buffers with too much loading that could be burned out by a CPU's HALT state. But I think hobby projects don't count for this question.

1

A straight, simple CPU and memory arrangement of a (sufficiently simple) computer is made to start from a reproducible state after RESET into the next deterministic state.

Permanent damage requires permanent storage or the ability to change something permanently in a computer through the ability to control external circuitry - and early home computers didn't have such luxury items. Even if you might (theoretically) be able to drive the same bus line from two devices to a conflicting state (which would be the closest to being able to damage anything), this is not very probable to really cause permanent damage to TTL and early CMOS chips - Early electronics can stand such a strain for quite some time, most even forever.

When more modern devices started to have EEPROM or Flash memory that could be permanently changed to store configuration data or have upgradable firmware, it became easier to permanently brick them. But I would deliberately exclude such devices here.

  • Any chip that you can overheat - for example, the bus collision scenario above - can be turned into a fusible PROM. – rackandboneman Jul 16 '17 at 23:13
  • Some common TTL bus drivers are quite low impedance - and 8 to a package... that could conceivably overheat quite badly in a collision scenario. – rackandboneman Jul 24 '17 at 22:17
1

If it's not too much of a stretch, to add to the "over-exercising the drive" examples, per one of the developers of Crash Bandicoot for the original Playstation:

Kelly is a smart guy, and a good game critic, but he had a lot more to worry about than just gameplay. For example, whether Crash was physically good for the hardware!

Andy had given Kelly a rough idea of how we were getting so much detail through the system: spooling. Kelly asked Andy if he understood correctly that any move forward or backward in a level entailed loading in new data, a CD “hit.” Andy proudly stated that indeed it did. Kelly asked how many of these CD hits Andy thought a gamer that finished Crash would have. Andy did some thinking and off the top of his head said “Roughly 120,000.” Kelly became very silent for a moment and then quietly mumbled “the PlayStation CD drive is ‘rated’ for 70,000.”

Kelly thought some more and said “let’s not mention that to anyone” and went back to get Sony on board with Crash.

So I think it doesn't hit the definition of a retro computer, but on the Playstation not only could a sequence of instructions damage the hardware, but one of the best-selling pieces of software was knowingly likely to do so.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.