In the early 1960s this was regarded as an urban myth.
I thought everyone knew that the answer to life, the universe and everything is “forty-two”.
DEC had the GT40 long before the70s.
If you want to blow up a computer room, attack the peripherals. Get a high-speed chain printer, (as fitted to IBM 1401s and 1440s) and make it print a line where the letters are in the same order as those on the chain.
Chain printers had fast moving chains with letters in an odd order (which I can’t bring to mind fifty years later). As the chain flew past a line of hammers the full width of the printer a hammer would be actuated when the right letter was in front of it to print the required letter at that point. If all the hammers actuated simultaneously the kinetic energy in the chain was enough to cause catastrophic breakdown of the physical machinery.
Ah, the Good Old Days.
True. The thing about the Xerox was that it sported a window based GUI, and a very modern OS. They had no idea what they had until it was far too late.
I remember hearing ledgends about that. We only had CDC drum printers. It was possible to slam all the hammers at the same time on those too, but it didn’t do the same amount of damage. You could make some good noises however. I still have a drum out of one of those in my little store of memorabilia. It weighs something astounding.
A small nitpick. Opcode 0xA2 is perfectly valid. It’s the LDX instruction, in immediate mode.
But your memory is otherwise correct. Several opcodes with a lower digit of 2 would freeze the 6502. See the “HLT” instruction on this page, about halfway down.
HLT crashes the microprocessor. When this opcode is executed, program execution ceases. No hardware interrupts will execute either. … Only a reset will restart execution. This opcode leaves no trace of any operation performed! No registers affected.
On the next-generation 65C02 CPU, all the illegal opcodes were changed into NOPs, thus taking away the anarchy. (And breaking a few games which had depended on the undocumented behaviors.)
I get the vague sense that the OP is talking about sitting down and more or less typing some vaguely comprehensible problem into the computer that would make it crash dramatically. This suggests a high-level language, which would tend to have range check safeguards, so running out of memory in such a scenario will just fault out. The only way to get something dramatic would either be assembly/machine code (pretty arcane for a story) or the equivalent of BASIC’s POKE to directly corrupt memory and/or hardware.
If you want to physically break an 80s PC you could pick the wrong video frequency and break some monitors. Otherwise it’s difficult to get them to overheat by controlled processing even with a broken fan. If you break the fan and they don’t overheat pretty quickly, not that much will make them overheat (this will obviously vary with particular hardware).
If you just want to cause a software crash on an 80s PC, just use it for a while.
Why would it do anything? An endless loop in and of itself requires very little memory, and if it’s not doing floating point operations it’s using very little processor functionality. The CPU may be maximizing it’s cycle usage if the instructions are all cached, but even that shouldn’t do so much to heat up an 80s CPU. If he started some endless recursion he’d hit a memory limit of some kind very quickly though.
Maybe. The video I saw was about 2-3 years old. It was a presentation by an energy conservation specialist, they were comparing the energy saving and heat regulating features of a modern Intel vs a modern AMD by stress testing them with no heatsink. In every case the Intel would just stop working until it got cool, while the AMD kept flailing and caught fire. Maybe it’s gotten better since then.
Which is why I recommended a naive recursive factorial program. I’m too lazy to calculate exactly how many recurses it would take to overflow with the stack frame on an <x> bit system with <y> bytes of memory, but it’s completely plausible and very easy to stack overflow a system with a factorial function, which is a function that can plausibly exist in any number of problems (say they were doing combinatorics).
One CPU the OP mentioned was a 6502, which has an 8-bit stack (256 bytes). Overflowing that would be trivial, except I suspect most 6502 software design did not involve stack-based automatic variables.
True, but if it’s in the modern day and the guy is just using a hacked together '80s computer it’s possible he just wrote a quick recursive factorial function while not thinking (depending on his characterization in the story).
I mean, not that you should ever use a recursive factorial function (caveat: in languages not optimized for tail recursion, obviously if you’re using Haskell or something…), even in modern software design. But whatever.
Well, I inferred that he wants the character working on a plausible real world problem when the computer breaks, rather than trying to break the computer for shits and giggles.
What I was saying is, it is not clear at all what the OP’s asking for, given the later post that I quoted. At one point he says he doesn’t want to damage the CPU. At another point in the same post, he complains about a possible solution because it doesn’t damage the CPU. So, I’m asking, is he trying to damage the CPU or not? If not, then it seems like he just wants to lock the thing up, so that’s why I asked him why the infinite loop wouldn’t suffice. (Granted it would need to be a little more complicated than a single line loop as it would need to interrupt any ctrl+break type of mechanism that may be operative on the machine in question.)
Yeah, I think he’s been convinced computers don’t break just because the problem is complex. I’m not sure what he’s after anyway. It’s easier to physically damage a modern PC, but it’s more difficult to crash one by using up memory.
True, but they would often take months to break. It wasn’t something that happened immediately. For those who aren’t aware, it was a problem with a lot of linux machines (due to the default settings they used for some monitors) and wasn’t all that noticeable since the screen looked ok to the user. Also, some monitors were more sensitive to it than others.
I also recall this problem as being more early 90s than 80s.
I was thinking of some of hi-res cards for IBM clones in the 80s. Depending on the monitor you instantly trash it. Would have been late 80s IIRC. Overdriving monitors has been a problem a lot of times, but barely qualifies as breaking a computer. I think some interfaces could detect the monitor dying, others wouldn’t even know about it, so the computer was really remaining fully functional except for a blank display. I heard about monitors smoking from this, but I only ever saw them after they were broken, and none looked burnt.
The 6502 stack pointer (S) is only 8 bits in size, with the stack itself always occupying the range $0100-01FF.
So executing a JSR-to-itself instruction would fill up the stack with return addresses, but it would also just wrap around, writing to the same 256 bytes over and over.