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

[Johnny Billquist]

On 2012-10-24 20:55, Alfred Falk wrote:
> 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 thought that was what I said...?

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

Why are you so sure it interleaved? The write-stop-write action is the 
typical way of a DECtape. Interleaving or no. Unless your controller is 
prepared to continue process data right when the previous block is 
finished, the tape has to stop. This is not a disk, which spins 
continuously without anything more untowards happening. Tapes have to 
stop, or else you'll run out of tape. If you specify multi-block DMA 
operations, the controller can keep the tape running. If you have a 
really stupid controller, you can decide on your own when the tape 
should stop, or you have something in between, which will stop after 
each block.

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

Oooh. I don't know about that. A 16-word PDP-10 cache was an option on 
the KA10, because it was expensive enough to put in the basic machine.
(The fast accumulator option.)

	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