@matthey

Quote:

matthey wrote: cdimauro Quote: Do you know where she got the 68k RTL, and which kind of architecture (68000, or 68020, or...)? I believe Jeri reverse engineered the Amiga custom chips. Maybe reading the documentation about the behavior, measuring outputs and replacing functionality piece by piece. The following link is the video about it again. The Amiga on a Chip Project - Too bad it was canceled https://www.youtube.com/watch?v=5uaDzF99a80 She says the Amiga custom chip design was more straight forward than the C64 design making it easier and then when she received the schematics it likely helped with final debugging. She had everything working from FPGA but the 68000 and Paula floppy controller. There have been several other Amiga chipset reverse engineered cores as well including at least 3 with AGA support and likely no schematics. I believe Jeri's Amiga on a chip was OCS/ECS only. How many times does the wheel need to be reinvented instead of improved?

Getting the original schematics avoids reinventing the wheel.

The video explained everything, thanks. Then no synthetic 68000 was available.

However, having the complete, original, chipset (OCS/ECS, yes) in RTL (for FPGA, but in this case it was also ready to be converted to ASIC) is a great value if the goal is to get a perfect replica of the system.
Quote:

cdimauro Quote: But they aren't specialized on CISC microarchitectures. It is mostly the CPU cores that are CISC specific while the majority of a SiFive SoC could likely be reused for a 68k SoC.

They are hardware engineers, so they work also on CISC chips, but their RISC-V design is very different from the 68k ones (including a 68060).

To be more clear, patching the processor's frontend by checking for instructions patterns to reduce the load-to-use stalls is very different from how our beloved CISCs work (those stalls are naturally reduced by the intrinsic nature of CISC architecures: without any instructions pattern matching).
Quote:

The major gain is all the tested semi-modern I/O functionality most likely with open source Linux drivers. I expect the bigger question is not the integration of 68k CPU cores but the integration of the Amiga chipset I/O and DMA, which is like a SoC, with the SiFive SoC. The SiFive SoC is modular so the modules could be integrated into the Amiga chipset or the SiFive SoC could be left mostly as is with the Amiga chipset integrated. There are advantages and disadvantages to both and the decision would be influenced by hardware engineers.

The best thing would be to leave out the chipset from the SoC and move it to a small FPGA. Everything else (included I/O and memory controller) can stay on the SoC.

This to give full flexibility on how to implement (and also evolve) the chipset.
Quote:

cdimauro Quote: The PULP team in Zurich is more interesting, because their RISC-V extensions have more in common with 68k (post increment modes, load/store multiple registers... and even hardware loops). There are potentially multiple teams that could perform the work. I believe the SiFive architects are good enough but the best ones may remain on their core development. I believe the SiFive 7 series CPU cores use a good CISC like design that could be turned into a 68k design.

No. See above on this.
Quote:

Licensing original Motorola cores would save time, be better for compatibility and be better for marketing.

A synthetic 68000 is definitely needed. A more advanced 68k doesn't need to be perfectly compatible with 68020+ processors, because this isn't usually required (and there are techniques to artificially limit the processor performance).
Quote:

The SiFive 7 series cores could be used to improve the Motorola cores if they were included with the SoC. SiFive could likely take the original Motorola 68k cores and insert them into a SiFive SoC.

Removing the RISC-V cores, I hope.
Quote:

I prefer creating a small team and fabless semi business which I believe has significant potential to increase in value with successful and popular designs. I would seek input and help from former Motorola 68k employees which could not only be valuable for their input but also give legitimacy to a successor. The same could be done with Amiga Corp and Commodore employees/engineers involved in continued development of the Amiga chipset. Involvement from developers like Jeri would apply too.

Likely. As we have seen, there's still a lot of love and passion for those retro devices, so some "old fart" could join for the revival of the platform.
Quote:

cdimauro Quote: The Amiga market isn't enough IMO, especially after the the Mini A500. It's better to think more widely, because there were several other 68k platforms. That's why I've recommended to integrate a plain 68000 core with one or more enhanced 68k core, and a small FPGA to emulate the chipset of the given system. This should cover many of such platforms. I have been talking about universal 68k support and a 68000 core for compatibility for awhile too. Kind of like the MiSTer/Multisystem but with real 68k cores and a smaller cheaper FPGA for chipsets and 8-bit CPU cores.

8-bit CPU cores are so small that probably can be implemented using the FPGA.
Quote:

I have also talked about embedded markets which is not possible with the MiSTer/Multisystem but is possible with a 68k SoC ASIC. A small FPGA is useful for embedded use or it can be left off the SBC.

*
Quote:

I also like the idea of turning caches into addressable SRAM so the SoC could be used as a MCU.

All caches, or a portion? Because there are pros and cons about having the SRAM used as memory.

IMO an hybrid configuration (part as memory, part as cache) has a better value (and that's what I've planned on my new architectures).

@kolla

Quote:

kolla wrote: @cdimauro Quote: That's why I've recommended to integrate a plain 68000 core with one or more enhanced 68k core, and a small FPGA to emulate the chipset of the given system. This should cover many of such platforms. So you want the MiSTer: select 68000 as CPU in the Minimig core and you get ljor’s cycle-exact Fx68k CPU core, and you select 68020 you get the less cycle-exact TG68/020.

The idea is to have more cores which can ALSO be used at the same time (multi core system), but yes, more or less like that.

However the 68k+ core should be much faster than the TG68/020.

The Fx68k seems the solution to one of the two problems (perfect 68000 core and perfect Amiga chipset). It has just one thing which is missing, but that probably can be added.
Its biggest problem is the license: GPLv3 is certainly NOT commercial-friendly...
Quote:

Why a dedicated small FPGA for chipset?

To be programmable, of course.
Quote:

Why use two FPGAs when there’s enough space in one?

No, the idea is to have a single chip (SoC) with everything, to reduce the costs.

Even if you've an ASIC, it can have inside multiple 68k cores and a small FPGA embedded. This gives maximum performance for the CPU core and maximum flexibility for the chipsets emulation.
Quote:

As for AmiCube, from what I recall, it has this “swirch board� that lets you chose between real two DIP64 sockets, one for 68000 and one for either PiStorm or other accelerator.

That's exactly NOT the scope of the project. See above.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: It is ridiculously expensive for such poor hardware. Anyway, the main problem for the Amiga is getting some professional to design a 68k ASIC. But I think that with a budget of more than $24 millions it shouldn't be that difficult. If you read from https://kibidango.com/2716

It's difficult to read Japanese. And I've no time now also for a translation.
Quote:

The Windows X64 fallback use case is a risk reduction tactic for the end user.

So, if you are not satisfied with the X68000, you can use it as a regular PC with Windows?

cdimauro Quote:

They are hardware engineers, so they work also on CISC chips, but their RISC-V design is very different from the 68k ones (including a 68060). To be more clear, patching the processor's frontend by checking for instructions patterns to reduce the load-to-use stalls is very different from how our beloved CISCs work (those stalls are naturally reduced by the intrinsic nature of CISC architecures: without any instructions pattern matching).

Normally I would say many CPU architects have no experience with CISC cores and little knowledge of them. However, the RISC-V 7 series in-order cores use a CISC like design that closely resembles the 68060 and Cyrix 6x86 designs. One of the major advantages of the design is zero cycle load-to-use penalty.

https://en.wikichip.org/wiki/sifive/microarchitectures/7_series#Key_changes_from_5_Series Quote:

0-cycle load-to-use latency (down from 1 cycle)

There are 4 major advantages to this design that I can think of.

o 0-cycle load-to-use latency
o early execution of instructions in the AGU/EAcalc stage removes/reduces dependencies/stalls
o more opportunities for instruction fusion/folding
o execution of CISC "op mem,Rn" and "op Rn,mem" instructions in the same pipeline with single cycle throughput

RISC ISAs do not gain the last advantage so this CISC like design is rare for RISC CPU designs. However, I believe the design is still a good design for RISC cores as the SiFive 7 series performance demonstrates even though it is a significantly better design for a CISC ISA. SiFive 7 series in-order cores are outperforming the PPC970/G5 OoO PPC cores in some benchmarks like 7-Zip compression/MHz and decompression/MHz and there are newer and higher performance versions of the 7 series CPU cores since the benchmarks.

cdimauro Quote:

The best thing would be to leave out the chipset from the SoC and move it to a small FPGA. Everything else (included I/O and memory controller) can stay on the SoC. This to give full flexibility on how to implement (and also evolve) the chipset.

Yes, it is the most flexible to use a FPGA for the retro chipsets. Still the default SiFive SoC hardware maps may interfere with the chipset hardware maps. There are various ways to deal with this. Also, it would be nice to have a default chipset for the hardware so it could be used as the control UI. There is more to consider than just load all chipsets into the FPGA.

cdimauro Quote:

A synthetic 68000 is definitely needed. A more advanced 68k doesn't need to be perfectly compatible with 68020+ processors, because this isn't usually required (and there are techniques to artificially limit the processor performance).

The 68000 core should be cycle exact for best compatibility and 68020+ cores do not need to be. Core clock speeds could be adjustable with full static designs (and multiple PLLs?). There are 68k accelerators which already have this. Caches can be disabled, self modifying code can be snooped, memory can have adjustable wait states, etc.

cdimauro Quote:

All caches, or a portion? Because there are pros and cons about having the SRAM used as memory. IMO an hybrid configuration (part as memory, part as cache) has a better value (and that's what I've planned on my new architectures).

The advantage of all SRAM is that no DRAM needs to be attached. This minimizes the hardware SBC and cost when a limited amount of memory suffices. SiFive 7 series SoCs allow this which works well with a decoupled instruction buffer like the 68060 and 7 series use but does not work well with cores that use predecode data in the L1 cache as has become more common. It should be possible to allow some of the memory to remain mapped as caches and some to be used as SRAM scratchpad memory. Some consoles used small SRAM scratchpad memory but I do not know that any 68k consoles did. A FPGA has SRAM blocks and may be able to configure very small amounts for some chipsets. Flexibility is good but has to have limits.

@matthey

Quote:

matthey wrote: cdimauro Quote: They are hardware engineers, so they work also on CISC chips, but their RISC-V design is very different from the 68k ones (including a 68060). To be more clear, patching the processor's frontend by checking for instructions patterns to reduce the load-to-use stalls is very different from how our beloved CISCs work (those stalls are naturally reduced by the intrinsic nature of CISC architecures: without any instructions pattern matching). Normally I would say many CPU architects have no experience with CISC cores and little knowledge of them. However, the RISC-V 7 series in-order cores use a CISC like design that closely resembles the 68060 and Cyrix 6x86 designs. One of the major advantages of the design is zero cycle load-to-use penalty. https://en.wikichip.org/wiki/sifive/microarchitectures/7_series#Key_changes_from_5_Series Quote: 0-cycle load-to-use latency (down from 1 cycle) There are 4 major advantages to this design that I can think of. o 0-cycle load-to-use latency o early execution of instructions in the AGU/EAcalc stage removes/reduces dependencies/stalls o more opportunities for instruction fusion/folding o execution of CISC "op mem,Rn" and "op Rn,mem" instructions in the same pipeline with single cycle throughput

I know this design, but it's very different from a regular CISC.

Yes, on a CISC core you need an AGU stage before the execution station, but that's it: you don't need anything else because and after that the processor can continue with the instruction execution (assuming the data is already available on the next cycle).

With the above RISC-V the processor needs to keep track of the previous instruction which entered the pipeline, annotate if it's a load instruction and what's the destination register, decode the current instruction, check if any of the source registers is matching the destination register of the previous instruction, check if the loaded data of the previous instruction is available and "pass" it to the current one continuing the execution (otherwise it has to stall).

All of this can be thrown away on a (in-order) CISC design.
Quote:

RISC ISAs do not gain the last advantage so this CISC like design is rare for RISC CPU designs. However, I believe the design is still a good design for RISC cores as the SiFive 7 series performance demonstrates even though it is a significantly better design for a CISC ISA. SiFive 7 series in-order cores are outperforming the PPC970/G5 OoO PPC cores in some benchmarks like 7-Zip compression/MHz and decompression/MHz and there are newer and higher performance versions of the 7 series CPU cores since the benchmarks.

Yes, it looks a great design to start with, but many hacks can be simply removed because they aren't needed ("CISC power").
Quote:

cdimauro Quote: The best thing would be to leave out the chipset from the SoC and move it to a small FPGA. Everything else (included I/O and memory controller) can stay on the SoC. This to give full flexibility on how to implement (and also evolve) the chipset. Yes, it is the most flexible to use a FPGA for the retro chipsets.

Just to be clear: it doesn't require to stay outside of the ASIC.

I was talking about a SoC and a small FPGA before, but the ASIC can have both on the same chip, which is a:
- cost advantage;
- simplification of the design;
- high performance.
Quote:

Still the default SiFive SoC hardware maps may interfere with the chipset hardware maps. There are various ways to deal with this.

Not a problem: remapping memory locations is trivial.
Quote:

Also, it would be nice to have a default chipset for the hardware so it could be used as the control UI. There is more to consider than just load all chipsets into the FPGA.

There UI might not be needed.

That's the reason why the embedded FPGA is there: to implement a display controller, if that's the case.
Quote:

cdimauro Quote: A synthetic 68000 is definitely needed. A more advanced 68k doesn't need to be perfectly compatible with 68020+ processors, because this isn't usually required (and there are techniques to artificially limit the processor performance). The 68000 core should be cycle exact for best compatibility

There's already one: Fx68.

The only problem is that it's GPLv3. But maybe the author could license it (and add the only behaviour which currently is missing).
Quote:

cdimauro Quote: All caches, or a portion? Because there are pros and cons about having the SRAM used as memory. IMO an hybrid configuration (part as memory, part as cache) has a better value (and that's what I've planned on my new architectures). The advantage of all SRAM is that no DRAM needs to be attached. This minimizes the hardware SBC and cost when a limited amount of memory suffices. SiFive 7 series SoCs allow this which works well with a decoupled instruction buffer like the 68060 and 7 series use but does not work well with cores that use predecode data in the L1 cache as has become more common. It should be possible to allow some of the memory to remain mapped as caches and some to be used as SRAM scratchpad memory. Some consoles used small SRAM scratchpad memory but I do not know that any 68k consoles did. A FPGA has SRAM blocks and may be able to configure very small amounts for some chipsets. Flexibility is good but has to have limits.

A small part used as scratchpad is ok, but not all. Caches are there for specific reasons that can't be ignored, if high-performance is the target.

Having all SRAM as scratchpad will not work out, unless you need a device like a DSP (which incompetent people are still advocating on some EAB threads) that has to carefully schedule the instructions execution for timing reasons (which is NOT our case, of course).

So, a flexible SRAM design is a requirement for this new SoC.

cdimauro Quote:

I know this design, but it's very different from a regular CISC. Yes, on a CISC core you need an AGU stage before the execution station, but that's it: you don't need anything else because and after that the processor can continue with the instruction execution (assuming the data is already available on the next cycle).

Technically, CISC core designs do not require an AGU stage before an execution stage in the pipeline but it gave a major performance advantage to CISC cores compares to RISC cores as now "op mem,Rn and "op Rn,mem" cached instructions could be executed with single cycle throughput and the longer pipeline could be clocked higher. The 68040 design was the first 68k design to add AGU/EA calc and AGU/EA fetch stages before the execute stage. The 68030 and earlier 68k designs used a shallower more RISC like pipeline looping through at least twice for AGU/EA calc in the execute stage and then execute in the execute stage requiring microcode that was not necessary for simple RISC designs (ARM and SuperH chose to use more powerful CISC like addressing modes so used microcode to loop through the pipeline multiple times as well). The longer pipeline 68040 and 68060 designs simplify the control logic but there is still resource tracking and complex dispatch dependency/hazard checking for the superscalar 68060.

The Superscalar Architecture of the MC68060 Quote:

Register scoreboarding, register renaming, and a robust resource crossbar minimize pipeline breaks. The operand execution pipeline performs operand writes after the instruction execution cycle in two additional pipeline stages; it updates the data cache during the write back cycle. The four bank data cache supports a simultaneous operand read and late-memory write during the same clock cycle, depending on address alignment.

CISC resource tracking and management is more complex but more powerful than RISC resource tracking. The in-order superscalar 68060 with 2 execution pipelines has peak performance (no cache misses) closer to a more complex 3-way or 4-way OoO superscalar RISC design than most 2-way in-order RISC designs. The 68060 can execute up to the equivalent of 5 RISC instructions per cycle and there are fewer dependencies than with RISC ISAs.

cdimauro Quote:

Yes, it looks a great design to start with, but many hacks can be simply removed because they aren't needed ("CISC power").

The SiFive 7 series core design is likely missing some support needed and used in a CISC design. The lack of RMW memory accesses is perhaps the largest difference. Instruction decode and dispatch conversion from RISC-V to 68k would likely be straightforward otherwise. Variable length instructions are already supported.

cdimauro Quote:

Just to be clear: it doesn't require to stay outside of the ASIC. I was talking about a SoC and a small FPGA before, but the ASIC can have both on the same chip, which is a: - cost advantage; - simplification of the design; - high performance.

Yes, integration is usually a cost advantage and it is possible to integrate FPGA functionality into a single ASIC. I do not know if eFPGA block licensing would be cost prohibitive but it should be considered if that is what you are talking about.

cdimauro Quote:

Not a problem: remapping memory locations is trivial.

I believe SiFive SoCs already support alternate memory mappings. I doubt there would be a major problem too.

cdimauro Quote:

There UI might not be needed. That's the reason why the embedded FPGA is there: to implement a display controller, if that's the case.

A display controller not in FPGA is a good idea as there would be no display output when switching FPGA cores or if there was a problem. Dual monitor HDMI outputs and an option for 15-pin VGA output for retro use should be considered. That way retro cores could have their own display and dual monitor displays have become common and expected. I have read 15-pin VGA can have lower latency than HDMI which is why a header on the board should be considered.

cdimauro Quote:

A small part used as scratchpad is ok, but not all. Caches are there for specific reasons that can't be ignored, if high-performance is the target. Having all SRAM as scratchpad will not work out, unless you need a device like a DSP (which incompetent people are still advocating on some EAB threads) that has to carefully schedule the instructions execution for timing reasons (which is NOT our case, of course). So, a flexible SRAM design is a requirement for this new SoC.

Caches are more system friendly with an OS than scratchpad memories and I much prefer them with SDRAM. More than usual flexibility would be desirable though.

Deeply integrated DSPs for specific uses are fine but for more general purpose digital signal processing, CPU SIMD/vector units have replaced DSPs for good reason.

So, have you guys started a crowdfunding for a 68k ASIC yet?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

matthey wrote: The Superscalar Architecture of the MC68060 Quote: Register scoreboarding, register renaming, and a robust resource crossbar minimize pipeline breaks. The operand execution pipeline performs operand writes after the instruction execution cycle in two additional pipeline stages; it updates the data cache during the write back cycle. The four bank data cache supports a simultaneous operand read and late-memory write during the same clock cycle, depending on address alignment. CISC resource tracking and management is more complex but more powerful than RISC resource tracking. The in-order superscalar 68060 with 2 execution pipelines has peak performance (no cache misses) closer to a more complex 3-way or 4-way OoO superscalar RISC design

More close to a simple 3-way OoO.
Quote:

than most 2-way in-order RISC designs.

In-order RISC designs have no chance, at all (even with more than 2 pipelines), to compete with a 68k or x86 2-way in-order design.
Quote:

cdimauro Quote: Yes, it looks a great design to start with, but many hacks can be simply removed because they aren't needed ("CISC power"). The SiFive 7 series core design is likely missing some support needed and used in a CISC design. The lack of RMW memory accesses is perhaps the largest difference. Instruction decode and dispatch conversion from RISC-V to 68k would likely be straightforward otherwise. Variable length instructions are already supported.

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.
Quote:

cdimauro Quote: Just to be clear: it doesn't require to stay outside of the ASIC. I was talking about a SoC and a small FPGA before, but the ASIC can have both on the same chip, which is a: - cost advantage; - simplification of the design; - high performance. Yes, integration is usually a cost advantage and it is possible to integrate FPGA functionality into a single ASIC. I do not know if eFPGA block licensing would be cost prohibitive but it should be considered if that is what you are talking about.

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.
Quote:

cdimauro Quote: There UI might not be needed. That's the reason why the embedded FPGA is there: to implement a display controller, if that's the case. A display controller not in FPGA is a good idea as there would be no display output when switching FPGA cores or if there was a problem. Dual monitor HDMI outputs and an option for 15-pin VGA output for retro use should be considered. That way retro cores could have their own display and dual monitor displays have become common and expected. I have read 15-pin VGA can have lower latency than HDMI which is why a header on the board should be considered.

I don't know this, but that wasn't the question. As I've stated before, there might not be the needed for a display, because it entirely depends on the project using the ASIC.

For cost reasons the single ASIC design might support a display output (even more than one, as you've explained), but its implementation should belong entirely to the FPGA (since this is part of the chipset).

@kolla

Quote:

kolla wrote: So, have you guys started a crowdfunding for a 68k ASIC yet?

Without professionals to support it?

Do you want to fail even before beginning?

@cdimauro

Quote:

So, if you are not satisfied with the X68000, you can use it as a regular PC with Windows?

That's correct. The project administrators have advertised Windows fallback as a risk reduction method for end users.

Anyway, Windows 11's Windows Subsystem for Linux (WSL) can run userland Linux applications.

A competent Linux LE desktop distro with Steam PC game compatibility can serve as a fallback.
Non-x64 Linux LE desktop distro can have Box64.

_________________
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: @cdimauro Quote: So, if you are not satisfied with the X68000, you can use it as a regular PC with Windows? That's correct. The project administrators have advertised Windows fallback as a risk reduction method for end users.

Which isn't interesting, rather a signal to customers that they might be disappointed with product (they are paying a lot of money for something which very likely hasn't that value).
Quote:

Anyway, Windows 11's Windows Subsystem for Linux (WSL) can run userland Linux applications.

Why should a customer use them?

I can, and I do, because sometimes (rarely, fortunately) I need it, but a regular Windows user has no reason to use WSL.
Quote:

A competent Linux LE desktop distro with Steam PC game compatibility can serve as a fallback. Non-x64 Linux LE desktop distro can have Box64.

See above: not interesting for Windows users (even because they already have plenty of software).

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: So, if you are not satisfied with the X68000, you can use it as a regular PC with Windows? That's correct. The project administrators have advertised Windows fallback as a risk reduction method for end users.

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.

@bhabbott

Quote:

You mean fail. Most people already have a Windows PC and don't need another one, especially one as limiting as this.

FYI, Windows 10 will reach end of support on October 14, 2025.

Intel AlderLake N (e-Cores) and AlderLake i5 (P-Core) models are Windows 11-compliant.

There are many non-Windows 11 PCs being dumped at Oz auction sites. It's a crazy amount of eWaste with laptop PCs.

Android / iOS phones are disposable eWaste after a few years due to EOL vendor OS support.

Satya Narayana's Microsoft will force the PC hardware upgrade issue despite the threats from Linux x64 desktop gains.

Quote:

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.

Another comparison, Framework Laptop has raised a significant amount of funding, totaling $45 million across several rounds, including a $9 million seed round, $18 million Series A, and $17 million Series A-1. Additionally, the company has raised $1 million through equity crowdfunding.

Without factoring in inflation, $50 million was Commodore UK's Amiga Inc. funding budget.

Last edited by Hammer on 12-May-2025 at 07:02 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:

I can, and I do, because sometimes (rarely, fortunately) I need it, but a regular Windows user has no reason to use WSL.

"Google Play Games" targets regular Windows PC users. https://play.google.com/googleplaygames/
It's mostly Android games with Google's middleware ecosystem.

"Google Play Games" removes the need for WSL with Android (with Amazon Appstore).

Last edited by Hammer on 12-May-2025 at 07:10 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:

cdimauro wrote: @kolla: if we've to stay in topic then not so much of what you've reported applies. To be more clear, this X68000 revival brings NOTHING new to the original platform in terms of enhancement and modern capabilities. So, they got more than $24 millions for a remake using a poor ARM SoC. Where's the innovation here? The new case? The usual emulator? [

Mass production consumes the available funding. Ask Framework Computer, Inc, and they have support from Intel, AMD, Deep Computing, Cooler Master, Insyde (UEFI), and Compal (ODM).

R&D ASIC SoC is half of the solution, since mass production is another major problem to be solved.

Last edited by Hammer on 12-May-2025 at 07:32 AM.
Last edited by Hammer on 12-May-2025 at 07:29 AM.
Last edited by Hammer on 12-May-2025 at 07:28 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: @cdimauro Quote: I can, and I do, because sometimes (rarely, fortunately) I need it, but a regular Windows user has no reason to use WSL. "Google Play Games" targets regular Windows PC users. https://play.google.com/googleplaygames/ It's mostly Android games with Google's middleware ecosystem. "Google Play Games" removes the need for WSL with Android (with Amazon Appstore).

That's something new and it's still beta...
Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: @kolla: if we've to stay in topic then not so much of what you've reported applies. To be more clear, this X68000 revival brings NOTHING new to the original platform in terms of enhancement and modern capabilities. So, they got more than $24 millions for a remake using a poor ARM SoC. Where's the innovation here? The new case? The usual emulator? [ Mass production consumes the available funding. Ask Framework Computer, Inc, and they have support from Intel, AMD, Deep Computing, Cooler Master, Insyde (UEFI), and Compal (ODM). R&D ASIC SoC is half of the solution, since mass production is another major problem to be solved.

There are plenty of devices in the retro market which use the same SoCs of this "new" X68000.

Even for them it should apply the "mass production" issues, but they cost much much less...

@cdimauro

Quote:

That's something new and it's still beta...

"Rome wasn't built in a day."

Google Play Games effectively replaced Stadia.

--------------------------------

Stadia Controller with updated Bluetooth mode shifts the device into Xbox One controller compatible as a fallback. Changing the Stadia Controller into updated Bluetooth mode is a one-way firmware update i.e. the change is permanent.

Quote:

There are plenty of devices in the retro market which use the same SoCs of this "new" X68000. Even for them it should apply the "mass production" issues, but they cost much much less...

It depends on the production scale. Zuiki's funding results can be used to estimate the production scale.

A similar argument can be made for RPi / Broadcom's and MediaTek's mostly cut-and-paste engineering with ARM's IP blocks.

Japan is a larger market when compared to Amiga's strongest market, i.e. UK.

Game console SoCs from Sony, Nintendo, and Xbox are mostly from established PC IHVs (independent hardware vendors). The bulk of R&D revenue generation is from the PC market while subsidizing embedded game console SoCs' R&D.

https://growjo.com/company/Framework_Computer
Framework Computer's revenue is estimated to be $33.3 million per year with 127 employees.

That's about 22,000 units at $1500 unit average. Framework Computer uses Compal ODM as its primary laptop manufacturing contractor.

Before RISC-V was transferred to a Swiss non-profit entity, the US government (US taxpayers) funded the University of California, Berkeley.

SiFive Inc.'s 2023 revenue reached $38.1 million with 500 employees.
----------
In September 2015, SiFive raised $5 million in Series A funding. In May 2017 SiFive raised $8.5 million in Series B.

In April 2018, SiFive received $50.6 million Series C funding, including a major amount from Intel Capital.

In June 2019, SiFive received $65.4 million in a Series D funding round led by existing investors Sutter Hill Ventures, Chengwei Capital (China), Spark Capital, Osage University Partners and Huami (China), alongside new investor Qualcomm Ventures. This brought the total investment in SiFive to $125 million.

In August 2020, SiFive received $60 million in a Series E funding round led by investors SK Hynix and Saudi Aramco (Saudi Arabian state-owned). This brought the total investment in SiFive to $186 million.

In March 2022, SiFive received $175 million in a Series F funding round led by Coatue Management. This brought the total investment in SiFive to over $350 million.
----------

Without the financial strength from a near-peer superpower like China, it's very difficult to build another Commodore.

Last edited by Hammer on 16-May-2025 at 04:09 AM.
Last edited by Hammer on 15-May-2025 at 04:19 AM.
Last edited by Hammer on 15-May-2025 at 04:18 AM.
Last edited by Hammer on 15-May-2025 at 04:17 AM.
Last edited by Hammer on 15-May-2025 at 04:10 AM.
Last edited by Hammer on 15-May-2025 at 04:08 AM.
Last edited by Hammer on 15-May-2025 at 04:00 AM.
Last edited by Hammer on 15-May-2025 at 03:57 AM.
Last edited by Hammer on 15-May-2025 at 03:44 AM.
Last edited by Hammer on 15-May-2025 at 03:33 AM.
Last edited by Hammer on 15-May-2025 at 03:29 AM.
Last edited by Hammer on 15-May-2025 at 03:26 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:

Jeri Ellsworth made a C64 SoC ASIC and almost a 68k SoC ASIC by herself on a shoestring budget and with minimal licensing and developer resources (Amiga chipset schematics were provided after development was started)

From https://en.wikipedia.org/wiki/Jeri_Ellsworth and https://en.wikipedia.org/wiki/C64_Direct-to-TV

Jeri Ellsworth's C-One (FPGA) demo led to Mammoth Toys, a Division of NSI International, NSI Products (HK) Limited hiring her to design the "computer in a chip" for the C64 Direct-to-TV C64-emulating joystick. QVC purchased the entire first production run of 250,000 units.

https://en.wikipedia.org/wiki/C-One
The C-One is a single-board computer (SBC) created in 2002 as an enhanced version of the Commodore 64, a home computer popular in the 1980s. Designed by Jeri Ellsworth and Jens Schönfeld from Individual Computers.

C-One with A500 compatibility includes 3rd FPGA via "Extender" card with Tobias Gubener's TG68 CPU core that replaced the physical 68000 CPU.

Last edited by Hammer on 15-May-2025 at 04:36 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: @cdimauro Quote: That's something new and it's still beta... "Rome wasn't built in a day."

Let's see when it'll finally be available.

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

Quote: There are plenty of devices in the retro market which use the same SoCs of this "new" X68000. Even for them it should apply the "mass production" issues, but they cost much much less... It depends on the production scale. Zuiki's revenue rise can be used to estimate the production scale. A similar argument can be made for RPi / Broadcom's and MediaTek's mostly cut-and-paste engineering with ARM's IP blocks. Japan is a larger market when compared to Amiga's strongest market, i.e. UK. Game console SoCs from Sony, Nintendo, and Xbox are mostly from established PC IHVs (independent hardware vendors). The bulk of R&D revenue generation is from the PC market while subsidizing embedded game console SoCs' R&D. https://growjo.com/company/Framework_Computer Framework Computer's revenue is estimated to be $33.3 million per year with 127 employees. That's about 22,000 units at $1500 unit average. Framework Computer uses Compal ODM as its primary laptop manufacturing contractor. Before RISC-V was transferred to a Swiss non-profit entity, the US government (US taxpayers) was funded the University of California, Berkeley. SiFive Inc.'s 2023 revenue reached $38.1 million with 500 employees. ---------- In September 2015, SiFive raised $5 million in Series A funding. In May 2017 SiFive raised $8.5 million in Series B. In April 2018, SiFive received $50.6 million Series C funding, including a major amount from Intel Capital. In June 2019, SiFive received $65.4 million in a Series D funding round led by existing investors Sutter Hill Ventures, Chengwei Capital (China), Spark Capital, Osage University Partners and Huami (China), alongside new investor Qualcomm Ventures. This brought the total investment in SiFive to $125 million. In August 2020, SiFive received $60 million in a Series E funding round led by investors SK Hynix and Saudi Aramco (Saudi Arabian state-owned). This brought the total investment in SiFive to $186 million. In March 2022, SiFive received $175 million in a Series F funding round led by Coatue Management. This brought the total investment in SiFive to over $350 million. ---------- Without the financial strength from a near-peer superpower like China, it's very difficult to build another Commodore.

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

As I've already said, there are plenty of "retro-devices" which are using the same SoC of this "new" (!) X68000, which are way cheaper.

Yes, economies of scale matters. But not to justify this big price that customers have to pay. It's clear that the producer wants to get a very high margin.

@matthey

Quote:

matthey wrote: Jeri Ellsworth made a C64 SoC ASIC and almost a 68k SoC ASIC by herself on a shoestring budget ...

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.