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

[Alfred Falk]

Johnny Billquist <bqt at softjar.se> wrote in
news:k5pveg$jnd$1 at Iltempo.Update.UU.SE: 

> On 2012-10-18 20:52, Alfred Falk wrote:
>> Johnny Billquist <bqt at softjar.se> wrote in
>> news:k5p9uo$d52$1 at Iltempo.Update.UU.SE:
>>
>>> On 2012-10-18 16:44, glen herrmannsfeldt wrote:
>>>> George Cornelius <cornelius at eisner.decus.org> 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.
>>>>
>>>>> I had heard that the data was written twice and always assumed (I
>>>>> suppose correctly) that the extra blocks were for redundancy. 
>>>>> That they might have been written in reverse bit order never
>>>>> occurred to me.
>>>>
>>>> The data is written twice, in parallel. Three data bits on 10
>>>> tracks. 
>>>
>>> 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. 
>>>
>>> Yes, data is written twice on the tape, on separate tracks, just
>>> like you write, Glen.
>>> And that is a big reason why data is rather safe on DECtape. You can
>>> even punch holes in the tape, and it will still work.
>>>
>>> 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.
>>
>> If I recall correctly, KM-9 (the sort-of OS DEC offered for the
>> PDP-9) wrote alternate blocks to DECtape, and wrote the skipped
>> blocks backwards.  Thus, if you imagine a ten-block tape it might be
>> written in this order: 0 2 4 6 8 9 7 5 4 3 1.  The odd-numbered
>> blocks would be processed backwards.
> 
> So if you wanted to read block 0,1,2, you would read block 0, then 2, 
> then turn around to read block 1? And the controller would handle the 
> DMA for this??? As well as all the bit fiddling that is required? Are 
> you serious?

Quite serious. But you would typically read block 1 right after block 2.  
I pulled out my PDP-9 manual.  It has a section on the TU55 drive and 
TC02 controller.  (Simpler times when a 250-page manual could describe 
the entire architecture along with most peripherals and provide useful 
programming examples.) Reading backwards would require programmatically 
de-scrambling by 3-bit chunks.  Not hard - the manual gives an example 
taking under 60 lines of assembler - mostly for the in-word de-
scrambling.  I am not certain that KM-9 actually interleaved forward and 
backward operation as I described, but I am certain it interleaved.  I 
remember very well the annoying slowness of it: write a block; stop; 
write a block; stop....  Stopping and starting required a fair bit of 
tape between actions.  Writing contiguous blocks was quite fast, but KM-
9 did a lot shoe-shining.  (It might have been a 5-way interleaving 
which would give enough space to start and stop.)

> Too bad I've never used a PDP-9. I have DECtape on my PDP-8, and can 
> with certainty tell that no controller on a PDP-8 ever did. You can 
> certainly write and read block backwards, but then you'll have to do
> bit and word fiddling afterwards. And OS/8 never do blocks in reverse.
> And the same is true for the PDP-11, as far as I can remember (it's
> been a long time since I ran DECtapes on a PDP-11).
> 
>>> 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.)
>>>
>>>       Johnny
>>
>> Interleaving of disk blocks used to be pretty common.
> 
> True. But not all disks did that, and even with interleaving, the disk
> blocks are passing at a blink of an eye, and DECtape certainly are
> not... 
> 
>>  The bus tranfer
>> rates of some systems couldn't keep up with the disk itslf.  I first
>> recall seeing interleaving discussed in a CDC 6400 (or maybe Cyber
>> 63) manual.  Data General used to do it for some of their drives when
>> connected to microNova systems that had (IIRC) 2-bit buses.
>> (Controlled by a switch or jumper on the drive or controller.)
> 
> Interleaving does nothing to solve a too high bit rate. You might get 
> relief by having local buffer along with interleaving though.

You are right, but a 512-byte buffer was not prohibitively expensive in 
the 70's and 80's.