I know branch and link was in the 360; was it earlier? And ... anybody know
who invented it?
This came up in a risc-v meeting just now :-) My claim is that if anybody
knows, they will be in this group.
> From: ron minnich
> I know branch and link was in the 360; was it earlier?
Well, as I understand it, branch and link (BAL and BALR) did a couple of
different things (if I have this wrong, I hope someone will correct me). It
was a subroutine call, but it also loaded a base register.
(Those were used to deal with the /360's bizarro memory management, which was
not 'base and bounds, with a user's virtual address space starting at zero',
like a lot of contemporary machines. Rather, a process saw its actual physical
memory location, so depending on where in memoty a process was loaded, it
would be executing at different addresses visible to it; the base registers
were used to deal with that. This made swapping complicated, since it had to
be swapped back in to the same location.)
Which function of BALR are you enquiring about? The subroutine call part?
> From: Angelo Papenhoff
> The Whirlwind used the A register for this purpose. ...
> Might be earlier than this, I just happen to know the Whirlwind
> somewhat well. It's late 40s machine, so you probably won't find
> anything *much* older.
The only machines older than Whirlwind I know of are the ACE (design;
not implemented until later) and EDVAC.
I have ACE stuff, but i) the documentation is really wierd, and hard to read,
and ii) it's really bizarre (it didn't have opcodes; different registers did
different things). There were subroutines written for it, but it's not clear
how they were called.
The EDVAC, the only thing I have on it is von Neumann's draft, and it's
even harder to read than Turing's ACE Report!
Noel
All,
I have revised my Research Unix Version 6 instructions for 2022, in part to
support the change to OpenSSH and also to bring it along into the modern
era (I did it on my Monterey instance). I updated the links, cleaned up
some lingering issues, and confirmed it working.
Please take a look and let me know if you find any issues,
misrepresentations, missing pieces, etc. I haven't touch v6 in a while, but
it was fun to reminisce.
http://decuser.blogspot.com/2022/10/installing-and-using-research-unix.html
Regards,
Will
>> Looking at net_vdh.h, it seems to be a "VDH-11C"
>> ...
>> I wasn't able to find anything out about it at all. (I have some
>> hardcopy manuals for other ACC IMP interface products, and I was going
>> to look in them to see if any of them listed its manual in a 'see
>> also', but I can't find them.)
> From: Lars Brinkhoff
> Noel Chiappa wrote:
>> Did VDH PDP-11's have a special VDH interface
> Sorry, no idea.
That was a semi-rhetorical question; after I typed it, I did some looking,
and came up with the answer above, the ACC VDH-11.
I did eventually find the hardcopy manuals for other ACC IMP interface
products, but none of them mention the VDH11.
On a hunch, I looked to see if there was a VDH11 driver for ELF, and
sure enough, there was:
https://github.com/pdp11/elf-operating-system/blob/master/files/kdvdh.m11%5…
(If anyone wants to look at it, ktbl.sml hold the register definitions.)
With no manual for the device, and no museum catalog hits to show that
someone has one which hasn't been scanned in yet, that's probably a dead end,
although with the two drivers, one could probably mock up a rudimentary
programmming manual.
I'm not sure there's any point, though; using an LH/DH interface is going to
work as well, and those device are already supported.
> From: Paul Ruizendaal
> impio.c: available here:
Thanks for chasing those all down; I knew the BBN system was based on the NCP
Unix (called in this discussion the 'NOSC' system), so I figured it would
have the missing files, in some form.
Looking at a diff between the damaged impio.c in the NOSC tree, and the
impio.c in the BBN tree, there are some changes (in the section where we have
both versions) between the NOSC one and the BBN one, but it will probably be
possible to take the missing piece off the bank end of the BBN one and tack
it on to the NOSC one.
Somewhere in the document scans available online from DOD, there used to
be a long thing from the UIUC people who did the original NCP Unix. I don't
know if it included source; it might have.
Noel
Berkeley Tague says he invited John to work with the USG in 1978
[ AUUG, below. Also by Ronda Hauben in multiple places ]
[ In two ‘recollections’ / history docs sourced from UNSW, ]
[ the first visit was misremembered as 1976 or 1977. ]
I was wondering when John's two other sabbaticals to Bells Labs were.
The Peter Ivanov interview with John in “Unix Review”, 1985, notes two sabbaticals by then.
After writing the celebrated Commentary on the UNIX Operating System in 1976,
Lions was asked to spend two sabbaticals at the Labs.
This comment in 2000 on “9fans” from Rob Pike
says John also visited in 1989,
but sadly his work by then had been affected.
<https://marc.info/?l=9fans&m=144372955601968&w=2>
Anyone know when the other visit was?
Presumably 1983 or 1984 if John took a semester off every 5 years.
========
In AUUGN Oct 1995, V16 #5, there’s a collection of emails, an ‘interview’ with John
PDF pages 17 & 24
<https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V16.5.pdf>
Berkeley Tague says in 1978 he invited John to work with the USG.
then
He wanted to come to Murray Hill for his sabbatical so it was a win/win situation.
He spent two or three summers at Bell Labs over the years
and supplied us with many of his graduate students
for sabbaticals and permanent employment.
Later:
AUUGN:
What have been the professional highlights of your career?
JL:
For myself, three sabbaticals at Bell Laboratories have been highlights.
For my students, opportunities arose for employment at the Laboratories.
========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
> From: Michael Casadevall
> sys4.c is entirely corrupted, and part of impio.c is cut off
The copy on MIT-CSR (the origin of the copy at TUHS) has the same issues. I
doubt it's possible to recover them from that system; you'll have to find
some other way to recover them (perhaps through a dump of the BBN system), or
re-code them (as you did with sys4.c).
> I do need to do a readthrough for the VDH driver ... I think that might
> be for the radio links to Hawaii and the UK?
No. Read BBN 1822.
The LH and DH bit-serial physical interfaces only work up to about 1000 feet
or so. (Less for LH; DH is logically idential to LH, but uses differential
pairs - the LH is single-sided). VDH is, in the bottom layer, simply a
synchronous serial link, allowing the host to be up to hunreds of miles from
the IMP.
> From: Lars Brinkhoff
> 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.
Did VDH PDP-11's have a special VDH interface, or did they simply use an
off-the-rack DEC synchronous serial interface like a DU11? (More of them
here:
http://gunkies.org/wiki/Category:DEC_Synchronous_Serial_Interfaces
if anyone wants.) Looking at net_vdh.h, it seems to be a "VDH-11C"
Looking online, the VDH-11 seems to be an ACC prodict, but I wasn't able to
find anything out about it at all. (I have some hardcopy manuals for other
ACC IMP interface products, and I was going to look in them to see if any of
them listed its manual in a 'see also', but I can't find them.)
I'm not sure why people did just use an off-the-rack DEC synchronous serial
interface; maybe the VDH11 did a BBN specific CRC, or something (in addition
to using DMA; mostr DEC sync interfaces didn't, IIRC)?
Anyway, you don't want to use VDH.
Noel
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
>> 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.
That is what the “V6 with TCP” on TUHS is:
Following the success of NCP Unix, it became a base for various TCP experiments in the ’77-’79 era. The first was an implementation by Jack Haverty, that wrapped an existing TCPv2 stack that was written in PDP-11 assembler into a Unix application. It ran in user mode and depended on Rand ports and several extensions that Jack added to the kernel (await/capac and a user mode timing variable, where the clock routine incremented a variable in user space). He used a PDP-11 with little core and the pipes (ports) did not stay in the file buffers, but flushed onto disk. This killed performance: Jack recalls that a bad run would average a few characters per second.
Next Mike Wingfield wrote a TCPv4 stack in C, more or less using the architecture of the above. It was the “winner" of the December 1979 bake-off. I think it is the first TCPv4 implementation for Unix and maybe the oldest surviving source for TCPv4 overall. I wanted to try if it would still interoperate with modern TCP/IP, but I never got around to that. An actual printout survives in the SRI archives and I painstakingly retyped that source, just weeks before Noel found the right tapes :^). Later still, Craig Partridge found a full report and listing in the BBN archives (report no. 3724). This NCP Unix with the Wingfield library is the version that is labeled “BBN V6 with TCP” on TUHS.
Some of the code in the Wingfield stack is to test the protocol. Arpanet essentially offers circuit switching, and some of the code is there to simulate dropped packets, out-of-order packets, etc. It also tested security features that were under consideration, but subsequently dropped as interest shifted to end-to-end encryption.
Again, user mode TCP was not found to be practical, the 16-bit era was ending and that is when Rob Gurwitz was assigned to write a new stack for the VAX (1980). By that time Jack Haverty was his boss. Some parts of the BBN VAX-TCP design still echo the user space origins and experiences of the BBN team in the immediate years before. This stack I got working and it still interoperates with modern TCP/IP (at least it did some 5 years ago).
Jack Haverty can easily be reached via the internet-history mailing list.
I’ve summarised the history here: http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networki…
I should transfer it to the TUHS wiki or to Gunkies one of these days.
===
I am not sure I understood which files are missing or corrupted and in which NCP Unix trees. Noel retrieved the files from old (mouldy even) tapes so some corruption is quite possible. Pulling together material from various sources can hopefully lead to a working source tree. Glad to help.
Further note that NCP Unix was initially developed on 5th Edition, but soon migrated to 6th edition. I am sure that the various installations tracked new developments and installed extra bits and pieces. The surviving images are from 1979 and for sure would have picked up bits from newer releases and other sources (such as the Uni of Calgary buffer extensions).
Paul
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=…
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