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

[Johnny Billquist]

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 2 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?

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.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol