[Info-vax] DECtape

[glen herrmannsfeldt]

Johnny Billquist <bqt at softjar.se> wrote:

(snip, then 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, then I wrote)
>> 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.

> Not really. DECtape blocks have a block header at both ends, so you can 
> figure out out no matter which way you are coming from.
> And even more clever, that marks on the mark track, which indicate when 
> a block starts, ends, tape starts and ends, and so on, are cleverly 
> designed. The tape start and tape end marks are the inverse of each 
> other. So it's actually just one mark at each end of the tape. Reading 
> forward, you'll find the tape start in the beginning, and tape end when 
> you come to the end. Reverse directory, and things looks just as correct 
> again.

And since the reels are also the same, you could mount the tape
the wrong end up...

> Block marks are designed so that they actually read out correct in both 
> directions.
> But then you get to the actual block header data, which have information 
> of which block it actually is, and so on. This data needs to be 
> processed, and you need to know in which direction you read it, and in 
> which direction it was written, so that you can correct it.

For soft sectored floppies, you have to have an address mark at
the beginning of each sector with a bit pattern that can never
occur in data. Most do that by removing one clock bit.

Floppies don't have the symmetry of being able to read from
either end, and drives don't reverse direction.


(snip)
>>> 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.

> Yes. But that seems like a bad idea in itself. So now you need to know 
> which blocks you wrote in which direction...

It seems that from the OP, the first half was written one direction,
the second half the other. Pretty easy to figure out.

(snip on bidirectional motors)

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

> Good controller. :-)

At least for S/360, that is done by the channel. The controller
sends the bytes through, the channel stores them into memory.
At the end of the block, along with the status bits, the channel
stores the count, if I remember, of bytes not read.
(That is, you ask for 100 bytes but the data block only had 70,
so it stores 30.)

(snip on different DECtape formats.)

-- glen