Showing my ignorance about hardware here - I noticed there is still a community developing Amiga accelerators cards. Giving substantial boost from the original memory for example.

However the processor frequency while faster, aren't significantly faster then the originals processors (nothing that comes close to modern clock-frequencies).

What prevents a 2ghz Motorola 68060 from being created for example? *

Is it a limitation of the architecture?
Or is possible, just uneconomical?

* of course speed isn't _just_ about clock frequency, nevertheless it's a factor.

Update: some of the answers focus on new CPU's for older hardware. Creating the new & faster version of an architecture may mean having new motherboard, ram, graphics bus... etc.

See also:

  • Firebee (entirely new Atari compatibles).
  • Vampire (new CPU's for Amigas)

10 Answers 10


If you look into real hardware (like a Motorola/Freescale 68060, which is long out of production): Modern CPU's (mainly Intel) boosted to several GHz clock frequency have one main technical limit: How to get the heat away from the sensitive silicon. There is a lot of clever technological magic involved to do that (powering down parts of the chip not currently in use, thermal design which respect to distribute the heat around the chip evenly, low-power technologies everywhere,...). "Old" stuff, like the 68k just don't have this in their design and would need to be re-designed, possibly entirely, in order to cope with the frequencies.

2 GHz 68000 is probably asking a bit much. as mcleod_ideafix points out, 100 (or several 100, on a really very, very fast FPGA) might be possible. MiST, which runs a quite decent Altera Cyclone III, is able to push its Atari ST emulation to about the level of an Atari TT, the Amiga can be emulated to somewhere between the margins of an Amiga 2000 or 3000. An emulated ZX Spectrum can be boosted to a whopping 56MHz (instead of its original 3.5). Obviously, most of the computer's internal timing is derived from the system clock, and some of the hardware needs a re-design as well to further scale down the clock used for example for video output.

The question is: Does this make sense - Old games used unchanged would become mostly unplayable due to the high speed, and there is not really that much software around to actually be able to use that power - Well, everything would be faster which is kind of comfortable.

(I do admit I like playing "The Hobbit" on an emulated ZX Spectrum at 56MHz, though :) )

  • 9
    A 68060 only has 2.5 million transistors -- about 1/1000 the count of a modern Skylake CPU. Do a process shrink from the original 600nm process to a 14nm process, and you'll have a tiny speck of a chip drawing a fraction of a watt, with fewer transistors total than the Skylake has active at any given time. I don't think you'll be thermally limited, you'll be limited by things like the shallow instruction pipeline. – Mark Jun 24 '16 at 18:41
  • 6
    Ironically, that's how I learned to type: I had a typing tutorial that was tuned for a much slower processor, and I got frustrated that I could never get more than 1 wpm... so I kept at it and got up to 3 wpm. Later, I realized the time scale was off by a factor of 11: I'd accidentally gotten up to 30 wpm at an early age just to try and beat a system was designed for a 3mhz processor on my 33mhz processor. – phyrfox Jun 25 '16 at 1:48

Nothing stops anyone from creating faster accelerator cards (assuming amiga or Atari ST - the only two platforms allowing for proper expansion cards), but there would be at least 3 major things to consider:

  • CPU's - as far as I know, the fastest "classic" 68k CPU's are about 60MHz, with some revisions that can go as fast as 80 or even 100MHz. For, say 2GHz CPU (or its equivalent in speed) one would have to create their own - most likely in FPGA or better yet - ASIC

  • Bus speed and other devices outside of accelerator card, remember that computer's have many more components such as I/O controllers, Video chips and other custom chips (such as blitter) - at some point you would hit performance issues with them

  • Timing issues, older computers heavily relied on proper timing on the bus, CPU and other components to ensure proper gameplay, going in with a very fast accelerator would almost certainly break compatibility with some of such products (mostly games)

Other platforms would have different limitations, on some the CPU's are actually static - so in theory can run with any speed, but you may be limited by memory speed for example.

FPGA's capable of such high frequencies would be extremely expensive, but this is the way such accelerator cards now go in this direction, examples include:

  • Vampire2, but even then it actually does NOT implement an actual m68k CPU, it has it's own architecture that is compatible with m68k. One reason being that Gunnar von Boehm already had the architecture invented and designed, and another would be licensing terms from Freescale - if I'm not wrong they didn't even want to talk about giving their m68k implementation to the team.

  • Chameleon (for commodore 64) and MIST implement CPU in FPGA - the former is kind-of an accelerator card for C64, while the latter is a whole platform implemented in FPGA, capable of mimicking various machines (Amiga, ST, C64 and many others)

Another clone called Minimig may be a minor exception - it uses an actual Freescale CPU, clocked at 7 or 49 MHz (turbo mode), the CPU is static.

  • 10
    FPGAs are currently far from reaching gigahertz frequencies for a design as complex as a 68000. A good design in a fast FPGA may give you about 100MHz – mcleod_ideafix Jun 24 '16 at 0:39
  • Some ColdFire CPU's were apparently up around 1 GHz, but I don't know if they would run Amiga software. From what I understand, Coldfire is a 68k subset, so an Amiga could theoretically run code for a Coldfire CPU, but a Coldfire might not implement all of the instructions that were needed by classic "true" 68k systems. – wrosecrans Dec 26 '18 at 5:35

I haven't looked at the architectures, but I suspect that one factor will be that the architecture sometimes will have implicit assumptions about the micro-architectural implementation. To achieve a GHz clock frequency, modern processors use maybe between 8 and 15 pipeline stages - with the expectation that typically all of the stages can be in use by a sqeuence of instructions.

The older architectures are probably closer to 5 pipeline stages, which means more work can be done in a single stage. On modern processes, this scales up to maybe 200 MHz. Adding pipeline stages to get a higher frequency will (simplistically) increase the cycle-per-instruction penalty.

  • 1
    Indeed, the 68000-68030 CPUs had one "pipeline" stage, ie. there was no pipelining before the 68040, which had a whopping three stages. – nsandersen Jun 28 '16 at 15:38
  • 2
    I think it's also a matter of the instruction set complexity. Supporting nine different addressing modes takes a lot of gates, and managing the clock with so many variable propagation delays takes more. That's one of the big reasons that RISC chips became so popular. – TMN Dec 9 '16 at 16:11
  • While this is correct that architecture changes are as much a part of speed improvement as the bandwidth of the silicon, this handwaves away the huge distinction between latency and throughput. Adding pipeline stages increases the latency of instructions, but the throughput remains high because much of the time you have an instruction at each stage of the pipeline. Only when the pipeline stalls or becomes invalidated by a branch do you suffer the full delay. The point of adding stages is to make each one faster (by doing less work in it), and the overall chip gets faster for most tasks. – Chris Stratton Jan 14 '18 at 3:21
  • 1
    The 68000/68010 had a two-stage pipeline for prefetch while the 68020/68030 used a three-stage pipeline for prefetch. Source "The M68000 family Volume 1", Motorola. – Ken Shirriff Jan 4 at 21:39

Many would agree that Motorola was in a much better position to develop their 68k into something fast and modern than Intel with their crufty x86 ;) But Motorola stopped and abandoned the 68k in favour the PowerPC (which today still is at the heart of IBM's 5+ GHz POWER CPUs). Most users of 68k CPUs switched to Intel or various RISC CPUs. Commodore and Atari stopped creating new machines altogether.

There are of course faster versions of the 68k architecture (eg ColdFire which goes to about 300MHz, and the VAMPIRE2 FPGA core which is only limited by the speed of the FPGA). But just making the CPU faster without improving the rest of the system results in a badly balanced system.

If you look at the original PC, it was (despite its general ugliness) a very well balanced design: the speed of the ISA bus, the bandwidth and the amount of memory, the graphics capabilities, and the disk of the IBM PC/XT roughly matched the capabilities of an 8088. While the CPU often was the bottleneck, every so often it wasn't. In a modern PC, the ratios are similar, and conversely there is very little left of the original XT's architecture.

You could of course build an adapter to put a modern Core i7 in an old XT to replace the 8088, and most people would agree that this is silly. There were in fact upgrades ("powerups") that adapted new CPUs to old sockets (eg to put a 386 in a 286 system), but the result was generally quite disappointing even for such an adapter that skipped just one generation.

And this is basically what accelerator cards do, they try to shoehorn a faster CPU onto an old architecture while keeping central parts of the existing architecture. Some accelerator cards move more periphery (memory, disks, graphics etc.) onto the accelerator to take advantage of all that new processing power, but this usually comes at the cost of compatibility, and if it's incompatible, what's the point?

  • 1
    The 8086 is much better balanced than the 8088 since the latter ends up spending most of its time awaiting code fetches (a typical two-byte instruction will take 2-3 cycles to execute if the prefetch buffer is full, but the CPU can only fetch one byte every four cycles (so fetching the instruction takes 8). The 8086 fetches two bytes every four cycles. Also, the CGA card is surprisingly slow to access; the "snow" might be tolerable if it allowed fast access, but accesses need to be synchronized to a character-output clock which is active once every 2.67 CPU cycles... – supercat Jul 1 '16 at 22:51
  • ...and IIRC the CPU never gets access on the first such clock but must await the second. – supercat Jul 1 '16 at 22:52
  • True, but we're not discussing whether the 8088 was a good CPU. What you're describing is a limitation of the CPUs interface, not the system that was built around it. With a perfect memory subsystem, an 8088 can execute an "add reg, reg" in 11 cycles (8 to fetch the instruction, 3 to execute it). With the actual memory subsystem it had, it could execute it in maybe 13. I would argue that this is quite balanced. A 486 with a perfect memory subsystem can execute that instruction in 1 cycle, but with the 8088's memory interface, it would take hundreds of cycles, making it extremely unbalanced. – Rico Pajarola Jul 3 '16 at 11:10
  • 1
    The prefetch and execute can happen simultaneously, so the execution time for a sequence of add reg,reg instructions would be eight cycles each. If one were to use an alternating sequence of mul bx and add cx,ax instructions, then the prefetch queue would get filled during each mul bx instruction, so the add cx,ax would delay the next multiply by three cycles rather than eight, but in most programs the CPU will spend most of its time waiting on prefetch queue. – supercat Jul 4 '16 at 18:20
  • Once you got a mul instruction in the pictures, all these calculations don't matter anymore, it takes 70+ cycles to execute. But it's still missing the point, what I'm saying is that the memory subsystem in the PC was quite adequate for that CPU... it was neither too fast nor too slow in the general case. – Rico Pajarola Jul 5 '16 at 21:39

Nothing actually prevents anybody of creating 2GHz 68060-like CPU. Or even highly-speculative out-of-order 68k-compatible one.

All you need is tens (if not hundreds or more) of millions dollars to be able to spin a production process at (for example) TSMC and a talented team that would be able to create RTL for such a processor, do a proper verification for it and do a proper physical design procedure to get production files for chips manufacturer.

Or more specifically, nothing prevents that except for economical reasons.


Many older architectures were designed so that the speed of internal operations would be well-balanced with the speed of memory technologies that were available at the time. They were also designed to balance the cost of circuitry within a microprocessor or microcontroller with the cost of required support circuitry. As technologies have changed, the ideal balances of performances and cost have shifted, so an architecture which was well balanced in the 1970s-1990s would be quite unbalanced today.

Further, many systems that used older processors relied upon the precise performance characteristics thereof. Code to generate video on an Atari 2600 or read an Apple II floppy disk would produce garbled results if instructions ran any slower or faster than expected. Making a faster processor useful on such systems would require that it include a mode which ran at exactly the same speed as on the old system and have a means of switching to and from that mode when required. While some boards for a system like the Apple II may have been able to manage that in such a way as to work with most existing software (e.g. include some high-speed memory separate from memory on the board, use that memory instead of the motherboard memory for regions outside $0400-$0BFF and $2000-$5FFF, and double the CPU speed whenever accessing the fast memory and the floppy motor isn't running) but since the required logic would vary depending upon the target system it would be difficult to include the logic within a CPU chip.

There is one 1970s architecture (the General Istruments PIC) for which speeds were pushed successfully in a third-party clone (the Parallax Scenix line). I'm not sure why Microchip (the company that inherited the GI design) never came up with anything even close, and unfortunately Scenix clones have been out of production for years now. I've never used one, but from what I understand a Scenix chip could read an I/O bit and conditionally update other bits 20ns later--a level of responsiveness which even modern controllers can't match.


I am not an electronics expert so I cannot give a really good answer here.


I do know that one of the main limitations on far greater speed is going to be how quickly the memory can be accessed. Normal dynamic system memory needs to be refreshed, and is generally slow and needs time to become ready to access.

Cache RAM meanwhile is typically static RAM which does not need constant refreshing, but has also traditionally been ridiculously expensive so the amount available was tiny, possibly only a few kilobytes vs megabytes of main memory.

The processor itself may contain some cache memory internally as part of its own chip logic, but this was also typically very expensive and so even smaller than the external static RAM cache.

Looking at a modern chip like the Intel i7-3820, it has 10 megabytes of cache RAM, the costs of which for a 68000 would have been absolutely ridiculous back in the day, and the processor may not even have the wired electronic capability to directly address the memory space of a cache this large.


Much of the speed increase of modern systems comes from changes to the memory electronics, which for the older methods topped out at about 133 mhz before double data rate was developed, followed by DDR2, DDR3, and DDR4 today.

You can't just slap these newer technologies onto an old CPU and just expect it to work. The CPU and its support chips have been designed to work with specific memory architectures, and redesigning to support newer types is so complex that essentially an entirely new chip needs to be fabricated.


Also older processors generally had a fixed speed clock that ran at a steady rate continuously. If the memory was not ready, the clock continued anyway so the processor constantly used energy even when it was stuck waiting.

Old processors were also generally slow enough that they operated fanless. The 68000 was generally installed as a bare chip without either a fan or heatsink.

In the same manner, most computers had physical power switches and ran continuously until manually turned off.

Although mobile systems eventually developed sleep modes to save battery capacity, interest in power savings and processor idling didn't really begin on the desktop until about 1995-2000.


Accelerating an old 68000 or 6502 to gigahertz speeds is therefore fraught with peril. Due to the steady clock rate no matter what it is doing, the CPU is going to be a fireball of heat production due to it lacking the ability to slow its clock or briefly sleep if necessary to prevent damaging overheating.

And due to the design differences in memory architecture between modern DDR and how the older RAM worked, it may not be possible to make it function at all.


This is essentially due to the miniaturization capability. At those very frequencies, the very small parasitic capacitors present in any transistor become more and more problematic : A capacitor is like an elastic membrane which block the current and the faster you alternate the direction of the current, the more movement you can give to your electrons, and this produces heat.

Now multiply all those small currents by the amount of transistors on your chip, and your start to have a thermal dissipation problem. The only way you can reduce those capacitors when you have reduced all the other causes, is by reducing it's size.

Those capacitors have another consequence, which is that they will absorb the command current you give your transistor, which makes them need a certain amount of time to react to command (it is called the raising time), and for this reason, you need to give each transistor, enough time or your CPU won't work.

  • 1
    How does this prevent a 2GHz 68060 from being made? The 8086 clearly managed to solve these problems. – Mark Jan 19 '18 at 23:46
  • Well, one probably «could» make it, but who would pay to remake an identical completely obsolete design ? there are improvements which were just impossible with this old technology. People would have a hard time reproducing it exactly the same -without- trying to improve things here and there, or introduce new ideas which have spawned since then. (And by the way : Do the original design still exist ?) – Camion Jan 20 '18 at 6:53

Fundamentally, just economics. All modern CPU's are just faster versions of old architectures. But, through decades of competition, not all of the architectures survived.

PC's are basically still 8086 in a hyperevolved state. IBM sells PowerPC systems that can trace a lineage back to the architecture in 1994. Phones run ARM CPU's that evolved from the ARM-1 in 1985.

If you had 10 billion dollars a year to spend on buying faster versions of your favorite defunct old architecture, I am sure they'd be happy to spin up a project to make it for you.


The x86 is an ancient architecture, some IBM mainframes as even older (System Z).

Their evolution is interesting to understand what is needed to make faster compatible CPUs.

To make a CPU faster than in the 80s, you can use modern manufacturing processes and gigahertz clocks, add large caches and all the refinements of current high performance CPUs : out of order, speculative, superscalar, branch prediction,...

But this is not enough. Because a 5GHz MC68000 is useless. Mostly.

The purpose of faster CPUs is to run more complex software, and this software will need larger registers (24 -> 32 -> 64 bits addressing), an FPU then some SIMD/Multimedia instructions for efficient processing of things that could not be conceivable in simple integer CPUs, then more elaborate MMU mechanisms (virtualisation, security features), multiprocessing, multithreading, assistance for encryption, support of dynamic compilation...

The ARM is nearly as old as the x86, but they broke the instruction set at least three times (ARMv2, 24bits, then ARMv7, then the 64bits ARMv8). Intel managed to keep things quite compatible, but there are clearly deprecated parts in the architecture (x87 instructions, segment registers) which adds dead weight.

Motorola was more aggressive in deprecating things and breaking compatibility : The MC68040 don't support in hardware all the MC68882 FPU instructions, its MMU is simpler than the MC68851, etc. The ColdFire family discarded many silly MC68020 addressing modes.

I think (but don't have any definitive proof) that the x86 family was more amendable to high performance implementations than the MC68K, because there are arguably more critical defects such as complex addressing modes (bad for pipelining, OoO and MMU faults management), most instruction update flags (bad for superscalar)... Of couse, a reboot, like what AMD did with the 64bits x86 mode (which, besides 64bitness, doubled the number of useable registers) could have fixed most MC68K original shortcomings.

In summary : Yes, a CPU running with a speed equivalent to a 20GHz 6502 is certainly possible, but it is useless as the main CPU of a personal computer. Sooner or later, the instruction set architecture would have to evolve (to a 65816, then the never released 65832...). Over 30 years, the descendant will keep little resemblance from its ancestor.

  • 1
    OP's question was if it could be done - isn't this answer all about whether you should do it – TonyM Jan 18 '18 at 8:08
  • @TonyM : There are many answers about changing the chipset and the microarchitecture. My answer is about which features a "MC68060" designed in the 2010's would have : multicore, 64bits, SIMD, virtualizable,...IBM and Intel are supporting decades-old architectures, and this is how things evolved : software-hardware co-evolution. – TEMLIB Jan 18 '18 at 20:32
  • Which wasn't asked about - or was it? – Raffzahn Dec 26 '18 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.