I would/wouldn't like a production run of 060's

[matthey]

I notice they sell the mysterious MC68060FE133.

Has anyone ever been able to confirm that these are genuine parts?

Yes. They were tried in the Natami 060 board. They work but lack FPU and/or MMU.

Freescale wouldn't even entertain the notion of a new production run unless a few million dollars worth of guaranteed orders were involved and as they own the IP no one else could make them without buying a licence and then we are back to the millions of dollars problem again.

And no one is likely to want a large number of the 68060 in it's current state (except the U.S. military). It needs some modern enhancements to be appealing today. It's a great processor but it's a low clock speed, no memory controller, small caches, etc.

[matthey]

If you are going to make a new CPU, don't make an 060... it has horrible issues that you have to deal with, making a LOT of software either partially or fully incompatible with it.  I would much prefer a 100MHz+ 68040.  No compatibility issues really, and a long tested and proven CPU.

The Rev 6 68060 is very stable and all know bugs are fixed. It runs very cool compared to the 68040 and is a much better design. Both CPU designs made mistakes though. The 68040 dropped the FINT/FINTRZ FPU instruction which is very important for FPU support and the 68060 dropped the 64 bit versions of integer instructions with MULS/MULU being very important.

I had to write a LOT of 68060 specific code and patch the crap out of the Mac OS to get it to work at all on the 060 (there was never a 060 Mac, and the OS was never going to be 060 friendly without a major re-write).  In the end, the overall speed for most everything end up being slower than a 33MHz 040.

Apple tried to make the MacOS 68040 compatible but they also tried to keep it from being 68060 compatible, especially after a 68060 Amiga became the fastest Mac. Did you notice how the older MacOS 6-7.5 versions were more compatible with the 68060 than the later ones?

If you're doing things that are static (ray trace and number crunching), the 060 is probably fine.  But, I hate that thing.  Give me an 040 any day!

The 68060 is much more than a number crunching can't branch DSP. Branches and loops became much faster not that the 68040 was bad (the 68060 is good even compared to modern processors). You may have disabled the branch cache, turned off superscalar execution and used 1/2 I/D caches for maximum compatibility though. I would expect a 68060@50MHz to still run faster than a 68040@33MHz with all this disabled.

[matthey]

Unfortunately, that was not the case.  The various Mac benchmarking programs showed only minor improvements in certain benchmarks with the 060.  SuperScalar always had to be off, and there was a limited amount of branch caching allowed in certain portions of the OS code, and the instruction and data caches were toggled off and on without anyone realizing it.  Surprisingly, memory functions were quite a bit slower with the 060.  We could compare the 040 speed vs. 060 speed using the same Phase 5 setup, just swapping the CPU card.  So, the memory was the same.

The 68060 speed would drop to less than half with superscalar off. The CPU would be scalar with all the limitations of superscalar. Turning branch caching off makes the branching performance about the same as the 040. The 040 does outperform the 060 working in memory and has a larger cache fetch. This allows larger instructions but the 68060 can handle mixed instructions well, is faster with more complex addressing modes and is faster at shifting and multiplying. The 040 also has the 64 bit integer instructions and optimizations for bit field instructions in registers that would help it. The 060 is a clear winner with the FPU and has a clock speed advantage. It probably comes down to the code for the MAC. Code that is optimized for an 040 is not going to be optimal in an 060. I don't know if optimizing code for an 060 with superscalar disabled and many of the caches turned off would even be possible. It would be quite handicapped but still faster than a 68030 (the 68060 resembles in some ways a superscalar 030).

Keep in mind that the FPU was the Mac's biggest asset for the OS.  This is why you didn't see many LC (or any EC) CPUs going into Macs.  The MMU was needed of course for virtual memory.   The FPU was used by EVERYTHING in the OS!  The position of where to draw a pixel on the display was calculated by the FPU, not the CPU because it was faster to do it this way.  When Joe and I re-wrote Apple's PACK4 and PACK5 in full assembly (like everything else we did), we actually broke most current benchmark programs in the FPU tests and we made the Mac insanely fast - to the point where production studios like Amblin Entertainment were using Amigas with my Mac emulation to run Avid video editing suites because that setup would run circles around real Macs... and they could also use Lightwave for rendering too.

The 040 FPU runs in parallel to the integer units but is still quite slow compared to integer. It's not very easy to go back and forth between the FPU and integer either with the lack of FINT/FINTRZ and no fp<-> unsigned integer. I'm kind of surprised you were using the FPU for the display. Are you sure it wasn't the MMU? There are drivers for Fusion/Shapeshifter that are faster with the MMU and the way the MAC renders the screen.

I think the only possible future for new accelerators for Classic's is FPGA.   It's unlikely that anybody will implement an 040/060 as an FPGA but it looks like we'll soon have the a fully compatible 020/030 option.    If this design could be clocked much higher than a real 020 and have faster memory access then it might actually be able to perform almost fast as a real 060 when running Classic 68k software.   It might even be possible to add some 040/060 instructions to the 020 core in the future to enable it to run some 060 software.

Remember the crazy fpga hardware I was talking about the other day with a 150MHz enhanced 68k in fpga soon and a possible 500MHz+ 68k CPU in fpga in about a year? It is possible but I don't want any "announcements" or vapor ware claims. There may be some interesting reading on http://www.amigacoding.de/ if you haven't been over there recently. I have seen the I/O expansion board early schematic .

[matthey]

In the form of accelerator cards for existing Amigas or complete systems like FPGA Arcade/MiST/Minimig?

Sort of complete system. It uses standard "commodity" fpga boards with a custom I/O expansion board (for common Amiga joystick, keyboard, mouse ports and such but also SATA/PCIe/HDMIsh etc).

[matthey]

Quite possibly but we are talking imaginary hardware here.

New standalone hardware is going to happen because it's too easy. Many will fail but there are several fpga projects in the works. Standalone makes the most sense. If there is a PS2 port for using a real Amiga keyboard and 9 pin joystick ports, what is there to miss? SATA, usb, PCIe, memory cards, most of this new stuff is fast and cheap.

The TG68k is reaching 68020-68030 speeds and is not fully pipelined but it may reach low 68040 speeds. A fully pipelined CPU in similar speed but larger fpga with smart caching should be 68040-68060 speed. A bigger fpga is a real plus for a faster CPU and leaves room for an FPU and MMU/MPU. That's why the Apollo aims for a Cyclone 5 minimum (that and ALMs are an advantage over LEs). The fpgaArcade is going to be hard pressed to fit an FPU in it's fpga. This is fine for what the fpgaArcade is targeting though. They would do better to focus on retro console emulation like Genesis and X68000 after the Amiga and Atari ST, IMO.