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