S-100 Bus

From: Richard Erlacher <edick_at_idcomm.com>
Date: Wed Oct 6 21:54:41 1999

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_at_hal.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Wednesday, October 06, 1999 7:14 PM
Subject: Re: S-100 Bus


>"Richard Erlacher" <edick_at_idcomm.com> wrote:
>>
>> 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
>
>
>Hi Dick
> I've only brought one IMSAI up from the dead. I only needed
>a dual trace oscilloscope but I realize that isn't always
>the best option. Way back when, I worked for Intel and
>was responsible for test of the UPP product. This had a 4040
>on it. I built a cable and interface that allowed
>one to replace the 4040 with a Series II development system.
>It was not a full logic analyzer, it just did normal read/write
>to ROM, RAM and I/O. This combined with an oscilloscope made
>a good trouble shooting tool. There isn't really a need to
>do 100 MHz operations to make a useful tool. One can make
>variable delays to adjust read and write timing to look
>for timing issues. The code that ran on the Series II
>was done in Forth. This way, one could quickly write a particular
>test routine for the particular problem one was trouble shooting,
>like one would do on a Sun with open boot. This would be quite
>hard to do in a GUI without some kind of command line
>macro ability ( the problem with GUI's is that, although a
>picture is worth a thousand words, they are often not the
>thousand words that you currently need ). Trouble shooting
>requires flexibility in test conditions that are much more
>varied than what would be used to simply go-nogo test.
>Dwight
>
Received on Wed Oct 06 1999 - 21:54:41 BST