Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site kuling.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!enea!kuling!thomas
From: thomas@kuling.UUCP (Thomas H{meenaho)
Newsgroups: net.micro.68k
Subject: Re: Strange MVME110-1 Bus Errors
Message-ID: <848@kuling.UUCP>
Date: Tue, 5-Nov-85 15:34:48 EST
Article-I.D.: kuling.848
Posted: Tue Nov  5 15:34:48 1985
Date-Received: Fri, 8-Nov-85 20:56:24 EST
References: <633@linus.UUCP>
Reply-To: thomas@kuling.UUCP (Thomas H{meenaho)
Distribution: net
Organization: The Royal Inst. of Techn., Stockholm
Lines: 26


Sorry to use a followup on this article as I haven't used these boards.
However I've encountered a problem with another Motorola board, the MVME 333
serial comm. board.

Has anyone successfully used this board with DMA transfers to-from the VME bus
when there's another board that is the current bus master?

When we looked at the bus activity during the transfers we noticed that
the MVME 333 board doesn't give a heck if there's another bus master in the
middle of a transfer, it just grabs the bus and tries to put out its own
bus signals. You can imagine the result, disaster!

It seems that Mot has done a mistake when they use the OWN signal from the
68450 DMAC as an input to the bus-requester. We pulled out that pin on the
bus-requster and tied it high and it works as nice as the processor cycles
on the bus.

Another problem with the bus-requester seems to be that once the board gets
the VME bus it wont let anyone else in until the board makes a local access, no
matter what priority levels one assigns to the boards.

-- 
Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden
Phone: +46 18 138650
UUCP: thomas@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!thomas)