On 2015-10-13 16:54, Paul Koning wrote:
On Oct 12, 2015, at 9:16 PM, Rich Alderson <ri...@livingcomputermuseum.org>
wrote:
...
The M tracks are longitudinally encoded (6-bit values chosen such that they
read the same as NRZ backwards and forwards for DECtape, 4-bit values for
LINCtape) to predefine blocks (cf. disk sectors) for data.
More precisely: it's Manchester encoding, not NRZ. The result is that mark
track codes are complemented and reversed end for end if you read them in the
opposite order.
The code choices are such that this process (obverse complement) produces another code word with the right
meaning for this spot of the tape in that direction. So "in the data field of the block" reads the
same in both directions. But "block start" in one direction reads as "block end" in the
other, which is just the result you want.
Right. So, start-of-tape read in one direction is end-of-tape read in
the other direction. Very clever.
And yes, the code telling that it is plain data reads the same in both
directions. However, the actual data needs a lot of massaging if you are
reading in reverse. Bits are inverted, and in addition, bits in groups
of 3 are also in reverse order. It helps if you have hardware that
descrambles this for you. Else, you are in for some bit fiddling...
(And anyone ever using the TD8E controller will be painfully aware of
the low level format of a DECtape...)
Johnny
