[TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code

[TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Michael Casadevall]

[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]

Hey all,
I've been recently working on researching ARPANET and the like for use in
an upcoming video. As a starting point, I've been looking at the early UNIX
networking code in archives, specifically, the NOSC tarball, and I've spent
quite a few hours trying to get building on livestreams.

What I've found is that there's corruption issues in code; which is noted
in JOHNS-NOTE, although it's more severe than I realized. For example
sys4.c is entirely corrupted, and part of impio.c is cut off. However, this
isn’t quite as bad as it sounds. For example, by kitbashing both the
original v6 source code, and the later BBN TCP code, I was able to create a
sys4.c that builds and links which should be close to the original.
Furthermore, it is possible to use the “vdh” target instead of the imp
target to at least try and get the code building. I did successfully get a
kernel to build, and it even prints out a mem message before deadlocking.

My guess is it's either deadlocked waiting for the IMP, or there’s
something wrong with the build. There’s some indication that it might need
a split kernel, although I’ve not had any success with that thus far. I
have uploaded my current build tree to git, as well as tarball with simh
images if anyone wants to try and figure out what has gone wrong. I admit,
my knowledge of PDP-11 assembly and debugging platforms is a bit wanting :)

There’s some indication that this, and the later BBN TCP (which is from
around the same time period) code were built on top of the Programmer’s
Workbench vs. stock v6; especially because some code patches were needed to
get it to build. I did look at the TUHS PWB archives, I see a bunch of
binaries, but absolutely no idea how to install them. I’ve heard that none
of these archives are actually complete, but I'm hoping someone might have
some idea of how to go forward, since, if nothing else, I’d like to end
this with a success story, although I’m happy with as far as I got.

Furthermore, I do know that I can run some of the ARPA level utilities in
MIT ITS on CHAOSNET, which will be an upcoming project, although that is
going to be a dive in and of itself.

In short, I’m hoping someone might be able to provide some insight into
where things have gone wrong:
  * Is the netunix kernel I built hanging because of corrupted code, or is
it waiting for non-existent hardware.
* NOTE: The DC-11 driver was not included, but I don’t think I need that
for a single console?
  * Is there any versions of PWB that is “easily” installable, since its
very clear the later BBN code requires it (it refers to ncc explicitly)?
  * I know IMPs have been emulated, and even have successfully routed
packets, so I’m also trying to figure out how much would still be necessary
to actually recreate a minimal ARPA network?

I did try to build some of the NCP applications regardless; it does appear
that some parts are simply missing. Mailer.cc seems to want a hnconv.o but
no source file exists. The FTP daemon on the other hand wants a library
simply called “j”.

My guess is that even if the NCP code was buildable, the applications might
not be. However, this did make me take a closer look at the BBN code, and
it does have an ifdef for NCP, suggesting that it was still
usable/supported? It makes sense, it seems to have been written before the
TCP/IP flag day. I’m just not sure where to approach compiling it.

I’ve uploaded the code with patches to build with the v6 compiler to github
here: https://github.com/NCommander/network-unix-v6/tree/attempted-repair

NOTE: v6's cc needs a seperate patch to increase the symbol table size;
that's done in the disk image.

Files, with SIMH configuration available here:
https://drive.google.com/file/d/1QS0B3RU_mwXSGtl2En-d0WI3PJ1-udEs/view?usp=sharing

My livestreams (12 hours or so) are on my YouTube channel:
https://youtube.com/c/NCommander

Feel free to forward this to other lists that may have PDP-11 or ARPANET
experts!
~ NCommander

[-- Attachment #2: Type: text/html, Size: 4414 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Lars Brinkhoff]

Michael Casadevall wrote:
> part of impio.c is cut off. However, this isn’t quite as bad as it
> sounds. For example, by kitbashing both the original v6 source code,
> and the later BBN TCP code, I was able to create a sys4.c that builds
> and links which should be close to the original. Furthermore, it is
> possible to use the “vdh” target instead of the imp target to at least
> try and get the code building.

Too bad about impio.c!  Maybe something can be extracted from the
unix.greg binary?  I see there's also the ACC interface, another
alternative to IMP11A.

> My guess is it's either deadlocked waiting for the IMP, or there’s
> something wrong with the build.

Since you don't have anything backing the hardware registers for the IMP
interface, it seems likely something will be upset.

> Furthermore, I do know that I can run some of the ARPA level utilities
> in MIT ITS on CHAOSNET, which will be an upcoming project, although
> that is going to be a dive in and of itself.

It's complicated.  Many of the utilities have parallels between the two,
and some work on both.  And there's a server to provide a gateway from
Chaosnet to Arpanet.  Give me a ping when you're looking into ITS.

> I know IMPs have been emulated, and even have successfully routed
> packets, so I’m also trying to figure out how much would still be
> necessary to actually recreate a minimal ARPA network?

Reviving the host software, like you are are doing, is one vital part of
it.  Another it adding emulators for various IMP interfaces.  I.e. you
will not get anywhere without adding one of IMP11A, ACC, or VDH to SIMH.

For adding other nodes to the network, PDP-10 hosts are your best bet.
There isn't much else left.

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Michael Casadevall]

[-- Attachment #1: Type: text/plain, Size: 3643 bytes --]

Replies inline

On Mon, Oct 10, 2022 at 3:48 PM Lars Brinkhoff <lars@nocrew.org> wrote:

> Michael Casadevall wrote:
> > part of impio.c is cut off. However, this isn’t quite as bad as it
> > sounds. For example, by kitbashing both the original v6 source code,
> > and the later BBN TCP code, I was able to create a sys4.c that builds
> > and links which should be close to the original. Furthermore, it is
> > possible to use the “vdh” target instead of the imp target to at least
> > try and get the code building.
>
> Too bad about impio.c!  Maybe something can be extracted from the
> unix.greg binary?  I see there's also the ACC interface, another
> alternative to IMP11A.
>
>
Well, there is an impio.c in the BBN TCP code which has #define NCPs, which
I used to rebuild the original impio.c; although this is very much a devil
in the
details situation.

I do need to do a readthrough for the VDH driver, which says its for "very
distant hosts".
I think that might be for the radio links to Hawaii and the UK? I vaguely
remember coming
across that term in my reading, but I'm drawing a blank ATM.

I did try to run the unix binaries in green and green47, but they seem to
be configured
for a RL0x drive of some sort; the driver is in the NOSC source, so it
might be possible
to get running, but without the host binaries, you'r enot going to get far.

> My guess is it's either deadlocked waiting for the IMP, or there’s
> > something wrong with the build.
>
> Since you don't have anything backing the hardware registers for the IMP
> interface, it seems likely something will be upset.
>
>
Well, I'm not sure if its trying to initialize the IMP on startup; there's
a userspace daemon,
ncpd which talks to the /dev nodes to do stuff; with network nodes showing
up as /dev/net/*host.

I did determine I at least seem to make it to sched() with my home cooked
kernel, but I can't even
start in single user mode.

Honestly, it reminds me of Plan 9 more than anything.


> > Furthermore, I do know that I can run some of the ARPA level utilities
> > in MIT ITS on CHAOSNET, which will be an upcoming project, although
> > that is going to be a dive in and of itself.
>
> It's complicated.  Many of the utilities have parallels between the two,
> and some work on both.  And there's a server to provide a gateway from
> Chaosnet to Arpanet.  Give me a ping when you're looking into ITS.
>
>
Will do. ITS feels like an extremely deep (if interesting) rabbithole :)


> > I know IMPs have been emulated, and even have successfully routed
> > packets, so I’m also trying to figure out how much would still be
> > necessary to actually recreate a minimal ARPA network?
>
> Reviving the host software, like you are are doing, is one vital part of
> it.  Another it adding emulators for various IMP interfaces.  I.e. you
> will not get anywhere without adding one of IMP11A, ACC, or VDH to SIMH.
>
>
Yup, that's what I figured. I've been trying to evaluate how much survives
here, but
my general feeling is one of the UNIX stacks might be recoverable, plus the
ARPA
stuff in ITS. I don't know if a runnable build of TENEX has been archived,
or if ARPA
stuff for TOPS-10/20 survived.

I also want to look into System/360 and 370, but I get the sense none of
the mainframe stuff survived.

The other problem is of the surviving stacks, they all seem to be for the
later 96-bit leader,
I'm not certain if any of the IMP software that has been archived is new
enough to work with that.

That said, that isn't an insurmountable problem.
~ NCommander

[-- Attachment #2: Type: text/html, Size: 4842 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

below...


On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael@casadevall.pro>
wrote:

>  For example sys4.c is entirely corrupted, and part of impio.c is cut off.
>
Hmmm

 % sha256sum impio.c sys4.c
1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efdaf34b4437d2  impio.c
7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f2ae6c88d  sys4.c

This is from my system - check to see if what you have are different




>
> There’s some indication that this, and the later BBN TCP (which is from
> around the same time period) code were built on top of the Programmer’s
> Workbench vs. stock v6;
>
Where did you see that?  Possible of course, but less likely.   PWB 1.0 was
not released outside of BTL.  Parts leaked to some of the Universities and
the MIT systems were famously PWBish, so it's possible it leaked from MIT
to BBN.  AGN is the comments -- Al Nemeth who is a friend of mine and Al
told me in those days, BBN was pretty spooked about where UNIX stuff came
from at BBN.

I think it's more likely if something is not stock V6, is using the
typesetter C compiler - which is the compiler described in K&R1 and would
later be part of V7 and PWB 2.0.  That was released independently a lot of
places had it and if you upgraded your V6 system to it, it was hard to go
backward.



>
> In short, I’m hoping someone might be able to provide some insight into
> where things have gone wrong:
>   * Is the netunix kernel I built hanging because of corrupted code, or is
> it waiting for non-existent hardware.
>
Could not a ton of things - where is stopping -- use simh to get an address
and then check then look UNIX symbol table and see what routine you are in
and see if you can egt a hint.

> * NOTE: The DC-11 driver was not included, but I don’t think I need that
> for a single console?
>
Should not need it - you can make sure /dev entry is nuked for it.   check
c.c and see what entry it was -- it should be commented it.   The look in
/dev and rm the entry so you don's accidentially try to open


>   * Is there any versions of PWB that is “easily” installable, since its
> very clear the later BBN code requires it (it refers to ncc explicitly)?
>
See comments -- I'm thinking this might not be PWB -- but if it is then go
to gunkies and get Noel's MIT system maybe.



>  NOTE: v6's cc needs a seperate patch to increase the symbol table size;
> that's done in the disk image.
>
Yep - done many times - also if you use a 45 or 70, make the compiler image
split I/D that helps too.   Although we ran them on 40s all the time - even
before Fred's overlay code.
ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 6317 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Michael Casadevall]

[-- Attachment #1: Type: text/plain, Size: 4405 bytes --]

Replies inline

On Mon, Oct 10, 2022 at 4:31 PM Clem Cole <clemc@ccc.com> wrote:

> below...
>
>
> On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael@casadevall.pro>
> wrote:
>
>>  For example sys4.c is entirely corrupted, and part of impio.c is cut
>> off.
>>
> Hmmm
>
>  % sha256sum impio.c sys4.c
> 1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efdaf34b4437d2  impio.c
> 7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f2ae6c88d  sys4.c
>
> This is from my system - check to see if what you have are different
>
>
From the NOSC tarball from THUS:

 % sha256sum ncpk/drivers/impio.c ken/sys4.c
ace2b7dae48bacf86b3bf1260a7715b66264308d67eb3232d963794481910c6a
 ncpk/drivers/impio.c
e5e727139e10b476c4dfa534155ddc07c0b3d32f132c98939c58d24f9a5efc41  ken/sys4.c

sys4.c is just garbage characters, impio.c stops in the middle of a
function.

There's also some corruption (mostly single bytes stuff) in other files,
i.e., I had to edit some non ASCII characters out because cc was unhappy,
so if a redump is possible, it would be good.


>
>>
>> There’s some indication that this, and the later BBN TCP (which is from
>> around the same time period) code were built on top of the Programmer’s
>> Workbench vs. stock v6;
>>
> Where did you see that?  Possible of course, but less likely.   PWB 1.0
> was not released outside of BTL.  Parts leaked to some of the Universities
> and the MIT systems were famously PWBish, so it's possible it leaked from
> MIT to BBN.  AGN is the comments -- Al Nemeth who is a friend of mine and
> Al told me in those days, BBN was pretty spooked about where UNIX stuff
> came from at BBN.
>
> I think it's more likely if something is not stock V6, is using the
> typesetter C compiler - which is the compiler described in K&R1 and would
> later be part of V7 and PWB 2.0.  That was released independently a lot of
> places had it and if you upgraded your V6 system to it, it was hard to go
> backward.
>
>
There are SCCS references in the code from 78/79, references to the V7 CC
compiler and updates. SCCS was introduced publicly with PWB, which is why I
suspect it might have been used. The code also uses some C syntax the stock
compiler dislikes (specifically, it was unhappy register in the function
declaration). The documentation discusses updating the C supervisor, and
also using the Yale shell included in the source before trying to build.

I know there's an updated cc that was on some of the disk dumps of later v6
systems, which might also be where things like "libg", and such are.
There's a few .a bundles that there are binaries but no sources in the
archive, but I didn't make a comprehensive list on it.

>
>
>>
>> In short, I’m hoping someone might be able to provide some insight into
>> where things have gone wrong:
>>   * Is the netunix kernel I built hanging because of corrupted code, or
>> is it waiting for non-existent hardware.
>>
> Could not a ton of things - where is stopping -- use simh to get an
> address and then check then look UNIX symbol table and see what routine you
> are in and see if you can egt a hint.
>

I'll check this next time I get the system out. I did follow the code a
fair bit, and it looks like I do at least get as far as sched() since mem =
is posted, and *then* it falls over.

* NOTE: The DC-11 driver was not included, but I don’t think I need that
>> for a single console?
>>
> Should not need it - you can make sure /dev entry is nuked for it.   check
> c.c and see what entry it was -- it should be commented it.   The look in
> /dev and rm the entry so you don's accidentially try to open
>

Awesome, thanks. That's what I suspected, but that's what I thought.


>
>
>>  NOTE: v6's cc needs a seperate patch to increase the symbol table size;
>> that's done in the disk image.
>>
> Yep - done many times - also if you use a 45 or 70, make the compiler
> image split I/D that helps too.   Although we ran them on 40s all the
> time - even before Fred's overlay code.
> ᐧ
>

Beside the startup code (which is in mch.c and uses a preprocessor macro),
is there anything specific gotchas in regards to models? I tried building
CPU40 and CPU70, and configuring simh, just to eliminate that gotcha, but
the only difference seems to be early initialization code ...

Michael

[-- Attachment #2: Type: text/html, Size: 8801 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

On Mon, Oct 10, 2022 at 4:49 PM Michael Casadevall <michael@casadevall.pro>
wrote:

>
> There are SCCS references in the code from 78/79, references to the V7 CC
> compiler and updates.
>
The 'V7 compiler' is 'Typesetter C' - it was released two compiler DWB on
V6.

SCCS had a interesting life.


> SCCS was introduced publicly with PWB,
>
Indeed.



> which is why I suspect it might have been used.
>
It might have been at MIT (it was a UCB and CMU BTW) - but I believe Al
Nemeth  - while it might have been a person disk, -- I'm pretty sure BBN
would have tried to kept those bits out of the building. - certainly out of
the mainstream of any project -- you see in the directories foo.c and
foo.c~ files -- this was typical of the day.  If you were using SCCS less
you would see a lot more evidence in the trees (again look at the UCB trees
- you can see once Ken brought it to UCB, wnj started to use it).




> The code also uses some C syntax the stock compiler dislikes
> (specifically, it was unhappy register in the function declaration).
>
As I said -- I suspect the typesetter compiler by then.  If userspace code
is using <stdio.h> and linking libS.a not Mike Lesk's portable I/O
library that's a huge clue also BTW.  But Dennis did a lot of work to the
compiler in the DWB timeframe.  A number of language features were added,
he changed the syntax of things like =+ to += and the like.   This is why
code that targets the Typesetter C compiler has a very difficult time going
back to the V6 (or basic PWB 1.0) compilers.   As I said in the other
message, this was the compiler he and Brian describe in the book - also
note a couple of us here reviewed different editions of it.

I suspect what you need is the original DWB 1.0 release that includes the
'typesetter' compiler -- that will bootstrap on a V6 system and will create
a v6 compiler.  I'm not sure we have that in the archives.  I think we have
the later PWB 2.0 release - that comes without the compiler.

Beside the startup code (which is in mch.c and uses a preprocessor macro),
> is there anything specific gotchas in regards to models? I tried building
> CPU40 and CPU70, and configuring simh, just to eliminate that gotcha, but
> the only difference seems to be early initialization code ...
>
Quick glance is that BBN was running a 45 - so I'd build for that to
start.   45s and 70s's are more similar but not exactly the same.  Don't
build for a 40. They are quite different.
Set simh up as a 45 and see if that just works.

If not .... then I would drop back and pull everything out to as simple a
UNIX as possible...  since it's a v6 system without any of the networking
-- as much line Ken and Dennis as you can.  Configure that a 40 and follow
Dennis's and Ken's instructions (which for v6 is a a 40) -- get that to
boot and a simh based 40.    Then reconfigure as a simh based 45 and make
that work.  Then and only then turn on the BBN stuff.

Feel free to send me email off line and I can try to help a little.  Note:
I have not played with a 45 in years. But I ran V5, V6. and V7 on 40s, 45
and 70s back in the day.  I have a PiDP 11/70 behind me so modulo being way
to busy, I can try to help a little.
ᐧ

[-- Attachment #2: Type: text/html, Size: 6598 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Lars Brinkhoff]

TUHS Disclaimer: I will claim this is primarily about getting Unix onto
the Arpanet, but it does also contain trace amounts of off-topic
information.  Reader discretion is adviced.

Michael Casadevall wrote:
> I do need to do a readthrough for the VDH driver, which says its for
> "very distant hosts".  I think that might be for the radio links

The hardware interfaces between a host and an IMP came in three flavors:
local host, distant host, and very distant host.  The first two are more
or less directly connected and I forget what the difference is.  But a
very distant host is basically connected over a phone line with a modem
at each end, so it's a different beast.  The VHD driver would be for
this, whilst IMP11A and ACC are local or distant.

> Hawaii

Side note: apparently tapes from the unique Hawaii BCC 500 have been
saved.  So maybe that's one more possible re-Arpanet host.

> Yup, that's what I figured. I've been trying to evaluate how much
> survives

Here's my take:
https://gunkies.org/wiki/Network_Control_Program_(ARPANET)#Implementations

So there are like four PDP-10 systems and two PDP-11.  The ELF system
will be a major challenge, RATS haven't been scanned off the printer
listing, and the BCC 500... oh boy, let's not go there now.

> I don't know if a runnable build of TENEX has been archived,

I think so.  I "almost" got one running but there was some problem...

> or if ARPA stuff for TOPS-10/20 survived.

TOPS-20AN seems to be there.  TOPS-10, nothing so far.

> I also want to look into System/360 and 370, but I get the sense none
> of the mainframe stuff survived.

I asked around; found nothing.  CDC, same.

> The other problem is of the surviving stacks, they all seem to be for
> the later 96-bit leader, I'm not certain if any of the IMP software
> that has been archived is new enough to work with that.

Nothing for the 316/516 IMP, as far as I know.  Pluribus IMP emulator,
anyone?

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Michael Casadevall]

[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]

>
>
> Replies inline:
>
> On Tue, Oct 11, 2022 at 1:31 AM Lars Brinkhoff <lars@nocrew.org> wrote:
>
>> TUHS Disclaimer: I will claim this is primarily about getting Unix onto
>> the Arpanet, but it does also contain trace amounts of off-topic
>> information.  Reader discretion is adviced.
>>
>> Michael Casadevall wrote:
>> > I do need to do a readthrough for the VDH driver, which says its for
>> > "very distant hosts".  I think that might be for the radio links
>>
>> The hardware interfaces between a host and an IMP came in three flavors:
>> local host, distant host, and very distant host.  The first two are more
>> or less directly connected and I forget what the difference is.  But a
>> very distant host is basically connected over a phone line with a modem
>> at each end, so it's a different beast.  The VHD driver would be for
>> this, whilst IMP11A and ACC are local or distant.
>>
>>
> That makes sense; most of the time, the documentation that survives implies
> the IMP is always local; knowing this is important. From what I got the
> impression
> From the docs, very early ARPA, you had systems directly on the network,
> but most
> users had to dial into a specific terminal machine, which, based on the
> comments
> on the RFCs, was less than ideal, although I haven't quite figured out how
> things like
> netmail worked.
>
> VHD I guess was more to get more hosts online?
>
> > Hawaii
>>
>> Side note: apparently tapes from the unique Hawaii BCC 500 have been
>> saved.  So maybe that's one more possible re-Arpanet host.
>>
>>
> Oh very nice. Depending on how that works, it might be possible to make a
> radio link
> over ham. I haven't seen anything about these links aside from them being
> marked
> the logicial maps.
>
>
>> > Yup, that's what I figured. I've been trying to evaluate how much
>> > survives
>>
>> Here's my take:
>> https://gunkies.org/wiki/Network_Control_Program_(ARPANET)#Implementations
>>
>> So there are like four PDP-10 systems and two PDP-11.  The ELF system
>> will be a major challenge, RATS haven't been scanned off the printer
>> listing, and the BCC 500... oh boy, let's not go there now.
>>
>>
>  Well, there's multiple UNIX v6 stacks. There's the NOSC one which I tried
> to build,
> and I think is the oldest. The BBN  with TCP stack is a bit mislabeled: it
> still appears
> to support NCP, but none of the client apps are there, but its directly
> built off the NOSC
> stack. it's probably a fork from earlier in development. 79-80 timespawn
> would have been
> *very* early in TCP's life
>
> > I don't know if a runnable build of TENEX has been archived,
>>
>> I think so.  I "almost" got one running but there was some problem...
>
>
>>
> > or if ARPA stuff for TOPS-10/20 survived.
>>
>> TOPS-20AN seems to be there.  TOPS-10, nothing so far.
>>
>> > I also want to look into System/360 and 370, but I get the sense none
>> > of the mainframe stuff survived.
>>
>> I asked around; found nothing.  CDC, same.
>>
>>
> Oof, although par the corse for mainframe preservation :(
>
>
>> > The other problem is of the surviving stacks, they all seem to be for
>> > the later 96-bit leader, I'm not certain if any of the IMP software
>> > that has been archived is new enough to work with that.
>>
>> Nothing for the 316/516 IMP, as far as I know.  Pluribus IMP emulator,
>> anyone?
>>
>
> I do actually wonder how hard that would be. The NCP kernel code seems to
> suggest
> it would be straightforward all things considered. It honestly reminds me
> Hayes modem
> commands of all things ...
> Michael
>

[-- Attachment #2: Type: text/html, Size: 5671 bytes --]

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Lars Brinkhoff]

Michael Casadevall wrote:
> From what I got the impression From the docs, very early ARPA, you had
> systems directly on the network, but most users had to dial into a
> specific terminal machine, which, based on the comments on the RFCs,
> was less than ideal

Sounds like a TIP, "Terminal IMP".  It was an IMP with double the amount
of memory.  In the upper half there was software to talk to a modem pool
for dial-in access to the network.  "Less than ideal", sure.  Modem
speeds were often 10-30 characters per second.  Much more fun to sit at
a video terminal next to the host.

> VHD I guess was more to get more hosts online?

In some cases there was an IMP which hooked up to some local hosts, but
they also wanted to connect a computer that not in the same building but
in the area.  That's when a VDH type interface was used.

> The BBN with TCP stack is a bit mislabeled: it still appears to
> support NCP, but none of the client apps are there, but its directly
> built off the NOSC stack.

That's very good.  I hope the NCP support there is in good shape.

> it's probably a fork from earlier in development. 79-80 timespawn
> would have been *very* early in TCP's life

TCP had been underway since 1973.  Experiments called "TCP bakeoffs"
started around 1979.

> > Pluribus IMP emulator,  anyone?
>
> I do actually wonder how hard that would be.

I'm not sure.  I have the impression the Pluribus computer isn't well
documented.

It might not be too hard to write an IMP replacement from scratch.

[TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code

[Lars Brinkhoff]

Tom Perrine wrote:
> A specific example of the VDH interface was the IMP at NOSC.
>
> IIRC it had 4 ports?

Normally yes (depending on the hardware configuration).

> One was a local connection to the machine at NOSC in the same room/building.
> One was a VDH to UCSD
> One was a VDH to LOGICON - the connection at the LOGICON end was a "56K
> wideband modem", which was a little larger than a 2-drawer file cabinet. I
> also seem to recall that the power supply had tubes.
> Not sure where the 4th port went - I only saw the UCSD and LOGICON ends in
> person.

Maybe this information for IMP 3 and 35 from 1979 can jog your memory.

HOST NOSC-SECURE2,      0/35,USER,TENEX,PDP10,[USC-ISIR1,ISIR1]
HOST LOGICON,           1/35,USER,UNIX,PDP11
HOST ACCAT-TIP,         2/35,USER,TIP,H316,[NELC-TIP]
HOST NOSC-SECURE3,      3/35,USER,UNIX,PDP11
HOST NOSC-CC,           0/3,SERVER,,UNIVAC-1110,[NUC-CC,NOSC-ELF]
HOST NOSC-SECURE1,      1/3,SERVER,UNIX,PDP11,[NUC-SECURE]
HOST NOSC-SDL,          2/3,SERVER,UNIX,PDP11,[NELC-ELF,NELC]
HOST NWC,               3/3,SERVER,EXEC-8,UNIVAC-1110
HOST NPRDC-11,          4/3,SERVER,UNIX,PDP11