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

[glen herrmannsfeldt]

Johnny Billquist <bqt at softjar.se> wrote:
> On 2012-10-09 20:49, glen herrmannsfeldt wrote:
>> Paul Sture <nospam at sture.ch> wrote:

 (snip)

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

>> I haven't heard about that but, just like floppy disks, I suppose
>> you could do block interleaving. As well as I understand it, DECtape
>> is direct access in the same way floppy disks are, with block headers
>> identifying the block number.

> Correct.
> But I too have not heard of anyone actually doing this kind of 
> semi-interleaving. Most machines I've seen or used don't have a problem 
> keeping the DECtape running at full speed across several blocks.

It would seem to require lower-level access to the drive than usual,
at least for the read backwards part. Forward, it should just look
for block headers.

> But you could definitely do it. But unless the controller managed all 
> the reverse twiddling required, it hardly pays to read in reverse. 
> You'll get the words in the wrong order, meaning you need to DMA from 
> last address to first. 

But if you write in reverse, then the bits should come out right.
That assumes that the motor supports read/write speed both directions,
instead of just rewind in reverse.

> And since DECtape do data 3 bits at a time, you 
> also get each group of 3 bits in the wrong order compared to forward 
> movement. And finally, since you are reading in reverse, all bits also 
> gets inverted.

IBM 9-track tape drives, farther back than I can remember, could
read backwards. At least for S/360 and successors, when you read
backwards the buffer is filled up from the end to the start,
such that the bits and bytes end up the right way. If the block
is shorter then the buffer, it will be at the end instead of
the beginning, though.

There are external sort algorithms optimized for tapes that can
read backwards. It saves a rewind between writing and reading
the data back in. The usual algorithms sort blocks of data
that fit into memory, then write them to tape. It then doesn't
matter what order they come back in. For merge, you have to 
be a little more careful with the data.

I only ever used DECtape on a PDP-10, and in that case the operators
had to mount the tapes. I do remember that PDP-10 format was
different from other systems, though.

-- glen