@g01df1sh
Because trapping and handling the differences between the 68k and Coldfire instruction sets generated so much overhead that it benchmarked around 68040 speeds, with less compatibility. While Coldfires were cheaper than 040's/060's most of the cost was just in making the board, so for not much more money you could make an 040/060 card that was significantly faster than the Dragon, didn't need any sort of emulation to run simple 68000/68020 code, and had relatively lightweight emulation libraries for the code that *was* incompatible (68040/68060.library).
Or you could just build a 100% compatible overclocked 68030 card for dirt cheap and get most of the performance of the Dragon. The only time the Dragon was really fast was when it was running code specifically compiled to avoid the emulation traps.
Nowadays we have the Apollo 68080 FPGA core that even running on reconfigurable silicon is faster, and it can be implemented with brand new parts (rather than old legacy Coldfire stock). If they ever get around to spinning up an ASIC of the core it will make a mockery of any other 68k compatible or semi-compatible that ever existed by an order of magnitude.
EDIT:
More specifically, going from the 68000 -> 68060, there are essentially no incompatibilities other than unimplemented instructions. These are easily dealt with using a trap handler that runs equivalent code when the CPU throws an unimplemented instruction exception (or in the case of Oxypatcher/Cyberpatcher, the handler actually patches the offending code in memory so that the next time it runs it doesn't throw an exception again).
The real danger is when an opcode exists on both CPUs, but behaves differently. The only one of these issues that seriously affected the 68000-68060 Amigas was that on the original 68000 the upper 8 bits of the address registers were completely ignored (the 68000 only used a 24-bit address bus) by memory operations, so some too-smart programmers decided to use those bits to get effectively an extra 8 8-bit storage registers on the CPU. This is why AmigaBASIC doesn't work on 68020+ (or on 68012 though I don't think anyone ever made a 68012 card for the Amiga). Some other early software used this trick but most programmers learned it was a bad idea by the late 80's. There's no runtime patch to make stuff like this work -- only patched executables that fix the problem.
Coldfire *DOES* have some opcodes that are valid, but behave differently than the same 68k opcode.
There's no way to reliably catch and back out of these situations without having something scanning the code ahead of time. It's possible to do this without *too* much overhead (this is how VMware's products worked on x86 chips built before 2006 -- they had to catch instructions on the virtual CPU that they couldn't allow to run on the physical CPU in order to maintain the virtual environment) but it requires some serious development and optimization.
Coupled with the fact the fact that Coldfire is missing tons of addressing modes commonly used in pretty much all Amiga 68k software (and every single one of those instructions had to be trapped and emulated or patched), the overhead just wasn't worth it.
The Coldfire shouldn't be though of as a 68k CPU that you should run 68k code on. Instead it should be thought of as a related CPU that due to its similar architecture can emulate 68k code in a pinch without having to run a full emulated hardware environment.
Last edited by AmigaHope on 10-Nov-2018 at 01:35 PM.
Last edited by AmigaHope on 10-Nov-2018 at 01:25 PM.
|
7 crawler(s) on-line.
123 guest(s) on-line.
0 member(s) on-line.
g01df1sh 
