@matthey

Quote:

matthey wrote: Hammer Quote: The 6809 (with 16-bit ALU) family is a dead-end since it's not compatible with the 68000 (with 16-bit ALU). Motorola ground-zeroed the 68xx desktops with an incompatible 68000. Motorola kills its established platforms. The 1978 6809 and 1979 68000 were not far apart in development or philosophies. It was reasonable to believe that the 6809 using 9,000 transistors would remain cheaper and lower end than the 68000 using 68,000 transistors (~7.6 times as many transistors). The 68000 killed the 6809 though which shows how important economies of scale are to chip production. The 6809 is one of the best 8-bit/16-bit CPU designs and it is too bad it was released so late. There is nothing wrong with releasing a much improved but incompatible CPU like the 16-bit/32-bit 68000. It was a better choice than breaking compatibility for improvements that still leave the CPU too limited like from the Intel 8080 to 8085.

Indeed.

BTW, Intel 8086 was source-assembly "compatible" with the 8085, which allowed to both recompile existing applications and greatly enhance the architecture.

Something which very common at the time, were source-level compatibility was much better than binary compatibility.

Motorola did the same with some of its 68xx processors. I've studied the 68HC12, which was only source-compatible with the 68HC11, but with a much better opcode structure and several enhancement. A great work and a great processor (albeit I've found that 68HC16 was another one which is source-compatible with the 68HC11. But I had no chance to study it).
Quote:

Hammer Quote: Zilog ground zero Z80 CP/M desktops with incompatible 16-bit Z8000. Early install base gains are wiped out. Zilog killed the Z80 CP/M establishment. Non-Z80 CP/M is not compatible with Z80 CP/M, i.e. CPU ISA difference wasn't abstracted. Lack of compatibility was not the only problem for the Z8000. The 8086 was earlier with 808x compatibility and support chips, the 8088 was at the same time but cheaper and the higher performance and better 32-bit ISA 68000 came shortly after. The Z8000 was a new incompatible design but not the best anywhere and had bugs. They were unlucky that the competition improved so much in a short period of time. The later NS32k CPUs were good too but the 68000 was better and the early NS32k CPUs also had bugs. New ISAs are difficult to introduce and gain support for them which is why it is better to reintroduce good old ISAs which still have support and software like the 68k.

Binary compatibility is a key principle/requirement for more modern software, but it creates problems for the evolution of the architecture & microarchitectures. So, it good to have, IF possible.
And 68k is important for this: a lot of software is only available in binary format.

Fortunately and since a lot of software is recompilable nowadays, it's becoming less and less important (which is a chance that new architectures can take). But this is a general statement for modern software.
Quote:

Hammer Quote: FYI, 8087 also handles INT32 and INT64 datatypes in addition to FP32, FP64, and FP80. 8087 is a math coprocessor, not just a FP math coprocessor. If it is faster to perform 32-bit and 64-bit calculations in the integer unit then it will be used instead of the FPU. I expect this is usually the case for 32-bit integer datatypes and 64-bit integer datatypes would have been exceedingly rare back then and still are rare on the 32-bit ISA 68k Amiga. Also, using the FPU may require expensive changing of the default rounding mode and even then results may not be exactly the same as performing all integer calculations. You are applying modern CPU usage to a time when 8-bit and 16-bit integer datatypes were 95+% of the datatypes.

Exactly. Lack of contextualisation is one of his major problems.
Quote:

The 68000 32-bit datatype usually went unused but 32-bit datatypes were important for the large flat address space. The same was true when moving from 32-bit to 64-bit where 64-bit datatypes were rarely used but a larger address space was needed. Some early benchmarks showed better performance with 32-bit than 64-bit where resources are limited. If the address space is not needed, a 32-bit CPU can provide better performance and use fewer resources.

Yes, in general.

Some architectures can mitigated the usage of 64-bit pointers, allowing to reduce their impact, or even do better than 32-bit pointers.

New 68020's, 68030's, and 68040's are still being produced (and they are expensive) but is it really true that Motorola lost their blueprints for the 68060 CPU, as some claim? Sounds a bit like a dog ate my homework at school.

But also Commodore lost their blueprints for their custom chips, like Paula, so they could not improve the audio circuit for AGA even if they wanted to? Looks like Motorola and Commodore had something in common, namely losing their blueprints for their precious hardware.

https://www.rocelec.com/category/all-parts?manufacturer=Freescale

coder76 Quote:

New 68020's, 68030's, and 68040's are still being produced (and they are expensive) but is it really true that Motorola lost their blueprints for the 68060 CPU, as some claim? Sounds a bit like a dog ate my homework at school. But also Commodore lost their blueprints for their custom chips, like Paula, so they could not improve the audio circuit for AGA even if they wanted to? Looks like Motorola and Commodore had something in common, namely losing their blueprints for their precious hardware. https://www.rocelec.com/category/all-parts?manufacturer=Freescale

The 68000 is still available directly from NXP but "no longer manufactured".

https://www.nxp.com/products/MC68000

Like Rochester Electronics, they mostly dice up old wafers with the CPU dies to create new chips. Rochester has the capability, IP and license to produce completely new chips from scratch but that is more expensive and may not be financially viable in smaller quantities.

Some unwanted products are buried deep. The Amiga Ranger chipset perhaps fits that category the most as it not only disappeared but info and references were so scarce at Commodore that Dave Haynie considered it a myth even though there is Commodore documentation that talks about it and Jay Miner said he completed the design. I really doubt losing Paula was the reason for not upgrading it for AGA. It was more likely due to Paula using analog circuits that make enhancing it and moving it to CMOS more difficult and the lack of time after delaying AGA. I have not heard the 68060 "blueprints" were lost but I believe the 68060 was aggressively sabotaged so it would not compete with PPC. Motorola would have been incompetent if an 8-stage 68060@50MHz using a 500nm process was all that was possible. A 68060@66MHz was already being tested before the 68060 was released and the design should have been able to reach ~150MHz using that process with continued development. It is possible that upper managers could make designs disappear or end up in unusual places so they can not be brought back to embarrass them and ending any hope from supporters and "enemies" within the business but that is reaching a level of corruption. I would not put it past Commodore which had some corruption but I would be more surprised about Motorola despite gross mismanagement and political maneuvering instead of making technology based decisions.

Welcome to Amigaworld since this is your first post. It is nice to see some of the new users are not trolls or bots.

@matthey

Quote:

IBM and Motorola codeveloped and shared PPC technology. I believe some of the IBM PPC designs were very much overrated like the PPC970 (G5), PPC Cell (PS3) and PPC Xenon (XBox 360).

Game console PPEs focus on 3D games with a budget price.

PPE has a single pipeline for normal scalar ALU, hence they are 68040 class with very high clock speed and profitable yields.

Quote:

Motorola/Freescale tended to produce more practical PPC designs but they sometimes suffered from minimization like the PPC603 (worst Macs ever) and castration like the QorIQ P1022 (A1222 with standard PPC FPU removed), especially for embedded use.

FYI, the early IBM PPC 601 doesn't have Motorola's 88000 60x bus support.

PPC603's small cache has a performance issue with 68K emulation.

_________________
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

Quote:

matthey wrote: The 68000 is still available directly from NXP but "no longer manufactured". https://www.nxp.com/products/MC68000 Like Rochester Electronics, they mostly dice up old wafers with the CPU dies to create new chips. Rochester has the capability, IP and license to produce completely new chips from scratch but that is more expensive and may not be financially viable in smaller quantities. Some unwanted products are buried deep. The Amiga Ranger chipset perhaps fits that category the most as it not only disappeared but info and references were so scarce at Commodore that Dave Haynie considered it a myth even though there is Commodore documentation that talks about it and Jay Miner said he completed the design. I really doubt losing Paula was the reason for not upgrading it for AGA. It was more likely due to Paula using analog circuits that make enhancing it and moving it to CMOS more difficult and the lack of time after delaying AGA. I have not heard the 68060 "blueprints" were lost but I believe the 68060 was aggressively sabotaged so it would not compete with PPC. Motorola would have been incompetent if an 8-stage 68060@50MHz using a 500nm process was all that was possible. A 68060@66MHz was already being tested before the 68060 was released and the design should have been able to reach ~150MHz using that process with continued development. It is possible that upper managers could make designs disappear or end up in unusual places so they can not be brought back to embarrass them and ending any hope from supporters and "enemies" within the business but that is reaching a level of corruption. I would not put it past Commodore which had some corruption but I would be more surprised about Motorola despite gross mismanagement and political maneuvering instead of making technology based decisions. Welcome to Amigaworld since this is your first post. It is nice to see some of the new users are not trolls or bots.

Thanks, been reading this forum for a long time though. Gunnar said on his site that the Apolloteam had contacted Motorola a long time ago (is it nowadays called FreeScale or NXP?), and he said they couldn't produce new 68060 CPUs even if they wanted to, because they had lost some data about it. Well, it seems this is true, as nobody is producing new 68060's these days, but instead all the lower versions of m68k CPUs are produced. Certainly there would be a market for 68060's as well in embedded systems. So the AC68080 is based on the design of the 68040 as I understood it.

@matthey

Quote:

The 1978 6809 and 1979 68000 were not far apart in development or philosophies. It was reasonable to believe that the 6809 using 9,000 transistors would remain cheaper and lower end than the 68000 using 68,000 transistors (~7.6 times as many transistors). The 68000 killed the 6809 though which shows how important economies of scale are to chip production. The 6809 is one of the best 8-bit/16-bit CPU designs and it is too bad it was released so late. There is nothing wrong with releasing a much improved but incompatible CPU like the 16-bit/32-bit 68000. It was a better choice than breaking compatibility for improvements that still leave the CPU too limited like from the Intel 8080 to 8085.

The application CPU market is different from a single-use case embedded CPU market.

If Motorola doesn't care about backward compatibility, why would the application platform vendor stay with Motorola?

Next-gen GUI software requires new platforms, hence the 68000's initial desktop computer success.

Intel evolved the 16-bit ALU 8086/8088 into a 32-bit 80386 that enabled the Compaq 386AT standard to beat IBM's 32-bit RT PC in 1986.

Quote:

From the in-order P54C Pentium to in-order Pentium MMX with 16kiB L1i+L1d circa 1997

FYI, Pentium MMX is P55C.

P54C followed the original P5 in 1994. P54C still has 8KB+8KB L1 cache.

Quote:

The OoO P6 Pentium using 5.5 million transistors initially could not double caches to 16kiB L1i+L1d until about 1997 with the Pentium II.

Pentium Pro has an on-chip package L2 cache chip that is faster than Pentium's motherboard L2 cache.

Pentium Pro has a re-order buffer, 2X larger TLB cache and, etc'.

Quote:

All these plans for the 68060 were cancelled shortly after announcement in 1994. Organic development of Motorola's 68k and 88k babies were thrown in the trash for IBM's PPC. The PPC AIM was more of a misfire that turned into a disaster for Motorola (and Apple) as both the embedded market and desktop market were surrendered.

For 1993, 68EC040 @ 25 Mhz wasn't a low-cost $40 like MIPS R4000 @ 93.75 MHz for the N64 project since 68060's 1994 release was late for post 16-bit embedded game console development since graphics custom chips are designed with host CPU's external bus characteristics in mind.

No Motorola 68K was competitive at $30 to $40 against MIPS R3051 (MIPS R3000A with embedded MMU) and N64 R4000 respectively.

PPC E-Book's embedded MMU was supposed to counter MIPS's embedded MMU.

X86 vendors offer Coppermine 128KB L2 cache and K7 Duron for the original Xbox project, which targeted MIPS game console CPU prices. These partly defective x86 CPUs are being thrown (offered) at the game console market.

IBM competed in the game console market with the PPC 602 and later, the PPE.

The mainstream Amiga has an inherent game console pricing consideration, and Motorola was unable to offer a competitive 68K CPU for the game console price range. The Amiga is not a Mac.

Last edited by Hammer on 29-Mar-2025 at 11:17 PM.

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

@coder76

Quote:

coder76 wrote: But also Commodore lost their blueprints for their custom chips, like Paula, so they could not improve the audio circuit for AGA even if they wanted to? Looks like Motorola and Commodore had something in common, namely losing their blueprints for their precious hardware.

For the C65 project, the CSG LSI team's engineers studied Amiga's custom chipset designs for 8 bit-plane evolution. CSG LSI team lost the SID engineers, and it would take a year to study the SID design, hence they "glued" two SIDs for a stereo SID.

AAA's Mary chip evolved from Puala, which is dependent on AAA's Andrea, the Agnus' replacement.

CSG LSI team's engineers spec'ed and designed AA Lisa and Alice while the Amiga group (not the original Los Gatos Amiga graphics chip engineers)'s primary system engineers and VLSI team focused on AAA chipset R&D.

AAA's Andrea R&D was distracted by other R&D projects, e.g. C65 and 2MB ECS Agnus bugs for about a year. Alice R&D is dependent on 2MB ECS Agnus R&D.

R&D time was wasted on monochrome ECS Denise, hence the switch to four-color ECS Denise after VGA and Mac II 1987 releases. Henri Rubin ordered #metoo monochrome ECS Denise R&D. At least ECS Denise and ECS Agnus A were demonstrated to be working in Q4 1988. ECS Denise has a separate 64 color palette circuitry from OCS's 4096 color palette.

Henri Rubin cancelled the Amiga Ranger chipset R&D in mid-1986.

The new Amiga group (these were from the C900 project) kept the chip designer for Paula, hence Mary was created, while the Los Gatos Amiga graphics / Agnus chip designers were shown the door. Commodore focuses on hiring more engineers for UNIX and PC R&D!

Read Commodore - The Final Years book.

There were three primary engineering groups;

1. The system engineer group that designed C900, taken over Amiga R&D, was distracted due to Henri Rubin's leadership. Unfocused R&D expanded into Unix R&D, PC bridgeboards, add-ons R&D and 'etc.

The system engineer group's cost-reduction team did a good job with A500.

C900 debacle repeated with Henri Rubin's AMIX project.
Henri Rubin's A2024 monitor production debacle, a workaround for OCS's lack of stable resolution modes for business. 5000 units production scale.
Henri Rubin's CDTV debacle.
Henri Rubin's ECS A3000 debacle.
Jeff Frank's ECS A600 debacle.
Jeff Frank's ECS A2200 debacle.

2. The original Los Gatos Amiga group, which designed the OCS. A500 OCS has been sustaining Commodore after the C64.

3. CSG LSI group, designed VIC-20, C-64 and C-65. C64 has been sustaining Commodore.

4. CBM PC group. Jeff Frank's group before taking over the Amiga's system engineer group in June 1991. Excess inventory f_ckup in 1989 and repeated later.

Jeff Frank's PC-40 III project used a Western Digital chipset. Jeff Frank is a con job.

Last edited by Hammer on 30-Mar-2025 at 12:35 AM.
Last edited by Hammer on 29-Mar-2025 at 11:59 PM.

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

@cdimauro

Quote:

Exactly. Lack of contextualisation is one of his major problems.

Wrong, killer app Lotus 123 2.0 supports x87.

You didn't factor in software's R&D time after the platform's initial release.

You didn't factor in the platform's system integration R&D time after the CPU's initial release.

Intel 8087 was released in 1980.
IBM PC 5150 was released in August 1981 and had an 8087 socket.

Motorola 68881 was released in 1984.
Mac II was released with official 68881 support in March 1987.

The 1st AutoCAD release for the IBM PC was in December 1982. As Autodesk's flagship product, by March 1986, AutoCAD had become the most ubiquitous CAD program worldwide.

The 1st Lotus 123 release for the IBM PC was in January 1983. Lotus 123 quickly overtook establishments such as VisiCalc, as well as MS's Multiplan and Sorcim's SuperCalc.

In terms of unit sales, C64 was keeping up with the IBM PC until around 1984. PC's "killer apps" help ramp up PC unit sales when coupled with multi-sourced PC clones.

After Multiplan's defeat, MS executed a plan to dethrone the high-resolution text UI Lotus 123 establishment with "next gen" high-resolution GUI MS Excel that depends on privileged access to MacOS's task switcher road map at the expense of Lotus Jazz's harder all-in-one effort.

Let that sink in.

Last edited by Hammer on 30-Mar-2025 at 01:28 AM.
Last edited by Hammer on 30-Mar-2025 at 01:27 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

coder76 Quote:

Thanks, been reading this forum for a long time though. Gunnar said on his site that the Apolloteam had contacted Motorola a long time ago (is it nowadays called FreeScale or NXP?), and he said they couldn't produce new 68060 CPUs even if they wanted to, because they had lost some data about it. Well, it seems this is true, as nobody is producing new 68060's these days, but instead all the lower versions of m68k CPUs are produced. Certainly there would be a market for 68060's as well in embedded systems. So the AC68080 is based on the design of the 68040 as I understood it.

Motorola spun off their semi business into Freescale in 2004 and Freescale merged with NXP in 2015. Freescale may still be a division of NXP but it looks like they are using the NXP brand and phasing out the Freescale brand.

The Natami team which included Gunnar contacted Freescale and asked if they had any problem with the creation of a new 68k core. Freescale responded that they had no issues with it. The Natami team first evaluated a Freescale ColdFive V4 CPU for the Natami but the poor 68k compatibility kills performance.

Restarting production of the 68060 using the old masks is not practical as the wafer size is no longer produced or available. Rochester may have old wafers with 68060 dies that they can slice up and turn into chips but with limited supplies. They are currently out of 68060 CPUs and have been for some time despite their high price. They used to have hundreds in stock. Mass production of the 68060 at an affordable price would require new masks and a much newer process but changes would be desirable to take advantage of the process improvements and add enhancements. The die size with mass production would likely cost less than one Euro so it would be good to beef it up and likely turn it into a SoC to be more competitive. The RP2040 price is less than $1 USD in quantity and it uses more transistors than a 68060 and AA+ combined.

https://en.wikipedia.org/wiki/RP2040
https://en.wikipedia.org/wiki/RP2350

The RP2350 successor uses significantly more transistor and has a price as low as $0.80 USD. The question is whether there is enough demand to cover several million USD for licensing, development, masks and initial production runs. A modernized 68060 ASIC would provide a major performance improvement and cost savings if the 68k market is large enough. The FPGA AC68080 SoC core could be turned into an ASIC as well and really needs to be to compete with JIT emulation of the 68k. I tried to make it happen as part of the Apollo team but Gunnar sabotaged his own project. I doubt the AC68080 is anywhere near the quality of the 68060, the AC68080 ISA has issues and Gunnar protects his precious too much making an ASIC unlikely but there are some cheap ASIC conversions that may allow the AC68080 to compete with the PiStorm at least.

I believe there would be an embedded market for the 68k again if professionally developed and turned into a nice SoC with modern embedded features and ColdFire compatibility. It would be a hard sell to replace mainstream embedded ARM but there are enough embedded niches like retro/gaming/hobby, big endian embedded support, easier 68k/ColdFire/SuperH embedded replacements and more standard ultra code density/small footrprint embedded systems than Thumb(-2). Before the RPi, RPi fabless semi development and the hot retro market, there would have been more naysayers but times have changed.

I would say the superscalar AC68080 is more like the superscalar 68060 than scalar 68040 although there are some similarities to both and departures from both. The AC68080 is perhaps more like the Cyrix 6x86 but with split L1 cache. The AC68080 is claimed to use instruction folding/fusing to turn pairs of instructions into internally executed 3 op instructions which is unique among these older CPUs. There are other unique features that other architects avoid like non-orthogonal register banks everywhere Gunnar could put them. The PPC A1222 CPU cores removed the standard PPC FPU register file to save transistors for embedded use while Gunnar has expanded the AC68080 register files to be larger than PPC. Gunnar's goal seems to be to dominate the desktop market with performance rather than sell 68k embedded SoCs. Probably not the best decision for potential investors.

@matthey, right and unfortunately.

Anyway, (ex)Motorola should have the RTL/HDL at least for the ColdFire series: V5 could be a very good starting point for rebuilding a 68060+ running at much higher frequencies (V5 reached 500Mhz, AFAIR. With an old process).

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Exactly. Lack of contextualisation is one of his major problems. Wrong,

Where? In this PRECISE context, I mean.
Quote:

killer app Lotus 123 2.0 supports x87.

https://en.wikipedia.org/wiki/Lotus_1-2-3#PC_version_history

"Release 2 brought add-in support, better memory management and expanded memory support, supported x87 math coprocessors, and introduced support for the Lotus International Character Set (LICS). Introduced in September 1985."
Quote:

You didn't factor in software's R&D time after the platform's initial release.

Which takes time on x86 due to the poor ISA. Especially for programming the x87.
Quote:

You didn't factor in the platform's system integration R&D time after the CPU's initial release. Intel 8087 was released in 1980. IBM PC 5150 was released in August 1981 and had an 8087 socket. Motorola 68881 was released in 1984. Mac II was released with official 68881 support in March 1987.

Right. And YOU didn't factor that:
- 68k + 68881 is WAY EASIER to develop for;
- Lotus Release 1 was the first release for DOS-based PCs. Introduced in January 1983;
- Lotus Release 1A in April 1983
- Lotus Release 2 [...] Introduced in September 1985.

Read: Lotus 2 with x87 took 2.5 years of R&D with a very poor ISA. It surely have required much less for 68k + 68881.
Quote:

The 1st AutoCAD release for the IBM PC was in December 1982. As Autodesk's flagship product, by March 1986, AutoCAD had become the most ubiquitous CAD program worldwide.

Let me quote YOU:

XCad vendor, Cadvision international, has exited the Amiga platform. CADVision Systems is a major provider for Dassault Système SOLIDWORKS.

https://www.nextcomputers.org/NeXTfiles/Articles/NeXTWORLD/NeXTWORLD_Extra/92.04.SummerNWE/92.04.SummerNWExtra12.html

Ditek has sold 10,000 units of DynaCADD since 1985, with 30 percent in North America and most of the balance in Germany, where Amiga and Atari flourish. Also shipping this fall, according to Asher, will be 10 to 15 third-party products taking advantage of DynaCADD's open, extensible architecture.

More from https://www.atarimagazines.com/startv4n3/dynacadd.html

We'll be reviewing DynaCADD in START, head-to-head against AutoCAD, in the near future-and we'll all see its real power But Atari users can reap the benefits of this program now. The first thing you notice about the program is that it runs much faster-up to nine times faster according to ISD. This speed increase is even more apparent on a system with a math coprocessor.

I highlight nothing here, because it should be self-explanatory.
Quote:

The 1st Lotus 123 release for the IBM PC was in January 1983. Lotus 123 quickly overtook establishments such as VisiCalc, as well as MS's Multiplan and Sorcim's SuperCalc.

See above.
Quote:

In terms of unit sales, C64 was keeping up with the IBM PC until around 1984. PC's "killer apps" help ramp up PC unit sales when coupled with multi-sourced PC clones.

Irrelevant?
Quote:

After Multiplan's defeat, MS executed a plan to dethrone the high-resolution text UI Lotus 123 establishment with "next gen" high-resolution GUI MS Excel that depends on privileged access to MacOS's task switcher road map at the expense of Lotus Jazz's harder all-in-one effort.

You forgot my favourite Borland's Quattro: https://en.wikipedia.org/wiki/Quattro_Pro
Quote:

Let that sink in.

You need to sink everything in: not only what YOU like.

In short: 68k allowed easier and faster development times, and faster execution even without a coprocessor.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Exactly. Lack of contextualisation is one of his major problems. Wrong, killer app Lotus 123 2.0 supports x87... Intel 8087 was released in 1980. IBM PC 5150 was released in August 1981 and had an 8087 socket. Motorola 68881 was released in 1984.

Lotus 123 didn't support the 8087 until version 2.0, released in September 1985.

Microbotics released their Starboard 2 RAM expansion with 68881 option for the A1000 in 1986. However there wasn't much interest in FPUs on the Amiga until 1987 when Eric Graham released Sculpt 3D. By the time we wanted an FPU Motorola had delivered.

Quote:

The 1st AutoCAD release for the IBM PC was in December 1982. As Autodesk's flagship product, by March 1986, AutoCAD had become the most ubiquitous CAD program worldwide.

The main reason AutoCAD became ubiquitous on the PC was that it was the first CAD program for the PC. It was pretty sucky on a PC in 640x200 CGA, which was the only IBM graphics card it worked with (EGA arrived in 1984).

AutoCAD didn't require an FPU until version 11, released in October 1990. AutoCAD was an expensive product that was generally only purchased by professionals. In 1985 it cost $1000. PCs didn't generally come with an FPU so that was another $200+ if you wanted one. List price of an Amiga 1000 in 1985 was $1250.

Quote:

In terms of unit sales, C64 was keeping up with the IBM PC until around 1984.

A meaningless statistic. The C64 and PC were occupying different market segments.

Quote:

Let that sink in.

Oh yes, it sunk in alright. Lack of contextualisation? More like trolling.

@Lou

Quote:

Lou wrote: The more I look into things the more I truly believe Motorola deserves as much hate as Intel. All of Motorola's products are good initially, but then they get fat and lazy.

When do you propose this happened?

Quote:

I've given many examples of why the 680X0 series was a boondoggle to Amiga. Too little for too much that came too late...

You're wrong. 680x0 was wonderful for the Amiga. Imagine how much worse it could have been. The original idea was to use a 6502, but they soon realized a 16-bit CPU would be needed. Their choices were 68000, Z8000, or 8086. Motorola quoted $12 each for the 68000, which was much cheaper than the Z8000 and 8086. So they chose the 68000, which was fortunate because the Z8000 and 8086 both sucked.

Quote:

What I learned today is ... Well besides that I finally found documentation that the 6800-series (not 68000) was using in GM vehicles in the 80's and early 90's - which I knew because I've programmed them...

I've programmed them too. In 1980 I built a 6802 based computer of my own design. It was much better than the CDP1802 in the first computer I had, but still not that good. In particular it only had one index register, which was a pain. I was going to replace it with a 6809 which is a very nice microprocessor, but got distracted by a ZX81 and went the Z80 way.

Quote:

The 6800 series what drive the 6502 design...which eventually led to the 16bit WDC65816 and CSG 65CE02... (OK so CSG had a chip-naming issue since you'd never know the 65CE02 is 16bit via the name, it's basically a 6809 but faster and of course way cheaper).

Please try to get your facts straight - the 65CE02 is an 8-bit CPU, fully code compatible with the 6502. An great improvement on the 6502 for sure - but still only 8-bit.

Quote:

Motorla has it's own naming convention issues in the 6800 -> 68000 line. For instance, a 68HC16 is part of the 6800-line...ugh.

The 68HC16 has a fully 16-bit architecture with 2 16-bit accumulators and 3 16-bit index registers. It also works with 32-bit numbers and has a 1MB addressing range. However it's obviously based on the 6800/09, so the naming is entirely appropriate.

Quote:

... anyway - the MC6845 is a display controller. It was/is the basis for CGA. Once again Motorola stagnated. Since Motorola never created a successor...

Motorola introduced the MC6845 in 1977. In 1978 they released the MC6847, which is a complete video display generator on a chip with built-in character ROM, color graphics and up to 256x192 bitmap resolution. I used one in my 6802 computer. In many ways it was quite crude, but a great chip to get lots of features for very little effort.

In 1984 Motorola announced their two chip RMS (Raster Memory System). It had all the features of the 6847 plus bitmap resolutions up to 640x250/500, RGB outputs with up to 32 colors from a 4096 color palette, smooth pixel level scrolling, 8 reusable multicolor sprites with collision detection, up to 32 thousand programmable characters / tiles, various text modes including teletext, was genlockable and addressed up to 1MB RAM shared with the CPU. Compare that to the Amiga (which was also demonstrated in 1984). In many ways RMS was better.

I always thought RMS was vaporware, until today when I found out that it was used in a British computer called the Microbox 3, which featured an 8 MHz 68000, 512k RAM expandable with 8MB, dual 800k floppy drives, SCSI, parallel, serial and mouse ports, and an optional FPU or Transputer. It could run OS9/68k, CP/M68k, TRIPOS or SMS-2. Unfortunately Motorola cancelled the RMS so only a few of these machines were produced.

Quote:

The 6845, 6800-cpu series, 680000-cpu series and Motorola PPC line are all examples of a company that was fat and lazy. Their products cost too much and got stagnant, and improvements came too late..again over-priced.

Ah, so Motorola was fat and lazy starting with the 6845 in 1977 - which you say they didn't improve on and was too expensive? I don't remember how much the 6847 cost me but it was very cheap. The 6845 was pretty cheap too IIRC, but needed a lot of extra chips to make a complete display system. RMS was a huge advance over the 6845 (which was just an address and sync generator) - too advanced apparently because almost nobody was interested in it. Motorola innovated too much!

Motorola certainly weren't 'fat and lazy' in 1978 or throughout the 80's. They worked hard out creating the 6809, 68000, 68020 and 68030, all of which were excellent MPUs. Motorola doesn't deserve any hate for its efforts in providing an alternative to Intel.

So why do you hate them? Is it because they couldn't keep up with Intel in the 90's so the Amiga slipped behind in CPU performance compared to the PC? That's no reason to hate Motorola - It's just PC envy. One would think that after 30 years Amiga fans would have gotten over it, but here we are...

@bhabbott

Quote:

Lotus 123 didn't support the 8087 until version 2.0, released in September 1985.

1. I already know that.

2. Did you factor in Lotus 123 2.0's development time?

Quote:

Microbotics released their Starboard 2 RAM expansion with 68881 option for the A1000 in 1986. However there wasn't much interest in FPUs on the Amiga until 1987 when Eric Graham released Sculpt 3D. By the time we wanted an FPU Motorola had delivered.

1. Unlike the PC, the main problem with Amiga's 3rd party accelerator add-ons is the lack of statistical visibility. My point is about install base vs risk.

It's pretty easy to add an 8087 with an IBM PC 5150 since there's a socket for it. The same for IBM PS/2 Model 55SX.

2. Software development consumes time, HR, and financial.

Quote:

The main reason AutoCAD became ubiquitous on the PC was that it was the first CAD program for the PC. It was pretty sucky on a PC in 640x200 CGA, which was the only IBM graphics card it worked with (EGA arrived in 1984).

AutoCAD 1.4 (1984) supports IBM CGA, Vectrix VX384, Hercules Graphics, and TECMAR Color Graphics video cards.

Quote:

AutoCAD didn't require an FPU until version 11, released in October 1990.

AutoCAD can use the math coprocessor. Time is money.

Quote:

Aautocad 9/10 ran on 286/386/486sx AutoCAD was an expensive product that was generally only purchased by professionals. In 1985 it cost $1000. PCs didn't generally come with an FPU so that was another $200+ if you wanted one. List price of an Amiga 1000 in 1985 was $1250.

Not a problem for me i.e., it's about who you know. I experienced AutoCAD R12 and R13.

Older license copies were sent my way. There's a reason for the fake Mac on my Amiga besides Deluxe Music (Mac and Amiga versions).

Last edited by Hammer on 30-Mar-2025 at 11:43 AM.
Last edited by Hammer on 30-Mar-2025 at 11:41 AM.
Last edited by Hammer on 30-Mar-2025 at 11:37 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

@bhabbott

Quote:

Please try to get your facts straight - the 65CE02 is an 8-bit CPU, fully code compatible with the 6502. An great improvement on the 6502 for sure - but still only 8-bit.

65CE02 has double-rate processing i.e. like DDR for the CPU's processing. 65CE02 CPU @ 3.54 Mhz is effectively 7.08 Mhz in single data rate e.g. 68000.

The CSG engineer for 65CE02 CPU was hired by AMD in 1991 and later joined the K7 Athlon project, which has a DDR EV6 bus and DDR-capable Northbridge.

CSG's 65xx CPU has unique characteristics that were assimilated into the green-black team i.e. "We will add your biological and technological distinctiveness to our own".

Quote:

I always thought RMS was vaporware, until today when I found out that it was used in a British computer called the Microbox 3, which featured an 8 MHz 68000, 512k RAM expandable with 8MB, dual 800k floppy drives, SCSI, parallel, serial and mouse ports, and an optional FPU or Transputer. It could run OS9/68k, CP/M68k, TRIPOS or SMS-2. Unfortunately Motorola cancelled the RMS so only a few of these machines were produced.

https://colorcomputerarchive.com/repo/Documents/Datasheets/Raster%20Memory%20System%20Brochure%20(Motorola).pdf

RMS is missing A1000 PAL's 64 color EHB mode, let alone lossy color compression HAM6 mode.

RMS 320x210 display with virtual screen mode (15 x (320x210)) has 16 colors. There are gotchas.

Last edited by Hammer on 31-Mar-2025 at 02:21 AM.
Last edited by Hammer on 30-Mar-2025 at 12:10 PM.
Last edited by Hammer on 30-Mar-2025 at 12:08 PM.
Last edited by Hammer on 30-Mar-2025 at 12:03 PM.
Last edited by Hammer on 30-Mar-2025 at 11:55 AM.

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

@cdimauro

Quote:

"Release 2 brought add-in support, better memory management and expanded memory support, supported x87 math coprocessors, and introduced support for the Lotus International Character Set (LICS). Introduced in September 1985."

Did you assume I didn't know about Lotus 123 2.0's September 1985 release? Hint: Specific Lotus 123 2.0 version was cited for a reason.

Quote:

Which takes time on x86 due to the poor ISA. Especially for programming the x87.

Irrelevant. MS Excel 1.0 GUI for Mac 512K was also released in 1985.

MS has prior experience with Apple Lisa 68K (released in 1983) e.g. Xenix 3.0 for Lisa (released in 1984), Multiplan for Xenix Lisa, and Multiplan for Mac (released in 1984).

Xenix Lisa 68K has MS Multiplan 2.x and MS Multiplan 3.x, MS Word 3.0 and MS Word 5.x, and FoxBase Plus 1.00. These business software programs have a text UI.

Mac gained significant business customers, and it was less cost-sensitive when compared to mainstream A500's demographics. Returning to Apple, Steve Jobs has secured the MS Office releases for the Mac.

MS's experience with Mac 68K with GUI later guided MS's partnership with Intel (386), Compaq 386AT standard, and Windows 2.x 386.

Quote:

You forgot my favourite Borland's Quattro: https://en.wikipedia.org/wiki/Quattro_Pro

https://en.wikipedia.org/wiki/Quattro_Pro
the product was launched in 1988
Quattro Pro began as a DOS program (like Lotus 1-2-3)
QPW was finally released in September 1992.

Quattro Pro DOS's 1988 release is a little late to displace Lotus 123 DOS, let alone MS Excel's "next gen" GUI's beach head.

Quattro Pro for Windows' September 1992 release is late.

Last edited by Hammer on 30-Mar-2025 at 12:50 PM.
Last edited by Hammer on 30-Mar-2025 at 12:47 PM.
Last edited by Hammer on 30-Mar-2025 at 12:42 PM.
Last edited by Hammer on 30-Mar-2025 at 12:38 PM.
Last edited by Hammer on 30-Mar-2025 at 12:36 PM.
Last edited by Hammer on 30-Mar-2025 at 12:31 PM.
Last edited by Hammer on 30-Mar-2025 at 12:29 PM.
Last edited by Hammer on 30-Mar-2025 at 12:27 PM.

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

@matthey
I'm not so worried about the AC68080 performance, it's certainly good enough for Amiga usage, and often beats a 68060 at same clock speed, though there seems to be cases where a 68060 is still faster. But with this new max 3 instr/clock cycle optimization, it's probably going to beat a 68060 in most cases. The extensions which Gunnar have made, like AMMX and new registers might be questionable, but these need not be used. AC68080 offers probably better compatibility with old software than a 68060, as it implements e.g. all 68020/68030 CPU and FPU instructions that Motorola left out from the 68060.

I'm more worried about the SAGA chipset, since it's not able to emulate OCS and AGA chipset perfectly, i'm not sure if they will ever get it close to 100% compatibility, probably WinUAE has better compatibility at the moment.

But I would also like to see new 68060's being manufactured, whatever problems there are in that, a 100 MHz 68060 is not so bad in performance. Maybe with some fundraising it would be possible, a few million bucks collected from some embedded system companies, Amiga enthusiasts, and Elon Musk?

coder76 Quote:

I'm not so worried about the AC68080 performance, it's certainly good enough for Amiga usage, and often beats a 68060 at same clock speed, though there seems to be cases where a 68060 is still faster. But with this new max 3 instr/clock cycle optimization, it's probably going to beat a 68060 in most cases. The extensions which Gunnar have made, like AMMX and new registers might be questionable, but these need not be used. AC68080 offers probably better compatibility with old software than a 68060, as it implements e.g. all 68020/68030 CPU and FPU instructions that Motorola left out from the 68060.

The AC68080 has good performance that often surpasses the 68060 at the same clock speed but it is due to newer technology, especially much larger caches and much higher memory performance. If the 68060 had the same sized caches and same memory bandwidth, I believe it would still have the advantage. Routing inefficiencies are so much of a disadvantage in FPGA that a 68060 using a 500nm process remains competitive with a 28nm process in FPGA. The 68060 can execute up to 3 instructions/cycle and up to the equivalent of 5 RISC instructions/cycle. The claim for the AC68080 is already 6 instructions/cycle.

http://apollo-core.com/index.htm?page=features Quote:

Executes up to six instructions per clock cycle

The AC68080 has more advanced instruction folding/fusing which increases the instructions/cycle. The 68060 only folds branch instructions which the ColdFire improved upon.

MOTOROLA THAWS COLDFIRE V4
https://www.cecs.uci.edu/~papers/mpr/MPR/2000/20000515/142001.PDF Quote:

The instruction-folding technique enables limited parallel execution without the extra logic of dual-issue superscalar pipelines. The second section of the V4 pipeline automatically folds certain pairs of instructions into a single cycle operation. For example, it combines MOV.l ,Rx and ADD.l Ry,Rx to create ADD.l ,Ry,Rx.Motorola says these kinds of instruction pairs occur frequently in embedded programs. Programmers writing in assembly language could make sure it happens by deliberately pairing those kinds of instructions inside critical loops.

ColdFire received many improvements that would increase 68060 performance including additional instructions like MVS, MVZ and BYTEREV, instructions folding, a hardware return stack and larger caches. The ColdFire V4 is like a scalar version of the 68060 (like cancelled 68060Lite) and the ColdFire V5 is superscalar like the 68060. They are very similar designs and may be considered the same microarchitecture even though the ISA is different, because Motorola did not want 68k compatibility for the ColdFire in order to kill the 68k.

Scalar: 68060Lite, ColdFire V4, Cyrix 5x86
Superscalar: 68060, ColdFire V5, Cyrix 6x86

The ColdFire lack of 68k compatibility contributed to the death of ColdFire and the loss of the embedded market by Motorola even though ColdFire was eventually well received in the embedded market. There was push back and complaints from 68k customers that resulted in the return of some 68k compatibility that was useful after all and that Motorola had castrated too far. Some customers were tired of the Motorola castrations and incompatibilities often with minimal benefits. The removal of the PPC standard FPU in the A1222 SoC was a mistake that was quickly undone but the damage was already done. ARM was adding embedded features while Motorola was castrating similar features and we know how that turned out.

coder76 Quote:

I'm more worried about the SAGA chipset, since it's not able to emulate OCS and AGA chipset perfectly, i'm not sure if they will ever get it close to 100% compatibility, probably WinUAE has better compatibility at the moment.

SAGA bugs are likely due to Gunnar focusing on the AC68080 and Gunnar's efforts to keep SAGA closed source and available to few people. Thomas Hirsch wanted to open source SAGA which Gunnar announced, perhaps as part of the deal to obtain SAGA (I suggested it as part of the Apollo team to improve value of accelerators). The open sourcing never occurred which is telling.

coder76 Quote:

But I would also like to see new 68060's being manufactured, whatever problems there are in that, a 100 MHz 68060 is not so bad in performance. Maybe with some fundraising it would be possible, a few million bucks collected from some embedded system companies, Amiga enthusiasts, and Elon Musk?

New 68060 ASICs would use newer chip fab processes so the 68060@100MHz limitation would be gone. The 68060 cores could likely reach 1-2GHz using modern embedded processes and auto layout tools like ColdFire chips.

MOTOROLA THAWS COLDFIRE V4
https://www.cecs.uci.edu/~papers/mpr/MPR/2000/20000515/142001.PDF Quote:

The larger caches are the biggest reason that the die didn’t shrink dramatically. Another reason is starkly visible in Figure 2, the die photo. ColdFire is the only family of processors from Motorola that’s entirely synthesized from high-level models with automated design tools. There’s no custom circuit layout at all. Compiled chips are bigger, slower, and less power-efficient than full-custom designs, but they are much quicker and cheaper to create. Where a hand-packed design typically has neat blocks of function units inside a Piet Mondrian grid of buses, the 5407 has an amorphous mass of compiler-generated circuits on a Jackson Pollock canvas of silicon. The only semblance of order comes from the caches and on-chip memories around the periphery of the die. They’re compiled too, but SRAM arrays obediently fall into dense rows and columns, even without a guiding hand. Fortunately, the mess of logic circuitry isn’t as inefficient as it appears. Based on Motorola’s upper-range power consumption estimate of 700mW, the 5407 delivers a whopping 367 mips per watt, nearly four times better than the 5307’s 94.6 mips per watt. Beauty is in the eye of the beholder, but performance can be measured.

Other modernizations would be added to a 68060 ASIC to increase competitiveness like increased caches and a memory controller supporting modern memory. SoCs are the most competitive for embedded use and maximum cost reduction of hardware. The result would not be pin compatible so no drop in direct solution but a low price for the SoC likely would result in new very affordable 68k accelerators and stand alone SBCs. Some new 68k accelerators include ARM SoCs because they are so cheap and increase value but a 68k SoC would offer much more value even if the price was several times that of the ARM SoC.

Financing remains to be seen as nobody has seriously tried to produce modern 68k ASICs. I consider a few million USD to be affordable and reachable. Trevor has wasted millions USD on the PPC AmigaNOne for a few thousand customers while 68k Amiga hardware has sold in the high tens of thousands if not low hundreds of thousands of units with crap emulation and low clocked 68k FPGA cores inside. A 68k SoC ASIC should boost performance by at least 10 times while cutting the hardware cost in half or more. Throw a 68000 core in the SoC for compatibility and I/O with adjustable clock speeds for the full static design 68k cores and good on the inside hardware could fully revive a sustainable 68k Amiga market. The A-EonKit/Hyperion crime syndicate already see RGL hardware as a threat with crap hardware on the inside and continue to sabotage the 68k Amiga. Corruption and uncertainty need to be dealt with before investment into more competitive hardware can occur.

@matthey

Quote:

The AC68080 has good performance that often surpasses the 68060 at the same clock speed but it is due to newer technology, especially much larger caches and much higher memory performance. If the 68060 had the same sized caches and same memory bandwidth, I believe it would still have the advantage. Routing inefficiencies are so much of a disadvantage in FPGA that a 68060 using a 500nm process remains competitive with a 28nm process in FPGA. The 68060 can execute up to 3 instructions/cycle and up to the equivalent of 5 RISC instructions/cycle. The claim for the AC68080 is already 6 instructions/cycle.

Running Lightwave 68K can show AC68080's single FPU design when compared to 68060's.

The big advantage with the AC68080 family is active R&D (on Intel/Altera FPGA platform) vs zero R&D for 68060.

Quote:

New 68060 ASICs would use newer chip fab processes so the 68060@100MHz limitation would be gone. The 68060 cores could likely reach 1-2GHz using modern embedded processes and auto layout tools like ColdFire chips.

Funding for wafer starts and elevated ROI risk is a problem.

Quote:

Financing remains to be seen as nobody has seriously tried to produce modern 68k ASICs. I consider a few million USD to be affordable and reachable. Trevor has wasted millions USD on the PPC AmigaNOne for a few thousand customers while 68k Amiga hardware has sold in the high tens of thousands if not low hundreds of thousands of units with crap emulation and low clocked 68k FPGA cores inside

Trevor has the freedom to spend his money.

Raspberry Pi waited until it exceeds UD$200 million revenue before embarking into wafer starts cut-n-paste ARM SoC adventure i.e. yet another MediaTek cut-n-paste ARM-based SoC.

AC68080 gaining ColdFire instructions is an attempt to attract embedded customers.

68K wasn't independently cloned during its golden era and many embedded customers have moved beyond 68K and Coldfire.

Solutions like Octavo OSD335x System-in-Package has 68000 bus compatibility for embedded 68000 legacy which offers a pathway towards ARM-based CPU road map.

68060 @ 1Ghz level experience is already delivered by low-cost / low-risk Emu68 with RPi CM4 / RPi 4B.

Cortex A76-based SoCs can emulate the Amiga faster than Emu68 with RPi CM4 / RPi 4B, + A1200 combo which is no better than WinUAE / Amiga Forever on crazy fast X86-64 PCs.
Cortex A76 can brute force Amiberry faster than Emu68 with ARM Cortex 72. The main difference is "the name" Commodore-Amiga Inc's custom hardware.


@matthey

Quote:

Scalar: 68060Lite, ColdFire V4, Cyrix 5x86 Superscalar: 68060, ColdFire V5, Cyrix 6x86

SiFive U74 (RISC‑V U7)'s single FPU pipeline is not "superscalar" situation with heavy FPU workloads.

I have argued against Gunar's claim on 4 instruction per cycle decode rate with show the high level pipeline layout when AC68080 doesn't have multi-pipeline FPUs. Intel Core 2's 4 instruction per cycle decode rate is backed by multiple FPU pipelines. https://en.m.wikipedia.org/wiki/File:Intel_Core2_arch.svg

I'm skeptical any multiple X instruction per cycle decode rate claims since it's useless without multiple duplicate pipelines to back such as claim.

Last edited by Hammer on 31-Mar-2025 at 02:10 AM.
Last edited by Hammer on 31-Mar-2025 at 01:54 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:

The AC68080 has good performance that often surpasses the 68060 at the same clock speed but it is due to newer technology, especially much larger caches and much higher memory performance. If the 68060 had the same sized caches and same memory bandwidth, I believe it would still have the advantage. Routing inefficiencies are so much of a disadvantage in FPGA that a 68060 using a 500nm process remains competitive with a 28nm process in FPGA. The 68060 can execute up to 3 instructions/cycle and up to the equivalent of 5 RISC instructions/cycle. The claim for the AC68080 is already 6 instructions/cycle. http://apollo-core.com/index.htm?page=features Executes up to six instructions per clock cycle

Yes, i wrote it wrong, meant 6 instr/clock cycle, previously AC68080 had 4.

I don't know much about Coldfire, but i know it was another failed CPU made by Motorola. Can't understand why they dropped the m68k line in favor of that. Well ok, it was a simpler CPU based on m68k and cheaper to produce. Nokia comes to mind here, they also thought that simple and cheap mobile phones were all that customers wanted, not some expensive touchscreens and Android.

Quote:

New 68060 ASICs would use newer chip fab processes so the 68060@100MHz limitation would be gone. The 68060 cores could likely reach 1-2GHz using modern embedded processes and auto layout tools like ColdFire chips.

Ok, would be nice with 1-2 GHz CPUs too, but do these work without cooling? I've got a 68030/50 MHz in my A1200, and it gets quite hot as a simple plugin in the expansion slot. Also tablets/phones have e.g. these 2,2 GHz ARM CPUs without getting hot, or needing any cooling. I mean quite a difference to Intel desktop CPUs, lots of crap and complexity inside.

Quote:

Other modernizations would be added to a 68060 ASIC to increase competitiveness like increased caches and a memory controller supporting modern memory. SoCs are the most competitive for embedded use and maximum cost reduction of hardware. The result would not be pin compatible so no drop in direct solution but a low price for the SoC likely would result in new very affordable 68k accelerators and stand alone SBCs. Some new 68k accelerators include ARM SoCs because they are so cheap and increase value but a 68k SoC would offer much more value even if the price was several times that of the ARM SoC.

And then some more improvements, like they planned in the 68060-B model.

Quote:

Financing remains to be seen as nobody has seriously tried to produce modern 68k ASICs. I consider a few million USD to be affordable and reachable. Trevor has wasted millions USD on the PPC AmigaNOne for a few thousand customers while 68k Amiga hardware has sold in the high tens of thousands if not low hundreds of thousands of units with crap emulation and low clocked 68k FPGA cores inside. A 68k SoC ASIC should boost performance by at least 10 times while cutting the hardware cost in half or more. Throw a 68000 core in the SoC for compatibility and I/O with adjustable clock speeds for the full static design 68k cores and good on the inside hardware could fully revive a sustainable 68k Amiga market. The A-EonKit/Hyperion crime syndicate already see RGL hardware as a threat with crap hardware on the inside and continue to sabotage the 68k Amiga. Corruption and uncertainty need to be dealt with before investment into more competitive hardware can occur.

PPC Amigas were bad from the beginning, but there were not many other alternatives in the 90's when Motorola dropped the m68k line. Unfortunately, some seem to want to sabotage the m68k Amiga, when they could instead try to profit from the growing m68k popularity.