A real VME30 never existed.

This is a VME10 with the CPU engine Modified to execute 030 instructions and addressing modes

It does not generate the 030 Format A or Format B access error stack frames. When an access error occurs, the 68010 Format 8 stack frame is created and pushed onto the stack. This means that 030 O.S.s will NOT run on this emulator. This also means that the VME10 normal Versados Runs. NO special SYSGEN is required.

WARNING - it is unknown how pre-020 Versados applications will react to misaligned accesses or 030 instructions or addressing modes.

Unix is NOT tested. 

CPM is NOT tested.    I suspect both may run (both = Unix and CPM for the VME10)

The MSP, CAAR, CACR are implemented. The MOVEC is 030 aware. There is NO cache.
The Format 1 Throw-away stack is implemented, but should not be used with VME10 software. It is always enabled. As long as the M bit is never set, this is OK. All O.S.s for the VME10 do not use the MSP

The T0 (trace on Flow change) works. 

The Format 2 Post instruction with Instruction pointer is also implemented, but is optional via MENU.
O.S. Software for the VME10 may not work if Format 2 is enabled. CPU32 and 030 generate Format 2 frames.

the 68030 PMMU is NOT implemented. 

The 68451 BSMMU is implemented, so that VME10 O.S.s will run.


Problems that need to be fixed

The Bit Field instructions always access bytes. 1-5 byte are accessed. The real 030 accesses using accesses of  4, 3, 2 or 1 bytes at a time. 4 + 1 for 5 byte operands.

The MI PC rel addressing modes fetch the MI pointer from Data space. Think it should be Program Space

Since the 68010 stack Format 8 stack does not have enough room, some instructions use non-saved temporary variables. This means that the instruction must re-calculate these un-saved variables after every access fault. This should be OK, but is not how a real 030 works. As long as the OS completely restores the user state after an access fault (Versodos does) this should not be a problem. Note that changes in the user state may cause the instruction to recalculate using different values than original decode, if the state is not restored completely

the EA decode for the 030 CPU setting, will detect and report as ILLEGAL, addressing modes that are reserved. This is the way the CPU32 does it. The 030 does NOT. There's only a couple instances, since the 030 uses almost all the bit encodings. 

The CAS and CAS2 instructions do not run Locked bus cycles. 
A CAS return from access errors will contine rather than restart the instruction. 
The CAS2 will always rerun the instruction.

None of the 030 MMU instructions are implemented or decoded. They generate ILL EXC

The emulator debugger will use ODD addresses to access words, even for 68000, 68010 and CPU32

I have not tested most stuff thouroughly. Some bugs are likely.



