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.