Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!uokmax!norlin From: norlin@uokmax.ecn.uoknor.edu (Norman Lin) Newsgroups: comp.sys.atari.8bit Subject: Re: CBRN (Crash and Burn) opcode Message-ID: <1990Sep22.213010.22357@uokmax.ecn.uoknor.edu> Date: 22 Sep 90 21:30:10 GMT References: <1990Sep19.171649.20159@ingres.Ingres.COM> <5501@harrier.ukc.ac.uk> <34182@cup.portal.com> Organization: Engineering Computer Network, University of Oklahoma, Norman, OK Lines: 29 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|====/ \\\/./ \\\/./ \/\/ \/\/ \/\/ +-----------------------------+ \/\/ \/\/