pixie Quote:

pixie wrote: @MEGA_RJ_MICAL What gives you, above everyone else, the high moral ground to say this? You the resident loonie... you're now pretending to be the voice of reason? No more zorram from you? I pity the fool

Some "fools" waste time to discredit, censor and vandalize the free speech of others to satisfy their egos. How hypocritical would be of them to say that people who are intellectual, educational, who speak the truth and who are productive are the ones wasting time?

I found pictures of a 68030 prototype which was the last 68k design before what I interpret as partially switching to Verilog and FPGAs for the 68040 and fully for the 68060.

68030 prototype at 1 MHz - 18 boards of TTL
https://retrocomputingforum.com/t/68030-prototype-at-1-mhz-18-boards-of-ttl/1387

The pic on this page is unfortunately the emulator. The actual pics are the *NEW.jpg pics at the following link.

https://drive.google.com/drive/folders/1w8kaX8qUO7b6cg6HBuXaQ6iqt2IPeahf

There are 18 TTL boards so quite large but it looks like Joe Pillow may have been more complex to create due to more wire wrapping.

https://www.floodgap.com/retrobits/ckb/secret/lorraine.html

It is entirely possible that chipset designs were commonly still using gate level schematics in software with manual/custom place and routing instead of using Verilog in the early 1990s. Commodore documentation says the AA+ CMOS chips were "full custom CMOS designs" so if they used HDL, they did not use any auto layout. In contrast, the 68060 "semicustom design methodology" where "synthesized logic comprised 35% of the die area" was used. We did not see anymore upgrades of Lorraine wire wrapped prototypes or 68030 prototypes using 18 boards of TTL after 1987. Maybe the Ranger chipset had prototypes that disappeared or maybe it did not get that far. Many of the original development files are likely sitting in storage somewhere even though they may not be in Verilog in the case of some chipsets, potentially making it easier to use MiSTer cores to develop ASICs. The 68k and ColdFire designs did use Verilog, FPGAs, synthesizable designs and fully static CMOS designs starting with the 68040. Motorola also went back and further developed some earlier cores like the originally NMOS 68000 and developed a CMOS synthesizable fully static 68000 core design, likely in Verilog too. These are valuable features today and it makes it more likely that the cores would be in good shape for FPGA and ASIC use. A lot of professionally designed cores with man years of development are wasting away unused despite likely still being amazing. Architects today would likely have trouble developing new cores today as efficiently and with the constraints they had much like OSs today have trouble keeping memory requirements to under 1GiB when OSs back then used less than 1MiB.

Last edited by matthey on 01-May-2026 at 01:19 AM.

Quote:

matthey wrote: I found pictures of a 68030 prototype which was the last 68k design before what I interpret as partially switching to Verilog and FPGAs for the 68040 and fully for the 68060. 68030 prototype at 1 MHz - 18 boards of TTL https://retrocomputingforum.com/t/68030-prototype-at-1-mhz-18-boards-of-ttl/1387 The pic on this page is unfortunately the emulator. The actual pics are the *NEW.jpg pics at the following link. https://drive.google.com/drive/folders/1w8kaX8qUO7b6cg6HBuXaQ6iqt2IPeahf There are 18 TTL boards so quite large but it looks like Joe Pillow may have been more complex to create due to more wire wrapping. https://www.floodgap.com/retrobits/ckb/secret/lorraine.html It is entirely possible that chipset designs were commonly still using gate level schematics in software with manual/custom place and routing instead of using Verilog in the early 1990s. Commodore documentation says the AA+ CMOS chips were "full custom CMOS designs" so if they used HDL, they did not use any auto layout. In contrast, the 68060 "semicustom design methodology" where "synthesized logic comprised 35% of the die area" was used. We did not see anymore upgrades of Lorraine wire wrapped prototypes or 68030 prototypes using 18 boards of TTL after 1987. Maybe the Ranger chipset had prototypes that disappeared or maybe it did not get that far. Many of the original development files are likely sitting in storage somewhere even though they may not be in Verilog in the case of some chipsets, potentially making it easier to use MiSTer cores to develop ASICs. The 68k and ColdFire designs did use Verilog, FPGAs, synthesizable designs and fully static CMOS designs starting with the 68040. Motorola also went back and further developed some earlier cores like the originally NMOS 68000 and developed a CMOS synthesizable fully static 68000 core design, likely in Verilog too. These are valuable features today and it makes it more likely that the cores would be in good shape for FPGA and ASIC use. A lot of professionally designed cores with man years of development are wasting away unused despite likely still being amazing. Architects today would likely have trouble developing new cores today as efficiently and with the constraints they had much like OSs today have trouble keeping memory requirements to under 1GiB when OSs back then used less than 1MiB.

You are mixing a few real historical facts with a lot of speculation and some outright misconceptions about how CPU and chipset design actually evolved in the late ’80s and early ’90s. I’ll be blunt: the conclusions you’re drawing don’t follow from the evidence you’re citing.


1) The “18 boards of TTL = how the 68030 was designed� claim is misleading

Yes, early prototypes of complex CPUs (including the Motorola 68030) were sometimes implemented as multi-board TTL or gate-array systems. That was standard practice for functional validation, not for design methodology.

These rigs were logic simulators in hardware, not the source design itself.
They existed because software simulation was too slow at the time.
Similar approaches were used at IBM, DEC, and others well into the late ’80s.


So pointing to a 1 MHz TTL prototype and implying that it reflects how the chip was designed (schematics vs HDL) is simply wrong. It reflects how it was verified, not how it was specified.


2) Your HDL timeline is off

You suggest a transition like:

68030 → “schematics/manual layout�
68040 → “partially Verilog/FPGAs�
68060 → “fully HDL-based�

That’s not how it happened.

Hardware description languages like Verilog and VHDL were already in use in the mid-to-late 1980s.
The Motorola 68040 was not “partially FPGA/Verilog designed�. FPGAs were nowhere near capable of hosting anything like that design at the time.

The Motorola 68060 did use more synthesis, but even then, “35% synthesized logic� explicitly means most of the chip was still custom-designed, not HDL-generated.

So the idea of a clean break between “manual� and “HDL/FPGAs� across these chips is an oversimplification bordering on fiction.


3) “Full custom CMOS� vs HDL — you’re conflating abstraction levels

You quote Commodore documentation about “full custom CMOS designs� and conclude that:
If they used HDL, they did not use any auto layout

That’s a misunderstanding.

“Full custom� refers to physical design style (transistor-level layout), not whether HDL was used.
You can absolutely use HDL at higher levels and still implement critical blocks as full custom.

Even today, high-performance CPUs mix:
synthesized standard cells
custom datapaths
hand-tuned analog blocks

So “full custom� ≠ “no HDL.� It just means manual layout where it matters.


4) The FPGA angle is anachronistic

You repeatedly connect early ’90s design flows to FPGAs and modern cores (e.g., MiSTer). That’s historically off:

Early FPGAs (late ’80s, early ’90s) were tiny and used mainly for glue logic.
No one was prototyping something like a 68040 in FPGA in that era.
FPGA-based CPU prototyping only became practical much later (mid–late ’90s onward).

So tying 68040/060 development to FPGA workflows is projecting modern practices backward.


5) “Old cores are just sitting around ready for ASIC reuse� — extremely optimistic

This is probably the biggest leap in your post.
Even if old cores exist internally:
They are tied to obsolete process nodes and libraries.

They depend on toolchains that no longer exist.
They often include non-portable custom layout and analog assumptions.
Legal/IP constraints alone would block reuse in most cases.

Porting a 68060-class core to a modern node is not “reuse�—it’s a major redesign effort.


6) The “modern engineers couldn’t do this� argument is weak

“Architects today would likely have trouble developing new cores as efficiently…�
This is nostalgia bias.
Constraints were different, not “harder.�

Today’s CPUs are orders of magnitude more complex.
Efficiency per engineer has increased massively due to tooling.

Comparing a 1 M transistor design to modern multi-billion transistor CPUs and concluding engineers got worse is not a serious argument.



7) OS memory comparison is irrelevant

Bringing in:
“OSs today struggle to stay under 1 GiB vs 1 MiB back then�
…has nothing to do with CPU design methodology. It’s a classic apples-to-oranges comparison driven by:

vastly different feature sets
security models
hardware expectations

It doesn’t support your core claim.



You’ve gathered interesting historical artifacts (the TTL prototype is genuinely cool), but then:
you infer design methodology from validation hardware
you misplace the timeline of HDL adoption
you project modern FPGA workflows backward
and you overestimate the reusability of legacy cores


The result is an appealing narrative, but not an accurate one.

If you want to make a solid argument, you need primary sources on actual design flows, not just photos of prototype rigs and scattered documentation quotes.

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

@MEGA_RJ_MICAL

A good analysis, did you write everything yourself or have you accepted help from AI?

ps.:
Used an AI checker .... No AI!

pps.:
Used ChatGPT for an answer to matthey, got this:

The main issue with your argument is that it mixes a few real historical facts with conclusions that don’t actually follow from them.

1. TTL prototype boards ≠ final design methodology
Seeing large multi-board TTL prototypes (like for the 68030) doesn’t mean the chip itself was designed without HDL or modern logic tools. In the 1980s, it was common to validate logic using wire-wrapped or TTL-based prototypes in parallel with IC design. These were debug/validation platforms, not a reflection of how the silicon layout was ultimately created.

2. “Full custom CMOS� does not mean “no HDL�
When documentation says chips were full custom CMOS, that refers to layout methodology, not necessarily the absence of hardware description languages. Designers could still use higher-level tools or schematic capture and then manually optimize layout.
So the assumption “no Verilog → no automation� is too simplistic. The industry was already transitioning through multiple abstraction levels at that time.

3. Verilog adoption timeline is being oversimplified
Verilog existed in the 1980s but was not widely adopted for full-chip CPU design until the 1990s. Even then, adoption was gradual and partial.
For example, the claim that the 68040 was already “partially switched to Verilog/FPGAs� is very unlikely—FPGAs of that era were far too limited for meaningful CPU prototyping at that scale. The 68040 was still largely designed using custom and semi-custom methodologies, not modern RTL synthesis flows as we understand them today.

4. “35% synthesized logic� doesn’t imply modern design flow dominance
For the 68060, saying 35% of the die was synthesized actually highlights that most of the chip was still not synthesized. That reinforces the opposite conclusion: designers were still heavily relying on manual or semi-custom techniques.

5. Missing prototypes ≠ evidence of different methods
The absence of surviving prototypes (e.g., Ranger chipset) isn’t evidence that they didn’t exist or that design methods changed—it’s just a gap in archival material. Hardware history is incomplete, especially for cancelled or internal projects.

6. Old cores being “easier� to reuse is speculative
Even if some later 68k-family cores were redesigned in synthesizable CMOS, that doesn’t mean:

the source still exists,
it’s in a usable HDL form,
or it’s compatible with modern FPGA/ASIC flows.

Porting old designs is often harder, not easier, due to missing tooling, undocumented assumptions, and outdated constraints.

7. The comparison to modern engineers/OS design is flawed
Comparing 1980s CPU engineers to modern software or hardware development ignores scale and complexity.
Modern systems:

target vastly more features,
operate under different constraints (security, parallelism, power),
and solve fundamentally harder problems.

It’s not that engineers today are less efficient—it’s that the problem space has expanded dramatically.

Bottom line:
You’re drawing strong conclusions from incomplete signals (prototype photos, partial documentation) and assuming a clean transition in design methodology that didn’t really exist. The reality is that the late ’80s to early ’90s was a messy hybrid period, where manual design, schematic capture, and early HDL-based synthesis all coexisted.

Last edited by OneTimer1 on 02-May-2026 at 04:24 PM.
Last edited by OneTimer1 on 02-May-2026 at 04:23 PM.
Last edited by OneTimer1 on 02-May-2026 at 04:22 PM.
Last edited by OneTimer1 on 02-May-2026 at 04:18 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: I've talked with Matthew at the Amiga 40 in Germany, and he promised to add another moderator and fix the problems with the site. Unfortunately, nothing changed after half a year, and the only way is to contact Steve (which isn't much active). The site is really abandoned to itself... The HypeA-EonKit syndicate leaders talk the talk but they do not walk the walk. They are good at lip service and hype but lie, cheat, steal, sabotage others and stab in the back. From everything I have seen, they are selfish bad actors acting in bad faith. The secret funding of criminal lawyers using lawfare to coerce business partners in duress at their most vulnerable time should result in an illegal bad faith contract but was just the start of these parasites digging in. The best hope around these parasites is only because Ben received some karma for his criminal behavior, even though far short of prison time, and Trevor may not be funding Hyperion enough to stay alive for his long dead AmigaNOne hobby where Amiga Corp is so close to taking any such funding in another lawsuit win.

Let's see what happens. To me it's still not clear the outcome of the last news / "agreements".

I would like to see The End put on this too long story, so that we can finally realize who and what can be done with Commodore IPs.
Quote:

cdimauro Quote: I've to say that I've seen a lot of interest around the A600GS when I was at the Amiga 40. Incredibly, there were some in the "corner" reserved for the largest die hard Amiga fans (which usually sport all kind of modded Amigas), and one of them said that it was a nice a comfortable to use. Maybe something is changing around retrogaming. People like to spend less time tinkering and just want to immediately use what they like. The HypeA-EonKit syndicate sabotaged the competition. They tried to keep RGL out of the Amiga market, reduced their competitiveness and caused uncertainty reducing Amiga market investments. The NeoGeo market, which is smaller than the Amiga market, gets faithful hardware recreations and the most accurate ASIC hardware while the Amiga market gets the worst accuracy emulation and no support for original storage media or I/O. Take away the competition, and sure, RPi like hardware is one of the cheapest ways to provide stand alone emulation of the Amiga. I previously suggested that it was cheap and easy to do but also mentioned anyone else could do the same and that it is the wrong way to go.

The main problem with ARM / not-Windows/x86-x64 emulation is that the used UAE version isn't so much accurate, because it uses an old WinUAE version port. Toni made, it's still doing, A LOT of improvement about emulation accuracy, optimized some common cases, and even offloaded part of the emulation code to another core / hardware thread.

RGL chose an ARM platform, like any other vendor of products like those, only because it's very cheap, working well with the selected software, and "good enough" with other that can be added. And required less effort -> cheap to produce.

The NeoGeo, despite being super-niche at the time when it was introduced, can aim at bigger numbers and much more earnings because of its legend as being THE top notch console of the early 90s. So, investing more on ASICs made sense (having the possibility to use part of the IPs / hardware emulation code).

Those are assessments that are needed when bringing a product to the market, because companies aren't missionaries and the primary (only?) scope is gaining money reducing as much as possible the risk for the investments.

The post-Amiga market hasn't this luxury anymore, unfortunately.
Quote:

The real beneficiary of this type of hardware is RPI which I expect outsells the A600GS for retro 68k Amiga use by at least 100:1 and perhaps more like 1000:1. Like THEA500 Mini, the A600GS relies on bundled software to provide value. There is also some value from convenience in an assembled ready to use product.

Exactly. The game to play on the Amiga land is the added value: if you give something more and palatable to the customers, then you are creating your niche where you can do some business.

And yes: users like Plug & Play (!) products, which is another important bonus.
Quote:

cdimauro Quote: But Amiga hadn't a unified memory system. We had two different types of memory, with fully independent buses. Not so much useful for the games of the time (I always preferred 1MB+ of Chip Mem), but that's the case. Amiga standards used a unified memory architecture. Fast memory was an option on high end systems and became somewhat important because Commodore failed to adequately upgrade the chip memory bandwidth and chip addressable memory. Ranger chipset SRAM as Jay wanted could have made the Amiga a true unified memory architecture but it was also possible with chipset upgrades using SDRAM interleaved memory accesses even though there is sometimes a performance advantage for accessing separate memory banks. Commodore certainly preferred the hardware simplification and cost reduction of a unified memory architecture over the performance advantage of adding fast memory. Let's compare the Amiga to NeoGeo with a discreet memory architecture like most console and computer architectures of the time, and the N64 using one of the early unified memory architectures. [...] The 68k Amiga more closely resembles a unified memory architecture even if some purists may not consider it so. It gains most of the advantages including reduced memory copying, more efficient use of memory capacity, easier to program, simpler and more scalable hardware, etc.

That's primarily good for consoles, but the Amiga wasn't only a game machine.

There were already discussions after my last post here, but the point is that Amiga remains isn't a unified architecture, and it was very good from this PoV.

As I've said before, having Amigas only with Chip Mem was ok and even recommended at the time, because (2D) games were the major selling point.

Fast Mem could have helped a few games, and specifically 3D games, but the system wasn't powerful enough anyway (especially due to the lack of packed/chunky pixels).

I had one of the first Amiga 2000, and I would have liked 1MB of Chip Mem. Unfortunately, it had 512kB of Chip Mem and 512kB of Slow Mem (the silliest thing even conceived by our beloved Commodore engineers). However, I had the chance to add a 2MB of Fast Mem a few months before that I had the opportunity to swap it with the new A1200.

BTW, Amiga was very similar to PCs. In fact, PCs had also the possibility to execute code on peripherals' memory connected to the ISA bus: it wasn't recommended (and it caused flickers on cheap/low-end graphic cards, for example) for obvious reasons, yet possible.

"This was/is the way" if we want general-purpose systems: system memory for the CPUs and dedicated memory for (some, at least) peripherals. And the Amiga has shown the potential of this model, which then become mainstream.
Quote:

cdimauro Quote: An Amiga ASIC requires 3 CPUs, IMO: a 68000 (FX68K), a 68020 (TG68), and speed demon 68k core. A FX68k/68000 core makes sense for max retro compatibility and can be used as a low power I/O core. I am not sure a TG68k/68020 core is necessary although it would improve compatibility, for example for A1200/CD32 compatibility.

That's exactly the point. And those 68000 and 68020 cores don't even take much space.
Quote:

cdimauro Quote: The Amiga chipset can be set in the stone and shouldn't take much for OCS/ECS, AGA, and RTG. The rest could be a small FPGA block which allows evolutions of the platform. The flexibility of FPGA support for chipsets is compelling and doesn't required too much FPGA space with hard CPU support of the more advanced CPUs.

But FPGAs are still expensive, so better to don't waste money here only for the chipset.
Quote:

cdimauro Quote: Likely. But even having the RTL would require a lot of work. If MiSTer has a very good soft core, then it might be worth using them. At then, Neo Geo hadn't many games, and having accurate soft cores just for them is certainly good enough for the purpose. Some RTL is better programmed and further prepared for an ASIC. RTL cores which have already been used for ASICs are further along in the testing and verification. Starting with a fully sythesizable core saves time. ColdFire chips used synthesized CPU cores and auto layout design tools for professional commodity chips. This reduced performance compared to using custom blocks but it was simpler and easier to move to new processes. MOTOROLA THAWS COLDFIRE V4 https://www.cecs.uci.edu/~papers/mpr/MPR/2000/20000515/142001.PDF Quote: The larger caches are the biggest reason that the die didn’t shrink dramatically. Another reason is starkly visible in Figure 2, the die photo. ColdFire is the only family of processors from Motorola that’s entirely synthesized from high-level models with automated design tools. There’s no custom circuit layout at all. Compiled chips are bigger, slower, and less power-efficient than full-custom designs, but they are much quicker and cheaper to create. Where a hand-packed design typically has neat blocks of function units inside a Piet Mondrian grid of buses, the 5407 has an amorphous mass of compiler-generated circuits on a Jackson Pollock canvas of silicon. The only semblance of order comes from the caches and on-chip memories around the periphery of the die. They’re compiled too, but SRAM arrays obediently fall into dense rows and columns, even without a guiding hand. Fortunately, the mess of logic circuitry isn’t as inefficient as it appears. Based on Motorola’s upper-range power consumption estimate of 700mW, the 5407 delivers a whopping 367 mips per watt, nearly four times better than the 5307’s 94.6 mips per watt. Beauty is in the eye of the beholder, but performance can be measured. ColdFire designs still delivered good CISC integer performance even with a castrated 68k ISA and full auto layout tools reducing core design work. cdimauro Quote: Yes, but it might be difficult to move them to modern RTL (VHDL, Verilog, SystemC, ...). Many of the old HDL core designs are in Verilog including 68k and ColdFire cores. Some of the buss standards are newer but even ColdFire uses AMBA busses developed by ARM and still in use today. Some file formats for ASIC like GDSII are still used today even though OASIS is now used for large ASICs. https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture https://en.wikipedia.org/wiki/GDSII https://wdc65xx.com/intellectual-property Early Amiga chipset, 68k CPU and 6502 family CPU designs used hand layout, but despite huge tech advances, some of the basic early tech is still used. The NeoGeo was released in the 1990s, approximately 5 years later than the Amiga chipset. The 68000 was released in 1979. The 68020 would have been too expensive for an Amiga console but not for a high end NeoGeo console considering all the expensive SRAM used. Some NeoGeo games experienced slow downs which is why there are over clocked NeoGeos and the NeoGeo AES+ supports over clocking. My point is, that the NeoGeo was late enough that it should have had regular HDL files, likely written in Verilog.

I've arrived late, after many discussions on this topic, so I'll not waste much time on that.

My point is: the Coldfire RTL might be very useful for having a starting point for further developing a more modern 68k.
However, it takes time and expertise to adapt it to modern processes. This is the most important point, and experts are required, obviously.
After that adding back the missing 68k instructions and extending it shouldn't be that much difficult (yet, an expert is needed).
Quote:

cdimauro Quote: Toni Wilen is making a great job at trying to accurately reproduce our splendid machines. If the code isn't hard to read, maybe it can be taken as the reference for implementing the chipset. Toni would be a valuable developer, or at least tester, if a 68k ASICs SoC was developed.

I don't think that he likes to be a tester, but there plenty of other Amigans that could easily do it, and for free.

Before I reply to cdimauro, I will answer kolla from the code density thread because it contains info/news about the NeoGeo AES+.

https://retrorgb.com/jotego-confirms-neo-geo-aes-features.html Quote:

Jotego confirmed that he and Furrtek were both part of the project and that it’s an ASIC spun off from the MiSTer FPGA core. The analogy he used was that this would be more like the Genesis 2 vs the Genesis 1 – The chips may be combined into one, but it’s still the same system. He also confirmed that the “A/V� output will support RGB and that he helped ensure the colors would look as accurate to the original as possible. Jotego also talked about the audio circuit and how it was also tailored to sound more like the original. And of course, Jotego confirmed this will be a lagless solution: The controller pins are wired directly to the ASIC, which processes the signal in real time just like the original Neo Geo, so from button press to movement from the analog video output should be identical to the original. No word on how much lag the HDMI output offers, or the resolutions it supports, but if it’s anything like the MiSTer core, it should prove to be very low latency as well. Jotego ended the interview by mentioning there’s another console on the way, but he can’t say any more than that.

There are 2 videos at the link with MiSTer developers who are helping to develop the NeoGeo AES+. I had seen the first video which was posted to EAB but was not motivated to update this thread because it was vandalized so badly by pitiful fools. The EAB thread I linked in the first post of this thread with the following comment from alexh.

alexh Quote:

Interesting video here from Jotego. It's in Spanish but you can turn on subtitles and translate to English (or whatever) it's not perfect when it comes to acronyms or technical stuff but usable. https://retrorgb.com/jotego-confirms-neo-geo-aes-features.html o The design is licensed from SNK. o It is a 2-chip solution. (Original was 8-chips) o The HDL design was a collaboration between himself and Furrtek, based on the MiSTer design. (No SNK technical input, the original engineers long gone and designs lost) o The RGB DAC circuit is the same as on the original so colours/brightness will look the same. o The audio interpolator in the JT10 core in MiSTer isn't in AES+ o The controller I/O is true GPIO and not USB as in MiSTer (I'm not sure it is accurate to say MiSTer I/O uses USB). o He likens the difference between original AES and AES+ to a "rev 2" or the differences between the Megadrive 1 and Megadrive 2 (I'm not that familiar with the differences there).

This suggests 2 ASICs where the previous https://retrorgb.com/jotego-confirms-neo-geo-aes-features.html suggests "the chips may be combined into one". The first video mentions FPGAs not having enough pins for the cartridge slot, or maybe not affordable enough ones anyway. The video is in Spanish and I may have lost something with Google auto translate. I expect a discrete memory architecture would require more pins than a unified memory architecture, which a modernized 68k Amiga could be with minimal performance loss. In other words, all the memory could be chip memory. With an ASIC, a modernized 68k Amiga could use dual ported integrated memory (one port for CPU and one for chipset) too like Jay Miner wanted for the Ranger chipset but I believe it is unnecessary and there are disadvantages. Interleaving memory accesses works just fine when there is adequate chip memory bandwidth. This is what Commodore planned but failed partially due to failing to increase the Amiga chipset bandwidth and chipset address space fast enough. The MiSTer/MiniMig core also interleaves accesses with different access ordering but the higher chipset clock rate provides more slots for CPU and chipset memory accesses much like AA+/AGA+ would have. The Lorraine Amiga prototypes had cartridge slots for what was originally planned to be a video game system, fortunately an expandable one due to Jay's foresight and desires. The video game crash of 1983 likely led to the hardware cost reduction of removing it and may have made it more difficult for Commodore to release a console before the CD based CD32. Today, supporting a cartridge slot is baggage. This may be true for CDs too but drives are still available that can play most CD formats where cartridge slots are not universal. Some retro gamers have large collections of CDs, resist the move to cloud only gaming without ownership of games, resist control of hardware and OSs by sellers, resist closed systems, etc.

kolla Quote:

So it uses Fx68k by Ijor https://github.com/MiSTer-devel/NeoGeo_MiSTer/tree/master/rtl/cpu Which is GPL3? https://github.com/MiSTer-devel/NeoGeo_MiSTer/blob/master/rtl/cpu/FX68K/fx68k.txt https://github.com/ijor/fx68k/blob/master/LICENSE Well, I hope all "legalities" have been sorted out already, and if not... more popcorn. EDIT: I contacted Ijor, and he's wasn't aware that the Neo Geo AES+ project is on, he thought it had died years ago. He's got no problem with people "baking" his 68000 softcore into ASIC, his view is that once you turn it into ASIC, the software license doesn't apply anyways.

It is unfortunate that Ijor was not informed about the use of the FX68k cycle exact 68000 core by the NeoGeo AES+ developers. I would have thought he would have valuable input for turning the core into an ASIC too. It is all likely legal and ljor is cool with it but it could have been handled more professionally.

kolla Quote:

So I'll cancel the popcorn for now.... and, eh... Minimig+Fx68k in ASIC anyone?

While it may be possible to clock up an ASIC somewhat from a relatively cheap FPGA to ASIC conversion, so much more performance, value and compatibility, in the case of the Amiga, X68000, Atari ST, 68k Mac, etc. is possible with fully pipelined 68020+ cores with caches in a more expensive 68k ASIC SoC with better design. Retaining a cycle exact 68000 core for old software compatibility, 68000 console compatibility and low power I/O would be very cheap though. It should be possible to retain good 68k retro compatibility and move forward with hardware that is appealing for general purpose, hobby, embedded and educational use, at the same time. As Jotego said in the 2nd video of the developer link you posted, "so yes and I think patrons in general have shared that, that I think that they like, they want to see the new stuff but they also like to see that the old stuff is not abandoned". He gets it where many retro businesses and people do not, including many current micro niche NG Amiga supporters who sabotage giving the retro masses what they want.

cdimauro Quote:

The NeoGeo, despite being super-niche at the time when it was introduced, can aim at bigger numbers and much more earnings because of its legend as being THE top notch console of the early 90s. So, investing more on ASICs made sense (having the possibility to use part of the IPs / hardware emulation code).

I expect there will be new buyers that have never owned a NeoGeo before based on the NeoGeo being the king of consoles and similar hardware being used in arcade cabinets. However, the NeoGeo AES+ misses the mark somewhat due to the games using expensive cartridges. MiSTer hardware provides more value for most retro fans and all but the most hardcore NeoGeo fans.

cdimauro Quote:

Those are assessments that are needed when bringing a product to the market, because companies aren't missionaries and the primary (only?) scope is gaining money reducing as much as possible the risk for the investments. The post-Amiga market hasn't this luxury anymore, unfortunately.

Risk is relative to the reward. I still think the Amiga has the 2nd most valuable 68k gaming market behind the Sega Genesis/Megadrive although there would be less risk in universal hardware for multiple 68k gaming markets. Lets not forget the tiny X68000 market with less than 200k original units sold in Japan only yet crowd funding of at least $2.7 million USD and perhaps as much as $24 million USD was given for a nostalgic facade with ARM inside.

https://www.indiegogo.com/en/projects/zuikiinc/x68000-z-super-xvi-japan-s-retro-pc-reborn#/section/project-story
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45483&forum=25&19

The tiny X68000 market could support an ASIC but not the 25+ times larger 68k Amiga market? Is there still a market for better and more faithful X68000 hardware large enough for an ASIC, especially considering much of the system was made public domain and the X68000 supports a 68060?

1984 SinclairQL ~150,000 units sold (first mass market preemptive multitasking computer)
1984 68kMac ? millions of units sold (overpriced Apple computers with some good software)
1985 68kAtari 3,000,000+ units sold (Jack's hackintosh Amiga wannabe)
1985 Amiga 4,900,000+ units sold (the king of computer gaming, designed for the masses)
1987 X68000 ~200,000 units sold (the king of computer gaming in Japan)
1988 Genesis 35,000,000+ units sold (good value console for the masses)
1990 NeoGeo ~2,000,000 AES+MVS units sold (king of consoles but late for 68000 main CPU)

The 68k Amiga was legendary also and more people world wide know about it than the NeoGeo and the X68000 combined. All 68k systems above but the NeoGeo and Genesis consoles support a 68060 and expanded memory, potentially providing much more value. A CD32 with a 68060@100MHz and fast memory would outperform the NeoGeo AES+ in many ways. A CD32+ with 68060+@1+GHz, chipset bottlenecks removed and modern memory would obliterate it. It would be like comparing a Pentium III system to a 386 system.

cdimauro Quote:

But FPGAs are still expensive, so better to don't waste money here only for the chipset.

The FPGA Ohme was $45 USD and the FPGA cost less than half of that.

https://www.indiegogo.com/en/projects/valentinangelovski/fleafpga-ohm-fpga-experimenter-board#/section/project-story

The FPGA needed to be a little larger for 68k Amiga support but it would be fine for only Amiga chipset support. Other 68k systems may need more space for just the chipset though. There are FPGAs with built in flash for the FPGA saving space and eFPGA blocks on an ASIC could eliminate the separate FPGA chip. It would be nice to have a hard Amiga chipset on an ASIC so it could be used for system management but FPGA chipset capabilities would allow simulation instead of emulation of retro systems.

cdimauro Quote:

I've arrived late, after many discussions on this topic, so I'll not waste much time on that. My point is: the Coldfire RTL might be very useful for having a starting point for further developing a more modern 68k. However, it takes time and expertise to adapt it to modern processes. This is the most important point, and experts are required, obviously. After that adding back the missing 68k instructions and extending it shouldn't be that much difficult (yet, an expert is needed).

I expect it would be easier to start with the 68060 core and use the similar but more modern ColdFire V5 core to quickly upgrade the 68060. I suspect the whole 68060 core is written in Verilog and is synthesizable even though only 35% of the 68060 logic was synthesized. The other blocks were all custom which was likely necessary then, where today, there are better auto layout tools and smaller process sizes allowing a larger percentage of the core to use auto layout. There are standard blocks available today for, for example, SRAM, which ColdFire cores synthesize and use auto layout along with ROMs. Even with block customization, SRAM is copy and paste of large parts of the die.

68060 2,530,000 transistors/devices total
~35% ~885,500 transistors synthesized (actual by area instead of transistors)
~16% ~393,216 6T 8kiB ICache raw (up to ~74k more transistors for tags & management bits)
~16% ~393,216 6T 8kiB DCache raw (up to ~74k more transistors for tags & management bits)
---
~67% sythesized (auto layout) and copy & paste SRAM I+D caches (standard blocks or auto layout for CF)

There are various other smaller SRAM caches and ROMs as well. I expect some of the tools/software and systems used are no longer easily available and buses predate the 1996 AMBA standard which was later used by CF but this would not be a deal breaker if all the Verilog source code was available and sythesizable. The 68060 is the 68k retro performance standard, it was "MC" qualified meeting a high quality Motorola standard with no known bugs and it has many low power features which make it more competitive with in-order cores.

P.S. Do not listen to AI lies and nit picking. I am no expert in this area but still smarter than AI. An old employee from Motorola who could act as a consultant like Mitch Alsup or other guys from 68k development could enlighten us further if serious about modern 68k development.

Last edited by matthey on 05-May-2026 at 05:37 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: The NeoGeo, despite being super-niche at the time when it was introduced, can aim at bigger numbers and much more earnings because of its legend as being THE top notch console of the early 90s. So, investing more on ASICs made sense (having the possibility to use part of the IPs / hardware emulation code). I expect there will be new buyers that have never owned a NeoGeo before based on the NeoGeo being the king of consoles and similar hardware being used in arcade cabinets. However, the NeoGeo AES+ misses the mark somewhat due to the games using expensive cartridges.

Yes, but they aren't so much expensive like the original ones (that costed like the entire console): now you can buy them at roughly the same price of an AAA game.
Quote:

MiSTer hardware provides more value for most retro fans and all but the most hardcore NeoGeo fans.

But it hasn't the official license.
Quote:

cdimauro Quote: Those are assessments that are needed when bringing a product to the market, because companies aren't missionaries and the primary (only?) scope is gaining money reducing as much as possible the risk for the investments. The post-Amiga market hasn't this luxury anymore, unfortunately. Risk is relative to the reward. I still think the Amiga has the 2nd most valuable 68k gaming market behind the Sega Genesis/Megadrive although there would be less risk in universal hardware for multiple 68k gaming markets. Lets not forget the tiny X68000 market with less than 200k original units sold in Japan only yet crowd funding of at least $2.7 million USD and perhaps as much as $24 million USD was given for a nostalgic facade with ARM inside. https://www.indiegogo.com/en/projects/zuikiinc/x68000-z-super-xvi-japan-s-retro-pc-reborn#/section/project-story https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45483&forum=25&19 The tiny X68000 market could support an ASIC but not the 25+ times larger 68k Amiga market? Is there still a market for better and more faithful X68000 hardware large enough for an ASIC, especially considering much of the system was made public domain and the X68000 supports a 68060?

X68000 is like the NeoGeo: it was the computer of our dreams, due to its superlative specs. So, it applies the same here.
Quote:

1984 SinclairQL ~150,000 units sold (first mass market preemptive multitasking computer)

Not appealing.
Quote:

1984 68kMac ? millions of units sold (overpriced Apple computers with some good software)

Macs are still alive -> not appealing.
Quote:

1985 68kAtari 3,000,000+ units sold (Jack's hackintosh Amiga wannabe)

It might be interesting, but I don't know which value could have a revival to justify investments.
Quote:

1985 Amiga 4,900,000+ units sold (the king of computer gaming, designed for the masses)

Still "alive" in some ways, but there were already products (some with official licenses) and a few more coming.

So, the market already absorbed the demand. I don't believe that, after the release of the coming products, there could be enough demand for other retro-machines.

To be more clear, a new product should bring an "added value" which is significant for customers.
Quote:

1987 X68000 ~200,000 units sold (the king of computer gaming in Japan)

The dream...
Quote:

1988 Genesis 35,000,000+ units sold (good value console for the masses)

SEGA already monetized.
Quote:

1990 NeoGeo ~2,000,000 AES+MVS units sold (king of consoles but late for 68000 main CPU)

The dream...
Quote:

The 68k Amiga was legendary also and more people world wide know about it than the NeoGeo and the X68000 combined. All 68k systems above but the NeoGeo and Genesis consoles support a 68060 and expanded memory, potentially providing much more value. A CD32 with a 68060@100MHz and fast memory would outperform the NeoGeo AES+ in many ways. A CD32+ with 68060+@1+GHz, chipset bottlenecks removed and modern memory would obliterate it. It would be like comparing a Pentium III system to a 386 system.

The thing isn't about outperform / obliterating.

The above consoles have appealing because they allow to play the good, old games which many people lucked. Once they achieve this, the mission is accomplished. And there's no need to something more.

For the Amiga (and Atari ST) the situation is similar: people are more oriented to play their old games. Once you, as customer, have it... then the game is over.

To sell such CD32+ you should provide an added value for which consumers are willing to pay. 1Ghz+ isn't an added value, unless you can bring them a concrete and palatable stuff under their hands which requires it.

I hope that the message is clear: the market needs a product which features to justify buying it, and actually I don't see it.
Quote:

cdimauro Quote: But FPGAs are still expensive, so better to don't waste money here only for the chipset. The FPGA Ohme was $45 USD and the FPGA cost less than half of that. https://www.indiegogo.com/en/projects/valentinangelovski/fleafpga-ohm-fpga-experimenter-board#/section/project-story The FPGA needed to be a little larger for 68k Amiga support but it would be fine for only Amiga chipset support. Other 68k systems may need more space for just the chipset though. There are FPGAs with built in flash for the FPGA saving space and eFPGA blocks on an ASIC could eliminate the separate FPGA chip. It would be nice to have a hard Amiga chipset on an ASIC so it could be used for system management but FPGA chipset capabilities would allow simulation instead of emulation of retro systems.

$20-30 for an FPGA section should be enough for the purpose.
Quote:

cdimauro Quote: I've arrived late, after many discussions on this topic, so I'll not waste much time on that. My point is: the Coldfire RTL might be very useful for having a starting point for further developing a more modern 68k. However, it takes time and expertise to adapt it to modern processes. This is the most important point, and experts are required, obviously. After that adding back the missing 68k instructions and extending it shouldn't be that much difficult (yet, an expert is needed). I expect it would be easier to start with the 68060 core and use the similar but more modern ColdFire V5 core to quickly upgrade the 68060. I suspect the whole 68060 core is written in Verilog and is synthesizable even though only 35% of the 68060 logic was synthesized. The other blocks were all custom which was likely necessary then, where today, there are better auto layout tools and smaller process sizes allowing a larger percentage of the core to use auto layout. There are standard blocks available today for, for example, SRAM, which ColdFire cores synthesize and use auto layout along with ROMs. Even with block customization, SRAM is copy and paste of large parts of the die. 68060 2,530,000 transistors/devices total ~35% ~885,500 transistors synthesized (actual by area instead of transistors) ~16% ~393,216 6T 8kiB ICache raw (up to ~74k more transistors for tags & management bits) ~16% ~393,216 6T 8kiB DCache raw (up to ~74k more transistors for tags & management bits) --- ~67% sythesized (auto layout) and copy & paste SRAM I+D caches (standard blocks or auto layout for CF) There are various other smaller SRAM caches and ROMs as well. I expect some of the tools/software and systems used are no longer easily available and buses predate the 1996 AMBA standard which was later used by CF but this would not be a deal breaker if all the Verilog source code was available and sythesizable. The 68060 is the 68k retro performance standard, it was "MC" qualified meeting a high quality Motorola standard with no known bugs and it has many low power features which make it more competitive with in-order cores.

Honestly, I don't see value on starting from the 68060: it's too much custom (and we don't even know if the RTL is still available).

The Coldfire V5 is only realistic option, and it's a very good base from where start.
Quote:

P.S. Do not listen to AI lies and nit picking. I am no expert in this area but still smarter than AI.

I'm using the so called "AI" (SIC!) at work: they are very powerful once you know their limits and you're checking their results

They could definitely help on such tasks. But they need a good, expert engineer which is the real value.

They are multipliers: multiply the throughput of the engineer. But if the multiplier is low, the result will be low...
Quote:

An old employee from Motorola who could act as a consultant like Mitch Alsup or other guys from 68k development could enlighten us further if serious about modern 68k development.

Difficult to get. They are old, likely retired.

I see only Mitch busy with his project. But he's busy, as said, and I don't know who else could help here for fun.

cdimauro Quote:

matthey Quote: 1984 SinclairQL ~150,000 units sold (first mass market preemptive multitasking computer) Not appealing.

I agree that the Sinclair QL has limited appeal but it was far from insignificant.

1. first mass market preemptive multitasking computer (already mentioned)
2. inspired Linus Torvald to develop also preemptive multitasking Linux
3. early and cheap 68008 computer became learning platform for later 68k UK developers
4. small market still has 68060 hardware and QDOS rewrite SMSQ/E support

The market may have been small with ~150,000 units sold and the Sinclair QL was considered a commercial failure but it is maybe 30 times larger than the PPC Amiga NG market of ~5000 units sold. Failure is relative.

cdimauro Quote:

matthey Quote: 1984 68kMac ? millions of units sold (overpriced Apple computers with some good software) Macs are still alive -> not appealing.

The large and successful Apple market means there are larger than usual retro and collector markets. Granted, the Apple I & II were more popular than the 68k Mac. Some of it comes down to early 68k Macs not being very usable and builtin CRTs are not very practical today. However, later 68k Macs improved enough to be a competitor to the Amiga and in many ways were more professional with more and often better software. The later standard spec of a 68040 and chunky meant they had some games and game types that lower spec 68020+AGA Amigas could not handle (Marathon series, Warcraft II, Star Wars: Dark Forces, etc.) The 68k Mac OS look, feel and support on later 68k hardware is more modern like the 68k Amiga and AmigaOS can be.

cdimauro Quote:

matthey Quote: 1985 68kAtari 3,000,000+ units sold (Jack's hackintosh Amiga wannabe) It might be interesting, but I don't know which value could have a revival to justify investments.

The 68k Atari was overshadowed by the Amiga which usually received better ports of the same games. There are dedicated fans and many are 68k fans like with the Amiga. I expect many feel abandoned by what Atari has to offer so far. The minimal hardware of the early models makes them relatively easy to support but CPU timing loops were more common than on the Amiga.

cdimauro Quote:

matthey Quote: 1985 Amiga 4,900,000+ units sold (the king of computer gaming, designed for the masses) Still "alive" in some ways, but there were already products (some with official licenses) and a few more coming. So, the market already absorbed the demand. I don't believe that, after the release of the coming products, there could be enough demand for other retro-machines. To be more clear, a new product should bring an "added value" which is significant for customers.

I expect the market for crap Amiga hardware and low end Amiga hardware is saturated. Most of the stand alone hardware is not Amiga hardware and not as good as WinUAE on a PC. It should be possible to have better compatibility with more accurate timing and competitive performance in very low cost stand alone hardware.

cdimauro Quote:

matthey Quote: 1987 X68000 ~200,000 units sold (the king of computer gaming in Japan) The dream...

Dream hardware but not dream OS. The standard Human68k OS is like MS-DOS. It is command line with no multitasking. There is a GUI called SX-Window which is kind of like Windows 3.1 running on top of MS-DOS but looks more like NeXTSTEP. It did not come in early models, did not support preemptive multitasking, did not support hardware acceleration, it is described on Wiki as difficult to program and it did not have much software. Human68k is fine for launching games and other OSs are supported including OS-9 and NetBSD but may require at least a 68030 for MMU. What the Amiga lacked in hardware, it made up for in OS and software volume with a much larger market.

cdimauro Quote:

matthey Quote: 1988 Genesis 35,000,000+ units sold (good value console for the masses) SEGA already monetized.

The Genesis/MegaDrive market has been monetized with 2 Minis that were not bad for emulation. The hardware could have been better and was limited to whatever games were built in which was 42 for 1st Mini and 60 for the 2nd Mini but still limiting. Better quality and cheaper hardware could be used for this market.

cdimauro Quote:

matthey Quote: 1990 NeoGeo ~2,000,000 AES+MVS units sold (king of consoles but late for 68000 main CPU) The dream...

The 68k Amiga may be a better general purpose computer than the X68000 and the X68000 may be a better gaming system than the NeoGeo. The NeoGeo has the arcade games on arcade like hardware though.

cdimauro Quote:

The thing isn't about outperform / obliterating. The above consoles have appealing because they allow to play the good, old games which many people lucked. Once they achieve this, the mission is accomplished. And there's no need to something more. For the Amiga (and Atari ST) the situation is similar: people are more oriented to play their old games. Once you, as customer, have it... then the game is over. To sell such CD32+ you should provide an added value for which consumers are willing to pay. 1Ghz+ isn't an added value, unless you can bring them a concrete and palatable stuff under their hands which requires it. I hope that the message is clear: the market needs a product which features to justify buying it, and actually I don't see it.

There are ports of many older CPU intensive, mostly FPS games already for a 68060 Amiga and many more available with more performance. This allows an expanded game selection.

1. original games work with compatibility
2. enhanced original games work due to improved features and performance
3. old game ports which were too slow on the Amiga work with more performance and features
4. with improved hardware value and a larger market, new games should appear

ARM Linux should be able to do #3 and #4 too but lack of standardization often requires compiling programs before use where Aminet has a large selection of ready to run Amiga software. Most ARM Linux hardware has a much larger memory and storage footprint too. RPi hardware is the right idea with more standardization and a reduced ARM/Linux footprint but 68k/Amiga hardware can do better and we have #1 and already some of #2 above. The RPi market is not saturated but is sustainable and growing with over 65 million units sold as of March 2025.

cdimauro Quote:

Honestly, I don't see value on starting from the 68060: it's too much custom (and we don't even know if the RTL is still available). The Coldfire V5 is only realistic option, and it's a very good base from where start.

I expect the CF V5 would be easier to work with because it is newer but would require major changes to make it compatible with the 68060 again and major changes require more verification and testing. Ideally, it would be best to have both the 68060 and CF V5 Verilog available as known working and similar modules could be mixed and matched as needed. Where CF modules are used, the 68060 modules would likely be invaluable for ensuring compatibility. Where 68060 modules are used, CF V5 modules could be examined for improvements and enhancements. With Verilog, there should be comments and maybe change logs which would be helpful too. Of course this is a lot of speculation but whatever is left of all the 68k cores should be preserved. Retro chipsets in whatever development form they are in should also be preserved before they are lost.

@matthey

Quote:

matthey wrote: cdimauro Quote: Not appealing. I agree that the Sinclair QL has limited appeal but it was far from insignificant. 1. first mass market preemptive multitasking computer (already mentioned) 2. inspired Linus Torvald to develop also preemptive multitasking Linux 3. early and cheap 68008 computer became learning platform for later 68k UK developers 4. small market still has 68060 hardware and QDOS rewrite SMSQ/E support The market may have been small with ~150,000 units sold and the Sinclair QL was considered a commercial failure but it is maybe 30 times larger than the PPC Amiga NG market of ~5000 units sold. Failure is relative.

Which software was developed for the QL that still deserves to be enjoyed by fans? How many people could by a "Mini QL" for that?

Those are the only questions that are relevant when you want to bring a product like that to the market.

I still don't see anything appealing here.
Quote:

cdimauro Quote: Macs are still alive -> not appealing. The large and successful Apple market means there are larger than usual retro and collector markets. Granted, the Apple I & II were more popular than the 68k Mac. Some of it comes down to early 68k Macs not being very usable and builtin CRTs are not very practical today. However, later 68k Macs improved enough to be a competitor to the Amiga and in many ways were more professional with more and often better software. The later standard spec of a 68040 and chunky meant they had some games and game types that lower spec 68020+AGA Amigas could not handle (Marathon series, Warcraft II, Star Wars: Dark Forces, etc.) The 68k Mac OS look, feel and support on later 68k hardware is more modern like the 68k Amiga and AmigaOS can be.

But how many Mac fans would by a Mini Mac for running that old software?

People which are used to buy the latest and greatest software for their current, well alive, platform. How much of them could be interested on a "revival"?
Quote:

cdimauro Quote: It might be interesting, but I don't know which value could have a revival to justify investments. The 68k Atari was overshadowed by the Amiga which usually received better ports of the same games. There are dedicated fans and many are 68k fans like with the Amiga. I expect many feel abandoned by what Atari has to offer so far. The minimal hardware of the early models makes them relatively easy to support but CPU timing loops were more common than on the Amiga.

Indeed. The only Atari fans which were interesting on a revival are the ones around a EmuTOS or something like that, but that's a niche, and they have already found the solution on PiStorm and Apollo Core.
Quote:

cdimauro Quote: Still "alive" in some ways, but there were already products (some with official licenses) and a few more coming. So, the market already absorbed the demand. I don't believe that, after the release of the coming products, there could be enough demand for other retro-machines. To be more clear, a new product should bring an "added value" which is significant for customers. I expect the market for crap Amiga hardware and low end Amiga hardware is saturated. Most of the stand alone hardware is not Amiga hardware and not as good as WinUAE on a PC. It should be possible to have better compatibility with more accurate timing and competitive performance in very low cost stand alone hardware.

It's difficult to obtain better compatibility without the original schematics.

But the main question is: for running what? Most of the badly written games were patched with projects like WHDLoad, Jodt, and they can already be used with the existing Mini/whatever solutions that are on the market (or that will come soon).
Quote:

cdimauro Quote: The dream... Dream hardware but not dream OS. The standard Human68k OS is like MS-DOS. It is command line with no multitasking. There is a GUI called SX-Window which is kind of like Windows 3.1 running on top of MS-DOS but looks more like NeXTSTEP. It did not come in early models, did not support preemptive multitasking, did not support hardware acceleration, it is described on Wiki as difficult to program and it did not have much software. Human68k is fine for launching games and other OSs are supported including OS-9 and NetBSD but may require at least a 68030 for MMU. What the Amiga lacked in hardware, it made up for in OS and software volume with a much larger market.

Right, but how many people are interested at the X68000 just for running the OS? I don't think many.

As usual, the main purpose (the only one, for the vast majority) is running its games...
Quote:

cdimauro Quote: SEGA already monetized. The Genesis/MegaDrive market has been monetized with 2 Minis that were not bad for emulation. The hardware could have been better and was limited to whatever games were built in which was 42 for 1st Mini and 60 for the 2nd Mini but still limiting. Better quality and cheaper hardware could be used for this market.

Do you believe that there's still a market here?
Quote:

cdimauro Quote: The dream... The 68k Amiga may be a better general purpose computer than the X68000 and the X68000 may be a better gaming system than the NeoGeo. The NeoGeo has the arcade games on arcade like hardware though.

Which is absolutely fine, since it's the only reason for buying a "remake".
Quote:

cdimauro Quote: The thing isn't about outperform / obliterating. The above consoles have appealing because they allow to play the good, old games which many people lucked. Once they achieve this, the mission is accomplished. And there's no need to something more. For the Amiga (and Atari ST) the situation is similar: people are more oriented to play their old games. Once you, as customer, have it... then the game is over. To sell such CD32+ you should provide an added value for which consumers are willing to pay. 1Ghz+ isn't an added value, unless you can bring them a concrete and palatable stuff under their hands which requires it. I hope that the message is clear: the market needs a product which features to justify buying it, and actually I don't see it. There are ports of many older CPU intensive, mostly FPS games already for a 68060 Amiga and many more available with more performance. This allows an expanded game selection. 1. original games work with compatibility 2. enhanced original games work due to improved features and performance 3. old game ports which were too slow on the Amiga work with more performance and features 4. with improved hardware value and a larger market, new games should appear ARM Linux should be able to do #3 and #4 too but lack of standardization often requires compiling programs before use where Aminet has a large selection of ready to run Amiga software. Most ARM Linux hardware has a much larger memory and storage footprint too. RPi hardware is the right idea with more standardization and a reduced ARM/Linux footprint but 68k/Amiga hardware can do better and we have #1 and already some of #2 above. The RPi market is not saturated but is sustainable and growing with over 65 million units sold as of March 2025.

How many games we have that require much better performance, and that the current ARM-based "Minins" can't handle (e.g.: more CPU power is required)?
Quote:

cdimauro Quote: Honestly, I don't see value on starting from the 68060: it's too much custom (and we don't even know if the RTL is still available). The Coldfire V5 is only realistic option, and it's a very good base from where start. I expect the CF V5 would be easier to work with because it is newer but would require major changes to make it compatible with the 68060 again and major changes require more verification and testing. Ideally, it would be best to have both the 68060 and CF V5 Verilog available as known working and similar modules could be mixed and matched as needed. Where CF modules are used, the 68060 modules would likely be invaluable for ensuring compatibility. Where 68060 modules are used, CF V5 modules could be examined for improvements and enhancements. With Verilog, there should be comments and maybe change logs which would be helpful too. Of course this is a lot of speculation but whatever is left of all the 68k cores should be preserved. Retro chipsets in whatever development form they are in should also be preserved before they are lost.

Well, if something is still available then it can certainly be used (even if only as a reference).

cdimauro Quote:

Which software was developed for the QL that still deserves to be enjoyed by fans? How many people could by a "Mini QL" for that? Those are the only questions that are relevant when you want to bring a product like that to the market. I still don't see anything appealing here.

Part of the appeal of the Sinclair QL was the software it came with which was known for being advanced and easy to use. The QDOS OS used preemptive multitasking, SuperBASIC was one of the most advanced languages in ROM at the time and the included office suite word processor, spreadsheet, database, and business graphics software written by Psion were well liked. It was an innovative and advanced system for the time that was let down by rushed hardware problems and early Microdrive issues which were later corrected by Samsung. I believe many Sinclair fans and ZX Spectrum owners saw it as the next gen Sinclair computer but many did not buy it or experience it because of the problems and bad reputation. It may have been the first of a line of more powerful Sinclair 68k computers if it was more mature at launch. It was a good enough system to inspire users to create 3rd party software and hardware upgrades despite the limited and problematic hardware.

There were some games created for it that are at least on par with better 8-bit systems.

Sinclair QL System Review & Story | Nostalgia Nerd (201k views, 442 comments)
https://youtu.be/yU_VUN9VVcM?t=844

Besides many UK 68k Amiga and Atari developers learning to program the 68k on the cheaper Sinclair QL, it was responsible for BCPL being ported to the 68k allowing TRIPOS to be created and used by the AmigaOS/AmigaDOS. It was a cheap computer aimed more at small businesses where It was still influential for productivity software despite reliability issues, which are especially bad for a business computer.

cdimauro Quote:

But how many Mac fans would by a Mini Mac for running that old software? People which are used to buy the latest and greatest software for their current, well alive, platform. How much of them could be interested on a "revival"?

Most likely, only Mac collectors would buy old Macs. That does not mean 68k Mac games are not desirable. Many older Mac fans wish they could use older software but Apple does not let them and changing hardware so often is bad for compatibility. How many PC fans use DOSBox to play old PC games?

cdimauro Quote:

Indeed. The only Atari fans which were interesting on a revival are the ones around a EmuTOS or something like that, but that's a niche, and they have already found the solution on PiStorm and Apollo Core.

The "ST" in MiST and MiSTer is from the Atari ST. The FX68K cycle exact 68000 core was developed for 68k Atari systems where cycle exact is more important. What 68k Atari fans lack in numbers, they often make up for in dedication.

cdimauro Quote:

It's difficult to obtain better compatibility without the original schematics. But the main question is: for running what? Most of the badly written games were patched with projects like WHDLoad, Jodt, and they can already be used with the existing Mini/whatever solutions that are on the market (or that will come soon).

Some fans want better hardware. Watch the 2 videos by the developers about the NeoGeo AES+ to see where the new ASIC using hardware has advantages over even the FPGA based MiSTer. The NeoGeo AES+ potentially benefits from better compatibility due to timing improvements but there is some benefit for performance too. DMA is simulated and memory access has reduced performance due to the cheapness of the MiSTer hardware.

cdimauro Quote:

Do you believe that there's still a market here?

Yes. I do not believe the Sega Genesis/MegaDrive market is saturated. It is difficult to saturate such a large market. Analogue's FPGA Genesis is sold out.

https://www.analogue.co/mega-sg Quote:

We set out to design the definitive way to explore Sega's 16-bit and 8-bit era. A reimagining of the underdog that led a 16-bit revolution. Engineered with an FPGA. No emulation. 1080p. Zero lag. Total accuracy. Mega Sg is not a plug n' play toy. Compatible with the 2,180+ Sega Genesis, Mega Drive and Master System game cartridge library. Explore and re-live one of the greatest video game systems of all time with no compromises.

Original Sega Genesis units often sell for less than $100 USD but Analogue Mega Sg units sell for over $300 USD (into price was $190 USD).

https://en.wikipedia.org/wiki/Mega_Sg#Features Quote:

The Mega Sg features 1080p HDMI, digital audio (48 kHz 16-bit), and original Genesis-style controller ports. Kevin Horton engineered Mega Sg to use an Altera Cyclone V to match the Genesis hardware logic with very high accuracy and also provided extra features, such as the option to scale the original 240p video output to different resolutions up to 1080p 60 Hz. Phil Fish, the designer of Fez, designed the user interface, and Arca composed the startup audio. It includes an unreleased Genesis game from 1994, Hardcore, renamed Ultracore due to licensing problems.

I believe it is obvious to see why fans would rather have the added features. Many collectors will own the original console and the Analogue Mega Sg but use the hardware with more features most of the time. This hardware could be cost reduced with ASICs like the NeoGeo AES+. I expect it could be cost reduced more than the NeoGeo AES+ as the Genesis has simpler hardware. There is a lot of markup in the NeoGeo AES+ and it looks like they are using like original quality parts. With ASICs it should be possible to sell the Genesis for less that $100 USD and perhaps less than $50 USD. It may be similar to the Minis but there has been considerable inflation since then and global logistics problems currently.

cdimauro Quote:

How many games we have that require much better performance, and that the current ARM-based "Minins" can't handle (e.g.: more CPU power is required)?

There are probably 20-40 games currently available for the 68k Amiga that would significantly benefit from "much better performance". Some could move to much better resolution, more colors and better FPS which makes a big difference. There are many older PC games which could be easily ported to the 68k Amiga with more performance. Some already have been for emulation but are unplayable on even a 68060@100MHz or V4SA. Some are unplayable even using emulation which could be surpassed with an ASIC 68k CPU. Most of the PPC AmigaOS 4 games that are too CPU demanding currently would work on the 68k Amiga. Ok, there are not many PPC AmigaOS 4 games but they would likely be very easy to port back to the 68k.

Last edited by matthey on 09-May-2026 at 07:25 PM.
Last edited by matthey on 09-May-2026 at 07:21 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Which software was developed for the QL that still deserves to be enjoyed by fans? How many people could by a "Mini QL" for that? Those are the only questions that are relevant when you want to bring a product like that to the market. I still don't see anything appealing here. Part of the appeal of the Sinclair QL was the software it came with which was known for being advanced and easy to use. The QDOS OS used preemptive multitasking, SuperBASIC was one of the most advanced languages in ROM at the time and the included office suite word processor, spreadsheet, database, and business graphics software written by Psion were well liked. It was an innovative and advanced system for the time that was let down by rushed hardware problems and early Microdrive issues which were later corrected by Samsung. I believe many Sinclair fans and ZX Spectrum owners saw it as the next gen Sinclair computer but many did not buy it or experience it because of the problems and bad reputation. It may have been the first of a line of more powerful Sinclair 68k computers if it was more mature at launch. It was a good enough system to inspire users to create 3rd party software and hardware upgrades despite the limited and problematic hardware. There were some games created for it that are at least on par with better 8-bit systems. Sinclair QL System Review & Story | Nostalgia Nerd (201k views, 442 comments) https://youtu.be/yU_VUN9VVcM?t=844 Besides many UK 68k Amiga and Atari developers learning to program the 68k on the cheaper Sinclair QL, it was responsible for BCPL being ported to the 68k allowing TRIPOS to be created and used by the AmigaOS/AmigaDOS. It was a cheap computer aimed more at small businesses where It was still influential for productivity software despite reliability issues, which are especially bad for a business computer.

I've finally had time to watch the entire video. Videogames weren't interesting, because most of them were ports which are better on other platforms.

Videogames are THE business reason for "revivals" like what we're discussing now. So, a "MiniQL" remains not interesting.

Application could have had some value at the time, but they are very limited and you can just play a bit with them.
At least Amiga, Mac and Atari ST had something which still can be used because they are much modern and productive.

Anyway, "Minis" only for applications aren't a strong business reason. The same for "cultural" reasons: not useful for a business case.
This applies to any retro platform.
Quote:

cdimauro Quote: But how many Mac fans would by a Mini Mac for running that old software? People which are used to buy the latest and greatest software for their current, well alive, platform. How much of them could be interested on a "revival"? Most likely, only Mac collectors would buy old Macs. That does not mean 68k Mac games are not desirable.

Yes, some of them were interesting (I've played Dark Castle on a Mac Plus, when I was a guest at the Wesleyan University, on 1988). Yet, limited and not much compelling. Many of them had better versions for other platforms.
Quote:

Many older Mac fans wish they could use older software but Apple does not let them and changing hardware so often is bad for compatibility.

Right, and that's a general problem for Macs. The only way is emulation.

However, it's also difficult to run old Windows games on PCs running on newer Windows. Some can't even run at all (16-bit version on 64-bit Windows).
Quote:

How many PC fans use DOSBox to play old PC games?

No idea, but GoG is selling old PC games which internally use DOSBox. I've bought some of them.
Quote:

cdimauro Quote: Indeed. The only Atari fans which were interesting on a revival are the ones around a EmuTOS or something like that, but that's a niche, and they have already found the solution on PiStorm and Apollo Core. The "ST" in MiST and MiSTer is from the Atari ST. The FX68K cycle exact 68000 core was developed for 68k Atari systems where cycle exact is more important. What 68k Atari fans lack in numbers, they often make up for in dedication.

How much can sell a MiniST then? Enough to justify the investements?
Quote:

cdimauro Quote: It's difficult to obtain better compatibility without the original schematics. But the main question is: for running what? Most of the badly written games were patched with projects like WHDLoad, Jodt, and they can already be used with the existing Mini/whatever solutions that are on the market (or that will come soon). Some fans want better hardware.

Enough for an investment?
Quote:

Watch the 2 videos by the developers about the NeoGeo AES+ to see where the new ASIC using hardware has advantages over even the FPGA based MiSTer. The NeoGeo AES+ potentially benefits from better compatibility due to timing improvements but there is some benefit for performance too. DMA is simulated and memory access has reduced performance due to the cheapness of the MiSTer hardware.

That's a problem of MiSTer, however. Better compatibility can be achieved even in software: it depends on the host system.
Quote:

cdimauro Quote: Do you believe that there's still a market here? Yes. I do not believe the Sega Genesis/MegaDrive market is saturated. It is difficult to saturate such a large market. Analogue's FPGA Genesis is sold out. https://www.analogue.co/mega-sg Quote: We set out to design the definitive way to explore Sega's 16-bit and 8-bit era. A reimagining of the underdog that led a 16-bit revolution. Engineered with an FPGA. No emulation. 1080p. Zero lag. Total accuracy. Mega Sg is not a plug n' play toy. Compatible with the 2,180+ Sega Genesis, Mega Drive and Master System game cartridge library. Explore and re-live one of the greatest video game systems of all time with no compromises. Original Sega Genesis units often sell for less than $100 USD but Analogue Mega Sg units sell for over $300 USD (into price was $190 USD). https://en.wikipedia.org/wiki/Mega_Sg#Features Quote: The Mega Sg features 1080p HDMI, digital audio (48 kHz 16-bit), and original Genesis-style controller ports. Kevin Horton engineered Mega Sg to use an Altera Cyclone V to match the Genesis hardware logic with very high accuracy and also provided extra features, such as the option to scale the original 240p video output to different resolutions up to 1080p 60 Hz. Phil Fish, the designer of Fez, designed the user interface, and Arca composed the startup audio. It includes an unreleased Genesis game from 1994, Hardcore, renamed Ultracore due to licensing problems. I believe it is obvious to see why fans would rather have the added features. Many collectors will own the original console and the Analogue Mega Sg but use the hardware with more features most of the time. This hardware could be cost reduced with ASICs like the NeoGeo AES+. I expect it could be cost reduced more than the NeoGeo AES+ as the Genesis has simpler hardware. There is a lot of markup in the NeoGeo AES+ and it looks like they are using like original quality parts. With ASICs it should be possible to sell the Genesis for less that $100 USD and perhaps less than $50 USD. It may be similar to the Minis but there has been considerable inflation since then and global logistics problems currently.

I see. An ASIC out of the schematics or by re-using MiSTer's Genesis core?
Quote:

cdimauro Quote: How many games we have that require much better performance, and that the current ARM-based "Minins" can't handle (e.g.: more CPU power is required)? There are probably 20-40 games currently available for the 68k Amiga that would significantly benefit from "much better performance". Some could move to much better resolution, more colors and better FPS which makes a big difference. There are many older PC games which could be easily ported to the 68k Amiga with more performance. Some already have been for emulation but are unplayable on even a 68060@100MHz or V4SA. Some are unplayable even using emulation which could be surpassed with an ASIC 68k CPU. Most of the PPC AmigaOS 4 games that are too CPU demanding currently would work on the 68k Amiga. Ok, there are not many PPC AmigaOS 4 games but they would likely be very easy to port back to the 68k.

OK, but this doesn't answer my original question: aren't the current solutions able to run such 20-40 games with much better performance?

cdimauro Quote:

I've finally had time to watch the entire video. Videogames weren't interesting, because most of them were ports which are better on other platforms. Videogames are THE business reason for "revivals" like what we're discussing now. So, a "MiniQL" remains not interesting.

Games are the primary reason for retro gaming system revivals, especially for gaming focused systems like consoles, but they are not the only reason. Nostalgia for older users includes the experience, visuals, history, developers & development, all software including productivity and OS, demos, etc. Younger users receive an education and a history lesson as they play around and discover things they did not know about. Minis have missed much of the nostalgia market due to their cheap and limited hardware. Emulators have done a better job with the extras. For example, Amiga Forever comes with many extras that are not games.

Amiga Forever extras
~96 games
~111 demos
10 gallery items (Amiga-Atari: "Lorraine" overview, first demos, Amiga 1000 cover, etc.)
10 videos (historic like Jay Miner interviews, Launch of Amiga, the Deathbed Vigil, etc.)

Some of the extras are on DVD which could optionally use streaming from internet but Minis support neither. Sadly, most stand alone retro hardware is severely lacking in more ways than the emulation for PCs which is not accurate and a different experience due to Windows. Better value, while retaining Mini like prices for stand alone hardware, can be achieved with ASICs like the NeoGeo AES+ demonstrates. Much better value can be achieved for stand alone systems which allow to increase performance by many times. The same 68k ASIC SoC could be used to support multiple systems further increasing value while increasing mass production potential to reduce prices.

cdimauro Quote:

Yes, some of them were interesting (I've played Dark Castle on a Mac Plus, when I was a guest at the Wesleyan University, on 1988). Yet, limited and not much compelling. Many of them had better versions for other platforms.

I hear the ports are better on other platforms argument but different platforms have the best ports or desirable features for each game. Some platforms are getting more enhanced games and are easier release targets. The 68k Amiga had enhanced games for AGA/CD32 but there have been other enhanced games since then.

enhanced & re-released original Amiga games
DungeonMaster - Meynaf's patches include features from other ports and new levels
Worms DC v1.5 30th anniversary
Turrican II: The Final Fight (AGA)
Banshee AGA
Double Dragon AGA
Rick Dangerous Enhanced (AGA)
Renegade: Enhanced (AGA)
Final Fight: Enhanced (AGA)
Out Run: Amiga Edition (AGA)
Super Cars 2 (AGA)

recent Amiga game ports & re-releases that would benefit from more performance
Alien Breed 3D (AGA/RTG) - many patches
Quake (AGA/RTG) - continues to be developed for the Amiga
The Settlers II (AGA/RTG)
Star Wars: Dark Forces (AGA/RTG)
Amispear (ECS/AGA/RTG)
Doom RPG (AGA/RTG)
Heart of Darkness (RTG)
Heart of the Alien (ECS/AGA/RTG/CD)
Ultima VII Exult (AGA/RTG)
Mini Slug (RTG)
Death Rally (AGA/RTG)
Exhumed / Powerslave (AGA/RTG)
Blood (AGA/RTG)
Older but ~2000+: Descent Freespace, Quake II, Payback, Heretic II, Hexen, Foundation: Gold, Descent, Genetic Species, OnEscapee, Myst

games which could be released for the 68k Amiga with more performance
Wipeout rewrite/enhanced
Shogo: Mobile Armor Division
Wings Remastered Edition
Tower57
Gorky17
Legend of Grimrock I & II - Indie games by former Amiga game programmers
newer UFO enemy unknown ports
OpenRedAlert
Return to Castle Wolfenstein
Quake III Arena
Dungeon Keeper

I am just scratching the surface with popular games. Some other 68k systems have significant development too like for the Sega Genesis despite the cartridge limitation.

cdimauro Quote:

Right, and that's a general problem for Macs. The only way is emulation. However, it's also difficult to run old Windows games on PCs running on newer Windows. Some can't even run at all (16-bit version on 64-bit Windows).

PCs are configuration hell but most of the hardware is still available and compatible. At the very least, it makes emulation much faster. The 68k Amiga was much better at emulating a 68k Mac with a 68k CPU available too.

cdimauro Quote:

No idea, but GoG is selling old PC games which internally use DOSBox. I've bought some of them.

Amiga and other 68k system games sometimes included emulators too but there is no native 68k acceleration unlike for x86(-64) using DOSBox.

cdimauro Quote:

How much can sell a MiniST then? Enough to justify the investements?

MiniST and MiniQL may not be viable alone but combine the support for universal 68k hardware and ST and even QL support should improve economies of scale.

cdimauro Quote:

Enough for an investment?

An ASIC for a one and done market may not be viable but for a sustainable market like RPi's market is different. RPI was more profitable than DELL until recently. There was no standard competition for RPI using a similar memory footprint. The 68k can go smaller and has a large games library which ARM/RPI does not. ARM choices of Cortex-M MCUs with T32 and no A32 or MMU, 32-bit low power low performance scalar Cortex-A32 or higher end fat Cortex-A cores dropping AArch32 support are not helping RPI either.

cdimauro Quote:

That's a problem of MiSTer, however. Better compatibility can be achieved even in software: it depends on the host system.

MiSTer's problem is using cheap generic hardware that was not designed for the needs of retro game systems. Tolerable emulation performance can be provided but only with overkill hardware and a RTOS or no OS. Emulation with CPU cores of highly parallel chipsets is challenging even with high clocked and powerful CPU cores. A fraction of the hardware which is much lower cost can be used if it the right hardware.

cdimauro Quote:

I see. An ASIC out of the schematics or by re-using MiSTer's Genesis core?

Preferably, original development sources/schematics would be used which is less error prone but I expect many original sources are not available or in good shape like for the NeoGeo. MiSTer cores would likely have advantages like possibly easier to use and better documented HDL sources, current developers which are familiar with the HDL code, already integrated chipsets into one core/chip/SoC and new features and I/O support. As with the 68060 and CF v5 where it would be very valuable to draw from both sources, I expect the same to be true for original chipsets and MiSTer chipsets/cores.

cdimauro Quote:

OK, but this doesn't answer my original question: aren't the current solutions able to run such 20-40 games with much better performance?

Yes, 68k emulation using ARM SoCs with in-order CPU cores have better performance than original spec 68k hardware standards. However, ARM hardware has no production cost advantage but actually a cost disadvantage due to royalties. A 68k ASIC SoC with 68060 like in-order cores at a similar clock speed using a similar chip process should have a similar or lower production cost while providing much more performance for 68k software without emulation. It would be possible to give access to the ARM/Linux side of emulation hardware to run ARM compiled games natively at higher performance but that is not how most ARM/Linux stand alone emulation systems works and it loses the advantage of standard hardware/OS, unless it is a RPi, and even then it is not as standard or as small of footprint as a 68k Amiga without emulation could be.

Has someone been listening to me finally?

Why ASIC technology could start the next Amiga hardware revolution
https://www.generationamiga.com/2026/05/14/why-asic-technology-could-start-the-next-amiga-hardware-revolution/ Quote:

... The arrival of modern systems such as the Neo Geo AES+ has shown that retro hardware does not have to choose only between original machines, software emulation and FPGA recreation. There is another path: newly manufactured, purpose-built silicon designed to reproduce classic hardware as a stable product rather than a flexible approximation. For the Amiga, that path is not merely attractive. It may be necessary.

The 68k Amiga continues a slow death without an ASIC 68k Amiga SoC but with one it becomes modern growing and supported hardware again like the RPi. If failure is not an option, indeed, "It may be necessary." "The real choice is between renewal and managed decline"

Last edited by matthey on 16-May-2026 at 08:20 PM.
Last edited by matthey on 16-May-2026 at 07:51 PM.

@matthey

Quote:

matthey wrote: Has someone been listening to me finally?

IF THEY HAD, THIS IS THE PICTURE YOU WOULD FIND ON THAT WEBSITE




/M!

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

@matthey

Quote:

with one it becomes modern growing and supported hardware again like the RPi

Nonsense, it would have to be quite a different 68k than what we know of today to anywhere near "modern".

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: The 68k Amiga continues a slow death without an ASIC 68k Amiga SoC but with one it becomes modern growing and supported hardware again like the RPi

Just imagine an Amiga in a RPi compatible form format ...


I can't imagine how they could compete with an RPi 4 in price and performance, the 68k is to old, the ECS/AGA graphic and sound is obsolete and every expansion would make it as alien as AROS on a RPi.

matthey Quote:

with one it becomes modern growing and supported hardware again like the RPi

kolla Quote:

Nonsense, it would have to be quite a different 68k than what we know of today to anywhere near "modern".

The 32-bit in-order superscalar 68060 CPU is more powerful/clock than the original Raspberry Pi (RPi) 32-bit 1xARM11@700MHz scalar CPU core. A superscalar CPU core can execute multiple integer instructions in parallel where a scalar core can only execute one instruction at a time. The RPi ARM11 core is more like a 68040 with larger caches than a 68060. The 68060 can execute more powerful CISC integer instructions, often in a single clock cycle, and the design does not suffer from load-to-use stalls after loads.

CPU core | fab tech | clock | DMIPS/MHz/thread
68000 3500nm 8MHz 0.16 scalar
68040 650nm 40MHz 1.10 scalar
68060 500nm 50MHz 1.80 in-order

ARM1176JZF-S 40nm 700MHz 1.25 scalar (RPi)
Cortex-A7 40nm 900MHz 1.90 in-order (RPi 2)
Cortex-A53 40nm 1200MHz 2.30 in-order (RPi 3)
Cortex-A72 28nm 1800MHz 4.72 OoO (RPi 4)
Cortex-A76 16nm 2400MHz 6.60 OoO (RPi 5)

X280/Series7 ? ? 3.3 in-order (SiFive RISC-V)

The largest factor for max clock speed is the chip fab process allowing a modern 68k CPU to advance in a huge leap. The 2nd most important factor is pipeline depth where more stages should increase the max clock speed and the 68060 is already in good shape with an 8-stage pipeline. At the same clock speed, the 68060 CPU core would outperform the RPi ARM11 core in some if not most int workloads where the instructions and data are cached. The RPi ARM11 core has 16kiB I+D L1 caches and a 128kiB L2 cache where the 68060 only has 8kiB I+D caches. Much of modernizing the 68060 would be to increase the caches which has minimal affect on the 68060 pipeline logic and its inherent performance but significantly increases overall core performance.

Intel’s Long-Awaited P55C Disclosed (Pentium P55C doubling caches to 16kiB I+D)
https://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/101404.PDF Quote:

Intel doubled the cache size to reduce the performance lost from cache misses at high core clock speeds. In addition, the caches are four-way (instead of two-way) set-associative. Preliminary data from Intel shows the doubled caches cut the data-cache miss rate (on SPECint95) by 20–30% and the instruction-cache miss rate by 35–40%. The net effect, combined with the pipeline and branch-prediction enhancements, is a 10–20% increase on standard benchmarks, according to Intel. The benefit of the large cache will be greatest at the 200-MHz clock rate, due to the higher cost of cache misses at that speed.

Arthur Revitalizes PowerPC Line (PPC603e to G3 with 32kiB I+D L1 & off-chip L2 caches)
https://www.eecg.toronto.edu/~moshovos/ACA07/lecturenotes/ppcg3%2520(mpr).pdf Quote:

Somerset estimates the larger on-chip caches alone add about 15% in performance for typical Mac applications, compared with the 603e. The changes to the core—the extra integer unit, improved fetch rate, hardware TLB miss handler, and dynamic branch prediction—add another 15% or so. The biggest performance gain comes from the new L2 cache bus; this change raises performance by 50% or more.

Quadrupling the L1 caches of a 68060 core to 32kiB I+D should give a 25%-35% performance gain and adding a L2 cache should give at least a 50% performance gain as an on-chip L2 cache has much better performance than an off-chip L2 like the original PPC G3 (Arthur). The 68060 needs fewer changes than these other cores above as the 8-stage pipeline depth is the most common for modern in-order cores, it already has dynamic branch prediction which was better than Pentium P54C and PPC603e, it has a 2nd int unit with better superscalar issue/execution rates than both, superior code density allows a lower instruction fetch rate than both of only 4B/cycle for reduces power or could be increased to 8B/cycle like the similar ColdFire v5 to improve performance. The 68060 design is a much better and more modern base to start with than P5 Pentium or PPC603 designs. It could use some other non cache enhancements mentioned for the P55C and PPC G3 like a "return stack buffer" (P55C) and "hardware TLB miss handler" (G3) but these are relatively minor enhancements.

I believe a modernized 68060 with larger caches, buffers and relatively minor enhancements would easily be outperforming the RPi2 Cortex-A7 which is barely superscalar with low superscalar issue rates. The RPi3 Cortex-A53 has high superscalar issue rates but performance killing 3 cycle load-to-use stalls where the Cortex-A7 has 1 cycle and the 68060 has zero cycle loads with no load-to-use stalls. Most early CISC designs had zero cycle loads which allowed 8 GP registers to perform like 32 GP registers and in-order designs to perform like weak OoO designs.

Zero-Cycle Loads: Microarchitecture Support for Reducing Load Latency
https://ftp.cs.wisc.edu/sohi/papers/1995/micro.zcl.pdf Quote:

Speedups on the out-of-order issue processor were significantly less due to the latency tolerating capability of the execution model. However, some programs still showed notable speedups, likely because the executions lacked sufficient parallelism to tolerate all load latency, and thus benefited from the latency reduction capability of fast address calculation. An in-order issue processor with zero-cycle load support compared favorably in performance to an out-of-order issue processor for programs with significant untolerated load instruction latency. With fewer registers, the frequency of loads and their impact of program performance increases significantly, especially for floating point codes. Providing an 8 register architecture with zero-cycle load support for only global and stack pointer references, resulted in performance comparable to a 32 register architecture. This result suggests limited support for zero-cycle loads is one avenue available to improving the performance of legacy architectures with few registers. With full support for zero-cycle loads, speedups were quite good, slightly better than for the 32 register architecture due to excellent prediction performance for the many extra global and stack accesses present

The paper above considers a RISC pipeline with 32 GP register and 2 cycle load-to-use stalls where the Cortex-A53 has 3 cycle load-to-use stalls and of course the 68060 has 16 GP registers instead of x86 with 8 GP registers. When using compressed ARM Thumb modes which is common on the RPi 3 to save memory, there are only 14 GP registers and using more than 8 GP registers often increases the code size. The Cortex-A53 is especially poor at emulating 68k CPUs with zero cycle loads and will commonly suffer from load-to-use stalls (PPC code is generally scheduled for 1-2 cycle load-to-use stalls so suffers less). While the Cortex-A53 is the smallest superscalar ARM64/AArch64 supporting core, it supports thousands of instructions for A64 (AArch64), A32 (original 32-bit ARM) and T32 (32-bit Thumb+Thumb-2) ISAs compared to low hundreds for the 68060. ARM's smallest superscalar Cortex-A core is fat and poor performance despite it and the mildly upgraded Cortex-A55 likely remaining the most popular Cortex-A cores. The 8-stage in-order superscalar cores are not just the bread and butter for ARM but also for RPI.

What model Raspberry Pi is the best selling all time?
AI Overview Quote:

The Raspberry Pi 3 is the best-selling model family of all time, making up roughly 30% to 37% of all lifetime sales. Combined with earlier predecessors like the Raspberry Pi 2, this generation of boards accounts for over half of the 68+ million units sold globally. The original Raspberry Pi 3 Model B alone holds the record as the single most popular model, which was eventually supplemented by the slightly upgraded 3B+ variant. Together, they helped propel the Raspberry Pi lineup to become the third best-selling computer series in history.

The Cortex-A competition has not improved much today at the lower end. ARM is putting most of their new Cortex-A core designs on a diet by removing A32+T32 ISA support but they are still larger than the Cortex-A53 and Cortex-A55 and power efficiency (performance/W) has not improved as much as performance making them less appealing for embedded use, especially for low power applications. The loss of T32 makes newer Cortex-A cores much less appealing for small footprint systems like RPi SBCs. High end Cortex-M cores are an option but lack a MMU for Linux, have legacy ARM support removed including A32 and are missing some Cortex-A features as options. ARM realized they had a gap of coverage in the middle which the unusual Cortex-A35 and Cortex-A32 attempt to provide. The Cortex-A35 core is smaller, lower power and more power efficient AArch64 supporting cores than Cortex-A53 cores but lower performance. This was achieved by dropping A32 and T32 support and what they call partial superscalar operation but I believe this is scalar operation with marketing propaganda much like Motorola used for ColdFire v4 where more than 1 int instruction can be issued and retired per cycle using code fusion/folding techniques. The smallest, lowest power and best power efficiency Cortex-A core is the 32-bit Cortex-A32 which drops 64-bit support while keeping A32 and T32 ISAs. It supports a MMU, most Cortex-A features, has legacy ARM support and adds over 100 ARMv8-A instructions but still is the smallest Cortex-A core. Getting rid of fat 64-bit support and superscalar operation saves a lot in both power and area without losing 32-bit performance for small footprint hardware like the RPi.

https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/introducing-cortex-a32-arm-s-smallest-lowest-power-armv8-a-processor-for-next-generation-32-bit-embedded-applications Quote:

2. Higher efficiency and performance Cortex-A32 is 25% more efficient (more performance per mW) than Cortex-A7 in the same process node. Cortex-A32 delivers this efficiency through performance improvements and power reduction, two often conflicting design goals that the Cortex-A32 team managed to deliver in tandem. The Cortex-A32 also delivers performance improvements compared to Cortex-A5 and Cortex-A7 processors. The performance improvements relative to the Cortex-A5 range from 30% to a massive 1300% across a range of benchmarks relevant to embedded markets. Streaming and crypto are key benchmarks at the top end of this scale. Compared to the Cortex-A7, the Cortex-A32 offers 5% to 25% higher performance. To put things in perspective, the Cortex-A32 delivers similar performance to the Cortex-A9, which was the premium smartphone standard just a few years ago. That performance is coming to the lowest cost rich embedded devices now, and at significantly less power. For integer workloads, the combination of performance improvements and power reduction provided by the Cortex-A32 translates into a greater than 25% efficiency gain over the Cortex-A7 and more than 30% efficiency gain over the Cortex-A5. Compared to Cortex-A35, the Cortex-A32 offers same 32-bit performance but consumes 10% less power and has a 13% smaller core. This means that Cortex-A32 is 10% more efficient than Cortex-A35 processor in the 32-bit world.

Despite the propaganda, the Cortex-A32 is a low power partial superscalar 32-bit core with a lot of features. It is true that 64-bit support provides a minimal overall general purpose performance gain but the cost of 64-bit is not minimal, especially for small footprint hardware. The Cortex-A32 is still not a small core and is not high performance. Power efficiency is not a point but a line. While low power power efficiency is very important for the embedded market, especially mobile battery operated devices, high performance power efficiency is more desirable for interactive computers due to less wait time and is used for some embedded markets like the communications and auto niche PPC markets held for years. Less overall energy is used for high performance power efficiency as the work gets done faster and the core can sleep more. The in-order Intel Atom also provided high performance power efficiency and gained markets for embedded niches like microservers, netbooks, set top boxes, smart TVs, etc.

https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient





The in-order Atom uses less energy than the ARM competition except for the OoO Cortex-A9 yet has significantly better performance. From the ARM webpage above, "the Cortex-A32 delivers similar performance to the Cortex-A9" so the in-order Intel Atom has significantly better performance than the in-order Cortex-A32 too. The 68060 was more efficient in many ways and had much better int performance than the P5 Pentium and I believe a modernized 68060 could provide a much smaller core that is more efficient in many ways and higher performance efficiency (performance/MHz) than the in-order Intel Atom.

SiFive has a RISC-V series 7 8-stage in-order superscalar core design which is a competitor too. It uses a similar CISC like design to the 68060 and Cyrix 6x86 which also eliminates load-to-use stalls. However, CISC ISAs allow to execute more powerful instructions which are the equivalent of 2 RISC instructions and not possible with the RISC-V ISA. Despite this, SiFive claims 3.3 DMIPS/MHz with newer series 7 cores. The 68k has better code density and attempts to improve the RISC-V code density with embedded extensions has made a non-standard mess. Perhaps most importantly, RISC-V does not have software like the 68k market which used more standard hardware. While the under $100 USD VisionFive 2 SBC with SoC using SiFive series 7 cores has not been as popular as RPi SBCs, SiFive gained the NASA contract to replace the PPC by bolting a vector processor to Series 7 cores. At the following link, see page 9 for performance claims and page 10 for a diagram of vector unit bolted on to X280 (upgraded series 7) CPU core.

http://microelectronics.esa.int/riscv/rvws2022/presentations/04-SiFive_Intelligence_X280_for_Space_Exploration_v2.0_Dec_22.pdf

I wonder how similar the vector unit bolt on is to the vector unit Mitch Alsup designed for the open source Libre-SoC project. Some 68k developers may prefer a more integrated SIMD unit but a vector unit like the X280 uses may be easier to bolt on and is likely more scalable than a SIMD unit.

Last edited by matthey on 18-May-2026 at 03:37 AM.
Last edited by matthey on 17-May-2026 at 11:03 PM.

@matthey

Quote:

Right. A 68k Amiga is so much more than a 6502 family C64 with very limited compiler and OS choices. It is amazing that the C64 was once used in businesses but it feels like a limited toy today. Even a moderately enhanced 68k Amiga feels surprising modern, responsive and useful in comparison. A modernized 68k Amiga Ultimate would be more like a RPi 2 or 3 than a C64 Ultimate. Most legacy I/O could be available through a plug on the board or GPIO (a PS2 keyboard/serial port and A1200 clockports may be worth retaining on SBC). A low price would allow people to play with SBCs and just throw away the burn outs. Make them so that some of the RPi hats work with them for hobbyists allowing to easily turn into handheld gaming devices, tablets and notebooks. Some embedded use would likely come with it. There is not much competition using standard hardware at the small footprint a 68k Amiga can scale down to. Small footprint ARM/Thumb2 Linux flavors do not scale down to the 68k Amiga footprint, are not standard or are being discontinued for much larger footprint AArch64. The 68k Amiga has some challenges when scaling up, the most difficult being lack of SMP support, but the Amiga does not need to scale up far if it is cheap, easy to use and fun.

https://youtu.be/_Mt0ZQE72vk
This a video from Jan Beta, an YouTuberq which work I like very much. One thing that caught my eye was the fact that this platform doesn't shy away of allowing, almost inviting the user to twinker with it's hardware. So I think it's very true to form, with the possibilities we have today what would be possible if such an Amiga solution would be presented nowadays...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

OneTimer1 Quote:

Just imagine an Amiga in a RPi compatible form format ... I can't imagine how they could compete with an RPi 4 in price and performance, the 68k is to old, the ECS/AGA graphic and sound is obsolete and every expansion would make it as alien as AROS on a RPi.

Chip production prices are dominated by the fab process used, area/transistors used, economies of scale and IP royalties. The RPi 4 SoC uses 4xCortex-A72 OoO cores which are likely larger than Cortex-A57 OoO cores, the predecessor. ARM no longer provides transistor counts but the trend is clear.

Year | CPU | transistors
1975 6502 3,500
1979 68000 68,000
1984 68020 190,000
1985 ARM1 25,000
1985 80386 275,000
1986 ARM2 30,000
1987 68030 273,000
1990 68040 1,170,000
1993 Pentium 3,100,000 superscalar in-order 2-way
1994 68060 2,530,000 superscalar in-order 2-way
1994 ARM7 250,000
1995 PentiumPro 5,500,000 OoO uop
2002 ARM11 7,500,000 (RPi1)
2008 Nehalem 731,000,000 64 bit OoO uop (1st gen Core i7 with 4 cores)
2011 Cortex-A7 10,000,000 superscalar in-order 2-way (RPi2)
2012 Cortex-A53 12,500,000 64-bit superscalar in-order 2-way (RPi3)
2012 Cortex-A57 75,000,000 64-bit OoO 3-way big.LITTLE companion of Cortex-A53

Notice that an OoO Cortex-A57 core is already 6 times larger than the in-order Cortex-A53 core of the same generation and this difference almost certainly grew with later generations as OoO cores push for more performance while power efficiency is more important for in-order cores. The RPi 5 Cortex-A76 cores are OoO uop which uses more transistors like the Nehalem above with 183,000,000 transistors per core and which it is likely closer in transistor count to than the Cortex-A57. These newer OoO cores produce more heat requiring more expensive fab processes too. The Cortex-A72 is practical because it does not use too aggressive of OoO. As we saw in my last post, the OoO ARM Cortex-A9 had better power efficiency and used less energy than the lower power in-order Cortex-A8. However, the in-order Intel Atom and much later in-order Cortex-A32 outperform it overall for performance, power efficiency and energy used. In-order cores can be competitive with limited OoO cores in performance while providing better power efficiency, using less energy and using less transistors/area providing a cost advantage. While in-order CISC cores use more transistors for pipelining than RISC cores, they can compete in performance with limited OoO cores, often while saving transistors, especially if there is a cache savings from better code density. The RISC-V VisionFive 2 SoC with SiFive series 7 CPU cores comes in between the CPU performance of a RPi 3 and RPi 4 while offering a better GPU with the transistor/area savings of using in-order cores. SiFive is likely able to use a cheaper fab process than the RPi 4 to save cost or it could use a newer fab process than the RPi 4 while leveraging the smaller die size to compete better in performance, perhaps why the SiFive X280 space SoC has improved performance approaching that of the RPi 4 SoC. Unfortunately for SiFive, the RISC-V ISA has weak performance traits/metrics unlike the 68k ISA which could take better advantage of the CISC like core design. The VisionFive 2 SBC is likely good enough to compete with an ASIC SoC despite RISC-V immaturity issues, weak performance, lack of pre-compiled software and a much larger memory footprint than the 68k Amiga as it is still available for $95 USD with 8GiB of memory after 3.5 years on the market.

https://www.amazon.com/VisionFive-RISC-V-JH7110-Quad-core-Application/dp/B0BGM1KQXQ

The NeoGeo AES+ provides the hardware equivalent of the original with minimal enhancements. A 68060 and AA+ chipset would likely be ~3,000,000 transistors with minimal enhancements. This is less than half the transistors of the ARM11 core used in the original RPi selling for $25 USD with 512MiB memory. RPI net profit margins have been significantly higher than Dell net profit margins.

2020 DELL=5.44% RPI=17.21%
2021 DELL=3.75% RPI=10.56%
2022 DELL=5.50% RPI=9.09%
2023 DELL=2.39% RPI=11.89%
2024 DELL=3.83% RPI=4.51%
2025 DELL=4.81% RPI=6.71%

RPI profit margins were higher with the old "obsolete" SoCs and small memory footprint SBCs. Newer higher tech RPi SBCs with more expensive SoCs and more memory have more competition and lower margins but some people may consider the RPi 4 and RPi 5 as less obsolete (RPI makes up some of the reduced profit margins by selling heat sinks, fans, cooling cases and higher amp power cables which is convenient but overall value is decreased). For most computer manufacturers including Commodore resulting in their demise, it is the low end computers which become obsolete and less profitable. I would not consider sustainable hardware with a healthy profit margin as obsolete whether it is a RPi 3 or a NeoGeo AES+. The 68k Amiga is currently obsolete due to Amiga Neverland mentality. Meanwhile, RPI shipped 7.6 million units in 2025, their price is back up pushing the market cap to over 1.3B GBP or 1.8B USD, their fabless semi developed ASIC chip volumes exceeded SBC volumes for the fist time and ARM has increased its stake to over 13%.

pixie Quote:

https://youtu.be/_Mt0ZQE72vk This a video from Jan Beta, an YouTuberq which work I like very much. One thing that caught my eye was the fact that this platform doesn't shy away of allowing, almost inviting the user to twinker with it's hardware. So I think it's very true to form, with the possibilities we have today what would be possible if such an Amiga solution would be presented nowadays...

Making tinkering and customization easy, fun and cheap for the win. The Amiga can do better already with a 3 finger salute instead of needing a reset switch and clockport LEDs with a better GUI and control.

Solas RGB LED controller for the Amiga
https://www.youtube.com/watch?v=bykoQt1D_KY

There are already clear A1200 cases kind of like the starlight C64 Ultimate option too. A1200 cases are made in every variation possible but no ASICs to make tinkering cheap. The recent
ZZAP! Live! 2026 show in the UK has more custom Amiga cases than I have seen anywhere else, mostly A1200 cases.

ZZAP! Live! 2026 - Commodore C64 - Amiga Retro Gaming Event - Conventry
https://www.youtube.com/watch?v=NTPWg9BKP0k

Last edited by matthey on 19-May-2026 at 12:10 AM.

Modern Vintage Gamer talks about the NeoGeo AES+ in some recent videos.

My Thoughts on the Neo Geo AES+
https://www.youtube.com/watch?v=yFNRUgRupkU

The Death of Mini Consoles
https://www.youtube.com/watch?v=fNz0pExtADY Quote:

We talked about the NeoGeo AES+ last week and this seems like where the market is right now. Being able to recreate these systems in their entirety and have them play original games and use original peripherals, I think is what is very very hot right now. But what's hot right now may not be hot in a couple years from now. But they are just my thoughts and opinions.

Right before the comments above, he talks about THEA500 Mini and THEA1200 full size. I have the same feeling as him that Minis were more collectable toys than useful and even crap hardware inside of a full size case is not enough anymore. FPGA devices like MiSTer and Analogue, emulation on higher end consoles and PCs and handhelds have more to offer than limited Minis and low end limited ARM hardware in full size cases. I also feel like the NeoGeo AES+ is a turning point where users demand and expect more from retro hardware. Once launching faithful hardware, the platform is essentially relaunched and likely sustainable with proper support.

Modern Vintage Gamer ported CannonBall (OutRun clone), Strife AGA, Heretic AGA and Zippy Race for the Amiga. He has owned an Amiga since at least 1988 as he has talked about buying a memory upgrade to play Dungeon Master. His choice to port Heretic AGA to the Amiga may be based on it being developed by Raven Software, an early Amiga developer of the Amiga exclusive Black Crypt which he has also played, before Raven Software saw the writing on the wall that Commodore did not intend to support chunky and CPU upgrades for FPS games. Despite being much loved with huge potential, the Amiga remains bottled up by limitations and poor decision making of the Commodore era. High performance 68k CPUs and chunky are still not available at a competitive value for the Amiga masses but they could be. There are multiple exiting 68k CPU cores, Amiga compatible chipsets supporting chunky/RTG and chunky using 3D GPUs which likely could modernize the 68k Amiga much further with ASIC integration than is possible with the NeoGeo AES+.

Last edited by matthey on 19-May-2026 at 01:36 PM.
Last edited by matthey on 19-May-2026 at 12:30 PM.