The point about the "best piece of equipment" is perhaps the thing I like
best about using a logic analyzer for a difficult problem. It's such a pain
to set up, it forces you to think through the analysis before making any
measurements . . . or assumptions. Another nice feature is that you can
rearrange the displayed waveforms without rearranging the probes. If you
choose to see a signal set differently than you previously did, you don't
necessarily have to redefine your trigger equations or any such fun.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, June 02, 1999 5:29 PM
Subject: Re: Re[6]: More Bringing up a CPM
>> On the subject of LA/scope/logic probe/voltmeter. I personally
>> consider a LA as the shot gun approach. It will often find
>> problems when one has no idea where to look. The only problem
>
>I can't agree with that. OK, so a logic analyser will monitor a lot of
>points at once, so you can test unrelated sections in the hope of finding
>the fault. But when you've got 64 or 128 or whatever traces, you still
>have to think about the fault.
>
>> is that someone with an oscilloscope can often have the
>> machine repaired by the time one gets the leads connected
>
>I've found that a small logic analyser (say about 3-4 channels),
>intellegently used, is very useful. It doesn't take long to connect it
>up. And it will tell you a lot about the circuit you're investigating.
>
>> I rarely use a logic probe because I don't have one. I
>> can use an oscilloscope just as well with the additional
>> features that an oscilloscope can provide when needed.
>> It is like a logic probe with more added.
>
>You _need_ a LogicDart :-)
>
>> Still the best overall trouble shooting tool I have is
>> an analog voltmeter. I can move quicker with one of these
>
>I agree. I use my old analogue meter a lot more than a digital one. It's
>a lot quicker to read an analogue meter for one thing.
>
>> than many can with other tools. As far as I'm concerned,
>> DVM's are only good for setting power supply voltages.
>
>Oh, they are also useful for setting voltage references on analogue
>subsystems. And checking the exact setting of a variable resistor (when
>you want to change it to (say) 3 time the value as an inital point in a
>modification).
>
>> I have one ( an accurate 5 digit unit ) but the analog meter
>> is still the first thing I reach for.
>
>There are 4 instruments that get most of the use on my bench. In order :
>
>An analogue VOM.
>The LogicDart
>A good bench PSU (30V, 10A). Useful for powering up subsystems
independantly
>A cheap handheld 'scope, audio band only. Useful for checking for PSU
>ripple, looking at motor drive waveforms, SMPSU waveforms, etc.
>
>
>> I find that most don't know how to trouble shoot. The
>> sequence is simple but many still don't get it:
>>
>> 1. Observe symptoms
>> 2. Make predictions
>> 3. validate predictions
>> 4. If predictions do not pan out add this
>> to the observed symptoms and go back to step 2 or 1.
>> 5. Repair bad part.
>>
>> I find that most don't understand the importance of steps
>> 2 and 3. They try to go from 1 to 5 and usually it doesn't
>> work. Step 2 does require that you understand what to
>> expect from each kind of failure.
>
>My method is related to that...
>
>1) Look for silly faults (cables fallen out, etc). Check fuses, etc
>2) Unless there's a very good reason, power up and observe the fault
>3) Do some standard checks. Check PSU rails, master clock, etc
>4) Think of possible causes for the observed symptoms
>5) Do tests (either execute commands or make measurements) to check out
>each possible cause.
>6) If no possible cause is the cause of the fault, you've missed one of
>the possible causes.
>7) You now know the bad part.
>
>The best piece of 'test equipment' you can have is a brain. _Always_
>think about the fault before trying to cure it. Often I make some intial
>measurements and then sit and think for maybe an hour before doing
>anything else.
>
>-tony
>
please see embedded comments below:
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, June 02, 1999 5:18 PM
Subject: Re[2]: More Bringing up a CPM
>"Richard Erlacher" <edick(a)idcomm.com> wrote:
>--snip--
>> The logic analyzer won't hide significant information about the logic and
>> timing. If you sample at twice the frequency of the fastest harmonic you
>> want to observe, you won't miss a thing.
>
> It is not just frequency issues. Levels can be a problem as
>well. I've seen circuits with mixed HC, LS, 4000 and other.
>You set the input for one and the other is wrong. Also,
>your 2X has to be twice the frequency of the response
>of the IC circuit and not just twice the clock speed.
>Also, the 2X sampling rule is only true for repetitive
>signals. This is a basic sampling law thing.
>100 Mhz isn't really fast enough to truly see what is
>going on in even an old 8080 processor board. Glitch
>catching helps but can still hide correct operation.
> Where I currently work, we are completely out of the
>ball park were current day LA's are of much use but
>that is another problem. We still have them and can,
>under limited conditions, use them.
>
I can assure you that you won't run into much CMOS circuitry in the old
IMSAI and Altair stuff. You're right, of course, if your instrument can't
be programmed to handle different thresholds then you could be persuaded you
see something you really don't, or perhaps be swindled out of seeing what's
really there. I remember looking at some new CMOS circuitry about 15 years
ago when the high-speed CMOS stuff was still new. It appeared, for all the
world, as though the outputs preceded the inputs of a series of gates by
quite a difference. I had set my 2467 display to the lower threshold of a
cmos schmidt trigger and displayed a couple of other signals with respect to
that, including the clock which triggered a sequence. It appeared that the
'Q' of a flipflop preceded the clock by quite a margin, perhaps 3-4 ns. We
quickly concluded that a sufficiently long chain would easily allow us to
read tomorrow's stock quotations today, thereby making us all rich. - - -
it didn't work that way!
The way I get around the random sampling error in observing a crystal driven
microprocessor circuit is that I use a little PLL to multiply the clock on
the board by some constant, say 4, 10, 16 or some such, and sample at that
rate as opposed to what the LA wants to use. That makes similarly long
pulses look similarly long as opposed to suffering from the temporal
distortion introduced by the asynchronism between the LA sampling clock and
the circuit on the board under observation.
Of course, like a 'scope or signal generator, you have to know how to drive
them, just as you must know how to interpret the results. The LA often
points up where to hook the 'scope. If it cuts my search through 60-70
signals down to half a dozen, it's made itself worthwhile.
I find the LA really handy for MCU-driven cirtuitry, since I can use the LA
to take a picture and then spiff it up and print it in the O&M manual.
What's more, with easily simulated FPLD's, it's really handy to compare the
simulation with what the LA sees. It's often quite heartening to see what
you thought you ought to see after working on one of those babies for a
couple of weeks.
In any case, I've troubleshot dozens of DRAM circuits with either the little
front-end sampling mux or a real LA, and have found them to be invaluable in
finding component failures, incorrenct jumpering, wrong delay lines, etc.
What's more, if I didn't make the mistake, I can prove it. If I did, I can
prove I fixed it. That's worth quite a bit of setup.
As far as frequency is concerned, the only problem I've encountered which
doesn't quickly show up on a LA display is metastability. As fast as things
run these days, and with the widespread use of fully synchronous circuitry,
almost everything goes into a device through a two-bit shift register stage
to mitigate metastability. I find that if I sample at twice or quadruple
the clock which drives the pipeline registers, I can catch everything I
need.
Those old circuits like the IMSAI and ALTAIR CPU circuits relied quite a bit
on circuits' propagation delays to build events. Races were common, and
that's why folks used to tack 20-400 pf caps all over those boards in hopes
of making them work better.
Like I wrote before, setup and interpretation is slow, painstaking, and
laborious. It's often wrong the first time. Unless you have half-a-dozen
similar boards to work on, it's hardly worth the trouble.
--- I8ABoogar(a)aol.com wrote:
> I have Two in great condition
What's the microprocessor? I used to have one of those when I was a kid. My
father might still have it in the attic (I know he has a box of those sorts of
things, but I don't know the exact contents, and he's several states away).
I recently saw a Mattel Baseball game at a Hamfest, but I've never seen the
Football for sale.
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
<I can't agree with that. OK, so a logic analyser will monitor a lot of
<points at once, so you can test unrelated sections in the hope of finding
<the fault. But when you've got 64 or 128 or whatever traces, you still
<have to think about the fault.
I'd also point out that if the LA in not connected into the system
correctly it can by virtue of ground loops and other things like the leads
actually induce problems. Seen that occur to people. same for scopes too!
I'm not saying they are bad but for some stuff you can end up looking for
the forest between the trees. the best example was a multibus design bring
up another engineer was doing and the board didn't do what was predicted
and of course it was surrounded with scopes LAs and even probes... the
problem...
8086 asm
MOV AH,Ah ( was supposed to move the immediate value x0A to
register A high byte!)
Them trees can hurt when the land of you.
Allison
<A Z80 will give useful patterns executing continual 00 (NOP, so the
<address bus cycles through all of memory) or FF (RST 38, so the stack
<builds down to fill all off memory). Both should provide useful patterns
<on DRAM control lines.
Indeed they do. If you want to force a pattern, the inbound bus buffer can
have pins lifted (if socketed). There are pleny of tricks before getting
out the "big guns".
For the cannons for ants set I do have a S100 Bus debugger that was use use
the phrase purpose built. It's a Logic analyser that has 4 leads floating
and 32 (address and datain plus data out) and a riot of controls so that
it's possible to do a bus level logic analysis and it has 16kx40bits of
2167 55ns ram to take a extended picture of things. I built it to deal
with the quad processor system as there were a lot of signals running.
<Like Allison I used to work almost entirely with a logic probe and a VOM
<(and a brain, which is the most important 'instrument' of all :-)). I had
<a good logic analyser, which saved me a lot of time on occasions, but it
<wasn't that convenient to use.
I have a 16 channel LA and two good scopes but often as not if I poke and
think as Dwight sugggested I rarely need to drag them out and set them up.
The most common use for the LA is craking "black box" devices and chips.
<I rarely use a 'scope for computer (digital) repairs. It's essential for
<analogue work, fixing SMPSUs, etc. But I don't find it _that_ useful on
<typical non-repetitive digital signals.
Depends, very handy for looking at some timing problems and general bus
havoc.
<Don't bet on it. I've lost count of the number of misdesigned (often
<subtly - like marginal timing or ground bounce problems) DRAM cards that
<I've had to sort out.
Those cards never worked, as in they often were unreliable or at best a
question. S100 cards generally were either solid or sick to my expereince.
It may have required running them for a day or two to see that they were
not good 24x7 designs.
<Also, a logic probe won't detect _some_ chip failures. You've got a 2
<input NAND gate. The logic probe shows nice pulse trains on all 3
<connections. You think it's OK and move on. What it hasn't told you is
<that one input does nothing, and the gate is a simple inverter on the
<other input. Yes, I've seen exactly that fault.
Same here, bad inputs are tough to shoot, though a chip clip (16pins 16
leds) does help here.
Allison
> 1. Observe symptoms
> 2. Make predictions
> 3. validate predictions
> 4. If predictions do not pan out add this
> to the observed symptoms and go back to step 2 or 1.
> 5. Repair bad part.
>
> I find that most don't understand the importance of steps
> 2 and 3. They try to go from 1 to 5 and usually it doesn't
> work. Step 2 does require that you understand what to
> expect from each kind of failure.
If you read usenet and/or the questions being asked on CLASSICCMP,
you'll find that most folks can't even execute step 1 correctly. If
I had a dime for every time someone complained about some problem they
were having and didn't even bother to quote the command line they were
trying or the exact error message that resulted, I'd be a millionaire.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Hi All
I decided, on good advice, to look at the static RAMs.
I found a couple of flaky boards. In both cases, it
looks like it was socket problems. I like sockets for
repair but in older machines, they are a major problem source.
I brought out my magic grease and coated the IC pins that were
offenders and now the machine seems quite reliable.
I found a couple more errors in my CBIOS but nothing
I can't work around until I get the source typed in and
use the ASM on the disk to generate code.
One bug stops the warm start from working correctly.
It is no biggy, it is related to how the controller deals
with track zero. When the head is unloaded, it doesn't
pass the track zero status. This means that if I'm at track
zero and then request to go to track zero, a quick check
of the controller status says I'm not there and I
step to track -1. Of course, there is no data there
so the thing fails to reload. I think the easy way
to deal with this is to issue a NOOP to the controller
to cause a head load and then read the status.
Another error that doesn't seem to cause trouble is that
the CONST routine is passing a 0F0H as a true flag instead
of a 0FFH. This is because I incorrectly wrote my return
flag routine. I don't like using conditional code to generate
flags. This is mostly the results of doing code for a
lot of real time applications that require deterministic
operation. The problem was I did it incorrectly. The code
I wrote was:
ANI 40H
ADI F0H
SBI F0H
What I should have written was:
ANI 40H
ADI 0FFH
SBB A
I still have one last problem that I don't understand. When
I send the back-space character to CPM I get erratic results.
Some times it sends back two back-space characters and other
times it sends one back-space and one space character. I don't
know if this is caused by a RAM problem or not. It is a funny
thing because every thing else seems work fine so I don't
think it is a problem with something like the RAM. At first
I used the ^R a lot to see the line. In any case,
I'm using my lap top as a terminal and can filter it until
I find time to look into it. Characters in the DUMP program
always come out right.
I'll have to look into the DRAM issue another day.
Dwight
<>A Z80 will give useful patterns executing continual 00 (NOP, so the
<>address bus cycles through all of memory) or FF (RST 38, so the stack
<>builds down to fill all off memory). Both should provide useful patterns
<>on DRAM control lines.
<>
<Of course, the old IMSAI didn't have a Z80, though I imagine the behavior o
<the 8080 is similarly predicable to some extent. However, this puts us in
<the realm of "coulda-woulda-shoulda" which is not where I like to work. A
<prom is easy, quick and earseable. If you don't have a few for diagnostic
<purposes, you get what you deserve.
same as z80 case, plus the front pannel can be very useful. However,
your point make two assumptions, a prom card or a card that assumably
works and takes a prom and the tools to program that specific prom.
When I was doing most of this stuff alot (early 1973-1983) those things
were often in short supply or non existant and a LA was stratosphere
priced.
<I guess I'm stupider than average, but I have never found what I get from
<logic probe to be particularly useful, nor have I gotten reliable/repeatabl
Different style and presentation. With a LP you attack section by section
and you have to visualize the big picture.
<results. The 'scope doesn't lie, however, and once you own one, it's a
<mistake even to pick up the logic probe, since it can tell you so little.
Wrong. I have all three and they have their place. Often the LP
is more than enough. It was enough to shoot the PDP-8f front pannel
with a bad input 7451 (lots of inputs!) and without a print!
<The logic analyzer is quite a complex beast and requires experience and
<patience to set it up and to utilize the information you get from it
<correctly. The reason I'm using mine is because I'm building a bus probe
<for the S-100 to be run from a PC. This will simulate a front panel on th
<screen and (hopefully) trivialize the task of making individual boards in
<the S-100 cardcage "so something" to aid in trouble-shooting. I'm not far
<along yet, but I thing taking a few pictures of the significant waveforms
<while fiddling with different CPU cards will get me back into the swing of
<things.
I found an easier way. Netronics 8085 system. 8085 with prom, ram, IO
local to itself and a s100 extension off that. Bought it in '78 before the
lightining hit fried the altair and it was vey useful as even dead cards
could be driven. Some of the S100 SBC style CPUs (Computime SB880 come to
mind as I have one) is also useful as it has z80, serial, 1kram, eprom
all on the card and great for driving the deadest of s100 busses.
<Some magazine published a multiplexer for the oscilloscope which enabled a
<externally triggered 'scope to display 8 multiplexed channels in either
<alternating or chopped mode. That was about 20 years ago, but little
<gadgets like that cost only a few bucks to build and will save lots of tim
<on things with several interacting signals. This one used 4000-series CMO
<stuff to form a bias voltage be summed with the logic signal in order to
Built one. Too slow to be useful for logic of even 8080 speeds. the
4066s were barely good to 10mhz as the board was laid out.
Allison
please see embedded comments below.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, June 02, 1999 2:52 PM
Subject: Re: Re[4]: More Bringing up a CPM
>> ><Even if you don't intend to use PROMs in your final device, I'd
certainly
>> ><recommend you build a few PROMS which make the processor do rudimentary
>> ><things and perhaps which make the DMAC do the same things. You then
have
>> ><simple tools with which to troubleshoot your memory interfaces.
>> >
>> >that can be helpful. I just use the CPU executing junk FF/00 or
whatever
>> >else the bus lets it see,
>>
>>
>> This might work but is rarely predictable.
>
>IMHO it's good design practice to put pull up/down resistors on a bus
>that might be floating (like most data buses). In which case the
>'floating' bus is predictable.
>
Just because it's good practice doesn't mean that it's happened.
>
>A Z80 will give useful patterns executing continual 00 (NOP, so the
>address bus cycles through all of memory) or FF (RST 38, so the stack
>builds down to fill all off memory). Both should provide useful patterns
>on DRAM control lines.
>
Of course, the old IMSAI didn't have a Z80, though I imagine the behavior of
the 8080 is similarly predicable to some extent. However, this puts us in
the realm of "coulda-woulda-shoulda" which is not where I like to work. A
prom is easy, quick and earseable. If you don't have a few for diagnostic
purposes, you get what you deserve.
>
>>
>> ><After reading about the problems you're having, I think I'll fetch the
1240
>> ><LA out onto the patio as well.
>> >
>> >I troubleshoot 90% of my s100 problems with a good logic probe and
>> >a DVM. The rare case I've dragged out the scope it was handy but
usually
>> >because I missed something stupid. The recent NS* bring up required the
>> >logic probe, its where I spotted a missing Mwrite/ (jumper smeared off
the
>> >cpu board).
>>
I guess I'm stupider than average, but I have never found what I get from a
logic probe to be particularly useful, nor have I gotten reliable/repeatable
results. The 'scope doesn't lie, however, and once you own one, it's a
mistake even to pick up the logic probe, since it can tell you so little.
The logic analyzer is quite a complex beast and requires experience and
patience to set it up and to utilize the information you get from it
correctly. The reason I'm using mine is because I'm building a bus probe
for the S-100 to be run from a PC. This will simulate a front panel on the
screen and (hopefully) trivialize the task of making individual boards in
the S-100 cardcage "so something" to aid in trouble-shooting. I'm not far
along yet, but I thing taking a few pictures of the significant waveforms
while fiddling with different CPU cards will get me back into the swing of
things.
>>
>> The logic analyzer is handy for gathering information about what a given
>
>Like Allison I used to work almost entirely with a logic probe and a VOM
>(and a brain, which is the most important 'instrument' of all :-)). I had
>a good logic analyser, which saved me a lot of time on occasions, but it
>wasn't that convenient to use.
>
>Then I got a small (small enough to sit on top of any part of a machine),
>simple (but expensive!) logic analyser. It has almost totally replaced my
>logic probe. The ability to compare the timing of a couple of signals
>(this thing has 3 channels, which is enough for most work) is _very
>useful_. For a DRAM problem, I'd certainly look at RAS and CAS, and maybe
>'board select' or 'refresh' or 'address mux control'.
Some magazine published a multiplexer for the oscilloscope which enabled an
externally triggered 'scope to display 8 multiplexed channels in either
alternating or chopped mode. That was about 20 years ago, but little
gadgets like that cost only a few bucks to build and will save lots of time
on things with several interacting signals. This one used 4000-series CMOS
stuff to form a bias voltage be summed with the logic signal in order to
present the signal with a sufficient offset to make each successive trace
appear with enough separation to be useful on the small CRT found on most
'SCOPEs. I have trouble with the notion of using that mode for displaying
what's happening, since you can fool yourself with the display of apparently
concurrent events when they are really not at all concurrent.
About 15 years ago, I made up a sampling circuit which drives a 'scope with
eight channels on each probe and triggers the 'scope on a third. I was
never totally happy with the triggering capability, but if I kept the
trigger simple, it would do what I wanted quite respectably. I used a DAC
to generate the voltage offset, hence I could go quite a bit faster than the
CMOS circuit I described above, though it was never necessary. Such a tool
is suitable for a job like this, and would make the LA unnecessary, except
that I do have the LA, and it will transfer the samples I catch to my PC,
allowing me to use the pictures I take for documentation prepared on the PC.
I became convinced of the need for a small and handy tool like the sampler I
mentioned before. This palm-sized device only served me once, because one
of my colleagues insisted I sell it to him. He had already borrowed it for
use elsewhere and had no plan to return it. I think I've come up with a
reasonable triggering circuit, so I may build another version.
My TEK logic analyzer is about the size and weight of a TEK portable
oscilloscope, and, hence is more portable than today's typical LA. I don't
use it unless I need it, but once it's on the work surface, it sees a bit of
use. I still miss the gadget with the wires hanging out the ends, though,
as it was the size of one of the pods on this LA.
>I rarely use a 'scope for computer (digital) repairs. It's essential for
>analogue work, fixing SMPSUs, etc. But I don't find it _that_ useful on
>typical non-repetitive digital signals.
What you describe is really just a 4-channel 'scope. What I would recommend
for anyone who attacks a system problem like this one is to use a small LA
like mine so he/she can capture the signals on the CPU card, the signals on
the bus, and the signals on the DRAM board. The addresses and data aren't
really essential, though it's useful to have one of each so one can see when
they become stabile, and little short of a logic analyzer will support so
many signals.
>> >With rare exception and all if a board doesn't work scoping it may or
may
>> >not help. just follow the logic with a logic probe as likely it's a
chip
>> >or socket failure. The reason is the board worked, was sold working and
>> >if it were good it should still work. The exception is when you have
bus
>
>Don't bet on it. I've lost count of the number of misdesigned (often
>subtly - like marginal timing or ground bounce problems) DRAM cards that
>I've had to sort out.
>
>Also, a logic probe won't detect _some_ chip failures. You've got a 2
>input NAND gate. The logic probe shows nice pulse trains on all 3
>connections. You think it's OK and move on. What it hasn't told you is
>that one input does nothing, and the gate is a simple inverter on the
>other input. Yes, I've seen exactly that fault.
>
That's certainly a valid observation. In this case, however, it is likely
that the cards will require some sort of redesign in order to make them not
only work together but work more or less in a standard way. That requires
lots of careful observation, more easily done with a logic analyzer than
with a 'scope or anything less.
>
>>
>> I've found the 'scope and LA more trouble to use than a meter and a logic
>> probe, but I've also learned that I get more useful information about
DRAM
>> boards by looking at their DRAM control strobes and timing relative to
the
>> memory access strobes and data than I could get with a meter and logic
probe
>> under any circumstances. So many DRAM cards are at least partly timed
with
>> one-shots, a tool which merely tells you sommething's happening but
doesn't
>> tell you what, is not of much use in THIS case.
>
>Agreeded.
>
>
>I've 'advertised' it before, but HP's LogicDart (the small logic analyser
>I mentioned a few screens back) is a very useful tool. It's probably
>overkill for most people here, but if you do a lot of component level
>repairs, or if you do design, it's certainly worth considering. It is as
>easy to use as a logic probe for simple measurements (tap one probe on a
>point and it'll tell you high/low/clocking, the mean DC voltage, and the
>frequency. Press a button and it'll capture the logic waveform at that
>point), but can do a lot more.
>
>-tony
>
please see embedded remarks below.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 9:00 PM
Subject: Re: Re[4]: More Bringing up a CPM
><Even if you don't intend to use PROMs in your final device, I'd certainly
><recommend you build a few PROMS which make the processor do rudimentary
><things and perhaps which make the DMAC do the same things. You then have
><simple tools with which to troubleshoot your memory interfaces.
>
>that can be helpful. I just use the CPU executing junk FF/00 or whatever
>else the bus lets it see,
This might work but is rarely predictable.
><After reading about the problems you're having, I think I'll fetch the 124
><LA out onto the patio as well.
>
>I troubleshoot 90% of my s100 problems with a good logic probe and
>a DVM. The rare case I've dragged out the scope it was handy but usually
>because I missed something stupid. The recent NS* bring up required the
>logic probe, its where I spotted a missing Mwrite/ (jumper smeared off the
>cpu board).
The logic analyzer is handy for gathering information about what a given
board does in a specific environment. I though I'd like to have pictures of
the cycle at the bus to correlate with the same cycle at the DRAMs, since I
have over a dozen DRAM boards to check out. This will give me information
about the various DRAM boards as well as the cycle timing generated by the
various CPU's.
>With rare exception and all if a board doesn't work scoping it may or may
>not help. just follow the logic with a logic probe as likely it's a chip
>or socket failure. The reason is the board worked, was sold working and
>if it were good it should still work. The exception is when you have bus
>incompatability problems and a scope will not help unless your going to
>alter the board to make it work assuming it was not also broken.
>
I've found the 'scope and LA more trouble to use than a meter and a logic
probe, but I've also learned that I get more useful information about DRAM
boards by looking at their DRAM control strobes and timing relative to the
memory access strobes and data than I could get with a meter and logic probe
under any circumstances. So many DRAM cards are at least partly timed with
one-shots, a tool which merely tells you sommething's happening but doesn't
tell you what, is not of much use in THIS case.
>
>Allison
>
