Charles Hedrick <HEDRICK@RUTGERS.ARPA> (11/10/84)
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". -------