Analyzer was Re: KIM-1 repair advice wanted
ajp166 at bellatlantic.net
Fri Oct 7 11:55:01 CDT 2005
>Subject: Analyzer was Re: KIM-1 repair advice wanted
> From: "Dwight K. Elvey" <dwight.elvey at amd.com>
> Date: Fri, 07 Oct 2005 09:29:36 -0700 (PDT)
> To: cctalk at classiccmp.org
>>From: "Hans Franke" <Hans.Franke at siemens.com>
>> First thing would be
>>to connect a logic analyzer to see if the CPU is still running
>>a programm in ROM or not.
> What is it with logic analyzers. Why not just an
>oscilloscope. In most cases, one can be farther along
>with an 'oscope in finding what is wrong by the
>time one can get an analyzer connected and setup.
>I've only had one time that I ever needed an analyzer
>and even that time, it didn't work well because
>of the complexity of the problem ( design not failure ).
> I'll admit that I've often thought of making one
>of those address compare circuits to trigger the 'scope
>but by the time I'd get serious, I'd found the problem.
> Am I alone here or does everyone else think that an
>analyzer is the ultimate tool?
;) Yes, the analyser is the ultimate tool, biggest hammer
and all that.
With all that in the case of 'shooting a KIM-1 the first tool
I'd grab is the trusty VOM to check power and then the logic
probe (you know those things that run off 5V and have three
leds for logic levels aka logic dart) and proble around for
the simple presence of pulses. If warrented then the O'scope.
Last (by a lot) is the big gun logic machine as that also takes
the longest time to drag out and set up. The other three live
on the bench.
One of the things to watch on the KIM-1 is a lot of the signals
come to the edge unbuffered. Can you say ESD? I've also lost
as much TTL as MOS to ESD as most TTL lives near accessable
connections (edge connectors, Keypads and the like). Typical
TTL ESD failures are "stuck input syndrome" and threshold
More information about the cctalk