On Mar 20, 2021, at 4:21 PM, Kyle Owen via cctalk
<cctalk at classiccmp.org> wrote:
On Sat, Mar 20, 2021, 16:13 Paul Koning <paulkoning at 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