29 Jan
2021
29 Jan
'21
4:49 p.m.
Hello All.
Many of you may remember the AT&T UNIX PC and 3B1. These systems
were built by Convergent Technologies and sold by AT&T. They had an
MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS
was System V Release 2 vintage. There was a built-in 1200 baud modem,
and a primitive windowing system with mouse.
I had a 3B1 as my first personal system and spent many happy hours writing
code and documentation on it.
There is an emulator for it that recently became pretty stable. The original
software floppy images are available as well. You can bring up a fairly
functional system without much difficulty.
The emulator is at https://github.com/philpem/freebee. You can install up
to two 175 Meg hard drives - a lot of space for the time.
The emulator's README.md there has links to lots of other interesting
3B1 bits, both installable software and Linux tools for exporting the
file system from disk image so it can be mounted under Linux and
importing it back. Included is an updated 'sysv' Linux kernel module
that can handle the byte-swapped file system.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
The emulator runs great under Linux; not so sure about MacOS or Windows. :-)
So, anyone wishing to journey back to 1987, have fun!
Arnold
29 Jan
29 Jan
7:49 p.m.
Probably faster than the 3B1 was in real life. Being an educational
institution in NJ (Rutgers) we had all sorts of AT&T stuff donated to
us, 3B2's, 3B5's, and 3B20's.
The 3B2 was the first machine that I came across I think with a soft
power switch. Amusingly, the thing would not let you shut it down
unless you were root (apparently, you don't have power switch privs as a
normal user).
Of course, this was in contrast with the 3B20 which you powered off by
turning a knob and then holding a button down for three seconds. Yep,
phone equipment. Those who ever dealt with things like real Western
Electric 303 "broadband" modems recognized that behavior. You commanded
loopback on them the same way.
8:37 p.m.
On Fri, Jan 29, 2021 at 9:00 AM Ronald Natalie <ron(a)ronnatalie.com> wrote:
Of course, this was in contrast with the 3B20 which
you powered off by
turning a knob and then holding a button down for three seconds. Yep,
phone equipment. Those who ever dealt with things like real Western
Electric 303 "broadband" modems recognized that behavior. You commanded
loopback on them the same way.
Ron, pls don't forget the best 3B20 power-up feature, the pull starter in
the middle (power) cabinet. Seriously there was a cable that pulled out of
the middle power box (that looked like a small engine pull starter) that
used to by-pass the batteries on a true cold boot because if it was not
there the battery power up would surge the incoming load and trip the mains.
IIRC the off button Ron describes does not completely power it off, it
just shuts it down and you can take out cards safely, but the batteries and
some subsystems are still active. True 'cold' power down is extremely
difficult. It is designed to stay powered.
As he said -- standard telco gear, 48V supplies, rack of truck batteries,
*etc*.
BTW: In the same vein, I once had a movie we all called the 'burning Alpha'
when the 'telco special packaged' DEC 4300 from DEC CSS went through its
fire testing in NJ. All equipment that was going to be in a CO or wiring
center has to be tested to see how it burns in a fire (plastic/nylon parts
in a computer rack can be nasty - and there are very tight specs). As I
understand the spec, all flames have to stay inside the cabinets.
One of the cute parts of the video is a sidebar, which is displaying the
syslog messages during the fire. There was a desire, but I don't know if
it was ever acted upon, to match the syslog messages to different
activities in the fire. During the time when it is burning, there is a
timer in the corner so they can note afterward at exactly which time,
different things were incinerated.
31 Jan
31 Jan
1:57 p.m.
"Ronald Natalie" <ron(a)ronnatalie.com> wrote:
Probably faster than the 3B1 was in real life.
Seems about as fast as I remember the hardware being, but that was
well over 25 years ago, so I don't know for sure.
Being an educational institution in NJ (Rutgers) we
had all sorts of
AT&T stuff donated to us, 3B2's, 3B5's, and 3B20's.
Yes, Georgia Tech got 3B2s and 3B20s. An instructor there referred to the
3B20s as white elephants, and explained it to me (since I didn't know):
A white elephant is something obviously rare and valuable, but what
exactly do you do with it? :-)
Ours had a bunch of the CDC 300 Meg washing machine disk drives. A huge
amount of storage for the time. We (the lab staff) wanted to port BSD
Unix to them, but that never went anywhere.
The 3B2 was the first machine that I came across I
think with a soft
power switch. Amusingly, the thing would not let you shut it down
unless you were root (apparently, you don't have power switch privs as a
normal user).
I remember occasionally just pulling the plug...
The 3B1 was a pleasure in comparison. Afforadable on a personal level
and eminently usable.
Arnold
2:41 p.m.
On Jan 30, 2021, at 23:57, arnold(a)skeeve.com wrote:
... An instructor there referred to the 3B20s as white elephants,
and explained it to me (since I didn't know):
A white elephant is something obviously rare and valuable,
but what exactly do you do with it? :-)
Actually, it's a bit worse than that:
The term white elephant refers to an extravagant,
impractical gift that cannot be easily disposed of. The phrase is said to come from the
historic practice of the King of Siam (now Thailand) giving rare albino elephants to
courtiers who had displeased him, so that they might be ruined by the animals' upkeep
costs.
-- https://en.wikipedia.org/wiki/White_elephant_gift_exchange
On a related note, I recall that Dick Karpinski won an IBM (?) minicomputer at a Usenix
conference. Problem was, if he accepted it the taxes would be far more than any value it
might have for him. So, he ended up doing some sort of dance that allowed the machine to
go to someone else...
-r
3 Feb
3 Feb
1:53 p.m.
On 2021-01-29 05:49, Arnold Robbins wrote:
Hello All.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
Thanks for doing & making the disk images, was an easy start!
Do you remember, ho to set up the system to have four disk drives?
Cheers & thanks again!
1:59 p.m.
emanuel stiebler <emu(a)e-bbes.com> wrote:
On 2021-01-29 05:49, Arnold Robbins wrote:
You're welcome. It's a fun side project. I think I finally get the
enjoyment of retrocomputing with emulated versions of systems one
used in one's youth. :-)
Hello All.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
Thanks for doing & making the disk images, was an easy start! Do you remember, ho to set up the system to have four
disk drives?
Cheers & thanks again!
I don't think it can support more than 2 drives. Certainly the emulator
cannot. I don't know about real hardware.
You can split a big drive into partitions when formatting with the
diagnostics disk, but I don't think that's what you're asking.
Sorry,
Arnold
2:53 p.m.
It seems to me today's 2GHz processors should be able to emulate a 3B (*3B
or not 3B, that is the question*) at a performance that far exceeds an
actual 3B. Is the instruction set definition and architecture of a 3B
available anywhere?
Just wondering. I did such emulations for 68K machines and Cray machines.
Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree.
On Wed, Feb 3, 2021 at 2:00 AM <arnold(a)skeeve.com> wrote:
emanuel stiebler <emu(a)e-bbes.com> wrote:
--
Advice is judged by results, not by intentions.
Cicero
On 2021-01-29 05:49, Arnold Robbins wrote:
You're welcome. It's a fun side project. I think I finally get the
enjoyment of retrocomputing with emulated versions of systems one
used in one's youth. :-)
Hello All.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
Thanks for doing & making the disk images, was an easy start! Do you remember, ho to set up the system to have
four disk drives?
Cheers & thanks again!
I don't think it can support more than 2 drives. Certainly the emulator
cannot. I don't know about real hardware.
You can split a big drive into partitions when formatting with the
diagnostics disk, but I don't think that's what you're asking.
Sorry,
Arnold
2:58 p.m.
The 3B1 had an MC 68010. I don't truly remember how fast the real
system ran. The emulated system seems to run more or less the same as
the hardware did, taking my poor memory into account.
The 5620 used the same processor as the 3B2, IIRC. There are emulators
for both (maybe done by the same guy, I don't remember). I don't know
of emulators for the 3B5 or 3B20.
Arnold
Ed Bradford <egbegb2(a)gmail.com> wrote:
It seems to me today's 2GHz processors should be
able to emulate a 3B (*3B
or not 3B, that is the question*) at a performance that far exceeds an
actual 3B. Is the instruction set definition and architecture of a 3B
available anywhere?
Just wondering. I did such emulations for 68K machines and Cray machines.
Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree.
On Wed, Feb 3, 2021 at 2:00 AM <arnold(a)skeeve.com> wrote:
emanuel stiebler <emu(a)e-bbes.com> wrote:
--
Advice is judged by results, not by intentions.
Cicero On 2021-01-29 05:49, Arnold Robbins wrote:
You're welcome. It's a fun side project. I think I finally get the
enjoyment of retrocomputing with emulated versions of systems one
used in one's youth. :-)
Hello All.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
Thanks for doing & making the disk images, was an easy start! Do you remember, ho to set up the system to have
four disk drives?
Cheers & thanks again!
I don't think it can support more than 2 drives. Certainly the emulator
cannot. I don't know about real hardware.
You can split a big drive into partitions when formatting with the
diagnostics disk, but I don't think that's what you're asking.
Sorry,
Arnold
4:13 p.m.
Hay, Arnold,
MC 68K was created in 1980 or thereabouts. We talked about 10's
of Megahertz, I think, in those times. I was involved (slightly) with the
Zilog Z80,000 which would have competed with the 68K, NS32K and the Intel
80386. Of the instruction sets (architectures) I was most happy with, the
Zilog 32-bit processor architecture was to me, the most minimalist and
thorough. At the time, I managed software development for the Zilog
company's Z8000 computers. It was a fun era. I bought a z8000 system and
developed a CRAY simulator on it when I left Zilog and went to work for
American Supercomputer Company (another interesting Silicon Valley story).
The 1980's were a very interesting time in Silicon Valley.
One of the saddest stories I recall is when "Eagle Computer" went public.
The CEO died on the IPO day after he had become a very rich person when he
crashed a Ferrari during a test drive. Eagle Computer died with the CEO.
Ed
On Wed, Feb 3, 2021 at 2:59 AM <arnold(a)skeeve.com> wrote:
The 3B1 had an MC 68010. I don't truly remember
how fast the real
system ran. The emulated system seems to run more or less the same as
the hardware did, taking my poor memory into account.
The 5620 used the same processor as the 3B2, IIRC. There are emulators
for both (maybe done by the same guy, I don't remember). I don't know
of emulators for the 3B5 or 3B20.
Arnold
Ed Bradford <egbegb2(a)gmail.com> wrote:
--
Advice is judged by results, not by intentions.
Cicero
It seems to me today's 2GHz processors
should be able to emulate a 3B
(*3B
or not 3B, that is the question*) at a
performance that far exceeds an
actual 3B. Is the instruction set definition and architecture of a 3B
available anywhere?
Just wondering. I did such emulations for 68K machines and Cray machines.
Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree.
On Wed, Feb 3, 2021 at 2:00 AM <arnold(a)skeeve.com> wrote:
emanuel stiebler <emu(a)e-bbes.com> wrote:
--
Advice is judged by results, not by intentions.
Cicero On 2021-01-29 05:49, Arnold Robbins wrote:
> Hello All.
>
> I have made a pre-installed disk image available with a fair amount
> of software, see https://www.skeeve.com/3b1/.
Thanks for doing & making the disk images, was an easy start!
You're welcome. It's a fun side project. I think I finally get the
enjoyment of retrocomputing with emulated versions of systems one
used in one's youth. :-)
Do you remember, ho to set up the system to have
four disk drives?
Cheers & thanks again!
I don't think it can support more than 2 drives. Certainly the emulator
cannot. I don't know about real hardware.
You can split a big drive into partitions when formatting with the
diagnostics disk, but I don't think that's what you're asking.
Sorry,
Arnold
8:58 p.m.
On Wed, Feb 3, 2021 at 5:14 AM Ed Bradford <egbegb2(a)gmail.com> wrote:
Hay, Arnold,
MC 68K was created in 1980 or thereabouts. We talked about 10's of
Megahertz, I think, in those times.
The original X series part was originally unnumbered but a sticker was
later set for the lids that said X68000 (I had one on my desk - which was
used for the Tektronix Magnolia prototype).[1] The X series ran at 8 Mhz,
but the original released (distributed - MC68000) part was binned at 8 and
10 as were the later versions with the updated paging microcode called the
MC68010 a year later. When the 68020 was released Moto got the speeds up
to 16Mhz and later 20. By the '040 I think they were running at 50MHz
[1] I think I still have the draft list of issues in my files. There was a
halt and catch fire style error you had to be careful about (I've forgotten
the details - but if you executed it in supervisor mode, the ucode turned
on the address drivers in such a manner that they stopped working after
that and the chip was ruined). I only did that once ;-) when we were
debugging Magix (the OS for Magnolia)
9:33 p.m.
On Wed, 3 Feb 2021 at 09:59, Clem Cole <clemc(a)ccc.com> wrote:
On Wed, Feb 3, 2021 at 5:14 AM Ed Bradford <egbegb2(a)gmail.com> wrote:
Was the "X" prefix always used for prototypes? I remember having an
XC68020 in something - might have been an Sun 3/60, or an early Mac IIcx?
-Henry
Hay, Arnold,
MC 68K was created in 1980 or thereabouts. We talked about 10's of
Megahertz, I think, in those times.
The original X series part was originally unnumbered but a sticker was
later set for the lids that said X68000 (I had one on my desk - which was
used for the Tektronix Magnolia prototype).[1] The X series ran at 8 Mhz,
but the original released (distributed - MC68000) part was binned at 8 and
10 as were the later versions with the updated paging microcode called
the MC68010 a year later. When the 68020 was released Moto got the speeds
up to 16Mhz and later 20. By the '040 I think they were running at 50MHz
10:53 p.m.
Interesting, were you at Sun as I did not think Moto allowed its customers
to XC chips to end-users. But may just like Intel (which has also sort of
special stuff if a customer like HP wants to use preproduction chips for
early ships) Moto had some way to do that. I never was familiar with that
side of it.
FWIW: In Motorola's terminology, anything in >>their<< customer's
hand was
supposed to have a X part if it was pre-production (eXperimental) [Intel
calls these B step devices]. The problem for what would become the 68000
(according to my friend Les Crudele - who was on the 3 or 4 people on the
original team) since it was midnight job (*i.e.* not sanctioned and
basically 'off book') it did not even have an assigned experimental part
number. The MC6809 was the official replacement for the MC6800. It was
not even an "A step" part - it literally ran as a test run at the fab, as a
favor by a few folks. I wasn't there, but I have been under the
impression that Nick, Tom and Les got back a couple of test wafers and had
to cut the dice and mount them in the engineering lab.
You have to understand the whole project was a reaction some of the
engineers had to the MC6809 and made a bet with their boss they could build
a PDP-11 on a die. Since DEC had just put CalData out of business when
Ken O'Mundro did the CD500, Nick and Les were careful not to directly copy
the ISA, just modeled it after them. They had an PDP-11/70 running ISC's
Unix port and a bunch of custom fox terminals with the Rand Editor
partially running in the terminal. The rest iof history as it were.
When the chip worked the first time, the team had a few (??hundred??) dice
that they bonded and the >>engineers<< gave them to a couple of their
partners to see what they thought. I do not know which firms all got them,
but I know some folks in IBM did, and we got 10 of them in Tek Labs
Computer Research in late winter '79 IIRC. We were working on a 29000
bitslice system called Tina which eventually died. I got asked by my boss
if I wanted to play with these chips we had been given that so far nobody
had messed with. The documental was on a lineprinter paper (clearly nroff
output BTW). Roger Bates and I started to build the personal computer for
ourselves. Paul Blattner wrote an assembler for it, and I hacked on the
Ritchie PDP-11 C compiler [as I have said in other posts, the code it
generated sucked and even put out PDP-11 code in a few cases - like for FP
which I never redid). Steve Glaser and I started hacking. This would
eventually become Magnolia
<http://www.bitsavers.org/pdf/tektronix/magnolia/> which turned into the
Tek 4404 Smalltalk system a few years later.
I'm not sure when the original chip got the XC series #, but somebody
(??Roger??) got a bunch of stickers that we put them on the lids, I want to
say June/July of 1979 but I might not be remembering everything. Before
that, the chips had been marked with some date code by hand with a sharpie
or equivalent and were in a clear plastic snap case between anti-static
sponge.
BTW: As an amusing side note as we were talking about 'BourneGol'' a
while
back. Roger (being ex-Xerox PARC and recently of the Dorado) was used to
BCPL so he wrote a similar set of BCPL macros in C similar to Bourne's hack
for sh and adb. The CAD tool he wrote to design the boards was written in
it and ran originally on V7 with a Tek 4014, then was moved to Magnolia
when we had a stable OS and his new graphics display.
Clem
ᐧ
On Wed, Feb 3, 2021 at 10:33 AM Henry Bent <henry.r.bent(a)gmail.com> wrote:
On Wed, 3 Feb 2021 at 09:59, Clem Cole
<clemc(a)ccc.com> wrote:
On Wed, Feb 3, 2021 at 5:14 AM Ed Bradford <egbegb2(a)gmail.com> wrote:
Was the "X" prefix always used for prototypes? I remember having an
XC68020 in something - might have been an Sun 3/60, or an early Mac IIcx?
-Henry
Hay, Arnold,
MC 68K was created in 1980 or thereabouts. We talked about 10's of
Megahertz, I think, in those times.
The original X series part was originally unnumbered but a sticker was
later set for the lids that said X68000 (I had one on my desk - which was
used for the Tektronix Magnolia prototype).[1] The X series ran at 8 Mhz,
but the original released (distributed - MC68000) part was binned at 8 and
10 as were the later versions with the updated paging microcode called
the MC68010 a year later. When the 68020 was released Moto got the speeds
up to 16Mhz and later 20. By the '040 I think they were running at 50MHz
4 Feb
4 Feb
6:41 a.m.
New subject: 68k prototypes & microcode
Clem Cole <clemc(a)ccc.com> wrote:
> MC 68K was created in 1980 or thereabouts.
Wikimedia Commons has a pic of a 1979 XC68000L:
https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg
https://en.wikipedia.org/wiki/File:XC68000.agr.jpg
After a USENET posting pointed me at them, I browsed the Sunnyvale
Patent Library to bring home the patents for the Motorola 68000. They
include a full listing of the entire microcode! I ended up copying it,
taping the sheets together to reconstitute Nick Tredennick's
large-format "hardware flowcharts", and hanging them in the hallway near
my office at Sun. Fascinating!
I never saw X68000 parts; Sun started in 1981, so Moto had production
parts by then. But Sun did get early prototypes of the 68010, which we
were very happy for, since we and our customers were running a swapping
Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run
the BSD UNIX that we were porting from the Vax. Later, I was part of
the Sun bringup team using the XC68020. We built a big spider-like
daughterboard adapter that would let it be plugged into a 64-pin 68010
socket, so we could debug the 68020 in a Sun-2 CPU board while building
32-bit-wide boards for the Sun-3 bringup. We had it successfully
running UNIX within a day of receiving it! (We later heard that our
Moto rep was intending to give that precious early part to another
customer, but decided during their meeting with us to give it to us,
because we were so ready to get it running.)
When the 68000 was announced, it was obviously head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space. It seems like the designers of
the other chips (e.g. the 8088) had never actually worked with real
computers (mainframes and minicomputers) and kept not-learning from
computing history.
Some of my early experience was in APL implementation on the IBM 360
series. I knew the 68000 would be a great APL host, since its
autoincrement addressing was perfect for implementing vector operations.
In the process of designing an APL for it (which was never built), I
wrote up a series of short suggestions to Motorola on how to improve the
design. This was published in Computer Architecture News. For the
68010 they actually did one of the ideas, the "loop mode" that would
detect a 1-instruction backward decrement-and-branch loop, and stop
continually re-fetching the two instructions. This made
memory-to-memory or register-vs-memory instruction loops run at almost
the speed of memory, which was a big improvement for bcopy, bzero,
add-up-a-vector-of-integers, etc.
I'll append a USENET posting about the 68000 patents, followed by my
addendum after visiting the Patent office.
John
From
decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue Mar 15 16:55:28 1983
Subject: 68000: 16 bits. With references
Newsgroups: net.micro.68k
With due respect to Henry Spencer I feel that I must correct
some of his statements regarding the 68000. He is correct in
saying that the 68000 is basically 16 bits wide; however,
his explanation of the segmented bus is incorrect.
The datapath of the 68000 is divided into three pieces, each of
which has two busses, address and data, running through it. Six
busses total. There are muxes which can be switched so that all
address busses are connected and all data busses are connected.
The three sections of the datapath are the data section
(includes low 16 bits of all data registers and ALU), the
"low" section (contains the low 16 bits of address registers and
the low half of the Address Adder(AAU)), and the "high" section
(contains high 16 bits of all address and data registers and
the upper half of the AAU).
Theoretically they could do 6 16 bit transfers simultaneously,
but in looking through the microcode I don't remember seeing more
than three transfers at a time. The "low" and "high" sections can
be cascaded to provide a 32 bit arithmetic unit for address
calculations. 32 bit data calculations must be done in two passes through
the ALU.
For the masochists out there, you can learn more than you ever wanted
to know about the 68000 by reading Motorola's patents on it. They are
available for some nominal fee (~ one dollar) from the Office
of Patents and Trademarks in Arlington. The relevant patents are:
1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two
Level Control Store for Data Processor", Tredennick, et al.
First design of 68000 which was scrapped?
2 - #4,296,469 "Execution Unit for Data Processor using Segmented
Bus structure", Gunter, et al.
All about the 16 bit data path
3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor",
Gunter, et al.
Boring.
4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data Processor",
Gunter et al.
Bonanza! Full of block diagrams and everything you ever wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
Hope this clears things up.
Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056
My [gnu] notes on additional 68000 patents:
Pat # Appl # Filed date Issued date Inventors
4,338,661 041,201 May 21, 1979 Jul 6, 1982
Tredennick & Gunter
Conditional Branch Unit for Microprogrammed Data Processor
4,342,078 041,202 May 21, 1979 Jul 27, 1982
Tredennick & Gunter
Instruction Register Sequence Decoder for Microprogrammed
Data Processor and Method
4,312,034 041,203 May 21, 1979 Jan 19, 1982
Gunter, Hobbs, Spak, Tredennick
ALU and Condition Code Control Unit for Data Processor
4,325,121 041,135 May 21, 1979 Apr 13, 1982
Gunter, Tredennick
Two-Level Control Store for Microprogrammed Data Processor
Bonanza! Full of block diagrams and everything you ever wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
4,296,469 961,798 Nov 17, 1978 Oct 20, 1981
Gunter, Tredennick, McAlister
Execution Unit for Data Processor Using Segmented Bus Structure
All about the 16 bit data path
4,348,722 136,845 Apr 3, 1980 Sep 7, 1982
Gunter, Crudele, Zolnowsky, Mothersole
Bus Error Recognition for Microprogrammed Data Processor
4,349,873 136,593 Apr 2, 1980 Sep 14, 1982
Gunter, Zolnowsky, Crudele
Microprocessor Interrupt Processing
4,524,415 447,721 Dec 7, 1982 Jun 18, 1985
Mills, Moyer, MacGregor, Zolnowsky
Virtual Machine Data Processor
68010 changes to 68000
4,348,741 169,558 Jul 17, 1980 Sep 7, 1982
McAlister, Gunter, Spak, Schriber
Priority Encoder
Used to decode the bit masks for MOVEM.
XXXXXXXXX 446,801 Dec 7, 1982
Crudele, Zolnowsky, Moyer, MacGregor
Virtual Memory Data Processor
XXXXXXXXX 447,600 Dec 7, 1982
MacGregor, Moyer, Mills Jr, Zolnowsky
Data Processor Version Validation
About how bus errors store a CPU mask version # to
prevent their being restarted on a different CPU mask
in a multiprocessor system
XXXXXXXXX 961,796 Nov 17, 1978
Tredennick et al
Microprogrammed Control Apparatus for Data Processor
(continued into 4,325,121, probably never issued)
XXXXXXXXX 961,797 Nov 17, 1978
McAlister et al
Multi-port RAM Structure for Data Processor Registers
4,307,445 961,796 Nov 17, 1978
Tredennick, et al
Microprogrammed Control Apparatus Having a Two Level
Control Store for Data Processor
First design of 68000 which was scrapped?
6:52 a.m.
New subject: 68k prototypes & microcode
On 2/3/21 4:41 PM, John Gilmore wrote:
Clem Cole <clemc(a)ccc.com> wrote:
Oliver Galibert's work on re the 68000
https://og.kervella.org/m68k/
http://gendev.spritesmind.net/forum/viewtopic.php?t=3023
> MC 68K was created in 1980 or thereabouts.
Wikimedia Commons has a pic of a 1979 XC68000L:
https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg
https://en.wikipedia.org/wiki/File:XC68000.agr.jpg
After a USENET posting pointed me at them, I browsed the Sunnyvale
Patent Library to bring home the patents for the Motorola 68000. They
include a full listing of the entire microcode! I ended up copying it,
taping the sheets together to reconstitute Nick Tredennick's
large-format "hardware flowcharts", and hanging them in the hallway near
my office at Sun. Fascinating! 
7:10 a.m.
New subject: 68k prototypes & microcode
On 2/3/2021 7:41 PM, John Gilmore wrote:
When the 68000 was announced, it was obviously
head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space.
The 68K always reminded me of the VAX.
art k.
7:33 a.m.
New subject: 68k prototypes & microcode
On Wed, Feb 03, 2021 at 08:10:58PM -0500, Arthur Krewat wrote:
On 2/3/2021 7:41 PM, John Gilmore wrote:
I'm not sure if that is a compliment or not.
The NS320XX always reminded me more of the PDP-11 (which is by *far*
my favorite assembler, so uniform, I had a TA that could read the octal
dump of a PDP-11 like it was C). I wasn't that good but I could sort of
see what he was seeing and I never saw that in the VAX. 68K was closer
but I felt like the NS320xx was closer yet. Pity they couldn't produce
bug free chips.
Someone mentioned Z80000, I stopped at Z80 so I don't know if that was
also a pleasant ISA.
The x86 stuff is about as far away from PDP-11 as you can get. Required
to know it, but so unpleasant.
I have to admit that I haven't looked at ARM assembler, the M1 is making
me rethink that. Anyone have an opinion on where ARM lies in the pleasant
to unpleasant scale?
--lm who misses comp.arch back when CPU people hung out there
When the 68000 was announced, it was obviously
head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space.
The 68K always reminded me of the VAX.
7:57 a.m.
New subject: 68k prototypes & microcode
On 2/3/21 5:47 PM, Al Kossow wrote:
On 2/3/21 5:33 PM, Larry McVoy wrote:
https://spin.atomicobject.com/2013/02/08/bit-banding/
Anyone have an opinion on where ARM lies in the
pleasant
to unpleasant scale?
Don't look at how they implemented bit manipulation
1:23 p.m.
New subject: 68k prototypes & microcode
On Wed, Feb 03, 2021 at 05:33:56PM -0800, Larry McVoy wrote:
I have to admit that I haven't looked at ARM
assembler, the M1 is making
me rethink that. Anyone have an opinion on where ARM lies in the pleasant
to unpleasant scale?
'Different' is what I would call it..
Years ago I did a bunch of assembly hacking on the original ARM2 used in the
Archimedes A3000, which was an amazingly fast CPU for the time.
The thing that stood out on these CPU's to me, which was wildly different
to what I was used to (M68K, 6502, Z80/8080, VAX), was the fact that
many instructions were (somewhat) composeable.
Aka. you can/could add varuous logical operations like AND, OR, etc. 'into' an
instruction like a load or store and it would take the same number of clock
cycles to execute it all in 1 go.
That was great for doing data manipulation at very high rates for the time
compared to the common CISC CPU's as you did not need to go through multiple
fetch and modify cycles.
Reminiscent of some VLIW setups, but still more 'human readable' :)
The original ARM1/2/3 design did have some oddities like status bits being
encoded in the top of the (23) address bits, which meant that later versions of
the original design had to do some memory tricks to use a bigger address
space and keep compatilibity to the original code.
I suspect the current common ARM revisions since the move to the StrongARM
(ARM4) architecture, when DEC got involved and ARM became a standalone chip
design firm, have long fixed those oddities.
Probably still retains the way in which it encodes it's instructions to make
a lot of common logic operations while shuffling data more efficient though..
Having said that.. (and bringing it more back to TUHS instead of COFF ;) )
The ARM2 and ARM3 based machines could already run UNIX with Acorn selling
RISC iX for a short time, which was a 4.3BSD port done in the late 80's
and early 90's.
Very few of those were ever used/sold though as the Acorn Archimedes series
of machines were quite a bit more expensive than more widespread CISC machines.
Most were found in the UK and often in universities and the like.
Bye, Arno.
5:28 p.m.
New subject: 68k prototypes & microcode
On 2021-02-04 2:23 a.m., Arno Griffioen wrote:
On Wed, Feb 03, 2021 at 05:33:56PM -0800, Larry McVoy
wrote:
That is immediately reminiscent of DG Nova, PDP-8 (and to a tiny extent,
PowerPC).
I have to admit that I haven't looked at ARM
assembler, the M1 is making
me rethink that. Anyone have an opinion on where ARM lies in the pleasant
to unpleasant scale?
'Different' is what I would call it..
Years ago I did a bunch of assembly hacking on the original ARM2 used in the
Archimedes A3000, which was an amazingly fast CPU for the time.
The thing that stood out on these CPU's to me, which was wildly different
to what I was used to (M68K, 6502, Z80/8080, VAX), was the fact that
many instructions were (somewhat) composeable.
Aka. you can/could add varuous logical operations like AND, OR, etc. 'into' an
instruction like a load or store and it would take the same number of clock
cycles to execute it all in 1 go.
That was great for doing data manipulation at very high rates for the time
compared to the common CISC CPU's as you did not need to go through multiple
fetch and modify cycles.
Reminiscent of some VLIW setups, but still more 'human readable' :)
The original ARM1/2/3 design did have some oddities like status bits being
encoded in the top of the (23) address bits, which meant that later versions of
the original design had to do some memory tricks to use a bigger address
space and keep compatilibity to the original code.
I suspect the current common ARM revisions since the move to the StrongARM
(ARM4) architecture, when DEC got involved and ARM became a standalone chip
design firm, have long fixed those oddities.
Probably still retains the way in which it encodes it's instructions to make
a lot of common logic operations while shuffling data more efficient though..
ARM MCUs also have the "bit manipulation engine" for a similar goal, I
think.
--Toby
Having said that.. (and bringing it more back to TUHS instead of COFF ;) )
The ARM2 and ARM3 based machines could already run UNIX with Acorn selling
RISC iX for a short time, which was a 4.3BSD port done in the late 80's
and early 90's.
Very few of those were ever used/sold though as the Acorn Archimedes series
of machines were quite a bit more expensive than more widespread CISC machines.
Most were found in the UK and often in universities and the like.
Bye, Arno.
9:47 p.m.
New subject: 68k prototypes & microcode
On 2/3/2021 8:33 PM, Larry McVoy wrote:
Neither, more of an observation than anything.
Post/pre decrement/increment, 32-bit everything, it was an easy move,
mentally, from VAX to 68K. I cut my teeth on a PDP-10, but also VAX, and
a sprinkling of microprocessors such as the 8080, Z80, 6502 and of
course, 8088/86.
Back around the mid 80's, a friend and I built a 68020 prototype
computer from spare parts, all wire-wrapped, fast static RAM (it was
free), and I wrote a cross-assembler in C (on a 80386 PC) and we went to
town. And then, as they say, life happened. It was much easier to get
access to, or take home, powerful enough computers that we didn't need
to build our own. My friend still has the thing. I still have the
cross-assembler too, but sadly no actual code I wrote at the time. It
would have been worth a laugh or two ;)
I still have a Sun 3/280 laying around here somewhere...
art k.
The 68K always
reminded me of the VAX.
I'm not sure if that is a compliment or not.
10:03 p.m.
New subject: 68k prototypes & microcode
On 2021-02-04 10:47, Arthur Krewat wrote:
Post/pre decrement/increment, 32-bit everything, it
was an easy move,
mentally, from VAX to 68K.
I worked with 11s and VAX at this time the 68k came out, and as a
student, the 68k was the only way to get a decent machine for less.
And it really felt like the real thing ...
5 Feb
5 Feb
3:55 a.m.
New subject: 68k prototypes & microcode
On Wed, 3 Feb 2021, Larry McVoy wrote:
The 68K was fairly clean; the VAX not so much... I got the impression
that it was designed by a committee i.e. everybody wanted to have their
own instruction/feature, and it showed. I do admit though that paging the
page tables was a stroke of genius.
The 68K always
reminded me of the VAX.
I'm not sure if that is a compliment or not. The NS320XX always reminded me more of the PDP-11
(which is by *far*
my favorite assembler, so uniform, I had a TA that could read the octal
dump of a PDP-11 like it was C). I wasn't that good but I could sort of
see what he was seeing and I never saw that in the VAX. 68K was closer
but I felt like the NS320xx was closer yet. Pity they couldn't produce
bug free chips.
I used to be a whiz on the 360 :-) As part of our final CompSci exams
we had to hand-assemble and disassemble some code, and I hardly ever referred
to the "green card".
Someone mentioned Z80000, I stopped at Z80 so I
don't know if that was
also a pleasant ISA.
The Z80 was quite nice; I wrote heaps of programs for it, and I even found
an ANSI C Compiler for it (Hi-Tech as I recall; BDS-C was, well, you could
barely call it "C")[*]. I compiled a number of Unix programs...
The x86 stuff is about as far away from PDP-11 as you
can get. Required
to know it, but so unpleasant.
The x86 architecture is utterly brain-dead; I mean, what's wrong with a
linear address space? I think it was JohnG who said "segment registers
are for worms".
I have to admit that I haven't looked at ARM
assembler, the M1 is making
me rethink that. Anyone have an opinion on where ARM lies in the pleasant
to unpleasant scale?
I've been looking at the ARM; it seems quite nice at first glance.
--lm who misses comp.arch back when CPU people hung
out there
Indeed. I gave up on USENET when the joint got flooded by spammers; I
still have my "cancel" script somewhere.
[*]
I think it was Henry Spencer who said (in an unrelated matter): "Somehow
to be called a C compiler, I think it ought at least be able to compile
C".
-- Dave, who ran aus.radio.amateur.*
4:11 a.m.
New subject: 68k prototypes & microcode
On Fri, 5 Feb 2021, Dave Horsfall wrote:
The Z80 was quite nice; I wrote heaps of programs for
it, and I even found an
ANSI C Compiler for it (Hi-Tech as I recall; BDS-C was, well, you could
barely call it "C")[*]. I compiled a number of Unix programs...
Well, it *was* "Braindead Software" C.
<snip>
The x86 architecture is utterly brain-dead; I mean,
what's wrong with a
linear address space? I think it was JohnG who said "segment registers
are for worms".
The 65816 doesn't have the screwed-up bitshifted segment stuff but it's
also a segmented architecture and is also braindead.
And I'm a 65C02 fan.
-uso.
4:39 a.m.
New subject: 68k prototypes & microcode
I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, and
I still like it a great deal. Admittedly register-starved (well, unless
you consider the zero page a whole page of registers), but...simple, easy
to fit in your head, kinda wonderful.
I'd love a 64-bit 6502-alike (but I'd probably give it more than three
registers). I mean given how little silicon (or how few FPGA gates) a
reasonable version of that would take, might as well include 65C02 and
65816 cores in there too with some sort of mode-switching instruction.
Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be fun?
Throw in an onboard MMU and FPU too, I suppose, and then you could have a
real system on it.
32-bit SPARC was kind of fun and felt kind of like 6502. The 6502 wasn't
exactly RISCy...but when working with RISC architectures, understanding the
6502 seemed to be helpful.
I really liked the 68000, but in a different way. It's a nice, regular,
easy-to-understand instruction set without many surprises, and felt to me
like it had plenty of registers. Once the 68030 brought the MMU onboard it
was glorious.
Post-370 (which is to say 390/z IBM mainframe architectures) went wild with
microprogrammed crazy baroque very, very special purpose instructions.
Which, I mean, OK, cool, I guess, but not elegant.
I don't really know enough about the DEC architectures. It is my strong
impression that the PDP-11 is regular, simple to understand, and rather
delightful (like I find the 68000), while VAX gets super-baroque like later
IBM mainframe instruction sets. Although I've worked with emulated 10s,
11s, and VAXen, I've never really done anything in assembly (sure, you can
argue that C is the best PDP-11 preprocessor there is) on them.
On Thu, Feb 4, 2021 at 3:12 PM Steve Nickolas <usotsuki(a)buric.co> wrote:
On Fri, 5 Feb 2021, Dave Horsfall wrote:
The Z80 was quite nice; I wrote heaps of programs
for it, and I even
found an
ANSI C Compiler for it (Hi-Tech as I recall;
BDS-C was, well, you could
barely call it "C")[*]. I compiled a number of Unix programs...
Well, it *was* "Braindead Software" C.
<snip>
The x86 architecture is utterly brain-dead; I
mean, what's wrong with a
linear address space? I think it was JohnG who said "segment registers
are for worms".
The 65816 doesn't have the screwed-up bitshifted segment stuff but it's
also a segmented architecture and is also braindead.
And I'm a 65C02 fan.
-uso.
4:47 a.m.
New subject: 68k prototypes & microcode
On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton(a)gmail.com> wrote:
I'm probably Stockholm Syndrommed about 6502.
It's what I grew up on, and
I still like it a great deal. Admittedly register-starved (well, unless
you consider the zero page a whole page of registers), but...simple, easy
to fit in your head, kinda wonderful.
I'd love a 64-bit 6502-alike (but I'd probably give it more than three
registers). I mean given how little silicon (or how few FPGA gates) a
reasonable version of that would take, might as well include 65C02 and
65816 cores in there too with some sort of mode-switching instruction.
Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be fun?
Throw in an onboard MMU and FPU too, I suppose, and then you could have a
real system on it.
Sounds like a perfect project for an FPGA. If there's already a 6502
implementation out there, converting to 64 bit should be fairly easy.
-Henry
8:42 p.m.
New subject: 68k prototypes & microcode
On 2021-02-04 16:47, Henry Bent wrote:
On Thu, Feb 4, 2021, 17:40 Adam Thornton
<athornton(a)gmail.com> wrote:
There are FPGA implementations of the 6502 out there. If you've not seen
it, check out the MiSTer[0] project, FPGA implementations of a LOT of
computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, and 32
bit systems from the 70s and 80s along with gaming consoles from the 70s
and 80s.
Keeping this semi-TUHS related, one guy[1] has even implemented a
Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux,
NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of the
"official" MiSTer bits (yet?).
--
Michael Parson
Pflugerville, TX
KF5LGQ
[0] https://github.com/MiSTer-devel/Main_MiSTer/wiki
[1] https://temlib.org/site/
[2] https://temlib.org/pub/mister/SS/
I'm probably Stockholm Syndrommed about
6502. It's what I grew up on,
and
I still like it a great deal. Admittedly register-starved (well,
unless
you consider the zero page a whole page of registers), but...simple,
easy
to fit in your head, kinda wonderful.
I'd love a 64-bit 6502-alike (but I'd probably give it more than three
registers). I mean given how little silicon (or how few FPGA gates) a
reasonable version of that would take, might as well include 65C02 and
65816 cores in there too with some sort of mode-switching instruction.
Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be
fun?
Throw in an onboard MMU and FPU too, I suppose, and then you could
have a
real system on it.
Sounds like a perfect project for an FPGA. If there's already a 6502
implementation out there, converting to 64 bit should be fairly easy. 
5:14 a.m.
New subject: 68k prototypes & microcode
On Thu, 4 Feb 2021, Richard Salz wrote:
On Thu, Feb 4, 2021, 5:12 PM Steve Nickolas
<usotsuki(a)buric.co> wrote:
Close enough that my point can stand - but I stand corrected.
-uso.
Well, it *was* "Braindead Software" C.
Braindamaged software. I knew Leor; he sold me his motorcycle.
4 Feb
4 Feb
7:35 a.m.
New subject: 68k prototypes & microcode
No, that was the 16032 from nat semi.
I believe at least Nick and Les had been building oil drilling controll
systems using pdp11s and custom TTL For Schulmerger before they came to
Moto. They were definitely pdp11 fans. But they had used 360 systems at
UT in college. So they idea of a 24 bit pointer stored in a 32 bit word
they took from it.
Remember the chip was a 16 chip inside. It has 16 bit Barallel shifter and
All 32 bit operations took 2 ticks. And int was naturally 16 bits which
is what it was in my compiler.
I think it was Jack Test's compiler from MIT that was the first one ILP32
one for the 68k.
I used to commute to work at Stellar with Les and he told me many of the
stories btw. One of them I remember was they were worried about the
Barallel shifter because it was one of the pieces that was different
between the TTL prototype and the MOS implementation and it was the largest
pattern on the die. It was one of the few parts of the chip that had full
spice simulation.
Clem
On Wed, Feb 3, 2021 at 8:18 PM Arthur Krewat <krewat(a)kilonet.net> wrote:
On 2/3/2021 7:41 PM, John Gilmore wrote:
Sent from a handheld expect more typos than usual
When the 68000 was announced, it was obviously
head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space.
The 68K always reminded me of the VAX.
art k.
--
5 Feb
5 Feb
8:16 a.m.
New subject: 68k prototypes & microcode
[ Directing to COFF, where it likely belongs ]
On Thu, 4 Feb 2021, Arthur Krewat wrote:
Urk... I stayed away from VMS as much as possible (I had a network of
PDP-11s to play with), although I did do a device driver course; dunno
why.
-- Dave
-- Dave,
wondering whether anyone has ever used every VAX instruction
Or every VMS call, for that matter. ;)
8:53 a.m.
New subject: 68k prototypes & microcode
On Fri, Feb 05, 2021 at 01:16:08PM +1100, Dave Horsfall wrote:
[ Directing to COFF, where it likely belongs ]
On Thu, 4 Feb 2021, Arthur Krewat wrote:
Urk... I stayed away from VMS as much as possible (I had a network of
PDP-11s to play with), although I did do a device driver course; dunno why.
Me too, though I did use Eunice, it was a lonely place, it did not let
me see who was on VMS. I was the only one. A far cry from BSD where
wall went to everyone and talk got you a screen where you talked.
-- Dave,
wondering whether anyone has ever used every VAX instruction
Or every VMS call, for that matter. ;)
4 Feb
4 Feb
7:14 a.m.
New subject: 68k prototypes & microcode
Hey John. Bad cut/paste. I did not say 1980. That was from Eds msg. I
said we got what would become X series parts in winter 79. As I
understand it from Les; he, Nick and Tom built try the TTL prototype in
Early 78 with Les and Tom turning it into Si later that year while Nick was
writing ucode and all of the writing AVTs we high ran against then TTL
system.
Les says Tom did a masterful job of keeping management out of their hair
such they they stayed under the radar.
From what I understand there was so much focus on
countering the Z80 with
the 6809 that management thought they were just
experimenting with a more
16 bit 6809. But what they were doing was an AD experiment. The fact
that it worked was amazing.
On Wed, Feb 3, 2021 at 7:41 PM John Gilmore <gnu(a)toad.com> wrote:
Clem Cole <clemc(a)ccc.com> wrote:
Sent from a handheld expect more typos than usual
> MC 68K was created in 1980 or thereabouts.
Wikimedia Commons has a pic of a 1979 XC68000L:
https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg
https://en.wikipedia.org/wiki/File:XC68000.agr.jpg
After a USENET posting pointed me at them, I browsed the Sunnyvale
Patent Library to bring home the patents for the Motorola 68000. They
include a full listing of the entire microcode! I ended up copying it,
taping the sheets together to reconstitute Nick Tredennick's
large-format "hardware flowcharts", and hanging them in the hallway near
my office at Sun. Fascinating!
I never saw X68000 parts; Sun started in 1981, so Moto had production
parts by then. But Sun did get early prototypes of the 68010, which we
were very happy for, since we and our customers were running a swapping
Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run
the BSD UNIX that we were porting from the Vax. Later, I was part of
the Sun bringup team using the XC68020. We built a big spider-like
daughterboard adapter that would let it be plugged into a 64-pin 68010
socket, so we could debug the 68020 in a Sun-2 CPU board while building
32-bit-wide boards for the Sun-3 bringup. We had it successfully
running UNIX within a day of receiving it! (We later heard that our
Moto rep was intending to give that precious early part to another
customer, but decided during their meeting with us to give it to us,
because we were so ready to get it running.)
When the 68000 was announced, it was obviously head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space. It seems like the designers of
the other chips (e.g. the 8088) had never actually worked with real
computers (mainframes and minicomputers) and kept not-learning from
computing history.
Some of my early experience was in APL implementation on the IBM 360
series. I knew the 68000 would be a great APL host, since its
autoincrement addressing was perfect for implementing vector operations.
In the process of designing an APL for it (which was never built), I
wrote up a series of short suggestions to Motorola on how to improve the
design. This was published in Computer Architecture News. For the
68010 they actually did one of the ideas, the "loop mode" that would
detect a 1-instruction backward decrement-and-branch loop, and stop
continually re-fetching the two instructions. This made
memory-to-memory or register-vs-memory instruction loops run at almost
the speed of memory, which was a big improvement for bcopy, bzero,
add-up-a-vector-of-integers, etc.
I'll append a USENET posting about the 68000 patents, followed by my
addendum after visiting the Patent office.
John
From decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue
Mar 15 16:55:28 1983
Subject: 68000: 16 bits. With references
Newsgroups: net.micro.68k
With due respect to Henry Spencer I feel that I must correct
some of his statements regarding the 68000. He is correct in
saying that the 68000 is basically 16 bits wide; however,
his explanation of the segmented bus is incorrect.
The datapath of the 68000 is divided into three pieces, each of
which has two busses, address and data, running through it. Six
busses total. There are muxes which can be switched so that all
address busses are connected and all data busses are connected.
The three sections of the datapath are the data section
(includes low 16 bits of all data registers and ALU), the
"low" section (contains the low 16 bits of address registers and
the low half of the Address Adder(AAU)), and the "high" section
(contains high 16 bits of all address and data registers and
the upper half of the AAU).
Theoretically they could do 6 16 bit transfers simultaneously,
but in looking through the microcode I don't remember seeing more
than three transfers at a time. The "low" and "high" sections can
be cascaded to provide a 32 bit arithmetic unit for address
calculations. 32 bit data calculations must be done in two passes through
the ALU.
For the masochists out there, you can learn more than you ever wanted
to know about the 68000 by reading Motorola's patents on it. They are
available for some nominal fee (~ one dollar) from the Office
of Patents and Trademarks in Arlington. The relevant patents are:
1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two
Level Control Store for Data Processor", Tredennick, et al.
First design of 68000 which was scrapped?
2 - #4,296,469 "Execution Unit for Data Processor using Segmented
Bus structure", Gunter, et al.
All about the 16 bit data path
3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor",
Gunter, et al.
Boring.
4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data
Processor",
Gunter et al.
Bonanza! Full of block diagrams and everything you ever wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
Hope this clears things up.
Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056
My [gnu] notes on additional 68000 patents:
Pat # Appl # Filed date Issued date Inventors
4,338,661 041,201 May 21, 1979 Jul 6, 1982
Tredennick & Gunter
Conditional Branch Unit for Microprogrammed Data Processor
4,342,078 041,202 May 21, 1979 Jul 27, 1982
Tredennick & Gunter
Instruction Register Sequence Decoder for Microprogrammed
Data Processor and Method
4,312,034 041,203 May 21, 1979 Jan 19, 1982
Gunter, Hobbs, Spak, Tredennick
ALU and Condition Code Control Unit for Data Processor
4,325,121 041,135 May 21, 1979 Apr 13, 1982
Gunter, Tredennick
Two-Level Control Store for Microprogrammed Data Processor
Bonanza! Full of block diagrams and everything you ever
wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
4,296,469 961,798 Nov 17, 1978 Oct 20, 1981
Gunter, Tredennick, McAlister
Execution Unit for Data Processor Using Segmented Bus Structure
All about the 16 bit data path
4,348,722 136,845 Apr 3, 1980 Sep 7, 1982
Gunter, Crudele, Zolnowsky, Mothersole
Bus Error Recognition for Microprogrammed Data Processor
4,349,873 136,593 Apr 2, 1980 Sep 14, 1982
Gunter, Zolnowsky, Crudele
Microprocessor Interrupt Processing
4,524,415 447,721 Dec 7, 1982 Jun 18, 1985
Mills, Moyer, MacGregor, Zolnowsky
Virtual Machine Data Processor
68010 changes to 68000
4,348,741 169,558 Jul 17, 1980 Sep 7, 1982
McAlister, Gunter, Spak, Schriber
Priority Encoder
Used to decode the bit masks for MOVEM.
XXXXXXXXX 446,801 Dec 7, 1982
Crudele, Zolnowsky, Moyer, MacGregor
Virtual Memory Data Processor
XXXXXXXXX 447,600 Dec 7, 1982
MacGregor, Moyer, Mills Jr, Zolnowsky
Data Processor Version Validation
About how bus errors store a CPU mask version # to
prevent their being restarted on a different CPU mask
in a multiprocessor system
XXXXXXXXX 961,796 Nov 17, 1978
Tredennick et al
Microprogrammed Control Apparatus for Data Processor
(continued into 4,325,121, probably never issued)
XXXXXXXXX 961,797 Nov 17, 1978
McAlister et al
Multi-port RAM Structure for Data Processor Registers
4,307,445 961,796 Nov 17, 1978
Tredennick, et al
Microprogrammed Control Apparatus Having a Two Level
Control Store for Data Processor
First design of 68000 which was scrapped?
--
7:20 a.m.
New subject: 68k prototypes & microcode
Bad iPhone autocorrect sigh...
They all ran the AVTs on the TTL prototype.
On Wed, Feb 3, 2021 at 8:14 PM Clem Cole <clemc(a)ccc.com> wrote:
Hey John. Bad cut/paste. I did not say 1980. That
was from Eds msg. I
said we got what would become X series parts in winter 79. As I
understand it from Les; he, Nick and Tom built try the TTL prototype in
Early 78 with Les and Tom turning it into Si later that year while Nick was
writing ucode and all of the writing AVTs we high ran against then TTL
system.
Les says Tom did a masterful job of keeping management out of their hair
such they they stayed under the radar.
From what I understand there was so much focus on countering the Z80 with
the 6809 that management thought they were just experimenting with a more
16 bit 6809. But what they were doing was an AD experiment. The fact
that it worked was amazing.
On Wed, Feb 3, 2021 at 7:41 PM John Gilmore <gnu(a)toad.com> wrote:
--
Sent from a handheld expect more typos than usual
Clem Cole <clemc(a)ccc.com> wrote:
Sent from a handheld expect more typos than usual
> MC 68K was created in 1980 or thereabouts.
Wikimedia Commons has a pic of a 1979 XC68000L:
https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg
https://en.wikipedia.org/wiki/File:XC68000.agr.jpg
After a USENET posting pointed me at them, I browsed the Sunnyvale
Patent Library to bring home the patents for the Motorola 68000. They
include a full listing of the entire microcode! I ended up copying it,
taping the sheets together to reconstitute Nick Tredennick's
large-format "hardware flowcharts", and hanging them in the hallway near
my office at Sun. Fascinating!
I never saw X68000 parts; Sun started in 1981, so Moto had production
parts by then. But Sun did get early prototypes of the 68010, which we
were very happy for, since we and our customers were running a swapping
Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run
the BSD UNIX that we were porting from the Vax. Later, I was part of
the Sun bringup team using the XC68020. We built a big spider-like
daughterboard adapter that would let it be plugged into a 64-pin 68010
socket, so we could debug the 68020 in a Sun-2 CPU board while building
32-bit-wide boards for the Sun-3 bringup. We had it successfully
running UNIX within a day of receiving it! (We later heard that our
Moto rep was intending to give that precious early part to another
customer, but decided during their meeting with us to give it to us,
because we were so ready to get it running.)
When the 68000 was announced, it was obviously head-and-shoulders better
than the other clunky 8-bit and 16-bit systems, with a clean 32-bit
architecture and a large address space. It seems like the designers of
the other chips (e.g. the 8088) had never actually worked with real
computers (mainframes and minicomputers) and kept not-learning from
computing history.
Some of my early experience was in APL implementation on the IBM 360
series. I knew the 68000 would be a great APL host, since its
autoincrement addressing was perfect for implementing vector operations.
In the process of designing an APL for it (which was never built), I
wrote up a series of short suggestions to Motorola on how to improve the
design. This was published in Computer Architecture News. For the
68010 they actually did one of the ideas, the "loop mode" that would
detect a 1-instruction backward decrement-and-branch loop, and stop
continually re-fetching the two instructions. This made
memory-to-memory or register-vs-memory instruction loops run at almost
the speed of memory, which was a big improvement for bcopy, bzero,
add-up-a-vector-of-integers, etc.
I'll append a USENET posting about the 68000 patents, followed by my
addendum after visiting the Patent office.
John
From decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue
Mar 15 16:55:28 1983
Subject: 68000: 16 bits. With references
Newsgroups: net.micro.68k
With due respect to Henry Spencer I feel that I must correct
some of his statements regarding the 68000. He is correct in
saying that the 68000 is basically 16 bits wide; however,
his explanation of the segmented bus is incorrect.
The datapath of the 68000 is divided into three pieces, each of
which has two busses, address and data, running through it. Six
busses total. There are muxes which can be switched so that all
address busses are connected and all data busses are connected.
The three sections of the datapath are the data section
(includes low 16 bits of all data registers and ALU), the
"low" section (contains the low 16 bits of address registers and
the low half of the Address Adder(AAU)), and the "high" section
(contains high 16 bits of all address and data registers and
the upper half of the AAU).
Theoretically they could do 6 16 bit transfers simultaneously,
but in looking through the microcode I don't remember seeing more
than three transfers at a time. The "low" and "high" sections can
be cascaded to provide a 32 bit arithmetic unit for address
calculations. 32 bit data calculations must be done in two passes through
the ALU.
For the masochists out there, you can learn more than you ever wanted
to know about the 68000 by reading Motorola's patents on it. They are
available for some nominal fee (~ one dollar) from the Office
of Patents and Trademarks in Arlington. The relevant patents are:
1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two
Level Control Store for Data Processor", Tredennick, et al.
First design of 68000 which was scrapped?
2 - #4,296,469 "Execution Unit for Data Processor using Segmented
Bus structure", Gunter, et al.
All about the 16 bit data path
3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor",
Gunter, et al.
Boring.
4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data
Processor",
Gunter et al.
Bonanza! Full of block diagrams and everything you ever wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
Hope this clears things up.
Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056
My [gnu] notes on additional 68000 patents:
Pat # Appl # Filed date Issued date Inventors
4,338,661 041,201 May 21, 1979 Jul 6, 1982
Tredennick & Gunter
Conditional Branch Unit for Microprogrammed Data Processor
4,342,078 041,202 May 21, 1979 Jul 27, 1982
Tredennick & Gunter
Instruction Register Sequence Decoder for Microprogrammed
Data Processor and Method
4,312,034 041,203 May 21, 1979 Jan 19, 1982
Gunter, Hobbs, Spak, Tredennick
ALU and Condition Code Control Unit for Data Processor
4,325,121 041,135 May 21, 1979 Apr 13, 1982
Gunter, Tredennick
Two-Level Control Store for Microprogrammed Data Processor
Bonanza! Full of block diagrams and everything you ever
wanted
to know. Includes complete listing of microcode with
Tredennick's "hardware flowcharts".
4,296,469 961,798 Nov 17, 1978 Oct 20, 1981
Gunter, Tredennick, McAlister
Execution Unit for Data Processor Using Segmented Bus Structure
All about the 16 bit data path
4,348,722 136,845 Apr 3, 1980 Sep 7, 1982
Gunter, Crudele, Zolnowsky, Mothersole
Bus Error Recognition for Microprogrammed Data Processor
4,349,873 136,593 Apr 2, 1980 Sep 14, 1982
Gunter, Zolnowsky, Crudele
Microprocessor Interrupt Processing
4,524,415 447,721 Dec 7, 1982 Jun 18, 1985
Mills, Moyer, MacGregor, Zolnowsky
Virtual Machine Data Processor
68010 changes to 68000
4,348,741 169,558 Jul 17, 1980 Sep 7, 1982
McAlister, Gunter, Spak, Schriber
Priority Encoder
Used to decode the bit masks for MOVEM.
XXXXXXXXX 446,801 Dec 7, 1982
Crudele, Zolnowsky, Moyer, MacGregor
Virtual Memory Data Processor
XXXXXXXXX 447,600 Dec 7, 1982
MacGregor, Moyer, Mills Jr, Zolnowsky
Data Processor Version Validation
About how bus errors store a CPU mask version # to
prevent their being restarted on a different CPU mask
in a multiprocessor system
XXXXXXXXX 961,796 Nov 17, 1978
Tredennick et al
Microprogrammed Control Apparatus for Data Processor
(continued into 4,325,121, probably never issued)
XXXXXXXXX 961,797 Nov 17, 1978
McAlister et al
Multi-port RAM Structure for Data Processor Registers
4,307,445 961,796 Nov 17, 1978
Tredennick, et al
Microprogrammed Control Apparatus Having a Two Level
Control Store for Data Processor
First design of 68000 which was scrapped?
-- 
8:56 p.m.
New subject: 68k prototypes & microcode
On Wed, Feb 3, 2021 at 7:42 PM John Gilmore <gnu(a)toad.com> wrote:
It seems like the designers of
the other chips (e.g. the 8088) had never actually worked with real
computers (mainframes and minicomputers) and kept not-learning from
computing history.
Hence the description of Windows 95 as "a 32-bit extension to a 16-bit
patch to an 8 bit OS originally for a 4-bit chip written by a 2-bit company
that doesn't care 1 bit about its users."
On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm(a)mcvoy.com> wrote:
The NS320XX always reminded me more of the PDP-11 (which is by *far*
my favorite assembler, so uniform,
I slightly prefer the MIPS-32.
The x86 stuff is about as far away from PDP-11 as you
can get. Required
to know it, but so unpleasant.
Required? Ghu forbid. After doing a bunch of PDP-11 assembler work, I
found out that the Vax had 256 opcodes and foreswore assembly thereafter.
Still, that was nothing compared to the 1500+ opcodes of x86*. I think I
dodged a bullet.
On Wed, Feb 3, 2021 at 9:18 PM Dave Horsfall <dave(a)horsfall.org> wrote:
-- Dave, wondering whether anyone has ever used every
VAX instruction
AFAIU, some of them were significantly slower than their multi-instruction
equivalents.
3 Feb
3 Feb
9:20 p.m.
On 2021-02-03 05:13, Ed Bradford wrote:
Hay, Arnold,
MC 68K was created in 1980 or thereabouts. We talked about 10's
of Megahertz, I think, in those times. I was involved (slightly) with
the Zilog Z80,000 which would have competed with the 68K, NS32K and the
Intel 80386. ...
The 1980's were a very interesting time in
Silicon Valley.
One of the saddest stories I recall is when "Eagle Computer" went
public. The CEO died on the IPO day after he had become a very rich
person when he crashed a Ferrari during a test drive. Eagle Computer
died with the CEO.
Did "eagle" not make an 68k emulation in bit slices? Am I mixing them up
with another company?
10:48 p.m.
The 3B1 ran at 10Mhz. Pretty common for the era on MC68010 type hardware.
Maybe I'll have to get mine out, fix it up to actually be runable again, and
compare.
I know the MFM drive kicked the bucket decades ago, and the hardware
MFM emulators just haven't come down to the price level where I'd just
go buy one or two.
The 3B2 is all the WE 32100 CPU
Seth Morabito wrote an emulator for the 3B2/DMD, and collects all the information about
3B2s here.
https://archives.loomcom.com/3b2/
On Wed, Feb 03, 2021 at 01:58:56AM -0700, arnold(a)skeeve.com wrote:
The 3B1 had an MC 68010. I don't truly remember
how fast the real
system ran. The emulated system seems to run more or less the same as
the hardware did, taking my poor memory into account.
The 5620 used the same processor as the 3B2, IIRC. There are emulators
for both (maybe done by the same guy, I don't remember). I don't know
of emulators for the 3B5 or 3B20.
Arnold
Ed Bradford <egbegb2(a)gmail.com> wrote:
> It seems to me today's 2GHz processors should be able to emulate a 3B (*3B
> or not 3B, that is the question*) at a performance that far exceeds an
> actual 3B. Is the instruction set definition and architecture of a 3B
> available anywhere?
>
> Just wondering. I did such emulations for 68K machines and Cray machines.
>
> Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree.
>
>
> On Wed, Feb 3, 2021 at 2:00 AM <arnold(a)skeeve.com> wrote:
>
> > emanuel stiebler <emu(a)e-bbes.com> wrote:
> >
> > > On 2021-01-29 05:49, Arnold Robbins wrote:
> > > > Hello All.
> > > >
> > > > I have made a pre-installed disk image available with a fair amount
> > > > of software, see https://www.skeeve.com/3b1/.
> > >
> > > Thanks for doing & making the disk images, was an easy start!
> >
> > You're welcome. It's a fun side project. I think I finally get the
> > enjoyment of retrocomputing with emulated versions of systems one
> > used in one's youth. :-)
> >
> > > Do you remember, ho to set up the system to have four disk drives?
> > >
> > > Cheers & thanks again!
> >
> > I don't think it can support more than 2 drives. Certainly the emulator
> > cannot. I don't know about real hardware.
> >
> > You can split a big drive into partitions when formatting with the
> > diagnostics disk, but I don't think that's what you're asking.
> >
> > Sorry,
> >
> > Arnold
> >
>
>
> --
> Advice is judged by results, not by intentions.
> Cicero
4:46 p.m.
On 2021-02-03 02:59, arnold(a)skeeve.com wrote:
I don't think it can support more than 2 drives.
Certainly the emulator
cannot. I don't know about real hardware.
I remember seeing a 3b1, with 4 hard drives. The guy used an external
enclosure (looked like a 5150 PC), to have the other three drives in it.
5:13 p.m.
emanuel stiebler <emu(a)e-bbes.com> wrote:
On 2021-02-03 02:59, arnold(a)skeeve.com wrote:
I'll take your word for it. :-) Maybe open an issue on the freebee
github asking about it. A serious undertanding of the hardware is
definitely beyond me.
Thanks,
Arnold
I don't think it can support more than 2
drives. Certainly the emulator
cannot. I don't know about real hardware.
I remember seeing a 3b1, with 4 hard drives. The guy used an external
enclosure (looked like a 5150 PC), to have the other three drives in it. 
5 Feb
5 Feb
6:44 p.m.
Hi everyone. I've built Freebee using Make and specifying win32 as
architecture under Cygwin with libSDL2 plus Cygwin-X XWindows installed.
The Freebee runs starting it from xterm. It's a bit faster than my own
real 3B1. I have briefly tested the two startup hard drives and the second
hard drive, empty. No problem as far as I have seen. Great work. On the
other hand I dare to suggest the improve of the GUI of the emulator to
reduce the flickering of the 3B1's screen refresh. Is too much visible.
Thanks and good luck, anyway.
Sergio
El vie., 29 ene. 2021 11:50, Arnold Robbins <arnold(a)skeeve.com> escribió:
Hello All.
Many of you may remember the AT&T UNIX PC and 3B1. These systems
were built by Convergent Technologies and sold by AT&T. They had an
MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS
was System V Release 2 vintage. There was a built-in 1200 baud modem,
and a primitive windowing system with mouse.
I had a 3B1 as my first personal system and spent many happy hours writing
code and documentation on it.
There is an emulator for it that recently became pretty stable. The
original
software floppy images are available as well. You can bring up a fairly
functional system without much difficulty.
The emulator is at https://github.com/philpem/freebee. You can install up
to two 175 Meg hard drives - a lot of space for the time.
The emulator's README.md there has links to lots of other interesting
3B1 bits, both installable software and Linux tools for exporting the
file system from disk image so it can be mounted under Linux and
importing it back. Included is an updated 'sysv' Linux kernel module
that can handle the byte-swapped file system.
I have made a pre-installed disk image available with a fair amount
of software, see https://www.skeeve.com/3b1/.
The emulator runs great under Linux; not so sure about MacOS or Windows.
:-)
So, anyone wishing to journey back to 1987, have fun!
Arnold
7 Feb
7 Feb
1:32 p.m.
Hi.
Thanks for the update. The speed comparison is interesting.
With respect to screen flickering, please open an issue on the Github
repo. I don't really see that under Linux.
Thanks,
Arnold
Sergio Pedraja <spedraja(a)gmail.com> wrote:
Hi everyone. I've built Freebee using Make and
specifying win32 as
architecture under Cygwin with libSDL2 plus Cygwin-X XWindows installed.
The Freebee runs starting it from xterm. It's a bit faster than my own
real 3B1. I have briefly tested the two startup hard drives and the second
hard drive, empty. No problem as far as I have seen. Great work. On the
other hand I dare to suggest the improve of the GUI of the emulator to
reduce the flickering of the 3B1's screen refresh. Is too much visible.
Thanks and good luck, anyway.
Sergio
El vie., 29 ene. 2021 11:50, Arnold Robbins <arnold(a)skeeve.com> escribió:
> Hello All.
>
> Many of you may remember the AT&T UNIX PC and 3B1. These systems
> were built by Convergent Technologies and sold by AT&T. They had an
> MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS
> was System V Release 2 vintage. There was a built-in 1200 baud modem,
> and a primitive windowing system with mouse.
>
> I had a 3B1 as my first personal system and spent many happy hours writing
> code and documentation on it.
>
> There is an emulator for it that recently became pretty stable. The
> original
> software floppy images are available as well. You can bring up a fairly
> functional system without much difficulty.
>
> The emulator is at https://github.com/philpem/freebee. You can install up
> to two 175 Meg hard drives - a lot of space for the time.
>
> The emulator's README.md there has links to lots of other interesting
> 3B1 bits, both installable software and Linux tools for exporting the
> file system from disk image so it can be mounted under Linux and
> importing it back. Included is an updated 'sysv' Linux kernel module
> that can handle the byte-swapped file system.
>
> I have made a pre-installed disk image available with a fair amount
> of software, see https://www.skeeve.com/3b1/.
>
> The emulator runs great under Linux; not so sure about MacOS or Windows.
> :-)
>
> So, anyone wishing to journey back to 1987, have fun!
>
> Arnold
>
1:59 p.m.
Ed Carp <erc(a)pobox.com> wrote:
Wasn't the 3B1 the same thing as the 7300?
There were differences in the amounts of memory and size of disk. The 3B1
had room for a larger disk and thus its case was shaped differently.
In terms of other hardware and the software, they were the same.
Arnold
19 Feb
19 Feb
12:07 a.m.
arnold(a)skeeve.com writes:
Ed Carp <erc(a)pobox.com> wrote:
Hmm.. think I used one of those 7300, aka Unix PC systems when I was an
undergrad a long time ago. It looked like images I find on the Net in
any case, but it was a long time ago. Whatever it was that we had, I
remember that the floppy drive was 5.25 inch and used 512 byte sectors.
I had a Radio Shack Color Computer 3 at the time and the disk controller
on that would read a 512 double density byte sector disk just fine. I
had gotten pretty good at reading foreign disks on the CC3 and I put a
copy of /bin/sh onto the floppy on the Unix PC and then used the CC3 to
adjust the ownership and mode to make the copy of the sh binary setuid
root. Since the Unix PC would allow anyone to mount the floppy (at
least on the one we had) and since they didn't restrict setuid for the
mounted floppy I ended up with a root shell. Fun times... used it for
some class work instead of the PDP11/44 running BSD that we also had at
the university.
--
Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Wasn't the 3B1 the same thing as the 7300?
There were differences in the amounts of memory and size of disk. The 3B1
had room for a larger disk and thus its case was shaped differently.
In terms of other hardware and the software, they were the same.
Arnold
1402
days inactive
1422
days old
49 comments
24 participants
participants (24)
-
Adam Thornton -
Al Kossow -
Arno Griffioen -
Arnold Robbins -
arnold＠skeeve.com
-
Arthur Krewat -
Brad Spencer -
Clem Cole -
Dave Horsfall -
Doug McIntyre -
Ed Bradford -
Ed Carp -
emanuel stiebler -
Henry Bent -
John Cowan -
John Gilmore -
Larry McVoy -
Michael Parson -
Rich Morin -
Richard Salz -
Ronald Natalie -
Sergio Pedraja -
Steve Nickolas -
Toby Thain