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. >> >