Chris_F_Chiesa@cup.portal.com (09/23/90)
Don't take the title too seriously -- I _DON'T_ have any info on an opcode, per se, but I do know a little bit about the history of opcodes that burn out computers. Whomever mentioned that "it wasn't the opcode, but a memory or hardware address or register that did it" was correct. I believe there was a con- trolling register in the early IBM PC that controlled whether or not the CRT flyback transformer signal was generated and/or actually directed to the transformer itself; apparently it was possible to send a particular control bit value to the register which caused the signal sent to the transformer to become straight DC current, burning out the whole video subsystem. POOF! (I heard something even earlier than this, attributed to the Commdore PET computer, but don't know the details.)
gdtltr@freezer.it.udel.edu (Gary Duzan) (09/23/90)
In article <34182@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes: => =>(I heard something even earlier than this, attributed to the Commdore PET =>computer, but don't know the details.) The way I heard it, the PET had the monitor built in, and had full control over screen width and height. All you had to do was reduce the screen to a single dot in the middle, and it would slowly fry the monitor. I also heard that the Vic-20 had a location that cross-wired an I/O port, causing a power surge into the circuits. This is all rumor and heresay. I haven't seen/performed any of these. Gary Duzan Time Lord Third Regeneration p.s. I have, however, seen Apple IIe's get fried by static charges. In High School, the computer room used to be a library and had this nice carpet... GD,TL,TR -- gdtltr@freezer.it.udel.edu _o_ -------------------------- _o_ [|o o|] An isolated computer is a terribly lonely thing. [|o o|] |_O_| "Don't listen to me; I never do." -- Doctor Who |_O_|
norlin@uokmax.ecn.uoknor.edu (Norman Lin) (09/23/90)
Chris_F_Chiesa@cup.portal.com writes: >Don't take the title too seriously -- I _DON'T_ have any info on an opcode, >per se, but I do know a little bit about the history of opcodes that burn >out computers. >Whomever mentioned that "it wasn't the opcode, but a memory or hardware >address or register that did it" was correct. I believe there was a con- >trolling register in the early IBM PC that controlled whether or not the >CRT flyback transformer signal was generated and/or actually directed to >the transformer itself; apparently it was possible to send a particular >control bit value to the register which caused the signal sent to the >transformer to become straight DC current, burning out the whole video >subsystem. POOF! >(I heard something even earlier than this, attributed to the Commdore PET >computer, but don't know the details.) It was a single POKE command on the Commodore PET. An early issue of Compute! Magazine (1982? 83?) actually gave the POKE command; it allowed the video display chip to run faster. Left unchecked, this would eventually burn out the display chip. -- \ /\/\ /\/\ +-----------------------------+ /\/\ /\/\ /./ \\ /./\\\ /./\\\ /====|Norman Lin/norlin@129.15.20.2|===/./\\\ /./\\\ /./ \\\/./ \\\/./ \\\/./===| norlin@uokmax.ecn.uoknor.edu|====/ \\\/./ \\\/./ \/\/ \/\/ \/\/ +-----------------------------+ \/\/ \/\/
umhild11@ccu.umanitoba.ca (Jeff 'Zar' Hildebrand) (09/25/90)
In article <34182@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes: >Don't take the title too seriously -- I _DON'T_ have any info on an opcode, >per se, but I do know a little bit about the history of opcodes that burn >out computers. > >Whomever mentioned that "it wasn't the opcode, but a memory or hardware >address or register that did it" was correct. I believe there was a con- >trolling register in the early IBM PC that controlled whether or not the >CRT flyback transformer signal was generated and/or actually directed to >the transformer itself; apparently it was possible to send a particular >control bit value to the register which caused the signal sent to the >transformer to become straight DC current, burning out the whole video >subsystem. POOF! > >(I heard something even earlier than this, attributed to the Commdore PET >computer, but don't know the details.) I *do* know a little about this 'feature' in the Commodore PETs. Apparently there was a memory location that controlled the clock speed of the processor. Altering this location was particularly useful for doing high speed screen updates. The problem was that the clock speed did not simply get bumped up to a higher rate - instead it continued to increase. If left long enough, the CPU simply burned up. Jeff