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)
  • 1
    Memory is the limiting factor. CPUs went from roughly 1MHz to 5GHz. Access time to went from 70 ns to 5 ns in the same time. So it is 3.5 order of magnitude difference. Modern CPUs gain their performance mainly thanks to the different level of caches and the extended bandwidht increasing modes (FP, EDO, 64 bit etc.). An old CPU without all these facilities would be limited by the memory access speed. Even if you clocked your m68k CPU gigahertz, it would only process as much as the memory is capable of delivering over the old bus system, so barely noticeable. – Patrick Schlüter Jul 23 '20 at 11:50

11 Answers 11


If you look into real hardware (like a Motorola/Freescale/Rochester 68060, which is long out of mass production):

Modern CPUs (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.

A 2 GHz 68000 is probably asking a bit much. As mcleod_ideafix points out, 100 MHz (or several 100 MHz, 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 and 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 56 MHz instead of its original 3.5 MHz. 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 56 MHz, though :) )

  • 13
    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
  • 10
    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
  • 1
    An emulated ZX Spectrum can be boosted to a whopping 56 MHz instead of its original 3.5 MHz. You could make a real hardware Spectrum that runs at 20MHz with an in-production CPU (the Z84C0020) that dates to 1990 (I have an announcement of availability in Practical Electronics Dec 1990). Given the generally large overclockability of 90s processors, it's plausible you could achieve the same same speed with real not emulated hardware, and have been able to do so in the 90s. There are reports of it running well at 24MHz, but that's without cooling or overvolting. RAM speed would be a big issue. – occipita Jul 21 '20 at 9:09
  • 1
    For a 56MHz Z80 to run with zero wait states you'd need RAM with a 26ns access time and 52ns cycle time. Fast enough RAM did exist at the time (I have found a 1991 motorola databook that includes 15ns SRAM), but it wouldn't have been cheap. – occipita Jul 21 '20 at 9:29
  • 1
    @occipita: Adding even one wait state to code fetches would greatly ease the memory timings. If one had a system with e.g. 256 bytes of zero-wait-state code memory, and ensured that the most speed-critical code lived there, that could probably greatly reduce the cost of a system running at that speed without hurting the performance too badly. – supercat Jul 30 '20 at 21:56

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.

  • 11
    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
  • @wrosecrans Coldfire CPUs are far from the GHz spec - the fastest v4e, the 547x, runs at max 266MHz. The base instruction set of v4e is basically identical to the 68000, the main thing is that the set of available addressing modes has been severely reduced. Most 68k software will not run. – tofro Aug 2 '20 at 8:28
  • Don't forget that a FPGA implementation could also use less cycles for reading/writing data and for each instruction, so the performance could be x-times faster per MHz. – bebbo Aug 7 '20 at 18:43

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.

  • Right. Motorola managed to keep the 68K product line competitive with Intel/AMD for just as long as they spent similar amounts of money developing it. They stopped because the sales didn't justify sinking the same amount of money their competitors could because they didn't have the lucrative PC-compatible market to sell to. – occipita Jul 21 '20 at 9:38

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
  • 3
    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
  • 2
    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 '19 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
  • 1
    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
  • 2
    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
  • 1
    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
  • 2
    What killed the m68k was not the instruction set itself, but its overcomplicated addressing modes, especially the ones introduced with 68020. These were really difficult to implement fast with a mmu. Theoretically a 68020 instruction could trigger up to 16 page faults. The addressing modes of 386 are in that regard much saner (max 2 page faults). – Patrick Schlüter Jul 23 '20 at 12:01

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.


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.

  • I don't think this is really true: "All modern CPUs are just faster versions of old architectures". – davidbak Aug 14 '20 at 16:03

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.


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.

  • 2
    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
  • 1
    Which wasn't asked about - or was it? – Raffzahn Dec 26 '18 at 10:06

Fundamentally, the real issue is lack of demand. Let's say a 6502 compatible chip...

It won't be any cheaper than the current 65816 (which is a 16bit 65xx series with support for bank-switching 256 banks of 64kb, and 14 MHz). Probably be more expensive, even. It works best with 14 NS or faster RAM and ROM.

The 65816 is mostly used in embedded systems where 16 MB memory is spacious.

Replacing it with a 6502 sounds cool, until you realize most 65816 code is for the non-emulation mode, and would require recompile. A faster 65816 would exist if the market demanded it, but the embedded systems using it are not looking for faster - they can swap to ARM if then need more speed or power.

Now here's the other big element: if you build a faster 65xx or 65xxx processor, what are you going to connect it to? Most of the compatible support chips aren't that fast, either.

So, you wind up wanting faster everything else, too.

And that's where the other shoe drops: FPGAs are now running over 50 MHz emulating the 65xx line.

There's no need to make a 50 MHz 6502 - you buy the off-the-shelf FPGA, load the core file into it, and use it as a 6502 at 50 MHz... or software set it for 20, or 10, or 4... or even the original 1.2... as needed for your current program. And a bonus: if you want, you can load a different core and use that FPGA as a Z80 or i8080.

I have heard there was a company looking at a faster 65816... but the price for a new chip would be prohibitive.

I have seen [reports][1] of FPGA 65xx cores running nearly 100 MHz...

And really, there's no need for 65xx processors that fast; it would be cheaper to use a modern 16 or 32 bit ARM (some arm SBCs using 32bit chips are under $20) and an emulator.



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

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.