MiniMig with AGA

[MskoDestny]

Um, y'all do know that the v3 and higher coldfire chips are faster and cheaper than all of those 68Ks, and can translate whichever core you want to use just by changing out the library you use in the boot ROM, right?

It's been a long time since I last looked at this, but the v3 isn't fully compatible even with the emulation library for missing instructions (for instance, I believe it only has a single stack pointer whereas the 68K has separate stack pointers for system and user mode). v4e + the emulation traps is probably close enough for most things though.

That said,  emulating instructions via traps is expensive, especially on moderned pipelined architectures like ColdFire. I haven't seen any solid numbers on what the performance hit is, but from the impressions I get it's substantial enough to wipe out most if not all of the performance gains over a 68060 and maybe even less powerful members of the 68K family. If AROS had a working Amiga 68K port, it might make more sense. Then at least the OS and libraries could all be compiled for native Coldfire and only legacy apps would end up triggering the traps. The Atari folks are working on some hardware that would be suitable for a ColdFire based Amiga clone: http://acp.atari.org/ It looks like it has a fairly large FPGA so I imagine it should have plenty of room for an AGA implementation, TG68 core for a compatibility mode and whatever extra features one might like to add.

Of course, if I understand some screenshots made by Tobias from the thread linked earlier, it seems that TG68 can beat out an 030 just by virtue of being clocked so much higher. It would seem that with a more modern design (TG68 is designed to be cycle accurate to a 68000 for most byte and word width instructions from what I understand) smoking a 68060 in a reasonably attainable FPGA should be quite possible.

[MskoDestny]

@MskoDestny - ...and at 220MHz I seriously doubt those traps would slow it down enough to even notice. The remainder of the coldfire's core is still 68K instruction compatable.

I think you greatly underestimate the cost of all those traps. There are a number of commonly used 68K instructions and addressing modes that ColdFire doesn't support even in the v4e version. Something as simple as add.w would need to be emulated with a trap (ColdFire only supports the 32-bit add.l natively). It will take several cycles to just branch to the trap and then you'll need several instructions to emulate the unimplemented instruction.

When you compile natively for Coldfire, a 220MHz v4e will handily beat even the fastest 68060, but code compiled for the 68K family will run substantially slower. Again, I don't have actual numbers, but at least one person said the performance was similar to a fast 030 or maybe an 040 when running typical Amiga software: http://bbrv.blogspot.com/2008/03/coldfire-developer-program-begins.html (see the second comment or so).

The benefit I see is being able to select the CPU you want to emulate for maximum compatability and performance. Hell, make it a menu in the boot ROM. Before you load the library, select the CPU for this session.

This isn't really a big deal. These libraries implement the missing instructions, but they don't deal with other sources of incompatibility (cache, 24-bit vs 32-bit addressing, etc.). If a piece of software won't run on a 68040 or 68060 equipped Amiga it won't run on ColdFire either. The only reason there are multiple versions of the emulation is that there is no point taking up ROM space to implement instructions your software is never going to use. Beyond that, there is no benefit not implementing some of the 68K family instructions.