@RB: ok, maybe I am on th wrong path here. I was referring to the address_space::allocate function that throws up at me here
Code:
throw emu_fatalerror("Invalid width %d specified for address_space::allocate", config.data_width());
when trying to create a 24 bit address space. Maybe this is not needed, see below.

@OG: I just realized that I must have dreamt up some features that I have seen and remembered as VME features but they were really special backplanes that for example aggregated four 8 bit I/O boards to allow D32 reads of data from 4 boards in a single cycle. Reading "Observation 2.16" in the spec I know that it is not possible with the VME alone.

This makes it a bit simpler and if I also combine the A16,A24, A32 and A64 into a single address space with only a mask for each I could use the AS_DATA, or what do you suggest?

The reason I want a separate address space is that each master is accessing the bus through a window in the local address space. For example this Force board (see http://bitsavers.informatik.uni-stuttgar...anual_Feb92.pdf)

Code:
Board             A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Force  D08-16 FCFFOOOO-FCFFFFFF  FCOOOOOO-FCFEFFFF    
CPU-40 D08-32 FBFFOOOO-FBFFFFFF  FBOOOOOO-FBFEFFFF  01000000-F9FF FFFF


Compare it to this Heurikon board (See http://bitsavers.informatik.uni-stuttgar...anual_Jun91.pdf )

Code:
Board                A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Heurikon  D08-16 00C00000-00C0FFFF  01000000-01FFFFFF      
HK68_V3D  D08-32                                       04000000-FFFFFFFF


You can see that the windows for A16 and A24 are complete while the A32 is crippled in order to map local devices. You can also see that the A16 and A24 windows are on different locations in the memory maps. Now if we also add the slave complexity to this it is quite possible that a VME slave board installs in the lower region of the A32 range and would collide with the local devices unless separated.

The master board (any SLOT) requests the bus. The bus arbiter on the controller board in SLOT 0 will grant the bus to the requesting master if there is noone else with higher, or upstream daisy chained with the equal, priority using the bus. The master puts the addresses on the bus together with one of the 8 bit address modifiers (A16, A24, A32, A16-priveleged, A24-user-defined and so forth). Once the adresses are on the bus all boards will compare the adress modifiers and the adresses and respond if they are matching. The slave check what type of transfer is requested on the DS0, DS1 and present the data on the appropriate data lines.

I don't intend to implement the arbiter for now becuase it doesn't makes sense with the non preemptive scheduling model used in MAME currently, so all accesses will be immediatelly granted and fully executed in turn.

EDIT: of course the master board requests the bus *before* it puts the adress there...

Last edited by Edstrom; 11/25/15 01:10 PM.

Because I can