Your comments are interesting and probably correct, but I think you've missed the point. What I wanted to address is the problem of deciding which features to put into a tool and which ones to leave out. The issue of host speed is interesting, except that it really doesn't matter whether it can emulate the S-100 system's processor at 15 times its normal rate or 2500 times its normal rate. The interface is bandwidth limited by design to 2 MHz updates. I've contemplated a FIFO of some sort, but since the S-100 can be operated in bursts or in loops at an arbitrarily high speed anyway, I doubt there's a need for a FIFO. What boards there were or are isn't really relevant, since the target is to produce a useful tool. Pointing out the weaknesses, which, after all this time are either forgotten by or known to all of us, of one tool or another, won't help. What I'm addressing is using TODAY's technology to facilitate testing and verification of the S-100 bus. We're free to assume that the width of various signals can be adjusted in 10 ns increments just to determine what might work the best, even if the CPU can't really generate that waveform, and we're free to try solutions to the S-100's 7 equations in 4 unknowns, not only as a linear programming problem, but with discrete attempts with each possible solution, even though our CPU doesn't play that way, just to find out what really is wrong. This stuff is, in some cases, over 20 years old. Digital circuit design has evolved considerably since the '70's and, as it happens, much of what was sold on the S-100 market really didn't work, not because it was designed back in the '70's, but because it was designed badly. Some of it worked, "sorta," when in combination with specific other components (boards) but others didn't really work reliably, (e.g. survive a 1k-hour test/burn-in) under any circumstances. Unfortunately, sometimes the very circuits we wanted to use were in this category and wouldn't work with OUR hardware, even though it seemed to work fine with THEIRs at the store/trade-show-whatever, where we first saw it. What I would do if now were then is try a board in my existing test system to see if it caught fire or did something equally irksome. If it worked, I'd smile and proceed, and if it didn't, I'd attempt to find out why. If the board is claimed to be IEEE-STD-696 compliant, I'd try driving it with a '696-compatible set of signals to see if it behaved as expected. If yes, then I'd have CPU issues to resolve, not "new-board" ones. The tool I've essentially proposed enables you to do that without having to buy '696-compliant boards, since you can't readily pick up the phone and order them. It will, however, support you in an effort to whittle at each of the boards you want to use in order to make them work and play well with the others you wish to use, regardless how recalcitrant. Features I've already built in include the abilities you mentioned, examine and deposit memory content, easily extended, by the way to ensuring that the memory works consistently, stop the processor, single-step through execution of a program or cycle, jam an instruction onto the bus during an instruction fetch, etc. What's more, it can do this without a CPU in the system, or, assuming the CPU can do this, it can float the CPU and do "correctly" what you think the CPU is doing incorrectly just to ensure the fault is on the board you think it is. Anyway, people who've had the experience of bringing up a dead multi-board system in which the various manufacturers had no convention as to defaults or operating modes, in which it was a given that three or five boards, though all functional could and usually did yield a system which did nothing until the incompatibilities were ironed out, and in which there were no guarantees that ALL the components would work together at all, would have a really good idea of what features a generalized emulation/troubleshooting tool like this one should have. Resurrecting a 20-year old S-100 is VERY different from bringing up an old PDP-8. In the latter case, the bus standards were set by DEC, who knew what they wanted to put out there. In the S-100, boards were often designed by people with incorrect and/or incomplete information about what had to be on the bus in order for it to work correctly. They were virtually always designed with incomplete information about how other mfg's boards behaved on the bus. What's more, that behavior was likely to change, depending on how the CPU or other bus masters behaved. Since it's difficult to get detailed information about how a board you just bought at the flea-market works, you have to figure that out for yourself. This is a tool for doing that. It won't do it automatically but it will help you. Dick -----Original Message----- From: allisonp(a)world.std.com <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Thursday, October 07, 1999 7:03 AM Subject: Re: S-100 Bus been and processor logic than folks. see boards the famous They of excellent standard this GND