XL400 multiprocessing?

[Norman Haas <NHAAS@IBM.COM>]

  At my site, we have an XL400, and we thought a nice cheap way to get
a second one would be to simply buy another board set and plug it into the
unused slots in our first one's chassis. However, Symbolics says that
we can't do this; it will lead to clashing between the machines- either
immediately or in the near future when the color systems come out.
Why should this be? The VMEBus architecture is specifically intended to
support multiple processors running simultaneously in the same chassis.
If Symbolics is conforming to the bus spec, then an XL400 board set added
into an existing VMEBus configuration will not interfere with the operation
of the other boards in that configuration (other than consuming some
bus bandwidth), provided that it doesn't step on the other boards'
addresses or interrupts, which is usually possible to achieve with VMEBus
products by means of on-board jumper blocks. And in that case, the
other boards could comprise one or more other Symbolicses. (VMEBus
permits up to 20 slots per chassis; you could make a Symbolics six-pack!)
And inter-board conflict should be particularly low for the Lisp-hacker,
since the XL400 makes no use of the VMEBus unless an application program
specifically requests it to (the board set having its own private bus
on the front edge, and disk I/O is through the Ethernet).

  Is the problem that bus lines on the J2/J3 connectors are being used in
such a way that there can be only one Symbolics present? Is there actually
clashing if one doesn't have color hardware? (We don't need color.)

  Whatever the reason, it's unfortunate, because this would certainly be
a nice way to configure a cost-effective, space-efficient multi-machine
system, and it would have the advantage that if several machines wanted to
collaborate on a task, a really fast, no-Ethernet communication channel
between them would come for free.

Norm