Agreed. The MC68060 is nice and all, but the lack of some integer instructions is a problem for old codes. The support package is nice, but unlike the FPU support package, the performance impact is significant [1]. A nice soft-core in a FPGA would be a great thing to have.
But...
The only motorola MMU implementation I know of is not open-sourced (... yet, hopefully) and is for the '030. There's no FPU implementation - I know of two projects including mine (don't hold your breath, haven't touched it in awhile) to do it, but the '881/'882 are complex beasts. Both projects are targeting the '040 subset as it's much easier and could be supported by the '040 FPSP. The '030 soft-core I've used from Suska for my Sun3 project has no open-source caches, no open-source MMU, is quite large, and as it emulates the exact behavior of the '030 (including instruction and bus timing) it is not very efficient in terms of timing closure - even on a Artix-7 speedgrade -2, 20 MHz is not an easy target to achieve :-/ But it works fine otherwise.
At some point I believe it does. if the CPU is just emulated on something faster (like a PiStorm), why bother with the rest of the system? Once the CPU is emulated, the SCSI disk is emulated, etc., then it's easier to just run Qemu. Faster and more reliable than any vintage hardware with or without acceleration.
FPGA is still "hardware", at least in terms of the way things are designed. If a proper MC68040 was available in a FPGA and validated as a substitute for the real thing, you'd """""only""""" (not sure 5 quotes is enough around that word
) need to simulate various timings and some hardware validation to start thinking about doing a VLSI version of it...Though I suspect it would be easier to do an older design first (the regular 68000 comes to mind). [1] The FPU in the '040 has much lower latency than the external interface to the '881/'882 (which was a very neat design, but also quite slow so offloading an instruction is only worth it if it takes long enough - tried that with AES instructions for SSH, the large gain of the faster instructions is almost wiped out by the coprocessor interface overhead). Trapping and executing a fast sequence of FPU instructions to replace the rare and ultra-long instructions like transcendentals was a good trade-off. Trapping for integer instructions that were done inside the pipeline of the '020/'030/'040 has a much more visible overhead.
