Analyzer was Re: KIM-1 repair advice wanted

Allison ajp166 at
Fri Oct 7 11:55:01 CDT 2005

>Subject: Analyzer was Re: KIM-1 repair advice wanted
>   From: "Dwight K. Elvey" <dwight.elvey at>
>   Date: Fri, 07 Oct 2005 09:29:36 -0700 (PDT)
>     To: cctalk at
>>From: "Hans Franke" <Hans.Franke at>
>> 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 mailing list