A few answers on Nasta's nice long post. Wish I had the time for more.
Nasta wrote:Currently 1a + 2a is covered with the Tetroid SGC clone. The problem here is the Ingot CPLD which is becoming impossible to find and to a lesser extent the floppy controller chip.
Even under the assumption CPLDs can be sourced, I'm not sure it is covered, lacking decent video. This is mainly why I opened the topic. And I would close it, if Tetroid or you added video.
Nasta wrote:Also, 1b + 2b os covered by the Q68 which is it's own single board computer and has no ties to old hardware except virtually
Maybe the term "virtual" sounds like "emulated" for some readers. Let me clarify: The Q68 implements
QL components in hardware
. Like SGC+Aurora, just with different features, and CPU inside programmable logic.
Nasta wrote:In fact, given that the 68EC030@40M tends to run just fine at 50M and is actually cheaper than 68020 variants, AND it supports dynamic bus sizing which lets it easily use various bus widths concurrently in the system (extremely useful if you are doing a SGC replacement!), AND it can also be interfaced to burst-capable RAM sich as SDRAM, it would be THE chip to use for this purpose, without breaking the bank. Given proper support for external hardware, this option actually runs significantly faster than the current Q68.
Agreed, but only due to DRAM waitstates. If we compare for fast SRAM (thereby looking only at CPU speed) the Q68 executes many instructions in a single clock cycle, including multiplication. Even if a 16-bit databus is kept for the Q68, I doubt the 68030 still beats the Q68 at this core discipline. I know this is hard to believe, but I put much effort in getting the CPU to run that fast inside a lowest-speedgrade decade-old FPGA. If someone had time, 68030 reference hardware, and benchmarks that fit the Q68 SRAM area, it can already be checked on the current Q68.
To reduce Q68 DRAM waitstates, I work on cache. My first implementation has only 2 KB, but there is a tag entry for every single word, I did not split it into lines. This should be very appropriate for QL-style code. (Currently I'm struggling with a bug, and I fear it is inside the synthesis tools.) Hard to predict if a 40 MHz Q68 with cache beats a 50 MHz 68030 with 32-bitwide DRAM, but the chance has become realistic. After all, 2048 bytes cache is more than 2x256 bytes, and 1 clock cycle per basic instruction is less than 2.
Nasta wrote:On the high end, there is a FPGA implementation of a new 68k+ sompatible core called the 68080, which includes a FPU and extension to 64-bits. It is not as fast as the fastest still available coldfires (which I have decidedly skipped for reasons I'll get to below), but still about 3-4 times faster than the fastest 68060, possibly more, depending on how much you are willing to pay for the FPGA to implement it.
And depending on how much you are willing to pay for licensing - the "68080" is a strictly commercial core. They offer a massively clock-reduced and otherwise limited version without royalties, in the hope to get money for upgrades. But once you want that outside
their Amiga-accellerator boards, there is need for negotiation and probably paid support work, besides large amounts of work for platform and FPGA vendor adaption. Since my name is known from Q60 and Q68 designs, they seemed open for cooperation, although I doubt they are aware how extremely small the QL scene is, and how little money they could make. I got some questions answered, but postponed a closer look. At the moment I don't feel like another high-end design, and anyway a SGC successor would probably not be the right place for it.