[Info-vax] TK50 - this is annoying...

[glen herrmannsfeldt]

Johnny Billquist <bqt at softjar.se> wrote:

 (snip, someone wrote)

>>>> I once met someone who had used DECtapes and he had been very impressed
>>>> by them in their day, but he was at least 20 years my senior.  IIRC he
>>>> described some mechanism where they skipped alternate blocks when
>>>> reading or writing so that the tape speed could be higher, and those
>>>> skipped blocks were used when the tape was travelling in the opposite
>>>> direction.

(snip)
> I think it's time we kill the just created myth of blocks written 
> backwards, and what not. That has, as far as I know, never been done.

(snip)
> Writing blocks backward would be more headaches that it would be worth, 
> not to mentioning, as I did before, that computers can keep the tape 
> spinning without missing blocks, so there is no need from an 
> optimization point of view.

It has one other advantage that hasn't been mentioned, which is
that the logical end is near the logical beginning. 

If, for example, you wanted to build a data logging device which
would keep the last N (one tape full) entries, that could be an
advantage, as there would not be a rewind delay at the end.

> If people actually thought about it... I mean, a PDP-11 could keep a 
> disk fed with data without missing blocks, and disk blocks pass by much 
> faster than tapes...
> (Heck, I could probably keep a disk fed data on a PDP-8 as well, if I 
> thought about it.)

As I mentioned before, the use of Read Backward on IBM drives allowed
for sort programs to avoid the rewind time. As you fill the tapes 
with blocks of sorted data, and then later read them back for merge,
it doesn't matter what order the blocks come back in. 

The interleaved reversed blocks form also satisfies that. Note that
it isn't just the speed that you can write the data, but also the
speed that you can compute what to write or process what you read.

-- glen

-- glen