[TUHS] Choice of Tape Format for BTL UNIX Distro

[Clem Cole via TUHS]

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