7 Jun
2002
7 Jun
'02
1:56 p.m.
You're actually taking the "catch fire" *literally*? Silicon doesn't
burn
*that* well. Well, except for an Athlon (and if you haven't seen the
smoking Athlon video on www.tomshardware.com, I recommend checking it out.
It's entertaining). However, much like 3 voltage EPROM socketted backwards,
the 6800 would get boiling hot for short time before it failed.
It wasn't like there was actual flames jetting out of the thing. That'd be
silly.
I have a record of it somewhere, I'm sure. Accessibility is another thing.
Living on a houseboat, 90% of my stuff is in boxes in a warehouse. Since
I've been inclined to try and fire up the IMSAI lately, I'll try to find the
notes from the period.
--John
-----Original Message-----
From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org]On
Behalf Of Richard Erlacher
Sent: Friday, June 07, 2002 14:44
To: cctalk(a)classiccmp.org
Subject: Re: [CCTECH] Interesting tidbit on 6502
HORSEFEATHERS!
I've got one of the first few dozen 6800 parts that were ever allowed
outside
the plant, and it's not even marked XC. It's simply marked SAMPLE and is
otherwise unmarked. However, based on when I got it, it has to be a very
early part.
I don't for a moment doubt that there were things that could have caused an
internal failure. However, I do very much doubt that there was a specific,
if
undocumented, instruction that could bring such a failure about. If there
is,
then please tell us all about it. Then tell us how that would cause the
device to catch fire, will you?
Dick
----- Original Message -----
From: "Jim Battle" <frustum(a)pacbell.net>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 9:21 AM
Subject: RE: [CCTECH] Interesting tidbit on 6502
a
At 11:00 AM 6/7/02 -0400, you wrote:
> Why don't you learn that you don't always know what you're
> talking about?
>
> Indeed, the first step level of the 6800 had an undocumented
> opcode that
>results in 3 particular transistors turning on that connected Vcc to GND.
>The damage caused by these three transistors shorting damaged the silicon
in
the immediate
area, rendering the CPU useless.
The R2000 MIPS CPU's had a similar problem. The TLB was implemented via a
small CAM. If more than one entry matched the virtual address, there was fight between two different words attempting to drive
the output
bitlines. This wouldn't be a problem other than the fact that the TLB
contents were managed by software. Granted, the code would be supervisor
code and not user code, but when developing the supervisor software, there
was always the danger that buggy software could damage the chip.
I believe this was fixed in R3000 and later parts.
-----
Jim Battle == frustum(a)pacbell.net