home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sun.misc:3810 alt.folklore.computers:12824
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!newshost.wcc.govt.nz!fmcg!equinox!Geoff
- Newsgroups: comp.sys.sun.misc,alt.folklore.computers
- Subject: Re: what is halt_and_catch_fire?
- Message-ID: <Geoff.1nrj@equinox.gen.nz>
- From: Geoff@equinox.gen.nz (Geoff Mccaughan)
- Date: 20 Aug 92 17:51:02 +1200
- References: <3140@isgtec.isgtec.com>
- Organization: Equinox Networks
- X-Newsreader: Tin 1.1 PL4
- Lines: 30
-
- bmw@isgtec.com (Bruce M. Walker) writes:
- >In article <1992Aug17.132819.29817@zoo.bt.co.uk> jcs@zoo.bt.co.uk (John C
- Sager) writes:
- >> I was told once that one of the unused opcodes on the original Motorola
- 6800
- >> would put the processor into a halt mode in such a way that a particular
- >> part of the chip got very hot & burned out, and this was called,
- jokingly,
- >> halt-and-catch-fire. It may however be apocryphal.
- >
- >It is semi-apocryphal. One undocumented opcode in the MC6800
- >instruction set caused the processor to cease fetching instructions,
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
- >but to increment its address lines rapidly (every one or two clocks,
- >don't remember which). This became known as the HCF instruction:
- >Halt-and-Catch-Fire, but that had nothing to do with the die
- >temperature :-), just the vision of all the address lines madly
- >flapping in the breeze.
- >
- >This feature was really handy for testing the address decode logic in a
- >new 6800 design. Just burn HCF into every EPROM location, get your 'scope
- ^^^^^^^^^^^^^^^^^^^^
- >probes ready and let 'er rip.
-
- Isn't this contradictory?
-
- --
- Geoff, Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 [4 Lines]
- Voice: +64 (3) 3852101
- "Hi. You have just entered the fourth dimension. Small isn't it?"
-