Path: utzoo!attcan!uunet!clyde.concordia.ca!ccu.umanitoba.ca!umhild11 From: umhild11@ccu.umanitoba.ca (Jeff 'Zar' Hildebrand) Newsgroups: comp.sys.atari.8bit Subject: Re: CBRN (Crash and Burn) opcode Message-ID: <1990Sep25.012956.20382@ccu.umanitoba.ca> Date: 25 Sep 90 01:29:56 GMT References: <1990Sep19.171649.20159@ingres.Ingres.COM> <5501@harrier.ukc.ac.uk> <34182@cup.portal.com> Organization: University of Manitoba, Winnipeg, Canada Lines: 25 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