So, if one wanted to re-create a QL-like hardware machine, there seem to be several options:
1. Use as close as possible to original hardware, perhaps expanded to what was available then assuming that (then) money would be no object. So in this group we have a machine based on the original 68k, and this means we would be limited to something like the 68SEC000.
On the + side:
* Can work in a 3V3 environment which makes it possible to use more modern cheaper memory components
* Can be made as a drop-in for 68008
* MUCH higher clock rates available
* very low power
* Reasonable price
* Fully compatible assuming some minor things (like treatment of interrupt lines, AVEC and lack of E and VPA... good riddance to those).
On the - side:
* Not as instruction-per-clock efficient as more modern members of 68k
* Not 5V tolerant when used at 3V3
* No dynamic bus sizing for attaching older peripherals so some external logic has to be used (like on the GC)
Undecided:
* 24 bit addressing
2. Two steps up, use of a more advanced and faster CPU, but at a reasonable price. Availability and price means we are practically limited to 68EC030, which is a fine option.
On the + side:
* Has dynamic bus sizing so using an 8 bit bus for slower peripherals is not a problem.
* Speed improved far over the original QL CPU, 50MHz capable parts are not uncommon
* Very reasonable price/performance ratio
* More instructions per clock compared to original 68k
* 32bit bus width makes things even faster.
* Full 32 bit addressing
On the - side:
* OS needs patching to cater for changes in exception behaviour, extra stack pointer and caches.
* 5V only, no direct interfacing to 3V3 unless the 3V3 parts are 5V tolerant. This means extra parts for interfacing modern memory, crucial for low cost. But see note at the end...
* Bus protocol(s) are different an need extra hardware to make QL compatible, this an be largely avoided if most traditional prepherals are replaced with more modern equivalents.
* To get maximum performance, some advanced bus functions need to be used which requires a fair amount of external logic, so count on a decent CPLD to get a complete system at a reasonable cost and speed.
3. The middle way between 1 and 2, using an integrated 68k series MCU. Several candidates aexist, most notably 68340 and 68SZ328. The former may be more interesting in something more like the vintage machine.
On the + side:
* 68k compatible cores, no OS changes needed past adding extra features (if wanted)
* Highly integrated can help put together a capable system with very few parts
* SZ328 is 3V3 capable, has built in LCD controller which can double as CRT base controller but for limited resolution (VGA 640 x 480).
* Much faster than original CPU
* 68340 is CPU32 based which is basically 68020 without the extra stack pointer and cache, and 16 bit bus, runs about 1.6x faster at the same clock compared to original 68k. This also means it has dynamic bus sizing!
* Can be had for fairly reasonable pricing, although the actual MCU price may seem high, it is compensated by many on-board features.
On the - side:
* 68340 is 5V only, 68SZ328 is 3V3 only - both may imply extra hardware for parts of the system
* 68340 runs at slower clock but with better efficiency but does not have a cache so to get the maximum performance, some really fast memory is needed. With fastest bus cycles, there is basically a single cycle of write data available per bus transaction which means either a decent SDRAM interface running at 2x clock (requires conversion of 5V to 3V3 logic) or 40ns or less static RAM which is expensive.
* 68340 has fairly low capability serial ports by todays standards, though far better than original machine
* 68SZ328 has so many options it is difficult to decide on a practical configuration
* 68SZ328 uses a 0.8mm pitch MAPBGA case which mat require a 6 layer PCB, though 4 layer could be possible with a 'breakout' adapter or VERY fine track geometry.
4. Top of the line performenace. Here it's almost only the 68060 and derivatives. FOr QL like applications the 68EC060 is perfectly fine. A FPu would be nice but a MMU is 95% wasted.
On the + side:
* FAR faster than the original machine, especially if overclocked.
* 3V3 compatible and tolerant which may simplify hardware
* Full 32-bit implementation of the bus
* VERY easily shares a common bus with other 68060(s?) which is a whole new area of exploration.
On the - side:
* Sky high prices and fake parts
* Top speed requires good memory sub-system, preferably SDRAM, but since that is 3V3 only, it basically negates 5V tolerance.
* No automatic bus sizing so interfacing to narrower buses either requires external logic or different address mapping. This may not be a big minus as interfacing to slow buses would require some sort of buffering between the fast and slow bus portions anyway.
* Has extra features over 68k that need to be catered for in the OS, like 68020 and higher plus extras.
* Quite large and potentially (very) hot running chip (especially overclocked)
* Expect decent size CPLD or two or FPGA to implement system glue logic efficiently.
5. The FPGA way. This is quite open ended as it can take the shape of any of the above propositions depending on FPGA programming. But in this case I will limit this to a FPGA re-implementation of a 68k fully compatible core (likely with speed enhancements) packaged to look like a sort fo 68k MCU variant. Think something like a small PCB which may be a drop-in replacement for an old style 68k CPU.
On the + side:
* Immense flexibility. One can envision a 68k 'chip' with a faster internal clock and cache, plus extra hardware depending on actual application, or something like the Q68 and then, depending on amount of work or money available, all the way to something very involved with a '68080' core.
* Reprogrammability means bugs can be fixed and the whole design streamlined and improved over time to the extent the used FPGA's capacity, but then even if that is reached, a re-design with a more modern one is possible.
* Implementation may range from very 'original' to very advanced, depending what one means under 'fidelity to the original design's soul'.
On the - side:
* Extra learning curve or VHDL/Verilog experience and a very wide understanding of CPU operation and native hardware required
* Lots of hours to be invested in perfecting and optimizing the design
* FPGA may get obsolete by the time the design is finished since it is practically an impossibility to make this a widely co-operative project. Usually it is a one-man band thing so it will require time, and FPGA manufacturers always want to sell you their latest and greatest.
* As a rule the FPGA is 3V3 only which means that some implementations, like replacing an older style 5V part, require external hardware. This may, however, also protest the FPGA from 'accidents' with clumsy users.
6. The path not traveled yet. This is about retargetting the hardware to one of the latest ColdFire chips, particulairly V4 is the most interetsing
On the + side
* Hard to beat performance, perhaps a very advanced FPGA implementation like the 68080 core could get close
* A TON of extra hardware and features integrated on the chip as Coldfire were always intended as MCUs.
On the - side:
* Hard to get chips and can be unreasonably expensive. Also may be prone to faking.
* not completely 68k compatible although V4 gets very close. Most of this can be fixed by the public domain emulation package.
* On the OS level, patching is needed to cater for single stack pointer. So here the problem is one less, rather than 020+ where there is one extra
* The bewildering array of extra on chip hardware make sit difficult to chose a sensible QL style configuration and most of the added high level functions will likely (sadly) remain unused. This ha salso repercussions on the hardware, these are all BGA chips with tons of pins...
* Never been done before so no existing code base for the hard non-compatible stuff, plus lots of time needed to fix problems that will arise.
6.5 A special mention, Coldfire V1. The MCF5102 Coldfire 'bridge chip' and the only V1 chip is essentially a compiled version of a slightly reduced 68EC040, with only the multiplexed bus mode available and smaller caches. This makes it fit into a small 144 pin TQFP case. This is the only Coldfire that is fully 68k compatible (or more precisely, as much as 68020 or 68030).
On the + side:
* Low power and small form factor, 3V3 operation
* Essentially it's an 68EC040 so OS patching stuff is available from Q40
* Very good performance, fully 32-bit, fastest part was 40MHz, Internally clock doubled so simple instructions approach 1 clock cycle per instruction.
* Expects SDRAM, multiplexed bus makes the system somewhat simpler to implement on a board basis but requires some more resources inside the inevitable glue logic CPLD or FPGA that needs to be used to make an efficient hardware design
On the - side:
* No dynamic bus sizing, so same considerations like the 060, a CPLD solution is needed to interface to a narrowr bus if one wants to meka this a QL compatible board or a drop-in replacement for an older 68k style CPU
* Not 5V tolerant (If I remember right)
* Has some bus quirks which actually prevent it from working as fast as theoretically possible
* Used to be fairly cheap, now it is unreasonably expensive and may also be faked (lower grade re-marked as higher grade)
Special note for Brane2
There is a nice Sinclair aspect to the potential use of a 68EC030. Like the full 030, this one too has dedicated power pins for the core and various pin drivers, so the challenge would be, figuring out if supplying different voltage power to pins that power the bus and control signal drivers, can get the 68030 to be 3V3 compatible... Assuming the treshold voltages of the P and N MOSFETs in the buffers don't cross when a lower voltage is applied, resulting in excess current through the buffer output stage, at least outputs should be no problem, inputs might be tricky. So... maybe consider it a challenge