Path: utzoo!attcan!uunet!decwrl!wuarchive!cs.utexas.edu!helios!calvin.tamu.edu
From: cnh5730@calvin.tamu.edu (Chuck Herrick)
Newsgroups: comp.sys.next
Subject: Re: Using the old 68030 board
Message-ID: <8986@helios.TAMU.EDU>
Date: 11 Oct 90 14:03:19 GMT
References: <MDIXON.90Oct2190616@thelonius.parc.xerox.com> <287@heaven.woodside.ca.us> <52796@brunix.UUCP>
Sender: usenet@helios.TAMU.EDU
Organization: geodynamics research institute, texas a+m univ
Lines: 28

In article <52796@brunix.UUCP> rca@cs.brown.edu (Ronald C.F. Antony) writes:
)In article <287@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:
))In short, I think that power and ventilation aren't the problem.
))The problem is more likely to be that NeXT wants the boards as
))trade-ins.
)
)The problem is not having two boards in one system, but running two
)monochrome megapixel displays from two boards. Thus the system has to
)supply two times the high currency for the display. 

Actually, the source with the greatest potential for problems in a 
multiple-processor-boarded cube would be likely to arise from the
following:

	Which board is in control of the bus and when?

Several backplane/bus configurations have been designed from the
start to handle more than one processor board (VME, Futurebus 1 and 2,
and STD come to mind). A set of bus-master/bus-slave protocols are
designed into these buses from the very beginning, and these
protocols, when followed, prevent interboard interference. 

Hope this helps.



-- 
	Chuck Herrick				cnh5730@calvin.tamu.edu