@OneTimer1

Not only cheaper but also better and much more flexible if done right.

Most people just don't care about "real HW" or 1ms better latency as long as they can just start their old games in an easy way and have them running good enough.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Quote:

Kronos wrote: Not only cheaper but also better and much more flexible if done right.

Yes, if they have f.e. 30 build in games, they will provide the start scripts needed to start them in a AOS_1.3 on 68000 ChipRAM only, AOS_2.4 with 68020 or AOS3.1 with 68030 and FPU if needed.

That's something that could lead into problems on an FPGA system.

cdimauro Quote:

More close to a simple 3-way OoO.

I am talking about simple/limited RISC OoO. The 68060 has the integer firepower to compete with some limited OoO RISC 4-way CPUs. It has some low power limitations but the performance potential is there.

68060 (peak issue 2+branch; like RISC 4+branch)
2x integer unit (like RISC 4x integer unit)
2x load/store unit
1x branch unit
1x FPU

PPC603 2-way (peak issue 2+branch)
1x integer unit
1x load/store unit
1x system-register unit
1x branch unit
1x FPU

PPC604 4-way (peak issue 4)
2x simple integer unit
1x complex integer unit (includes system-register unit)
1x load/store unit
1x branch unit
1x FPU

PPC G3 2-way (peak issue 2+branch)
2x integer unit
1x system unit
1x load/store unit
1x branch unit
1x FPU

RISC OoO removes memory/cache latency but I qualified as "peak performance (no cache misses)" so no gain here. The idea is that small 68k Amiga programs with semi-modern cache sizes would not have many cache misses and without cache misses, an in-order 68k CPU would narrow the performance gap with RISC OoO CPUs while using fewer resources and less power. RISC OoO can remove dependencies too but many were created by RISC "simplification" while CISC uses nice packets of instructions that can be executed in pairs with no dependencies.

Quote:

cdimauro [quote] Unfortunately, instructions decoding is also another big difference. In fact, RISC-V variable-length instructions are very simple and straightforward to be decoded (it's enough to take a loot at a few bits of the opcode, at the very beginning). 68ks and x86s are on a completely different level.

Even the 68k and x86 decoding are significantly different. The x86 decoding is well documented as a simple loop while the 68k uses a table lookup.

The Superscalar Architecture of the MC68060 Quote:

The four-stage instruction fetch pipeline, which the FIFO instruction buffer decouples from the dual execution pipelines, performs the chip's instruction prefetch. The third stage is a table lookup that uses the 16-bit opcode to produce a 32-bit longword of decode information.

It sounds simple enough and may not be that much different than decoding some RISC ISAs. ColdFire used a "variable-length RISC architecture" just by limiting the 68k max instruction size to 6 bytes.

cdimauro Quote:

The FPGA part should be small. Hence, quite cheap. But why are you interested on an eFPGA (sub) core instead of a regular FPGA? A chipset implementation doesn't require an eFPGA.

You correctly mentioned the cost advantages of integration so it is good to consider all possibilities. A FPGA is just an ASIC with mostly eFPGA blocks. A FPGA with a hard 68060 CPU core would provide the needed performance, compatibility and flexibility.

bhabbott Quote:

You mean fail. Most people already have a Windows PC and don't need another one, especially one as limiting as this. But it fails out of the box anyway. Not an X68000, just a 'PC' in a tiny case that resembles a shrunk down X68000. Very disappointing and certainly not worth $24 million.

The problem in Japan may be the small apartments with limited space thus the all in one computer solution. The new X68000 guts certainly leave a lot to be desired as far as a X68000 computer but some X68000 fans will enjoy the nostalgic facade. The X68000 keyboard and mouse are unique designs and quality products. The lack of concern for faithful guts with that much money raised is disappointing though.

Zuiki not using the crowd sourcing to develop more faithful hardware could allow a competitor to take most of their X68000 business. Much of the X68000 is public domain and freely available.

https://en.wikipedia.org/wiki/X68000#Operating_system Quote:

Since the system's release, software such as Human68k itself, console, SX-Window C compiler suites, and BIOS ROMs have been released as public domain software and are freely available for download. Other operating systems available include OS-9 and NetBSD for X68030.

The X68000 supports more powerful 68k CPUs including the 68060 and is sometimes considered to be the "The Japanese Amiga Alternative".

https://www.everythingamiga.com/2021/01/sharp-x68000-the-japanese-amiga-alternative.html

Retro 68k hardware that supports the X68000 and Amiga should be fairly painless, other than Hyperion who acts like they own the classic AmigaOS. Licensing retro IP for the Neo Geo and Sega Genesis may be more difficult but the performance of these consoles can not be cranked up like it can for these gaming computers and a CD32 like console. The X68000 had a better chipset than the Amiga, likely including AGA, but the Amiga had a better OS and a console at least. Some people wish the X68000 had a console.

https://comp.sys.amiga.misc.narkive.com/UII804NO/i-liked-the-amiga-but-x68000-was-better-imho-rant-long Quote:

I wish there had been a television / console version of the X68000, like the Commodore CDTV or CD-32.

The X68000 Z mini is basically a console.

OneTimer1 Quote:

Yes she was talking about an Amiga on a Chip, she still used the original 68k and Paula of the A500, her implementation of the custom chips might be different from those used in the Minimig. Source: https://www.youtube.com/watch?v=5uaDzF99a80 But the story of the C64 DTV seems to be typical for redesigns, the 'C64 DTV' with it's build in Blitter, 256 Color Palette and even a IEC Bus is one of the best C64 hardware clones ever produced but successful implementations today like "THEC64" are using an RasPi like ARM platform with software emulation. It's hard to accept but most implementation do rely on software only, it seems to be cheaper.

Emulation is easier but not cheaper than a mass produced ASIC! A real 68k SoC ASIC would use a fraction of the resources of an ARM SoC. Emulation is a resource hog requiring much higher performance CPU cores, more caches, more memory, more power, larger power supplies, more cooling, more cost, etc. The problem is that most retro gaming businesses are looking to turn a quick profit rather than invest in a sustainable retro market with high quality products. The closest are some high quality FPGA products like Analogue.

https://www.analogue.co/

These guys get it. They have trouble keeping their products in stock and it is not unusual for the ones out of stock to sell for more than the original price. The Minis are money grabs even if guys like RGL try to be as faithful as possible resources permitting (they approached Jeri about creating an ASIC Amiga but they are a micro-business). Analogue is respectful of the history too. The FPGA devices are more faithful but emulation is cheaper so the market size is several times larger. A 68k SoC ASIC would require much higher investment but the production cost should be around that of ARM SoCs. ARM SoCs have no cost advantage as 64-bit ARM cores are fat, use more resources than a 32-bit 68k core and ARM requires significant royalties. The advantage of ARM SoCs is that ARM makes it easy.

@cdimauro

Quote:

In the meanwhile, WSL continues to be irrelevant/ not useful for the average Joe.

Meanwhile, Google Play Games requires Windows Hypervisor Platform to be enabled, which is the same dependency as WSL.

SteamOS 3.x targets the average PC gamer.

SteamDeck's SteamOS 3.8 install image can be installed on an Intel-based x86-64v3 PC with an AMD NAVI GPU with minimal issues.

PC gaming is not limited to Valve's Steam distribution platform since Epic Games' distribution platform reached about half of Steam's active account install base.

Quote:

That wasn't the point of THIS part of discussion.

This topic is about raising funds for particular projects and "What If" remap for an independent 68K ASIC project.

My post shows other startup examples e.g. Framework Computer Inc. is closer to Zuiki example. Both Framework Computer Inc. and Zuiki Inc. are startup system integrators, NOT another Motorola/Freescale Semiconductor wannabe.

SiFive example has RISC-V-compatible ASIC designs and a funding magnitude. Deep Computing uses StarFiveTech's cut-and-paste engineered SoC with SiFive's RISC-V implementation, and designs the mainboard for Framework Computer Inc. (contracts with Compal ODM).

The original Amiga Corporation has outsourced its CPU needs to Motorola Semiconductor. The original Amiga Corporation's aims are closer to NVIDIA i.e. mostly a graphics chipset design house. CSG provided chip fabrication services, and the C= system engineering group provided system integration. NVIDIA's Shield TV console and Founder Edition graphics cards are the closest relationship between NVIDIA and end users.

Commodore management deleted the original Amiga's graphics chipset design house.

Apollo Computers (AC68080 and SAGA) example is a Motorola/Freescale Semiconductor and a C= system engineering group wannabe.

Matthey wants the "Amiga" idea to be converted into a Motorola Semiconductor wannabe or another Apollo Computers i.e. dislikes Gunnar von Boehn's direction.

Last edited by Hammer on 16-May-2025 at 06:48 AM.
Last edited by Hammer on 16-May-2025 at 04:59 AM.
Last edited by Hammer on 16-May-2025 at 04:57 AM.
Last edited by Hammer on 16-May-2025 at 04:55 AM.
Last edited by Hammer on 16-May-2025 at 04:54 AM.
Last edited by Hammer on 16-May-2025 at 04:42 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

The original Amiga ideology involved outsourcing CPU needs to other companies.

Quote:

I am talking about simple/limited RISC OoO. The 68060 has the integer firepower to compete with some limited OoO RISC 4-way CPUs. It has some low power limitations but the performance potential is there.

L1 instruction cache's 4 bytes per cycle fetch is a major bottleneck for 68060's dual integer pipelines. SysInfo benchmark easily steps on 68060's L1 cache bottleneck.

AC68080 fixes the "low-hanging fruit" 68060's L1 instruction cache 4-byte fetch bottleneck for dual integer pipelines.

Both AC68080 and 68060 have dual integer pipelines.

AC68080's concurrent dual integer and floating point pipelines show its strength with titles like Quake, less with heavy floating point Lightwave. Lightwave's heavy floating-point workload shows that AC68080's FPU wasn't multi-pipelined (any updates on this issue?).

I don't recall a full 68030 FPGA implementation that includes PMMU. This is important for PMMU Linux compliance.

VexRISCV FPGA has an MMU implemented, hence it can run PMMU Linux.

SiFive U74 has PMMU Linux compliance.

Perhaps Amigaworld.net should be renamed into 68Kworld.net. LOL

VexRISCV full with MMU (RV32IM, 1.24 DMIPS/MHz, 2.35 Coremark/MHz, with cache trashing, 4KB L1 instruction cache, 4KB L1 data cache)
AMD Artix 7 yields 151 MHz, 2021 LUT, 1541 FF
Intel Cyclone V yields 124 MHz, 1368 ALMs
Intel Cyclone IV yields 128 MHz, 2826 LUT, 1474 FF

For Cyclone V, VexRISCV's clock speed attainment is similar to AC68080 V4's 100 MHz.

https://bitlog.it/20220118_asic_roundup_of_open_source_riscv_cpu_cores.html
VexRISCV's ASIC implementation

"All CPU cores were synthesized using a well known 65 nm PDK."
"Synopsys Design Compiler with ultra effort was used for synthesis."
"Cadence Innovus was used for place & route"
"The goal was maximum clock frequency."

RV32I ISA reached 606 Mhz,

RV32IMAC ISA reached 526 Mhz,

RV32I's SERV implementation reached 1020 Mhz,

RV32I's PicoRV32 implementation reached 806 Mhz.

RV32IM's Minerva implementation reached 625 Mhz

RV32IM (with basic MMU) is needed for PMMU Linux.


------------------------
Deep Computing has designed its second mainboard (DC-ROMA RISC-V Mainboard II) for the Framework 13 laptop shell with RISC-V 64-bit 8-core CPU up to 2.0GHz with SiFive P550 CPU cores.

SiFive's P550 application processor has a 13-stage pipeline, triple-issue, out-of-order pipeline compatible with the RISC-V RV64GBC ISA. ARM Cortex A72 class with triple-issue and out-of-order processing.

68060's 8-stage pipeline is not enough when SiFive's P550 has a 13-stage pipeline with 2 GHz clock speed. SiFive's P550 RISC-V implementation is not free i.e. must be paid.

PS: I have a Framework 13 laptop with an AMD R7 mainboard.

Quote:

Emulation is easier but not cheaper than a mass produced ASIC! A real 68k SoC ASIC would use a fraction of the resources of an ARM SoC.

Existing ARM SoC has the fractional financial risk of an independent 68040/68060 ASIC clone design. The best FPGA 68K clone has yet to implement 68K MMU, hence they are 68EC0x0 clones with FP64.

Raspberry Pi started from Broadcom's mostly cut-and-paste engineered ARM-based SoC.

Last edited by Hammer on 16-May-2025 at 03:42 PM.
Last edited by Hammer on 16-May-2025 at 03:37 PM.
Last edited by Hammer on 16-May-2025 at 07:09 AM.
Last edited by Hammer on 16-May-2025 at 06:44 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

matthey wrote: Emulation is easier but not cheaper than a mass produced ASIC! A real 68k SoC ASIC would use a fraction of the resources of an ARM SoC. Emulation is a resource hog requiring much higher performance CPU cores, more caches, more memory, more power, larger power supplies, more cooling, more cost, etc.

Certainly a 68k SoC ASIC doesn't use as many resources when running, but what about development? With the millions you spend designing and making the SOC you could have bought thousands of mini PCs or whatever to run an emulator on.

X68000 emulators are already here and even open source. All you need is some existing hardware powerful enough to run the emulator. People who aren't picky about what the hardware looks like can simply run it on a PC. Most people already have a PC so the cost is zero. If you want a dedicated emulator box then just get an old PC, which are practically free these days.

Quote:

The problem is that most retro gaming businesses are looking to turn a quick profit rather than invest in a sustainable retro market with high quality products. The closest are some high quality FPGA products like Analogue.

No, the problem is the market for high quality retro products is very small. Hardcore retro enthusiasts rightly on insist having original hardware, and the masses aren't interested enough to pay big bucks for it. That leaves only a tiny number of fans who have the money and don't care that the hardware is nothing like the original and so has no historical value.

Quote:

These guys get it. They have trouble keeping their products in stock and it is not unusual for the ones out of stock to sell for more than the original price.

This is par for retro products. The reason they run out of stock is that there isn't enough money in it to build up inventory. It's not like toilet paper where there's a continuing demand, sooner or later the market will saturate and you could be left with product you can't sell that wipes out all your profit. So you raise just enough cash to make one batch and hope like hell that you can sell it all at sufficient margin. Assuming you do, you then have to decide whether to risk it again. In many cases the return isn't enough to justify continuing, or even worse is a net loss.

A SoC may be technically superior but in reality emulation on more powerful hardware is winning. That hardware is getting even more powerful and cheaper too, so eventually SoC will have no advantage. For example a PiStorm with the latest RPi is fast enough to emulate an Amiga 500 at full speed running in a window on the Amiga's (Pi RTG) WorkBench. So the ARM CPU is emulating a 68k CPU which is then emulating an entire Amiga including the 68000 CPU and all hardware.

Economy of scale is far more important than you might think. Despite the greater complexity of an RPI it can still sell for less than your 'more efficient' SoC because when making millions at a time the unit cost is peanuts. if the chip yield is high (which it should be at these quantities) it doesn't really matter what's on it - it's just silicon. Add to that a software emulator which is essentially hardware agnostic and it can adapt to whatever new host hardware becomes available. Meanwhile you are stuck trying to sell enough of your immutable SoC's to break even.

Last edited by bhabbott on 16-May-2025 at 08:31 AM.

@matthey

there will be no new 68k soc.
not enough new customers in 68k retro community.
in industry everybody who want to still use 68k like already switch to coldfire.

@ppcamiga1

Quote:

here will be no new 68k soc.

RISC-V is the new darling in low-performance embedded markets. Despite 68K being obsolete, NXP is not moving the 68040 into open source.

https://websrv.cecs.uci.edu/~papers/mpr/MPR/19971229/111702.pdf
From 1997,

Motorola Buys Reverse-Engineered 68000

Motorola has signed an exclusive licensing agreement for a
reverse-engineered version of its own 68000 microprocessor
core. The new core runs unmodified 68000 binary code an
average of 4× faster than the 68000 itself, according to Motorola.

Application-specific chips based on the new design
should start appearing in the middle of 1998.
Motorola licensed the core from the small Japanese
design firm of Excellent Design (EXD) of Yokohama. In its
seven-year history, EXD had previously developed synthesizable
versions of 8-bit CPU cores, a PCI interface, and video
encoding and decoding circuits. The new 68000 was not
entirely a clean-room design;

Motorola provided some assistance in the later stages of its development.
The new core adds another weapon to the Motorola
arsenal, but it also casts a shadow over ColdFire, which
Motorola spent years developing for essentially the same purpose:
to provide ASIC customers with better performance while
maintaining some level of 68K compatibility

(skip)

New Core Faster Than 68000, But Slightly Bigger
The new core is completely object-code-compatible with the
original 68000 chip. Unless programs include software timing
loops, existing binaries will run unmodified—but faster. The
new core executes many 68000 instructions in a single cycle,
compared with 4–24 cycles for a standard 68000 chip. The
core’s interface also supports single-cycle bus transactions,
versus the four-cycle bus on the original Motorola part. After
simulating several benchmarks, Motorola arrived at an
average performance improvement of 4:1 compared with a 68000
running at the same clock frequency

(skip)

Anyone Can Design, But Motorola Must Build
Under the terms of the agreement, Motorola retains exclusive
worldwide rights to manufacture parts using the 68000-
compatible core. Other ASIC customers can still license and
design with EXD’s core, but any resulting chips must be
manufactured on Motorola fab lines

Motorola can sub-license the core to allow other semiconductor vendors to
build EXD-based chips


This is comical when Motorola buys out a faster 68000 re-implementation clone.
Motorola blocks independent 68K clones i.e. Motorola must be involved in the loop.

It's largely too late for 68K desktop vendors.

I can understand RISC-V as a f__k you against Motorola's must be involved in the loop mindset.

Last edited by Hammer on 16-May-2025 at 03:26 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

Synthesized TG68 into an ASIC wouldn't be able to run PMMU Linux for the Ubuntu port.

Modern Ubuntu port would want a multiple-core CPU per cluster design.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Hammer Quote:

The original Amiga ideology involved outsourcing CPU needs to other companies.

The original Amiga Corporation could choose any CPU they wanted for the Amiga. Amiga software uses the 68k CPU and any change away from it, the Amiga chipset or the AmigaOS, loses the large retro Amiga market. There is no adequate commodity 68k hardware available so there are 3 options I can think of.

1. outsource/contract a business to develop hardware to the required specs
2. develop the hardware from scratch as a fabless semi business
3. license existing 68k hardware and develop as a fabless semi business

I prefer option #3 if possible. A fabless semi businesses has potential to increase in value and can continue to make enhancements while licensing saves times, provides maximum compatibility, provides credibility and provides a professional foundation. The RPi MCUs, SiFive SoCs and Vortex86 SoCs are examples of what were originally small fabless semi business developments along the lines of what a 68k SoC needs to become competitive. Some of these small fabless semi businesses have become valuable and others have been bought out like P. A. Semi or there would be more.

Hammer Quote:

L1 instruction cache's 4 bytes per cycle fetch is a major bottleneck for 68060's dual integer pipelines. SysInfo benchmark easily steps on 68060's L1 cache bottleneck. AC68080 fixes the "low-hanging fruit" 68060's L1 instruction cache 4-byte fetch bottleneck for dual integer pipelines. Both AC68080 and 68060 have dual integer pipelines.

My 68060 "low-hanging fruit" performance improvements in the order I expect is important for integer performance.

1. larger caches and buffers
2. better superscalar execution
a) increase the 6 byte/instruction limit (even 8 byte/instruction would be a big improvement)
b) add more superscalar capable instructions like SWAP and ColdFire instructions
c) allow PC relative addressing mode in either OEP and support (bd,An,Rn*SF)
3. increase to 8B/cycle instruction fetch
4. add hardware return stack
5. bring back missing integer 64-bit MUL and DIV

That should be enough to compete in performance with limited OoO PPC cores again using a similar process.

Hammer Quote:

AC68080's concurrent dual integer and floating point pipelines show its strength with titles like Quake, less with heavy floating point Lightwave. Lightwave's heavy floating-point workload shows that AC68080's FPU wasn't multi-pipelined (any updates on this issue?).

Lightwave uses many 6888x instructions that are trapped on the 68060. I do not know how the AC68080 handles them besides the AC68080PRM description of "Slow microcode float instructions". The SAS/C code for the 6888x was not even optimal for the 6888x.

Hammer Quote:

I don't recall a full 68030 FPGA implementation that includes PMMU. This is important for PMMU Linux compliance. VexRISCV FPGA has an MMU implemented, hence it can run PMMU Linux. SiFive U74 has PMMU Linux compliance.

A MMU in an ASIC needs path delay analysis and optimization as the timing is critical in places. The inefficient routing in a FPGA may slow the core clock speed more than an ASIC which is likely why many FPGA cores omit them.

Hammer Quote:

https://websrv.cecs.uci.edu/~papers/mpr/MPR/19971229/111702.pdf From 1997, ... This is comical when Motorola buys out a faster 68000 re-implementation clone. Motorola blocks independent 68K clones i.e. Motorola must be involved in the loop. It's largely too late for 68K desktop vendors.

The 68000 patents were still valid in 1997 and Motorola sold 79.3 million 68k chips that year into the embedded market. They had a large enough market to protect but they may have wanted to use it in the few 68k designs they were still producing. They did not have a logical product development plan as the 68k was still the best selling 32-bit architecture in the world, they were pushing and spending on PPC development in the higher end of the embedded market and scaling the 68k down into ColdFire where PPC was too fat to scale. It sure looks like they sabotaged everything 68k above ColdFire including possibly from external sources in order to try to achieve economies of scale for PPC. Maybe Motorola thought they were winning as PPC sales increased by 138% from 1996 to 1997 while 68k sales only increased by 44%. The 68k sales increase was 24 million chips compared to PPC 3.4 million chips though.

RISC Volume Gains But 68K Still Reigns
https://websrv.cecs.uci.edu/~papers/mpr/MPR/19980126/120102.pdf

It would have been nice to know how much Motorola was spending on 68k, ColdFire and PPC development during the 1990s. It looks like the 68k was the unfunded big revenue generator, PPC was the development recipient and ColdFire was a low budget handicapped and castrated can't mention the 68k architecture development. Political based development instead of technical based development was a good way to kill the 68k and give up the embedded market.

bhabbott Quote:

Certainly a 68k SoC ASIC doesn't use as many resources when running, but what about development? With the millions you spend designing and making the SOC you could have bought thousands of mini PCs or whatever to run an emulator on.

You are right. ARM should have looked at the 68k economies of scale and dropped out of the market. Even after Motorola practically stopped development of the 68k, the 68k went on outselling ARM for many years. In 1997, it was 79.3 million 68k chips to ARM's 4th place 10 million chips.

bhabbott Quote:

X68000 emulators are already here and even open source. All you need is some existing hardware powerful enough to run the emulator. People who aren't picky about what the hardware looks like can simply run it on a PC. Most people already have a PC so the cost is zero. If you want a dedicated emulator box then just get an old PC, which are practically free these days.

Many people settle for less when they can not get the real thing.

bhabbott Quote:

No, the problem is the market for high quality retro products is very small. Hardcore retro enthusiasts rightly on insist having original hardware, and the masses aren't interested enough to pay big bucks for it. That leaves only a tiny number of fans who have the money and don't care that the hardware is nothing like the original and so has no historical value.

The market for high quality retro products is based on the price which is high with large FPGAs.

bhabbott Quote:

This is par for retro products. The reason they run out of stock is that there isn't enough money in it to build up inventory. It's not like toilet paper where there's a continuing demand, sooner or later the market will saturate and you could be left with product you can't sell that wipes out all your profit. So you raise just enough cash to make one batch and hope like hell that you can sell it all at sufficient margin. Assuming you do, you then have to decide whether to risk it again. In many cases the return isn't enough to justify continuing, or even worse is a net loss.

There is more demand and more consistent demand when lowering the price. ASICs have a big advantage here for CPU performance as can be seen in RPi demand not saturating.



That is a nice curve with competitive hardware from using an ASIC.

bhabbott Quote:

A SoC may be technically superior but in reality emulation on more powerful hardware is winning. That hardware is getting even more powerful and cheaper too, so eventually SoC will have no advantage. For example a PiStorm with the latest RPi is fast enough to emulate an Amiga 500 at full speed running in a window on the Amiga's (Pi RTG) WorkBench. So the ARM CPU is emulating a 68k CPU which is then emulating an entire Amiga including the 68000 CPU and all hardware.

The "more powerful hardware winning" is a ARM SoC ASIC and the reason it is being used is because there is not a competitive 68k SoC ASIC.

bhabbott Quote:

Economy of scale is far more important than you might think. Despite the greater complexity of an RPI it can still sell for less than your 'more efficient' SoC because when making millions at a time the unit cost is peanuts. if the chip yield is high (which it should be at these quantities) it doesn't really matter what's on it - it's just silicon. Add to that a software emulator which is essentially hardware agnostic and it can adapt to whatever new host hardware becomes available. Meanwhile you are stuck trying to sell enough of your immutable SoC's to break even.

I preach/rant about integration and economies of scale. Where have you been?

@matthey
Quote:

The original Amiga Corporation could choose any CPU they wanted for the Amiga. Amiga software uses the 68k CPU and any change away from it, the Amiga chipset or the AmigaOS, loses the large retro Amiga market. There is no adequate commodity 68k hardware available so there are 3 options I can think of. 1. outsource/contract a business to develop hardware to the required specs 2. develop the hardware from scratch as a fabless semi business 3. license existing 68k hardware and develop as a fabless semi business I prefer option #3 if possible. A fabless semi businesses has potential to increase in value and can continue to make enhancements while licensing saves times, provides maximum compatibility, provides credibility and provides a professional foundation. The RPi MCUs,

RPi RP2040 is mostly ARM IP cut-and-paste. RPi is the UK's MediaTek (Taiwan) wannabe.

RPi's main products are still Broadcom SoCs with cut-n-paste ARM CPU cores and in-house graphics IP i.e. Broadcom VideoCore series.

RPi is minority owned by Softbank(JP)'s ARM Holdings.

Quote:

SiFive SoCs

SiFive designs CPU cores and has weak GPU R&D. StarFiveTech combines SiFive CPU cores with Imagination Technologies GPU IP (state-owned by the CCP government).

StarFiveTech is partly owned by the CCP's Hong Kong government.


Quote:

and Vortex86 SoCs are examples of what were originally small fabless semi business developments along the lines of what a 68k SoC needs to become competitive. Some of these small fabless semi businesses have become valuable and others have been bought out like P. A. Semi or there would be more.

DM&P Electronics Vortex86 SoCs have a 2D graphics core. X86-64v1 has exited US patent protection sometime in 2023.

https://chipsandcheese.com/p/the-weird-and-wacky-world-of-via-the-3rd-player-in-the-modern-x86-market
X86 still has VIA and Zhaoxin (state-owned by the CCP government).

VIA holds an x86 license which allows its subsidiaries to produce compatible microprocessors; this allows Zhaoxin to develop x86 computer chips.
Zhaoxin Lujiazui uarch lost Intel AVX2 in 2019.


Quote:

My 68060 "low-hanging fruit" performance improvements in the order I expect is important for integer performance. 1. larger caches and buffers 2. better superscalar execution a) increase the 6 byte/instruction limit (even 8 byte/instruction would be a big improvement) b) add more superscalar capable instructions like SWAP and ColdFire instructions c) allow PC relative addressing mode in either OEP and support (bd,An,Rn*SF) 3. increase to 8B/cycle instruction fetch 4. add hardware return stack 5. bring back missing integer 64-bit MUL and DIV That should be enough to compete in performance with limited OoO PPC cores again using a similar process.

Who is going to do it?

FPGA TG68 is only 68020 ISA-compliant i.e., missing MMU and FPU.

Quote:

Lightwave uses many 6888x instructions that are trapped on the 68060. I do not know how the AC68080 handles them besides the AC68080PRM description of "Slow microcode float instructions". The SAS/C code for the 6888x was not even optimal for the 6888x.

Use MuRedox https://aminet.net/package/util/boot/MuRedox


MuRedox is a MuLib based "on the fly" speedup patch for 68040
and 68060 based Amiga boards. The 68040 and 68060 do not implement
all instructions of the MC 68K family. The unimplemented instructions -
mainly FPU instructions - generate an exception and need to be
emulated by the 68040 resp. 68060.library. This is the job of the so-
called "FPSP routines" (floating point support package) within the
CPU libraries. MuRedox detects these instructions as soon as they
generate the emulator exceptions, runs a "just-in-time" compiler
that generates a "stub replacement routine" for this specific
instruction and patches the replacement routine into the running
program. Hence, MuRedox replaces the overhead of the emulator
trap on the next use of the same instruction sequence.


MuRedox minimizes the trap instruction overheads.

For less-used instructions, 68060 doesn't have Pentium Pro's microcode decoder path.

Any revised 68060+ would need to gain a microcode decoder path for running unimplemented instructions with minimal trap overheads and in-the-field bug fixing via microcode firmware update.

Quote:

A MMU in an ASIC needs path delay analysis and optimization as the timing is critical in places. The inefficient routing in a FPGA may slow the core clock speed more than an ASIC which is likely why many FPGA cores omit them.

My cited RV32 ASIC examples are running mostly automated software tools.

https://www.jeffgeerling.com/blog/2025/sifives-hifive-premier-p550-strange-powerful-risc-v-board
Benchmark for SiFive P550 quad cores with Radeon RX 460, Witcher 3 at 2.5 fps. The game was heavily CPU-bound, as all four cores were going 100%, and the GPU was almost idling between 8-12%.

That's a long way from a modern gaming PC.

Quote:

The 68000 patents were still valid in 1997 and Motorola sold 79.3 million 68k chips that year into the embedded market.

That's mostly low-end 68K SKUs. I'm still waiting for the annual 3.5 million 68060 sales data.

Quote:

They had a large enough market to protect but they may have wanted to use it in the few 68k designs they were still producing. They did not have a logical product development plan as the 68k was still the best selling 32-bit architecture in the world, they were pushing and spending on PPC development in the higher end of the embedded market and scaling the 68k down into ColdFire where PPC was too fat to scale. It sure looks like they sabotaged everything 68k above ColdFire including possibly from external sources in order to try to achieve economies of scale for PPC. Maybe Motorola thought they were winning as PPC sales increased by 138% from 1996 to 1997 while 68k sales only increased by 44%. The 68k sales increase was 24 million chips compared to PPC 3.4 million chips though. RISC Volume Gains But 68K Still Reigns https://websrv.cecs.uci.edu/~papers/mpr/MPR/19980126/120102.pdf

That's a retro 1998 paper.

NXP has moved into 16-bit length ISA-equipped PPC.

Last edited by Hammer on 17-May-2025 at 03:07 PM.
Last edited by Hammer on 17-May-2025 at 02:49 PM.
Last edited by Hammer on 17-May-2025 at 05:02 AM.
Last edited by Hammer on 17-May-2025 at 05:01 AM.
Last edited by Hammer on 17-May-2025 at 04:25 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

You are right. ARM should have looked at the 68k economies of scale and dropped out of the market. Even after Motorola practically stopped development of the 68k, the 68k went on outselling ARM for many years. In 1997, it was 79.3 million 68k chips to ARM's 4th place 10 million chips.

For 1996 time period, ARM had StrongARM PDA market to drive +100MHz CPU use case and sales. StrongARM was followed by ARM's ARM9T +100Mhz.

StrongARM is 68040 class CPU with 100+ Mhz clock speed that is suited for application handheld devices. This was the beginning of ARM's smart handheld device revolution.

68060 wasn't friendly for handheld devices.

A 68000-compatible clone with 1 IPC implementation was locked up by Motorola's control.

Where's your 68060's annual sales data?

EXD’s 1 IPC fast 68000 core could have competed against StrongARM instead of the about 0.25 IPC classic 68000-based Dragon Ball VZ series.

Last edited by Hammer on 20-May-2025 at 02:02 AM.
Last edited by Hammer on 17-May-2025 at 02:58 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

matthey wrote: cdimauro Quote: More close to a simple 3-way OoO. I am talking about simple/limited RISC OoO. The 68060 has the integer firepower to compete with some limited OoO RISC 4-way CPUs. It has some low power limitations but the performance potential is there. 68060 (peak issue 2+branch; like RISC 4+branch) 2x integer unit (like RISC 4x integer unit) 2x load/store unit 1x branch unit 1x FPU PPC603 2-way (peak issue 2+branch) 1x integer unit 1x load/store unit 1x system-register unit 1x branch unit 1x FPU PPC604 4-way (peak issue 4) 2x simple integer unit 1x complex integer unit (includes system-register unit) 1x load/store unit 1x branch unit 1x FPU PPC G3 2-way (peak issue 2+branch) 2x integer unit 1x system unit 1x load/store unit 1x branch unit 1x FPU RISC OoO removes memory/cache latency but I qualified as "peak performance (no cache misses)" so no gain here. The idea is that small 68k Amiga programs with semi-modern cache sizes would not have many cache misses and without cache misses, an in-order 68k CPU would narrow the performance gap with RISC OoO CPUs while using fewer resources and less power. RISC OoO can remove dependencies too but many were created by RISC "simplification" while CISC uses nice packets of instructions that can be executed in pairs with no dependencies.

That's not enough to let a 2-way in-order 68k (or x86) compete with a 4-way OoO RISC design (even "simple") on the same regular applications (and I wouldn't talk about "peak" performance).

Intel's Atom has already shown that it's possible to get close to a simple 3-way OoO ARM design (which has quite complex instructions compared to other RISCs), which is quire representative of what CISCs processors could do against RISCs.

I don't think that it changes so much for a 68k processor.
Quote:

Quote: cdimauro Unfortunately, instructions decoding is also another big difference. In fact, RISC-V variable-length instructions are very simple and straightforward to be decoded (it's enough to take a loot at a few bits of the opcode, at the very beginning). 68ks and x86s are on a completely different level. Even the 68k and x86 decoding are significantly different. The x86 decoding is well documented as a simple loop while the 68k uses a table lookup. The Superscalar Architecture of the MC68060 Quote: The four-stage instruction fetch pipeline, which the FIFO instruction buffer decouples from the dual execution pipelines, performs the chip's instruction prefetch. The third stage is a table lookup that uses the 16-bit opcode to produce a 32-bit longword of decode information. It sounds simple enough and may not be that much different than decoding some RISC ISAs.

It's conceptually simple, but much more expensive even compared to an x86.

In fact, this LuT alone requires 16-bit * 4 bytes = 256kB of space. Which is an ENORMOUS amount, if you compare it to the size of the 68060's caches. Think about how many transistors are needed for implementing it, that you require two of such LuTs (or a dual-ported one?) to decode two instructions, and you can draw your conclusions.

RISC processors, even with variable lengths, don't certainly require something like that (usually the decoding logic is very very cheap, and requires some hundred gates).
Quote:

ColdFire used a "variable-length RISC architecture" just by limiting the 68k max instruction size to 6 bytes.

Probably it didn't use the same, very big, LuT as the 68060.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: In the meanwhile, WSL continues to be irrelevant/ not useful for the average Joe. Meanwhile, Google Play Games requires Windows Hypervisor Platform to be enabled, which is the same dependency as WSL.

Whatever: that's not the/a problem.
Quote:

SteamOS 3.x targets the average PC gamer. SteamDeck's SteamOS 3.8 install image can be installed on an Intel-based x86-64v3 PC with an AMD NAVI GPU with minimal issues. PC gaming is not limited to Valve's Steam distribution platform since Epic Games' distribution platform reached about half of Steam's active account install base.

Irrelevant.
Quote:

Quote: That wasn't the point of THIS part of discussion. This topic is about raising funds for particular projects and "What If" remap for an independent 68K ASIC project. My post shows other startup examples e.g. Framework Computer Inc. is closer to Zuiki example. Both Framework Computer Inc. and Zuiki Inc. are startup system integrators, NOT another Motorola/Freescale Semiconductor wannabe.

Again, irrelevant: there are plenty of retro projects which used the same SoC of this "new" X68000, which are very very cheap. Which was the point of this part of the discussion.
Quote:

SiFive example has RISC-V-compatible ASIC designs and a funding magnitude. Deep Computing uses StarFiveTech's cut-and-paste engineered SoC with SiFive's RISC-V implementation, and designs the mainboard for Framework Computer Inc. (contracts with Compal ODM).

Irrelevant: the SoCs being used are ARMs and not RISC-Vs.
Quote:

The original Amiga Corporation has outsourced its CPU needs to Motorola Semiconductor. The original Amiga Corporation's aims are closer to NVIDIA i.e. mostly a graphics chipset design house. CSG provided chip fabrication services, and the C= system engineering group provided system integration. NVIDIA's Shield TV console and Founder Edition graphics cards are the closest relationship between NVIDIA and end users. Commodore management deleted the original Amiga's graphics chipset design house. Apollo Computers (AC68080 and SAGA) example is a Motorola/Freescale Semiconductor and a C= system engineering group wannabe.

Totally irrelevant.
Quote:

Matthey wants the "Amiga" idea to be converted into a Motorola Semiconductor wannabe or another Apollo Computers i.e. dislikes Gunnar von Boehn's direction.

Who likes the horrible patchwork that he created?

@Hammer

Quote:

Hammer wrote: @bhabbott Synthesized TG68 into an ASIC wouldn't be able to run PMMU Linux for the Ubuntu port. Modern Ubuntu port would want a multiple-core CPU per cluster design.

Drat. There goes my plan to take over the World!

@Hammer

Quote:

Modern Ubuntu port would want a multiple-core CPU per cluster design.

This sentence doesn't make much sense...

What do you mean with "would want"? What is "multiple-core CPU per cluster design"? Are you talking of multi-core CPUs? And what "cluster design" do you mean?

For what it's worth, Ubuntu works fine with single-core CPUs, however building Ubuntu for 32-bit CPUs is a no-go by today, as that was dropped half a decade ago already.

(Linux/68k has a couple of obstacles ahead to get it "up to par", one being changing default alignment from 2 to 4 bytes (already default on NetBSD/68k) and the other being the move to 64-bit for timestamps (and for large filesystems, large files etc) as 2038 is approaching. Both more or less require rebuilding everything from scratch.)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

What do you mean with "would want"? What is "multiple-core CPU per cluster design"? Are you talking of multi-core CPUs? And what "cluster design" do you mean?

The same layout as the SiFive P550 quad-core cluster example. This is a want, not a need.

Quote:

For what it's worth, Ubuntu works fine with single-core CPUs, however building Ubuntu for 32-bit CPUs is a no-go by today, as that was dropped half a decade ago already.

https://ubuntu.com/blog/lts-cra-arm
Bringing 12-year LTS to 32-bit Arm processors as CRA comes into force.

With the release of Ubuntu 24.04 LTS (Noble Numbat) and Ubuntu Core 24, Canonical introduced a 12-year Long Term Support commitment for 32-bit Arm® processors

Date: 20 January 2025.

Unlike 32-bit ARM, 32-bit X86 support was dropped.

Google AI: Ubuntu provides developer images specifically for RISC-V, including RV32, enabling users to run a full desktop or server experience.
Reference: https://ubuntu.com/download/risc-v

RV32 = 32bit RISC-V

https://archlinux32.org/
Maintained Arch Linux for 32-bit x86 i.e. i686 and Pentium IV.

Last edited by Hammer on 20-May-2025 at 01:23 AM.
Last edited by Hammer on 20-May-2025 at 01:19 AM.
Last edited by Hammer on 20-May-2025 at 01:15 AM.
Last edited by Hammer on 20-May-2025 at 01:11 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

Whatever: that's not the/a problem.

The same "Virtual Machine Platform" dependency needs to be enabled.

You're making a big deal about the Windows Subsystem for Linux and Google Play Games name difference.

For normal end users, the end goal with Windows Subsystem for Linux is Windows Subsystem for Android, which MS has ended support for. The primary driver is running 3rd-party apps and games.

Google Play Games for Windows is the official method from Google Inc.

Quote:

Irrelevant

It's relevant since it has the Linux foundation with a different middleware focus, i.e., targeting Windows DirectX closed-source games.

Android also has Linux foundations with Google's middleware.

Linux port + Box64 port + Radeon driver port enables little-endian hardware platforms to run Steam games. This is relevant for this topic's source link's fallback feature.

Quote:

Again, irrelevant: there are plenty of retro projects which used the same SoC of this "new" X68000, which are very very cheap. Which was the point of this part of the discussion.

For *this* topic, this project is not purely "retro" when this Japanese project includes a mainstream OS platform fallback feature, which is clearly stated in the source website. Your excuse is that you can't read Japanese.

This project has a retro X68000 theme with modern mini-PC system integration. Mini-PC form factor is a major virtue in the Japanese market. Most gamers don't care about the hardware guts, they only care about the delivered gaming experience within their budget.

Only the extremists care about the hardware guts.

Unlike Zuiki's projects, the specific ASIC C64 joystick is effectively a dead-end eWaste toy since it has no fallback use case to run a mainstream desktop OS.

----------------------------------
For Zuiki's initial 2022 project:
https://retrolike.net/2023/10/29/the-zuiki-x68000z-the-minimized-powerhouse/
The cost for X68000Z tiers and packs

On June 8, 2023, Zuiki opened pre-orders for the consumer-level X68000Z through various platforms. Including Amazon Japan, BEEP, and select department stores and retailers. They offer three distinct packages:

Starter Pack (Â¥29,935 / $200 US): This basic package includes the computer, a joypad, and copies of Gradius and Human 68K Version 1.01. Despite its simplicity, all the computers in this tier are identical, regardless of which package you choose.

Basic Pack (Â¥65,780 / $439): The Basic Pack comprises everything from the Starter Pack, adding a keyboard and mouse specifically designed for this computer. The keyboard is a faithful replica of the original down to the buttons and weight. This package provides a more comprehensive experience but comes at a higher price.

Complete Pack (¥87,780 / $586): For those seeking the ultimate X68000Z experience. The Complete Pack includes everything mentioned in the other sets. Most interesting addition is is the five-inch monitor replicating the 1987 original 14″ version. This replica monitor maintains the 4:3 aspect ratio of the original CRT screen but features an HDMI connection and a resolution of 1024×768 pixels. It can also be used with other hardware that supports this resolution. Additionally, this package comes with a UART cable, a serial I/O interface for connecting original accessories.



Bundled X68000 games have proper licenses.

Production scale can be estimated from revenue generation vs unit price.

US$24,131,274.13 / $439 = about 54,968 unit production scale.

US$24,131,274.13 / $200 = about 120,656 unit production scale.

Zuiki developed a semi-custom SoC with ARM-based Z7213 SoC (System-on-a-Chip), which is based on Allwinner R16 + Mali GP-400 SoC.

For 2022, the Japanese market can tolerate Zuiki's initial offer i.e. "what the market will bear" basic economics 101.

It's similar to Mac 68K's audience, which they can tolerate Apple's higher prices, being driven by Mac's consistent GUI design, productivity software, and baseline stable high resolution i.e. they are not Amiga's demographics.

The majority of Amiga's demographics are in Europe, with weaker buying strength.

I'm on topic, you're not.

Last edited by Hammer on 20-May-2025 at 02:42 AM.
Last edited by Hammer on 20-May-2025 at 02:37 AM.
Last edited by Hammer on 20-May-2025 at 02:32 AM.
Last edited by Hammer on 20-May-2025 at 02:20 AM.
Last edited by Hammer on 20-May-2025 at 02:16 AM.
Last edited by Hammer on 20-May-2025 at 02:15 AM.
Last edited by Hammer on 20-May-2025 at 02:06 AM.
Last edited by Hammer on 20-May-2025 at 02:06 AM.
Last edited by Hammer on 20-May-2025 at 02:01 AM.
Last edited by Hammer on 20-May-2025 at 01:55 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Hammer wrote: Most gamers don't care about the hardware guts, they only care about the delivered gaming experience within their budget. Only the extremists care about the hardware guts.

If that is true then the presentation of this 'X68000' machine is even more puzzling. If they don't care about 'hardware guts' then why the fake case? Just buy a standard mini PC and run an emulator on it.

BTW I feel the same about the TheA500 Mini (which seems to be out of production now). I was going to buy one so I could be part of the next generation of new 'Amiga' owners when it became wildly popular. The Warehouse was supposed to be stocking it, but when I went there they had none and weren't getting any. Another trinket I avoided wasting my money on.

Now I have to decide if I really want those Amiga-branded ball-point pans that cost NZ$30 each landed, perhaps along with an Amiga-themed mouse pad. Should go well with my Amiga cap and tie pin, and very rare NZ Amiga magazine from the 90's!

If this hardware fetish makes me an extremist then so be it. But if I just wanted to play games and didn't care about hardware I would just use my existing PC. Minimum cost, built-in fully configured 'fallback' and it plays the latest PC games too! (well OK, maybe not the latest games, on a 10 year old PC running 32-bit Linux).