TUHS January 2020

tuhs@tuhs.org

110 participants
92 discussions

More oldies but goodies available if anyone wants them

by Jon Steinhart

Kind of scary what's in my basement. For those of you building UNIX workstations in the early days, I have a big fat notebook full of Weitek floating point chip specs, many of which are marked as preliminary. Also a set of CORBA specs. Again, low-hanging fruit that's getting recycled unless anyone has a use for them. In the not completely sure that I want to part with them yet for some strange reason, I have a set of SunOS manuals. Also, if anyone collects old hardware I have a SparcStation 20 with a slightly modified SunOS sitting around and an Ultra 60 Solaris box. Jon

4 years, 3 months

Re: [TUHS] Spider (and back to quiz)

by Paul Ruizendaal

There is more in that issue of BSTJ, and indeed it seems this was a precursor. https://ia801905.us.archive.org/25/items/bstj51-6-1147/bstj51-6-1147_text.p… https://ia801603.us.archive.org/0/items/bstj51-6-1167/bstj51-6-1167_text.pdf The first paper makes mention of repeaters starting to self oscillate, and a redesign being underway. There is a possibility that a Unix PDP11 was connected to this earlier network prior to Spider existing, in which case the accepted quiz answer would be wrong. >> Ugh. Memory lane has a lot of potholes. This was a really long time ago. > > Many thanks for that post - really interesting! > > I had to look up "Pierce Network", and found it described in the Bell Journal: > https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.p… > > In my reading the Spider network is a type of Pierce network. > > However, the network that you remember is indeed most likely different from Spider: > - it was coax based, whereas the Spider line was a twisted pair > - there was more than one, whereas Spider only ever had one (operational) loop > > Condon and Weller are acknowledged in the report about Spider as having done many of its hardware details. The report discusses learnings from the project and having to tune repeaters is not among them (but another operational issue with its 'line access modules’ is discussed). > > All in all, maybe these coax loops were pre-cursors to the Spider network, without a switch on the loop (“C” nodes in the Pierce paper). It makes sense to first try out the electrical and line data protocol before starting work on higher level functions. > > I have no idea what a GLANCE G is...

4 years, 3 months

Another oldie but goodie available if anyone wants it [ DECNET ]

by Jon Steinhart

Was looking for my DomainOS manuals and came across a fat notebook containing the DECNET Phase III spec. Anyone want it? Not anything that I need to keep and low-hanging fruit on the decluttering list. Jon

4 years, 3 months

Re: [TUHS] Spider

by Paul Ruizendaal

> I have vague memories here that maybe Heinz can help with if his are any better. > I believe that Sandy played a part in "the loop" or "the ring" or whatever it > was called that we had connecting our Honeywell 516 to peripherals. I do > remember the 74S00 repeaters because of the amount of time that Dave Weller > spent tuning them when the error rate got high. Also, being a loop, Joe > Condon used to pull his connectors out of the wall whenever people weren't > showing up to a meeting on time. I don't know whether our network was a > forerunner to the spider network. It most likely was Spider - it became operational in 1972. The vist report that I linked to earlier also says: "The current system contains just one loop with the switching computer (TEMPO I), four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers, and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are connected in turn to other items of digital equipment.” It would be interesting to know more about the H516’s and Spider, any other recollections?

4 years, 3 months

Spider [was: Unix quix]

by Paul Ruizendaal

I can answer some of the below, as I was looking into that a few years ago. > 81. Q: What was the first Unix network? > A: spider > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier > project. > > When did Alexander G Fraser's spider cell network happen? For that matter, > when did Datakit happen? I can't find references to either start date on > line (nor anything on spider except for references to it in Dr Fraser's > bio). I can find references to Datakit in 1978 or so. Spider was designed between 1969 and 1974 - the final lab report (#23) dates from December 1974. It was based around a serial loop running at T1 signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about Spider, second half about Datakit). It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure. There is an interesting visit report from 1975 that discusses some of the stuff that was done with Spider here: https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf Beyond those experiments I think Spider usage was limited to file serving (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was used for remote login, but I have not found any traces of such usage. Same for email usage. From what little I know, I think that Datakit became operational in a test network in 1979 and as a product in 1982. > I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix > in late 1974 or early 1975 from the University of Illinois dating from that > time (the code in TUHS appears to be based on V6 + a number of patches). “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of 1974. To my best knowledge they used V5 and migrated to V6 as it came along. I think they were getting regular update tapes, and they implemented their system as a device driver (plus userland support) to be able to keep up with the steady flow of updates. Greg Chesson was also involved with this Arpanet Unix. As far as I can tell, Arpanet Unix saw fairly wide deployment within the Arpanet research community, also as a front end processor for other systems. A few years back I asked on this list why “Network Unix” was not more enthusiastically received by the core Unix development team and (conceptually) integrated into the main code base. I understood the replies as that (i) people were very satisfied with Spider; and (ii) being part of Bell they wanted a networking system that was more compatible with the Bell network, i.e. Datakit. == In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long conceptual shadow. From Spider onwards, the Research systems viewed the network as a device (Spider), that could be multiplexed (V8 streams) or even mounted (Plan9). The Arpa lineage saw the network as a long distance bidirectional pipe, with the actual I/O device hidden from view; this view persists all the way to 4.2BSD and beyond. I often wonder if it was (is?) possible to come up with a design with the conceptual clarity of Plan9, but organised around the “network as a pipe” view instead.

4 years, 3 months

Unix quix

by Rob Pike

I reposted the original Unix quiz, which disappeared when public Google Plus was turned off. Answers will reappear in a few days. https://commandcenter.blogspot.com/2020/01/unix-quiz.html -rob

4 years, 3 months

"Network Unix" (i.e. Arpanet Unix)

by Paul Ruizendaal

> Because we can't ask Greg sadly, I think the Holmgren is the last around that would know definitively and I've personally lost track of him. Steve Holmgren and the Arpanet Unix team are still around (at least they were 3 years ago). I just remembered that I put some of my notes & findings in a draft wiki that I wanted to develop for TUHS - but I never finished it: http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networki… The recent find of CSRG report 3 and 4 may be the incentive I needed to complete my notes about 4.1a, 4.1c and 4.2BSD. However, still looking for the actual source tape to 4.1a - the closest I have is its derivative in 2.9BSD (https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net)

4 years, 3 months

Apollo Domain/OS

by Pete Wright

Apologies that this isn't specifically a Unix specific question but I was wondering if anyone had insight in running domain/OS and it's relationship to Plan 9 (assuming there is any). One of my early mentors was a former product person at Apollo in Mass. and was nice enough to tell me all sorts of war stories working there. I had known about Plan9 at the time, and from what he described to me about domain/OS it sounded like there was lots of overlap between the two from a high level design perspective at the least. I've always been keen to understand if domain/OS grew out of former Bell Labs folks, or how it got started. As an aside, he gifted me a whole bunch of marketing collateral from Apollo (from before the HQ acquisition) that i'd be happy to share if there is any historical value in that. At the time I was a video/special effects engineer are was amazed at how beneficial having something like domain/OS or Plan9 would have been for us, it felt we were basically trying to accomplish a lot of the same goals by duct taping a bunch of Irix and Linux systems together. Cheers, -pete -- Pete Wright pete(a)nomadlogic.org @nomadlogicLA

4 years, 3 months

Re: [TUHS] Unix on Zilog Z8000?

by Paul Ruizendaal

My memory failed me: the part numbers were Z8001/Z8002 for the original and Z8003/Z8004 for the revised chips (segmented/unsegmented). Hence it is unlikely that the Onyx had any form of demand paging (other than extending the stack in PDP11-like fashion). —— A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/ Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse. I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction. If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging. Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production. > Message: 7 > Date: Tue, 21 Jan 2020 21:32:51 +0000 > From: Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> > To: The Unix Heritage Society mailing list <tuhs(a)tuhs.org> > Subject: [TUHS] Onyx (was Re: Unix on Zilog Z8000?) > Message-ID: <20200121213251.GA25322(a)clarinet.employees.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote: >> The Onyx box redated all the 68K and later Intel or other systems. > > That was a fun bit of grubbing around courtesy of a bitsavers mirror > (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/). > > It seems they started with a board based upon the non-segmented Z8002 > and only later switched to using the segmented Z8001. In the initial > board, they created their own MMU: > > Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C… > > Memory Management Controller: > > The Memory Management Controller (MMC) enables the C8002 to perform > address translation, memory block protection, and separation of > instruction and data spaces. Sixteen independent map sets are > implemented, with each map set consisting of an instruction map and > a data map. Within each map there are 32 page registers. Each page > register relocates and validates a 2K byte page. The MMC generates > a 20 bit address allowing the C8002 to access up to one Mbyte of > physical memory. > > So I'd guess the MMC was actually programed through I/O instuctions > to io space, and hence preserved the necessary protection domains. > > Cute. I've had a background interest in the Z8000 (triggered by reading > a Z80000 datasheet around 87/88), and always though about using > the segmented rather than unsegmented device. > > The following has a bit more info about the version of System III > ported to their boxes: > > https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3… > > DF

4 years, 3 months

Re: [TUHS] Unix on Zilog Z8000?

by Paul Ruizendaal

A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/ Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse. I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction. If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging. Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production. > Message: 7 > Date: Tue, 21 Jan 2020 21:32:51 +0000 > From: Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> > To: The Unix Heritage Society mailing list <tuhs(a)tuhs.org> > Subject: [TUHS] Onyx (was Re: Unix on Zilog Z8000?) > Message-ID: <20200121213251.GA25322(a)clarinet.employees.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote: >> The Onyx box redated all the 68K and later Intel or other systems. > > That was a fun bit of grubbing around courtesy of a bitsavers mirror > (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/). > > It seems they started with a board based upon the non-segmented Z8002 > and only later switched to using the segmented Z8001. In the initial > board, they created their own MMU: > > Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C… > > Memory Management Controller: > > The Memory Management Controller (MMC) enables the C8002 to perform > address translation, memory block protection, and separation of > instruction and data spaces. Sixteen independent map sets are > implemented, with each map set consisting of an instruction map and > a data map. Within each map there are 32 page registers. Each page > register relocates and validates a 2K byte page. The MMC generates > a 20 bit address allowing the C8002 to access up to one Mbyte of > physical memory. > > So I'd guess the MMC was actually programed through I/O instuctions > to io space, and hence preserved the necessary protection domains. > > Cute. I've had a background interest in the Z8000 (triggered by reading > a Z80000 datasheet around 87/88), and always though about using > the segmented rather than unsegmented device. > > The following has a bit more info about the version of System III > ported to their boxes: > > https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3… > > DF

4 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS January 2020