<From CLASSICCMP-owner(a)u.washington.edu Thu Jan 8 15:08:02 1998
^^^^^
<Do you mean a National Semi 32000 class cpu? Kewl. Boy, those were
<hot, hot, hot when they hit the market in the early 80's. National
<did everything right on this one: Full object code compatibility
<between the 8,16 and 32 bit versions of the device; truly orthogonal
<instruction set, and so on. Mondo cool. It also was THE FIRST true
<32-bit cpu on the market (according to an EDN magazine article).
Look at that one and then look at VAX... the similarity is very strong.
<Did I say National did everything right? Yes. Well, depends on how
<you look at it. You couldn't run dos or CP/M on it. This, I
<suppose, was it's fatal 'flaw' (although I am of the opinion that
<that such compatibility would be a major DEFECT, but never mind).
The problem was it was late and only the slow ones with no second source.
<That and National didn't market the device very well, although
<it was used in alot of embedded applications. I wonder how much
<further it would have gone, had the free Unices we have today been
<available back then . . . .
The lack of OS support, lack of a perceived need for 32bits, late entry
into the market, poor marketing and the 808x and 68k being both well
embedded in the market were factors that could not be missed.
Allison
At 11:23 PM 8/8/97 -0700, Cord Coslor wrote:
>I have a C64c, although I haven't found them to be very common. This unit may
>be for sell as well if anyone is looking for one. Also, I too found a C64 in a
>third party case that looked just like the c-64... and it also was made in
>Australia. I can get this for anyone that might want this unit as well. Let me
>know.
>
>CORD COSLOR
I have heard that there were about 1 million of these produced with about
3 different subtle kinds made. (Different LED's, new vs old style keyboards,
etc.) Of course, compared to the 9+ million 64's produced I guess that means
that 64c's are *relatively* uncommon.
Les
><Do you mean a National Semi 32000 class cpu? Kewl. Boy, those were
><hot, hot, hot when they hit the market in the early 80's. National
><did everything right on this one: Full object code compatibility
><between the 8,16 and 32 bit versions of the device; truly orthogonal
><instruction set, and so on. Mondo cool. It also was THE FIRST true
><32-bit cpu on the market (according to an EDN magazine article).
>
>Look at that one and then look at VAX... the similarity is very strong.
I don't know; I didn't see it. To me, a processor architecture is hung off
the register structure and how the registers are used. When I read the
introductory chapters of the NS32 book, I got all excited, but when I
actually waded through the description of the machine I felt let down.
The thing about the VAX is that the entire machine is built around the
general purpose register set. Things that are special in other architectures
(immediate values, pushing and popping the stack) are simply side effects
of everyday addressing modes on the VAX. You can pop things from the
stack because you can pop them from any register; MOV R0,(R1)+ works
just as well as MOV R0,(SP)+. Immediate values are fundamentally popping
things from the PC: MOV R0,(PC)+. The NS32K required special address
modes for these operations because SP and PC weren't general purpose
registers.
I'm also not impressed by folks who claim that a 68000 is a whole lot
like a PDP-11 for the same reason...
Roger Ivie
ivie(a)cc.usu.edu
> Inutitively I know what microcode is. I think of it as hard-coded ROM
>for the instruction fetch unit of the microprocessor. Since I haven't been
>formally schooled in computer science or microprocessor design, I'd like to
>understand (in 500 words or less <g>) how microcode works, i.e., how is it
>implemented and how does the microprocessor access it.
The problem is that doing it right takes a picture...
A computer is built from (among other things) a whole grundle of
state machines. A state machine is a circuit that, at each clock cycle,
uses some number of inputs and its current state and uses them to generate
some number of outputs. The current state is a set of outputs that are fed
back into the machine; that is, they are outputs that become inputs to the
"next state generator", the logic which figures out what the outputs should
be at the next clock.
The next state generator is a complex piece of logic, especially for a
machine with a lot of states; the next state generator for a state machine
with, say, 256 states has 8 inputs just for the state variables! Designing
the next state generator for a state machine as complex as the control unit
of a CPU is very difficult and error-prone.
Microcode is simply a technique which replaces the logic of the next state
generator with a ROM. The inputs (including the current state) are fed
into the address of the ROM and the data from the ROM are taken to be
the outputs for the next state. Instead of implementing the logic by
tossing around gates, you implement the logic by building a lookup table
in the microcode ROM.
Roger Ivie
ivie(a)cc.usu.edu
In a message dated 98-01-07 20:19:54 EST, you write:
<< David, how cheap did you gotten some of these parts through this
mail list? Model 77? I do not know this specs, kindly tell me what
about this? :)
My book does not list this Model 77. >>
as far as the ps2 models i own go, my brother gave me the two model 30s. the
place where he used to work at had round filed them, so he rescued them for
me. the 8086 model was complete with a 4869 floppy drive and 8503 monitor!
works great and had data on it dated up to 1991. the model 77 is a premium
class ps2 machine announed in 1993 or 1994 i think so doesnt really apply to
discussion here although it has mca architecture with is 10 years old. mine is
a 9577-ouf which is a 486sx 33. full scsi, 2.88 floppy. 2-400 meg scsi drives
and 16 meg which is max i think. i found a mca scsi adaptor at a radio rally
for $1. tests ok, but its not a caching controller. this ps2 could support as
many scsi drives as there are drive letters to support them, btw.
david
> > MFM (early 80's?)
>
> Very early 80's, I think, for the ST-506.
>
> > RLL (late 80's?)
>
> I tend to think of this as a minor variation of MFM, myself :-)
Not quite. The interface is the same (ST-506/412), but the encoding is
different.
RLL-encoded ST-506/412 drives were finicky, especially as regards
temperature -- you shouldn't LLF them cold, for example.
Actually, some (if not all) IDE's use variations of RLL encoding.
One of the best sources for used parts for PS/2's I've found is
Skip Paret in Florida. (skip(a)bcp.mhs.compuserve.com) His company is
Business Computer Products: phone: (voice) 904-760-9300 (fax).
Also since I collect PS/2's I have found the newsgroup comp.sys.ibm.ps2.hardware
to be an excellent source of parts and info. There you will also find
that amazing German, Peter Wendt, quite possibly the world's greatest living authority on
PS/2's!
And there is also quite a stash of them downstairs, mostly Model 25's,
30's. 55's, 50Z's, 70's, and 80's.
A lot of the auxiliary parts from model 80's will work on the 70's.
so if there is something in particular you need, please let me know.
Kirk Scott
scottk5(a)ibm.net
On 1998-01-08 Tim said:
>Well, I've found a source of PS/2 parts/systems, but it'll cost.
>It's a company. They seem to have tons of the stuff. Their URL is
>http://www.kahlon.com . The problem is that they list(ed) a Model
>55SX as $249, but that did include a monitor. Well, you could
>probably say that you collect classics and that that price is way
>out of whack, but that might not work....
>Tim D. Hotze
Net-Tamer V 1.09.2 - Test Drive
Tektronix made a number of interesting UN*X workstations (their flavor
was called UTek) in the early/mid eighties, finally hanging it up
around 1990 after releasing a Motorola 88K-based machine called the
XD88 series.
Earlier Tek workstations were the Magnolia, the 4XXX series, the 613X
series, and the 6205. The 6205 and 6130 were based on the National
Semiconductor 32032 processor - the 6130 was a desk-top that actually
made it to market. The 6205 was a floor-standing "tower" version that
was faster and more expandable, but which never sriously made it to the
commercial market, as far as I know. The 43XX and 44XX boxes were very
cool, too - these ran UTek or Smalltalk. As with all Tek products, all
of these systems had fantastic graphics for their time.
I have various of these machines (6205, 6132, etc.). I can probably
copy some docs for you if you'd like. Let me know.
Bill
The following is some info about these that I collected from someone
who worked at Tektronix during the time:
The Magnolia was a proof-of-concept design, built in small quantities for
internal use only. It had two 68000 processors, one for general use, and
one for display only. It was a floor-standing cube about 18" per side. I
believe it ran BSD Unix and used VME cards. My guess is there were some
20-50 built. My understanding is that the design was not easily
"productized," meaning EL approval, inexpensive, etc. It had some custom
hybrid ICs in it that apparently cost a mint to make.
The Magnolia people and the 6000-line people were at war over
processors and OS's. The 6000 line eventually lost -- the Magnolia
people eventually produced the 4000-line, which were based on Motorola
processors and an awful UNIX clone called Uniflex. Once the 6000-line
died, it became politically possible to port UTek to the 4000-line
boxes, and their names changed.
Here's a quick run-down (somewhat chronological):
Magnolia -- Tek-internal-only, integrated bitmap display, dual 68000, BSD
Unix, VME?.
6205 -- only a few sold, Futurebus, NS32032, integrated display subsystem
never really worked.
6130 -- NS32032 desk-top, not expandable, integrated display subsystem
never really worked terribly well, usually used with a serial console.
4404 -- 68000, all-in-one with integrated 15" monochrome display, Uniflex OS.
4406 -- 68202, all-in-one with integrated 19", 4-bit gray display, Uniflex
OS. Extremely sharp, but short-lived, internally produced CRT -- I'd be
amazed if any of these are still working. The displays regulary started
getting dim about a month after the warranty expired.
4407 -- same as 4406, but with a Hitachi color monitor.
4404+ -- internal-only, the 4404 with a 68010 daughtercard and MMU so it
can run UTek.
4315 -- 4404 package with a 68020 processor, UTek.
4316 -- 4406 with minor changes, running UTek. Same dismal CRT.
4317 -- 4407 with minor changes, running UTek.
It's been a while, some of these numbers might be off by a digit or so...
>><I've got a line on a Tektronix 6132 workstations, and I'm wondering what
>><exactly it is. According to the current owner it runs Berkeley UNIX ver
>><4.2 with some 4.3 extensions. Apparently it's been sitting in a closet
>><unused for the last 8 years, so who knows if it's working. He also
>><referred to it as a UTek workstation.
>><
>><I didn't even know Tek made any computers, and web searches bring up zilc
>>
>>Look inside it may be a DEC PDP-11 series machine in differnt garb.
>>
>>Allison
>
>Ack, don't get my hopes up! Sounds like I'll have to arrange to pick this
>beast up sooner than expected :^)
Um. I'm not familiar with the Tek 6000 series at all, although the
description "Workstation" makes me suspect that it's not a PDP. (That
is purely a guess - I shall be happy to be proven wrong)
In the late 1970s and early '80s Tek made the 4050 series. These were
almost workstations - personal machines built around a vector storage
CRT.
The 4051 (earliest) seems to have used a 6800 micro as its CPU. This
was replaced in the 4052 and 4054 by a bitslice machine which appeared
to be a 25 MHz 6800-alike with some extra instructions. Fun machines.
I have a 4052, BTW. Recent web searches, researching a talk I was
giving on these machines, did indeed bring up practically nothing - all
I discovered was that the Dutch computer museum also has a 4052, Hans
Pufal's list mentions them, and that a company I had once met in a quite
different context started life making software for these machines.
Otherwise, no results from any search engine I tried. (The Tektronix
site has narry a mention)
So, when you do get hold of this, please tell us all about it.
Philip.
< Inutitively I know what microcode is. I think of it as hard-coded RO
<for the instruction fetch unit of the microprocessor. Since I haven't bee
<formally schooled in computer science or microprocessor design, I'd like
<understand (in 500 words or less <g>) how microcode works, i.e., how is i
<implemented and how does the microprocessor access it.
Microcode:
In the simplest form it's the control program that runs the CPU.
Every computer has it's instructions set, most we know like ADD A,B or
MOV A,B. Those are called MACROinstructions. Microcode is the internal
coding to actually create the sequence of timing pulses to actually make
the ADD happen.
The microcode resides in it own storage area and is generally inaccessable
(there are exceptions). A typical sequence would be in english:
macro instruction: ADD A,B Add contents of register A to
register B and place results
in A
Start: Fetch an instruction (uses program counter register
as address or source and
destination is the "instruction
register).
Jump to address @I (use the instruction register
as an address of the next
microinstruction.)
ADD: -signal add instruction
to ALU
-gate A register to ALU
-gate B register to ALU
-store ALU to A register (this could al be in one
microinstruction or it could
be a sequence of several.)
jump to START (get next MACROinstuction)
NOTE: microcoding is one way to construct a computer control, sequential
logic is also possible but as the machines increase in complexity
the logic complexity grows to sometimes implementable levels or
becomes hard to correct if there is an error.
Microcoding makes error correction easier and if new instruction
need to be added it's possible if the code space exists. It's also
easier to create a machine on paper or as a program that executes
microcode to test it.
Allison
