38

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.

TonyM
  • 3,704
  • 1
  • 19
  • 31
mcleod_ideafix
  • 18,784
  • 2
  • 70
  • 102
  • 2
    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 07 '17 at 09:48
  • Possibly a duplicate: http://retrocomputing.stackexchange.com/questions/1874/can-a-pet-2001-be-physically-damaged-from-basic – cbmeeks Feb 07 '17 at 13:37
  • I wonder if the inverse is possible. Which unsuspecting computer could permanently damage its users, for example by emitting earth shattering sounds? We all know that computers actively try to turn users insane, but I'm excluding psychological warfare. – Grabul Feb 07 '17 at 22:34
  • 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 08 '17 at 00: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 08 '17 at 08:54
  • 1
    "Sending the electron beam into circuitry" Whaaaaat? Are you serious? – mcleod_ideafix Feb 08 '17 at 09:27
  • I heard a story once, which at the time I took as first-hand knowledge of the events, of someone "terminating" an old PDP-8 (it had been taken out of service and was to be scrapped, IIRC) using a "halt and catch fire" loop, and the story teller claimed this actually caused some wire-wrap wires on the backplane to over-heat, thus burning their insulation. But, this was of course a mini-computer, not a micro-computer. – Greg A. Woods Feb 16 '17 at 19:05
  • 7
    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 02:49
  • @RobertColumbia Isn't FSM to HCF as GOTO is to COMEFROM? – user Jul 13 '17 at 19:21
  • @mcleod_ideafix rumour has it that some projection CRTs could suffer even more severe damage than burn spots if you stopped the deflection circuitry. Vector displays (or oscilloscopes) quickly suffer phosphor damage if a static spot is displayed at full brightness. Obviously, that mostly applies to professional equipment (70s graphics terminals) when it comes to anything under software control. – rackandboneman Jul 17 '17 at 00:17
  • Is "make the program tell the user do something not obviously unsafe, but actually deleterious, to the hardware" - eg plugging a parallel printer into a DB-25 SCSI port - on topic? – rackandboneman Jul 17 '17 at 00:22
  • 1
    @mcleod_ideafix The PC timer is not able to generate frequencies below 18.2 Hz. I wonder whether calling "sound(7)" actually caused a divide error when calculating the timer value needed to achieve a 7 Hz tone... – Michael Karcher Sep 21 '20 at 20:09
  • This question has turned out to be a dangerous one: It should probably be re-phrased to "What urban myth is there that talks about destroying a computer purely by software" - because that is what a lot of the answers seem to relate to. – tofro Mar 17 '22 at 17:08
  • I presume you are excluding products that are designed with that in mind as a feature - specifically military hardware, and hardware associated with financial transactions (ie, key storage and encryption modules for ATMs). Many microcontrollers allow a user to erase their own flash, and lock the flash from further access, either read or write, thus "bricking" the microcontroller and requiring a hardware replacement. – Adam Davis Mar 17 '22 at 17:35

20 Answers20

41

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.

Chenmunka
  • 8,141
  • 3
  • 39
  • 65
  • 21
    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 07 '17 at 09:29
  • 11
    @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 07 '17 at 09:47
  • 1
    How did you test the "fry switch" working properly, then? ;) – tofro Feb 07 '17 at 10:56
  • 10
    @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 07 '17 at 11:01
  • 1
    Google "halt-and-catch-fire" instruction... ISTR a CPU with a built-in destruction circuit. – John U Feb 07 '17 at 12:12
  • 4
    you would fry the bad CPU rather than simply powering it down because that way the bad CPU can never power up again. this way if there's a power failure and the entire system resets, the bad CPU won't end up active again. – Ken Gober Feb 07 '17 at 13:42
  • 18
    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. – Grabul Feb 07 '17 at 22:28
  • 5
    Exactly. As I said, more modern machines trip a fuse - much more gentle but effective. The old way did actually cause a fuse to blow so no propagation of HV. I only ever heard of it happening once in the real world, and that was traced to a lightning strike. – Chenmunka Feb 08 '17 at 08:37
  • 3
    Wow. I've heard of "shoot the other node in the head" configurations before, but that's taking it to the next level. –  Feb 25 '17 at 23:23
  • 28
    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 05 '17 at 19:08
  • 1
    @wizzwizz4 My thoughts entirely. I thought the rule was never have only two, because there is no way to arbitrate between them. – JeremyP Jul 10 '17 at 08:49
  • 4
    There isn't a fuse in the world that will reliably cut a 110V source before the 110V has gotten god-knows-where-you-dont-want-any in that setup - unless, and that is the behaviour I would almost expect, the filtering capacitors act as a single-use voltage clamp :) ... Lore has it that one much used railway signalling software was written by somebody that really loved LSD.... – rackandboneman Jul 16 '17 at 23:09
  • 3
    This is a wonderful and surprising answer. Can you please clarify what got fried? Was it only the misbehaving processor, or both? I can understand both, because in a 2oo2 system I don't know how a processor would be able to know it was the good one. Perhaps having the signal just go dark is the best way to fail, so frying both would make sense. – Wayne Conrad Jul 20 '17 at 18:47
  • 7
    I can't find any supporting material for this claim, and it does seem rather unlikely. As well as causing catastrophic and unpredictable damage to an expensive system, when you only have two CPUs there is no way of knowing which one is malfunctioning and needs frying. Typically you would use 3 CPUs in this kind of situation for that reason. – user Sep 24 '20 at 11:52
  • 5
    While plausible, I'd take this account as a myth. The GE Harmon VHLC system has a single vital logic processor (VLP) per chassis, and communications connections for 2 adjacent VHLC chassis. So the system is meant to run with three units, not two. Further, the vital output relay (VOR) only cuts off power to the VLP that is considered faulty within the group. In fact, the datasheet claims 3,000VRMS isolation between the high voltage and low voltage sides of the unit. While a crowbar mechanism and a shorting relay to high voltage is possible, it's not likely nor reasonable. – Adam Davis Mar 17 '22 at 17:17
  • 4
    Here are two sources for information about failsafe train circuits in general, and specifics about the GE Harmon VHLC system: https://www.transittraining.net/images/uploads/document_previews/PREVIEW_Course_350_Microprocessors_Participant_Guide_FINAL_12.27.2018.pdf and http://122.252.230.113/content/notes/sig/kyoson/6.pdf

    Given that the 5V power line is used to drive the communications between modules and other devices, a short from high voltage to that line would do significantly more than merely kill the one VLP - it would kill the entire switching network, including the backup VLP units.

     – Adam Davis Mar 17 '22 at 17:20
  • IN the case of Stlv 85 ( a swedish constructed now built by Hitachi signal) interlocking, it is composed of two alike processors. The controllers in the yard which is co-located with a switch demands that both processors sends it exactly the same instruction AT the same time - if not the instruction will be ignored. – Stefan Skoglund Mar 19 '22 at 11:38
  • And for the switch motor to continue running the same instruction must arrive from both processors continuously while the switch moves. The switch motor current is switched of in the controller (in other usage of the same switch, there is a cutoff contact directly in the motor.) – Stefan Skoglund Mar 19 '22 at 11:43
  • @wizzwizz4 That's the essence of Byzantine faults - how does any one component of the system know which (if any) of the other components are malfunctioning? This makes for great (if sobering, but also occasionally hilarious) reading: https://c3.ndc.nasa.gov/dashlink/static/media/other/ObservedFailures1.html – Duncan Bayne Jan 14 '24 at 08:00
30

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

davidbak
  • 6,269
  • 1
  • 28
  • 34
  • 11
    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 '20 at 05:59
  • 4
    The technique of executing a performance-critical loop out of the registers was well-known even to us raw undergrads. Mind you, we probably weren't doing it for more than a few jiffies at a time. (KI-10, to be precise) – dave Mar 17 '22 at 21:36
  • @another-dave - I still think the PDP-10 ISA is probably the most beautiful I've ever seen. This feature (addresses 0..15), the indirect bit, the XCT instruction, variable-length byte addressing ... I worked as the night operator for the HMC PDP-10 my junior and senior years in college. It was like my own personal computer between 9PM and 2AM ... – davidbak Mar 17 '22 at 21:53
  • (I also don't get why I racked up 160 rep points on this old answer today. I assume the SO computer will reverse it all tomorrow for someone's fraud or something ...) – davidbak Mar 17 '22 at 22:04
  • 3
    I think it works like this: someone found the question and edited it, bringing it to the top of the pile. The rest of us can't quite remember whether we have already read it, take a look, and maybe find something worthy of a vote or a comment. Which then keeps it at the top of the pile... – dave Mar 18 '22 at 02:06
  • 1
    Re the -10's beauty: How do you feel about KL10-B extended addressing? Maybe it's just because it happened after I no longer used the -10, but that just looks to me like a horrible bag on the side. – dave Mar 18 '22 at 02:09
  • 1
    AC loops - now I recall, you could put 000 020 000 000 (octal) into AC0 from the monitor command line, and then jump to it. This is an unassigned instruction "Z @0" in address 0. This would pointlessly burn up 30 (?) seconds of CPU time trying to compute the effective address. The KI never caught fire :-) – dave Mar 18 '22 at 17:32
  • The DEC PDP-11/05 (also badged as PDP-11/10) could also execute code out of the processor's registers. In theory the inbuilt CRT display of the DEC GT40 (which was based on the PDP-11/05) could have had an image burnt into the CRT. I don't know of any attempts to deliberately damage the CRT in this fashion. It was possible to exercise disk drives to death. Had to warm up a drive to do a head alignment. Left a drive running a warm up exercise over the morning tea break then had to replace all the cooked drive transistors which were TO-3 packages on a PCB. Least it wasn't the site alignment pack – PDP11 Jan 17 '24 at 06:21
19

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.

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274
  • 3
    Hmm. Peripheral devices were explicitly excluded. – tofro Feb 07 '17 at 06: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 07 '17 at 06:41
  • 16
    @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. – Omar and Lorraine Feb 07 '17 at 10:37
  • Now, the CRT is definitely not the logic board as poninted out above by original poster – tofro Feb 07 '17 at 10:53
  • Fair point. Should I delete my answer? – Omar and Lorraine Feb 07 '17 at 14:26
  • 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 08 '17 at 02:36
  • 5
    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 08 '17 at 08:49
  • The CRT in a PET was part of the main computer. If over exercising an internal hard drive counts, so does the killer poke. – JeremyP Mar 06 '17 at 16:47
  • I guess if we allow the PET then there's an argument for the Amstrad CPC: the monitor isn't built into the machine in the PET sense but the machine's power supply is built into the monitor. So part of the machine is in there. – Tommy Mar 12 '17 at 23:14
  • 3
    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 '20 at 13:16
  • 1
    I'd characterize the killer poke in a category of operations that accelerate wear. If one were to e.g. write a program to continuously slam a floppy drive head against the end stop and left it running for a weekend, it might very well knock the drive out of alignment or wear out some of the mechanical parts. Likewise, doing the "killer poke" and leaving the machine in the errant state for days might overstress some of the components to the point of failure. Neither operation would be able to cause significant damage, however, in the presence of someone who reacted quickly to stop them. – supercat Sep 23 '20 at 15:58
18

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?

davidbak
  • 6,269
  • 1
  • 28
  • 34
  • 10
    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 Sep 22 '20 at 17:59
  • Burroughs B6700 System. Had to warm up a drive to do a head alignment. Left a drive running a warm up exercise over the morning tea break then had to replace all the cooked drive transistors which were TO-3 packages on a PCB. Heat build up in the drive transistors cooked them to the point of failure. In normal random seek operation it was not a problem. At least the drive was not loaded with the site alignment pack. – PDP11 Jan 17 '24 at 06:32
15

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.

Vince
  • 259
  • 1
  • 4
  • 2
    Welcome to Retrocomputing! Hope you stick around and continue to share your knowledge. – JAL Feb 10 '17 at 21:44
  • 3
    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
  • 2
    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
  • 4
    @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 http://www.vintagecomputer.net/commodore/1541-1571_Drive_Alignment_Free_Spirit.pdf on the second page of content. – Tommy Mar 12 '17 at 23:12
  • 1
    @MichaelKjörling Sorry, but this was pretty close to 30 years ago and in DOS 3.3 using 8086 registers. I remember it was a simple assembly program that pushed the maximum value to the register that handled the arm motor, however I do not remember the register that was used. Pushing the max value on some drives caused a click, but would continually run never reaching the appropriate value until the motor itself burnt out. – Vince Mar 14 '17 at 19:43
  • 3
    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
  • 1
    @BrianKnoblauch that was the cause of many Apple floppy drive failures in normal use. The backstop was a bit too hard and eventually the head went out of alignment from repeatedly hitting it. – user Sep 24 '20 at 11:54
14

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.

Muzer
  • 1,782
  • 12
  • 21
  • 11
    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
14

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 2C02 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 2C02 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.

jogloran
  • 105
  • 4
NobodyNada
  • 5,464
  • 1
  • 23
  • 35
  • 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
  • 3
    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
14

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

Bruce Abbott
  • 6,673
  • 15
  • 31
  • 3
    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 00:23
  • 5
    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 Sep 24 '20 at 11:59
11

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.

Tim Leonard
  • 341
  • 2
  • 4
  • It's weird that the ribbon was not continuously moved to even out the wear. – Leo B. Sep 23 '20 at 16:27
  • @LeoB. Could the ribbon have been driven from the paper-feed mechanism, so still paper ⇒ still ribbon? – gidds Jan 15 '24 at 13:47
  • @gidds Precisely, and that is the design decision which I find weird. Ribbon movement must be completely decoupled from the paper feed to even out the wear. – Leo B. Jan 16 '24 at 04:52
11

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.

Mark
  • 8,556
  • 1
  • 40
  • 63
  • 3
    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
  • 4
    @Jeremy Though that is a result of a soft brain in control, not software in control... – rackandboneman Jul 17 '17 at 00:20
  • 4
    @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 Sep 25 '20 at 03:12
  • 5
    @jeffB I believe the progression goes HED -> LED -> SED -> DED. – user253751 Mar 22 '21 at 09:20
8

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.

Pedro Gimeno
  • 246
  • 3
  • 4
  • 4
    The manual of my MSX said "don't be afraid to experiment, you can't damage your computer by running code alone". LIARS! – Konamiman Sep 22 '20 at 15:36
7

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.

Tommy
  • 36,843
  • 2
  • 124
  • 171
  • 3
    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 '20 at 12:42
  • 1
    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 Sep 24 '20 at 12:03
7

Circa 1984, when I was an undergrad at Caltech, some friends of mine (including IIRC Adam Greenblatt and Joe Decker) had an account on the CS department's IBM 4381 mainframe. Most of us turned up our noses at it because it was basically just a retro computer — an IBM 360 emulator that you programmed in FORTRAN through a virtual card punch.

But these guys knew it was the fastest machine on campus, with an outboard vector processing unit the size of a dorm fridge. It had a bitmapped color display too. As such, it would be great for rendering the Mandelbrot set, which we were all hyped about due to the recent Scientific American article. I had written a Mandelbrot renderer for HP 9836 workstations, but it was very slow on a 68000 with no hardware FP!

So my friends taught themselves the 4381 vector processor's instruction set and wrote a super tight assembly loop for computing Mandelbrot pixels in parallel. It was indeed much, much faster. But after a while (i don’t remember how long) it crashed. In fact the whole mainframe crashed, and couldn’t be restarted. My friends were in trouble with the department for breaking a very expensive computer with a frivolous hack.

The IBM repair guy who came out determined that the vector unit had overheated and damaged itself. Apparently none of IBM's test code had been able to push the VPU as hard, with no wait states. He replaced the unit, talked the staff out of punishing the perps, and took a copy of the assembly code back with him so IBM could study it and make the hardware more resilient.

I’ll leave it to you to decide whether or not the vector unit was an integral part of the computer, a separate computer, or just a peripheral.

(I was not present, but I heard the story direct from several of the folks involved soon afterward, so there’s no FOAF distortion.)

Jens Alfke
  • 171
  • 1
  • 2
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.)

mschaef
  • 4,836
  • 1
  • 16
  • 23
  • 6
    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.

Joel Rees
  • 351
  • 2
  • 5
2

According to Dragon Data themselves, the Dragon 32 speed-up poke (POKE 65495,0) could potentially harm the machine.

Graham Lee
  • 813
  • 5
  • 11
  • 1
    I think they're just hedging their bets by saying "we do not know whether overclocking will cause harm". – dave Jan 14 '24 at 17:38
1

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

Jean-François Fabre
  • 10,805
  • 1
  • 35
  • 62
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.

tofro
  • 34,832
  • 4
  • 89
  • 170
  • 3
    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
  • 2
    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

As I recall, IBM released a microcode update for the RS6000 machines that had a bug. The first few customers who applied it found that it permanently bricked the CPU, and IBM ended up replacing the associated hardware.

I’d love to know if anyone has more details on this, or can verify the story.

Jeff Younker
  • 1
  • 1
-1

This isn't the computer itself but: which manufacturer of storage systems had a programmed feature there it was possible to modify the programs in individual HD controllers ?

Great crack: get inside such a storage system and then instantly turn all hard disks into door stops.

Stefan Skoglund
  • 387
  • 1
  • 6