S-100 Bus

There's a copy of the IEEE Std 696 in my lap. I've been searching for this document in "the pile" for quite some time and it's held up my work on a bus probe for the S-100. I intend to run the S-100 from my PC and have completed circuitry to enable transfer of data from the PC to the probe at a maximum of about 2 MHz. Now, this is entirely fast enough to run the bus, with the exception that it probably can't run it continuously at that rate, hence I've contemplated inserting a state machine to operate the bus automatically in a series of operations while sampling the activity on the bus at the same resolution as that at which it is being driven, e.g. 8 MHz for a 2 MHz processor clock, and more or less at that same proportion otherwise. Unfortunately, I'm not convinced that it's necessary for me to have a really long sample memory (has adverse effects on price and circuit complexity). What's more, though I've considered including a large crosspoint switch for both writing and reading signals from the S-100, at real time, I'm not sure it will be of sufficient value to the user public. Its purpose is to allow compaction of the data transfers during a simulated bus transaction in real time. What's more, in order to get 2 MHz throughput, even in bursts, it requires I operate the device at around 100 MHz internally, which will be both costly and difficult. Originally I intended this thing strictly as a diagnostic tool. When I noted that IMSAI is bringing back its front panel board and the box to accomodate it, I figured it might be useful to provide a fairly automated method for testing and debugging the thing, including tests for shorts, crosstalk, I figured that the notion of putting a Pentium-class machine in an IMSAI box might not satisfy everyone's debugging an testing needs, particularly if they wanted to run REAL '70's era hardware. My intention is to allow the PC to function as the front-panel, and, to small extent, as a combined pattern generator/logic analyzer, for numerous purposes ranging from backplane troubleshooting to peripheral testing. The plan is to provide functional support for things like block transfers, I/O-to-memory and memory-to-I/O as well as memory-to memory-transfers. Memory testing, at least superficially will be supported as well. I'm contemplating a graphical interface for purposes of stimulating the bus, though, again, I've yet to see whether that's useful enough to warrant the effort. This is YOUR big chance to have input into the design of this device, assuming you have some idea of how YOU'd use it. I've got to break the functional sections up enough that the device can be sold as a "kit" not requiring FCC approval, so much of the cost will be in things like adapter sockets for the FPGA's and CPLD's, which often outcost the IC's by 10x. Since FCC approval will goose up the cost by 100x, I'm trying to avoid that. 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. Dick