>I'm contemplating using SCSI interfaces as a networking medium.  Does
>anyone have any thoughts on where I should look for (a) convincing a
>machine that it should speak on other than ID 7 or (b) convincing a
>machine to respond as if it were a drive, ie, to respond to another
>device on the bus attempting to contact it?  If necessary I'm prepared
>to make the link asymmetric, with one of the hosts distinctly in
>control of what happens, though I'd prefer to avoid that.


The answer is a big Maybe.  I think you're probably on SCSI  or early SCSI 2
with fast-wide at most. What you must do is obtain data sheets for each of
your relevant SCSI controller chips.  Most of the Adaptec and NCR nee
Symbios chips allow this, that is, dynamic allocation of the SCSI ID of the
controller, or have for some time (since, say, 1994 or so which is as far
back as I recall any specifics.  The 78xx family does so, as does most of
the NCR stuff.

Obviously you must avoid collisions at all costs.  SCSI ID 7 has ultimate
priority.  There is nothing in the spec which prevents multiple controllers.
Unless you're on SCSI-2, however, you're limited to 8 devices, which SCSI-2
and fast-wide brings up to 16.  So you're going to have to wade through
datasheets a little.

BTW, LVDS is being used by some ISPs for this purpose now, or at least the
LVDS cabling is.  LVDS opens the door to Ultra SCSI (40 MB/sec) and Ultra2
(80 MB/sec).

>Oh, it is also important that both hosts be able to speak to disks on
>the bus.  (Yes, I do intend to make sure they use disjoint subsets of
>the drives present. :-)


Not a problem.  To preserve, on SCSI-2, the hosts ability to get priority on
the bus, make your "ultimate master" be device 7.  It has highest priority.
Then it ripples downward to 0 in priority, and then starts down from 15 to 8
for subsequent priority.  SCSI is just a bus.  Anything defined in the spec
can be put on it, and there are lists of supported commands in the spec.
Intermachine communication, ala networking, is fairly unusual but if you
grok the spec, the chips you are writing drivers for etc, and do it right,
it can be made to work.  After all, it is just a piece of cable whose signal
meanings make it a flexible cable bus, neither more nor less.

>In case this is hardware-dependent, the machines I'm considering doing
>this with are SPARCstations (ELC, 1+, IPX); if necessary I can dedicate
>a Sun-3/60 to it.


Hardware dependence depends strongly on your SCSI controller chips.  Most
SCSI firmware presumes that there will only be one master and many slaves.
But obviously, being just a bus by design, and with the updates, it can
stretch further than just being a disc controller.

The real problem with SCSI is that it is not really designed for networking.
The address space is limited to 8 devices in SCSI, 16 in SCSI-2.  It won't
be a big network :-)

You've got a bit of digging to do on the spec and the particulars of your
controllers but I'd be rather surprised if you couldn't get a couple of
computers talking on it.

And you can share the drives between the controllers if you make your driver
intelligent.  Disc partitioning is not exactly a new concept.

An interesting way of extending this network, if you can add SCSI
controllers, would be to base them on a star topology with, say, your Sun 3
acting as the router.  I suspect what you want to do will be labor intensive
but if time is cheaper than money, well, go for it.

One problem you will DEFINITELY run into is that few SCSI controllers ever
have responded to the SCSI IDENTIFY command.  This makes dynamic
configuration of your network a problem.  Some intelligent hardcoding in the
drivers can get around this, but with some ugliness.  Be careful of cable
lengths you use.  SCSI has limits in this regard.

Good luck.