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

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.

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?

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.

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.

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?

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.