Hi all,
I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
https://github.com/hveit01/pcs-munix.
MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus
workstations in the 80's. They were
based on Motorola 68020 CPUs on a DEC QBUS.
The interesting feature of this kernel is the integration of the
Newcastle Connection network
(https://en.wikipedia.org/wiki/Newcastle_Connection) which I found,
beyond a tech report https://assets.cs.ncl.ac.uk/TRs/175.pdf, no further
references for.
The kernel source was reverse engineered and verified (see readme in the
distribution who this was done) from the binary tape at
ftp.informatik.uni-stuttgart.de/pub/cm/pcs/sw/IS0371P.tap (Computer
museum of the University of Stuttgart), and to my knowledge reveals the
Newcastle connection code for the first time in a commercial Unix.
The Github package includes the kernel sources, i/O drivers, several
standard libraries, the disassembled boot ROM and for reference, two of
my tools, a partial syscall emulator pcsrun which allowed me to run the
C compiler and other native binaries outside the PCS hardware/Unix
environment, and a disassembler pcsdis for the specific COFF dialect
(note that IDA will produce garbage without a specific patch).
Regards
Holger
I've been looking into the history of the nl command lately, which has gotten me curious as to what facilities folks have used at various points in UNIX history for line numbering.
The earliest version of nl I've found is in System III, and it does not derive from Research, PWB, or CB. Neither does it come from BSD, although BSD has the num command which, according to the source commentary, aims to replicate the '#' behavior of ex.
Were there any other facilities for printing back arbitrary lines from a file with line numbers?
Also, would anyone happen to know if the above appearance of nl might have been from the USG line given none of the others feature it? It neither seems to be in V8-V10. nl has managed to find its way into the POSIX standard, so it definitely has some staying power wherever it came from.
- Matt G.
Good morning everyone. Wanted to pose the question since folks here would probably be more likely to know than anyone.
What are the chances that there are surviving tapes of some of the UNIX versions that weren't so well publicized. The versions that come to mind are the CB and USG lines especially, with PWB 2.0 and TS 4.0 getting honorable mention. If folks will recall, we did luck out in that Arnold, a member of this mailing list, did have a documentation trove from TS 4.0, but no binary or source code assets. This had me curious on what trying to unearth these would even look like.
Has anyone tried to dive deep on this sort of stuff before? Would it look more like trying to find old Bell facilities that might have a tape bumping around in a box in a basement somewhere, or is it more likely that if anything survived it would have been due to being nabbed by an employee or contractor before disposal? Or even just in general, what would folks say is the likelihood that there is a recoverable tape of any of this material just waiting to see the light of day? The closest we have on CB is a paper scan of the kernel sources, and I don't know that any assets from USG-proper have ever percolated up, closest thing to any of that would be the kernel routine description bumping around on the archive somewhere. PWB 2.0 is mentioned in several places, but no empirical evidence has surfaced as far as I know, and with 4.0 of course we have the documents Arnold thankfully preserved, but that's it.
Thanks in advance for any insight or thoughts. My concern is that there is a rapidly closing window on ever being able to properly preserve these parts of the UNIX story, although recognition must be paid to all of the hard work folks have done here thus far to keep this valuable part of computing history in the collective consciousness and accessible to researchers and programmers for years and years to come.
- Matt G.
P.S. Even more honorable mention is the Bell Interdata 8/32 work. I've read several places that never saw outside distribution, but I would have to wonder if any of that work survived beyond the visible portability changes in V7.
I didn't expect to have more documents to share this soon, but I've just secured a trove of early System V/5.0 documents, as listed:
System V User's Manual
System V Administrator's Manual
System V Error Message Manual
System V Transition Aids
System V Release Description
User's Guide
Operator's Guide
Administrator's Guide
Programming Guide
Graphics Guide
Support Tools Guide
Document Processing Guide
The System V-prefixed ones are very specifically labeled System V, although I know at least of the User's and Administrator's Manuals with "Release 5.0" branding out in the wild as well. I've got two of the User's Manuals exhibiting this difference. I believe I've seen a scan of the Admin's Manual with 5.0 as well, but I would have to go searching for it, it's on bitsavers perhaps? In any case, this is the documentation series for the initial releases of System V, the ones with "UNIX System" in big letters with grid patterns fading out into the background. I don't know if the second set is considered part of the Release 5.0 or System V version of the document package, or if they made that distinction, but as of present I can positively identify the first 5 as being specifically for the System V version of this release. What is particularly curious is there are documents displaying "System V" but with a Western Electric logo on the front. I've seen a scan of a System V gold User's Manual with the logo removed and a disclaimer on the front page explaining that they can't use the Bell logo anymore due to the divestiture, likewise on bitsavers I'm pretty sure, so this may establish that there were at least three revisions: Release 5.0, System V pre-divestiture, and System V post-divestiture.
Now for a little plug, just because she's been so incredibly helpful, I bought these from Leslie (last name unknown) known as "oldmaddogshop" on eBay. We got chatting for a little while and her husband was a computing professor at the University of Portland for some time as it sounds, and they're currently starting to go through the decades of literature and hardware he's picked up over the years for sale on eBay and perhaps other avenues. She very specifically mentioned a PDP-8 that he happens to have that he's hoping they can coordinate to donate to a museum or some other way to get it into a relatively publicly accessible space rather than winding up in the closet of a private collector. I told her I'd drop a brief mention in letting folks know about the documents in case they'd want the option of perusing some of what they're going to be offloading. She made mention of a stack of USENIX manuals as well, I have a smattering of 4.2 and 4.3 manuals already, so someone may be lucky enough to snag those soon enough. Up currently are an early SVID and some OSF/Motif stuff, but she said they've got plenty of boxes of books to go through.
Anywho, once I receive these documents, I plan on starting the scanning process much like with the UNIX/TS 4.0 stuff, and will be in touch with Warren concerning hosting and a release as time goes on. One bit of input if anyone knows, does the above list represent (aside from Release 5.0 variants) the complete documentation package for System V gold? I can't say I've come across any other titles, and most certainly haven't seen PDFs of anything that isn't included here, but I see plenty of titles I've never seen scanned. If nothing else, I'm hoping that "Release Description" document may have a brief flyover of the published materials, akin to the list of books at the beginning of the SVR4 manuals or the documentation roadmaps of earlier UNIX/TS and PWB releases.
- Matt G.
> Any ideas on why businesses didn’t pick up the H11 in 1980?
> [priced too high for hobbyists]
>
> Wikipedia says:
>
> 1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”)
> display advert <http://www.decodesystems.com/heathkit-h11-ad-1.gif> $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ?
>
> 1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.”
> ( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files)
Note that those are nominal prices. In terms of purchasing power USD 1595 in 1978 equated about USD 2200 in 1981 (https://www.in2013dollars.com/us/inflation/1978?endYear=1981&amount=1595)
Otherwise agree with your observation on packaged, off-the-shelf software being the main driver. In small business before the IBM PC, Visicalc drove Apple II uptake; Wordstar, C-Basic 2 and DBase drove CP/M uptake.
Would LSI-11 hardware with LSX, ed and nroff have been competitive in small business? The experiences of John Walker (of AutoCAD fame) suggests not:
https://www.fourmilab.ch/documents/marinchip/
> While looking for something else, I found this:
>
> VAX-UNIX Networking Support Project Implementation Description
> Robert F. Gurwitz; January, 1981
> https://www.rfc-editor.org/ien/ien168.txt
>
> in a somewhat obscure location. I have no idea if it's already widely known
> or not, but here it is anyway.
Hi Noel,
Thank you for highlighting this document. I had seen it before and the implementation (as found on the tapes from CSRG and now on THUS) follows the plan outlined in IEN168 quite closely. The first snapshot of the code is just a few months after this document.
In a way it is modeled after the UoI Arpanet Unix implementation (and thank you again for finding that source!), with a separate (kernel) process for network activity. In my experiments I have found that it is not all that easy to get smooth network data flow as this network process is difficult to schedule just right. I now better understand why Joy moved to "software interrupts” to get better scheduling of kernel network operations.
Wbr,
Paul
While looking for something else, I found this:
VAX-UNIX Networking Support Project Implementation Description
Robert F. Gurwitz; January, 1981
https://www.rfc-editor.org/ien/ien168.txt
in a somewhat obscure location. I have no idea if it's already widely known
or not, but here it is anyway.
Noel
> Also, another problem with trying to 'push' LSX into a previously
> un-handled operating regions (e.g. large disks, but there are likely
> others) is that there are probably things that are un-tested in that
> previously unused operating mode, and there may be un-found bugs that
> you trip across.
'Speak of the devil, and hear the sound of his wings.'
>> From: Gavin Tersteeg
>> Interestingly enough, existing large V6 RK05 images can be mounted,
>> read from, and written to. The only limitations on these pre existing
>> images is that if enough files are deleted, the system will randomly
>> crash.
> I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and
> alloc.c), but I couldn't quickly find the cause; it isn't obvious.
I don't know if the following is _the_ cause of the crashes, but another
problem (another aspect of the '100 free inodes cache' thing) swam up out of
my brain. If you look at V6's alloc$ifree(), it says:
if(fp->s_ninode >= 100)
return;
fp->s_inode[fp->s_ninode++] = ino;
LSX's is missing the first two lines. So, if you try and free more than 100
inodes on LSX, the next line will march out of the s_inode array and smash
other fields in the in-core copy of the super-block.
Like I said, this is not certain to be the cause of those crashes; and it's
not really a 'bug' (as in the opening observation) - but the general sense of
that observation is right on target. LSX is really designed to operate only
on disks with less than 100 inodes, and tring to run it elsewhere is going to
run into issues.
How many similar limitations exist in other areas I don't know.
> From: Heinz Lycklama <heinz(a)osta.com>
> Remember that the LSX and Mini-UNIX systems were developed for two
> different purposes.
Oh, that's understood - but this just re-states my observation, that LSX was
designed to operate in a certain environment, and trying to run it elsewhere
is just asking for problems.
Noel
{I was going to reply to an earlier message, but my CFS left me with
insufficient energy; I'll try and catch up on the points I was goibf to make
here.}
> From: Gavin Tersteeg
> This leaves me with about 1.9kb of space left in the kernel for
> additional drivers
I'm curious how much memory you have in your target system; it must not be a
lot, if you're targeting LSX.
I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a
negative way; it's just recognition that LSX has had a lot of corners
trimmed, to squeeze it down as much as possible), and some of those trims
behind some of the issues you're having (below).
At the time the LSI-11 came out, semiconductor DRAM was just getting started,
so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core
memory cards :-), to produce the 40KB target for LSX systems, was then a
reasonable configuration. These days, one has to really search to find
anything smaller than 64KB...
It might be easier to just run MINI-UNIX (which is much closer to V6, and
thus a known quantity), than add a lot of things back in to LSX to produce
what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS
memory for the machine.
> the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of
> inodes. This maxed the number of files on a disk to 96, but even with
> the maximum circumvented LSX would only tolerate a maximum of 101 files.
And here you're seeing the 'lobotomizing' of LSX come into play. That '101'
made me suspicious, as the base V6 'caches' 100 free inodes in the
super-block; once those are used, it scans the ilist on disk to refill it.
The code in alloc$ialloc in LSX is hard to understand (there are a lot of
#ifdef's), and it's very different from the V6 code, but I'm pretty sure it
doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you
can have as many free inodes on a disk as you want, but LSX will never use
more than the first 100.
(Note that the comment in the LSX source "up to 100 spare I nodes in the
super block. When this runs out, a linear search through the I list is
instituted to pick up 100 more." is inaccurate; it probably wasn't updated
after the code was changed. ISTR tis is true of a lot of the comments.)
Use MINI-UNIX.
> A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX,
> but any attempt to create files on it will fail.
The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's
empty when you start out. The LSX ialloc() says:
if(fp->s_ninode > 0) {
...
}
u.u_error = ENOSPC;
return(NULL);
which would produce what you're seeing.
Also, another problem with trying to 'push' LSX into a previously un-handled
operating regions (e.g. large disks, but there are likely others) is that
there are probably things that are un-tested in that previously unused
operating mode, and there may be un-found bugs that you trip across.
Use MINI-UNIX.
> Interestingly enough, existing large V6 RK05 images can be mounted,
> read from, and written to. The only limitations on these pre existing
> images is that if enough files are deleted, the system will randomly crash.
I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c),
but I couldn't quickly find the cause; it isn't obvious. (When unlinking a
file, the blocks in the file have to be freed - that's inode 'ip' - and the
directory - inode 'pp' - has to be updated; so it's pretty complicated.)
Use MINI-UNIX.
> The information there about continuous files ... will be extremely
> helpful if I ever try to make those work in the future.
My recollection is that the LSX kernel doesn't have code to create contiguous
files; the LSX page at the CHWiki says "the paper describing LSX indicates
there were two separate programs, one to allocate space for such files, and
one to move a file into such an area, but they do not seem to be extant". If
you find them, could you let me know? Thanks.
Noel
The MERT (Multi-Environment Real-Time) system was developed
at Bell Telephone Laboratories in Murray Hill, NJ by myself and
Doug Bayer in the mid 1970's on a DEC PDP 11/45 computer.
MERT was picked up by the UNIX Support Group (USG) in 1977 and
has been distributed and supported throughout the Bell System.
The MERT Manual consists of both the MERT Programmer's
Manual and the UNIX Programmer's Manual. You can find
all of this documentation at:
1. https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/
The hosting of this manual online was made possible by Clem Cole's
painstaking efforts to scan in and organize the hundreds of pages
in the hard copy MERT Manual. Clem had previously scanned in
my Technical Memoranda documenting my work at Bell Labs in
the 1970's on MERT, LSX, Mini-UNIX and the Mini-Computer
Satellite Processor System:
2.
https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/
The monthly UNIX Technology Advisor newsletter published
in 1989 and 1990 contains articles written by some of the leading
open systems industry pioneers. The first issue is available online here:
3. https://www.tuhs.org/Archive/Documentation/Unix_Advisor/
I want to thank Warren Toomey for providing and maintaining
the TUHS.org <https://www.tuhs.org/> platform for the hosting of this
historical information
on UNIX systems for the community.
Heinz Lycklama
