[Info-vax] DECtape (was: TK50 - this is annoying...)

[Johnny Billquist]

On 2012-10-09 23:07, glen herrmannsfeldt wrote:
> 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.

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

A "good" controller would handle all this without the CPU ever knowing. 
A "bad" controller just gives you the raw data, and you figure it out 
yourself.

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

> That assumes that the motor supports read/write speed both directions,
> instead of just rewind in reverse.

They do. It's part of the DECtape design. LINCtape is actually DECtape, 
but run 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.

Good controller. :-)

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

Right.

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

Not really that different. There was basically three formats on DECtape, 
based on what kind of machines. You can group them into:
18-bit (along with 36-bit), 12-bit and 16-bit.

But controllers can normally handle tapes written in another format as 
well. The differences comes out to the size of the blocks.
If I remember right, 18-bit systems record 128 18-bit words to a block. 
Since each line on the tape have 3 bits, this turns out to 768 "lines" 
of data for one block on the tape.
For 12-bit systems, you record 128 12-bit words. However, since the 
number of lines must be divisible by 6, for a PDP-8 you actually have 
129 words reserved for one block, with the last word not being used. And 
this ends up being 516 lines for one block.
For 16-bit systems, I think it used 128 word per block, with a little 
waste at the end of each block as well, ending up with 684 lines per block.
But I can read any formatted DECtape on my PDP-8. It's just that I need 
to do a lot of bit-fiddling to understand a PDP-10 DECtape. (Obviously)

	Johnny