Blowing processors
Thunderchief
Thanks for all the amazing feedback on 'musical' printers and disk drives.
Another thing struck me on the way to work today - Commodore PETS. I can't
for the life of me remember which particular model, but wasn't there a, erm,
poke or something that set the processor going madly in an unbreakable loop
that eventually blew up the processor.
I'm sure I remember reading this at the time (very early 80's ?) but does
anyone else remember this?
Later
Thunderchief
~ The past is tense, the future tenser ~
Ralph Wade Phillips
Thunderchief wrote in message <7vum6j$qke$1...@news4.svr.pol.co.uk>...
>Hi
>
>Thanks for all the amazing feedback on 'musical' printers and disk drives.
>
>Another thing struck me on the way to work today - Commodore PETS. I can't
>for the life of me remember which particular model, but wasn't there a,
erm,
>poke or something that set the processor going madly in an unbreakable loop
>that eventually blew up the processor.
Not quite, but you COULD reset the video display controller (6545 /
6845) and cause it to destroy the monitor ...
fungus
Thunderchief wrote:
>
> Hi
>
> Thanks for all the amazing feedback on 'musical' printers and disk drives.
>
> Another thing struck me on the way to work today - Commodore PETS. I can't
> for the life of me remember which particular model, but wasn't there a, erm,
> poke or something that set the processor going madly in an unbreakable loop
> that eventually blew up the processor.
>
No, but you could fry the monitor by poking the display controller chip.
--
<\___/>
/ O O \
\_____/ FTB.
John Ferrell
controller at boot time or no sweep led to blowing something in the monitor.
Ralph Wade Phillips wrote:
> Howdy!
>
> Thunderchief wrote in message <7vum6j$qke$1...@news4.svr.pol.co.uk>...
> >Hi
> >
> >Thanks for all the amazing feedback on 'musical' printers and disk drives.
> >
> >Another thing struck me on the way to work today - Commodore PETS. I can't
> >for the life of me remember which particular model, but wasn't there a,
> erm,
> >poke or something that set the processor going madly in an unbreakable loop
> >that eventually blew up the processor.
>
> Not quite, but you COULD reset the video display controller (6545 /
> 6845) and cause it to destroy the monitor ...
>
> >
> >I'm sure I remember reading this at the time (very early 80's ?) but does
> >anyone else remember this?
> >
> >Later
> >
> >Thunderchief
> >~ The past is tense, the future tenser ~
> >
> >
--
John Ferrell in Julian NC, de W8CCW
Dixie Competition Products
6241 Phillippi Rd
Julian NC 27283
Phone: (336)685-9606 Fax: (336)685-9771
"My Competition is Not My Enemy"
Bill Bradley
>>for the life of me remember which particular model, but wasn't there a,
>erm,
>>poke or something that set the processor going madly in an unbreakable loop
>>that eventually blew up the processor.
>
>
> Not quite, but you COULD reset the video display controller (6545 /
>6845) and cause it to destroy the monitor ...
Actually there was a command on the 6809(?) often reffered to as HCF (
Halt and Catch Fire) which would run through ever address and data line to
test the board wiring. This was supposed to be used in processor step mode,
and supposedly if executed at full speed wuld roast the chip.
Of course the PETs were 6502 based, but wasn't the floppy controller a
6809?
Bill
Michael Davidson
> Actually there was a command on the 6809(?) often reffered to as HCF (
> Halt and Catch Fire) which would run through ever address and data line to
> test the board wiring. This was supposed to be used in processor step mode,
> and supposedly if executed at full speed wuld roast the chip.
I am pretty sure that (at least as far as the 6809 is concerened) this
is an
"Urban Myth" (or, perhaps it should be a "Cyber Myth").
I worked with 6809's for several years as both a hardware and a software
engineer, and I don't recall anything even remotely like this.
Most of the "Halt and Catch Fire" stories relate to machines with core
memory - perhaps inspired by one of the old PDP-11 diagnostics - the
"worst case core heating test" ...
The most credible version of this story that I have heard related to
the Honeywell 516, where a "branch to self" instruction allegedly had
this effect.
Michael Black
<D...@thunderchief1.freeserve.co.uk> wrote:
> Hi
>
> Thanks for all the amazing feedback on 'musical' printers and disk drives.
>
> Another thing struck me on the way to work today - Commodore PETS. I can't
> for the life of me remember which particular model, but wasn't there a, erm,
> poke or something that set the processor going madly in an unbreakable loop
> that eventually blew up the processor.
>
> I'm sure I remember reading this at the time (very early 80's ?) but does
> anyone else remember this?
>
> Later
>
Blowing the processor seems unlikely.
The PET, at least some models, used the 6845 video controller. Since it
was programmable, you could put out all kinds of oddball sync signals to
the video section.
I'm sure I read about misprogramming of that causing damage to the
video section. I'm not sure if it was a warning, or it actually
happened to someone. What I remember was not so much a warning about
feeding the wrong bytes to the 6845 registers, but comments about
if the CPU went into an loop chewing up garbage code, it could
send the wrong values to the 6845 and then blow up the video section.
And "blow up" can be misleading. I doubt it would be an actual explosion,
more like a transistor being destroyed. And I think you'd have to
run it for a bit to do permanent damage, which doesn't quite fit
the random scenario epsecially if you are right there at the keyboard.
I've fiddled with monitors to try to get them to run at different synx
speeds, and I've run monitors termporarily with out of spec horizontal
output transistors and timing capacitors, and while things got hot,
I could turn them off before permanent damage. Leaving them like
that, is of course another matter.
Michael
Bruce Tomlin
> Bill Bradley wrote:
>
> > Actually there was a command on the 6809(?) often reffered to
as HCF (
> > Halt and Catch Fire) which would run through ever address and data line to
> > test the board wiring. This was supposed to be used in processor step mode,
> > and supposedly if executed at full speed wuld roast the chip.
>
> I am pretty sure that (at least as far as the 6809 is concerened) this
> is an
> "Urban Myth" (or, perhaps it should be a "Cyber Myth").
Opcodes 14 and 15 hex. Causes the processor to go into "test mode" which
is basically: 1) read byte pointed to by PC, 2) increment PC, 3) goto 1.
Takes like 30ms or so to read the whole address space at 2MHz. The only
way out is to reset the CPU.
ISTR seeing that Motorola put a register into the 6811 which has to be set
to enable this mode. I guess they learned their lesson.
> I worked with 6809's for several years as both a hardware and a software
> engineer, and I don't recall anything even remotely like this.
I'm still working with them. It doesn't "roast the chip", but it sure is
annoying in an unattended embedded systems controller. Doubly so when
it's on a board in a PC case where you have to power cycle an NT box or
pop the lid and find the little reset button on the card. At an
unattended gas station (HCF, anyone? :) where it may take a few hours to
get a real human out there to reboot it.
I only found out a month or two ago that our watchdog circuitry (in
hardware designed four years ago) was resetting its timer on both memory
writes AND reads. Furrfu. At least we're not using our 6809s on Mars
space probes.
> Most of the "Halt and Catch Fire" stories relate to machines with core
> memory - perhaps inspired by one of the old PDP-11 diagnostics - the
> "worst case core heating test" ...
>
> The most credible version of this story that I have heard related to
> the Honeywell 516, where a "branch to self" instruction allegedly had
> this effect.
In the microcomputer world, most HCF instances involve a 6845 video chip
and a fixed frequency monitor.
Mike Meredith at home
sen...@ugcs.caltech.edu (Bill Bradley) writes:
>> Not quite, but you COULD reset the video display controller (6545 /
>>6845) and cause it to destroy the monitor ...
Only on some of them, although I can't remember whether it was
the later ones with the VDC, or the earlier ones without.
> Of course the PETs were 6502 based, but wasn't the floppy controller a
> 6809?
Nope. Dual 6502's (yes really).
Eric Smith
> Actually there was a command on the 6809(?) often reffered to as HCF (
> Halt and Catch Fire) which would run through ever address and data line to
> test the board wiring. This was supposed to be used in processor step mode,
> and supposedly if executed at full speed wuld roast the chip.
Most 6800-series processors had such an instruction, as did the 6502 and
family. It was undocumented and was used as part of the factory testing
of the part. It is unknown whether the manufacturers assigned an
"official" mnemonic to these instructions; the HCF mnemonic was probably
coined by customers.
When claims of hardware damage due to this instruction first started
appearing on Usenet over 15 years ago, I was convinced that it was an
urban legend. I conducted tests on the 6809 and 6502. After more than
24 hours of running their HCF instructions, the processors were not
noticably warmer than they were in normal operating condition. The
"catch fire" part of the mnemonic is obviously a humorous interpretation
of the resulting address bus activity, and has nothing to do with
thermal status of the part.
The manufacturers did not specify the behavior of undocumented
instructions, but they would have been very foolhardy to design the
parts such that an undocumented instruction was likely to cause hardware
damage, as there could easily be product liability issues.
Of course, it's possible that a poorly-engineered computer might
misinterpret the activity on the address bus and cause some other sort
of hardware damage. But such hardware would be prone to damage by any
sort of unpredictable software behavior even if no undocumented
instructions are used.
Andrew Gabriel
Michael Davidson <m...@sco.com> writes:
>
>Most of the "Halt and Catch Fire" stories relate to machines with core
>memory - perhaps inspired by one of the old PDP-11 diagnostics - the
>"worst case core heating test" ...
>
>The most credible version of this story that I have heard related to
>the Honeywell 516, where a "branch to self" instruction allegedly had
>this effect.
My recollection of "Halt and Catch Fire" instructions is that
they resulted from invalid instructions which fell through
micro-programmed instruction decodes without being trapped and
caused the processor to halt with multiple sets of bus drivers
active driving the same bus, which then overheated and damaged
themselves.
I don't know of any specific cases, but I spent some time
looking for bugs in a mini-computer's microprogram, and it would
certainly have been possible to create instruction decodes which
would do as I described above, with suitable modification of the
microprogram.
--
Andrew Gabriel
Consultant Software Engineer
freddy1X
>
> Bill
There was a line of printers( Datapoint Matrix ) at the company I used
to work for that were supposed to blow fuses if you sent certain data
patterns. At least, that's what it said in the instruction details of
the field change that we put in.
--
Caution: battery may explode if discharged or disposed of in fire
/\>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\/
/\ I may be demented \/
/\ but I'm not crazy! \/
/\<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\/
* SPAyM trap: there is no X in my address *
|| attatch FLAME here ||
\/ \/
X
Ralph Wade Phillips
Bill Bradley wrote in message <801iun$8...@gap.cco.caltech.edu>...
>
> Of course the PETs were 6502 based, but wasn't the floppy controller a
>6809?
Nope, a pair 6504's, IIRC (small address space 6502 derivative).
They accessed the RAM on alternate cycles, using the built-in memory
multiplexing of the 65xx (and 68xx) family.
The only PET that I'm aware of with a 6809 was the SuperPET, which
used the '09 as a coprocessor to enable such nicities as Watfor, WatBOL, and
the other Waterloo languages.
I'd STILL love to have one of those, with all the languages ...
RwP
Ralph Wade Phillips
John Ferrell wrote in message <38236D09...@sprintmail.com>...
>The original IBM Monochrome Display was dependent on the processor to set
up the
>controller at boot time or no sweep led to blowing something in the
monitor.
Horizontal Output Transistor, BU406 IIRC, and the flyback
transformer(LOPT or HOT to non-Murrikans) by overstressing it.
Could do the same thing, plugging it into a CGA port, since the
flyback transformer didn't have enough iron in it to sustain saturation at
the lower frequencies, and the transistor wasn't heatsunk enough for the
longer linear-on time.
RwP
bma...@iglou.com
On 1999-11-05 D...@thunderchief1.freeserve.co.uk said:
>Hi
>Thanks for all the amazing feedback on 'musical' printers and disk
>drives.
>Another thing struck me on the way to work today - Commodore PETS.
>I can't for the life of me remember which particular model, but
>wasn't there a, erm, poke or something that set the processor going
>madly in an unbreakable loop that eventually blew up the processor.
>I'm sure I remember reading this at the time (very early 80's ?)
>but does anyone else remember this?
There was a poke that could burn out the video monitor by changing the
horizontal output frequency. The 6502 processor also had an undocumented
instruction called HCF (halt and catch fire), but that didn't physically
damage anything, it just looped until power was turned off.
Net-Tamer V 1.08X - Test Drive
Markus Wandel
POKE 59458,62
Again from memory which has suffered much decay, what it did was change
an I/O line from input to output. The line connected to a signal related
to vertical sync. The ROM routines that wrote to the display would wait
until it was in vertical blank to avoid the "video snow" that otherwise
resulted. The killer POKE would fool it into seeing the display
always in vertical blank so it would write whenever. The hardware was
apparently unbothered by this.
The CURSOR tape magazine programs would issue this POKE, draw a whole screen
of stuff, then return things to normal.
The later version of the hardware did not react favourably to this I/O line
being driven, it would mess up the video timing. That this stressed
the electronics was clear from the fact that the brief stint in the "killer"
mode (a fraction of a second) often produced a bright flash followed by a
dimmed and shrunk video display that would re-expand to its former self over
the course of two seconds or so.
Of course the later hardware also had the video snow thing fixed and the
ROM no longer checked for vertical retrace, so the killer POKE disappeared.
Markus
Simon Slavin
Eric Smith <eric-no-s...@brouhaha.com> wrote:
> When claims of hardware damage due to this instruction first started
> appearing on Usenet over 15 years ago, I was convinced that it was an
> urban legend. I conducted tests on the 6809 and 6502. After more than
> 24 hours of running their HCF instructions, the processors were not
> noticably warmer than they were in normal operating condition. The
> "catch fire" part of the mnemonic is obviously a humorous interpretation
> of the resulting address bus activity, and has nothing to do with
> thermal status of the part.
It was explained to me that the 'Catch Fire' bit was a possible
side-effect of the wiring on the motherboard -- that the instruction
made the address-lines count repeatedly from 0 to FFFFFFFF and that
doing so would create eddy currents and around the address lines on
the motherboard. This would, naturally, create a magnetic field and
the field would create more eddy currents, leading to eventual
heating of the (presumably rather thin) lines until they melted.
In other words, that the HCF didn't make the processor burn-up, but
that it could conceivably make the motherboard burn-up. I have no
idea if this is the case or not.
Simon.
--
http://www.hearsay.demon.co.uk | John Peel:
No junk email please. | [My daughter] has modelled herself on you.
| Courtney Love:
| Oh, I'm so sorry.
Gene Wirchenko
[snip]
>It was explained to me that the 'Catch Fire' bit was a possible
>side-effect of the wiring on the motherboard -- that the instruction
>made the address-lines count repeatedly from 0 to FFFFFFFF and that
>doing so would create eddy currents and around the address lines on
>the motherboard. This would, naturally, create a magnetic field and
>the field would create more eddy currents, leading to eventual
>heating of the (presumably rather thin) lines until they melted.
Whereas other use of the address lines wouldn't? For this
particular explan, I smell a wabbit, um, UL.
ISTR reading it as being that some lines were tristate and the
HCF let them float. (I burned up a logic chip once by not tying down
the inputs.)
>In other words, that the HCF didn't make the processor burn-up, but
>that it could conceivably make the motherboard burn-up. I have no
>idea if this is the case or not.
No, the case isn't the motherboard.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
bon...@newsguy.com
Gene Wirchenko <ge...@shuswap.net> wrote:
>slavins.at.hearsay.demon.co.uk@localhost (Simon Slavin) wrote:
>
>[snip]
>
>>It was explained to me that the 'Catch Fire' bit was a possible
>>side-effect of the wiring on the motherboard -- that the instruction
>>made the address-lines count repeatedly from 0 to FFFFFFFF and that
>>doing so would create eddy currents and around the address lines on
>>the motherboard. This would, naturally, create a magnetic field and
>>the field would create more eddy currents, leading to eventual
>>heating of the (presumably rather thin) lines until they melted.
>
> Whereas other use of the address lines wouldn't? For this
>particular explan, I smell a wabbit, um, UL.
I'll agree that _that_ explanation is 'wabbity'.
Some hard facts:
1) CMOS gates consume essentially no power, and thus generate essentially
no heat, _when_ they are in either the 'on' or 'off' state.
2) In _trasition_ between 'on' and 'off', in _either_ direction, they
*do* consume a fair amount of power, and correspondingly generate heat.
Quite literally, hundreds to thousands (or more) of times what they
draw when in one of the 'stable' states.
3) the amount of power, and heat, is related to how _fast_ thet transition
is. 'faster' == hotter.
Given the above, it is entirely reasonable that something that flip-flopped
the *same* set of gates repeatedly -- especially if they were in physical
proximity on the chip -- that this _could_ cause an unacceptable heat build-
up, leading to 'thermal run-away', and a catastrophic failure.
*IF* that scenario developed, it could be possible to reduce, if not eliminate,
the problem by a modification of the positioning of the gates on the chip. i.e.,
spread 'em out, so the ones getting 'beat up on' were _not_ all together.
In the event of such a 're-layout' of the chip, if _all_specifications_
remained *unchanged*, this would _not_ require a modification of the
'part number' (e.g. by adding an 'A' suffix).
One would have the situation that chips with a manufacturing date-code of
XXYY or before _could_ burn up, and ones _after_ that would _not_, even though
they had *excatly* the same part number.
I do know that a DEC VAX 11/780 CPU had a vulnerability along these lines --
hackers broke into a system that a friend of mine managed, threw the machine
into the 'right' hard loop, and _did_ damage hardware.
Hardware of that vintage has all sorts of 'weird & wonderful' duty-cycle
limitations. Limitations, which if cavalierly ignored, could, and *did*
lead to fires. Dot-matrix printers being a prime example. Virtually all
of them had *severe* limits on how much 'graphics' you could print, without
letting the print-head cool down. Push things too far past that limit, and
it _would_ set the paper in the printer afire. usually about the same time
the print-head was ruined.
Newsgroups: alt.folklore.computers
Subject: Re: HCF instructions (was Re: Blowing processors)
References: <7vum6j$qke$1...@news4.svr.pol.co.uk> <qhr9i2y1...@ruckus.brouhaha.com> <B44E4BB59...@hearsay.demon.co.uk> <38292aa9...@news.shuswap.net>
Sender: bon...@newsguy.com
From: bon...@newsguy.com
Originator: bon...@newsguy.com
Followup-To: newsgroup
Organization: Not Much
X-Newsreader: trn 4.0-test69 (20 September 1998)
In article <38292aa9...@news.shuswap.net>,
Gene Wirchenko <ge...@shuswap.net> wrote:
>slavins.at.hearsay.demon.co.uk@localhost (Simon Slavin) wrote:
>
>[snip]
>
>>It was explained to me that the 'Catch Fire' bit was a possible
>>side-effect of the wiring on the motherboard -- that the instruction
>>made the address-lines count repeatedly from 0 to FFFFFFFF and that
>>doing so would create eddy currents and around the address lines on
>>the motherboard. This would, naturally, create a magnetic field and
>>the field would create more eddy currents, leading to eventual
>>heating of the (presumably rather thin) lines until they melted.
>
> Whereas other use of the address lines wouldn't? For this
>particular explan, I smell a wabbit, um, UL.
I'll agree that _that_ explanation is 'wabbity'.
Some hard facts:
1) CMOS gates consume essentially no power, and thus generate essentially
no heat, _when_ they are in either the 'on' or 'off' state.
2) In _trasition_ between 'on' and 'off', in _either_ direction, they
*do* consume a fair amount of power, and correspondingly generate heat.
Quite literally, hundreds to thousands (or more) of times what they
draw when in one of the 'stable' states.
3) the amount of power, and heat, is related to how _fast_ thet transition
is. 'faster' == hotter.
Given the above, it is entirely reasonable that something that flip-flopped
the *same* set of gates repeatedly -- especially if they were in physical
proximity on the chip -- that this _could_ cause an unacceptable heat build-
up, leading to 'thermal run-away', and a catastrophic failure.
*IF* that scenario developed, it could be possible to reduce, if not eliminate,
the problem by a modification of the positioning of the gates on the chip. i.e.,
spread 'em out, so the ones getting 'beat up on' were _not_ all together.
In the event of such a 're-layout' of the chip, if _all_specifications_
remained *unchanged*, this would _not_ require a modification of the
'part number' (e.g. by adding an 'A' suffix).
One would have the situation that chips with a manufacturing date-code of
XXYY or before _could_ burn up, and ones _after_ that would _not_, even though
they had *excatly* the same part number.
I do know that a DEC VAX 11/780 CPU had a vulnerability along these lines --
hackers broke into a system that a friend of mine managed, threw the machine
into the 'right' hard loop, and _did_ damage hardware.
Hardware of that vintage has all sorts of 'weird & wonderful' duty-cycle
limitations. Limitations, which if cavalierly ignored, could, and *did*
lead to fires. Dot-matrix printers being a prime example. Virtually all
of them had *severe* limits on how much 'graphics' you could print, without
letting the print-head cool down. Push things too far past that limit, and
it _would_ set the paper in the printer afire. usually about the same time
the print-head was ruined.
Thunderchief
Thanks everyone for the information.
Those were indeed the days...
--
Thunderchief
~ The past is tense, The future is tenser ~
fungus
bon...@newsguy.com wrote:
> >>It was explained to me that the 'Catch Fire' bit was a possible
> >>side-effect of the wiring on the motherboard -- that the instruction
> >>made the address-lines count repeatedly from 0 to FFFFFFFF and that
> >>doing so would create eddy currents and around the address lines on
> >>the motherboard.
> > Whereas other use of the address lines wouldn't? For this
> >particular explan, I smell a wabbit, um, UL.
>
> I'll agree that _that_ explanation is 'wabbity'.
>
> Some hard facts:
> 1) CMOS gates consume essentially no power, and thus generate essentially
> no heat, _when_ they are in either the 'on' or 'off' state.
> 2) In _trasition_ between 'on' and 'off', in _either_ direction, they
> *do* consume a fair amount of power, and correspondingly generate heat.
> Quite literally, hundreds to thousands (or more) of times what they
> draw when in one of the 'stable' states.
>
> Given the above, it is entirely reasonable that something that flip-flopped
> the *same* set of gates repeatedly -- especially if they were in physical
> proximity on the chip -- that this _could_ cause an unacceptable heat build-
> up, leading to 'thermal run-away', and a catastrophic failure.
>
Are you saying that running a normal program doesn't flip the address
lines quickly?
> 3) the amount of power, and heat, is related to how _fast_ thet transition
> is. 'faster' == hotter.
Well, yeees... but it's hard to see how a CPU could cycle the lines
faster than its normal clock speed.
dave pierson
Long ago and far far away....
The class of entry level techs was being taught to tune memory.
Core memory. With REAL cores & settable sense amps. At one point
the scope probe lsipped a bit, but the procedure was completed.
However, the thing would not boot thereafter. Instructors huddled
& finally decided the core stack had been blown....
A few Years Later (but still in the days of real core....):
The particular system had a Real Power switch with Real 110vac
on the front panel. On faston tabs. And sundry DC supplies for
the lamps. ALSO on faston tabs. For reasons lost in the mists,
the front panel had to be changed. Off came all the data cables.
Off came all the DC cables. Off came the AC cables.
Reassemble in reverse order. Power up and...... Remember all
those faston tabs??? flashed bit (IIR) all thru the dat cables
and back into the modules...
Actually, earlier. On a mainframe. So The Story goes, there
was a change required to the master clear, which went thruout
the system. In those days, this meant pulling and removing
individual wires. (Wire wrap, natch...) Welllll someone had
a gun with a defective ground on the tip. Master Clear
goes throut the system....
--
thanks
dave pierson |the facts, as accurately as i can manage,
Smart Modular Technology |the opinions, my own.
334 South St |
Shrewsbury, Mass |pie...@mail.dec.com
"He has read everything, and, to his credit, written nothing." A J
Raffles
"Internet: net of a million lies..." after Vernor Vinge
bon...@newsguy.com
fungus <sp...@egg.chips.and.spam.com> wrote:
>
>
>bon...@newsguy.com wrote:
>> >>It was explained to me that the 'Catch Fire' bit was a possible
>> >>side-effect of the wiring on the motherboard -- that the instruction
>> >>made the address-lines count repeatedly from 0 to FFFFFFFF and that
>> >>doing so would create eddy currents and around the address lines on
>> >>the motherboard.
>> >particular explan, I smell a wabbit, um, UL.
>>
>> I'll agree that _that_ explanation is 'wabbity'.
>>
>> Some hard facts:
>> 1) CMOS gates consume essentially no power, and thus generate essentially
>> no heat, _when_ they are in either the 'on' or 'off' state.
>> 2) In _trasition_ between 'on' and 'off', in _either_ direction, they
>> *do* consume a fair amount of power, and correspondingly generate heat.
>> Quite literally, hundreds to thousands (or more) of times what they
>> draw when in one of the 'stable' states.
>>
>> the *same* set of gates repeatedly -- especially if they were in physical
>> proximity on the chip -- that this _could_ cause an unacceptable heat build-
>> up, leading to 'thermal run-away', and a catastrophic failure.
>>
>
>lines quickly?
I am saying that it is *very* unlikely to be changing the _same_ address
lines every cycle. the closest thing is a 'jump to here' loop that
will beat up on a minimal number of memory locaions (at least 2, probably
3 or 4). this is a far cry from a _single_ instruction that toggles
all lines from 0 to 1 (or back) _every_ cycle. w/o having to do a
memory fetch for the next instruction, you're probably looking at something
like 8x as many gate transitions per cycle, and those gates are getting
pounded on *every* cycle, not average every third one, or so, on even
a -tight- loop.
>
>> 3) the amount of power, and heat, is related to how _fast_ thet transition
>> is. 'faster' == hotter.
>
>Well, yeees... but it's hard to see how a CPU could cycle the lines
>faster than its normal clock speed.
_some_ lines change, obviously. not necessarily the _same_ ones every
time, and definitely not *all* of them.
it is a question of the 'density' of the gates being affected, and how
often _they_ change. Too many transitions too fast in too little real-
estate and it burns up.
Think of 'rubbing two sticks together to make a fire'.
if you have 5 sets of sticks, and just twirl each one in rotation,
in all probability, you'll *never* get a fire started. If you
twirl one set _continuously_ you _can_ 'burn it up'.
Ignatios Souvatzis
bon...@newsguy.com writes:
> Some hard facts:
> 1) CMOS gates consume essentially no power, and thus generate essentially
> no heat, _when_ they are in either the 'on' or 'off' state.
> 2) In _trasition_ between 'on' and 'off', in _either_ direction, they
> *do* consume a fair amount of power, and correspondingly generate heat.
> Quite literally, hundreds to thousands (or more) of times what they
> draw when in one of the 'stable' states.
> 3) the amount of power, and heat, is related to how _fast_ thet transition
> is. 'faster' == hotter.
partially incorrect, I think.
The amoutn of power depends on how long they are in the transistional area.
That is, if you switch them _often_, they get hot, and if it takes you a long
time to switch them, they get hot.
Therefor, switching them _fast_ is better. The limit (besides the input signal)
is the capacitive load of the output.
Now, switching them at a high frequency, all other parameters being the
same, certainly makes them run hotter...
Regards,
-is
--
* Progress (n.): The process through which Usenet has evolved from
smart people in front of dumb terminals to dumb people in front of
smart terminals. -- o...@burnout.demon.co.uk (obscurity)
Simon Slavin
ge...@shuswap.net (Gene Wirchenko) wrote:
> ISTR reading it as being that some lines were tristate and the
> HCF let them float. (I burned up a logic chip once by not tying down
> the inputs.)
That sounds more likely. Could you explain how a floating line could
do this ? I don't know that kind of electronics.
Gene Wirchenko
>In article <38292aa9...@news.shuswap.net>,
>ge...@shuswap.net (Gene Wirchenko) wrote:
>
>> ISTR reading it as being that some lines were tristate and the
>> HCF let them float. (I burned up a logic chip once by not tying down
>> the inputs.)
>
>That sounds more likely. Could you explain how a floating line could
>do this ? I don't know that kind of electronics.
I don't understand it much myself and might have details wrong.
As I understand, if you don't tie input lines to something stable,
they can oscillate and that can result in the magic smoke escaping.
(Some electronics engineer has probably just died laughing.)
jmfb...@aol.com
ge...@shuswap.net (Gene Wirchenko) wrote:
>slavins.at.hearsay.demon.co.uk@localhost (Simon Slavin) wrote:
>
>>In article <38292aa9...@news.shuswap.net>,
>>ge...@shuswap.net (Gene Wirchenko) wrote:
>>
>>> ISTR reading it as being that some lines were tristate and the
>>> HCF let them float. (I burned up a logic chip once by not tying down
>>> the inputs.)
>>
>>That sounds more likely. Could you explain how a floating line could
>>do this ? I don't know that kind of electronics.
>
> I don't understand it much myself and might have details wrong.
>As I understand, if you don't tie input lines to something stable,
>they can oscillate and that can result in the magic smoke escaping.
>
> (Some electronics engineer has probably just died laughing.)
Only the ones worth their smoke.
/BAH
Subtract a hundred and four for e-mail.
Jerry Bauer
Simon Slavin <slavins.at.hearsay.demon.co.uk@localhost> wrote:
>In article <38292aa9...@news.shuswap.net>,
>ge...@shuswap.net (Gene Wirchenko) wrote:
>
>> ISTR reading it as being that some lines were tristate and the
>> HCF let them float. (I burned up a logic chip once by not tying down
>> the inputs.)
>
>That sounds more likely. Could you explain how a floating line could
>do this ? I don't know that kind of electronics.
>
I'll give it a shot -- hardware made simple, for the software engineer:
In another branch of this thread, it has been stated that running faster
means running hotter. That's true, too, and for much the same reason.
Consider two inverters in series:
(You'd best be in a monospaced font here!)
|\ |\
In --------| >o--M--| >o--- Out
|/ |/
This looks like this to an EE:
+ +
_| _|
|-|[_p0 |-||_p1
In ----| |--m-| |---- Out
| _| | _|
|-|[_n0 |-||_n1
| |
V V
Those little three-sided squares with letters in them are transistors,
and the little vertical lines to the left of each is the "gate" of the
transistor. The little '+' symbols identify the positive voltage
supply, and the 'V' symbols identify the circuit ground. By
convention, current flows from the positive supply to ground, when it
can.
This kind of process is called CMOS, for Complementary
Metal-Oxide-Semiconductor (or Silicon). Complementary, because both
polatities of transistor (p and n) are used and they complement each
other, and Metal-Oxide-Something because, when the term was
invented. the gate was metal, and was separated from the substrate by
a layer of oxididized substrate material. Now, the gate is usually a
layer of doped ploycrystalline silicon and metal is used exclusively
for conductors.
These transistors can be considered to be boolean switches; that is,
any analog behavior can be disregarded for this explanation (except
for a little bit of "where-does-the-energy-go?" below. The top two
transistors are "P-type", and the bottom two are "n-type".
An n-type transistor conducts when the voltage on its gate is greater
than a certain threshold, and a p-type transistor conducts when the
voltage on its gate is less than a (different) certain threshold.
When the voltage on the input ("In") is high (a digital logic '1'), the
leftmost p-type transistor p0 is off and the leftmost n-type
transistor n0 is on. This makes the middle connection ("m")
disconnected from '+' and connected to 'V', i.e. it is low (a digital
logic '0').
Because 'm' is low, p1 is on and n1 is off, so "Out" is connected to
'+' and disconnected from 'V' (a digital logic '1'). "Out" tracks "In".
The switching ranges for the p-type and n-type switches overlap.
There is a middle range of voltages such that if "In" is somewhere
between '+' and 'V', both p0 and n0 are on, conducting. It should
come as no surprise that these transistors are not perfect conductors
(duh! -- they're semiconductors!), so there is some Ohm's law stuff
going on here. When they are off, they are (very) high-valued
resistors, when they are on, they are low-valued resistors. When they
are both on, they form a low-valued resistor between '+' and 'V'.
In normal operation, this "short" from power to ground occurs briefly
each time "In" switches from high to low or back. Each time the short
occurs, the current through the resistors becomes heat. The more
state transitions per unit time, the more heat per unit time. There
is another reason, it has to do with charge stored on 'm' while "In"
is low and then discharged when "In" goes high. A first-order
approximation of this treats p0-n0 as a variable resistor, with value
proportional to the frequency of "In". Working together, these two
effects account for (much of) the relation between operating frequency
and temperature.
However, if "In" is allowed to remain at a voltage level that allows
both p0 and n0 to conduct, the resulting static short can cause the
temperature to increase to the point where the circuit could be
damaged. In practice, this is not common because circuit designers
often bias the inputs so they do not float to "bad" levels, and
because MOS transistors are typically thermally self-limiting,
i.e. their resistance increases with temperature; they tend to turn
off as they heat up.
I worked as a test engineer for a company that second-sourced the
Motorola 6800. I do not recall using an HCF instruction in the test
program. In fact, the address lines and program counter were tested
by forcing a NOP on the databus, and watching the address lines
increment at the instruction-fetch rate. I suspect, but cannot
confirm, that HCF was a consequence of partial decoding of the
instruction set. It seems unnecessary, as tying the data bus to NOP
accomplishes pretty much the same thing. I also suspect that HCF
would not damage the processor, again, I cannot confirm this.
Jerry Randal Bauer