Z🛞RRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

Joe Circello, chief architect of 68060, answers question about 68000 CPU in NeoGeo AES+
https://youtu.be/1takr2k7Yfo?t=4465

Question: Given that the team at Plaion has managed to recreate an ASIC version of the 68000 for the new NeoGeo AES+ console, do you think it is possible or will eventually be possible to do the same thing for the '060 for perhaps a future Amiga Ultimate computer?

Answer: "There is a huge world of difference between a 68000 and 68060, right. I mean they're orders of magnitude more complex, the machines."

But...

1. " the 68060 does not have any microcode per se in it" where 68000 microcode uses 34136 bits with some estimates at ~20k of ~68k transistors (ARM1 was ~25k transistors using 1512 bits of microcode)
2. x86 is "clearly clearly more complicated" than 68k and "started from a position of difficulty and has only gotten worse over all the years"
3. "original 68000 was fairly well known as being a very clean ISA implementation"
4. 68060 "processor itself and the pipeline, all of that stuff, was done fully synthesizable" allowing the 68060 to be synthesized in a modern FPGA
5. fully synthesizable 68060 design more easily allows a "validated and verified" design, moving to newer chip fab processes and improves chip yields (68060 did not suffer from chip yield problems of earlier 68k CPUs)
6. "There is always the option of starting from a clean sheet of paper and going off and developing a new microarchitecture. Even if you are trying to copy an existing one, you have to go through the process. That is an infinitely more complex road than being able to take, if you had a snapshot of the existing design, like the RTL database, being able to take that and resynthesize that in a 5nm process or something like that."
7. the 68060 used to emulate a 68040 Mac at better performance than any Mac "which warms my heart" but now stand alone ARM and x86 hardware are orders of magnitude better performance than any 68k Amiga while we keep reinventing and throwing away known good 68k wheels

Text in quotes above are from Joe Circello.

The NeoGeo AES+ ASICs may allow an optional minor 68000 overclock of 50% (12MHz to 18MHz) providing an ~50% performance improvement while a modernized 68060 Amiga, like the old in-order Intel Atom, should provide an ~10,000% to ~20,000% CPU performance improvement. This would be using an older more affordable process like the Atom originally used of ~40nm instead of the 5nm process Joe mentioned. Would the two NeoGeo AES+ ASICs or a single ASIC 68060+ Amiga SoC offer more value? Should Motorola engineers have settled for another 6800 model CPU and should Jay Miner have settled for another 6502 gaming machine because it would have been easier? Do 68k and Amiga fans like the hardware and technology, understand it and know it is still good other than being on outdated silicon or shall we throw away the old 68k Amiga technology and history choosing to use emulation on ARM and pretending it is real 68k Amiga hardware because it is easier?

Last edited by matthey on 25-May-2026 at 11:58 PM.

@matthey

Why “or� when we can do both? Emulation of CPU is fine by me, not like the real 68k CPUs were doing much in parallel (except FPU) anyways, and if you don’t care about MMU you can have very fast JIT emulation for cheap. However, some of us want fast _and_ fully featured 68k with MMU, not necessarily to run AmigaOS, and for that we long for a new ASIC 68040/060-ish CPU.

Oh and the AC68080 MMU is now 6 months overdue because reasons.

Last edited by kolla on 26-May-2026 at 05:45 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: However, some of us want fast _and_ fully featured 68k with MMU, not necessarily to run AmigaOS, and for that we long for a new ASIC 68040/060-ish CPU.

True, if you want full compatibility you need FPU+MMU and at least a 68040 compatible ABI.

If you only want to sell a gaming device for the masses, you can go with 68000 (A500) or 68020 (A1200) and no one will ask you for performance increase. The 'masses' of potential customers are ex-Amiga users, they will happily buy something that runs like a basic Amiga.

Only a fraction of a fraction is asking for a faster Amiga, I got the impression that no one is asking for a Apollo A6000.

@kolla
The superscalar 68060 is "doing much in parallel" with many units operating in parallel, not just the FPU.

68060 units which can issue/execute/retire/fold instructions in parallel
2x integer units (equivalent of load/store unit in each integer unit)
1x branch unit
1x FPU

45%-55% of instructions issued as pairs/triplets (existing 680X0 code)
50%-65% of instructions issued as pairs/triplets (targeted 68060 code)

This is a high instruction multi-issue rate, especially for existing unsheduled 68k code. Most instruction execution is with single cycle throughput like RISC cores but unlike RISC cores, more powerful CISC instructions with memory accesses can execute in a single cycle. Emulation can not come close to the performance efficiency (performance/MHz or performance/cycle) of the 68060, even using a much more expensive OoO CPU core which uses more power and generates more heat. If we assume AArch64 requires 5 instructions for each 68k instruction, one 68k instruction using less than 3 bytes of code on average expands to 20 bytes of code. The RPi 3 in-order Cortex-A53 and RPi 4 OoO Cortex-A72 have a 16B/cycle instruction fetch yet can not keep up with the power saving 4B/cycle instruction fetch of the 68060 for 68k code. Instruction supply is the largest power consumption for smaller CPU cores which is a major reason why code density is so important.


https://www.cast-inc.com/blog/consider-code-density-when-choosing-embedded-processors

The Cortex-A53 can issue 2 instructions/cycle and the Cortex-A72 3 instructions/cycle but this also does not keep up with the up to 3 instruction/cycle issue of the 68060 for 68k code. The Cortex-A72 OoO also uses more power and wastes energy reducing or eliminating the load-to-use stalls the 68060 does not have. This abomination of efficiency is when executing the already translated code in JIT buffers where translating the 68k code to AArch64 code is more wasteful, creates jitter, the JIT buffers waste several times more memory that a 68k system uses and the much increased memory accesses waste energy. Come pay up to try our abomination of 68k efficiency on ARM hardware and if you like it, you will have to learn to live with 1990s performance levels. How is this going to attract ex-Amiga fans let alone new users?

The solid state transistor and general purpose computer/CPU are THE most important tech inventions/advancement of the last 100 years. Most other top tech advancements of the last 100 years would not be possible without them. There are approximately 3 to 4 MPUs and tens of MCUs in the world for every living person. The 2 most important attributes of a computer that make it useful are performance and price. Efficiencies are also important which reflect these such as price efficiency (performance/$), power efficiency (performance/W) and performance efficiency (performance/MHz). If you want the 68k to be antiquated and EOL, then ignore this reality. The good news is that I believe the 68k could be competitive on silicon. The bad news is that many 68k fans do not see the advantage of this. I not only want 68k hardware to replace my dying 68k Amigas but also to be able to do more computer work on 68k hardware which is easier to use than any other computers I have experienced.

Features are important for computer usefulness too. Any 68k hardware needs more modern I/O while retaining retro compatibility. A MMU per CPU core is an important feature for modern systems. Not only is it important for retro 68k use but it is important for other more modern features like memory protection, process isolation, security and SMP. I believe it is possible to retain compatibility and vastly improve performance. A modernized 68060 design would operate much the same way as the 68060 design and it is a fully static design that can have the frequency reduced from max to zero. Add a fully static 68000 core to the SoC and a few more clock sources than usual to increase 68k compatibility further. Adding back some missing 68060 features should improve 68k compatibility as well since transistors on silicon are much cheaper than in the 1990s.

Last edited by matthey on 26-May-2026 at 10:47 PM.

@matthey

Quote:

The superscalar 68060 is

out of production, NXP is giving a sh!t about its legacy hardware, they are supporting ARM now and every embedded customer is asking for ARM instead of 68x

Last edited by OneTimer1 on 27-May-2026 at 07:25 PM.
Last edited by OneTimer1 on 27-May-2026 at 02:10 PM.

OneTimer1 Quote:

out of production, NXP is giving a sh!t about its legacy hardware, they are supporting ARM now and every embedded customer is asking for ARM instead of 68x

ARM makes life easy for NXP and others. ARM develops and provides the ISAs, configurable CPU and GPU cores, standard IP blocks, etc. The a la carte resources are convenient for NXP and has made them lazy. They pay significant royalties to ARM while they have better technology they stopped developing. ARM has become the standard and nobody gets fired for buying ARM. The original saying was nobody gets fired for buying IBM but did that make the IBM PC/AT better than the 68k Amiga in 1985? Did the 68k Amiga have better CPU and chipset tech, come with a better OS and at a significantly lower price than the IBM PC/AT? Should the Amiga developers have stopped Amiga development because the IBM PC was already the PC standard or chosen x86 CPUs because that looked like a safer option for the future of PCs?

As for MSX switching to ARM hardware which you edited away, it did not help compatibility.

Review MSX0 Stack – Handheld MSX Revival Is A Bitter Disappointment
https://www.timeextension.com/reviews/msx0-stack-n-handheld-msx-revival-is-a-bitter-disappointment Quote:

Compatibility isn’t 100%, unfortunately. We've had a few games that would not load at all, while some do run but with graphical glitches that render them either annoying or unplayable. Worryingly, the menu for selecting disks is also glitchy. Give a disk image an over-long filename or fill the SD card with more than a handful of games and the menu is prone to corrupt or simply not display every filename. It’s no wonder that some early adopters have programmed their own improved disk selection tool. When games work, which is about 70% of the time in our experience, it’s really good fun to play old favourites on this dinky system – but we would have expected a much higher compatibility rate from an official system. ... Until that time, we would only recommend the MSX0 to hardcore fans. For everyone else, there are better solutions. We'd encourage anyone curious about the classic system to buy a real MSX2 and a few carts, while those who wish to emulate on the go will almost certanly find more reliability in the Analogue Pocket’s forthcoming FPGA core. An FPGA core is also available for the MiSTer platform. That said, we've found ourselves taking the MSX0 with us everywhere we go this week. It’s small enough to add to our daily carry, and many games are compact enough for quick bursts of play in spare moments. In many ways, the system reminds us of the Amiga; it has the potential to be expanded, altered and improved by its community in ways perhaps its creators never anticipated, and we hope it will eventually blossom into something special in time.

It is funny that Ashley Day, the new MSX handheld review author, would bring up the 68k Amiga to compare with the flexibility provided by the ARM based hardware. The 68k Amiga with 32-bit CPU ISA and modular dynamic libraries is more flexible, expandable and upgradeable than many earlier systems based on 8-bit tech. Emulation did not improve the MSX handheld but a Z80 CPU is not nearly as upgradeable as a 68k CPU. While the Z80 family is more capable of supporting OSs and compilers than the 6502 family, the 68k can fully support and retains surprisingly good support by OSs, compilers and development tools despite the age. The 68060 is already supported by the Amiga, Atari ST, X68000, 68k Mac and Sinclair QL. The most modern Z80 family successor, the Z80000/Z320, is not compatible with the Z80 while the 68060 not only offers good compatibility but good performance executing 68k code from before the 68060 was released.

68060 units which can issue/execute/retire/fold instructions in parallel
2x integer units (equivalent of load/store unit in each integer unit)
1x branch unit
1x FPU

45%-55% of instructions issued as pairs/triplets (existing 680X0 code)
50%-65% of instructions issued as pairs/triplets (targeted 68060 code)

The 6502 and Z80 CPU family gaming computers and consoles are limited by the primitive CPU designs. MIPS based consoles like the PS1, PS2 and N64 can not be easily upgraded to superscalar CPUs because of the RISC instruction fetch bottleneck problem compounded by NOPs in the code, load-to-use stalls requiring different instruction scheduling and branch delay slots causing further problems. Also, deeper pipelines of modern RISC cores usually increase load-to-use penalties which was already a problem for the relatively early MIPS R4000. ARM for the not gaming oriented Acorn Archimedes and the 3DO console is a little better off. The Archimedes RISC OS requires kludges for 26-bit addressing software and the original 32-bit ISA is being dropped from both superscalar Cortex-A cores and MCUs leaving few options for legacy support. The 3DO ARM CPU received the new 32-bit addressing narrowly avoiding this problem. ARM did not use NOPs excessively or use branch delay slots but newer superscalar cores have increased load-to-use penalties, like the Cortex-A53 with a 3 cycle load-to-use penalty, and superscalar execution requires more independent instructions between a load and use of the data loaded, twice as many independent instructions in the case of 2-way superscalar execution like the Cortex-A53. The original ARM 32-bit ISA was weak with only 14 GP registers while the code density was almost as bad as old RISC ISAs with 30+ GP registers like MIPS, SPARC and PPC. The 68k has 16 GP registers with the code density of ARM's Thumb ISAs, which allowed ARM to finally take the embedded market but with weaker performance than the 68k as usually only 8 GP registers are available. Later RISC architectures than the 68k have more modern performance handicaps and legacy RISC code may not run on more modern RISC cores at all. A RISC philosophy rarely stated is the do over at the expense of compatibility philosophy. This is why we are up to RISC-V after 4 do overs, ARM has 4 ISAs with 3 do overs and the A1222 is barely PPC compatible after fat PPC castrations for the embedded market. Modern RISC should stand for Redone Instruction Set Architecture considering that modern RISC ISAs no longer have a minimalist Reduced Instruction Set Architecture. The CISC 68k ISA has fewer instructions than most modern RISC ISAs.

Last edited by matthey on 27-May-2026 at 10:45 PM.
Last edited by matthey on 27-May-2026 at 09:46 PM.

@matthey

Quote:

68060 units which can issue/execute/retire/fold instructions in parallel 2x integer units (equivalent of load/store unit in each integer unit) 1x branch unit 1x FPU

That’s not the point, which was about code execution in an emulated 68k vs a real 68060, running AmigaOS - AmigaOS code doesn’t expect the CPU to do things in parallel (even when it does) so emulation of CPU isn’t nearly as "critical" as having chipset components running independently from each other and the CPU.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla
The Hyperion developed 68k AmigaOS has 1979 expectations for a 16-bit 68000 CPU. An expectation for code is that instructions are generally executed as if sequentially ordered in memory like most other CPUs. A 68000 compiler target assumes a scalar 68000 CPU with selection of instructions and optimizations based on 68000 timings. Instruction scheduling reordering of instructions to avoid instruction pipeline and superscalar instruction pipeline dependency stalls is unnecessary without a 68000 pipeline or superscalar capabilities. Instruction pipelining is a form of Instruction Level Parallelism (ILP) and the scalar 68020-68040 sometimes benefit from instruction scheduling.

https://en.wikipedia.org/wiki/Instruction-level_parallelism Quote:

Micro-architectural techniques that are used to exploit ILP include: o Instruction pipelining, where the execution of multiple instructions can be partially overlapped. o Superscalar execution, VLIW, and the closely related explicitly parallel instruction computing concepts, in which multiple execution units are used to execute multiple instructions in parallel. o Out-of-order execution where instructions execute in any order that does not violate data dependencies. Note that this technique is independent of both pipelining and superscalar execution. Current implementations of out-of-order execution dynamically (i.e., while the program is executing and without any help from the compiler) extract ILP from ordinary programs. An alternative is to extract this parallelism at compile time and somehow convey this information to the hardware. Due to the complexity of scaling the out-of-order execution technique, the industry has re-examined instruction sets which explicitly encode multiple independent operations per instruction. o Register renaming, which refers to a technique used to avoid unnecessary serialization of program operations imposed by the reuse of registers by those operations, used to enable out-of-order execution. o Speculative execution, which allows the execution of complete instructions or parts of instructions before being certain whether this execution should take place. A commonly used form of speculative execution is control flow speculation, where instructions past a control flow instruction (e.g., a branch) are executed before the target of the control flow instruction is determined. Several other forms of speculative execution have been proposed and are in use, including speculative execution driven by value prediction, memory dependence prediction, and cache latency prediction. o Branch prediction, which is used to avoid stalling for control dependencies to be resolved. Branch prediction is used with speculative execution. ILP is exploited by both the compiler and hardware, but the compiler also provides inherent and implicit ILP in programs to hardware by compile-time optimizations. Some optimization techniques for extracting available ILP in programs include instruction scheduling, register allocation/renaming, and memory-access optimization.

FPU instructions can execute in parallel with int instructions also benefiting in performance from instruction scheduling for the 68020-68060. This is a simplified but similar OoO execution to high performance OoO CPUs which is mentioned as ILP. Commodore supported at least 2 forms of CPU ILP and compiled the AmigaOS for the 68020 which offers much better performance for the 32-bit pipelined 68020-68060 than compiling for the 16-bit unpipelined 68000. The SAS/C compiler used to compile the AmigaOS was simple and had just introduced instruction scheduling targeting the Motorola 68040 processor and 6888x FPUs with SAS/C 6.0 released in 1993. Commodore went bankrupt the year the 68060 was released explaining why the superscalar ILP of the 68060 was not better supported. Note that the 68060 also uses ILP speculative execution, branch prediction and a form of what Motorola called register renaming allowing the results of early execution in the AGU stage of some instructions to be forwarded to the other int pipeline thus avoiding similar stalls as what is normally thought of as register renaming. Another important ILP of the 68060 not mentioned but that much improves 68k Amiga performance is the store buffer.

M68060 User’s Manual Quote:

The MC68060 implements a four-entry store buffer that maximizes system performance by decoupling the integer pipeline from the external system bus. When needed, the store buffer allows the pipeline to generate writes every clock cycle until full, even if the system bus runs at a slower speed than the processor.

Chip memory should be marked as cache-inhibited imprecise on the 68060 reducing the performance loss of slow chip memory CPU stores. Earlier 68k CPUs had to wait on slow chip memory for stores to complete. Commodore was planning for AA+ to add write posting and fast register access to reduce CPU and chipset related stalls as they planned to use a 68020/68030 class CPU with AA+ and the single chip 68k Amiga.

Specifications for Upgraded AA (AA+) based system Quote:

Write Posting (optional) To minimize stalls caused by chip access, ARIEL supports write posting (aka write buffering). What this means is that for a chip register or memory write ARIEL latches the processor address and data and immediately asserts A_DONE_N, allowing the processor to proceed while the write is completed at some later time. Obviously if a read or second write request is issued before the first one has been executed, the second request must be deferred until completion. There is some concern about potential adverse software impact, but this is probably minimal since the write will be completed just as soon as if the processor was stalled on it, and any subsequent read (or write) will cause resynchronization by stalling on an uncompleted write. However, it is important that writes to INTENA bypass this feature since this would leave open the possibility that interrupts would be recognized after they were disabled by the CPU. Write posting requires no significant on-chip resources, but entails some elaborate of the processor interface logic.

After Commodore upper management got their head out of their ass after realizing their "no new chips" mandate would produce an outdated 68k Amiga instead of the next C64, they tried to catch up quickly with the rushed AA/AGA and better done AA+ but it was too late. At least the engineers understood the importance of CPU ILP which works in parallel with chipset and multi-processor/multi-core parallelism. CPU ILP allows the single core/thread performance needed by games and allows software in general to be more interactive. While the chipset was the cheaper way to provide performance back then, CPU performance upgrades were more general purpose and often provided larger performance improvements. AI says that from a 386 to an in-order Intel Atom is roughly a 1,000 to 15,000 times performance improvement which should be similar to a 68020/68030 improved into a modernized 68060+. A 68060 would likely have remained too expensive for Commodore to use in a single chip 68k SoC until the late 1990s despite the reasonable $308 USD price at introduction. Today, a 68060&AA+ SoC could be produced for less than $1 USD as it uses fewer transistors than less than $1 RPI MCUs. The choice is between ignoring modern tech with a no new chips philosophy and a retro EOL virtual Amiga or modernizing it so it is useful and relevant again. Commodore supported ILP for improved CPU performance but was slow to advance tech which greatly contributed to their demise. Hyperion development of the AmigaOS is a step back in tech at a much later date still using the SAS/C compiler but now targeting a 68000 with practically no ILP. Commodore had fallen far enough behind in tech to be called a dinosaur but the software AmigaOS support and hardware virtual 68k Amiga emulation is much further behind today.

The only use of the current 68k Amiga is for retro EOL support. A virtual 68k Amiga is not competitive for any other use.

https://www.buffee.ca/Why-PJIT-Why/ Quote:

In Emu68, a single 16-bit 68000 opcode can take several 32-bit ARM instructions to execute; if every opcode took just three, then that's a 600% increase in code size, not including the extra bit of code to enter and exit each block and the possibility of the same block of code needing to be translated several times from slightly different entry points.

JIT 600% code growth creates an instruction fetch bottleneck worse than the fat RISC bottleneck and blows out caches. It is not competitive for performance.

https://www.buffee.ca/Why-PJIT-Why/ Quote:

Jitter is caused when the JIT code needs to be created the first time before it can be executed. It is so expensive that most modern JITs will avoid it on the first pass of code. On Emu68, the jitter shows about a 20~25% performance difference between the self-reported SysInfo scores and the "wall clock" benchmark that includes the time to create the block.

JIT jitter is unacceptable for embedded systems where consistent performance and response times for interrupts are valued. The in-order Cortex-A53 at 2.3 DMIPS/MHz replaced the OoO Cortex-A9 at 2.5 DMIPS/MHz with similar performance and reduced stalls. Part of the reason the Cortex-A53 became the most popular CPU core ever is that it had reduced jitter compared to the Cortex-A9.

https://wiki.amiga.org/index.php/A600GS Quote:

A600GS o 2GB system memory with 512MB allocated to AmiBench as Fast Memory o 64GB total storage The A600GS+ has enhanced specifications: o 4GB system memory with 1GB allocated to AmiBench as Fast Memory o 128GB total storage

Wasting 75% of system memory is nowhere close to competitive for small footprint systems.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=35809&forum=33&start=1540&viewmode=flat&order=0#872510 Quote:

Native ARM code with instruction scheduling can partially remove the huge ARM Cortex-A53 bottleneck due to load-to-use stalls. Simple and quick emulation conversion of 68k to AArch64 code usually does not include instruction scheduling though. Worst case instruction scheduling can be expected as the 68k CPUs do not have load-to-use stalls so the code is not scheduled to avoid them (load results are usually accessed by the next instruction stalling the Cortex-A53). A load-to-use penalty of 3 cycles is a performance killer and bad for an 8-stage CPU especially when 68k CPUs didn't have any load-to-use penalty. Then there is the RISC load/store instruction bottleneck that requires more instructions, memory traffic and registers than CISC. A typical general purpose CPU workload of instructions will average to approximately the following. load 26% (~25% which is 5 out of 20 instructions) store 10% (2 out of 20 instructions) ALU 49% (~50% which is 10 out of 20 instructions) branch 15% (3 out of 20 instructions) 20 instruction typical workload for ARM Cortex-A53 emulating 68k code load x5 with load-to-use stalls (5*4= 20 cycles) store x2 (2*0.5 to 2*1= 1-2 cycles with store buffer) ALU x10 (10*0.5 to 10*1= 5-10 cycles) branch x3 (most are conditional predicted branches so ~0 cycles) --- total: 26-32 cycles The Cortex-A53 load instruction execution throughput is 1 cycle but the latency is 3 cycles and the load result can't be used for 3 cycles. Much of the Cortex-A53 performance improvement over the predecessor Cortex-A7 is due to improved superscalar execution but this requires very good and sometimes impossible instruction scheduling due to the increased load-to-use penalty. The Cortex-A53 has two simple integer execution pipelines so it can execute two ALU instructions in a cycle but so could the 68060 which also has most of the design features without the bottlenecks. 20 instruction typical workload for 68060 load+ALU x5 (5*0.5 to 5*1= 2.5-5 cycles) store x2 (2*0.5 to 2*1= 1-2 cycles with store buffer) ALU x5 (5*0.5 to 5*1= 2.5-5 cycles) branch x3 (most are conditional predicted branches so ~0 cycles) --- total: 6-12 cycles

The Cortex-A53 wastes roughly half of CPU core cycles to load-to-use stalls with JIT unscheduled code. With code and data cached, the 68060 outperforms the Cortex-A53 at the same clock speed even when the Cortex-A53 uses perfectly scheduled code which is very difficult. If you do not believe that is possible, compare the P5 Pentium using ancient fab process and the same size caches as the 68060 vs Cortex-A53 in the 7-Zip benchmark below and then consider that the 68060 had 40% better integer performance than the Pentium in the ByteMark benchmark. If the 68060 had 40% better int performance for the 7-Zip benchmarks, it would have an avg score of 0.88, outperforming the most popular in-order cores for embedded use, the OoO PPC G5 and the OoO Cortex-A9. The SiFive series 7 (U74) cores use a similar but modernized CISC/68060 like design with a weaker RISC-V ISA. I believe a modernized 68060+ core can compete with limited OoO cores several times the size while some here believe a Cortex-A53 virtual 68k Amiga that can not reach scalar CPU core performance and with a far worse jitter and memory footprint is adequate.

single core | 7-Zip compression/MHz | 7-Zip decompression/MHz | 7-Zip avg
IBM_Cell_PPE 0.23 0.33 0.28 (PS3)
AtomN2800 0.47 0.62 0.55
PentiumP5 0.64 0.62 0.63
Cortex-A53 0.56 0.92 0.74 (RPi 3, A500 Mini, A600GS)
SiFive_U74 0.70 0.92 0.81 (RISC-V HiFive Unmatched, VisionFive 2 core claimed 20% better per MHz)
Cortex-A55 0.63 1.03 0.83
68060 ? ? 0.88 (68060 estimate of +40% int performance/MHz vs Pentium)
SiFive_U74 ? ? 0.97 (VisionFive 2 core estimate of +20% performance/MHz vs Unmatched)

IBM_PPC_G5 0.49 0.82 0.66 (OoO)
Cortex-A9 0.56 0.84 0.70 (OoO)
IBM_POWER9 1.08 0.83 0.96 (OoO)
Cortex-A57 1.08 1.02 1.05 (OoO, Nintendo Switch)
Cortex-A76 1.00 1.18 1.09 (OoO, RPi 5)

https://www.7-cpu.com/ (source of 7-Zip benchmark results)
https://blog.bitsofnetworks.org/riscv-performance-power-usage/ (claim VisionFive 2 series 7 CPU cores have +20% performance/MHz vs Unmatched based on decompression benchmarks)
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44391&forum=25#847418 (Bytemark results showing 68060 +40% int performance/MHz vs P5 Pentium)

Note: The performance efficiency (performance/MHz) of the in-order PPC Cell, in-order Atom and OoO PPC G5 were reduced by deep pipelines to allow higher clock speeds. While the Intel Atom and Cortex-A9 lack performance efficiency for good single core/thread performance, they were #1 and #2 respectively for least energy used in https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient benchmarks. Super pipelining is no longer necessary to achieve reasonably high clock speeds so more practical approximately 8-stage pipelines like the 68060 have become more common, especially for in-order embedded cores where latencies and jitter become more important to minimize.

Last edited by matthey on 08-Jun-2026 at 05:11 AM.
Last edited by matthey on 08-Jun-2026 at 04:29 AM.
Last edited by matthey on 08-Jun-2026 at 04:22 AM.
Last edited by matthey on 08-Jun-2026 at 12:40 AM.

Metro Siege Kickstarter raising more funds from NeoGeo market than Amiga or PC market. Perhaps there is an advantage to having new and supported hardware rather than old dying and virtual hardware?

Neo Geo
Neo Geo AES Edition €323 x19 = €6137
Neo Geo AES Ultimate Edition €365 x14 = €5110
Early Neo Geo AES Edition €318 x5 = €1590
Early Neo Geo AES Ultimate Edition €360 x5 = €1800
---
NeoGeo AES subtotal €14817

Neo Geo MVS Edition €285 x0 = 0
Neo Geo MVS Ultimate Edition €318 x0 = 0
Early Neo Geo MVS Edition €280 x5 = €1400
Early Neo Geo MVS Ultimate Edition €313 x5 = €1565
---
NeoGeo MVS subtotal €2965
===
NeoGeo total €17782

Amiga
Amiga DVD Case CD Edition €39 x14 = €546
Amiga Boxed CD and USB Key Edition €55 x20 = €1100
Amiga Boxed Floppy Disk Edition €73 x7 = €511
Amiga Boxed Collector's Edition €86 x4 = €344
Amiga Boxed Ultimate Edition €108 x15 = €1620
Early Amiga DVD Case CD Edition €34 x5 = €170
Early Amiga Boxed CD and USB Key Ed. €50 x5 = €250
Early Amiga Boxed Collector's Ed. €80 x5 = €400
Early Amiga Boxed Ultimate Edition €103 x5 = €515
===
Amiga total €5456

Universal
Metro Siege Digital Edition €13 x109 = €1417
Metro Siege Digital Collector's Edition €43 x2 = €86
Metro Siege Digital Ultimate Edition €82 x0 = 0
Early Digital Ultimate Edition €77 x4 = €308
Early Digital Collector's Edition €39 x5 = €195
===
Universal total €2006

https://www.kickstarter.com/projects/metrosiege/metro-siege
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45869&forum=9

The Neo Geo cartridges have a much higher price and the Neo Geo wait until release is longer yet new hardware has clearly rejuvenated the Neo Geo AES market. The 68k Amiga market is treated as a 2nd class citizen again with only a 68000 ECS 1 MiB spec, no guarantee of even a 68020 AGA 2 MiB spec version and obvious inferiority to the Neo Geo version. Commodore treated the 68k Amiga as non-upgradeable planning to replace it instead and A-EonKit treated the 68k Amiga as a 2nd class citizen to PPC AmigaNOne. SNK and Plaion treated the Neo Geo as the king of consoles and it is back as a result, despite the 68k Amiga being much more upgradeable, expandable and flexible. Cheap virtual 68k Amigas receive a RPi 1 level of scalar CPU performance but without the low power, small footprint or cheap price. The Neo Geo, C64 Ultimate and Acorn Archimedes on the RPi get ultimate upgrades while the 68k Amiga gets the Commodore treatment all over again.

Last edited by matthey on 08-Jun-2026 at 09:47 PM.

@matthey

You ruin your own chaln of reasoning by using A600GS as an argument, Amiberry isn’t a 68k emulator, it’s an Amiga emulator. So apparently your agree that AmigaOS doesn’t rely on parallel execution of code of the sorts you keep bringing up, and that this isn’t critical at all compared to chipset etc, you just use wall-of-text approach to disguise it.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla
Amiga emulation without 68k emulation is AmigaNOne emulation, best known for dividing and sabotaging the Amiga market after horrible value AmigaNOne hardware failed in the Amiga market. As far as parallelism, emulation uses a CPU core which provides sequential execution as I stated previously. The CPU providing the emulation is working on emulating the 68k CPU or chipset with brute force by switching between emulating them. There is minimal if any parallelism between the CPU and chipset, no Amiga DMA, no asymmetric multiprocessing architecture, no message driven with wait based preemptive multitasking, no efficient 68k CPU design, 68k CPU ILP is replaced by brute force OoO execution, 68k super code density is replaced by several times larger code than already fetch bottlenecked fat RISC ISAs and no elegance 68k Amiga design remains. A virtual 68k Amiga is as much of an AmigaNOne as PPC AmigaNOne hardware and even less elegant as more brute force sequential processing and CPU polling is used. PPC AmigaNOne hardware uses DMA, parallel GPUs, message driven wait based preemptive multitasking and CPUs operating in parallel with more ILP. The Amiga is a 68k CPU, Amiga chipset and the AmigaOS or it is not compatible and the Amiga masses flee though. It is no different than the Commodore guys trying to bait and switch a PC with Linux Commodore OS for the C64 market except that the Commodore guys payed for their used IP and A-EonKit never relented at trying to jam a market failure down customer throats. Perhaps SNK and Plaion learned from the A-EonKit and Commodore mistakes and got it right the first time with the Neo Geo AES+.

Wrote a reply here but apparently posting is broken...

Last edited by minator on 09-Jun-2026 at 02:17 PM.
Last edited by minator on 09-Jun-2026 at 02:17 PM.
Last edited by minator on 09-Jun-2026 at 02:16 PM.
Last edited by minator on 09-Jun-2026 at 02:15 PM.

_________________
Whyzzat?

Will try again...

CISC may make code smaller but has an opposite effect on silicon. In fact it has an enormous cost on silicon area and complexity.

The 060 was $308
The MIPS R4200 had similar performance and lower power (about 2W) at around $50.

2 years later the StrongARM gave 2x the performance, required under 0.5 Watts and cost $29.

The 060 was very RISCy for a CISC chip and a worthy end to the 68K line, but RISC outperformed it at the high end and undercut it at the low end.

Last edited by minator on 09-Jun-2026 at 07:51 PM.

_________________
Whyzzat?