16 Aug
2015
16 Aug
'15
7 a.m.
We did a lot more debugging on the TC12 LINCtape controller.
We saw a 500ns glitch in the LMU MOTION signal that corresponded to a short
slowdown in tape speed. We will investigate this next week.
We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-0000) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.
At this point we don't think that we are working with bad tapes, but the
problem might be in either the TU56 tape drive, or the TC12 LINCtape
controller. We see bad behavior in both devices so we will do as Charles
Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
controller, and test a known good TU55 with a questionable TC12 LINCtape
controller.
We ran the A-to-D converter test and were rewarded with a display on the
VR14 that showed correct operation of the knobs and A-to-D converters.
--
Michael Thompson
16 Aug
16 Aug
3:18 p.m.
On 8/16/2015 9:00 AM, Michael Thompson wrote:
We did a lot more debugging on the TC12 LINCtape
controller.
We saw a 500ns glitch in the LMU MOTION signal that corresponded to a short
slowdown in tape speed. We will investigate this next week.
We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-0000) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.
Just a gut hunch, based on the symptoms. Could you have a bit pick or
drop in the block number in the TC12? Given the behavior, one might bet
on a bit pick. Perhaps intermittent.
Second gut hunch is that it would be hard to see how the drive could
cause this UNLESS the TC12 uses one side of the redundant tape channels
in one direction, and the other side in the other direction.
Will be interesting to hear what you really find.
JRJ
17 Aug
17 Aug
11:51 a.m.
From: Jay Jaeger
Sent: Sunday, August 16, 2015 3:18 PM
On 8/16/2015 9:00 AM, Michael Thompson wrote:
> We did a lot more debugging on the TC12 LINCtape
controller.
Second gut hunch is that it would be hard to see how
the drive could
cause this UNLESS the TC12 uses one side of the redundant tape channels
in one direction, and the other side in the other direction.
Not possible. The *drive* wire-ORs the redundant channels, before the
data goes into (or after it comes out of) the controller. *That's* the
redundancy. When reading in the reverse direction, only the mark tracks
on a DECtape read the same way backwards as forwards; LINCtape uses a
different set of markers.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
18 Aug
18 Aug
6:08 a.m.
On 8/17/2015 1:51 PM, Rich Alderson wrote:
From: Jay Jaeger
Sent: Sunday, August 16, 2015 3:18 PM
On 8/16/2015 9:00 AM, Michael Thompson wrote:
Well, not exactly a wired or, per my TU56 manual, but yeah point taken.
At least on the TU56 the head windings are connected in series,
resulting in the *analog* sum. (A wired or didn't quite make sense to
me - it wouldn't really be redundant, so I looked it up).
But it brings me back to my original point - I don't see how this could
be the drive unless the block number in question always involves a
particular channel on the tape.
JRJ
> We did a lot more debugging on the TC12
LINCtape controller.
Second gut hunch is that it would be hard to see
how the drive could
cause this UNLESS the TC12 uses one side of the redundant tape channels
in one direction, and the other side in the other direction.
Not possible. The *drive* wire-ORs the redundant channels, before the
data goes into (or after it comes out of) the controller. *That's* the
redundancy. When reading in the reverse direction, only the mark tracks
on a DECtape read the same way backwards as forwards; LINCtape uses a
different set of markers.
11 Oct
11 Oct
7:42 a.m.
We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I. We
found that the TU56 uses a double-sided paddle card for the control signals
and the TU55 uses a single-sided paddle-card. The TC12 tape controller in
the PDP-12 will work with either tape drive if you have the right cable. We
borrowed a control and data cable from the PDP-8/I. The TU56 in the PDP-12
was wired for +5V, but can use +10V or +5V. The TU55 needs just 50ma of
+10V, so we ran a wire from a +10V backplane pin to the TU55. After these
modifications the TU55 operated correctly in the PDP-12.
The TU55 behaved a little better than the TU56, and sometimes would
actually boot OS/8. We continued chasing the issue and found glitches on
data channel 3. We have swapped every module and cable that relates to data
channel 3, but have not been able to fix the glitches. The glitches are
there with both the TU55 and the TU56, so the problem is in the TC12
controller.
We put the TU56 back in the PDP-12, and the TU55 back in the PDP-8/I. The
TU56 behaves worse than the TU55, but that may be due to the timing
adjustments in the TU56. I have to make the same adjustments in my personal
TU56, so by next I will know how to adjust the TU56 in the PDP-12.
We are running out of things to try for debugging the TC12 controller in
the PDP-12. At this point we are really stumped as to why the TC12 doesn't
work correctly. We are going to try a few remaining ideas like running the
TC12 from a laboratory power supply.
We would welcome any ideas that you have.
On Sun, Aug 16, 2015 at 10:00 AM, Michael Thompson <
michael.99.thompson at gmail.com> wrote:
We did a lot more debugging on the TC12 LINCtape
controller.
We saw a 500ns glitch in the LMU MOTION signal that corresponded to a
short slowdown in tape speed. We will investigate this next week.
We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-0000) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.
At this point we don't think that we are working with bad tapes, but the
problem might be in either the TU56 tape drive, or the TC12 LINCtape
controller. We see bad behavior in both devices so we will do as Charles
Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
controller, and test a known good TU55 with a questionable TC12 LINCtape
controller.
We ran the A-to-D converter test and were rewarded with a display on the
VR14 that showed correct operation of the knobs and A-to-D converters.
--
Michael Thompson
--
Michael Thompson
12:38 p.m.
On 11 October 2015 at 10:42, Michael Thompson
<michael.99.thompson at gmail.com> wrote:
We are running out of things to try for debugging the
TC12 controller in
the PDP-12. At this point we are really stumped as to why the TC12 doesn't
work correctly. We are going to try a few remaining ideas like running the
TC12 from a laboratory power supply.
We would welcome any ideas that you have.
I'm most assuredly not an expert, and have zero clue what I'm talking
about...
But have you checked that the wire wrap on the backplane is all good?
Perhaps Some of the backplane wrap has gotten damaged and that's why
the TC12 isn't working correctly.
Cheers,
Christian
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
4:44 p.m.
On 10/11/2015 9:42 AM, Michael Thompson wrote:
We are running out of things to try for debugging the TC12 controller in
the PDP-12. At this point we are really stumped as to why the TC12 doesn't
work correctly. We are going to try a few remaining ideas like running the
TC12 from a laboratory power supply.
We would welcome any ideas that you have.
Don't forget about the other more remote possibilities: cables,
backplane, bad wrap, supply voltages at the actual card(s) for the
mis-behaving channel, etc.
JRJ
5:07 p.m.
I have no constructive input to share - except the strong memory of
the bloke who maintained my pdp-12s for 25 years before I collected
them saying that the TC12 was an "absolute bugger" and the hardest
part of the machine to troubleshoot! Good luck and don't feel bad
about having a hard time with it!
Mike
On Mon, Oct 12, 2015 at 3:42 AM, Michael Thompson
<michael.99.thompson at gmail.com> wrote:
We swapped the TU56 and TU55 drives between the PDP-12
and the PDP-8/I. We
found that the TU56 uses a double-sided paddle card for the control signals
and the TU55 uses a single-sided paddle-card. The TC12 tape controller in
the PDP-12 will work with either tape drive if you have the right cable. We
borrowed a control and data cable from the PDP-8/I. The TU56 in the PDP-12
was wired for +5V, but can use +10V or +5V. The TU55 needs just 50ma of
+10V, so we ran a wire from a +10V backplane pin to the TU55. After these
modifications the TU55 operated correctly in the PDP-12.
The TU55 behaved a little better than the TU56, and sometimes would
actually boot OS/8. We continued chasing the issue and found glitches on
data channel 3. We have swapped every module and cable that relates to data
channel 3, but have not been able to fix the glitches. The glitches are
there with both the TU55 and the TU56, so the problem is in the TC12
controller.
We put the TU56 back in the PDP-12, and the TU55 back in the PDP-8/I. The
TU56 behaves worse than the TU55, but that may be due to the timing
adjustments in the TU56. I have to make the same adjustments in my personal
TU56, so by next I will know how to adjust the TU56 in the PDP-12.
We are running out of things to try for debugging the TC12 controller in
the PDP-12. At this point we are really stumped as to why the TC12 doesn't
work correctly. We are going to try a few remaining ideas like running the
TC12 from a laboratory power supply.
We would welcome any ideas that you have.
On Sun, Aug 16, 2015 at 10:00 AM, Michael Thompson <
michael.99.thompson at gmail.com> wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
We did a lot more debugging on the TC12 LINCtape
controller.
We saw a 500ns glitch in the LMU MOTION signal that corresponded to a
short slowdown in tape speed. We will investigate this next week.
We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-0000) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.
At this point we don't think that we are working with bad tapes, but the
problem might be in either the TU56 tape drive, or the TC12 LINCtape
controller. We see bad behavior in both devices so we will do as Charles
Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
controller, and test a known good TU55 with a questionable TC12 LINCtape
controller.
We ran the A-to-D converter test and were rewarded with a display on the
VR14 that showed correct operation of the knobs and A-to-D converters.
--
Michael Thompson
--
Michael Thompson 
12 Oct
12 Oct
11:29 a.m.
We swapped the TU56 and TU55 drives between the PDP-12
and the PDP-8/I. We
Does the TU55 work correctly on the 8/I ?
The TU55 behaved a little better than the TU56, and
sometimes would
actually boot OS/8. We continued chasing the issue and found glitches on
data channel 3. We have swapped every module and cable that relates to data
What exactly do you mean by 'glitches'? Are these on a TTL level signal, an
analogue
output of the read amplifer, or what?
Have you looked for glitches on the other data channels?
channel 3, but have not been able to fix the glitches.
The glitches are
there with both the TU55 and the TU56, so the problem is in the TC12
controller.
IIRC this thing has 3 data channels, so is channel 3 on the outside of the head/tape?
Could it be some external interference that happens to be picked up most strongly
by that head winding?
-tony
6:16 p.m.
From: tony duell
Sent: Monday, October 12, 2015 11:29 AM
> We swapped the TU56 and TU55 drives between the
PDP-12 and the PDP-8/I. We
Does the TU55 work correctly on the 8/I ?
> The TU55 behaved a little better than the TU56,
and sometimes would actually
> boot OS/8. We continued chasing the issue and found glitches on data channel
> 3. We have swapped every module and cable that relates to data
What exactly do you mean by 'glitches'? Are
these on a TTL level signal, an
analogue output of the read amplifer, or what?
Have you looked for glitches on the other data
channels?
> channel 3, but have not been able to fix the
glitches. The glitches are
> there with both the TU55 and the TU56, so the problem is in the TC12
> controller.
IIRC this thing has 3 data channels, so is channel 3
on the outside of the
head/tape? Could it be some external interference that happens to be picked
up most strongly by that head winding?
DECtape and LINCtape (same medium, wound opposite directions on the reel) are
10 tracks across. These are pairwise connected serially to produce 5 signals,
called T (timing), M (mark), and 1, 2, and 3. The T tracks are outermost, the
M tracks are next inward from the T tracks, and the tracks making up 1, 2, & 3
are non-adjacent:
T M 1 2 3 1' 2' 3' M' T'
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.
So neither of the tracks which make up channel 3 is on the outside of the tape.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
13 Oct
13 Oct
7:54 a.m.
On Oct 12, 2015, at 9:16 PM, Rich Alderson <RichA
at 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.
The DECtape patent (3,387,293 -- on bitsavers among other places) describes this very
nicely.
paul
8:16 a.m.
Did you ever speak with anyone at System Source (Bob) about their PDP 12?
Maybe they'd be interested in collaborating. http://museum.syssrc.com/
On Tue, Oct 13, 2015 at 10:54 AM, Paul Koning <paulkoning at comcast.net>
wrote:
--
Bill
On Oct 12, 2015, at 9:16 PM, Rich Alderson
<RichA at 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.
The DECtape patent (3,387,293 -- on bitsavers among other places)
describes this very nicely.
paul
8:29 a.m.
On Tue, Oct 13, 2015 at 11:16:54AM -0400, william degnan wrote:
Did you ever speak with anyone at System Source (Bob)
about their PDP 12?
Maybe they'd be interested in collaborating. http://museum.syssrc.com/
I highly recommend everyone pull up the Univac 490 (1963) page and look
in the "gallery" for a comparison of the Raspberry Pi and the 490.
Someone buy Bob a $beverage for me.
mcl
10:02 a.m.
On 2015-10-13 16:54, Paul Koning wrote:
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
On Oct 12, 2015, at 9:16 PM, Rich Alderson
<RichA at 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.
11:28 a.m.
From: Paul Koning
Sent: Tuesday, October 13, 2015 7:55 AM
> On Oct 12, 2015, at 9:16 PM, Rich Alderson
<RichA at 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.
OK, what I had readily to hand was the TC02 DECtape Control maintenance
manual (from the PDP-9 series, DEC-09-I3CD-D), where page 2-3 states:
Data is recorded by the Manchester method in which a prerecorded
timing track synchronizes read/write operations. When writing on
the tape, the write amplifiers supply the maximum current in either
one direction or the other (non-return to zero, NRZ).
So yes, you're correct to observe that NRZ is not as important as Manchester
in a description of *reading* the data. Thank you for the correction.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
3120
days inactive
3178
days old
14 comments
10 participants
participants (10)
-
ard＠p850ug1.demon.co.uk -
billdegnan＠gmail.com -
bqt＠update.uu.se -
captainkirk359＠gmail.com -
cube1＠charter.net -
linimon＠lonesome.com -
michael.99.thompson＠gmail.com -
paulkoning＠comcast.net -
RichA＠LivingComputerMuseum.org -
tmfdmike＠gmail.com