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)