7 Oct
1999
7 Oct
'99
12:55 a.m.
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!
All the multibus bring ups were done using CPUs like intel 80/20 or
national BLC204, even if the bus was a mess you could run with these
as ram/rom/io on board were alive.
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
Not to say it can't. The SBC880 was a z80/serial/parallel/rom/ram on one
card and more of less had those function isolated from the bus. This
allowed severly crunched bus to be driven while having the luxuray of a
real cpu and terminal interface. I used my own debug monitor in Eprom.
The key is I still have it, and I used it from the early 80s on.
For board level debug the explorer 8085 <netronics> was good as s100 was
the 'add on bus" so if the card was not running you could
drive/interrogate it.
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.
A s100 card with z80, io and enough ram and rom to run is a trivial board
and was cheap even in the early 80s. Using todays parts 64k of eprom,
64k (or more) of banked ram and other things would be not only simpler but
cheaper too!
The PC approach depends on the processor having lots of speed. What if
all you have for this kind of task is a 486dx/33 or maybe an old P133?
Not evey one is invested in PCs to the ears. FYI: my hottest PC is for on
line use and not for adding cards like that and it's only a P166 with
about 2.1gb. The only systems I have with an abundance of loose storage
are VAXen.
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.
I started with PDP-8s, 10s then a CM2100 and firs micro was ALTAIR. FP
were ok for some thing where seeing state was nice. I used it more to mod
software that had IO that didn't match mine. It was the easiest way to
see what addresses it was looping at.
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.
There were two proms in the entire system, 488 2102s, and lots of '367s,
241s, and '244s. Not to mention the fried terminal and printer. In 1979 a
logic tester for would have cost several times the system. Now, I'd toss
the MB <PC> and start fresh.
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.
S100 was nice in one respect you could strip the bus and plug in pboard
until it broke.
Allison