Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!rutgers!mcdchg!mcdclv!stevea From: stevea@mcdclv.UUCP (Steve Alexander) Newsgroups: comp.realtime Subject: Re: VME 680X0 Boards Message-ID: <613@mcdclv.UUCP> Date: 30 Nov 89 22:48:50 GMT References: <4667@ncsuvx.ncsu.edu> Reply-To: stevea@mcdclv.UUCP (Steve Alexander) Organization: Motorola MCD, Cleveland Lines: 50 In article luis@octopus.tds.kth.se (Luis Barriga) writes: > >>>From: aras@ecerl2.ncsu.edu () >>>I am trying to set up a VME based system for a real-time robot control >>>application. I had previously posted a request for VME info. Now I have >>>found several large companies out there and would like to hear about any >>>experiences you net folk may have with them. The companies are below: > >For some time ago I used a board (I think it was from Motorola) called >VME134/68020. I found some bugs in it: the dissassembler failed on some >complex instructions although the board could still execute them. >There was something worse: an instruction like "MOVE.L A6,16(SP)" was >not executed. It was a board error since the a SUN could execute it. >I've heard the they do not produce it anymore (hopefully). >-- It is pretty obvious that you are confused. Motorola (my employer) makes a CPU card called the MVME134, DY-4 makes a DVME134 cpu card, Ferranti makes a DVME134 and I seem to recall one vendor making a VME1xx cpu board series, but I can't recall right now who it was. I have been using the Motorola MVME134 for a couple of years now running System V Unix and Psos. I can assure you that the 68020 on the MVME134 has no trouble executing any valid 68020 instruction. It is possible that the `problem` you refer to is in the on board firmware called the MVME134-Bug. In addition to providing primitive disk and serial line I/O facilities, there are memory dump/modify commands which include a single line assembler and disassembler. These were not intended to be used as a developers assembler & disassembler tool, but merely as a quick & dirty way to decode & modify the contents of memory. This limited ROM-based assembler does not accept SP as a mnemonic for the stack pointer. This is clearly documented on page 4-5 & 4-6 of the MVME134BUG/D1 User's manual (did you RTFM ?). I have just tried the instruction: MOVE.L A6,16(A7) on my MVME134 and it executes as expected. Unfortunately the illegal syntax: MOVE.L A6,16(SP) does not generate a syntax error and interprets the destination as location hex 16. I guess you can only fit so much software on 32KB of ROM. I should mention that the Sun assembly sytax differs in a number of ways from the Motorola assembly syntax for the MC680x0 and anyone attempting a port should consult the appropriate manuals. The MVME134 is still happily in production on Motorola's JIT Fab line in Tempe Arizona. -- Steve Alexander | Evolution is a very messy business. Motorola Cleveland | Brought to you by Super Global Mega Corp .com