[TUHS] Choice of Tape Format for BTL UNIX Distro

[Clem Cole via TUHS]

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 <clemc at ccc.com> 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 <tuhs at tuhs.org>
> 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 <tuhs at tuhs.org> 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.
>>
>