From: Clem Cole <clemc@ccc.com>
To: John Gilmore <gnu@toad.com>
Cc: UNIX Heritage Society <tuhs@tuhs.org>
Subject: Re: [TUHS] 68k prototypes & microcode
Date: Wed, 3 Feb 2021 20:20:05 -0500 [thread overview]
Message-ID: <CAC20D2MkzfqfY_LK3tswB7Q5w_pddeYpDdvTaQuCX7rLZxu3zg@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2NdDsGK2Y1y1kSMCGr+X047DDou3i76iBPhD9=AGK0pCg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9673 bytes --]
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@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@toad.com> wrote:
>
>> Clem Cole <clemc@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?
>>
>> --
> Sent from a handheld expect more typos than usual
>
--
Sent from a handheld expect more typos than usual
[-- Attachment #2: Type: text/html, Size: 11818 bytes --]
next prev parent reply other threads:[~2021-02-04 1:20 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 10:49 [TUHS] AT&T 3B1 - Emulation available Arnold Robbins
2021-01-29 13:49 ` Ronald Natalie
2021-01-29 14:37 ` Clem Cole
2021-01-31 7:57 ` arnold
2021-01-31 8:41 ` Rich Morin
2021-02-03 7:53 ` emanuel stiebler
2021-02-03 7:59 ` arnold
2021-02-03 8:53 ` Ed Bradford
2021-02-03 8:58 ` arnold
2021-02-03 10:13 ` Ed Bradford
2021-02-03 14:58 ` Clem Cole
2021-02-03 15:33 ` Henry Bent
2021-02-03 16:53 ` Clem Cole
2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore
2021-02-04 0:52 ` Al Kossow
2021-02-04 1:10 ` Arthur Krewat
2021-02-04 1:33 ` Larry McVoy
2021-02-04 1:47 ` Al Kossow
2021-02-04 1:57 ` Al Kossow
2021-02-04 7:23 ` Arno Griffioen
2021-02-04 11:28 ` Toby Thain
2021-02-04 15:47 ` Arthur Krewat
2021-02-04 16:03 ` emanuel stiebler
2021-02-04 21:55 ` Dave Horsfall
2021-02-04 22:11 ` Steve Nickolas
2021-02-04 22:39 ` Adam Thornton
2021-02-04 22:47 ` Henry Bent
2021-02-05 14:42 ` Michael Parson
2021-02-04 22:56 ` Richard Salz
2021-02-04 23:14 ` Steve Nickolas
2021-02-04 1:35 ` Clem Cole
2021-02-04 2:18 ` Dave Horsfall
2021-02-04 15:53 ` Arthur Krewat
2021-02-05 2:16 ` Dave Horsfall
2021-02-05 2:53 ` Larry McVoy
2021-02-04 1:14 ` Clem Cole
2021-02-04 1:20 ` Clem Cole [this message]
2021-02-04 14:56 ` John Cowan
2021-02-03 15:20 ` [TUHS] AT&T 3B1 - Emulation available emanuel stiebler
2021-02-03 16:48 ` Doug McIntyre
2021-02-03 10:46 ` emanuel stiebler
2021-02-03 11:13 ` arnold
2021-02-05 12:44 ` Sergio Pedraja
2021-02-07 7:32 ` arnold
2021-02-17 16:07 ` emanuel stiebler
2021-02-17 22:00 ` Ed Carp
2021-02-17 22:14 ` Larry McVoy
2021-02-18 1:30 ` Ed Carp
2021-02-18 7:59 ` arnold
2021-02-18 18:07 ` Brad Spencer
2021-02-13 1:06 [TUHS] 68k prototypes & microcode Jason Stevens
2021-02-13 2:30 ` Gregg Levine
2021-02-13 4:34 Jason Stevens
2021-02-13 6:05 ` Toby Thain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC20D2MkzfqfY_LK3tswB7Q5w_pddeYpDdvTaQuCX7rLZxu3zg@mail.gmail.com \
--to=clemc@ccc.com \
--cc=gnu@toad.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).