@Hammer

Quote:

Hammer wrote: @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?

1. But you've reported it. Guess why: cherry-picking only what's interesting for you -> not intellectual honest.

2. Did you factor that development time is much faster on 68k systems?
Quote:

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.

1. Unlike PCs, on Amiga (and other socket-based 68k systems as well) it was easy to add accelerator cards and they were famous -> install base was irrelevant.

2. Software development consumes much less time, HR, financial on equivalent 68k systems.
Quote:

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

AutoCAD can use the math coprocessor. Time is money.[/quote]
But it took SIX YEARS to support the coprocessors, whereas it's much much easier on 68k systems. Time is money, but 68k systems required much less.

You didn't factor it because you never programmed x86 AND 68k systems in assembly, at time. So, you aren't able to correctly evaluate and contextualize.
Quote:

Hammer wrote: @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?

No, obviously: I'm not you.
Quote:

Hint: Specific Lotus 123 2.0 version was cited for a reason.

See above: you missed to report everything else because it wasn't supporting your rhetoric. As usual.

You're not interested on understanding the full context and rebuilt how was the real situation, but the only thing that you want is to support your "filtered-universe".
Quote:

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

Very relevant, as "someone else" already reported:

2. Did you factor in Lotus 123 2.0's development time?
[...]
2. Software development consumes time, HR, and financial.
[...]
AutoCAD can use the math coprocessor. Time is money.

Coherency... NOT found!
Quote:

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.

Irrelevant: THIS PART of the discussion was about the development time required for supporting math coprocessors, and you already got the answer.
Quote:

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.

Yes, not enough to displace Lotus 123, but enough for Lotus to sue Borland:
https://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_Int%27l,_Inc.

Evidently it was threat...

@Hammer

Quote:

Hammer wrote: @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".

Irrelevant + Red Herring: the (sub)topic here was that the 65CE02 is an 8-bit and NOT a 16-bit CPU.
Quote:

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.

Irrelevant. The (sub)topic here was that RMS arrived one year before the Amiga. And it was a great system AT THAT TIME.

@Hammer

Quote:

Hammer wrote: @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 idea was to have a revised 68060, with some updates which included a pipelined FPU.

You missed the context. Again...
Quote:

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

https://en.wikipedia.org/wiki/Lapalissade

A lapalissade is an obvious truth—i.e. a truism or tautology—which produces a comical effect.

@coder76

Quote:

coder76 wrote: @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.

Even 4 was too much for an in-order design.

That's the reason why when you want to approach the 3 instructions per cycle for an in-order system, it's better to evaluate a 2-way OoO one which allows much better performance.

On top of this, 3-way in-order makes more sense on LD/ST (former RISC) designs, where you can have more dependent instructions due to the need to load or build constants to be used later by other instructions.
Quote:

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.

Because they were dumb.
Quote:

PPC Amigas were bad from the beginning, but there were not many other alternatives in the 90's when Motorola dropped the m68k line.

There were many in the 90s. Much less on the new millennium.

In fact, Amiga port to PowerPCs made no sense when effectively it was started.
Even Apple tried to exist the PowerPC market at the very beginning of 2000s, before such Amiga ported started, because PowerPCs were not competitive anymore against x86 systems.
Quote:

Unfortunately, some seem to want to sabotage the m68k Amiga, when they could instead try to profit from the growing m68k popularity.

Indeed. But the primary problem is that a lot from the post-Amiga community are supporting them by buying their product, hence continue to finance THE Empire of the Evil.

@cdimauro

Quote:

1. But you've reported it. Guess why: cherry-picking only what's interesting for you -> not intellectual honest. 2. Did you factor that development time is much faster on 68k systems?

Irrrelevant.

Did you factor in 68881's release date? Hint: 1984.

Did you factor in 68881's official support with the 1st mainstream 68K platform? Hint: 1987 for Macintosh II.

Did you factor in 68881's official support with the 2nd mainstream 68K platform? Hint: 1988 for Amiga 2000's A2620.

Timeline facts:
8087 was released in 1980.

IBM PC 5150 was released on 12th of August 1981 with an 8087 socket.

Lotus was founded in 1982 by partners Mitch Kapor and Jonathan Sachs with backing from Ben Rosen.

80287 was released in 1982.

Apple Lisa was released on 19th of January 1983. Lisa OS platform suffered a sales flop.

Lotus 1-2-3 1.0 was released on 26th of January 1983.

Xenix 3.0 for Apple Lisa was released in 1984, including Xenix Software Development System, Xenix 68K apps from MS e.g. Multiplan 2.x and MS Word 3.0 and FoxBase Plus 1.0.

Motorola released 68881 in 1984.

MS Multiplan for Mac was released in 1984.

IBM PC/AT was released on 14th of August 1984.

Lotus 1-2-3 2.0 was released in September 1985 with x87 support.
MS Excel 1.0 was released on the 30th of September 1985.

Compaq 386 DeskPro (386AT) was released in September 1986. Includes 287 socket.

The 1st official mainstream 68k platform support for 68881 was with Macintosh II's March 1987 release. Macintosh II has Apple's custom MMU.

Mac GUI port MS Excel 2.0 for Windows 2.0 was released in November 1987. Windows 2.0 supports business 640x480p VGA color and MCGA monochrome.


80387 was released in 1987.
http://www.bitsavers.org/components/chipsAndTech/CS8230_Numeric_Coprocessor_19870712.pdf
Rev 1.2, 12th of July 1987, Chips and Technologies 8230 chipset documentation on 387 integration.


The 2nd official mainstream 68K platform support for 68881 was with Amiga 2000's A2620's March 1988 release (demonstrated in March 1988's CeBIT show). Commodore wasted R&D time on two custom MMUs for 68000 and 68020, respectively, since 68551 was late. Unlike the Mac, the Amiga OCS is missing a mass production stable business resolution. A2024's production scale is 5000 units with production delays.

IBM VGA and VGA clones (e.g. ET3000) were released in 1987 in millions production scale.

ECS Denise and at least ECS Agnus A were demonstrated with A2000 in Q4 1988.

Henri Rubin departs from ECS's original intention for a quick Amiga OCS upgrade, making it time-exclusive for the A3000's 1990 release.

You're not intellectually honest when the official system integration pace is slower with mainstream 68K platform vendors.

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

According to Dataquest November 1989, VGA crossed more than 50 percent market share in 1989 i.e. 56%.
http://bitsavers.trailing-edge.com/components/dataquest/0005190_PC_Graphics_Chip_Sets--Product_Analysis_1989.pdf

Low-End PC Graphics Market Share by Standard Type
Estimated Worldwide History and Forecast

Total low-end PC graphic chipset shipment history and forecast
1987 = 9.2. million, VGA 16.4% market share i.e. 1.5088 million VGA.
1988 = 11.1 million, VGA 34.2% i.e. 3.79 million VGA.
1989 = 13.7 million, VGA 54.6% i.e. 7.67 million VGA.
1990 = 14.3 million, VGA 66.4% i.e. 9.50 million VGA.
1991 = 15.8 million, VGA 76.6% i.e. 12.10 million VGA.
1992 = 16.4 million, VGA 84.2% i.e. 13.81 million VGA.
1993 = 18.3 million, VGA 92.4% i.e. 16.9 million VGA.

Commodore - The Final Years

Henri Rubin had been brought to Commodore in order to enter the
business market. His central plan had been to use the Bridgeboard
as a way to sneak Amiga computers into the business world by
claiming MS-DOS compatibility. “The stuff that came from
management was all really bizarre and most of it didn't really
happen,� says Bryce Nesbitt.

Rubin also banked on “Productivity Mode� in the new Amiga 3000
as a way to stay current with the VGA capabilities of PC clones.

Instead, by mid-November 1990, even Hedley Davis acknowledged
to his fellow engineers that the PC and Macintosh had moved far
beyond the capabilities of the Amiga line. In a memo to his fellow
employees, he wrote, “While the Amiga was first out on the
(inexpensive) market with certain interesting capabilities, this lead
has rapidly eroded as other vendors have brought the MS-DOS and
Mac machines up to and far beyond the capabilities available on
Amiga platforms.�



Henri Rubin has an ECS mistake e.g. A3000.

Bill Sydnes and Jeff Frank have ECS mistakes e.g. ECS A300/A600, ECS A2200/A2400, and ECS A3200/A3400.

Last edited by Hammer on 31-Mar-2025 at 12:43 PM.
Last edited by Hammer on 31-Mar-2025 at 12:30 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:

Irrelevant + Red Herring: the (sub)topic here was that the 65CE02 is an 8-bit and NOT a 16-bit CPU.

It's relevant since 65CE02 has double data rate (DDR) processing with its 8-bit ALU, while the 68000's ALU has 16-bit SDR processing.

Quote:

I Irrelevant. The (sub)topic here was that RMS arrived one year before the Amiga. And it was a great system AT THAT TIME.

Wrong. You didn't factor in system integration R&D time.

From
https://books.google.dk/books?id=k5bNBQAAQBAJ
https://retrocomputing.stackexchange.com/questions/10977/fate-of-mystery-motorola-rms-graphics-chipset-68486-68487


In the book "CoCo: The Colorful History of Tandy’s Underdog Computer" (ref), authors Boisy Pitre and Bill Loguidice describe how the RMS originally was developed in conjunction with or at least at the same time as the Tandy Color Computer 3, which was released in summer 1986. Presumably then, the CoCo3 was developed during 1985-86.


A1000's 1985 release includes system integration, not just chipset release.


The Microbox 3 manufactured and sold by UK-based company "Micro Concepts" from Cheltenham! I can only find it described in detail one place and that is in the Electronics & Wireless World issue of May 1986. On page 63, it is announced as the British rival to the Amiga and the description leaves little doubt:



"May 1986" announcement dickhead.

http://retro.co.za/6809/microbox/Microbox3.html
From David Rumball, system integrator for Match Box 3,

I was forced to quickly redesign the MB3 after the RMS cancellation and this became the "Phoenix" AKA MB4 AKA Image-10 (late 1986).

The RMS devices were replaced by and Intel 82786 graphics chip which gave vastly improved graphics performance (hardware windowing and acceleration), the processor was the 68010 and the peripherals were more or less the same although I added a Transputer link
interface (I was heavily into the Transputer at the time). The same OSs were ported again to the Image-10.

There was a variant of the Image-10 which was used by a company called Visual Data Systems for interactive video.


RMS cancellation, dickhead.

RMS didn't reach A1000's mass production product release state.

-------------------------------------------
Motorola released the 68040 in 1990.

The 1st 68040-based mainstream platform was released in October 1991 via Apple's Quadra 700.

Mainstream 68K camp has a slower system integration pace.

Last edited by Hammer on 31-Mar-2025 at 01:12 PM.
Last edited by Hammer on 31-Mar-2025 at 01:02 PM.
Last edited by Hammer on 31-Mar-2025 at 12:56 PM.
Last edited by Hammer on 31-Mar-2025 at 12:56 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

Hammer Quote:

Trevor has the freedom to spend his money.

Trevor is only free to waste his money on legal activities. He has wasted his money on illegal Amiga IP stealing while sabotaging the 68k Amiga for the lost Trevor Amiga decade. He wanted to have nothing to do with the 68k Amiga during his lost decade with the main goal to keep the 68k Amiga inferior to PPC AmigaNOne so users would be forced to upgrade. Cloanto was largely ignored catering to the growing retro 68k Amiga market except for Ben licensing stolen Amiga IP behind Michele's back. Now that the retro 68k Amiga has gained momentum, A-EonKit is challenging Amiga IP ownership with the A600GS, A1200NG, AmigaKit, AmigaStore.com and Amiga Technologies and Hyperion has moved in more with the 68k AmigaOS, more lawfare and demanding Amiga IP licenses. This is a full on assault by Trevor proxies. Michele tolerated the Hyperion A-EonKit syndicate when they were just doing AmigaOS 4 but it is has become clear that this is a criminal syndicate that will further and further encroach on the Amiga IP until they control it all or are eliminated.

Hammer Quote:

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.

Commodity SoC ASICs make it much cheaper to produce SBCs but then there is competition from other SBC producers using commodity SoCs. A unique market like the 68k has less competition allowing for higher margins. The retro/embedded Vortex86 SoCs likely have higher margins than the saturated ARM SoC market for the same reason even though the Vortex86 SoCs are far from competition to modern high performance x86-64 SoCs. It looks like just scalar Cyrix 5x86 CPU cores are used because x86 is so poor on power where the higher performance in-order superscalar 68060 was low enough power for the embedded market for over a decade. The 68060 eventually lost competitiveness to newer SoC designs with better integration, optimizations for newer silicon and more modern enhancements which is what the 68060 needs to become competitive again.

Hammer Quote:

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

I am still unsure about the AC68080 ColdFire support. I believe Gunnar added them to early AC68k cores, then removed them and maybe added them back but did not update the AC68080PRM or used different encodings?

AC68080PRM MOVS (similar to ColdFire MVS)
%1010 reg 10s EA

AC68080PRM MOVZ (similar to ColdFire MVZ)
%1010 reg 11s EA

ColdFire MVS
%0111 reg 10s EA

ColdFire MVZ
%0111 reg 11s EA

The AC68080PRM ColdFire instructions use a different name and encoding. The original ColdFire names are not human friendly and should be changed to be more 68k consistent but aliases should be specified for assemblers to allow the original ColdFire instruction names for compatibility. Changing these encoding is unnecessary as the encoding space is open on the 68k but Gunnar likely used it for something else after ignoring my recommendation to use it for the ColdFire instructions. Some people do things the hard way over and over again.

Hammer Quote:

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

It was easier to license the 68k until the Hitachi license dispute after which Motorola was much more protective of the 68k. The Hitachi dispute was a turning point for the 68k as not only were 2nd source suppliers for the 68020+ not available but Hitachi was likely going to produce the 68030 for Sega consoles which could have been copied by other Japanese console producers as was the case with MIPS, PPC and x86-64 later. Sega switched to Hitachi developed SuperH instead but SH-2 was not as mature and more of a MCU ISA that did not scale up as well as the 68k.

Hammer Quote:

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

A 68060@1GHz may be 10 times the performance of a 68060@100MHz but the addition of modern embedded caches would increase the performance closer to 20 times. The 68060+ was going to "increase performance 20-30% independent of clock frequency" which is likely mostly due to doubling the L1 cache when it would be quadrupled, at least a L2 cache added and modern memory used for a modern enhanced 68060. There are other relatively easy performance enhancements that could be added too.

Hammer Quote:

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.

The Cortex-A72 using a 28nm process remains practical although an in-order CPU core with close to the same performance would be more practical, cheaper and lower power. The Cortex-A76 using a 16nm process is much less practical, especially for embedded use where it uses too much power and produces too much heat to embed. The CPU cores do not leave enough power or area for a good microconsole GPU for gaming either.

Hammer Quote:

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

The SiFive 7-series looks like it copied the 68060 design more than any other. The 68060 also prioritized integer performance over floating point performance which is what most embedded hardware needs. Even for desktop hardware, FPU performance is less important as the A1222 does not need a standard PPC FPU even though the AC68080 has a fully pipelined FPU including for the FDIV/FSQRT unit. Speaking of FPU units, even the 68060 has separate FPU units.

Motorola Introduces Heir to 68000 Line
https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080502.pdf Quote:

The floating-point unit contains separate add, multiply, and divide/square-root units, although adds and multiplies cannot occur simultaneously. Internally, all floating-point operations are performed in 80-bit extended precision. Complex or infrequently used operations from the ’040 instruction set are implemented via software emulation. The floating-point unit can be disabled, in which case floating-point instructions trap to the F-Line handler, making a full ’060 operate like an ’LC060 or ’EC060.

The 68060 has separate FADD, FMUL and FDIV/FSQRT units but would require more logic to pipeline and track more FPU instructions in flight. This is typical whether the FPU is pipelined or not. Some newer FPUs have FMA units which have a combined FMUL+FADD unit. Only the very highest performance FPUs have multiple duplicate units for the same operations. The capability to start executing a FPU instruction in each unit every cycle with pipelined units is very powerful and much less wasteful than duplicating units.

coder76 Quote:

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.

ColdFire was moderately successful but at the low end of the embedded market where it did not get much attention. More people have heard of PPC but it was only moderately successful or perhaps moderately unsuccessful considering the huge R&D capital spent on it. ColdFire was just castrated 68k often reusing existing 68k designs which was very cheap to do in comparison. Unsuccessful and perhaps the last ISA Motorola developed was the short lived MCore.

https://en.wikipedia.org/wiki/M%C2%B7CORE

It is more comparable to a simplified and inferior SuperH. Several large businesses thought simplification and castration was the goal for embedded systems but now that they have lost influence, embedded CPU ISAs and cores have become big and fat compared to the 68k which is practical for embedded use, especially with its very good code density. Too bad politics made the pioneering and leading 32-bit embedded 68k architecture disappear.

coder76 Quote:

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.

The 68060 is a low power and cool chip in operation, especially the later revision ones. Passive cooling should be possible for modernized 68060@1-2GHz SoCs. This is one of the advantages of in-order cores. Higher end GPUs in a 68k SoC likely would require more than passive cooling though.

coder76 Quote:

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.

Yes, there are conflicting goals for the sabotaging Hyperion A-EonKit syndicate. Hyperion would save time with Warp3D sources available to create new drivers for emulation hardware like the PiStorm and proliferating the hardware which would increase sales for their game porting business. AmigaKit blocks because the PiStorm hardware may take business away from the A600GS and A1200NG and other competitors may use it like THEA500 Mini, THEA1200 Maxi and Pi users even though AmigaKit sells the PiStorm. A-Eon may still want to sabotage the 68k Amiga until they sell off remaining PPC hardware inventories and possibly beyond if they can find more PPC CPUs in a dumpster somewhere. Hyperion would benefit from the A1200 Maxi release as they could sell more copies of the 68k AmigaOS and ported games yet they block it to try to force RGL to pay to include their 68k AmigaOS for all units. Rather than fair competition, sharing or actually cooperating to make the Amiga great again, they are sabotaging the "growing m68k popularity" which I believe is backfiring. Hyperion was supported in their theft of Amiga IP like Robin Hood stealing from what was perceived as Amiga Inc sabotaging Amiga advancement but now eyes are being opened to the thieves and road blocks who did not steal it for Amiga advancement or the Amiga community but for themselves. I hope enough customers vote with their pocketbook and take their business elsewhere that they are forced to change their ways. If that does not work, the lawsuits will have to be a cure for arrogance.

cdimauro Quote:

Even 4 was too much for an in-order design. That's the reason why when you want to approach the 3 instructions per cycle for an in-order system, it's better to evaluate a 2-way OoO one which allows much better performance. On top of this, 3-way in-order makes more sense on LD/ST (former RISC) designs, where you can have more dependent instructions due to the need to load or build constants to be used later by other instructions.

The "executes up to six instructions per clock cycle" is more of a marketing thing. The same link has a chart that uses "Peak Inst/Cycle" instead.

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

The 68060 is listed at 2 peak instructions/cycle when it should be 3 with two integer instructions and a predicted branch possible even though it is really not executing the predicted branch but folding it away. ColdFire and the AC68080 use other code folding techniques as well to increase the peak instructions/cycle even though this may not be common. The AC68080 is claimed to be able to fold two instructions into a single 3 op instruction in each integer pipe which is 4 peak instructions/cycle. Maybe he added the 3rd pipe which I suggested based on research showing the 68k usually has 2.5-3.0 average instruction length allowing a reasonable sized instruction fetch to feed 3 integer pipelines. For comparison, I found Cyrix claims for x86 average instruction length.

https://datasheets.chipdb.org/Cyrix/5x86/5X-DPAPR.PDF Quote:

Two facts were fundamental in identifying features for the 5x86: (a) the x86 is a 32-bit architecture. (b) the average instruction length is 2.7 bytes for existing 8/16-bit code and 4.4 bytes for 32-bit code.

16B/2=8B 16B/3=5.33B 16B/4=4B 16B/5=3.2B 16B/6=2.66B

The scalar Cyrix 5x86 has a 16B/cycle instruction fetch with a larger size needed due to the average 32-bit x86 instruction size and because of less efficient byte alignment of instructions. The superscalar 68060 has a 4B/cycle instruction fetch with a decoupled instruction fetch pipeline, instruction buffer and execution pipelines and a 8B/cycle instruction fetch could feed 3 integer pipelines better than 4B/cycle feeds 2 integer pipelines. The superscalar AC68080 has a 16B/cycle instruction fetch with no decoupling which requires ~2.66 average instruction length and perfect alignment of instructions to the instruction fetch to be able to execute 6 instructions/cycle. I do not expect this is common as the use of a 16-bit prefix likely increased the average instruction length and decreased code density. It would be rare to be able to fold 3 pairs of instructions in 3 execution pipes from a single 16B fetch but 3 pipes could still be worthwhile without instruction folding and there is adequate instruction fetch for execution of 5 instructions/cycle most of the time. A 16B instruction fetch for 32-bit x86 code could only feed 3 instructions/cycle execution most of the time which is a big difference. Even 32-bit fixed length RISC encodings obtain 4 instructions from a 16B fetch and the instructions are perfectly aligned every time. Maybe this is why ARM64/AArch64 returned to a 32-bit fixed length encoding without the 68k demonstrating CISC instruction fetch and code density advantages.

average instructions in a 16B instruction fetch
8/16-bit_x86 5.9
32-bit_x86 3.6
32-bit_68k 5.3-6.4
AArch64 4

The 68k had a large advantage by starting with a 32-bit ISA, 32-bit pointers and a large flat address space. The handicap of x86(-64) is severe when moving to 32-bit and 64-bit yet the 68k was the architecture killed for political reasons.

cdimauro Quote:

There were many in the 90s. Much less on the new millennium. In fact, Amiga port to PowerPCs made no sense when effectively it was started. Even Apple tried to exit the PowerPC market at the very beginning of 2000s, before such Amiga ported started, because PowerPCs were not competitive anymore against x86 systems.

The rumors that Apple was unhappy with PPC development, especially low clock speeds, and contemplated switching to Intel started around 2000 while AmigaOS 4 development started in 2001.

https://web.archive.org/web/20201031220502/https://www.macrumors.com/2005/06/05/intel-based-mac-rumor-roundup/ Quote:

An Intel based Macintosh? Rumors of Apple switching to an Intel based processor pre-date the existence of this site. The earliest reference in our archives comes from March 15, 2000 (this site was founded in Feb 2000). For some perspective... a rumor roundup for WWDC 2000 (5 years ago) included rumors of "Intel-based Macs". Analysts also "urged Apple to move to microchips from Intel Corp" back in July 2002. Steve Jobs replied that they had to finish the OS 9 -> OS X transition first but "Then we'll have options, and we like to have options. But right now, between Motorola and IBM, the roadmap looks pretty decent." After the transition to Mac OS X, Apple was reported to have kept an OS X on x86 side-project known as Marklar. The original article described Marklar as a "fall back plan" should the PowerPC fail to deliver. The PowerPC was undergoing slow development during that time until IBM took over development and Apple announced PowerPC G5 based PowerMacs in the summer on 2003. In fact, IBM bragged in an internal memo that while Apple considered moving to Intel at that time they went with IBM's PowerPC G5 (970) because Apple felt the transition to Intel would be too difficult: IBM internal memo Quote: While Intel is aggressive in achieving its performance and speed goals, Apple believed that using Intel would deeply affect its current customer base. Using an Intel architecture might solve Apple's short-term megahertz dilemma, but customers would have to suffer through a slow transition from PowerPC over the long term. Every existing Mac program would potentially have to be recompiled to work on an Intel platform. These massive software changes were something that Apple wanted to avoid, and IBM had the solution. Despite this, Apple/Intel rumors continued to surface (Sept 2003).

The shallow pipeline PPC designs were not good for high clock speeds. Ironically, Apple switched away from the 68k just as the 8-stage 68060 with what was considered a deep pipeline then came out and the announcement of higher clocked 68060s that were in testing and a 68060+ were cancelled. It is amazing how many tech CEOs do not understand tech and make political decisions instead.

@matthey

Quote:

Trevor is only free to waste his money on legal activities. He has wasted his money on illegal Amiga IP stealing while sabotaging the 68k Amiga for the lost Trevor Amiga decade. He wanted to have nothing to do with the 68k Amiga during his lost decade with the main goal to keep the 68k Amiga inferior to PPC AmigaNOne so users would be forced to upgrade. Cloanto was largely ignored catering to the growing retro 68k Amiga market except for Ben licensing stolen Amiga IP behind Michele's back. Now that the retro 68k Amiga has gained momentum, A-EonKit is challenging Amiga IP ownership with the A600GS, A1200NG, AmigaKit, AmigaStore.com and Amiga Technologies and Hyperion has moved in more with the 68k AmigaOS, more lawfare and demanding Amiga IP licenses. This is a full on assault by Trevor proxies. Michele tolerated the Hyperion A-EonKit syndicate when they were just doing AmigaOS 4 but it is has become clear that this is a criminal syndicate that will further and further encroach on the Amiga IP until they control it all or are eliminated.

I'm aware of this particular drama, but I have supported both Cloanto (via multiple AF purchases) and Hyperion (via AmigaOS 4.1 FE and AmigaOS 3.1.4/3.2.x purchases).

Quote:

Commodity SoC ASICs make it much cheaper to produce SBCs but then there is competition from other SBC producers using commodity SoCs. A unique market like the 68k has less competition allowing for higher margins. The retro/embedded Vortex86 SoCs likely have higher margins than the saturated ARM SoC market for the same reason even though the Vortex86 SoCs are far from competition to modern high performance x86-64 SoCs.

Certain Vortex86 SoC models are not retro since they target the modern embedded market that needs mirror redundancy + ECC memory endurance.

Quote:

It looks like just scalar Cyrix 5x86 CPU cores are used because x86 is so poor on power

AMD and Intel modern out-of-order X86-64 v3/v4 SoCs have reached mainstream handheld gaming devices. Intel's in-order Atom SoC has already reached the mobile phone form factor.

Refer to mobile X86 models i.e. they are speed-binned for different market segments.

FYI, 1993 original P5 Pentium's 800 microns process node is similar to the 68040 @ 40 Mhz's. LOL The original P5 Pentium officially has 60 MHz at 5V and 66 MHz at 5.1V SKUs.

1994's P54C used 600 and 500 microns process nodes at 3.3V, which is similar 68060 rev 1's 600 microns process nodes at 3.3V. P54C's clock speed ranges from 75 (50 Mhz FSB) to 100 Mhz (66 MHz FSB). It's easy FSB jumper switch from Pentium 75 into 90 MHz (60 Mhz FSB) overclock.

The purpose why I purchased 1994 68060 rev 1 with TF1260 is to investigate the clock speed reach "what if". 68060 rev 1 has subpar overclock characteristics.

On clock speed reach and similar process node, 68060 rev 1 has already lost to P54C Pentium. Craftsmanship can influence the attainable clock speed.

I don't give damn about power efficiency when my A1200 is plugged into the wall power e.g. Warp1260 has a modern laptop blower cooler solution.


Quote:

where the higher performance in-order superscalar 68060 was low enough power for the embedded market for over a decade.

Where's your mobile phone with 68060? Hint: It was 68000-based Dragon Ball VZ instead, and it was fragged by the likes of ARM 925T with a 120 MHz clock speed!

Apple Newton 100 handheld has ARM610 @ 20 MHz with an ex-Commodore Bob Welland-designed ARM MMU. Bob Welland got his MMU effort included with ARM 610.

StrongARM was released in 1996 with clock speeds of 100, 160, and 200 MHz. Apple MessagePad 2000 (precursor to the later iPad) used StrongARM SA-110 @ 162 MHz. This is leading up to later NextStep/Mac OS based iOS device nukes.

During the Pentium era,

1. Intel/AMD 486DX4, AMD 5x86, and Cyrix 5x86 were in the budget PC market segment. The approach is similar to StrongARM with +100 MHz and 68040-class IPC.

2. 1 million transistors scale 486 class cores are cheap, i.e., below 1 million transistors, which are 68040 class CPUs like StrongARM, and MIPS R3051 (e.g. PS1, R3000A compatible with embedded MMU) examples. There's a cost sensitivity factor driving sales with the mentioned SKUs.

The Cyrix 5x86 processor, codename "M1sc", was based on a scaled-down version of the "M1" core used in the Cyrix 6x86, which provided 80% of the performance for a 50% decrease in transistors over the 6x86 design.

Desktop X86 CPUs are designed for the highest attainable clock speed at the expense of power efficiency, since they are desktop computers plugged into the wall power.

3. Vortex86 is not using Cyrix 5x86's process node.

Quote:

The 68060 eventually lost competitiveness to newer SoC designs with better integration, optimizations for newer silicon and more modern enhancements which is what the 68060 needs to become competitive again.

On powerful handheld devices, 68060 never has a chance against ARM and MIPS.

68060's chip package is too large for mobile phones and handheld devices.

Quote:

It was easier to license the 68k until the Hitachi license dispute after which Motorola was much more protective of the 68k. The Hitachi dispute was a turning point for the 68k as not only were 2nd source suppliers for the 68020+ not available but Hitachi was likely going to produce the 68030 for Sega consoles

For the 3D geometry use case, 68030 is inferior to SuperH-2.

Quote:

which could have been copied by other Japanese console producers as was the case with MIPS, PPC and x86-64 later. Sega switched to Hitachi developed SuperH instead but SH-2 was not as mature and more of a MCU ISA that did not scale up as well as the 68k.

Fact: For the 3D geometry use case, 68030 is inferior to SuperH-2.

Again, specify a game console BOM costing with either 68EC040 or 68EC060.

Prove $30 to $40 price range 68EC040 for the 1994 time frame!
Prove $30 to $40 price range 68EC060 for the 1994 time frame!

Quote:

A 68060@1GHz may be 10 times the performance of a 68060@100MHz but the addition of modern embedded caches would increase the performance closer to 20 times. The 68060+ was going to "increase performance 20-30% independent of clock frequency" which is likely mostly due to doubling the L1 cache when it would be quadrupled, at least a L2 cache added and modern memory used for a modern enhanced 68060. There are other relatively easy performance enhancements that could be added too.

That's speculative dreamland.

PiStorm and Emu68 projects are low risk compared to Raspberry Pi's mostly copy-and-paste wafer start.

Quote:

The Cortex-A72 using a 28nm process remains practical although an in-order CPU core with close to the same performance would be more practical, cheaper and lower power.

https://www.anandtech.com/show/9184/arm-reveals-cortex-a72-architecture-details
For mainstream, ARM Cortex-A72 has 16 nm FinFET from Samsung/GlobalFoundries and TSMC.

Broadcom's BCM2711 SoC with Cortex A72 has the older 28 nm TSMC.

Quote:

The Cortex-A76 using a 16nm process is much less practical, especially for embedded use where it uses too much power and produces too much heat to embed.

FUD.

https://www.cnx-software.com/2019/01/03/samsung-exynos-auto-v9-cortex-a76-automotive-processor/
Samsung Exynos Auto V9 Octa-core Cortex A76 Processor Targets Automotive Infotainment Systems

https://www.epey.co.uk/phone/first-coprocessor/dual-core-2-6-ghz-arm-cortex-a76/
ARM Cortex A76 in Samsung mobile phones.

Last edited by Hammer on 01-Apr-2025 at 03:42 AM.
Last edited by Hammer on 01-Apr-2025 at 03:39 AM.
Last edited by Hammer on 01-Apr-2025 at 03: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

@matthey

Quote:

The shallow pipeline PPC designs were not good for high clock speeds. Ironically, Apple switched away from the 68k just as the 8-stage 68060 with what was considered a deep pipeline then came out and the announcement of higher clocked 68060s that were in testing and a 68060+ were cancelled. It is amazing how many tech CEOs do not understand tech and make political decisions instead.

IBM's Power 4-based PPC 970 wasn't a shallow pipeline design.

PPC 970 the following:
# 10 stages for simple integer and permute instructions.
# 13 stages for complex integer instructions.
# 16 stages for floating-point instructions.

AMD K8 reached higher clock speeds using the same IBM/Motorola process nodes (ref 1).

AMD Athlon X2 6400+ dual-core 90 nm reached 3.2 Ghz.
IBM PowerPC 970MP dual-core 90 nm reached 2.5 Ghz

PowerPC 970 with 130 nm reached 2 Ghz.
K8 Athlon Clawhammer with 130 nm reached 2.6 Ghz (FX-55).

Reference
1. https://arstechnica.com/uncategorized/2004/12/4459-2/

Craftsmanship is a factor.

Both AMD K8 and IBM PowerPC 970 product lines were defeated by Intel's Core 2 "Conroe" (desktop) and "Merom" (laptop). Intel's Core 2 combines the lessons from Pentium M and Pentium IV designs.



Quote:

The scalar Cyrix 5x86 has a 16B/cycle instruction fetch with a larger size needed due to the average 32-bit x86 instruction size and because of less efficient byte alignment of instructions.

Cyrix 5x86 is a 486-class CPU with a single ALU pipeline, despite what Cyrix's marketing material's "586" class.

Pentium class needs two ALU pipelines, and the 6x86 and 6x86L were not completely compatible with the Intel P5 Pentium instruction set.

Both Cyrix 5x86 and 6x86 were released in Q4 1995. Quake was released in July 1996, and it wreaked Cyrix's 6x86 business.

https://thandor.net/benchmark/33
Quake benchmark
Intel Pentium @ 100 Mhz = 26.70 fps
AMD K5 PR166 @ 116 Mhz = 24.40 fps
Intel Pentium @ 90 Mhz = 24.30 fps
AMD K5 PR133 Model 1 @ 100 Mhz = 22.90 fps
Intel Pentium @ 75 Mhz = 20.00 fps,
AMD K5 PR100 Model 0 @ 100Mhz = 20 fps,
IBM/Cyrix 6x86 P150+ M1R @ 120 MHz = 19.50 fps,
AMD K5 PR90 @ 90 Mhz = 18.50 fps

For X86 cloners, AMD K5 was the least worst than the Pentium, and Cyrix 6x86 dropped from the majority of gaming PC builds.

There were IPC improvements between K5 PR100 Model 0 (SSA5 uarch) @ 100 Mhz and K5 PR133 Model 1 (5k86 uarch) @ 100 Mhz within the same 1996 year.

Last edited by Hammer on 01-Apr-2025 at 05:25 AM.
Last edited by Hammer on 01-Apr-2025 at 04:12 AM.
Last edited by Hammer on 01-Apr-2025 at 04:09 AM.
Last edited by Hammer on 01-Apr-2025 at 04:06 AM.

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

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: 1. But you've reported it. Guess why: cherry-picking only what's interesting for you -> not intellectual honest. 2. Did you factor that development time is much faster on 68k systems? Irrrelevant. Did you factor in 68881's release date? Hint: 1984.

Yes.
Quote:

Did you factor in 68881's official support with the 1st mainstream 68K platform? Hint: 1987 for Macintosh II. Did you factor in 68881's official support with the 2nd mainstream 68K platform? Hint: 1988 for Amiga 2000's A2620. Timeline facts: 8087 was released in 1980. IBM PC 5150 was released on 12th of August 1981 with an 8087 socket.

Who cares? You lived on a parallel universe, evidently, when people were using accelerator boards at least for the Amiga 1000:
https://amiga.resource.cx/exp/csa1020
https://amiga.resource.cx/exp/turboamiga1000
https://amiga.resource.cx/exp/netchfpu
https://amiga.resource.cx/exp/hurricane1000

1986 for the first three and 1987 for the first one.

On top of that, could you tell me how was possible to release Sculpt 4D for the 68020 + 68881 on 1988?
How the developers worked, without your Amiga 2000's A2620?
Quote:

Lotus was founded in 1982 by partners Mitch Kapor and Jonathan Sachs with backing from Ben Rosen. 80287 was released in 1982. Apple Lisa was released on 19th of January 1983. Lisa OS platform suffered a sales flop. Lotus 1-2-3 1.0 was released on 26th of January 1983. Xenix 3.0 for Apple Lisa was released in 1984, including Xenix Software Development System, Xenix 68K apps from MS e.g. Multiplan 2.x and MS Word 3.0 and FoxBase Plus 1.0. Motorola released 68881 in 1984. MS Multiplan for Mac was released in 1984. IBM PC/AT was released on 14th of August 1984. Lotus 1-2-3 2.0 was released in September 1985 with x87 support. MS Excel 1.0 was released on the 30th of September 1985. Compaq 386 DeskPro (386AT) was released in September 1986. Includes 287 socket. The 1st official mainstream 68k platform support for 68881 was with Macintosh II's March 1987 release. Macintosh II has Apple's custom MMU. Mac GUI port MS Excel 2.0 for Windows 2.0 was released in November 1987. Windows 2.0 supports business 640x480p VGA color and MCGA monochrome. 80387 was released in 1987. http://www.bitsavers.org/components/chipsAndTech/CS8230_Numeric_Coprocessor_19870712.pdf Rev 1.2, 12th of July 1987, Chips and Technologies 8230 chipset documentation on 387 integration. The 2nd official mainstream 68K platform support for 68881 was with Amiga 2000's A2620's March 1988 release (demonstrated in March 1988's CeBIT show). Commodore wasted R&D time on two custom MMUs for 68000 and 68020, respectively, since 68551 was late. Unlike the Mac, the Amiga OCS is missing a mass production stable business resolution. A2024's production scale is 5000 units with production delays.

Hammer's PADDING: see above! Nobody on the Amiga land waited Commodore for buying and using accelerator cards.

You were living on a parallel universe!
Quote:

IBM VGA and VGA clones (e.g. ET3000) were released in 1987 in millions production scale. ECS Denise and at least ECS Agnus A were demonstrated with A2000 in Q4 1988. Henri Rubin departs from ECS's original intention for a quick Amiga OCS upgrade, making it time-exclusive for the A3000's 1990 release. You're not intellectually honest when the official system integration pace is slower with mainstream 68K platform vendors. ------------------------------------------------------------------ According to Dataquest November 1989, VGA crossed more than 50 percent market share in 1989 i.e. 56%. http://bitsavers.trailing-edge.com/components/dataquest/0005190_PC_Graphics_Chip_Sets--Product_Analysis_1989.pdf Low-End PC Graphics Market Share by Standard Type Estimated Worldwide History and Forecast Total low-end PC graphic chipset shipment history and forecast 1987 = 9.2. million, VGA 16.4% market share i.e. 1.5088 million VGA. 1988 = 11.1 million, VGA 34.2% i.e. 3.79 million VGA. 1989 = 13.7 million, VGA 54.6% i.e. 7.67 million VGA. 1990 = 14.3 million, VGA 66.4% i.e. 9.50 million VGA. 1991 = 15.8 million, VGA 76.6% i.e. 12.10 million VGA. 1992 = 16.4 million, VGA 84.2% i.e. 13.81 million VGA. 1993 = 18.3 million, VGA 92.4% i.e. 16.9 million VGA. Commodore - The Final Years Henri Rubin had been brought to Commodore in order to enter the business market. His central plan had been to use the Bridgeboard as a way to sneak Amiga computers into the business world by claiming MS-DOS compatibility. “The stuff that came from management was all really bizarre and most of it didn't really happen,� says Bryce Nesbitt. Rubin also banked on “Productivity Mode� in the new Amiga 3000 as a way to stay current with the VGA capabilities of PC clones. Instead, by mid-November 1990, even Hedley Davis acknowledged to his fellow engineers that the PC and Macintosh had moved far beyond the capabilities of the Amiga line. In a memo to his fellow employees, he wrote, “While the Amiga was first out on the (inexpensive) market with certain interesting capabilities, this lead has rapidly eroded as other vendors have brought the MS-DOS and Mac machines up to and far beyond the capabilities available on Amiga platforms.� Henri Rubin has an ECS mistake e.g. A3000. Bill Sydnes and Jeff Frank have ECS mistakes e.g. ECS A300/A600, ECS A2200/A2400, and ECS A3200/A3400.

Completely OT PADDING which you repeat as a BROKEN RECORD every time and everywhere.

BOT!

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Irrelevant + Red Herring: the (sub)topic here was that the 65CE02 is an 8-bit and NOT a 16-bit CPU. It's relevant since 65CE02 has double data rate (DDR) processing with its 8-bit ALU, while the 68000's ALU has 16-bit SDR processing.

ROFL You miss even elementary microelectronic concepts!

How in your parallel universe a double data rate 8-bit circuit could make an 8-bit ALU as a 16-bit ALU? How?!?

Do you understand that the 65CE02 has only 8-bit data registers? Have you ever opened its architecture/datasheet manual? Not even once in your life, for sure!
Quote:

Quote: Irrelevant. The (sub)topic here was that RMS arrived one year before the Amiga. And it was a great system AT THAT TIME. Wrong. You didn't factor in system integration R&D time. From https://books.google.dk/books?id=k5bNBQAAQBAJ https://retrocomputing.stackexchange.com/questions/10977/fate-of-mystery-motorola-rms-graphics-chipset-68486-68487 In the book "CoCo: The Colorful History of Tandy’s Underdog Computer" (ref), authors Boisy Pitre and Bill Loguidice describe how the RMS originally was developed in conjunction with or at least at the same time as the Tandy Color Computer 3, which was released in summer 1986. Presumably then, the CoCo3 was developed during 1985-86.

Irrelevant. You have not even opened the PDF which Bruce has shared.
Quote:

A1000's 1985 release includes system integration, not just chipset release.

Sure, but on this part of discussion it was about the chipset and not an entire computer.

Motorola's PDF clearly talks and reports about the RMS chipset that they have created, for which a devkit was also available.

So, that was the context, BOT!
Quote:

The Microbox 3 manufactured and sold by UK-based company "Micro Concepts" from Cheltenham! I can only find it described in detail one place and that is in the Electronics & Wireless World issue of May 1986. On page 63, it is announced as the British rival to the Amiga and the description leaves little doubt: "May 1986" announcement

See above, bot! This is a computer. Motorola developed chipsets, like the good old 6845.
Quote:

dickhead.

Oh, guess what: you start heavily offending here. Not able to discuss, right, looser?
Quote:

http://retro.co.za/6809/microbox/Microbox3.html From David Rumball, system integrator for Match Box 3, I was forced to quickly redesign the MB3 after the RMS cancellation and this became the "Phoenix" AKA MB4 AKA Image-10 (late 1986). The RMS devices were replaced by and Intel 82786 graphics chip which gave vastly improved graphics performance (hardware windowing and acceleration), the processor was the 68010 and the peripherals were more or less the same although I added a Transputer link interface (I was heavily into the Transputer at the time). The same OSs were ported again to the Image-10. There was a variant of the Image-10 which was used by a company called Visual Data Systems for interactive video. RMS cancellation,

Sure, it happens to projects. And?
Quote:

dickhead.

Same above: heavily offending is a clear sign of incapacity to sustain a discussion.
Quote:

RMS didn't reach A1000's mass production product release state.

ROFL.

BOT!
Quote:

------------------------------------------- Motorola released the 68040 in 1990. The 1st 68040-based mainstream platform was released in October 1991 via Apple's Quadra 700. Mainstream 68K camp has a slower system integration pace.

And here your usual total OT / PADDING.

You miss nothing. As usual. BOT!

@matthey

Quote:

matthey wrote: Hammer Quote: AC68080 gaining ColdFire instructions is an attempt to attract embedded customers. I am still unsure about the AC68080 ColdFire support. I believe Gunnar added them to early AC68k cores, then removed them and maybe added them back but did not update the AC68080PRM or used different encodings? AC68080PRM MOVS (similar to ColdFire MVS) %1010 reg 10s EA AC68080PRM MOVZ (similar to ColdFire MVZ) %1010 reg 11s EA ColdFire MVS %0111 reg 10s EA ColdFire MVZ %0111 reg 11s EA The AC68080PRM ColdFire instructions use a different name and encoding.

Reusing existing/used opcodes for something else is CRIMINAL.

Unfortunately, that's what Gunner does (see the CALLM instruction as another example).

Specifically, he used LINE-A for such instructions which ColdFire has smartly placed on a different lane.

LINE-A could have much better being used for a SIMD/Vector extension! No words...

@cdimauro

Quote:

ROFL You miss even elementary microelectronic concepts! How in your parallel universe a double data rate 8-bit circuit could make an 8-bit ALU as a 16-bit ALU? How?!?

Ask Intel about the integer ALU of the Pentium 4 Willamette and Northwood, which was a "double-pumped" 16-bit ALU.

Quote:

Do you understand that the 65CE02 has only 8-bit data registers? Have you ever opened its architecture/datasheet manual? Not even once in your life, for sure!

I'm aware that 65CE02 has 8-bit registers, but it has some interesting design features. You assumed wrong.

Quote:

You have not even opened the PDF which Bruce has shared.

It's useless when it's a pure tech demo without a product release, i.e., it was cancelled.

Your counterargument is not even at A1000's 1985 release state, which includes the system integration stage.

Amiga Corp's Amiga Lorraine's June CES 1984 demostration was a pure tech demo. CSG did a reasonable job of converting Lorraine's breadboards into ASICs. Between CES June 1984 and NTSC A1000's July 23, 1985 release, 64-color EHB mode was added. The original Amiga team quickly responded, and the CSG team followed.

Last edited by Hammer on 01-Apr-2025 at 05:57 AM.
Last edited by Hammer on 01-Apr-2025 at 05:39 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:

Sure, but on this part of discussion it was about the chipset and not an entire computer. Motorola's PDF clearly talks and reports about the RMS chipset that they have created, for which a devkit was also available. So, that was the context, BOT!

My post has an RMS system integration timeline example. TURD!

For pure tech demo vs pure tech demo in CES June 1984, it was Amiga Lorraine.

PAL A1000 had the 64-color EHB mode and upgrades for early ICS NTSC A1000s.

Last edited by Hammer on 01-Apr-2025 at 05:52 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:

Who cares? You lived on a parallel universe, evidently, when people were using accelerator boards at least for the Amiga 1000: https://amiga.resource.cx/exp/csa1020 https://amiga.resource.cx/exp/turboamiga1000 https://amiga.resource.cx/exp/netchfpu https://amiga.resource.cx/exp/hurricane1000

Not a simple empty FPU socket.

Do you have sales statistics for them? Hint: John Carmack's install base argument.

On WinUAE,
Amiga 1000 with Kickstart 1.1 ROM (1986 PAL, rev 31.34), 68000 CPU, 512KB Chip RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Crash at startup sequence i.e. "software error - task held"

Amiga 1000 with Kickstart 1.1 ROM (1986 PAL, rev 31.34), 68020 CPU, 512KB Chip RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Crash at startup sequence i.e. "software error - task held"

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

Amiga 500 with Kickstart 1.2 ROM (1987), 68000 CPU, 512KB Chip RAM, 512 KB Slow RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Start-up success.

Amiga 500 with Kickstart 1.2 ROM (1987), 68020 CPU, 512KB Chip RAM, 512 KB Slow RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Start-up success.

Sculpt Animate 4D v2.04 (1988) needs 1987 era Kickstart 1.2 ROM.

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

https://amiga.resource.cx/exp/csa1020
68020 @ 7.14 MHz,
68881 @ 7.14 MHz,

the board is meant for accelerating math intensive applications, otherwise it gives only a 10% speed increase on integer code


https://amiga.resource.cx/exp/netchfpu
1986 release, 68010 + 68881 board @ 16 Mhz.

https://amiga.resource.cx/exp/hurricane1000
1987 release,
68020 / 68030 @ 14.3 MHz, PGA.
68881 @ 16 or 20 MHz, PGA.


https://amiga.resource.cx/exp/turboamiga1000
1986 release,
68020 and 68881 @ 14.3 MHz overclock from 12Mhz

Note that 68020 and 68881 were released in 1984.

That wouldn't match
1. Intel 386 (October 1985) and Compaq DeskPro 386 (386AT, September 1986) system integration pace.
2. Intel 486 (April 10, 1989) and 486/25 Power Platform (first shipping in late September 1989) system integration pace. Compaq Deskpro 486/25 was released in November 6, 1989.

Last edited by Hammer on 01-Apr-2025 at 07:35 AM.
Last edited by Hammer on 01-Apr-2025 at 07:27 AM.
Last edited by Hammer on 01-Apr-2025 at 06:48 AM.
Last edited by Hammer on 01-Apr-2025 at 06:47 AM.

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

@matthey

Quote:

matthey wrote: coder76 Quote: 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. ColdFire was moderately successful but at the low end of the embedded market where it did not get much attention. More people have heard of PPC but it was only moderately successful or perhaps moderately unsuccessful considering the huge R&D capital spent on it. ColdFire was just castrated 68k often reusing existing 68k designs which was very cheap to do in comparison. Unsuccessful and perhaps the last ISA Motorola developed was the short lived MCore. https://en.wikipedia.org/wiki/M%C2%B7CORE It is more comparable to a simplified and inferior SuperH.

Indeed. Nice effort, but nothing really new, "game changer".

I also find it weak on some critical areas: constants limited to only a few instructions. Loads/stores only with 4-bit unsigned immediate. And only zero-extended byte/half-word loads/stores. So, I strongly doubt that it can reach very good code density.

And it's more suitable for embedded: not so much general-purpose, with a crippled future for extensions.
Quote:

Several large businesses thought simplification and castration was the goal for embedded systems but now that they have lost influence, embedded CPU ISAs and cores have become big and fat compared to the 68k which is practical for embedded use, especially with its very good code density. Too bad politics made the pioneering and leading 32-bit embedded 68k architecture disappear.

Because they never factored/understood the Moore's law, which consistently reduced the impact of the "complexity" in decoders/frontend and backend.
Quote:

cdimauro Quote: Even 4 was too much for an in-order design. That's the reason why when you want to approach the 3 instructions per cycle for an in-order system, it's better to evaluate a 2-way OoO one which allows much better performance. On top of this, 3-way in-order makes more sense on LD/ST (former RISC) designs, where you can have more dependent instructions due to the need to load or build constants to be used later by other instructions. The "executes up to six instructions per clock cycle" is more of a marketing thing. The same link has a chart that uses "Peak Inst/Cycle" instead. http://apollo-core.com/index.htm?page=features The 68060 is listed at 2 peak instructions/cycle when it should be 3 with two integer instructions and a predicted branch possible even though it is really not executing the predicted branch but folding it away. ColdFire and the AC68080 use other code folding techniques as well to increase the peak instructions/cycle even though this may not be common. The AC68080 is claimed to be able to fold two instructions into a single 3 op instruction in each integer pipe which is 4 peak instructions/cycle.

Just marketing...
Quote:

Maybe he added the 3rd pipe which I suggested based on research showing the 68k usually has 2.5-3.0 average instruction length allowing a reasonable sized instruction fetch to feed 3 integer pipelines. For comparison, I found Cyrix claims for x86 average instruction length. https://datasheets.chipdb.org/Cyrix/5x86/5X-DPAPR.PDF Quote: Two facts were fundamental in identifying features for the 5x86: (a) the x86 is a 32-bit architecture. (b) the average instruction length is 2.7 bytes for existing 8/16-bit code and 4.4 bytes for 32-bit code. 16B/2=8B 16B/3=5.33B 16B/4=4B 16B/5=3.2B 16B/6=2.66B The scalar Cyrix 5x86 has a 16B/cycle instruction fetch with a larger size needed due to the average 32-bit x86 instruction size and because of less efficient byte alignment of instructions. The superscalar 68060 has a 4B/cycle instruction fetch with a decoupled instruction fetch pipeline, instruction buffer and execution pipelines and a 8B/cycle instruction fetch could feed 3 integer pipelines better than 4B/cycle feeds 2 integer pipelines. The superscalar AC68080 has a 16B/cycle instruction fetch with no decoupling which requires ~2.66 average instruction length and perfect alignment of instructions to the instruction fetch to be able to execute 6 instructions/cycle. I do not expect this is common as the use of a 16-bit prefix likely increased the average instruction length and decreased code density. It would be rare to be able to fold 3 pairs of instructions in 3 execution pipes from a single 16B fetch but 3 pipes could still be worthwhile without instruction folding and there is adequate instruction fetch for execution of 5 instructions/cycle most of the time. A 16B instruction fetch for 32-bit x86 code could only feed 3 instructions/cycle execution most of the time which is a big difference. Even 32-bit fixed length RISC encodings obtain 4 instructions from a 16B fetch and the instructions are perfectly aligned every time. Maybe this is why ARM64/AArch64 returned to a 32-bit fixed length encoding without the 68k demonstrating CISC instruction fetch and code density advantages. average instructions in a 16B instruction fetch 8/16-bit_x86 5.9 32-bit_x86 3.6 32-bit_68k 5.3-6.4 AArch64 4

Frankly speaking (as usual), I doubt that the numbers reported by Cyrix are correct. In my experience / statistics, the x86 average instruction length is 3.2 bytes circa. And not only mine: it's also reported on some other studies. 4.4 bytes is even more than what's found for x64.
Quote:

The 68k had a large advantage by starting with a 32-bit ISA, 32-bit pointers and a large flat address space. ìThe handicap of x86(-64) is severe when moving to 32-bit and 64-bit yet the 68k was the architecture killed for political reasons.

Yes, it was and still is a very nice architecture. It's a pity that it was killed.

But it's missing two important things: a 64-bit extension and a SIMD/vector unit.
Quote:

cdimauro Quote: There were many in the 90s. Much less on the new millennium. In fact, Amiga port to PowerPCs made no sense when effectively it was started. Even Apple tried to exit the PowerPC market at the very beginning of 2000s, before such Amiga ported started, because PowerPCs were not competitive anymore against x86 systems. The rumors that Apple was unhappy with PPC development, especially low clock speeds, and contemplated switching to Intel started around 2000 while AmigaOS 4 development started in 2001. https://web.archive.org/web/20201031220502/https://www.macrumors.com/2005/06/05/intel-based-mac-rumor-roundup/ Quote: An Intel based Macintosh? Rumors of Apple switching to an Intel based processor pre-date the existence of this site. The earliest reference in our archives comes from March 15, 2000 (this site was founded in Feb 2000). For some perspective... a rumor roundup for WWDC 2000 (5 years ago) included rumors of "Intel-based Macs". Analysts also "urged Apple to move to microchips from Intel Corp" back in July 2002. Steve Jobs replied that they had to finish the OS 9 -> OS X transition first but "Then we'll have options, and we like to have options. But right now, between Motorola and IBM, the roadmap looks pretty decent." After the transition to Mac OS X, Apple was reported to have kept an OS X on x86 side-project known as Marklar. The original article described Marklar as a "fall back plan" should the PowerPC fail to deliver. The PowerPC was undergoing slow development during that time until IBM took over development and Apple announced PowerPC G5 based PowerMacs in the summer on 2003. In fact, IBM bragged in an internal memo that while Apple considered moving to Intel at that time they went with IBM's PowerPC G5 (970) because Apple felt the transition to Intel would be too difficult: IBM internal memo While Intel is aggressive in achieving its performance and speed goals, Apple believed that using Intel would deeply affect its current customer base. Using an Intel architecture might solve Apple's short-term megahertz dilemma, but customers would have to suffer through a slow transition from PowerPC over the long term. Every existing Mac program would potentially have to be recompiled to work on an Intel platform. These massive software changes were something that Apple wanted to avoid, and IBM had the solution. Despite this, Apple/Intel rumors continued to surface (Sept 2003).

Those weren't rumours: I've written an article about that, some years ago. Apple was switching to Intel at the very beginning of 2000s. The switch was just delayed because IBM promised the G5 to Jobs. But it was a delay, as we know (G5 flopped).
Quote:

The shallow pipeline PPC designs were not good for high clock speeds. Ironically, Apple switched away from the 68k just as the 8-stage 68060 with what was considered a deep pipeline then came out and the announcement of higher clocked 68060s that were in testing and a 68060+ were cancelled. It is amazing how many tech CEOs do not understand tech and make political decisions instead.

Commodore is another great example...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: ROFL You miss even elementary microelectronic concepts! How in your parallel universe a double data rate 8-bit circuit could make an 8-bit ALU as a 16-bit ALU? How?!? Ask Intel about the integer ALU of the Pentium 4 Willamette and Northwood, which was a "double-pumped" 16-bit ALU.

I knew that you were going on this direction, and I was just wait for your next complete non-sense. In fact, you're on time like Swiss clock.

NO, and again NO! As I've said, you've no basic/elementary microelectronic knowledge!

A double-pumped 8-bit ALU just (!) produces two 8-bit results in a single clock cycle, and NOT one 16-bit result per clock! Like two women that do NOT make a single baby in 4.5 months!

A 16-bit result per clock cycle could be produced only if the 8-bit ALUs are "chained" in some way (e.g.: part of the result of the first computation is feed as input for the second computation. Like the carry bit).

This clarified, that's NOT the case for the 65EC02!
Quote:

Quote: Do you understand that the 65CE02 has only 8-bit data registers? Have you ever opened its architecture/datasheet manual? Not even once in your life, for sure! I'm aware that 65CE02 has 8-bit registers,

So, how it can produce 16-bit results for all or the majority of it's operations? HOW?!?
Quote:

but it has some interesting design features.

I DON'T CARE!

What's not clear to you that the context was different?
Quote:

You assumed wrong.

I assumed right: see above! You don't know of what you talk about!
Quote:

Quote: You have not even opened the PDF which Bruce has shared. It's useless when it's a pure tech demo without a product release, i.e., it was cancelled. Your counterargument is not even at A1000's 1985 release state, which includes the system integration stage. Amiga Corp's Amiga Lorraine's June CES 1984 demostration was a pure tech demo. CSG did a reasonable job of converting Lorraine's breadboards into ASICs. Between CES June 1984 and NTSC A1000's July 23, 1985 release, 64-color EHB mode was added. The original Amiga team quickly responded, and the CSG team followed.

Hammer's PADDING.

As I've said in vain, Motorola do NOT produce entire computers, rather only CHIPSETS!

You're comparing apples with oranges!

EDIT.
Quote:

Hammer wrote: @cdimauro Quote: Sure, but on this part of discussion it was about the chipset and not an entire computer. Motorola's PDF clearly talks and reports about the RMS chipset that they have created, for which a devkit was also available. So, that was the context, BOT! My post has an RMS system integration timeline example.

No way! Even Bruce was talking about the RMS "per sé": all about the CHIPSET!

You don't know how to follow a discussion and continue to change the context, BOT!
Quote:

TURD!

Guess what: another free offence.

Because you don't know how to argue on a discussion which you can't sustain.

Looser!
Quote:

For pure tech demo vs pure tech demo in CES June 1984, it was Amiga Lorraine. PAL A1000 had the 64-color EHB mode and upgrades for early ICS NTSC A1000s.

Same as above: apples and oranges!

Last edited by cdimauro on 02-Apr-2025 at 04:55 AM.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Who cares? You lived on a parallel universe, evidently, when people were using accelerator boards at least for the Amiga 1000: https://amiga.resource.cx/exp/csa1020 https://amiga.resource.cx/exp/turboamiga1000 https://amiga.resource.cx/exp/netchfpu https://amiga.resource.cx/exp/hurricane1000 Not a simple empty FPU socket.

And HOW CARES?!? The Amiga market was florid and gave all users many accelerator cards WITHOUT waiting the sleeping Commodore engineers!
Quote:

Do you have sales statistics for them?

No. I don't care and it's totally irrelevant.
Quote:

Hint: John Carmack's install base argument.

Sure. Another one which never understood how the Amiga market worked and how its users resolved such problems.

But you need to have lived this time to understand: it's not something for aliens which lived on a parallel universe...
Quote:

On WinUAE, Amiga 1000 with Kickstart 1.1 ROM (1986 PAL, rev 31.34), 68000 CPU, 512KB Chip RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Crash at startup sequence i.e. "software error - task held" Amiga 1000 with Kickstart 1.1 ROM (1986 PAL, rev 31.34), 68020 CPU, 512KB Chip RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Crash at startup sequence i.e. "software error - task held" --------------------- Amiga 500 with Kickstart 1.2 ROM (1987), 68000 CPU, 512KB Chip RAM, 512 KB Slow RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Start-up success. Amiga 500 with Kickstart 1.2 ROM (1987), 68020 CPU, 512KB Chip RAM, 512 KB Slow RAM, selected Sculpt Animate 4D v2.04 (1988) ADF. Result: Start-up success. Sculpt Animate 4D v2.04 (1988) needs 1987 era Kickstart 1.2 ROM.

It's incredible: you miss no opportunity to show your ignorance.

https://theamigamuseum.com/amiga-kickstart-workbench-os/kickstart/kickstart-1-2/
Kickstart 1.2 first appeared in October 1986
[...]
this was the first version of Kickstart that not only came on a floppy disk for the (newly renamed) Amiga 1000

https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt
Kickstart 1.2 (33.166) for Amiga 1000
Size: 256 kB
Year: 1986
Checksum: OK (F989BAC3)
Resident modules: 23

https://wandel.ca/homepage/execdis/exec_disassembly.txt
The following is a complete disassembly of the Amiga 1.2 "exec", as found on a kickstart disk for an Amiga 1000.

WHEN you will SERIOUSLY STUDY something in your life?

I can understand that you haven't enjoyed the Amiga time because you're were living on parallel universe, but in this case why you just do NOT write of things that you've no clue?!?

In fact, just selecting the quick config on WinUAE for the A1000 with its Kickstart 1.2, adding the above Sculpt 4D ADF and... rolling drum... it worked!
Quote:

--------------------- https://amiga.resource.cx/exp/csa1020 68020 @ 7.14 MHz, 68881 @ 7.14 MHz, the board is meant for accelerating math intensive applications, otherwise it gives only a 10% speed increase on integer code https://amiga.resource.cx/exp/netchfpu 1986 release, 68010 + 68881 board @ 16 Mhz. https://amiga.resource.cx/exp/hurricane1000 1987 release, 68020 / 68030 @ 14.3 MHz, PGA. 68881 @ 16 or 20 MHz, PGA. https://amiga.resource.cx/exp/turboamiga1000 1986 release, 68020 and 68881 @ 14.3 MHz overclock from 12Mhz

And?!?
Quote:

Note that 68020 and 68881 were released in 1984.

Sure. And in two years it was already available and supported on the Amiga 1000.

Now you can do another home work and try this: Sculpt Animate 4D v2.09 (1988)(Byte-by-Byte)(Disk 1 of 3)[cr Unicorn][68020, FPU].adf
on the A1000.

And you can tell me how it was possible the this software was released supporting the FPU. HOW?
Quote:

That wouldn't match 1. Intel 386 (October 1985) and Compaq DeskPro 386 (386AT, September 1986) system integration pace.

One year vs two years, and? What's YOUR problem?!?
Quote:

2. Intel 486 (April 10, 1989) and 486/25 Power Platform (first shipping in late September 1989) system integration pace. Compaq Deskpro 486/25 was released in November 6, 1989.

Again, irrelevant: we have NOT waited Commodore for the first 68040 boards.

Here we go, again:
https://amiga.resource.cx/exp/fusion40
https://amiga.resource.cx/exp/turbomaster
https://amiga.resource.cx/exp/progressive540
https://amiga.resource.cx/exp/magnum2040
https://amiga.resource.cx/exp/gforce2040
https://amiga.resource.cx/exp/overthetop
https://amiga.resource.cx/exp/progressive2040
https://amiga.resource.cx/exp/zeus2040

You "simply" (!) don't know how the Amiga market worked.

@cdimauro

Quote:

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."

What you don't get is that Lotus 123 2.0's x87 support was in the marketplace from September 1985 with large existing install base and PC hardware sales rivaling C64's unit annual sales, while mainstream 68K competition is largely missing in action or starting ground zero or sales stalling, despite your "68k + 68881 is WAY EASIER to develop for" argument.

The fight among the 68K platforms is reaching the number 2 business desktop computer platform position.

1985 Mac platform received "killer apps" with "next gen" GUI like MS Excel 1.0 (from September 30, 1985), Aldus PageMaker 1.0 (from July 1985). Mac obtained PostScript support in 1986. Killer app business software in H2 1985 and into 1986 helped reverse Mac's declining 1985 sales, with sales growth in 1986.

https://en.wikipedia.org/wiki/Market_share_of_personal_computer_vendors
Mac
1984: 372,000, partly starts from ground zero with lessons from the sales-flopped Apple Lisa.
1985: 200,000, declining sales. MS Excel 1.0 from September 30, 1985.
1986: 380,000, return to sales growth.
1987: 550,000, the "killer GUI app" Quark Express 1.0 from March 1987. Color Mac II from March 1987.
For the Mac platform, early MS Excel 1.0 reached 200,000 vs Lotus Jazz's 20,000.
1988: 900,000,
1989: 1,100,000,
1990: 1,300,000, Mac LC I released with 500,000 1st year unit sales.
During March 994 to January 1995, Mac's customer demographics were able to purchase 1 million PowerMacs and the Amiga's demographics do NOT have this attribute!


IBM PC compatible,
1984: 2,000,000, Phoenix PC ROM BIOS was introduced in May 1984, which enabled OEMs such as Hewlett-Packard, Tandy Corporation, and AT&T Computer Systems to build essentially 100%-compatible clones without having to reverse-engineer the PC BIOS themselves as Compaq had.
1985: 3,700,000, Lotus 123 2.0 from September 1985,
1986: 5,020,000, Compaq 386AT standard from September 9, 1986. American Megatrends's AMIBIOS availability in 1986. Page Maker 1.0 with Windows 2.0 runtime in 1986.
1987: 5,950,000, Windows 2.0 8086/286/386, MS Excel 2.0 GUI, Xenix 386 availability in 1987. The VGA standard was released.


Commodore C64,
1984: 2,500,000,
1985: 2,500,000,
1986: 2,500,000,
1987: 1,500,000,
Treated like a soft drink product, the management rot already inside Commodore.


Commodore Amiga,
1985: 100,000, starts from ground zero, not compatible with C64. A1000 was released.
1986: 200,000, Germany's A2000 was released. Defender of the Crown moment from Nov 1986.
1987: 300,000, A500, and A2000-CR was released.
1988: 400,000. ECS's productivity mode was demonstrated on A2000 in Q4 1988. Henri Rubin departs from the original ECS's purpose i.e. timed exclusive for the A3000 project. ECS's original purpose is to upgrade OCS into ECS ASAP. A2024 monitor's production scale is just 5000 units. LOL

Your counterargument with Amiga's 3D software with 68020/68881 support in 1988 is largely too late, and it's not even coupled with stable high-resolution modes for business! Amiga is not a Mac.

1989: 600,000, Starter Packs sales initiative started.
1990: 750,000,
1991: 1,035,000,
1992: ECS A600 sales flop. Commodore was effectively insolvent with a max credit limit in 1993.

If AGA sales numbers are treated as worldwide
44,000 (the UK has 30,000 during its launch),
100,000 (AF50, Sep 1993),
170,000 (AF56, Feb 1994),
166,000 (CD32, Commodore US president, Jan 1994),
7,500 (Germany's A4000/030),
3,800 (Germany's A4000/040),
Total: 491,300 AGA units.
To build more AGA machines, Irving Gould lent his money to Commodore in 1993.
Amiga engineers placed an empty FPU location on the A1200's motherboard.
400,000 A1200 manufacturing contract has a per unit $50 tax to pay back old A600-related debt, and Apple didn't have this financial stress.


Atari ST,
1985: 100,000,
1986: 200,000, MegaST released with blitter, not a platform standard.
1987: 400,000,
1988: 350,000, declining sales. ST's game graphics are aging at this point.
1989: 300,000, declining sales. Too late STE released with blitter, 4096 color palette, two-channel PCM DMA audio updates.


Unlike the Atari ST, Amiga's unit sales continued to grow until the stupid 1 million ECS A600 debacle in 1992.

You missed the big picture on the platform's general situation.

Last edited by Hammer on 02-Apr-2025 at 05:43 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