@Chucky:
If you were to implement the integer CPU, an FPU, an MMU, and the chipset, in which order would you tackle those?
I think it is reasonable to do the integer CPU first because else you cannot execute any code. The FPU should be implemented before the MMU because there is far more code using the FPU than the MMU. So the order Integer, FPU, MMU makes a lot of sense. FPU is in the making so MMU will have to wait. This is where we are now and it makes a lot of sense.
What about AGA and SAGA? Obviously there is some confusion about what SAGA is. SAGA is an enhanced AGA with an additional chunky playfield. The chunky playfield is controlled via registers in the Amiga register address range and can be controlled by the copper. Since AmigaOS doesn't know about chunky playfields, there is a P96 driver for the chunky playfield which makes this chipset feature appear as standard RTG even though it can/could do much more (e.g. copper scrolling and copper palette shading).
The most notable advantage of SAGA is that the screen DMA can read directly from the local Vampire RAM which is faster than previous fastmem but functionally chipmem. All previous RTG software was slowed down by outdated hardware buses with something like 16 MB/s maximum throughput. The Vampire does hundreds of MB per second.
So far we have only seen the chunky playfield part of SAGA, i.e. the part that seems to be simple RTG but is implemented in an Amiga-way, in public releases. The Gold3 previews already have the AGA chipset, i.e. the planar part of SAGA added but there are still some bugs. You could call this the AGA in SAGA. Simply put SAGA = AGA + RTG on one and the same screen.
I think it wouldn't make any sense to make an effort to purposely slow down the planar part of SAGA to AGA speed. It is not even required for (my broader understanding of) compatibility. I can understand that democoders want to work around a known set of limitations and that for this reason the Vampire/Apollo project doesn't make sense for them. Well, so be it, it is not as if the demosceners were such a big part of the Amiga usergroup. Their wishes just don't comply with the goals of the project and this is not going to Change no matter how much "input" and "listening" there might be.
Now let's return to the CPU: you are very emotional about AMMX, hyperthreading and 64 bit extensions which you consider crap that is not going to get used and that take FPGA real estate that could be used for stuff that does get used like FPU and MMU. I know that you do not agree to Gunnar's vision but perhaps this explanation will make you see that there is an inner logic to the sequence in which the individual items on the TODO list are tackled.
Gunnar wants to improve the 68k ISA and extend it to what it might look like if Motorola hadn't dropped the ball over 20 years ago. This is what drives him, this is why it is happening at all.
You want something different. Everybody understood that and the project is not going to change its goals for you and those who think alike no matter how much you voice your opinion and personal preferences. You are free to conclude that Apollo/Vampire does not cater your very well defined needs and that's all there really is.
Anyway, if one wants to do a modern extension of the 68k architecture, it immediately follows that the 8 address, 8 data and 8 FPU registers just aren't enough. There is a need for 64 bit datatypes handled in the integer part while the need for 16 bit datatypes is almost zero in today's computing. More registers and especially more FPU registers are a must.
Whether you agree with this vision or not, if you want to end up with such a CPU, you can either build a 32bit CPU, throw it away and start with another one that is 64bit OR you build a 64bit CPU right from the start which means to have those additional registers and to make them wider right from the start. Adding a few AMMX instructions that actually work on those wide registers then is far less work than building and testing an FPU.
And AMMX actually does get used not only in RiVA but more importantly in the P96 driver. So even the totally-anti-AMMX user will have some benefit from the presence of AMMX even if it remains completely hidden from the user.
The same goes for the FPU itself: if you implement a 68k FPU with just 8 registers and everything the way it used to be, then all this work will go to the trashcan if you do an FPU afterwards that can access 24 registers. It is simply easier to first implement the _superset_ and then the _subset_ based on the finished superset.
The AMMX parts and additional registers are the foundation of a house that will have an FPU and MMU as a roof. You simply can't start with the roof and then build the foundation.
Another thing you have addressed multiple times is how femu is not better than the 68060.library approach. This is wrong for a simple reason: femu will be included in the core and thus not visible to outside code, most of all it cannot be overwritten by accident. More importantly femu will be present from power-on and does not need to get loaded from disk or wherever. This means that thanks to femu the FPU looks to any code exactly like an 882 FPU right after power-on/reset.
When you compare the Apollo FPU in its current state to the 040/060 FPU, the Apollo FPU is just as well a software/hardware mix as the 040/060 FPUs are. While the 040/060 FPUs have a fixed distinction between hardware instructions and emulated instructions, the Apollo FPU is flexible and can be handtuned for the FPGA at hand. For a smaller footprint you can implement less instructions in hardware, for a larger FPGA you can implement all instructions in hardware. I think that is actually a very interesting approach.
It is unfortunate that the FPGA in the V2 is too small for the full-featured Apollo Core. However, please understand that this isn't a concern to Gunnar. The Vampire isn't his baby, it is a card that licenses his core and is now too small to hold all of it. He doesn't develop the core for the Vampire, he develops the core as an end in itself.
I hope this clears up a few things...
