please see embedded comments 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: Wednesday, October 06, 1999 9:21 PM Subject: Re: S-100 Bus 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! Those go without saying. After all, this is supposed to be a diagnostic tool. 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. 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'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.