From tuhs at tuhs.org Sun Mar 1 02:08:38 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Sat, 28 Feb 2026 11:08:38 -0500 (EST) Subject: [TUHS] Can PDP-11/23 PLUS run Unix? Message-ID: <20260228160838.76B2B18C084@mercury.lcs.mit.edu> > From: Phil Budne > V7M has overlays Ah, the CHWiki doesn't have a page for that system; I'll have to add it. Yes, it does seem to have had _kernel_ overlays before 2.9 (I looked, to see if I could find any direct credit in 2.9, to indicate that their support for kernel overlays came from V7M, but couldn't; I'm too lazy to do sources compares). I say "_kernel_ overlays" because I gather (see some evidence, below) that use-of/support-for overlays in _processes_, in user mode, preceded use-of/support-for overlays in the kernel. See: "Running Large Text Processes on Small Unix Systems", Charles Haley, William Joy, William F. Jolitz https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/doc/ovpap "We describe a set of simple modifications to the Unix system, which permit larger programs to be run than has previously been possible. In particular, the 'f77' and 'a68' compilers and version 2 of the 'ex' editor, which previously would not run on the non-separate I/D machines such as the 11/23, 11/34 and 11/40, may be run, without source code modification, using this scheme. This scheme will also allow processes larger than 65K bytes of instruction space to run on all 11/ cpu's with segmentation hardware. and: "How to use the UNIX Automatic Text Overlays: A Tutorial", Barbara Bekins, Bill Jolitz https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/doc/ovtutorial The former unfortunately does not have a date on it; the latter has a date of 10/20/81, but we can infer that the original work was before that. It does appear to be later than "The Second BSD" (1979-04); there's nothing about overlats that I could find there.. V7M contains notes that more or less state that its use-of/support-for overlays in the kernel is based on the prior support for overlays in _processes_, done at Berkeley: This directory contains the C overlay loader and some other junk. ... Covld is derived from Bill Joy's covld .. The paper in ovpap.n describes the original Berkeley overlayed text scheme which was intended for use in user mode programs. I use overlays only for the kernel itself. https://www.tuhs.org/cgi-bin/utree.pl?file=V7M/src/cmd/covld/README I also have a memory that someone did some work that allowed large amounts of disk buffers (and maybe clists too), which were not statically mapped into kernel address space; one segment was used to map them in, as needed. Can anyone point me at anything which covers that? (URL's would be a big plus!) I will add all that (and this) to the appropriate places in the CHWiki. I understand that all these kludges were not really important; in the long run, they were dead ends. I just want to see them all documented, and credit correctly assigned (as above, for the code overlays). Noel From tuhs at tuhs.org Sun Mar 1 04:11:21 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 28 Feb 2026 18:11:21 +0000 Subject: [TUHS] Ongoing UNIX Manual Scans In-Reply-To: References: Message-ID: On Thursday, February 26th, 2026 at 09:30, segaloco via TUHS wrote: > Hello, starting a new thread for a new round of UNIX manual scans I'm > going to be working up over the next few months. To start it all off, > here is the cover and introductory pages from the December, 1983 manual > UNIX System V Release 2.0 Programmer Reference Manual, known on-line as > "p_man". > > https://archive.org/details/unix-system-v-release-2-programmer-reference-manual-btl-edition > > ... > > - Matt G. > The above scan is now complete, and so I've now started on the corresponding User Manual: https://archive.org/details/unix-system-v-release-2-user-reference-manual-btl-edition Like the previous link, this is a BTL internal version that includes a number of pieces not found in the stock SVR2 manuals, including various microprocessor development tools as well as WWB. I'll let folks know when it is entirely scanned. For now, like last time, it is just the cover and man0 content until I get the manpages themselves scanned. - Matt G. From tuhs at tuhs.org Sun Mar 1 08:51:24 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 1 Mar 2026 08:51:24 +1000 Subject: [TUHS] Fwd: London and Reiser's UNIX VAX port paper, reconstructed Message-ID: ----- Forwarded message from "G. Branden Robinson" Date: Sat, 28 Feb 2026 16:48:08 -0600 From: "G. Branden Robinson" Subject: London and Reiser's UNIX VAX port paper, reconstructed [CCing Warren for help with my usual problems mailing the TUHS list] Hi folks, I'm pleased to report that I've "finalized" my reconstruction of London and Reiser's paper documenting the process of porting Seventh Edition Unix to the VAX-11/780. This effort started back in mid-2024, and drove numerous improvements to groff's mm package. You can find the reconstruction at GitHub, with a pre-rendered PDF under "Released". My thanks to everyone who helped; you're acknowledged in the paper itself. :) Regards, Branden ----- End forwarded message ----- From tuhs at tuhs.org Sun Mar 1 08:53:04 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 1 Mar 2026 08:53:04 +1000 Subject: [TUHS] Fwd: London and Reiser's UNIX VAX port paper, reconstructed In-Reply-To: References: Message-ID: On Sun, Mar 01, 2026 at 08:51:24AM +1000, Warren Toomey via TUHS wrote: > ----- Forwarded message from "G. Branden Robinson" > I'm pleased to report that I've "finalized" my reconstruction of London > and Reiser's paper documenting the process of porting Seventh Edition > Unix to the VAX-11/780. https://github.com/g-branden-robinson/reconstructing-unix-32v-port-paper is the Github repository. Cheers, Warren From tuhs at tuhs.org Mon Mar 2 19:50:19 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 02 Mar 2026 11:50:19 +0200 Subject: [TUHS] Other Bell Labs shells from the 80s? Message-ID: <202603020950.6229oMxK017045@freefriends.org> Hello all. The CL memo was interesting, in a way. The notations are clearly much more verbose than the standard shell, and I found that a little off-putting. The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever happened to that? Are source and or the memo for it available somewhere? Also it refers to a shell by Blewett and arder called Parser. Anyone have that memo? Just wondering, Thanks, Arnold From tuhs at tuhs.org Mon Mar 2 19:58:35 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 02 Mar 2026 02:58:35 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: <202603020950.6229oMxK017045@freefriends.org> References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: <202603020958.6229wZg6017415@freefriends.org> Arnold Robbins via TUHS wrote: > Also it refers to a shell by Blewett and arder called Parser. Anyone ... and another called Parser. ... Sheesh. Not enough coffee this morning I guess. From tuhs at tuhs.org Tue Mar 3 04:03:40 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 2 Mar 2026 11:03:40 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: <202603020958.6229wZg6017415@freefriends.org> References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: there was a lisp shell ca 1977. I always liked the idea. there were a lot of shells out there, like the REX shell. On Mon, Mar 2, 2026 at 1:58 AM Arnold Robbins via TUHS wrote: > Arnold Robbins via TUHS wrote: > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > ... and another called Parser. ... > > Sheesh. Not enough coffee this morning I guess. > From tuhs at tuhs.org Tue Mar 3 06:59:41 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Tue, 3 Mar 2026 07:59:41 +1100 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: Self promotion: the v8 shell was underseen. Not really even what people want in shells these days, but in its own environment it worked well and its principle of all its output being valid shell input is missing from most interactive tools to this day. -rob On Tue, Mar 3, 2026 at 5:04 AM ron minnich via TUHS wrote: > > there was a lisp shell ca 1977. I always liked the idea. > > there were a lot of shells out there, like the REX shell. > > > > On Mon, Mar 2, 2026 at 1:58 AM Arnold Robbins via TUHS > wrote: > > > Arnold Robbins via TUHS wrote: > > > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > > > ... and another called Parser. ... > > > > Sheesh. Not enough coffee this morning I guess. > > From tuhs at tuhs.org Tue Mar 3 07:30:26 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 2 Mar 2026 16:30:26 -0500 Subject: [TUHS] Other Bell Labs shells from the 80s? Message-ID: > there were a lot of shells out there Much to the credit of Multics innovation, brought to you by Ken's mythical man-month. Doug From tuhs at tuhs.org Tue Mar 3 08:11:16 2026 From: tuhs at tuhs.org (Reese Johnson via TUHS) Date: Mon, 2 Mar 2026 17:11:16 -0500 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: Message-ID: Hello, I just noticed this is the first post I've ever seen from this list. Thank you so much to the person that added me. I hope everybody has a good day today. I really love Unix. 73 DE KN4NTU - Reese On Mon, Mar 02, 2026 at 04:30:26PM -0500, Douglas McIlroy via TUHS wrote: > > there were a lot of shells out there > > Much to the credit of Multics innovation, brought to you by Ken's > mythical man-month. > > Doug From tuhs at tuhs.org Tue Mar 3 08:33:26 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 3 Mar 2026 08:33:26 +1000 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: That "output is valid input" thing totally was what I wanted, I played with making PS1 and PS2 elements which did not prevent cut-paste making valid commands and it never quite worked for me. Not the same, but related. I think as a killer feature, that definitely counts as one. Modern shell behaviour being "nice" makes the output and command history very hard to just replay if it's a complex command. I frequently make intermediate commands in piped sequences emit shell which is then executed, because you can run it without the final | sh to see what it will do, and then do it. So my command streams in construction are often echo "thing to be done" =G On Tue, Mar 3, 2026 at 7:00 AM Rob Pike via TUHS wrote: > Self promotion: the v8 shell was underseen. Not really even what > people want in shells these days, but in its own environment it worked > well and its principle of all its output being valid shell input is > missing from most interactive tools to this day. > > -rob > > On Tue, Mar 3, 2026 at 5:04 AM ron minnich via TUHS wrote: > > > > there was a lisp shell ca 1977. I always liked the idea. > > > > there were a lot of shells out there, like the REX shell. > > > > > > > > On Mon, Mar 2, 2026 at 1:58 AM Arnold Robbins via TUHS > > wrote: > > > > > Arnold Robbins via TUHS wrote: > > > > > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > > > > > ... and another called Parser. ... > > > > > > Sheesh. Not enough coffee this morning I guess. > > > > From tuhs at tuhs.org Tue Mar 3 08:45:21 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Mon, 2 Mar 2026 14:45:21 -0800 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: <20260302224521.GB27230@mcvoy.com> On Tue, Mar 03, 2026 at 08:33:26AM +1000, George Michaelson via TUHS wrote: > That "output is valid input" thing totally was what I wanted, I played with > making PS1 and PS2 elements which did not prevent cut-paste making valid > commands and it never quite worked for me. Not the same, but related. > > I think as a killer feature, that definitely counts as one. Modern shell > behaviour being "nice" makes the output and command history very hard to > just replay if it's a complex command. > > I frequently make intermediate commands in piped sequences emit shell which > is then executed, because you can run it without the final | sh to see what > it will do, and then do it. So my command streams in construction are often > echo "thing to be done" Isn't this sort of solved by "set -x". lm goes and tries it. Welp, not so much: $ echo foo + echo foo foo $ ls | wc + ls -C + wc 377 381 3851 The set -x doesn't keep the pipeline so yeah, I see the problem. Or one of them. From tuhs at tuhs.org Tue Mar 3 09:13:45 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Tue, 3 Mar 2026 10:13:45 +1100 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: On Tue, 3 Mar 2026 at 09:33, George Michaelson via TUHS wrote: > That "output is valid input" thing totally was what I wanted, I played with > making PS1 and PS2 elements which did not prevent cut-paste making valid > commands and it never quite worked for me. Not the same, but related. > That's why 'rc' and 'es' use ';' and ';;', respectively, as prompts. From tuhs at tuhs.org Tue Mar 3 09:30:56 2026 From: tuhs at tuhs.org (Paul McJones via TUHS) Date: Mon, 2 Mar 2026 15:30:56 -0800 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: <177249152689.1801233.9831702167961447275@minnie.tuhs.org> References: <177249152689.1801233.9831702167961447275@minnie.tuhs.org> Message-ID: <827E8BF2-FE25-4626-AE8F-512DADF33728@mcjones.org> > Date: Mon, 2 Mar 2026 11:03:40 -0700 > From: ron minnich > Subject: [TUHS] Re: Other Bell Labs shells from the 80s? > To: arnold at skeeve.com > Cc: tuhs at tuhs.org > > there was a lisp shell ca 1977. I always liked the idea. > > there were a lot of shells out there, like the REX shell. Here’s the paper on the LISP shell: John R. Ellis. 1980. A LISP Shell. SIGPLAN Notices, Volume 15, Issue 5 (May 1980), pages 24-34. http://doi.acm.org/10.1145/947639.947642 It was built on Forrest Howard’s Harvard Lisp for the PDP-11: https://softwarepreservation.computerhistory.org/LISP/other.html#Harvard_LISP_ From tuhs at tuhs.org Tue Mar 3 17:30:56 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Tue, 3 Mar 2026 18:30:56 +1100 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: Yes, rc shares that property at least to some extent. Try % whatis cd to see what I mean. -rob On Tue, Mar 3, 2026 at 10:14 AM Noel Hunt via TUHS wrote: > > On Tue, 3 Mar 2026 at 09:33, George Michaelson via TUHS > wrote: > > > That "output is valid input" thing totally was what I wanted, I played with > > making PS1 and PS2 elements which did not prevent cut-paste making valid > > commands and it never quite worked for me. Not the same, but related. > > > > That's why 'rc' and 'es' use ';' and ';;', respectively, as prompts. From tuhs at tuhs.org Tue Mar 3 18:01:54 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 03 Mar 2026 01:01:54 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: Message-ID: <202603030801.62381sHC010624@freefriends.org> It took me a while to figure out the references... Douglas McIlroy via TUHS wrote: > > there were a lot of shells out there > > Much to the credit of Multics innovation, Which was that the command interpreter was "just" a user level program that could be replaced. > brought to you by Ken's mythical man-month. The weeks when his wife was on vacation and he turned his filesystem into an OS. Did I get them right? Thanks, Arnold From tuhs at tuhs.org Tue Mar 3 18:06:06 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 03 Mar 2026 01:06:06 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: <202603030806.623866Rd011025@freefriends.org> Thanks Marc. Warren, can this go into the archive? It seems that with the invetion of /dev/fd, David Korn managed to provide a notation for non-linear pipelines: diff <(pipeline1) <(pipeline2) sets up the two pipelines, with the standard output of each dup'ed to different file descriptors and diff sees something like diff /dev/fd/41 /dev/fd/42 Bash provides this, and will use FIFOs if /dev/fd isn't available. I'm not sure it counts as fully two dimensional. Thanks, Arnold Marc Rochkind wrote: > The 2dsh shell came up in a discussion some months ago here, and Doug > McIlroy kindly provided me with a copy of the memo, which I've attached. > > I'm sure the source is long gone. It was really just a hobby research > project for me. (I spent part of my time at Bell Labs horsing around. What > a great place to work!) > > Marc > > On Mon, Mar 2, 2026 at 2:57 AM Arnold Robbins via TUHS > wrote: > > > Hello all. > > > > The CL memo was interesting, in a way. The notations are clearly > > much more verbose than the standard shell, and I found that a little > > off-putting. > > > > The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever > > happened to that? Are source and or the memo for it available somewhere? > > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > have that memo? > > > > Just wondering, > > > > Thanks, > > > > Arnold > > From tuhs at tuhs.org Tue Mar 3 23:05:51 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Tue, 03 Mar 2026 05:05:51 -0800 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: > That "output is valid input" thing totally was what I wanted, I played with > making PS1 and PS2 elements which did not prevent cut-paste making valid > commands and it never quite worked for me. Not the same, but related. I have had this in ~/.env for as long as I can remember: cd () { command cd "$@" && setprompt } setprompt () { PS1=": `id -un`@`hostname -s`:$(pwd -L); " } export PS1 setprompt --lyndon From tuhs at tuhs.org Wed Mar 4 01:50:33 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 03 Mar 2026 15:50:33 +0000 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: I always detested the CSH. The problem was the Sys5 Bourne shell didn’t support the BSD job control. So, I spent the time to figure out how it worked in csh (the kernel calls are not exactly well documented), and hacked it into /bin/sh. Even that wasn’t enough to convince my coworkers to switch as they were now using the tcsh. So, ,I put command line editing (to a better implementation having been working on gosmacs at the time) into /bin/sh. I used it for as long as I was at BRL. By the time I left, the Korn shell was beginning to make its way out of the labs. I do remember sitting at a USENIX having a nice discussion of shell internals with Dave. I also explained carefully to the guys working on one of the open source shells how it all worked so they could implement it. For a long time googling my name got shell manual pages all over the place as the programmers gave me credit. Years after the fact I was working for my intelligence imagery company and we did a lot of work with loaner equipment (our software being ultraportable we worked on MIPS, Dec Alpha, Itanium, Suns and SGIs of various configurations Apollo, HP Oki, Masspar, Cray, DG, Stellar, Ardent, NeXT, IBM (from PCs to RS/6000 to mainframes) etc…). Usually the first thing I did is port emacs (having never really learned vi I always impressed my office mates with how fast I could do stuff with ed) and one of the shells (pdksh usually). Anyhow, I’m sitting at a machine and type “fg” at the coknsole absentmindedly. It comes back with “Job Control Not Enabled”. Hmm… that sounds familiar. I type “set -J” which was the command to turn on Job Control in my version fo the SysV shell and it replies with “Job Control Enabled.” Holy crap, this is a “ron shell.” After a bit of tracing I found that Doug Gwyn had put my shell on the SystemV on BSD distribution tapes. Then Mach fully included that distribution in theirs, so every one with mach derived source had a “ron shell” for /bin/sh. From tuhs at tuhs.org Wed Mar 4 17:55:23 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 04 Mar 2026 00:55:23 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: <202603040755.6247tNjQ018520@freefriends.org> Ron, Doug Gwyn distributed your changes with his "System 5 on top of BSD" tape, which we had at Georgia Tech. As I recall it, the version we had did not have command line editing, neither csh-style nor vi/emacs style. I went through your changes and backported them to the 4.2 BSD Bourne shell (Boune-gol, anyone?), and posted the diffs to USENET. I also wrote a csh-style history mechanism for the Bourne shell and I'm pretty sure posted it as well. I did other hacking on the System V shell; Rob sent me the V8 sh(1) man page and that inspired me to do a whatis command that knew how to pretty-print shell functions. I may have done a "builtin" command and changed the order so that function were found first, but I don't remember. This would all have been circa 1983-1985. In any case, Ron, I was very grateful for your efforts, as I detested csh's syntax, and refused to use it, even though it meant not having job control. Later on we got ksh86 at Georgia Tech, and I switched to that for day-to-day use, and then even later on when I was at Emory to ksh88. At some point I also made a few contributions to pdksh; my name used to be listed in the doc for it. Upon moving to Linux, Bash became my daily driver and I've been quite happy with it for well over 25 years now (thanks Chet!) Arnold Ron Natalie via TUHS wrote: > I always detested the CSH. The problem was the Sys5 Bourne shell > didn’t support the BSD job control. So, I spent the time to figure out > how it worked in csh (the kernel calls are not exactly well documented), > and hacked it into /bin/sh. Even that wasn’t enough to convince my > coworkers to switch as they were now using the tcsh. So, ,I put > command line editing (to a better implementation having been working on > gosmacs at the time) into /bin/sh. I used it for as long as I was at > BRL. By the time I left, the Korn shell was beginning to make its way > out of the labs. I do remember sitting at a USENIX having a nice > discussion of shell internals with Dave. I also explained carefully > to the guys working on one of the open source shells how it all worked > so they could implement it. For a long time googling my name got shell > manual pages all over the place as the programmers gave me credit. > > Years after the fact I was working for my intelligence imagery company > and we did a lot of work with loaner equipment (our software being > ultraportable we worked on MIPS, Dec Alpha, Itanium, Suns and SGIs of > various configurations Apollo, HP Oki, Masspar, Cray, DG, Stellar, > Ardent, NeXT, IBM (from PCs to RS/6000 to mainframes) etc…). > > Usually the first thing I did is port emacs (having never really learned > vi I always impressed my office mates with how fast I could do stuff > with ed) and one of the shells (pdksh usually). > > Anyhow, I’m sitting at a machine and type “fg” at the coknsole > absentmindedly. It comes back with “Job Control Not Enabled”. Hmm… > that sounds familiar. I type “set -J” which was the command to turn on > Job Control in my version fo the SysV shell and it replies with “Job > Control Enabled.” > Holy crap, this is a “ron shell.” After a bit of tracing I found that > Doug Gwyn had put my shell on the SystemV on BSD distribution tapes. > Then Mach fully included that distribution in theirs, so every one with > mach derived source had a “ron shell” for /bin/sh. From tuhs at tuhs.org Wed Mar 4 19:31:46 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Wed, 04 Mar 2026 09:31:46 +0000 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: (Ron Natalie via TUHS's message of "Tue, 03 Mar 2026 15:50:33 +0000") References: <202603020950.6229oMxK017045@freefriends.org> <202603020958.6229wZg6017415@freefriends.org> Message-ID: <7wikbcndod.fsf@junk.nocrew.org> Ron Natalie wrote: > Even that wasn’t enough to convince my coworkers to switch as they > were now using the tcsh. I guess they wanted to feel like 10X programmers. From tuhs at tuhs.org Fri Mar 6 04:20:02 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 05 Mar 2026 18:20:02 +0000 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup Message-ID: Hi everyone, this is something I don't usually broach but I'm realizing there may be an opportunity here. This document stuff ain't cheap, and I've been bankrolling all my own preservation efforts for some time. I wanted to test the waters to see how folks would feel about crowdsourcing some funding for a preservation effort. I'm fully prepared to fund this myself but wanted to share: https://www.ebay.com/itm/257390793755 After the link is what may be the complete set of tapes and support materials from the AT&T Videotape Library. I posted a thread about this program previously and it seemed to be relatively unknown or at least not very discussed. Now I'm staring down the potential of landing and preserving the whole thing. Anywho my solicitation for donations to the process is for a few reasons: - The auction starts at $350, is probably going to go up significantly. - I do not currently own VHS archiving hardware, I've been waiting for an opportunity like this to make the investment, so would have more costs than just the auction itself. - Just a week ago I closed on a magtape transport with read/write heads so I can fix it up (hopefully) and start considering some magtape jobs too. Wasn't cheap, so still figuring out amortizing that one somehow. Thanks for any consideration. I don't plan on opening up the factory and showing how the sausages are made often, but this is one I want to make sure I don't miss out on over funding. I have no idea when all these VHS tapes will surface again. - Matt G. From tuhs at tuhs.org Fri Mar 6 04:28:57 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Thu, 5 Mar 2026 10:28:57 -0800 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: References: Message-ID: On 3/5/26 10:20 AM, segaloco via TUHS wrote: > I want to make sure I don't miss out on over funding. As someone who has been doing this for decades, all I can do is roll my eyes and say "wow"... From tuhs at tuhs.org Fri Mar 6 04:38:17 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 05 Mar 2026 18:38:17 +0000 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: References: Message-ID: On Thursday, March 5th, 2026 at 10:29, Al Kossow via TUHS wrote: > On 3/5/26 10:20 AM, segaloco via TUHS wrote: > > I want to make sure I don't miss out on over funding. > > As someone who has been doing this for decades, all I can do is roll > my eyes and say "wow"... > > > If CHM wants to be finder here and take this over, no skin off my nose, I don't have any sort of institutional/professional backers, I'm just a guy with a flatbed scanner and some office space to setup a few more tools. - Matt G. From tuhs at tuhs.org Fri Mar 6 05:37:57 2026 From: tuhs at tuhs.org (Jason T via TUHS) Date: Thu, 5 Mar 2026 13:37:57 -0600 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: References: Message-ID: On Thu, Mar 5, 2026, 12:20 segaloco via TUHS wrote: > > I wanted to test the waters to see how folks would feel about > crowdsourcing some funding for a preservation effort. I'm fully prepared > to fund this myself but wanted to share: > > > > Is the current bid on that item yours? The seller has a lot of AT&T listings, including a few other video tape sets. I don't know what makes up the entire library (not sure if anyone does). A good strategy might be to convince him to bundle all of the tape sets for a much lower price. J From tuhs at tuhs.org Fri Mar 6 05:51:44 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 05 Mar 2026 19:51:44 +0000 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: References: Message-ID: <6cNp_OCXLRyuo4s3OOVILSOnoiSGimqhlPos6oD0ikEWgh4ik-WSF-vXWgwDReyhpZgbXErtxFRQ0vUZ5a4xZG8xd20P3lzMEJB1MvGJjR0=@protonmail.com> On Thursday, March 5th, 2026 at 11:38, Jason T via TUHS wrote: > On Thu, Mar 5, 2026, 12:20 segaloco via TUHS wrote: > > > > > I wanted to test the waters to see how folks would feel about > > crowdsourcing some funding for a preservation effort. I'm fully prepared > > to fund this myself but wanted to share: > > > > > > > > > Is the current bid on that item yours? > > The seller has a lot of AT&T listings, including a few other video tape > sets. I don't know what makes up the entire library (not sure if anyone > does). > > A good strategy might be to convince him to bundle all of the tape sets for > a much lower price. > > J > Hah, I should pay more attention. Turns out this is someone I helped label some AT&T terminals properly (they originally had a 55C terminal listed as a 3B1 since it was in a box with a bunch 3B1 docs). Given that history they might be willing to negotiate with me...I'll shoot them a message. - Matt G. From tuhs at tuhs.org Fri Mar 6 08:16:04 2026 From: tuhs at tuhs.org (babydr DBA James W. Laferriere via TUHS) Date: Thu, 5 Mar 2026 13:16:04 -0900 (AKST) Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: <6cNp_OCXLRyuo4s3OOVILSOnoiSGimqhlPos6oD0ikEWgh4ik-WSF-vXWgwDReyhpZgbXErtxFRQ0vUZ5a4xZG8xd20P3lzMEJB1MvGJjR0=@protonmail.com> References: <6cNp_OCXLRyuo4s3OOVILSOnoiSGimqhlPos6oD0ikEWgh4ik-WSF-vXWgwDReyhpZgbXErtxFRQ0vUZ5a4xZG8xd20P3lzMEJB1MvGJjR0=@protonmail.com> Message-ID: <03f24289-bb83-3ebc-2dfe-649a7c30bc2d@baby-dragons.com> On Thu, 5 Mar 2026, segaloco via TUHS wrote: > On Thursday, March 5th, 2026 at 11:38, Jason T via TUHS wrote: > >> On Thu, Mar 5, 2026, 12:20 segaloco via TUHS wrote: >> >>> I wanted to test the waters to see how folks would feel about >>> crowdsourcing some funding for a preservation effort. I'm fully prepared >>> to fund this myself but wanted to share: >>> >>> Is the current bid on that item yours? >> >> The seller has a lot of AT&T listings, including a few other video tape >> sets. I don't know what makes up the entire library (not sure if anyone >> does). >> >> A good strategy might be to convince him to bundle all of the tape sets for >> a much lower price. >> >> J > > Hah, I should pay more attention. Turns out this is someone I helped label some AT&T terminals properly (they originally had a 55C terminal listed as a 3B1 since it was in a box with a bunch 3B1 docs). > > Given that history they might be willing to negotiate with me...I'll shoot them a message. > > - Matt G. Did someone here grab this ??? https://www.ebay.com/itm/257380939623 Cuase it is sold now , But shows '0'(Zero) bids . Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From tuhs at tuhs.org Sat Mar 7 03:38:45 2026 From: tuhs at tuhs.org (Alex Bochannek via TUHS) Date: Fri, 06 Mar 2026 09:38:45 -0800 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: <202603020950.6229oMxK017045@freefriends.org> References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: Arnold Robbins via TUHS writes: > Hello all. > > The CL memo was interesting, in a way. The notations are clearly > much more verbose than the standard shell, and I found that a little > off-putting. > > The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever > happened to that? Are source and or the memo for it available somewhere? > > Also it refers to a shell by Blewett and arder called Parser. Anyone > have that memo? I received the scans of the 2dsh and the Parser memos. The Parser scan is pretty poor quality, but legible. What's interesting is that Parser makes reference to both the TOPS-20/TENEX EXEC as well as the Interlisp history facility. The latter of which is where C-Shell got its inspiration from as well. I noticed the location listed for Marc Rochkind is WH, which suspect was Whippany. But it lists "DR" for Blewett and Rader. What was the DR location of Bell Labs? -- Alex. From tuhs at tuhs.org Sat Mar 7 05:56:53 2026 From: tuhs at tuhs.org (Marc Rochkind via TUHS) Date: Fri, 6 Mar 2026 12:56:53 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: WH was indeed Whippany. DR was Denver (Westminster, CO, actually). Marc On Fri, Mar 6, 2026 at 10:40 AM Alex Bochannek via TUHS wrote: > Arnold Robbins via TUHS writes: > > > Hello all. > > > > The CL memo was interesting, in a way. The notations are clearly > > much more verbose than the standard shell, and I found that a little > > off-putting. > > > > The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever > > happened to that? Are source and or the memo for it available somewhere? > > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > have that memo? > > I received the scans of the 2dsh and the Parser memos. The Parser scan > is pretty poor quality, but legible. What's interesting is that Parser > makes reference to both the TOPS-20/TENEX EXEC as well as the Interlisp > history facility. The latter of which is where C-Shell got its > inspiration from as well. > > I noticed the location listed for Marc Rochkind is WH, which suspect was > Whippany. But it lists "DR" for Blewett and Rader. What was the DR > location of Bell Labs? > > -- > Alex. > From tuhs at tuhs.org Sat Mar 7 06:23:44 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 6 Mar 2026 13:23:44 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: Was DR the weird "satellite dish building" on 120th? Warner On Fri, Mar 6, 2026 at 12:57 PM Marc Rochkind via TUHS wrote: > WH was indeed Whippany. DR was Denver (Westminster, CO, actually). > > Marc > > On Fri, Mar 6, 2026 at 10:40 AM Alex Bochannek via TUHS > wrote: > > > Arnold Robbins via TUHS writes: > > > > > Hello all. > > > > > > The CL memo was interesting, in a way. The notations are clearly > > > much more verbose than the standard shell, and I found that a little > > > off-putting. > > > > > > The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever > > > happened to that? Are source and or the memo for it available > somewhere? > > > > > > Also it refers to a shell by Blewett and arder called Parser. Anyone > > > have that memo? > > > > I received the scans of the 2dsh and the Parser memos. The Parser scan > > is pretty poor quality, but legible. What's interesting is that Parser > > makes reference to both the TOPS-20/TENEX EXEC as well as the Interlisp > > history facility. The latter of which is where C-Shell got its > > inspiration from as well. > > > > I noticed the location listed for Marc Rochkind is WH, which suspect was > > Whippany. But it lists "DR" for Blewett and Rader. What was the DR > > location of Bell Labs? > > > > -- > > Alex. > > > From tuhs at tuhs.org Sat Mar 7 07:17:55 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Fri, 06 Mar 2026 21:17:55 +0000 Subject: [TUHS] Almquist shell Message-ID: For those interested in different shells, I discovered ash, the Almquist shell, while learning how to hack my WiFi extender. I found this page about it: https://www.in-ulm.de/~mascheck/various/ash/ Which contains a thank you to TUHS for archiving the traditional BSDs and 386BSD. Have a safe and interesting weekend, Cameron From tuhs at tuhs.org Sat Mar 7 08:56:18 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Fri, 06 Mar 2026 22:56:18 +0000 Subject: [TUHS] Almquist shell In-Reply-To: <75527984-a68e-6709-68ba-a1ffc375b5c5@makerlisp.com> References: <75527984-a68e-6709-68ba-a1ffc375b5c5@makerlisp.com> Message-ID: Thank you. I read about its performance giving faster shell script execution. I am just about to disappear down the Busybox rabbit hole but that's one for the COFF, I think. Best regards, Cameron -------- Original Message -------- On Friday, 03/06/26 at 22:35 Luther Johnson wrote: In recent releases, Debian has used a version of this shell they call 'dash', in their start-up scripts, so they are running in a strictly Bourne compatible shell, and so "bash-isms" don't creep into their scripts - before switching to dash, they were using bash. dash/ash probably helps with script performance, too. From tuhs at tuhs.org Sat Mar 7 09:57:50 2026 From: tuhs at tuhs.org (Marc Rochkind via TUHS) Date: Fri, 6 Mar 2026 16:57:50 -0700 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: Sort of. The building that was there when I got there in 1980 was much plainer, and behind it was a huge Western Electric factory that made PBXs. Much later, various parts of the Bell System changed hands, and a company called Avaya (or something like that) built that building in front. On Fri, Mar 6, 2026 at 1:23 PM Warner Losh wrote: > Was DR the weird "satellite dish building" on 120th? > > Warner > > On Fri, Mar 6, 2026 at 12:57 PM Marc Rochkind via TUHS > wrote: > >> WH was indeed Whippany. DR was Denver (Westminster, CO, actually). >> >> Marc >> >> On Fri, Mar 6, 2026 at 10:40 AM Alex Bochannek via TUHS >> wrote: >> >> > Arnold Robbins via TUHS writes: >> > >> > > Hello all. >> > > >> > > The CL memo was interesting, in a way. The notations are clearly >> > > much more verbose than the standard shell, and I found that a little >> > > off-putting. >> > > >> > > The memo's references refer to Marc Rochkind's 2dsh --- Marc, whatever >> > > happened to that? Are source and or the memo for it available >> somewhere? >> > > >> > > Also it refers to a shell by Blewett and arder called Parser. Anyone >> > > have that memo? >> > >> > I received the scans of the 2dsh and the Parser memos. The Parser scan >> > is pretty poor quality, but legible. What's interesting is that Parser >> > makes reference to both the TOPS-20/TENEX EXEC as well as the Interlisp >> > history facility. The latter of which is where C-Shell got its >> > inspiration from as well. >> > >> > I noticed the location listed for Marc Rochkind is WH, which suspect was >> > Whippany. But it lists "DR" for Blewett and Rader. What was the DR >> > location of Bell Labs? >> > >> > -- >> > Alex. >> > >> > From tuhs at tuhs.org Sat Mar 7 10:00:28 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Fri, 6 Mar 2026 19:00:28 -0500 Subject: [TUHS] Almquist shell In-Reply-To: References: Message-ID: And of course, don't forget the adventure shell. Get Doug Gwyn's copy from https://www.ifarchive.org/if-archive/shells/ From tuhs at tuhs.org Sat Mar 7 15:32:55 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sat, 07 Mar 2026 05:32:55 +0000 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: (Alex Bochannek via TUHS's message of "Fri, 06 Mar 2026 09:38:45 -0800") References: <202603020950.6229oMxK017045@freefriends.org> Message-ID: <7wtsuskxvc.fsf@junk.nocrew.org> Alex Bochannek wrote: > What's interesting is that Parser makes reference to both the > TOPS-20/TENEX EXEC as well as the Interlisp history facility. Is that scan available somewhere online? From tuhs at tuhs.org Sat Mar 7 15:34:26 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sat, 07 Mar 2026 05:34:26 +0000 Subject: [TUHS] Almquist shell In-Reply-To: (Rich Salz via TUHS's message of "Fri, 6 Mar 2026 19:00:28 -0500") References: Message-ID: <7wpl5gkxst.fsf@junk.nocrew.org> Rich Salz wrote: > And of course, don't forget the adventure shell. Get Doug Gwyn's copy from > https://www.ifarchive.org/if-archive/shells/ GET LAMP retrieves a web server suite. From tuhs at tuhs.org Sun Mar 8 05:19:10 2026 From: tuhs at tuhs.org (Alex Bochannek via TUHS) Date: Sat, 07 Mar 2026 11:19:10 -0800 Subject: [TUHS] Other Bell Labs shells from the 80s? In-Reply-To: <7wtsuskxvc.fsf@junk.nocrew.org> References: <202603020950.6229oMxK017045@freefriends.org> <7wtsuskxvc.fsf@junk.nocrew.org> Message-ID: Lars Brinkhoff writes: > Alex Bochannek wrote: >> What's interesting is that Parser makes reference to both the >> TOPS-20/TENEX EXEC as well as the Interlisp history facility. > > Is that scan available somewhere online? If anybody has an upload location where these documents ultimately make it into the TUHS archives, please let me know! -- Alex. From tuhs at tuhs.org Sun Mar 8 17:40:36 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 08 Mar 2026 00:40:36 -0700 Subject: [TUHS] Almquist shell In-Reply-To: References: Message-ID: <202603080740.6287ea6F068845@freefriends.org> Rich Salz via TUHS wrote: > And of course, don't forget the adventure shell. Get Doug Gwyn's copy from > https://www.ifarchive.org/if-archive/shells/ Relatively recently I found a C rewrite of that shell that I did. (Something I'd totally forgotten.) I think I'd have posted it to USENET but I don't remember. I really must have had too much time on my hands... :-) From tuhs at tuhs.org Sun Mar 8 17:51:20 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 08 Mar 2026 00:51:20 -0700 Subject: [TUHS] 2dsh doc uploaded to TUHS archive Message-ID: <202603080751.6287pK4F069542@freefriends.org> Giving credit where credit is due: - Doug McIlroy sent Marc Rochkind a scan of the 2dsh memo - Marc sent it to me - Clem Cole asked me for it - Clem placed it into the archive See https://www.tuhs.org/Archive/Documentation/Papers/2dsh.pdf Arnold From tuhs at tuhs.org Mon Mar 9 00:42:49 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sun, 08 Mar 2026 14:42:49 +0000 Subject: [TUHS] Fwd: Happy Bell Birthday Message-ID: Hello everyone, The following was posted, yesterday evening on the ICON [Insulator Collectors On the Net] mailing list. Have a safe Sunday! Cameron ---begin included message-- March 7, 2026 at 6:14 PM Today is the 150th anniv of the Bell System founding Jack Snyder, Erie, MI ---end included message--- From tuhs at tuhs.org Mon Mar 9 03:06:21 2026 From: tuhs at tuhs.org (Marc Rochkind via TUHS) Date: Sun, 8 Mar 2026 11:06:21 -0600 Subject: [TUHS] 2dsh doc uploaded to TUHS archive In-Reply-To: <202603080751.6287pK4F069542@freefriends.org> References: <202603080751.6287pK4F069542@freefriends.org> Message-ID: Thanks! On Sun, Mar 8, 2026 at 12:51 AM Arnold Robbins via TUHS wrote: > Giving credit where credit is due: > > - Doug McIlroy sent Marc Rochkind a scan of the 2dsh memo > - Marc sent it to me > - Clem Cole asked me for it > - Clem placed it into the archive > > See https://www.tuhs.org/Archive/Documentation/Papers/2dsh.pdf > > Arnold > From tuhs at tuhs.org Mon Mar 9 04:13:04 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 8 Mar 2026 14:13:04 -0400 Subject: [TUHS] 2dsh doc uploaded to TUHS archive In-Reply-To: References: <202603080751.6287pK4F069542@freefriends.org> Message-ID: Most welcome. Sent from a handheld expect more typos than usual On Sun, Mar 8, 2026 at 1:06 PM Marc Rochkind via TUHS wrote: > Thanks! > > On Sun, Mar 8, 2026 at 12:51 AM Arnold Robbins via TUHS > wrote: > > > Giving credit where credit is due: > > > > - Doug McIlroy sent Marc Rochkind a scan of the 2dsh memo > > - Marc sent it to me > > - Clem Cole asked me for it > > - Clem placed it into the archive > > > > See https://www.tuhs.org/Archive/Documentation/Papers/2dsh.pdf > > > > Arnold > > > From tuhs at tuhs.org Mon Mar 9 21:42:27 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 9 Mar 2026 17:12:27 +0530 Subject: [TUHS] Fwd: Happy Bell Birthday In-Reply-To: References: Message-ID: <20260309114227.4739BFB9A6C2@ary.local> It appears that Cameron Mí� eál Tyre via TUHS said: >March 7, 2026 at 6:14 PM > >Today is the 150th anniv of the Bell System founding Not really. It's the date that Bell's original telephone patent was issued. I'd say the Bell System was created on December 30, 1899 when a reverse merger made AT&T the parent company of the local and long distance companies. R's, John From tuhs at tuhs.org Mon Mar 9 23:22:07 2026 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Mon, 9 Mar 2026 09:22:07 -0400 Subject: [TUHS] Almquist shell In-Reply-To: References: Message-ID: <3c5dc7d5-18f3-41f5-830f-0a698fb1e451@case.edu> On 3/6/26 7:00 PM, Rich Salz via TUHS wrote: > And of course, don't forget the adventure shell. Get Doug Gwyn's copy from > https://www.ifarchive.org/if-archive/shells/ I used to ship this with bash, up through bash-4.2. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Tue Mar 10 05:04:54 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 09 Mar 2026 19:04:54 +0000 Subject: [TUHS] UNIX and USB Message-ID: So USB hits the scene in the mid-90s, the raucous 80s of UNIX had come to a close by this point and many original actors and architects were on to bigger and brighter things. In other words, the folks who designed terminal handling, block and character I/O, etc. were long since "retired" from helming the UNIX ship. This has me wondering, when USB hit the market, was there any attempt at a grand, unified "this is how UNIX does USB" around the industry or was implementation of drivers and interfacing largely left to individual shops? The reason I ask is I'm currently working up some tooling in the UNIX tradition for interacting with the RP2040 microcontroller (as opposed to their picotool and pico-sdk which are bulkier than what I want). What I'm currently tinkering with is something dd(1)-like that allows indicating things like I/O direction, packet type (control, bulk, etc.), payload, etc. for a very basic generic USB operation that could then be used on /dev files, as opposed to my current approach of writing a libusb-oriented monolith. Was there ever any sort of canonical basic USB packet tools operating on /dev entries in the UNIX ecosystem? Something making USB packet I/O a shell affair rather than libusb or custom kernel stuff/ioctls in a C application? Getting this far down into USB is pretty fresh for me BTW, so pardon any incorrect assumptions (e.g. whether stateless, individual process invocations could even reliably issue sequential USB transfers without potential transients introduced between invocations, claims and halt states between processes, etc.). - Matt G. From tuhs at tuhs.org Tue Mar 10 05:29:37 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 9 Mar 2026 13:29:37 -0600 Subject: [TUHS] UNIX and USB In-Reply-To: References: Message-ID: On Mon, Mar 9, 2026 at 1:05 PM segaloco via TUHS wrote: > So USB hits the scene in the mid-90s, the raucous 80s of UNIX had come to > a close by this point and many original actors and architects were on to > bigger and brighter things. In other words, the folks who designed > terminal handling, block and character I/O, etc. were long since "retired" > from helming the UNIX ship. > > This has me wondering, when USB hit the market, was there any attempt at a > grand, unified "this is how UNIX does USB" around the industry or was > implementation of drivers and interfacing largely left to individual shops? > > The reason I ask is I'm currently working up some tooling in the UNIX > tradition for interacting with the RP2040 microcontroller (as opposed to > their picotool and pico-sdk which are bulkier than what I want). What I'm > currently tinkering with is something dd(1)-like that allows indicating > things like I/O direction, packet type (control, bulk, etc.), payload, etc. > for a very basic generic USB operation that could then be used on /dev > files, as opposed to my current approach of writing a libusb-oriented > monolith. > > Was there ever any sort of canonical basic USB packet tools operating on > /dev entries in the UNIX ecosystem? Something making USB packet I/O a > shell affair rather than libusb or custom kernel stuff/ioctls in a C > application? > > Getting this far down into USB is pretty fresh for me BTW, so pardon any > incorrect assumptions (e.g. whether stateless, individual process > invocations could even reliably issue sequential USB transfers without > potential transients introduced between invocations, claims and halt states > between processes, etc.). > libusb has been the convergencec point for different implementations. The BSDs share a common API (more or less) because the original version was copied, but then diverged. Linux did its own thing. Other sytems also do their own thing, though some did port Linux or BSD stack over and diverge. There never was any attempt to make this be packet driven because that was a poor fit with ohci/uhci devices IIRC. That is, you couldn't really get the packats like that and even if you could the different endpoints and the need to configure made things complicated. Of course, this is me watching from the sidelines, so maybe I missed something? Warner From tuhs at tuhs.org Thu Mar 12 13:39:26 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 12 Mar 2026 03:39:26 +0000 Subject: [TUHS] Community Fund Re: AT&T UNIX VHS Backup In-Reply-To: References: Message-ID: <4W63x9TQR0DiLdymaLNMbo860RRIniaTXeBp-zwZd4kZwyLZYHf-yjNJpFQqS0apjFusAPMeOktdzFIWoBf-i5i2bh8yP8HXXbV9EZrr14o=@protonmail.com> On Thursday, March 5th, 2026 at 10:20, segaloco wrote: > I have no idea when all these VHS tapes will surface again. > > - Matt G. Well good news, now I don't have to know. Luckily I closed all three auctions that had parts of the VHS collection and nobody else bid, so was able to keep costs down. Along with these tapes looks like I'm going to wind up with a bunch of red-covered SVR2 and SVR3 literature. Not really hurting for those in my bookshelf so once I curate everything I might have a mess of mid 80s AT&T UNIX literature to resell/gift depending on who wants it. More to come once the tapes are in. - Matt G. P.S. Speaking of tapes, got a Kennedey tape transport for real cheap, appears to be read-write, gonna be boning up how to get it fixed up and interfaced with something reasonably modern, hopefully I can add some kind of magtape to my things I can backup soon! From tuhs at tuhs.org Mon Mar 23 18:56:07 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 23 Mar 2026 18:56:07 +1000 Subject: [TUHS] Ping Message-ID: Hi all, just checking that the TUHS list is still alive :-) Cheers, Warren From tuhs at tuhs.org Sat Mar 21 05:40:48 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 20 Mar 2026 19:40:48 +0000 Subject: [TUHS] UNIX In Bell Labs after SVR2 Message-ID: These manuals I am scanning currently demonstrate steady USG UNIX usage within Bell Laboratories for many, many years. As time went on and commercial UNIX crawled further and further away from Bell Labs-proper, research continued their own journey with V8 and on. Within the larger Bell Labs ecosystem, was there a particular leaning towards continued SysV use? Did these later research versions instead retake the hearts and minds of BTL facilities? Was it more of a free for all, with research, USG, BSD, etc. sprinkled throughout the various parts of Bell Labs? Most stuff I read from the mid 70s to mid 80s paints a very USG-centric picture, but I find myself curious on folks' recollections of the situation through the mid 80s and beyond, if any census or rough estimate of UNIX stream uptake in BTL exists. - Matt G. From tuhs at tuhs.org Tue Mar 17 23:03:59 2026 From: tuhs at tuhs.org (Adam Koszek via TUHS) Date: Tue, 17 Mar 2026 15:03:59 +0200 Subject: [TUHS] Bootstrapping UNIX - how was it done Message-ID: Hi, How was UNIX bootstrapped in the early days? Trying to piecemeal the story with regards to what hardware was available. This video: https://www.youtube.com/watch?v=_jefHB8IzoY Is showing what seems to be the later stage - UNIX up and running, practical things working. But the thumbnail is a famous Thomson + Richie, both in front of the teletype terminal and PDP machine in front of its light control panel. What editors were used for early B, B+, C and early kernel? For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. Adam From tuhs at tuhs.org Fri Mar 20 04:55:35 2026 From: tuhs at tuhs.org (Diomidis Spinellis via TUHS) Date: Thu, 19 Mar 2026 20:55:35 +0200 Subject: [TUHS] Bell Labs sed performance Message-ID: Over the past year I ported the (now {Free,Net,Open})BSD version of sed(1) I implemented in C in the 1990s into Rust as part of the uutils initiative. I've described the process in a series of four IEEE Software "Adventures in Code" [2] columns. In this March's column [3] I compare the performance of the Rust implementation against that of GNU, FreeBSD, and the original 1970s Bell Labs Seventh Research Edition one [6]. Amazingly, in four benchmarks the Bell Labs implementation is still the fastest. At 1850 lines of code (including a regular expression engine) it's also the smallest one (FreeBSD, 2672 LoC; GNU 5462; Rust, 8946). Admittedly, modern sed versions have more features. Still, one can only admire the design and craftsmanship that went into the original implementation. [1] https://github.com/uutils/sed [2] https://www.spinellis.gr/adventures-in-code.html [3] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=11433192 [4] https://github.com/dspinellis/sed-research-v7 From tuhs at tuhs.org Mon Mar 23 19:17:20 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 23 Mar 2026 10:17:20 +0100 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: <521447E8-EB18-460D-9B7A-FC899FA50196@tuhs.org> Have a read of this to start: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.pdf Cheers, Warren On 17 March 2026 2:03:59 pm GMT+01:00, Adam Koszek via TUHS wrote: >Hi, > >How was UNIX bootstrapped in the early days? > >Trying to piecemeal the story with regards to what hardware was available. This video: > >https://www.youtube.com/watch?v=_jefHB8IzoY > >Is showing what seems to be the later stage - UNIX up and running, practical things working. But the thumbnail is a famous Thomson + Richie, both in front of the teletype terminal and PDP machine in front of its light control panel. > >What editors were used for early B, B+, C and early kernel? > >For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. > >Adam -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Mon Mar 23 19:19:58 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 23 Mar 2026 10:19:58 +0100 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: Also the first few chapters of the PDF linked here: https://wiki.tuhs.org/doku.php?id=publications:quarter_century_of_unix Cheers, Warren On 17 March 2026 2:03:59 pm GMT+01:00, Adam Koszek via TUHS wrote: >Hi, > >How was UNIX bootstrapped in the early days? > >Trying to piecemeal the story with regards to what hardware was available. This video: > >https://www.youtube.com/watch?v=_jefHB8IzoY > >Is showing what seems to be the later stage - UNIX up and running, practical things working. But the thumbnail is a famous Thomson + Richie, both in front of the teletype terminal and PDP machine in front of its light control panel. > >What editors were used for early B, B+, C and early kernel? > >For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. > >Adam -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Mon Mar 23 20:11:18 2026 From: tuhs at tuhs.org (John P. Linderman via TUHS) Date: Mon, 23 Mar 2026 06:11:18 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: > > >How was UNIX bootstrapped in the early days? > > When I started at the Labs in 1973, what eventually morphed into the Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was sufficiently flakey at that time that they liked to reboot the system each day to clean up corruption in the file system. Someone noticed that I arrived before 6 am every morning, when a reboot would go unnoticed by most people. So I was taught how to halt the system, set a bunch of keys on the front of the 45, and hit start. I'm guessing that the keys simply directed the 45 to read a boot block from some device, and execute the instructions in that block, where the real software bootstrapping began. I'm sure others in this group can supply the correct details. I was not then, and still am not now, a hardware person, but I remain an early riser. -- jpl From tuhs at tuhs.org Mon Mar 23 20:13:28 2026 From: tuhs at tuhs.org (Hellwig Geisse via TUHS) Date: Mon, 23 Mar 2026 11:13:28 +0100 Subject: [TUHS] Ping In-Reply-To: References: Message-ID: <6091156bde478e954cad4e9ea3e84ec773a4d346.camel@mni.thm.de> On Mon, 2026-03-23 at 18:56 +1000, Warren Toomey via TUHS wrote: > Hi all, just checking that the TUHS list is still alive :-) > Cheers, Warren *pong* ;-) And a big "thank you" for maintaining the list! Hellwig From tuhs at tuhs.org Mon Mar 23 20:49:29 2026 From: tuhs at tuhs.org (John P. Linderman via TUHS) Date: Mon, 23 Mar 2026 06:49:29 -0400 Subject: [TUHS] Bell Labs sed performance In-Reply-To: References: Message-ID: Russ Cox has written extensively about regular expression matching, and why some "features", like backtracking, may not be a good idea. -- jpl On Mon, Mar 23, 2026 at 5:05 AM Diomidis Spinellis via TUHS wrote: > Over the past year I ported the (now {Free,Net,Open})BSD version of > sed(1) I implemented in C in the 1990s into Rust as part of the uutils > initiative. I've described the process in a series of four IEEE > Software "Adventures in Code" [2] columns. In this March's column [3] I > compare the performance of the Rust implementation against that of GNU, > FreeBSD, and the original 1970s Bell Labs Seventh Research Edition one > [6]. Amazingly, in four benchmarks the Bell Labs implementation is > still the fastest. At 1850 lines of code (including a regular > expression engine) it's also the smallest one (FreeBSD, 2672 LoC; GNU > 5462; Rust, 8946). Admittedly, modern sed versions have more features. > Still, one can only admire the design and craftsmanship that went into > the original implementation. > > [1] https://github.com/uutils/sed > [2] https://www.spinellis.gr/adventures-in-code.html > [3] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=11433192 > [4] https://github.com/dspinellis/sed-research-v7 > From tuhs at tuhs.org Mon Mar 23 22:00:47 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 23 Mar 2026 06:00:47 -0600 Subject: [TUHS] UNIX In Bell Labs after SVR2 In-Reply-To: References: Message-ID: <202603231200.62NC0lGS000960@freefriends.org> The Bell System continued to use System V for quite a while. There was a small division within DEC that was responsible for continuing to keep SVR3.x running on Vaxen, just to be able to sell to the Bell companies. (Even though their official product, Ultrix, was BSD-based.) Even as UNIX became commercial, many of the big companies (HP, IBM) aligned on the System V side, with selling to the Bells undoubtedly part of the reason, as well as the fact that the "official source" (``they're the guys who own UNIX'') was AT&T. BSD was well known, and many vendors pulled in bits and pieces of BSD (csh, vi, sometimes kernel bits) and glommed them onto their SV systems. segaloco via TUHS wrote: > These manuals I am scanning currently demonstrate steady USG UNIX usage within Bell Laboratories for many, many years. As time went on and commercial UNIX crawled further and further away from Bell Labs-proper, research continued their own journey with V8 and on. Within the larger Bell Labs ecosystem, was there a particular leaning towards continued SysV use? Did these later research versions instead retake the hearts and minds of BTL facilities? Was it more of a free for all, with research, USG, BSD, etc. sprinkled throughout the various parts of Bell Labs? Most stuff I read from the mid 70s to mid 80s paints a very USG-centric picture, but I find myself curious on folks' recollections of the situation through the mid 80s and beyond, if any census or rough estimate of UNIX stream uptake in BTL exists. > > - Matt G. From tuhs at tuhs.org Mon Mar 23 23:01:56 2026 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Mon, 23 Mar 2026 06:01:56 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: As I remember, the 11/70 was booted just as John describes. One keyed in a boot loader at the console. On Mon, Mar 23, 2026 at 3:11 AM John P. Linderman via TUHS wrote: > > > > > >How was UNIX bootstrapped in the early days? > > > > When I started at the Labs in 1973, what eventually morphed into the > Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was > sufficiently flakey at that time that they liked to reboot the system each > day to clean up corruption in the file system. Someone noticed that I > arrived before 6 am every morning, when a reboot would go unnoticed by most > people. So I was taught how to halt the system, set a bunch of keys on the > front of the 45, and hit start. I'm guessing that the keys simply directed > the 45 to read a boot block from some device, and execute the instructions > in that block, where the real software bootstrapping began. I'm sure others > in this group can supply the correct details. I was not then, and still am > not now, a hardware person, but I remain an early riser. -- jpl From tuhs at tuhs.org Mon Mar 23 23:15:38 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 23 Mar 2026 09:15:38 -0400 Subject: [TUHS] Bell Labs sed performance In-Reply-To: References: Message-ID: DIomidis's note is a welcome tribute to its creator, Lee McMahon, perhaps the least well known member of the original Unix cohort. He reported to the Visual and Acoustics Research Center, not CSRC. A linguist and former Jesuit seminarian, Lee brought a strong liberal-arts perspective to the team and played a central role in the first Unix text-analysis project, statistical study of the Federalist papers in the tradition of Frederick Mosteller. The project exploited the nascent software toolkit. At least one Unix staple came out of the project, Lee's comm(1). Sed, Lee's biggest software-tool contribution, made its debut in v7. Calling attention to it, the introduction to the v7 manual said, "It is well worth learning". Although sed has been widely upstaged by awk, it stands as a beacon of power and simplicity.. Both had 3-page entries in the manual, but awk requires one to know C, while sed's only prerequisite is ed. Outside of Unix, Lee, Ken, Joe Condon and others made TPC (The Phone Company), a demonstration telephone switch, which ran many phones in 1127 for several years, and, more importantly, influenced the architecture of #5 ESS, AT&T's workhorse switch. Lee conceived TPC's basic software architecture of one process per device, in contrast to previous architectures' process-per-call or process-per function. Doug On Mon, Mar 23, 2026 at 6:49 AM John P. Linderman via TUHS wrote: > > Russ Cox has written extensively about > regular expression matching, and why some "features", like backtracking, > may not be a good idea. -- jpl > > On Mon, Mar 23, 2026 at 5:05 AM Diomidis Spinellis via TUHS > wrote: > > > Over the past year I ported the (now {Free,Net,Open})BSD version of > > sed(1) I implemented in C in the 1990s into Rust as part of the uutils > > initiative. I've described the process in a series of four IEEE > > Software "Adventures in Code" [2] columns. In this March's column [3] I > > compare the performance of the Rust implementation against that of GNU, > > FreeBSD, and the original 1970s Bell Labs Seventh Research Edition one > > [6]. Amazingly, in four benchmarks the Bell Labs implementation is > > still the fastest. At 1850 lines of code (including a regular > > expression engine) it's also the smallest one (FreeBSD, 2672 LoC; GNU > > 5462; Rust, 8946). Admittedly, modern sed versions have more features. > > Still, one can only admire the design and craftsmanship that went into > > the original implementation. > > > > [1] https://github.com/uutils/sed > > [2] https://www.spinellis.gr/adventures-in-code.html > > [3] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=11433192 > > [4] https://github.com/dspinellis/sed-research-v7 > > From tuhs at tuhs.org Mon Mar 23 23:56:51 2026 From: tuhs at tuhs.org (Rich Kulawiec via TUHS) Date: Mon, 23 Mar 2026 09:56:51 -0400 Subject: [TUHS] George Goble (Purdue University) Message-ID: <20260323135651.GA4848@gsp.org> We lost George on March 18, 2026. Much of the world only knows him for his experiments with rapid (*extremely* rapid) BBQ grill ignition, and those were impressive [1]; but the work that he did at the Purdue Engineering Computer Network was much more germane to this mailing list. George and Mike Marsh came up with the "Purdual" 2-CPU VAX, which was the first multiprocessor Unix system; and along with other folks in EE department, he built one of the first Unix networks. He did all kinds of work with DEC and Sun and UCBerkeley and everyone who was anyone in the Unix world...and I once watched him casually twiddling bits in kernel memory space with adb on a running multiuser system. He did not make a mistake. Of course not. Of much less note but of great personal importance to me, he picked my login name -- although it wasn't his first choice. He assigned my last name early one morning and by mid-afternoon had become so frustrated trying to spell it correctly that he changed it to this one -- and it's stuck for 45+ years. I won't ever change it: if it was good enough for Ghg, as we all knew him, it's good enough for me. George was an incredibly smart guy who could have easily gone somewhere else and made a fortune, but he stayed at Purdue...and as a result, tens of thousands of students and faculty and staff benefitted from his work. "Brilliant" and "dedicated" are sometimes overused words; but not this time. ---rsk [1] I was present for some of those, as George escalated from hair dryers to liquid oxygen, and recalled that there were scientists at Los Alamos who were concerned that a nuclear detonation might ignite the atmosphere. After watching a $15 K-Mart grill be more-or-less vaporized, I began to understand their trepidation. From tuhs at tuhs.org Tue Mar 24 02:20:25 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 23 Mar 2026 12:20:25 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: <20260323162025.A87F5FE15EBD@ary.qy> It appears that Peter Weinberger (温� � �) via TUHS said: >As I remember, the 11/70 was booted just as John describes. One keyed >in a boot loader at the console. I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set the starting address from the switches and started it. Before that I toggled boot loaders into PDP-8's and I don't miss it. R's, John > >On Mon, Mar 23, 2026 at 3:11 AM John P. Linderman via TUHS > wrote: >> >> > >> > >How was UNIX bootstrapped in the early days? >> > >> > When I started at the Labs in 1973, what eventually morphed into the >> Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was >> sufficiently flakey at that time that they liked to reboot the system each >> day to clean up corruption in the file system. Someone noticed that I >> arrived before 6 am every morning, when a reboot would go unnoticed by most >> people. So I was taught how to halt the system, set a bunch of keys on the >> front of the 45, and hit start. I'm guessing that the keys simply directed >> the 45 to read a boot block from some device, and execute the instructions >> in that block, where the real software bootstrapping began. I'm sure others >> in this group can supply the correct details. I was not then, and still am >> not now, a hardware person, but I remain an early riser. -- jpl > From tuhs at tuhs.org Tue Mar 24 02:37:00 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 23 Mar 2026 12:37:00 -0400 (EDT) Subject: [TUHS] Bootstrapping UNIX - how was it done Message-ID: <20260323163700.43F4718C07A@mercury.lcs.mit.edu> > From: Adam Koszek > How was UNIX bootstrapped in the early days? How early? The PDP-7? :-) On _very_ early machines, it was quite common to have to manually enter the initial small program for bootstrapping, using the toggle switches on the front console (which allowed one to examine and store memory locations), to read in the system from wherever it was stored. Note that _very_ early on, the initial software load would have been on a reel of punched paper tape, not read in from the disk. (I think some early PDP-11 UNIX versions did that, IIRC.) Soon after the PDP-11 arrived, it had available a very small bootstrap ROM - an array of diodes! Diode in = 1, diode out = 0. (I am not making this up! Image of one here: https://gunkies.org/wiki/BM792_ROM You can read the program off the image! I have actually programmed one of those - with a soldering iron!) Most of the -11's I worked with had that, or a later ROM chip ROM - but not all, and had to be toggled. The software aspect was a whole different world. The DEC-supplied bootstrap program (in ROM) loaded block 0 from the disk - which for UNIX contained a small elegant program, described here: https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition which was prepared too load in the entirety of a normal UNIX-format binary file from any place in the file system, and start it. (I used that capability to load ring network interface diagnostics I wrote.) >From there: UNIX kernels consists of a number of smallish relocatable binary modules which are statically linked into a large object code image; during booting, that image is loaded into memory and started. After the usual initialization, the '0th' process (which in V6 has the task of swapping processes in and out) is hand-crafted; if then 'forks' into two, using the standard UNIX fork() system call (which creates a 'clone' of the existing process). The second process then runs a tiny program (the binary for which is built into the kernel) which does an 'exec()' system call, to read in and run "/etc/init". That process/command then does another fork(), and the child process from that exec()'s the shell (command interpreter, in "/bin/sh"). (Which was all very simple, compared to some contemporary operating systems. To explain how Multics booted _did_ take a book - "Internal Organization of Multics System Initialization; Program Logic Manual", AN70: https://bitsavers.mirrorservice.org/pdf/honeywell/large_systems/multics/haley/AN70_Feb75.pdf In its defense, the exact same magtape could be used to boot _any_ Multics system, no matter what its physical configuration; basically, a custom kernel was linked together during the boot process.) > What editors were used for early B, B+, C and early kernel? Some version of 'ed', I would expect. > For bootstrapping, some aspects must have been easier: ... But some > aspects must have been hard - after hitting some level of complexity > with sizable programs, debugging things from the long log of teletype > printout must have been interesting Most programs could be debugged under the OS, and there were tools available to help with that. In early UNIX versions (before V6; V5 didn't seem to have ptrace()) debugging was not interactive; the system could produce - on demand, or after a fault - a 'core dump' of the process, stored on disk, in the file system. 'db' could be used to poke around in that. Debugging the OS was a whole different trip. I gather that core dumps were the usual mechanism at Bell, etc. (At MIT, where we did a lot of OS work, to add networking, we grumped about that. The _other_ OS's in use in the Tech Sq building - ITS and TOPS-20 - had debuggers integrated into the OS, so one could set breakpoints, single-step them - all symbolically. On UNIX, nothing doing.) We should have used printf()'s - maybe the guys at Bell used them, but we never did at MIT. (I only started to use them doing retro UNIX OS work, after I retired.) >From early versions of UNIX (I'm too lazy to check, but I think it started at the first versions) there was a manual 'core dump' tool. Stop the machine, and start it (via the front console) at a magic location, and it would write the entire contents of main memory, along with some key registers, onto a magtape. See: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s at label "dump:". (Our machine at MIT didn't have a magtape drive, so we wrote code to dump it into a reserved partition, on the RK drive we used for swapping.) With that dump tool, you couldn't see processes that were swapped out at the time the dump was taken, but it usually saved enough to poke around, and thinking hard, work out what had gone wrong. Feel free to ask for details of any part of this! Noel From tuhs at tuhs.org Tue Mar 24 02:37:22 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 23 Mar 2026 12:37:22 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323162025.A87F5FE15EBD@ary.qy> References: <20260323162025.A87F5FE15EBD@ary.qy> Message-ID: On Mon, Mar 23, 2026 at 12:20 PM John Levine via TUHS wrote: > It appears that Peter Weinberger (温� � �) via TUHS said: > >As I remember, the 11/70 was booted just as John describes. One keyed > >in a boot loader at the console. > > I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set > the starting address from the switches and started it. > > Before that I toggled boot loaders into PDP-8's and I don't miss it. > > The 11/70 most certainly had a boot ROM--the M9312. Perhaps the version of Unix in question wasn't compatible with the M9312 bootstrap loader, or they just preferred their own bootstrap loader to the M9312? Or maybe they didn't have a M9312 installed. -Paul W. From tuhs at tuhs.org Tue Mar 24 02:40:54 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 23 Mar 2026 09:40:54 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323162025.A87F5FE15EBD@ary.qy> References: <20260323162025.A87F5FE15EBD@ary.qy> Message-ID: I've still got my diode ROM from what was either an 11/45 or an 11/70. I've given away my 11/45 and 11/70 front panels, sadly. By the time I came on scene, in 1975 or so, to boot from (say) an RK05, you would flip the halt swtich (usually a good idea), toggle in an address that was owned by the diode rom, 177400, whatever, flip a momentary switch UP, not DOWN, to load that starting address, release halt, and hit the momentary start switch. I believe if you left HALT set, you could step it through the diode rom, but that's an only memory. But on the -8, we were toggling in code, and on the -11, we were toggling in a starting address in a boot diode ROM -- much easier. On Mon, Mar 23, 2026 at 10:20 AM John Levine via TUHS wrote: > It appears that Peter Weinberger (温� � �) via TUHS said: > >As I remember, the 11/70 was booted just as John describes. One keyed > >in a boot loader at the console. > > I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set > the starting address from the switches and started it. > > Before that I toggled boot loaders into PDP-8's and I don't miss it. > > R's, > John > > > > > >On Mon, Mar 23, 2026 at 3:11 AM John P. Linderman via TUHS > > wrote: > >> > >> > > >> > >How was UNIX bootstrapped in the early days? > >> > > >> > When I started at the Labs in 1973, what eventually morphed into the > >> Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was > >> sufficiently flakey at that time that they liked to reboot the system > each > >> day to clean up corruption in the file system. Someone noticed that I > >> arrived before 6 am every morning, when a reboot would go unnoticed by > most > >> people. So I was taught how to halt the system, set a bunch of keys on > the > >> front of the 45, and hit start. I'm guessing that the keys simply > directed > >> the 45 to read a boot block from some device, and execute the > instructions > >> in that block, where the real software bootstrapping began. I'm sure > others > >> in this group can supply the correct details. I was not then, and still > am > >> not now, a hardware person, but I remain an early riser. -- jpl > > > > > From tuhs at tuhs.org Tue Mar 24 02:41:24 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 23 Mar 2026 09:41:24 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323162025.A87F5FE15EBD@ary.qy> Message-ID: I believe on the -8 it was called the RIM loader? On Mon, Mar 23, 2026 at 10:37 AM Paul Winalski via TUHS wrote: > On Mon, Mar 23, 2026 at 12:20 PM John Levine via TUHS > wrote: > > > It appears that Peter Weinberger (温� � �) via TUHS > said: > > >As I remember, the 11/70 was booted just as John describes. One keyed > > >in a boot loader at the console. > > > > I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set > > the starting address from the switches and started it. > > > > Before that I toggled boot loaders into PDP-8's and I don't miss it. > > > > The 11/70 most certainly had a boot ROM--the M9312. Perhaps the version > of Unix in question wasn't compatible with the M9312 bootstrap loader, or > they just preferred their own bootstrap loader to the M9312? Or maybe they > didn't have a M9312 installed. > > -Paul W. > From tuhs at tuhs.org Tue Mar 24 03:03:06 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 23 Mar 2026 13:03:06 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323162025.A87F5FE15EBD@ary.qy> Message-ID: <725420d6-fe67-204a-5499-ea01fca590d0@taugh.com> On Mon, 23 Mar 2026, ron minnich wrote: > I believe on the -8 it was called the RIM loader? That was what DEC provided but there was a much shorter version that needed you to hit the start key twice, as a kludgy way to wait for the paper tape reader. But that was definitely not Unix. R's, John > > On Mon, Mar 23, 2026 at 10:37 AM Paul Winalski via TUHS > wrote: > >> On Mon, Mar 23, 2026 at 12:20 PM John Levine via TUHS >> wrote: >> >>> It appears that Peter Weinberger (温� � �) via TUHS >> said: >>>> As I remember, the 11/70 was booted just as John describes. One keyed >>>> in a boot loader at the console. >>> >>> I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set >>> the starting address from the switches and started it. >>> >>> Before that I toggled boot loaders into PDP-8's and I don't miss it. >>> >>> The 11/70 most certainly had a boot ROM--the M9312. Perhaps the version >> of Unix in question wasn't compatible with the M9312 bootstrap loader, or >> they just preferred their own bootstrap loader to the M9312? Or maybe they >> didn't have a M9312 installed. From tuhs at tuhs.org Tue Mar 24 03:16:48 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 23 Mar 2026 17:16:48 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: On Monday, March 23rd, 2026 at 02:05, Adam Koszek via TUHS wrote: > Hi, > > What editors were used for early B, B+, C and early kernel? > > Adam > My understanding is that prior to UNIX being self hosting, Ken was editing things in QED under GECOS on the 645 BTL had gotten for Multics development, carrying over the PPT output to then load up on the PDP-7. - Matt G. From tuhs at tuhs.org Tue Mar 24 03:56:52 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 23 Mar 2026 10:56:52 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> On Mar 17, 2026, at 6:03 AM, Adam Koszek via TUHS wrote: > > For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. For our V7 port to a brand new (in 1981) 68K based board, we had to download the kernel using XMODEM or some such protocol that we had added to the boot ROM. Our cross-dev environment was on a VAX 11/780 so we continued this way until the ported system was stable enough and I had a minimal ST412 driver up and running using programmed IO! But if the kernel crashed, we were back to downloading via the serial connection! From tuhs at tuhs.org Tue Mar 24 04:09:17 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 23 Mar 2026 18:09:17 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> References: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> Message-ID: On Monday, March 23rd, 2026 at 10:57, Bakul Shah via TUHS wrote: > On Mar 17, 2026, at 6:03 AM, Adam Koszek via TUHS wrote: > > > > For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. > > For our V7 port to a brand new (in 1981) 68K based board, we > had to download the kernel using XMODEM or some such protocol > that we had added to the boot ROM. Our cross-dev environment > was on a VAX 11/780 so we continued this way until the ported > system was stable enough and I had a minimal ST412 driver up > and running using programmed IO! But if the kernel crashed, > we were back to downloading via the serial connection! Some things never change. The StarFive VisionFive line of RISC-V SBCs have a recovery console accessible over 9600 baud 3-wire serial. The basic monitor allows you to load/store individual bytes, jump to a memory location, or load data over using XMODEM. This seems to still be quite common although some other boards, like RPi's Pico line, are using bulk and control USB packets for their lowest level bootstrap monitors. Sadly I know this StarFive one too well because both their 16550 core implementation is bugged and the XMODEM monitor omits one of the acknowledge/handshake steps, so following the 16550 datasheet and XMODEM protocol to a T, you would think the thing doesn't work at all. Nah, it simply doesn't twiddle the THRE in the UART on transmit and doesn't send the right ACK or SOH or whatever back when it gets an XMODEM packet clean and good. In both cases you just have to sleep and pray. Their DRAM training in their only available first stage boot firmware for the VisionFive V1 is also broken...so avoid at all costs unless you like getting your hands dirty with all this bootstrapping stuff. Still, cool to see how historically entrenched this is. If it ain't broke don't fix it I suppose. - Matt G. From tuhs at tuhs.org Tue Mar 24 04:31:53 2026 From: tuhs at tuhs.org (Larry Stewart via TUHS) Date: Mon, 23 Mar 2026 14:31:53 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: RIM (Read In Mode) was used for both 8 and 11 iirc. > On Mar 23, 2026, at 12:41, ron minnich via TUHS wrote: > > I believe on the -8 it was called the RIM loader? > >> On Mon, Mar 23, 2026 at 10:37 AM Paul Winalski via TUHS >> wrote: >> >> On Mon, Mar 23, 2026 at 12:20 PM John Levine via TUHS >> wrote: >> >>> It appears that Peter Weinberger (温� � �) via TUHS >> said: >>>> As I remember, the 11/70 was booted just as John describes. One keyed >>>> in a boot loader at the console. >>> >>> I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set >>> the starting address from the switches and started it. >>> >>> Before that I toggled boot loaders into PDP-8's and I don't miss it. >>> >>> The 11/70 most certainly had a boot ROM--the M9312. Perhaps the version >> of Unix in question wasn't compatible with the M9312 bootstrap loader, or >> they just preferred their own bootstrap loader to the M9312? Or maybe they >> didn't have a M9312 installed. >> >> -Paul W. >> From tuhs at tuhs.org Tue Mar 24 04:43:26 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Mon, 23 Mar 2026 14:43:26 -0400 Subject: [TUHS] Bell Labs sed performance In-Reply-To: References: Message-ID: On Mon, Mar 23, 2026 at 5:05 AM Diomidis Spinellis via TUHS wrote: Amazingly, in four benchmarks the Bell Labs implementation is > still the fastest. At 1850 lines of code (including a regular > expression engine) it's also the smallest one (FreeBSD, 2672 LoC; GNU > 5462; Rust, 8946). Admittedly, modern sed versions have more features. > Still, one can only admire the design and craftsmanship that went into > the original implementation. > If you have time, you might want to benchmark the old GNU sed, which is also Minix sed. The current version (1.16) lives at < http://dl.exactcode.de/oss/minised/minised-1.15.tar.gz>. It's only slightly longer than the Bell Labs sed at 1868 LoC. From tuhs at tuhs.org Tue Mar 24 04:47:40 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 23 Mar 2026 14:47:40 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: On Mon, Mar 23, 2026 at 1:54 PM segaloco via TUHS wrote: > On Monday, March 23rd, 2026 at 02:05, Adam Koszek via TUHS wrote: > > What editors were used for early B, B+, C and early kernel? > > My understanding is that prior to UNIX being self hosting, Ken was > editing things in QED under GECOS on the 645 BTL had gotten for Multics > development, carrying over the PPT output to then load up on the PDP-7. I believe it was a GE-635 that was used for bootstrapping Unix onto the PDP-7: https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf Despite the similarity in name, the 635 and 645 were very different machines. - Dan C. From tuhs at tuhs.org Tue Mar 24 04:49:53 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 23 Mar 2026 12:49:53 -0600 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: On Mon, Mar 23, 2026 at 12:48 PM Dan Cross via TUHS wrote: > On Mon, Mar 23, 2026 at 1:54 PM segaloco via TUHS wrote: > > On Monday, March 23rd, 2026 at 02:05, Adam Koszek via TUHS < > tuhs at tuhs.org> wrote: > > > What editors were used for early B, B+, C and early kernel? > > > > My understanding is that prior to UNIX being self hosting, Ken was > > editing things in QED under GECOS on the 645 BTL had gotten for Multics > > development, carrying over the PPT output to then load up on the PDP-7. > > I believe it was a GE-635 that was used for bootstrapping Unix onto the > PDP-7: > > https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf > > Despite the similarity in name, the 635 and 645 were very different > machines. > In my history of Unix talks, I spoke of Ken creating paper tapes that were loaded by the PDP-7 on the GE to get going. First to get SpaceWar going, then to get the 'paper filesystem' going, which turned into the unix kernel... Warner From tuhs at tuhs.org Tue Mar 24 04:51:55 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 23 Mar 2026 14:51:55 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> References: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> Message-ID: On Mon, Mar 23, 2026 at 1:57 PM Bakul Shah via TUHS wrote: > On Mar 17, 2026, at 6:03 AM, Adam Koszek via TUHS wrote: > > For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. > > For our V7 port to a brand new (in 1981) 68K based board, we > had to download the kernel using XMODEM or some such protocol > that we had added to the boot ROM. Our cross-dev environment > was on a VAX 11/780 so we continued this way until the ported > system was stable enough and I had a minimal ST412 driver up > and running using programmed IO! But if the kernel crashed, > we were back to downloading via the serial connection! We use a serial UART to do OS bringup on our machines: a minimal bootloader with some debugging facilities built in starts when the machine comes out of reset (indeed, it starts from the reset vector: no BIOS/UEFI on Oxide machines); you send it a command and it initiates a transfer protocol, currently either ZMODEM or XMODEM. You then send it a ramdisk imagine with a UFS filesystem on it, which it will "mount", find the kernel in, load the kernel, and jump into. We run the UART at 3 MBAUD, so it's quite as painful as the bad old days of 9600 or slower, but it's still not super fun. https://github.com/oxidecomputer/bldb - Dan C. From tuhs at tuhs.org Tue Mar 24 04:58:55 2026 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Mon, 23 Mar 2026 11:58:55 -0700 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: <20260323135651.GA4848@gsp.org> References: <20260323135651.GA4848@gsp.org> Message-ID: oh, so sad. i loved ghg, smart and fun. rip. On Mon, Mar 23, 2026 at 6:57 AM Rich Kulawiec via TUHS wrote: > We lost George on March 18, 2026. Much of the world only knows him > for his experiments with rapid (*extremely* rapid) BBQ grill ignition, > and those were impressive [1]; but the work that he did at the Purdue > Engineering Computer Network was much more germane to this mailing list. > George and Mike Marsh came up with the "Purdual" 2-CPU VAX, which > was the first multiprocessor Unix system; and along with other folks > in EE department, he built one of the first Unix networks. He did > all kinds of work with DEC and Sun and UCBerkeley and everyone who was > anyone in the Unix world...and I once watched him casually twiddling > bits in kernel memory space with adb on a running multiuser system. > > He did not make a mistake. Of course not. > > Of much less note but of great personal importance to me, he picked > my login name -- although it wasn't his first choice. He assigned my > last name early one morning and by mid-afternoon had become so frustrated > trying to spell it correctly that he changed it to this one -- and it's > stuck for 45+ years. I won't ever change it: if it was good enough > for Ghg, as we all knew him, it's good enough for me. > > George was an incredibly smart guy who could have easily gone somewhere > else and made a fortune, but he stayed at Purdue...and as a result, > tens of thousands of students and faculty and staff benefitted from > his work. "Brilliant" and "dedicated" are sometimes overused words; > but not this time. > > ---rsk > > [1] I was present for some of those, as George escalated from hair > dryers to liquid oxygen, and recalled that there were scientists > at Los Alamos who were concerned that a nuclear detonation might > ignite the atmosphere. After watching a $15 K-Mart grill be > more-or-less vaporized, I began to understand their trepidation. > From tuhs at tuhs.org Tue Mar 24 05:41:55 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 23 Mar 2026 12:41:55 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <2C36C4B5-24AA-412C-BBFC-BEEB80E84EBF@iitbombay.org> Message-ID: > On Mar 23, 2026, at 11:51 AM, Dan Cross wrote: > > On Mon, Mar 23, 2026 at 1:57 PM Bakul Shah via TUHS wrote: >> On Mar 17, 2026, at 6:03 AM, Adam Koszek via TUHS wrote: >>> For bootstrapping, some aspects must have been easier: lights connected to registers and displayed on the dashboard. But some aspects must have been hard - after hitting some level of complexity with sizable programs, debugging things from the long log of teletype printout must have been interesting. >> >> For our V7 port to a brand new (in 1981) 68K based board, we >> had to download the kernel using XMODEM or some such protocol >> that we had added to the boot ROM. Our cross-dev environment >> was on a VAX 11/780 so we continued this way until the ported >> system was stable enough and I had a minimal ST412 driver up >> and running using programmed IO! But if the kernel crashed, >> we were back to downloading via the serial connection! > > We use a serial UART to do OS bringup on our machines: a minimal > bootloader with some debugging facilities built in starts when the > machine comes out of reset (indeed, it starts from the reset vector: > no BIOS/UEFI on Oxide machines); you send it a command and it > initiates a transfer protocol, currently either ZMODEM or XMODEM. You > then send it a ramdisk imagine with a UFS filesystem on it, which it > will "mount", find the kernel in, load the kernel, and jump into. > > We run the UART at 3 MBAUD, so it's quite as painful as the bad old > days of 9600 or slower, but it's still not super fun. > > https://github.com/oxidecomputer/bldb At a later company (1996) Jaime Da Silva added an ethernet "console" for debugging, broadcasting on a directly connected net. With separate netbooting this worked very well (though the system has to at least come up to where the blocking broadcasting console worked). You could do source level debugging from another host by attaching gdb. This worked very well (we could bring up 16 or so physical hosts, each running multiple virtual hosts running BGP for testing!). From tuhs at tuhs.org Tue Mar 24 06:01:14 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 23 Mar 2026 16:01:14 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323163700.43F4718C07A@mercury.lcs.mit.edu> References: <20260323163700.43F4718C07A@mercury.lcs.mit.edu> Message-ID: A few additions to Noel's comments [we are showing our age here a bit I suspect]. The M792 (like the FP11 FPU and KT11-C or D MMU were options for the 11/45 or the 11/40). We had several machines without the M792 to save money ( hey we were used to toggling in the bootstrap for years). Like Noel, I also remember unsoldering and resoldering one that we had to program for a new disk. WRT to editors, early UNIXes all used some flavor of ed(1), which was often extended in different ways depending on the institution. If you go to TUHS you can find some of them direct from the people that did them, as well as on USENIX tapes [also an Internet search of the old USENET comp.source archives are likely to show a few. By the time of the Sixth Edition, you can find a version of teco(1) in on the USENIX distribution tape from 1979/80 (it's in TUHS). My memory is that it was a hacked version of the teco from RT11, written in macro11. WRT to debugging, like Noel, I remember core dumps and the lack of ptrace(2) in Fifth edition and being glad when Sixth edition included db(1) for user space. Being a heavy DEC OS shop, DDT was ingrained into our fingers, and a Unix flavor of it appeared early on in v6. But coming from TSS, where (like ITS) the command interpreter was the debugger, it was a weird world for me at first. Of course, we could not (yet) run a debugger on the kernel itself, so as Noel mentioned, the traditional memory dump was the fallback when things went south. Using kernel printfs was pretty standard. One trick we did was we had a printfsw() call, which on the 11/40, 45, and 70, was able to check to set if a bit was set in the console switch register to decide to print or not (with the 11/34's loss of really switches, we lost that trick). We could turn on/off different messages, and for a live system, that was handy. Sometime after V7, a number of us at different institutions implemented some flavor of a kernel debugger, often called kdb(1). In small address systems, it could not be very feature-rich, but by the time of the 68000 workstations, Masscomp's RTU had a very elegant one, and I'm aware that other folks created fairly elegant ones as well. Later, when processors became very inexpensive, such as in the 386-based UNIX systems, a second PC was often used to run the kernel debugger, and extremely minimal support was needed in the "target." Really just enough to read/modify the registers, memory, react to a breakpoint, stop the system, and send the relevant info to the control system On Mon, Mar 23, 2026 at 12:37 PM Noel Chiappa via TUHS wrote: > > From: Adam Koszek > > > How was UNIX bootstrapped in the early days? > > How early? The PDP-7? :-) > > On _very_ early machines, it was quite common to have to manually enter the > initial small program for bootstrapping, using the toggle switches on the > front console (which allowed one to examine and store memory locations), to > read in the system from wherever it was stored. > > Note that _very_ early on, the initial software load would have been on a > reel of punched paper tape, not read in from the disk. (I think some early > PDP-11 UNIX versions did that, IIRC.) > > Soon after the PDP-11 arrived, it had available a very small bootstrap ROM > - > an array of diodes! Diode in = 1, diode out = 0. (I am not making this up! > Image of one here: > > https://gunkies.org/wiki/BM792_ROM > > You can read the program off the image! I have actually programmed one of > those - with a soldering iron!) Most of the -11's I worked with had that, > or > a later ROM chip ROM - but not all, and had to be toggled. > > > The software aspect was a whole different world. The DEC-supplied bootstrap > program (in ROM) loaded block 0 from the disk - which for UNIX contained a > small elegant program, described here: > > https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition > > which was prepared too load in the entirety of a normal UNIX-format binary > file from any place in the file system, and start it. (I used that > capability > to load ring network interface diagnostics I wrote.) > > From there: > > UNIX kernels consists of a number of smallish relocatable binary modules > which are statically linked into a large object code image; during > booting, > that image is loaded into memory and started. After the usual > initialization, > the '0th' process (which in V6 has the task of swapping processes in and > out) > is hand-crafted; if then 'forks' into two, using the standard UNIX fork() > system call (which creates a 'clone' of the existing process). > > The second process then runs a tiny program (the binary for which is > built > into the kernel) which does an 'exec()' system call, to read in and run > "/etc/init". That process/command then does another fork(), and the child > process from that exec()'s the shell (command interpreter, in "/bin/sh"). > > (Which was all very simple, compared to some contemporary operating > systems. > To explain how Multics booted _did_ take a book - "Internal Organization of > Multics System Initialization; Program Logic Manual", AN70: > > > https://bitsavers.mirrorservice.org/pdf/honeywell/large_systems/multics/haley/AN70_Feb75.pdf > > In its defense, the exact same magtape could be used to boot _any_ Multics > system, no matter what its physical configuration; basically, a custom > kernel > was linked together during the boot process.) > > > > What editors were used for early B, B+, C and early kernel? > > Some version of 'ed', I would expect. > > > > For bootstrapping, some aspects must have been easier: ... But some > > aspects must have been hard - after hitting some level of complexity > > with sizable programs, debugging things from the long log of teletype > > printout must have been interesting > > Most programs could be debugged under the OS, and there were tools > available > to help with that. In early UNIX versions (before V6; V5 didn't seem to > have > ptrace()) debugging was not interactive; the system could produce - on > demand, or after a fault - a 'core dump' of the process, stored on disk, in > the file system. 'db' could be used to poke around in that. > > Debugging the OS was a whole different trip. I gather that core dumps were > the usual mechanism at Bell, etc. (At MIT, where we did a lot of OS work, > to > add networking, we grumped about that. The _other_ OS's in use in the Tech > Sq > building - ITS and TOPS-20 - had debuggers integrated into the OS, so one > could set breakpoints, single-step them - all symbolically. On UNIX, > nothing > doing.) > > We should have used printf()'s - maybe the guys at Bell used them, but we > never did at MIT. (I only started to use them doing retro UNIX OS work, > after > I retired.) > > From early versions of UNIX (I'm too lazy to check, but I think it started > at > the first versions) there was a manual 'core dump' tool. Stop the machine, > and > start it (via the front console) at a magic location, and it would write > the > entire contents of main memory, along with some key registers, onto a > magtape. See: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s > > at label "dump:". (Our machine at MIT didn't have a magtape drive, so we > wrote code to dump it into a reserved partition, on the RK drive we used > for > swapping.) With that dump tool, you couldn't see processes that were > swapped > out at the time the dump was taken, but it usually saved enough to poke > around, and thinking hard, work out what had gone wrong. > > > Feel free to ask for details of any part of this! > > Noel > From tuhs at tuhs.org Tue Mar 24 06:07:36 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Mon, 23 Mar 2026 20:07:36 +0000 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: References: <20260323135651.GA4848@gsp.org> Message-ID: We built a couple of the Purdue Duals at BRL. Pull the terminator out of the SBI bus and put another CPU there. You just ordered another CPU card cage and boards from DEC. The tricky part is that you needed to hack the interconnect cables to flip the signals around since you were using the wrong end of the bus. The 780 also had a Unibus on it. George to accomplish some testing, put a PDP-11 on the far end of the UNIBUS as well. This resulted in a system with no bus terminators in it at all. In addition to his fun and games with liquid oxygen, he developed an ozone-friendly refrigerant. https://www.yarchive.net/ac/r406a.html We moved on from the DualVax to two processor Gould SEL systems which George and friends did the same OS hacks that he did for the dual vax. Of course, someone at Berkeley decided it would be cute to put a 0 at location 0 in the 4BSD address space. This led to a whole slew of undetected undefiend behavior. The Gould UNIX just unmapped page zero causing a hard trap if you did that. Unfortunately, there was some software we didn’t have source for (notably Oracle) that relied on *0 = 0, so one of the Purdue guys put a hack in the OS that if they saw a certain value in the a.out header it would enable “Breain-dead VAX compatilibity mode” and map a zero at zero. We just had to poke the affected binaries to turn it on. -Ron From tuhs at tuhs.org Tue Mar 24 06:09:49 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Mon, 23 Mar 2026 20:09:49 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323163700.43F4718C07A@mercury.lcs.mit.edu> Message-ID: I never learned vi. I went from ed, via a short hop with INed (or as we called it, the Bland editor), to EMACS. If there’s no EMACS, I limp along with ed until I get something ported over. If I’m forced to use VI, I just run it in “ex” mode. My employees were always amazed how fast I could edit things with just plain ed. You learned regular expressions out of necessity. -Ron From tuhs at tuhs.org Tue Mar 24 06:18:07 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Mon, 23 Mar 2026 20:18:07 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323163700.43F4718C07A@mercury.lcs.mit.edu> Message-ID: Hello Ron, That has been my experience with ed. The more I use it, the more muscle memory kicks in and sometimes I feel like a spectator, watching my own hands achieving stuff with a text file or program I'd not have ever thought I could do. Have a good one! Cameron -------- Original Message -------- On Monday, 03/23/26 at 20:10 Ron Natalie via TUHS wrote: I never learned vi. I went from ed, via a short hop with INed (or as we called it, the Bland editor), to EMACS. If there’s no EMACS, I limp along with ed until I get something ported over. If I’m forced to use VI, I just run it in “ex” mode. My employees were always amazed how fast I could edit things with just plain ed. You learned regular expressions out of necessity. -Ron From tuhs at tuhs.org Tue Mar 24 06:18:18 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Mon, 23 Mar 2026 21:18:18 +0100 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: The booting procedure is described in the manual in bproc(7) in v1 and v2, bproc(8) afterwards. A fun read :) http://squoze.net/UNIX/v1man/man7/bproc http://squoze.net/UNIX/v2man/man7/bproc http://squoze.net/UNIX/v3man/man8/bproc http://squoze.net/UNIX/v4man/man8/bproc http://squoze.net/UNIX/v5man/man8/bproc http://squoze.net/UNIX/v6man/man8/bproc On 23/03/26, Peter Weinberger (温博格) via TUHS wrote: > As I remember, the 11/70 was booted just as John describes. One keyed > in a boot loader at the console. > > On Mon, Mar 23, 2026 at 3:11 AM John P. Linderman via TUHS > wrote: > > > > > > > > >How was UNIX bootstrapped in the early days? > > > > > > When I started at the Labs in 1973, what eventually morphed into the > > Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was > > sufficiently flakey at that time that they liked to reboot the system each > > day to clean up corruption in the file system. Someone noticed that I > > arrived before 6 am every morning, when a reboot would go unnoticed by most > > people. So I was taught how to halt the system, set a bunch of keys on the > > front of the 45, and hit start. I'm guessing that the keys simply directed > > the 45 to read a boot block from some device, and execute the instructions > > in that block, where the real software bootstrapping began. I'm sure others > > in this group can supply the correct details. I was not then, and still am > > not now, a hardware person, but I remain an early riser. -- jpl From tuhs at tuhs.org Tue Mar 24 06:24:31 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Mon, 23 Mar 2026 20:24:31 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323162025.A87F5FE15EBD@ary.qy> References: <20260323162025.A87F5FE15EBD@ary.qy> Message-ID: Ours indeed had it. You set 77765000 in the switches, LOAD ADDRESS, then START. I was known to start humming Glen Miller’s Pennsylvania 6-5000 while booting up the machine. ------ Original Message ------ >From "John Levine via TUHS" To tuhs at tuhs.org Cc pjw at google.com Date 3/23/2026 12:20:25 PM Subject [TUHS] Re: Bootstrapping UNIX - how was it done >It appears that Peter Weinberger (温� � �) via TUHS said: >>As I remember, the 11/70 was booted just as John describes. One keyed >>in a boot loader at the console. > >I'm pretty sure our PDP-11 at Yale had a boot ROM, so you just set >the starting address from the switches and started it. > >Before that I toggled boot loaders into PDP-8's and I don't miss it. > >R's, >John > > >> >>On Mon, Mar 23, 2026 at 3:11 AM John P. Linderman via TUHS >> wrote: >>> >>> > >>> > >How was UNIX bootstrapped in the early days? >>> > >>> > When I started at the Labs in 1973, what eventually morphed into the >>> Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was >>> sufficiently flakey at that time that they liked to reboot the system each >>> day to clean up corruption in the file system. Someone noticed that I >>> arrived before 6 am every morning, when a reboot would go unnoticed by most >>> people. So I was taught how to halt the system, set a bunch of keys on the >>> front of the 45, and hit start. I'm guessing that the keys simply directed >>> the 45 to read a boot block from some device, and execute the instructions >>> in that block, where the real software bootstrapping began. I'm sure others >>> in this group can supply the correct details. I was not then, and still am >>> not now, a hardware person, but I remain an early riser. -- jpl >> > > From tuhs at tuhs.org Tue Mar 24 07:24:44 2026 From: tuhs at tuhs.org (=?utf-8?q?Martin_Schr=C3=B6der_via_TUHS?=) Date: Mon, 23 Mar 2026 22:24:44 +0100 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: <20260323135651.GA4848@gsp.org> References: <20260323135651.GA4848@gsp.org> Message-ID: Am Mo., 23. März 2026 um 14:57 Uhr schrieb Rich Kulawiec via TUHS : > We lost George on March 18, 2026. Much of the world only knows him Sorry to hear this. Is there an "official" obituary somewhere that can be cited by e.g. Wikipedia? His article (https://en.wikipedia.org/wiki/George_H._Goble ) needs some attention. Best Martin From tuhs at tuhs.org Tue Mar 24 07:34:11 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 23 Mar 2026 17:34:11 -0400 (EDT) Subject: [TUHS] Bootstrapping UNIX - how was it done Message-ID: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> > From: Adam Koszek > How was UNIX bootstrapped in the early days? Reading some of the later replies, it strikes me that the term "bootstrapped" has two distinct meanings: 1 - Bring a computer, on which a set of software is fully installed and operational, from a powered-off state to a fully up one, running that pre-installed software (this is the question I thought you were asking, and answered). 2 - Move a set of existing software from one type of machine to another. (A much more common event, now that we have portable software. Speaking of portable software, I'm still amazed that this, which became one of Unix's most important attributes, and a major driver in its spread, after V7, does not appear to have been really thought about before V6/V7 was ported to several other architectures.) Which one (if not both) were you thinking of? > with regards to what hardware was available. These files: https://web.archive.org/web/20250731052141/https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/11-45 https://web.archive.org/web/20251114044234/https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/low.s give a bit of info about what PDP-11 hardware was there circa V4. Noel From tuhs at tuhs.org Tue Mar 24 07:46:18 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 23 Mar 2026 17:46:18 -0400 (EDT) Subject: [TUHS] Bootstrapping UNIX - how was it done Message-ID: <20260323214618.0721718C07A@mercury.lcs.mit.edu> > From: Ron Minnich > toggle in an address that was owned by the diode rom, 177400, whatever The 'magic number', 773030, which had to be left in the front console switches for the system to come up single-user (in early UNIX versions), was in fact an address in the BM792 ROM - clearly the address used to start the 'start from powered off' bootstrap on their machine! > I believe if you left HALT set, you could step it through the diode > romK That was the incantation to give to the front console of PDP-11's that had one to cause it to single step. Noel From tuhs at tuhs.org Tue Mar 24 08:52:53 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Mon, 23 Mar 2026 22:52:53 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323214618.0721718C07A@mercury.lcs.mit.edu> References: <20260323214618.0721718C07A@mercury.lcs.mit.edu> Message-ID: Nothing magic. Leave the halt key down and press continue (not START). That single steps most othe PDP-11’s with switches. The 11/70 even allowed you to choose from single step or single bus cycle. Pressing start does a bus reset which you probably don’t want. ------ Original Message ------ >From "Noel Chiappa via TUHS" To tuhs at tuhs.org Cc jnc at mercury.lcs.mit.edu Date 3/23/2026 5:46:18 PM Subject [TUHS] Re: Bootstrapping UNIX - how was it done > > From: Ron Minnich > > > toggle in an address that was owned by the diode rom, 177400, whatever > >The 'magic number', 773030, which had to be left in the front console >switches for the system to come up single-user (in early UNIX versions), was >in fact an address in the BM792 ROM - clearly the address used to start the >'start from powered off' bootstrap on their machine! > > > I believe if you left HALT set, you could step it through the diode > > romK > >That was the incantation to give to the front console of PDP-11's that had >one to cause it to single step. > > Noel From tuhs at tuhs.org Tue Mar 24 09:27:46 2026 From: tuhs at tuhs.org (Yayitz via TUHS) Date: Mon, 23 Mar 2026 23:27:46 +0000 Subject: [TUHS] Ping In-Reply-To: <6091156bde478e954cad4e9ea3e84ec773a4d346.camel@mni.thm.de> References: <6091156bde478e954cad4e9ea3e84ec773a4d346.camel@mni.thm.de> Message-ID: Hello everyone! I joined the mailing list recently! It's a pleasure to meet you all My name is Luis, I'm a CS student in Mexico :-) willing to contribute to TUHS soon Cheers :) Sent with Proton Mail secure email. On Monday, March 23rd, 2026 at 4:13 AM, Hellwig Geisse via TUHS wrote: > On Mon, 2026-03-23 at 18:56 +1000, Warren Toomey via TUHS wrote: > > Hi all, just checking that the TUHS list is still alive :-) > > Cheers, Warren > > *pong* ;-) > > And a big "thank you" for maintaining the list! > > Hellwig > From tuhs at tuhs.org Tue Mar 24 09:47:19 2026 From: tuhs at tuhs.org (bruner--- via TUHS) Date: Mon, 23 Mar 2026 23:47:19 +0000 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: References: <20260323135651.GA4848@gsp.org> Message-ID: RIP, GHG. So many good memories. You will be missed. --John Bruner On Monday, March 23rd, 2026 at 14:25, Martin Schröder via TUHS wrote: > Am Mo., 23. März 2026 um 14:57 Uhr schrieb Rich Kulawiec via TUHS > : > > We lost George on March 18, 2026. Much of the world only knows him > > Sorry to hear this. > > Is there an "official" obituary somewhere that can be cited by e.g. Wikipedia? > His article (https://en.wikipedia.org/wiki/George_H._Goble ) needs > some attention. > > Best > Martin > From tuhs at tuhs.org Tue Mar 24 09:57:38 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Mon, 23 Mar 2026 23:57:38 +0000 Subject: [TUHS] Ping In-Reply-To: References: <6091156bde478e954cad4e9ea3e84ec773a4d346.camel@mni.thm.de> Message-ID: Hello Luis, Welcome. The TUHS is a fun and super educational place to be. In the short time I have been on the list I have learned so much. Have a great rest of your week! Cameron On Monday, March 23rd, 2026 at 11:28 PM, Yayitz via TUHS wrote: > Hello everyone! > > I joined the mailing list recently! It's a pleasure to meet you all > My name is Luis, I'm a CS student in Mexico :-) willing to contribute to TUHS soon > > Cheers :) From tuhs at tuhs.org Tue Mar 24 10:08:15 2026 From: tuhs at tuhs.org (Jim Mellander via TUHS) Date: Mon, 23 Mar 2026 17:08:15 -0700 Subject: [TUHS] Ping In-Reply-To: References: <6091156bde478e954cad4e9ea3e84ec773a4d346.camel@mni.thm.de> Message-ID: I was unable to resist forwarding this Amazon review of the classic children's book "The Story about Ping": PING! The magic duck! Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most venerable networking utilities. Even more stunning is that they were clearly working with a very early beta of the program, as their book first appeared in 1933, years (decades!) before the operating system and network infrastructure were finalized. The book describes networking in terms even a child could understand, choosing to anthropomorphize the underlying packet structure. The ping packet is described as a duck, who, with other packets (more ducks), spends a certain period of time on the host machine (the wise-eyed boat). At the same time each day (I suspect this is scheduled under cron), the little packets (ducks) exit the host (boat) by way of a bridge (a bridge). From the bridge, the packets travel onto the internet (here embodied by the Yangtze River). The title character -- er, packet, is called Ping. Ping meanders around the river before being received by another host (another boat). He spends a brief time on the other boat, but eventually returns to his original host machine (the wise-eyed boat) somewhat the worse for wear. If you need a good, high-level overview of the ping utility, this is the book. I can't recommend it for most managers, as the technical aspects may be too overwhelming and the basic concepts too daunting. Problems With This Book As good as it is, The Story About Ping is not without its faults. There is no index, and though the ping(8) man pages cover the command line options well enough, some review of them seems to be in order. Likewise, in a book solely about Ping, I would have expected a more detailed overview of the ICMP packet structure. But even with these problems, The Story About Ping has earned a place on my bookshelf, right between Stevens' Advanced Programming in the Unix Environment, and my dog-eared copy of Dante's seminal work on MS Windows, Inferno. Who can read that passage on the Windows API ("Obscure, profound it was, and nebulous, So that by fixing on its depths my sight -- Nothing whatever I discerned therein."), without shaking their head with deep understanding. But I digress. On Mon, Mar 23, 2026 at 4:28 PM Yayitz via TUHS wrote: > Hello everyone! > > I joined the mailing list recently! It's a pleasure to meet you all > My name is Luis, I'm a CS student in Mexico :-) willing to contribute to > TUHS soon > > Cheers :) > > > > Sent with Proton Mail secure email. > > On Monday, March 23rd, 2026 at 4:13 AM, Hellwig Geisse via TUHS < > tuhs at tuhs.org> wrote: > > > On Mon, 2026-03-23 at 18:56 +1000, Warren Toomey via TUHS wrote: > > > Hi all, just checking that the TUHS list is still alive :-) > > > Cheers, Warren > > > > *pong* ;-) > > > > And a big "thank you" for maintaining the list! > > > > Hellwig > > > From tuhs at tuhs.org Tue Mar 24 10:29:50 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Mon, 23 Mar 2026 17:29:50 -0700 Subject: [TUHS] UNIX In Bell Labs after SVR2 In-Reply-To: <202603231200.62NC0lGS000960@freefriends.org> References: <202603231200.62NC0lGS000960@freefriends.org> Message-ID: <5f337faf-48c1-47a1-a823-d40df4646b2b@mhorton.net> I was in Bell Labs at Columbus, outside CSRG but with good relations. In the mid-late 1980s there was considerable pressure to not only use System V but the various 3B hardware. Many tech folks lusted after Sun and other BSD-based, TCP/IP centric systems. In 1987 we were expected to use 3B5, 3B2, and Datakit. Management told us to "Eat your own dog food." Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 3/23/26 05:00, Arnold Robbins via TUHS wrote: > The Bell System continued to use System V for quite a while. > There was a small division within DEC that was responsible for continuing > to keep SVR3.x running on Vaxen, just to be able to sell to the Bell > companies. (Even though their official product, Ultrix, was BSD-based.) > > Even as UNIX became commercial, many of the big companies (HP, IBM) > aligned on the System V side, with selling to the Bells undoubtedly > part of the reason, as well as the fact that the "official source" > (``they're the guys who own UNIX'') was AT&T. BSD was well known, > and many vendors pulled in bits and pieces of BSD (csh, vi, sometimes > kernel bits) and glommed them onto their SV systems. > > segaloco via TUHS wrote: > >> These manuals I am scanning currently demonstrate steady USG UNIX usage within Bell Laboratories for many, many years. As time went on and commercial UNIX crawled further and further away from Bell Labs-proper, research continued their own journey with V8 and on. Within the larger Bell Labs ecosystem, was there a particular leaning towards continued SysV use? Did these later research versions instead retake the hearts and minds of BTL facilities? Was it more of a free for all, with research, USG, BSD, etc. sprinkled throughout the various parts of Bell Labs? Most stuff I read from the mid 70s to mid 80s paints a very USG-centric picture, but I find myself curious on folks' recollections of the situation through the mid 80s and beyond, if any census or rough estimate of UNIX stream uptake in BTL exists. >> >> - Matt G. From tuhs at tuhs.org Tue Mar 24 10:57:42 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 24 Mar 2026 00:57:42 -0000 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> Message-ID: <10psni6$2o5o$1@gal.iecc.com> According to Noel Chiappa via TUHS : >2 - Move a set of existing software from one type of machine to another. (A >much more common event, now that we have portable software. Speaking of >portable software, I'm still amazed that this, which became one of Unix's >most important attributes, and a major driver in its spread, after V7, does >not appear to have been really thought about before V6/V7 was ported to >several other architectures.) I don't think it occurred to anyone until that that it would even make sense to move an operating system from one kind of computer to another. Historically, architectures were different, data formats were different, I/O architecture was different, and everything was written in assembler or maybe a language tied to the system like Burroughs Algol. By a decade after S/360 came out, computer architectures had all converged on 8-bit byte addressable two's complement designs with multiple registers. (Older machines like the PDP-10 weren't dead yet but it was just a matter of time.) Then Unix came along, written mostly in C which was highly portable to those 8-bit byte addressable machines. The group at the Labsy allegedly picked the Perkin Elmer 7/32 because it was as different as possible from the PDP-11, but it wasn't all that different. It was 32 bits but the data formats were the same (give or take a few details of floating point), addressing and memory protection were similar to the PDP-11, and it had terminals and disks. Wollongong and the Labs separately did 7/32 ports, both probably observing that if they retargeted the C compiler to the 7/32 and recompiled the PDP-11 C code, they were about 80% of the way there, so the rest of the work was a manageable project. R's, John -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Tue Mar 24 11:15:25 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 24 Mar 2026 11:15:25 +1000 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <10psni6$2o5o$1@gal.iecc.com> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: EMAS was ported from the ICL 1900 to the 2900 at Edinburgh Uni across this time. In like sense TOPS-10 was ported from the 10 to the 20 but that was at worst a marginal conversion. Obviously the entire suite of DEC RSTS type operating systems were cross ported to the variants of the PDP11 on an as-emerged basis, but I suspect like tops10/20 that was hardly a "port" in any real sense but I believe the 1900 an 2900 were quite different, the 1900 was 24bit word, 6bit byte. the 2900 32 bit word 8bit byte. (I was a kid at the time of course, I'm not a dinosoar like the rest of you) -so I think it was more than just uplift. Different code/microcode. -G On Tue, Mar 24, 2026 at 10:57 AM John Levine via TUHS wrote: > According to Noel Chiappa via TUHS : > >2 - Move a set of existing software from one type of machine to another. > (A > >much more common event, now that we have portable software. Speaking of > >portable software, I'm still amazed that this, which became one of Unix's > >most important attributes, and a major driver in its spread, after V7, > does > >not appear to have been really thought about before V6/V7 was ported to > >several other architectures.) > > I don't think it occurred to anyone until that that it would even make > sense to > move an operating system from one kind of computer to another. > Historically, > architectures were different, data formats were different, I/O > architecture was > different, and everything was written in assembler or maybe a language > tied to > the system like Burroughs Algol. > > By a decade after S/360 came out, computer architectures had all converged > on > 8-bit byte addressable two's complement designs with multiple registers. > (Older > machines like the PDP-10 weren't dead yet but it was just a matter of > time.) > Then Unix came along, written mostly in C which was highly portable to > those > 8-bit byte addressable machines. The group at the Labsy allegedly picked > the > Perkin Elmer 7/32 because it was as different as possible from the PDP-11, > but > it wasn't all that different. It was 32 bits but the data formats were the > same > (give or take a few details of floating point), addressing and memory > protection > were similar to the PDP-11, and it had terminals and disks. > > Wollongong and the Labs separately did 7/32 ports, both probably observing > that if they retargeted the C compiler to the 7/32 and recompiled the > PDP-11 > C code, they were about 80% of the way there, so the rest of the work was > a manageable project. > > R's, > John > -- > Regards, > John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > From tuhs at tuhs.org Tue Mar 24 12:07:45 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 23 Mar 2026 22:07:45 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> Message-ID: On Mon, Mar 23, 2026 at 5:34 PM Noel Chiappa via TUHS wrote: > > 2 - Move a set of existing software from one type of machine to another. (A > much more common event, now that we have portable software. > Noel, I'm not sure I'm parsing this. Do you want me to move the kernel and all its utilities, or move the application SW? Writing portable *application* software goes back to the 1960s. It was why there was a push for formal programming language standards, such as what was developed for FORTRAN-66 (ANSI X3.9-1963) and the NBS [today's NIST] 1967 FORTRAN test suite. In the case of Algol-60 [The Revised Report (1963), although the NPL/Wichmann validation test do happen until 10 years later], we had a less formal standard, but there was something. And with the COBOL-60 report, there was something [although until COBOL-68 - ANSI X3.23-1968 for a formal standard]. Still, before developing its own formal language standard, ANSI established Task Group X3.4.4 in 1963 to develop "test problems" to test COBOL features, laying the groundwork for formal validation. Thus, by the late 1960s, the Navy had created its COBOL Validation System. So I don't think the idea of writing portable software was really new with UNIX. It was pretty common through the 1960s and beyond. In fact, meeting the standard and then adding features (Microsoft "embrace and extend) was very much the norm for most manufacturers. The system vendors wanted to lock in the applications to their systems, *so you could not easily move them*. It was common everywhere, with IBM and CDC notorious for doing so in their language implementations. Althought the most successful at this was the DEC VMS FORTRAN compiler, which, if you talked to customers, they would swear their code was written in FORTRAN-77. By the time of the superminis, Crayettes, and UNIX workstation vendors that offered FORTRAN, they all had to add the many VMS FORTRAN extensions to get customers' code to compile. FWIW: the out-of-the-box, the f77 compiler in UNIX Seventh Edition was ok, but could not pass the NIST FORTRAN Compiler Validation System (FCVS) without a good bit of work. And it did not support the VMS extensions either, so moving code from VMS was often nightmarish if that was what you had. DEC eventually moved (and sold as an option) the Vax VMS Compiler to later editions of the VAX, although they bundled V7's f77 in both Ultrix-11 and Ultrix-Vax standard. Going back to the OS, and porting it as others have already discussed a bit. Other than Burrough's, with the Master Control Program (MCP) being written, is ESPOL. What was really new with UNIX was that the kernel itself was mostly in an HLL, so we now had the possibility of moving the OS from one HW system to another. Remember that, until that time, if you look at systems from DEC, IBM, and the rest of the "BUNCH" [minus Burroughs], their OS had been written in assembler (for efficiency, of course). High-level languages gave great programmer efficiency, but they were not deemed appropriate for "production" use in the "system code" (including for the compiler itself in many cases). It was not until Wulf's BLISS Compiler experiments and the publication of the Green Book in the 74-75 time frame that people began to seriously believe it was possible to create what Wulf called a "Production Quality Code Generator." What is interesting is that at the time, Dennis's code generator/optimizer for C on the PDP-11 was almost a toy when you compared it to BLISS-11 [but even DEC - well Culter, famously refused to use BLISS for writing the VMS kernel (in fact when VMS was moved to Alpha and Itanium years later, the solution that was developed was to create a DEC GEM compiler "front-ed" that accepted VAX assembler and generated code for the new system. VSI still does that with the INTEL*64 and ARM architectures. Anyway, coming back to C, the fact is, Dennis compiler and Steve Johnson's PCC, while "not as good" as ones with a "Green Book" style optimizer, they were "good enough," and retargeting C was done anyway. [Plus, eventually enough of a new generation of compiler writers had graduated, educated in the new techniques, and Wulf-style optimizers became the norm for most languages, and in particular C]. So the idea of having a "portable OS," particularly if you had a "production quality compiler," was no longer considered silly. In fact, the world switched, and it became silly to think about writing the core OS in anything but an HLL. From tuhs at tuhs.org Tue Mar 24 12:13:46 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 23 Mar 2026 22:13:46 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: ITS was moved from the PDP-6 to a couple of different PDP-10 implementations. And TOPS-10 evolved from the DEC PDP-6 monitor. BBN wrote Tenex for a modified PDP-10, but they had certainly learned many lessons from their (modified) PDP-6 and PDP-1 systems On Mon, Mar 23, 2026 at 9:15 PM George Michaelson via TUHS wrote: > EMAS was ported from the ICL 1900 to the 2900 at Edinburgh Uni across this > time. In like sense TOPS-10 was ported from the 10 to the 20 but that was > at worst a marginal conversion. Obviously the entire suite of DEC RSTS type > operating systems were cross ported to the variants of the PDP11 on an > as-emerged basis, but I suspect like tops10/20 that was hardly a "port" in > any real sense > > but I believe the 1900 an 2900 were quite different, the 1900 was 24bit > word, 6bit byte. the 2900 32 bit word 8bit byte. (I was a kid at the time > of course, I'm not a dinosoar like the rest of you) -so I think it was more > than just uplift. Different code/microcode. > > -G > > On Tue, Mar 24, 2026 at 10:57 AM John Levine via TUHS > wrote: > > > According to Noel Chiappa via TUHS : > > >2 - Move a set of existing software from one type of machine to another. > > (A > > >much more common event, now that we have portable software. Speaking of > > >portable software, I'm still amazed that this, which became one of > Unix's > > >most important attributes, and a major driver in its spread, after V7, > > does > > >not appear to have been really thought about before V6/V7 was ported to > > >several other architectures.) > > > > I don't think it occurred to anyone until that that it would even make > > sense to > > move an operating system from one kind of computer to another. > > Historically, > > architectures were different, data formats were different, I/O > > architecture was > > different, and everything was written in assembler or maybe a language > > tied to > > the system like Burroughs Algol. > > > > By a decade after S/360 came out, computer architectures had all > converged > > on > > 8-bit byte addressable two's complement designs with multiple registers. > > (Older > > machines like the PDP-10 weren't dead yet but it was just a matter of > > time.) > > Then Unix came along, written mostly in C which was highly portable to > > those > > 8-bit byte addressable machines. The group at the Labsy allegedly picked > > the > > Perkin Elmer 7/32 because it was as different as possible from the > PDP-11, > > but > > it wasn't all that different. It was 32 bits but the data formats were > the > > same > > (give or take a few details of floating point), addressing and memory > > protection > > were similar to the PDP-11, and it had terminals and disks. > > > > Wollongong and the Labs separately did 7/32 ports, both probably > observing > > that if they retargeted the C compiler to the 7/32 and recompiled the > > PDP-11 > > C code, they were about 80% of the way there, so the rest of the work was > > a manageable project. > > > > R's, > > John > > -- > > Regards, > > John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for > > Dummies", > > Please consider the environment before reading this e-mail. > https://jl.ly > > > > > From tuhs at tuhs.org Tue Mar 24 13:01:04 2026 From: tuhs at tuhs.org (A. P. Garcia via TUHS) Date: Mon, 23 Mar 2026 23:01:04 -0400 Subject: [TUHS] Bell Labs sed performance In-Reply-To: References: Message-ID: I really enjoyed this thread, especially the reminder of how much careful craftsmanship went into early Unix tools. Inspired by the discussion, I put together a small utility that extracts “unusual” words from a text by filtering against a large frequency list. It started as a simple vocabulary aid, but it turned out to surface some interesting patterns. Running it on *The Legend of Sleepy Hollow* highlighted Irving’s mix of archaic and regional language. More amusingly, running it on *War and Peace* surfaced a cluster of words like “gwief” and “pwoceed,” which turned out not to be OCR artifacts, but Tolstoy’s deliberate rendering of Captain Denisov’s speech. It was a nice reminder that even very simple tools can uncover structure in text. Not just vocabulary, but character and style. In a small way, it felt like rediscovering the spirit behind tools like sed and spell. On Mon, Mar 23, 2026 at 9:34 AM Douglas McIlroy via TUHS wrote: > > DIomidis's note is a welcome tribute to its creator, Lee McMahon, > perhaps the least well known member of the original Unix cohort. He > reported to the Visual and Acoustics Research Center, not CSRC. A > linguist and former Jesuit seminarian, Lee brought a strong > liberal-arts perspective to the team and played a central role in the > first Unix text-analysis project, statistical study of the Federalist > papers in the tradition of Frederick Mosteller. The project exploited > the nascent software toolkit. At least one Unix staple came out of the > project, Lee's comm(1). > > Sed, Lee's biggest software-tool contribution, made its debut in v7. > Calling attention to it, the introduction to the v7 manual said, "It > is well worth learning". Although sed has been widely upstaged by awk, > it stands as a beacon of power and simplicity.. Both had 3-page > entries in the manual, but awk requires one to know C, while sed's > only prerequisite is ed. > > Outside of Unix, Lee, Ken, Joe Condon and others made TPC (The Phone > Company), a demonstration telephone switch, which ran many phones in > 1127 for several years, and, more importantly, influenced the > architecture of #5 ESS, AT&T's workhorse switch. Lee conceived TPC's > basic software architecture of one process per device, in contrast to > previous architectures' process-per-call or process-per function. > > Doug > > On Mon, Mar 23, 2026 at 6:49 AM John P. Linderman via TUHS > wrote: > > > > Russ Cox has written extensively about > > regular expression matching, and why some "features", like backtracking, > > may not be a good idea. -- jpl > > > > On Mon, Mar 23, 2026 at 5:05 AM Diomidis Spinellis via TUHS > > wrote: > > > > > Over the past year I ported the (now {Free,Net,Open})BSD version of > > > sed(1) I implemented in C in the 1990s into Rust as part of the uutils > > > initiative. I've described the process in a series of four IEEE > > > Software "Adventures in Code" [2] columns. In this March's column [3] I > > > compare the performance of the Rust implementation against that of GNU, > > > FreeBSD, and the original 1970s Bell Labs Seventh Research Edition one > > > [6]. Amazingly, in four benchmarks the Bell Labs implementation is > > > still the fastest. At 1850 lines of code (including a regular > > > expression engine) it's also the smallest one (FreeBSD, 2672 LoC; GNU > > > 5462; Rust, 8946). Admittedly, modern sed versions have more features. > > > Still, one can only admire the design and craftsmanship that went into > > > the original implementation. > > > > > > [1] https://github.com/uutils/sed > > > [2] https://www.spinellis.gr/adventures-in-code.html > > > [3] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=11433192 > > > [4] https://github.com/dspinellis/sed-research-v7 > > > From tuhs at tuhs.org Tue Mar 24 13:45:36 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 24 Mar 2026 03:45:36 +0000 Subject: [TUHS] Bell Labs sed performance In-Reply-To: References: Message-ID: On Monday, March 23rd, 2026 at 20:01, A. P. Garcia via TUHS wrote: > Inspired by the discussion, I put together a small utility that > extracts “unusual” words from a text by filtering against a large > frequency list. It started as a simple vocabulary aid, but it turned > out to surface some interesting patterns. > > In a small way, it felt like rediscovering the spirit behind tools > like sed and spell. > Little lengthy but appreciation of UNIX as applied to one of my favorite hobbies like this incoming: One of my key hobby projects these days is to not only produce disassemblies of specific video games for code analysis, but to produce methodology and tooling for meticulous preservation of software through analyzing binaries. In this the UNIX philosophy features heavily, with my toolkit featuring little scripts that all do one thing or another, as well as a few particularly helpful pipelines made up of these and standard UNIX utilities. For instance, the Ricoh R2C02 graphics chip in the NES stores sprites as 4-byte entries containing the coordinates, flip, priority, and color attributes, as well as the tile ID to display with those properties. I've got my series of headers I carry from project to project with all of these bits defined symbolically, and so set out to write a tool to automatically convert chunks of data I was looking at in disassembler garbage in vi(1) to neatly formatted tables of these OAM entries. Well, as it turns out I really just needed to write an awk(1) script to translate something like: .byte $40, $41, $42, $43 into: .byte 64, chr_obj::actor+0, obj_attr::h_flip|obj_attr::color2, 67 regardless of what sort of mess I was looking at on screen. The reason? By this point I had already, due to other such projects, written: - asd - an assembler just for processing .byte, .word, .db, .dw, etc. - dump - a tool for dumping to just .byte, .word, .db, .dw, etc. This resulted in such assembler directives as the common machine readable format for data in my various projects, in turn allowing me to use these as my bits for either snipping binary data out to make the byte list or otherwise quickly reformatting. The latter is kinda hacky to be honest but demonstrates the quick applicability: :'a,'b!asd | dump -r 4 | oamdec Can be used to take a hunk of such machine readable data and reformat it into rows of 4 bytes. That then meets the criteria for processing by my OAM tool as described above, no futzing with diversity of inputs to my OAM tool, just my simple data manipulators. My dump tool takes other arguments to pick different sizes or snip just certain ranges too. If I'm looking at some garbage but know where it starts and ends, I could hit the range with: :'a,'b!dump -s 0xBEEF -e 0xDEAD -t word -r 16 And I get all the data between 0xBEEF and 0xDEAD in rows of 16 ".word"s. (Note in practice these are 6502 specific for now, m65asd and m65dump, but will handle endianness and other stuff when ported to other CPUs...) Long story short, the natural inclination in pipeable tools towards separating interface from implementation lead me to writing pipeable serialization-deseriliazation tools before even realizing that was going to come up repeatedly in my work. That just became the natural conclusion in things since that's how everything else around what I'm doing works. I'm nearing the end of some 6502 projects. When all is said and done I intend to take a bunch of what I've learned and point it at the PDP-11. When that time comes, I'll be sure to share any similar tooling I come up with, especially stuff that helps analyze UNIX binaries. If all goes according to plan, I'll just be able to extend my existing tools to other architectures, but remains to be seen. Eat your heart out Ghidra and IDA Pro, vi(1) and a gaggle of little scripts has made me infinitely more productive at disassembly... - Matt G. From tuhs at tuhs.org Tue Mar 24 15:47:39 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 24 Mar 2026 05:47:39 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: (Larry Stewart via TUHS's message of "Mon, 23 Mar 2026 14:31:53 -0400") References: Message-ID: <7wldfhbwxw.fsf@junk.nocrew.org> Larry Stewart wrote: >> Ron Minnich wrote: >> I believe on the -8 it was called the RIM loader? > RIM (Read In Mode) was used for both 8 and 11 iirc. And the 10. (And my axe.) From tuhs at tuhs.org Tue Mar 24 15:50:23 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 24 Mar 2026 05:50:23 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: (Dan Cross via TUHS's message of "Mon, 23 Mar 2026 14:47:40 -0400") References: Message-ID: <7wh5q5bwtc.fsf@junk.nocrew.org> Dan Cross wrote: > Despite the similarity in name, the 635 and 645 were very different > machines. I always thought that approximately, the 645 = 635 + Multics stuff. Is that not so? From tuhs at tuhs.org Tue Mar 24 15:56:21 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 24 Mar 2026 05:56:21 +0000 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: (George Michaelson via TUHS's message of "Tue, 24 Mar 2026 11:15:25 +1000") References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: <7wcy0tbwje.fsf@junk.nocrew.org> George Michaelson wrote: > In like sense TOPS-10 was ported from the 10 to the 20 but that was at > worst a marginal conversion. DEC-10 and DEC-20 are largely only different names for the same machine. A DEC-10 comes with TOPS-10, and a DEC-20 comes with TOPS-20. Depending on operating system version, the microcode may differ with regards to monitor functions. From tuhs at tuhs.org Tue Mar 24 23:26:38 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Tue, 24 Mar 2026 09:26:38 -0400 Subject: [TUHS] Bell Labs sed performance Message-ID: > I put together a small utility that extracts “unusual” words from a text This reminds me of a Lorinda Cherry story. Lorinda made a suite of programs to search records of AT&T customer-service calls for systemic anomalies evidenced by sudden changes in word frequency. One amusing catch was "ten". This mundane word suddenly spiked in Missouri. It seems that the automated instructions for prepaid phone-card calls had been updated to say something like "Please enter your card number and PIN". In Missouri, where many people pronounce "ten" as "tin", this led to folks complaining that their calls did not go through although they were sure they had correctly entered the card number and "tin". Lorinda's biggest triumph was "monkey". A newsletter that AT&T distributed to some customers carried a piece about international calling, illustrated by a sketch map of the world that showed a cartoon person on each continent with connections between them. Offended customers called to complain that the person in Africa looked like a monkey. This complaint rocked the executive suite. Justly chastened, AT&T abolished the newsletter. Doug From tuhs at tuhs.org Wed Mar 25 00:05:14 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 24 Mar 2026 14:05:14 +0000 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <7wcy0tbwje.fsf@junk.nocrew.org> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <7wcy0tbwje.fsf@junk.nocrew.org> Message-ID: Different cabinetry as well. The DEC10 has a classic tall 19” rack arrangement lime the PDP-11 and many other contemporary machines. The DEC-20 has shorter cabinetry sort of like a VAX 780 only orange. ------ Original Message ------ >From "Lars Brinkhoff via TUHS" To "George Michaelson via TUHS" Date 3/24/2026 1:56:21 AM Subject [TUHS] Re: porting to different systems, Bootstrapping UNIX - how was it done >George Michaelson wrote: >> In like sense TOPS-10 was ported from the 10 to the 20 but that was at >> worst a marginal conversion. > >DEC-10 and DEC-20 are largely only different names for the same machine. >A DEC-10 comes with TOPS-10, and a DEC-20 comes with TOPS-20. Depending >on operating system version, the microcode may differ with regards to >monitor functions. From tuhs at tuhs.org Wed Mar 25 01:14:21 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 24 Mar 2026 11:14:21 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <7wcy0tbwje.fsf@junk.nocrew.org> Message-ID: Well, more importantly, is the hardware in it. TOPS-20 ran on the ECL-based KL10-D [2040/2050] and KL10-E [2060/2065] and AMD 2900 bit-slide KS10 [2020] Besides the earlier KA and KI variants, TOPS-10 ran on the KL10-D [1090], KL10-PV [1091], and the KL10-E [1091]. The KL10-D could support dual and tri CPUs [1090 SMP and Tri-SMP]. The KL10 series used something called the E-bus (executing bus) that communicated with the MASSBUS, the I-bus (KA/KI10 style for peripherals developed for earlier PDP-10s), and a DMA memory bus called the C-bus (channel bus), as well as the front-end PDP-11 (and its Unibus). For the KS10, there was its memory bus of course, but it supplied a C-bus implementation and a Unibus. The 1091 and 2060 used the same processor logic, but had some differences, such as the PDP-11/40 [called the DL10 on a 1090 and the DTE20 on the 2060]. The DL10 ran a system called RSX-20, while the DTE20 ran a hacked version of RSX-11M called DN20. Because TOPS-10 and TOPS-20 used different paging and context-switching schemes, different microcode was loaded into the KL10-E's microstore. The 1091 loaded microcode optimized for the TOPS-10 memory model and supported its "monitor calls." The 2060 loaded microcode that implemented the BBN-style paging and "JSYS" instructions required for TOPS-20. In the 2020 model, in addition to the core KL10 emulation, the AMD bitslice microcode also emulated the PDP-11 and the Intel 8080. This microcode was the SW equivalent of the original 11/34, which used the 8080 as its front console. At boot time, the KS10 ran RT11 from either its own floppy disk or from the system disk. This version of RT11 could run diagnostics and load the OS [originally TOPS-20, but eventually Version 7.01 could execute on a KS10 too]. At some point after the OS was loaded, the microcode switched to emulate KL10. Unlike KL10-E's the console terminal via the PDP-11 front-end, for the KS10 the console's UART was attached ti main processor [what I don't know is after the microcode swap from PDP-11/8080 mode into PDP-10 mode, how console communicated with the OS - i.e., was it just part of TOPS-20 or did the TOPS-20 use the same interface as the KL's and thus the microcoded PDP-11 running RT11, would have actually push the bits to the UART. From tuhs at tuhs.org Wed Mar 25 02:34:14 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Tue, 24 Mar 2026 12:34:14 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: On Mon, Mar 23, 2026 at 9:15 PM George Michaelson via TUHS wrote: > In like sense TOPS-10 was ported from the 10 to the 20 but that was > at worst a marginal conversion. Obviously the entire suite of DEC RSTS type > operating systems were cross ported to the variants of the PDP11 on an > as-emerged basis, but I suspect like tops10/20 that was hardly a "port" in > any real sense > > The original PDP-10 did not have virtual memory capability. BBN designed their own paging hardware and wrote their own operating system called TENEX. DEC did implement paging hardware for the KL10 processor, which was used in the DECSYSTEM-20. But the paging system differed from the BBN design and TENEX would not run on the DECSYSTEM-20. By then TENEX was extremely popular in DEC's PDP-10 customer base. DEC bought the rights to TENEX and ported it to the DECSYSTEM-20, the main changes being to cope with the different paging system. This port was TOPS-20. TOPS-10 would run on some DECSYSTEM-20 models, in particular those using the KS10 CPU. -Paul W. From tuhs at tuhs.org Wed Mar 25 02:49:07 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 24 Mar 2026 12:49:07 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <7wh5q5bwtc.fsf@junk.nocrew.org> References: <7wh5q5bwtc.fsf@junk.nocrew.org> Message-ID: On Tue, Mar 24, 2026 at 1:50 AM Lars Brinkhoff via TUHS wrote: > Dan Cross wrote: > > Despite the similarity in name, the 635 and 645 were very different > machines > Be careful, that's not completely true. I always thought that approximately, the 645 = 635 + Multics stuff. > Exactly: the GE645 is a 635 plus what GE called the Appending Unit (APU) . This was the same idea IBM used with the 360 models 65 and 67. The 67 had what IBM called the Data Address Translator (DAT) and some new microcode. > Is that not so? > The APU had the new hardware to: - Paged Segmentation: Support for both paging and independent segments, which allowed for the "single-level store" abstraction central to Multics. - New Addressing Modes: The addition of an "Appending Mode" that used 18-bit segment numbers and 18-bit offsets, effectively expanding the address space and simplifying virtual memory support. - Associative Memory: Implementation of what is now known as a Translation Lookaside Buffer (TLB) to speed up address translation. - Base Registers: Eight 24-bit address base registers (often used in pairs) to handle segmented addresses. Note that because of the changes to the addressing logic and the instruction set, the GE-645 was not directly object-code compatible with the GE-635. However, the 645 remained compatible enough with the 635 family to run the standard GE operating system (GECOS) and memory controllers. The GE-645 featured a way to switch hardware (described as a "mode knob") — that allowed it to operate in "GCOS mode". So an object file written for the GE-635 GECOS could run a 645 running GECOS with mode nob set. But that same object could not run directly on *Multics* as a native executable. I don't have the details, but I believe the 635 object can be run using a simulator or a specific command that sets up a GECOS environment for the processing and runs that object. FWIW: TSS/360 worked the same way. An OS/360 application could not directly execute on a 67 running TSS/360, although it was basically straightforward to modify the source [this is what my first paid programming gig was - moving York/APL to TSS]. That said, CP-67 "Hypervisor" from IBM Cambridge allowed you to boot unmodified copies of OS/360. So a 67 could run those user binaries in a VM [this is like running VMWare on my Intel Mac, so I can run Windows-11 applications in a "hosted" Win11 instance]. From tuhs at tuhs.org Wed Mar 25 02:59:09 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Tue, 24 Mar 2026 16:59:09 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: Hello Angelo, Thank you and you forgot to mention the wonderful repository of many things available at: http://squoze.net/UNIX/ Sufficient coffee and a long weekend could soon turn into a delightful and educational "lost weekend" with that starting point! Have a great rest of the week, Cameron On Monday, March 23rd, 2026 at 8:18 PM, Angelo Papenhoff via TUHS wrote: > The booting procedure is described in the manual in bproc(7) in v1 and > v2, bproc(8) afterwards. A fun read :) > > http://squoze.net/UNIX/v1man/man7/bproc > http://squoze.net/UNIX/v2man/man7/bproc > http://squoze.net/UNIX/v3man/man8/bproc > http://squoze.net/UNIX/v4man/man8/bproc > http://squoze.net/UNIX/v5man/man8/bproc > http://squoze.net/UNIX/v6man/man8/bproc From tuhs at tuhs.org Wed Mar 25 03:15:15 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 24 Mar 2026 13:15:15 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <7wh5q5bwtc.fsf@junk.nocrew.org> Message-ID: Dragging hard into my own personal memory, with the 67; IBM added a mode to the PSW and two new interrupts (Segment translation exception — Code 16 and Page translation exception — Code 17 ). The user programs got Branch and Store (BAS), Branch and Store Register (BAS & BASR) [instead of using Branch and Link and Branch and Link Register [BAL/BALR]; and three new privileges instructions for the OS: Load Multiple Control (LMC), Store Multiple Control (SMC) which manipulated the registers for the segment table and other stuff used in the DAT box; as well as Load Real Address (LRA). LRA was used in the fault processing to ask the HW to perform a virtual-to-real address translation. It returned the corresponding actual real memory address if it was in memory, or a failure code if the page wasn't currently resident. The 635/645 changes were bigger. GE added new instructions for base register management, control/descriptor management, and support for its new ring-based security model. They also made one major change to the instruction-word formats between the two models. On the 635, bit-29 was not really used, so on the 645 if it was set a different layout [base register member format] was used to interpret the instructions. I suspect the changes to the instruction fields are why Dan thinks they were different. On Tue, Mar 24, 2026 at 12:49 PM Clem Cole wrote: > > > On Tue, Mar 24, 2026 at 1:50 AM Lars Brinkhoff via TUHS > wrote: > >> Dan Cross wrote: >> > Despite the similarity in name, the 635 and 645 were very different >> machines >> > Be careful, that's not completely true. > > I always thought that approximately, the 645 = 635 + Multics stuff. >> > Exactly: the GE645 is a 635 plus what GE called the Appending Unit (APU) . > This was the same idea IBM used with the 360 models 65 and 67. The 67 had > what IBM called the Data Address Translator (DAT) and some new microcode. > > > >> Is that not so? >> > The APU had the new hardware to: > > - Paged Segmentation: Support for both paging and independent > segments, which allowed for the "single-level store" abstraction central to > Multics. > - New Addressing Modes: The addition of an "Appending Mode" that used > 18-bit segment numbers and 18-bit offsets, effectively expanding the > address space and simplifying virtual memory support. > - Associative Memory: Implementation of what is now known as a Translation > Lookaside Buffer (TLB) to speed up address translation. > - Base Registers: Eight 24-bit address base registers (often used in > pairs) to handle segmented addresses. > > Note that because of the changes to the addressing logic and the > instruction set, the GE-645 was not directly object-code compatible with > the GE-635. However, the 645 remained compatible enough with the 635 family > to run the standard GE operating system (GECOS) and memory controllers. The > GE-645 featured a way to switch hardware (described as a "mode knob") — that > allowed it to operate in "GCOS mode". > So an object file written for the GE-635 GECOS could run a 645 running > GECOS with mode nob set. But that same object could not run directly on > *Multics* as a native executable. I don't have the details, but I > believe the 635 object can be run using a simulator or a specific command > that sets up a GECOS environment for the processing and runs that object. > > FWIW: TSS/360 worked the same way. An OS/360 application could not > directly execute on a 67 running TSS/360, although it was basically > straightforward to modify the source [this is what my first paid > programming gig was - moving York/APL to TSS]. That said, CP-67 > "Hypervisor" from IBM Cambridge allowed you to boot unmodified copies of > OS/360. So a 67 could run those user binaries in a VM [this is like > running VMWare on my Intel Mac, so I can run Windows-11 applications in a > "hosted" Win11 instance]. > From tuhs at tuhs.org Wed Mar 25 03:46:44 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 24 Mar 2026 13:46:44 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: On Tue, Mar 24, 2026 at 12:34 PM Paul Winalski via TUHS wrote: > > The original PDP-10 did not have virtual memory capability. right KA10/KI10s > BBN designed their own paging hardware and wrote their own operating > system called TENEX. See Gunkies: https://gunkies.org/wiki/TENEX > DEC did implement paging hardware for the KL10 processor, which was > used in the DECSYSTEM-20. But the paging system differed from the BBN > design and TENEX would not run on the DECSYSTEM-20. Not quite right. At least one KL10-E shop modified the microcode, and I believe a few small changes to TENEX were also made. Those sites were not the only ones to make changes; MIT's MC machine [1090] was a KL10-PV, sometimes the model B. Since ITS was created for the older MIT modified KA10's 18-bit addressing and had its own unique paging scheme, Tom Knight (one of the MIT engineers) made hardware modifications to the KL10-PV's paging logic/microcode [*a.k.a.* "extended addressing]. > By then TENEX was extremely popular in DEC's PDP-10 customer base. DEC > bought the rights to > TENEX and ported it to the DECSYSTEM-20, the main changes being to cope > with the different paging system. This port was TOPS-20. > Right. > > TOPS-10 would run on some DECSYSTEM-20 models, KL10-D and Es were the same core CPU. TOPS ran on all of them fine, it just loaded different microcode as I explain previously. > in particular those using the KS10 CPU. > Actually, not until much later. The KS10 was sufficiently different from the KL10; TOPS-10 had to be modified. The 2020 running TOPS-20 was released in the first part of 1980. TOPS-10 version 7.01 was not released for another 2 years (1980). In that release, support for KS10 was added, but the primary addition was to support Master/Slave processing on a dual KL10-E. That said, in the same timeframe, TOPS-20 Release 4 came out, and it supported "fully symmetric" operation on a dual-processor KL10-E (though there were limits, as true "shared-everything" symmetry was constrained by the hardware itself). From tuhs at tuhs.org Wed Mar 25 04:25:28 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 24 Mar 2026 14:25:28 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: <20260324182529.4FF87FE3598B@ary.qy> It appears that Clem Cole via TUHS said: >ITS was moved from the PDP-6 to a couple of different PDP-10 >implementations. And TOPS-10 evolved from the DEC PDP-6 monitor. BBN wrote >Tenex for a modified PDP-10, but they had certainly learned many lessons >from their (modified) PDP-6 and PDP-1 systems That's not much of a port. The program differences between the PDP-6 and the original KA10 were tiny. Same data formats, same instruction set, even pretty much the same I/O architecture. Going to the KI10 which had paged virtual memory was more of a change. The KL10/20 which had expanded memory addressing and a new I/O architecture with a PDP-11 front end was an even bigger change. R's, John > >On Mon, Mar 23, 2026 at 9:15 PM George Michaelson via TUHS >wrote: > >> EMAS was ported from the ICL 1900 to the 2900 at Edinburgh Uni across this >> time. In like sense TOPS-10 was ported from the 10 to the 20 but that was >> at worst a marginal conversion. Obviously the entire suite of DEC RSTS type >> operating systems were cross ported to the variants of the PDP11 on an >> as-emerged basis, but I suspect like tops10/20 that was hardly a "port" in >> any real sense ... From tuhs at tuhs.org Wed Mar 25 04:31:45 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 24 Mar 2026 14:31:45 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <10psni6$2o5o$1@gal.iecc.com> <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> Message-ID: <20260324183146.23073FE35B57@ary.qy> It appears that Clem Cole via TUHS said: >On Tue, Mar 24, 2026 at 12:34 PM Paul Winalski via TUHS >wrote: > >> >> The original PDP-10 did not have virtual memory capability. > >right KA10/KI10s The KA10 had a two section relocation and protection box, geenrally with the low half being writable and the top half read only and shared. The KI10 had a pager, but not as sophisticated as the BBN one. It says so here on pages 1-38 and 1-39 of the manual. >> BBN designed their own paging hardware and wrote their own operating >> system called TENEX. Right, which evolved into TOPS-20 R's, John From tuhs at tuhs.org Wed Mar 25 05:09:22 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Tue, 24 Mar 2026 15:09:22 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <7wcy0tbwje.fsf@junk.nocrew.org> Message-ID: Your comments are interesting.  Do you have references? In particular, I do not believe the KS10 ever emulated the PDP-11 or the Intel 8080, or ran RT-11.  (Unless you know someone who did that as a hack?)  The microcode here shows the power-up sequence at listing source lines 2148 (0:) and 7843 (PWRON:): https://archive.org/details/bitsavers_decpdp10KS_21955535/mode/1up The KS10 included a real 8080 as the front-end processor. In manufacturing, so that certain diagnostics could control the machine under test, a serial line from a KL10, which ran the diagnostic program, was connected to the 8080.  Through the 8080, the diagnostic could (among other things) load microcode into the KS10, single-step the KS10, and read the micro-PC. (There wasn't a direct 32-bit data output that could be sampled, so in MSDPM (for the data paths to memory, DPM) board, a microcode snippet branched to one of two locations based on 1 bit, the diagnostic read the micro PC to find the location to see what the bit was, and the snippet shifted the data to get the next bit.  I debugged that sitting on the floor (I guess I had the DPE board on an extender) and used a DVM to check the bit's value and then reached up to the LA36 console to hit return and execute the next step.  (Return repeated the last command.)  We should have put the KS10 protos up on concrete blocks like they did in TW for the Comet protos, although I think the KS10 cabinets were taller to start with. The KS10 data path execution (DPE board) had 10 AM2901 bit slice chips, with 2 bits extra on each end, so the left and right halfwords were divided between chips and could be clocked separately. The DPM board had bunch of (IIRC Fujitsu 10ns but this was long ago) SRAMs along with the 10-bit exponent arithmetic datapath logic (not done with AMD chips) that wouldn't fit on the DPE board. The KS10's microsequencer was custom built and did not use the AM2900-family chip.  I don't recall why. As for the KL10: The standard KL10 front-end PDP-11 operating system was RSX-20F (F for front end).  However, when the machines started shipping, it wasn't ready, so temporarily they used a different, small operating system, KLDCP (the KL Diagnostic Control Program) written by the Large Systems Diagnostics Group in MR1-2 for, well, running diagnostics programs. https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n5/mode/1up?q=kldcp https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n154/mode/1up?q=kldcp https://f6.erista.me/files/bitsavers/scandocs.trailing-edge.com/rsx20f-aa-h213a-tk.pdf (I was hired by DEC for the Large Systems Diagnostics Group in MR1-2 to modify KLDCP for a new machine, I think it was Dolphin.  When that project suffered a design setback, I worked on the KS10 STIRS diagnostic [MSDPM, mentioned above] and the VAX-11/750 [Comet] "CPU Cluster" Exerciser [NOT related to VAXcluster] for character string and interlocked queue instructions.) - Aron On 3/24/26 11:14, Clem Cole via TUHS wrote: > [...] > In the 2020 model, in addition to the core KL10 emulation, the AMD bitslice > microcode also emulated the PDP-11 and the Intel 8080. This microcode was > the SW equivalent of the original 11/34, which used the 8080 as its front > console. At boot time, the KS10 ran RT11 from either its own floppy disk > or from the system disk. This version of RT11 could run diagnostics and > load the OS [originally TOPS-20, but eventually Version 7.01 could execute > on a KS10 too]. At some point after the OS was loaded, the microcode > switched to emulate KL10. Unlike KL10-E's the console terminal via the > PDP-11 front-end, for the KS10 the console's UART was attached ti main > processor [what I don't know is after the microcode swap from PDP-11/8080 > mode into PDP-10 mode, how console communicated with the OS - i.e., was it > just part of TOPS-20 or did the TOPS-20 use the same interface as the KL's > and thus the microcoded PDP-11 running RT11, would have actually push the > bits to the UART. From tuhs at tuhs.org Wed Mar 25 06:01:59 2026 From: tuhs at tuhs.org (Aron Insinga via TUHS) Date: Tue, 24 Mar 2026 16:01:59 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <7wcy0tbwje.fsf@junk.nocrew.org> Message-ID: <8799c8d3-f724-471b-b7c1-15c90426e35c@insinga.com> p.s. The first reference to check for DEC computer history questions (up through when the book was published) is _Computer Engineering_ by Bell et al.  (Your favorite search engine is also your friend, when it isn't being evil. :-) ) https://gordonbell.azurewebsites.net/Computer_Engineering/00000539.htm We should ask: "Could a PDP-6 level processor be built in/1975/to sell for $10K?" Clearly it could, and such a system has been built as an advanced development project. This small 10 has a unified bus structure like the PDP-11 with a connection to use the Unibus family*I/O*devices. A system with 512 Kwords and the performance of greater than that of a KA10 occupies a cabinet somewhat smaller than a PDP-11/70 minicomputer.* ---- *The computer called the 2020 was introduced in May 1978. The internal bus of the DECSYSTEM-2020 was somewhat similar to the SBI (Synchronous Backplane Interconnect) of the VAX-11/780. I had heard that the name change from PDP-10 to DECsystem-10 happened when DEC started selling PDP-10s for data processing applications, and started using them for that itself at the Information Processing Center (IPC) in PK (Parker St., Maynard), while the later capitalization change to DECSYSTEM-20 was due to some trademark issue.  But many people still called them PDP-10s or by the CPU model name (KA, KI, KL, KS). There is a very nice table here: http://pdp10.nocrew.org/cpu/processors.html Although I believe the Tiny machine was to be KT20 instead of KT10 because some old PDP-10 option was called a KT10. For the way-too-curious :-) the MSDPM Test sources are here: https://pdp-10.trailing-edge.com/klad_sources/01/klad.sources/msdpmt.b36.html I can't speak for others on the team, but I'm sure that I should have typed more comments, sorry. If my BLISS-36 coding style is a bit a-typical, perhaps it is because I liked that it was (at the time) an expression language. https://archive.org/details/full-bliss-history More related files are in https://pdp-10.trailing-edge.com/klad_sources/ Naming convention: m = MainDEC (diagnostic); s = KS10; DPM, DPE, etc. are the boards to be tested. (And if you get into that directory, I have to add that I think DAKA*.MAC is a really nice example of testing each instruction and using what you already tested in the remaining tests.  Hats off to JOHN R. KIRCHOFF and DICK MALISKA [RIP].  But I digress.) - Aron On 3/24/26 15:09, Aron Insinga via TUHS wrote: > Your comments are interesting.  Do you have references? > > In particular, I do not believe the KS10 ever emulated the PDP-11 or > the Intel 8080, or ran RT-11.  (Unless you know someone who did that > as a hack?)  The microcode here shows the power-up sequence at listing > source lines 2148 (0:) and 7843 (PWRON:): > > https://archive.org/details/bitsavers_decpdp10KS_21955535/mode/1up > > The KS10 included a real 8080 as the front-end processor. > > In manufacturing, so that certain diagnostics could control the > machine under test, a serial line from a KL10, which ran the > diagnostic program, was connected to the 8080.  Through the 8080, the > diagnostic could (among other things) load microcode into the KS10, > single-step the KS10, and read the micro-PC. > > (There wasn't a direct 32-bit data output that could be sampled, so in > MSDPM (for the data paths to memory, DPM) board, a microcode snippet > branched to one of two locations based on 1 bit, the diagnostic read > the micro PC to find the location to see what the bit was, and the > snippet shifted the data to get the next bit.  I debugged that sitting > on the floor (I guess I had the DPE board on an extender) and used a > DVM to check the bit's value and then reached up to the LA36 console > to hit return and execute the next step.  (Return repeated the last > command.)  We should have put the KS10 protos up on concrete blocks > like they did in TW for the Comet protos, although I think the KS10 > cabinets were taller to start with. > > The KS10 data path execution (DPE board) had 10 AM2901 bit slice > chips, with 2 bits extra on each end, so the left and right halfwords > were divided between chips and could be clocked separately. > > The DPM board had bunch of (IIRC Fujitsu 10ns but this was long ago) > SRAMs along with the 10-bit exponent arithmetic datapath logic (not > done with AMD chips) that wouldn't fit on the DPE board. > > The KS10's microsequencer was custom built and did not use the > AM2900-family chip.  I don't recall why. > > As for the KL10: > > The standard KL10 front-end PDP-11 operating system was RSX-20F (F for > front end).  However, when the machines started shipping, it wasn't > ready, so temporarily they used a different, small operating system, > KLDCP (the KL Diagnostic Control Program) written by the Large Systems > Diagnostics Group in MR1-2 for, well, running diagnostics programs. > > https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n5/mode/1up?q=kldcp > > https://archive.org/details/bitsavers_decpdp10KLaintenanceGuideVolume2Rev3Apr85_21152180/page/n154/mode/1up?q=kldcp > > > https://f6.erista.me/files/bitsavers/scandocs.trailing-edge.com/rsx20f-aa-h213a-tk.pdf > > > (I was hired by DEC for the Large Systems Diagnostics Group in MR1-2 > to modify KLDCP for a new machine, I think it was Dolphin. When that > project suffered a design setback, I worked on the KS10 STIRS > diagnostic [MSDPM, mentioned above] and the VAX-11/750 [Comet] "CPU > Cluster" Exerciser [NOT related to VAXcluster] for character string > and interlocked queue instructions.) > > - Aron > > On 3/24/26 11:14, Clem Cole via TUHS wrote: >> [...] >> In the 2020 model, in addition to the core KL10 emulation, the AMD >> bitslice >> microcode also emulated the PDP-11 and the Intel 8080.   This >> microcode was >> the SW equivalent of the original 11/34, which used the 8080 as its >> front >> console.  At boot time, the KS10 ran RT11 from either its own floppy >> disk >> or from the system disk.  This version of RT11 could run diagnostics and >> load the OS [originally TOPS-20, but eventually Version 7.01 could >> execute >> on a KS10 too].  At some point after the OS was loaded, the microcode >> switched to emulate KL10.  Unlike KL10-E's the console terminal via the >> PDP-11 front-end, for the KS10 the console's UART was attached ti main >> processor [what I don't know is after the microcode swap from >> PDP-11/8080 >> mode into PDP-10 mode, how console communicated with the OS - i.e., >> was it >> just part of TOPS-20 or did the TOPS-20 use the same interface as the >> KL's >> and thus the microcoded PDP-11 running RT11, would have actually push >> the >> bits to the UART. > From tuhs at tuhs.org Tue Mar 24 08:19:43 2026 From: tuhs at tuhs.org (bruner--- via TUHS) Date: Mon, 23 Mar 2026 22:19:43 +0000 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: <20260323214618.0721718C07A@mercury.lcs.mit.edu> References: <20260323214618.0721718C07A@mercury.lcs.mit.edu> Message-ID: Most of the PDP-11's I used had boot ROMs, but I do recall at least one machine where the boot procedure was Set HALT/RUN to HALT Press START LOAD ADDR 777404 DEP 5 LOAD ADDR 0 Set HALT/RUN to RUN Press START The reset cleared all of the controller registers, so this read 64Kwords from RK05 drive 0 into memory starting at 0. A little overkill for reading one 512-byte block... --John From tuhs at tuhs.org Thu Mar 26 22:30:02 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Thu, 26 Mar 2026 08:30:02 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <7wh5q5bwtc.fsf@junk.nocrew.org> Message-ID: On Tue, Mar 24, 2026 at 1:16 PM Clem Cole via TUHS wrote: > [snip] > The 635/645 changes were bigger. GE added new instructions for base > register management, control/descriptor management, and support for its new > ring-based security model. They also made one major change to the > instruction-word formats between the two models. On the 635, bit-29 was > not really used, so on the 645 if it was set a different layout [base > register member format] was used to interpret the instructions. I suspect > the changes to the instruction fields are why Dan thinks they were > different. Yes, primarily. I'm sure there was much that was quite similar between the two, and I don't mean to overstate it, but my sense was that the changes made to the 645 to support Multics were substantial. - Dan C. > >> Dan Cross wrote: > >> > Despite the similarity in name, the 635 and 645 were very different > >> machines > >> > > Be careful, that's not completely true. > > > > I always thought that approximately, the 645 = 635 + Multics stuff. > >> > > Exactly: the GE645 is a 635 plus what GE called the Appending Unit (APU) . > > This was the same idea IBM used with the 360 models 65 and 67. The 67 had > > what IBM called the Data Address Translator (DAT) and some new microcode. > > > >> Is that not so? > >> > > The APU had the new hardware to: > > > > - Paged Segmentation: Support for both paging and independent > > segments, which allowed for the "single-level store" abstraction central to > > Multics. > > - New Addressing Modes: The addition of an "Appending Mode" that used > > 18-bit segment numbers and 18-bit offsets, effectively expanding the > > address space and simplifying virtual memory support. > > - Associative Memory: Implementation of what is now known as a Translation > > Lookaside Buffer (TLB) to speed up address translation. > > - Base Registers: Eight 24-bit address base registers (often used in > > pairs) to handle segmented addresses. > > > > Note that because of the changes to the addressing logic and the > > instruction set, the GE-645 was not directly object-code compatible with > > the GE-635. However, the 645 remained compatible enough with the 635 family > > to run the standard GE operating system (GECOS) and memory controllers. The > > GE-645 featured a way to switch hardware (described as a "mode knob") — that > > allowed it to operate in "GCOS mode". > > So an object file written for the GE-635 GECOS could run a 645 running > > GECOS with mode nob set. But that same object could not run directly on > > *Multics* as a native executable. I don't have the details, but I > > believe the 635 object can be run using a simulator or a specific command > > that sets up a GECOS environment for the processing and runs that object. > > > > FWIW: TSS/360 worked the same way. An OS/360 application could not > > directly execute on a 67 running TSS/360, although it was basically > > straightforward to modify the source [this is what my first paid > > programming gig was - moving York/APL to TSS]. That said, CP-67 > > "Hypervisor" from IBM Cambridge allowed you to boot unmodified copies of > > OS/360. So a 67 could run those user binaries in a VM [this is like > > running VMWare on my Intel Mac, so I can run Windows-11 applications in a > > "hosted" Win11 instance]. > > From tuhs at tuhs.org Fri Mar 27 00:48:17 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Thu, 26 Mar 2026 08:48:17 -0600 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323214618.0721718C07A@mercury.lcs.mit.edu> Message-ID: On Thu, Mar 26, 2026, 5:29 AM bruner--- via TUHS wrote: > Most of the PDP-11's I used had boot ROMs, but I do recall at least one > machine where the boot procedure was > > Set HALT/RUN to HALT > Press START > LOAD ADDR 777404 > DEP 5 > LOAD ADDR 0 > Set HALT/RUN to RUN > Press START > > The reset cleared all of the controller registers, so this read 64Kwords > from RK05 drive 0 into memory starting at 0. A little overkill for reading > one 512-byte block... > Boot time was optimized in favor of the operator key in time over the time to read in blocks from the disk... Warnet --John > From tuhs at tuhs.org Fri Mar 27 00:55:22 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Thu, 26 Mar 2026 14:55:22 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM Message-ID: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> Hi, Would anyone happen to have a copy of the companion CD-ROM which came with the book Panic! - Unix System Crash Dump Analysis on Prentice Hall (ISBN 0-13-149386-8). There's a copy already up on archive.org[1] but the source CD had some unreadable sectors which just happen to be where some of the files were located on their disk, resulting in a useless iso. Any chance someone could upload a fresh working copy or make one available? Sincerely, Sevan [1] https://archive.org/details/failsafe-media From tuhs at tuhs.org Fri Mar 27 01:56:50 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Thu, 26 Mar 2026 11:56:50 -0400 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323214618.0721718C07A@mercury.lcs.mit.edu> Message-ID: On the IBM System/360 and S/370 one set the dials on the system console to the 3-hex-digit address of the boot device and pressed the IPL (Initial Program Load) button. On S/370 models 115 and 125, which did not have blinkenlight consoles but instead a video console, one selected IPL from the console menu options. This caused the system to send a "Read IPL" channel command word (CCW) to the selected channel and controller, which then read one record off of the device into hardware memory location 0. The IPL record was 24 bytes long. The first 4 bytes were loaded into the Program Status Word (PSW) register and specified the address of the first instruction to be executed. The second 4 bytes were a CCW to load further instructions and data from the boot device. One could boot from any device that supported the Read IPL CCW function. This included disk, drum, and data cell devices, magnetic tape, and punch cards. -Paul W. On Thu, Mar 26, 2026 at 7:29 AM bruner--- via TUHS wrote: > Most of the PDP-11's I used had boot ROMs, but I do recall at least one > machine where the boot procedure was > > Set HALT/RUN to HALT > Press START > LOAD ADDR 777404 > DEP 5 > LOAD ADDR 0 > Set HALT/RUN to RUN > Press START > > The reset cleared all of the controller registers, so this read 64Kwords > from RK05 drive 0 into memory starting at 0. A little overkill for reading > one 512-byte block... > > --John > From tuhs at tuhs.org Fri Mar 27 02:01:53 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 26 Mar 2026 09:01:53 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: <20260323214618.0721718C07A@mercury.lcs.mit.edu> Message-ID: Same deal with virtual machines under VM/370, except one issued the IPL CP command. 'IPL 00C' booted from the virtual card reader - I used this way too many times during the UNIX on the 370 bringup. On Thu, Mar 26, 2026 at 8:57 AM Paul Winalski via TUHS wrote: > On the IBM System/360 and S/370 one set the dials on the system console to > the 3-hex-digit address of the boot device and pressed the IPL (Initial > Program Load) button. On S/370 models 115 and 125, which did not have > blinkenlight consoles but instead a video console, one selected IPL from > the console menu options. > > This caused the system to send a "Read IPL" channel command word (CCW) to > the selected channel and controller, which then read one record off of the > device into hardware memory location 0. The IPL record was 24 bytes long. > The first 4 bytes were loaded into the Program Status Word (PSW) register > and specified the address of the first instruction to be executed. The > second 4 bytes were a CCW to load further instructions and data from the > boot device. One could boot from any device that supported the Read IPL > CCW function. This included disk, drum, and data cell devices, magnetic > tape, and punch cards. > > -Paul W. > > On Thu, Mar 26, 2026 at 7:29 AM bruner--- via TUHS wrote: > > > Most of the PDP-11's I used had boot ROMs, but I do recall at least one > > machine where the boot procedure was > > > > Set HALT/RUN to HALT > > Press START > > LOAD ADDR 777404 > > DEP 5 > > LOAD ADDR 0 > > Set HALT/RUN to RUN > > Press START > > > > The reset cleared all of the controller registers, so this read 64Kwords > > from RK05 drive 0 into memory starting at 0. A little overkill for > reading > > one 512-byte block... > > > > --John > > > From tuhs at tuhs.org Fri Mar 27 04:07:20 2026 From: tuhs at tuhs.org (James Frew via TUHS) Date: Thu, 26 Mar 2026 11:07:20 -0700 Subject: [TUHS] Bootstrapping UNIX - how was it done In-Reply-To: References: Message-ID: Our (v6++) 11/45 wasn't especially flakey, but it did have a primitive frame buffer attached to it that I was debugging a driver for, so I wound up getting up close and personal with the rebooting process, to the extent that I had actually memorized the multiple instruction sequence (now, thankfully, forgotten) that had to be keyed in to restart it. Have to say I was both proud and horrified to be *programming a computer with switches*... /Frew On 2026-03-23 3:11 AM, John P. Linderman via TUHS wrote: >>> How was UNIX bootstrapped in the early days? >> When I started at the Labs in 1973, what eventually morphed into the > Programmer's Workbench UNIX ran a PDP45 in Piscataway, NJ. UNIX was > sufficiently flakey at that time that they liked to reboot the system each > day to clean up corruption in the file system. Someone noticed that I > arrived before 6 am every morning, when a reboot would go unnoticed by most > people. So I was taught how to halt the system, set a bunch of keys on the > front of the 45, and hit start. I'm guessing that the keys simply directed > the 45 to read a boot block from some device, and execute the instructions > in that block, where the real software bootstrapping began. I'm sure others > in this group can supply the correct details. I was not then, and still am > not now, a hardware person, but I remain an early riser. -- jpl From tuhs at tuhs.org Fri Mar 27 04:08:58 2026 From: tuhs at tuhs.org (Robert Clausecker via TUHS) Date: Thu, 26 Mar 2026 19:08:58 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> Message-ID: Hi Sevan, I have a copy of that book. Let me see if I can make a copy of the CD. Yours, Robert Clausecker Am Thu, Mar 26, 2026 at 02:55:22PM +0000 schrieb Sevan Janiyan via TUHS: > Hi, > Would anyone happen to have a copy of the companion CD-ROM which came with > the book Panic! - Unix System Crash Dump Analysis on Prentice Hall (ISBN > 0-13-149386-8). > There's a copy already up on archive.org[1] but the source CD had some > unreadable sectors which just happen to be where some of the files were > located on their disk, resulting in a useless iso. > > Any chance someone could upload a fresh working copy or make one available? > > Sincerely, > > > Sevan > [1] https://archive.org/details/failsafe-media > -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From tuhs at tuhs.org Fri Mar 27 17:47:28 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 27 Mar 2026 01:47:28 -0600 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <10psni6$2o5o$1@gal.iecc.com> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> Message-ID: <202603270747.62R7lS7d090987@freefriends.org> If I recall correctly, the labs port was to an Interdata 8/32. John Levine via TUHS wrote: > According to Noel Chiappa via TUHS : > >2 - Move a set of existing software from one type of machine to another. (A > >much more common event, now that we have portable software. Speaking of > >portable software, I'm still amazed that this, which became one of Unix's > >most important attributes, and a major driver in its spread, after V7, does > >not appear to have been really thought about before V6/V7 was ported to > >several other architectures.) > > I don't think it occurred to anyone until that that it would even make sense to > move an operating system from one kind of computer to another. Historically, > architectures were different, data formats were different, I/O architecture was > different, and everything was written in assembler or maybe a language tied to > the system like Burroughs Algol. > > By a decade after S/360 came out, computer architectures had all converged on > 8-bit byte addressable two's complement designs with multiple registers. (Older > machines like the PDP-10 weren't dead yet but it was just a matter of time.) > Then Unix came along, written mostly in C which was highly portable to those > 8-bit byte addressable machines. The group at the Labsy allegedly picked the > Perkin Elmer 7/32 because it was as different as possible from the PDP-11, but > it wasn't all that different. It was 32 bits but the data formats were the same > (give or take a few details of floating point), addressing and memory protection > were similar to the PDP-11, and it had terminals and disks. > > Wollongong and the Labs separately did 7/32 ports, both probably observing > that if they retargeted the C compiler to the 7/32 and recompiled the PDP-11 > C code, they were about 80% of the way there, so the rest of the work was > a manageable project. > > R's, > John > -- > Regards, > John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Sat Mar 28 03:24:26 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 27 Mar 2026 13:24:26 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <202603270747.62R7lS7d090987@freefriends.org> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <202603270747.62R7lS7d090987@freefriends.org> Message-ID: <2960d9e5-e61c-0e72-7b3b-fb012f8034ca@taugh.com> On Fri, 27 Mar 2026, arnold at skeeve.com wrote: > If I recall correctly, the labs port was to an Interdata 8/32. Quite possibly. Programming for the 7/32 and 8/32 were nearly the same. R's, John > John Levine via TUHS wrote: > >> According to Noel Chiappa via TUHS : >>> 2 - Move a set of existing software from one type of machine to another. (A >>> much more common event, now that we have portable software. Speaking of >>> portable software, I'm still amazed that this, which became one of Unix's >>> most important attributes, and a major driver in its spread, after V7, does >>> not appear to have been really thought about before V6/V7 was ported to >>> several other architectures.) >> >> I don't think it occurred to anyone until that that it would even make sense to >> move an operating system from one kind of computer to another. Historically, >> architectures were different, data formats were different, I/O architecture was >> different, and everything was written in assembler or maybe a language tied to >> the system like Burroughs Algol. >> >> By a decade after S/360 came out, computer architectures had all converged on >> 8-bit byte addressable two's complement designs with multiple registers. (Older >> machines like the PDP-10 weren't dead yet but it was just a matter of time.) >> Then Unix came along, written mostly in C which was highly portable to those >> 8-bit byte addressable machines. The group at the Labs allegedly picked the >> Perkin Elmer 7/32 because it was as different as possible from the PDP-11, but >> it wasn't all that different. It was 32 bits but the data formats were the same >> (give or take a few details of floating point), addressing and memory protection >> were similar to the PDP-11, and it had terminals and disks. >> >> Wollongong and the Labs separately did 7/32 ports, both probably observing >> that if they retargeted the C compiler to the 7/32 and recompiled the PDP-11 >> C code, they were about 80% of the way there, so the rest of the work was >> a manageable project. From tuhs at tuhs.org Sat Mar 28 03:37:08 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 27 Mar 2026 11:37:08 -0600 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <2960d9e5-e61c-0e72-7b3b-fb012f8034ca@taugh.com> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <202603270747.62R7lS7d090987@freefriends.org> <2960d9e5-e61c-0e72-7b3b-fb012f8034ca@taugh.com> Message-ID: On Fri, Mar 27, 2026, 11:24 AM John R Levine via TUHS wrote: > On Fri, 27 Mar 2026, arnold at skeeve.com wrote: > > If I recall correctly, the labs port was to an Interdata 8/32. > > Quite possibly. Programming for the 7/32 and 8/32 were nearly the same. > Yes. Wollongong had the 7/32 and Bell Labs had the 8/32. Warner R's, > John > > > John Levine via TUHS wrote: > > > >> According to Noel Chiappa via TUHS : > >>> 2 - Move a set of existing software from one type of machine to > another. (A > >>> much more common event, now that we have portable software. Speaking of > >>> portable software, I'm still amazed that this, which became one of > Unix's > >>> most important attributes, and a major driver in its spread, after V7, > does > >>> not appear to have been really thought about before V6/V7 was ported to > >>> several other architectures.) > >> > >> I don't think it occurred to anyone until that that it would even make > sense to > >> move an operating system from one kind of computer to another. > Historically, > >> architectures were different, data formats were different, I/O > architecture was > >> different, and everything was written in assembler or maybe a language > tied to > >> the system like Burroughs Algol. > >> > >> By a decade after S/360 came out, computer architectures had all > converged on > >> 8-bit byte addressable two's complement designs with multiple > registers. (Older > >> machines like the PDP-10 weren't dead yet but it was just a matter of > time.) > >> Then Unix came along, written mostly in C which was highly portable to > those > >> 8-bit byte addressable machines. The group at the Labs allegedly picked > the > >> Perkin Elmer 7/32 because it was as different as possible from the > PDP-11, but > >> it wasn't all that different. It was 32 bits but the data formats were > the same > >> (give or take a few details of floating point), addressing and memory > protection > >> were similar to the PDP-11, and it had terminals and disks. > >> > >> Wollongong and the Labs separately did 7/32 ports, both probably > observing > >> that if they retargeted the C compiler to the 7/32 and recompiled the > PDP-11 > >> C code, they were about 80% of the way there, so the rest of the work > was > >> a manageable project. > From tuhs at tuhs.org Sat Mar 28 07:56:38 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 27 Mar 2026 17:56:38 -0400 Subject: [TUHS] porting to different systems, Bootstrapping UNIX - how was it done In-Reply-To: <2960d9e5-e61c-0e72-7b3b-fb012f8034ca@taugh.com> References: <20260323213411.0DF6A18C07A@mercury.lcs.mit.edu> <10psni6$2o5o$1@gal.iecc.com> <202603270747.62R7lS7d090987@freefriends.org> <2960d9e5-e61c-0e72-7b3b-fb012f8034ca@taugh.com> Message-ID: On Fri, Mar 27, 2026 at 1:24 PM John R Levine via TUHS wrote: > On Fri, 27 Mar 2026, arnold at skeeve.com wrote: > > If I recall correctly, the labs port was to an Interdata 8/32. > > Quite possibly. Programming for the 7/32 and 8/32 were nearly the same. > It true: https://gunkies.org/wiki/Interdata_7/32 They shared a core set of Instructions (largely based on S/360 BTW). Gunkies calls the 8/32 the 7/32's big sister. IIRC 7/32 binaries ran on 8/32 but not the other way around. While (like the S/360 architectural definition) they both used 32-bit registers, the 8/32 had 32-bit data paths and the 7/32 had 16-bit data paths. Also the implementations differed using 7400 logic in the one and 74S00 in the other. The combination of a double datapath and faster logic implementation made the 8/32 2-2.5 times faster than the 7/32.