@OneTimer1

Quote:

OneTimer1 wrote: You can always play the "What If Game" What if C= had found a way for CD32 marketing What if C= could have sold it on Christmas in the USA (patent issue) What if C= would have lowered the price What if C= would had AAA titles for the CD32 What if C= would have known how to subside the CD32 price via games. What if C= had the money and know how to do everything right.

'What if's' can go many ways. 'What if' there wasn't a downturn in the PC market in 1991? Hiring lots of PC engineers might have been a genius move. Commodore might make a killing on PCs, keeping Bill Sydnes busy and leaving the Amiga team alone to make what they wanted. With plenty of money coming in the Amiga engineers would able to realize their AAA dreams. Amigas would be made in the same factory as the PCs and share a lot of the technology. The A1200 and CD32 wouldn't be necessary. Soon Commodore would be making 'NG' Amigas with PPC or even Intel CPUs inside, with PCI bus and using PC video and sound cards.

Some Amiga fans would have loved that, but I think we would be poorer for it. In the actual world Commodore managed to maintain the Amiga's essence right to the end, stopping just before they would have begun bastardizing it with a different CPU etc. Think about how many uniquely different Amigas Commodore produced which are still compatible with each other, and compare them to typical boring PC developments or orphan consoles. The Amiga lineup that Commodore produced gave us plenty of variety for our retro hobby without splitting the community (can't say the same for PPC 'Amigas' but that wasn't Commodore's doing).

'What if's' can be fun, but we shouldn't let them consume us. I'm getting back onto my A1200 right now (literally) to continue working on the app I've been developing for several years. Need to wrap it up ASAP so I can start on new projects!

@bhabbott

Quote:

Commodore managed to maintain the Amiga's essence right to the end, stopping just before they would have begun bastardizing it with a different CPU etc. Think about how many uniquely different Amigas Commodore produced which are still compatible with each other, and compare them to typical boring PC developments or orphan consoles.

I totally agree! The C= lineup we got including the A4000T, was the complete encapsulation of Jay Miner's vision. The Amiga enabled home flight sims and animation just like he intended. It even led to Virtuality (Amiga VR) and the Video Toaster/Scala Workstations! Yes, we didn't get the Ranger chipset nor the AAA chips but the upcoming Hombre would have been a different beat with limited to no compatibility! We definitely got the best timeline!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

Kronos Quote:

9 million Dreamcast, 13 million WiiU neither considered a success.

The Sega Saturn initially outsold the PS1 and sold over 9 million units but was considered a failure like the Dreamcast would be later. Sega bet and spent big on the Saturn and Dreamcast. The SegaCD and 32X were cheaper add-ons and much smaller bets. The SegaCD and 32X were considered failures compared to expectations but the SegaCD may have been financially break even if not profitable as I expect for the CD32.

Kronos Quote:

So in short: CD32 made had no market in Europe and couldn't be sold in the US due to the patent issue making everything spec an afterthought.

There was a console market in Europe but it was small. The Amiga CD32 outsold the SegaCD in the UK. I believe the CD32 was the right gaming device to finally penetrate the North America market but it would have been challenging with limited distribution channels and Sega Genesis popularity boosting the SegaCD here (Sega had 43% of the US gaming market by $). The SegaCD was weaker hardware with only a high clocked 68000 and a single speed drive. The Amiga CD32 could have taken market share and built the Amiga reputation with a price around $250 USD. I do not expect it would have surpassed the popularity of the budget Genesis and SNES consoles though.

Hammer Quote:

68060 doesn't have the front end design to mitigate the gap between multi-Ghz CPU vs external memory performance.

The 68060 was a better CPU than most of the console CPUs. The 32-bit data bus and 32-bit memory was the standard for not just the embedded market but the console market for years after Commodore committed financial suicide. The Apple Pippen PPC 603 with a selectable 32/64 bit data bus used a 32-bit data bus. The PS1 used a 32-bit data bus.

https://retrocomputing.stackexchange.com/questions/13533/how-wide-were-the-ram-chips-in-the-playstation-1

Even the 1996 N64, marketed as the world's first 64-bit gaming system with a 64-bit MIPS CPU, used a 32-bit data bus. The N64 specs were more desktop like with a 64-bit MIPS CPU at 93.75 MHz, 16kiB I-cache+8kiB D-cache, 4 MiB of memory and a unified memory system. The 68060 would have been a better choice as the 64-bit support and large instruction cache was unnecessary and wasteful.

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

The console's main microprocessor is a 64-bit NEC VR4300 CPU with a clock rate of 93.75 MHz and a performance of 125 million instructions per second. Popular Electronics said it had power similar to the Pentium processors found in desktop computers. Except for its narrower 32-bit system bus, the VR4300 retained the computational abilities of the more powerful 64-bit MIPS R4300i, though software rarely took advantage of 64-bit data precision operations. Nintendo 64 games generally used faster and more compact 32-bit data-operations, as these were sufficient to generate 3D-scene data for the console's RSP (Reality Signal Processor) unit. In addition, 32-bit code executes faster and requires less storage space (which is at a premium on the Nintendo 64's cartridges).

The 68060 would have made a great console but Motorola/Freescale would try to sell PPC trash like the PPC603 instead. In fact, the next generation Nintendo console used a 32-bit G3 CPU based on the PPC603 design.

bhabbott Quote:

Are you sure about that? The A4000 has a jumper to enable 8MB Chip RAM, which suggests they were thinking of doing the same in the CD32. In any case, the consensus from subsidiaries was that 2MB was the sweet spot, and I agree. It meant the same game would work on the CD32 and a stock A1200. This was a point in favor of the CD32 that other consoles didn't have, and was important given the small user base. Developers could produce basically the same games on both platforms, with CD enhancements that A1200 users could also access if they got a CD-ROM drive. By this time CD-ROM drives were becoming standard on PCs too, so the CD32 could be seen as an entry-level computer without paying for stuff you didn't need for games. All it needed for full computer functionality was a keyboard, mouse, writable storage and comms. Those last two functions could be provided via the internal serial port, which was quite slow - but then how much data did you really need to transfer?

Commodore could have enhanced the CD32 and Amiga 1200 to a 68060&AA+@57MHz SoC and increased the unified Amiga memory to 4MiB so it would have been a more practical N64 spec or desktop spec that allowed easy porting of desktop games.

bhabbott Quote:

Indeed. There's no way that was happening. And it wasn't just the CPU. You would also want plenty of really fast RAM, and the pcb (and therefore the whole console) would have to be considerably larger. You would also need a bigger power supply (not a repurposed Plus 4 psu). The result would be a ridiculously high price for a console even if the CPU itself was cheap. BTW someone recently gave me an Xbox, and I was surprised by how bulky and heavy it was. You turn it on and the hard drive whirs away for quite a while as it boots up. It's practically an entire PC in a box! The PlayStation 2 is much more compact and more convenient. I carry my mine (original larger version) around in a laptop bag with all the accessories. The Xbox would need a larger bag, and be a pain to carry as the main unit alone weighs over 3kg, almost twice the weight of the PlayStation 2. That's the price you pay for making a console from 'conventional' PC parts. A console should be small and light. The CD32 was better than the CDTV in this regard, and still had room for lots of internal expansion. I made an internal floppy drive interface and installed the drive into the right side of the unit. I plugged in a PC keyboard in via an adapter I made, and a mouse, turning it into the equivalent of a stock A1200 with CD-ROM drive - only more compact and 'console-like'. I really regret selling that machine. A CD32 is listed on TradeMe (NZ auction site) right now, and I'm hoping the price won't go too high.

The 68060 is close to working with a stock CD32 power supply.

https://exxosforum.co.uk/forum/viewtopic.php?p=21131#p21131 terriblefire Quote:

Viktor i dont understand... The SMPSU design will be on the TF360.. its 90%+ efficient. Maybe the 360 will work with the stock PSU maybe not but as Mark says .. .just use an ATX if it doesnt.

A die shrink from a 68060&AA+@57MHz 500nm process, like the N64 MIPS CPU at 350nm, would have lowered power and maybe could have allowed a 68060&AA+@114MHz. Even without 3D support, a 68060&AGA CD32 plays many of the 3D PC game ports. The following is another 68060 CD32 video playing PC 3D games Doom, Hexen and Scumm VM games.

nowy80Retro #139, Terrible Fire 360 in Amiga CD32, TF360
https://youtu.be/4htKrCyUAO8?t=310

With the benefit of hindsight, why do you want to keep the Commodore mistakes and handicaps?

@bhabbott

Quote:

Are you sure about that? The A4000 has a jumper to enable 8MB Chip RAM, which suggests they were thinking of doing the same in the CD32.

Refer to Alice's address line limits i.e. A0 to A20.

https://retro-commodore.eu/files/downloads/amigamanuals-xiik.net/Hardware/Specifications%20Alice-AGA%20-%20Manual-ENG.pdf

CD32's development follows the A1200s. It's too late for another Alice modification in 1992.

8MB Chip RAM has no benefits for improving the CPU's math performance.

Fast RAM equipped CD32 improves Wing Commander's performance at a very low price increase.

1990 Wing Commander has made an impression on Jeff Porter.

Quote:

Indeed. There's no way that was happening. And it wasn't just the CPU. You would also want plenty of really fast RAM, and the pcb (and therefore the whole console) would have to be considerably larger. You would also need a bigger power supply (not a repurposed Plus 4 psu). The result would be a ridiculously high price for a console even if the CPU itself was cheap.

1. The lowest price 68040 based product is 68EC040-25, which is similar to Am386-40 wholesale price. Without Dave Haynie's new glue chips, the Amiga can't use 68EC040-25.

You're looking at an Amiga equipped 68EC040-25 around fast 386DX 40 PC prices which has performance vs cost advantage.

68EC040-25's asking price would be difficult for the game console price range.

2. The add-on market for A1200's 314,000 units and CD32's 166,000 units (Jan 1994) is smaller than A500's multi-million install base. Commodore has delayed AGA's install base build-up, hence not being ready against SNES's earlier 1990 install base build-up.

Last edited by Hammer on 26-Nov-2024 at 04:46 AM.
Last edited by Hammer on 25-Nov-2024 at 10:17 PM.
Last edited by Hammer on 25-Nov-2024 at 10:15 PM.
Last edited by Hammer on 25-Nov-2024 at 10:14 PM.
Last edited by Hammer on 25-Nov-2024 at 10:12 PM.

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

@matthey

Quote:

The 68060 was a better CPU than most of the console CPUs. The 32-bit data bus and 32-bit memory was the standard for not just the embedded market but the console market for years after Commodore committed financial suicide. The Apple Pippen PPC 603 with a selectable 32/64 bit data bus used a 32-bit data bus. The PS1 used a 32-bit data bus.

1. The problem is 68060's price and 1994 release date. The cheapest 68060 SKU is 68EC060-50.

2. PS1 CPU/GTE/SCC SoC includes an embedded EDO DRAM controller. Sony has early access to EDO.

68060 wasn't SoC like PS1's implementation.

https://gamesx.com/wiki/lib/exe/fetch.php?media=schematics:sony_playstation_scph-5500-5501-5502-5503.pdf
Page 6 of 99 for PS1's block diagram.

Most of the semi-custom engineering work was done by LSI.

Like LSI, AMD has a semi-custom division for the game consoles market.


Lisa Su factor with AMD's game console CPU business.

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

Lisa Su represented IBM in a collaboration to create next-generation chips with Sony and Toshiba
....
Lisa Su became senior vice president and general manager at AMD in January 2012, overseeing the company's global business units and the "end-to-end business execution" of AMD's products. Over the next two years she "played a prominent role" in pushing the company to diversify beyond the PC market, including working with Microsoft and Sony to place AMD chips in Xbox One and PS4 game consoles.


Lisa Su's game-centric CPU bias led to AMD's return as the gaming PC CPU king (i.e. Ryzen 7 9800X3D) and game console design wins e.g. Xbox One, PS4, PS5, Xbox Series X, Xbox Series S, Steam Deck, PS6 and Next Xbox.

Steam Deck's Van Gogh APU is custom-designed for Valve.

https://duet-cdn.vox-cdn.com/thumbor/0x0:1075x600/828x462/filters:focal(538x300:539x301):format(webp)/cdn.vox-cdn.com/uploads/chorus_asset/file/24934105/cohesive_hybrid_compute_xbox.jpg
The Next Xbox with co-designed AMD GPU. The CPU can be ARM64 or Zen 6. AMD is known to be developing yet another ARM64 clone.

My point, Motorola has a weaker semi-custom business.
---------------------------------

For 1996, Pippen's PPC 603 @ 66 Mhz with Taos 8/16bit VGA-like chipset is largely behind when the "32-bit" game console competition from PS1 and Saturn has texture-mapped 3D acceleration.

My 1996 gaming PC has a Pentium CPU @ 166 Mhz and a 64-bit 66Mhz external bus which is important for software 3D rendering. I used a 64-bit-based S3 Trio 64UV+.

PS1 SOC (CPU/GTE) has 32-bit EDO DRAM.
PS1 GPU (texture mapper, display) has dual port 16-bit VRAM or 32-bit SGRAM.

For pure software rendering with PS1 ports such as Tomb Raider, the Pentium PC has a 64-bit 66Mhz external bus to approximate the entire PS1's memory bandwidth potential.

Pentium FPU can process integer and floating point formats e.g. PC's Tomb Raider port uses the FPU.

Amiga AGA with 68EC060-50 would heavily rely on 68040's older 32-bit external bus on gameplay logic, geometry, and texture processing.

Amiga Hombre (double memory controllers of 32-bit/64-bit VRAM and 32-bit DRAM) is the superior solution for texture-mapped 3D games.

My argument for Pentium's 64bit 66Mhz external bus includes gameplay logic, geometry, and texture processing for baseline software 3D rendering before applying 3DFX Voodoo 3D acceleration. Pentium with S3 Trio 64 is a popular configuration.

PS1 solution is a poor man's Pentium class 3D render.
---------------------------------

Apple Pippen's PPC 603 supplier is IBM. IBM doesn't supply 68060.

https://en.wikipedia.org/wiki/Apple_Pippin
The Pippin platform is based on the PowerPC Platform, a platform designed and supported by IBM and Apple.

With game consoles, IBM has targeted game consoles e.g. Pippin (IBM PPC 603), 3DO M2 (IBM PPC 602), 3DO MX (IBM PPC 604), Xbox 360 (IBM PPE), and PS3 (mostly IBM CELL).

For 3DO MX, Microsoft ultimately acquired the 3DO Systems hardware team (CagEnt under Samsung) and chipset in 1998. IBM offered low-cost PowerPC 604.

For 3DO M2, IBM designed a low-cost PowerPC 602 and offered good prices on it i.e. 3DO M2 has two PPC 602.

IBM tried very hard to gain the games console business.

Last edited by Hammer on 26-Nov-2024 at 04:51 AM.
Last edited by Hammer on 26-Nov-2024 at 01:19 AM.
Last edited by Hammer on 26-Nov-2024 at 01:17 AM.
Last edited by Hammer on 26-Nov-2024 at 01:07 AM.
Last edited by Hammer on 25-Nov-2024 at 11:17 PM.

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

@OneTimer1

Quote:

OneTimer1 wrote: You can always play the "What If Game" What if C= had found a way for CD32 marketing What if C= could have sold it on Christmas in the USA (patent issue) What if C= would have lowered the price What if C= would had AAA titles for the CD32 What if C= would have known how to subside the CD32 price via games. What if C= had the money and know how to do everything right. --- The PS1 that came 2 years later shuck up the whole market, some competitors disappeared, C= would had major troubles if if they would have done everything right on the hypothetical "What If Game"

I bet you're a lot of fun at parties.

Any positive changes to Commodore in a what-if scenario is a change to all other aspects of the market. A stronger Commodore may have dissuaded SONY from entering the market, given that they chose to do so in large part due to Nintendo snubbing them. What if a stronger Commodore actually made that deal with SONY? What if that ended up changing SEGA's attitude toward Microsoft? There might not have been a PS1 nor an Xbox, as we know them.

_________________
All the way, with 68k

@agami

Quote:

A stronger Commodore may have dissuaded SONY from entering the market

Unlikely.

Sony engineer Ken Kutaragi became interested in working with video games after seeing his daughter play games on Nintendo's Famicom video game console.

Quote:

given that they chose to do so in large part due to Nintendo snubbing them.

The issue is about control. Under their agreement, Sony would develop and retain control over the Super Disc format, with Nintendo thus effectively ceding a large amount of control of software licensing to Sony.

Sony is fresh from losing the Beta vs VHS wars, hence Sony has focused on buying game studios and timed exclusive games prior to PS1's release.

The strong game-exclusive Sony platform is hard to beat.

The only Western platform vendor who learned from the game exclusivity lesson is Microsoft.

Apple iPod/iPhone/iTunes has broken Sony's Walkman and optical disc music dominance.

Last edited by Hammer on 26-Nov-2024 at 05:17 AM.
Last edited by Hammer on 26-Nov-2024 at 05:13 AM.
Last edited by Hammer on 26-Nov-2024 at 05:11 AM.
Last edited by Hammer on 26-Nov-2024 at 05:09 AM.

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

@bhabbott

Quote:

What if's' can go many ways. 'What if' there wasn't a downturn in the PC market in 1991? Hiring lots of PC engineers might have been a genius move. Commodore might make a killing on PCs, keeping Bill Sydnes busy and leaving the Amiga team alone to make what they wanted. With plenty of money coming in the Amiga engineers would able to realize their AAA dreams. Amigas would be made in the same factory as the PCs and share a lot of the technology. The A1200 and CD32 wouldn't be necessary. Soon Commodore would be making 'NG' Amigas with PPC or even Intel CPUs inside, with PCI bus and using PC video and sound cards .

The plan for Amiga Hombre's OpenGL target is similar to NVIDIA's.

NVIDIA can't survive with NVIDIA's Shield TV and Nintendo Switch. The 1990s deal with Sega almost bankrupted NVIDIA.

https://www.yahoo.com/tech/nvidia-nearly-went-business-1996-151504041.html
Quote:

Nvidia nearly went out of business in 1996 trying to make Sega's Dreamcast GPU, instead, Sega America's CEO offered the company a $5 million lifeline. (skip) Thus, the conclusion of the Sega-Nvidia contract seemed to be doomed to failure for both parties. Nvidia had spent lots of time and money on R&D and had nothing acceptable to show for it, which put Nvidia CEO Jensen Huang in an unenviable position. He wound up coming clean to Sega about not having their needed graphics hardware...but still asked for payment despite this. And ultimately, Nvidia was still paid for its failed attempt at making the Dreamcast's GPU— thanks to then-CEO of Sega America, Shoichiro Irimajiri. When Huang came to Sega with the unfortunate news, he asked to still be paid in full for the contract, lest their company go out of business. The answer picked by Irimajiri and Sega wound up being a $5 million investment into Nvidia, since Irimajiri had previously met Huang and taken a liking to him. While Irimajiri eventually stepped down from executive positions at Sega (and was briefly president of the whole company, not just the US branch), this investment was cashed out for $15 million afterward, helping keep Sega stable as the company departed the console business.

NVIDIA's NV2 Dreamcast adventure almost bankrupted the company and Sega's extra $5 million lifeline enabled NVIDIA to release NV3, RiVA 128 for the PC market in 1997.

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

Quote:

By 1996, Nvidia was in poor shape financially. It had initially pursued a completely different type of rendering technology called quadratic texture mapping with its first product, the NV1. Then the company had spent a year trying to use its inferior technology to build the graphics chip for Sega's Dreamcast video game console. Sega finally had to pull the plug on Nvidia's project and switch vendors, but was convinced to keep Nvidia alive with a $5 million investment. Nvidia then laid off half of its 100 employees and focused its remaining resources on developing the RIVA 128. By the time the RIVA 128 was released in August 1997, Nvidia was down to one month of payroll. This extremely desperate situation resulted in what remains "the unofficial company motto" today: "Our company is thirty days from going out of business".

Last edited by Hammer on 26-Nov-2024 at 05:33 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:

1. The problem is 68060's price and 1994 release date. The cheapest 68060 SKU is 68EC060-50. 2. PS1 CPU/GTE/SCC SoC includes an embedded EDO DRAM controller. Sony has early access to EDO. 68060 wasn't SoC like PS1's implementation.

The 68060 was no longer a core asset before release in 1994. Motorola/Freescale architects had designed it to be a modular and upgradeable CPU core but Motorola/Fresscale management wanted it to disappear unchanged after milking back development costs in the embedded market. Motorola/Freescale throwing out their beautiful 68k with the bathwater gave an opportunity for a reasonable license after the 68k IP had been very protected after the Hitachi lawsuits. The problem was that Commodore committed financial suicide before they could take advantage. They were more than capable of memory controllers and were planning to turn the Amiga into a 68EC030&AA+ SoC already. A SoC lowers the cost of the CPU+chipset as the production cost is shared between them. Upgrading the CPU to the already developed 68060 was one of the quickest ways to improve competitiveness. The 68060 could have been further upgraded by including the minimalist FPU, increasing the cache sizes and increasing the clock rate past the competition with the deep 8-stage pipeline. Was Commodore smart enough to quickly upgrade the 68k SoC back into competitiveness? Not likely or they never would have fallen so far behind but there were people at Commodore that could see the 68k SoC upgrade path they needed. Reduce the CD32 and Amiga 1200 prices by $100 USD with a SoC while enhancing to AA+ features and the Commodore/Amiga survives.

Hammer Quote:

My point, Motorola has a weaker semi-custom business.

Motorola was better at designing the CPU cores than the SoC I/O. Lack of vision and lack of organization by management was a Commodore problem too.

Hammer Quote:

For 1996, Pippen's PPC 603 @ 66 Mhz with Taos 8/16bit VGA-like chipset is largely behind when the "32-bit" game console competition from PS1 and Saturn has texture-mapped 3D acceleration. My 1996 gaming PC has a Pentium CPU @ 166 Mhz and a 64-bit 66Mhz external bus which is important for software 3D rendering. I used a 64-bit-based S3 Trio 64UV+.

The PPC603 had only a 4-stage pipeline so there is much less of an option to clock it up compared to the 8-stage 68060. A 68060@114MHz would have been more competitive against the Pentium. 40% more integer performance would be like a Pentium@160MHz. Even with a 68060 FPU, and with the 32-bit data bus, the frames per second would be limited compared to a Pentium so 3D hardware would have been necessary for desktop performance but most desktop 3D games would have been playable in a smaller console at a lower power. It probably would have been good enough until adding a 3D chipset to lower cost, lower power and improve performance. The PPC603 only had an 8kiB instruction cache which had the performance of a 2kiB instruction cache for a 68k CPU core. I guess they didn't have the RISC-V research back then so suffered from RISC front end bottlenecks. They figured it out soon enough as the caches of the 603 and 604 were doubled to the 603e and 604e within months but it did not help the Pippen performance and it was not as bottlenecked as the PPC 602 3DO successor would have been.

Hammer Quote:

Amiga AGA with 68EC060-50 would heavily rely on 68040's older 32-bit external bus on gameplay logic, geometry, and texture processing. Hammer [quote] An instruction fetch memory bandwidth savings allows for more data. A 32-bit data bus for consoles was the standard for many years. Consoles needed to get by with cheaper hardware and less power than the desktop. Hammer [quote] IBM tried very hard to gain the games console business.

Nintendo GameCube and Wii customized PPC G3 CPUs were from IBM as well. IBM had practically the whole console market when it was PPC but PPC cores were nothing special. PPC was not an easy game porting target but PPC was not designed for human use despite replacing the most friendly ISA ever in the 68k.

@BigD

Quote:

BigD wrote: I totally agree! The C= lineup we got including the A4000T, was the complete encapsulation of Jay Miner's vision. The Amiga enabled home flight sims and animation just like he intended. It even led to Virtuality (Amiga VR) and the Video Toaster/Scala Workstations! Yes, we didn't get the Ranger chipset nor the AAA chips but the upcoming Hombre would have been a different beat with limited to no compatibility! We definitely got the best timeline!

Jay Miner's vision is in "3DO" with a custom math-co-processor for geometry and texture mapper hardware backed by fast VRAM. 2 million 3DO units were sold, which is more than the C= AGA platform's about half a million units.

3DO developed the M2 with IBM's dual PowerPC 602 CPUs @ 66 Mhz which mirrored PS1's R3000A @ 33Mhz and GTE's @ 58 Mhz or Saturn's dual SuperH2 @ 28.6 Mhz.

3DO M2 GPU is texture-mapped triangle-based hardware accelerated. The low-cost PowerPC 602 includes FPU. 3DO M2's dual PowerPC 602 CPU delivers two FPUs with FMA.

PowerPC FPU's FMA feature beats 68060 FPU and Pentium FPU (reliant on twice the clock speed).

The advantage of the PA-RISC family is the inherent SIMD vector design. Intel quickly added 64-bit SIMD with Pentium MMX, followed by AMD K6 II has 3DNow 64-bit SIMD with FP, and followed by Pentium III's SSE SIMD with FP.

For 3D render workloads, 68060 is outclassed by
Intel Pentium (P5, P54),
Intel Pentium MMX (P55C),
IBM PowerPC 601 (with FMA),
IBM PowerPC 602 (with FMA),
Intel Pentium Pro (P6),
Intel Pentium II (P6 with MMX),
Intel Celeron (P6 with MMX),
AMD K6 with MMX,
AMD K6 II 3DNow,

PowerPC's small cache is a problem with the 68K emulation issue.

I have 68060 rev 1 with TF1260 and I'm correct on my 1996 Pentium 166 purchase. 68060's aging 68040 32-bit external bus is a major problem for software 3D rendering.

Last edited by Hammer on 27-Nov-2024 at 01:42 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 68060 was no longer a core asset before release in 1994. Motorola/Freescale architects had designed it to be a modular and upgradeable CPU core

Mainstream game consoles require semi-custom integration services.

Quote:

Motorola/Freescale throwing out their beautiful 68k with the bathwater gave an opportunity for a reasonable license after the 68k IP had been very protected after the Hitachi lawsuits.

After 68K, Hitachi switched to PA-RISC PA/50 clone (workstation) and SuperH (embedded).

Hitachi joined the Precision RISC Organisation in 1992.
Hitachi PA/50 was released in 1993.

PA-RISC was one of the RISC victims when Pentium Pro (chipset with ECC memory support) was released.

Both Nintendo and Sony continued with semi-custom MIPS CPU service until they both switched to IBM's semi-custom PowerPC services.


Motorola/Freescale had another try with early 68K-based handheld PDA devices and they were displaced by the ARMv4 era. ARMv4 killed Dragon Ball VZ (68000 @ 66Mhz) from the handheld markets. IA-32 Atom, MIPS, and ARM battled in the handheld PDA and smartphone markets until ARM emerged as the winner.


Quote:

@matthey They were more than capable of memory controllers and were planning to turn the Amiga into a 68EC030&AA+ SoC already.

Commodore can do it for the in-house Amiga platform.

http://www.bambi-amiga.co.uk/amigahistory/21helper.txt

Quote:

Dr Helper: It had a microcode processor (very RISC like) built in to do coordinate arithmetic, etc. Much of the line draw arithmetic, clipping, etc., was done in hardware on Andrea... The last couple of years, I reported to the VP of Engineering and was responsible for the architecture of next-generation Amigas. In that role, I performed various studies including one which would have produced a single-chip Amiga (Motorola MC680x0 core, plus AA logic), and early versions of Hombre which contained a SIMD processor for graphics, etc.

The main 3D processing comes from Hombre. Hombre is capable of processing the entire game logic, geometry processing, Z-buffering, texture mapping, and other 3D-related effects e.g. gouraud shading.

"68K AA" Amiga on a single chip is only for backward compatibility and hosting 68K AmigaOS.


Quote:

@matthey, Upgrading the CPU to the already developed 68060 was one of the quickest ways to improve competitiveness.

Reminder, Commodore's Amiga Homber two chips has a 1 million transistor budget.

68060's 2.1 million transistor budget blows Amiga Hombre's 1 million transistor budget.

Hint: Amiga Hombre's 1 million transistor budget is similar to PS1's 1 million transistor budget.

3DO M2 has a larger transistor budget with aggressive discounts from IBM.

Quote:

@matthey, The PPC603 had only a 4-stage pipeline so there is much less of an option to clock it up compared to the 8-stage 68060.

PPC camp is not limited by a single 603 implementation e.g. PPC 603e scaled to 300Mhz
https://everymac.com/systems/by_processor/powerpc603e.html

Unlike 68060, PPC 603 has a fully pipelined FPU.

68060's "8 stage pipeline" is meanless e.g. Alpha 21064 has 7-stage integers and 10-stage FPU pipelines.

68060 started from 0.60 microns to 0.45 microns.

Alpha 21064 reached 200 Mhz with 0.675 microns.
https://www.cpu-world.com/CPUs/21064/DEC-21-35023-21.html

Alpha 21064A reached 275 Mhz with 0.500 micron fab tech.
https://www.cpu-world.com/CPUs/21064/DEC-21-40532-04.html

https://www.cpu-world.com/CPUs/PowerPC-603/IBM-EMPPC603eFG-100%20-%20IBM25EMPPC603eFG-100.html
IBM PowerPC 603 with 0.500 microns reached 100 Mhz.

For the given process tech, 68060 wouldn't match Pentium's clock speed reach.

Reaching high-clock speed CPU design is an art, not just pipeline stages.


Quote:

@matthey, A 68060@114MHz would have been more competitive against the Pentium.

Not true for games like Quake i.e. 100 Mhz 68060 Rev 6 (Warp1260) is like Pentium 75 or Pentium 83.


Quote:

@matthey, 40% more integer performance would be like a Pentium@160MHz.

Prove it with a fixed-point 3D game.

Pentium FPU can process integer workloads e.g. Tomb Raider DOS version.

SysInfo tripped on 68060's 4-byte (32-bit) fetch per cycle from L1 instruction cache limitation. LOL

P5 Pentium can sustain a 32-byte (256-bit) fetch per cycle from the L1 instruction cache.

Quote:

@matthey, Even with a 68060 FPU, and with the 32-bit data bus, the frames per second would be limited compared to a Pentium so 3D hardware would have been necessary for desktop performance

With 3D acceleration, the CPU still has 3D dot game state processing.

DirectX6's geometry pipeline stage is optimized for the CPU side vector SSE and 3DNow.

In 1995, the flagship X86 processor switched to Pentium Pro (P6), pushing the classic Pentiums into the Celeron's price segment.


The CPU load is even greater with raytracing-related BVH boxes and triangles processing feeding BHV hardware-accelerated raytraced GPU.

Quote:

@matthey, but most desktop 3D games would have been playable in a smaller console at a lower power. It probably would have been good enough until adding a 3D chipset to lower cost, lower power and improve performance.

The game console has a low-cost issue.

For 2.x million transistor budget, IBM offers two PPC 602 CPUs with fully pipelined FMA FPU each.

68060 FPU is not fully pipelined with a 2.1 million transistor budget. 68060 FPU doesn't have an FMA feature.

For PPC 602, IBM has its fabs when offering aggressive discounts.

Due to higher costs, NVIDIA kicked out Motorola/Freescale DSP63K (NVIDIA's SoundStorm brand) when MS withdrew the Xbox subsidy.


Quote:

@matthey, The PPC603 only had an 8kiB instruction cache which had the performance of a 2kiB instruction cache for a 68k CPU core.

PowerPC's code is about twice of 68K's. PPC603's 8KB instruction cache is about 4KB CISC equivalent.

PowerPC 603's transistor budget is 1.6 million.
PowerPC 603e's transistor budget is 2.6 million. 16KB i-cache and 16 KB d-cache.

Quote:

@matthey, I guess they didn't have the RISC-V research back then so suffered from RISC front end bottlenecks. They figured it out soon enough as the caches of the 603 and 604 were doubled to the 603e and 604e within months but it did not help the Pippen performance

Pippen's PP603's small cache is a problem for 68K emulation. Pippen has other design issues besides the CPU.

MIPS, Alpha, and PowerPC camps didn't keep up with the AMD vs Intel Ghz race.

Quote:

@matthey, and it was not as bottlenecked as the PPC 602 3DO successor would have been.

3DO M2 runs on native PPC code with zero 68K emulation.

"Japan Inc" deep state tapped Panasonic to drop the 3DO M2 game console adventure.

Last edited by Hammer on 27-Nov-2024 at 12:55 PM.
Last edited by Hammer on 27-Nov-2024 at 04:24 AM.
Last edited by Hammer on 27-Nov-2024 at 04:15 AM.
Last edited by Hammer on 27-Nov-2024 at 04:01 AM.
Last edited by Hammer on 27-Nov-2024 at 03:46 AM.
Last edited by Hammer on 27-Nov-2024 at 02:46 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:

I have 68060 rev 1 with TF1260 and I'm correct on my 1996 Pentium 166 purchase. 68060's aging 68040 32-bit external bus is a major problem for software 3D rendering.

Just switch to a PiStorm or Vampire.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

Quote:

BigD wrote: @Hammer Quote: I have 68060 rev 1 with TF1260 and I'm correct on my 1996 Pentium 166 purchase. 68060's aging 68040 32-bit external bus is a major problem for software 3D rendering. Just switch to a PiStorm or Vampire.

I have PiStorm32 with CM4. I investigated 68060 hype as an alternative "What If" purchase.

68060 wasn't completed since there's a cancelled 68060B project.

_________________
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

Think of CD32 with FMV module which includes 3rd party 40Mhz custom MIPS-X, 24bit display chip, video DAC, local memory, audio DAC and 'etc'.

FMV module uses AGA's genlock feature to play true color VCD content while host AmigaOS provides user control GUI overlay.

Replace the MIPS-X-based FMV module with C= Amiga Hombre's PA-RISC-SIMD-3D @ 50 Mhz to 100 Mhz based module as the full 3D Game Processing Unit as C= APU.


https://ridgeracer.fandom.com/wiki/Namco_System_22
Namco System 22
CPU: 68020 @ 24.5Mhz
DSP: Two Texas Instruments TMS32025 @ 49.152 MHz
GPU: Evans & Sutherland TR3 (Texture Mapping, Gouraud shading, T&L, Z-buffering, and etc).

Amiga Hombre "APU" with AA/68K SoC is like a cost-reduced Namco System 22.

Both Namco System 22 and cost-reduced PS1 can play Ridge Racer.

Commodore has middleware libraries for accessing Amiga Hombre APU from 68K AmigaOS.

The Amiga Hombre APU can run the entire texture-mapped 3D game, while the AA/68K SoC hosts the AmigaOS GUI on standby.

_________________
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:

Reminder, Commodore's Amiga Homber two chips has a 1 million transistor budget. 68060's 2.1 million transistor budget blows Amiga Hombre's 1 million transistor budget. Hint: Amiga Hombre's 1 million transistor budget is similar to PS1's 1 million transistor budget. 3DO M2 has a larger transistor budget with aggressive discounts from IBM.

The 68060 used ~2.5 million transistors with at least 786,432 transistors used for L1 caches.

8kiB_I+D 768,432 (at least as 4-way set associative for both)
logic 1,743,568 (likely less)
---
68060 2,530,000 transistors

The 68060 also used more transistors for the 8-stage pipeline, FPU, branch cache and ATC/TLB cache than most low end embedded like console RISC CPU cores in the 1990s. The N64 64-bit MIPS CPU core was a shift in philosophy toward more powerful and higher clocked cores like the 68060. The N64 CPU core has a 5-stage pipeline, 16kiB-I + 8kiB-D (only direct mapped) and floating point separate fraction/mantissa and exponent instructions (inferior to a FPU) which, with the transistors wasting 64-bit support, is more than half the transistors of the 68060. The 68060 was a more powerful, more efficient and easier to program CPU design for a console that was competitive with desktop specs while saving transistors, power and cost compared to x86 CPUs.

Hammer Quote:

PPC camp is not limited by a single 603 implementation e.g. PPC 603e scaled to 300Mhz https://everymac.com/systems/by_processor/powerpc603e.html Unlike 68060, PPC 603 has a fully pipelined FPU.

The PPC603 FPU is pipelined for single precision FP only. Most FP math for a console and 3D can use single precision FP but C compilers defaulted to double precision FP and lacked support for single precision FP until C99.

Hammer Quote:

For the given process tech, 68060 wouldn't match Pentium's clock speed reach. Reaching high-clock speed CPU design is an art, not just pipeline stages.

The Motorola/Freescale 68060 architects were incompetent but the PPC architects were pros? The 68060@66MHz was being tested and months from production but never sees the light of day because of technical problems?

Hammer Quote:

Not true for games like Quake i.e. 100 Mhz 68060 Rev 6 (Warp1260) is like Pentium 75 or Pentium 83.

A 68060@100MHz would have been a good close to desktop spec with lower power and cost console CPU even without 3D hardware. Watch the videos of Amiga CD32 consoles with 68060s playing 3D games despite far from optimal hardware and software support.

Hammer Quote:

Prove it with a fixed-point 3D game. Pentium FPU can process integer workloads e.g. Tomb Raider DOS version. SysInfo tripped on 68060's 4-byte (32-bit) fetch per cycle from L1 instruction cache limitation. LOL P5 Pentium can sustain a 32-byte (256-bit) fetch per cycle from the L1 instruction cache.

Instruction fetch can use 20% or more of the power for an embedded CPU.

https://ieeexplore.ieee.org/document/1241489 Quote:

Computer system performance depends on high access rate and low miss rate in the instruction cache, which also affects energy consumed by fetching instructions. Simulation of a small computer typical for embedded systems shows that up to 20% of the overall processor energy is consumed in the instruction fetch path and as much as 23% of the execution time is spent on instruction fetch. Therefore it is of key importance to reduce the energy dissipated during instruction fetch. One way to increase the instruction memory bandwidth is to fetch more instructions in each access without increasing the bus width. We propose an extension to a RISC ISA, with variable length instructions, yielding higher information density without compromising programmability. Based on profiling of dynamic instruction usage and argument locality of a set of SPEC CPU2000 applications, we present a scheme using 8 16- and 24-bit instructions accompanied by lookup tables inside the processor Our scheme yields a 20-30% reduction in main memory usage, and experiments show that up to 60% of all executed instructions consist of short instructions. The overall energy savings are up to 15% for the entire data path and memory system, and up to 20% in the instruction fetch path.

The x86 Pentium was not practical for console use and x86-64 OoO successors were too high of power for consoles for several more generations. Also, notice that improved code density in the research paper above lowered main memory usage by 20-30% from reducing instruction memory traffic. As I pointed out earlier, reducing instruction memory traffic leaves more memory bandwidth for data memory traffic, thus reducing the need for a more expensive 64-bit data bus and 64-bit memory. The 68060+ transistor count was low enough that it was practical to double the caches which would have further reduced memory traffic unlike the Pentium until years later.

Hammer Quote:

With 3D acceleration, the CPU still has 3D dot game state processing. DirectX6's geometry pipeline stage is optimized for the CPU side vector SSE and 3DNow. In 1995, the flagship X86 processor switched to Pentium Pro (P6), pushing the classic Pentiums into the Celeron's price segment.

The in-order P55C Pentium with MMX SIMD unit was released after the P6.

1995 P6 (OoO, no SIMD unit)
1996 P55C (in-order with SIMD unit)

The in-order P55C design left more transistors for a SIMD unit and doubling the caches, was lower power and was cheaper to produce despite Intel x86 in-order designs being disappointing including the later Bonnell and Larrabee designs. The 68060 CPU was a much better in-order design that should have allowed the 68k to scale down below x86 into consoles and clock up above them everywhere.

Hammer Quote:

The game console has a low-cost issue. For 2.x million transistor budget, IBM offers two PPC 602 CPUs with fully pipelined FMA FPU each. 68060 FPU is not fully pipelined with a 2.1 million transistor budget. 68060 FPU doesn't have an FMA feature.

CISC FPUs like the 68060 and x86 FPUs can perform mem-reg FPU loads without load-to-use stalls so CISC FMUL+FADD instructions using data in memory can be fewer cycles than RISC FMA instructions. Skipping the FMA rounding gives a different result which is sometimes preferable though. Motorola/Freescale was too busy minimizing the 68k FPU for embedded use to add FMA instructions or anything else.

Hammer Quote:

PowerPC's code is about twice of 68K's. PPC603's 8KB instruction cache is about 4KB CISC equivalent. PowerPC 603's transistor budget is 1.6 million. PowerPC 603e's transistor budget is 2.6 million. 16KB i-cache and 16 KB d-cache.

No.

The RISC-V Compressed Instruction Set Manual Version 1.7 Quote:

The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.

PPC code is more like 50% larger than 68k code.



If the 68k code has 50% better code density than PPC code, PPC would need 4 times the instruction cache size for the same instruction cache performance. Optimized 68k code can be 50% better code density than PPC code but compiled code may average less.

The PPC603 only has 8kiB I+D 2-way set associative caches where the 68060 has 8kiB I+D 4-way set associative caches. The 68060 caches are more comparable to a PPC603e with 16kiB I+D 4 way set associative caches where the 68060 still has an instruction cache advantage while the PPC603e has a data cache performance advantage which is partially offset by the higher instruction cache memory traffic reducing available memory bandwidth for data. The PPC602 has only 4kiB I+D 2-way set associative caches which is more like having a 1kiB 68k instruction cache. The PPC602 cache performance is closer to the cache performance of a 68030 with 256B I+D direct mapped caches than the 68060.

Last edited by matthey on 27-Nov-2024 at 09:30 PM.

@matthey

Quote:

The 68060 also used more transistors for the 8-stage pipeline, FPU, branch cache and ATC/TLB cache than most low end embedded like console RISC CPU cores in the 1990s. The N64 64-bit MIPS CPU core was a shift in philosophy toward more powerful and higher clocked cores like the 68060. The N64 CPU core has a 5-stage pipeline, 16kiB-I + 8kiB-D (only direct mapped) and floating point separate fraction/mantissa and exponent instructions (inferior to a FPU) which, with the transistors wasting 64-bit support, is more than half the transistors of the 68060. The 68060 was a more powerful, more efficient and easier to program CPU design for a console that was competitive with desktop specs while saving transistors, power and cost compared to x86 CPUs.

1. A cost-reduced 3D game-centric 68K would optimize instructions that are beneficial for 3D processing while moving other instructions in the slow microcode path.

Game console transistor budgets are stricter when compared to desktops.

Motorola doesn't provide semi-custom services like LSI or Lisa Su's AMD.



2. Your SPECInt 2006's "same gcc global options" are flawed i.e.

i. X64 CPU is native for both IA-32 and X64 code paths. You haven't factored in instruction issue reduction from X64's vector path.

AVX2's gather instruction can load many 32-bit data elements from a pointer list. This instruction is the baseline standard on PS5. Refer to Linux's X86-64 v3 level.

For 32-bit data elements, SSE has SIMD4 while 68060 is purely scalar. For example, FP32 for game FP geometry processing.

For 16-bit data elements, SSE has SIMD8 while 68060 is purely scalar. Popular for FP16 and INT16 game workloads. Pack math FP16 for speeding up FP pixel shaders.

For 8-bit data elements, SSE has SIMD16 while 68060 is purely scalar. Popular for 8-bit pack math RGBA pixel processing.

ii. ICC and MSVC are used in high-performance games.

You haven't delivered game benchmarks which is Amiga's primary target audience.

iv. At 28 nm process, AMD can pack 64bit Jaguar's transistors nearly rivaling NVIDIA's 32bit A15 area size. Engineering skills matter.

Quake PPC is superior when compared to Quake 68060.

Quote:

@matthey, The Motorola/Freescale 68060 architects were incompetent but the PPC architects were pros? The 68060@66MHz was being tested and months from production but never sees the light of day because of technical problems?

PPC 601 is mostly IBM's design. Motorola's contribution is reusing 88000's external bus.

The first PPC 601 was introduced in an IBM RS/6000 workstation in October 1993 alongside its more powerful multichip cousin IBM POWER2 line of processors.

Quote:

@matthey, A 68060@100MHz would have been a good close to desktop spec with lower power and cost console CPU even without 3D hardware. Watch the videos of Amiga CD32 consoles with 68060s playing 3D games despite far from optimal hardware and software support.

For the game console market, the problem is Motorola's asking price of 68EC060-50, 68LC060-50, and 68060-50.

Dave Haynie's new custom glue chips targeted 68EC040-25.

From Commodore - The Final Years
Quote:

On December 20, 1991, Dave Haynie and Greg Berlin finished their proposed spec for a fourth generation Amiga system architecture. They called the proposal Acutiator, which was a medieval term for a sharpener of weapons. They wrote, “One of the main design goals of the Acutiator architecture is to separate functions into modular pieces. This gives us the flexibility to design low-cost systems which make use of some subset of these components, or to use them all to create a ‘feature enriched’ machine for those customers willing to pay the additional cost.� The engineers wanted to allow the then-new Motorola 68040 processor to work with the next generation of Amigas. And of course, the architecture would work with the upcoming AAA chipset, as well as the more imminent AA. And because AAA was designed to work with different processor families, Haynie wanted his Acutiator motherboard to also handle different processors. Specifically, there were at least three major RISC processor families at that time and he wanted Acutiator to accept these RISC chips. Their architecture required three custom chips: EPIC, AMOS, and SAIL. In cost comparisons, Haynie calculated that the Acutiator architecture would add approximately $125 to a system (including the cost of a 68EC040 chip), resulting in a $300 retail price increase. This was a bargain, considering the user received a significant processor upgrade. Haynie proposed that Commodore should assign Scott Shaeffer, Paul Lassa, and himself to each create the three required gate array chips. He expected prototypes in 7 to 9 months, with the first systems shipping in 1992.

You're looking at $799 to $899 USD Amiga with 68EC040-25 and three new custom chips.

Due to the shared 68040 socket, Acutiator's minor revised custom chips would allow for 1994's 68EC060.

For Xmas 1992, a 486SX-25 class desktop power AAmiga with 68EC040-25 for under $999 USD would be excellent value.

Dave Haynie's mid-priced Amiga with 68EC040-25 would step on Jeff Frank's Commodore PC plans.

Why RISC from Commodore, - The Final Years
Quote:

RISC Ever since the late eighties, when A500 co-designer Bob Welland was still working for Commodore, the company had been investigating RISC processor technology, often in relation to developing its Unix machines. RISC (Reduced Instruction Set Computer) is a CPU design philosophy that stands in contrast to the CISC (Complex Instruction Set Computer) philosophy of the Intel x86 and Motorola 68000 series of processors. With CISC, semiconductor companies added more and more features to their chips in the form of larger instruction sets. This meant CISC chips required more circuitry, resulting in a larger footprint, thus producing less chips from each silicon wafer. This of course made them more expensive to fabricate. Commodore’s engineers wanted to design computers around RISC. Using RISC chips, the processor could theoretically operate faster with the most common opcodes in an instruction set. It would be up to the programmers to use this reduced instruction set to create more complex instructions, in software. RISC also didn’t require as much electricity, resulting in smaller power requirements and cooler operating temperatures. The other factor pushing the engineers towards RISC was that even Motorola was abandoning the 68000 line of processors in favor of RISC. Motorola released the final chip in the 68000 family, the 68060, in 1994. The 68060 was not well adopted by the industry, due to most manufacturers wanting to move onto RISC— although Commodore engineer Paul Lassa briefly considered using the 68060 in a variation of his A4000T. Commodore’s Ted Lenthe began looking into RISC chips with the AAA chipset back in the summer of 1989, specifically the Motorola 88000. But the engineers always balked at concrete plans due to the incompatibility problems a new processor would cause. For his part, Ed Hepler favored creating his own RISC CPU on the basis that Commodore could produce it much cheaper than buying the 88000 from Motorola.

Motorola's asking price for 88000 is NOT at game console level prices.

Motorola doesn't have low-priced 88000 compatible in a similar price segment as 68000 and 68EC020. This is the reason why Commodore selected the PA-RISC clone.

You're not factoring in Commodore's core revenue markets.

Motorola lost the game console market to MIPS and SuperH!

Last edited by Hammer on 28-Nov-2024 at 02:17 AM.
Last edited by Hammer on 28-Nov-2024 at 02:14 AM.
Last edited by Hammer on 28-Nov-2024 at 02:12 AM.
Last edited by Hammer on 28-Nov-2024 at 02:11 AM.
Last edited by Hammer on 28-Nov-2024 at 02:10 AM.
Last edited by Hammer on 28-Nov-2024 at 01:59 AM.
Last edited by Hammer on 27-Nov-2024 at 11:32 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

Besides your non-sense when you talk about Amiga & consoles (and the DSP. But here there's no hope at all, even after all technical & factual articles that I've written), below there are a couple of points that need a technical correction.

Quote:

Hammer wrote: @matthey 2. Your SPECInt 2006's "same gcc global options" are flawed i.e. i. X64 CPU is native for both IA-32 and X64 code paths. You haven't factored in instruction issue reduction from X64's vector path.

And you haven't factored that 68k processors could have evolved exactly as x86. So, by adding SIMD instructions of any type and even adding 64 bit.

You only count x86 evolution over the time when you make such senseless comparisons, but leave the situation crystallized when talking about 68k processors. Basically you stop at the 68060.

"Fair" comparison...
Quote:

AVX2's gather instruction can load many 32-bit data elements from a pointer list. This instruction is the baseline standard on PS5. Refer to Linux's X86-64 v3 level.

That's completely wrong. Again, you talk of things that you've no clue at all, since you never opened an x86/x64 architecture manual in your life neither you've developed something in assembly / machine language.

From the last revision of Intel's manual (just download two days ago to sync my new architecture with the latest changes introduced in the x86/x64 world), I take ONE of the gather instructions:

VGATHERDPD/VGATHERQPD—Gather Packed Double Precision Floating-Point Values Using Signed Dword/Qword Indices
VGATHERDPD xmm1, vm32x, xmm2

Using dword indices specified in vm32x, gather double precision floating-point values from memory conditioned on mask specified by xmm2. Conditionally gathered elements are merged into xmm1.

The instruction conditionally loads up to 2 or 4 double precision floating-point values from memory addresses specified by the memory operand (the second operand) and using qword indices. The memory operand uses the VSIB form of the SIB byte to specify a general purpose register operand as the common base, a vector register for an array of indices relative to the base and a constant scale factor.
[...]
Using dword indices in the lower half of the mask register, the instruction conditionally loads up to 2 or 4 double precision floating-point values from the VSIB addressing memory operand, and updates the destination register

Pseudocode:

VGATHERDPD (VEX.128 version)
MASK[MAXVL-1:128] := 0;
FOR j := 0 to 1
    i := j * 64;
    IF MASK[63+i] THEN
        MASK[i +63:i] := FFFFFFFF_FFFFFFFFH; // extend from most significant bit
    ELSE
    MASK[i +63:i] := 0;
FI;
ENDFOR
FOR j := 0 to 1
    k := j * 32;
    i := j * 64;
    DATA_ADDR := BASE_ADDR + (SignExtend(VINDEX[k+31:k])*SCALE + DISP;
    IF MASK[63+i] THEN
        DEST[i +63:i] := FETCH_64BITS(DATA_ADDR); // a fault exits the instruction
    FI;
    MASK[i +63: i] := 0;
ENDFOR
DEST[MAXVL-1:128] := 0;

@cdimauro


; Perform the gather operation and save the results.
vgatherdps ymm0,[edx+ymm1*4],ymm2 ;ymm0 = gathered elements
vmovaps ymmword ptr [eax],ymm0 ;save des
vmovdqa ymmword ptr [ebx],ymm1 ;save indices (unchanged)
vmovdqa ymmword ptr [ecx],ymm2 ;save mask (all zeros)

vzeroupper
pop ebx
pop ebp
ret
AvxGatherFloat_ endp

Try again.

---------------
The core code is only this for any ROWSxCOLS matrix:

mov ebx, 0
mov eax, 0
.while ebx

Last edited by Hammer on 28-Nov-2024 at 09:23 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:

Hammer wrote: @cdimauro ; Perform the gather operation and save the results. vgatherdps ymm0,[edx+ymm1*4],ymm2 ;ymm0 = gathered elements vmovaps ymmword ptr [eax],ymm0 ;save des vmovdqa ymmword ptr [ebx],ymm1 ;save indices (unchanged) vmovdqa ymmword ptr [ecx],ymm2 ;save mask (all zeros) vzeroupper pop ebx pop ebp ret AvxGatherFloat_ endp Try again.

INDICES != POINTERS.

Go back to the school!

@cdimauro

VPGATHERDD ymm1, (edx+ymm0*1), ymm2 ;The instruction conditionally loads 8 dword values from memory addresses specified by the memory operand (the second operand) and using dword indices.


Try again.

Last edited by Hammer on 28-Nov-2024 at 09:26 PM.
Last edited by Hammer on 28-Nov-2024 at 09:26 PM.
Last edited by Hammer on 28-Nov-2024 at 09:25 PM.
Last edited by Hammer on 28-Nov-2024 at 09:25 PM.
Last edited by Hammer on 28-Nov-2024 at 09:24 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