Hi! When I said the device had to work at high speed, I was referring to the crosspoint switch which is used to distribute and collect the bus signals, and by means of which one can assign an arbitrary destination for any of the source signals, viewing them as channels rather than as individual bits. The reason for this is to facilitate wiggling bus hanshake signal lines at something approaching real-life speeds. If you've got 96 such channels and want to update them all at a 2 MHz rate without skew between the various changes, you've got to multiply that number of bits by the rate, which quickly yields 192 MHz, which is the rate at which the circuit translates the bits. The good (and saving) thing that I'd quickly point out, is that it's seldom necessary to change all the signals. There's a way to shorten the delay between bus updates by skipping the updates of unchanged registers. That will help, hopefully with this bandwidth demand. It's easy to reduce the signals changed in a transaction on the bus by a couple of dozen by paying attention only to the signals relevant to a given transaction. This means that the board should have no difficulty whatever generating the typical data transfer handshake ant a normal speed, and wouldn't strain too much to perform block fills and block transfers, and, more interestingly, reasonably thorough memory verification, since that actually involves only a couple of dozen or so signals. I was/am contemplating a programmable state machine with which to perform bus transactions at real-world rates in lieu of a "full-blown" crosspoint switch because that way I could proceed to program macro-operations locally as opposed to doing everything in the PC and suffering the performance loss. What the crosspoint switch does for me is it allows me to group the inputs and outputs in any combination I like, thereby making really fast bus transactions possible since the delay form update at the PC interface to the S-100 is a function of how long it takes me to load the registers I need to load in order to do what I need. If only two or three registers need to be changed, then loading them will be all that has to be done before generating an update of the S-100. In any case, I'm considering an alternative design which will operate at a much higher rate because of parallelism. In a couple of weeks I'll know whether I can exploit that higher rate with PC-resident software. Keep in mind, that this thing has to work from the parallel port, else it's too big a hassle. I don't want to build a kit to go in the PC along with one to go in the S-100. What's more, I don't want to fiddle with USB, since it's WAY too slow, and SCSI is a bit too complex for me to fiddle with for this application. (I don't like having to buy documents on standards like ASPI). What's more, I want this to be useable from a notebook. That's how I intend to drive it. As far as the graphical interface, I've considered how I'm going to sneak up on this. I'm not a WINDOWS programmer, nor do wish to become one. I thought what I'd do is write the code in 'C' using Borland's stuff, then move to their WINDOWS-compatible software set or maybe SYMANTEC's, which is also in house. Ultimately, I was hopeful I could generate the top level GUI stuff, e.g. the front panel buttons, in Visual Basic. I've got a physical front panel built with switches that look a bit like the buttons VB creates quite easily, and, since each one has a little round LED in it, the VB handler can emulate that as well. I expect that this will be a substantial education for me, but I also expect that the fundamental software tools to make this board a useful tool will be no trouble at all. I don't HAVE to run it under Windows in order to use some display graphics, you see. I think that I can cook up a library of routines (macros) which the user can select from a popup menu or drop-down list, or some such. That way he simply generates a block of data, be it a byte, word, or whatever, with nearly no limits, and tells the system what to do by means of macro commands, like fill memory from-to-with . . . maybe even some I/O operations. What's needed is a bit of outside input. Dick -----Original Message----- From: Dwight Elvey <elvey(a)hal.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Wednesday, October 06, 1999 7:14 PM Subject: Re: S-100 Bus up a your