PDP-12 Restoration at the RICM

Mike Ross tmfdmike at gmail.com
Sun Oct 11 19:07:23 CDT 2015


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:
>
>> 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



-- 

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.'


More information about the cctech mailing list