tapes as mass storage (sob)

[CusterDD]

What donn at hp-dcd says is quite right about "crap in the gap" and
associated problems with timing and skew if you use conventional methods. 

The solution I published was to pre-record the tape with blocks separated
by hardware tape marks.  Each block had a header id record and a data record,
somewhat like a soft-sectored floppy has nowadays.

The key was the grossness of the tape (eof) mark -- 3 **inches** of blank
tape (erased) followed by a special character.  Regular inter-record gaps
were used only between the header record and the data record within
a block.  Once the block was recorded, the header was never over-written
(at least not intentionally :-) ).

The grossness of the tape mark allowed the drive to make all its dirties
in the 3" gap after a write.  Since the normal irg was only about 1" this left
2" for "crap in the gap", timing/speed errors, etc. Actually, tape stretch
increased the margin for error.  

This scheme worked for both the top-of-the line controller and the
bottom-of-the-line.  Had no trouble with it at all.  Except for speed, it
was a reasonably good system for the time.  It was **much** slower than
DECtape.  Much better than paper tape!  Over the years I got two
inquiries from interested parties via DECUS, so you can see that it wasn't
wildly popular, but then those tape drives cost more than the DF-32s,
**alot** more.  To give you an idea of the situation, the tape controller
we had occupied most of a 6 foot high rack (SSI?  heck, no!  Transistors!
discrete components, and the like.  2 flip-flops per pc card.)  The tape
control was about 4 times the size of the PDP-8 CPU.  The bottom-of-the-line
control used what dec called the 3 cycle DMA of the PDP-8, which means it
used the CPU to keep track of the word count, and addresses.  Not this
baby though!  It used the single cycle DMA, which meant it had to have
its own accumulators for word count and addresses, as well as function
registers, etc.  On the basis of sheer size it would seem that it had
more logic in it than the CPU!

In any event both controls would successfully wade thru the "crap in the gap"
and find the tape mark.  Sometimes the status register would indicate parity
error and sometimes not.  I didn't care, just reset it and go.

Sure was nice to have FORTRAN II and no paper tape to edit, splice and
keep the programmer busy till 4AM!

Incidentally, if anyone is really interested in all the gory details, its
in either the 1968 or 1969 Proceedings of the DECUS Fall Symposium, 1969
I think.  Held in Las Vegas.  DEC had a PDP-12 on demo there that year.
Couldn't get next to it because someone had programmed it to allow two
users to play space wars (against each other).  Boy, was it neat!

Ain't reminiscing fun! :-)  If you are really, REALLY interested in all the
gory details and you can't find the opus cited (which is probably quite likely
since most have probably crumbled to dust by now :-) ), let me know, and for
only an arm and a leg, I'll dig thru the mold in my basement & see if I can 
find my copy.

David Custer
AT&T Information Systems Labs, Denver
druky!ddc
(303) 538-3517