39

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.

Improve this question
15
  • 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
    Commented Feb 7, 2017 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
    Commented Feb 8, 2017 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.
    Commented Feb 8, 2017 at 8:54
  • 1
    "Sending the electron beam into circuitry" Whaaaaat? Are you serious?
    – mcleod_ideafix
    Commented Feb 8, 2017 at 9:27
  • 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
    Commented Feb 26, 2017 at 2:49

20 Answers 20

Reset to default
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.

Improve this answer
19
  • 23
    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
    Commented Feb 7, 2017 at 9: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 ♦
    Commented Feb 7, 2017 at 9:47
  • 11
    @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 ♦
    Commented Feb 7, 2017 at 11:01
  • 19
    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
    Commented Feb 7, 2017 at 22:28
  • 29
    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 ♦
    Commented Mar 5, 2017 at 19:08
32

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
8
  • 13
    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
    Commented Sep 21, 2020 at 5: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
    Commented Mar 17, 2022 at 21:36
  • 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
    Commented Mar 18, 2022 at 2: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
    Commented Mar 18, 2022 at 2: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
    Commented Mar 18, 2022 at 17:32
20

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
11
  • 4
    Hmm. Peripheral devices were explicitly excluded.
    – tofro
    Commented Feb 7, 2017 at 6:14
  • 20
    @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
    Commented Feb 7, 2017 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
    Commented Feb 8, 2017 at 2: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.
    Commented Feb 8, 2017 at 8:49
  • 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
    Commented Sep 20, 2020 at 13:16
19

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
  • 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
    Commented Sep 22, 2020 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
    Commented Jan 17 at 6: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.

Improve this answer
7
  • 2
    Welcome to Retrocomputing! Hope you stick around and continue to share your knowledge.
    – JAL
    Commented Feb 10, 2017 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
    Commented Mar 11, 2017 at 14:10
  • 3
    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
    Commented Mar 11, 2017 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 vintagecomputer.net/commodore/… on the second page of content.
    – Tommy
    Commented Mar 12, 2017 at 23:12
  • 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
    Commented Jul 11, 2017 at 16:03
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.

Improve this answer
1
  • 11
    Ditto the Electron. But that didn't stop some games using quick switches of the cassette relay as an extra sound effect.
    – Tommy
    Commented Mar 12, 2017 at 23:16
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

Improve this answer
5
  • 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
    Commented Mar 11, 2017 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
    Commented Mar 11, 2017 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
    Commented Mar 12, 2017 at 14:52
  • DMA controllers and all the way you could misconfigure them are probably worth looking at...
    – rackandboneman
    Commented Jul 17, 2017 at 0: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
    Commented Sep 24, 2020 at 11:59
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.

Improve this answer
3
  • But would it be exactly a short? Isn't there some kind of a pull-up resistor preventing a literal short-circuit?
    – DmytroL
    Commented Feb 18, 2017 at 11:45
  • @DmytroL Nope; the pin goes directly to ground and the PPU connects it directly to 5V.
    – NobodyNada
    Commented Feb 18, 2017 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
    Commented Mar 11, 2017 at 14:15
12

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
3
  • It's weird that the ribbon was not continuously moved to even out the wear.
    – Leo B.
    Commented Sep 23, 2020 at 16:27
  • @LeoB. Could the ribbon have been driven from the paper-feed mechanism, so still paper ⇒ still ribbon?
    – gidds
    Commented Jan 15 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.
    Commented Jan 16 at 4: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.

Improve this answer
4
  • 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
    Commented Mar 13, 2017 at 10:41
  • 4
    @Jeremy Though that is a result of a soft brain in control, not software in control...
    – rackandboneman
    Commented Jul 17, 2017 at 0: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
    Commented Sep 25, 2020 at 3:12
  • 5
    @jeffB I believe the progression goes HED -> LED -> SED -> DED.
    – Criticizing Israel not allowed
    Commented Mar 22, 2021 at 9:20
9

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
1
  • 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
    Commented Sep 22, 2020 at 15:36
9

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

Improve this answer
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.

Improve this answer
2
  • 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
    Commented Sep 20, 2020 at 12:42
  • 2
    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
    Commented Sep 24, 2020 at 12:03
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
1
  • 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
    Commented Jul 20, 2017 at 18:52
4

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
1
  • That the opcodes 0x9D and 0xDD.
    – cup
    Commented Mar 19, 2022 at 8:39
2

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

Improve this answer
1
  • 1
    I think they're just hedging their bets by saying "we do not know whether overclocking will cause harm".
    – dave
    Commented Jan 14 at 17:38
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.

Improve this answer
2
  • 3
    Any chip that you can overheat - for example, the bus collision scenario above - can be turned into a fusible PROM.
    – rackandboneman
    Commented Jul 16, 2017 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
    Commented Jul 24, 2017 at 22:17
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 :))

Improve this answer
1
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.

Improve this answer
1
  • 2
    If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review
    – Greenonline
    Commented Jan 14 at 22:31
-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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .