- Modifications to the MOVEC instruction

0x700 - always returns 0
0x701 - returns Emulator Major 0-9999
0x702 - returns Emulator Minor 0-9999
0x703 - returns Emulator Revision 0-9999
0x704 - returns CPU TYPE MC68000=0, MC68010=10, CPU32=32
0x705 - returns CPU STACK TYPES Supported (as bit mask in low order word)
	Format 0 is Bit0=1  used by 010 and CPU32 (4 word frame with FVO)
	Format 2 is Bit2=1  used by CPU32 hybrid (6 word frame with FVO and IA)
	Format 8 is Bit8=1  used by MC68010 and CPU32 hybrid (29 word frame for AE and BE)
All bits = 0 is MC68000
	All exceptions except AE and BE use 3 word frame
	AE and BE use 7 word frame
0x706 - always returns 0
0x707 - returns boot disk 

MOVEC $704,D0
$4E7A 0704 

none of these special control registers are writable and generate an ILLEGAL Intstruction Exception

- Special Emulator only instruction to access physical memory by-passing the MMU

the opcode is defined as follows

  f e d c b a 9 8 7 6 5 4 3 2 1 0
  1 1 1 1 1 1 1 D s s a a a d d d

this appears as a Co-processor instruction CPID=7 

 D is direction - 0 = (An)->Dn   1= Dn->(An)
 aaa is An
 ddd is Dn
 ss is size - 00=byte 01=word 10=long 11=invalid

this instruction reads or writes a physical address, bypassing the MMU

if size is invalid it is a regular F-line exception

if a berr or aerr occurs, then it does nothing(NOP) 
(note - no berr or aerr exception occurs)

If menu item has the MovePhys disabled, then it is an F-line Exception

Explaination - this was needed because unix r1v2.8 does not have the phyaddr option for shmget, and /dev/mem seems to dislike berr's 

this instruction dissassembes as MOVPHY (An),Dn or MOVPHY Dn,(An)


- Option MC68000/MC68010/CPU32hybrid

Since the VME10 uses a MC68010, there's realy no reason to have an option for MC68000 or an option for CPU32.

However, the CPM distribution comes with CPM15000 and CPM400 S-rec files that are generated for a MC68000. So, to facilitate using these files as initial files to test and debug, the MC68000 option was added...

The MC68000 option does NOT create a true MC68000 rendering. it only ensures that MC68000 code will run. 

The following changes are made to the MC68010 engine to make it run MC68000 code.

 The MOVE from SR instruction is made NON-PRIVILEDGED

 The RTE instruction is changed to only return using a MC68000 stack frame (3 words, SR and PC)

 The Address Error and Bus Error exception microcode, only saves a 7 word stack frame 
	( Internal SSW, Fault Address, Instruction register, SR and PC)

 All other Exception microcode is modified to generate a 3 word exception stack frame (SR and PC)

Nothing else is changed... all other MC68010 features exist. This means that the dissassembler will still dissassemble instructions like MOVE from CCR , MOVEC, MOVES , and any other MC68010 instructions.. they will also execute... the VBR still exists and is used... 

NOTE - the MC68000 CPM15000 and CPM400 s-rec files actually work on the MC68010; but, there are problems...
	
	The CPM dispatcher only creates a 3 word frame, but works due to the serendipidous fact that the subroutine that called the dispather pushed a 32 bit address with the upper byte (31-24) as zeroes (00).. this satisfied the need for a format zero stack frame.. and since the dipatcher is never returned to and the stack is never used to pull the return address (the stack now pointing to the wrong word), it worked...

(the return from an application is done by either a TRAP #2 with D0=0 or by a RTS... the RTS works because prior to dispathing the application, the system pushes the address immediately following the dispather onto the USER stack.. the return to this address (in USER MODE) simply excutes a TRAP #2 with D0=0..note that the corrupted stack from the dispatch is never used..the TRAP #2 with d0=0 , simply resets the stack to a good value. Exceptions that trash the upper word of the return address that was pushed to call the dispather, simply don't matter)

	The programs compiled to run on the system are created with MOVE SR,D0 and MOVE D0,CCR instructions surrounding instructions that the compiler wanted to NOT affect the CCR... on a system generated for a MC68010, there would be a modification to the Priviledge Violation exception handler, to change MOVE from SR instructions to MOVE from CCR instructions... this would make MC68000 USER code run as-is on a MC68010... However, the S-rec files do not have the Move from SR emulation code.

The CPU32/010 Hybrid selection adds the CPU32 instruction set to the MC68010. It does not change the Exception processing for Address Error and Bus Error. When CPU32 is selected, there is an option to add Format 2 (6 word) stack frames, but this might compromise existing 68010 OS's that know nothing about Format 2 stack frames. The RTE instruction is changed to detect a Format 2 stack frame and return using it. (Format Error if not CPU32)
