@matthey

Quote:

matthey wrote: 1987 68020+Ranger (Amiga 2000 only until VRAM prices dropped) 2MiB chip VRAM, x2 chip mem bandwidth, 99% CPU performance without fast mem, 7MHz clock 128 colors max (256 cheaply if they added EHB mode and another bit plane) 320x256x8 (LORES 256 colors), 640x256x8 (HIRES 256 colors), 1280x256x4 (SUPER-HIRES 16 colors) 640x480x4 (SVGA 16 colors), 1024x1024x4 (16 colors) 1990 68000+ECS (all Amigas) 2MiB chip DRAM, 7MHz chipset clock 64 colors max (with EHB mode) 320x256x6 (LORES 64 colors), 640x256x4 (HIRES 16 colors), 1280x256x2 (SUPER-HIRES 4 colors) 640x480x2 (SVGA 4 colors), 1024x1024x2 (4 colors) 1992 68020+AGA (all Amigas) 2MiB chip DRAM, x4 chip mem bandwidth, 14MHz chipset clock 256 colors max (plus HAM8) 320x256x8 (LORES 256 colors), 640x256x8 (HIRES 256 colors), 1280x256x5 (SUPER-HIRES 32 colors) 640x480x5 (SVGA 32 colors), 1024x1024x5 (32 colors)

So I'm assuming that in 1987 you'd still have an A500 (as we had it) accompanying the Amiga Ranger big box machine?
Following it up with an A600 (as we had it) in 1990?
If at that time they could've had it at $599 then that would've been a seller. It'd be beating the C64 launch price (when adjusted for inflation). There might've even been more sales of the A600 in 1990/91 than A500s in 1987/88. Creating a new gaming baseline, which then would've seen more A500 owners upgrading.

An A300 at $299 would've matched the 1983 C64 $250 price, but from 1990 and onward it was no longer a low-price market. That price bracket was the domain of gaming consoles, but also people wanted to do more with their personal/home computers, so $499+ is where consumers felt they're getting a device that can help with work, and also entertain.

In the above release schedule, do you have an AGA A3000 coming out in 1992, and therefore the very expandable Amiga Ranger covering from 1987 to 1992?
Skip the slim desktop episode and make sure the AGA A3000 can accommodate Video Toaster cards?

In this schedule, Amiga is better challenging Apple: Having a Desktop that is comparable to the Mac II, and then an A3000 better challenging the IIvi/vx/Performa 600.
And eating some of Quadra's lunch if/when equipped with an 040.

_________________
All the way, with 68k

@agami
Alternate timeline.

1985 Amiga 1000 68000+OCS@7MHz

1987 Amiga 2000 68020+Ranger@14MHz
1987 Amiga 500 68000+OCS@7MHz

1988 Amiga 300 console 68000+OCS@7MHz (no floppy, cartridge based)

1989 Amiga 3000 68030+AA+@28MHz
1989 Amiga 700 68020+Ranger@14MHz

1990 Amiga CD32 68020+Ranger@14MHz

1991 Amiga 4000T 68040+AA+@28MHz (or separately clocked 68040)
1991 Amiga 1200 68030+AA+@28MHz

1992 Amiga CD32+ 68030+AA+@28MHz

1994 Amiga 5000T 68060+AA+3D@57MHz (or separately clocked 68060)
1994 Amiga 1400CD 68030+AA+@57MHz single chip SoC
1994 Amiga CD32++ 68030+AA+@57MHz single chip SoC

1997 Amiga CD32+3D 68030+AA+3D@57MHz single chip SoC
1997 Amiga 1500CD 68030+AA+3D@57MHz single chip SoC

1998 Amiga 6000T 68060+AA+3D@114MHz single chip SoC

2000 AmigaCD32+3D+ 68060+AA+3D@114MHz single chip SoC

Notes:
The Amiga 300 cartridge based 68000+OCS console may be difficult without a better Amiga launch with better gaming marketing (C= at first wanted to disassociate the Amiga from the collapsed console gaming market). There were starting to be more Amiga games by 1988 and the console market was picking up again so it probably was worth a try, especially if it could be expanded with a keyboard and floppy drive into a full Amiga. C= likely wouldn't have had much financing to launch it but it may have had a successful enough launch like the CD32 and the hardware was attractive and could sell itself at a low enough price point.

It would be better if the Amiga 3000 was made a little taller and included a 5.25" drive bay for a CD-ROM drive as well as better communication and coordination with NewTek to make sure the Toaster fits. I skip the Amiga 4000 and go directly to a 4000T in my timeline. The Amiga 4000 only delayed the more desirable 4000T and split production between two models. If the Amiga 3000 desktop demand remains high enough then the CPU+chipset can be upgraded like the Amiga 3000+.

I skip AA/AGA which isn't enough of an upgrade over Ranger and develop AA+ in my timeline. The integration from 3 to 2 CMOS chips using a better chip process costs a little more up front but the chips become cheaper to produce, product footprints can be reduced with a cost savings and there would be a power supply and heat reduction savings. The 2 modernized chips would then be ready to integrate further into a single chip Amiga SoC.

The Amiga 1200 should have been designed to more easily accommodate a CD-ROM drive upgrade from the beginning. Moving the Amiga to a CD-ROM standard was an after thought by C=. The CDTV wasn't marketed as an Amiga and only with the release of the CD32 did C= think of an Amiga CD-ROM standard. More economical IDE hard drive support should have been planned earlier for the low end and more modern and higher performance CPU, SCSI and memory options used on the high end when they provided good value. Also, networking and mic support were late to the Amiga which could have made the Amiga more professional. C= wanted the Amiga to be a professional business machine but they were far from IBM.

I assume C= would be able to license the 68060 by about 1997 in order to include it in the Amiga SoC by 1998. The AIM alliance was formed in late 1991 and the 68k became an embedded CPU where PPC was too fat to compete so Motorola likely didn't consider even the top of the line 68060 a core asset. Just process improvements likely could have had it reach 114MHz but pipeline stage rebalancing and optimization of bottlenecks was likely necessary to clock it up more. At some point, the CPU clock would need to run at a multiple of the chipset clock and caches increased in order to remain competitive. This would require enhancements which either C= could have payed Motorola to do or they could have made some changes themselves like they did with PA-RISC which they licensed. The basic 8 stage in-order 68060 design has good single core performance, should allow a relatively high clock speed at that time and is low power which is perfect for a console so it doesn't need major changes although a SIMD unit and/or better FPU were becoming more important around the year 2000. The original XBox introduced an aggressively OoO Pentium III in 2001 but it ran hot and the next XBox 360 went back to a cooler running in-order PPC CPU core. The Nintendo GameCube in 2000 was likely the first console with an OoO CPU core but PPC core designs were often shallow pipeline limited OoO designs so this 4 pipeline stage OoO Gekko CPU only had 2.31 DMIPS/MHz which a good in-order CPU core can compete with (the in-order 68060 was outperforming the OoO PPC 603 and the in-order 8 stage ARM Cortex-A53 CPU core is ~2.3 DMIPS/MHz albeit using a significantly improved chip process). The PS1-PS3 used in-order CPU cores to save power as well. Chip processes had improved enough that the PS4 in 2013 and XBox One in 2013 could use aggressively OoO x86-64 CPU cores even though these newer consoles use more power and run hotter than older consoles. By this time, a 68060 Amiga SoC based console would have dropped to a budget console and with the chipset seeing incremental upgrades using newer chip processes, it would have still been a nice sub $100 USD fanless console with decades of compatible Amiga software. Such an Amiga console still looks pretty good today. The embedded market has grown a huge amount since the CD32 in 1993 as the Raspberry Pi has shown by catering to the same budget hardware market. The 68k may have the same or better performance potential compared to the x86(-64) even though it has better code density so OoO CPU designs are possible and likely if Amiga consoles and computers sold well enough. Economies of scale are king as ARM has shown by leveraging the low margin but high volume embedded market to now compete with x86-64.

Last edited by matthey on 05-Oct-2023 at 09:45 PM.
Last edited by matthey on 05-Oct-2023 at 07:24 PM.

@matthey

While I am on record stating that C= should've tried to stick to a 2-year new product/major upgrade cadence, I still do consider it highly optimistic for our C= to pull that off.

Here you have omitted ECS, which I agree would be a waste of engineering time and sand, in a Ranger world. And with the AA+ delivered in its stead, one has to wonder what kind of games, productivity and creative software, and hardware peripherals it would engender that could've seen it as a more legitimate threat to Apple's ecosystem: Potentially boosting the Amiga platform from 5% global market in 1991 to the 10% occupied by Apple, and essentially switching places.

It's like that joke where one of the people running away from the bear stops to switch their shoes. The goal is not to outrun the bear, it's to outrun the the other person.

Your bullish view extends all the way to the turn of the millennium. Which of the products do you see generating enough revenue/net profit to stave off the bankruptcy? Or does Microsoft step in, given Amiga's #2 position, and Apple going bankrupt earlier?

While I do agree that the 060 had legs which it never got to fully stretch, in the 2000s C= (or whoever is making these Amigas) would've needed a 64-bit processor to stay competitive. Lots of options, but none that feel quite right.

I do think a CD32+ in 1992 would've been an excellent Doom and Doom II console. And a game like that would be a system seller.
But I think the CD32++ would've needed to flex its expansion capabilities to get a Quake port.

_________________
All the way, with 68k

agami Quote:

While I am on record stating that C= should've tried to stick to a 2-year new product/major upgrade cadence, I still do consider it highly optimistic for our C= to pull that off.

C= had a "2-year new product/major upgrade" plan from AGA on, after it was too late. The following data is from the C= Post Bankruptcy doc.

Hardware Technology History/Plan
1985 OCS@14MHz, 16 bit, 5 chips, 1x performance
1989 ECS@28MHz, 16 bit, 5 chips, 2x performance
1992 AA@28MHz, 32 bit, 5 chips, 4x performance
1994 AA+@57MHz, 32 bit, 2 chips, 8x performance
1995 68k-SoC@57MHz, 32 bit, 1 chip, 8x+ performance

C= was scrambling to catch up at the end but they should have been on a 2 year upgrade plan from the beginning and that is roughly what I showed with the Amiga product plan after accepting the Ranger chipset. Rejecting Jay Miner's Ranger chipset also rejected his vision and guidance for Amiga chipset development which appears to also be about a 2 year chipset upgrade plan but from the beginning. The saddest part about it is that Jay worked on the Ranger chipset of his own initiative without being told to and was effectively told to stop and the chipset buried so deep that engineers like Dave Haynie in West Chester knew little about it.

Jay tried to put the Amiga on a 2 year chipset development plan from the beginning and C= tried to switch to a 2 year chipset development plan at the end so I consider it feasible and desirable to stay competitive. It was "highly optimistic" with C= upper management because history paints a different picture. C= had financial problems shortly after acquiring the Amiga and at the end but chipset development from 1988-1991 when the Amiga was more successful was lame too. The lack of R&D investment for a technology business is a clear sign of gross mismanagement.

agami Quote:

Here you have omitted ECS, which I agree would be a waste of engineering time and sand, in a Ranger world. And with the AA+ delivered in its stead, one has to wonder what kind of games, productivity and creative software, and hardware peripherals it would engender that could've seen it as a more legitimate threat to Apple's ecosystem: Potentially boosting the Amiga platform from 5% global market in 1991 to the 10% occupied by Apple, and essentially switching places.

The Amiga on release in 1985 was initially higher performance, more capable and higher end yet cheaper than the Apple Mac which is a major "value" threat. The Mac was incrementally improved over time while the Amiga technology practically stood still. The big game changer for the Mac was when it had 256+ colors and VRAM making the graphics faster and more colorful than ECS could provide. C= then had no high margin high end Amiga but all they seemed to care about was having a high volume low margin C64 replacement. The Ranger chipset would have been a game changer for the Amiga and likely closed the door on the Mac by having more colors and graphics performance earlier. Follow that up with an earlier AA+ and it is easy enough to believe that the Mac may have been gone with Apple not worth saving by Microsoft. Much of the Mac market would have gone to the Amiga including desktop publishing to go with the desktop video market. The Amiga hardware could have been the value play for desktop workstations as a better integrated chipset would have improved the value of the Amiga 3000UX by making it significantly cheaper and better whether or not they were able to sign the licensing deal with Sun.

agami Quote:

It's like that joke where one of the people running away from the bear stops to switch their shoes. The goal is not to outrun the bear, it's to outrun the the other person. Your bullish view extends all the way to the turn of the millennium. Which of the products do you see generating enough revenue/net profit to stave off the bankruptcy? Or does Microsoft step in, given Amiga's #2 position, and Apple going bankrupt earlier?

Ideally, Atari needs to be taken out sooner with better marketing and the Amiga 300 console (console hurts Atari even though it would likely not be a big initial success for C= selling the console at near cost). Then you never allow Apple to get their foot in the door of the high end market by using better chipsets and higher performance product offerings. C= needed to find some different people for advertising, U.S. marketing and educational marketing where they were getting destroyed by Apple. C= could have sold non-core assets and done more licensing and partnering to raise cash and reduce costs. C= could have been forced into bankruptcy shortly after buying the Amiga but their tech pipeline looked promising so creditors negotiated but it looked neglected and years behind at the end so they pulled the plug. C= upper management knew they botched the Amiga and that it was too late to recover. No big businesses stepped in to buy the Amiga technology because it was obvious that it had fallen too far behind. In a different time line, don't make the same mistakes. It all starts with C= throwing the partially developed Ranger chipset away in 1986 based on VRAM being too expensive instead of asking, can we make VRAM optional, can we have an 8th bit plane pointer for EHB mode with 256 colors while only using 128 color registers, can we have a better HAM mode (HAM8 was developed later but may be possible with the 8th bit plane) and how can we double the chipset clock speed for x4 chip memory performance vs OCS?

agami Quote:

While I do agree that the 060 had legs which it never got to fully stretch, in the 2000s C= (or whoever is making these Amigas) would've needed a 64-bit processor to stay competitive. Lots of options, but none that feel quite right.

Sony
2000 PS2 32-bit in-order MIPS CPU
2006 PS3 64-bit in-order PPC CPU
2013 PS4 64-bit OoO x86-64 CPU
2020 PS5 64-bit OoO x86-64 CPU

Nintendo
2001 Gamecube 32-bit OoO PPC CPU
2006 Wii 32-bit OoO PPC CPU
2012 Wii U 32-bit OoO PPC CPU
2017 Switch 64-bit OoO ARM CPU

Microsoft
2001 XBox 64-bit OoO x86-64 CPU
2005 XBox 360 64-bit in-order PPC CPU
2013 XBox One 64-bit OoO x86-64 CPU
2020 XBox S/X 64-bit OoO x86-64 CPU

Nintendo didn't use a 64 bit CPU until 2017 and then there isn't really a choice with ARM except for the small embedded CPU cores using Thumb encodings which are not powerful enough for a console. The Nintendo Switch OS is based on the OS for the Nintendo 3DS which used an older 32 bit ARM CPU. Hackers have discovered info on the Switch OS.

https://en.wikipedia.org/wiki/Nintendo_Switch_system_software#OS Quote:

Notable findings include that the Switch operating system is codenamed Horizon, that it is an evolution of the Nintendo 3DS system software, and that it implements a proprietary microkernel architecture. All drivers run in userspace, including the Nvidia driver which the security researchers described as "kind of similar to the Linux driver". The graphics driver features an undocumented thin API layer, called NVN, which is "kind of like Vulkan" but exposes most hardware features like OpenGL compatibility profile with Nvidia extensions. All userspace processes are sandboxed and use Address Space Layout Randomization (ASLR), a computer security technique involved in preventing exploitation of memory corruption vulnerabilities. Nintendo made efforts to design the system software to be as minimalist as possible, with the home menu's graphical assets using less than 200 kilobytes. This minimalism is meant to improve system performance and launch games faster.

The Switch OS sounds more than a little like the AmigaOS. I wonder if they use 32-bit Thumb code for faster loading of smaller programs and a memory savings. Similarly, the Raspberry Pi OS, and TwisterOS which is based on it, more commonly use 32-bit versions on RPi hardware for better compatibility and lower memory usage. I recall a 64 bit version of a RPi OS using 30% more memory than a 32 bit version which is not good for low cost embedded use or a console. With everything else equal, a 64-bit OS is usually slower than a 32-bit OS. With similar resources, a 32-bit CPU is higher performance most of the time for general purpose use but the 64 bit CPU is much faster for a few algorithms. Certainly for small footprint hardware, 64 bit is not so important and may be detrimental. It helps if the 64-bit ISA has good code density, where ARM AArch64 is mediocre, but 64 bit pointers are always a performance impediment. Higher end computer markets need 64-bit CPUs to address more than 4GiB of memory which C= would have needed to address but ARM didn't come out with AArch64 until 2011.

C= had plenty of time to become a technology powerhouse before opportunities opened to buy Motorola's chip division. The first was in 2003 when Motorola decided to sell the division but ended up doing an IPO of the division as Freescale instead. Private equity firms bought out Freescale in 2006 and loaded up its debt which nearly forced a bankruptcy in 2008-2009 during a financial crisis which opened up another possible discount purchase opportunity. The article below discusses the Freescale history and creative debt handling in order to avoid bankruptcy.

https://www.dallasnews.com/news/texas/2010/08/22/chip-maker-freescale-semiconductor-s-taken-drastic-steps-to-make-a-dent-in-its-debt/

C= may have been able to create a 64-bit 68k ISA and add it to the 68060 themselves. A healthy C= likely could have poached Motorola chip architects or hired others if they didn't have good enough ones. The 6502 is pipelined not that MOS/CSG was doing much to improve it which happened at Western Digital instead but we are talking about a reformed C= under better management. We are no longer talking about minor improvements to the 68060 but it may be possible to make the 68060 64-bit without a full redesign. The data bus needs to support 64 bit (perhaps with selectable 32 or 64 bit width allowing to choose cheaper memory or higher performance), the memory controller needs to be integrated and support SDRAM when it comes out, the 4 bytes/cycle instruction fetch needs to be expanded for performance and the internal RISC encoding needs to be widened to execute more powerful instructions with larger datatypes. The 68060 has very good performance potential for an in-order CPU core design but performance options were balanced with low power for embedded use. Eventually a 64-bit OoO 68k CPU would be needed for the high end as well but a good in-order CPU is valuable for the low end as can been by the perhaps still most popular CPU in the world ARM Cortex-A53 and by often low power in-order cores being used with high performance cores in DynamIQ (formerly called big.LITTLE) configuration for background task. The newest Intel CPUs also use what they call E-cores for background tasks but these cores are actually very powerful OoO cores which they claim maximizes performance/W. Lack of a powerful, small area and low power in-order x86-64 CPU core means x86-64 is not able to scale down anyway. This is a missed opportunity as in-order CISC CPUs have an inherent performance advantage over RISC in-order CPUs and can even outperform some limited OoO RISC CPU cores.

agami Quote:

I do think a CD32+ in 1992 would've been an excellent Doom and Doom II console. And a game like that would be a system seller. But I think the CD32++ would've needed to flex its expansion capabilities to get a Quake port.

That's true. Quake uses enough floating point that software floating point was challenging. Motorola didn't leave much of an option until the 3.3V 68060 as the 5V 68040 ran too hot for a console and the 3.3V 68040V didn't have a FPU. There are obviously options with a license and close relationship with Motorola but it would be tough to keep up with the PC clone desktop spec. At least x86 CPUs ran hot like the 68040 keeping them from being competitive in the console market. The N64 CPU had a powerful MIPS CPU with partial floating point support (fraction and exponent still needed to be calculated separately) and the Saturn has no CPU floating point support that I'm aware of but they received playable albeit significantly downgraded Quake ports compared to PC clones.

Quake - N64 vs Saturn: In-Depth Analysis | White_Pointer Gaming
https://www.youtube.com/watch?v=FougzBclukc

The Amiga version of Quake is mentioned in the video. My 68060@75MHz Amiga with 3dfx Voodoo 3 or 4 card looks much better playing in 512x384x16 than these console ports. It helps for the 68060 to have a FPU even if my CPU is clocked significantly lower and has fewer DMIPS, at least on paper, than the N64 CPU. I wonder how well a PPC version of Quake runs on the A1222 without recompiling for the bastard FPU. It has a much higher clock speed and more CPU performance than these old CPUs but trapping all the FPU instructions with no FPU registers and having to use already used integer registers makes the trapped missing 6888x instructions look efficient on the 68040 and 68060. The A1222 is likely better off with software floating point compiled versions of software which is not at all true on the 68040 or 68060. Good integer performance is general purpose and gives options at least.

Last edited by matthey on 07-Oct-2023 at 12:17 AM.

@matthey

Quote:

matthey wrote: C= had a "2-year new product/major upgrade" plan from AGA on, after it was too late. The following data is from the C= Post Bankruptcy doc.

Getting into the 2-year cadence from 1992 was definitely late, if not already too late.

According to the article linked below, the cracks were revealed at the end of Commodore's fiscal 1991/92, where they were only able to eke out a profit of 6.4%. That's borderline FMCG territory.
They followed it up with a poor Christmas '92 performance, defaulting on a $33M loan, and posting a net loss in fiscal 1992/93, and were literally laying all their hopes on the Christmas '93 season.

They may have had better odds in Vegas, than getting that dumpster fire under control in 1993.

https://www.washingtonpost.com/archive/business/1993/06/21/commodore-is-hoping-for-some-christmas-cheer/8df758f2-5de4-4645-8a7b-2ac02659370a/

When they purchased Amiga, they appeared to be oblivious to the fact that the key asset was the acquisition of the talent pool.

_________________
All the way, with 68k

agami Quote:

Getting into the 2-year cadence from 1992 was definitely late, if not already too late. According to the article linked below, the cracks were revealed at the end of Commodore's fiscal 1991/92, where they were only able to eke out a profit of 6.4%. That's borderline FMCG territory. They followed it up with a poor Christmas '92 performance, defaulting on a $33M loan, and posting a net loss in fiscal 1992/93, and were literally laying all their hopes on the Christmas '93 season. They may have had better odds in Vegas, than getting that dumpster fire under control in 1993. https://www.washingtonpost.com/archive/business/1993/06/21/commodore-is-hoping-for-some-christmas-cheer/8df758f2-5de4-4645-8a7b-2ac02659370a/

Some old articles are time capsules. Indeed, the outlook for C= was bleak and it is difficult to turn around a big ship.



The article has some inaccuracies though. The Mac was using the same "unique" Motorola CPUs as the Amiga and C= had Intel based PCs but sales fell off a cliff in 1993. The C64 division had been in a steep decline before that. Together, the smaller C= PC clone division and C64 division revenue likely declined over $300 million dollars in 2 years and I expect they had worse profit margins than the Amiga.

Division 6/92 6/93 6/94est (Revenue in millions)
Amiga 575 350 270
PC 220 220 30
C64 115 20 0

It's interesting that Amiga sales had been going up from 1989-1991 while PC clone sales declined but then PC clone sales started to rise in 1991 and replaced the Amiga in 1992.




The Amiga had a chance to impress from 1989-1991 but 1990 68000+ECS vs 386+SVGA wasn't enough. Even 1992 68020+AGA vs 486+SVGA wasn't enough although the CD32 was more competitive as a console due to being low power and low cost. The Amiga had some redeeming value as a budget PC but quickly turned into obsolete. The PC clone cliff in 1993 was bad for manufacturers but it was good for consumers bringing cheaper PC hardware and x86 CPUs.

Apple had trouble a few years later after their PPC launch in 1994.



Customer loyalty takes some time to decline as unhappy customer reviews filter out into the public. For Amiga, it was the Amiga 68000+ECS which was an upgrade that wasn't worth the upgrade for many customers considering the minimal feature gain and compatibility lost. For Apple, the lower cost PPC machines like the Performa 5200 with PPC 603 soiled their reputation due to poor performance and bugs. While higher performance Macs with large PPC CPU caches initially had good performance as was common for early RISC CPUs, Intel x86 CPUs were gaining performance faster than PPC Macs with CPUs using shallow pipelines and too large of L1 caches to clock up (large L1 caches are slower to access and L2 caches used too many transistors at the time). Apple nearly went bankrupt too. It was the iPod, iPhone and iPad in 2000+ that made them into the powerhouse they are today.

agami Quote:

When they purchased Amiga, they appeared to be oblivious to the fact that the key asset was the acquisition of the talent pool.

All the overpaid suits at C= were not half as valuable as the unassuming and unusual free thinkers at Amiga Corporation. It's too bad there wasn't more communication and cooperation between Amiga Corporation and C=. There are plenty of "what ifs" that could have turned out different for the 68k Amiga.

@matthey

Quote:

matthey wrote: Jay Miner didn't have the go ahead to make prototype Ranger custom chips... The most important point which you seem to miss is the spec.

What spec?

Quote:

The 68020 and 68030 compatibility means it wouldn't take much to upgrade to the 68030 which should have been after the stock of 68020s ran out. The CPU could have been on the CPU card but there is a small increased chance of problems with the contacts (corrosion or inserting/removing). The AmigaOS was not using the MMU so that was not a major factor.

When the A2000 was designed 68020's were very expensive. A considerable amount of design effort would be required to add it, which meant even more cost plus delays and possible hardware bugs. The 68000 was practically free, guaranteed to work, and 100% compatible with all existing software. Many users would be quite happy with the power of the 68000 for several years to come. And of course the A2000 had the CPU slot for if/when they needed more grunt in the future.

In the original A2000 you had to remove the 68000 when installing a CPU card. On the B model the 68000 was left on the motherboard and merely disabled. This allowed you to 'have your cake and eat it too'. The CPU card could easily be disabled on boot and the onboard 68000 switched in for stuff that wasn't compatible with whatever CPU you had (which might be an 040, 060 etc.). When running on the 68000 the A2000 was very compatible with both the A1000 and A500, so you still play all those non-dos games that hit the hardware. In effect you had an A500 built in that was only one switch or keystroke away.

That was not the case for the A3000 with its built-in 030. Some stuff wouldn't work no matter how hard you tried. I guess that was a good thing because it stopped me from wasting my time playing games.

Quote:

C= was better at providing programming guidelines later. They didn't even provide adequate programming documentation early which resulted in less Amiga software and slower Amiga adoption.

Early on the OS was still evolving. I reckon the documentation was 'adequate', but developers had a lot of trouble handling the complex hardware and multitasking environment.

When I got my A1000 I was keen to get into programming it. I had the Hardware Reference Manual but wanted to do stuff 'legally' through the OS. I bought an Amiga magazine which had an article on how to open a screen and draw stuff in it. 'Great', I thought, until I looked at the code and saw that it kicked out the OS and poked the hardware registers. I didn't want that! So I spend a year learning about all the OS functions and how to access them from assembly language, before writing any of my own code.

I read all the documentation I could get my hands on, including the RKMs and books on programming the Amiga. But I had enough experience with previous machines to know that some things like self-modifying code were pure evil. Problem is back then many coders were cowboys who did whatever worked no matter how bad it was, in the quest for greater efficiency or simply because they didn't know any better. And they brought their bad coding practices with them to the Amiga.

Quote:

Sure, upgrading was as important in 1985 but then Moore's Law kicked in and kicked C='s behind.

Moore's law was kicking everybody's behind. One thing that really annoyed me about that era was how just as you got to know an architecture something new came out and you had do it all over again. Software developers had to get stuff out in a hurry before the machines they were targeting became redundant. I made the mistake of developing a game for the Sega SC-3000, which only lasted 3 years - and I started in year 3.

The Amiga deserved better. It deserved to have its architecture preserved for as long as possible. Even in 1993 - after AGA machines came out - developers were still getting more out the A500 that many thought possible.

Quote:

Self modifying code was legal on the 68000 and many programmers had no familiarity with a 68020 to know better. The "move.w SR,EA" instruction that became supervisor only on the 68020 is also a problem but that is partially Motorola's fault.

Just because something is 'legal' doesn't mean you should do it. Self-modifying code was considered a 'necessary evil' on some 8 bit CPUs like the 6502, but was otherwise discouraged - for good reason. For example I wanted to put a Spectrum music player into ROM for the Aquarius, which was a pain because it was full of unnecessary self-modifying code, with zero documentation about it in the source code.

It's sort of understandable that Motorola missed this one, since you wouldn't think merely reading the status register would be a privilege violation. However nobody should have using the "move SR,EA" instruction in normal application code anyway. Unfortunately once again some coders were bringing their bad practices to the Amiga.

Quote:

I agree that the majority of upgrade problems were not due to the CPU. Many problems were due to poor programming but upgraded 68020+Ranger hardware would have been useful for testing.

People were already experimenting with the 68020 for raytracing, mainly because the 68881 did not operate efficienctly with the 68000. I don't think that is enough reason to put it on the motherboard.

You mentioned Moore's Law. The rapid advances in CPU technology meant that the 68020 would soon become obsolete. The 68030 was introduced in the same year as the A2000, at a lower price than the 68020 was. Computer manufacturers have to preorder bulk quantities of chips to get a good price and ensure supply. Imagine Commodore purchasing a large quantity of 68020's, only to see the 030 become cheaper before they got the A2000 out the door!

Quote:

The PC world requires way more kludges than the Amiga. Motorola and Jay Miner deserve credit for creating and choosing the 32 bit ISA 68k for the Amiga. In a sad twist of fate, the ugly and kludgy PC lives on while the beautiful and good 68k is dead. All because IBM chose the vastly inferior 8088 instead of the futuristic 68000 or we would be using the 68k today.

Yes, but in the end it didn't matter how kludgy the PC hardware was. Most People were buying computers to run software, not to be awed by the beauty of the architecture. The business world was desperate for IBM to make something for them so they didn't have to worry about whether they made the right choices ("Nobody ever got fired for buying IBM"). The fact that the PC was a turd didn't bother them. It was made by IBM so it had to be good - and eventually it was.

The only really 'good' thing about the PC was that it was 'open source', which allowed clone manufacturers to jump on the bandwagon (the last one they would aver have to) and make a killing undercutting IBM. By the time IBM realized their mistake it was too late. Imagine if they had instead led with well protected IP like they did with the PS/2 line. Since the machines couldn't be cloned the industry would have to settle on something else, and by 1990 IBM and their 'PC' would have been history.

@matthey

Quote:

matthey wrote: Some old articles are time capsules. Indeed, the outlook for C= was bleak and it is difficult to turn around a big ship. The article has some inaccuracies though.

One inaccuracy hidden in that chart is that Commodore went bankrupt in May 1994, so the values for 1994 only represent 3 months of 'normal' operation.

Quote:

The Mac was using the same "unique" Motorola CPUs as the Amiga and C= had Intel based PCs but sales fell off a cliff in 1993. The C64 division had been in a steep decline before that. Together, the smaller C= PC clone division and C64 division revenue likely declined over $300 million dollars in 2 years and I expect they had worse profit margins than the Amiga.

And they weren't the only ones hurting. The PC was eating everything. Why? Because it was going mainstream, and the general public was not interested in having something different. Everybody had heard about how difficult computers were to learn and maintain, and they didn't want anything that could make it worse. The name of the game was 'compatibility' and the PC had positioned itself as the one that was 'compatible'.

The Amiga could have been the most awesome computer possible for a ridiculously low price, and it still wouldn't have survived. Of course in reality it couldn't be that so it was surely doomed. But I don't care. Actually I prefer it that way. Despite all its missteps Commodore still managed to produce awesome machines that were cheap and popular enough that I got to own some of them. Because Commodore didn't churn out new models every 5 minutes and didn't survive past 1994, the Amiga has maintained its character right up until today. No other platform has managed that. The others either morphed into something quite different (PC, Mac), or died and became retro curiosities. It even survived efforts to destroy it from within (NG 'Amigas' and OS4).

Quote:

All the overpaid suits at C= were not half as valuable as the unassuming and unusual free thinkers at Amiga Corporation.

I disagree. Without the 'overpaid suits' at Commodore, the Amiga would have sunk without trace. The 'free thinkers' at Amiga corp were incapable of turning their dreams into reality. They needed those 'suits', and Jay Miner as good as said so (he said they did a wonderful job of helping realize the A1000). Not to say that Commodore was perfect - far from it - but they were there when Amiga corp needed them because of what they were. Without Gould and his money, Commodore would not have existed. Without Jack's aggressive marketing strategies, they wouldn't have become a leading home computer manufacturer. Without a willingness to enter new markets with 'flawed' designs, they wouldn't have created the great machines that they did.

Last edited by bhabbott on 09-Oct-2023 at 12:33 AM.