On 2015-11-13 01:16, Rich Alderson wrote:
From: Johnny Billquist
Sent: Thursday, November 12, 2015 3:44 PM
However, that is still dealing with DECtapes.
I'm curious about the
ability to deal with LINCtapes, that don't use the same codes on the mark
track (or whatever it was called, my memory fails me at the moment).
Yes, "mark track".
Thanks. I must be getting old. :-)
The TD8E do
not understand things at all, and everything have to be done
in software, which is why I'm saying that it will actually deal with the
LINCtape format if you want it to.
Right. The TD8E only sees "single line passed" (= 3 bits of data + 1 bit
of mark) and "four lines passed" (= 12 bits of data + 1 mark code) and is
completely agnostic about the values.
Yes, except it is of course kludgier than that, since DECtape mark codes
are always 6 bits. The PDP-8 scheme of putting in 12 bit words means
they do not align up with the mark codes easily. So, even more bit
fiddling and packing...
That's also why there are actually 129 12-bit words to a block, even
though only 128 is used.
(128 12-bit words are not evenly divisible by 18.)
However, more
"intelligent" controllers do all this processing of the
mark track to identify start and end of block/tape, and all other
processing, in the controller. Can you make them read out the contents
and do the processing if you have different control codes?
The state machine implemented in hardware for all the intelligent DECtape
controllers will not recognize the 4-bit LINCtape codes at all, since the
DECtape codes are 6 bits long. You'll just get a MARK Error.
Thanks. That is what I sortof was suspecting.
Interesting that the LINCtape use 4-bit codes. That makes it even more
incompatible with DECtape.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol