bqt at update.uu.se
Fri Nov 13 03:49:01 CST 2015
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 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
More information about the cctalk