failsafe tapes

[Charles Hedrick]

Things are not quite as bad as you make them out.  The 10 does not use
the parity bit.  What it does do is split one 36-bit word among 5 bytes
on the tape.  If you want to write a program to decode it, it shouldn't
be that hard.  As I recall, FAILSAFE tapes were written with each file
being a separate file on the tape, but with some extra label
information.  So if you just read the thing into a bunch of text files,
with bit of editing, you should be able to pull out the information you
want. If you  are dealing with text (I trust you aren't trying to read
binary data), it is packed 5 per 36-bit word, with the low-order bit
left over.  In the following Bn means bit n, with B0 being the
high-order (leftmost, or sign bit) bit.  P is parity.  | is used to show
where text bytes end.  I means to ignore this bit.

		tracks

9     8     7     6     5     4     3     2     1

b0   b1    b2    b3    b4    b5    b6  | b7     P 
b8   b9    b10   b11   b12   b13 | b14   b15    P
b16  b17   b18   b19   b20 | b21   b22   b23    P
b24  b25   b26   b27 | b28   b29   b30   b31    P
I    I     I     I     b32   b33   b34 | b35    P

Although the low-order bit is real data, it isn't used for text (since 7
* 5 is 35, not 36).  In the simplest approach, you can just ignore it.

That was the simple way.  If you really want to do things right, you
should look at bit 35.  If it is on, it marks the current 36-bit word as
a line number.  In that case, you simply drop those 5 characters, and
the first character in the next word.  However it would be just as easy
to write a filter that drops the first 6 characters in each line, so you
might prefer not to worry.  Note that the format of a line of text is
one of the following:
   unnumbered files:
	normal text, with each line terminated by CRLF.  You will
		want to remove the CR's for use on Unix.
   numbered file:
	line number, always 5 chars starting on a word boundary,
		with bit 35 on (as a flag that this is a line number).
	normal text
	line ends with CRLF, with nulls filling to the next word
		boundary (since the next line number has to be on
		a word boundary)
	You may find large blocks of nulls in these files, since
	a line never crosses a block boundary, where a block is
	128 words.  Nulls are inserted where that would have
	happened.
Note also that underlining is typically done by ending a line in a bare
CR.  This makes the next line overprint the current one. A bare LF (Unix
end of line) has no obvious meaning, though I have seen it used.  FF
(form feed, ^L) is used to mark pages.  Tops-10 conventions say that
nulls should always be ignored in text files.  Many Tops-10 programs
also ignore CR's and treat LF's as end of line.  That won't do if you
are trying to read files that do underlining on lineprinters.  But for
normal files, the simplest conversion to Unix is to just drop nulls and
CR's.

Now, for your next assignment, right a program to read upper/lower
case files encoded as CDC display/"ASCII".
-------