DECtape ancestry

[Paul Koning]

> 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