[Info-vax] DECtape

[Johnny Billquist]

On 2012-10-10 16:28, glen herrmannsfeldt wrote:
> 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...

Possible, but if you monted them inside out, you should be able to tell 
by the fact that the text on the reel is facing inwards.
You could also mount the tape on the wrong hub. You normally had an 
empty reel on the pickup hub, so it shouldn't be hard to get it right, 
but there was nothing preventing you from removing that reel too.
Or spool the tape off to the pickup reel, and remove that reel with the 
tape.

It was fairly easy to mount them right, so that mounting them wrong 
would mostly be if not at all paying attention, or being slightly dense.

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

Well, the OP said (if I remember, and understand right), that running 
the tape at speed, you would miss the start of the next block when 
reading, so you did a kind of interleave, where you grabbed every other 
block, and then did the other ones in reverse.
Now, assume you do this, starting at block 0, with writing. Do you then 
write block 0,2,4,6 and so on, skipping 1,3,5 and so on, and then write 
those in reverse? Do you then also write them in the order 5.3.1, or 
1,3,5? Also, if you then go to block 1, and read just that one, which 
way to you read it?
You could, of course, just say that all odd-numbered blocks are written 
backwards. But that means you need to know which blocks anyway, by some 
algorithm, even if it is as easy as blocknumber%1 to tell the direction.
However, since the numbering of the blocks are strictly from 0 to max, a 
reverse writing, from the back, means you should write blocks 5,3,1. So, 
writing all of blocks 0 to 6 means writing blocks 0,2,4,6,5,3,1. And 
reading blocks 3 to 6 means you would read (starting forward), 4,6,5,3. 
It all actually becomes rather complex and funny, and like I said, I've 
never seen any software actually do this, nor any that needed to. A 
PDP-8 can keep the tape busy at full speed without missing blocks.

	Johnny