6 Jun
2002
6 Jun
'02
10:56 a.m.
While browsing sites for 6800 information, I came across this quote from
<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Mostec>.
which talks about the design goals for the 650x in comparison to the 6800.
The design goal was a low-cost (smaler chip) design,
realized by
simplifying the decoder stage. There were no instructions with the
value
xxxxxx11, reducing the 1-of-4 decoder to a single NAND gate. Instructions
with the value xxxxxx11 actually executed two instructions in paralell, some
of them useful. <
Now, I didn't look at an opcode map, but it seems that this is an
interesting twist that I've never seen quoted when people discussed the
mysterious undocumented 6502 opcodes executing what appeared to be multiple
instructions.
Any thoughts?
Rich
==========================
Richard A. Cini, Jr.
Congress Financial Corporation
1133 Avenue of the Americas
30th Floor
New York, NY 10036
(212) 545-4402
(212) 840-6259 (facsimile)
_______________________________________________
cctech mailing list
cctech(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctech
6 Jun
6 Jun
12:44 p.m.
On Thu, 6 Jun 2002, Cini, Richard wrote:
While browsing sites for 6800 information, I came
across this quote from
<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Mostec>.
which talks about the design goals for the 650x in comparison to the 6800.
That is indeed very enlightening. I'd always known about the
"undocumented opcodes" but never ventured to use them. However, this is
pretty much what I guessed was going on (though my hankering was not as
technically astute as the reality).
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
_______________________________________________
cctech mailing list
cctech(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctech
The design goal was a low-cost (smaler chip)
design, realized by
simplifying the decoder stage. There were no instructions with
the value
xxxxxx11, reducing the 1-of-4 decoder to a single NAND gate. Instructions
with the value xxxxxx11 actually executed two instructions in paralell, some
of them useful. <
Now, I didn't look at an opcode map, but it seems that this is an
interesting twist that I've never seen quoted when people discussed the
mysterious undocumented 6502 opcodes executing what appeared to be multiple
instructions.
Any thoughts? 
7 Jun
7 Jun
3:12 p.m.
Sellam Ismail wrote:
"undocumented opcodes" but never ventured to
use them. However, this is
These are things that engineering says not to depend on, the documentation
says not to use, and that during the next development cycle, sales says
is an absolutely necessary feature.
-chuck
6 Jun
6 Jun
1:14 p.m.
One of the more interesting features of the 6502 is that when you're looking
at the data bus, it shows you what last was on the bus in those cases where
there's nothing present to drive the data-in bus. This will give you
information useful in figuring out what is going inside the chip, and, that's
what gave me the clues that convinced me that the reason the 6502 is so cheap
on silicon is that it doesn't use counters for its registers, but, rather,
uses simple gated latches and uses the ALU to operate on the addresses during
phase-2 while operating on the data during phase-1.
If you look at what's required to build a synchronous counter large enough to
support the simple register set in the 6502 you'll see that the saved gates
are sufficient to warrant its design in exactly that way, and that it would
yield a significant savings in silicon. It allows you to use a relatively
complex ALU, together with a register set that's essentially a small RAM array
with an instruction set that never operates on two registers in a single
cycle. If you build the PC, the address bus registers, the SP, the two index
registers, and the accumulator as 8-bit registers, it's easy to see why one
would do things that way. I'm not sure anybody has ever taken a really close
look at what happens when each possible opcode is fed to the 6502 as the first
instruction after a reset and then recorded what the CPU does with it right up
to the next SYNC, signalling that a new opcode is being fetched, but it might
be a useful extension on what's been done. Of course, the 6502 is of little
interest to persons planning any practical endeavors, so this fits squarely
under the aegis of this forum.
Dick
----- Original Message -----
From: "Cini, Richard" <RCini(a)congressfinancial.com>
To: "'CCLTech'" <cctech(a)classiccmp.org>
Sent: Thursday, June 06, 2002 1:56 PM
Subject: [CCTECH] Interesting tidbit on 6502
While browsing sites for 6800 information, I came
across this quote from
<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Mostec>.
which talks about the design goals for the 650x in comparison to the 6800.
The design goal was a low-cost (smaler chip)
design, realized by
simplifying the decoder stage. There were no instructions with
the value
xxxxxx11, reducing the 1-of-4 decoder to a single NAND gate. Instructions
with the value xxxxxx11 actually executed two instructions in paralell, some
of them useful. <
Now, I didn't look at an opcode map, but it seems that this is an
interesting twist that I've never seen quoted when people discussed the
mysterious undocumented 6502 opcodes executing what appeared to be multiple
instructions.
Any thoughts?
Rich
==========================
Richard A. Cini, Jr.
Congress Financial Corporation
1133 Avenue of the Americas
30th Floor
New York, NY 10036
(212) 545-4402
(212) 840-6259 (facsimile)
_______________________________________________
cctech mailing list
cctech(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctech
4:54 p.m.
Richard Erlacher wrote:
One of the more interesting features of the 6502 is that when you're looking
at the data bus, it shows you what last was on the bus in those cases where
there's nothing present to drive the data-in bus. This will give you
information useful in figuring out what is going inside the chip, and, that's
what gave me the clues that convinced me that the reason the 6502 is so cheap
on silicon is that it doesn't use counters for its registers, but, rather,
uses simple gated latches and uses the ALU to operate on the addresses during
phase-2 while operating on the data during phase-1.
If you look at what's required to build a synchronous counter large enough to
support the simple register set in the 6502 you'll see that the saved gates
are sufficient to warrant its design in exactly that way, and that it would
yield a significant savings in silicon. It allows you to use a relatively
complex ALU, together with a register set that's essentially a small RAM array
with an instruction set that never operates on two registers in a single
cycle. If you build the PC, the address bus registers, the SP, the two index
registers, and the accumulator as 8-bit registers, it's easy to see why one
would do things that way. I'm not sure anybody has ever taken a really close
look at what happens when each possible opcode is fed to the 6502 as the first
instruction after a reset and then recorded what the CPU does with it right up
to the next SYNC, signalling that a new opcode is being fetched, but it might
be a useful extension on what's been done. Of course, the 6502 is of little
interest to persons planning any practical endeavors, so this fits squarely
under the aegis of this forum.
I think that the 6100 (PDP-8 on a chip) fit this model better.
8 bit cpu's often used random logic thus don't cares and unimplimented
opcodes
could change actions between cpu mask revisions. Other than the 6800
HCF
instruction ( Halt and Catch on Fire ) most undefined instructions
are mostly harmess.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
5:43 p.m.
One of the things that kept the 6502 cheaper than the average microprocessor
was that there weren't any such changes of which I was made aware until the
CMOS parts were released. These had several different instruction sets, for
some odd reason, mostly thanks to Rockwell, I think, but the unimplemented
opcodes were, IIRC, implemented as NOP's. New features included such things
as waits on write cycles, and no bogus reads on indexed instructions. This
fouled up some hardware/software interactions.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <cctalk(a)classiccmp.org>
Sent: Thursday, June 06, 2002 7:54 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
Richard Erlacher wrote:
>
> One of the more interesting features of the 6502 is that when you're
looking
> at the data bus, it shows you what last was on
the bus in those cases
where
> there's nothing present to drive the data-in
bus. This will give you
> information useful in figuring out what is going inside the chip, and,
that's
> what gave me the clues that convinced me that the
reason the 6502 is so
cheap
> on silicon is that it doesn't use counters
for its registers, but, rather,
> uses simple gated latches and uses the ALU to operate on the addresses
during
> phase-2 while operating on the data during
phase-1.
>
> If you look at what's required to build a synchronous counter large enough
to
> support the simple register set in the 6502
you'll see that the saved
gates
> are sufficient to warrant its design in exactly
that way, and that it
would
> yield a significant savings in silicon. It
allows you to use a relatively
> complex ALU, together with a register set that's essentially a small RAM
array
> with an instruction set that never operates on
two registers in a single
> cycle. If you build the PC, the address bus registers, the SP, the two
index
> registers, and the accumulator as 8-bit
registers, it's easy to see why
one
> would do things that way. I'm not sure
anybody has ever taken a really
close
> look at what happens when each possible opcode is
fed to the 6502 as the
first
> instruction after a reset and then recorded what
the CPU does with it
right up
> to the next SYNC, signalling that a new opcode is
being fetched, but it
might
> be a useful extension on what's been done.
Of course, the 6502 is of
little
> interest to persons planning any practical
endeavors, so this fits
squarely
under the
aegis of this forum.
I think that the 6100 (PDP-8 on a chip) fit this model better.
8 bit cpu's often used random logic thus don't cares and unimplimented
opcodes
could change actions between cpu mask revisions. Other than the 6800
HCF
instruction ( Halt and Catch on Fire ) most undefined instructions
are mostly harmess.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
8:34 p.m.
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
Richard Erlacher wrote:
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
One of the more interesting features of the 6502
is that when you're looking
at the data bus, it shows you what last was on
the
bus in those cases where
there's nothing present to drive the data-in
bus.
This will give you
information useful in figuring out what is going
inside the chip, and, that's
what gave me the clues that convinced me that the
reason the 6502 is so cheap
on silicon is that it doesn't use counters
for its
registers, but, rather,
uses simple gated latches and uses the ALU to
operate on the addresses during
phase-2 while operating on the data during
phase-1.
If you look at what's required to build a
synchronous counter large enough to
support the simple register set in the 6502
you'll
see that the saved gates
are sufficient to warrant its design in exactly
that way, and that it would
yield a significant savings in silicon. It
allows
you to use a relatively
complex ALU, together with a register set
that's
essentially a small RAM array
with an instruction set that never operates on
two
registers in a single
cycle. If you build the PC, the address bus
registers, the SP, the two index
registers, and the accumulator as 8-bit
registers,
it's easy to see why one
would do things that way. I'm not sure
anybody
has ever taken a really close
look at what happens when each possible opcode is
fed to the 6502 as the first
instruction after a reset and then recorded what
the CPU does with it right up
to the next SYNC, signalling that a new opcode is
being fetched, but it might
be a useful extension on what's been done.
Of
course, the 6502 is of little
interest to persons planning any practical
endeavors, so this fits squarely
under the aegis of this forum.
I think that the 6100 (PDP-8 on a chip) fit this
model better.
8 bit cpu's often used random logic thus don't cares
and unimplimented
opcodes
could change actions between cpu mask revisions.
Other than the 6800
HCF
instruction ( Halt and Catch on Fire ) most
undefined instructions
are mostly harmess.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
9:04 p.m.
Loboyko Steve wrote:
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
Not on the 6800 but I believe some FORTH chips have that problem.
This instruction for the 6800 if remember right just continually
increments the address bus, ignoring any data read. Only a hard
RESET will reset the machine from this state. I think the opcode
is $00.
7 Jun
7 Jun
4:26 a.m.
This only occurred in the very first step level of the 6800 released, IIRC.
You'd be hard pressed to find any parts with this flaw. And even if you
should wind up flaming a part (which are astromical odds these days), 6800s
are still readily available.
--John
-----Original Message-----
From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org]On
Behalf Of Ben Franchuk
Sent: Friday, June 07, 2002 02:04
To: cctalk(a)classiccmp.org
Subject: Re: [CCTECH] Interesting tidbit on 6502
Loboyko Steve wrote:
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
Not on the 6800 but I believe some FORTH chips have that problem.
This instruction for the 6800 if remember right just continually
increments the address bus, ignoring any data read. Only a hard
RESET will reset the machine from this state. I think the opcode
is $00.
5:15 a.m.
It's crap like this that causes the confusion that Steve pointed out.
Why can't we keep some distance between fact and facetious fiction for the
benefit of those whose knowledge is largely semantic?
Dick
----- Original Message -----
From: "J.C. Wren" <jcwren(a)jcwren.com>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 7:26 AM
Subject: RE: [CCTECH] Interesting tidbit on 6502
This only occurred in the very first step level of the
6800 released, IIRC.
You'd be hard pressed to find any parts with this flaw. And even if you
should wind up flaming a part (which are astromical odds these days), 6800s
are still readily available.
--John
-----Original Message-----
From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org]On
Behalf Of Ben Franchuk
Sent: Friday, June 07, 2002 02:04
To: cctalk(a)classiccmp.org
Subject: Re: [CCTECH] Interesting tidbit on 6502
Loboyko Steve wrote:
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
Not on the 6800 but I believe some FORTH chips have that problem.
This instruction for the 6800 if remember right just continually
increments the address bus, ignoring any data read. Only a hard
RESET will reset the machine from this state. I think the opcode
is $00.
6 a.m.
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.
But since the shop I worked for only flamed out 2 Sphere-II 6800 CPUs
before the Motorola FAE defined the problem and gave us new parts, it
probably didn't really happen, since you said it's fiction.
--John
-----Original Message-----
From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org]On
Behalf Of Richard Erlacher
Sent: Friday, June 07, 2002 10:16
To: cctalk(a)classiccmp.org
Subject: Re: [CCTECH] Interesting tidbit on 6502
It's crap like this that causes the confusion that Steve pointed out.
Why can't we keep some distance between fact and facetious fiction for the
benefit of those whose knowledge is largely semantic?
Dick
----- Original Message -----
From: "J.C. Wren" <jcwren(a)jcwren.com>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 7:26 AM
Subject: RE: [CCTECH] Interesting tidbit on 6502
This only occurred in the very first step level of the
6800 released,
IIRC.
You'd be hard pressed to find any parts with this
flaw. And even if you
should wind up flaming a part (which are astromical odds these days),
6800s
are still readily available.
--John
-----Original Message-----
From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org]On
Behalf Of Ben Franchuk
Sent: Friday, June 07, 2002 02:04
To: cctalk(a)classiccmp.org
Subject: Re: [CCTECH] Interesting tidbit on 6502
Loboyko Steve wrote:
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
Not on the 6800 but I believe some FORTH chips have that problem.
This instruction for the 6800 if remember right just continually
increments the address bus, ignoring any data read. Only a hard
RESET will reset the machine from this state. I think the opcode
is $00.
6:21 a.m.
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 a
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
9:44 a.m.
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
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 a
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
9:56 a.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
10:18 a.m.
see below, plz.
Dick
----- Original Message -----
From: "J.C. Wren" <jcwren(a)jcwren.com
To: <cctalk(a)classiccmp.org
Sent: Friday, June 07, 2002 12:56 PM
Subject: RE: [CCTECH] Interesting tidbit on 6502
Many NMOS parts would get pretty hot,
particularly if you considered simply
hot-to-the-touch as being hot. The 2147's in my early fast 6502's were seldom
cool enough to touch without making a sound, both vocally and from the sizzle,
once they'd been powered up for more than 10 minutes and exercised. We even
had a routine in the memory diagnostic that was intended to heat the memories.
It certainly did that. There were four boards of these 2147's and you could
tell which one was being exercised simply by holding a finger over the board.
70 degrees Celsius (the upper limit of "industrial" temperature range) is
pretty hot!
> 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
> > 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
> a
> > 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
> >
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.
What normally catches fire is the PCB. However, lots of parts got plenty hot
in normal usage. Many wouldn't run on an extender board because of the added
capacitance and path lengths, but, often enough, it was because, out of the
normal cardcage forced-air cooling, the parts got so hot they no longer worked
within the limts to which the system was designed.
6:31 a.m.
"J.C. Wren" 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.
But since the shop I worked for only flamed out 2 Sphere-II 6800 CPUs
before the Motorola FAE defined the problem and gave us new parts, it
probably didn't really happen, since you said it's fiction.
Since this was a early and rare version of the 6800 and most of my
information
is second hand stuff (general computer books vs data sheets )
information
like this is useful trivia. Even modern chips can have hard to find
bugs,
like the pentium division bug.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
9:47 a.m.
... regarding that Pentium FDIV bug ... my understanding from the guys on the
inside is that they knew about the bug for nearly a year before the buggy
parts were released. The management made the decision that since many of
their customers didn't need the FDIV instruction, they could sucessfully build
hardware around it with no ill effects. The home PC market, after all, was
then still an insignificant part of their market. They knew well in advance
that they'd be replacing the "buggy" parts, but had to start getting some
of
their NRE back in order to avoid the IRE of top management.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 9:31 AM
Subject: Re: [CCTECH] Interesting tidbit on 6502
"J.C. Wren" 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.
>
> But since the shop I worked for only flamed out 2 Sphere-II 6800
CPUs
before the
Motorola FAE defined the problem and gave us new parts, it
probably didn't really happen, since you said it's fiction.
Since this was a early and rare version of the 6800 and most of my
information
is second hand stuff (general computer books vs data sheets )
information
like this is useful trivia. Even modern chips can have hard to find
bugs,
like the pentium division bug.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
5:12 a.m.
I don't see an HCF in the Mot listings of their instruction set.
I've heard about this fiction over several decades now, and, surely, it must
be clear to you that there's no way the microprocessor can cause that effect
without the aid of external hardware.
We used to joke about a BEO instruction (branch and execute operator) but I've
never seen the effects of that one either.
Dick
----- Original Message -----
From: "Loboyko Steve" <sloboyko(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Thursday, June 06, 2002 11:34 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
I'm building a 6800 machine right now and I was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that will
overheat the chip?
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
Richard Erlacher wrote:
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
One of the more interesting features of the 6502
is that when you're looking
at the data bus, it shows you what last was on
the
bus in those cases where
there's nothing present to drive the data-in
bus.
This will give you
information useful in figuring out what is going
inside the chip, and, that's
what gave me the clues that convinced me that the
reason the 6502 is so cheap
on silicon is that it doesn't use counters
for its
registers, but, rather,
uses simple gated latches and uses the ALU to
operate on the addresses during
phase-2 while operating on the data during
phase-1.
If you look at what's required to build a
synchronous counter large enough to
support the simple register set in the 6502
you'll
see that the saved gates
are sufficient to warrant its design in exactly
that way, and that it would
yield a significant savings in silicon. It
allows
you to use a relatively
complex ALU, together with a register set
that's
essentially a small RAM array
with an instruction set that never operates on
two
registers in a single
cycle. If you build the PC, the address bus
registers, the SP, the two index
registers, and the accumulator as 8-bit
registers,
it's easy to see why one
would do things that way. I'm not sure
anybody
has ever taken a really close
look at what happens when each possible opcode is
fed to the 6502 as the first
instruction after a reset and then recorded what
the CPU does with it right up
to the next SYNC, signalling that a new opcode is
being fetched, but it might
be a useful extension on what's been done.
Of
course, the 6502 is of little
interest to persons planning any practical
endeavors, so this fits squarely
under the aegis of this forum.
I think that the 6100 (PDP-8 on a chip) fit this
model better.
8 bit cpu's often used random logic thus don't cares
and unimplimented
opcodes
could change actions between cpu mask revisions.
Other than the 6800
HCF
instruction ( Halt and Catch on Fire ) most
undefined instructions
are mostly harmess.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
5:57 a.m.
Well, it isn't beyond the realm of possibility that an
unimplemented op code or strange code could do
something bad to the states of a chip, potentially
overheating the i/o interfaces.
For example, the PII/III...etc are designed to shut
down certain subsystems when they aren't used (the
floating point, part, for example). Certain software
can force the processor ro keep everything on and get
the chip to its maximum temperature, possibly causing
a machine with marginal construction or marginal
internal/external thermal management to fail.
Also, I was thinking that some of these "smart cards"
might be designed to self-destruct upon execution of
an unimplemented opcode. Maybe a military processor in
a dangerous device might be designed this way also, so
that the computer would crash and immediately
self-destruct before doing something, shall we say,
"unexpected".
So, I don't think my question was THAT unreasonable. I
am working with 75/76 dated chips marked "XC", also,
so I probably DO have the first externally available
silicon or nearly so.
--- Richard Erlacher <edick(a)idcomm.com> wrote:
I don't see an HCF in the Mot listings of their
instruction set.
I've heard about this fiction over several decades
now, and, surely, it must
be clear to you that there's no way the
microprocessor can cause that effect
without the aid of external hardware.
We used to joke about a BEO instruction (branch and
execute operator) but I've
never seen the effects of that one either.
Dick
----- Original Message -----
From: "Loboyko Steve" <sloboyko(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Thursday, June 06, 2002 11:34 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
I'm building a 6800 machine right now and I
was
wondering about this "Halt and Catch on Fire"
instruction. Is this for real. This is a serious
question. Is there actually an instruction that
will
overheat the chip?
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
> Richard Erlacher wrote:
> >
> > One of the more interesting features of the
6502
> is that when you're looking
> > at the data bus, it shows you what last was on
the
> bus in those cases where
> > there's nothing present to drive the data-in
bus.
> This will give you
> > information useful in figuring out what is
going
> inside the chip, and, that's
> > what gave me the clues that convinced me that
the
> reason the 6502 is so cheap
> > on silicon is that it doesn't use counters for
its
> registers, but, rather,
> > uses simple gated latches and uses the ALU to
> operate on the addresses during
> > phase-2 while operating on the data during
> phase-1.
> >
> > If you look at what's required to build a
> synchronous counter large enough to
> > support the simple register set in the 6502
you'll
> see that the saved gates
> > are sufficient to warrant its design in
exactly
> that way, and that it would
> > yield a significant savings in silicon. It
allows
> you to use a relatively
> > complex ALU, together with a register set
that's
> essentially a small RAM array
> > with an instruction set that never operates on
two
> registers in a single
> > cycle. If you build the PC, the address bus
> registers, the SP, the two index
> > registers, and the accumulator as 8-bit
registers,
> it's easy to see why one
> > would do things that way. I'm not sure
anybody
> has ever taken a really close
> > look at what happens when each possible opcode
is
> fed to the 6502 as the first
> > instruction after a reset and then recorded
what
> the CPU does with it right up
> > to the next SYNC, signalling that a new opcode
is
> being fetched, but it might
> > be a useful extension on what's been done. Of
> course, the 6502 is of little
> > interest to persons planning any practical
> endeavors, so this fits squarely
> > under the aegis of this forum.
>
> I think that the 6100 (PDP-8 on a chip) fit this
> model better.
> 8 bit cpu's often used random logic thus don't
cares
and
unimplimented
opcodes
could change actions between cpu mask revisions.
Other than the 6800
HCF
instruction ( Halt and Catch on Fire ) most
undefined instructions
are mostly harmess.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
9:38 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Loboyko Steve" <sloboyko(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 8:57 AM
Subject: Re: [CCTECH] Interesting tidbit on 6502
Well, it isn't beyond the realm of possibility
that an
unimplemented op code or strange code could do
something bad to the states of a chip, potentially
overheating the i/o interfaces.
If you check the datasheets, I think you'll agree that's not very likely,
so
long as you don't violate the absolute maxima.
For example, the PII/III...etc are designed to shut
down certain subsystems when they aren't used (the
floating point, part, for example). Certain software
can force the processor ro keep everything on and get
the chip to its maximum temperature, possibly causing
a machine with marginal construction or marginal
internal/external thermal management to fail.
The Pentium-class processors of today, and, in fact, any of today's designs,
are so different from the old 6502 types, that it's not helpful to try to
extrapolate backward from the one technology to the other. 6502-based systems
were so simple and easy to design correctly, seldom requiring more than a
day's effort to design, though the drafting could take longer, that it's
unlikely any such concerns would arise.
Also, I was thinking that some of these "smart cards"
might be designed to self-destruct upon execution of
an unimplemented opcode. Maybe a military processor in
a dangerous device might be designed this way also, so
that the computer would crash and immediately
self-destruct before doing something, shall we say,
"unexpected".
... and what would they (smart-cards) have to do with the old 6502 or 6800?
So, I don't think my question was THAT unreasonable. I
am working with 75/76 dated chips marked "XC", also,
so I probably DO have the first externally available
silicon or nearly so.
If you stop and think about it, there's nothing that one instruction stream
will cause the chip to do that another wouldn't. If you allow yourself to
assume worst-case conditions of loading on the address and data bus pins,
among others, I don't think you'll have any trouble convincing yourself of
that. The output transistors are, effectively, resistors, when they're turned
on, so when the load increases, the voltage swing suffers accordingly. The
maximum specifications will clearly show you that the power dissipation in a
normally operating device will not cause enough dissipation to put out heat
sufficient to ignite the PCB, and certainly not the package itself.
The "XC" designation simply indicated that they were pre-production parts,
and, actually, the 'C' refers to the package, IIRC, not that they were
experimental or inadequately characterized. Some such parts were never
relieved of the XC designation, particularly some of the monitor-equipped
single-chippers. An example would be the XC 6801L1, which was a 6801L-1 with
the LILBUG monitor in ROM, and the XC68HC705K1, though that didn't have a
monitor program in it which was the windowed ceramic 16-pin part, however, and
was never used in production due to its high cost ($45-$70 depending on
quantity and source).
There were instructions in the 6502 (note that I keep coming back to that one,
since that's what the thread is about) that were "unimplemented" and could,
if
encountered in the course of an otherwise normal run, cause a running program
to go astray, resulting in a "freeze-up" of the system. If you let a 6502 run
long enough, it might get hot, too, if not provided with adquate air
circulation. The same, of course, is true of any NMOS part, including the
680x series from MOT. Hot, BTW, has several sets of definitions, but, from a
purely pragmatic standpoint, if you lick your finger and then touch the part,
and it sizzles, it's warm, and perhaps out of spec. If you touch the part and
it sizzles BEFORE you lick your finger, then it's HOT! They didn't make
Mil-spec 6502's so that's definitely out of spec. Now, if it's hot enough to
cause the solder to come loose, that's really, Really, REALLY hot. Lots of
the parts would quit before they got that hot. If they quit, they'd cool off
again.
I've seen very few machines "halt and catch fire" without the aid of a
hardware failure of some sort. One example was a Wang 2200 MVP which had an
MOS memory board's clock driver short between the bipolar 12-volt rails, and
quickly caught the PCB on fire, allowing flames and thick black smoke to
emanate from the top of the open cabinet. It STANK!
--- Richard Erlacher <edick(a)idcomm.com> wrote:
> I don't see an HCF in the Mot listings of their
> instruction set.
>
> I've heard about this fiction over several decades
> now, and, surely, it must
> be clear to you that there's no way the
> microprocessor can cause that effect
> without the aid of external hardware.
>
> We used to joke about a BEO instruction (branch and
> execute operator) but I've never seen the effects of
> that one either.
>
> Dick
>
> ----- Original Message -----
> From: "Loboyko Steve" <sloboyko(a)yahoo.com>
> To: <cctalk(a)classiccmp.org>
> Sent: Thursday, June 06, 2002 11:34 PM
> Subject: Re: [CCTECH] Interesting tidbit on 6502
>
>
> > I'm building a 6800 machine right now and I was
> > wondering about this "Halt and Catch on Fire"
> > instruction. Is this for real. This is a serious
> > question. Is there actually an instruction that
> will
> > overheat the chip?
> >
<snip>
6:37 a.m.
Richard Erlacher wrote:
I don't see an HCF in the Mot listings of their instruction set.
I've heard about this fiction over several decades now, and, surely, it must
be clear to you that there's no way the microprocessor can cause that effect
without the aid of external hardware.
We used to joke about a BEO instruction (branch and execute operator) but I've
never seen the effects of that one either.
I can't remember the memonics but
Branch on bit bucket full and
Branch both ways and
interupt when turned off come to mind.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
7:12 a.m.
New subject: Joke Mnemonics
Back In The Day (mid 70s) I was doing a design based on the Z80 stuff.
Someone doctored up and circulated several of the relevant datasheets.
Among the japery therein was :
JGL - Jump and Get Lost
BGR - Branch for no Good Reason
SBW - Shift Both Ways
SSP - Sharpen Stack Pointer (After much use, they apparently get dull)
RWO - Registers Write Only
CRA - Convert to Random Address
IBD - Interpolate Data Bits
CSR - Context Sensitive Reset
and my personal favorite
POF - Power On Fail
The data sheets also had numerous other little details... one I liked
was the address line's rise-time called out as: "6:45 AM, Mon -> Fri"
Cheers
John
7:24 a.m.
New subject: Joke Mnemonics
On Fri, 7 Jun 2002, John Lawson wrote:
Back In The Day (mid 70s) I was doing a design based on the Z80 stuff.
Someone doctored up and circulated several of the relevant datasheets.
Among the japery therein was :
JGL - Jump and Get Lost
BGR - Branch for no Good Reason
SBW - Shift Both Ways
SSP - Sharpen Stack Pointer (After much use, they apparently get dull)
RWO - Registers Write Only
CRA - Convert to Random Address
IBD - Interpolate Data Bits
CSR - Context Sensitive Reset
and my personal favorite
POF - Power On Fail
The data sheets also had numerous other little details... one I liked
was the address line's rise-time called out as: "6:45 AM, Mon -> Fri"
Cheers
John
Reminds me of the same vintage Signetics data sheet for the 9046 bit Write
Only Memory.
Always liked the "Pins remaining versus socket insertions" chart...
Peter Wallace
9:03 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 969 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020607/05e4cd21/at…
9:34 a.m.
Problem with the 6502 is that different versions
from different manufacturers had different
undocumented instructions. So for the general
public this was not much of a boon ....
The Z80 situation was much better
Also the 65C02 (the special CMOS version)
als was more reliable in this respect
Sipke de Wal
-----------------------------------------
http://xgistor.ath.cx
-----------------------------------------
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 8:03 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
<snip>
Many processors (and other chips for
that matter) have undocumented
instructions used for factory testing.
-tony
10:03 a.m.
On Fri, 7 Jun 2002, Sipke de Wal wrote:
Problem with the 6502 is that different versions
from different manufacturers had different
undocumented instructions. So for the general
public this was not much of a boon ....
True.
The Z80 situation was much better
Also the 65C02 (the special CMOS version)
als was more reliable in this respect
The 65C02 actually has additional instructions which invalidate former
"undocumented" instructions on the 6502.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
3:28 p.m.
see below, plz.
Dick
----- Original Message -----
From: "Sellam Ismail" <foo(a)siconic.com>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 1:03 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
There was considerable variation among the CMOS implementations of the 6502.
Some had the same, more or less, enhancements in the bit manipulation
instructions and read-modify-write instructions, and they all included the
wait-on-write cycles, which the NMOS versions lacked. AFAIK, only the
Rockwell CMOS version had the jump-indexed-indirect instruction, though.
On Fri, 7 Jun 2002, Sipke de Wal wrote:
Has anybody got examples, not including the CMOS versions, of course, which
are documented to be different, of differences in the NMOS 6502's? In the
years that I used 'em, I only had hands-on contact with MOS Technology,
Synertek, and Rockwell parts.
Problem with the 6502 is that different versions
from different manufacturers had different
undocumented instructions. So for the general
public this was not much of a boon ....
True.
The Z80 situation was much better
Also the 65C02 (the special CMOS version)
als was more reliable in this respect
The 65C02 actually has additional instructions which invalidate former
"undocumented" instructions on the 6502.
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com
*
8 Jun
8 Jun
1:48 a.m.
On Fri, 7 Jun 2002, Richard Erlacher wrote:
see below, plz.
Dick
----- Original Message -----
Where the UNDOCUMENTED aspects are DOCUMENTED to be different ?
> Problem with the 6502 is that different
versions
> from different manufacturers had different
> undocumented instructions. So for the general
> public this was not much of a boon ....
Has anybody got examples, not
including the CMOS versions, of course, which
are documented to be different, of differences in the NMOS 6502's? In the
years that I used 'em, I only had hands-on contact with MOS Technology,
Synertek, and Rockwell parts.
5:19 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com To: <cctalk(a)classiccmp.org Sent: Saturday, June 08, 2002 4:48 AM
Subject: Re: [CCTECH] Interesting tidbit on 6502
There's been quite a bit of effort put into characterizing the behavior of
serveral popular processors of the '80's with respect to their behavior, both
in terms of their behavior when given undocumented opcodes, and in terms of
undocumented behaviors (bugs) when they were executing documented opcodes. A
few of these are well publicized, while some are not.
One example of the latter sort is the beavior of the Z80 executing an INIR or
OTIR, which is not supposed to impact the parity flag, but seemingly does.
Since there has been effort in this direction
over the past two decades, quite
a bit is published, albeit not by the chip manufacturers.
Of course, this is not "official" data, but anything that is unofficial can be
documented, and the rest is a question of how much you trust the source. The
manufacturer didn't document these unofficially recognized behaviors for a
number of reasons, among which would be that they intended to use the logic
that provided them for something they considered more important, or perhaps
because they simply didn't want to take responsibility for those behaviors.
On Fri, 7 Jun 2002, Richard Erlacher wrote:
which
see below, plz.
Dick
----- Original Message -----
> > Problem with the 6502 is that different versions
> > from different manufacturers had different
> > undocumented instructions. So for the general
> > public this was not much of a boon ....
> Has anybody got examples, not including the CMOS versions, of course, are documented
to be different, of differences in the NMOS 6502's? In the
years that I used 'em, I only had hands-on contact with MOS Technology,
Synertek, and Rockwell parts.
Where the UNDOCUMENTED aspects are DOCUMENTED to be different ?
5:25 a.m.
New subject: OT (?): Mac (NUBUS) users ... ethernet board available
somebody convinced me that I wanted to take a Mac NUBUS (Centris 610) ethernet
card off his hands. I did it, but I'm not sure why. It's OLD, dating back to
the very early '90's and may, in fact, be old enough to be on-topic for this
forum. The notes on the box suggest it was phased out in '94. It doesn't fit
any hardware I own.
$5 + freight ($3.75 via USPS Priority Mail) if you want it. It's complete
with the box, manual, and diskettes.
Dick
7 Jun
7 Jun
10:05 a.m.
You may be confused about this. I don't know of a single NMOS 6502 that
didn't adhere to the MOS-technology instruction set. There's no telling
whether that included the undocumented opcodes, but since Synertek and
Rockwell used the MOS mask set, I suspect there was no difference. The later
Synertek parts may have been different since they shrank the die and got a bit
more speed, offering a 4 MHz 6502-C, which was an NMOS part and worked
perfectly in NMOS-targeted systems that didn't work with the later CMOS parts.
Dick
----- Original Message -----
From: "Sipke de Wal" <sipke(a)wxs.nl>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 12:34 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
Problem with the 6502 is that different versions
from different manufacturers had different
undocumented instructions. So for the general
public this was not much of a boon ....
The Z80 situation was much better
Also the 65C02 (the special CMOS version)
als was more reliable in this respect
Sipke de Wal
-----------------------------------------
http://xgistor.ath.cx
-----------------------------------------
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 8:03 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
<snip>
Many processors (and other chips for
that matter) have undocumented
instructions used for factory testing.
-tony
11:43 a.m.
Problem with the 6502 is that different versions
from different manufacturers had different
undocumented instructions. So for the general
public this was not much of a boon ....
On the Commodore 8-bits, since Commodore made all the 6502 derivatives they
used in their systems, the undocumented opcodes are considerably more
reliable and even appeared in some commercial titles as parts of heavily
protected loader routines. For that matter, every Commodore 8-bit system
except the 65 is NMOS (some are "HMOS" which is just Commodore's later NMOS
manufacturing process designation), so every Commodore 8-bit supports them
(again, except the 65, which is based on the 4510-cum-65CE02).
This is now backfiring as the SuperCPU is CMOS (not to mention a 65816 in
any case), and these titles inevitably crash on SCPU-equipped Commodore 64s
and 128s.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- Now and then innocent people are sent to the legislature. ------------------
10:01 a.m.
You can get them running plenty hot by simply wiring a DIP switch to the
address bus with NOP encoded into it using the R/W line as the low to which
the bus is switched. Each time it reads the bus, that's what it will see. It
will require pullups on the order of 4.7K to provide the high level. That's
one way of determining how fast a particular chip can be run, though you have
to try it with a wide range of instructions. With the 6800, of course, you
have to run the clock generator with it as well, however, and that may not
work as fast as the CPU before it goes out of specified limits.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <cctalk(a)classiccmp.org>
Sent: Friday, June 07, 2002 12:03 PM
Subject: Re: [CCTECH] Interesting tidbit on 6502
must
I don't see an HCF in the Mot listings of their instruction set.
Many processors (and other chips for that matter) have undocumented
instructions used for factory testing.
> I've heard about this fiction over several decades now, and, surely, it
> be clear to you that there's no way the
microprocessor can cause that
effect
without the
aid of external hardware.
It's not clear to me. What I am thinking of is the following :
The test instruction puts the processor into a mode where one of the
external lines toggles at the clock frequency, whereas normally it only
toggles at (say) 1/4 of the clock frequency (at most). This signal is
driving a bus line that has considerable capacitance to ground. At the
higher freqeucny, the drive buffer passes a higher current (to
charge/discharge that bus capacitance) and overheats.
I doubt you could get the chip to catch fire, but I think it would be
possible to get the chip to run hot.
-tony
7:04 p.m.
I don't see an HCF in the Mot listings of their
instruction set.
I doubt it would be listed...
I've heard about this fiction over several decades
now, and, surely, it
must be clear to you that there's no way the microprocessor can cause
that effect without the aid of external hardware.
I've actually seen it in operation, though I've not seen it smoke a
chip... I have one of the Heathkit Microprocessor Trainers (ET-3400)
and actually tried the instruction... and yes, you can see the address
lines incrementing (one of the exercises is to setup LEDs to watch
either data or address lines).
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | email: gentry at zk3.dec.com (work) |
| Unix Support Engineering Group | mbg at world.std.com (home) |
| Hewlett Packard | (s/ at /@/) |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 (DEC '77-'98) | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+
6:21 a.m.
New subject: Undefined instructions in 8-bit processors (was Re: [CCTECH] Interesting tidbit on 6502)
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
8 bit cpu's... most undefined instructions
are mostly harmess.
There is one undefined instruction on the 1802 - $68 IIRC. It's in
the group of I/O instructions, but there are only 7 defined ports (with
the N-lines indicating 1-7 at the appropriate cycle). The later,
extended versions of the 1802 used $68 as an opcode extender.
The reason for bringing it up is that I remember playing on the Elf
20 years ago, and noticing that if I accidentally executed a $68, the
CPU would go berserk and whomp on random patches of memory. If it
happened, I was guaranteed to have to retoggle the program in from
scratch.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
6 Jun
6 Jun
2:49 p.m.
It was thus said that the Great Cini, Richard once stated:
While browsing sites for 6800 information, I came across this quote from
<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Mostec>.
which talks about the design goals for the 650x in comparison to the 6800.
I've actually heard that some of the undocumented 6502 opcodes appeared to
do two operations, but I've never programmed a 6502 (a 6809 yes, and I found
out that encoding a TRF 8b,16b would set the high byte of the 16b register
to $FF---I never did see what the undocumented opcodes did though; I tended
to stay away from the undocumented stuff as a programmer).
-spc (I find that interesting though ... )
The design goal was a low-cost (smaler chip)
design, realized by
simplifying the decoder stage. There were no instructions with
the value
xxxxxx11, reducing the 1-of-4 decoder to a single NAND gate. Instructions
with the value xxxxxx11 actually executed two instructions in paralell, some
of them useful. <
Now, I didn't look at an opcode map, but it seems that this is an
interesting twist that I've never seen quoted when people discussed the
mysterious undocumented 6502 opcodes executing what appeared to be multiple
instructions.
Any thoughts?
4:11 p.m.
On Thu, 6 Jun 2002, Sean 'Captain Napalm' Conner wrote:
I've actually heard that some of the
undocumented 6502 opcodes appeared to
do two operations, but I've never programmed a 6502 (a 6809 yes, and I found
out that encoding a TRF 8b,16b would set the high byte of the 16b register
to $FF---I never did see what the undocumented opcodes did though; I tended
to stay away from the undocumented stuff as a programmer).
The "undocumented" opcodes in the 6502 do indeed trigger two operations as
the revelation of the simplified decoder whereby no instructions have
their lower two bits set to 1 reveals.
It was a matter of experimentation to issue one such instruction and see
what effect it had on the accumulator and registers. I know some
instructions would, for instance, do an OR operation and then an ADD, or
maybe a LOAD and then a logical operation.
I have a document somewhere that describes these operations, and it is
abound on the web.
Here's one such description (rather lengthy):
http://www.s-direktnet.de/homepages/k_nadj/opcodes.html
...and another (you have to download a zip file):
http://www.programmersheaven.com/zone5/cat440/15555.htm
Go to Google for more.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
4:12 p.m.
> >The design goal was a low-cost (smaler chip)
design, realized by
> simplifying the decoder stage. There were no instructions with the value
> xxxxxx11, reducing the 1-of-4 decoder to a single NAND gate. Instructions
> with the value xxxxxx11 actually executed two instructions in paralell, some
> of them useful. <
> Now, I didn't look at an opcode map, but it seems that this is an
> interesting twist that I've never seen quoted when people discussed the
> mysterious undocumented 6502 opcodes executing what appeared to be multiple
> instructions.
I've actually heard that some of the
undocumented 6502 opcodes appeared to
do two operations,
They sure do. For example, I believe there's a LAX that loads the
accumulator and X register simultaneously. Others are considerably more
useless, and there's several HCF-type instructions also.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- ** COMMODORE 64 BASIC V2 ** 64K RAM SYSTEM 38911 BASIC BYTES FREE ----------
7 Jun
7 Jun
9:36 a.m.
New subject: [CCTECH] ancient transistors found!
While working at video/audio shop, we cleaned out old junk boxes,
only few unearthed stuff that goes "exclaims: what that!?" from me or
coworker goes "wow.".
Here's this odd transistor only marking on it is:
ADY26
8:24 p.m.
New subject: [CCTECH] ancient transistors found!
jpero(a)sympatico.ca wrote:
While working at video/audio shop, we cleaned out old junk boxes,
only few unearthed stuff that goes "exclaims: what that!?" from me or
coworker goes "wow.".
Here's this odd transistor only marking on it is:
ADY26
Bolt stud?? sounds like a TO36 . . looks like a big round doorknob with
emitter and base leads in a straight line with the stud
(case=collector). Most of that case style were PNP germanium
transistors, used in car radio output stages, and some old two-way radio
T-power B+ supplies. Being Ge, they usually weren't too reliable, and
quite prone to failure.
Gary Hildebrand
St. Joseph, MO
From web search, it is TO3 package. Felt like
solid tin
plated copper w/ bolt stud.
What it is usually used in what equipment?
What era that transistors were used? 1960's?
This one is way before MY TIME. :-( )
Cheers,
Wizard
8 Jun
8 Jun
11:13 a.m.
New subject: [CCTECH] ancient transistors found!
What era that
transistors were used? 1960's?
This one is way before MY TIME. :-( )
Cheers,
Wizard
Bolt stud?? sounds like a TO36 . . looks like a big round doorknob with
emitter and base leads in a straight line with the stud
(case=collector). Most of that case style were PNP germanium
transistors, used in car radio output stages, and some old two-way radio
T-power B+ supplies. Being Ge, they usually weren't too reliable, and
quite prone to failure.
True. I heard that germanium transistors quits functioning when too
hot even hot water before boiling point is enough. But germanium
diodes IS still in use in automotive alternators.
What would put in that certain years range when that ADY26
transistors commonly used back then when products were in production
using that ADY26 transistors? Not counting the years for those
as repair parts in production even that equipment using them is not
in production.
Gary Hildebrand
St. Joseph, MO
Cheers,
Wizard
7 Jun
7 Jun
9:08 p.m.
New subject: [CCTECH] ancient transistors found!
jpero(a)sympatico.ca wrote:
While working at video/audio shop, we cleaned out old
junk boxes,
only few unearthed stuff that goes "exclaims: what that!?" from me or
coworker goes "wow.".
Here's this odd transistor only marking on it is:
ADY26
The 2 or 3 letters - number - possible letter format for transistors
is the European
labelling scheme.
From my copy of Tower's,
ADY26 PNP Germanium. Case T036 with lead-out L13. Vcb max 80V, Vce max
40V,
Veb max 40V, Ic max 25A, Tj max 90C, Ptot 100WH, F1min 100KHz, Hfe
15MN,
Hfe bias 25A.
Use - audio, high current, general purpose.
Manufacturer - Mullard.
European equivalent ADZ12
US Equivalent 2N1100.
That's all I can tell you about the beast,
Dave.
From web search, it is TO3 package. Felt like
solid tin
plated copper w/ bolt stud.
What it is usually used in what equipment?
What era that transistors were used? 1960's?
This one is way before MY TIME. :-( )
Cheers,
Wizard
_______________________________________________
cctech mailing list
cctech(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctech 
11:19 p.m.
New subject: [CCTECH] ancient transistors found!
Hi,
jpero(a)sympatico.ca said:
While working at video/audio shop, we cleaned out old
junk boxes,
only few unearthed stuff that goes "exclaims: what that!?" from me or
coworker goes "wow.".
Here's this odd transistor only marking on it is:
ADY26
Germanium PNP 75W Vcbo -80V Vceo -60V Ic 25A hFE 60 @ 4mA,80V
General purpose power transistor.
From web search, it is TO3 package. Felt like
solid tin
plated copper w/ bolt stud.
8 Jun
8 Jun
3 p.m.
New subject: [CCTECH] ancient transistors found!
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1126 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020609/8ac51316/at…
12:58 p.m.
New subject: [CCTECH] ancient transistors found!
Here's
this odd transistor only marking on it is:
ADY26
It's not TO3. TO3 is that diamond-shaped package, as used for the 2N3055
(and if you've not seen one of those, you've never done any electronics
;-)). The ADY26 is in a TO36 package. From web search, it is TO3 package. Felt like
solid tin
plated copper w/ bolt stud. :-P
Yes, I have seen TO3 packages in regular and small sizes. In fact
that dates me from that era (born '72 and while growing up
dissassembling old thrown out stuff had those package.)
Doesn't TO3 was also used in '60s electronic equipments as well?
May can't be. This package style seems to be '70s onwards era and IS
still in use.
Thanks for the correction on that TO36. website is wrong. :-( )
snip
What it is usually used in what equipment?
An output transistor for a stereo amplifier?
What era that transistors were used? 1960's?
I think so. Towers doesn't give dates, but it's in another late 1960's
databook of mine (and not in the early 1970's edition from what I can see). -tony
Cheers,
Wizard
9 Jun
9 Jun
9:47 a.m.
New subject: [CCTECH] ancient transistors found!
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 501 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020609/885f2366/at…
11 Jun
11 Jun
7:29 p.m.
New subject: [CCTECH] AT&T PC7300 / UnixPC is ill! :(
Hi all! :)
Today, I acquired a PC7300. Alas, the poor fellow
seems to have a rather large malady of some type. I've
never had much experience with these beasts before, so
much of what I say goes on the word of the last owner.
Evidently, before one of these machines first boots
up, it displays a few rectangular characters in the
upper left hand corner of the screen. It then proceeds
to its boot screen. (And then OS loading and whatnot
if all is well.) My machine just sits there and
displays rectangle after rectangle after rectangle. No
boot screen ever appears. The machine was working when
put away for storage when put away a few months ago,
but refused to boot when it came out. I guess that
leaves it at the point that I got it. :)
I managed, with a bit of yanking about, to get it
disassembled, down to the motherboard, as per the 3b1
FAQ. I got some of the big dust out and reseated all
of the seatable chips. There didn't seem to be any
major damage anywhere... one of the fans had a cut
line which I repaired, but there was no evidence of
any type of overheating. Most socketed chips were
reseated, everything was powered on once again, and
the same thing seems to happen. :( The rectangles
appear, the floppy drive sits and spins, and the hard
drive spins up and sits there. There is a loud
beep/click type sound, which I'd figured to be the
heads unparking themselves. When the hard drive cable
is removed, the machine freezes at one rectangle, so
was thinking it could be something along those lines.
Will see if I can dig up a HH ST-506 drive somewhere
soon. The power supply looked OK... one very slightly
mad looking / bulging cap, but nothing overtly broken.
(My DMM is in the mail at the moment, so I wasn't
really able to test much. :() The only other thing I
think I can report are that the four indicator LEDs
are at a constant on state - could also be normal for
this part of the boot cycle for this machine, too.
Any suggestions as to what is making this poor machine
act as it does would be very, very much appreciated.
:) Can't wait to get it running at some point... it
looks like such a nifty box.
Thanks kindly! :)
Andy
_____________________
groovelists(a)yahoo.com
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
_______________________________________________
cctech mailing list
cctech(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctech
9:12 p.m.
New subject: [CCTECH] AT&T PC7300 / UnixPC is ill! :(
At 09:29 PM 6/11/2002 -0700, you wrote:
I managed, with a bit of yanking about, to get it
disassembled, down to the motherboard, as per the 3b1
FAQ. I got some of the big dust out and reseated all
of the seatable chips. There didn't seem to be any
major damage anywhere... one of the fans had a cut
line which I repaired, but there was no evidence of
any type of overheating. Most socketed chips were
reseated, everything was powered on once again, and
the same thing seems to happen. :( The rectangles
appear, the floppy drive sits and spins, and the hard
drive spins up and sits there. There is a loud
beep/click type sound, which I'd figured to be the
heads unparking themselves. When the hard drive cable
is removed, the machine freezes at one rectangle, so
was thinking it could be something along those lines.
Will see if I can dig up a HH ST-506 drive somewhere
soon. The power supply looked OK... one very slightly
mad looking / bulging cap, but nothing overtly broken.
(My DMM is in the mail at the moment, so I wasn't
really able to test much. :() The only other thing I
think I can report are that the four indicator LEDs
are at a constant on state - could also be normal for
this part of the boot cycle for this machine, too.
It sounds offhand like the hard drive has the "stiction" problem
referred to in the FAQ. Did you try booting from a floppy?
Comp.sys.3b1 used to be where the Unix pc folks hung out.
They are cool machines, I have a couple myself.
G
Gordon Zaft
zaft(a)azstarnet.com
http://www.zaft.org/gordon
8110
days inactive
8116
days old
47 comments
23 participants
participants (23)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
chd_1＠nktelco.net -
cisin＠xenosoft.com -
dave＠naffnet.org.uk -
edick＠idcomm.com -
erd_6502＠yahoo.com -
foo＠siconic.com -
frustum＠pacbell.net -
ghldbrd＠ccp.com -
groovelists＠yahoo.com -
jcwren＠jcwren.com -
jpero＠sympatico.ca -
jpl15＠panix.com -
mbg＠TheWorld.com -
pcw＠mesanet.com -
RCini＠congressfinancial.com -
sipke＠wxs.nl -
sloboyko＠yahoo.com -
spc＠conman.org -
spectre＠stockholm.ptloma.edu -
stanb＠dial.pipex.com -
zaft＠azstarnet.com