20

The question 'Can a USR command damage a ZX Spectrum?' has led 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 writing 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
  • 2
    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
  • 3
    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. – Robert Columbia Feb 26 '17 at 2:49

17 Answers 17

27

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.

| improve this answer | |
  • 9
    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
  • 4
    @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
  • 4
    @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
  • 7
    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
  • 11
    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
13

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.

| improve this answer | |
  • 1
    Hmm. Peripheral devices were explicitly excluded. – tofro Feb 7 '17 at 6:14
  • 8
    @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. – OmarL Feb 7 '17 at 10:37
  • 1
    @wilson My suggestion is keep it. I had a half-memory about software damaging the CRT on a C= Pet, and your answer confirmed it. So it did add to the general gist of what Wilson's question is asking. – RichF Feb 8 '17 at 2:36
  • 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
  • 2
    Tech Tangents has a video on the PET Killer POKE which explores its history, what it's doing, electrically, and how it's not as lethal as people make it out to be. – ssokolow Sep 20 at 13:16
11

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.

| improve this answer | |
  • 2
    Welcome to Retrocomputing! Hope you stick around and continue to share your knowledge. – JAL Feb 10 '17 at 21:44
  • 1
    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.) – user 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. – user Mar 11 '17 at 14:12
  • 2
    @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
  • 2
    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
10

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.

| improve this answer | |
  • 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
  • 1
    @Jeremy Though that is a result of a soft brain in control, not software in control... – rackandboneman Jul 17 '17 at 0:20
  • @JeremyP In my very early days I wanted to set up a TTL circuit, but didn't have a 5V power supply, so I used a glass-case silicon diode in series with a 6V lantern battery. I managed to short Vcc to ground, downstream of the diode. That was the day I learned that any diode can be an LED if you give it enough power. – jeffB 9 hours ago
10

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

| improve this answer | |
  • 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
  • This won't cause any damage. The NMOS parts use the equivalent of a pull-up resistor to produce a high level, which is inherently current limited. Lines are only ever driven low. That allows several devices to share a bus without the need for tristate outputs. In other words it happens constantly anyway. – user yesterday
8

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.

| improve this answer | |
  • 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 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?". – user Mar 11 '17 at 14:15
5

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.

| improve this answer | |
  • 2
    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
5

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

| improve this answer | |
  • 5
    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
5

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.

| improve this answer | |
4

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.

| improve this answer | |
  • 2
    Each of Crash Bandicoot's "hits" only moved the head a short distance, if at all, and read a small amount of data at a time, with the disc already spinning at the correct speed. That's much less wearing than a random seek and long read on a CD-ROM. – Chromatix Sep 20 at 12:42
  • 70k seeks seems incredibly low for an optical drive... Then again many early model Playstations did have seek problems later in life, often remedied by turning the console upside down. – user yesterday
4

The original MSX specification requires the AY-3-8910 sound chip to be included as part of the hardware, and indeed many machines (like the Philips VG-8020/00, for example) were built using that chip.

This chip has two 8-bit I/O ports, and the decision of whether a port is an input or an output is made by software. In the MSX, one of the ports is used for input, and the other for output. The input port is used for the joystick and the cassette. If it's configured as output by the software, it's possible to short-circuit one or several of the lines that get to the port, which can lead to permanent damage.

Later machines typically use the Yamaha S3527 chip, which integrates several functions necessary in MSX computers, among them a sound generator compatible with the AY-3-8910. But in this chip, the port direction bit for the joystick/cassette port is not honoured: the port is an input regardless of the setting, therefore this problem does not exist.

This is known as the "unsafe port directions" problem. The openMSX emulator emits a warning when it detects a program that does this.

| improve this answer | |
  • The manual of my MSX said "don't be afraid to experiment, you can't damage your computer by running code alone". LIARS! – Konamiman 2 days ago
4

The PDP-10 (KA-10 model) is a retro-computer but not a retro-micro-computer. But maybe you'll allow it.

A friend in college programmed a few PDP-10 assembly language routines for multi-precision integer arithmetic (aka bignums). He ran it to compute 50000! and Harvey Mudd College's PDP-10 crashed. And wouldn't restart. PDP-10 service was called, they came out, and replaced a burnt-out set of machine registers. Well, that was a coincidence.

He ran it again: same thing happened. The PDP-10 service guy was perturbed: Whatever you were doing, don't do it again! I'm not coming back for this!

The PDP-10 has 16 registers. You can refer to them in the register field of instructions - or you can refer to them as addresses 0..15 in the addressing field of instructions: In other words, the PDP-10 registers are addressable like main memory. And this works throughout the machine: You can jump to address 5 (say) and start executing instructions out of the registers.

But the registers were transistors - not core memory - and thus it was much faster to fetch instructions from registers than main memory. And if you had a tight little loop where you could fit your data and your instructions in registers - it would really fly. Which is the way my friend wrote this code.

But actually, the registers apparently weren't designed for the 100% duty cycle of adding instruction fetches to data read/write. So they could overheat, and burn up, when calculating, say, 50000!.

| improve this answer | |
  • 1
    I can just imagine a junior engineer at Digital raising the issue and being shot down by a senior engineer saying something like, "nobody would ever do that." – snips-n-snails Sep 21 at 5:59
2

I don't suppose an IBM System 370/145 counts as a microprocessor, but let me tell you the story anyway as best I remember it. In 1975 or so, Boston University was running a home-grown operating system on its System 370. It had the typical mainframe peripherals of the day, including disks, tape drives, card reader, card punch, and a line printer, all in a raised-floor machine room. The line printer could be commanded (using privileged I/O instructions) to open its cover so the operator could load more fan-fold paper or change the print ribbon. My housemates and I were students, and one of us (Lew Nathan) made a bet with one of the OS developers that he could write a user-mode program to get the line printer to open. The program he wrote was a loop that repeatedly printed a full line of underscore characters followed by a carriage return WITHOUT a line feed. So a full line across was printed endlessly at the same spot on the paper. Lew's intention was to cut the paper in half, which the printer would sense, and would respond to by sounding an alarm and opening so it could be reloaded. What actually happened was that he also shredded the ribbon, so when the printer opened a cloud of (electrically conductive?) ink-coated ribbon shreds were wafted into the air and settled everywhere, including being drawn into the processor by the cooling fans. That shut down the computing center until everything could be cleaned. So that's a user-mode program that damaged the processor (admittedly by means of a peripheral). Sorry I can't do better.

| improve this answer | |
New contributor
Tim Leonard is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • It's weird that the ribbon was not continuously moved to even out the wear. – Leo B. yesterday
1

The IBM 1620 is a retro-computer but not a retro-micro-computer. But maybe you'll allow it.

You could get it with a hard disk drive - one of those washing machine-sized cabinets that had replaceable multi-platter disks. Here's a picture in a wikipedia article - note that the disk pack on top weighed 10 pounds and rotated at 1500rpm, and had 14" metal platters. So you can imagine how big the multi-platter read head was - and how fast it had to move (light as it was), and also how much mass and momentum was involved in that spinning disk at the top of the cabinet.

Anyway, there was a thick multi-wire cable attaching the drive to the main computer cabinet. And in the installation I was familiar with - at the local junior college (Pierce Jr College) in Los Angeles - the drive wasn't "embedded" into a raised floor - it was just sitting on it's 4 little legs and the cable went under one of those plastic tunnels.

So the guys hanging around the computer lab were friendly to high schoolers and would show them stuff if they were curious. Like me. And one day they showed me a single-card program that sent the drive head back and forth from cylinder to cylinder in a narrowing sequence, e.g., 0 - 99 - 0 - 99 - 0 - 99 - 1 - 98 - 1 - 98 - 1 - 98 - 2 - 97 - ...

After a bit of this the drive would start to vibrate a bit, then start vibrating like an unbalanced washing machine, then it would really start to go ... you'd found the resonant frequency where the heads bashing back and forth would interact with the entire device.

And then you'd flip one of the console switches on the 1620 and the program would just start seeking between the two last tracks - ... - 32 - 68 - 32 - 68 - 32 - 68 - ....

And the drive would start walking across the floor, dragging its cable behind it.

Now, I didn't see it, but they told me that one time they let it go so far that it pulled its own cable out of the plug. Stopping it, of course.

Does that count as "damaging" the machine?

| improve this answer | |
  • 2
    Re, "walking across the floor,..." Until it bumped up against my desk at one place where I worked as a summer intern. There was a naively written accounting program that they ran once each week. The job took about two hours and it made the drive shake like an earthquake. I got permission from the boss to re-write the program, allocated as much memory as I could grab for buffers, cut the run-time down to about ten minutes, and for the rest of the summer, I was able to fill out my FORTRAN coding forms in peace. – Solomon Slow 2 days ago
0

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.

| improve this answer | |
  • 1
    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
0

I'm pretty sure that floppy drive "music" (using low level head/motor instructions to create noises/frequencies and play music) isn't very good for a computer internal floppy disk.

(For instance https://www.youtube.com/watch?v=-NYbd5AcwPY, A500 playing a star wars theme)

When you operate a floppy disk normally, you read a track, then step, then read ... and the drive wear is real, but slow.

With those kinds of hacks the drive wear/heating is much faster. Let's imagine a virus waiting you to leave your computer inattended (by scanning the keyboard/mouse/joystick) to trigger a massive step/motor operation that lasts until you notice it, it could damage the drive/accelerate the normal drive wear tenfold or more. And if the drive is an internal one, the replacement is more complicated.

(I've heard rumours of Atari ST overheating and catching fire because of such code but was unable to confirm it, maybe it was just a hoax spread by Amigans :))

| improve this answer | |
0

This is outside of boundaries but: one of the storage manufacturers (EMC ?) had special firmware in their drives which allowed the storage controller to replace the same firmware (ie easy upgrades/fixes of faulty firmware.)

Which basically allows an intruder to brick all the drives at the same time...

| improve this answer | |

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.