Subject: DEC-Tape Cacacity?

From: [email-masked] (Ben A. Fairbank)
Date: 16 Jan 1995 21:56:52 GMT

Twenty years ago, give or take a few, I worked as a PDP-8 assembly 
language programmer in addition to some scientific duties.  My OS/8 
manual is long gone, but I was recently wondering how the DEC-Tape 
minireels compare to our current diskettes.  Can anyone tell me the 
capacity of one small reel?  128 K of 12-bit words seems about right, 
but it is a figure pulled from the air.

Ben Fairbank

---

From: [email-masked] (Mike Yankus)
Date: 17 Jan 1995 16:29:46 GMT

In article <[email-masked]>,
>but it is a figure pulled from the air.
On a PDP-11 the TU56 DECtapes held 578 512-byte blocks or 289K bytes.

-- 
Mike Yankus	             
PRC Inc.                     INTERNET: [email-masked]
1410 Wall St.                Phone:    (402) 291-8300 
Bellevue, NE. 68005-3687     FAX:      (402) 291-4362

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 17 Jan 1995 16:29:47 GMT

[email-masked] (Ben A. Fairbank):

> minireels compare to our current diskettes.

Unformatted, a standard DECtape held 849,036 lines of 3 bits each, or
2,547,108 bits.  Formatted in 129 word blocks (as was standard on a
PDP-8, where only 128 of the 129 words were typically used), the
standard formatted tape contained 1464 blocks.

1464 x 128 = 187,392 words per tape, 12 bits each.  Converting to 8 bit
bytes, this is 281,088 bytes.

Someday, I've got to get my DECtape drives working!

                                        Doug Jones
                                        [email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 19 Jan 1995 13:26:02 GMT

>but it is a figure pulled from the air.

A *standard* PDP-8 DECtape *officially* holds 2702 octal blocks of 129 
decimal words each.  Other than the Disk Monitor and related software, 
most PDP-8 software ignores the 129th word.

There is a hardware restriction that since the mark-track design is a 
multiple of 6 info bits over 3 data bits each, the tape block length must 
be a multiple of 18 bits.  However, the only two official formats that 
DEC ever official endorsed are the PDP-8 format (derived from an 
arbitrary formula that is quite conservative) and the PDP-10/20/7/9/15/11 
format which is 384 decimal words each block and a total of 1102 blocks.  
Note that this format gives a whole lot more data, but is only considered 
an archival format on the PDP-8 (except for OS8 (no slash there!), see 
below).

The DECtape formatting program uses MARK384 as a special exception case 
that "violates" the formula to allow the extra data.  MARK129 just plugs 
into the formula producing the standard result, etc.

The extra capacity is there because there are far fewer inter-block 
zones, and additionally all of the tape is used.  Thus, while the tape 
was sold as a *nominal* 260 feet, you really need 10-20 feet more to 
properly support the MARK384 format.  Unfortunately, later DECtape sales 
were for shortened tape (sometimes to less than 260 feet; people measured 
it :-( !), and caused tapes to be relegated to MARK129 format strictly, 
or worse, when the worn end was cut off, it was then too short and was 
trashed :-(.

The older tapes that could format MARK384 with ease were often set aside 
for use as "extra-long" PDP-8 DECtapes formatted using a patched version 
of the format program that made MARK129 perform a format of 3000 blocks.  
P?S/8's version of the formatter has option switches to set this mode 
more easily, etc.

When the same media is used as LINCtape, even more blocks can be had.  
The reasons are as follows:

Other than for use on the PDP-12 version of the Disk Monitor, there is no 
sane reason to have 129 words/block, since LINC hardware only demands 
multiples of 12-bits, etc.  (Note: P?S/8 and OS/8 LINCtape PDP-12 
handlers all check for the possible presence of the nuisance 129th word.  
The potentially destroyed 129th word is stored before the DMA is started, 
and restored afterwards!)  Thus, using 128 words/block gets more blocks.

LINCtape has less overhead in the inter-block zone.  As a consequence, it 
cannot transfer backwards (but can search backwards; most PDP-8 software 
transfers forwards-only anyway.)  But this also contributes to higher 
tape block count.

LINCtape writes at a marginally higher density than DECtape.  As a 
defense against the ever-shortening tape lengths, some users cranked up 
the mark clock on their DECtape controllers (especially TC08) to get 
proper tape lengths anyway.  This could lead to trouble on TD8E-based 
systems.

As an alternative to tweaking the clock, "laying on of hands" (usually a 
thumb) is often used to get a little more tape usage on marginal length 
tapes.  Again, the TD8E consequences could be bad.

The best possible tape length achieved is 4000 octal blocks of 128 
decimal 12-bit words on a LINC-8.  However, there is an anomaly there:

The LINCtape format doesn't use end-zone sensing to turn the tape 
around!  Instead, dummy blocks -1, -2, -3, -4 etc. are written so the 
arithmetic search works the turn-around instead.  Additionally, the inner 
end should have blocks higher than the largest desired for the same 
reason.  However, on the PDP-12, the end-zone will tend to make the tape 
reverse, so this isn't a problem region, etc.

But on the LINC-8, if a block 4000 is searched forward after a transfer 
of block 3777, the search algorithm is blown, i.e., it will tend to make 
the tape turn *further* into the inner end, only to have the end-zone 
sensing reverse the tape direction.  Thus, the tape can get trapped in a 
search loop unless manually overridden.  Good tape handlers can avoid 
this assuming the next block transferred is a lower-numbered block,e tc.

So, the most optimistic PDP-8 capacity for this media is 4000 blocks or 
2048x128x12 bits.  I think that works out to 384 KBytes for those who 
can't count higher than 8.

cjl

---

From: [email-masked] (Charles Lasner)
Date: 19 Jan 1995 13:35:38 GMT

In article <[email-masked]>,

>On a PDP-11 the TU56 DECtapes held 578 512-byte blocks or 289K bytes.

Nope.  There are 578 blocks, but each holds 256 18-bit words.  The PDP-11 
just chooses to waste some of the bits for most storage purposes.  Thus, 
your figure should be inflated by 1/8th.  (Unless you are referring to 
9-bit bytes :-).)

cjl

---

From: [email-masked] (Kenn Goutal)
Date: Wed, 18 Jan 1995 05:51:31 GMT

In article <[email-masked]>,
>Someday, I've got to get my DECtape drives working!

When you do, I've got some files that need converting!

Actually, most of mine are LINCtape, though I also have a couple DECtapes.
I remember being impressed when, after my box of tapes had sat in the back
of my VW through 3 or 4 freezing winters and blazing summers, I plopped
some of them onto a drive, and after a few "warm-up" spins, they read in
just fine!

-- Kenn Goutal
[email-masked]
http://www.mv.com/users/kgg/kenn.html

---

From: [email-masked] (Ben A. Fairbank)
Date: 18 Jan 1995 14:02:41 GMT

In article <[email-masked]> [email-masked] (Kenn Goutal) writes:

snip
>some of them onto a drive, and after a few "warm-up" spins, they read in
 
Which reminds me that in '73 or so our lab had retreaded a 
clerk/administrator into a PDP-8 programmer (and a damn good one).  Her 
husband was our electonics technician and had explained to her that the 
magnetic dots on the tape tended to accumulate at the edges of the tape 
unless they were regularly rotated.  For months we, not knowing what he 
had told her, watched her every Monday picking up the tapes and turning
them over.  Finally someone asked her what she was doing...

---

From: [email-masked] (Bob Hassinger)
Date: 19 Jan 95 00:08:33 -0500

> bytes, this is 281,088 bytes.

Not as well know where schemes to get more than the standard on a tape.  I
recall Jim VanZee telling me about using schemes as extreme as pressing on the
edge of the reel while the tape was being formatted to slow it down.  That let
him get more blocks on the tape.

Bob Hassinger
[email-masked]

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 18 Jan 1995 19:46:15 GMT

>From article <[email-masked]>, by [email-masked] (Kenn Goutal):
> 

DECtape is an archivist's dream.  The sandwich mylar construction of the
tape makes it far less sensitive than normal mag-tape to such environmental
considerations such as humidity, and the massive redundancy of the
recording format (all bits recorded twice) makes it resistant to the
random flaking and dropout problems that plague those who try to read
ancient conventional tapes.

You can take a hole punch to a DECtape (the kind you'd use to punc a
ticket or make a hole in a page you wanted to put in a binder), and there's
a good chance you won't damage any data.  You lose out, though, if you're
unlucky enough to punch a hole opposite a bad spot in the tape that wiped
out the other copy of the bits you punched out.

I know some wonderful DECtape stories, the best being from a friend of mine
who loaded a DECtape on his PDP-10 upside down, then hit the load switch,
at which point, the whole reel of tape was dumped on the floor at high
speed.  He must have lost a bit too much sleep, but anyway, his reaction
was to pull the reels, pop them on right side up, and hit the load switch
again, at which point the tape was snapped back onto the reels at high
speed, complete with many folds, dirt from the floor, and various crumples.

His solution to the folds and crumples was to rock the tape quickly back
and forth over its whole length.  That got out most of the wrinkles, but
it set the others even harder.  Then, he pressed the tape down over the
head with his finger and wound the tape back and forth again to get it all
flat.

When he tried to read the tape, there were plenty of bad bits, but he
figured that they were just places where the wrinkles were holding the
tape away from the head, so he pressed his finger against the head while
he read the tape.  The friction was too much, but by hand cranking the
tape reels with a pencil while he held it against the head with a finger,
he successfully read the tape, without errors.

That was a good thing, it was the only tape he had with that data on it.

					Doug Jones
					[email-masked]

---

From: [email-masked] (John Wilson)
Date: 17 Jan 1995 04:25:28 GMT

In article <[email-masked]>,
Ben A. Fairbank <[email-masked]> wrote:
>Can anyone tell me the 

Right ballpark, it's actually a little more.  The "standard" format was
1474. blocks (somehow that's easier to remember in octal) of 129. words
each.  I think TOG-8 would let you mess around with weird formats but
at your own risk, the hardware requires a block to be a multiple of 36
bits but otherwise you could pretty much do your own thing and it would
work, with your own driver.  Even with stock format the tape would spin
off the end of the reel while formatting the end zone unless you had only
threaded it just enough to barely stay on the reel at the beginning.

John Wilson

---

From: [email-masked] (Frank R. Borger)
Date: Wed, 25 Jan 1995 00:24:29 GMT

In article <[email-masked]> [email-masked] (John Wilson) writes:

>... Even with stock format the tape would spin

	That was a commony symptom of a mal-adjsted formatter.

	The interface used an adjustable oscillator to determine how
	OFTEN you wrote formatting data, with the tape moving at constant
	reel speed. If the frequency of the oscillator was a little low,
	the format marks were too far apart and you ended up running off
	the end of the reel.

	I remember an article that actually made it into DECUScope that
	described how one software specialist re-wrote the formatter to
	only do 6' instead of 10' leader/trailer sections.

Frank R. Borger - Physicist     ___      What's the difference between:
Michael Reese - U of Chicago   |___      (1) having a baby and 
Center for Radiation Therapy   | |_) _   (2) doing an RSX11M sysgen?
net: [email-masked]    | \|_)
ph: 312-791-8075 fa: 791-2517       |_)  Having a baby only takes 9 months!

---

From: [email-masked] (Charles Lasner)
Date: 28 Jan 1995 20:18:28 GMT

In article <[email-masked]>,
>	That was a commony symptom of a mal-adjsted formatter.

Not necessarily.

>	the format marks were too far apart and you ended up running off

True.  But the problem is that DEC mis-specified the tape length so that 
later when 3M sold *correctly-specified* tapes, they were too short for 
the intended purpose(s) many of the time, etc.  As a bandaid, many people 
upped the density either with fingers on the hubs or by increasing the 
mark clock on the various controllers, since the clock speed was quite 
conservative.  Thus, you often could get away with a little marginal 
reliability (other than on the TD8E!) to get more density and thus fit 
what you wanted on less tape, etc.

>	only do 6' instead of 10' leader/trailer sections.

No, that happened earlier.  The standard PDP-8 DECtape formatter has two 
modes of operation:

1)	Anything other than MARK384 uses a stated conservative formula 
found in some early DEC manuals that will calculate out to 2702 blocks 
octal of 129 words with 10 foot leader/trailers and will completely 
succeed if the tapes really are a bit longer than the nominal 260 foot 
claimed (instead of really being about 10-15 feet longer as they usually 
were at the beginning!).  Other selected values will give corresponding 
variations that use the same amount of tape.  As the tapes started being 
made shorter (some even being *less* than thenominal 260 feet!), more and 
more tapes couldn't be formatted correctly.  Note that this effect is 
compounded by too-slow mark clock adjustments, and the tendancy of some 
ignorant lusers who erroneously assumed the program needed "help" so they 
wound the tape on some number of turns before starting the formatting 
operation (which is dead wrong - the program writes its own leader.  An 
additional variant: Lusers would cut off the leader because it was "worn 
out" or something perceived but incorrect.  The truth is that the tape 
format requires nothing of the leader other than to exist; the writing 
occurs further down the tape.  All that could happen is that a tape could 
move to the inner-most portion of the end-zone, and be turned around back 
towards the data.

During the PDP-8 formatting process, you turn on the mark clock, and do a 
first pass over the tape.  The tape could fall off, but is usually not 
fatal, although many lusers didn't realize that, etc.  You turn off the 
mark clock, remount the tape if necessary, then enter the next phase (hit 
a CR to continue).  The tape is first rewound about 20-30 feet, then 
turned around to write forward the pattern "BLOCK 2701" an indefinite 
number of times (resulting in an anomalous tape so far!) until the end 
zone is hit at its inner end.  At this point, the last-written block *IS* 
block 2701.  Previous block patterns can then be written in descending 
order from 2700 down to 0000 at which point another end zone error should 
occur at the tape beginning, hitting the inner end of the front end zone, 
etc.

Thus, as long as the tape can successfully not fall off a second time, 
the tape is valid, albeit possibly with a short inner end zone, etc.

2)	When the specific command MARK384 is given, the formula is 
bypassed and constants plugged in to create the variant PDP-10 format 
tape.  The end zones are written as 6 feet instead of 10 feet to 
accomodate getting 1102 blocks of 600 words (600=384 decimal).  Were the 
standard formula used, far less blocks would be written, etc.

Thus, from the beginning, the notion of 6 ft end zones was standard.  
Since the standard PDP-8 format (from the formula) didn't require as much 
tape, 10 ft end zones were written.

The P?S/8 version of the formatter has an option to run such that MARK129 
is the command that uses the plug-in values.  The number of blocks is 
taken from the =xxxx user-specified and the end-zone is shorteded to 6 
ft.  As a result, "extra-long" DECtapes can be created as long as the 
tapes are truly full-length, etc.  A common semi-standard was to achieve 
3300 blocks instead of 2702.

When some late-production tapes were sold that were too short, the P?S/8 
method was the only way to achieve 2702 blocks!  The MARK384 command 
invariably failed.  The tape falling off only once became the standard as 
never falling off ceased to exist, and falling off twice (and flunking 
the formatter!) become all too common :-(.

Some people then purchased tapes directly from 3M.  If they stated "DIGL 
WIND" then they are DECtapes right out of the box.  Else they are wound 
as LINCtapes and need to be reversed, etc.  Unfortunately, most of these 
tapes were accurately 260 ft long, thus guaranteeing no further too-short 
tape problems, but also preventing any more extra-long tapes either.

cjl