> But if your program tried to write to ROM and did it often enough, you stressed both the CPU and ROM chip and could cause one or the other to overheat and fail.
I was very much into the C64 scene back in the early 90s and while I heard claims similar to that one (code that destroys chips or other components by overheating/stressing them) there was never any legitimate source of that. It was all just urban legends
Facts. Only attacks I ever saw were physical where the code would seek the drive head on Atari 810s repeatedly or strobe it or attempt force xt drives in and out of the landing zone to similar effect. obviously over time this is not good for the mechanism.
I don’t remember cpu therms being an issue until the mid late 90s - and then it was athlons. I could be wrong but I dont remember seeing CPU fans until the Pentium II cartridge but that is probably misremembering nostalgia.
80s was just robust against thermal - heck ataris had a giant aluminium shield over the mobo
> he’d seen protection schemes that, if they detected you had tampered with them, would try to break your disk drive in retaliation. The most common way to do this was to send the drive a command to try to move the drive’s stepper motor beyond its physical range. The drive would oblige and try to do the impossible, so it was possible to command the drive to permanently damage its own drive mechanism.
I didn't have a C64 and my Radio Shack Coco had a less complex disk drive mechanism based around a standard Western Digital disk controller chip, but there were similar copy protections on some software titles.
While I'm sure someone did tell Dave this story, and that person may have believed it themselves, I suspect it's based on a mistaken extrapolation of a more innocent behavior. Way back in the day, we heard a similar report at my local user's group but a techie friend of mine looked into the offending software title and discovered a reality that was more benign. Basically, during manufacturing disk protections tend to put some non-standard formatting someplace on the original disk and then the software tries to read back the non-standard stuff to verify it's the original disk. These could be extra, missing or mis-numbered tracks or sectors. Some protections also put data on an extra track added beyond the last track. Coco disks had 35 "official" tracks in the specification but users quickly learned that these drives were manufactured as 40 track drives, of which some didn't pass QA tests seeking all the way to track 40 and were sold cheaper to Radio Shack. But I never saw a Radio Shack Coco drive that wouldn't seek to track 36, 37 and usually more. I eventually had four drives and all of them would reliably seek to track 41 or 42. In fact, hobbyists made mods for the disk operating system to add extra tracks to the official count. So, at least on the Coco, there were multiple disk protections that would seek the head "beyond the last track", not to damage the drive but because they knew the original disk had data there which all drives could read but no normal disk copy command would write.
The other thing to know is that all these floppy drives were inexpensive, mass-manufactured mechanical devices that had varying tolerances between individual units at the factory which only grew with wear over time, temperature, shipping and handling. Also the diskettes themselves weren't exactly made to exacting mil-spec standards. So, to read the disk the controller software would seek to the desired track and try to read the requested sector. It wasn't terribly unusual for a read to fail and time out due to the head moving a bit too slow or perhaps initially undershooting or overshooting the target track. So all controller software would move the head back (usually to track zero) and then try to step back to the desired track and do the read again. If it didn't work, it would repeat this several times hoping to get a good read before eventually failing with an error. When these rapid head resets and retries happened, the drive would make a loud and unusual "gronking" sound that was quite noticeable. And that was just with normal disks and no oddball disk formatting or trick-play head seeking.
When disk protections would fail to find the expected oddball tracks or sectors, they'd do the same reset/retry behavior with the same furious gronking. Except in the case of disk protections half the sectors on a track could be "special" (on the Coco there were 18 sectors on a track). At 3 or 5 retries each, that's a lot of loud head gronking for a long time as each sector is attempted and fails out in turn. Such was the case with the protected software title my friend disassembled. The erstwhile failed pirate at our user's group meeting (a middle schooler) was trying to start a copy of the game which had none of the "special" sectors present. While I doubt all that gronking was good for the disk mechanism, it wasn't intentionally malicious on the part of the software title. But you can see how the loud gronking sounds which only happened on a failed attempt to pirate a copy of a protected disk could cause people to make assumptions and leap to nefarious conclusions which would then be further embellished through the retelling.
Of course, I don't doubt that some hobbyist hacker or maybe solo software dev had nefarious thoughts and maybe even played around with how to do it and showed their friends a demo. But I never saw or heard any credible claims a commercial software title sold at scale ever shipped to consumers with the intent to destroy user hardware. Even in those days software was sold by publishers to distributors who then sold to retail stores, who sold to end users. A national wave of failed hardware reports associated with one title could mean blame and perhaps even legal liability for any and all of those parties. And disassembling the software sufficiently to prove it was doing this intentionally would have been much easier than making working pirated copies. To be so reckless, not only would the author have to be really dumb, so would the publisher and anyone who knew about it in advance.
The kicker is that, in those days, bulk duplication of diskettes (especially funkily formatted diskettes) wasn't all that reliable - meaning there was a pretty high probability that some non-zero percentage of your legit copies sometimes wouldn't read correctly for a paying customer due to varying manufacturing tolerances (or stray magnetic fields in shipping). And, of course, this failure to read could cause the copy protection to detect the legit disk as "pirated". Back in the 80s and 90s I worked for a successful software manufacturer and one of our products was a large, professional tool which eventually grew to occupy well over a dozen 3.5 inch floppy disks. When a disk wouldn't read for a customer it was a costly warranty issue to ship them a new disk set (and there was no consumer internet). As our software and disk count grew, we saw increasing disk failures. So we analyzed it and despite using the top disk duplicator in the U.S. and legit top-notch, direct-from-the-Sony-factory media - once our install was over a dozen diskettes, the statistical best case was almost every fourth customer would have at least one disk from their set fail to read. And this is without any funky formatting! Fortunately, CD-ROM became a thing shortly thereafter but the point is, the top disk duplicator in the country confirmed that "Yep, we do this better than anyone and your media is the best money can buy - and you're getting the expected field failure rate." So, selling hardware destroying time bombs would have been incredibly stupid, because statistically inevitable failures would certainly harm the hardware of more than one legitimate paying customer by mistake, and that would result in a very fast (but quite spectacular) fireball of infamy for any company dumb enough to try it.
> But if your program tried to write to ROM and did it often enough, you stressed both the CPU and ROM chip and could cause one or the other to overheat and fail.
I was very much into the C64 scene back in the early 90s and while I heard claims similar to that one (code that destroys chips or other components by overheating/stressing them) there was never any legitimate source of that. It was all just urban legends
I don’t remember cpu therms being an issue until the mid late 90s - and then it was athlons. I could be wrong but I dont remember seeing CPU fans until the Pentium II cartridge but that is probably misremembering nostalgia.
80s was just robust against thermal - heck ataris had a giant aluminium shield over the mobo
I didn't have a C64 and my Radio Shack Coco had a less complex disk drive mechanism based around a standard Western Digital disk controller chip, but there were similar copy protections on some software titles.
While I'm sure someone did tell Dave this story, and that person may have believed it themselves, I suspect it's based on a mistaken extrapolation of a more innocent behavior. Way back in the day, we heard a similar report at my local user's group but a techie friend of mine looked into the offending software title and discovered a reality that was more benign. Basically, during manufacturing disk protections tend to put some non-standard formatting someplace on the original disk and then the software tries to read back the non-standard stuff to verify it's the original disk. These could be extra, missing or mis-numbered tracks or sectors. Some protections also put data on an extra track added beyond the last track. Coco disks had 35 "official" tracks in the specification but users quickly learned that these drives were manufactured as 40 track drives, of which some didn't pass QA tests seeking all the way to track 40 and were sold cheaper to Radio Shack. But I never saw a Radio Shack Coco drive that wouldn't seek to track 36, 37 and usually more. I eventually had four drives and all of them would reliably seek to track 41 or 42. In fact, hobbyists made mods for the disk operating system to add extra tracks to the official count. So, at least on the Coco, there were multiple disk protections that would seek the head "beyond the last track", not to damage the drive but because they knew the original disk had data there which all drives could read but no normal disk copy command would write.
The other thing to know is that all these floppy drives were inexpensive, mass-manufactured mechanical devices that had varying tolerances between individual units at the factory which only grew with wear over time, temperature, shipping and handling. Also the diskettes themselves weren't exactly made to exacting mil-spec standards. So, to read the disk the controller software would seek to the desired track and try to read the requested sector. It wasn't terribly unusual for a read to fail and time out due to the head moving a bit too slow or perhaps initially undershooting or overshooting the target track. So all controller software would move the head back (usually to track zero) and then try to step back to the desired track and do the read again. If it didn't work, it would repeat this several times hoping to get a good read before eventually failing with an error. When these rapid head resets and retries happened, the drive would make a loud and unusual "gronking" sound that was quite noticeable. And that was just with normal disks and no oddball disk formatting or trick-play head seeking.
When disk protections would fail to find the expected oddball tracks or sectors, they'd do the same reset/retry behavior with the same furious gronking. Except in the case of disk protections half the sectors on a track could be "special" (on the Coco there were 18 sectors on a track). At 3 or 5 retries each, that's a lot of loud head gronking for a long time as each sector is attempted and fails out in turn. Such was the case with the protected software title my friend disassembled. The erstwhile failed pirate at our user's group meeting (a middle schooler) was trying to start a copy of the game which had none of the "special" sectors present. While I doubt all that gronking was good for the disk mechanism, it wasn't intentionally malicious on the part of the software title. But you can see how the loud gronking sounds which only happened on a failed attempt to pirate a copy of a protected disk could cause people to make assumptions and leap to nefarious conclusions which would then be further embellished through the retelling.
Of course, I don't doubt that some hobbyist hacker or maybe solo software dev had nefarious thoughts and maybe even played around with how to do it and showed their friends a demo. But I never saw or heard any credible claims a commercial software title sold at scale ever shipped to consumers with the intent to destroy user hardware. Even in those days software was sold by publishers to distributors who then sold to retail stores, who sold to end users. A national wave of failed hardware reports associated with one title could mean blame and perhaps even legal liability for any and all of those parties. And disassembling the software sufficiently to prove it was doing this intentionally would have been much easier than making working pirated copies. To be so reckless, not only would the author have to be really dumb, so would the publisher and anyone who knew about it in advance.
The kicker is that, in those days, bulk duplication of diskettes (especially funkily formatted diskettes) wasn't all that reliable - meaning there was a pretty high probability that some non-zero percentage of your legit copies sometimes wouldn't read correctly for a paying customer due to varying manufacturing tolerances (or stray magnetic fields in shipping). And, of course, this failure to read could cause the copy protection to detect the legit disk as "pirated". Back in the 80s and 90s I worked for a successful software manufacturer and one of our products was a large, professional tool which eventually grew to occupy well over a dozen 3.5 inch floppy disks. When a disk wouldn't read for a customer it was a costly warranty issue to ship them a new disk set (and there was no consumer internet). As our software and disk count grew, we saw increasing disk failures. So we analyzed it and despite using the top disk duplicator in the U.S. and legit top-notch, direct-from-the-Sony-factory media - once our install was over a dozen diskettes, the statistical best case was almost every fourth customer would have at least one disk from their set fail to read. And this is without any funky formatting! Fortunately, CD-ROM became a thing shortly thereafter but the point is, the top disk duplicator in the country confirmed that "Yep, we do this better than anyone and your media is the best money can buy - and you're getting the expected field failure rate." So, selling hardware destroying time bombs would have been incredibly stupid, because statistically inevitable failures would certainly harm the hardware of more than one legitimate paying customer by mistake, and that would result in a very fast (but quite spectacular) fireball of infamy for any company dumb enough to try it.