Previous Thread
Next Thread
Print Thread
Page 3 of 14 1 2 3 4 5 13 14
Re: VME boards [Re: Edstrom] #101693
09/21/15 10:27 PM
09/21/15 10:27 PM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
I have filed a new pull request for a MVME-350 driver, which is a QIC-02 tape controller board. Info how to use is available here:

https://drive.google.com/file/d/0B685nj_1DkduVFpYT3FVZmtKaGc/view?usp=sharing

However, a lot is still to be done and for that an OS with driver is needed and a CPU board driver, for example for a MVME-131 CPU-board. I have neither at the moment so if anyone has info or a spare to lend/donate I'd be happy to help going forward here.

Also any info on VersaDOS and/or Motorola System V Unix is also welcome

Re: VME boards [Re: Edstrom] #101698
09/22/15 02:49 PM
09/22/15 02:49 PM
Joined: Mar 2001
Posts: 16,007
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,007
USA
Trying to get my head around things here: this is a VME peripheral board, rather than a host, right? We need to set up a VME bus/slot structure like we have for ISA and such before too much more goes on.

Re: VME boards [Re: Edstrom] #101699
09/22/15 03:42 PM
09/22/15 03:42 PM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
Yes, I have started to define the VME bus but needed a peripheral to interact with. I now have both this one and the Mizar board where I faked the SIo board, but could need some directions to make it right. Should I open a pull request with the VME interface and you direct me or do you want to do it yourself?

Re: VME boards [Re: Edstrom] #101700
09/22/15 05:50 PM
09/22/15 05:50 PM
Joined: Mar 2001
Posts: 16,007
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,007
USA
I don't know much about VME, but I'm familiar with the bus/slot system (I implemented the Apple II and Mac NuBus buses). So you can either open a pull request with the interface and we can discuss it there, or post it someplace and discuss it here, whichever is more comfortable for you.

Re: VME boards [Re: Edstrom] #101702
09/22/15 09:03 PM
09/22/15 09:03 PM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
Some 25+ years ago I was the FAE/Sales engineer for the local distributor of some brands of VME boards here, so I had some training in the VME bus at Force in Munich for instance but I can't claim I am an expert anymore but to some degree I know the bus quite well. Not the MESS bus/slot system however.

VME is basically a multi CPU/Master capable bus with Interrupt/DMA support and priority levels etc and there can only be one Bus Controller (which can also can be master).

The special case here, I believe, is that a VME CPU board can be a Bus Controller in its first instance but not in the second and beyond. Is it possible for a CPU board to instantiate itself? Otherwise we can just derive a base board to be the controller instance and another to be the slot device, let me know what you think.

Some random characteristics of VME boards from top of my head:
The controller provides the Bus clock, the arbiter and also monitors bus collisions and such. The Bus master is the board that currently got the bus from the Bus controller. The slave is getting tasks assigned and will usually generate an interrupt when it is done or it needs to be polled. A bus interrupt can target zero or more boards, usually one.

I have not coded so much yet of the VME driver so I think I just open a branch on my fork and work there until we got something that you are comfortable with, I'll post it here when I have something.

Re: VME boards [Re: Edstrom] #102415
11/04/15 10:00 AM
11/04/15 10:00 AM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
Regarding the emulation of bus timing as mentioned in the shout box recently, where intelligent carts with fast microcontrollers etc insert data into running systems, I have the opposite need when emulating the 68K DTACK.
In a single CPU system it can mainly be ignored but in a VME system there is an arbiter than can postpone a request over the bus infintelly by not granting the bus request until the bus is clear, so then the asynchrounous nature of the 68K upto 68030 is more important.

Any suggestions how this can be handled in MAME?

Will it just work if the read/write handler hangs on the arbiter until the bus request finishes? What about eating clock cycles?

Re: VME boards [Re: Edstrom] #102418
11/04/15 01:21 PM
11/04/15 01:21 PM
Joined: Mar 2001
Posts: 16,007
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,007
USA
Unfortunately that isn't possible right now; we need a cycle-by-cycle 68k core that can break out of the read/write and let the scheduler run until the read/write is ready. This is also a pain point for certain things in the Mac driver (Apple used a PAL that allows MOVEing 2 or 4 bytes at a time from the 8-bit-wide SCSI chip; it doesn't tick DTACK until all the bytes are ready from the SCSI bus).

Right now you can either make it so the transaction magically happens immediately, or if that's not possible you can wait on those features until the new core is ready.

Re: VME boards [Re: Edstrom] #102419
11/04/15 02:05 PM
11/04/15 02:05 PM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
Ok, I just postpone DMA transfers and other multimaster capabilities until the core is ready for this and do the other accesses magical, as if they were local.

Last edited by Edstrom; 11/04/15 02:05 PM.
Re: VME boards [Re: Edstrom] #102423
11/04/15 03:29 PM
11/04/15 03:29 PM
Joined: Jan 2011
Posts: 175
A
Al Kossow Online content
Senior Member
Al Kossow  Online Content
Senior Member
A
Joined: Jan 2011
Posts: 175
Two revs of the VME spec are on bitsavers under motorola/VME
I should dig around and try to find the extended version of the spec that added 32 bit bus support.

In the very early days, there was a separate bus controller board that handled the arbitration, that was integrated onto the CPU board around the 68020 timeframe.

I know I had the manual for the moto 131, but I haven't seen it in 20+ years. I'm going through storage right now, maybe it will turn up.

Re: VME boards [Re: Edstrom] #102424
11/04/15 05:03 PM
11/04/15 05:03 PM
Joined: Aug 2015
Posts: 358
Edstrom Offline OP
Senior Member
Edstrom  Offline OP
Senior Member
Joined: Aug 2015
Posts: 358
Makes sense, the arbiter was probably a pain to implement with pure TTL prior programmable logics

Page 3 of 14 1 2 3 4 5 13 14

Who's Online Now
1 registered members (Al Kossow), 93 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,575
Posts112,038
Members4,812
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.027s Queries: 14 (0.009s) Memory: 5.7342 MB (Peak: 5.9552 MB) Zlib enabled. Server Time: 2018-09-24 01:30:28 UTC