please see embedded comments below.
Dick
-----Original Message-----
From: Allison J Parent <allisonp_at_world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Wednesday, October 06, 1999 9:21 PM
Subject: Re: S-100 Bus
><If you're an S-100 user, particularly if you have experience in bringing
><up a system from totally dead to totally alive, I'd certainly like to
><see what your impression of your needs from such a device might be.
>
>I've brought up several IMSAIs, Altairs, NS*, Netronics explorer 8085,
>several mongrels and my multi-CPU s100 crate.
>
I've also brought up a number of S-100's and SBC's, not to mentions systems
on the MULTIBUS-I. The only case in which I've used a front panel has been
the one MULTIBUS-user-client I had once whose SW types thought it would
help. I doubt that it did, but it was a fun job!
>
>Front pannel systems were rich enough to accomplish the task once the FP
>was known working or nearly so. Often the problems were dirty switches,
>broken wires, failed oneshots or maybe a bad LED. Other problems were the
>older boards that didn't like Bus pins 20 and 70 (protect/unprotect).
>
>Must haves:
>
> ability to display memory
> ability to write to memory
> Start, stop and single step the CPU
Those go without saying. After all, this is supposed to be a diagnostic
tool.
>Most front pannel systems (alatir, Imsai, Ithaca intersystems, PDA-80 have
>the basic resources. A scope may be needed if there are timing issues
>or one shots that are drifted off.
>
>The non front pannel systems required a FP that could be plugged in. the
>easiest way was a a minimal CPU (Computime SBC880) that can drive the bus
>but is otherwise self contained. That and a terminal is as good as a front
>panel (better).
I agree, except that I belive that your PC-compatible would make an even
better FP substitute, with its nearly 1 GHz processor, 1GB of RAM and
several 3-doz-GB HDD's. Moreover, since it can not only load programs and
monitor their execution, clock-tick-by-clock-tick, and disassemble
unfamiliar code in real time, generally waiting for the resident processor
to catch up, it has potential not yet exploited. You can use it for logic
analysis, signature analysis/failure detection, code verification,
profiling, etc. It's just another tool, but if it can be sold for less than
IMSAI's FP, then it's not only an improved tool, but less costly, too.
Since you can repetitively stimulate the S-100 in a short loop, you can
easily address signal quality issues previous too slippery for most folks.
You can look over the processor's shoulder or you can take him out of the
loop and run things yourself. When you've narrowed the problem you have
down to a small set of signals, you can poke around with your 'scope to see
that all's as it should be.
>The multi-cpu system needed more as the CPUs were not commercial units
>IE: they never worked before so they had to be debugged first and that
>required a bus logic analyser (capture bus state 1024 cycles deep) that
>could trigger on specified conditions. This was needed to look at the
>interaction of the many cpus and DMA devices. Once the system could run
>code predictably (could still crash but reset to rom monitor was reliable)
>The bus analyser was almost by un-needed.
I never used a front panel until I was asked to build one for a
multi-processor system on a VERY extended Multibus-I. That was fun and
profitable, but wholly unnecessary, I felt, since all the processor boards
were completely self-sufficient with the exception of mass storage, and
since the CP/M image was in ROM, it didn't take long to boot, either.
>A simple logic probe was the single common tool besides a front panel or
>its analogue. A multi trace scope was handy for Altairs (too damn many
>one-shots!) and other system where the problem was logic that was damaged
>from lightining (my old NS* system).
>
I've normally addressed lightning damage with a call to the insurance
company, though they usually don't respond promptly. The procedure for
socketed boards is to take the parts out and test them in a tester. Most
prom programmers can do that.
I really don't see how a logic probe can help you until you've narrowed the
problem down to a single board. What's more, it's common enough to have
several boards which work correctly in a system that doesn't. Sometimes
they just don't work and play well with others. CompuPro boards were famous
for this. They often wouldn't work with other boards from CompuPro. They
weren't alone in this, but their idea of interoperability was that MOST of
the boards in a system which they sold would work together. Their excellent
marketing and advertising made them the main force behind adoption of a
standard too weak to work, and too vague to provide guidance. They, more
than any other maker of S-100 stuff ignored whatever parts of the standard
that it suited them to ignore, and they weren't alone. The problems of this
sort are exactly the sort I'd seek to address with a bus probe. What's
more, there are few tools which will automatically allow you to find
inadvertent connections between signals, say, because of a mis-jumpered
board, or such, or to find that what one board maker uses for signal is GND
to another.
>
>Allison
>
>
>
>
Received on Thu Oct 07 1999 - 00:54:20 BST