please see embedded comments below.
Dick
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_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
>
Received on Wed Jun 02 1999 - 17:24:00 BST