From tuhs at tuhs.org Wed Apr 1 13:20:47 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 1 Apr 2026 13:20:47 +1000 Subject: [TUHS] Problems with TUHS and COFF mailing lists Message-ID: Hi all, I'm back from a 3 1/2 week overseas holiday. Of course, partway through the trip the TUHS server "minnie" decided to hit 0% free disk space. I was able to clean things out remotely using a tablet and Bluetooth keyboard. However, since then I've had a few e-mails saying that submissions to TUHS and COFF have gone to /dev/null. I haven't deduced the issue yet. So, if in the next few weeks you post to TUHS or COFF and you don't see your posting, please e-mail with as much details as you can provide; a copy of the logs from your mail server would be wonderful! Thanks, Warren From tuhs at tuhs.org Wed Apr 1 18:08:31 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Apr 2026 08:08:31 +0000 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro Message-ID: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> Surprise surprise, another hyper-specific topic incoming. I am curious if anyone on-list can provide insight on this topic. Setting Up Unix - Seventh Edition indicates: > The tape is 9-track 800 BPI... Was this a matter of convention given the general computing ecosystem at the time, or was this more driven by Bell System standards for magtape? I find myself curious as I recently procured a 7-track 556 BPI transport which, while not applicable to V7 UNIX tapes as so described, has me itching to explore the world of magtape further, including eventually tracking down a 9-track supporting the necessary BPI should another UNIX tape needing preservation surface. I also recently got a QIC drive (not the right size for the early 90s BTL tapes I have) and am exploring repurposing the read head to yank data off these janky QIC tapes I have. Needless to say, magnetic tape media and preservation is on the mind lately. Further on the subject of UNIX tapes though, was there any regular shipment of other media not matching this description or was it pretty settled that order_unix() has a return type of mt_track_9_bpi_800_t ? - Matt G. From tuhs at tuhs.org Wed Apr 1 18:51:12 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 01 Apr 2026 02:51:12 -0600 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> Message-ID: <202604010851.6318pCpZ096750@freefriends.org> In that time frame, 800 BPI was pretty standard. 9 tracks gave you eight bits of data plus a parity bit. By the mid-80s, 1600 BPI was pretty common for the same media, so the BSD distributions might have been 1600 BPI tapes. I think at some point 9 track tape drives hit something like 6400 BPI, but I may be hallucinating the memory. HTH, Arnold segaloco via TUHS wrote: > Surprise surprise, another hyper-specific topic incoming. I am curious > if anyone on-list can provide insight on this topic. Setting Up Unix - > Seventh Edition indicates: > > > The tape is 9-track 800 BPI... > > Was this a matter of convention given the general computing ecosystem at > the time, or was this more driven by Bell System standards for magtape? > > I find myself curious as I recently procured a 7-track 556 BPI transport > which, while not applicable to V7 UNIX tapes as so described, has me > itching to explore the world of magtape further, including eventually > tracking down a 9-track supporting the necessary BPI should another UNIX > tape needing preservation surface. > > I also recently got a QIC drive (not the right size for the early 90s > BTL tapes I have) and am exploring repurposing the read head to yank > data off these janky QIC tapes I have. Needless to say, magnetic tape > media and preservation is on the mind lately. > > Further on the subject of UNIX tapes though, was there any regular > shipment of other media not matching this description or was it pretty > settled that > > order_unix() > > has a return type of > > mt_track_9_bpi_800_t > > ? > > - Matt G. From tuhs at tuhs.org Wed Apr 1 20:10:39 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Wed, 1 Apr 2026 21:10:39 +1100 Subject: [TUHS] Fwd: Choice of Tape Format for BTL UNIX Distro References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: Thanks I’ll try sending this to the list. > Begin forwarded message: > > From: arnold at skeeve.com > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > Date: 1 April 2026 at 8:41:04 pm AEDT > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > I don't see the list in the To: or CC: > > Thanks for confirming my memory that 6400 BPI drives existed. > > Peter Yardley wrote: > >> Don’t know if this will hit the list. >> >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. >> >> The 6400 BPI drives were much more expensive so not everyone had one. >> >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: >>> >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you >>> eight bits of data plus a parity bit. >>> >>> By the mid-80s, 1600 BPI was pretty common for the same media, so >>> the BSD distributions might have been 1600 BPI tapes. >>> >>> I think at some point 9 track tape drives hit something like 6400 BPI, >>> but I may be hallucinating the memory. >>> >>> HTH, >>> >>> Arnold >>> >>> segaloco via TUHS wrote: >>> >>>> Surprise surprise, another hyper-specific topic incoming. I am curious >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - >>>> Seventh Edition indicates: >>>> >>>>> The tape is 9-track 800 BPI... >>>> >>>> Was this a matter of convention given the general computing ecosystem at >>>> the time, or was this more driven by Bell System standards for magtape? >>>> >>>> I find myself curious as I recently procured a 7-track 556 BPI transport >>>> which, while not applicable to V7 UNIX tapes as so described, has me >>>> itching to explore the world of magtape further, including eventually >>>> tracking down a 9-track supporting the necessary BPI should another UNIX >>>> tape needing preservation surface. >>>> >>>> I also recently got a QIC drive (not the right size for the early 90s >>>> BTL tapes I have) and am exploring repurposing the read head to yank >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape >>>> media and preservation is on the mind lately. >>>> >>>> Further on the subject of UNIX tapes though, was there any regular >>>> shipment of other media not matching this description or was it pretty >>>> settled that >>>> >>>> order_unix() >>>> >>>> has a return type of >>>> >>>> mt_track_9_bpi_800_t >>>> >>>> ? >>>> >>>> - Matt G. >> >> >> .1.3.6.1.4.1.8852.4.2 >> Peter Yardley >> peter.martin.yardley at gmail.com .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Wed Apr 1 20:18:31 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 01 Apr 2026 04:18:31 -0600 Subject: [TUHS] Fwd: Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: <202604011018.631AIVqY002680@freefriends.org> Clem Cole reminds me that the denser drives were 6250 BPI, not 6400. Thanks, Arnold Peter Yardley via TUHS wrote: > Thanks I’ll try sending this to the list. > > > Begin forwarded message: > > > > From: arnold at skeeve.com > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > Date: 1 April 2026 at 8:41:04 pm AEDT > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > I don't see the list in the To: or CC: > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > Peter Yardley wrote: > > > >> Don’t know if this will hit the list. > >> > >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. > >> > >> The 6400 BPI drives were much more expensive so not everyone had one. > >> > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: > >>> > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > >>> eight bits of data plus a parity bit. > >>> > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > >>> the BSD distributions might have been 1600 BPI tapes. > >>> > >>> I think at some point 9 track tape drives hit something like 6400 BPI, > >>> but I may be hallucinating the memory. > >>> > >>> HTH, > >>> > >>> Arnold > >>> > >>> segaloco via TUHS wrote: > >>> > >>>> Surprise surprise, another hyper-specific topic incoming. I am curious > >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - > >>>> Seventh Edition indicates: > >>>> > >>>>> The tape is 9-track 800 BPI... > >>>> > >>>> Was this a matter of convention given the general computing ecosystem at > >>>> the time, or was this more driven by Bell System standards for magtape? > >>>> > >>>> I find myself curious as I recently procured a 7-track 556 BPI transport > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > >>>> itching to explore the world of magtape further, including eventually > >>>> tracking down a 9-track supporting the necessary BPI should another UNIX > >>>> tape needing preservation surface. > >>>> > >>>> I also recently got a QIC drive (not the right size for the early 90s > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape > >>>> media and preservation is on the mind lately. > >>>> > >>>> Further on the subject of UNIX tapes though, was there any regular > >>>> shipment of other media not matching this description or was it pretty > >>>> settled that > >>>> > >>>> order_unix() > >>>> > >>>> has a return type of > >>>> > >>>> mt_track_9_bpi_800_t > >>>> > >>>> ? > >>>> > >>>> - Matt G. > >> > >> > >> .1.3.6.1.4.1.8852.4.2 > >> Peter Yardley > >> peter.martin.yardley at gmail.com > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > From tuhs at tuhs.org Wed Apr 1 21:17:36 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 07:17:36 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <202604010851.6318pCpZ096750@freefriends.org> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> Message-ID: Matt, 1/2” 7-track magnetic tape was developed assuming the then 6-bit byte of early computers (IIRC by Univac originally). Tape was an imperfect media, so a 7th parity bit was added to help detect errors. Each byte plus its parity is written in parallel on the tape. In 1964, when Fred Brooks required Gene Amdahl to make a byte and a full word on the S/360 a power of two, the 9-track transport was created allowing a user can store a byte (8-bit) + parity. The traditional ½” magnetic tape reels varied in diameter depending on the tape length, with standard 9-track capacities ranging from 20 MB to 220 MB depending on the recording encoding and density a block size (used to reduce the IRGs). Also, remember 9-track was defined assuming start/stop operation of the tape transport (as opposed to streaming - used in ¼”, 4mm and many later DLT formats). The reason is that time is needed to “spin up” or “slow down” the tape reel motor between read or write operations - so the size of IRG is part of the ANSI standard. When the QIC standard was developed the assumption is that once started, the motor doesn’t stop. Data must be ready for the drive on writes or under run occurs, and motor stops backs up the tape and starts again when it has data [over run occurrs on read when the host cannot accept the data]. Also modern “streamers” write serially and traditionally use a serpentine data path and read/write in both direction. ½” tape media has been sold in the three factors, with the diameter of the reel determined by the total length of the tape it was designed to hold: - *600’*: 7-inch diameter reel. - *1200’*: 8.5-inch diameter reel. - *2400’*: 10.5-inch diameter reel (the most common industry standard). There was also a 3600’ tape made by 3M that used a thinner tape, so it fit on a 2400’ reel. The downside, was the risk of stretching, so it was ok as an archival (write once) use, but could be risky when used for things like incremental backup where the physical tape was reused many times. *Capacities and Recording Schemes* Each standard density used a specific encoding method to ensure data integrity and timing. Capacities listed below are approximate for a standard *2400’* reel: *800 bpi* *NRZI*(Non-Return-to-Zero, Inverted) *20–22.5 MB* Older format where a "1" bit is represented by a change in magnetic state. *1600 bpi* *PE* (Phase Encoding) *40–45 MB* Most common interchange format; every bit is represented by a transition in the middle of a bit cell. *6250 bpi* *GCR*(Group Coded Recording) *140–175 MB* High-density format using complex error detection and correction codes.It was often achieved by modifying the Phase Encoding (PE) scheme to double the recording density (sometimes called "Double Density PE"). It was popular on desktop/minicomputer drives in the 1980s to create higher-density tapes on a budget before 6250 GCR became universal. I don’t remember if it had a ANSI standard, but Cipher created 3200 bpi option, that I believe a couple of other transport vendors offered (IIRC Overland Data, but I don’t remember if Kennedy did also). The 3200 bpi encoding achieved by modifying the Phase Encoding (PE) scheme to double the recording density (sometimes called "Double Density PE"). It was popular on workstation/minicomputer drives in the 1980s to create higher-density tapes on a budget before 6250 GCR became universal. *Note: the capacity of a tape is highly dependent on the block **size/factor used; smaller blocks increased the number of Inter-Record Gaps (IRGs) [**reducing capacity]. Record sizes were traditionally limited to under 64k bytes as the tape controllers of the day were often unable to support records of larger size. With 512 byte block used by the minicomputers, blocking factors of 10 or 20 times such as tar’s 20b (10240 bytes) became a defacto standard. 36-bit systems like the PDP-10 often used record sizes such as 512 words * 36 bits + some header (2950 was typical) and the IBM mainframes were all over the map. * Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 4:51 AM Arnold Robbins via TUHS wrote: > In that time frame, 800 BPI was pretty standard. 9 tracks gave you > eight bits of data plus a parity bit. > > By the mid-80s, 1600 BPI was pretty common for the same media, so > the BSD distributions might have been 1600 BPI tapes. > > I think at some point 9 track tape drives hit something like 6400 BPI, > but I may be hallucinating the memory. > > HTH, > > Arnold > > segaloco via TUHS wrote: > > > Surprise surprise, another hyper-specific topic incoming. I am curious > > if anyone on-list can provide insight on this topic. Setting Up Unix - > > Seventh Edition indicates: > > > > > The tape is 9-track 800 BPI... > > > > Was this a matter of convention given the general computing ecosystem at > > the time, or was this more driven by Bell System standards for magtape? > > > > I find myself curious as I recently procured a 7-track 556 BPI transport > > which, while not applicable to V7 UNIX tapes as so described, has me > > itching to explore the world of magtape further, including eventually > > tracking down a 9-track supporting the necessary BPI should another UNIX > > tape needing preservation surface. > > > > I also recently got a QIC drive (not the right size for the early 90s > > BTL tapes I have) and am exploring repurposing the read head to yank > > data off these janky QIC tapes I have. Needless to say, magnetic tape > > media and preservation is on the mind lately. > > > > Further on the subject of UNIX tapes though, was there any regular > > shipment of other media not matching this description or was it pretty > > settled that > > > > order_unix() > > > > has a return type of > > > > mt_track_9_bpi_800_t > > > > ? > > > > - Matt G. > From tuhs at tuhs.org Wed Apr 1 21:24:36 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 07:24:36 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> Message-ID: Bad cut & paste on the iPhone. The comment field on GCR included stuff and PE that should not been there (GCR and PE are unrelated in this case). It should have simply read: “High-density format using complex error detection and correction codes.” Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 7:17 AM Clem Cole wrote: > Matt, > > 1/2” 7-track magnetic tape was developed assuming the then 6-bit byte of > early computers (IIRC by Univac originally). Tape was an imperfect media, > so a 7th parity bit was added to help detect errors. Each byte plus its > parity is written in parallel on the tape. In 1964, when Fred Brooks > required Gene Amdahl to make a byte and a full word on the S/360 a power of > two, the 9-track transport was created allowing a user can store a byte > (8-bit) + parity. > > The traditional ½” magnetic tape reels varied in diameter depending on > the tape length, with standard 9-track capacities ranging from 20 MB to > 220 MB depending on the recording encoding and density a block size (used > to reduce the IRGs). Also, remember 9-track was defined assuming > start/stop operation of the tape transport (as opposed to streaming - used > in ¼”, 4mm and many later DLT formats). The reason is that time is needed > to “spin up” or “slow down” the tape reel motor between read or write > operations - so the size of IRG is part of the ANSI standard. When the QIC > standard was developed the assumption is that once started, the motor > doesn’t stop. Data must be ready for the drive on writes or under run > occurs, and motor stops backs up the tape and starts again when it has data > [over run occurrs on read when the host cannot accept the data]. Also > modern “streamers” write serially and traditionally use a serpentine data > path and read/write in both direction. > > ½” tape media has been sold in the three factors, with the diameter of > the reel determined by the total length of the tape it was designed to hold: > > > - *600’*: 7-inch diameter reel. > - *1200’*: 8.5-inch diameter reel. > - *2400’*: 10.5-inch diameter reel (the most common industry standard). > > > There was also a 3600’ tape made by 3M that used a thinner tape, so it fit > on a 2400’ reel. The downside, was the risk of stretching, so it was ok as > an archival (write once) use, but could be risky when used for things like > incremental backup where the physical tape was reused many times. > > *Capacities and Recording Schemes* > > Each standard density used a specific encoding method to ensure data > integrity and timing. Capacities listed below are approximate for a > standard *2400’* reel: > > > *800 bpi* *NRZI*(Non-Return-to-Zero, Inverted) *20–22.5 MB* Older format > where a "1" bit is represented by a change in magnetic state. > *1600 bpi* *PE* (Phase Encoding) *40–45 MB* Most common interchange > format; every bit is represented by a transition in the middle of a bit > cell. > *6250 bpi* *GCR*(Group Coded Recording) *140–175 MB* High-density format > using complex error detection and correction codes.It was often achieved > by modifying the Phase Encoding (PE) scheme to double the recording density > (sometimes called "Double Density PE"). It was popular on > desktop/minicomputer drives in the 1980s to create higher-density tapes on > a budget before 6250 GCR became universal. > I don’t remember if it had a ANSI standard, but Cipher created 3200 bpi > option, that I believe a couple of other transport vendors offered (IIRC > Overland Data, but I don’t remember if Kennedy did also). The 3200 bpi > encoding achieved by modifying the Phase Encoding (PE) scheme to double the > recording density (sometimes called "Double Density PE"). It was popular on > workstation/minicomputer drives in the 1980s to create higher-density tapes > on a budget before 6250 GCR became universal. > > > *Note: the capacity of a tape is highly dependent on the block **size/factor used; > smaller blocks increased the number of Inter-Record Gaps (IRGs) [**reducing > capacity]. Record sizes were traditionally limited to under 64k bytes as > the tape controllers of the day were often unable to support records of > larger size. With 512 byte block used by the minicomputers, blocking > factors of 10 or 20 times such as tar’s 20b (10240 bytes) became a defacto > standard. 36-bit systems like the PDP-10 often used record sizes such as > 512 words * 36 bits + some header (2950 was typical) and the IBM mainframes > were all over the map. * > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 1, 2026 at 4:51 AM Arnold Robbins via TUHS > wrote: > >> In that time frame, 800 BPI was pretty standard. 9 tracks gave you >> eight bits of data plus a parity bit. >> >> By the mid-80s, 1600 BPI was pretty common for the same media, so >> the BSD distributions might have been 1600 BPI tapes. >> >> I think at some point 9 track tape drives hit something like 6400 BPI, >> but I may be hallucinating the memory. >> >> HTH, >> >> Arnold >> >> segaloco via TUHS wrote: >> >> > Surprise surprise, another hyper-specific topic incoming. I am curious >> > if anyone on-list can provide insight on this topic. Setting Up Unix - >> > Seventh Edition indicates: >> > >> > > The tape is 9-track 800 BPI... >> > >> > Was this a matter of convention given the general computing ecosystem at >> > the time, or was this more driven by Bell System standards for magtape? >> > >> > I find myself curious as I recently procured a 7-track 556 BPI transport >> > which, while not applicable to V7 UNIX tapes as so described, has me >> > itching to explore the world of magtape further, including eventually >> > tracking down a 9-track supporting the necessary BPI should another UNIX >> > tape needing preservation surface. >> > >> > I also recently got a QIC drive (not the right size for the early 90s >> > BTL tapes I have) and am exploring repurposing the read head to yank >> > data off these janky QIC tapes I have. Needless to say, magnetic tape >> > media and preservation is on the mind lately. >> > >> > Further on the subject of UNIX tapes though, was there any regular >> > shipment of other media not matching this description or was it pretty >> > settled that >> > >> > order_unix() >> > >> > has a return type of >> > >> > mt_track_9_bpi_800_t >> > >> > ? >> > >> > - Matt G. >> > From tuhs at tuhs.org Thu Apr 2 08:07:20 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Thu, 2 Apr 2026 09:07:20 +1100 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> Thanks Clem My submissions to the list were getting lost. Been about 30 years since I last used tape in anger. Your answer was quite comprehensive. > On 1 Apr 2026, at 11:11 pm, Clem Cole wrote: > > Take a look at what I sent to whole list. If you have questions let me know off list. Clem > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 1, 2026 at 6:11 AM Peter Yardley via TUHS wrote: > Thanks I’ll try sending this to the list. > > > Begin forwarded message: > > > > From: arnold at skeeve.com > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > Date: 1 April 2026 at 8:41:04 pm AEDT > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > I don't see the list in the To: or CC: > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > Peter Yardley wrote: > > > >> Don’t know if this will hit the list. > >> > >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. > >> > >> The 6400 BPI drives were much more expensive so not everyone had one. > >> > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: > >>> > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > >>> eight bits of data plus a parity bit. > >>> > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > >>> the BSD distributions might have been 1600 BPI tapes. > >>> > >>> I think at some point 9 track tape drives hit something like 6400 BPI, > >>> but I may be hallucinating the memory. > >>> > >>> HTH, > >>> > >>> Arnold > >>> > >>> segaloco via TUHS wrote: > >>> > >>>> Surprise surprise, another hyper-specific topic incoming. I am curious > >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - > >>>> Seventh Edition indicates: > >>>> > >>>>> The tape is 9-track 800 BPI... > >>>> > >>>> Was this a matter of convention given the general computing ecosystem at > >>>> the time, or was this more driven by Bell System standards for magtape? > >>>> > >>>> I find myself curious as I recently procured a 7-track 556 BPI transport > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > >>>> itching to explore the world of magtape further, including eventually > >>>> tracking down a 9-track supporting the necessary BPI should another UNIX > >>>> tape needing preservation surface. > >>>> > >>>> I also recently got a QIC drive (not the right size for the early 90s > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape > >>>> media and preservation is on the mind lately. > >>>> > >>>> Further on the subject of UNIX tapes though, was there any regular > >>>> shipment of other media not matching this description or was it pretty > >>>> settled that > >>>> > >>>> order_unix() > >>>> > >>>> has a return type of > >>>> > >>>> mt_track_9_bpi_800_t > >>>> > >>>> ? > >>>> > >>>> - Matt G. > >> > >> > >> .1.3.6.1.4.1.8852.4.2 > >> Peter Yardley > >> peter.martin.yardley at gmail.com > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Thu Apr 2 09:04:51 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Apr 2026 23:04:51 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured Message-ID: Howdy folks, I've got some exciting news for UNIX document preservation. I just closed this purchase: https://www.ebay.com/itm/147235873077 After the link is an auction for several original BTL UNIX manuals and technical memoranda, including: Documents for UNIX - Sixth Edition Seventh Edition Volume 2A/2B UNIX Product Release Description - Release 4.0 Program Generic PG-1C300 Issue 3 UNIX Release 4.0 Release Notes Package Several Technical Memoranda For me the most exciting parts are the Release 4.0 material and the Program Generic Issue 3 manual. This all should be arriving in a week or two, at which point I'll bump it to the top of my scan list (right under the SVR2 BTL manual I'm halfway through right now). More to come! Also, the seller also has original print BBN UNIX literature, I expressed no personal interest as I'm keeping focused on BTL and UCB, but I'll share when that auction is posted as they seem like quite rare pieces someone here might be interested in. - Matt G. From tuhs at tuhs.org Thu Apr 2 09:16:28 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 19:16:28 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> References: <202604010941.6319f4uM099912@freefriends.org> <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> Message-ID: Most welcome. Glad it was helpful. I’ve actually been considered a tape wizard by many of my friends. It really goes back to learning my learn how to handle tapes on TSS/360 an Exec 8 on the Univac, early in my career. The later had three 7-track drives (5-20 M 6-bit bytes) and very little drum/disk. I still can speak a bit of the language with term like LRECL [Logical RECord length - IBM speak for block size]. Tapes often had file systems on them. Technically that can be read or written in both directions in the old mainframe world. Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 6:07 PM Peter Yardley wrote: > Thanks Clem > > My submissions to the list were getting lost. > > Been about 30 years since I last used tape in anger. Your answer was quite > comprehensive. > > > On 1 Apr 2026, at 11:11 pm, Clem Cole wrote: > > > > Take a look at what I sent to whole list. If you have questions let me > know off list. Clem > > > > Sent from a handheld expect more typos than usual > > > > > > On Wed, Apr 1, 2026 at 6:11 AM Peter Yardley via TUHS > wrote: > > Thanks I’ll try sending this to the list. > > > > > Begin forwarded message: > > > > > > From: arnold at skeeve.com > > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > > Date: 1 April 2026 at 8:41:04 pm AEDT > > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > > > I don't see the list in the To: or CC: > > > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > > > Peter Yardley wrote: > > > > > >> Don’t know if this will hit the list. > > >> > > >> My memory is we had a 1600 BPI tape drive. Of course that would have > read 800BPi tapes. > > >> > > >> The 6400 BPI drives were much more expensive so not everyone had one. > > >> > > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS > wrote: > > >>> > > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > > >>> eight bits of data plus a parity bit. > > >>> > > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > > >>> the BSD distributions might have been 1600 BPI tapes. > > >>> > > >>> I think at some point 9 track tape drives hit something like 6400 > BPI, > > >>> but I may be hallucinating the memory. > > >>> > > >>> HTH, > > >>> > > >>> Arnold > > >>> > > >>> segaloco via TUHS wrote: > > >>> > > >>>> Surprise surprise, another hyper-specific topic incoming. I am > curious > > >>>> if anyone on-list can provide insight on this topic. Setting Up > Unix - > > >>>> Seventh Edition indicates: > > >>>> > > >>>>> The tape is 9-track 800 BPI... > > >>>> > > >>>> Was this a matter of convention given the general computing > ecosystem at > > >>>> the time, or was this more driven by Bell System standards for > magtape? > > >>>> > > >>>> I find myself curious as I recently procured a 7-track 556 BPI > transport > > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > > >>>> itching to explore the world of magtape further, including > eventually > > >>>> tracking down a 9-track supporting the necessary BPI should another > UNIX > > >>>> tape needing preservation surface. > > >>>> > > >>>> I also recently got a QIC drive (not the right size for the early > 90s > > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > > >>>> data off these janky QIC tapes I have. Needless to say, magnetic > tape > > >>>> media and preservation is on the mind lately. > > >>>> > > >>>> Further on the subject of UNIX tapes though, was there any regular > > >>>> shipment of other media not matching this description or was it > pretty > > >>>> settled that > > >>>> > > >>>> order_unix() > > >>>> > > >>>> has a return type of > > >>>> > > >>>> mt_track_9_bpi_800_t > > >>>> > > >>>> ? > > >>>> > > >>>> - Matt G. > > >> > > >> > > >> .1.3.6.1.4.1.8852.4.2 > > >> Peter Yardley > > >> peter.martin.yardley at gmail.com > > > > > > .1.3.6.1.4.1.8852.4.2 > > Peter Yardley > > peter.martin.yardley at gmail.com > > > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > > From tuhs at tuhs.org Thu Apr 2 16:41:25 2026 From: tuhs at tuhs.org (Rich Kulawiec via TUHS) Date: Thu, 2 Apr 2026 02:41:25 -0400 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: References: <20260323135651.GA4848@gsp.org> Message-ID: <20260402064125.GA25443@gsp.org> On Mon, Mar 23, 2026 at 10:24:44PM +0100, Martin Schr??der via TUHS wrote: > Is there an "official" obituary somewhere that can be cited by e.g. Wikipedia? There is. The link was sent by one of the other long, LONG-time Purdue folks: George Goble - Obituary - Journal and Courier https://www.jconline.com/obituaries/psbn1445636 ---rsk From tuhs at tuhs.org Mon Apr 6 17:37:10 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 07:37:10 +0000 Subject: [TUHS] 9P Communities like TUHS? Message-ID: So several recommendations here coupled with a recent system transition has finally landed me on 9front for my personal computer. I'm super excited to finally take this step, its a long time coming. I was curious if anyone can recommend a community much like this but 9P focused? I haven't "started fresh" since I first picked up GNU nearly 2 decades ago now, so its an exciting time of discovery and learning I'd love to find some folks to chit chat with. - Matt G. P.S. Big UNIX manual shipment slated for tomorrow. Between that and now aiming to get a full 9front print manual set...I'm gonna need a bigger bookshelf... From tuhs at tuhs.org Mon Apr 6 20:47:34 2026 From: tuhs at tuhs.org (=?utf-8?q?Rodrigo_G=2E_L=C3=B3pez_via_TUHS?=) Date: Mon, 6 Apr 2026 12:47:34 +0200 Subject: [TUHS] 9P Communities like TUHS? In-Reply-To: References: Message-ID: hi matt, you should join the 9front ml: https://lists.9front.org/ welcome! -rodri On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: > So several recommendations here coupled with a recent system transition > has finally landed me on 9front for my personal computer. I'm super > excited to finally take this step, its a long time coming. I was curious > if anyone can recommend a community much like this but 9P focused? I > haven't "started fresh" since I first picked up GNU nearly 2 decades ago > now, so its an exciting time of discovery and learning I'd love to find > some folks to chit chat with. > > - Matt G. > > P.S. Big UNIX manual shipment slated for tomorrow. Between that and now > aiming to get a full 9front print manual set...I'm gonna need a bigger > bookshelf... > From tuhs at tuhs.org Mon Apr 6 23:21:03 2026 From: tuhs at tuhs.org (Stanley Lieber via TUHS) Date: Mon, 6 Apr 2026 09:21:03 -0400 Subject: [TUHS] 9p discussion Message-ID: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> hello, i saw your post on tuhs. you’ll probably dig this up eventually, but: https://fqa.9front.org/fqa2.html#2.2 regards, sl From tuhs at tuhs.org Mon Apr 6 23:43:29 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Mon, 6 Apr 2026 14:43:29 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> Message-ID: <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> On 27/03/2026 05:05, Greg 'groggy' Lehey wrote: > OK, I've tried in a different system and got the same errors, so it's > the CD. But strangely I could mount it, and I've made a tar archive > of it:http://lax.lemis.com/grog/panic-cdrom.tar. It's only 1722 kB > in size. I can untar it and get the files, but of course I can't > confirm that they're correct. Can you compare? Thanks for digging in, Greg. Unfortunately your URL never worked for me. A kind person sent me an archive from their CD, off-list, which I've posted on my site. Just to be helpful to scrapers, the file is up at /files/panic-cdrom-files.zip on the domain of my email address, accessible via HTTPS :-) Sincerely, Sevan From tuhs at tuhs.org Tue Apr 7 02:47:12 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Mon, 06 Apr 2026 18:47:12 +0200 Subject: [TUHS] 9p discussion In-Reply-To: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> References: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> Message-ID: <20260406164712.MG3cTU5i@steffen%sdaoden.eu> Stanley Lieber via TUHS wrote in <5282DF63-A000-4019-8A79-20E3D18C24AE at stanleylieber.com>: |i saw your post on tuhs. you’ll probably dig this up eventually, but: | |https://fqa.9front.org/fqa2.html#2.2 And i wanted to post the following, but did not yet. Hello Stanley! Rodrigo G. López via TUHS wrote in : |On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: | |> So several recommendations here coupled with a recent system transition |> has finally landed me on 9front for my personal computer. I'm super |> excited to finally take this step, its a long time coming. I was curious |> if anyone can recommend a community much like this but 9P focused? I |> haven't "started fresh" since I first picked up GNU nearly 2 decades ago |> now, so its an exciting time of discovery and learning I'd love to find |> some folks to chit chat with. |> |> - Matt G. |> |> P.S. Big UNIX manual shipment slated for tomorrow. Between that and now |> aiming to get a full 9front print manual set...I'm gonna need a bigger |> bookshelf... |you should join the 9front ml: https://lists.9front.org/ And 9fans at 9fans.net (the ~"what were they thinking?" group, posted after the last systemcall was added to the "labs version" ... sysnsec?), at times posts appear. And plan9port-dev at googlegroups.com for the plan9-on-XY layer. The "Introduction to Operating Systems Abstractions. Using Plan9 from Bell Labs" of Francisco J Ballesteros is a great book. (The V4 commentary of Rodriguez "just appeared", also is, i find.) I kept a farewell program that umbraticus_at_prosimetrum_dot_com posted once Mycroftiv, a well known person in the Plan9 community, died, and that source code alone is so "extraterristrian" in the Linux / BSD* environment i live in! My terminal (font) cannot even display it in full. UNIX boy and girl become real Eunuchs when facing Plan9. So they sing higher. What i also like is their coding style, "continued" on 9front. That is the style Kernighan used in v6's RAT[FOR], and Johnson used in v6's yacc, in 1975. Fun fact: it seems the gigabyte big clang compiler framework, which also includes a code formatter, is incapable to be configurable to reiterate this coding style! Eg for(i=0; i References: Message-ID: On Monday, April 6th, 2026 at 03:48, Rodrigo G. López via TUHS wrote: > hi matt, > > you should join the 9front ml: https://lists.9front.org/ > > welcome! > > > -rodri > > On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: > > > So several recommendations here coupled with a recent system transition > > has finally landed me on 9front for my personal computer. I'm super > > excited to finally take this step, its a long time coming. I was curious > > if anyone can recommend a community much like this but 9P focused? I > > haven't "started fresh" since I first picked up GNU nearly 2 decades ago > > now, so its an exciting time of discovery and learning I'd love to find > > some folks to chit chat with. > > > > - Matt G. > > > > P.S. Big UNIX manual shipment slated for tomorrow. Between that and now > > aiming to get a full 9front print manual set...I'm gonna need a bigger > > bookshelf... > > > Thanks for the recommendations everyone! I try and keep my subscription list pretty small so appreciate the opportunity for some second opinions before I go signing up for a new list. - Matt G. From tuhs at tuhs.org Tue Apr 7 07:02:07 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 6 Apr 2026 14:02:07 -0700 Subject: [TUHS] the device tree, hardware, and kernels. Message-ID: I'm trying to refresh my memory on something. The first machines to have a device tree were, .. Sun 4/Power/Mac? Of these, which was first, first? The intent of the device tree was to be embedded in a ROM (or writable ROM) such that a kernel could figure out properties of hardware, as I recall. Is this even vaguely correct? It seems to track with my current digging. The reason I ask: somehow, the device tree is now something that gets packaged with the kernel, which seems a violation of its purpose. But, for example, linux kexec on risc-v will fail (EINVAL) if it is not passed a device tree. The Image struct for arm and riscv usually has a device tree at the front. And the risc-v linux source includes a bunch of device trees. For some boards, there is more than one choice, and if you pick the wrong one, you get a brick. Was the device tree a Mitch Bradley thing? From tuhs at tuhs.org Tue Apr 7 07:03:18 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Mon, 6 Apr 2026 22:03:18 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> Message-ID: <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > A kind person sent me an archive from their CD, off-list, which I've > posted on my site. Forgot to say, they also had read issues with the disk too. They removed the disk from the book's sleeve for the first time to grab the files so it may be that there was a mastering problem with the CDs as it's the 3rd occurrence?!? Sevan From tuhs at tuhs.org Tue Apr 7 07:09:17 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:09:17 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On 4/6/26 2:02 PM, ron minnich via TUHS wrote: > Was the device tree a Mitch Bradley thing? > yes. Sun's Open Firmware was first From tuhs at tuhs.org Tue Apr 7 07:11:37 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:11:37 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> On 4/6/26 2:09 PM, Al Kossow via TUHS wrote: > On 4/6/26 2:02 PM, ron minnich via TUHS wrote: > >> Was the device tree a Mitch Bradley thing? >> > > yes. Sun's Open Firmware was first Apple adopted PCI assuming that card vendors would include OF along with PC BIOS. Unfortunately that rarely happened. It ended up that only cards required during boot ended up with OF in rom. From tuhs at tuhs.org Tue Apr 7 07:14:09 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:14:09 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> References: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> Message-ID: On 4/6/26 2:11 PM, Al Kossow wrote: > On 4/6/26 2:09 PM, Al Kossow via TUHS wrote: >> On 4/6/26 2:02 PM, ron minnich via TUHS wrote: >> >>> Was the device tree a Mitch Bradley thing? >>> >> >> yes. Sun's Open Firmware was first > > Apple adopted PCI assuming that card vendors would include OF along > with PC BIOS. Unfortunately that rarely happened. It ended up that > only cards required during boot ended up with OF in rom. > The other difference was OF hung around on Suns after the OS booted. On the Mac, it was discarded after the first stage bootstrap. From tuhs at tuhs.org Tue Apr 7 08:12:48 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 22:12:48 +0000 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Monday, April 6th, 2026 at 14:02, ron minnich via TUHS wrote: > The reason I ask: somehow, the device tree is now something that gets > packaged with the kernel, which seems a violation of its purpose. Somewhat, you get a DTB in your boot partition (usually FAT to appease UEFI these days afaik) but this boot partition may be loading a kernel directly on some systems, dropping in a uboot loader on others, but the DTB gets loaded usually pretty darn early, in my experience prior to jumping into the actual kernel bootstrap, much like how PCs dump a bunch of information in a know memory location ala BIOS for the bootstrap to inspect. Granted the sources that become DTBs I see distributed as DTSs with i.e. the Linux kernel. I don't know DTB holistically, if there is some upstream that feeds the penguins or if they run the show on their DTB stuff. > The Image struct for arm and riscv usually has a device tree > at the front. This is not my experience on Raspberry Pi and RISC-V distros of Linux and FreeBSD I've used. They all had a directory of DTBs in their boot partition that were selected from by whatever bootloader stage straps in the kernel, initramfs, etc. The kernel Image file, initrd, and dtb are transferred as separate BLOBs, so could exist independently of one another. - Matt G. From tuhs at tuhs.org Tue Apr 7 08:17:52 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 22:17:52 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> Message-ID: On Monday, April 6th, 2026 at 14:03, Sevan Janiyan via TUHS wrote: > On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > > A kind person sent me an archive from their CD, off-list, which I've > > posted on my site. > > Forgot to say, they also had read issues with the disk too. They removed > the disk from the book's sleeve for the first time to grab the files so > it may be that there was a mastering problem with the CDs as it's the > 3rd occurrence?!? > > Sevan > Weird disk that isn't a straightforward single track ISO9660? I used to run into that all the time with preserving optical media for game consoles. Our goto in that scene was bin/cue for funky optical media. - Matt G. From tuhs at tuhs.org Tue Apr 7 08:30:23 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 6 Apr 2026 15:30:23 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: in linux, there are 236 files in the riscv part of the tree, for 60 boards. Riscv kexec is pretty insistent on having a dts for kernels it boots. There are 2821 files fitting this pattern: "dts$" in the tree. They seem to each apply to one board; in some cases, there are DTS for different versions of the same board (I'm seeing this with some risc-v boards). I think my notions of where the DTS lives are pretty much obsolete :-) Anyway, thanks all, and especially Tom for getting Mitch here, and to Mitch for his reply :-) On Mon, Apr 6, 2026 at 3:12 PM segaloco via TUHS wrote: > On Monday, April 6th, 2026 at 14:02, ron minnich via TUHS > wrote: > > > The reason I ask: somehow, the device tree is now something that gets > > packaged with the kernel, which seems a violation of its purpose. > > Somewhat, you get a DTB in your boot partition (usually FAT to appease > UEFI these days afaik) but this boot partition may be loading a kernel > directly on some systems, dropping in a uboot loader on others, but the DTB > gets loaded usually pretty darn early, in my experience prior to jumping > into the actual kernel bootstrap, much like how PCs dump a bunch of > information in a know memory location ala BIOS for the bootstrap to > inspect. Granted the sources that become DTBs I see distributed as DTSs > with i.e. the Linux kernel. I don't know DTB holistically, if there is > some upstream that feeds the penguins or if they run the show on their DTB > stuff. > > > The Image struct for arm and riscv usually has a device tree > > at the front. > > This is not my experience on Raspberry Pi and RISC-V distros of Linux and > FreeBSD I've used. They all had a directory of DTBs in their boot > partition that were selected from by whatever bootloader stage straps in > the kernel, initramfs, etc. The kernel Image file, initrd, and dtb are > transferred as separate BLOBs, so could exist independently of one another. > > - Matt G. > From tuhs at tuhs.org Tue Apr 7 08:49:32 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 6 Apr 2026 18:49:32 -0400 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Mon, Apr 6, 2026 at 5:02 PM ron minnich via TUHS wrote: > I'm trying to refresh my memory on something. > > The first machines to have a device tree were, .. Sun 4/Power/Mac? Of > these, which was first, first? Sun, with OpenBoot, for sure. > The intent of the device tree was to be embedded in a ROM (or writable ROM) > such that a kernel could figure out properties of hardware, as I recall. As I understood it, it was constructed in memory by the ROM monitor, and the OS walked and parsed it, by reaching back into the PROM monitor to get the actual data. > Is this even vaguely correct? It seems to track with my current digging. I think it served two purposes: 1) it provided some mechanism for the machine to boot. If the OS was on a storage device that itself is on the far side of an HBA that needs non-trivial support to get itself going, what do you do? Answer: embed an interpreter for a small, low-level language into your ROM monitor and have an option ROM on each device that contains a program in that language with enough smarts to load a real OS from it. Sun chose Forth, but UEFI went a different route. 2) provide an accounting of the machine that the OS could absorb so that it didn't have to (re)probe everything. Presumably the PROM monitor had already enumerated the SBus or PCI; in that case, having the OS do it again feels like busy-work. I think now days we mostly use it for the latter, and the former has been more or less lost. > The reason I ask: somehow, the device tree is now something that gets > packaged with the kernel, which seems a violation of its purpose. I can kind of see it. For a small SBC where devices are physically soldered onto the board, there's not a lot of expansion to be done: the device tree itself is pretty much static. If you just plop it into an flash device or something, you can skip the full PROM monitor/Forth interpreter/option ROM thing. > But, for > example, linux kexec on risc-v will fail (EINVAL) if it is not passed a > device tree. The Image struct for arm and riscv usually has a device tree > at the front. And the risc-v linux source includes a bunch of device trees. > For some boards, there is more than one choice, and if you pick the wrong > one, you get a brick. > > Was the device tree a Mitch Bradley thing? From tuhs at tuhs.org Tue Apr 7 09:12:03 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 23:12:03 +0000 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Monday, April 6th, 2026 at 15:50, Dan Cross via TUHS wrote: > I can kind of see it. For a small SBC where devices are physically > soldered onto the board, there's not a lot of expansion to be done: > the device tree itself is pretty much static. If you just plop it > into an flash device or something, you can skip the full PROM > monitor/Forth interpreter/option ROM thing. > Well and the prevailing SBC ecosystems aren't nearly as standardized as PC has historically been. These devices don't have some least common denominator "I'm an 8086 with bus characteristics " so the kernel needs a little more help. DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. Plus, sometimes this means if you already have kernel support for device *xyz* in your current image and add one such device at some I/O address, you just have to rebuild your dtb rather than the kernel hiding all of that info deep inside. Much lower risk to roll back a dtb than a whole kernel too. Annoyingly it makes provision of quality documentation on memory maps and bus architecture a little worse, seems like you just have to "trust the dts" in many cases these days... - Matt G. From tuhs at tuhs.org Tue Apr 7 13:03:02 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 03:03:02 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: References: Message-ID: On Wednesday, April 1st, 2026 at 16:05, segaloco via TUHS wrote: > Howdy folks, I've got some exciting news for UNIX document preservation. > I just closed this purchase: > > ... > > - Matt G. > I just couldn't hold my excitement any longer, I decided to short circuit my scan backlog and scan this, the Product Release Description for UNIX Release 4.0: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Product_Release_Description_Release_4.0.pdf Lots of good stuff there, this is the predecessor of the System Release Description distributed with System V, similarly it has an MR report which, with the System V one, could be used to reconstruct Release 4.0 to a highly accurate degree at least as far as the interface is concerned. I've been feeling quite sentimental scanning this one because it was nearly two decades ago when I first got into UNIX-like systems and started getting curious about why there wasn't a System IV. That single question, what happened to System IV, is the flashpoint that eventually lead me to all of this documentation work. This feels like the conclusion of a long and winding road, but also just the beginning. Now I can set about the task of reconstructing a UNIX Release 4.0 work-alike, achieving partially the goal of preserving the running system, although that would be in name only. I'm still holding out hope some real tapes might surface eventually. In any case, I'm over the moon about finally finding these. This isn't the only Release 4.0 literature in this lot, the other I plan on scanning after I finish that SVR2 manual is a manpage supplement and the original release notification for Release 4.0. The PRD here indicates that indeed: > No new hardcopy user's manual will be produced for this release, but the > delivered on-line copy is correct and up-to-date. In addition, some > machine reproducible documents are included on the release tape. Confirming what Arnold Robbins and others have indicated, that BTL saw no need to do a print run of the Release 4.0 literature. That makes this stack of manpage edits the closest thing to a Release 4.0 physical manual publication. Couple that with the Volume 2 issues and flipbook from Arnold Robbins and there are now very few holes left in the documentation history of Release 4.0. I will be sharing more documents from this lot as time goes on but this one was just so special and sentimental to me that I had to bump it to the top. Enjoy! - Matt G. From tuhs at tuhs.org Tue Apr 7 13:41:10 2026 From: tuhs at tuhs.org (r.stricklin via TUHS) Date: Mon, 6 Apr 2026 20:41:10 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> Message-ID: <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > Weird disk that isn't a straightforward single track ISO9660? I used to run into that all the time with preserving optical media for game consoles. Our goto in that scene was bin/cue for funky optical media. More likely just that CD-ROM isn’t an archival medium. I’ve encountered any number of e.g. early ‘90s Sun CDs with optical rot of one kind or another. Oxidation of the aluminum layer, clouding in the polycarbonate layer… It doesn’t surprise me to hear that, having encountered one bad CD, several other copies had similar problems. ok bear. From tuhs at tuhs.org Tue Apr 7 15:03:15 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 6 Apr 2026 23:03:15 -0600 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: On Mon, Apr 6, 2026 at 9:42 PM r.stricklin via TUHS wrote: > > > > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > > > Weird disk that isn't a straightforward single track ISO9660? I used to > run into that all the time with preserving optical media for game > consoles. Our goto in that scene was bin/cue for funky optical media. > > More likely just that CD-ROM isn’t an archival medium. I’ve encountered > any number of e.g. early ‘90s Sun CDs with optical rot of one kind or > another. Oxidation of the aluminum layer, clouding in the polycarbonate > layer… It doesn’t surprise me to hear that, having encountered one bad CD, > several other copies had similar problems. > The Solaris 2.0 Alpha binary CD that I have has been unreadable for at least 15 years. Warner From tuhs at tuhs.org Tue Apr 7 16:09:34 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 06:09:34 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: On Monday, April 6th, 2026 at 22:03, Warner Losh via TUHS wrote: > On Mon, Apr 6, 2026 at 9:42 PM r.stricklin via TUHS wrote: > > > > > > > > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > > > > > Weird disk that isn't a straightforward single track ISO9660? I used to > > run into that all the time with preserving optical media for game > > consoles. Our goto in that scene was bin/cue for funky optical media. > > > > More likely just that CD-ROM isn’t an archival medium. I’ve encountered > > any number of e.g. early ‘90s Sun CDs with optical rot of one kind or > > another. Oxidation of the aluminum layer, clouding in the polycarbonate > > layer… It doesn’t surprise me to hear that, having encountered one bad CD, > > several other copies had similar problems. > > > > The Solaris 2.0 Alpha binary CD that I have has been unreadable for at > least 15 years. > > Warner > I guess the question then becomes whether the multiple bad dumps have the proper complement of good blocks between them to assemble a proper image. This may also suggest performing something like a bin/cue backup that captures more sector information, that way you can also use that metadata to better reconstruct a complete image. This has been done for a few video games where just enough good blocks could be pulled from known-but-decayed specimens that the correct image could ultimately be produced. Heck just recently in the NES circle I chit-chat in, a few folks were able to recover a lost bootleg title by visually analyzing mis-matched cartridge traces to the particular ROM chip involved coupled with analysis of a good dump of the title the pirate was built on, resulting in determining which address and data bus bits were reversed and both the precise bit twiddling on both data and addresses that was necessary to reproduce a functional, playable copy of the game, and also the banking logic that was buried under a chip-on-board blob. This subject of creative recovery methods is quite interesting to me, I often times worry that the video game and general systems history communities don't have a lot of crossover because several of my go-to "archaeological" techniques derive from practices in the video game ROM hacking and emulation communities rather than the folks in institutions with credentials archiving UNIVAC magtapes and Western Electric ROMs. All to say I do love these moments when the oddball techniques from the video game preservation microcosm are also applicable to the other tech history stuff I appreciate. - Matt G. From tuhs at tuhs.org Tue Apr 7 16:11:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 06:11:18 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Bounced for Greg below: On Monday, April 6th, 2026 at 23:01, Greg 'groggy' Lehey wrote: > I've been having difficulties with the TUHS mailing list. Warren is > informed. If you get this directly but not from the list, could you > bounce it, please? > > On Monday, 6 April 2026 at 14:43:29 +0100, Sevan Janiyan wrote: > > On 27/03/2026 05:05, Greg 'groggy' Lehey wrote: > >> OK, I've tried in a different system and got the same errors, so it's > >> the CD. But strangely I could mount it, and I've made a tar archive > >> of it:http://lax.lemis.com/grog/panic-cdrom.tar. It's only 1722 kB > >> in size. I can untar it and get the files, but of course I can't > >> confirm that they're correct. Can you compare? > > > > Thanks for digging in, Greg. > > Unfortunately your URL never worked for me. > > Sorry, it got removed automatically, presumably too soon for you. > It's there again now, and I'll leave it there for a while longer. > > > A kind person sent me an archive from their CD, off-list, which I've posted > > on my site. > > Just to be helpful to scrapers, the file is up at > > /files/panic-cdrom-files.zip on the domain of my email address, accessible > > via HTTPS :-) > > I've downloaded it and compared. All the files are the same and have > the same contents, so I assume that they're (both) correct. > > On Monday, 6 April 2026 at 22:03:18 +0100, Sevan Janiyan wrote: > > On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > >> A kind person sent me an archive from their CD, off-list, which I've > >> posted on my site. > > > > Forgot to say, they also had read issues with the disk too. They removed the > > disk from the book's sleeve for the first time to grab the files so it may > > be that there was a mastering problem with the CDs as it's the 3rd > > occurrence?!? > > Sounds just like what I did. I wonder how many people actually used > the CD at the time. > > On Monday, 6 April 2026 at 22:17:52 +0000, segaloco wrote: > > On Monday, April 6th, 2026 at 14:03, Sevan Janiyan via TUHS wrote: > >> On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > >>> A kind person sent me an archive from their CD, off-list, which I've > >>> posted on my site. > >> > >> Forgot to say, they also had read issues with the disk too. They removed > >> the disk from the book's sleeve for the first time to grab the files so > >> it may be that there was a mastering problem with the CDs as it's the > >> 3rd occurrence?!? > > > > Weird disk that isn't a straightforward single track ISO9660? I > > used to run into that all the time with preserving optical media for > > game consoles. Our goto in that scene was bin/cue for funky optical > > media. > > Possibly. As I said, I had issues mounting it, but I could still read > the files. That suggests that it's not age-related deterioration, but > some incompatibility. If you have any ideas about how to investigate, > I'd be interested. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > From tuhs at tuhs.org Tue Apr 7 16:49:41 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 07 Apr 2026 00:49:41 -0600 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: References: Message-ID: <202604070649.6376nfH0099434@freefriends.org> Matt, This is great! I remember reading this document, but apparently I didn't copy it for myself at the time. My favorite part is to be found on page 5 of attachment 1, indicating changes: sort(1) The destroy-your-input-file feature is gone. This used to be accomplished by saying sort -ooutput input. If there was no space between the -o and the output file, the input file was assumed to be the argument to the -o and truncated to zero. Thanks for recovering this. Arnold segaloco via TUHS wrote: > On Wednesday, April 1st, 2026 at 16:05, segaloco via TUHS wrote: > > > Howdy folks, I've got some exciting news for UNIX document preservation. > > I just closed this purchase: > > > > ... > > > > - Matt G. > > > > I just couldn't hold my excitement any longer, I decided to short > circuit my scan backlog and scan this, the Product Release Description > for UNIX Release 4.0: > > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Product_Release_Description_Release_4.0.pdf > > Lots of good stuff there, this is the predecessor of the System Release > Description distributed with System V, similarly it has an MR report > which, with the System V one, could be used to reconstruct Release 4.0 > to a highly accurate degree at least as far as the interface is > concerned. > > I've been feeling quite sentimental scanning this one because it was > nearly two decades ago when I first got into UNIX-like systems and > started getting curious about why there wasn't a System IV. That single > question, what happened to System IV, is the flashpoint that eventually > lead me to all of this documentation work. This feels like the > conclusion of a long and winding road, but also just the beginning. Now > I can set about the task of reconstructing a UNIX Release 4.0 > work-alike, achieving partially the goal of preserving the running > system, although that would be in name only. I'm still holding out hope > some real tapes might surface eventually. > > In any case, I'm over the moon about finally finding these. This isn't > the only Release 4.0 literature in this lot, the other I plan on > scanning after I finish that SVR2 manual is a manpage supplement and the > original release notification for Release 4.0. The PRD here indicates > that indeed: > > > No new hardcopy user's manual will be produced for this release, but the > > delivered on-line copy is correct and up-to-date. In addition, some > > machine reproducible documents are included on the release tape. > > Confirming what Arnold Robbins and others have indicated, that BTL saw > no need to do a print run of the Release 4.0 literature. That makes > this stack of manpage edits the closest thing to a Release 4.0 physical > manual publication. Couple that with the Volume 2 issues and flipbook > from Arnold Robbins and there are now very few holes left in the > documentation history of Release 4.0. > > I will be sharing more documents from this lot as time goes on but this > one was just so special and sentimental to me that I had to bump it to > the top. > > Enjoy! > > - Matt G. From tuhs at tuhs.org Tue Apr 7 18:25:38 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 08:25:38 +0000 Subject: [TUHS] Program Generic Issue 3 Findings Message-ID: Long initial post for "PG-III General" incoming: After scanning the Release 4.0 PRD, I started thumbing through the Program Generic Issue 3 manual and hoo boy am I excited to get this one scanned. I've only bounced around but there are just so many little tidbits that I've been waiting to sink my teeth into for years. I'll leave a few highlights and due to the excitement, I am also going to scan this before I resume the schedule I set for myself weeks ago. Notable: sh(I) - The USG shell took a different track concerning capturing stderr via redirection. Rather than giving the three redirection symbols of the Thompson Shell (<, >, >>), the following are also given: %name causes 'name' to be used as the error output file for the associated command. 'Name' is created if it did not exist and is truncated at the outset. %%name causes 'name' to be used as the error output for the associated command. If 'name' did not exist, it is created; if it existed, the error output is appended to the file. s/2>>/%%/g s/2>/%/g May the USG shell be with you. msg(II) - USG PG-III is now the earliest confirmed manual sighting I know of demonstrating the early BTL IPC (which is actually proposed in one of the BTL library documents recently scanned by Stephen Searle[1]). The msg(II) page here, for instance ([2] from MERT 0 which is scanned and has this page verbatim) indicates the same interface that then gets pulled into the PWB line as of Release 4.0, albeit with a few new bits. This interface's influence can also be seen in CB-UNIX as of Edition 2.3[3] albeit with some differences. However, even as early as 1977 this interface was also intertwined with CB-UNIX as described in another technical report[4] which also brings in things like MAUS. As of Release *4.1* for the 3B20S, however, the IPC starts to look a bit more like System V IPC[5]. All in all this puts the development of this early IPC that was replaced in System V either in the SCCS/CB branch or squarely in USG PG-III (give or take whatever UNIX tide-pool it first gestated in.) In any case, this sets the backstop on manpages for pre-V IPC at March 1977. This makes the picture from 1976 to 1983 with IPC much more clear. I'm glad I don't actually have to scan anything else to aggregate this info together. lines(V) - My suspicion that System V init(8) derived from PG-III init is stronger than ever. A part of this page is found in the scanned CB-UNIX 2.3 manual[6][7] but the first is cut-off and the second indicates replacement by inittab(5). In CB-UNIX 2.3[8], inittab(5) adds the powerfail and powerwait actions as well as initdefault. These enhancements also then show up in 5.0/System V[9], at which point a paper is added to the SRD[10]. I have not identified yet whether this paper derives from a specific Technical Memorandum or if it was drafted for the System V SRD itself. Either way, this confirms a heritage of System V init going back to at least March 1977 with Program Generic Issue 3. Will the sysvinit project rename to pg3init for my sake? Probably not...but I get to know the hidden truth. hd(IV) - From the page: "This section describes the half-duplex protocol implemented as a line discipline which permits access to UNIX using Teletype Model 40/1's and Model 40/2's (in 202 mode) using 202S data sets or null modems." I haven't completely done my homework on the Teletype Model 40's origins, I just know that it became the standard Bell System terminal for a while, showing up in for instance the 3B20S Release 4.1 User's Manual cover art[11] and other AT&T materials in the early 80s (I've got some non-UNIX-related American Bell stuff, 1982, I intend to scan soon. Very early, some nice pictures of a bunch of AT&T hardware, also first year the Death Star was on any of their stuff afaik, so formative "Death Star AT&T" ephemera). This one is significant to me as I do find myself quite interested in the Teletype 40/2 (also known as Dataspeed 40/2), although I haven't gone looking too hard to determine its true age. Either way, the service manual has copyrights as early as 1973[12] but according to one of the BTL Library papers[13] initial development of this driver was complete as of December 1975 (source code included!!!). The driver is not present as of Program Generic Issue 2[14] nor is it in research, PWB, or CB-UNIX. I haven't gone looking for what, if any, Teletype 40- specific bits might have been in other streams...but still luckily much of the history of this period of Teletype 40 support is now known. That's all for now, but I knew I wouldn't be able to sleep tonight if I didn't start the marble rolling on discussing the significance of Program Generic Issue 3 to the history of a number of UNIX's features that would become ubiquitous with later releases. Maybe it's just me, but this manual already paints a picture of an experience in 1977 not all that different from what the PWB and CB folks were getting up to in the early 80s. Needless to say, I hope to have this scanned soon and tossed up on the archive as well. More to come! - Matt G. P.S. Fun fact, while doing this analysis, I was using a Motorola Bellboy pager and Western Electric ruler I purchased recently to hold pages open. Something about that feels auspicious[15]. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1090_Proposal_for_UNIX_Interprocess_Communication.pdf [2] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Calls%20-%20man2/msg.2.pdf [3] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/msg.2.pdf [4] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1234_Interprocess_Communication_Mechanisms_in_CB_UNIX.pdf [5] - https://gitlab.com/segaloco/pwb4u_man/-/blob/master/man2/msgop.2 [6] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5.pdf [7] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5l.pdf [8] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/inittab.5.pdf [9] - https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/man/u_man/man4/inittab.4 [10] - https://archive.org/details/unix-system-release-description-system-v/C%20-%20UNIX%20System%20V%20Init%20and%20Getty [11] - https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png [12] - https://bitsavers.org/communications/teletype/40/325-077_Teletypewriter_Compatable_Model_40_Service_Jan82.pdf [13] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1077_UNIX_DH_11_Driver_to_Support_Both_TTY_and_Dataspeed_40_Terminals.pdf [14] - https://bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf [15] - https://ibb.co/35hC5Tk9 From tuhs at tuhs.org Tue Apr 7 20:51:50 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 7 Apr 2026 06:51:50 -0400 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Mon, Apr 6, 2026 at 7:12 PM segaloco via TUHS wrote: > On Monday, April 6th, 2026 at 15:50, Dan Cross via TUHS wrote: > > I can kind of see it. For a small SBC where devices are physically > > soldered onto the board, there's not a lot of expansion to be done: > > the device tree itself is pretty much static. If you just plop it > > into an flash device or something, you can skip the full PROM > > monitor/Forth interpreter/option ROM thing. > > > > Well and the prevailing SBC ecosystems aren't nearly as standardized as PC has historically been. These devices don't have some least common denominator "I'm an 8086 with bus characteristics " so the kernel needs a little more help. DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. Plus, sometimes this means if you already have kernel support for device *xyz* in your current image and add one such device at some I/O address, you just have to rebuild your dtb rather than the kernel hiding all of that info deep inside. Much lower risk to roll back a dtb than a whole kernel too. Trust me, the PC world ain't that standard, either. :-D UEFI has devolved as a way to paper over the differences between systems at the mainboard level, and it serves a similar function as OpenBoot: it gives the board vendors a place to do platform enablement: initializing IO bridges and kicking off PCIe links training, allocating physical address space for MMIO, etc; it also bundles up a bunch of information about the system so that software, specifically kernels and boot loaders, is reasonably decoupled from the underlying hardware; and it solves the boot problem: vendors can plug their device-specific code into a UEFI stack and ship it in flash or on a ROM and it can start devices "enough" to load a boot loader or OS. It also subsumes the traditional BIOS function of being a least-common denominator for driving IO devices: it can implement USB, for example, and provide simulation of PS/2 keyboards and mice for OS's that don't know how to drive USB HID devices (the system trapping through SMIs and SMM to reach into the UEFI layer, so the system is none the wiser), for example. But on balance, ACPI tables are like device trees in a lot of ways; some would argue they're less expressive and overall the whole UEFI stack is a lot less elegant than OpenBoot was. I would agree with them. > Annoyingly it makes provision of quality documentation on memory maps and bus architecture a little worse, seems like you just have to "trust the dts" in many cases these days... Sadly, with very few exceptions, we generally "trust" that the ACPI tables firmware leaves in memory adequately describe the system, too. Nothing new under the Sun.... (Sorry for the terrible pun.) - Dan C. From tuhs at tuhs.org Tue Apr 7 22:04:33 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Tue, 7 Apr 2026 13:04:33 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: <71cbd2f9-7a3e-4505-ba0f-54317e2df84f@geeklan.co.uk> On 07/04/2026 07:00, Greg 'groggy' Lehey wrote: > Sorry, it got removed automatically, presumably too soon for you. > It's there again now, and I'll leave it there for a while longer. Managed to fetch it now. Thanks. >> Weird disk that isn't a straightforward single track ISO9660? I >> used to run into that all the time with preserving optical media for >> game consoles. Our goto in that scene was bin/cue for funky optical >> media. > Possibly. As I said, I had issues mounting it, but I could still read > the files. That suggests that it's not age-related deterioration, but > some incompatibility. If you have any ideas about how to investigate, > I'd be interested. There are a couple of tools recommended in the following post for archiving CDs, though I'm not sure if they cope with unreadability, like in this situation. https://www.mistys-internet.website/blog/blog/2024/09/13/the-working-archivists-guide-to-enthusiast-cd-rom-archiving-tools/ Sevan From tuhs at tuhs.org Wed Apr 8 03:48:34 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Tue, 7 Apr 2026 10:48:34 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: cdparanoia, last time I used it, was pretty good at recovering data from busted CDs. I suspect that doing that across multiple copies might indeed get you, in aggregate, a good image. On Mon, Apr 6, 2026 at 11:20 PM segaloco via TUHS wrote: > > I guess the question then becomes whether the multiple bad dumps have > the proper complement of good blocks between them to assemble a proper > image. This may also suggest performing something like a bin/cue backup > that captures more sector information, that way you can also use that > metadata to better reconstruct a complete image. This has been done for > a few video games where just enough good blocks could be pulled from > known-but-decayed specimens that the correct image could ultimately be > produced. > > From tuhs at tuhs.org Wed Apr 8 12:05:52 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 8 Apr 2026 12:05:52 +1000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM Message-ID: Something is definitely going wrong with Greg's posts to TUHS. I need to investigate. Here is his latest post, forwarded: ----- Forwarded message from Greg 'groggy' Lehey ----- Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis companion CD-ROM On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society wrote: > > I guess the question then becomes whether the multiple bad dumps have > the proper complement of good blocks between them to assemble a proper > image. In general, maybe. In this particular case I suspect that there's a format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is it possible that at the time Sun was using something other than ISO 9660? Sevan's dump was identical to mine, which doesn't smell of medium corruption. All the errors could be format-related. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php ----- End forwarded message ----- From tuhs at tuhs.org Wed Apr 8 12:46:52 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Tue, 7 Apr 2026 19:46:52 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Early Sun CDs used 512 byte blocksize, but the industry settled on 2K. (IIRC) So maybe that has something to do with it? On Tue, Apr 7, 2026 at 7:25 PM Warren Toomey via TUHS wrote: > Something is definitely going wrong with Greg's posts to TUHS. > I need to investigate. Here is his latest post, forwarded: > > ----- Forwarded message from Greg 'groggy' Lehey ----- > Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis companion > CD-ROM > > On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society > wrote: > > > > I guess the question then becomes whether the multiple bad dumps have > > the proper complement of good blocks between them to assemble a proper > > image. > > In general, maybe. In this particular case I suspect that there's a > format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is > it possible that at the time Sun was using something other than ISO > 9660? Sevan's dump was identical to mine, which doesn't smell of > medium corruption. All the errors could be format-related. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > ----- End forwarded message ----- > From tuhs at tuhs.org Wed Apr 8 20:11:16 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 8 Apr 2026 03:11:16 -0700 Subject: [TUHS] AUUGN book review list Message-ID: Here is a list of books aggregated from the TUHS AUUGN archive book reviews courtesy of Claude.. Brave New World. Probably missing some as it was just looking for ISBNs. https://claude.ai/public/artifacts/35294957-feec-45f5-9db8-89f7a07d1a7c Regards, Kevin From tuhs at tuhs.org Wed Apr 8 20:16:42 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 8 Apr 2026 03:16:42 -0700 Subject: [TUHS] AUUGN book review list In-Reply-To: References: Message-ID: On Wed, Apr 8, 2026 at 3:11 AM Kevin Bowling wrote: > > Here is a list of books aggregated from the TUHS AUUGN archive book > reviews courtesy of Claude.. Brave New World. Probably missing some > as it was just looking for ISBNs. > > https://claude.ai/public/artifacts/35294957-feec-45f5-9db8-89f7a07d1a7c More complete that punched through some trivial OCR transcription errors and includes some without ISBN https://claude.ai/public/artifacts/ecfc1c6c-f592-4fd3-9b2f-536a3fe559e7 > Regards, > Kevin From tuhs at tuhs.org Wed Apr 8 20:31:26 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 08 Apr 2026 10:31:26 +0000 Subject: [TUHS] AUUGN book review list In-Reply-To: References: Message-ID: Thank you, Kevin I was going to reply to your first post that, "...I didn't realize Aldous Huxley had contributed to the AUUGN...". But, soma aside, that's an impressive list! 249 books with ISBNs and 36 books without. Nice. Best wishes, Cameron -------- Original Message -------- On Wednesday, 04/08/26 at 11:17 Kevin Bowling via TUHS wrote, in part: More complete that punched through some trivial OCR transcription errors and includes some without ISBN https://claude.ai/public/artifacts/ecfc1c6c-f592-4fd3-9b2f-536a3fe559e7 > Regards, > Kevin From tuhs at tuhs.org Wed Apr 8 21:40:52 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Wed, 08 Apr 2026 13:40:52 +0200 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: <20260408114052.kmITURDX@steffen%sdaoden.eu> Adam Thornton via TUHS wrote in : |On Mon, Apr 6, 2026 at 11:20 PM segaloco via TUHS wrote: |> I guess the question then becomes whether the multiple bad dumps have |> the proper complement of good blocks between them to assemble a proper |> image. This may also suggest performing something like a bin/cue backup |> that captures more sector information, that way you can also use that |> metadata to better reconstruct a complete image. This has been done for |> a few video games where just enough good blocks could be pulled from |> known-but-decayed specimens that the correct image could ultimately be |> produced. |cdparanoia, last time I used it, was pretty good at recovering data from |busted CDs. I suspect that doing that across multiple copies might indeed |get you, in aggregate, a good image. You may also want to have a look at xorriso[1]. Can check media for damages and copy readable blocks to disk. The maintainer had a tremendous run a couple of years ago, one that included sending kernel patches to certain BSDs (at least), ie, to improve the ISO 9660 (handling) support, and more. (Could be ten years even, though .. you know.) (Thankfully so he did, so i could sit down in the early Corona months, and write a "modern" digital audio CD accessor program for BSD* and Linux, s-cdda.c, one that only uses SCSI Multimedia Commands, for extracting CD-TEXT and such. Does not test CRC itself, at least yet, but only certain logical data conditions.) [1] https://www.gnu.org/software/xorriso/ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Apr 8 22:11:01 2026 From: tuhs at tuhs.org (Kenneth Goodwin via TUHS) Date: Wed, 8 Apr 2026 08:11:01 -0400 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Memory fades, but wasn't it an initial 512 boot program that then loaded that 2k super boot block? Mostly because the system board boot roms at the time only could load a 512 byte bootstrap program. On Tue, Apr 7, 2026, 10:47 PM Tom Lyon via TUHS wrote: > Early Sun CDs used 512 byte blocksize, but the industry settled on 2K. > (IIRC) > So maybe that has something to do with it? > > On Tue, Apr 7, 2026 at 7:25 PM Warren Toomey via TUHS > wrote: > > > Something is definitely going wrong with Greg's posts to TUHS. > > I need to investigate. Here is his latest post, forwarded: > > > > ----- Forwarded message from Greg 'groggy' Lehey ----- > > Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis > companion > > CD-ROM > > > > On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society > > wrote: > > > > > > I guess the question then becomes whether the multiple bad dumps have > > > the proper complement of good blocks between them to assemble a proper > > > image. > > > > In general, maybe. In this particular case I suspect that there's a > > format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is > > it possible that at the time Sun was using something other than ISO > > 9660? Sevan's dump was identical to mine, which doesn't smell of > > medium corruption. All the errors could be format-related. > > > > Greg > > -- > > Sent from my desktop computer. > > Finger grog at lemis.com for PGP public key. > > See complete headers for address and phone numbers. > > This message is digitally signed. If your Microsoft mail program > > reports problems, please read http://lemis.com/broken-MUA.php > > ----- End forwarded message ----- > > > From tuhs at tuhs.org Sat Apr 11 10:06:05 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Apr 2026 00:06:05 +0000 Subject: [TUHS] Pirzada's Thesis Missing? Message-ID: Does anyone have handy a copy of Pirzada's thesis "A Statistical Examination of the Evolution of the Unix System"? I'm having a bit of trouble finding a live link to a PDF at present. Given the detailed history too, should/can a copy be placed in the archive? I imagine if it's been publicly accessible elsewhere its probably fine to mirror. - Matt G. From tuhs at tuhs.org Sat Apr 11 10:29:40 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 11 Apr 2026 10:29:40 +1000 Subject: [TUHS] Pirzada's Thesis Missing? In-Reply-To: References: Message-ID: On Sat, Apr 11, 2026 at 12:06:05AM +0000, segaloco via TUHS wrote: > Does anyone have handy a copy of Pirzada's thesis "A Statistical Examination of the Evolution of the Unix System"? I'm having a bit of trouble finding a live link to a PDF at present. Given the detailed history too, should/can a copy be placed in the archive? I imagine if it's been publicly accessible elsewhere its probably fine to mirror. > > - Matt G. https://spiral.imperial.ac.uk/entities/publication/700a4f59-117e-4a67-a5be-e1a4c0ef396d From tuhs at tuhs.org Sun Apr 12 09:41:22 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Apr 2026 23:41:22 +0000 Subject: [TUHS] Program Generic Issue 3 Findings In-Reply-To: References: Message-ID: And here you have it: https://www.tuhs.org/Archive/Documentation/Manuals/Program_Generic_Issue_3/UNIX_Programmers_Manual_Program_Generic_Issue_3.pdf After the link is the UNIX Programmer's Manual for Program Generic PG-1C300 Issue 3, the last release of USG Generic UNIX prior to the establishment of the UNIX/TS and UNIX/RT projects and eventual absorption into the PWB/commercial line. USG first adopted the Program Generic nomenclature with a maintenance revision of USG UNIX Release 2. At the time, this system was still quite comparable to research[1], but with Issue 2[2] and then Issue 3 here, things start to diverge. Based on the issue numbers, I believe now having Issue 2 and Issue 3 manuals completes the preservation of available Program Generic manuals, as the issue numbering for the manuals (as opposed to the versions) begins with Issue 1 in January, 1976, and Issue 2 in March, 1977, trailing the underlying generic issue by one. I get the feeling print literature prior to Issue 2 was limited to copies of the research literature if any distribution was done en masse, but can't confirm this. Either way, I suspect it is unlikely any "produced" paper manuals of USG Release 1, Release 2, or Program Generic Issue 1 will surface. If anything is out there, it is likely (n)roff printouts from a user's terminal. Minute changes in the Program Generic line after Issue 3 may be represented in the MERT Release 0 manual, which is based on it[3]. An older MERT manual was present in the USG library items[4] which could then prove useful for determining MERT vs USG contributions to Release 0 and later versions. In any case, plenty of holes now filled in the USG situation in the mid 70s leading up to UNIX/TS and UNIX/RT (and PWB expansion). As far as manuals, cross-referencing Pirzada's thesis as well as references available in the USG library and other UNIX manuals, at the very least I suspect these manuals may have been formally published (in other words, are likely to survive somewhere in a "standard" form) by USG: CB-UNIX Edition 1.0 UNIX/TS Edition 1.1 UNIX/RT Release 1 CB-UNIX Edition 2.1 PWB/UNIX Release 2.0 Of these, there's really only a lead on the latter right now. I can't confirm the others ever existed as a distributed (as opposed to one-off) printed BTL package, but they're the most likely candidates to have had print distribution by USG otherwise. Anywho, enjoy! I plan on doing an in-depth analysis of Program Generic literature sometime this year, resulting in both a navigable git repository with commits/tags representing research->PG II->PG III manual revisions as well as updates to the wiki describing the various differences. This will all eventually be worked back into my mandiff project as well, which I'm probably going to start over since so much new literature is available since last I touched that. - Matt G. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1017_Setting_Up_UNIX_Issue_Three.pdf [2] - https://www.bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf [3] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ [4] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1070_MERT_Programmers_Manual_First_Edition.pdf From tuhs at tuhs.org Mon Apr 13 19:12:46 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Mon, 13 Apr 2026 11:12:46 +0200 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface Message-ID: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Hi, As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for fun, not serious like simh. Currently it can run BSD 2.11 multiuser on an ESP32-S3 (altough booting takes almost 50 minutes on that platform). It also runs on Linux etc. So I setup a BSD kernel with slip and dz11 support to allow telnet over IP with slip. Unfortunately that hangs. I can ping, I can nmap the virtual PDP but telnet to the PDP just does SYN/SYNACK/ACK and then nothing. Any ideas why telnet would hang? Pinging the pdp: root at snsv:~# ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=77.5 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=185 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=90.2 ms ^C --- 192.168.1.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 77.503/117.547/184.895/47.905 ms nmap: Nmap scan report for 192.168.1.2 Host is up (0.069s latency). Not shown: 990 closed tcp ports (reset) PORT STATE SERVICE 1/tcp open tcpmux 7/tcp open echo 9/tcp open discard 21/tcp open ftp 23/tcp open telnet 79/tcp open finger 113/tcp open ident 513/tcp open login 514/tcp open shell 515/tcp open printer Device type: general purpose Running (JUST GUESSING): BSD 2.X (85%) OS CPE: cpe:/o:bsd:bsd:2.11 Aggressive OS guesses: 2.11BSD (85%) No exact OS matches for host (test conditions non-ideal). OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 27.90 seconds telnet network trace: 10:39:41.390230 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [S], seq 730571314, win 65535, options [mss 256,sackOK,TS val 1346414773 ecr 0,nop,wscale 10], length 0 10:39:41.458696 IP 192.168.1.2.23 > 192.168.1.1.55606: Flags [S.], seq 43457, ack 730571315, win 4096, options [mss 966], length 0 10:39:41.458753 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [.], ack 1, win 65535, length 0 10:39:41.459364 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] 10:39:42.035173 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] 10:39:43.123157 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] ... regards -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com From tuhs at tuhs.org Mon Apr 13 23:25:26 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Mon, 13 Apr 2026 09:25:26 -0400 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface In-Reply-To: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> References: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Message-ID: On Mon, Apr 13, 2026 at 5:13 AM Folkert van Heusden via TUHS wrote: > As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for > fun, not serious like simh. "(just a hobby, won't be big and professional like gnu}" --Linus Torvalds, 1991 From tuhs at tuhs.org Tue Apr 14 05:25:27 2026 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Mon, 13 Apr 2026 12:25:27 -0700 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface In-Reply-To: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> References: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Message-ID: IIRC, telnet might be started by inetd, configured in /etc/inetd.con. It handles connections (and the built-in, like echo) and then passes the connection off to the actual telnetd. I suggest taking a look there, and making sure you have the actual server... Rik On Mon, Apr 13, 2026 at 2:13 AM Folkert van Heusden via TUHS wrote: > Hi, > > As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for > fun, not serious like simh. > > Currently it can run BSD 2.11 multiuser on an ESP32-S3 (altough booting > takes almost 50 minutes on that platform). > > It also runs on Linux etc. So I setup a BSD kernel with slip and dz11 > support to allow telnet over IP with slip. Unfortunately that hangs. I > can ping, I can nmap the virtual PDP but telnet to the PDP just does > SYN/SYNACK/ACK and then nothing. Any ideas why telnet would hang? > > Pinging the pdp: > > root at snsv:~# ping 192.168.1.2 > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=77.5 ms > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=185 ms > 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=90.2 ms > ^C > --- 192.168.1.2 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2004ms > rtt min/avg/max/mdev = 77.503/117.547/184.895/47.905 ms > > nmap: > > Nmap scan report for 192.168.1.2 > Host is up (0.069s latency). > Not shown: 990 closed tcp ports (reset) > PORT STATE SERVICE > 1/tcp open tcpmux > 7/tcp open echo > 9/tcp open discard > 21/tcp open ftp > 23/tcp open telnet > 79/tcp open finger > 113/tcp open ident > 513/tcp open login > 514/tcp open shell > 515/tcp open printer > Device type: general purpose > Running (JUST GUESSING): BSD 2.X (85%) > OS CPE: cpe:/o:bsd:bsd:2.11 > Aggressive OS guesses: 2.11BSD (85%) > No exact OS matches for host (test conditions non-ideal). > > OS detection performed. Please report any incorrect results at > https://nmap.org/submit/ . > Nmap done: 1 IP address (1 host up) scanned in 27.90 seconds > > telnet network trace: > > 10:39:41.390230 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [S], seq > 730571314, win 65535, options [mss 256,sackOK,TS val 1346414773 ecr > 0,nop,wscale 10], length 0 > 10:39:41.458696 IP 192.168.1.2.23 > 192.168.1.1.55606: Flags [S.], seq > 43457, ack 730571315, win 4096, options [mss 966], length 0 > 10:39:41.458753 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [.], ack 1, > win 65535, length 0 > 10:39:41.459364 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > 10:39:42.035173 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > 10:39:43.123157 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > ... > > regards > > -- > www.vanheusden.com [1] > > Links: > ------ > [1] http://www.vanheusden.com > From tuhs at tuhs.org Tue Apr 14 06:28:09 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 13 Apr 2026 20:28:09 +0000 Subject: [TUHS] AT&T SVR4 MP RAS? Message-ID: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> Passing this one up, but wanted to share there is some late oddball SVR4 box on eBay, might be significant: https://www.ebay.com/itm/377109437421 After the link is a box set for AT&T UNIX SVR4 MP-RAS. Looks to be SVR4 with some fault tolerance stuff from NCR? I haven't done my research but in case someone else is looking to get into the UNIX archival business, I'm not jumping at this one. - Matt G. From tuhs at tuhs.org Tue Apr 14 14:26:26 2026 From: tuhs at tuhs.org (Chris Hanson via TUHS) Date: Mon, 13 Apr 2026 21:26:26 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: <6F578299-2A93-49C6-8C39-9F714705C2A3@eschatologist.net> On Apr 6, 2026, at 4:12 PM, segaloco via TUHS wrote: > > DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. This is the main reason I think someone is working on improving device tree adoption in NetBSD; availability of community and vendor device trees could reduce the number of more specialized kernel builds needed, and reduce the requirement to do a full port to support new hardware. -- Chris From tuhs at tuhs.org Tue Apr 14 17:44:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 14 Apr 2026 07:44:41 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: <202604070649.6376nfH0099434@freefriends.org> References: <202604070649.6376nfH0099434@freefriends.org> Message-ID: <88ChQJL-Z7OpvvBOUFJb1oYQGLcYj83YThpjyxEqMms7EIF3kh8mvBpVs1HbwhQJC2-A8nesGNyw5ZBE-VG2caqNeC3vm1e7q2gFEpGuG5Q=@protonmail.com> Alright, here's the last bit of Release 4.0 stuff from the recent document haul: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Selected_Manual_Pages_Release_4.0.pdf This time around is the letter included with a Release 4.0 tape shipment as well as the selected manual pages indicated as document set 10 in the letter. While no hard-copy manuals were published, BTL did offer these specific pages with the shipment. This list also includes the recently scanned PRD as document 1. Documents 4-9 are accounted for in the Documents For UNIX set scanned a few years back. Between all of these documents, I believe the only remaining published Release 4.0 documents to preserve are: UNIX Release 4.0 - Highlights of Changes to Commands - F. M. Carlson & R. R. Rush Setting up UNIX - R. C. Haight, M. J. Petrella, and L. A. Wehr Administrative Advice for UNIX - R. C. Haight The former is referenced in the PRD whereas the latter are referenced in a few spots, most notably in "Recommended Reading" in the Documents For UNIX TOC. The reason given for their not being included: > Because this document changes with each release of UNIX, it is not > included here; it is distributed with each copy of the UNIX system > itself. Hopefully if any of these papers for Release 4.0 *do* show up, they are accompanying tapes...in any case, I now plan on getting back to the SVR2 BTL stuff then probably the Release 4.1 manual, although with all this new stuff there is much to do in on-line reconstructions as well... - Matt G. P.S. I'll be updating the documentation section of the wiki quite a bit with all this recent stuff pretty soon. From tuhs at tuhs.org Tue Apr 14 19:54:42 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Tue, 14 Apr 2026 02:54:42 -0700 Subject: [TUHS] AT&T SVR4 MP RAS? In-Reply-To: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> References: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> Message-ID: On Mon, Apr 13, 2026 at 1:28 PM segaloco via TUHS wrote: > > Passing this one up, but wanted to share there is some late oddball SVR4 box on eBay, might be significant: > > https://www.ebay.com/itm/377109437421 > > After the link is a box set for AT&T UNIX SVR4 MP-RAS. Looks to be SVR4 with some fault tolerance stuff from NCR? I haven't done my research but in case someone else is looking to get into the UNIX archival business, I'm not jumping at this one. Interesting, I grabbed it because I have a non-zero chance of running into a NCR 43xx at some point. I'm somewhat surprised by the AT&T branding and not NCR.. with the 1996 date. This era of ATT-IS/NCR had some very interesting x86 systems: https://www.ardent-tool.com/NCR/Docs/ncr3000overview.pdf http://ps-2.kev009.com/ncr3xxx/thecorememory/html/ncr_system_3000.html What little I gleaned back in the day, before some of this was memory holed, is that they sold some of these 128-256 CPU x86 systems and they were basically synonymous with Teradata and used by large retailers like Walmart to do datamining. Would have been impressive to see one in the early 90s. The smaller ones were normal PC servers, but they did have SMP and pushed it a few years before most other vendors who waited for Intel with the glueless P54C SMP and APIC. > - Matt G.