PDP-8/I at the RICM

[Ian S. King]

Once upon a time, I was troubleshooting an intermittent problem on the
PDP-8/e on the LCM exhibit floor.  What I discovered was that one of the
double-shift instructions wasn't working (which wasn't intermittent - it
failed whenever that instruction was part of the mix).  I had to get the
machine back in running condition since it was on the floor, so I swapped
in a spare CPU and set the other boards aside for further analysis - and of
course, that's where they still sit.  :-)  But this illustrates the point
made here: the ICs do change in their timing characteristics over time, and
some of these designs were right on the hairy edge of specs.  Another
illustration of that: a one-shot in the data-break controller (ISTR) that
was being used (by design, per the engineering drawings) right at the lower
edge of its timing range.

On Sun, Jan 11, 2015 at 2:59 AM, Paul Anderson <useddec at gmail.com> wrote:

> Hi Jim,
>
> That's still good info to know.
>
> Thanks, Paul
>
> On Sun, Jan 11, 2015 at 4:52 AM, jwsmobile <jws at jwsss.com> wrote:
>
> >
> > On 1/11/2015 2:09 AM, Johnny Billquist wrote:
> >
> >> On 2015-01-11 10:41, jwsmobile wrote:
> >>
> >>>
> >>> On 1/10/2015 4:53 PM, Michael Thompson wrote:
> >>>
> >>>> We did more debugging on the PDP-8/I today. The individual CLA and CMA
> >>>> instructions work OK, but the combined CLA CMA instruction does not
> >>>> set all
> >>>> of the AC bits to 1s. Tracing with a 'scope found that the AC ENABLE
> >>>> signal
> >>>> was not active during the combined CLA CMA instruction. Replacing the
> >>>> M160
> >>>> in slot E30 fixed the missing AC ENABLE signals and fixed the combined
> >>>> CLA
> >>>> CMA instruction. The Instruction Test 1 and Instruction Test 2
> >>>> diagnostics
> >>>> ran OK, so the processor is probably working fine. The TC01 DECtape
> >>>> diags
> >>>> did not run as expected so we need to read the manual before we try it
> >>>> again next week
> >>>>
> >>>>  Stab in the dark from discussion with Sherman Foy last night. When
> >>> instructions don't play nice together, the timing may be off.
> Apparently
> >>> timing on the E at least worked in many cases because the speed of some
> >>> of the IC's at the time they were new caused the timing to be different
> >>> on old systems.
> >>>
> >>> Another client who was (and is) servicing old systems had him looking
> at
> >>> the problem in systems which were remote and ran for years at a time.
> >>> When turned off they frequently would not come up.
> >>>
> >>> Anyway the client actually found that the problem could also be fixed
> by
> >>> the fact that the bypass caps were all old.  He replaced the bypass
> caps
> >>> on the timing board, and joy.
> >>>
> >>> I don't know if this will translate to any problem on the I you are
> >>> looking for, but he found it by looking at the signals on a logic
> >>> analyzer and noticing they were not the same with different timing
> >>> boards.   In the I the logic is probably on  more boards, but older
> >>> logic might have more problems if you replaced problem IC's with newer
> >>> faster and less delay parts.  Using older parts was not a full solution
> >>> (to try to get similar timing to the older circuits.)
> >>>
> >>> Just tossing it out as a place to look
> >>>
> >>
> >> Re-read the post. They fixed the CPU. Their problem now is a DECtape
> >> controller.
> >>
> >>     Johnny
> >>
> >>
> >>  I see that now.
> >
>



-- 
Ian S. King, MSIS, MSCS
Ph.D. Candidate
The Information School
University of Washington

An optimist sees a glass half full. A pessimist sees it half empty. An
engineer sees it twice as large as it needs to be.