From ats at offog.org  Sun Mar  1 09:35:04 2020
From: ats at offog.org (Adam Sampson)
Date: Sun, 01 Mar 2020 17:35:04 +0000
Subject: [ih] evil umpire?
In-Reply-To: <63afc14e-a5ea-af43-617b-24f672d30e77@meetinghouse.net> (Miles
 Fidelman via Internet-history's message of "Sat, 29 Feb 2020 15:02:25
 -0500")
References: <63afc14e-a5ea-af43-617b-24f672d30e77@meetinghouse.net>
Message-ID: <y2aftesq8qf.fsf@offog.org>

Miles Fidelman via Internet-history <internet-history at elists.isoc.org>
writes:

> Who was it who's USENET sig line referred to the "evil umpire," and
> what was the exact line?? (My Google Foo doesn't seem to be working
> today, or it happened too long ago to be indexed.)

I don't know if it's the one you're thinking of, but Glen Raphael
<c160-ax at zooey.Berkeley.EDU> used this sig in 1986:

| "Through the intervening years, this ex-American baseball player who
| defected to the Soviet Union rose through the ranks to his current
| position as the single, driving force behind all Soviet foreign policy
| decisions.  It is he to whom Reagan refers as 'The Evil Umpire' "

(I found this in the utzoo archive, which is available on archive.org;
I keep a local copy indexed with notmuch for searching.)

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>


From mfidelman at meetinghouse.net  Sun Mar  1 19:38:33 2020
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Sun, 1 Mar 2020 22:38:33 -0500
Subject: [ih] USENET Archives [was Re:  evil umpire?]
In-Reply-To: <CAAbKA3XC_0OATi31zSCBmGain7ccBANCvWNNqL72NzxmMq4hpQ@mail.gmail.com>
References: <63afc14e-a5ea-af43-617b-24f672d30e77@meetinghouse.net>
 <CAAbKA3XC_0OATi31zSCBmGain7ccBANCvWNNqL72NzxmMq4hpQ@mail.gmail.com>
Message-ID: <bb96d4b2-3fe4-e6c5-9e5a-8bbef096cdf3@meetinghouse.net>

On 2/29/20 6:51 PM, Bill Ricker wrote:
> Tangential reply ...
>
> On Sat, Feb 29, 2020 at 3:02 PM Miles Fidelman via Internet-history
> <internet-history at elists.isoc.org> wrote:
>>   (My Google Foo doesn't seem to be working today, or
>> it happened too long ago to be indexed.)
> I don't think it's you.
> As you're probably painfully aware, the DejaNews archive that Google
> bought is mostly inaccessible now (since 2015), alas.
> AFAIK there is not equivalent mirror on-line.
> (One hopes Henry Spencer or UT kept a copy of the Usenet 1981-1991
> that he sent Google in 2003.)
> So it's not /your/ Google-Fu that's lacking, it's Google's.
>
> (Which is a shame for history and research, but may have prevented
> quite a few careers from being cut short by youthful indiscretions
> resurfacing. I don't think /mine/ were CLM but ... there's something
> to be said for EU's "Right to be Forgotten", as well as plenty to be
> said against it. I wouldn't be surprised if the impossibility of
> compliance with that EU directive may be why DejaNews qua Google
> Groups no longer does the Usenet for which Google doesn't have a
> user-agreement for each account.)
>
> I gather the Smithsonian Inst. has some of Usenet as well as snapshots
> of important Dot.Com pages archived for posterity
> (we were informed our Dot.Com had been included! :-D)
> but AFAIK they're mostly offline.
>
> // Bill

Damn.? Now doesn't that just suck.

Another case of Google being Evil, I guess.

Sigh...

Miles


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown



From mfidelman at meetinghouse.net  Sun Mar  1 19:39:33 2020
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Sun, 1 Mar 2020 22:39:33 -0500
Subject: [ih] evil umpire?
In-Reply-To: <y2aftesq8qf.fsf@offog.org>
References: <63afc14e-a5ea-af43-617b-24f672d30e77@meetinghouse.net>
 <y2aftesq8qf.fsf@offog.org>
Message-ID: <8f6d2b77-e1c7-1f60-3bbb-e8176a0679de@meetinghouse.net>

On 3/1/20 12:35 PM, Adam Sampson via Internet-history wrote:

> Miles Fidelman via Internet-history <internet-history at elists.isoc.org>
> writes:
>
>> Who was it who's USENET sig line referred to the "evil umpire," and
>> what was the exact line?? (My Google Foo doesn't seem to be working
>> today, or it happened too long ago to be indexed.)
> I don't know if it's the one you're thinking of, but Glen Raphael
> <c160-ax at zooey.Berkeley.EDU> used this sig in 1986:
>
> | "Through the intervening years, this ex-American baseball player who
> | defected to the Soviet Union rose through the ranks to his current
> | position as the single, driving force behind all Soviet foreign policy
> | decisions.  It is he to whom Reagan refers as 'The Evil Umpire' "
>
> (I found this in the utzoo archive, which is available on archive.org;
> I keep a local copy indexed with notmuch for searching.)

Thanks Adam!? An actual real answer, no less.

Miles


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown



From vint at google.com  Thu Mar  5 03:21:48 2020
From: vint at google.com (Vint Cerf)
Date: Thu, 5 Mar 2020 06:21:48 -0500
Subject: [ih] timeline of domain names and web hosting
Message-ID: <CAHxHggdoKf7Aio_wUCFJhAZ0ahtkD+r2S8sACpCpiF+SZau3Yw@mail.gmail.com>

https://www.dailyhostnews.com/the-history-of-web-hosting


vint
-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


From vgcerf at gmail.com  Mon Mar  9 23:14:54 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 10 Mar 2020 02:14:54 -0400
Subject: [ih] NCP and TCP implementations
Message-ID: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>

Steve Kirsch asks in what languages NCP and TCP were written.

The Stanford first TCP implementation was done in BCPL by Richard Karp.
Another version was written for PDP-11/23 by Jim Mathis but not clear in
what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
Dave Clark did one for IBM PC (assembly language/??)

Other recollections much appreciated.

vint


From casner at acm.org  Mon Mar  9 23:25:34 2020
From: casner at acm.org (Stephen Casner)
Date: Mon, 9 Mar 2020 23:25:34 -0700 (PDT)
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <alpine.OSX.2.21.9999.2003092323460.85530@auge.attlocal.net>

On Tue, 10 Mar 2020, vinton cerf via Internet-history wrote:
>
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language.

MACRO-11.  We adapted it for our EPOS operating system on the PDP11/45
at ISI.

                                                        -- Steve


From vgcerf at gmail.com  Mon Mar  9 23:29:27 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 10 Mar 2020 02:29:27 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <alpine.OSX.2.21.9999.2003092323460.85530@auge.attlocal.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <alpine.OSX.2.21.9999.2003092323460.85530@auge.attlocal.net>
Message-ID: <CAAFtm_WLy7UP09gptNcVURikUX3Kg455Pe-3um89U7FWfz9TgQ@mail.gmail.com>

thanks Steve C.

v


On Tue, Mar 10, 2020 at 2:25 AM Stephen Casner <casner at acm.org> wrote:

> On Tue, 10 Mar 2020, vinton cerf via Internet-history wrote:
> >
> > The Stanford first TCP implementation was done in BCPL by Richard Karp.
> > Another version was written for PDP-11/23 by Jim Mathis but not clear in
> > what language.
>
> MACRO-11.  We adapted it for our EPOS operating system on the PDP11/45
> at ISI.
>
>                                                         -- Steve
>


From lars at nocrew.org  Mon Mar  9 23:37:32 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 10 Mar 2020 06:37:32 +0000
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 (vinton cerf via Internet-history's message of "Tue, 10 Mar 2020
 02:14:54 -0400")
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <7w36agk95f.fsf@junk.nocrew.org>

Vinton Cerf wrote:
> Tenex was probably done in C at BBN.

Tenex and its NCP were written in MACRO-10 assembly language.
The source code is online: https://github.com/PDP-10/tenex


From vgcerf at gmail.com  Mon Mar  9 23:52:12 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 10 Mar 2020 02:52:12 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <7w36agk95f.fsf@junk.nocrew.org>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <7w36agk95f.fsf@junk.nocrew.org>
Message-ID: <CAAFtm_VENbuYHWTd+q204CfobWRZvZZp_0cUVyAVkz8GJTTc-Q@mail.gmail.com>

thanks Lars!

v


On Tue, Mar 10, 2020 at 2:37 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Vinton Cerf wrote:
> > Tenex was probably done in C at BBN.
>
> Tenex and its NCP were written in MACRO-10 assembly language.
> The source code is online: https://github.com/PDP-10/tenex
>


From steve at shinkuro.com  Tue Mar 10 01:28:31 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 04:28:31 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
Message-ID: <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>

If memory serves, prior to Multics and Unix and with the exception of the
Burrough?s computers, operating systems were written in the assembly
language of the machine.  This includes the Sigma 7 (host 1), the SDS 940
(host 2), the IBM 360 (host 3) and Tenex (host 4).  The NCP (?Network
Control *Program*") was an addition to the existing code of the operating
system and, I believe, written in the same language as the operating
system.  I think C appeared with Unix.  I don't think C was used or
available on Tenex, but I'm not the most authoritative source.  I don't
know much about the later implementations of NCP.  PDP-11s became popular
and there were several operating systems written for them.  ELF (Dave Retz
in Santa Barbara) and ANTS (University of Illinois) come to mind, and I
think there were others.  At the time, I had the impression writing network
compatible operating systems for the PDP-11 was a cottage industry.

It would be interesting to compare the timelines of the transition from NCP
to TCP/IP with the evolution of hosts from the Tenex era to the Unix era.

Steve

On Tue, Mar 10, 2020 at 2:09 AM Vint Cerf <vint at google.com> wrote:

> NCP was probably done in assembly language for most operating systems -
> adding steve crocker for comment
> TCP was written in BCPL at Stanford for PDP-11/40. Probaby C for Tenex.
> PL/1 (?) for 360's???
>
> Let me ask the Internet History list.
>
> v
>
>
> On Tue, Mar 10, 2020 at 2:03 AM Steve Kirsch <stk at m10.io> wrote:
>
>> Was it written in C? you?d think only a small part would have to be
>> customized for the operating system?!
>>
>>
>>
>> *From:* Vint Cerf <vint at google.com>
>> *Sent:* Monday, March 9, 2020 1:59 AM
>> *To:* Steve Kirsch <stk at m10.io>
>> *Subject:* Re: NCP, TCP/IP question
>>
>>
>>
>> 1. NCP was written individually for each operating system
>>
>> 2. TCP was also written for each operating system but UNIX propagated
>> most widely; TENEX version was popular for PDP-10s.
>>
>> Bob Braden did the TCP for IBM 360/91 and I think that got ported to
>> 360/75 at UCSB. Berkeley BSD 4.2 and follow-ons was most widely spread for
>> UNIX.
>>
>>
>>
>> v
>>
>>
>>
>>
>>
>> On Mon, Mar 9, 2020 at 4:15 AM Steve Kirsch <stk at m10.io> wrote:
>>
>>
>>    1. Did UCLA provide the source code for NCP and TCP/IP for various
>>    places to run?
>>
>>
>>
>>    1. Or did everyone write their own implementation based on the spec?
>>
>>
>>
>> If the latter, was that problematic? Would it have been easier if
>> everyone ran Unix and there was C source code that was distributed to
>> everyone to run? Is that in fact what in fact happened? Why UCLA lost their
>> SEX and became EUNUCHs? I mean UNIX?
>>
>>
>>
>>
> --
>>
>> New postal address:
>>
>> Google
>>
>> 1875 Explorer Street, 10th Floor
>> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g>
>>
>> Reston, VA 20190
>> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g>
>>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g>
> Reston, VA 20190
> <https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g>
>


From lars at nocrew.org  Tue Mar 10 02:08:05 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 10 Mar 2020 09:08:05 +0000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 (Steve Crocker's message of "Tue, 10 Mar 2020 04:28:31 -0400")
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
Message-ID: <7weeu0inm2.fsf@junk.nocrew.org>

Steve Crocker wrote:
> I don't think C was used or available on Tenex, but I'm not the most
> authoritative source.

There were several PDP-10 C compilers, but I'm not sure whether one
actually ran on Tenex.  Some ran on TOPS-20, so it wouldn't have been a
big leap.


From steve at shinkuro.com  Tue Mar 10 02:16:04 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 05:16:04 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <7weeu0inm2.fsf@junk.nocrew.org>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <7weeu0inm2.fsf@junk.nocrew.org>
Message-ID: <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>

Lars,

Thanks.  For anyone who hasn't tracked PDP-10 operating systems, I believe
TOPS-20 and Tenex were the same.  Tenex was developed at BBN.  DEC provided
the TOPS-10 operating system but it was less capable than Tenex.  DEC
acquired the rights to Tenex and brought it out as TOPS-20.  I don't know
if there are substantive changes in the process; I have the impression
there weren't.

These systems were connected to the Arpanet when NCP was the host level
protocol.  I didn't follow their history through the transition to TCP/IP,
but I have the impression they continued to be commonplace on the Internet
and thus would have had TCP/IP implementations.  Others can fill in the
gaps here better than I can.

Steve


On Tue, Mar 10, 2020 at 5:08 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Steve Crocker wrote:
> > I don't think C was used or available on Tenex, but I'm not the most
> > authoritative source.
>
> There were several PDP-10 C compilers, but I'm not sure whether one
> actually ran on Tenex.  Some ran on TOPS-20, so it wouldn't have been a
> big leap.
>


From vgcerf at gmail.com  Tue Mar 10 02:33:07 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Tue, 10 Mar 2020 05:33:07 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <7weeu0inm2.fsf@junk.nocrew.org>
 <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>
Message-ID: <CAAFtm_WFR8kkaU-kUyE0gwUtRFur9Rd6M1HOSa4N0viF-jFrUA@mail.gmail.com>

TENEX was the prototype for TCP/IP for the DEC 10/20 systems and they were
prevalent well into the 1980s and perhaps beyond that.

v


On Tue, Mar 10, 2020 at 5:16 AM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> Lars,
>
> Thanks.  For anyone who hasn't tracked PDP-10 operating systems, I believe
> TOPS-20 and Tenex were the same.  Tenex was developed at BBN.  DEC provided
> the TOPS-10 operating system but it was less capable than Tenex.  DEC
> acquired the rights to Tenex and brought it out as TOPS-20.  I don't know
> if there are substantive changes in the process; I have the impression
> there weren't.
>
> These systems were connected to the Arpanet when NCP was the host level
> protocol.  I didn't follow their history through the transition to TCP/IP,
> but I have the impression they continued to be commonplace on the Internet
> and thus would have had TCP/IP implementations.  Others can fill in the
> gaps here better than I can.
>
> Steve
>
>
> On Tue, Mar 10, 2020 at 5:08 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>
> > Steve Crocker wrote:
> > > I don't think C was used or available on Tenex, but I'm not the most
> > > authoritative source.
> >
> > There were several PDP-10 C compilers, but I'm not sure whether one
> > actually ran on Tenex.  Some ran on TOPS-20, so it wouldn't have been a
> > big leap.
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From dave.walden.family at gmail.com  Tue Mar 10 04:12:34 2020
From: dave.walden.family at gmail.com (David Walden)
Date: Tue, 10 Mar 2020 07:12:34 -0400
Subject: [ih] NCP, TCP/IP question
Message-ID: <h4w08esjxrjlkuhg0gelgl6h.1583838754694@email.android.com>

Re TENEX and TOP-20

See http://tenex.opost.com



On March 10, 2020, at 5:16 AM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:

>Lars,
>Thanks.? For anyone who hasn't tracked PDP-10 operating systems, I believe
>TOPS-20 and Tenex were the same.? Tenex was developed at BBN.? DEC provided
>the TOPS-10 operating system but it was less capable than Tenex.? DEC
>acquired the rights to Tenex and brought it out as TOPS-20.? I don't know
>if there are substantive changes in the process; I have the impression
>there weren't.
>These systems were connected to the Arpanet when NCP was the host level
>protocol.? I didn't follow their history through the transition to TCP/IP,
>but I have the impression they continued to be commonplace on the Internet
>and thus would have had TCP/IP implementations.? Others can fill in the
>gaps here better than I can.
>Steve
>On Tue, Mar 10, 2020 at 5:08 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>> Steve Crocker wrote:
>> > I don't think C was used or available on Tenex, but I'm not the most
>> > authoritative source.
>>
>> There were several PDP-10 C compilers, but I'm not sure whether one
>> actually ran on Tenex.? Some ran on TOPS-20, so it wouldn't have been a
>> big leap.
>>
>-- 
>Internet-history mailing list
>Internet-history at elists.isoc.org
>https://elists.isoc.org/mailman/listinfo/internet-history

From jeanjour at comcast.net  Tue Mar 10 04:16:28 2020
From: jeanjour at comcast.net (John Day)
Date: Tue, 10 Mar 2020 07:16:28 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CAAFtm_WFR8kkaU-kUyE0gwUtRFur9Rd6M1HOSa4N0viF-jFrUA@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <7weeu0inm2.fsf@junk.nocrew.org>
 <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>
 <CAAFtm_WFR8kkaU-kUyE0gwUtRFur9Rd6M1HOSa4N0viF-jFrUA@mail.gmail.com>
Message-ID: <13275C32-9918-4044-BFC0-8F8B2F9E86A7@comcast.net>

The early Illinois NCPs (for ANTS) were written in PEESPOL, PDP-11 Espol. The language created Dave Grothe based on Burros ESPOL, their operating system language which was a derivative of Algol.

The first UNIX NCP (1975) was written in C for the Illinois PDP-11/45, all of the TCPs (for PDP-11/45, 70, and VAX) were in C.

There is a paper from 1972 by Metcalfe on writing NCPs. I will have to find it and see what language that was.

Take care,
John


> On Mar 10, 2020, at 05:33, vinton cerf via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> TENEX was the prototype for TCP/IP for the DEC 10/20 systems and they were
> prevalent well into the 1980s and perhaps beyond that.
> 
> v
> 
> 
> On Tue, Mar 10, 2020 at 5:16 AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Lars,
>> 
>> Thanks.  For anyone who hasn't tracked PDP-10 operating systems, I believe
>> TOPS-20 and Tenex were the same.  Tenex was developed at BBN.  DEC provided
>> the TOPS-10 operating system but it was less capable than Tenex.  DEC
>> acquired the rights to Tenex and brought it out as TOPS-20.  I don't know
>> if there are substantive changes in the process; I have the impression
>> there weren't.
>> 
>> These systems were connected to the Arpanet when NCP was the host level
>> protocol.  I didn't follow their history through the transition to TCP/IP,
>> but I have the impression they continued to be commonplace on the Internet
>> and thus would have had TCP/IP implementations.  Others can fill in the
>> gaps here better than I can.
>> 
>> Steve
>> 
>> 
>> On Tue, Mar 10, 2020 at 5:08 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>> 
>>> Steve Crocker wrote:
>>>> I don't think C was used or available on Tenex, but I'm not the most
>>>> authoritative source.
>>> 
>>> There were several PDP-10 C compilers, but I'm not sure whether one
>>> actually ran on Tenex.  Some ran on TOPS-20, so it wouldn't have been a
>>> big leap.
>>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From bernie at fantasyfarm.com  Tue Mar 10 05:11:52 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 10 Mar 2020 08:11:52 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>,
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>,
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
Message-ID: <5E678408.27184.246772BF@bernie.fantasyfarm.com>

On 10 Mar 2020 at 4:28, Steve Crocker via Internet-hi wrote:

> If memory serves, prior to Multics and Unix and with the exception of
> the
> Burrough?s computers, operating systems were written in the assembly
> language of the machine.  This includes the Sigma 7 (host 1), the SDS
> 940
> (host 2), the IBM 360 (host 3) and Tenex (host 4).  The NCP
> (?Network
> Control *Program*") was an addition to the existing code of the
> operating
> system and, I believe, written in the same language as the operating
> system.

I don't know the significance of the host numbering, but BBN's PDP-1d was on 
the ARPAnet well before TENEX was.   I can't remember who hacked up the host 
interface, but I implemented the stuff in the timesharing system [ExecIII] to 
handle the ARPAnet and not long thereafter it became the "NCC".   And, yes, it 
was done in assembler [MIDAS].   The PDP-1 was decommissioned before 
TCP/IP appeared, so it never got a TCP stack cobbled into it.

  /Bernie\

            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --
   





From geoff at iconia.com  Tue Mar 10 05:19:59 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 02:19:59 -1000
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <CAEf-zriQiOoeDuPPANpyQMnKwVag+yyv8EsJZ5YZa=wRPveHew@mail.gmail.com>

prior to TCP being integrated into the Tenex monitor, there were several
BCPL user level programs written by Bill Plummer at BBN that used a (new at
the time) ICP mechanism to communicate between them.

there were four programs (TCP, Sink, ECHO O, and a telnet server that used
PTY's -- rather than NVT's) to support remote user logins.  There was also
a TCP User Telnet program that allows outward TCP telneting ICP'ng to the
user TCP program.

each of these programs (TCP, Sink, ECHO O, and a telnet server that used
PTY's) were auto started at system boot time by using SYSJOB's "CRJOB"
mechanism to log each of them in "DETACHED" under WHEEL'd user TCP.

Bill Plummer then later came out to SRI to install either this user TCP
stuff (and the ICP and PTY monitor code) or later when TCP was integrated
into the monitor (in PDP-10 Macro Assembly Language) on what was originally
SRI-AI, then SRI-KA, then DARCOM-KA (where the NSW [National Software
Works] also ran).

On Mon, Mar 9, 2020 at 8:15 PM vinton cerf via Internet-history <
internet-history at elists.isoc.org> wrote:

> Steve Kirsch asks in what languages NCP and TCP were written.
>
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
>
> Other recollections much appreciated.
>
> vint
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From beebe at math.utah.edu  Tue Mar 10 05:31:33 2020
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 10 Mar 2020 06:31:33 -0600
Subject: [ih] NCP, TCP/IP question
Message-ID: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>

Vint Cerf asks about early implementation languages for TCP/IP.

I searched our remaining archives of what in the 1980s and 1990s was
science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
running TOPS-20, and found TCP/IP network code written in PDP-10
assembly languages with these names:

	tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac

The files in that directory carry time stamps from 1984.10.25 to
1985.09.11.

The tcpbbn.mac file has this comment:

	;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.

	This module implements the BBN TCP JSYS interface.
	This  code  was originally developed at Bolt Beranek and Newman (BBN)
	under contract to  the  Defense  Advanced  Research  Projects  Agency
	(DARPA).

The JSYS instruction is the PDP-10 system call.

I also found a memo, design.mem, with the header

		  Black Arts
		      of
	Transmission Control Protocol
	    Inter Network Protocol
		Implementation
		    in the
	    VAX / VMS Environment

		  July 1982

		Stan C. Smith
	       Tektronix, Inc.
	Computer Resource Dept 50-454
		 P.O. box 500
	   Beaverton, Oregon  97077

that describes the VAX/VMS TCP/IP code written in Bliss, a systems
programming language that was developed at CMU for DEC, and used by a
few sites with DEC development contracts.  Otherwise, it was a
licensed software product that was too expensive for us to have on our
PDP-10, PDP-11, and VAX systems.

Instead, we wrote such code in assembly language, and later, in Pascal
(TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
written by Kok Chen at Stanford and significantly extended for systems
programming work by Ken Harrenstien at SRI International), and PCL
(Programmable Command Language, a DEC compiler available only on
TOPS-20). Once C became available on the PDP-10 and VAX, it was
clearly the language of choice for software tools, and assembly code
was a dead end with the growth in minicomputer and microprocessor
architectures.

For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
structured Fortran developed at JPL in Pasadena, and machine
translated to standard Fortran 66 and 77), with only low-level
primitives for character and bit processing, and system calls, written
in assembly code.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From vint at google.com  Tue Mar 10 05:34:24 2020
From: vint at google.com (Vint Cerf)
Date: Tue, 10 Mar 2020 08:34:24 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
Message-ID: <CAHxHggeyXaKNb0DaE+Z1Hgn+Pjd3+KCVA+J3Oep90QS4Wcq4Gg@mail.gmail.com>

thanks!!

v


On Tue, Mar 10, 2020 at 8:31 AM Nelson H. F. Beebe via Internet-history <
internet-history at elists.isoc.org> wrote:

> Vint Cerf asks about early implementation languages for TCP/IP.
>
> I searched our remaining archives of what in the 1980s and 1990s was
> science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
> running TOPS-20, and found TCP/IP network code written in PDP-10
> assembly languages with these names:
>
>         tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac
>
> The files in that directory carry time stamps from 1984.10.25 to
> 1985.09.11.
>
> The tcpbbn.mac file has this comment:
>
>         ;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.
>
>         This module implements the BBN TCP JSYS interface.
>         This  code  was originally developed at Bolt Beranek and Newman
> (BBN)
>         under contract to  the  Defense  Advanced  Research  Projects
> Agency
>         (DARPA).
>
> The JSYS instruction is the PDP-10 system call.
>
> I also found a memo, design.mem, with the header
>
>                   Black Arts
>                       of
>         Transmission Control Protocol
>             Inter Network Protocol
>                 Implementation
>                     in the
>             VAX / VMS Environment
>
>                   July 1982
>
>                 Stan C. Smith
>                Tektronix, Inc.
>         Computer Resource Dept 50-454
>                  P.O. box 500
>            Beaverton, Oregon  97077
>
> that describes the VAX/VMS TCP/IP code written in Bliss, a systems
> programming language that was developed at CMU for DEC, and used by a
> few sites with DEC development contracts.  Otherwise, it was a
> licensed software product that was too expensive for us to have on our
> PDP-10, PDP-11, and VAX systems.
>
> Instead, we wrote such code in assembly language, and later, in Pascal
> (TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
> compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
> written by Kok Chen at Stanford and significantly extended for systems
> programming work by Ken Harrenstien at SRI International), and PCL
> (Programmable Command Language, a DEC compiler available only on
> TOPS-20). Once C became available on the PDP-10 and VAX, it was
> clearly the language of choice for software tools, and assembly code
> was a dead end with the growth in minicomputer and microprocessor
> architectures.
>
> For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
> structured Fortran developed at JPL in Pasadena, and machine
> translated to standard Fortran 66 and 77), with only low-level
> primitives for character and bit processing, and system calls, written
> in assembly code.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
> <(801)%20581-5254>                  -
> - University of Utah                    FAX: +1 801 581 4148
> <(801)%20581-4148>                  -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


From geoff at iconia.com  Tue Mar 10 05:34:32 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 02:34:32 -1000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <7weeu0inm2.fsf@junk.nocrew.org>
 <CABf5zv+FydEXEztrGLDCWEorYnnXk+FOPNLHkPJGrvYqwhkuvQ@mail.gmail.com>
Message-ID: <CAEf-zrjS5yCDTaCOZj1yMou_OavexmmrQwCV2Lp9g0qrU8+5aA@mail.gmail.com>

there was a substantive change to the file system between Tenex (BBN) and
TOPS-20 (DEC) in that TOPS-20 was much more robust and didn't require
CHECKDISK (and also optionally  BSYS Verify) to be run at (re)boot time.

Dan Lynch hacked CHECKDISK to speed up significantly by creating a FORK
(process) for each disk drive... as the CHECKDISKing took longer and longer
as more and more washing machine disk drives got added. :D

the TOPS-20 file system also had the ability to have sub-directories which
was lacking on Tenex... and file version numbers went from ;'s to .'s...

sadly, there are no Tenex systems on the net today that yours truly is away
of, but if you wish a trip down memory lane: there are a couple of
free/public access TOPS-20 systems available at https://sdf.org/twenex/ which
you can SSH into with "ssh twenex at sdf.org" as well as at
https://livingcomputers.org/ which you can SSH into with ssh
toad2 at tty.livingcomputermuseum.org

geoff

On Mon, Mar 9, 2020 at 11:16 PM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> Lars,
>
> Thanks.  For anyone who hasn't tracked PDP-10 operating systems, I believe
> TOPS-20 and Tenex were the same.  Tenex was developed at BBN.  DEC provided
> the TOPS-10 operating system but it was less capable than Tenex.  DEC
> acquired the rights to Tenex and brought it out as TOPS-20.  I don't know
> if there are substantive changes in the process; I have the impression
> there weren't.
>
> These systems were connected to the Arpanet when NCP was the host level
> protocol.  I didn't follow their history through the transition to TCP/IP,
> but I have the impression they continued to be commonplace on the Internet
> and thus would have had TCP/IP implementations.  Others can fill in the
> gaps here better than I can.
>
> Steve
>
>
> On Tue, Mar 10, 2020 at 5:08 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>
> > Steve Crocker wrote:
> > > I don't think C was used or available on Tenex, but I'm not the most
> > > authoritative source.
> >
> > There were several PDP-10 C compilers, but I'm not sure whether one
> > actually ran on Tenex.  Some ran on TOPS-20, so it wouldn't have been a
> > big leap.
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From lars at nocrew.org  Tue Mar 10 05:39:14 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 10 Mar 2020 12:39:14 +0000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu> (Nelson
 H. F. Beebe via Internet-history's message of "Tue, 10 Mar 2020
 06:31:33 -0600")
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
Message-ID: <7w7dzsidu5.fsf@junk.nocrew.org>

Nelson H. F. Beebe wrote:
> KCC, written by Kok Chen at Stanford and significantly extended for
> systems programming work by Ken Harrenstien at SRI International

Ken Harrenstien also added TCP/IP to the ITS operating system in late
1982.  The implemenation language was PDP-10 MIDAS assembler.


From jnc at mercury.lcs.mit.edu  Tue Mar 10 05:42:19 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 10 Mar 2020 08:42:19 -0400 (EDT)
Subject: [ih] NCP and TCP implementations
Message-ID: <20200310124219.B284718C0C5@mercury.lcs.mit.edu>

    > From: vinton cerf

    > Steve Kirsch asks in what languages NCP and TCP were written.

The NCP for PDP-11 Unix was in C; the source for that still exists, and is
online here:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC
  
The ITS NCP was written in MIDAS, the PDP-10 macro assembler. The source
still exists, and is online.


    > Another version was written for PDP-11/23 by Jim Mathis but not clear in
    > what language.

That TCP was in Macro-11; the source for that one still exists in
machine-readable form, but is not yet openly available online. Oh, and it
would run on any -11, not just the /23.

    > Tenex was probably done in C at BBN.

BBN did two different PDP-11 TCPs for Unix (early on; later they did one for
VAX Unix); one was in Macro-11, and is not available (but Jack Haverty might
have it in hard-copy); one was in C, and is available here:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6

    > Was 360 done in PL/1?? Dave Clark did one for IBM PC (assembly
    > language/??)

Dave Clark did two TCPs (well, he worked on two, but only one he did from
scratch): one in PL/1 for Multics (started by Drew Mason, I think that was his
name), a later version of which is still available in the emulated Multics;
and he wrote one in scratch in BCPL for the Alto, which I suspect is lost.

The one for the PC was done by David Bridgham and John Ronkey, and was in C;
the source for a slightly later version still exists in machine-readable form,
but again I'm not sure if it's openly available online yet.

    > Other recollections much appreciated.

There were several in C done at MIT for V6 Unix. One was a translation of Dave
Clark's Alto one into C by Larry Allen (I suspect?), which was only suitable
for low-bandwith applications (e.g. User TELNET) the other was from scratch,
by Liza Martin, in C. Both also still exists in machine-readable form, but are
not yet openly available online.

    Noel


From geoff at iconia.com  Tue Mar 10 05:46:33 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 02:46:33 -1000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
Message-ID: <CAEf-zriOgDTtct2w1n=-sBer7tKMz5oBGHvjrOW+0BtKZZ_wsg@mail.gmail.com>

there were at least two NCP implementations for UNIX...  one was written by
Steve Zucker at RAND and the other was (perhaps?) written by Steve Holmgren
at the University of illinois Urbana-Champaign.

yours truly had interactions with both of these NCP implementations --
with Steve Holmgren integrating the Network Virtual Terminals into the
kernel (from the telnetd pty processes).

the Rand NCP implementation (in Peter Weiner's RAND-ISD lab) "lost" and to
yours trulys knowledge didn't get adopted outside of RAND.

geoff


On Mon, Mar 9, 2020 at 10:29 PM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> If memory serves, prior to Multics and Unix and with the exception of the
> Burrough?s computers, operating systems were written in the assembly
> language of the machine.  This includes the Sigma 7 (host 1), the SDS 940
> (host 2), the IBM 360 (host 3) and Tenex (host 4).  The NCP (?Network
> Control *Program*") was an addition to the existing code of the operating
> system and, I believe, written in the same language as the operating
> system.  I think C appeared with Unix.  I don't think C was used or
> available on Tenex, but I'm not the most authoritative source.  I don't
> know much about the later implementations of NCP.  PDP-11s became popular
> and there were several operating systems written for them.  ELF (Dave Retz
> in Santa Barbara) and ANTS (University of Illinois) come to mind, and I
> think there were others.  At the time, I had the impression writing network
> compatible operating systems for the PDP-11 was a cottage industry.
>
> It would be interesting to compare the timelines of the transition from NCP
> to TCP/IP with the evolution of hosts from the Tenex era to the Unix era.
>
> Steve
>
> On Tue, Mar 10, 2020 at 2:09 AM Vint Cerf <vint at google.com> wrote:
>
> > NCP was probably done in assembly language for most operating systems -
> > adding steve crocker for comment
> > TCP was written in BCPL at Stanford for PDP-11/40. Probaby C for Tenex.
> > PL/1 (?) for 360's???
> >
> > Let me ask the Internet History list.
> >
> > v
> >
> >
> > On Tue, Mar 10, 2020 at 2:03 AM Steve Kirsch <stk at m10.io> wrote:
> >
> >> Was it written in C? you?d think only a small part would have to be
> >> customized for the operating system?!
> >>
> >>
> >>
> >> *From:* Vint Cerf <vint at google.com>
> >> *Sent:* Monday, March 9, 2020 1:59 AM
> >> *To:* Steve Kirsch <stk at m10.io>
> >> *Subject:* Re: NCP, TCP/IP question
> >>
> >>
> >>
> >> 1. NCP was written individually for each operating system
> >>
> >> 2. TCP was also written for each operating system but UNIX propagated
> >> most widely; TENEX version was popular for PDP-10s.
> >>
> >> Bob Braden did the TCP for IBM 360/91 and I think that got ported to
> >> 360/75 at UCSB. Berkeley BSD 4.2 and follow-ons was most widely spread
> for
> >> UNIX.
> >>
> >>
> >>
> >> v
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 9, 2020 at 4:15 AM Steve Kirsch <stk at m10.io> wrote:
> >>
> >>
> >>    1. Did UCLA provide the source code for NCP and TCP/IP for various
> >>    places to run?
> >>
> >>
> >>
> >>    1. Or did everyone write their own implementation based on the spec?
> >>
> >>
> >>
> >> If the latter, was that problematic? Would it have been easier if
> >> everyone ran Unix and there was C source code that was distributed to
> >> everyone to run? Is that in fact what in fact happened? Why UCLA lost
> their
> >> SEX and became EUNUCHs? I mean UNIX?
> >>
> >>
> >>
> >>
> > --
> >>
> >> New postal address:
> >>
> >> Google
> >>
> >> 1875 Explorer Street, 10th Floor
> >> <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
> >
> >>
> >> <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
> >
> >>
> >> <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
> >
> >>
> >> <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
> >
> >>
> >> Reston, VA 20190
> >> <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
> >
> >>
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
> >
> > Reston, VA 20190
> > <
> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
> >
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From jeanjour at comcast.net  Tue Mar 10 05:51:41 2020
From: jeanjour at comcast.net (John Day)
Date: Tue, 10 Mar 2020 08:51:41 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CAEf-zriOgDTtct2w1n=-sBer7tKMz5oBGHvjrOW+0BtKZZ_wsg@mail.gmail.com>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <CAEf-zriOgDTtct2w1n=-sBer7tKMz5oBGHvjrOW+0BtKZZ_wsg@mail.gmail.com>
Message-ID: <7CAB13EB-5B84-48DF-B1D4-B1E92839BBD6@comcast.net>

Holmgren wrote the NCP under the close watch of Gary Grossman and I believe Steve Bunch got into the picture at some point. Grossman was lead on the TCP implementations but they eventually went over to Dave Healy.

> On Mar 10, 2020, at 08:46, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> there were at least two NCP implementations for UNIX...  one was written by
> Steve Zucker at RAND and the other was (perhaps?) written by Steve Holmgren
> at the University of illinois Urbana-Champaign.
> 
> yours truly had interactions with both of these NCP implementations --
> with Steve Holmgren integrating the Network Virtual Terminals into the
> kernel (from the telnetd pty processes).
> 
> the Rand NCP implementation (in Peter Weiner's RAND-ISD lab) "lost" and to
> yours trulys knowledge didn't get adopted outside of RAND.
> 
> geoff
> 
> 
> On Mon, Mar 9, 2020 at 10:29 PM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> If memory serves, prior to Multics and Unix and with the exception of the
>> Burrough?s computers, operating systems were written in the assembly
>> language of the machine.  This includes the Sigma 7 (host 1), the SDS 940
>> (host 2), the IBM 360 (host 3) and Tenex (host 4).  The NCP (?Network
>> Control *Program*") was an addition to the existing code of the operating
>> system and, I believe, written in the same language as the operating
>> system.  I think C appeared with Unix.  I don't think C was used or
>> available on Tenex, but I'm not the most authoritative source.  I don't
>> know much about the later implementations of NCP.  PDP-11s became popular
>> and there were several operating systems written for them.  ELF (Dave Retz
>> in Santa Barbara) and ANTS (University of Illinois) come to mind, and I
>> think there were others.  At the time, I had the impression writing network
>> compatible operating systems for the PDP-11 was a cottage industry.
>> 
>> It would be interesting to compare the timelines of the transition from NCP
>> to TCP/IP with the evolution of hosts from the Tenex era to the Unix era.
>> 
>> Steve
>> 
>> On Tue, Mar 10, 2020 at 2:09 AM Vint Cerf <vint at google.com> wrote:
>> 
>>> NCP was probably done in assembly language for most operating systems -
>>> adding steve crocker for comment
>>> TCP was written in BCPL at Stanford for PDP-11/40. Probaby C for Tenex.
>>> PL/1 (?) for 360's???
>>> 
>>> Let me ask the Internet History list.
>>> 
>>> v
>>> 
>>> 
>>> On Tue, Mar 10, 2020 at 2:03 AM Steve Kirsch <stk at m10.io> wrote:
>>> 
>>>> Was it written in C? you?d think only a small part would have to be
>>>> customized for the operating system?!
>>>> 
>>>> 
>>>> 
>>>> *From:* Vint Cerf <vint at google.com>
>>>> *Sent:* Monday, March 9, 2020 1:59 AM
>>>> *To:* Steve Kirsch <stk at m10.io>
>>>> *Subject:* Re: NCP, TCP/IP question
>>>> 
>>>> 
>>>> 
>>>> 1. NCP was written individually for each operating system
>>>> 
>>>> 2. TCP was also written for each operating system but UNIX propagated
>>>> most widely; TENEX version was popular for PDP-10s.
>>>> 
>>>> Bob Braden did the TCP for IBM 360/91 and I think that got ported to
>>>> 360/75 at UCSB. Berkeley BSD 4.2 and follow-ons was most widely spread
>> for
>>>> UNIX.
>>>> 
>>>> 
>>>> 
>>>> v
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Mar 9, 2020 at 4:15 AM Steve Kirsch <stk at m10.io> wrote:
>>>> 
>>>> 
>>>>   1. Did UCLA provide the source code for NCP and TCP/IP for various
>>>>   places to run?
>>>> 
>>>> 
>>>> 
>>>>   1. Or did everyone write their own implementation based on the spec?
>>>> 
>>>> 
>>>> 
>>>> If the latter, was that problematic? Would it have been easier if
>>>> everyone ran Unix and there was C source code that was distributed to
>>>> everyone to run? Is that in fact what in fact happened? Why UCLA lost
>> their
>>>> SEX and became EUNUCHs? I mean UNIX?
>>>> 
>>>> 
>>>> 
>>>> 
>>> --
>>>> 
>>>> New postal address:
>>>> 
>>>> Google
>>>> 
>>>> 1875 Explorer Street, 10th Floor
>>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>>> 
>>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>>> 
>>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>>> 
>>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>>> 
>>>> Reston, VA 20190
>>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>>> 
>>> 
>>> 
>>> --
>>> New postal address:
>>> Google
>>> 1875 Explorer Street, 10th Floor
>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>> Reston, VA 20190
>>> <
>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
>>> 
>>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> 
> 
> -- 
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> http://geoff.livejournal.com
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From geoff at iconia.com  Tue Mar 10 05:53:47 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 02:53:47 -1000
Subject: [ih] Before the DNS: How yours truly upstaged The NIC's
 Official HOSTS.TXT (An Internet history lesson)
In-Reply-To: <7D3259F5-86FC-42D0-9639-E72C6C0EEE9A@shinkuro.com>
References: <CAEf-zriM0=4vtWneg6LQ6LqEzXvLYvgXQ+q9Pcd+az7pAOwWGw@mail.gmail.com>
 <7D3259F5-86FC-42D0-9639-E72C6C0EEE9A@shinkuro.com>
Message-ID: <CAEf-zrg+6jh1SMRun5kX4bNU7BwnqOLnNDEDr-BfFGRiDcq8gg@mail.gmail.com>

steve,

don't recall exact what early 70's year yours truly started doing this
other than it surely commenced once yours truly became a "Tenex wheel" and
was able to edit
<SYSTEM>HOST-NAME/DESCRIPTOR-FILE.TXT

RST came into being with the inception of NCP, viz. NIC 8246:
https://ban.ai/multics/doc/McKenzieNCP1972.pdf
and later wanting to be changed, viz.:

Network Working Group                                       J. Burchfiel
Request for Comments: 467                                   R. Tomlinson
NIC: 14741                                       Bolt Beranek and Newman
                                                        20 February 1973

                 Proposed Change To Host-Host Protocol
                Resynchronization Of Connection Status



geoff

On Wed, Feb 5, 2020 at 9:45 PM Steve Crocker <steve at shinkuro.com> wrote:

> Geoff,
>
> Do you remember when you started doing this?
>
> Also, when did RST come into being?
>
> Thanks,
>
> Steve
>
> P.S. Feel free to share on the list if you wish.
>
> Sent from my iPhone
>
> > On Feb 5, 2020, at 10:05 PM, the keyboard of geoff goodfellow via
> Internet-history <internet-history at elists.isoc.org> wrote:
> >
> > ?copy and pasted from https://iconia.com/before_the_dns.txt:
> >
> > Back in the early '70s of the ARPANET... before the Domain Name System
> (DNS)
> > even existed, the Network Information Center (NIC) based at SRI
> > International controlled and distributed The Official Host Table for The
> Net
> > called HOSTS.TXT. The NIC updated this table through "official channels"
> and
> > host administrators would periodically transfer over a new version of the
> > table to their systems. There was Just One Problem: The Official Channels
> > took forever for the NIC to update HOSTS.TXT and therefore The Nets host
> > table was frequently out of date with the reality of what was actually up
> > and operating on The Net.
> >
> > What I did, as a nobody teenager and budding system and network janitor
> at
> > the time, was to notice new "nameless" hosts when they came up on the
> net by
> > looking at a 'netstat' of hosts that did not have host names and only
> > showed up as numbers.  This was easy because in those early days the
> Network
> > Control Program known as NCP (this was before TCP/IP) would broadcast
> > messages called RSTs to every possible host address on the network when
> they
> > booted.  What RSTs did was say to a host: "Hi there, please mark me as
> UP in
> > your netstat listing and if you have any left over connections from the
> time
> > I went down, please reset them".
> >
> > I would then telnet or ftp to these nameless hosts and see what host name
> > the operating system login prompt gave me or what host name the ftp
> server
> > announced in its greeting. I would then plug this information into my
> > systems host table.
> >
> > Word started to spread through the grapevine to other system and network
> > janitors that my system's host table was the most up to date on The Net.
> You
> > can imagine what happened next: many system administrators started to
> > reference my host table instead of the NIC's. Someone suggested I create
> a
> > notification list so that every time my hostable was updated they would
> know
> > to install a new one (Some even installed automated daily processes that
> > would transfer over my host table without any human intervention.)
> >
> > When the NIC got wind of being upstaged by this guerilla/underground host
> > table information gathering and distribution network, they were mightily
> > unhappy about having their monopoly authority challenged. but, EACH OF
> THE
> > SYSTEM ADMINISTRATORS MADE AN INDIVIDUAL CHOICE: Geoff Goodfellow's
> hostable
> > was more up to date and better managed than the NIC's Official HOSTS.TXT
> > table, so WE CHOOSE TO USE IT.
> >
> > There was absolutely nothing the NIC could do to stop these individual
> > system admins from each making their own decision about who they wanted
> to
> > trust and where to get the most up to date host information. As far as
> > I know my host table was the preferred host table used by the majority of
> > sites on The Net until the DNS came along and host tables became moot.
> >
> > Please note that I did not develop my host table for the net. I just
> needed
> > one for my site that was more up-to-date, so I figured out how to create
> it.
> > Then my friends copied it, and word spread, and the market made its free
> > choice. Of course, I did not mind this happening, since they were just
> > copying what I needed to make for myself.
> >
> > --
> > Geoff.Goodfellow at iconia.com
> > living as The Truth is True
> > http://geoff.livejournal.com
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From bernie at fantasyfarm.com  Tue Mar 10 05:57:16 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 10 Mar 2020 08:57:16 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <7w7dzsidu5.fsf@junk.nocrew.org>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
 <7w7dzsidu5.fsf@junk.nocrew.org>
Message-ID: <170c4854fe0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>

On March 10, 2020 08:39:31 Lars Brinkhoff via Internet-history 
<internet-history at elists.isoc.org> wrote:

> Nelson H. F. Beebe wrote:
>> KCC, written by Kok Chen at Stanford and significantly extended for
>> systems programming work by Ken Harrenstien at SRI International
>
> Ken Harrenstien also added TCP/IP to the ITS operating system in late
> 1982.  The implemenation language was PDP-10 MIDAS assembler.

side note : Bill mann {I think} put MIDAS on our pdp-1 and
it's macro processor was good enough that I could hack it
to being a 516 assembler {16 bit words,  512 word paged
memory} and Dave walden and I moved the IMP system sources
from a godawful roll of paper tape to being happily
cross-assembled on the pdp-1.


/b\

                     Bernie Cosell
           bernie at fantasyfarm. com
? Too many people,  too few sheep ?


From steve.bunch at gmail.com  Tue Mar 10 06:00:32 2020
From: steve.bunch at gmail.com (Steve Bunch)
Date: Tue, 10 Mar 2020 09:00:32 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <7CAB13EB-5B84-48DF-B1D4-B1E92839BBD6@comcast.net>
References: <BYAPR14MB26130714334B4CA072DCCF55D2FE0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggdLaM+DtjTgrGjfZdiGhzTTdhbtbauTGQV_motaZgEayA@mail.gmail.com>
 <BYAPR14MB2613BB90AD104BED83BA0B78D2FF0@BYAPR14MB2613.namprd14.prod.outlook.com>
 <CAHxHggepaGzj4H4=xfuzb87xXkHu_HHrXBoW5_qSX6HsHseMzA@mail.gmail.com>
 <CABf5zvLLUutS-2W+EL7N20-46XP2LjTZpBqhxbxZQQU9Tq3Z-g@mail.gmail.com>
 <CABf5zvKVtFXoBbNvRChrLME8SuwuAuEcnPLD9t_Q088X7hi2mg@mail.gmail.com>
 <CAEf-zriOgDTtct2w1n=-sBer7tKMz5oBGHvjrOW+0BtKZZ_wsg@mail.gmail.com>
 <7CAB13EB-5B84-48DF-B1D4-B1E92839BBD6@comcast.net>
Message-ID: <219C5F1A-4FF5-4880-86A8-778BAC10B2B7@gmail.com>

Steve Holmgren wrote the kernel portion of the NCP, which was the connection data passing portion.  Gary Grossman wrote the user-level NCP daemon that took care of initialization, and connection establishment and teardown.  I wrote the kernel memory management code.

Since this was the third NCP being written by Gary and Steve H (ANTS and ANTS II)., it took only a few weeks to write and bring up.

Steve

> On Mar 10, 2020, at 8:51 AM, John Day via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Holmgren wrote the NCP under the close watch of Gary Grossman and I believe Steve Bunch got into the picture at some point. Grossman was lead on the TCP implementations but they eventually went over to Dave Healy.
> 
>> On Mar 10, 2020, at 08:46, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>> there were at least two NCP implementations for UNIX...  one was written by
>> Steve Zucker at RAND and the other was (perhaps?) written by Steve Holmgren
>> at the University of illinois Urbana-Champaign.
>> 
>> yours truly had interactions with both of these NCP implementations --
>> with Steve Holmgren integrating the Network Virtual Terminals into the
>> kernel (from the telnetd pty processes).
>> 
>> the Rand NCP implementation (in Peter Weiner's RAND-ISD lab) "lost" and to
>> yours trulys knowledge didn't get adopted outside of RAND.
>> 
>> geoff
>> 
>> 
>> On Mon, Mar 9, 2020 at 10:29 PM Steve Crocker via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>> 
>>> If memory serves, prior to Multics and Unix and with the exception of the
>>> Burrough?s computers, operating systems were written in the assembly
>>> language of the machine.  This includes the Sigma 7 (host 1), the SDS 940
>>> (host 2), the IBM 360 (host 3) and Tenex (host 4).  The NCP (?Network
>>> Control *Program*") was an addition to the existing code of the operating
>>> system and, I believe, written in the same language as the operating
>>> system.  I think C appeared with Unix.  I don't think C was used or
>>> available on Tenex, but I'm not the most authoritative source.  I don't
>>> know much about the later implementations of NCP.  PDP-11s became popular
>>> and there were several operating systems written for them.  ELF (Dave Retz
>>> in Santa Barbara) and ANTS (University of Illinois) come to mind, and I
>>> think there were others.  At the time, I had the impression writing network
>>> compatible operating systems for the PDP-11 was a cottage industry.
>>> 
>>> It would be interesting to compare the timelines of the transition from NCP
>>> to TCP/IP with the evolution of hosts from the Tenex era to the Unix era.
>>> 
>>> Steve
>>> 
>>> On Tue, Mar 10, 2020 at 2:09 AM Vint Cerf <vint at google.com> wrote:
>>> 
>>>> NCP was probably done in assembly language for most operating systems -
>>>> adding steve crocker for comment
>>>> TCP was written in BCPL at Stanford for PDP-11/40. Probaby C for Tenex.
>>>> PL/1 (?) for 360's???
>>>> 
>>>> Let me ask the Internet History list.
>>>> 
>>>> v
>>>> 
>>>> 
>>>> On Tue, Mar 10, 2020 at 2:03 AM Steve Kirsch <stk at m10.io> wrote:
>>>> 
>>>>> Was it written in C? you?d think only a small part would have to be
>>>>> customized for the operating system?!
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:* Vint Cerf <vint at google.com>
>>>>> *Sent:* Monday, March 9, 2020 1:59 AM
>>>>> *To:* Steve Kirsch <stk at m10.io>
>>>>> *Subject:* Re: NCP, TCP/IP question
>>>>> 
>>>>> 
>>>>> 
>>>>> 1. NCP was written individually for each operating system
>>>>> 
>>>>> 2. TCP was also written for each operating system but UNIX propagated
>>>>> most widely; TENEX version was popular for PDP-10s.
>>>>> 
>>>>> Bob Braden did the TCP for IBM 360/91 and I think that got ported to
>>>>> 360/75 at UCSB. Berkeley BSD 4.2 and follow-ons was most widely spread
>>> for
>>>>> UNIX.
>>>>> 
>>>>> 
>>>>> 
>>>>> v
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Mar 9, 2020 at 4:15 AM Steve Kirsch <stk at m10.io> wrote:
>>>>> 
>>>>> 
>>>>>  1. Did UCLA provide the source code for NCP and TCP/IP for various
>>>>>  places to run?
>>>>> 
>>>>> 
>>>>> 
>>>>>  1. Or did everyone write their own implementation based on the spec?
>>>>> 
>>>>> 
>>>>> 
>>>>> If the latter, was that problematic? Would it have been easier if
>>>>> everyone ran Unix and there was C source code that was distributed to
>>>>> everyone to run? Is that in fact what in fact happened? Why UCLA lost
>>> their
>>>>> SEX and became EUNUCHs? I mean UNIX?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> --
>>>>> 
>>>>> New postal address:
>>>>> 
>>>>> Google
>>>>> 
>>>>> 1875 Explorer Street, 10th Floor
>>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>>> 
>>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>>> 
>>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>>> 
>>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>>> 
>>>>> Reston, VA 20190
>>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+%0D%0A+%0D%0A+%0D%0A+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> New postal address:
>>>> Google
>>>> 1875 Explorer Street, 10th Floor
>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>> Reston, VA 20190
>>>> <
>>> https://www.google.com/maps/search/1875+Explorer+Street,+10th+Floor+Reston,+VA+20190?entry=gmail&source=g
>>>> 
>>>> 
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>> 
>>> 
>> 
>> -- 
>> Geoff.Goodfellow at iconia.com
>> living as The Truth is True
>> http://geoff.livejournal.com
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From wayne at playaholic.com  Tue Mar 10 06:30:04 2020
From: wayne at playaholic.com (Wayne Hathaway)
Date: Tue, 10 Mar 2020 09:30:04 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <1583847004.7ax86rre8s8o44c8@hostingemail.digitalspace.net>

My implementations for the IBM 360/67 TSS system at NASA Ames
were all done in 360 Assembler Language.  That was just the language
that was used for TSS systems work; no real alternatives.

wayne



On Tue, 10 Mar 2020 02:14:54 -0400, vinton cerf via Internet-history <internet-history at elists.isoc.org> wrote:

>> Steve Kirsch asks in what languages NCP and TCP were written.
>>
>> The Stanford first TCP implementation was done in BCPL by Richard Karp.
>> Another version was written for PDP-11/23 by Jim Mathis but not clear in
>> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
>> Dave Clark did one for IBM PC (assembly language/??)
>>
>> Other recollections much appreciated.
>>
>> vint
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history


From clemc at ccc.com  Tue Mar 10 06:43:46 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 10 Mar 2020 09:43:46 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <CAC20D2NjGdmEp_jOatEROg6GCOszuNyMWCEYO-TjUwsjQHiNbw@mail.gmail.com>

I can offer the history on the first VAX/VMS implementation.  Stan Smith
and I wrote that IP/TCP stack and userspace commands in BLISS at Tektronix
in the winter of 79-80.  I later gave it my old cronies at CMU, who hacked
on it (primarily adding the SMTP mailer interface which we had not yet
written).

Stan and I would have used C if we had had a C compiler for the Vax; but
DEC had not written/released one yet (at least a year or two away).  So,
our choices at the time were BLISS, Fortran, Assembler (and maybe Pascal).
Stan was pushing a little for the latter two as he was coming from NOS and
the CDC systems were Fortran and Assemblker were king, plus we already had
licenses for them from DEC on the system.   But being a CMU person, I
already knew BLISS  and been using for a number of years on the Vaxen at
CMU, and convinced him that BLISS would be easier (if I remember correctly,
this was around the time when the larger part of DEC had been using BLISS
for all most of its userspace code and that was part of my argument).   We
did have to cons up $5k for a compiler license (IIRC management was none
too happy about the unexpected $5K).  But I taught it to Stan and off we
went.  Funny, that was probably the last BLISS code I ever wrote.

BTW:   Vint, there was an early 36-bit C compiler for the PDP-10 done at
MIT originally for ITS, I want to say '75/'76 timeframe (it was a master
project for Alan Synder IIRC:
https://github.com/PDP-10/Snyder-C-compiler/blob/master/MAC-TR-149.pdf).
It was moved to TOPS and TENEX; but the code it generated was not that
stellar (check out about page 26 or so of the report).   So at the time,
Assembler and BLISS (and LISP at MIT) were the primary systems programming
languages for the 10s.

Clem

On Tue, Mar 10, 2020 at 2:15 AM vinton cerf via Internet-history <
internet-history at elists.isoc.org> wrote:

> Steve Kirsch asks in what languages NCP and TCP were written.
>
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
>
> Other recollections much appreciated.
>
> vint
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From bob.hinden at gmail.com  Tue Mar 10 09:01:45 2020
From: bob.hinden at gmail.com (Bob Hinden)
Date: Tue, 10 Mar 2020 09:01:45 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>

Vint,

I did an NCP implementation for the BBN Pluribus TIP, must have been in Pluribus assembly language.

I later did a TCP implementation for the TAC in H-316 assembly language.   Was lots of fun doing 32-bit segment calculations on a machine with 15-bit arithmetic.

Bob


> On Mar 9, 2020, at 11:14 PM, vinton cerf via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Steve Kirsch asks in what languages NCP and TCP were written.
> 
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
> 
> Other recollections much appreciated.
> 
> vint
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20200310/2c9f9d54/attachment.asc>

From karl at cavebear.com  Tue Mar 10 10:04:27 2020
From: karl at cavebear.com (Karl Auerbach)
Date: Tue, 10 Mar 2020 10:04:27 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <1731bce4-d891-9ced-e7ff-62ea4cd08b5c@cavebear.com>

I have a somewhat vague memory of a University of Illinois 
implementation dating from the mid-to-late 1970's.

I mostly remember that it ran on Unix and thus was probably written in C.

It had a large daemon (that contained most of the protocol code) and a 
small daemon (that mainly listened for incoming connections and exec-ed 
itself to become the large daemon.)

I had most direct interaction with it at some gov't offices (DoD 
related) in Reston, VA.

The Dave Clark/MIT one was perhaps the PC/IP one written by John Romkey 
and Dave Bridgham?? That was nearly all in C.? Some tiny parts (such as 
the code that did an audio chirp in its telnet client) were in assembly 
language.?? That TCP implementation was constructed on the assumption 
that its only application would be a human typing on a telnet session, 
so it simplified the code by ignoring the offered receive window on the 
assumption that a human could never type fast enough to fill whatever 
window was offered. That's why it had to be re-written (again, in C) 
when it it became PC/TCP from FTP Software.

 ??? ??? --karl--




From karl at cavebear.com  Tue Mar 10 10:12:51 2020
From: karl at cavebear.com (Karl Auerbach)
Date: Tue, 10 Mar 2020 10:12:51 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <1731bce4-d891-9ced-e7ff-62ea4cd08b5c@cavebear.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <1731bce4-d891-9ced-e7ff-62ea4cd08b5c@cavebear.com>
Message-ID: <09c7cafd-bd87-3adf-6f57-b78122c0f56f@cavebear.com>

By-the-way, Diane Cabel wrote the very short and very open MIT software 
license that was applied to the MIT PC/IP code.

I'm am not sure which predated which, the Berkeley BSD license or the 
MIT license.

 ??? ??? --karl--



From louie at transsys.com  Tue Mar 10 10:13:48 2020
From: louie at transsys.com (Louis Mamakos)
Date: Tue, 10 Mar 2020 13:13:48 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <BB019EB9-A33C-4A5B-B559-FEB1858D675F@transsys.com>

The implementation that Mike Petry and I did at the University of 
Maryland
for our UNIVAC 1108 and 1100/40 was first written in UNIVAC assembly 
code.  This
was in the early 1980's, initially as a class project that turned into
a real "thing".

Later large parts were reimplemented in PLUS, a systems programming 
language that
UNIVAC / Sperry / UniSys created for the 1100 (and later, 2200) series 
of
mainframes.  That implementation later ran on 1100/80, 1100/70 and 
1100/90
series UniSys mainframes.  TELNET, FTP and SMTP servers and various 
weird printing
and batch job submission services were supported.

louie


On 10 Mar 2020, at 2:14, vinton cerf via Internet-history wrote:

> Steve Kirsch asks in what languages NCP and TCP were written.
>
> The Stanford first TCP implementation was done in BCPL by Richard 
> Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear 
> in
> what language. Tenex was probably done in C at BBN. Was 360 done in 
> PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
>
> Other recollections much appreciated.
>
> vint
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history


From leo at vegoda.org  Tue Mar 10 10:19:37 2020
From: leo at vegoda.org (Leo Vegoda)
Date: Tue, 10 Mar 2020 10:19:37 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
Message-ID: <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>

On Tue, Mar 10, 2020 at 9:02 AM Bob Hinden via Internet-history
<internet-history at elists.isoc.org> wrote:

[...]

> I later did a TCP implementation for the TAC in H-316 assembly language.
> Was lots of fun doing 32-bit segment calculations on a machine with 15-bit arithmetic.

Do you know why the designers of the TAC chose 15-bit arithmetic for it?

Thanks,

Leo


From steve at shinkuro.com  Tue Mar 10 10:23:46 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 13:23:46 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
Message-ID: <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>

The TAC was an extension of the IMP.  The original IMP was built on the
Honeywell 516 (and later 316) platform, which was a 16 bit twos complement
computer.  I assume Hinden's reference to 15-bit arithmetic reflected the
fact that the arithmetic was signed.

Steve


On Tue, Mar 10, 2020 at 1:20 PM Leo Vegoda via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Tue, Mar 10, 2020 at 9:02 AM Bob Hinden via Internet-history
> <internet-history at elists.isoc.org> wrote:
>
> [...]
>
> > I later did a TCP implementation for the TAC in H-316 assembly language.
> > Was lots of fun doing 32-bit segment calculations on a machine with
> 15-bit arithmetic.
>
> Do you know why the designers of the TAC chose 15-bit arithmetic for it?
>
> Thanks,
>
> Leo
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From jack at 3kitty.org  Tue Mar 10 10:30:01 2020
From: jack at 3kitty.org (Jack Haverty)
Date: Tue, 10 Mar 2020 10:30:01 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
Message-ID: <e2cb399e-0ed8-b11b-1ca2-113c833fba2a@3kitty.org>

The first TCP implementation for Unix was done in PDP-11 assembly
language, running on a PDP-11/40 (with way too little memory or address
space).?? It was built using code fragments excerpted from the LSI-11
TCP implementation provided by Jim Mathis, which ran under SRI's
home-built OS.? Jim's TCP was all written in PDP-11 assembler.? The code
was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded
over a TTY line to the PDP-11/40.? That was much easier and faster than
doing all the implementation work on the PDP-11.

The code architecture involved putting TCP itself at the user level,
communicating with its "customers" using Unix InterProcess
Communications facilities (Rand "Ports").?? It would have been
preferable to implement TCP within the Unix kernel, but there was simply
not enough room due to the limited address space available on the 11/40
model.? Later implementations of TCP, on larger machines with twice the
address space, were done in the kernel.? In addition to the Berkeley BSD
work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP
implementation for the PDP-11/70 and Vax.

The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as
was Jim's LSI-11 code.? This 2.5 implementation was one of the players
in the first "TCP Bakeoff" organized by Jon Postel and carried out on a
weekend at ISI before the quarterly Internet meeting.? The PDP-11/40 TCP
was modified extensively over the next year or so as TCP advanced
through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems
we still have today, 40+ years later!)

The Unix TCP implementation required a small addition to the Unix kernel
code, to add the "await" and "capac" system calls.? Those calls were
necessary to enable the implementation of user-level code where the
traditional Unix "pipeline" model of programming
(input->process->process...->output) was inadequate for use in
multi-computer programming (such as FTP, Telnet, etc., - anywhere where
more than one computer was involved).

The code to add those new system calls was written in C, as was almost
all of the Unix OS itself.? The new system calls added the functionality
of "non-blocking I/O" which did not previously exist.? It involved very
few lines of code, since there wasn't room for very many more
instructions, and even so it required finding more space by shortening
many of the kernel error messages to save a few bytes here and there.

Randy Rettberg and I did that work, struggling to understand how Unix
kernel? internals worked, since neither of us had ever worked with Unix
before even as a user.?? We did not try to "get it right" by making
significant changes to the basic Unix architecture.? That came later
with the Berkeley and Gurwitz efforts.? The PDP-11/40 was simply too
constrained to support such changes, and our mission was to get TCP
support on the machine, rather than develop the OS.

I think I speak authoritatively here, since I wrote and debugged that
first Unix TCP code.?? I still have an old, yellowing listing of that
first Unix TCP.

FWIW, if there's interest in why certain languages were chosen, there's
a very simple explanation of why the Unix implementation was done in
assembler rather than C, the native language of Unix.? First, Jim
Mathis' code was in assembler, so it was easy to extract large chunks
and paste them into the Unix assembler implementation.? Second, and
probably most important, was that I was very accustomed to writing
assembler code and working at the processor instruction level.? But I
barely knew C existed, and was certainly not proficient in it, and we
needed the TCP working fast for use in other projects.? The choice was
very pragmatic, not based at all on technical issues of languages or
superiority of any architecture.

/Jack Haverty


On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote:
> Steve Kirsch asks in what languages NCP and TCP were written.
>
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
>
> Other recollections much appreciated.
>
> vint


From bernie at fantasyfarm.com  Tue Mar 10 10:44:44 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 10 Mar 2020 13:44:44 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>,
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>,
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
Message-ID: <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>

On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:

> The TAC was an extension of the IMP.  The original IMP was built on
> the
> Honeywell 516 (and later 316) platform, which was a 16 bit twos
> complement
> computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> the
> fact that the arithmetic was signed.

I honestly cannot remember what the TAC was!!   Was that the TIP?   Regardless, 
yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits of page 
address, 1 bit of "this page" or the 0 page, 16Kwords of memory. 

Things got more complicated with the 316 -- it supported 32K words.  What we 
did for the TIP [and maybe the TAC, whatever that was] was to keep the IMP 
*unchanged* in the bottom 16K, and then in the upper 16K we wrote a 
self-contained "host". There was some [small!] hack to fake interrupts and 
input/output to this host but to the IMP it thought it was just another NCP 
connected host.  It'd set up a host output buffer and instead of doing a hardware 
"send" it'd pass control to the upper 16K.  Similarly [at least for the TIP], when it 
got something in from a terminal it'd copy it into a host-input buffer and then 
issue an "interrupt" down to the IMP.   Worked quite well.

  /Bernie\
            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --
   





From steve at shinkuro.com  Tue Mar 10 11:03:25 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 14:03:25 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
Message-ID: <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>

Argh.  I echoed Leo's use of "TAC."  I read it as referring to the TIP.  If
I recall correctly, the "TAC" was an access control method on the TIPs.
"TIP Access Control" I think.

Steve


On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
>
> > The TAC was an extension of the IMP.  The original IMP was built on
> > the
> > Honeywell 516 (and later 316) platform, which was a 16 bit twos
> > complement
> > computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> > the
> > fact that the arithmetic was signed.
>
> I honestly cannot remember what the TAC was!!   Was that the TIP?
>  Regardless,
> yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
> of page
> address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
>
> Things got more complicated with the 316 -- it supported 32K words.  What
> we
> did for the TIP [and maybe the TAC, whatever that was] was to keep the IMP
> *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
> self-contained "host". There was some [small!] hack to fake interrupts and
> input/output to this host but to the IMP it thought it was just another
> NCP
> connected host.  It'd set up a host output buffer and instead of doing a
> hardware
> "send" it'd pass control to the upper 16K.  Similarly [at least for the
> TIP], when it
> got something in from a terminal it'd copy it into a host-input buffer and
> then
> issue an "interrupt" down to the IMP.   Worked quite well.
>
>   /Bernie\
>             Bernie Cosell
>        bernie at fantasyfarm.com
> -- Too many people; too few sheep --
>
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From steve at shinkuro.com  Tue Mar 10 11:06:45 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 14:06:45 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
Message-ID: <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>

To create the TIP, a second bank of memory was added to the 316 and some
interrupts and modes were added to enable switching back and forth between
banks.  It was a bit of a kludge with some unexpected interactions.  The
BBN crew finally sorted out the details and wrote a delightful titled "It's
Amazing That it Works at all."

On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
>
> > The TAC was an extension of the IMP.  The original IMP was built on
> > the
> > Honeywell 516 (and later 316) platform, which was a 16 bit twos
> > complement
> > computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> > the
> > fact that the arithmetic was signed.
>
> I honestly cannot remember what the TAC was!!   Was that the TIP?
>  Regardless,
> yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
> of page
> address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
>
> Things got more complicated with the 316 -- it supported 32K words.  What
> we
> did for the TIP [and maybe the TAC, whatever that was] was to keep the IMP
> *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
> self-contained "host". There was some [small!] hack to fake interrupts and
> input/output to this host but to the IMP it thought it was just another
> NCP
> connected host.  It'd set up a host output buffer and instead of doing a
> hardware
> "send" it'd pass control to the upper 16K.  Similarly [at least for the
> TIP], when it
> got something in from a terminal it'd copy it into a host-input buffer and
> then
> issue an "interrupt" down to the IMP.   Worked quite well.
>
>   /Bernie\
>             Bernie Cosell
>        bernie at fantasyfarm.com
> -- Too many people; too few sheep --
>
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From leo at vegoda.org  Tue Mar 10 11:20:04 2020
From: leo at vegoda.org (Leo Vegoda)
Date: Tue, 10 Mar 2020 11:20:04 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
Message-ID: <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>

On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
<internet-history at elists.isoc.org> wrote:
>
> To create the TIP, a second bank of memory was added to the 316 and some
> interrupts and modes were added to enable switching back and forth between
> banks.  It was a bit of a kludge with some unexpected interactions.  The
> BBN crew finally sorted out the details and wrote a delightful titled "It's
> Amazing That it Works at all."

Am I right in inferring that the key driver behind the design decision
was cost rather than elegance?

Thanks,

Leo


From geoff at iconia.com  Tue Mar 10 11:33:28 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 08:33:28 -1000
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
Message-ID: <CAEf-zrjkENTA0wwQ-83B3KvS+QKWJ3Yis1ZeQRtJb3K99O3CUg@mail.gmail.com>

let's not forget/what about the MTIP's?  i.e. the Terminal Interface
Processors with a Magnetic Tape unit attached...

recalling there was one at GWC and also perhaps another one at Norsar --
further recalling that they were used to "ship" data (from a magtape) to a
"host" somewhere else on the ARPANET.

how dose yours truly "remember" this?  cuz in the Tenex host table
<SYSTEM>HOST-NAME/DESCRIPTOR-FILE.TXT
there were several host "classification" types to "describe" what a given
hosts capabilities entailed: USER, SERVER, TIP, MTIP so that when you went
into a program such as telnet, it would "politely ignore" the USER
defined/declared host names and only recognize the SERVER hosts names... as
USER hosts only did/supported outgoing connections to SERVER hosts. :D

geoff

On Tue, Mar 10, 2020 at 8:07 AM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> To create the TIP, a second bank of memory was added to the 316 and some
> interrupts and modes were added to enable switching back and forth between
> banks.  It was a bit of a kludge with some unexpected interactions.  The
> BBN crew finally sorted out the details and wrote a delightful titled "It's
> Amazing That it Works at all."
>
> On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
> >
> > > The TAC was an extension of the IMP.  The original IMP was built on
> > > the
> > > Honeywell 516 (and later 316) platform, which was a 16 bit twos
> > > complement
> > > computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> > > the
> > > fact that the arithmetic was signed.
> >
> > I honestly cannot remember what the TAC was!!   Was that the TIP?
> >  Regardless,
> > yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
> > of page
> > address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
> >
> > Things got more complicated with the 316 -- it supported 32K words.  What
> > we
> > did for the TIP [and maybe the TAC, whatever that was] was to keep the
> IMP
> > *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
> > self-contained "host". There was some [small!] hack to fake interrupts
> and
> > input/output to this host but to the IMP it thought it was just another
> > NCP
> > connected host.  It'd set up a host output buffer and instead of doing a
> > hardware
> > "send" it'd pass control to the upper 16K.  Similarly [at least for the
> > TIP], when it
> > got something in from a terminal it'd copy it into a host-input buffer
> and
> > then
> > issue an "interrupt" down to the IMP.   Worked quite well.
> >
> >   /Bernie\
> >             Bernie Cosell
> >        bernie at fantasyfarm.com
> > -- Too many people; too few sheep --
> >
> >
> >
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From bob.hinden at gmail.com  Tue Mar 10 11:38:35 2020
From: bob.hinden at gmail.com (Bob Hinden)
Date: Tue, 10 Mar 2020 11:38:35 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
Message-ID: <023FF66E-5E9B-46C8-87FB-4E7B27A7D6C1@gmail.com>

H Steve,

> On Mar 10, 2020, at 11:03 AM, Steve Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Argh.  I echoed Leo's use of "TAC."  I read it as referring to the TIP.  If
> I recall correctly, the "TAC" was an access control method on the TIPs.
> "TIP Access Control" I think.

The Terminal Access Controller (TAC) was a TIP like machine that ran TCP/IP instead of NCP.   I think it was done for the DDN, but my memory on that part is hazy.

Bob



> 
> Steve
> 
> 
> On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
>> 
>>> The TAC was an extension of the IMP.  The original IMP was built on
>>> the
>>> Honeywell 516 (and later 316) platform, which was a 16 bit twos
>>> complement
>>> computer.  I assume Hinden's reference to 15-bit arithmetic reflected
>>> the
>>> fact that the arithmetic was signed.
>> 
>> I honestly cannot remember what the TAC was!!   Was that the TIP?
>> Regardless,
>> yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
>> of page
>> address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
>> 
>> Things got more complicated with the 316 -- it supported 32K words.  What
>> we
>> did for the TIP [and maybe the TAC, whatever that was] was to keep the IMP
>> *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
>> self-contained "host". There was some [small!] hack to fake interrupts and
>> input/output to this host but to the IMP it thought it was just another
>> NCP
>> connected host.  It'd set up a host output buffer and instead of doing a
>> hardware
>> "send" it'd pass control to the upper 16K.  Similarly [at least for the
>> TIP], when it
>> got something in from a terminal it'd copy it into a host-input buffer and
>> then
>> issue an "interrupt" down to the IMP.   Worked quite well.
>> 
>>  /Bernie\
>>            Bernie Cosell
>>       bernie at fantasyfarm.com
>> -- Too many people; too few sheep --
>> 
>> 
>> 
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20200310/4e7bfd17/attachment.asc>

From bob.hinden at gmail.com  Tue Mar 10 11:42:26 2020
From: bob.hinden at gmail.com (Bob Hinden)
Date: Tue, 10 Mar 2020 11:42:26 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
Message-ID: <5F963110-8941-4607-B7C5-6874999261A5@gmail.com>

Leo,

> On Mar 10, 2020, at 10:19 AM, Leo Vegoda <leo at vegoda.org> wrote:
> 
> On Tue, Mar 10, 2020 at 9:02 AM Bob Hinden via Internet-history
> <internet-history at elists.isoc.org> wrote:
> 
> [...]
> 
>> I later did a TCP implementation for the TAC in H-316 assembly language.
>> Was lots of fun doing 32-bit segment calculations on a machine with 15-bit arithmetic.
> 
> Do you know why the designers of the TAC chose 15-bit arithmetic for it?

No idea, it was the same architecture used for the IMPs, I am sure someone here knows why that machine was picked for the IMP.

Bob

> 
> Thanks,
> 
> Leo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20200310/bf39d7e6/attachment.asc>

From steve at shinkuro.com  Tue Mar 10 11:46:17 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 14:46:17 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <023FF66E-5E9B-46C8-87FB-4E7B27A7D6C1@gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <023FF66E-5E9B-46C8-87FB-4E7B27A7D6C1@gmail.com>
Message-ID: <CABf5zvLQBXNwqJgxfyQcWODquAjM2Jy+rgAfbAjw3rxzCDFZPw@mail.gmail.com>

Ah.  And other memories are slowly coming back.  In 1981 I joined The
Aerospace Corporation to establish a computer science research lab.  There
was an IMP at the Air Force operation across the street, and I arranged to
get our lab attached to it.  When it came time to register our host name, I
used "Aerospace" as the long name but I was challenged to find a good short
name.  The official name of the corporation was "The Aerospace Corporation"
and it was not uncommon to see "TAC" used internally.  But that would have
caused massive confusion.

What actually happened was even more interested.  I decided to register
just the letter A.  It took Carnegie-Mellon University off the net.  They
had several hosts, CMU-A, CMU-B, etc, and the were using single letters
internally as abbreviations.  Their A machine was the gateway to the
Arpanet.  In short order, single letter host names were prohibited from the
host table.

Steve


On Tue, Mar 10, 2020 at 2:38 PM Bob Hinden <bob.hinden at gmail.com> wrote:

> H Steve,
>
> > On Mar 10, 2020, at 11:03 AM, Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Argh.  I echoed Leo's use of "TAC."  I read it as referring to the TIP.
> If
> > I recall correctly, the "TAC" was an access control method on the TIPs.
> > "TIP Access Control" I think.
>
> The Terminal Access Controller (TAC) was a TIP like machine that ran
> TCP/IP instead of NCP.   I think it was done for the DDN, but my memory on
> that part is hazy.
>
> Bob
>
>
>
> >
> > Steve
> >
> >
> > On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
> >>
> >>> The TAC was an extension of the IMP.  The original IMP was built on
> >>> the
> >>> Honeywell 516 (and later 316) platform, which was a 16 bit twos
> >>> complement
> >>> computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> >>> the
> >>> fact that the arithmetic was signed.
> >>
> >> I honestly cannot remember what the TAC was!!   Was that the TIP?
> >> Regardless,
> >> yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
> >> of page
> >> address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
> >>
> >> Things got more complicated with the 316 -- it supported 32K words.
> What
> >> we
> >> did for the TIP [and maybe the TAC, whatever that was] was to keep the
> IMP
> >> *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
> >> self-contained "host". There was some [small!] hack to fake interrupts
> and
> >> input/output to this host but to the IMP it thought it was just another
> >> NCP
> >> connected host.  It'd set up a host output buffer and instead of doing a
> >> hardware
> >> "send" it'd pass control to the upper 16K.  Similarly [at least for the
> >> TIP], when it
> >> got something in from a terminal it'd copy it into a host-input buffer
> and
> >> then
> >> issue an "interrupt" down to the IMP.   Worked quite well.
> >>
> >>  /Bernie\
> >>            Bernie Cosell
> >>       bernie at fantasyfarm.com
> >> -- Too many people; too few sheep --
> >>
> >>
> >>
> >>
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
>


From steve at shinkuro.com  Tue Mar 10 11:48:23 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Tue, 10 Mar 2020 14:48:23 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <5F963110-8941-4607-B7C5-6874999261A5@gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <5F963110-8941-4607-B7C5-6874999261A5@gmail.com>
Message-ID: <CABf5zvL5zgPT-hPkGgoKqBHek8c6N5tR4sUvVsUXZBJDvLf9mQ@mail.gmail.com>

There's actually quite a bit of documentation on why the Honeywell 516 was
chosen for the IMP.  The short version is the interrupt structure and
ability to add I/O devices.  Proximity of the Honeywell operation to BBN in
Cambridge also played a role.

Steve


On Tue, Mar 10, 2020 at 2:42 PM Bob Hinden via Internet-history <
internet-history at elists.isoc.org> wrote:

> Leo,
>
> > On Mar 10, 2020, at 10:19 AM, Leo Vegoda <leo at vegoda.org> wrote:
> >
> > On Tue, Mar 10, 2020 at 9:02 AM Bob Hinden via Internet-history
> > <internet-history at elists.isoc.org> wrote:
> >
> > [...]
> >
> >> I later did a TCP implementation for the TAC in H-316 assembly language.
> >> Was lots of fun doing 32-bit segment calculations on a machine with
> 15-bit arithmetic.
> >
> > Do you know why the designers of the TAC chose 15-bit arithmetic for it?
>
> No idea, it was the same architecture used for the IMPs, I am sure someone
> here knows why that machine was picked for the IMP.
>
> Bob
>
> >
> > Thanks,
> >
> > Leo
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From bernie at fantasyfarm.com  Tue Mar 10 11:53:56 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 10 Mar 2020 14:53:56 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
Message-ID: <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>

On March 10, 2020 14:20:23 Leo Vegoda <leo at vegoda.org> wrote:

> On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
> <internet-history at elists.isoc.org> wrote:
>>
>> To create the TIP, a second bank of memory was added to the 316 and some
>> interrupts and modes were added to enable switching back and forth between
>> banks.  It was a bit of a kludge with some unexpected interactions.  The
>> BBN crew finally sorted out the details and wrote a delightful titled "It's
>> Amazing That it Works at all."
>
> Am I right in inferring that the key driver behind the design decision
> was cost rather than elegance?

no.  cost wasn't the issue.  in fact elegance was.  I did the design
and most of the code for the tip and the issue was making it
" clean".    the imp was a pretty complicated program {I had
a hand in that, too} and was, at best, squeezed into its 16k.
there really wasn't room in the lower bank for the tip and
it's device buffers, etc.  I thought about how to implement
and it became clear to me that writing a "terminal handling
IMP" was madness.  the underlying IMP code still had to do
everything an imp has to do {routing, forwarding, etc} and
the problem of managing, debugging and updating this 'hybrid"
in parallel, but forked apart from, the main IMP code seemed
like a nightmare.

instead, I cooked up a "virtual host" mechanism and aside
from that mechanism,  the TIP code and its underlying IMP
code were quite insulated from one another.  Imo {ymmv :)}
that split worked out to be pretty elegant and effective.
{as steve hinted} it was a little tricky to get working, but
after that  it was quite solid. the imp was maintained by the
imp guys pretty much independent of the TIP software and
the TIP development/debugging could {and didi} proceed
independently of the IMP software.

/bernie\

                     Bernie Cosell
           bernie at fantasyfarm. com
? Too many people,  too few sheep ?


From dave.walden.family at gmail.com  Tue Mar 10 14:59:05 2020
From: dave.walden.family at gmail.com (dave walden)
Date: Tue, 10 Mar 2020 14:59:05 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <5F963110-8941-4607-B7C5-6874999261A5@gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <35DF5526-0C09-492E-A870-49F6FEDBA6EA@gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <5F963110-8941-4607-B7C5-6874999261A5@gmail.com>
Message-ID: <2d714419-d2d3-02d1-40d7-7469ba65c923@gmail.com>

The 516/316 was a typical minicomputer circa 1968.? Alex McKenzie 
shortly before had evaluated some minicomputers for another possible 
project.? For choosing a minicomputer for the IMP, that prior evaluation 
was reviewed, and the 516/316 was suitable for our IMP design in terms 
of speed and memory size.? It was convenient that the DDP division of 
Honeywell was close to BBN.? I don't remember if there being a hardened 
516 version matter a lot, but Frank Heart was very happy to be able to 
use the 516s for the first few IMPs.? What we told ARPA about the 516 
choice is on appendix pages D-1 to D-3 at 
https://walden-family.com/bbn/arpanet-prop-ocr.pdf as well as at other 
places in the proposal, e.g., the timing calculations.

On 3/10/2020 11:42 AM, Bob Hinden via Internet-history wrote:
> I am sure someone here knows why that machine was picked for the IMP.


From lars at nocrew.org  Tue Mar 10 12:02:42 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 10 Mar 2020 19:02:42 +0000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <7w7dzsidu5.fsf@junk.nocrew.org> (Lars Brinkhoff via
 Internet-history's message of "Tue, 10 Mar 2020 12:39:14 +0000")
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
 <7w7dzsidu5.fsf@junk.nocrew.org>
Message-ID: <7wblp4ghil.fsf@junk.nocrew.org>

> Ken Harrenstien also added TCP/IP to the ITS operating system in late
> 1982.  The implemenation language was PDP-10 MIDAS assembler.

Which was also used for NCP.  A twist on that story is that Bob Bressler
first wrote an NCP for ITS together with Bob Metcalfe for the Dynamic
Modeling PDP-6.  However, rather than accepting that code into ITS the
AI lab people rewrote it more to their liking.  So in a sense that was a
second NCP for ITS.


From geoff at iconia.com  Tue Mar 10 12:12:04 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 09:12:04 -1000
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
Message-ID: <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>

for some reason when the C/70's came along, TIP's were renamed to TAC's
(Terminal Access Controllers) or some such... BUT, the Access control (i.e.
login to use/make a connection) of it was known as TACACS (Access Control
System).... and it might have come about via a conversation/discussion
yours truly had with Col. Dave Russell of DARPA:

we were in North Carolina heading/driving to the Fort Bragg ARMY base there
to do a Packet Radio Net demo... as we drove along yours truly brought up
the issue of the lack of security on the TIP's-- i.e. that anyone (i.e.
"randoms") could call up and then connect to any host without having to
"login" to do so.

Col. Russell kinda pushed back saying that without userid on a host there
was nothing you could do -- and therefore would eventually "go away".

yours truly countered this allowed for "crackers" to spend their time
trying to break into systems... which yours truly constantly witnessed on
our systems at SRI was it was common for people to use easily guessable
passwords such as their initials (or even summarily detailed in RFC602
<https://tools.ietf.org/html/rfc602> by Bob Metcalfe of PARC-MAXC "*The
Stockings Were Hung by the Chimney with Care"
<https://tools.ietf.org/html/rfc602> *when a cracker guessed their SYSTEM's
password which was their host name spelled backwards).

so to abate this, a "dead bolt" on the front door of the ARPANET (i.e. the
TIPs) was needed to this vehicle of easy/free remote access "penetration"
attemptages.

there may have been others in other quarters "preaching" the same issues...
but Col. Russell then agreed and sometime later, there was TACACS.

let's not forget that at this time many (most?) of the APRANET systems had
guest accounts on them... user GUEST, password ARPA... and they were
"advertised" via the NIC at SRI-ARC (host 2) where after connecting to the
TIP, you did a @l (for link... the original TIP command to connect to a
host... later also @o (for open) and once getting the SRI-ARC Tenex exec
prompt just typed in NIC and you were then automatically logged in (w/o a
pw) as NICGUEST into an NLS (Doug Engelbart's system) special program that
allowed you to electronically browse the ARPANET Resource Handbook on line
that contained all the Good Stuff about each ARPANET host system.

let's also not forget that the MIT ITS (Incompatible Timesharing System)
hosts MIT-AI, MIT-ML and MIT-DM did not have passwords (let alone any type
of "security" at all, as it's "command" interface was DDT... perhaps it's
where the term Security By/Through Obscurity came about?) and given this
lack of passwords, it was a favorite hangout for "randoms" (along with
SU-AI with its NET,GUE login) that dialed into the NO access controlled
TIP's -- like yours truly did via the AMES-TIP after meeting a summer hire
at Tymshare who wrote its phone # and a few TIP commands on the back of an
envelope in the early 70's... :D

geoff

On Tue, Mar 10, 2020 at 8:03 AM Steve Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> Argh.  I echoed Leo's use of "TAC."  I read it as referring to the TIP.  If
> I recall correctly, the "TAC" was an access control method on the TIPs.
> "TIP Access Control" I think.
>
> Steve
>
>
> On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
> >
> > > The TAC was an extension of the IMP.  The original IMP was built on
> > > the
> > > Honeywell 516 (and later 316) platform, which was a 16 bit twos
> > > complement
> > > computer.  I assume Hinden's reference to 15-bit arithmetic reflected
> > > the
> > > fact that the arithmetic was signed.
> >
> > I honestly cannot remember what the TAC was!!   Was that the TIP?
> >  Regardless,
> > yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
> > of page
> > address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
> >
> > Things got more complicated with the 316 -- it supported 32K words.  What
> > we
> > did for the TIP [and maybe the TAC, whatever that was] was to keep the
> IMP
> > *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
> > self-contained "host". There was some [small!] hack to fake interrupts
> and
> > input/output to this host but to the IMP it thought it was just another
> > NCP
> > connected host.  It'd set up a host output buffer and instead of doing a
> > hardware
> > "send" it'd pass control to the upper 16K.  Similarly [at least for the
> > TIP], when it
> > got something in from a terminal it'd copy it into a host-input buffer
> and
> > then
> > issue an "interrupt" down to the IMP.   Worked quite well.
> >
> >   /Bernie\
> >             Bernie Cosell
> >        bernie at fantasyfarm.com
> > -- Too many people; too few sheep --
> >
> >
> >
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From bernie at fantasyfarm.com  Tue Mar 10 12:16:08 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Tue, 10 Mar 2020 15:16:08 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
Message-ID: <170c5e02cc0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>

On March 10, 2020 14:20:23 Leo Vegoda <leo at vegoda.org> wrote:

> On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
> <internet-history at elists.isoc.org> wrote:
>>
>> To create the TIP, a second bank of memory was added to the 316 and some
>> interrupts and modes were added to enable switching back and forth between
>> banks.  It was a bit of a kludge with some unexpected interactions.  The
>> BBN crew finally sorted out the details and wrote a delightful titled "It's
>> Amazing That it Works at all."
>
> Am I right in inferring that the key driver behind the design decision
> was cost rather than elegance?

i think i misunderstood you... let me clarify..

when the 316 came out and it could hold 32k, the only plan that I knew of 
was to use the 32k 316 for the TIP.  I don't know if the
approach of just using a *second* 16k 316 for a fully
independent, standalone TIP was considered.  seems kinda brute force to me. 
 perhaps Dave remembers how the decision of
making a 32k combined imp/tip versus making the TIP an independent 
standalone host was made. I was just stuck
with the job of figuring out how to make it work.  :)


/b\

                     Bernie Cosell
           bernie at fantasyfarm. com
? Too many people,  too few sheep ?


From b_a_denny at yahoo.com  Tue Mar 10 12:23:08 2020
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Tue, 10 Mar 2020 19:23:08 +0000 (UTC)
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
Message-ID: <1803214590.7384037.1583868188460@mail.yahoo.com>

 I don't think anyone has mentioned Charlie Lynn yet.? My memory might be faulty but I think he was working on TCP in the early 80s, perhaps even earlier. I don't know if he was bug fixing someone else's implementation but I am pretty sure he reported on TCP during our BBN packet radio status meetings.? Charlie worked on many Internet projects but unfortunately died fairly young.? Perhaps Jil Westcott can verify or fill in here since she was managing the packet radio project at BBN at this time.?
barbara?

    On Tuesday, March 10, 2020, 05:31:54 AM PDT, Nelson H. F. Beebe via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 Vint Cerf asks about early implementation languages for TCP/IP.

I searched our remaining archives of what in the 1980s and 1990s was
science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
running TOPS-20, and found TCP/IP network code written in PDP-10
assembly languages with these names:

??? tcpbbn.mac? tcpcrc.mac? tcpjfn.mac? tcptcp.mac

The files in that directory carry time stamps from 1984.10.25 to
1985.09.11.

The tcpbbn.mac file has this comment:

??? ;COPYRIGHT? (C)? DIGITAL? EQUIPMENT? CORPORATION? 1976, 1985.

??? This module implements the BBN TCP JSYS interface.
??? This? code? was originally developed at Bolt Beranek and Newman (BBN)
??? under contract to? the? Defense? Advanced? Research? Projects? Agency
??? (DARPA).

The JSYS instruction is the PDP-10 system call.

I also found a memo, design.mem, with the header

??? ??? ? Black Arts
??? ??? ? ? ? of
??? Transmission Control Protocol
??? ? ? Inter Network Protocol
??? ??? Implementation
??? ??? ? ? in the
??? ? ? VAX / VMS Environment

??? ??? ? July 1982

??? ??? Stan C. Smith
??? ? ? ? Tektronix, Inc.
??? Computer Resource Dept 50-454
??? ??? P.O. box 500
??? ? Beaverton, Oregon? 97077

that describes the VAX/VMS TCP/IP code written in Bliss, a systems
programming language that was developed at CMU for DEC, and used by a
few sites with DEC development contracts.? Otherwise, it was a
licensed software product that was too expensive for us to have on our
PDP-10, PDP-11, and VAX systems.

Instead, we wrote such code in assembly language, and later, in Pascal
(TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
written by Kok Chen at Stanford and significantly extended for systems
programming work by Ken Harrenstien at SRI International), and PCL
(Programmable Command Language, a DEC compiler available only on
TOPS-20). Once C became available on the PDP-10 and VAX, it was
clearly the language of choice for software tools, and assembly code
was a dead end with the growth in minicomputer and microprocessor
architectures.

For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
structured Fortran developed at JPL in Pasadena, and machine
translated to standard Fortran 66 and 77), with only low-level
primitives for character and bit processing, and system calls, written
in assembly code.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe? ? ? ? ? ? ? ? ? ? Tel: +1 801 581 5254? ? ? ? ? ? ? ? ? -
- University of Utah? ? ? ? ? ? ? ? ? ? FAX: +1 801 581 4148? ? ? ? ? ? ? ? ? -
- Department of Mathematics, 110 LCB? ? Internet e-mail: beebe at math.utah.edu? -
- 155 S 1400 E RM 233? ? ? ? ? ? ? ? ? ? ? beebe at acm.org? beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA? ? URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From geoff at iconia.com  Tue Mar 10 12:33:43 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 09:33:43 -1000
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <1803214590.7384037.1583868188460@mail.yahoo.com>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
 <1803214590.7384037.1583868188460@mail.yahoo.com>
Message-ID: <CAEf-zri9g63sQb8E95jkR0+PPKRGgnuDa0exwpNcuXcpKxydmQ@mail.gmail.com>

let's also not forget the late MAP, i.e. Mike Padlipsky
<https://en.wikipedia.org/wiki/Michael_A._Padlipsky>, EXCERPT:

... *Internetworking*

Full participation in Arpanet technical discussions required current
programming assignments on Arpanet. Mike summarized his own internetworking
experience as follows: [4]
<https://en.wikipedia.org/wiki/Michael_A._Padlipsky#cite_note-4>

Therefore, to combat that sort of brain surgery by transmission mechanics,
I feel I should present my credentials. ... So, aside from having coined
the term "Old Network Boy" ? and being one ? and indeed probably being the
only person in the world who knew, worked with, and was even on friendly
terms with Vint Cerf <https://en.wikipedia.org/wiki/Vint_Cerf>, Jon Postel
<https://en.wikipedia.org/wiki/Jon_Postel>, and Dave Clark
<https://en.wikipedia.org/wiki/David_D._Clark> before they got their
respective doctorates, I was an active participant in the design of the
ARPANET "Old" and "New" Telnet <https://en.wikipedia.org/wiki/Telnet>
protocols,
the File Transfer Protocol
<https://en.wikipedia.org/wiki/File_Transfer_Protocol>, and the first
Graphics Protocol; I was the originator and a principal designer of
"neted," a common editor command for the ARPANET; and I was the originator
and a principal designer of the first Host-Front-End Protocol, not only for
the ARPANET. I also implemented "Old" Telnet for Multics, did the
integration and checkout of NCP and Telnet on 645 Multics ? setting the
one-month record for Development Machine Time in the process ? and later
served as the Multics Network Technical Liaison and Network and Graphics
Group Leader, supervising the attachment of 6180 Multics to the ARPANET in
the process. In recent years, I've tried to help the Government get some of
its money's worth from contractors on any number of networks too depressing
to mention both for the ?????* [Name withheld to avoid the necessity of
Corporate Review][5]
<https://en.wikipedia.org/wiki/Michael_A._Padlipsky#cite_note-5> Corporation,
which now [Ed. 1983] employs me, and for the DoD's Protocol Standards
Technical Panel.[6]
<https://en.wikipedia.org/wiki/Michael_A._Padlipsky#cite_note-6>

While a member of the NWG, Mike wrote 20 RFCs...


On Tue, Mar 10, 2020 at 9:24 AM Barbara Denny via Internet-history <
internet-history at elists.isoc.org> wrote:

>  I don't think anyone has mentioned Charlie Lynn yet.  My memory might be
> faulty but I think he was working on TCP in the early 80s, perhaps even
> earlier. I don't know if he was bug fixing someone else's implementation
> but I am pretty sure he reported on TCP during our BBN packet radio status
> meetings.  Charlie worked on many Internet projects but unfortunately died
> fairly young.  Perhaps Jil Westcott can verify or fill in here since she
> was managing the packet radio project at BBN at this time.
> barbara
>
>     On Tuesday, March 10, 2020, 05:31:54 AM PDT, Nelson H. F. Beebe via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>  Vint Cerf asks about early implementation languages for TCP/IP.
>
> I searched our remaining archives of what in the 1980s and 1990s was
> science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
> running TOPS-20, and found TCP/IP network code written in PDP-10
> assembly languages with these names:
>
>     tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac
>
> The files in that directory carry time stamps from 1984.10.25 to
> 1985.09.11.
>
> The tcpbbn.mac file has this comment:
>
>     ;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.
>
>     This module implements the BBN TCP JSYS interface.
>     This  code  was originally developed at Bolt Beranek and Newman (BBN)
>     under contract to  the  Defense  Advanced  Research  Projects  Agency
>     (DARPA).
>
> The JSYS instruction is the PDP-10 system call.
>
> I also found a memo, design.mem, with the header
>
>           Black Arts
>               of
>     Transmission Control Protocol
>         Inter Network Protocol
>         Implementation
>             in the
>         VAX / VMS Environment
>
>           July 1982
>
>         Stan C. Smith
>           Tektronix, Inc.
>     Computer Resource Dept 50-454
>         P.O. box 500
>       Beaverton, Oregon  97077
>
> that describes the VAX/VMS TCP/IP code written in Bliss, a systems
> programming language that was developed at CMU for DEC, and used by a
> few sites with DEC development contracts.  Otherwise, it was a
> licensed software product that was too expensive for us to have on our
> PDP-10, PDP-11, and VAX systems.
>
> Instead, we wrote such code in assembly language, and later, in Pascal
> (TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
> compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
> written by Kok Chen at Stanford and significantly extended for systems
> programming work by Ken Harrenstien at SRI International), and PCL
> (Programmable Command Language, a DEC compiler available only on
> TOPS-20). Once C became available on the PDP-10 and VAX, it was
> clearly the language of choice for software tools, and assembly code
> was a dead end with the growth in minicomputer and microprocessor
> architectures.
>
> For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
> structured Fortran developed at JPL in Pasadena, and machine
> translated to standard Fortran 66 and 77), with only low-level
> primitives for character and bit processing, and system calls, written
> in assembly code.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah                    FAX: +1 801 581 4148
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                      beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From amckenzie3 at yahoo.com  Tue Mar 10 12:47:56 2020
From: amckenzie3 at yahoo.com (Alex McKenzie)
Date: Tue, 10 Mar 2020 19:47:56 +0000 (UTC)
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
Message-ID: <770722617.43655.1583869676385@mail.yahoo.com>

 The key driver was that the TIP be managed as part of the network, rather than as part of a user organization.? That meant that BBN followed the same rules for the TIP that they did for the IMP, which included "no rotating storage", which in those days was quite unreliable in a MTBF sense.? And we wanted it to be in the same box as the IMP, sharing a processor, so it had to exist in 16K of 16-bit words.? Other approaches, like ANTS and ELF, ran in separate boxes and were run by user organizations, so more buffers and more code for specialized I/O devices were possible.? ARPA supported, one way or another, all of the TIP, ANTS, and ELF.
Cheers,Alex McKenzie (BBN 1967-96)

    On Tuesday, March 10, 2020, 2:20:35 PM EDT, Leo Vegoda via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
<internet-history at elists.isoc.org> wrote:
>
> To create the TIP, a second bank of memory was added to the 316 and some
> interrupts and modes were added to enable switching back and forth between
> banks.? It was a bit of a kludge with some unexpected interactions.? The
> BBN crew finally sorted out the details and wrote a delightful titled "It's
> Amazing That it Works at all."

Am I right in inferring that the key driver behind the design decision
was cost rather than elegance?

Thanks,

Leo
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From geoff at iconia.com  Tue Mar 10 13:08:17 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Tue, 10 Mar 2020 10:08:17 -1000
Subject: [ih] NCP and TCP implementations
In-Reply-To: <770722617.43655.1583869676385@mail.yahoo.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <770722617.43655.1583869676385@mail.yahoo.com>
Message-ID: <CAEf-zrjxTF=pXYi+avBtBE7go51W+VB9=3wsJZ3YRHJx7ch0-g@mail.gmail.com>

in addition to TIP/TAC, ANTS, and ELF there was also a number of different
implementations of/a TSP: *Terminal Support Processor *such as the one at
Lincoln Labs (LL-TSP) detailed in
https://apps.dtic.mil/dtic/tr/fulltext/u2/726534.pdf

there was also a PDP-11 TSP version -- not related to the LL-TSP version --
(that might have come from ISI?) that yours truly brought up on on the Earl
Craighill and Tom Magill (SRI-NSC11 host) when it was sitting idle (i.e.
not being used for/with the Voice over IP of ARPA's Network Speech
Compression program) which had a single dial-up modem on it and provided
for "alternative access" when all of the direct SRI-AI dial-up lines
scanner PDP-10 Tenex system lines were busy/in use. :D

geoff


On Tue, Mar 10, 2020 at 9:48 AM Alex McKenzie via Internet-history <
internet-history at elists.isoc.org> wrote:

>  The key driver was that the TIP be managed as part of the network, rather
> than as part of a user organization.  That meant that BBN followed the same
> rules for the TIP that they did for the IMP, which included "no rotating
> storage", which in those days was quite unreliable in a MTBF sense.  And we
> wanted it to be in the same box as the IMP, sharing a processor, so it had
> to exist in 16K of 16-bit words.  Other approaches, like ANTS and ELF, ran
> in separate boxes and were run by user organizations, so more buffers and
> more code for specialized I/O devices were possible.  ARPA supported, one
> way or another, all of the TIP, ANTS, and ELF.
> Cheers,Alex McKenzie (BBN 1967-96)
>
>     On Tuesday, March 10, 2020, 2:20:35 PM EDT, Leo Vegoda via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>  On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
> <internet-history at elists.isoc.org> wrote:
> >
> > To create the TIP, a second bank of memory was added to the 316 and some
> > interrupts and modes were added to enable switching back and forth
> between
> > banks.  It was a bit of a kludge with some unexpected interactions.  The
> > BBN crew finally sorted out the details and wrote a delightful titled
> "It's
> > Amazing That it Works at all."
>
> Am I right in inferring that the key driver behind the design decision
> was cost rather than elegance?
>
> Thanks,
>
> Leo
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From dhc at dcrocker.net  Tue Mar 10 13:48:08 2020
From: dhc at dcrocker.net (Dave Crocker)
Date: Tue, 10 Mar 2020 13:48:08 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>
Message-ID: <ba96d6fe-910c-f8b0-f1f2-b904aa8a8109@dcrocker.net>

On 3/10/2020 11:53 AM, Bernie Cosell via Internet-history wrote:
>> Am I right in inferring that the key driver behind the design decision
>> was cost rather than elegance?
>
> no.? cost wasn't the issue.? in fact elegance was. 

My subjective view, at the time, was the the existence of a single 
integrated device for terminal access was extremely helpful in growing 
the user population of the early Arpanet.? Juggling two devices -- IMP 
and a separate host -- for sites needing access but not really having a 
machine or operator cycles to spare, would have been a significant 
barrier to entry.

Small tidbit:

As part of my job doing user support at the UCLA CS site, I got tasked 
with helping Einar Stefferud get started using access.? He didn't access 
through our system but had other arrangements; I just had to help.

One day he calls me up and says that he can't send email.? He was using 
Tenex.? I don't remember whether we were yet into the RD/BananaRD/MSG 
world yet, but in any case, sending was done with Sndmsg.

So I ask him to describe the problem and he says he types the 
destination address and the system responded with "Bad".

I told him he needed to enter at-sign (@) twice.? I felt quite proud of 
realizing the TIP was intercepting the the at-sign.? As I recall, the 
TIP was the only system on the net that gave 'bad' as an error message...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net



From dhc at dcrocker.net  Tue Mar 10 13:52:00 2020
From: dhc at dcrocker.net (Dave Crocker)
Date: Tue, 10 Mar 2020 13:52:00 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <770722617.43655.1583869676385@mail.yahoo.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <770722617.43655.1583869676385@mail.yahoo.com>
Message-ID: <fd2e79fa-3cfa-d4cd-43be-d7bca2b60b31@dcrocker.net>

On 3/10/2020 12:47 PM, Alex McKenzie via Internet-history wrote:
> which included "no rotating storage", which in those days was quite unreliable in a MTBF sense.

Indeed.? I recall ISI making the unusual decision to not use a 
high-speed swapping disk/drum and, instead, to just get a lot more (very 
expensive) main memory and then do the (less frequent) swapping from a 
regular (slower) disk.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net



From craig at tereschau.net  Tue Mar 10 14:02:02 2020
From: craig at tereschau.net (Craig Partridge)
Date: Tue, 10 Mar 2020 15:02:02 -0600
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <1803214590.7384037.1583868188460@mail.yahoo.com>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
 <1803214590.7384037.1583868188460@mail.yahoo.com>
Message-ID: <CAHQj4Cc5skTBwxgaCW-2hhi6HrPhJeAH1AibByTLYvorFVpT+Q@mail.gmail.com>

I got to know Charlie after 1983.  My recollection was that he worked on
TCP implementations in the 1970s.  I cannot remember the platforms.

Craig

On Tue, Mar 10, 2020 at 1:24 PM Barbara Denny via Internet-history <
internet-history at elists.isoc.org> wrote:

>  I don't think anyone has mentioned Charlie Lynn yet.  My memory might be
> faulty but I think he was working on TCP in the early 80s, perhaps even
> earlier. I don't know if he was bug fixing someone else's implementation
> but I am pretty sure he reported on TCP during our BBN packet radio status
> meetings.  Charlie worked on many Internet projects but unfortunately died
> fairly young.  Perhaps Jil Westcott can verify or fill in here since she
> was managing the packet radio project at BBN at this time.
> barbara
>
>     On Tuesday, March 10, 2020, 05:31:54 AM PDT, Nelson H. F. Beebe via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>  Vint Cerf asks about early implementation languages for TCP/IP.
>
> I searched our remaining archives of what in the 1980s and 1990s was
> science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
> running TOPS-20, and found TCP/IP network code written in PDP-10
> assembly languages with these names:
>
>     tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac
>
> The files in that directory carry time stamps from 1984.10.25 to
> 1985.09.11.
>
> The tcpbbn.mac file has this comment:
>
>     ;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.
>
>     This module implements the BBN TCP JSYS interface.
>     This  code  was originally developed at Bolt Beranek and Newman (BBN)
>     under contract to  the  Defense  Advanced  Research  Projects  Agency
>     (DARPA).
>
> The JSYS instruction is the PDP-10 system call.
>
> I also found a memo, design.mem, with the header
>
>           Black Arts
>               of
>     Transmission Control Protocol
>         Inter Network Protocol
>         Implementation
>             in the
>         VAX / VMS Environment
>
>           July 1982
>
>         Stan C. Smith
>           Tektronix, Inc.
>     Computer Resource Dept 50-454
>         P.O. box 500
>       Beaverton, Oregon  97077
>
> that describes the VAX/VMS TCP/IP code written in Bliss, a systems
> programming language that was developed at CMU for DEC, and used by a
> few sites with DEC development contracts.  Otherwise, it was a
> licensed software product that was too expensive for us to have on our
> PDP-10, PDP-11, and VAX systems.
>
> Instead, we wrote such code in assembly language, and later, in Pascal
> (TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
> compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
> written by Kok Chen at Stanford and significantly extended for systems
> programming work by Ken Harrenstien at SRI International), and PCL
> (Programmable Command Language, a DEC compiler available only on
> TOPS-20). Once C became available on the PDP-10 and VAX, it was
> clearly the language of choice for software tools, and assembly code
> was a dead end with the growth in minicomputer and microprocessor
> architectures.
>
> For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
> structured Fortran developed at JPL in Pasadena, and machine
> translated to standard Fortran 66 and 77), with only low-level
> primitives for character and bit processing, and system calls, written
> in assembly code.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah                    FAX: +1 801 581 4148
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                      beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From jeanjour at comcast.net  Tue Mar 10 14:41:01 2020
From: jeanjour at comcast.net (John Day)
Date: Tue, 10 Mar 2020 17:41:01 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <ba96d6fe-910c-f8b0-f1f2-b904aa8a8109@dcrocker.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>
 <ba96d6fe-910c-f8b0-f1f2-b904aa8a8109@dcrocker.net>
Message-ID: <A6E8A2BE-9921-45AD-AFAC-E2B9394C374B@comcast.net>

The only better error message I ever saw was from the TIPSERV. (To provide a bit more of a command line interface, TIPs could be configured to connect directly to TIPSERV on a BBN Tenex, which then provided the command interpreter.)

The only error message it emitted was:

won?t

(not can?t, won?t)  ;-)

> On Mar 10, 2020, at 16:48, Dave Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> On 3/10/2020 11:53 AM, Bernie Cosell via Internet-history wrote:
>>> Am I right in inferring that the key driver behind the design decision
>>> was cost rather than elegance?
>> 
>> no.  cost wasn't the issue.  in fact elegance was. 
> 
> My subjective view, at the time, was the the existence of a single integrated device for terminal access was extremely helpful in growing the user population of the early Arpanet.  Juggling two devices -- IMP and a separate host -- for sites needing access but not really having a machine or operator cycles to spare, would have been a significant barrier to entry.
> 
> Small tidbit:
> 
> As part of my job doing user support at the UCLA CS site, I got tasked with helping Einar Stefferud get started using access.  He didn't access through our system but had other arrangements; I just had to help.
> 
> One day he calls me up and says that he can't send email.  He was using Tenex.  I don't remember whether we were yet into the RD/BananaRD/MSG world yet, but in any case, sending was done with Sndmsg.
> 
> So I ask him to describe the problem and he says he types the destination address and the system responded with "Bad".
> 
> I told him he needed to enter at-sign (@) twice.  I felt quite proud of realizing the TIP was intercepting the the at-sign.  As I recall, the TIP was the only system on the net that gave 'bad' as an error message...
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From vint at google.com  Tue Mar 10 14:57:05 2020
From: vint at google.com (Vint Cerf)
Date: Tue, 10 Mar 2020 17:57:05 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <CAHQj4Cc5skTBwxgaCW-2hhi6HrPhJeAH1AibByTLYvorFVpT+Q@mail.gmail.com>
References: <CMM.0.95.0.1583843493.beebe@gamma.math.utah.edu>
 <1803214590.7384037.1583868188460@mail.yahoo.com>
 <CAHQj4Cc5skTBwxgaCW-2hhi6HrPhJeAH1AibByTLYvorFVpT+Q@mail.gmail.com>
Message-ID: <CAHxHggcbK5t2JggED3DJR+iZ1+1F11cdXiN-PXGyemX3_jrjMQ@mail.gmail.com>

tenex work at bbn was done by bill plummer and ray tomlinson.

dunno what charlie worked on

v


On Tue, Mar 10, 2020 at 5:02 PM Craig Partridge via Internet-history <
internet-history at elists.isoc.org> wrote:

> I got to know Charlie after 1983.  My recollection was that he worked on
> TCP implementations in the 1970s.  I cannot remember the platforms.
>
> Craig
>
> On Tue, Mar 10, 2020 at 1:24 PM Barbara Denny via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> >  I don't think anyone has mentioned Charlie Lynn yet.  My memory might be
> > faulty but I think he was working on TCP in the early 80s, perhaps even
> > earlier. I don't know if he was bug fixing someone else's implementation
> > but I am pretty sure he reported on TCP during our BBN packet radio
> status
> > meetings.  Charlie worked on many Internet projects but unfortunately
> died
> > fairly young.  Perhaps Jil Westcott can verify or fill in here since she
> > was managing the packet radio project at BBN at this time.
> > barbara
> >
> >     On Tuesday, March 10, 2020, 05:31:54 AM PDT, Nelson H. F. Beebe via
> > Internet-history <internet-history at elists.isoc.org> wrote:
> >
> >  Vint Cerf asks about early implementation languages for TCP/IP.
> >
> > I searched our remaining archives of what in the 1980s and 1990s was
> > science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
> > running TOPS-20, and found TCP/IP network code written in PDP-10
> > assembly languages with these names:
> >
> >     tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac
> >
> > The files in that directory carry time stamps from 1984.10.25 to
> > 1985.09.11.
> >
> > The tcpbbn.mac file has this comment:
> >
> >     ;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.
> >
> >     This module implements the BBN TCP JSYS interface.
> >     This  code  was originally developed at Bolt Beranek and Newman (BBN)
> >     under contract to  the  Defense  Advanced  Research  Projects  Agency
> >     (DARPA).
> >
> > The JSYS instruction is the PDP-10 system call.
> >
> > I also found a memo, design.mem, with the header
> >
> >           Black Arts
> >               of
> >     Transmission Control Protocol
> >         Inter Network Protocol
> >         Implementation
> >             in the
> >         VAX / VMS Environment
> >
> >           July 1982
> >
> >         Stan C. Smith
> >           Tektronix, Inc.
> >     Computer Resource Dept 50-454
> >         P.O. box 500
> >       Beaverton, Oregon  97077
> >
> > that describes the VAX/VMS TCP/IP code written in Bliss, a systems
> > programming language that was developed at CMU for DEC, and used by a
> > few sites with DEC development contracts.  Otherwise, it was a
> > licensed software product that was too expensive for us to have on our
> > PDP-10, PDP-11, and VAX systems.
> >
> > Instead, we wrote such code in assembly language, and later, in Pascal
> > (TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
> > compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
> > written by Kok Chen at Stanford and significantly extended for systems
> > programming work by Ken Harrenstien at SRI International), and PCL
> > (Programmable Command Language, a DEC compiler available only on
> > TOPS-20). Once C became available on the PDP-10 and VAX, it was
> > clearly the language of choice for software tools, and assembly code
> > was a dead end with the growth in minicomputer and microprocessor
> > architectures.
> >
> > For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
> > structured Fortran developed at JPL in Pasadena, and machine
> > translated to standard Fortran 66 and 77), with only low-level
> > primitives for character and bit processing, and system calls, written
> > in assembly code.
> >
> >
> >
> -------------------------------------------------------------------------------
> > - Nelson H. F. Beebe                    Tel: +1 801 581 5254
> <(801)%20581-5254>
> >     -
> > - University of Utah                    FAX: +1 801 581 4148
> <(801)%20581-4148>
> >     -
> > - Department of Mathematics, 110 LCB    Internet e-mail:
> > beebe at math.utah.edu  -
> > - 155 S 1400 E RM 233                      beebe at acm.org
> > beebe at computer.org -
> > - Salt Lake City, UT 84112-0090, USA    URL:
> > http://www.math.utah.edu/~beebe/ -
> >
> >
> -------------------------------------------------------------------------------
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


From dan at lynch.com  Tue Mar 10 15:01:11 2020
From: dan at lynch.com (Dan Lynch)
Date: Tue, 10 Mar 2020 15:01:11 -0700
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <1803214590.7384037.1583868188460@mail.yahoo.com>
References: <1803214590.7384037.1583868188460@mail.yahoo.com>
Message-ID: <6C78355B-0338-43BC-8084-AF8FCCE27635@lynch.com>

It was a slightly confusing time in the early 80s with the DEC machine situation. The virtual machine design was initiated by BBN and their paging box that brought the Tenex operating system into existence in the early 70s. That was on KA machines. Then DEC brought out the KI machine with similar but not identical features in the mid 70s. Then DEC brought out the KL machines In the late 70s. Tenex was ported to those machines by non DEC people.  Somewhere DEC got wise and bought the rights to something and came out with Tops20, a very decent clone of Tenex with a superior file system. Meanwhile TCP/IP was floating about and needing to be ported to all those systems so those of us who had responsibilities to DARPA had to keep source licenses to Tops20 so we could keep developing TCP/IP because it was inside the OS. Everyone played nice. Charlie Lynn was the BBN guy who had inherited it on their side. He was young and bright. I was in charge of the machines at ISI in Marina del Rey, then the largest node on the Arpanet. I had a collection of 6  DEC machines of various vintages and a team of systems programmers to keep the humming and changing almost every day in the final months before Flag Day of New Year?s Day, 1983. Plus we were feeding all the fixes to DEC to help them keep their commercial products up to date. All the while delivering services to 3,000 online customers around the world and a hundred researchers in the building including Jon Postel, Danny Cohen and Paul Mockapetris who were my go to brain trust on a daily basis. It was an exciting time. 

Dan

Cell 650-776-7313

> On Mar 10, 2020, at 12:24 PM, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> ? I don't think anyone has mentioned Charlie Lynn yet.  My memory might be faulty but I think he was working on TCP in the early 80s, perhaps even earlier. I don't know if he was bug fixing someone else's implementation but I am pretty sure he reported on TCP during our BBN packet radio status meetings.  Charlie worked on many Internet projects but unfortunately died fairly young.  Perhaps Jil Westcott can verify or fill in here since she was managing the packet radio project at BBN at this time. 
> barbara 
> 
>    On Tuesday, March 10, 2020, 05:31:54 AM PDT, Nelson H. F. Beebe via Internet-history <internet-history at elists.isoc.org> wrote:  
> 
> Vint Cerf asks about early implementation languages for TCP/IP.
> 
> I searched our remaining archives of what in the 1980s and 1990s was
> science.utah.edu, a DECsystem 20/40 (later upgraded to a 20/60)
> running TOPS-20, and found TCP/IP network code written in PDP-10
> assembly languages with these names:
> 
>     tcpbbn.mac  tcpcrc.mac  tcpjfn.mac  tcptcp.mac
> 
> The files in that directory carry time stamps from 1984.10.25 to
> 1985.09.11.
> 
> The tcpbbn.mac file has this comment:
> 
>     ;COPYRIGHT  (C)  DIGITAL  EQUIPMENT  CORPORATION  1976, 1985.
> 
>     This module implements the BBN TCP JSYS interface.
>     This  code  was originally developed at Bolt Beranek and Newman (BBN)
>     under contract to  the  Defense  Advanced  Research  Projects  Agency
>     (DARPA).
> 
> The JSYS instruction is the PDP-10 system call.
> 
> I also found a memo, design.mem, with the header
> 
>           Black Arts
>               of
>     Transmission Control Protocol
>         Inter Network Protocol
>         Implementation
>             in the
>         VAX / VMS Environment
> 
>           July 1982
> 
>         Stan C. Smith
>           Tektronix, Inc.
>     Computer Resource Dept 50-454
>         P.O. box 500
>       Beaverton, Oregon  97077
> 
> that describes the VAX/VMS TCP/IP code written in Bliss, a systems
> programming language that was developed at CMU for DEC, and used by a
> few sites with DEC development contracts.  Otherwise, it was a
> licensed software product that was too expensive for us to have on our
> PDP-10, PDP-11, and VAX systems.
> 
> Instead, we wrote such code in assembly language, and later, in Pascal
> (TOPS-20 compiler from Chuck Hedrick's team at Rutgers), C (PCC
> compiler ported to TOPS-20 by the late Jay Lepreau, and later KCC,
> written by Kok Chen at Stanford and significantly extended for systems
> programming work by Ken Harrenstien at SRI International), and PCL
> (Programmable Command Language, a DEC compiler available only on
> TOPS-20). Once C became available on the PDP-10 and VAX, it was
> clearly the language of choice for software tools, and assembly code
> was a dead end with the growth in minicomputer and microprocessor
> architectures.
> 
> For scientific work, all of our coding was in Fortran, and SFTRAN3 (a
> structured Fortran developed at JPL in Pasadena, and machine
> translated to standard Fortran 66 and 77), with only low-level
> primitives for character and bit processing, and system calls, written
> in assembly code.
> 
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                      beebe at acm.org  beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From dugo at xs4all.nl  Tue Mar 10 15:04:48 2020
From: dugo at xs4all.nl (Jacob Goense)
Date: Tue, 10 Mar 2020 23:04:48 +0100
Subject: [ih] NCP and TCP implementations
In-Reply-To: <20200310124219.B284718C0C5@mercury.lcs.mit.edu>
References: <20200310124219.B284718C0C5@mercury.lcs.mit.edu>
Message-ID: <52c33fdd6ee32432db2cc654677e57fa@xs4all.nl>

On 2020-03-10 13:42, Noel Chiappa via Internet-history wrote:
>> From: vinton cerf
> 
>     > Steve Kirsch asks in what languages NCP and TCP were written.
> 
>     > Another version was written for PDP-11/23 by Jim Mathis but not 
> clear in
>     > what language.
> 
> That TCP was in Macro-11; the source for that one still exists in
> machine-readable form, but is not yet openly available online. Oh, and 
> it
> would run on any -11, not just the /23.
> 
>     > Tenex was probably done in C at BBN.
> 
> BBN did two different PDP-11 TCPs for Unix (early on; later they did 
> one for
> VAX Unix); one was in Macro-11, and is not available (but Jack Haverty 
> might
> have it in hard-copy); one was in C, and is available here:

David L. Mills did what became the Fuzzball on the LSI-11. In its final 
form,
at the time of the first NSFNET backbone, it was written in MACRO-11 
with RT-11
as development environment and bootstrap.

A nice language detail to mention from a Q1 1980 COMSAT Quarterly Report 
on
SATNET participation.

     The DCN supports user processes which can run the RT-11
     system and user programs. Insofar as practical, the internet
     interfaces to these processes have been cast in a manner com-
     patible with the RT-I1 programming conventions, so that appli-
     cation programs can be constructed in high-level languages such
     as FORTRAN.


From mbgreen at seas.upenn.edu  Tue Mar 10 15:30:06 2020
From: mbgreen at seas.upenn.edu (Michael Greenwald)
Date: Tue, 10 Mar 2020 15:30:06 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <A6E8A2BE-9921-45AD-AFAC-E2B9394C374B@comcast.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>
 <ba96d6fe-910c-f8b0-f1f2-b904aa8a8109@dcrocker.net>
 <A6E8A2BE-9921-45AD-AFAC-E2B9394C374B@comcast.net>
Message-ID: <82ae19c08369c228ac02fb6eac291eef@seas.upenn.edu>

On 2020-03-10 14:41, John Day via Internet-history wrote:
> The only better error message I ever saw was from the TIPSERV. (To
> provide a bit more of a command line interface, TIPs could be
> configured to connect directly to TIPSERV on a BBN Tenex, which then
> provided the command interpreter.)
> 
> The only error message it emitted was:
> 
> won?t
> 
> (not can?t, won?t)  ;-)

Not so surprising given Telnet WILL/WONT DO/DONT

> 
>> On Mar 10, 2020, at 16:48, Dave Crocker via Internet-history 
>> <internet-history at elists.isoc.org> wrote:
>> 
>> On 3/10/2020 11:53 AM, Bernie Cosell via Internet-history wrote:
>>>> Am I right in inferring that the key driver behind the design 
>>>> decision
>>>> was cost rather than elegance?
>>> 
>>> no.  cost wasn't the issue.  in fact elegance was.
>> 
>> My subjective view, at the time, was the the existence of a single 
>> integrated device for terminal access was extremely helpful in growing 
>> the user population of the early Arpanet.  Juggling two devices -- IMP 
>> and a separate host -- for sites needing access but not really having 
>> a machine or operator cycles to spare, would have been a significant 
>> barrier to entry.
>> 
>> Small tidbit:
>> 
>> As part of my job doing user support at the UCLA CS site, I got tasked 
>> with helping Einar Stefferud get started using access.  He didn't 
>> access through our system but had other arrangements; I just had to 
>> help.
>> 
>> One day he calls me up and says that he can't send email.  He was 
>> using Tenex.  I don't remember whether we were yet into the 
>> RD/BananaRD/MSG world yet, but in any case, sending was done with 
>> Sndmsg.
>> 
>> So I ask him to describe the problem and he says he types the 
>> destination address and the system responded with "Bad".
>> 
>> I told him he needed to enter at-sign (@) twice.  I felt quite proud 
>> of realizing the TIP was intercepting the the at-sign.  As I recall, 
>> the TIP was the only system on the net that gave 'bad' as an error 
>> message...
>> 
>> d/
>> 
>> --
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history


From jeanjour at comcast.net  Tue Mar 10 17:07:40 2020
From: jeanjour at comcast.net (John Day)
Date: Tue, 10 Mar 2020 20:07:40 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <01282e85-a871-0ad7-e77a-e2f06c8c1c25@bbiw.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvL4guHdJ9fxQXzGXw-3vRDpFzKem+z6D-15Dbzz7rZOgg@mail.gmail.com>
 <CAPfiqjYhVJ0=vfoOGZW1TWFG3Ox-TU-kh9DCz76TAL6idr0wSw@mail.gmail.com>
 <170c5cbd9a0.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>
 <ba96d6fe-910c-f8b0-f1f2-b904aa8a8109@dcrocker.net>
 <A6E8A2BE-9921-45AD-AFAC-E2B9394C374B@comcast.net>
 <01282e85-a871-0ad7-e77a-e2f06c8c1c25@bbiw.net>
Message-ID: <83B4A299-C3ED-4D7D-A834-F375FCCF2BA7@comcast.net>

cmd/response. It was symmetrical. It didn?t matter which came first.

Yea, that is what it was or seemed to be, but as a response to command line, it gave an entirely different impression.  ;-)

I always thought it was inspired humor.

> On Mar 10, 2020, at 17:43, Dave Crocker <dcrocker at bbiw.net> wrote:
> 
> On 3/10/2020 2:41 PM, John Day via Internet-history wrote:
>> (not can?t, won?t);-)
> 
> telnet option response.
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net



From gtaylor at tnetconsulting.net  Tue Mar 10 21:15:19 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 10 Mar 2020 22:15:19 -0600
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
Message-ID: <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>

On 3/10/20 1:12 PM, the keyboard of geoff goodfellow via 
Internet-history wrote:
> TIP's were renamed to TAC's (Terminal Access Controllers) or some 
> such... BUT, the Access control (i.e.  login to use/make a connection) 
> of it was known as TACACS (Access Control System)....

Aside:  Is this related to TACACS+ which is still occasionally used in 
network equipment?  Or is it a name collision?



-- 
Grant. . . .
unix || die


From vgcerf at gmail.com  Wed Mar 11 01:35:15 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Wed, 11 Mar 2020 04:35:15 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
 <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>
Message-ID: <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>

TACACS is indeed still used.

v


On Wed, Mar 11, 2020 at 12:15 AM Grant Taylor via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 3/10/20 1:12 PM, the keyboard of geoff goodfellow via
> Internet-history wrote:
> > TIP's were renamed to TAC's (Terminal Access Controllers) or some
> > such... BUT, the Access control (i.e.  login to use/make a connection)
> > of it was known as TACACS (Access Control System)....
>
> Aside:  Is this related to TACACS+ which is still occasionally used in
> network equipment?  Or is it a name collision?
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From sob at sobco.com  Wed Mar 11 03:37:46 2020
From: sob at sobco.com (Scott O. Bradner)
Date: Wed, 11 Mar 2020 06:37:46 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
 <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>
 <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>
Message-ID: <D900DAA8-53B4-471E-9A5E-0C68AEDE6801@sobco.com>

And the IETF is (finally) about to publish a specification (many years in the making - some people do not 
want a spec for what they see as a competing protocol or a dead protocol (even though it is not dead))

Scott

> On Mar 11, 2020, at 4:35 AM, vinton cerf via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> TACACS is indeed still used.
> 
> v
> 
> 
> On Wed, Mar 11, 2020 at 12:15 AM Grant Taylor via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> On 3/10/20 1:12 PM, the keyboard of geoff goodfellow via
>> Internet-history wrote:
>>> TIP's were renamed to TAC's (Terminal Access Controllers) or some
>>> such... BUT, the Access control (i.e.  login to use/make a connection)
>>> of it was known as TACACS (Access Control System)....
>> 
>> Aside:  Is this related to TACACS+ which is still occasionally used in
>> network equipment?  Or is it a name collision?
>> 
>> 
>> 
>> --
>> Grant. . . .
>> unix || die
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From chet.ramey at case.edu  Wed Mar 11 08:06:23 2020
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 11 Mar 2020 11:06:23 -0400
Subject: [ih] NCP, TCP/IP question
In-Reply-To: <6C78355B-0338-43BC-8084-AF8FCCE27635@lynch.com>
References: <1803214590.7384037.1583868188460@mail.yahoo.com>
 <6C78355B-0338-43BC-8084-AF8FCCE27635@lynch.com>
Message-ID: <866c9f47-1442-4a0e-d9df-d9d102843582@case.edu>

On 3/10/20 6:01 PM, Dan Lynch via Internet-history wrote:
> It was a slightly confusing time in the early 80s with the DEC machine situation. The virtual machine design was initiated by BBN and their paging box that brought the Tenex operating system into existence in the early 70s. That was on KA machines. Then DEC brought out the KI machine with similar but not identical features in the mid 70s. Then DEC brought out the KL machines In the late 70s. Tenex was ported to those machines by non DEC people.  Somewhere DEC got wise and bought the rights to something and came out with Tops20, a very decent clone of Tenex with a superior file system. 

http://tenex.opost.com/hbook.html

has a pretty good history.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From mfidelman at meetinghouse.net  Wed Mar 11 09:41:24 2020
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Wed, 11 Mar 2020 12:41:24 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
 <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>
 <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>
Message-ID: <f822f77b-c94b-2b3c-2697-119183af6b7b@meetinghouse.net>

Wow!? Where?? By who & what? (Are there any TACs still out there?)

Cheers,

Miles

On 3/11/20 4:35 AM, vinton cerf via Internet-history wrote:
> TACACS is indeed still used.
>
> v
>
>
> On Wed, Mar 11, 2020 at 12:15 AM Grant Taylor via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> On 3/10/20 1:12 PM, the keyboard of geoff goodfellow via
>> Internet-history wrote:
>>> TIP's were renamed to TAC's (Terminal Access Controllers) or some
>>> such... BUT, the Access control (i.e.  login to use/make a connection)
>>> of it was known as TACACS (Access Control System)....
>> Aside:  Is this related to TACACS+ which is still occasionally used in
>> network equipment?  Or is it a name collision?
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown



From gtaylor at tnetconsulting.net  Wed Mar 11 14:34:24 2020
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 11 Mar 2020 15:34:24 -0600
Subject: [ih] NCP and TCP implementations
In-Reply-To: <f822f77b-c94b-2b3c-2697-119183af6b7b@meetinghouse.net>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
 <1c3537d8-6c9d-e3d9-4787-e87d113308ae@spamtrap.tnetconsulting.net>
 <CAAFtm_Xzx_wrCo7UrMMKswBJY0j-7ED7FOh3ftumsf6OvQ3Gcg@mail.gmail.com>
 <f822f77b-c94b-2b3c-2697-119183af6b7b@meetinghouse.net>
Message-ID: <1c7df525-57da-5760-add6-4887bc4226e0@tnetconsulting.net>

2 emails for the price / distraction of one.



On 3/11/20 10:41 AM, Miles Fidelman via Internet-history wrote:
> Wow!? Where?? By who & what? (Are there any TACs still out there?)

My $EMPLOYER uses TACACS+ daily, much like RADIUS, for various pieces of 
equipment.

I probably consume the service multiple times a month.

I'm also getting ready to explore configuring a Linux server to use PAM 
to authenticate accounts via said TACACS+.



On 3/11/20 2:35 AM, vinton cerf via Internet-history wrote:
> TACACS is indeed still used.

Thank you for the clarification.



-- 
Grant. . . .
unix || die


From bob.hinden at gmail.com  Sat Mar 14 08:25:04 2020
From: bob.hinden at gmail.com (Bob Hinden)
Date: Sat, 14 Mar 2020 08:25:04 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
References: <CAAFtm_VOa2Xmq1aQ9-yLwYDCow9UYE5=anYxd1=uNm7s+=j0sg@mail.gmail.com>
 <CAPfiqjZYcMAAmQQNa_99sQ3roVsV40fqTsJi1uLgviUvVeo55w@mail.gmail.com>
 <CABf5zvKu5GS5XzSmCtd4T23rsxex4Gv1fFTCo3cUTQfKJ0wDWw@mail.gmail.com>
 <5E67D20C.9198.259832EC@bernie.fantasyfarm.com>
 <CABf5zvK0zLQmRkQMWFgMpZbE6-_LO-SmM0sHwbNpG2nYA63DUw@mail.gmail.com>
 <CAEf-zrj_D-tSY0=Ldy9K3fkTdo-uRPN0fSBKRTEb_zstCYLOGA@mail.gmail.com>
Message-ID: <EF1B791F-80AC-44E9-AF7F-58B053449939@gmail.com>

Geoff,

> On Mar 10, 2020, at 12:12 PM, the keyboard of geoff goodfellow via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> for some reason when the C/70's came along, TIP's were renamed to TAC's
> (Terminal Access Controllers) or some such?

I have a vague memory that the term TAC came from AUTODIN, which had included in its architecture a terminal controller that ran TCP/IP.   I found this that shows that:

https://www.computer.org/csdl/proceedings-article/afips/1978/50860735/12OmNzwHv9M

Bob


> BUT, the Access control (i.e.
> login to use/make a connection) of it was known as TACACS (Access Control
> System).... and it might have come about via a conversation/discussion
> yours truly had with Col. Dave Russell of DARPA:
> 
> we were in North Carolina heading/driving to the Fort Bragg ARMY base there
> to do a Packet Radio Net demo... as we drove along yours truly brought up
> the issue of the lack of security on the TIP's-- i.e. that anyone (i.e.
> "randoms") could call up and then connect to any host without having to
> "login" to do so.
> 
> Col. Russell kinda pushed back saying that without userid on a host there
> was nothing you could do -- and therefore would eventually "go away".
> 
> yours truly countered this allowed for "crackers" to spend their time
> trying to break into systems... which yours truly constantly witnessed on
> our systems at SRI was it was common for people to use easily guessable
> passwords such as their initials (or even summarily detailed in RFC602
> <https://tools.ietf.org/html/rfc602> by Bob Metcalfe of PARC-MAXC "*The
> Stockings Were Hung by the Chimney with Care"
> <https://tools.ietf.org/html/rfc602> *when a cracker guessed their SYSTEM's
> password which was their host name spelled backwards).
> 
> so to abate this, a "dead bolt" on the front door of the ARPANET (i.e. the
> TIPs) was needed to this vehicle of easy/free remote access "penetration"
> attemptages.
> 
> there may have been others in other quarters "preaching" the same issues...
> but Col. Russell then agreed and sometime later, there was TACACS.
> 
> let's not forget that at this time many (most?) of the APRANET systems had
> guest accounts on them... user GUEST, password ARPA... and they were
> "advertised" via the NIC at SRI-ARC (host 2) where after connecting to the
> TIP, you did a @l (for link... the original TIP command to connect to a
> host... later also @o (for open) and once getting the SRI-ARC Tenex exec
> prompt just typed in NIC and you were then automatically logged in (w/o a
> pw) as NICGUEST into an NLS (Doug Engelbart's system) special program that
> allowed you to electronically browse the ARPANET Resource Handbook on line
> that contained all the Good Stuff about each ARPANET host system.
> 
> let's also not forget that the MIT ITS (Incompatible Timesharing System)
> hosts MIT-AI, MIT-ML and MIT-DM did not have passwords (let alone any type
> of "security" at all, as it's "command" interface was DDT... perhaps it's
> where the term Security By/Through Obscurity came about?) and given this
> lack of passwords, it was a favorite hangout for "randoms" (along with
> SU-AI with its NET,GUE login) that dialed into the NO access controlled
> TIP's -- like yours truly did via the AMES-TIP after meeting a summer hire
> at Tymshare who wrote its phone # and a few TIP commands on the back of an
> envelope in the early 70's... :D
> 
> geoff
> 
> On Tue, Mar 10, 2020 at 8:03 AM Steve Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Argh.  I echoed Leo's use of "TAC."  I read it as referring to the TIP.  If
>> I recall correctly, the "TAC" was an access control method on the TIPs.
>> "TIP Access Control" I think.
>> 
>> Steve
>> 
>> 
>> On Tue, Mar 10, 2020 at 1:55 PM Bernie Cosell via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>> 
>>> On 10 Mar 2020 at 13:23, Steve Crocker via Internet-hi wrote:
>>> 
>>>> The TAC was an extension of the IMP.  The original IMP was built on
>>>> the
>>>> Honeywell 516 (and later 316) platform, which was a 16 bit twos
>>>> complement
>>>> computer.  I assume Hinden's reference to 15-bit arithmetic reflected
>>>> the
>>>> fact that the arithmetic was signed.
>>> 
>>> I honestly cannot remember what the TAC was!!   Was that the TIP?
>>> Regardless,
>>> yes, the x16s had 16-bit signed arithmetic with 10 bit addressing 9 bits
>>> of page
>>> address, 1 bit of "this page" or the 0 page, 16Kwords of memory.
>>> 
>>> Things got more complicated with the 316 -- it supported 32K words.  What
>>> we
>>> did for the TIP [and maybe the TAC, whatever that was] was to keep the
>> IMP
>>> *unchanged* in the bottom 16K, and then in the upper 16K we wrote a
>>> self-contained "host". There was some [small!] hack to fake interrupts
>> and
>>> input/output to this host but to the IMP it thought it was just another
>>> NCP
>>> connected host.  It'd set up a host output buffer and instead of doing a
>>> hardware
>>> "send" it'd pass control to the upper 16K.  Similarly [at least for the
>>> TIP], when it
>>> got something in from a terminal it'd copy it into a host-input buffer
>> and
>>> then
>>> issue an "interrupt" down to the IMP.   Worked quite well.
>>> 
>>>  /Bernie\
>>>            Bernie Cosell
>>>       bernie at fantasyfarm.com
>>> -- Too many people; too few sheep --
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> 
>> 
> 
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> http://geoff.livejournal.com
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20200314/8c7ae1a2/attachment.asc>

From brian.e.carpenter at gmail.com  Sun Mar 15 21:38:47 2020
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Mon, 16 Mar 2020 17:38:47 +1300
Subject: [ih] Statistical multiplexing
Message-ID: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>

Hi,

When was statistical multiplexing invented? Google doesn't seem to know.

Regards
   Brian Carpenter


From bill.n1vux at gmail.com  Sun Mar 15 22:30:36 2020
From: bill.n1vux at gmail.com (Bill Ricker)
Date: Mon, 16 Mar 2020 01:30:36 -0400
Subject: [ih] Statistical multiplexing
In-Reply-To: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
References: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
Message-ID: <CAAbKA3Um_5dJQ44hy1xGpL2mTG1c4CWqhb=hNmQsuLyn69VY5w@mail.gmail.com>

On Mon, Mar 16, 2020 at 12:39 AM Brian E Carpenter via Internet-history <
internet-history at elists.isoc.org> wrote:

> When was statistical multiplexing invented? Google doesn't seem to know.
>

Since Google picked up the business model my startup abandoned (after our
sales team took a dive), I take that as a challenge to my Google-fu ... or
Google-ismus, to follow Bletchley ...

The earliest reference in Google Books is a 1973 bibliography listing a
1971 paper.

*CHU WESLEY W *

*DEMULTIPLEXING CONSIDERATIONS FOR STATISTICAL MULTIPLEXORS *
CALIFORNIA UNIV OF LOS ANGELES OEPT OF COMPUTER SCIENCE
JACKSON PETER E PROCEEOINGS ACM IEEE SECOND SYMPOSIUM ON PROBLEMS IN THE
OPTIMIZATION OF DATA COMMUNICATION SYSTEMS
PALO ALTO CA OCTOBER 20 22 1971
ASSOCIATION FOR COMPUTING MACHINERY NEW YORK SPECIAL INTEREST GROUP ON OATA
COMMUNICATIONS
INSTITUTE OF ELECTRICAL ANO ELECTRONICS ENGINEERS NEW YORK COMPUTER SOCIETY
TECHNICAL COMMITTEE ON COMPUTER COMMUNICATIONS
*1971* IEEE CAT 71C59 C P 32 38 7 REFS ANNOTATION UNOER 3.2 9
("Annotated bibliography of the literature on resource sharing computer
networks" edited by Robert P. Blanc,
*if you can call an ALLCAPS lineprinter report "photo-ready copy" to have
been "edited"* )

HOWEVER moving over to Scholar.Google, we see was preceded by same W.W.Chu's


*Design considerations of statistical multiplexors*WW Chu - Proceedings of
the first ACM symposium on Problems ?, *1969* - dl.acm.org
Computer Science Department University of California Los Angeles, California
ABSTRACT Design considerations for statistical multiplexors with ?
  Cited by 20 Related articles All 3 versions

This may be the seminal paper?

A patent was filed 1976-08-24 by Wesley W Chu
https://patents.google.com/patent/US4093823A/en

Dr W.W.Chu's IEEE author file and personal pages

   -
   https://ieeexplore.ieee.org/author/37278389800?searchWithin=%22Author%20Ids%22:37278389800&history=no&sortType=newest&highlight=true&returnFacets=ALL&returnType=SEARCH&ranges=1969_1976_Year
   - https://www.ithistory.org/honor-roll/dr-wesley-w-chu
   - http://web.cs.ucla.edu/~wwc/
   - http://web.cs.ucla.edu/~wwc/publications.html#ccn




In *Scholar.Google*.com, "statistical multiplexing" does *not* occur as a
phrase *1945-1960*.
(and only appears as references from later patents to non-statistical prior
patents aside from above in the 1960s)
But there are a couple papers that might be precursors
https://scholar.google.com/scholar?q=statistical+multiplexing&hl=en&as_sdt=0%2C22&as_ylo=1945&as_yhi=1960

*Asynchronous multiplexing*
JE Taylor - Transactions of the American Institute of Electrical ?, 1960 -
ieeexplore.ieee.org
? to what statistical distributions is this a maximum? Does an optimum set
of statistics exist for any
general class of signals? The study of the second problem pro- vides bounds
on the performance
of chan- nel-synchronized and general asynchro- nous multiplexing systems ?
  Cited by 12 Related articles All 3 versions
  https://ieeexplore.ieee.org/abstract/document/6368516

*On the statistical theory of optimum demodulation*
J Thomas, E Wong - IRE Transactions on Information Theory, 1960 -
ieeexplore.ieee.org
? &i/F) = Ic,p[&, (r - 77i)]* (3 Page 2. 1960 Thomas and Wang: On the
Statistical Theory
of Optimum Demodulation 421 ? Quadrature 114odulation One of the most
familiar
examples of multiplexing is Let the received waveform be ?
  Cited by 25 Related articles All 3 versions

*Fundamental aspects of linear multiplexing*
LA Zadeh, KS Miller - Proceedings of the IRE, 1952 - ieeexplore.ieee.org
? t Columbia University, New York 27, NY $ New York University, New York
53, NY ' N. Marchand
and HR Holloway, "Multiplexing by Orthog- onal Functions," IRE ? However,
the statistical structures
of S1 and S2 are seldom well defined and are usually lacking in stability ?
  Cited by 15 Related articles All 2 versions

New Developments in FM Reception and Their Application to the Realization
of a System of
*Power-Division" Multiplexing*
E Baghdady - IRE Transactions on Communications Systems, 1959 -
ieeexplore.ieee.org
? 147 New Developments in FM Reception and Their Application to the
Realization of a System of
?Power-Division? Multiplexing* ELIE J. BAGHDADYt ? The following is only a
partial list: a)
Multiplexing by ?power division'' and amplitude discrimination becomes
practicable ?
  Cited by 25 Related articles All 3 versions

*On the modulation levels in a frequency multiplexed communication system
by statistical methods*
R Brock, R McCarty - IRE Transactions on Information Theory, 1955 -
ieeexplore.ieee.org
? For the case of frequency modulation, where the sinusoids are of constant
amplitude, the resultant
in- stantaneous value of multiplexing n subcarrier ? of subcarriers, (ie) n
I 12, which is of particular
interest here, can be readily determined by the methods of statistical
analysis ?
  Cited by 2 Related articles All 3 versions

And of course, one should mention  Hedy_Lamarr
<https://en.wikipedia.org/wiki/Hedy_Lamarr> and WW2 Spread Spectrum
(frequency hopping) which is an allied art form - a practical precursor to
the formal statistical models of later statistical multiplexing.
Which suggests the real origin may have been classified in WW2 and might be
in historical archives now.

-- 
Bill Ricker
bill.n1vux at gmail.com
https://www.linkedin.com/in/n1vux


From gnu at toad.com  Sun Mar 15 23:54:58 2020
From: gnu at toad.com (John Gilmore)
Date: Sun, 15 Mar 2020 23:54:58 -0700
Subject: [ih] Statistical multiplexing
In-Reply-To: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com> 
References: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
Message-ID: <30899.1584341698@hop.toad.com>

> When was statistical multiplexing invented?

The first product I know of that included it was called a Smart/Mux.
One of my early employers, Scientific Time Sharing Corp. in Bethesda,
which ran an IBM mainframe running APL.  They used pairs of these to
compress the traffic of modem banks in remote cities (typically 300 baud
modems carrying 134.5bps printing Selectric terminal traffic, often
dialed in to with with acoustic couplers).  This was in about 1973.

I'd look for ads in old magazines like Datamation or Computerworld.
Here's an article in Computerworld of August 28, 1974, page 19, complete
with typos:

  https://archive.org/details/computerworld8275unse9/page/n17/mode/2up/search/%22smart+mux%22?q=%22smart+mux%22

  "DCA's Smart/Mux Has Bit/Sec Detection

  Atlanta - Digital Communications Associates, Inc. has added an
  intelligent remote multiplexer to its line of programmable front ends
  and concentrators.

  Thy Smart/Mux offers automatic bit/sec rate detection for 10-, 15- and
  30 char./sec terminals; complete character transparency; and error
  detection/retransmission, according to the firm.

  The multiplexer can transmit data from up to 32 interactive mixed-
  speed terminals over a 2,400 bit/sec synchronous link to the head-end
  multiplexer, and dial backup capability is provided, a spokesman
  noted.

  Smart/mux options include a remote line printer, card readers, full-
  and half-duplex 1,200 bit/sec terminal support, and support for IBM
  2780 remote job entry terminals.

  A host-end Smart/Mux can handle up to six remote-and multiplexers,
  the firm stated.  A typical system with 24 ports costs $18,400.

  Delivery is 60 days from the firm at 2801 Clearview Place, Suite 400,
  30340."

Hmm, it looks like IDG donated a complete set of Computerworld's and
funded their scanning by the Internet Archive!  Now there's some history...

Here's some brief info about the company:

  https://en.wikipedia.org/wiki/Digital_Communications_Associates

That page led me to this very interesting history of computer
communications by Jim Pelkey, from 85 interviews he also made available,
here:

  http://www.historyofcomputercommunications.info/

	John



From vint at google.com  Mon Mar 16 03:16:11 2020
From: vint at google.com (Vint Cerf)
Date: Mon, 16 Mar 2020 06:16:11 -0400
Subject: [ih] Statistical multiplexing
In-Reply-To: <CAAbKA3Um_5dJQ44hy1xGpL2mTG1c4CWqhb=hNmQsuLyn69VY5w@mail.gmail.com>
References: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
 <CAAbKA3Um_5dJQ44hy1xGpL2mTG1c4CWqhb=hNmQsuLyn69VY5w@mail.gmail.com>
Message-ID: <CAHxHggdtG2=KYgE9yBN-C2aWogT76=Zbbwf2prFfeMK2B_riYw@mail.gmail.com>

I believe Weley Chu is the correct answer - UCLA. Steve Crocker and I were
graduate students when Wes was a young professor there.

It is also fair to cite Hedy Lamarr who invented frequency hopping as a
multiplexing method. Eventually that led to direct sequence spreading
which was used in the Packet Radio system during the development of the
Internet.

vint cerf

On Mon, Mar 16, 2020 at 1:30 AM Bill Ricker via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Mon, Mar 16, 2020 at 12:39 AM Brian E Carpenter via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > When was statistical multiplexing invented? Google doesn't seem to know.
> >
>
> Since Google picked up the business model my startup abandoned (after our
> sales team took a dive), I take that as a challenge to my Google-fu ... or
> Google-ismus, to follow Bletchley ...
>
> The earliest reference in Google Books is a 1973 bibliography listing a
> 1971 paper.
>
> *CHU WESLEY W *
>
> *DEMULTIPLEXING CONSIDERATIONS FOR STATISTICAL MULTIPLEXORS *
> CALIFORNIA UNIV OF LOS ANGELES OEPT OF COMPUTER SCIENCE
> JACKSON PETER E PROCEEOINGS ACM IEEE SECOND SYMPOSIUM ON PROBLEMS IN THE
> OPTIMIZATION OF DATA COMMUNICATION SYSTEMS
> PALO ALTO CA OCTOBER 20 22 1971
> ASSOCIATION FOR COMPUTING MACHINERY NEW YORK SPECIAL INTEREST GROUP ON OATA
> COMMUNICATIONS
> INSTITUTE OF ELECTRICAL ANO ELECTRONICS ENGINEERS NEW YORK COMPUTER SOCIETY
> TECHNICAL COMMITTEE ON COMPUTER COMMUNICATIONS
> *1971* IEEE CAT 71C59 C P 32 38 7 REFS ANNOTATION UNOER 3.2 9
> ("Annotated bibliography of the literature on resource sharing computer
> networks" edited by Robert P. Blanc,
> *if you can call an ALLCAPS lineprinter report "photo-ready copy" to have
> been "edited"* )
>
> HOWEVER moving over to Scholar.Google, we see was preceded by same
> W.W.Chu's
>
>
> *Design considerations of statistical multiplexors*WW Chu - Proceedings of
> the first ACM symposium on Problems ?, *1969* - dl.acm.org
> Computer Science Department University of California Los Angeles,
> California
> ABSTRACT Design considerations for statistical multiplexors with ?
>   Cited by 20 Related articles All 3 versions
>
> This may be the seminal paper?
>
> A patent was filed 1976-08-24 by Wesley W Chu
> https://patents.google.com/patent/US4093823A/en
>
> Dr W.W.Chu's IEEE author file and personal pages
>
>    -
>
> https://ieeexplore.ieee.org/author/37278389800?searchWithin=%22Author%20Ids%22:37278389800&history=no&sortType=newest&highlight=true&returnFacets=ALL&returnType=SEARCH&ranges=1969_1976_Year
>    - https://www.ithistory.org/honor-roll/dr-wesley-w-chu
>    - http://web.cs.ucla.edu/~wwc/
>    - http://web.cs.ucla.edu/~wwc/publications.html#ccn
>
>
>
>
> In *Scholar.Google*.com, "statistical multiplexing" does *not* occur as a
> phrase *1945-1960*.
> (and only appears as references from later patents to non-statistical prior
> patents aside from above in the 1960s)
> But there are a couple papers that might be precursors
>
> https://scholar.google.com/scholar?q=statistical+multiplexing&hl=en&as_sdt=0%2C22&as_ylo=1945&as_yhi=1960
>
> *Asynchronous multiplexing*
> JE Taylor - Transactions of the American Institute of Electrical ?, 1960 -
> ieeexplore.ieee.org
> ? to what statistical distributions is this a maximum? Does an optimum set
> of statistics exist for any
> general class of signals? The study of the second problem pro- vides bounds
> on the performance
> of chan- nel-synchronized and general asynchro- nous multiplexing systems ?
>   Cited by 12 Related articles All 3 versions
>   https://ieeexplore.ieee.org/abstract/document/6368516
>
> *On the statistical theory of optimum demodulation*
> J Thomas, E Wong - IRE Transactions on Information Theory, 1960 -
> ieeexplore.ieee.org
> ? &i/F) = Ic,p[&, (r - 77i)]* (3 Page 2. 1960 Thomas and Wang: On the
> Statistical Theory
> of Optimum Demodulation 421 ? Quadrature 114odulation One of the most
> familiar
> examples of multiplexing is Let the received waveform be ?
>   Cited by 25 Related articles All 3 versions
>
> *Fundamental aspects of linear multiplexing*
> LA Zadeh, KS Miller - Proceedings of the IRE, 1952 - ieeexplore.ieee.org
> ? t Columbia University, New York 27, NY $ New York University, New York
> 53, NY ' N. Marchand
> and HR Holloway, "Multiplexing by Orthog- onal Functions," IRE ? However,
> the statistical structures
> of S1 and S2 are seldom well defined and are usually lacking in stability ?
>   Cited by 15 Related articles All 2 versions
>
> New Developments in FM Reception and Their Application to the Realization
> of a System of
> *Power-Division" Multiplexing*
> E Baghdady - IRE Transactions on Communications Systems, 1959 -
> ieeexplore.ieee.org
> ? 147 New Developments in FM Reception and Their Application to the
> Realization of a System of
> ?Power-Division? Multiplexing* ELIE J. BAGHDADYt ? The following is only a
> partial list: a)
> Multiplexing by ?power division'' and amplitude discrimination becomes
> practicable ?
>   Cited by 25 Related articles All 3 versions
>
> *On the modulation levels in a frequency multiplexed communication system
> by statistical methods*
> R Brock, R McCarty - IRE Transactions on Information Theory, 1955 -
> ieeexplore.ieee.org
> ? For the case of frequency modulation, where the sinusoids are of constant
> amplitude, the resultant
> in- stantaneous value of multiplexing n subcarrier ? of subcarriers, (ie) n
> I 12, which is of particular
> interest here, can be readily determined by the methods of statistical
> analysis ?
>   Cited by 2 Related articles All 3 versions
>
> And of course, one should mention  Hedy_Lamarr
> <https://en.wikipedia.org/wiki/Hedy_Lamarr> and WW2 Spread Spectrum
> (frequency hopping) which is an allied art form - a practical precursor to
> the formal statistical models of later statistical multiplexing.
> Which suggests the real origin may have been classified in WW2 and might be
> in historical archives now.
>
> --
> Bill Ricker
> bill.n1vux at gmail.com
> https://www.linkedin.com/in/n1vux
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


From dhc at dcrocker.net  Mon Mar 16 06:35:11 2020
From: dhc at dcrocker.net (Dave Crocker)
Date: Mon, 16 Mar 2020 06:35:11 -0700
Subject: [ih] Statistical multiplexing
In-Reply-To: <CAHxHggdtG2=KYgE9yBN-C2aWogT76=Zbbwf2prFfeMK2B_riYw@mail.gmail.com>
References: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
 <CAAbKA3Um_5dJQ44hy1xGpL2mTG1c4CWqhb=hNmQsuLyn69VY5w@mail.gmail.com>
 <CAHxHggdtG2=KYgE9yBN-C2aWogT76=Zbbwf2prFfeMK2B_riYw@mail.gmail.com>
Message-ID: <0862e661-6423-913e-6094-ec7e869248c7@dcrocker.net>

On 3/16/2020 3:16 AM, Vint Cerf via Internet-history wrote:
> I believe Weley Chu is the correct answer - UCLA. Steve Crocker and I were
> graduate students when Wes was a young professor there.

Since the Arpanet was based on stat mux, doesn't that qualify as earlier 
than Chu?


> It is also fair to cite Hedy Lamarr who invented frequency hopping as a
> multiplexing method. Eventually that led to direct sequence spreading
> which was used in the Packet Radio system during the development of the
> Internet.

But what she proposed had fixed timings and fixed frequency residence, 
didn't it?  ie, it didn't have a statistical component?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From pschow at gmail.com  Mon Mar 16 08:58:51 2020
From: pschow at gmail.com (Peter Schow)
Date: Mon, 16 Mar 2020 09:58:51 -0600
Subject: [ih] Statistical multiplexing
In-Reply-To: <CAHxHggdtG2=KYgE9yBN-C2aWogT76=Zbbwf2prFfeMK2B_riYw@mail.gmail.com>
References: <f095000d-9fff-d2d0-f2ce-7711bdd62018@gmail.com>
 <CAAbKA3Um_5dJQ44hy1xGpL2mTG1c4CWqhb=hNmQsuLyn69VY5w@mail.gmail.com>
 <CAHxHggdtG2=KYgE9yBN-C2aWogT76=Zbbwf2prFfeMK2B_riYw@mail.gmail.com>
Message-ID: <CANaTVhWJ=A_m6fngeqc6hdPyAykhB1WpHC5W=rRZKPk1sx3iLw@mail.gmail.com>

On Mon, Mar 16, 2020 at 4:16 AM Vint Cerf via Internet-history
<internet-history at elists.isoc.org> wrote:
>
> I believe Weley Chu is the correct answer - UCLA. Steve Crocker and I were
> graduate students when Wes was a young professor there.

Wesley Chu does acknowledge in his 1969 paper that his statistical
multiplexer work was hatched at Bell Labs, Holmdel.


From jnc at mercury.lcs.mit.edu  Mon Mar 16 09:31:34 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 16 Mar 2020 12:31:34 -0400 (EDT)
Subject: [ih] NCP and TCP implementations
Message-ID: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>

Hi, all, I've been meaning to respond to this thread, but I wanted to look at
some old host tables first, since as an amateur historian I'm only too aware
of how fallible human memory is (see here:

  http://www.chiappa.net/~jnc/nontech/tmlotus.html
  
for an amusimg story about that), _but_ I couldn't find any online!

I did have a modest collection of them at home, but didn't have access to them
where I was. I have now put them all online here:

  http://mercury.lcs.mit.edu/~jnc/tech/hosts/

and will add a link to them from my "ARPANET Technical Information" page:

  http://www.chiappa.net/~jnc/tech/arpanet.html

when I get a chance. They are a mixture of NIC- and MIT-format host tables. If
anyone has any that are missing from that set that they'd like me to add,
please contact me off-list.

Anyway, on to what I wanted to comment on:


    > From: Geoff Goodfellow

    > for some reason when the C/70's came along, TIP's were renamed to TAC's

IIRC, the C/70's were timesharing machines (running Unix, IITC); the C/
machines which were packet switches (IMPs), terminal concentators (TACs) etc
were C/30's. I note from the host tables that the TIP's all seem to have been
H316's, and all TAC's were C/30's.

I don't recall there difference between a TIP and a TAC, but in addition to
the hardware, the TAC may have been (as someone suggested) a TCP machine. Someone
needs to check this, though, as the February 1983 host table (above) shows a
few TIP's (on H316's), which was after the NCP->TCP conversion (January '83).


My memories of what happened at MIT are confused, since it's all mixed up with
the addition of a 3rd IMP to MIT (IMP 77), which IIRC was one of the first
C/30 IMPs. Actually, I'm pretty sure that there were two new C/30 IMPs at that
point, one of which replaced IMP 44, (a TIP, which IIRC was turned into a host),
and I do see this line:

  ;;; 254,MIT-TIP,TIP,USER,NEW has moved to 2/77.

in the Aug/82 host table. (By the January/83 table, it had turned into a C/30,
and was MIT-TAC. So it must have quickly been converted from an H316 to a
C/30, but I have no memory of that.)


    > let's also not forget that the MIT ITS (Incompatible Timesharing System)
    > hosts MIT-AI, MIT-ML and MIT-DM did not have passwords

Initially, no; later, under pressure from DARPA, passwords were added (along
with a liberal policy on guest accounts).

	Noel


From bernie at fantasyfarm.com  Mon Mar 16 10:27:39 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 16 Mar 2020 13:27:39 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
References: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
Message-ID: <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>

On 16 Mar 2020 at 12:31, Noel Chiappa via Internet-history wrote:

> Anyway, on to what I wanted to comment on:
> 
> 
>     > From: Geoff Goodfellow
> 
>     > for some reason when the C/70's came along, TIP's were renamed to
> TAC's
> 
> IIRC, the C/70's were timesharing machines (running Unix, IITC); the
> C/
> machines which were packet switches (IMPs), terminal concentators (TACs)
> etc
> were C/30's. I note from the host tables that the TIP's all seem to have
> been
> H316's, and all TAC's were C/30's.

You're correct.   The TIP was a 316 IMP with the terminal handling code in the 
upper 16K of memory.   The C/30 was an implementation of the 316 on the MBB 
[Microprogrammable Building Block] that BBN had developed.   I have no idea 
about why it was "/30".  The MBB was "microprogrammable" and so we built the 
C/70 -- it was called the "C machine" and the idea what that "C" was its assembly 
language.  I have no idea how that project got started but three of us were 
working on it: Al Nemeth was hacking the Unix kernel,  Carl Howe did the 
microcode and I did a crosscompiler from TENEX to the MBB.

I think it was tagged the "C/70" because it was intended to run Unix as well as an 
11/70 [in practice it worked out to be MUCH faster].  the MBB had 20 bit words 
and Al and Carl were designing a hand-tuned, irregular "instruction set".  Such 
things as a built-in indirect index: he figured out the optimal size of the offset 
field so that referencing part of a 'struct' through a pointer could be done in a 
single instruction not using a register.

There was *NO* regularity to the "instruction set" -- each instruction carved up 
the 20 available bits as seemed most efficient.  We added new/strange 
instructions as we saw fit [e.g.,: Al noticed that almost all subroutine calls in the 
kernel were either zero or one argument calls, and so we had two call 
instructions: the normal one [push push push <call>] and one that *always* 
pushed ONE arg and called in a single instruction.   I had the fun task of putting 
together a C cross compiler running on a 36 bit machine for a 20-bit-word 
machine to handle all that irregularity.

We eventually got the kernel working [with the underlying "instruction set" 
constantly evolving as Al looked at the code the compiler was producing and 
figuring ways to tweak things to make it faster.  Carl and I mostly kept up.  The 
big day [for me, at least] was when I ported the C compiler I"d been working on 
to run natively on the MBB [which involved taking out the 36-bit-ness and 
replacing it with 20-bit-ness].  The Unix kernel compiled on the MBB  and was 
bit-for-bit the same as the image produced on TENEX and we cut the strings to 
TENEX and it was now running solo.   That was pretty much when i left the 
project:  I have no idea [at least no memory] what happened after that [some of 
you might have guessed that I was a bit of a vagabond jack-of-all-trades at BBN: I 
worked on one project or another, got it working and "released" and then I went 
onto the next thing].  I don't remember what *we* called it, but shortly after we 
got it all working it went over to BBNCC and was marketed as the "C/70"

I don't remember its ever running the IMP code.  Alex/Dave: was any of the 
development of the C70 written up?  I wasn't much on writing reports :o)

  /Bernie\



            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --
   





From amckenzie3 at yahoo.com  Mon Mar 16 10:43:22 2020
From: amckenzie3 at yahoo.com (Alex McKenzie)
Date: Mon, 16 Mar 2020 17:43:22 +0000 (UTC)
Subject: [ih] NCP and TCP implementations
In-Reply-To: <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>
References: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
 <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>
Message-ID: <530756142.1460705.1584380602454@mail.yahoo.com>

 Bernie et al,
I am quite sure that the C/70 never ran the IMP code.
The MBB was probably funded by ARPA and its development was (I think) recorded in BBN QTRs to ARPA and definitely in other BBN Technical Reports.? But I think the C/70 was a BBN internal (self funded) project and (I think) was not in QTRs.? I do think there was at least one technical paper about the C/70 given at a conference but I can't find any reference, so perhaps not.
Alex

    On Monday, March 16, 2020, 1:28:21 PM EDT, Bernie Cosell via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 On 16 Mar 2020 at 12:31, Noel Chiappa via Internet-history wrote:

> Anyway, on to what I wanted to comment on:
> 
> 
>? ? > From: Geoff Goodfellow
> 
>? ? > for some reason when the C/70's came along, TIP's were renamed to
> TAC's
> 
> IIRC, the C/70's were timesharing machines (running Unix, IITC); the
> C/
> machines which were packet switches (IMPs), terminal concentators (TACs)
> etc
> were C/30's. I note from the host tables that the TIP's all seem to have
> been
> H316's, and all TAC's were C/30's.

You're correct.? The TIP was a 316 IMP with the terminal handling code in the 
upper 16K of memory.? The C/30 was an implementation of the 316 on the MBB 
[Microprogrammable Building Block] that BBN had developed.? I have no idea 
about why it was "/30".? The MBB was "microprogrammable" and so we built the 
C/70 -- it was called the "C machine" and the idea what that "C" was its assembly 
language.? I have no idea how that project got started but three of us were 
working on it: Al Nemeth was hacking the Unix kernel,? Carl Howe did the 
microcode and I did a crosscompiler from TENEX to the MBB.

I think it was tagged the "C/70" because it was intended to run Unix as well as an 
11/70 [in practice it worked out to be MUCH faster].? the MBB had 20 bit words 
and Al and Carl were designing a hand-tuned, irregular "instruction set".? Such 
things as a built-in indirect index: he figured out the optimal size of the offset 
field so that referencing part of a 'struct' through a pointer could be done in a 
single instruction not using a register.

There was *NO* regularity to the "instruction set" -- each instruction carved up 
the 20 available bits as seemed most efficient.? We added new/strange 
instructions as we saw fit [e.g.,: Al noticed that almost all subroutine calls in the 
kernel were either zero or one argument calls, and so we had two call 
instructions: the normal one [push push push <call>] and one that *always* 
pushed ONE arg and called in a single instruction.? I had the fun task of putting 
together a C cross compiler running on a 36 bit machine for a 20-bit-word 
machine to handle all that irregularity.

We eventually got the kernel working [with the underlying "instruction set" 
constantly evolving as Al looked at the code the compiler was producing and 
figuring ways to tweak things to make it faster.? Carl and I mostly kept up.? The 
big day [for me, at least] was when I ported the C compiler I"d been working on 
to run natively on the MBB [which involved taking out the 36-bit-ness and 
replacing it with 20-bit-ness].? The Unix kernel compiled on the MBB? and was 
bit-for-bit the same as the image produced on TENEX and we cut the strings to 
TENEX and it was now running solo.? That was pretty much when i left the 
project:? I have no idea [at least no memory] what happened after that [some of 
you might have guessed that I was a bit of a vagabond jack-of-all-trades at BBN: I 
worked on one project or another, got it working and "released" and then I went 
onto the next thing].? I don't remember what *we* called it, but shortly after we 
got it all working it went over to BBNCC and was marketed as the "C/70"

I don't remember its ever running the IMP code.? Alex/Dave: was any of the 
development of the C70 written up?? I wasn't much on writing reports :o)

? /Bernie\



? ? ? ? ? ? Bernie Cosell
? ? ? bernie at fantasyfarm.com
-- Too many people; too few sheep --
? 



-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  

From stewart at serissa.com  Mon Mar 16 10:58:10 2020
From: stewart at serissa.com (Lawrence Stewart)
Date: Mon, 16 Mar 2020 13:58:10 -0400
Subject: [ih] Statistical Multiplexing
In-Reply-To: <mailman.56.1584380610.1740.internet-history@elists.isoc.org>
References: <mailman.56.1584380610.1740.internet-history@elists.isoc.org>
Message-ID: <B079DB8E-6965-4F72-8FE7-6130905D0B5F@serissa.com>

The earliest work I know about was indeed from Bell Laboratories: https://en.wikipedia.org/wiki/Time-assignment_speech_interpolation <https://en.wikipedia.org/wiki/Time-assignment_speech_interpolation>.  This may be what Chu was referring to.

Time assignment speech interpolation (TASI) was a statistical multiplexing technique to increase channel capacity of expensive (overseas) cables.

Evidently the first TASI links were in service in mid-1960.

The semi-official record seems to be https://ieeexplore.ieee.org/abstract/document/6773473 <https://ieeexplore.ieee.org/abstract/document/6773473>

I remember learning about this while doing Ethernet voice at PARC circa 1979.




From jnc at mercury.lcs.mit.edu  Mon Mar 16 11:28:57 2020
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 16 Mar 2020 14:28:57 -0400 (EDT)
Subject: [ih] NCP and TCP implementations
Message-ID: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>

    > From: Bernie Cosell

    > The TIP was a 316 IMP with the terminal handling code in the upper 16K
    > of memory.  The C/30 was an implementation of the 316 on the MBB

Any idea/recollection of why the 316 TIP hardware was ditched and replaced
with the C/30 for the TAC? Just to have more modern/maintainable hardware? (I
recall the 316 was made of a lot of tiny cards.)

    > The MBB was "microprogrammable" and so we built the C/70 ... Alex/Dave:
    > was any of the development of the C70 written up?

I definitely read a document about the MBB. I have this vague memory that it was
hardcopy, but I doubt I'll be able to locate it anytime soon.

ISTR that the MBB took a daughtercard, which implemented extra functionality,
and the C/70 took its own; I don't recall exactly what the C/70 one did,
though.

    Noel



From dave.walden.family at gmail.com  Mon Mar 16 15:27:18 2020
From: dave.walden.family at gmail.com (dave walden)
Date: Mon, 16 Mar 2020 15:27:18 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <530756142.1460705.1584380602454@mail.yahoo.com>
References: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
 <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>
 <530756142.1460705.1584380602454@mail.yahoo.com>
Message-ID: <2ea217b5-30a2-7120-a38e-55fff1517429@gmail.com>

Alex, I think the MBB was developed, by Kraley and Rettberg, with BBN 
internal R&D money.

Everyone, What I think I remember is that before the C/30 etc. was 
developed, BBN Communication Corporation was BBN Computer Company and 
its product was a computer, the C/70, which executed C as its basic 
instruction set.  Univx probably ran on that machine.  The 70 might have 
been chosen because BBN thought the C/70 was a competitor for the VAX 
11/70.  Ben Barker would know all about this.  I don't remember if the 
C/30 IMP development started before BBNCC became the computer 
corporation instead of the computer company.  The C/30, as perhaps has 
already been noted, was a different set of micro code for the MBB which 
looked like the Honeywell 316 IMP, so the earlier IMP code ran on the 
new machine, called a C/30.  I don't remember all the reasons for moving 
from the 316 to the C/30 but I suppose one of them was that computers 
were getting cheapter and the 316 was pretty expensive and a cheaper 
computer was needed.  Another reason might have been that BBN no longer 
had to but 316s from Honeywell and instead got to make the margin on the 
hardware sale because it manufactured the computer.



On 3/16/2020 10:43 AM, Alex McKenzie via Internet-history wrote:
>   Bernie et al,
> I am quite sure that the C/70 never ran the IMP code.
> The MBB was probably funded by ARPA and its development was (I think) recorded in BBN QTRs to ARPA and definitely in other BBN Technical Reports.? But I think the C/70 was a BBN internal (self funded) project and (I think) was not in QTRs.? I do think there was at least one technical paper about the C/70 given at a conference but I can't find any reference, so perhaps not.
> Alex
> 


From dave.walden.family at gmail.com  Mon Mar 16 15:42:31 2020
From: dave.walden.family at gmail.com (dave walden)
Date: Mon, 16 Mar 2020 15:42:31 -0700
Subject: [ih] H316 to MBB-base C/30
Message-ID: <06581ebe-6565-0f6a-0efa-bbdb526cee2d@gmail.com>

Here is one more reason for the transition:
"The Honeywell 316 computer was going out of production and the 
Honeywell 716 was not suitable for the IMP task."

Someone much have recounted that for the "MBB-based systems" subsection 
of the paper at https://walden-family.com/bbn/imp-code.pdf


From pnr at planet.nl  Mon Mar 16 13:08:32 2020
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 16 Mar 2020 21:08:32 +0100
Subject: [ih] NCP and TCP implementations
In-Reply-To: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
Message-ID: <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>

Dear all,

The C/30 and C/70 were discussed on this list in October 2017. I think I recall from then that the MBB project got started because BBN had not done a CPU project in a while, Al Nemeth had some ideas and ARPA needed a replacement for the 316/516.

This is an excerpt from a message I posted back then:

====

The MBB processor:

The MBB processor is documented in this paper (available from the ACM library, unfortunately behind a paywall):
M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake, ?Design of a User-Microprogrammable Building Block? in Proceedings of the 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
It is an interesting read and I can certainly recommend it; it also discusses some aspects of the C/30 and C/70 configurations.

The MBB processor seems to have been word (not byte) addressable, with 20 bit addresses and data paths. It is highly reminiscent of the Alto, with I/O device controllers partially implemented in microcode. It is also somewhat reminiscent of the TI990 and the later Sparc in that it had 1024 registers with a visible window of 16 registers. It is unique in that the processor had two optional daughter boards to customise the system: (i) a board to assist with macro-instruction decoding, (ii) an MMU board.

The C/30 version seems to have had a macro-instruction daughter board, but with addresses going straight through. When used as an IMP, some 30% of microcycles seem to have gone on I/O processing and the remaining 70% on executing H316 code.

The C/70 version had both daughter boards. The MMU board divided the 1MW address space into 128 pages of 4KW, and had protection & dirty bits per page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is only 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses. Apparently, there was also a ?switch? (IMP?) version of the C/70, without the MMU board and running a minimal OS (but using the ?C? microcode & board).

The C/70 seems to have implemented a load/store type architecture with 40 basic instructions, each offering one of 19 addressing modes in an orthogonal setup. The 19 addressing modes were designed around typical C data access operations. Next to that there were 44 specialised instructions.

Procedure calls were very fast, as specialised instructions existed to switch to a new register bank as part of the call, with spilling to main memory upon deep recursion. Apparently it was possible for C code to ?call' into microcode, and this may be how system calls were done.

====

According to the paper mentioned above, it is all documented in detail in the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980. Unfortunately, this document does not seem to be available on the DTIC website. Maybe this document still exists in the BBN (and successor) library. As the topic comes up from time to time, maybe it could be added to Bitsavers? 

BBN-UNIX for the C/70:

This was a port of the V7 based Unix that BBN had running on the PDP11, with various BSD-type extensions. It had the Gurwitz TCP/IP stack integrated, and accessible via the VAX-TCP API (which was compatible with the earlier NCP Unix API). It also had some of the earlier IPC features (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is available for study on TUHS https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet (note how the code has #ifdef?s for VAX and MBB).

Again from the discussion three years ago, I think this Unix version and the C/30-C/70 were maintained into the late nineties by BBN.

There was a commercial version of the C/70 (called the C/60) done by/for the BBN computer division - see for instance this advert: https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false <https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN C/60&f=false>

Paul


> On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> 
>> From: Bernie Cosell
> 
>> The TIP was a 316 IMP with the terminal handling code in the upper 16K
>> of memory.  The C/30 was an implementation of the 316 on the MBB
> 
> Any idea/recollection of why the 316 TIP hardware was ditched and replaced
> with the C/30 for the TAC? Just to have more modern/maintainable hardware? (I
> recall the 316 was made of a lot of tiny cards.)
> 
>> The MBB was "microprogrammable" and so we built the C/70 ... Alex/Dave:
>> was any of the development of the C70 written up?
> 
> I definitely read a document about the MBB. I have this vague memory that it was
> hardcopy, but I doubt I'll be able to locate it anytime soon.
> 
> ISTR that the MBB took a daughtercard, which implemented extra functionality,
> and the C/70 took its own; I don't recall exactly what the C/70 one did,
> though.
> 
>    Noel
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history



From agmalis at gmail.com  Mon Mar 16 13:37:34 2020
From: agmalis at gmail.com (Andrew G. Malis)
Date: Mon, 16 Mar 2020 16:37:34 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
Message-ID: <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>

I wrote both code and microcode for the C/30 IMP. We started by
implementing a straight emulation of the Honeywell 316 architecture and
instruction set so that we could port the existing IMP code pretty much
untouched. Once that was working, we then conducted extensive performance
testing to determine where the code was spending its time, and moved a
number of expensive (from a CPU perspective) operations, such as queue
handing and process scheduling, to the microcode. That also allowed us to
make the queue handing instructions "atomic", which helped
eliminate possible race conditions without requiring software semaphores
and the like. We were able to really improve the IMP's forward capacity on
the fast path though the use of microcode optimization. In the end, the
C/30 IMP code looked very different from the original 316 code base, even
though it was still in assembly language (what we now called "C/30
assembly"). We had talked about porting the code base to C and compiling
that down to C/30 assembly, but that never ended up happening.

Cheers,
Andy


On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
internet-history at elists.isoc.org> wrote:

> Dear all,
>
> The C/30 and C/70 were discussed on this list in October 2017. I think I
> recall from then that the MBB project got started because BBN had not done
> a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
> replacement for the 316/516.
>
> This is an excerpt from a message I posted back then:
>
> ====
>
> The MBB processor:
>
> The MBB processor is documented in this paper (available from the ACM
> library, unfortunately behind a paywall):
> M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
> ?Design of a User-Microprogrammable Building Block? in Proceedings of the
> 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
> It is an interesting read and I can certainly recommend it; it also
> discusses some aspects of the C/30 and C/70 configurations.
>
> The MBB processor seems to have been word (not byte) addressable, with 20
> bit addresses and data paths. It is highly reminiscent of the Alto, with
> I/O device controllers partially implemented in microcode. It is also
> somewhat reminiscent of the TI990 and the later Sparc in that it had 1024
> registers with a visible window of 16 registers. It is unique in that the
> processor had two optional daughter boards to customise the system: (i) a
> board to assist with macro-instruction decoding, (ii) an MMU board.
>
> The C/30 version seems to have had a macro-instruction daughter board, but
> with addresses going straight through. When used as an IMP, some 30% of
> microcycles seem to have gone on I/O processing and the remaining 70% on
> executing H316 code.
>
> The C/70 version had both daughter boards. The MMU board divided the 1MW
> address space into 128 pages of 4KW, and had protection & dirty bits per
> page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is only
> 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
> Apparently, there was also a ?switch? (IMP?) version of the C/70, without
> the MMU board and running a minimal OS (but using the ?C? microcode &
> board).
>
> The C/70 seems to have implemented a load/store type architecture with 40
> basic instructions, each offering one of 19 addressing modes in an
> orthogonal setup. The 19 addressing modes were designed around typical C
> data access operations. Next to that there were 44 specialised instructions.
>
> Procedure calls were very fast, as specialised instructions existed to
> switch to a new register bank as part of the call, with spilling to main
> memory upon deep recursion. Apparently it was possible for C code to ?call'
> into microcode, and this may be how system calls were done.
>
> ====
>
> According to the paper mentioned above, it is all documented in detail in
> the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
> Unfortunately, this document does not seem to be available on the DTIC
> website. Maybe this document still exists in the BBN (and successor)
> library. As the topic comes up from time to time, maybe it could be added
> to Bitsavers?
>
> BBN-UNIX for the C/70:
>
> This was a port of the V7 based Unix that BBN had running on the PDP11,
> with various BSD-type extensions. It had the Gurwitz TCP/IP stack
> integrated, and accessible via the VAX-TCP API (which was compatible with
> the earlier NCP Unix API). It also had some of the earlier IPC features
> (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is
> available for study on TUHS
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet (note
> how the code has #ifdef?s for VAX and MBB).
>
> Again from the discussion three years ago, I think this Unix version and
> the C/30-C/70 were maintained into the late nineties by BBN.
>
> There was a commercial version of the C/70 (called the C/60) done by/for
> the BBN computer division - see for instance this advert:
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
> <
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
> C/60&f=false>
>
> Paul
>
>
> > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> >
> >> From: Bernie Cosell
> >
> >> The TIP was a 316 IMP with the terminal handling code in the upper 16K
> >> of memory.  The C/30 was an implementation of the 316 on the MBB
> >
> > Any idea/recollection of why the 316 TIP hardware was ditched and
> replaced
> > with the C/30 for the TAC? Just to have more modern/maintainable
> hardware? (I
> > recall the 316 was made of a lot of tiny cards.)
> >
> >> The MBB was "microprogrammable" and so we built the C/70 ... Alex/Dave:
> >> was any of the development of the C70 written up?
> >
> > I definitely read a document about the MBB. I have this vague memory
> that it was
> > hardcopy, but I doubt I'll be able to locate it anytime soon.
> >
> > ISTR that the MBB took a daughtercard, which implemented extra
> functionality,
> > and the C/70 took its own; I don't recall exactly what the C/70 one did,
> > though.
> >
> >    Noel
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From vint at google.com  Mon Mar 16 13:59:01 2020
From: vint at google.com (Vint Cerf)
Date: Mon, 16 Mar 2020 16:59:01 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
 <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
Message-ID: <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>

Thanks Andrew - that is consistent with my recollection (I used the C/30's
and C/50s for the MCI Mail backbone network). These machines
presented X.25/X.29/X.75 to the hosts connected to the network.

Did the C/70 really run "C" - surely C programs had to be compiled into
some kind of assembly language??

v


On Mon, Mar 16, 2020 at 4:37 PM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> I wrote both code and microcode for the C/30 IMP. We started by
> implementing a straight emulation of the Honeywell 316 architecture and
> instruction set so that we could port the existing IMP code pretty much
> untouched. Once that was working, we then conducted extensive performance
> testing to determine where the code was spending its time, and moved a
> number of expensive (from a CPU perspective) operations, such as queue
> handing and process scheduling, to the microcode. That also allowed us to
> make the queue handing instructions "atomic", which helped
> eliminate possible race conditions without requiring software semaphores
> and the like. We were able to really improve the IMP's forward capacity on
> the fast path though the use of microcode optimization. In the end, the
> C/30 IMP code looked very different from the original 316 code base, even
> though it was still in assembly language (what we now called "C/30
> assembly"). We had talked about porting the code base to C and compiling
> that down to C/30 assembly, but that never ended up happening.
>
> Cheers,
> Andy
>
>
> On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > Dear all,
> >
> > The C/30 and C/70 were discussed on this list in October 2017. I think I
> > recall from then that the MBB project got started because BBN had not
> done
> > a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
> > replacement for the 316/516.
> >
> > This is an excerpt from a message I posted back then:
> >
> > ====
> >
> > The MBB processor:
> >
> > The MBB processor is documented in this paper (available from the ACM
> > library, unfortunately behind a paywall):
> > M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
> > ?Design of a User-Microprogrammable Building Block? in Proceedings of the
> > 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
> > It is an interesting read and I can certainly recommend it; it also
> > discusses some aspects of the C/30 and C/70 configurations.
> >
> > The MBB processor seems to have been word (not byte) addressable, with 20
> > bit addresses and data paths. It is highly reminiscent of the Alto, with
> > I/O device controllers partially implemented in microcode. It is also
> > somewhat reminiscent of the TI990 and the later Sparc in that it had 1024
> > registers with a visible window of 16 registers. It is unique in that the
> > processor had two optional daughter boards to customise the system: (i) a
> > board to assist with macro-instruction decoding, (ii) an MMU board.
> >
> > The C/30 version seems to have had a macro-instruction daughter board,
> but
> > with addresses going straight through. When used as an IMP, some 30% of
> > microcycles seem to have gone on I/O processing and the remaining 70% on
> > executing H316 code.
> >
> > The C/70 version had both daughter boards. The MMU board divided the 1MW
> > address space into 128 pages of 4KW, and had protection & dirty bits per
> > page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is
> only
> > 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
> > Apparently, there was also a ?switch? (IMP?) version of the C/70, without
> > the MMU board and running a minimal OS (but using the ?C? microcode &
> > board).
> >
> > The C/70 seems to have implemented a load/store type architecture with 40
> > basic instructions, each offering one of 19 addressing modes in an
> > orthogonal setup. The 19 addressing modes were designed around typical C
> > data access operations. Next to that there were 44 specialised
> instructions.
> >
> > Procedure calls were very fast, as specialised instructions existed to
> > switch to a new register bank as part of the call, with spilling to main
> > memory upon deep recursion. Apparently it was possible for C code to
> ?call'
> > into microcode, and this may be how system calls were done.
> >
> > ====
> >
> > According to the paper mentioned above, it is all documented in detail in
> > the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
> > Unfortunately, this document does not seem to be available on the DTIC
> > website. Maybe this document still exists in the BBN (and successor)
> > library. As the topic comes up from time to time, maybe it could be added
> > to Bitsavers?
> >
> > BBN-UNIX for the C/70:
> >
> > This was a port of the V7 based Unix that BBN had running on the PDP11,
> > with various BSD-type extensions. It had the Gurwitz TCP/IP stack
> > integrated, and accessible via the VAX-TCP API (which was compatible with
> > the earlier NCP Unix API). It also had some of the earlier IPC features
> > (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is
> > available for study on TUHS
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet (note
> > how the code has #ifdef?s for VAX and MBB).
> >
> > Again from the discussion three years ago, I think this Unix version and
> > the C/30-C/70 were maintained into the late nineties by BBN.
> >
> > There was a commercial version of the C/70 (called the C/60) done by/for
> > the BBN computer division - see for instance this advert:
> >
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
> > <
> >
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
> > C/60&f=false>
> >
> > Paul
> >
> >
> > > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> > >
> > >
> > >> From: Bernie Cosell
> > >
> > >> The TIP was a 316 IMP with the terminal handling code in the upper 16K
> > >> of memory.  The C/30 was an implementation of the 316 on the MBB
> > >
> > > Any idea/recollection of why the 316 TIP hardware was ditched and
> > replaced
> > > with the C/30 for the TAC? Just to have more modern/maintainable
> > hardware? (I
> > > recall the 316 was made of a lot of tiny cards.)
> > >
> > >> The MBB was "microprogrammable" and so we built the C/70 ...
> Alex/Dave:
> > >> was any of the development of the C70 written up?
> > >
> > > I definitely read a document about the MBB. I have this vague memory
> > that it was
> > > hardcopy, but I doubt I'll be able to locate it anytime soon.
> > >
> > > ISTR that the MBB took a daughtercard, which implemented extra
> > functionality,
> > > and the C/70 took its own; I don't recall exactly what the C/70 one
> did,
> > > though.
> > >
> > >    Noel
> > >
> > > --
> > > Internet-history mailing list
> > > Internet-history at elists.isoc.org
> > > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


From bernie at fantasyfarm.com  Mon Mar 16 14:10:30 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 16 Mar 2020 17:10:30 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
 <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
 <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
Message-ID: <170e52f0970.2796.742cd0bcba90c1f7f640db99bf6503c5@fantasyfarm.com>

On March 16, 2020 16:59:23 Vint Cerf via Internet-history 
<internet-history at elists.isoc.org> wrote:

> Thanks Andrew - that is consistent with my recollection (I used the C/30's
> and C/50s for the MCI Mail backbone network). These machines
> presented X.25/X.29/X.75 to the hosts connected to the network.
>
> Did the C/70 really run "C" - surely C programs had to be compiled into
> some kind of assembly language??
i only vaguely recall, but i think the C compiler actual spit out
a binary file

/b\


                     Bernie Cosell
           bernie at fantasyfarm. com
? Too many people,  too few sheep ?


From agmalis at gmail.com  Mon Mar 16 14:14:34 2020
From: agmalis at gmail.com (Andrew G. Malis)
Date: Mon, 16 Mar 2020 17:14:34 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
 <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
 <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
Message-ID: <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>

Vint,

I wasn't close enough to the C/70 development to really know how it was
implemented, I was just a user. :-)

I also assume that the C/70 microcode implemented some sort of intermediate
assembly with built in support for C constructs like procedure calls and
data structures, but I don't know for sure.

Cheers,
Andy


On Mon, Mar 16, 2020 at 4:59 PM Vint Cerf <vint at google.com> wrote:

> Thanks Andrew - that is consistent with my recollection (I used the C/30's
> and C/50s for the MCI Mail backbone network). These machines
> presented X.25/X.29/X.75 to the hosts connected to the network.
>
> Did the C/70 really run "C" - surely C programs had to be compiled into
> some kind of assembly language??
>
> v
>
>
> On Mon, Mar 16, 2020 at 4:37 PM Andrew G. Malis via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> I wrote both code and microcode for the C/30 IMP. We started by
>> implementing a straight emulation of the Honeywell 316 architecture and
>> instruction set so that we could port the existing IMP code pretty much
>> untouched. Once that was working, we then conducted extensive performance
>> testing to determine where the code was spending its time, and moved a
>> number of expensive (from a CPU perspective) operations, such as queue
>> handing and process scheduling, to the microcode. That also allowed us to
>> make the queue handing instructions "atomic", which helped
>> eliminate possible race conditions without requiring software semaphores
>> and the like. We were able to really improve the IMP's forward capacity on
>> the fast path though the use of microcode optimization. In the end, the
>> C/30 IMP code looked very different from the original 316 code base, even
>> though it was still in assembly language (what we now called "C/30
>> assembly"). We had talked about porting the code base to C and compiling
>> that down to C/30 assembly, but that never ended up happening.
>>
>> Cheers,
>> Andy
>>
>>
>> On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>> > Dear all,
>> >
>> > The C/30 and C/70 were discussed on this list in October 2017. I think I
>> > recall from then that the MBB project got started because BBN had not
>> done
>> > a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
>> > replacement for the 316/516.
>> >
>> > This is an excerpt from a message I posted back then:
>> >
>> > ====
>> >
>> > The MBB processor:
>> >
>> > The MBB processor is documented in this paper (available from the ACM
>> > library, unfortunately behind a paywall):
>> > M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
>> > ?Design of a User-Microprogrammable Building Block? in Proceedings of
>> the
>> > 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
>> > It is an interesting read and I can certainly recommend it; it also
>> > discusses some aspects of the C/30 and C/70 configurations.
>> >
>> > The MBB processor seems to have been word (not byte) addressable, with
>> 20
>> > bit addresses and data paths. It is highly reminiscent of the Alto, with
>> > I/O device controllers partially implemented in microcode. It is also
>> > somewhat reminiscent of the TI990 and the later Sparc in that it had
>> 1024
>> > registers with a visible window of 16 registers. It is unique in that
>> the
>> > processor had two optional daughter boards to customise the system: (i)
>> a
>> > board to assist with macro-instruction decoding, (ii) an MMU board.
>> >
>> > The C/30 version seems to have had a macro-instruction daughter board,
>> but
>> > with addresses going straight through. When used as an IMP, some 30% of
>> > microcycles seem to have gone on I/O processing and the remaining 70% on
>> > executing H316 code.
>> >
>> > The C/70 version had both daughter boards. The MMU board divided the 1MW
>> > address space into 128 pages of 4KW, and had protection & dirty bits per
>> > page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is
>> only
>> > 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
>> > Apparently, there was also a ?switch? (IMP?) version of the C/70,
>> without
>> > the MMU board and running a minimal OS (but using the ?C? microcode &
>> > board).
>> >
>> > The C/70 seems to have implemented a load/store type architecture with
>> 40
>> > basic instructions, each offering one of 19 addressing modes in an
>> > orthogonal setup. The 19 addressing modes were designed around typical C
>> > data access operations. Next to that there were 44 specialised
>> instructions.
>> >
>> > Procedure calls were very fast, as specialised instructions existed to
>> > switch to a new register bank as part of the call, with spilling to main
>> > memory upon deep recursion. Apparently it was possible for C code to
>> ?call'
>> > into microcode, and this may be how system calls were done.
>> >
>> > ====
>> >
>> > According to the paper mentioned above, it is all documented in detail
>> in
>> > the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
>> > Unfortunately, this document does not seem to be available on the DTIC
>> > website. Maybe this document still exists in the BBN (and successor)
>> > library. As the topic comes up from time to time, maybe it could be
>> added
>> > to Bitsavers?
>> >
>> > BBN-UNIX for the C/70:
>> >
>> > This was a port of the V7 based Unix that BBN had running on the PDP11,
>> > with various BSD-type extensions. It had the Gurwitz TCP/IP stack
>> > integrated, and accessible via the VAX-TCP API (which was compatible
>> with
>> > the earlier NCP Unix API). It also had some of the earlier IPC features
>> > (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is
>> > available for study on TUHS
>> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet (note
>> > how the code has #ifdef?s for VAX and MBB).
>> >
>> > Again from the discussion three years ago, I think this Unix version and
>> > the C/30-C/70 were maintained into the late nineties by BBN.
>> >
>> > There was a commercial version of the C/70 (called the C/60) done by/for
>> > the BBN computer division - see for instance this advert:
>> >
>> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
>> > <
>> >
>> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
>> > C/60&f=false>
>> >
>> > Paul
>> >
>> >
>> > > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
>> > internet-history at elists.isoc.org> wrote:
>> > >
>> > >
>> > >> From: Bernie Cosell
>> > >
>> > >> The TIP was a 316 IMP with the terminal handling code in the upper
>> 16K
>> > >> of memory.  The C/30 was an implementation of the 316 on the MBB
>> > >
>> > > Any idea/recollection of why the 316 TIP hardware was ditched and
>> > replaced
>> > > with the C/30 for the TAC? Just to have more modern/maintainable
>> > hardware? (I
>> > > recall the 316 was made of a lot of tiny cards.)
>> > >
>> > >> The MBB was "microprogrammable" and so we built the C/70 ...
>> Alex/Dave:
>> > >> was any of the development of the C70 written up?
>> > >
>> > > I definitely read a document about the MBB. I have this vague memory
>> > that it was
>> > > hardcopy, but I doubt I'll be able to locate it anytime soon.
>> > >
>> > > ISTR that the MBB took a daughtercard, which implemented extra
>> > functionality,
>> > > and the C/70 took its own; I don't recall exactly what the C/70 one
>> did,
>> > > though.
>> > >
>> > >    Noel
>> > >
>> > > --
>> > > Internet-history mailing list
>> > > Internet-history at elists.isoc.org
>> > > https://elists.isoc.org/mailman/listinfo/internet-history
>> >
>> > --
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> >
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
>


From vgcerf at gmail.com  Mon Mar 16 14:48:45 2020
From: vgcerf at gmail.com (vinton cerf)
Date: Mon, 16 Mar 2020 17:48:45 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
 <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
 <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
 <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>
Message-ID: <CAAFtm_V_HB+bpKCnh9vZnvEj1B9R+Sw=X5tfoPmK90gqm2yhcA@mail.gmail.com>

that makes more sense than running native "C" code!!!

v


On Mon, Mar 16, 2020 at 5:14 PM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Vint,
>
> I wasn't close enough to the C/70 development to really know how it was
> implemented, I was just a user. :-)
>
> I also assume that the C/70 microcode implemented some sort of intermediate
> assembly with built in support for C constructs like procedure calls and
> data structures, but I don't know for sure.
>
> Cheers,
> Andy
>
>
> On Mon, Mar 16, 2020 at 4:59 PM Vint Cerf <vint at google.com> wrote:
>
> > Thanks Andrew - that is consistent with my recollection (I used the
> C/30's
> > and C/50s for the MCI Mail backbone network). These machines
> > presented X.25/X.29/X.75 to the hosts connected to the network.
> >
> > Did the C/70 really run "C" - surely C programs had to be compiled into
> > some kind of assembly language??
> >
> > v
> >
> >
> > On Mon, Mar 16, 2020 at 4:37 PM Andrew G. Malis via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> I wrote both code and microcode for the C/30 IMP. We started by
> >> implementing a straight emulation of the Honeywell 316 architecture and
> >> instruction set so that we could port the existing IMP code pretty much
> >> untouched. Once that was working, we then conducted extensive
> performance
> >> testing to determine where the code was spending its time, and moved a
> >> number of expensive (from a CPU perspective) operations, such as queue
> >> handing and process scheduling, to the microcode. That also allowed us
> to
> >> make the queue handing instructions "atomic", which helped
> >> eliminate possible race conditions without requiring software semaphores
> >> and the like. We were able to really improve the IMP's forward capacity
> on
> >> the fast path though the use of microcode optimization. In the end, the
> >> C/30 IMP code looked very different from the original 316 code base,
> even
> >> though it was still in assembly language (what we now called "C/30
> >> assembly"). We had talked about porting the code base to C and compiling
> >> that down to C/30 assembly, but that never ended up happening.
> >>
> >> Cheers,
> >> Andy
> >>
> >>
> >> On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
> >> internet-history at elists.isoc.org> wrote:
> >>
> >> > Dear all,
> >> >
> >> > The C/30 and C/70 were discussed on this list in October 2017. I
> think I
> >> > recall from then that the MBB project got started because BBN had not
> >> done
> >> > a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
> >> > replacement for the 316/516.
> >> >
> >> > This is an excerpt from a message I posted back then:
> >> >
> >> > ====
> >> >
> >> > The MBB processor:
> >> >
> >> > The MBB processor is documented in this paper (available from the ACM
> >> > library, unfortunately behind a paywall):
> >> > M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
> >> > ?Design of a User-Microprogrammable Building Block? in Proceedings of
> >> the
> >> > 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
> >> > It is an interesting read and I can certainly recommend it; it also
> >> > discusses some aspects of the C/30 and C/70 configurations.
> >> >
> >> > The MBB processor seems to have been word (not byte) addressable, with
> >> 20
> >> > bit addresses and data paths. It is highly reminiscent of the Alto,
> with
> >> > I/O device controllers partially implemented in microcode. It is also
> >> > somewhat reminiscent of the TI990 and the later Sparc in that it had
> >> 1024
> >> > registers with a visible window of 16 registers. It is unique in that
> >> the
> >> > processor had two optional daughter boards to customise the system:
> (i)
> >> a
> >> > board to assist with macro-instruction decoding, (ii) an MMU board.
> >> >
> >> > The C/30 version seems to have had a macro-instruction daughter board,
> >> but
> >> > with addresses going straight through. When used as an IMP, some 30%
> of
> >> > microcycles seem to have gone on I/O processing and the remaining 70%
> on
> >> > executing H316 code.
> >> >
> >> > The C/70 version had both daughter boards. The MMU board divided the
> 1MW
> >> > address space into 128 pages of 4KW, and had protection & dirty bits
> per
> >> > page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is
> >> only
> >> > 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
> >> > Apparently, there was also a ?switch? (IMP?) version of the C/70,
> >> without
> >> > the MMU board and running a minimal OS (but using the ?C? microcode &
> >> > board).
> >> >
> >> > The C/70 seems to have implemented a load/store type architecture with
> >> 40
> >> > basic instructions, each offering one of 19 addressing modes in an
> >> > orthogonal setup. The 19 addressing modes were designed around
> typical C
> >> > data access operations. Next to that there were 44 specialised
> >> instructions.
> >> >
> >> > Procedure calls were very fast, as specialised instructions existed to
> >> > switch to a new register bank as part of the call, with spilling to
> main
> >> > memory upon deep recursion. Apparently it was possible for C code to
> >> ?call'
> >> > into microcode, and this may be how system calls were done.
> >> >
> >> > ====
> >> >
> >> > According to the paper mentioned above, it is all documented in detail
> >> in
> >> > the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
> >> > Unfortunately, this document does not seem to be available on the DTIC
> >> > website. Maybe this document still exists in the BBN (and successor)
> >> > library. As the topic comes up from time to time, maybe it could be
> >> added
> >> > to Bitsavers?
> >> >
> >> > BBN-UNIX for the C/70:
> >> >
> >> > This was a port of the V7 based Unix that BBN had running on the
> PDP11,
> >> > with various BSD-type extensions. It had the Gurwitz TCP/IP stack
> >> > integrated, and accessible via the VAX-TCP API (which was compatible
> >> with
> >> > the earlier NCP Unix API). It also had some of the earlier IPC
> features
> >> > (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is
> >> > available for study on TUHS
> >> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet
> (note
> >> > how the code has #ifdef?s for VAX and MBB).
> >> >
> >> > Again from the discussion three years ago, I think this Unix version
> and
> >> > the C/30-C/70 were maintained into the late nineties by BBN.
> >> >
> >> > There was a commercial version of the C/70 (called the C/60) done
> by/for
> >> > the BBN computer division - see for instance this advert:
> >> >
> >>
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
> >> > <
> >> >
> >>
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
> >> > C/60&f=false>
> >> >
> >> > Paul
> >> >
> >> >
> >> > > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
> >> > internet-history at elists.isoc.org> wrote:
> >> > >
> >> > >
> >> > >> From: Bernie Cosell
> >> > >
> >> > >> The TIP was a 316 IMP with the terminal handling code in the upper
> >> 16K
> >> > >> of memory.  The C/30 was an implementation of the 316 on the MBB
> >> > >
> >> > > Any idea/recollection of why the 316 TIP hardware was ditched and
> >> > replaced
> >> > > with the C/30 for the TAC? Just to have more modern/maintainable
> >> > hardware? (I
> >> > > recall the 316 was made of a lot of tiny cards.)
> >> > >
> >> > >> The MBB was "microprogrammable" and so we built the C/70 ...
> >> Alex/Dave:
> >> > >> was any of the development of the C70 written up?
> >> > >
> >> > > I definitely read a document about the MBB. I have this vague memory
> >> > that it was
> >> > > hardcopy, but I doubt I'll be able to locate it anytime soon.
> >> > >
> >> > > ISTR that the MBB took a daughtercard, which implemented extra
> >> > functionality,
> >> > > and the C/70 took its own; I don't recall exactly what the C/70 one
> >> did,
> >> > > though.
> >> > >
> >> > >    Noel
> >> > >
> >> > > --
> >> > > Internet-history mailing list
> >> > > Internet-history at elists.isoc.org
> >> > > https://elists.isoc.org/mailman/listinfo/internet-history
> >> >
> >> > --
> >> > Internet-history mailing list
> >> > Internet-history at elists.isoc.org
> >> > https://elists.isoc.org/mailman/listinfo/internet-history
> >> >
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > Reston, VA 20190
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From clemc at ccc.com  Mon Mar 16 15:05:20 2020
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Mar 2020 18:05:20 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>
 <278421CC-8AAF-4DE3-AC1C-48BEBBCBEB54@planet.nl>
 <CAA=duU0LMcDfSxpMggYwWrnYhbv4bXXukVwOQ+_4vxjH2sag=w@mail.gmail.com>
 <CAHxHggd7m7oid9WwtsugHsph_FrtVbEGDJWJVaJi9heBAg1_kQ@mail.gmail.com>
 <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>
Message-ID: <CAC20D2O59Ww3Nt1Gck6CdBC70YSyy06LASFedKnfnQ8m-XFrEA@mail.gmail.com>

Yes, there was a simple instruction set.  I once had a C manual for it, I
don't think I kept it.  I remember it had a lot of registers, which
compared to the PDP-11 was a big deal for C.  There were some high-level
instructions like CSAV and CRET instruction like the PDP-11/40E.  I don't
remember completely, but I think it lacked the ton of addressing modes
that the PDP-11 and later 68K supported.  For some reason, I do think I
remember that it had auto-increment and decrement, although I may be
confusing/mixing it up with the 68K.

IIRC at the time, the Vaxen were going for about $500K-750K and PDP-11/70s
'well equipped' about $300K-450K.  BBN was trying to sell them to the same
folks that wanted were looking at 11/70's but since it was a 20bit machine,
the C/70s did not have many of the limits that 11's did.   The price was
about $150K-250K if I remember correctly.

I've long since lost the document, but when BBN created the C Machine, they
had the traditional marketing materials.   I remember after Al Nemeth gave
a talk about it at USENIX.  After I got back, I remember calling BBN to get
information sent to us at Tektronix.  I remember seeing a wonderful typo in
the material that I have never forgotten, but the doc folks were
highlighting the wonderful *'resistor to resistor'* instructions that it
supported.

Clem

On Mon, Mar 16, 2020 at 5:14 PM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Vint,
>
> I wasn't close enough to the C/70 development to really know how it was
> implemented, I was just a user. :-)
>
> I also assume that the C/70 microcode implemented some sort of intermediate
> assembly with built in support for C constructs like procedure calls and
> data structures, but I don't know for sure.
>
> Cheers,
> Andy
>
>
> On Mon, Mar 16, 2020 at 4:59 PM Vint Cerf <vint at google.com> wrote:
>
> > Thanks Andrew - that is consistent with my recollection (I used the
> C/30's
> > and C/50s for the MCI Mail backbone network). These machines
> > presented X.25/X.29/X.75 to the hosts connected to the network.
> >
> > Did the C/70 really run "C" - surely C programs had to be compiled into
> > some kind of assembly language??
> >
> > v
> >
> >
> > On Mon, Mar 16, 2020 at 4:37 PM Andrew G. Malis via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> I wrote both code and microcode for the C/30 IMP. We started by
> >> implementing a straight emulation of the Honeywell 316 architecture and
> >> instruction set so that we could port the existing IMP code pretty much
> >> untouched. Once that was working, we then conducted extensive
> performance
> >> testing to determine where the code was spending its time, and moved a
> >> number of expensive (from a CPU perspective) operations, such as queue
> >> handing and process scheduling, to the microcode. That also allowed us
> to
> >> make the queue handing instructions "atomic", which helped
> >> eliminate possible race conditions without requiring software semaphores
> >> and the like. We were able to really improve the IMP's forward capacity
> on
> >> the fast path though the use of microcode optimization. In the end, the
> >> C/30 IMP code looked very different from the original 316 code base,
> even
> >> though it was still in assembly language (what we now called "C/30
> >> assembly"). We had talked about porting the code base to C and compiling
> >> that down to C/30 assembly, but that never ended up happening.
> >>
> >> Cheers,
> >> Andy
> >>
> >>
> >> On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
> >> internet-history at elists.isoc.org> wrote:
> >>
> >> > Dear all,
> >> >
> >> > The C/30 and C/70 were discussed on this list in October 2017. I
> think I
> >> > recall from then that the MBB project got started because BBN had not
> >> done
> >> > a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
> >> > replacement for the 316/516.
> >> >
> >> > This is an excerpt from a message I posted back then:
> >> >
> >> > ====
> >> >
> >> > The MBB processor:
> >> >
> >> > The MBB processor is documented in this paper (available from the ACM
> >> > library, unfortunately behind a paywall):
> >> > M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
> >> > ?Design of a User-Microprogrammable Building Block? in Proceedings of
> >> the
> >> > 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
> >> > It is an interesting read and I can certainly recommend it; it also
> >> > discusses some aspects of the C/30 and C/70 configurations.
> >> >
> >> > The MBB processor seems to have been word (not byte) addressable, with
> >> 20
> >> > bit addresses and data paths. It is highly reminiscent of the Alto,
> with
> >> > I/O device controllers partially implemented in microcode. It is also
> >> > somewhat reminiscent of the TI990 and the later Sparc in that it had
> >> 1024
> >> > registers with a visible window of 16 registers. It is unique in that
> >> the
> >> > processor had two optional daughter boards to customise the system:
> (i)
> >> a
> >> > board to assist with macro-instruction decoding, (ii) an MMU board.
> >> >
> >> > The C/30 version seems to have had a macro-instruction daughter board,
> >> but
> >> > with addresses going straight through. When used as an IMP, some 30%
> of
> >> > microcycles seem to have gone on I/O processing and the remaining 70%
> on
> >> > executing H316 code.
> >> >
> >> > The C/70 version had both daughter boards. The MMU board divided the
> 1MW
> >> > address space into 128 pages of 4KW, and had protection & dirty bits
> per
> >> > page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is
> >> only
> >> > 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
> >> > Apparently, there was also a ?switch? (IMP?) version of the C/70,
> >> without
> >> > the MMU board and running a minimal OS (but using the ?C? microcode &
> >> > board).
> >> >
> >> > The C/70 seems to have implemented a load/store type architecture with
> >> 40
> >> > basic instructions, each offering one of 19 addressing modes in an
> >> > orthogonal setup. The 19 addressing modes were designed around
> typical C
> >> > data access operations. Next to that there were 44 specialised
> >> instructions.
> >> >
> >> > Procedure calls were very fast, as specialised instructions existed to
> >> > switch to a new register bank as part of the call, with spilling to
> main
> >> > memory upon deep recursion. Apparently it was possible for C code to
> >> ?call'
> >> > into microcode, and this may be how system calls were done.
> >> >
> >> > ====
> >> >
> >> > According to the paper mentioned above, it is all documented in detail
> >> in
> >> > the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
> >> > Unfortunately, this document does not seem to be available on the DTIC
> >> > website. Maybe this document still exists in the BBN (and successor)
> >> > library. As the topic comes up from time to time, maybe it could be
> >> added
> >> > to Bitsavers?
> >> >
> >> > BBN-UNIX for the C/70:
> >> >
> >> > This was a port of the V7 based Unix that BBN had running on the
> PDP11,
> >> > with various BSD-type extensions. It had the Gurwitz TCP/IP stack
> >> > integrated, and accessible via the VAX-TCP API (which was compatible
> >> with
> >> > the earlier NCP Unix API). It also had some of the earlier IPC
> features
> >> > (Haverty?s await() and capac() calls, ports, etc.). That TCP stack is
> >> > available for study on TUHS
> >> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet
> (note
> >> > how the code has #ifdef?s for VAX and MBB).
> >> >
> >> > Again from the discussion three years ago, I think this Unix version
> and
> >> > the C/30-C/70 were maintained into the late nineties by BBN.
> >> >
> >> > There was a commercial version of the C/70 (called the C/60) done
> by/for
> >> > the BBN computer division - see for instance this advert:
> >> >
> >>
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
> >> > <
> >> >
> >>
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
> >> > C/60&f=false>
> >> >
> >> > Paul
> >> >
> >> >
> >> > > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
> >> > internet-history at elists.isoc.org> wrote:
> >> > >
> >> > >
> >> > >> From: Bernie Cosell
> >> > >
> >> > >> The TIP was a 316 IMP with the terminal handling code in the upper
> >> 16K
> >> > >> of memory.  The C/30 was an implementation of the 316 on the MBB
> >> > >
> >> > > Any idea/recollection of why the 316 TIP hardware was ditched and
> >> > replaced
> >> > > with the C/30 for the TAC? Just to have more modern/maintainable
> >> > hardware? (I
> >> > > recall the 316 was made of a lot of tiny cards.)
> >> > >
> >> > >> The MBB was "microprogrammable" and so we built the C/70 ...
> >> Alex/Dave:
> >> > >> was any of the development of the C70 written up?
> >> > >
> >> > > I definitely read a document about the MBB. I have this vague memory
> >> > that it was
> >> > > hardcopy, but I doubt I'll be able to locate it anytime soon.
> >> > >
> >> > > ISTR that the MBB took a daughtercard, which implemented extra
> >> > functionality,
> >> > > and the C/70 took its own; I don't recall exactly what the C/70 one
> >> did,
> >> > > though.
> >> > >
> >> > >    Noel
> >> > >
> >> > > --
> >> > > Internet-history mailing list
> >> > > Internet-history at elists.isoc.org
> >> > > https://elists.isoc.org/mailman/listinfo/internet-history
> >> >
> >> > --
> >> > Internet-history mailing list
> >> > Internet-history at elists.isoc.org
> >> > https://elists.isoc.org/mailman/listinfo/internet-history
> >> >
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
> >
> > --
> > New postal address:
> > Google
> > 1875 Explorer Street, 10th Floor
> > Reston, VA 20190
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


From bernie at fantasyfarm.com  Mon Mar 16 15:49:10 2020
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Mon, 16 Mar 2020 18:49:10 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <CAAFtm_V_HB+bpKCnh9vZnvEj1B9R+Sw=X5tfoPmK90gqm2yhcA@mail.gmail.com>
References: <20200316182857.B147E18C08F@mercury.lcs.mit.edu>,
 <CAA=duU1FJ3GDC-zf2SNRrXpw9GAsf41BoBGBwPuDd30hkAPnzw@mail.gmail.com>,
 <CAAFtm_V_HB+bpKCnh9vZnvEj1B9R+Sw=X5tfoPmK90gqm2yhcA@mail.gmail.com>
Message-ID: <5E700266.9986.4594FF80@bernie.fantasyfarm.com>

On 16 Mar 2020 at 17:48, vinton cerf via Internet-hist wrote:

> On Mon, Mar 16, 2020 at 5:14 PM Andrew G. Malis via Internet-history <
> internet-history at elists.isoc.org> wrote:

> > I also assume that the C/70 microcode implemented some sort of
> intermediate
> > assembly with built in support for C constructs like procedure calls
> and
> > data structures, but I don't know for sure.

> that makes more sense than running native "C" code!!!


That's right.  The nature of the "instruction set" of the c/70 made it relatively easy 
to generate the "machine code" for C programs and it was assembled by a VERY 
simple assembler.  And, indeed, the microcode that Carl set up made it relatively 
easy to do most of the C constructs.

The tricky stuff came in the optimizations - in knowing that if you did a 
load-indexed-indirect and the index was small enough you could use the special 
instruction, but if it was larger than that you had to dosomething fancier.  Similar 
to what I mentioned with the subroutine call: zero or one args used one 
instruction and more than that used a different mechanism.  I don't remember 
exactly but I'm pretty sure I had the compiler optimize "switch" statements: it had 
three things it could do: if/then/else chain, dispatch table, or a hash table. and it 
picked the best one for the set of switch-keys.

As I recall, it also used a kind of hamming code for the actual instruction codes 
[is that term right, my ancient mind is foggy]: that is the thing had a variable size 
"opcode" field and so we used more bits for the "opcode" for some instructions 
and fewer bits for others.   for example, [NB I'm kinda making this up but the 
idea is right} : consider load immediate.  It takes three fields: opcode register 
constant.   Al figured out the optimal number of bits for the "constant" field, the 
register field was what it was, and the rest could be used for the opcode, so that 
pushed it somewhere down the opcode tree.   In the compiler, when it needed to 
do a "load immidiate" it *knew* whether the immediate part could fit in the 
instruction or whether it had to come from somewhere else.   My opinion [dunno 
about al or carl, or anyone else who has messed with the 'assembler' back end] is 
that it'd drive a programmer *nuts* to keep track of this operation allows nine-bit 
field, but this other allows a 15 bit field, etc.

  /B\


            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --
   





From louie at transsys.com  Mon Mar 16 19:07:04 2020
From: louie at transsys.com (Louis Mamakos)
Date: Mon, 16 Mar 2020 22:07:04 -0400
Subject: [ih] NCP and TCP implementations
In-Reply-To: <530756142.1460705.1584380602454@mail.yahoo.com>
References: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
 <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>
 <530756142.1460705.1584380602454@mail.yahoo.com>
Message-ID: <60C7873D-C943-4ED1-87A1-876AC5D770C3@transsys.com>

For what it's worth, while I was at the University of Maryland, we got 
one
of the later batches of C/30 IMPs with X.25 host interfaces as part of 
the
NSFNET interconnection project.  It sure looked "new" when it arrived, 
vs.
having been shipped from some other site, so I presume it a relatively
recent version.

Now, I know that there were other IMP networks besides MILNET and 
ARPANET
so maybe other flavors existed in those.  However, I believe that the
NSFNET interconnection project with the ARPANET was probably near the 
end
of any ARPANET expansion.

Then there were the Butterfly gateways, an entirely different beast and 
not
based on C/70 from what I remember.  I think they might have been 68K
multiprocessor systems?

Louis Mamakos


On 16 Mar 2020, at 13:43, Alex McKenzie via Internet-history wrote:

>  Bernie et al,
> I am quite sure that the C/70 never ran the IMP code.
> The MBB was probably funded by ARPA and its development was (I think) 
> recorded in BBN QTRs to ARPA and definitely in other BBN Technical 
> Reports.? But I think the C/70 was a BBN internal (self funded) 
> project and (I think) was not in QTRs.? I do think there was at least 
> one technical paper about the C/70 given at a conference but I can't 
> find any reference, so perhaps not.
> Alex
>
>     On Monday, March 16, 2020, 1:28:21 PM EDT, Bernie Cosell via 
> Internet-history <internet-history at elists.isoc.org> wrote:
>
>  On 16 Mar 2020 at 12:31, Noel Chiappa via Internet-history wrote:
>
>> Anyway, on to what I wanted to comment on:
>>
>>
>> ? ? > From: Geoff Goodfellow
>>
>> ? ? > for some reason when the C/70's came along, TIP's were 
>> renamed to
>> TAC's
>>
>> IIRC, the C/70's were timesharing machines (running Unix, IITC); the
>> C/
>> machines which were packet switches (IMPs), terminal concentators 
>> (TACs)
>> etc
>> were C/30's. I note from the host tables that the TIP's all seem to 
>> have
>> been
>> H316's, and all TAC's were C/30's.
>
> You're correct.? The TIP was a 316 IMP with the terminal handling 
> code in the
> upper 16K of memory.? The C/30 was an implementation of the 316 on 
> the MBB
> [Microprogrammable Building Block] that BBN had developed.? I have no 
> idea
> about why it was "/30".? The MBB was "microprogrammable" and so we 
> built the
> C/70 -- it was called the "C machine" and the idea what that "C" was 
> its assembly
> language.? I have no idea how that project got started but three of 
> us were
> working on it: Al Nemeth was hacking the Unix kernel,? Carl Howe did 
> the
> microcode and I did a crosscompiler from TENEX to the MBB.
>
> I think it was tagged the "C/70" because it was intended to run Unix 
> as well as an
> 11/70 [in practice it worked out to be MUCH faster].? the MBB had 20 
> bit words
> and Al and Carl were designing a hand-tuned, irregular "instruction 
> set".? Such
> things as a built-in indirect index: he figured out the optimal size 
> of the offset
> field so that referencing part of a 'struct' through a pointer could 
> be done in a
> single instruction not using a register.
>
> There was *NO* regularity to the "instruction set" -- each instruction 
> carved up
> the 20 available bits as seemed most efficient.? We added new/strange
> instructions as we saw fit [e.g.,: Al noticed that almost all 
> subroutine calls in the
> kernel were either zero or one argument calls, and so we had two call
> instructions: the normal one [push push push <call>] and one that 
> *always*
> pushed ONE arg and called in a single instruction.? I had the fun 
> task of putting
> together a C cross compiler running on a 36 bit machine for a 
> 20-bit-word
> machine to handle all that irregularity.
>
> We eventually got the kernel working [with the underlying "instruction 
> set"
> constantly evolving as Al looked at the code the compiler was 
> producing and
> figuring ways to tweak things to make it faster.? Carl and I mostly 
> kept up.? The
> big day [for me, at least] was when I ported the C compiler I"d been 
> working on
> to run natively on the MBB [which involved taking out the 36-bit-ness 
> and
> replacing it with 20-bit-ness].? The Unix kernel compiled on the 
> MBB? and was
> bit-for-bit the same as the image produced on TENEX and we cut the 
> strings to
> TENEX and it was now running solo.? That was pretty much when i left 
> the
> project:? I have no idea [at least no memory] what happened after 
> that [some of
> you might have guessed that I was a bit of a vagabond 
> jack-of-all-trades at BBN: I
> worked on one project or another, got it working and "released" and 
> then I went
> onto the next thing].? I don't remember what *we* called it, but 
> shortly after we
> got it all working it went over to BBNCC and was marketed as the 
> "C/70"
>
> I don't remember its ever running the IMP code.? Alex/Dave: was any 
> of the
> development of the C70 written up?? I wasn't much on writing reports 
> :o)
>
> ? /Bernie\
>
>
>
> ? ? ? ? ? ? Bernie Cosell
> ? ? ? bernie at fantasyfarm.com
> -- Too many people; too few sheep --
> ?
>
>
>
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history


From bob.hinden at gmail.com  Wed Mar 18 18:07:04 2020
From: bob.hinden at gmail.com (Bob Hinden)
Date: Wed, 18 Mar 2020 18:07:04 -0700
Subject: [ih] NCP and TCP implementations
In-Reply-To: <60C7873D-C943-4ED1-87A1-876AC5D770C3@transsys.com>
References: <20200316163134.5F99918C08F@mercury.lcs.mit.edu>
 <5E6FB70B.2366.446EA5DD@bernie.fantasyfarm.com>
 <530756142.1460705.1584380602454@mail.yahoo.com>
 <60C7873D-C943-4ED1-87A1-876AC5D770C3@transsys.com>
Message-ID: <61D9EBEE-646B-4B51-8F69-F96A06091341@gmail.com>

Louis,

> On Mar 16, 2020, at 7:07 PM, Louis Mamakos via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> ?.
> 
> Then there were the Butterfly gateways, an entirely different beast and not
> based on C/70 from what I remember.  I think they might have been 68K
> multiprocessor systems?

That is correct, it was not related to the C/70, and the processor was some flavor of Motorola 68K processor.

Bob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20200318/0a718773/attachment.asc>

From geoff at iconia.com  Sat Mar 21 22:55:28 2020
From: geoff at iconia.com (the keyboard of geoff goodfellow)
Date: Sat, 21 Mar 2020 19:55:28 -1000
Subject: [ih] "Installing TCP and servers" on Tenex memo (William W. Plummer
 - 19SEP76)
Message-ID: <CAEf-zrjDOqo6QxZGKFXzy9-Fyu_gG-oxc79mJrrbsGSHxjfb_Q@mail.gmail.com>

in poking around an "ancient" archive of files -- just uncovered this "gem":

To:	System Programmers
From:	William W. Plummer, BBN
Date:	19SEP76

Re:	Installing TCP and servers


1.	Make a directory <TCP> to hold all of the files.

2.	If the TCP and servers are to be run by <SYSTEM> or <TCP> or
	whoever, give that user WHEEL (so it can use PTY's in their
	current partially implemented form) and NETWIZ (so it can
	use raw network messages.

3.	Add the TCP assembly switch to PARAMS.MAC.  See partial
	listing.

4.	Add code under TCP switch in FORKS.MAC.  See partial listing.

5.	Add directed PSI code in IMPDV.MAC.  See partial listing.

6.	Define FORKX as JSYS 747 in STENEX.MAC.  Reassemble STENEX.

7.	Define FORKX in PROLOG.MAC.  Delete LDINIT.REL;* to cause the
	JSYS dispatch vector to be reassembled.

8.	In PARAMS.MAC  set NPTYS to 8.  Figure out what line numbers
	your PTY's will be for later use.

9.	Be sure your CHKJFN routine matches the one enclosed.  Same
	for other PTY-related fragments enclosed.

10.	Assemble a new monitor.

11.	A copy of the file <SYSTEM>SYSJOB.TCP is included here which
	should be updated for your system.  To restart the TCP after
	flushing the old jobs, just copy this file to
	<SYSTEM>SYSJOB.COMMANDS and Job0 will do the rest.

12.	To have the TCP started automatically when the system comes
	up, include the contents of SYSJOB.TCP in SYSJOB.RUN.


13.	You may want to have a separate account and pieslice for the
	TCP.

14.	Files and what they do:

	<TCP>TCP155.SAV		Contains all code for the TCP job and
				interface (simulated JSYS's) for users.

	<TCP>TTLSRV.MAC		Sources for "TCP Telnet Server".
	<TCP>TTLSRV.SAV		The actual program.
	<TCP>TTLSRV.LOG		Textual log of activities.

	<TCP>ECHO.SAV		An echo server.
	<TCP>ECHO.LOG		A log file.

	<TCP>SINK.SAV		InterNet version of NIL:
	<TCP>SINK.LOG		Textual log file.

	<TCP>XTCP155.SAV	Used to map the TCP for debugging.
	<TCP>XTCI155.SAV	Used to map the TCI

	<TCP>START-TCP155.SAV	Program run by a created job to cause
				a TCP to be mapped and started.

	<TCP>START-TTLSRV155.SAV	Program run by a created job to
					cause the TTLSRV to be started.

	<TCP>START-ECHO.SAV		Program run by a created job to
					start the ECHO server.

	<TCP>START-SINK.SAV		Program run by a created job to
					start the SINK server.


15.	A word about TCP155.SAV

	This is a specially constructed SSAVE file.  Parts are "normal"
Read, Copy-on-write, Execute while others are actual shared Read-Write.
This file may be copied with the EXEC "COPY" command and may be
shipped around with FTP, but don't try to GET and SSAVE it. Don't
try to just RUN it.  In order for the GET JSYS to properly map the
file, it must be openned with "per-page table" access.  That is all
XTCP155 and XTCI155 do: open the file, do a GET and HALTF.  The
EXEC "START" command may then be used.  Programs like START-TCP155
do the same but automatically start the program.

	TCP is the actual protocol routines, the packetizer, the
retransmitter, the reassembler, ... etc.


-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True
http://geoff.livejournal.com


From lars at nocrew.org  Sat Mar 21 23:35:52 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 22 Mar 2020 06:35:52 +0000
Subject: [ih] "Installing TCP and servers" on Tenex memo (William W.
 Plummer - 19SEP76)
In-Reply-To: <CAEf-zrjDOqo6QxZGKFXzy9-Fyu_gG-oxc79mJrrbsGSHxjfb_Q@mail.gmail.com>
 (the keyboard of geoff goodfellow via Internet-history's message of
 "Sat, 21 Mar 2020 19:55:28 -1000")
References: <CAEf-zrjDOqo6QxZGKFXzy9-Fyu_gG-oxc79mJrrbsGSHxjfb_Q@mail.gmail.com>
Message-ID: <7wa748522f.fsf@junk.nocrew.org>

That's great, thanks!  I'd like to see Tenex running again, with TCP
and/or NCP.


From johnl at iecc.com  Sun Mar 22 08:16:03 2020
From: johnl at iecc.com (John Levine)
Date: 22 Mar 2020 11:16:03 -0400
Subject: [ih] "Installing TCP and servers" on Tenex memo (William W.
 Plummer - 19SEP76)
In-Reply-To: <7wa748522f.fsf@junk.nocrew.org>
Message-ID: <20200322151603.D59661660F51@ary.qy>

In article <7wa748522f.fsf at junk.nocrew.org> you write:
>That's great, thanks!  I'd like to see Tenex running again, with TCP
>and/or NCP.

If TOPS-20 will do, see https://sdf.org/twenex/



From steve at shinkuro.com  Mon Mar 16 16:21:48 2020
From: steve at shinkuro.com (Steve Crocker)
Date: Mon, 16 Mar 2020 23:21:48 -0000
Subject: [ih] Deep dive into the C/30 microcode
In-Reply-To: <E9069AF2-E4B3-4581-8ABB-8833E5D736B6@shinkuro.com>
References: <E9069AF2-E4B3-4581-8ABB-8833E5D736B6@shinkuro.com>
Message-ID: <CABf5zvKaw8w635249BzRFK1d0UbPmgmOqE-xCBACuFD2ohGkhg@mail.gmail.com>

In the mid 1980s I was working on formal proof techniques for microcode.
We used the C/30 microcode as our  "object of affection."  That is, we
wrote formal descriptions of both MBB and the C/30 instruction set (ISA),
and then set out to show that the microcode implemented the C/30 ISA when
executing on the MBB.  Attached are some crudely photographed copies of
slides I dredged out of my files.  (I can try to make a better copy if
anyone is interested.)

Since the machines were working and out in the field, we didn't expect to
find anything major.  Nonetheless, in anticipation that we might find some
rough edges, we adopted a classification system for the problems.  The
major error categories were:

A = an error in the microcode
B = an error in the description of the MBB
C = an error in the description of the C/30
D = an error or limitation in our proof system.

We broke down groups B and C into three subgroups:

B1, C1 = error in the documentation of the architecture
B2, C2 = ambiguity in the documentation of the architecture
B3, C3 = our error in creating the formal description of the architecture

There were 128 distinct opcodes.  Ten of these were for IO, maintenance or
diagnostic purposes.  We did not deal with these.  We did push through
proofs for the other 118 opcodes.  In a number of cases we found problems.
Some of these were discrepancies in the documentation or our formalization
of the architectures.  Others were actual errors in the microcode but of
little consequence because they caused inconsequential errors in the
behavior of the instruction.  A common case was returning the wrong error
code, but the code running on top of the instruction didn't make use of the
error code.

One of the more droll discrepancies were the implementations of the Set
Overflow Bit and Reset Overflow Bit instructions.  We found their
implementations were reversed.  However, when we consulted with BBN, they
said they had found the error but instead of changing the microcode, they
changed the output of the assembler.

Cheers,

Steve


















































Sent from my iPhone