[TUHS] Unix with TCP/IP for small PDP-11s

[TUHS] Unix with TCP/IP for small PDP-11s

[Noel Chiappa]

    > From: Paul Ruizendaal

    > I'm looking into the history of Spider and early Datakit. Sandy Fraser
    > was kind enough to send me the 1974 report on Spider

Is that online? If not, any chances you can make it so?


    > Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g.
    > the 'tiu' device driver, the 'nfs' file transfer package, etc.)?

You're in luck.

To start with, check out:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/oldstuff

which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
are part of it?

I'm not at all clear how this stuff got there - someone at Bell must have just
dumped the contents of the 'dmr' directory, and sent it all off?


The PWB1-based MIT systems also have a lot of the Spider software (although it
was never used). It's a slightly different version than the one above: 'diff'
shows that 'tiu.c' is almost identical, but mpx.c has more significant
differences.

It also contains man pages, and sources for some (?) user programs; I have the
source and manpage for 'nfs'. What other names should I be looking for? (The
man page for 'nfs' doesn't list any other commands.) I'll put them up
momentarily.

In the meantime, I'll append the 'tiu' man page. There isn't one for mpx,
alas.

	Noel


--------


.th TIU IV 10/28/73
.sh NAME
tiu \*- Spider interface
.sh DESCRIPTION
Spider
is a fast digital switching network.
.it Tiu
is a directory which contains
files each referring to a Spider control
or data channel.
The file /dev/tiu/d\fIn\fR refers to data channel \fIn;\fR
likewise /dev/tiu/c\fIn\fR refers to control channel \fIn\fR.
.s3
The precise nature of the UNIX interface
is specified elsewhere.
.sh FILES
/dev/tiu/d?, /dev/tiu/c?
.sh BUGS

[TUHS] Unix with TCP/IP for small PDP-11s

[Noel Chiappa]

    > From: Paul Ruizendaal

    >>> the 1974 report on Spider

    >> Is that online? If not, any chances you can make it so?

    > It is a paper copy, but I can make a scan for you.

That makes it sounds like it might not be possible to put it online?
What's the exact title, so I can look and see if it's already online?
I'm pretty sure I've got a hardcopy of some Spider thing, but it would
probably take me a while to find it... ;-)


    > I think that in the lifespan of Spider (1972-1978) there were 3 main
    > network programs (basing myself on McIlroy's Unix Reader):
    > - 'nfs' an FTP-like program ...
    > - 'ufs' not sure what it was, but I think a telnet-like facility
    > - 'npr' a network printing program

OK, the only one I have is 'nfs'. Here's the source, and man page:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6

	Noel

[TUHS] Unix with TCP/IP for small PDP-11s

[Jeremy C. Reed]

On Wed, 24 May 2017, Noel Chiappa wrote:

>     > From: Paul Ruizendaal
> 
>     >>> the 1974 report on Spider
> 
>     >> Is that online? If not, any chances you can make it so?
> 
>     > It is a paper copy, but I can make a scan for you.
> 
> That makes it sounds like it might not be possible to put it online?
> What's the exact title, so I can look and see if it's already online?
> I'm pretty sure I've got a hardcopy of some Spider thing, but it would
> probably take me a while to find it... ;-)

Maybe it is:

%T Spider \(em An Experimental Data Communications System
%Z ctr127
%A A. G. Fraser
%J Proc. IEEE Conf. on Communications
%P 21F
%O IEEE Cat. No. 74CH0859-9-CSCB.
%D June 1974

(as seen in usr/dict/papers/Rv7man)

[TUHS] Unix with TCP/IP for small PDP-11s

[Paul Ruizendaal]

> 
>> I'm looking into the history of Spider and early Datakit. Sandy Fraser
>> was kind enough to send me the 1974 report on Spider
> 
> Is that online? If not, any chances you can make it so?

It is a paper copy, but I can make a scan for you.

> which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
> are part of it?

I think tiu.c might be all. The TIU ("terminal access unit") was the network card,
so to speak (actually some 5 boards in a rack) and did a lot of the heavy lifting.

[TUHS] Unix with TCP/IP for small PDP-11s

[Paul Ruizendaal]

>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> ...
>> DCEC's adaptation of the Wingfield TCP/IP library, designed to work
>> with V6. It is mostly a user space daemon, but requires some kernel
>> enhancements.
> 
> I wonder what the performance would be like, since the TCP is in a user
> process (a different one from the application), i.e. there's a process switch
> every time the application goes to send or receive data. This wouldn't have
> been such an issue when the code was written, since ARPANet-type networks
> were not very fast, but with a better network, it would have been limiting.

IEN98 (http://www.rfc-editor.org/rfc/ien/ien98.txt, page 2) has the answer: about 10kb/s.

The DCEC version used shared memory instead of rand ports and was claimed to be
a bit more performant, but I have no number. I'd be surprised if it was twice as fast,
so perhaps 15kb/s.

Paul

[TUHS] Unix with TCP/IP for small PDP-11s

[Noel Chiappa]

    > From: Clem Cole

    > So some other mechanism (also discussed here) needed to be created to
    > avoid blocking in the application.
    > ...
    > Rand, UNET & Chaos had something else that gave the save async function,
    > who's name I've forgotten at the moment

I don't think the RAND code had the non-blocking stuff; AFAICR, all it had was
named pipes (effectively). Jack Haverty at BBN defined and implemented two new
calls (IIRC, 'capac()' and 'await()') to do non-blocking I/O. The
documentation for that is in the 'BBN' branch at TUHS:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/await
  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ipc

My memory might be incorrect, but I don't think it was asynchronous (i.e. a
process issued a read() or write(), and that returned right away, before the
I/O was actually done, and the system notified the process later when the I/O
actually completed).

I actually did implement asyn I/O for an early LAN device driver - and just to
make it fun, the device was a DMA device, and we didn't want the overhead of a
copy, so the DMA was direct to buffers in the process - i.e. 'raw' I/O. So
that required some major system tweaks, to keep the process from being swapped
out - or moved around - while the I/O was pending.
  
    > I believe Noel posted the code for same in the last year from one of the
    > MIT kernels

I found it on the dump of an MIT machine, but it was never run on any machine
at MIT - we just had the source in case we had any use fot it.

       Noel

[TUHS] Unix with TCP/IP for small PDP-11s

[Noel Chiappa]

    > From: Paul Ruizendaal

    > There are two other routes to TCP/IP on a PDP11 without split I/D:
    > ...
    > DCEC's adaptation of the Wingfield TCP/IP library, designed to work
    > with V6. It is mostly a user space daemon, but requires some kernel
    > enhancements.

I wonder what the performance would be like, since the TCP is in a user
process (a different one from the application), i.e. there's a process switch
every time the application goes to send or receive data. This wouldn't have
been such an issue when the code was written, since ARPANet-type networks
were not very fast, but with a better network, it would have been limiting.


    > From: Steve Simon

    > do you have pointers to any documentation on the rand/MIT network API?

There was no 'MIT' network API. He was talking about the CHAOSNet API. The
TCP/IP done in the CSR group at MIT used a totally different API.

The various Unix systems at MIT were pretty well out of touch with each other,
and did not exchange code. The only exceptions were the DSSR (later RTS) and
CSR groups in Tech Sq, who used pretty much the same system.

	Noel

[TUHS] Unix with TCP/IP for small PDP-11s

[Paul Ruizendaal]

I had somehow convinced myself that Ultrix-11 needed split I/D, but indeed it does not:

# file unix
unix:   (0450) pure overlay executable not stripped
# size unix
14784+(8192,8000,8064,8000,8064,8128,8000,7808,7936,7936,7680,7360,1344)+3524+13500 = 31808b = 076100b (111296 total text)

With only 16KB of permanent kernel there will be a lot of overlay switching. I'm not entirely sure why bss could not be 1KB smaller, enabling 8KB more of permanent kernel. The loss of performance from 2 disk buffers less really outweighed less overlay switching?

If I understand correctly, the network code continuously switches around segment 5 to access the right mbuf.

According to the notes in the TUHS archive (http://www.tuhs.org/Archive/Distributions/DEC/Ultrix-11/Fred-Ultrix3/setup-3.1.txt), running Ultrix-11 with networking on a 11/40 class machine is borderline workable:

"I have personally tested it on a 23+, 53 and 83.  I know it runs
fine on the 73.  The smaller machines (34, 40 etc) should work
akin to the 23, meaning using overlays and be very tight on RAM
for the drivers.  TCP/IP is a biiiiig load for those systems!"

There are two other routes to TCP/IP on a PDP11 without split I/D:
- 3COM's TCP/IP package (initially an overlay over V7, soon after also over 2BSD); I believe the source to this is lost.
- DCEC's adaptation of the Wingfield TCP/IP library, designed to work with V6. It is mostly a user space daemon, but requires some kernel enhancements. The Wingfield code is in the TUHS archive, but that version has a modified V6 kernel that also supports NCP networking and requires split I/D. If used with a minimally enhanced V6 kernel, it would easily fit in 64KB, without overlays.

Note that these last two options have very different API's and would not be so easy to work with.

Paul
 

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

> There are two other routes to TCP/IP on a PDP11 without split I/D:
> - 3COM's TCP/IP package (initially an overlay over V7, soon after also
> over 2BSD);
>
​It's called UNET​




> I believe the source to this is lost.
>
​So far that is true, there are a couple of leads including a couple of
unread tapes in my own basement.   The original authors and I have been in
touch.   Assuming we can find and recover it, there is still an open issue
of copyright.​




> ​.....​
>
>
> Note that these last two options have very different API's
>
​Indeed...​




> and would not be so easy to work with.
>
​Mumble ... it just means post-Joy sockets code does not 'just work.'  UNET
uses the Rand interface, which is similar to the interface MIT used for
Chaos and Chesson used for the ARPAnet code at UofI, so there are programs
that talk to it.   We had mail, ftp and telnet working just fine.​

​ Back in the day and IIRC we were playing with a port of the MIT SUPDUP
code but I do not remember if that ever worked on the small address
machines.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/bf42b9fa/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Steve Simon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

hi Clem,

do you have pointers to any documentation on the rand/MIT network API?

-Steve




> On 22 May 2017, at 15:09, Clem Cole <clemc at ccc.com> wrote:
> 
> 
>> On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> - 3COM's TCP/IP package (initially an overlay over V7, soon after also over 2BSD);
> ​It's called UNET​
> 
> 
>  
>> I believe the source to this is lost.
> ​So far that is true, there are a couple of leads including a couple of unread tapes in my own basement.   The original authors and I have been in touch.   Assuming we can find and recover it, there is still an open issue of copyright.​ 
> 
>  
>> ​.....​
>> 
>> 
>> Note that these last two options have very different API's
> ​Indeed...​
> 
> 
>  
>> and would not be so easy to work with.
> ​Mumble ... it just means post-Joy sockets code does not 'just work.'  UNET uses the Rand interface, which is similar to the interface MIT used for Chaos and Chesson used for the ARPAnet code at UofI, so there are programs that talk to it.   We had mail, ftp and telnet working just fine.​ ​ Back in the day and IIRC we were playing with a port of the MIT SUPDUP code but I do not remember if that ever worked on the small address machines.​
>  
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/476191bd/attachment-0001.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]

The Rand API is documented in a couple of papers that have been discussed
here previously.   I'll have to do a little googling to find them.   The
ChaosNET docs are the best MIT docs.


The API pretty much worked this way...  there was one simple kernel hook.
A small mod was done to the old nami routine (what modern UNIX calls
'lookup'), as a path was being parsed, the rest of the path was left in
place made available to other routines.

Thus you could open:  /dev/tcp/xxx  and the string xxx was available in
call that was implementing tcp and was then able to be passed xxx as a
parameter.  Hence, the traditional open/close/read/write was all that was
needed.

Joy codified a new API that was supposed to be more network centric and map
to different network protocols - the thinking being that
open/close/read/write were insufficient semantics for network operations.

Also, the only other issue at the time was that BSD's select(2) did not
exist, and the UNIX I/O were 100% synchronous.  So some other mechanism
(also discussed here) needed to be created to avoid blocking in the
application.  There were a couple of different schemes with V7's
multiplexor call was created by Chesson for DataKit (which was similar to
was used in the UofI code Arpanet code).   Rand, UNET & Chaos had something
else that gave the save async function, who's name I've forgotten at the
moment, but I believe Noel posted the code for same in the last year from
one of the MIT kernels - we had used it at CMU that we had gotten from Rand.

On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve at quintile.net> wrote:

> hi Clem,
>
> do you have pointers to any documentation on the rand/MIT network API?
>
> -Steve
>
>
>
>
> On 22 May 2017, at 15:09, Clem Cole <clemc at ccc.com> wrote:
>
>
> On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
>
>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> - 3COM's TCP/IP package (initially an overlay over V7, soon after also
>> over 2BSD);
>>
> ​It's called UNET​
>
>
>
>
>> I believe the source to this is lost.
>>
> ​So far that is true, there are a couple of leads including a couple of
> unread tapes in my own basement.   The original authors and I have been in
> touch.   Assuming we can find and recover it, there is still an open issue
> of copyright.​
>
>
>
>
>> ​.....​
>>
>>
>> Note that these last two options have very different API's
>>
> ​Indeed...​
>
>
>
>
>> and would not be so easy to work with.
>>
> ​Mumble ... it just means post-Joy sockets code does not 'just work.'
>  UNET uses the Rand interface, which is similar to the interface MIT used
> for Chaos and Chesson used for the ARPAnet code at UofI, so there are
> programs that talk to it.   We had mail, ftp and telnet working just fine.​
>
> ​ Back in the day and IIRC we were playing with a port of the MIT SUPDUP
> code but I do not remember if that ever worked on the small address
> machines.​
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/b5457eb2/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Ron Natalie]

Gak, the days before select.    I remember writing some terminal programs where I had to fork and do the synchronous read in each direction separately.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/6f1762bc/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Paul Ruizendaal]

Clem,

You've got me confused.

> The API pretty much worked this way...  there was one simple kernel hook.   A small mod was done to the old nami routine (what modern UNIX calls 'lookup'), as a path was being parsed, the rest of the path was left in place made available to other routines.

The UoI Arpanet code did not use the partial path parsing that you describe.
The namei() routine is unchanged (see http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/nami.c).

The code recognizes a network open, because the open() is of a special character file with major number 255;
the minor number would be the remote address (1974 arpanet used 8 bit network addresses - 6 bits IMP, 2 bits host).
If the 'mode' parameter to open() is 0, 1 or 2, then a NCP/telnet connection would be made to that host. If the mode parameter was anything else, it was a pointer to a data block with the full specification of the connection to be made. See:
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c - open1()
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpk/nopcls.c - netopen()

The data block contained all the parameters that are set via calls to connect/bind/listen in the BSD sockets API. 

> There were a couple of different schemes with V7's multiplexor call was created by Chesson for DataKit (which was similar to was used in the UofI code Arpanet code).

You've lost me here.

Paul

On 22 May 2017, at 18:29 , Clem Cole wrote:

> The Rand API is documented in a couple of papers that have been discussed here previously.   I'll have to do a little googling to find them.   The ChaosNET docs are the best MIT docs.
> 
> 
> The API pretty much worked this way...  there was one simple kernel hook.   A small mod was done to the old nami routine (what modern UNIX calls 'lookup'), as a path was being parsed, the rest of the path was left in place made available to other routines.
> 
> Thus you could open:  /dev/tcp/xxx  and the string xxx was available in call that was implementing tcp and was then able to be passed xxx as a parameter.  Hence, the traditional open/close/read/write was all that was needed.
> 
> Joy codified a new API that was supposed to be more network centric and map to different network protocols - the thinking being that open/close/read/write were insufficient semantics for network operations.
> 
> Also, the only other issue at the time was that BSD's select(2) did not exist, and the UNIX I/O were 100% synchronous.  So some other mechanism (also discussed here) needed to be created to avoid blocking in the application.  There were a couple of different schemes with V7's multiplexor call was created by Chesson for DataKit (which was similar to was used in the UofI code Arpanet code).   Rand, UNET & Chaos had something else that gave the save async function, who's name I've forgotten at the moment, but I believe Noel posted the code for same in the last year from one of the MIT kernels - we had used it at CMU that we had gotten from Rand.
> 
> On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve at quintile.net> wrote:
> hi Clem,
> 
> do you have pointers to any documentation on the rand/MIT network API?
> 
> -Steve

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

We'll have to do some digging. And having too been part of too many, but
similar of different implementations. The Chaos code used the partial
parsing as did a few others.  IIRC: That's the same trick Apollo used with
Domain too.  I had thought I had remember that Chesson and the UofI folks
used the same trick with the Arpanet code, but I have not looked at it in
years and clearly as you point out he did not.

As for DataKit et al..  Greg Chesson was a grad student at UoI.  The UoI
folks did the original  V6 Arpanet for UNIX code and Greg was the one of
the primary developers same.  What I do not remember is who came first, the
Rand networking work for the UoI work.   Rand did the the ports (later
called named pipes) and a few other things pretty early.   But again all
those dates sort of mix together in the early middle 70s.  USENIX was not
yet publishing proceedings so it's hard to keep straight.   It pretty much
just email and memories of those of us that were sharing things at the time.


Anyway, when Greg graduated, he was hired by Ken when he finished and
developed DataKit at Bell labs.   One of the pieces of datakit that was
released as part of V7 was Greg's mpx(2) code - which was the multiplexer.
The legend is that on is way to UCB for his sabbatical, Ken was checking in
Greg and the infamous v6 patches tape was left behind at UoI.  Greg used to
deny all knowledge of same, but smiled all the time he said it.

Clem

On Mon, May 22, 2017 at 6:07 PM, Paul Ruizendaal <pnr at planet.nl> wrote:

> Clem,
>
> You've got me confused.
>
> > The API pretty much worked this way...  there was one simple kernel
> hook.   A small mod was done to the old nami routine (what modern UNIX
> calls 'lookup'), as a path was being parsed, the rest of the path was left
> in place made available to other routines.
>
> The UoI Arpanet code did not use the partial path parsing that you
> describe.
> The namei() routine is unchanged (see http://www.tuhs.org/cgi-bin/
> utree.pl?file=SRI-NOSC/ken/nami.c).
>
> The code recognizes a network open, because the open() is of a special
> character file with major number 255;
> the minor number would be the remote address (1974 arpanet used 8 bit
> network addresses - 6 bits IMP, 2 bits host).
> If the 'mode' parameter to open() is 0, 1 or 2, then a NCP/telnet
> connection would be made to that host. If the mode parameter was anything
> else, it was a pointer to a data block with the full specification of the
> connection to be made. See:
> http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c - open1()
> http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpk/nopcls.c -
> netopen()
>
> The data block contained all the parameters that are set via calls to
> connect/bind/listen in the BSD sockets API.
>
> > There were a couple of different schemes with V7's multiplexor call was
> created by Chesson for DataKit (which was similar to was used in the UofI
> code Arpanet code).
>
> You've lost me here.
>
> Paul
>
> On 22 May 2017, at 18:29 , Clem Cole wrote:
>
> > The Rand API is documented in a couple of papers that have been
> discussed here previously.   I'll have to do a little googling to find
> them.   The ChaosNET docs are the best MIT docs.
> >
> >
> > The API pretty much worked this way...  there was one simple kernel
> hook.   A small mod was done to the old nami routine (what modern UNIX
> calls 'lookup'), as a path was being parsed, the rest of the path was left
> in place made available to other routines.
> >
> > Thus you could open:  /dev/tcp/xxx  and the string xxx was available in
> call that was implementing tcp and was then able to be passed xxx as a
> parameter.  Hence, the traditional open/close/read/write was all that was
> needed.
> >
> > Joy codified a new API that was supposed to be more network centric and
> map to different network protocols - the thinking being that
> open/close/read/write were insufficient semantics for network operations.
> >
> > Also, the only other issue at the time was that BSD's select(2) did not
> exist, and the UNIX I/O were 100% synchronous.  So some other mechanism
> (also discussed here) needed to be created to avoid blocking in the
> application.  There were a couple of different schemes with V7's
> multiplexor call was created by Chesson for DataKit (which was similar to
> was used in the UofI code Arpanet code).   Rand, UNET & Chaos had something
> else that gave the save async function, who's name I've forgotten at the
> moment, but I believe Noel posted the code for same in the last year from
> one of the MIT kernels - we had used it at CMU that we had gotten from Rand.
> >
> > On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve at quintile.net>
> wrote:
> > hi Clem,
> >
> > do you have pointers to any documentation on the rand/MIT network API?
> >
> > -Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/e97f362d/attachment-0001.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Paul Ruizendaal]

On 23 May 2017, at 1:25 , Clem Cole wrote:

> As for DataKit et al..  Greg Chesson was a grad student at UoI.  The UoI folks did the original  V6 Arpanet for UNIX code and Greg was the one of the primary developers same.  What I do not remember is who came first, the Rand networking work for the UoI work.   Rand did the the ports (later called named pipes) and a few other things pretty early.   But again all those dates sort of mix together in the early middle 70s.  USENIX was not yet publishing proceedings so it's hard to keep straight.   It pretty much just email and memories of those of us that were sharing things at the time.

These dates I can fill in:
- UoI Arpanet Unix was initially done between December 1974 and March 1975, building on the experience gained with the earlier ANTS I and II projects.
- Rand ports were done in 1977, under contract to the air force (report dated June '77).

> Anyway, when Greg graduated, he was hired by Ken when he finished and developed DataKit at Bell labs.   One of the pieces of datakit that was released as part of V7 was Greg's mpx(2) code - which was the multiplexer.

Interesting. I always thought that mpx files were driven by the work on the Blit terminal, the link to networking is new to me.

I'm looking into the history of Spider and early Datakit. Sandy Fraser was kind enough to send me the 1974 report on Spider and it already mentions actual usage for remote printing, remote login and a central 'file store'. Spider was an interesting bit of technology, essentially it linked a dozen or so computers over a 1.5Mb/s shared link (a daisy chained twisted pair cable) to a central router/switch. There was only ever one Spider router, but the design allowed for multiple routers to be connected over T1 long distance lines.

Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g. the 'tiu' device driver, the 'nfs' file transfer package, etc.)?

[TUHS] Unix with TCP/IP for small PDP-11s

[Johnny Billquist]

On 2017-05-20 04:00, Warner Losh <imp at bsdimp.com> wrote:

> https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
>
> Looks like it requires MMU, but not split I/D space as it lists the
> following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It
> does require 256kb of memory. See table 2, page 6 for details.


Uh...? Where do you see that there is any TCP/IP support in Ultrix-11? 
If any was done by someone else, there is no saying that it would be 
usable on a machine without split I/D. To be honest, I've never seen any 
mention of TCP/IP on any machine without split I/D space. I guess it 
could be done, but it would be a rather big headache...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Unix with TCP/IP for small PDP-11s

[Henry Bent]

There is absolutely TCP/IP in Ultrix-11.  This is an emulated 11/23+:

--
hrb11# uname -a
ULTRIX-11 hrb11 3 0 PDP-11/23
hrb11# ifconfig qe0
qe0: 192.168.1.199 netmask ffffff00
flags=263<UP,BROADCAST,NOTRAILERS,RUNNING>
broadcast: 192.168.1.255
hrb11# netstat -rn
Routing tables
Destination     Gateway         Flags    Refcnt Use        Interface
74.42.148.138   192.168.1.1     UGH      0      0          qe0
192.168.1       192.168.1.199   U        1      0          qe0
default         192.168.1.1     UG       0      0          qe0
192.168.5       192.168.1.1     UG       0      0          qe0
hrb11# ftp 192.168.1.63
Connected to 192.168.1.63.
220 aelfric FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
Name (192.168.1.63:root):
...
--

It has trouble talking to the outside world, probably not a big surprise,
but works just fine on my local network.  I am working on getting it
installed in a real 11/23 but the Ultrix RL02 driver doesn't seem to like
my Dilog emulation board.

-Henry

On 20 May 2017 at 06:46, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2017-05-20 04:00, Warner Losh <imp at bsdimp.com> wrote:
>
> https://ia601901.us.archive.org/10/items/bitsavers_decpdp11u
>> lLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
>>
>> Looks like it requires MMU, but not split I/D space as it lists the
>> following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It
>> does require 256kb of memory. See table 2, page 6 for details.
>>
>
>
> Uh...? Where do you see that there is any TCP/IP support in Ultrix-11? If
> any was done by someone else, there is no saying that it would be usable on
> a machine without split I/D. To be honest, I've never seen any mention of
> TCP/IP on any machine without split I/D space. I guess it could be done,
> but it would be a rather big headache...
>
>         Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                   ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170520/f571a6a9/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Johnny Billquist]

On 2017-05-20 19:39, Henry Bent wrote:
> There is absolutely TCP/IP in Ultrix-11.  This is an emulated 11/23+:

Cool. But obviously not the version the SPD was for then. Which version 
of Ultrix-11?

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Unix with TCP/IP for small PDP-11s

[Henry Bent]

That was Ultrix-11 3.1, which I believe was the final version.  Full source
is available on tuhs.org.

-Henry

On 20 May 2017 at 16:40, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2017-05-20 19:39, Henry Bent wrote:
>
>> There is absolutely TCP/IP in Ultrix-11.  This is an emulated 11/23+:
>>
>
> Cool. But obviously not the version the SPD was for then. Which version of
> Ultrix-11?
>
>
>         Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                   ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170520/1aeef558/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Warner Losh]

On Sat, May 20, 2017 at 4:46 AM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2017-05-20 04:00, Warner Losh <imp at bsdimp.com> wrote:
>
> https://ia601901.us.archive.org/10/items/bitsavers_decpdp11u
>> lLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
>>
>> Looks like it requires MMU, but not split I/D space as it lists the
>> following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It
>> does require 256kb of memory. See table 2, page 6 for details.
>>
>
>
> Uh...? Where do you see that there is any TCP/IP support in Ultrix-11? If
> any was done by someone else, there is no saying that it would be usable on
> a machine without split I/D. To be honest, I've never seen any mention of
> TCP/IP on any machine without split I/D space. I guess it could be done,
> but it would be a rather big headache...


I read the sources to see the TCP/IP support was there (that's the bit
about adding Berkeley Sockets). I see nowhere that it's excluded for the
non I/D machines, but haven't tried it first hand. I got interested not
because of the PDP-11, but because I have an old Rainbow that recently
started running Venix (v7-based version) and was trolling around for some
way to do TCP/IP to it (though w/o readily available ethernet cards, I'm
not sure it is a viable project).

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170520/391c19a1/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[arnold]

Warner Losh <imp at bsdimp.com> wrote:

> I read the sources to see the TCP/IP support was there (that's the bit
> about adding Berkeley Sockets). I see nowhere that it's excluded for the
> non I/D machines, but haven't tried it first hand. I got interested not
> because of the PDP-11, but because I have an old Rainbow that recently
> started running Venix (v7-based version) and was trolling around for some
> way to do TCP/IP to it (though w/o readily available ethernet cards, I'm
> not sure it is a viable project).

Boy is the memory going.  What was the TCP/IP implementation people
ran on DOS to do connections over serial lines?  Could that be found
and revived for such a system?

Thanks,

Arnold

[TUHS] Unix with TCP/IP for small PDP-11s

[Warner Losh]

On Sat, May 20, 2017 at 1:05 PM, <arnold at skeeve.com> wrote:

> Warner Losh <imp at bsdimp.com> wrote:
>
> > I read the sources to see the TCP/IP support was there (that's the bit
> > about adding Berkeley Sockets). I see nowhere that it's excluded for the
> > non I/D machines, but haven't tried it first hand. I got interested not
> > because of the PDP-11, but because I have an old Rainbow that recently
> > started running Venix (v7-based version) and was trolling around for some
> > way to do TCP/IP to it (though w/o readily available ethernet cards, I'm
> > not sure it is a viable project).
>
> Boy is the memory going.  What was the TCP/IP implementation people
> ran on DOS to do connections over serial lines?  Could that be found
> and revived for such a system?
>

That would be mTCP with CSLIP. And under DOS people have that running
already, but there's limitations and it's not designed for a Unix kernel....

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170520/41537f9a/attachment-0001.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[David Arnold]

> On 21 May 2017, at 05:05, arnold at skeeve.com wrote:
> 
> Warner Losh <imp at bsdimp.com> wrote:
> 
>> I read the sources to see the TCP/IP support was there (that's the bit
>> about adding Berkeley Sockets). I see nowhere that it's excluded for the
>> non I/D machines, but haven't tried it first hand. I got interested not
>> because of the PDP-11, but because I have an old Rainbow that recently
>> started running Venix (v7-based version) and was trolling around for some
>> way to do TCP/IP to it (though w/o readily available ethernet cards, I'm
>> not sure it is a viable project).
> 
> Boy is the memory going.  What was the TCP/IP implementation people
> ran on DOS to do connections over serial lines?  Could that be found
> and revived for such a system?

ka9q?



d

[TUHS] Unix with TCP/IP for small PDP-11s

[Erik E. Fair]

Also MIT PC/IP:

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

	Erik Fair

[TUHS] Unix with TCP/IP for small PDP-11s

[Johnny Billquist]

On 2017-05-20 20:18, Warner Losh wrote:
>
>
> On Sat, May 20, 2017 at 4:46 AM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     On 2017-05-20 04:00, Warner Losh <imp at bsdimp.com
>     <mailto:imp at bsdimp.com>> wrote:
>
>         https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
>         <https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf>
>
>         Looks like it requires MMU, but not split I/D space as it lists the
>         following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and
>         11/60. It
>         does require 256kb of memory. See table 2, page 6 for details.
>
>
>
>     Uh...? Where do you see that there is any TCP/IP support in
>     Ultrix-11? If any was done by someone else, there is no saying that
>     it would be usable on a machine without split I/D. To be honest,
>     I've never seen any mention of TCP/IP on any machine without split
>     I/D space. I guess it could be done, but it would be a rather big
>     headache...
>
>
> I read the sources to see the TCP/IP support was there (that's the bit
> about adding Berkeley Sockets). I see nowhere that it's excluded for the
> non I/D machines, but haven't tried it first hand. I got interested not
> because of the PDP-11, but because I have an old Rainbow that recently
> started running Venix (v7-based version) and was trolling around for
> some way to do TCP/IP to it (though w/o readily available ethernet
> cards, I'm not sure it is a viable project).

You do know that the Rainbow is not a PDP-11, right?

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Unix with TCP/IP for small PDP-11s

[Warner Losh]

On Sat, May 20, 2017 at 2:40 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2017-05-20 20:18, Warner Losh wrote:
>
>>
>>
>> On Sat, May 20, 2017 at 4:46 AM, Johnny Billquist <bqt at update.uu.se
>> <mailto:bqt at update.uu.se>> wrote:
>>
>>     On 2017-05-20 04:00, Warner Losh <imp at bsdimp.com
>>     <mailto:imp at bsdimp.com>> wrote:
>>
>>         https://ia601901.us.archive.org/10/items/bitsavers_decpdp11u
>> lLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf
>>         <https://ia601901.us.archive.org/10/items/bitsavers_decpdp11
>> ulLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf>
>>
>>         Looks like it requires MMU, but not split I/D space as it lists
>> the
>>         following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and
>>         11/60. It
>>         does require 256kb of memory. See table 2, page 6 for details.
>>
>>
>>
>>     Uh...? Where do you see that there is any TCP/IP support in
>>     Ultrix-11? If any was done by someone else, there is no saying that
>>     it would be usable on a machine without split I/D. To be honest,
>>     I've never seen any mention of TCP/IP on any machine without split
>>     I/D space. I guess it could be done, but it would be a rather big
>>     headache...
>>
>>
>> I read the sources to see the TCP/IP support was there (that's the bit
>> about adding Berkeley Sockets). I see nowhere that it's excluded for the
>> non I/D machines, but haven't tried it first hand. I got interested not
>> because of the PDP-11, but because I have an old Rainbow that recently
>> started running Venix (v7-based version) and was trolling around for
>> some way to do TCP/IP to it (though w/o readily available ethernet
>> cards, I'm not sure it is a viable project).
>>
>
> You do know that the Rainbow is not a PDP-11, right?


Only since '84 when I bought mine... They are both small memory boxes,
though, and something that can run in a 256kB machine should be able to run
on a 892kB machine...  I have bits of mch.c/low.s from Venix that I can
leverage for the port to the Ultrix kernel to the 8088 that's inside the
Rainbow it would be running on.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170520/4fe0cc15/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Johnny Billquist]

On 2017-05-20 23:05, Warner Losh wrote:
>
>
> On Sat, May 20, 2017 at 2:40 PM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     On 2017-05-20 20:18, Warner Losh wrote:
>
>         I read the sources to see the TCP/IP support was there (that's
>         the bit
>         about adding Berkeley Sockets). I see nowhere that it's excluded
>         for the
>         non I/D machines, but haven't tried it first hand. I got
>         interested not
>         because of the PDP-11, but because I have an old Rainbow that
>         recently
>         started running Venix (v7-based version) and was trolling around for
>         some way to do TCP/IP to it (though w/o readily available ethernet
>         cards, I'm not sure it is a viable project).
>
>
>     You do know that the Rainbow is not a PDP-11, right?
>
>
> Only since '84 when I bought mine... They are both small memory boxes,
> though, and something that can run in a 256kB machine should be able to
> run on a 892kB machine...  I have bits of mch.c/low.s from Venix that I
> can leverage for the port to the Ultrix kernel to the 8088 that's inside
> the Rainbow it would be running on.

Good. Just wanted to make sure you wouldn't get surprised/confused 
later. :-)
No offense intended.

That said, I suspect it is not that easy to move over, as this probably 
ties very closely in to how the hardware works, and more specifically 
the MMU. Thus, an 8088 have to do things rather differently than a PDP-11.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Unix with TCP/IP for small PDP-11s

[Random832]

On Sat, May 20, 2017, at 17:34, Johnny Billquist wrote:
> That said, I suspect it is not that easy to move over, as this probably 
> ties very closely in to how the hardware works, and more specifically 
> the MMU. Thus, an 8088 have to do things rather differently than a
> PDP-11.

Also, x86 is totally "split I/D" by any relevant definition, and has a
20-bit physical address space.

[TUHS] Unix with TCP/IP for small PDP-11s

[Ron Natalie]

> Also, x86 is totally "split I/D" by any relevant definition, and has a 20-bit physical address space.

The physical address space isn't the issue.    The PDP-11's (well the later ones) had 22 bits of address space.

Even the amount of virtual address space wasn't the problem.   The problem was really the lack of segments    The PDP11, only had 8 for code and 8 for the combined stack/data (on the split I/D) machine.
While we were able to "thunk" in a code overlay system without any real hardware support, there's no way to do that practically for data.

As I stated earlier, using the BSD networking code, we ran out of the combined code/data registers when it came to having ot have one to map the mbufs.   I supposed you could have added more magic (and perhaps th is is what the later Ultrix did), to carefully unmap one of the data segements to get to the network data, but boy, we never figured out a good way to do that when we tried.    We retired all but the 11/70's (which we had three of) at the time as the Vaxes and other machines were beginning to roll in.    In fact, I did eventually also turn one of the 11/70's into a router using my LOS (little operating system...no time for sharing, uniprocessor system) gateway OS.    Each driver ran in it's own little program so it was a lot easier.

[TUHS] Unix with TCP/IP for small PDP-11s

[Noel Chiappa]

I'm trying to find out if there is any existing Unix for the PDP-11
which supports TCP/IP on /40-/34-23 class machines (i.e. non-I+D
machines)?

Does 2.9 BSD with TCP/IP (assuming such a thing exists) fit on those
machines? (I know 2.9 does run on them, but I don't know about the TCP/IP
part.)


The reason I ask is that MIT did a TCP/IP for V6 which would run on them
(only incoming packet de-mux is in the kernel - the TCP is in with the
application, in the user process), which has recently been recovered from a
backup tape.

I'm trying to figure out if there is any use for it, as it would take some
work to make it usable (I'd have to write device drivers for available
Ethernet cards, and adapt an ARP implementation for it).

	Noel

[TUHS] Unix with TCP/IP for small PDP-11s

[Henry Bent]

There is a later patch release of 2.9BSD that includes TCP/IP support but I
have not had any luck getting a compiled kernel to boot. My recommendation
would be Ultrix 3.1 which does run on the smaller machines.

I think it is possible that 2.10BSD could be made to work but I have never
had any success booting it in SIMH. If anyone has booted it or has any
suggestions, I would be interested to hear it.

-Henry

On May 19, 2017 11:15 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

I'm trying to find out if there is any existing Unix for the PDP-11
which supports TCP/IP on /40-/34-23 class machines (i.e. non-I+D
machines)?

Does 2.9 BSD with TCP/IP (assuming such a thing exists) fit on those
machines? (I know 2.9 does run on them, but I don't know about the TCP/IP
part.)


The reason I ask is that MIT did a TCP/IP for V6 which would run on them
(only incoming packet de-mux is in the kernel - the TCP is in with the
application, in the user process), which has recently been recovered from a
backup tape.

I'm trying to figure out if there is any use for it, as it would take some
work to make it usable (I'd have to write device drivers for available
Ethernet cards, and adapt an ARP implementation for it).

        Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170519/f37cd216/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

To my knowledge no.   We had already gone to code overlays on the 11/34’s just to get the pre-TCP unix working.    When we needed yet another segment to map mbufs (which we could do on the 11/70), there just weren’t any left.      It was then that I scarfed up all the 11/23, 24, 34’s that were available and turned them into routers.    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170519/75140600/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

There's a copy of ultrix-11, which is v7 based with some 4.1BSD additions,
including sockets and a TCP/IP stack. Don't know if it runs on the smaller
PDP-11, but it looks like it might. The sources are in the TUHS archives.
Seems like the best low-end v7ish kernel with TCP/IP around, but I've not
used it extensively.

Warner

On Fri, May 19, 2017 at 1:04 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> To my knowledge no.   We had already gone to code overlays on the 11/34’s
> just to get the pre-TCP unix working.    When we needed yet another segment
> to map mbufs (which we could do on the 11/70), there just weren’t any
> left.      It was then that I scarfed up all the 11/23, 24, 34’s that were
> available and turned them into routers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170519/8b6f7875/attachment-0001.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDSep84_870730/AE-X370C-TC_ULTRIX-11_2.0SPD_Sep84.pdf

Looks like it requires MMU, but not split I/D space as it lists the
following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It
does require 256kb of memory. See table 2, page 6 for details.

Warner



On Fri, May 19, 2017 at 6:15 PM, Warner Losh <imp at bsdimp.com> wrote:

> There's a copy of ultrix-11, which is v7 based with some 4.1BSD additions,
> including sockets and a TCP/IP stack. Don't know if it runs on the smaller
> PDP-11, but it looks like it might. The sources are in the TUHS archives.
> Seems like the best low-end v7ish kernel with TCP/IP around, but I've not
> used it extensively.
>
> Warner
>
> On Fri, May 19, 2017 at 1:04 PM, Ron Natalie <ron at ronnatalie.com> wrote:
>
>> To my knowledge no.   We had already gone to code overlays on the 11/34’s
>> just to get the pre-TCP unix working.    When we needed yet another segment
>> to map mbufs (which we could do on the 11/70), there just weren’t any
>> left.      It was then that I scarfed up all the 11/23, 24, 34’s that were
>> available and turned them into routers.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170519/a381ab39/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

My quick answer is yes, this sounds cool.

From that time, that two attempts to network 40 class systems that I know
about were:


   -  As I have mentioned in the past, in the late 1970s CMU had developed
   an 8085 later 8086 based Multibus board that would eventually begat the
   Cisco AGS, called the CMU distributed Front-End.   It was an attempt to get
   IP connected to the 11/40 class systems, by splicing them into the 11's
   with an DR-11B or C (I've forgotten which).   But the primary protocol
   processing was done on the FE and not in the UNIX kernel.     Phil Karn
   might remember what happened to that stuff, I do not believe I still have
   it.
   - Shortly thereafter @ Tektronix had 3Com's UNET.  I was primarily
   running on the 11/70 and that was what we used to develop against the Cyber
   and VMS IP/TCP's we wrote.  We also had it on an 11/44 but both of those
   are 45 class.     We did try to run on an 11/60 - which is 40 class as you
   asked, and we did get it work as I recall after a fashion.   But we did not
   push it very hard;as we had built a front end that in the same vein as the
   CMU device, called the NIBB - Network Interface Black Box, which was a Z80
   that did the same sort of thing and the need was not there.

 I was under the impression the 2.X folks may have tried to do it later
with all the thunk code.  But that was all after my work.   Fred Canter at
DEC might have tried something in later versions of Ultrix/PDP11, we should
look at the sources in his stream had see what he did too.

Clem

On Fri, May 19, 2017 at 11:15 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I'm trying to find out if there is any existing Unix for the PDP-11
> which supports TCP/IP on /40-/34-23 class machines (i.e. non-I+D
> machines)?
>
> Does 2.9 BSD with TCP/IP (assuming such a thing exists) fit on those
> machines? (I know 2.9 does run on them, but I don't know about the TCP/IP
> part.)
>
>
> The reason I ask is that MIT did a TCP/IP for V6 which would run on them
> (only incoming packet de-mux is in the kernel - the TCP is in with the
> application, in the user process), which has recently been recovered from a
> backup tape.
>
> I'm trying to figure out if there is any use for it, as it would take some
> work to make it usable (I'd have to write device drivers for available
> Ethernet cards, and adapt an ARP implementation for it).
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170519/56bea0f0/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Dave Horsfall]

On Fri, 19 May 2017, Clem Cole wrote:

> We did try to run on an 11/60 - which is 40 class as you asked, and we 
> did get it work as I recall after a fashion.

Ah, the mighty 11/60; boy, but that takes me back.  We bought one to 
replace our ageing /40, and I was fascinated by its octal display (yes, I 
wrote an idle loop to shift its digits back and forth; there should be an 
article somewhere in the AUUG archives).

Story time: DEC were flogging the /60s real cheap here in Oz, because a 
deal with a major publisher (Murdoch?  Packer?  Who knows?) fell through 
at the last moment, and they had an entire warehouse to shift.

Trivia: the thing was micro-codeable, and I had dreams of implementing the 
Unix call/return sequences as single instructions, but I never did get a 
round tuit.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

On Sun, May 21, 2017 at 12:16 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Story time: DEC were flogging the /60s real cheap here in Oz, because a
> ​ ​
> deal with a major publisher (Murdoch?  Packer?  Who knows?) fell through
> ​ ​
> at the last moment, and they had an entire warehouse to shift.
>
​It was world wide.   The /60 was the fastest machine from release to
traditional product in DEC's history.​




>
> Trivia: the thing was micro-codeable, and I had dreams of implementing the
> ​ ​
> Unix call/return sequences as single instructions, but I never did get a
> ​ ​
> round tuit.
>
​Indeed.  @ Tek we had both the DEC tools and the CMU tools and the 11/40e
microcode from CMU (and the compiler that used csav/cret - probably still
do somewhere).   One problem was the microcode compiler from DEC ran on RSX
and CMU's ran on TOPS-10 of which I had neither.  ​

The /60 and /40 had similar but different base microengines and it was
going to take some work reimplementing the CMU extens for the 60.   I've
forgotten the details of what changed in the microengine, but something was
hugely different and enough that the CMU microcode would have been a model,
but would not work even if I could manage to get the tools together.
So, it was also on my todo list, but we got an 11/70 shortly after I pulled
together the pieces and we never got to it.

What I can tell you from the CMU experience is that it bought a small
amount of speed up, but the big thing code size reduction for some programs
and on 40 class machine -- anything like that helped.   But... the problem
was it made the binaries not portable.

We had to be very careful.   The EE production machines (which were 11/34
and later /34As) binaries of course could run on the CS systems, but the CS
machines with the /40e microcode, compiler et al, created binaries that
core dumped on the 34.   Worse yet, was accidently mixing libraries.

Ted and I talked about hacking the EE kernel to support a UUI like the FPs
did could take the CS binaries and run them.   But that project never
occurred - which was probably a shame.  Instead, Danny Klein and I got
really good at purging any tape or disk that passed through a CS system for
anything binary on it.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170521/944d42bd/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

The 11/60’s main claim to fame if I recall was a writable control store.   Don’t know anybody who actually used that feature.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170521/bd053dd8/attachment.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3027 bytes --]

Actually, the 11/60's main claim to fame was it supposed to be a
'commercial' PDP-11 and was built for the small business market.  The WCS
was a side effect.

It was to built to run RSTS and RSX and had a commercial instruction set
exten *etc.*. Somebody had written a 'dentist office' package for it and a
'car dealership package' IIRC.    And was physically packaged a tad
differently than the other 11's as it was trying to be marketing to places
that might want to show it off instead of hiding it in a computer room.

The main competition at the time was the Burrough 1700 and the IBM System
38 and DEC was trying to find a system to compete in the market.   Now, the
B1700 is a very cool system and could swap its microcode depending on the
language running (it is also bit addressable). As I understand it from
talking to the 11/60s product manager many years later at a party, one of
the ideas was that the PDP 11/60 WCS an attempt to be able offer features
that might be needed to compete with it.

The the real truth was that issue in the original 11's had stored the ucode
in PROM and if an ECO went out the CPU boards had be swapped, so the chips
could be swapped at the factory.    Plus a number of places, like MIT and
CMU had been banging on DEC to make the ucoding of the system an available
option (CMU just built it's own the 11/40e that triple drip made for them).

Anyway, as the price of SRAM had fallen dramatically from when the 11 was
introduced, and the 11/60 was storing the primary ucode it, not PROM like
the other 45 and 40 class systems; WCS became a possible feature to expose.
  But, as I said, the problem was that the WCS tools were not very portable
and the microengine was (as I remember) not well enough documented.  Which
is why I don't think many people tried.

Also the 11/60 also had a unique feature we called the HCU instruction -
Halt and Confuse Microcode.  Unlike the 11/34 which had an Intel 8008 that
ran front (programmers) console, the 11/60's microcode loop read the LED's
and keypad.  But ... if the ucode took a dive, the only recourse was turn
off the system - as it would stop responding to anything (just like PC
years later ;-)  We never found what sequence caused it; but when I was
debugging the original 11/60 port of V6, I would run into a lot ;-)

IIRC - we realized on these pages that Dave Horsfall in OZ and I in Oregon
must have been doing similar work around the same time.  FWIW, my changes
made it back to AT&T via Ted and I believe eventually went out in the
System III release.   That said, I suspect if we were to compare our
patches I bet they are pretty similar.

Clem

On Sun, May 21, 2017 at 4:57 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> The 11/60’s main claim to fame if I recall was a writable control store.
> Don’t know anybody who actually used that feature.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170521/873e6a94/attachment-0001.html>

[TUHS] Unix with TCP/IP for small PDP-11s

[William Pechter]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

I believe Reuters turned them into faster PDP8s via Microcode changes... 

-----Original Message-----
From: Ron Natalie <ron@ronnatalie.com>
To: 'Clem Cole' <clemc at ccc.com>, 'Dave Horsfall' <dave at horsfall.org>
Cc: 'The Eunuchs Hysterical Society' <tuhs at tuhs.org>
Sent: Sun, 21 May 2017 16:58
Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s

The 11/60’s main claim to fame if I recall was a writable control store.   Don’t know anybody who actually used that feature.