kolla Quote:

A bunch of money wasting suckers. Imagine if all that money instead had been used to support development of AROS on conventional off-the-shelf hardware and "classic" 68k hardware, instead of wasting it on development of hardware that is doomed to be low volume, super expensive and old before it is even ready.

With competitive hardware, the need to protect the AmigaOS would be greatly reduced and a more open AmigaOS could develop faster and proliferate instead of the reinvented wheel AROS. Contrast how open the software is on RPi hardware where the larger problem is not whether the OS is open but which open OS to use and lack of a standard OS for pre-compiled software. The 32-bit version of the RPi OS is still recommended while the 64-bit version has gained market share and can not be run on older RPi hardware. Ubuntu is used by maybe 10% of RPi users and another 20% of users use some OS with less than 10% market share. I believe the RISC-V VisionFive2 OS market share is even more divided. The standard 68k Amiga/AmigaOS binaries are still a unifying force on the Amiga even with emulation on PPC, x86-64 and ARM hardware. Hardware that tried to reduce compatibility with the 68k Amiga standard suffered from poor sales like PPC AmigaNOne hardware.

Lou Quote:

You guys and your silly fights are something else! Motorla has already given you the answer on what is the best architecture. That's why millions of MOTOROLA set-top cable boxes from the early 2000's use .... 68k? Coldfire? PPC? .... 6502... The one cpu that rules them all!

Motorola liked to reduce hardware like cutting instructions, FPUs and compatibility but it was detrimental to their embedded market which they lost to ARM. A 6502 CPU core is still useful where a tiny area and low power are valuable without much code but I do not believe this applies to a set top box in the early 2000s.

Lou Quote:

The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES.

I expect a C65 console would have sold at least as well as the 1990 C64GS.

https://en.wikipedia.org/wiki/Commodore_64_Games_System Quote:

The C64GS was not Commodore's first gaming system based on the Commodore 64 hardware. However, unlike the 1982 MAX Machine (a game-oriented computer based on a very cut-down version of the same hardware family), the C64GS is internally very similar to the complete Commodore 64, with which it is compatible. Out of the approximately 20,000 consoles produced, only 2000 consoles were sold.

Even the A600GS will likely sell more units and it is too little too late too. If Commodore had invested in improving the Amiga chipset instead of the C65 chipset, a 68EC030&AA+@28MHz would have made the CD32 a better value and much more competitive in the early 1990s. Likewise, if the A600GS had better hardware, it would be more competitive. Some people try to get a free lunch where there is none. Competitive hardware requires investment and delivering low value hardware gives a bad reputation.

@matthey

Quote:

With competitive hardware, the need to protect the AmigaOS would be greatly reduced and a more open AmigaOS could develop faster and proliferate instead of the reinvented wheel AROS. Contrast how open the software is on RPi hardware where the larger problem is not whether the OS is open but which open OS to use and lack of a standard OS for pre-compiled software. The 32-bit version of the RPi OS is still recommended while the 64-bit version has gained market share and can not be run on older RPi hardware. Ubuntu is used by maybe 10% of RPi users and another 20% of users use some OS with less than 10% market share. I believe the RISC-V VisionFive2 OS market share is even more divided. The standard 68k Amiga/AmigaOS binaries are still a unifying force on the Amiga even with emulation on PPC, x86-64 and ARM hardware. Hardware that tried to reduce compatibility with the 68k Amiga standard suffered from poor sales like PPC AmigaNOne hardware

The main problem with PPC Amiga is price vs performance.

There's no Raspberry Pi Foundation and Broadcom for PPC.

Broadcom's SoC is important for the Raspberry Pi Foundation's founding.

_________________
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: @NutsAboutAmiga Memory controllers have been integrated on MPUs and SoCs for about 20 years now because integration offers better performance and lower communications latency. SoCs are a further integration of I/O with CPU and GPU cores. Integration is what allowed Jay Miner to bring an affordable 68k Amiga to market and what Commodore failed to continue doing with the 68k Amiga resulting in their bankruptcy. Commodore planned for a 68k Amiga SoC but failed to deliver the Commodore estimated $100 USD per unit cost savings that would have saved them. Integration is what allows emulation to outperform 68k and PPC cores with low end ARM SoCs. The history of the Amiga is a lesson in integration. Jay Miner foresaw it but could not save the Amiga from oblivious financiers like Irving Gould and Trevor Dickinson. For example, Trevor does not believe it is necessary to integrate a standard FPU in AmigaNOne "desktop" hardware with a price several times that of the competition. Trevor and his Amiga wannabe hardware are repeating the Commodore 1990s failures all over again.

Somebody has advised Trevor Dickinson (an investor) on e500's suitability.

Irving Gould is an investor who hired an "electrical engineer" like Herni Rubin, who can't use a computer.

Irving Gould used his money to fund A1200/CD32's production. Mehdi Ali (investment banker) was installed by the institutional shareholders.

From Commodore - The Final Years,

On Tuesday, November 22, 1988 the annual shareholder meeting
commenced at the Manufacturers Hanover Trust Co. building in
Manhattan. Lasting for more than an hour and with 50 people in
attendance, Luck attempted to vote his proxy shares. Unfortunately,
his inexperience in corporate matters soon halted his game. “It was
a public meeting but the right paperwork wasn’t done so I could
vote my shares,� he says.

Instead of Luck being placed on the ballot for a position on the
board, the vote took place only for Mehdi Ali. Most shareholders
were institutional shareholders, such as mutual fund managers or
retirement funds. Ali won easily. He now took his place as one of six
members on Commodore’s board of directors and began to enjoy
true corporate power.

For his part, Luck had to settle for airing his grievances publicly to
the board. His biggest criticism was aimed at the very people in front
of him. “There is no one with a significant technical background on
the board of directors,� Luck told the attendees. “Other companies
have someone who has vision or understanding of the basic
technologies and can help the board. Even in the high level
management of Commodore there really isn't anyone who grasps
the technology.�


After Thomas Rattigan, Irving Gould had remained at the helm of Commodore International
as President and CEO for almost two years.

Herni Rubin was the main actor in kicking out Thomas Rattigan from Commodore.

Mehdi Ali went to Pepsico Inc. as VP of finance where he worked alongside Thomas Rattigan.

Last edited by Hammer on 06-Mar-2025 at 01:38 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

@Lou

Quote:

The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES.

From Commodore - The Final Years

Although Victor Andrade was supposed to have been working on
AAA all year, he had instead been working on the 4510 chipset until
the middle of October 1989, at which time he began on AAA. By
then it was clear they could not meet the early 1990 schedule for
working silicon.


C65's hidden 4510 R&D delayed AAA's R&D.

_________________
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

With A-Eon Dinosaur Technologies going back in time feature wise, with Trevor starting with a 6502 system which may compete with his love for PPC, with Lou's 6502 suggestion and with the continued availability of Western Design Center 6502 MCUs, maybe it is time for A-Eon 6502 systems. Exit the A-Eon X5000 and enter the C6502.

C6502/20
https://www.amazon.com/W65C134SXB-Engineering-Development-Featuring-Microcomputer/dp/B00ZJTXIL0/

C6502/40
https://www.amazon.com/W65C02SXB-Engineering-Development-System-Board-Microprocessor/dp/B00ZRTPG44/

A-Eon just needs to provide huge cases for these SBCs with some C65 stickers and customers will be amazed at the next generation Commodore wanted and A-Eon delivered. Neither Commodore or A-Eon like the 68k Amiga after all as they did as little as possible to develop it and tried to replace it. The Commodore IP should be easier to steal than the Amiga IP. Trevor may even be able to buy it for less than can he steal it but where is the fun in that?

@Lou

Quote:

Lou wrote: You guys and your silly fights are something else! Motorla has already given you the answer on what is the best architecture. That's why millions of MOTOROLA set-top cable boxes from the early 2000's use .... 68k? Coldfire? PPC? .... 6502... The one cpu that rules them all! https://retro-hardware.com/2017/01/06/6502-in-millions-of-tv-set-top-boxes-across-north-america-or-cracking-satellite-and-cable-pay-tv/ Long live the 6502! Oh that's right ... it still lives ... unlike the boat-anchor cpu(s) you guys are defending... Perhaps if AROS was ported to the 65816 or 65CE02, more people would care about AROS. What's an Amiga without it's chipset? An underclocked Atari. Why did Amiga lag behind? It's cpu and it's chipset. The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES. https://www.youtube.com/watch?v=OoHxDe3Gc9E Keep fighting amongst yourselves... See you in a month!

LOL. Sometimes they came back...

Oh, here's again the poor 65xx fanatical that disappeared after he crashed against the reality that people put in front of his face. You weren't able to sustain the reality, and preferred to go back into the parallel universe/cave where your glorious 65xx (crap) is the top notch.

Now you're back, but... do you know what? Nothing changed! 65xx is still crap and it's simply impossible to take into consideration as a possibility for having it on our beloved Amiga. For all reasons which I've already tried to explain on the old thread, where you escaped like a bunny (even after put a challenge there. Where I gave the C version).

Now you'll go back to the cave to celebrate the crappy architecture that you love.

cdimauro Quote:

Now you're back, but... do you know what? Nothing changed! 65xx is still crap and it's simply impossible to take into consideration as a possibility for having it on our beloved Amiga. For all reasons which I've already tried to explain on the old thread, where you escaped like a bunny (even after put a challenge there. Where I gave the C version).

The 6502 ISA is crap but the design is still often adequate for a minimal area and low power 8-bit CPU core which is why it is still available from Western Design Center, Bill Mensch's fabless semiconductor development business he created while Chuck Peddle created the Pet at Commodore. The 6502@8MHz with SRAM MCU has more CPU performance than the original 68000 Amiga. The 6502 family has ended up in or attached to the Amiga before as an embedded (keyboard) I/O controller and could be used for compatibility which I have no problem with anymore than a RISC-V core. The RPi 500 uses the RPi fabless semi developed RP2040 MCU for I/O.

https://www.jeffgeerling.com/blog/2024/pi-500-much-faster-lacks-m2 Quote:

Glancing at the other parts of the Pi 500's PCB, the whole middle section is nearly identical in layout to a Pi 5, probably saving on design costs, and then for the keyboard input, Raspberry Pi switched to using their own microcontroller, the RP2040. (RP2040 for peripheral support seems to be a trend, lately—I've spotted it on the MNT Reform trackball module, the Positron 3D printer control board, the System76 Launch keyboard, and even inside the System76 Thelio Astra I'm testing, on an IO/Fan controller!

As popular as the RP2040 and RP2350 MCUs have become, I do not think they really threaten Bill's 47 year old fabless semi business that has outlived Commodore by 31 years. The 6502 is much lower end than the RPi custom MCUs.

https://en.wikipedia.org/wiki/RP2040
https://en.wikipedia.org/wiki/RP2350
https://www.westerndesigncenter.com/

The embedded market is huge and the fabless semi developers like RPi, WDC, SiFive and DMP Electronics (Vortex86 SoCs) seem to be doing better than the niche commodity computer producers. All these fabless semi businesses are involved directly or indirectly in the mass production of low cost SBCs for their ASIC SoCs. Fabless semi businesses like ARM Holdings and WDC have outlived the higher profile Acorn and Commodore computer businesses that used their CPUs. The market cap of some of these businesses is crazy too.

There is nothing 68k Amiga related here and we know compatibility is too important to replace the 68k and chipset as the PPC AmigaNOne failure has demonstrated. Too bad as good as the 68k Amiga was that it does not get some fabless semi development love but Trevor loves PPC and the 6502 instead and hates the 68k and Amiga chipset which he will not stop sabotaging.

Last edited by matthey on 08-Mar-2025 at 02:50 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Now you're back, but... do you know what? Nothing changed! 65xx is still crap and it's simply impossible to take into consideration as a possibility for having it on our beloved Amiga. For all reasons which I've already tried to explain on the old thread, where you escaped like a bunny (even after put a challenge there. Where I gave the C version). The 6502 ISA is crap but the design is still often adequate for a minimal area and low power 8-bit CPU core which is why it is still available from Western Design Center, Bill Mensch's fabless semiconductor development business he created while Chuck Peddle created the Pet at Commodore. The 6502@8MHz with SRAM MCU has more CPU performance than the original 68000 Amiga. The 6502 family has ended up in or attached to the Amiga before as an embedded (keyboard) I/O controller and could be used for compatibility which I have no problem with anymore than a RISC-V core. The RPi 500 uses the RPi fabless semi developed RP2040 MCU for I/O. https://www.jeffgeerling.com/blog/2024/pi-500-much-faster-lacks-m2 Quote: Glancing at the other parts of the Pi 500's PCB, the whole middle section is nearly identical in layout to a Pi 5, probably saving on design costs, and then for the keyboard input, Raspberry Pi switched to using their own microcontroller, the RP2040. (RP2040 for peripheral support seems to be a trend, lately—I've spotted it on the MNT Reform trackball module, the Positron 3D printer control board, the System76 Launch keyboard, and even inside the System76 Thelio Astra I'm testing, on an IO/Fan controller! As popular as the RP2040 and RP2350 MCUs have become, I do not think they really threaten Bill's 47 year old fabless semi business that has outlived Commodore by 31 years. The 6502 is much lower end than the RPi custom MCUs. https://en.wikipedia.org/wiki/RP2040 https://en.wikipedia.org/wiki/RP2350 https://www.westerndesigncenter.com/

And I've absolutely no problem with that! I loved the 65xx family because it was fun and they were very good for such embedded use cases.

However, they aren't good outside of this. The reason why I've called them crap is purely and only because of Lou's insane fantasies:

Perhaps if AROS was ported to the 65816 or 65CE02, more people would care about AROS.
[...]
The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES.

He's clearly out of mind by promoting such non-sense.
Quote:

The embedded market is huge and the fabless semi developers like RPi, WDC, SiFive and DMP Electronics (Vortex86 SoCs) seem to be doing better than the niche commodity computer producers. All these fabless semi businesses are involved directly or indirectly in the mass production of low cost SBCs for their ASIC SoCs. Fabless semi businesses like ARM Holdings and WDC have outlived the higher profile Acorn and Commodore computer businesses that used their CPUs. The market cap of some of these businesses is crazy too. There is nothing 68k Amiga related here and we know compatibility is too important to replace the 68k and chipset as the PPC AmigaNOne failure has demonstrated. Too bad as good as the 68k Amiga was that it does not get some fabless semi development love but Trevor loves PPC and the 6502 instead and hates the 68k and Amiga chipset which he will not stop sabotaging.

I fully agree. There's still a lot of room here, and 68k could have very good cards to play.

cdimauro Quote:

And I've absolutely no problem with that! I loved the 65xx family because it was fun and they were very good for such embedded use cases. However, they aren't good outside of this. The reason why I've called them crap is purely and only because of Lou's insane fantasies: Perhaps if AROS was ported to the 65816 or 65CE02, more people would care about AROS. [...] The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES. He's clearly out of mind by promoting such non-sense.

Releasing the C65 before AGA for the Amiga likely would have reduced Amiga sales. The C128 was more expensive to produce than the Amiga 500 and it likely reduced Amiga sales and Commodore profit margins. The SNES showed it was possible for a late 6502 family CPU console to be successful. The 6502 family CPU crippled the nice SNES console chipset but it was cheap and there were enough experienced 6502 assembly programmers to make it a success. Launching the Amiga with a 6502 family CPU would have lowered the price, could have improved compatibility with the C64 and may have been more appealing to C64 owners. Commodore failed to upgrade enough C64 owners to the 68k Amiga. I strongly believe the 68k was the right choice for the Amiga but Commodore should have moved to a 68020 sooner with 6502 and 8088 emulation rather than using a 68000 Amiga with bridgeboards that catered to the business PC market instead of home and gaming PC market, including C64 customers. Commodore chased the business market but lost the home and gaming market despite the 68k Amiga being the best home and gaming PC in the market. Commodore thought the biggest Amiga adoption impediment was price as the C64 was cheaper so they resisted upgrading the Amiga which would have increased the price despite the 68k Amiga being one of the most upgradeable systems on the market. Lack of early C64 compatibility and software in general was a bigger problem than price as the rise of the more expensive gaming PC demonstrated despite the much more difficult to upgrade 8-bit 8088 PC to 32-bit Pentium PC path. The 8-bit 6502 and C64 upgrade path was more difficult but the 16/32-bit 68000 upgrade path was easily the easiest due to the 32-bit ISA and large flat address space from inception. Jay Miner knew what he was doing by insisting on the 68k. A 6502 Amiga would be as crippled and upgradeable as the SNES while there are 68060@100MHz CD32s with 128MiB of memory that retain good compatibility and more modern improvements are possible.

cdimauro Quote:

I fully agree. There's still a lot of room here, and 68k could have very good cards to play.

The similar to the 68060 in-order Cyrix 6x86 was developed with a small team and "perhaps a tenth" of the $100 million Intel P5 Pentium development cost which would be $10 million.

Cyrix Describes Pentium Competitor
x86-Compatible “M1� Design is Superscalar, Deeply Pipelined
https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/071401.pdf Quote:

Competition For Pentium The M1 design uses a variety of advanced techniques to execute x86 code at high speeds. These techniques are particularly advantageous for existing x86 code; Pentium, in contrast, loses 20-30% of its peak performance unless programs are recompiled. Cyrix’s initial performance simulations seem to demonstrate the superiority of its approach. The new design raises questions about Intel’s Pentium, which is said to have cost as much as $100 million to develop. Even with this enormous effort, Pentium ended up being little more than two 486 pipelines glued together, with a fast floating-point unit. Cyrix will spend perhaps a tenth of that amount and has developed a much more innovative design, using register renaming and other advanced tactics to solve critical problems in the x86 architecture. ... If, during 1995, Cyrix can offer processors similar to Intel’s premium products, Intel may have to drop prices on its high-end chips, jeopardizing its legendary profitability. Alternatively, Intel could try to boost prices on its 486 chips, or cut back on R&D or other spending. Either of these tactics could open the door for other x86 chip vendors. Furthermore, Cyrix could become a “one-stop shopping� alternative to Intel. Before this scenario can develop, Cyrix must move M1 from a fancy design to a potent reality. The fabless vendor must then demonstrate an ability to obtain enough chips to make a dent in the overall market; while Pentiums are in short supply today, Intel will probably be shipping a million per quarter by the time the M1 is available, raising the bar for Cyrix. Finally, the fledgling company must withstand inevitable legal challenges. While the recent revelations show that Cyrix has a talented and efficient design team, only time will tell whether the M1 is truly a Pentium killer.

The 68060 and 6x86 both chose integer performance over FPU performance and picked on the shallow 5-stage Pentium pipeline. The 6x86 may have copied features from the earlier 68060 as the design has similarities. The 68060 was earlier, has a better ISA with better code density, has a lower latency FPU with a much better FPU ISA and is smaller area for upgrading the caches. The 6x86 was late and the design choice to focus on integer performance was doing well until Quake emphasized FPU performance and was optimized for the Pentium. It was bad luck or Cyrix would have had their foot in the door with maybe a $10 million investment. The scalar version of the Cyrix 6x86 core, a 5x86 core, is likely used in many variations of the Vortex86 ASIC still today. Maybe DMP Electronics does not have access to the superscalar 6x86 or maybe the 6x86 with x86 baggage is too high of power for embedded use, unlike the superscalar 68060. In any case, the mediocre P5 Pentium design was almost killed by the competition. In-order cores are much cheaper to develop than OoO cores and cheaper to get the foot in the door. Of course the 68k does not have the x86 competition to contend with with the bigger question being whether the 68k market is large enough to have economies of scale for mass production. It did not with Apple switching to PPC and Commodore dead although today, the 68060 would be much cheaper to mass produce for 68k Amiga toys like RPi Acorn Archimedes toys but with a large library of retro 68k games.

@matthey

Quote:

matthey wrote: cdimauro Quote: And I've absolutely no problem with that! I loved the 65xx family because it was fun and they were very good for such embedded use cases. However, they aren't good outside of this. The reason why I've called them crap is purely and only because of Lou's insane fantasies: Perhaps if AROS was ported to the 65816 or 65CE02, more people would care about AROS. [...] The 3.57Mhz 8/16bit 65CE02 C65 was outperforming the Amiga 500 and they didn't want to cut into Amiga sales so they cancelled it. In 1990, it was doing 640x400x16 320x200 256 color graphics before AGA and could have competed against the SNES. He's clearly out of mind by promoting such non-sense. Releasing the C65 before AGA for the Amiga likely would have reduced Amiga sales.

I'm not sure about this, because software compatibility for the C65 would have been a very big problem (primarily because of the new CPU).

AGA had its big problems as well, but purely because of the many idiots which haven't followed Commodore's guidelines. Too many jerks at the keyboard, unfortunately.

Last but not really least, the C65 would have had too little memory even compared an unexpanded A500, so it would have limited as well what could have been possible.
Quote:

The C128 was more expensive to produce than the Amiga 500 and it likely reduced Amiga sales and Commodore profit margins. The SNES showed it was possible for a late 6502 family CPU console to be successful. The 6502 family CPU crippled the nice SNES console chipset but it was cheap and there were enough experienced 6502 assembly programmers to make it a success.

I don't think that the 6502 crippled the SNES. For what was the purpose of the CPU, it was a perfect match for SNES' chipset, because... it was a very powerful console.

Contrary to the usual belief, CPUs were mostly the slaves of the chipset: they were there mostly to load the hardware's registers, and business logic was a very limited piece of the cake.
Quote:

Launching the Amiga with a 6502 family CPU would have lowered the price, could have improved compatibility with the C64 and may have been more appealing to C64 owners. Commodore failed to upgrade enough C64 owners to the 68k Amiga. I strongly believe the 68k was the right choice for the Amiga but Commodore should have moved to a 68020 sooner with 6502 and 8088 emulation rather than using a 68000 Amiga with bridgeboards that catered to the business PC market instead of home and gaming PC market, including C64 customers. Commodore chased the business market but lost the home and gaming market despite the 68k Amiga being the best home and gaming PC in the market. Commodore thought the biggest Amiga adoption impediment was price as the C64 was cheaper so they resisted upgrading the Amiga which would have increased the price despite the 68k Amiga being one of the most upgradeable systems on the market. Lack of early C64 compatibility and software in general was a bigger problem than price as the rise of the more expensive gaming PC demonstrated despite the much more difficult to upgrade 8-bit 8088 PC to 32-bit Pentium PC path. The 8-bit 6502 and C64 upgrade path was more difficult but the 16/32-bit 68000 upgrade path was easily the easiest due to the 32-bit ISA and large flat address space from inception. Jay Miner knew what he was doing by insisting on the 68k. A 6502 Amiga would be as crippled and upgradeable as the SNES while there are 68060@100MHz CD32s with 128MiB of memory that retain good compatibility and more modern improvements are possible.

The 68k was the right choice because the Amiga was NOT a console.

And having a serious OS demanding something which a 6502 could never meet as requirements, even with a 4GB RAM expansion. That's the reason why it's crap.
Quote:

cdimauro Quote: I fully agree. There's still a lot of room here, and 68k could have very good cards to play. The similar to the 68060 in-order Cyrix 6x86 was developed with a small team and "perhaps a tenth" of the $100 million Intel P5 Pentium development cost which would be $10 million. Cyrix Describes Pentium Competitor x86-Compatible “M1� Design is Superscalar, Deeply Pipelined https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/071401.pdf Quote: Competition For Pentium The M1 design uses a variety of advanced techniques to execute x86 code at high speeds. These techniques are particularly advantageous for existing x86 code; Pentium, in contrast, loses 20-30% of its peak performance unless programs are recompiled. Cyrix’s initial performance simulations seem to demonstrate the superiority of its approach. The new design raises questions about Intel’s Pentium, which is said to have cost as much as $100 million to develop. Even with this enormous effort, Pentium ended up being little more than two 486 pipelines glued together, with a fast floating-point unit. Cyrix will spend perhaps a tenth of that amount and has developed a much more innovative design, using register renaming and other advanced tactics to solve critical problems in the x86 architecture. ... If, during 1995, Cyrix can offer processors similar to Intel’s premium products, Intel may have to drop prices on its high-end chips, jeopardizing its legendary profitability. Alternatively, Intel could try to boost prices on its 486 chips, or cut back on R&D or other spending. Either of these tactics could open the door for other x86 chip vendors. Furthermore, Cyrix could become a “one-stop shopping� alternative to Intel. Before this scenario can develop, Cyrix must move M1 from a fancy design to a potent reality. The fabless vendor must then demonstrate an ability to obtain enough chips to make a dent in the overall market; while Pentiums are in short supply today, Intel will probably be shipping a million per quarter by the time the M1 is available, raising the bar for Cyrix. Finally, the fledgling company must withstand inevitable legal challenges. While the recent revelations show that Cyrix has a talented and efficient design team, only time will tell whether the M1 is truly a Pentium killer.

This shows that having good engineers is a key factor, when there aren't many money/resources available. The same thing happened with AMD.
Quote:

The 68060 and 6x86 both chose integer performance over FPU performance and picked on the shallow 5-stage Pentium pipeline. The 6x86 may have copied features from the earlier 68060 as the design has similarities. The 68060 was earlier, has a better ISA with better code density, has a lower latency FPU with a much better FPU ISA and is smaller area for upgrading the caches. The 6x86 was late and the design choice to focus on integer performance was doing well until Quake emphasized FPU performance and was optimized for the Pentium. It was bad luck or Cyrix would have had their foot in the door with maybe a $10 million investment.

Definitely, it was a bad luck. FPU weren't that important before Quake, and it was good to focus on the GP/integer part of the chips.
Quote:

The scalar version of the Cyrix 6x86 core, a 5x86 core, is likely used in many variations of the Vortex86 ASIC still today. Maybe DMP Electronics does not have access to the superscalar 6x86 or maybe the 6x86 with x86 baggage is too high of power for embedded use, unlike the superscalar 68060. In any case, the mediocre P5 Pentium design was almost killed by the competition. In-order cores are much cheaper to develop than OoO cores and cheaper to get the foot in the door.

Not only that: in-order design are much smaller and draw much less power. They are very good at PPA, and that's the reason why they are still largely used on mobile phones.
Quote:

Of course the 68k does not have the x86 competition to contend with with the bigger question being whether the 68k market is large enough to have economies of scale for mass production.

That's a big question mark.
Quote:

It did not with Apple switching to PPC and Commodore dead although today, the 68060 would be much cheaper to mass produce for 68k Amiga toys like RPi Acorn Archimedes toys but with a large library of retro 68k games.

An enhance 68k for games isn't a good solution. Rather the opposite: it gives big compatibility problems.

Here it's better to stick to the exact 68000 design.

68020 is less a concern, because of the code cache. So, 68020 games could likely run well on a super-duped 68k core.

I would personally spend $250-$500 on an FPGA board that would give me PPC 603e system to play with (I don't really care whether it's faster or slower than other systems on the market, I just want one for -basically- irrational reasons ).

How many man-years of an FPGA coding would it take to implement one ?

Would it require a board of V4SA size or would smaller one suffice ? What kind of a CPU frequency would be reasonable to expect from such board ?

@Heimdall

Quote:

How many man-years of an FPGA coding would it take to implement one ?

No idea, but you can get a big head start by downloading this.

_________________
Whyzzat?

Quote:

minator wrote: @Heimdall Quote: How many man-years of an FPGA coding would it take to implement one ? No idea, but you can get a big head start by downloading this.

Yeah, well just because I have C++ skills, doesn't mean it's a best idea to stop all my engine/game projects and instead focus on FPGA coding.

And I say this fully aware of completely useless [but exciting for me!] rabbit holes I often go down (that just further postpone releasing anything - but since I am financing the whole endeavor, it's nobody's business, really).

But, since we're already entertaining a what-if scenario here, how much of a CPU feature-set could I theoretically implement in, say, 3-4 months full-time (after I spend 1 month with initial familiarization of the FPGA coding) ? Would that even make a dent at all?

@Heimdall

Quote:

But, since we're already entertaining a what-if scenario here, how much of a CPU feature-set could I theoretically implement in, say, 3-4 months full-time (after I spend 1 month with initial familiarization of the FPGA coding) ? Would that even make a dent at all?

If it's just a means to an end (you just want a PowerPC in an FPGA), then it'll take very little time because the link I pointed to above is to an existing Power architecture (read PowerPC) soft core.

To do one from scratch, I've no idea, I'm interested to know myself.
I guess it'll depend on what you want to build, and how much open source material you can use, or at least look at and, if you plan to use it, how much AI can help.

_________________
Whyzzat?

cdimauro Quote:

I don't think that the 6502 crippled the SNES. For what was the purpose of the CPU, it was a perfect match for SNES' chipset, because... it was a very powerful console. Contrary to the usual belief, CPUs were mostly the slaves of the chipset: they were there mostly to load the hardware's registers, and business logic was a very limited piece of the cake.

What other console other than SNES had so many CPUs and DSPs in cartridges?

The 1988 Sega Genesis/Mega Drive with a 68000 held its own against the 1990 SNES with a Ricoh 5A22 (16-bit 6502 family). The Genesis is older and inferior on paper except for the CPU which should be close in performance but the Genesis feels faster and it was not common for it to have CPU and DSP replacements in cartridges. SNES games were often more colorful but also often sluggish in my experience. I would like to think some of it was due to the CPU. The 68k Amiga was also responsive and versatile compared to the competition and I do not believe it was just the chipset and AmigaOS.

cdimauro Quote:

An enhance 68k for games isn't a good solution. Rather the opposite: it gives big compatibility problems. Here it's better to stick to the exact 68000 design. 68020 is less a concern, because of the code cache. So, 68020 games could likely run well on a super-duped 68k core.

While a deeply embedded 6502 CPU core is acceptable, I would rather have a 68000 core for I/O and game compatibility.

Heimdall Quote:

I would personally spend $250-$500 on an FPGA board that would give me PPC 603e system to play with (I don't really care whether it's faster or slower than other systems on the market, I just want one for -basically- irrational reasons ). How many man-years of an FPGA coding would it take to implement one ? Would it require a board of V4SA size or would smaller one suffice ? What kind of a CPU frequency would be reasonable to expect from such board ?

You are not the first person to ask.

PowerPC In FPGA - How Much Sense Does It Make?
http://apollo-core.com/knowledge.php?b=5¬e=25817&x=0
Gunnar von Boehn Quote:

We got ask if putting a PPC into an FPGA makes sense. To answer this I think it makes good sense to explain a few things about FPGA. Some years ago I participated in a project at IBM which goal was to port the PowerPC-460 CPU from ASIC to FPGA. As you know the PowerPC 460 is the CPU used in the SAM systems. The 460 CPU cost as ASIC a few dollars and reaches as ASIC over 1 GigaHerz. At IBM we used an very high-end FPGA which cost over $5000 per FPGA. In this FPGA the maximum clockrate for the Soft-460 was 210 MHz. What do we clearly see here: - FPGA by design will always reach a lower clockrate than ASIC. - The used FPGA reaches only 20% speed of the ASIC but had 200 times higher cost! If we would have used a more reasonable priced FPGA e.g. for $100 per unit - the speed of the 460-CPU would have been much lower - more like 80 MHz. Part of the FPGA IBM team did also run various benchmarks on the PPC 460 Core and compared the PPC with 2 other FPGA cores. One of the 3 benchmarked cores was APOLLO Core. APOLLO did win this benchmark shootout by far. It was clearly visible that if running in the same FPGA - APOLLO was much faster then the PPC and the other RISC chip which competed against it. So its very clear: Putting a PPC as "accelerator" in an FPGA makes no sense. As its not faster than APOLLO 68080 but much slower. A PPC inside an FPGA can run PPC software but a lower speed than existing ASICs. Roughly ~ 10 times slower than existing ASICs. ... A PPC in FPGA will be just to slow for reasonable OS4 or anything like this. I'm pretty sure no one will like running OS 4 on a PPC460 @ 80MHz, right? It will crawl. Adding a daughter CPU board with e.g. 800 MHz PPC will make a lot more sense. The problem with PPC is that its dying technology. In the 90th this was totally different - there PPC was emerging technology, there you could get good priced, reasonable PPC chips. But this is not the case today anymore. Today all company are abandoning PPC technology. Its getting very difficult to find good PPC chips today allowing you to build a CPU card.

The CISC 68k has a reduced instruction set computer architecture compared to RISC PPC. MMU timing is often a critical path in CPU design and timing may be difficult to maintain in a FPGA core, likely one of the reasons why Gunnar dropped MMU support from the AC68080. Amiga technology is degrading with the removal of FPUs, extended precision to double precision FPU downgrades, no MMU or reduced embedded MMU downgrades, etc., all with a reduction in 68k Amiga compatibility. Before long, we will be back to an 8-bit 6502 and Trevor will be talking about how he loves his 6502. He can put a WDC SBC in a huge desktop box with some chicken lips stickers and his fantasy can continue until he is in an old person's home, an insane asylum or prison with his fixer lawyer Ben.

@matthey

Quote:

matthey wrote: cdimauro Quote: I don't think that the 6502 crippled the SNES. For what was the purpose of the CPU, it was a perfect match for SNES' chipset, because... it was a very powerful console. Contrary to the usual belief, CPUs were mostly the slaves of the chipset: they were there mostly to load the hardware's registers, and business logic was a very limited piece of the cake. What other console other than SNES had so many CPUs and DSPs in cartridges?

It depends on the specific game (3D, for example, was out of range for the SNES's CPU).

Some games also used such extra chips as protection.
Quote:

The 1988 Sega Genesis/Mega Drive with a 68000 held its own against the 1990 SNES with a Ricoh 5A22 (16-bit 6502 family).

The ISA is 16-bit, but its data bus is 8-bit, which furtherly crippled its performance.
Quote:

The Genesis is older and inferior on paper except for the CPU which should be close in performance but the Genesis feels faster and it was not common for it to have CPU and DSP replacements in cartridges.

Making comparisons is difficult. The same games should be compared to be more objective.

As I've said before, 3D games are more difficult for the SNES's CPU, and here the Genesis' CPU has a clear advantage. However, Genesis's 32X was developed mostly for 3D games, because more complex 3D games were more demanding in terms of required performance.
Quote:

SNES games were often more colorful but also often sluggish in my experience. I would like to think some of it was due to the CPU.

It could be the reason, but it's difficult to prove it.
Quote:

The 68k Amiga was also responsive and versatile compared to the competition and I do not believe it was just the chipset and AmigaOS.

Nevertheless, it was used as the slave of the chipset when talking about games, because the first actor was the Blitter here (second was the sprites).
Quote:

cdimauro Quote: An enhance 68k for games isn't a good solution. Rather the opposite: it gives big compatibility problems. Here it's better to stick to the exact 68000 design. 68020 is less a concern, because of the code cache. So, 68020 games could likely run well on a super-duped 68k core. While a deeply embedded 6502 CPU core is acceptable, I would rather have a 68000 core for I/O and game compatibility.

I even haven't considered a 6502 core.

As I've said before, a 68000 is an absolute requirement for a 68k-based retro platform for compatibility reasons. It can also be used as an I/O chip, as you've said, or as an "orchestrator" like the 68000 in the Jaguar chip, even when primary CPU that it's used is a 680x0 with steroids.

I don't see any value on integrating other cores from other CPU families, unless the retrogaming station should be used for many other, different, systems. But here the problem is that there several CPU families used: what to integrate? Too much stuff would complicate the platform.

P.S. I agree about the PowerPCs: they are EoL and it's non-sense trying to get an FPGA version, which will be running at very low frequency -> very poor performance. Whereas there are still several cores available which are performing much better.

Quote:

cdimauro wrote: @matthey Quote: matthey wrote: What other console other than SNES had so many CPUs and DSPs in cartridges? It depends on the specific game (3D, for example, was out of range for the SNES's CPU). Some games also used such extra chips as protection.

Which is confirmed, looking at the list of such DSPs: List of Super NES enhancement chips

There are only a few games that used such extra chips for things that a 68000 might be better at, compared to the SNES's CPUs.

- The DSP-3 is only in the turn-based strategy game SD Gundam GX for Super Famicom. It assists with tasks like calculating the next AI move, Shannon–Fano bitstream decompression, and bitplane conversion of graphics.
But here it does also other things (where a 68000 was also not suitable for), and not only for the AI.

- The ST series of chips are used by SETA Corporation to enhance AI.
Only three games used it, only for the AI.

Basically only three games using the above ST chips where a 68000 MIGHT have been a better choice compared to the SNES's CPU. Too little, considered the thousands of games developed for the SNES.

@matthey

Quote:

Releasing the C65 before AGA for the Amiga likely would have reduced Amiga sales. The C128 was more expensive to produce than the Amiga 500 and it likely reduced Amiga sales and Commodore profit margins. The SNES showed it was possible for a late 6502 family CPU console to be successful. The 6502 family CPU crippled the nice SNES console chipset but it was cheap and there were enough experienced 6502 assembly programmers to make it a success.

SNES's 65816 CPU's math power was supported by custom DSP and SuperFX (this 16-bit RISC coprocessor development led to Argonaut RISC Core CPU family) add-ons.

65xx/65xxx CPU family's slow R&D pace led to ARM and ARC RISC CPUs.

Quote:

Launching the Amiga with a 6502 family CPU would have lowered the price, could have improved compatibility with the C64 and may have been more appealing to C64 owners. Commodore failed to upgrade enough C64 owners to the 68k Amiga. I strongly believe the 68k was the right choice for the Amiga but Commodore should have moved to a 68020 sooner with 6502 and 8088 emulation rather than using a 68000 Amiga with bridgeboards that catered to the business PC market instead of home and gaming PC market, including C64 customers.

Commodore PC clone's Jeff Frank is the wrecking ball on the Amiga group.

Jeff Frank's Commodore PC-40 III effort used a 3rd party chipset from Western Digital's Farday ASICs. https://theretroweb.com/motherboards/s/commodore-pc-40-iii#chips

From Commodore - The Final Years

On the second day of the meeting, Gould and the worldwide
executives approved of Jeff Frank’s work with the PC clones.
Specifically they wanted the cost-reduced PC10-III and the Intel
386-based PC40-III to go forward with pilot production in October,
although it was agreed to cancel the PC30-III at the meeting.
The executives also approved of a PC50 and PC60 based around
the Intel 386 architecture to come after the PC40-III release

(skip)

PC Clones
The PC clone division, begun in 1986 under Gerard Bucas, had
become one of the cornerstones of Commodore’s profits. That trend
continued, and now the division, headed by engineer Jeff Frank with
some of the German engineers, would remain profitable until at least
the end of 1989.


Commodore's bad 386 inventory control caused inventory write down.


“Compaq came out with a 386 machine first because they were
working directly with Intel. No one else had a 386 machine, not even
IBM. And everyone else was scrambling to come out with a 386
machine.�
In 1989 Commodore was finally about to match what Compaq had
released years earlier. “By the time they came out with a 386
machine, Compaq came out with a 486 machine,� says Augenbraun.
“So everyone was sort of a generation behind, other than Compaq,
including IBM. So Commodore was in with the unwashed masses of
being a generation behind, and Commodore was even slightly
worse.�

Intel had announced the 80486 at the Spring COMDEX in April
1989, with samples of the new chip expected for the third quarter of
1989 and production quantities in the fourth quarter of 1989. And as
usual, Compaq was the first to announce a system using the new
chip. “Until it got to the 486, Commodore was trying to build the
previous generation machine. They were really behind,� says
Augenbraun.




Quote:

The 68060 and 6x86 both chose integer performance over FPU performance and picked on the shallow 5-stage Pentium pipeline. The 6x86 may have copied features from the earlier 68060 as the design has similarities. The 68060 was earlier, has a better ISA with better code density, has a lower latency FPU with a much better FPU ISA and is smaller area for upgrading the caches.

https://youtu.be/xueMYhXmAGw?t=838
Pentium 100 Mhz vs Cyrix 6x86 100 MHz and both have 50 MHz 64-bit FSB.

Open JPEG: Cyrix is 134.6% of P100, Cyrix is faster.

SolidWorks open file: Cryrix is 96.8% of P100, Cryrix is slower.

Bryce 3D render: Cryrix is 74% of P100, Cryrix is slower.

Sort and Recalc in Excel: Even

WinStone Extraction: Cyrix is 105% of P100, Cyrix is faster.

Winstone 99, Office 97 runtime: Cyrix is 123% of P100, Cyrix is faster.

Doom: Cyrix is 97.9% of P100, Cyrix is slower.

Quake: Cyrix is 69.7% of P100, Cyrix is slower.

Unlike 68060, Cyrix 6x86 has 16 bytes per cycle fetch from L1 instruction cache.


https://www.tomshardware.com/reviews/return-jedi,26-2.html
MMX performance
3D
6x86MX @ 166Mhz = 66.41
6x86MX (M2) @ 187.5 Mhz = 74.91
K6 166 = 102.77
K6 200 = 122.15
K6 233 = 141.07
Pentium MMX 200 = 159.78
Pentium Pro 200 = 211.55 (not MMX)
Pentium II 233 = 247.49


Image Processing
6x86MX @ 166Mhz = 547.41
6x86MX (M2) @ 187.5 Mhz = 617.87
K6 166 = 527.55
K6 200 = 605.07
K6 233 = 697.16
Pentium MMX 200 = 684.98
Pentium Pro 200 = 219.7 (not MMX)
Pentium II 233 (512 KB L2 cache) = 1051.64


Video
6x86MX @ 166Mhz = 226.47
6x86MX (M2) @ 187.5 Mhz = 257.72
K6 166 = 228.71
K6 200 = 269.14
K6 233 = 308.54
Pentium MMX 200 = 252.07
Pentium Pro 200 = 160.22 (not MMX)
Pentium II 233 = 276.61


Audio
6x86MX @ 166Mhz = 210.04
6x86MX (M2) @ 187.5 Mhz = 236.94
K6 166 = 200.79
K6 200 = 238.11
K6 233 = 273.22
Pentium MMX 200 = 326.58
Pentium Pro 200 = 232.32 (not MMX)
Pentium II 233 = 395.88


https://archive95.net/view-amigaplus_n/http://www.newtek.com/tech/faqs/lightwav/multi/bench.html
Lightwave benchmarks
DOF.lws
Amiga (Phase5/060): 48 min. 33 sec
MAC 8500/150mhz = 4 min. 31 sec.
Intel P5/166 = 4 min. 30 sec.
Intel PP200 = 2 min. 36 sec.
Dual PP200 = 1 min. 36 sec.
Alpha 366 MHz = 1 min. 20 sec.
Alpha 500 MHz = 54 sec.
SGI 02 R10K = 2 min. 1 sec.
Ultrasparc 167 MHz = 3 min. 28 sec.

Raytrace.lws
Amiga (Phase5/060): 5hr 28min. 14 sec.
MAC 8500/150mhz = 31 min. 51 sec.
Intel P5/166 = 37 min. 43 sec
Intel PP200 = 20 min. 24 sec
Dual PP200 = 12 min. 20 sec
Alpha 366 MHz = 13 min. 48 sec
Alpha 500 MHz = 12 min. 34 sec
SGI 02 R10K = 23 min. 58 sec.
Ultrasparc 167 MHz = 26 min 57 sec.

Ligtwave benchmark discussion from https://eab.abime.net/showthread.php?t=113338&page=8


Other Raytrace.lws benchmark results with low resolution settings from Hold and Modify on YouTube
A3000, Phase5-MKII (060@50), OS3.2.1 = 52m 24s
A1200, TF1260 (060@50)128MB, OS3.2.1 = 54m 22s
A4000, BFG060 (rev5) 060@50, 128MB, OS3.2.1 = 43m 46s
A2500, PP&S (040@25), OS3.3.2.1 = 2h 2m8s

A1200/Vamp v2 Coffin56/Gold2.12fw - 1526s (25m 26s)
Amiga4000D 3.2.1 WarpEngine060@96MHz - 1477s (24m 37s)
Vampire V4SA+ Coffin57/SA_8435.jic (x14) - 1405s (23m 25s)
Amiga4000T 3.2.1, BFG9060@100MHz - 1358s (22m 38s)

A4000D, TF4060, 060@100 (Rev6), AmigaOS 3.2.2.1 - 28 minutes

Last edited by Hammer on 11-Mar-2025 at 09:36 AM.
Last edited by Hammer on 11-Mar-2025 at 09:26 AM.
Last edited by Hammer on 11-Mar-2025 at 09:23 AM.
Last edited by Hammer on 11-Mar-2025 at 09:06 AM.
Last edited by Hammer on 11-Mar-2025 at 08:52 AM.
Last edited by Hammer on 11-Mar-2025 at 08:46 AM.
Last edited by Hammer on 11-Mar-2025 at 08: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

@cdimauro

Quote:

Definitely, it was a bad luck. FPU weren't that important before Quake, and it was good to focus on the GP/integer part of the chips.

Strong FPU is important for 3D rendering, not just Quake e.g. Bryce 3D.

MS Excel also supports FPU.

Bryce 3D v3 is available for Mac 68K, hence they should run on fake Mac Amigas.

Bryce 3D v3.1 is available for Windows 95/NT 3.5/NT 4.

Last edited by Hammer on 11-Mar-2025 at 09:05 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

@minator

Quote:

minator wrote: @Heimdall Quote: But, since we're already entertaining a what-if scenario here, how much of a CPU feature-set could I theoretically implement in, say, 3-4 months full-time (after I spend 1 month with initial familiarization of the FPGA coding) ? Would that even make a dent at all? If it's just a means to an end (you just want a PowerPC in an FPGA), then it'll take very little time because the link I pointed to above is to an existing Power architecture (read PowerPC) soft core. To do one from scratch, I've no idea, I'm interested to know myself. I guess it'll depend on what you want to build, and how much open source material you can use, or at least look at and, if you plan to use it, how much AI can help.

Oh, I missed that completely while browsing the github link! I wouldn't care to rewrite one from scratch, if it (or majority of it) already exists, of course.
I'll go take another look at your link!

To me, it'd be important because I could observe (as a coder) real-life behavior of the RISC pipeline with all its bubbles and slowly keep refactoring the code to remove all of them.

This was the most satisfying part of working with Jaguar's GPU/DSP, even if it became exceedingly frustrating by the endless stream of HW bugs. But since there would be no HW bugs here on the PowerPC, it could just be pure enjoyment !