> 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
Received on Thu Oct 07 1999 - 07:55:52 BST