That would be something, to get Dragon run A OS code without emulation, but much faster than Elbox did. It is also proved that it is possible make exe that can run natively both 68k and coldfire.
I wouldn't call trapping 1/2 the 68k instructions on a ColdFire as "running native". It would destroy performance and thus the reason why Cod3r made an emulation layer. It's probably the same idea as OxyPatcher/CyberPatcher/MuRedox does for FPU instructions before they are trapped. It no doubt is easier to emulate the 68k on a ColdFire because of it's architectural similarities but the slow speeds and handicapped performance of the ColdFire make up for any advantage. Motorola/Freescale decided that the 68k can't compete with the PowerPC so they have been crippling it ever since the 68060 outperformed early PowerPCs. Freescale would rather develop weak sauce scaled down 68k like ColdFire micro-controllers and pay ARM licensing fees for an inferior product than use a little initiative to come up with an innovative and modern 68k design. It would be easier to run ColdFire code on a 68k processor. Not counting MAC or FPU instructions, there is only 6 or 7 instructions to trap at the user level and the emulation could be put in the CPU libraries. Freescale/Motorola did put MOV3Q in the A-line so no more 68k Macintosh emulation, REMU/REMS is not fully compatible with the DIVS/DIVU instruction and the ColdFire stack is 32 bit aligned instead of 16 bit aligned so there are "problems". The best bet for 68k and ColdFire native is probably in a new fpga CPU and possibly an ASIC after that. I have been working on a new ISA called 68koolFusion. The current evaluation documentation has BYTEREV, BITREV, FF1, SATS, MVS, MVZ, REMU and REMS. MOV3Q is weak and we found better ways to have the best code density in the industry (should easily beat ARM with Thumb 2 and CF
. Some CF instructions have different encodings or mnemonics though. BYTEREV and BITREV are mnemonics for the new PERM instruction, FF1 is a mnemonic for BFFFO and REMU/REMS weren't compatible with the 68k as is. MVS, MVZ and SATS are encoded the same as the CF. That's as close as you will get to running "native" 68k and CF code.
http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf@Cod3r
Nice work. The CF is weak but it does have 2 advantages and that's the built in hardware support (SoC) and price. I wondered why the Natami didn't use the CF for the hardware support considering the price and use the fpga for the main processor and Amiga chipset emulation. The CF could be used like a simple sound DSP also. SMP would not be easy to add but the Amiga has always been about coprocessors
. The fpgaArcade offloads some of the work and processing to it's ARM processor but the CF would be more familiar to Amiga programmers even if it's a watered down 68k microcontroller for the hardware. Add an fpga of Cyclone III size or bigger for the 68k and chipset emulation with basic hardware support like ethernet, USB and PCI through the CF and do it for less than $500 U.S. and you might have a winner. There is fpga code for 68k processors and the AGA chipset available to enhance and put in the fpga.
