> On Mar 20, 2021, at 4:21 PM, Kyle Owen via cctalk <cctalk@classiccmp.org>
> wrote:
>
> On Sat, Mar 20, 2021, 16:13 Paul Koning <paulkon...@comcast.net> wrote
>
>> Speculating here since I have no direct knowledge: the DECtape format
>> allows read and write in either direction, while LINCtape only allows read
>> and write forward. The bidirectional I/O capability was part of DECtape
>> format from the start, and I suspect the desire was to keep that.
>
>
> What systems took advantage of the bidirectional nature?
>
> Kyle
DOS-11 for one (and thus RSTS, which reuses that format). DOS DECtape files
are linked lists; each block contains a link to the next block. To allow for
reading one block at a time, start/stop mode, DOS interleaves 4:1. If you're
allocating a long file and the allocation reaches end of tape, allocation then
continues in the reverse direction. The extreme case of a single file that
takes up the whole drive looks like two up/down passes over the tape, each one
touching 1/4th of the blocks in each direction. When a file is read, blocks
are read in the same direction as they were written. The direction is given by
the sign of the block number in the link word, negative means reverse.
As Grant pointed out in the oral history interview, bidirectional DECtape I/O
in the sense that you could read a block in the opposite direction it was
written isn't all that useful. While the PDP-11 controller does the obverse
complement thing, that just means you get the bits in the word correct but the
256 words are still in the opposite order. That could be handled, of course,
but I haven't seen programs that do so.
Well, one exception: the tape formatter does the write timing/mark forward,
then write all in reverse, then reads (to check) forward. But those are test
patterns so the job of dealing with the direction change is easy.
paul
