@matthey

Quote:

matthey wrote: The competition between the 68k Amiga, Atari and Mac wasn't always friendly. Amiga users didn't feel threatened as much by the Mac or Atari PCs as we had the superior hardware, at least until we realized CBM was the bigger threat than the competition.

No, the biggest threat was the PC - and not just to us. The industry settled on the PC in 1981, and from that time on every other platform was a dead man walking. If Commodore was smart they wouldn't have taken on the Amiga at all.

Quote:

Imagine the horror of a Mac fan in 1985 with their black and white display, mono audio and what they thought was a fancy mouse driven GUI and OS when the Amiga came out with hardware accelerated 4096 colors, 4 voice stereo sound and a mouse driven GUI and OS with preemptive multitasking. The first thought had to be that CBM was going to put Apple out of business

Apple themselves were worried. They shouldn't have been though, because the Mac's strength wasn't its hardware or software specs, but the users it was targeting. Jobs understood this.

Quote:

There is the famous e-mail response from Carmack about the Amiga too. Quote: [response from Id software] From jo...@idcube.idsoftware.com Sun Sep 4 02:52 EST 1994 From: John Carmack Date: Sat, 3 Sep 94 11:50:23 -0600 To: G.San...@ais.gu.edu.au Subject: amiga doom The amiga is not powerful enough to run DOOM. It takes the full speed of a 68040 to play the game properly even if you have a chunky pixel mode in hardware. Having to convert to bit planes would kill it even on the fastest amiga hardware, not to mention the effect it would have on the majority of the amiga base. John Carmack

Note the date. The Amiga was already dead. Its user base was dwindling and there was little hope of that reversing. Therefore porting Doom to it wasn't worth the effort. And that wasn't a big deal. We had plenty of other games to play.

People say Doom changed everything, but it certainly didn't for me and my Amiga-owning friends. I used to run it on PCs in the workshop to test them for stability, but the game itself didn't interest me. When Doom finally came out for the Amiga in 1998 I sold it in my shop, but couldn't be bothered installing it on my own Amiga 3000 with 060 and RTG.

Quote:

Quake ports 1996 Linux, SPARC Solaris 1997 Mac OS, Sega Saturn 1998 N64, Amiga

I bought the Quake port when it came out thinking this is it, finally a game that will make good use of the expensive hardware in my A3000. It was a huge disappointment. Not only was it slower than expected, it was boring. I should have bought Doom instead and put more effort into playing it!

Quote:

The problem for consoles was that most still used fixed point integers instead of floating point for 3D (usually no FPU). Software fp is easy but low performance while converting from fp to fixed point is a major undertaking and helps explain why PS1 and Jaguar ports were not released. Desktop PCs had standard FPUs for awhile but older CPUs lacked the FPU performance to run Quake like the 68040.

Quake needed at least a Pentium 75 to get an acceptable frame rate, so there was no hope for any reasonably priced Amiga system. This practice of developing games that only run properly on the very latest PC hardware continues to this day. And for what? I see no evidence that the latest games are any better than stuff we were playing in the 90's.

Last edited by bhabbott on 17-Jul-2024 at 03:46 AM.

@bhabbott

Quote:

No, the biggest threat was the PC - and not just to us. The industry settled on the PC in 1981, and from that time on every other platform was a dead man walking. If Commodore was smart they wouldn't have taken on the Amiga at all.

The Amiga had found its mass market as a good value gaming content creation and easy-to-use game player machine. Amiga's pixel art focus is game artwork content instead of publishing artwork content.

The Amiga doesn't need to copy Macintosh i.e. Commodore needs to focus on interactive entertainment business.

There is no shame in the entertainment business i.e. money is money.

Quote:

Apple themselves were worried. They shouldn't have been though, because the Mac's strength wasn't its hardware or software specs, but the users it was targeting. Jobs understood this.

Steve Jobs is focused on "day job" business users while Commodore should be focused on "after hours" users.

AAA moonshot project is a distraction from Amiga's "after-hours" mass market.

For a $1 billion company, Commodore is spreading itself too thin.

Quote:

Note the date. The Amiga was already dead. Its user base was dwindling and there was little hope of that reversing. Therefore porting Doom to it wasn't worth the effort. And that wasn't a big deal. We had plenty of other games to play.

Strong Commodore national subsidiaries like Commodore UK traded in the entirety of 1994.

NEC's PC-98 is regional in the Japanese market.

In terms of population size and spending strength, you need to combine Germany and the UK to rival the Japanese market.

Quote:

People say Doom changed everything, but it certainly didn't for me and my Amiga-owning friends.

For my school friends and my Dad's workmates in Australia, 3D texture-mapped PC games delivered a different gaming experience, hence the mass switch.

Doom was being previewed in PC game press starting around May 1993.

Quote:

I used to run it on PCs in the workshop to test them for stability, but the game itself didn't interest me. When Doom finally came out for the Amiga in 1998 I sold it in my shop, but couldn't be bothered installing it on my own Amiga 3000 with 060 and RTG.

Doom wasn't a fad in 1998 e.g. Epic Games' Unreal, Baldur Gate, Fallout 2, StarCraft, Thief The Dark Project, Half-Life, Tomb Raider III, Resident Evil 2, Tom Clancy's Rainbow Six, Metal Gear Solid, Age of Empire - The Rise of Rome, Falcon 4.0, FIFA 99, Dune 2000.

Open source OpenRA has support for Dune 2000 and the Amiga has OpenRA port.

Quote:

I bought the Quake port when it came out thinking this is it, finally a game that will make good use of the expensive hardware in my A3000. It was a huge disappointment. Not only was it slower than expected, it was boring. I should have bought Doom instead and put more effort into playing it!

A Tomb Raider port would be better since the PS1 baseline is fixed-point integer math and 68060 has pretty good fixed-point integer math performance.

Quake's victims weren't limited to 68060 e.g. Cyrix 6x86.

PS1's Quake port was refactored for fixed-point integer math.

The Amiga's Quake port was from the PC version that exploited Pentium's FPU strength. Michael Abrash was hired by Intel after Quake PC optimization work.

PocketQuake for Windows CE ARM is another refactored fixed-point integer math version.

68060's weaker FPU caused the Amiga to behave closer to PS1's integer-only processing.


Quote:

This practice of developing games that only run properly on the very latest PC hardware continues to this day. And for what? I see no evidence that the latest games are any better than stuff we were playing in the 90's.

Wrong. Modern PC gaming's core experience is based on the current-generation game consoles' hardware.

A PC with 8-core Zen 2 and RX 6700XT 12GB VRAM would have delivered a core gaming experience that slightly exceeds PS5. RTX 3070/3070 Ti's 8 GB VRAM can struggle with PS5 ports.

PC's "heavy raytracing" promoted by NVIDIA is optional.

For PS5 Pro's 60 CU RDNA 3.5+ (BVH8 assumes doubles the raytracing performance over RDNA 3's BVH4), the PC equivalent would be about RTX 4070 12 GB or RTX 3080 12GB.

Pentium class-era PC games have synced with PS1. For a given hardware generation, PlayStation has a major influence on game design.

Last edited by Hammer on 17-Jul-2024 at 05:08 AM.
Last edited by Hammer on 17-Jul-2024 at 05:02 AM.
Last edited by Hammer on 17-Jul-2024 at 04:55 AM.
Last edited by Hammer on 17-Jul-2024 at 04:51 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

I don't need to. You don't get it. Your list of BOM prices and random SKU transistor counts

They are not random.

Quote:

does not magically yield a solution to the "sidecar A500 doom expansion" and certainly for nothing remotely like the retail price of the game! It doesn't cover the R&D costs, licensing costs, development costs, projected sales return etc. It shouldn't be remotely necessary to explain this.

You don't get it. Commodore owns a silicon fabrication plant and many A500 sidecar solutions come from small 3rd party vendors with weaker economies of scale.

CD32 has Commodore's FMV module example with a relatively expensive $50 MIPS-X-based SOC.

Commodore's FMV module is nearly a standalone small board computer since it doesn't use CD32's A1200 hardware.

Nintendo's involvement is needed for SuperFX. SuperFX has been reused for multiple SNES games, NOT just Doom.

As for your R&D issue, the Super FX chip design team included engineers Ben Cheese, Rob Macaulay, and James Hakewill.

The UK has at least a double record in designing "cheap RISC CPUs" in the market i.e. ARM and ARC. Engineering talent is a big factor.

PS1's CPU was designed by LSI and the GPU was designed by Toshiba. Ken Kutaragi provides leadership to glue many hardware, software, dev kits, and game dev relationship components together to form PS1.

Both Commodore and Sony touched 3rd party MIPS-based RISC CPUs, but only one company is focused on delivering texture-mapped 3D experience.

The summary, Sony delivered superior leadership with razor-sharp focus!

Last edited by Hammer on 17-Jul-2024 at 05:59 AM.
Last edited by Hammer on 17-Jul-2024 at 05:55 AM.
Last edited by Hammer on 17-Jul-2024 at 05:46 AM.
Last edited by Hammer on 17-Jul-2024 at 05:33 AM.
Last edited by Hammer on 17-Jul-2024 at 05:31 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Carmack's statement was not true as even a high clocked 68030 with fast memory is adequate for Doom but it seemed to be effective at discouraging Amiga interest. It may be true that nobody tried to license Doom for the Amiga but Carmack statements likely discouraged it from happening. There never was an official Amiga port either but it was eventually released as freeware and was finally ported to the Amiga.

John Carmack's 1994 statement repeated Commodore's official view on chunky pixels for A1200/A4000.

https://bigbookofamigahardware.com/bboah/product.aspx?id=1604
Quote:

The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

As a US-based company, IDsoftware is not in the business of software patching Amiga's design flaws.


SNES's Doom reverse engineering work was done on the Amiga dev machine and there was SNES Doom source code sitting on Amiga's hard disk, but Nintendo camp is not in the business of helping the Amiga platform.

Last edited by Hammer on 17-Jul-2024 at 06:02 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Wolfenstein 3D.

@Hammer

Absolutely nothing you've just written answers the question:

How much would it cost, factoring in all R&D licensing costs to produce a sidecar "doom cartridge" for the A500 in 1993 capable of running the game acceptably, given the state of commodore.

Your meandering posts of cockwaffle about Nintendo and Sony do nothing towards answering it.

If you don't know (and given it never happend, why would you) it's fine to just say so.

I don't know either but I'm confident it would not be covered by the retail cost of the game.

_________________
Doing stupid things for fun...

@Karlos

Quote:

How much would it cost, factoring in all R&D licensing costs to produce a sidecar "doom cartridge" for the A500 in 1993 capable of running the game acceptably, given the state of commodore.

Refer to Commodore's FMV cartridge example and delete the expensive 3rd party chips.

https://www.commodorefree.com/magazine/vol11/issue98.pdf
Commodore's FMV cartridge has 199 UKP retail cost. FMV cartridge is nearly an SBC due to its near independence from CD32's AGA/68EC020.

$20 DSP3210 is off-the-shelf which doesn't need Commodore's RISC CPU R&D effort.

Commodore's FMV cartridge's $50 MIPS-X-based CL450 SoC @ 40Mhz has the compute power for Doom.

A500's Doom cartridge would need the FMV cartridge's compute and display capability.

$52 for A1200's 2 MB FP DRAM.

$50 MIPS-X-based SoC @ 40Mhz + $52 2 MB FP DRAM is about $102 price.

$50 MIPS-X-based SoC @ 40Mhz needs to be replaced with a cheaper $10 range RISC CPU and off-the-self $20 DSP3210 would do the job.

$52 2 MB FP DRAM + $20 DSP3210 is about $72.


--------------------------
CD32's FMV module has the following:

1. 24-bit DAC (STM's STV8438CV) for 16.7 million colors display. For 256 colors, A1200/CD32 wouldn't need this chip.

2. MPEG-1 decoder from C-Cube CL450, 352 x 240 pixels @ 30hz, 352 x 288 pixels at 25 Hz, pixel interpolation and frame duplication to produce output formats of 704 x 240 pixels at 60 Hz or 704 x 288 pixels at 50 Hz.

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/060803.PDF

CL450 has about 398K transistors with up to 40 MHz. CL450 includes a licensed MIPS-X RISC processor with semi-custom extensions. In quantities of 100K or more per year, the price is less than $50 in 1992.

CL450's MIPS-X RISC processor still has the usual RISC instruction set.

For the Doom cartridge, this CL450 SoC needs to be replaced with a cheaper RISC CPU solution.

3. LSI l64111qc (Digital Audio Decoder, 16-bit DAC). This is not needed for the Doom cartridge.

4. 512 KB local RAM, NEC 423260 DRAM 4Mbit (512 KB) with 80 ns access. Needs FP DRAM increase.

5. Lattice ispLSI 1024-60LJ CPLD, the glue logic. This is not needed for DSP3210's built-in 68020/68030 bus support.

I only have wholesale prices for A1200's 2MB FP DRAM, MIPS-X based CL450 SoC, DSP3210 and SuperFX (ARC).

I don't have the 1992 wholesale price for STV8438CV DAC.

CD32's MIPS-based FMV cartridge's retail cost is approaching MIPS-based PS1's US retail cost, hence you might as well glue PS1 next to A500.

Due to A500's obsolete components, its proposed Doom cartridge would require more components when compared to SNES's Doom cartridge.

Any Doom cartridge add-on must be 256 color capable A1200/CD32 baseline.

Amiga Hombre chipset has a $40 quotation which targets CD32's and A1200's price range.

Motorola's 68K is a dead end for the 1994-1995 era 3D game console's price range which is close to A1200's price range. Motorola was kicked out of the game console market for a reason!

Designing cost-competitive texture-mapped 3D game consoles from off-the-shelf chips is nearly impossible.

3DO M2 has two IBM PowerPC 602 @ 66Mhz CPUs that is specifically targeted for the game console's price range.

Last edited by Hammer on 18-Jul-2024 at 05:59 AM.
Last edited by Hammer on 18-Jul-2024 at 05:39 AM.
Last edited by Hammer on 18-Jul-2024 at 05:28 AM.
Last edited by Hammer on 18-Jul-2024 at 05:23 AM.
Last edited by Hammer on 18-Jul-2024 at 05:12 AM.
Last edited by Hammer on 18-Jul-2024 at 05:09 AM.
Last edited by Hammer on 18-Jul-2024 at 05:06 AM.
Last edited by Hammer on 18-Jul-2024 at 04:53 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

I fail to see the relevancy of the components used in the CD32 FMV module when talking about a sidecar expansion to play Doom for the A500. Saying "we don't need component X" is obvious, because we aren't supposedly making an FMV module.

Saying we need an A1200/CD32 baseline is shifting goalposts. In 1993 they were many more A500 than A1200 in use. The A500 represents the largest installed user base there's ever been.

It sounds like what you are avoiding saying is "we need a nice little RISC CPU, some memory and a cheap VGA framebuffer". Again, this is patently obvious.

_________________
Doing stupid things for fun...

@Karlos

Quote:

fail to see the relevancy of the components used in the CD32 FMV module when talking about a sidecar expansion to play Doom for the A500

You should be aware of A500's edge connector (16-bit data/24-bit address Zorro I 68K-based) is the older variant when compared to CD32's edge connector (32-bit data/24-bit address).

Amitech's A2200 clone's Agent 88 board was able to duplicate A1200's edge connector and A3000/A4000's local CPU slot from CD32's edge connector.

ACA500 has most of A1200's edge connector functions.

CD32 is the max cost-reduced AA3000+ Pandora.

Did you assume Commodore has "high energy" to design a completely new edge connector?

Quote:

Saying "we don't need component X" is obvious, because we aren't supposedly making an FMV module.

CD32 FMV cartridge is a price guide example from Commodore with self-contained high math compute power in the game console's price range in the 1992-1993 date range. CL450 SoC still has the usual MIPS-X CPU instruction set despite being a "MPEG decoder".

CD32 FMV cartridge includes 16-bit stereo audio and 24-bit video DAC separated from CD32.

Do we need 2-channel 16-bit audio in addition to Paula's 8-bit four-channel?

Do we need a separate 24-bit video DAC in addition to A1200/CD32/A4000's ADV101 Triple 8-bit Video DAC? Would you tolerate 64-color EHB Doom?

CD32 FMV cartridge includes 512KB system memory separated from CD32.

CL450 SoC's $50 price is swapped out for $52 2MB FP DRAM.

512KB 80 ns access FP DRAM is about $13 which is close to DSP3210's $20 price.

This is a price estimate.

Quote:

Saying we need an A1200/CD32 baseline is shifting goalposts. In 1993 they were many more A500 than A1200 in use. The A500 represents the largest installed user base there's ever been.

A500 is too old. The "Doom module" for A500 is nearly a complete SBC (small board computer).

Refer to the "Sega X32" addon. https://en.wikipedia.org/wiki/32X

Quote:

It sounds like what you are avoiding saying is "we need a nice little RISC CPU, some memory and a cheap VGA framebuffer". Again, this is patently obvious.

Sure.

_________________
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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: @Hammer I fail to see the relevancy of the components used in the CD32 FMV module when talking about a sidecar expansion to play Doom for the A500. Saying "we don't need component X" is obvious, because we aren't supposedly making an FMV module. Saying we need an A1200/CD32 baseline is shifting goalposts. In 1993 they were many more A500 than A1200 in use. The A500 represents the largest installed user base there's ever been. It sounds like what you are avoiding saying is "we need a nice little RISC CPU, some memory and a cheap VGA framebuffer". Again, this is patently obvious.

I think he's saying that the FMV 'cartridge' for the CD32 gave it a MIPS accelerator that could have been potentially used for other purposes by other software.

aka ala the SuperFX chip for the SNES...



Re: SNES Doom code ... wouldn't have helped Amiga since SNES used the 65816... Should have ported it to a SuperCPU-equipped C64. :) (yes I realize the 3D code was for SuperFX but the SuperCPU is ~6x faster than the SNES' 3.57 Mhz cpu and perhaps it could all run on the SuperCpu... The RAD-DOOM port did a great job degrading the graphics...

@Hammer

Quote:

Hammer wrote: Did you assume Commodore has "high energy" to design a completely new edge connector?

No design done, no "high energy" needed as all these edge connectors are just straight connections to the CPU.

None of this matters as the FMV (or even the naked CD32) were no where near the needed install base to make a special DOOM port viable.

That fact that C= was either dying or already dead when such a port could have been made (killing all potential future growth) also didn't help.

While adding special HW in a module for a game you plan publish for a game console with a 8 figure install might make sense, doing so for any home computer is abeyond brainfart level.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Lou Quote:

I think he's saying that the FMV 'cartridge' for the CD32 gave it a MIPS accelerator that could have been potentially used for other purposes by other software. aka ala the SuperFX chip for the SNES...

Hammer may be suggesting more.

1. Cheaper AT&T DSP hardware using existing Amiga memory is possible for 3D, MPEG decoding and Doom.
2. Hombre could have been used for 3D, MPEG decoding and Doom if a more powerful, flexible and expensive solution is wanted.
3. CBM ignored their organically developed DSP, Hombre and Amiga chipset tech choosing higher cost and more specialized foreign MIPS based tech for FMV hardware.

The FMV hardware MIPS-X CPU is not very general purpose using 24 bit GP registers and a 2kiB instruction buffer instead of instruction cache. More useful is the fast CL450 FMV chip 512kiB or 1MiB DRAM controller with addressable memory from the 68k and possibly the additional and fast memory the 68k needs. I expect CBM went with the 512kiB memory option and the additional memory is probably not added for AmigaOS use by default making it less useful for Doom.

The AT&T DSP option may have been the cheapest but more memory and fast memory is needed for the DSP and Doom. The CD32 is missing hardware compared to the original hardware planned for the DSP. A low bandwidth chip memory only system would have had the DSP competing with the 68k CPU and Amiga chipset for memory bandwidth which already was a problem. The small DSP memory was not a good solution as it requires slow memory data copying overhead. It would be best to add fast memory with a controller and share fast mem between the 68k CPU and DSP only. This requires additional hardware and expense, perhaps more than Hammer considers, but 1MiB of fast mem and a DSP likely would have allowed a semi-playable Doom with a cost low enough to make the hardware standard for all CD32s. MPEG decoding may have been possible but may have required some help from custom hardware.

Hombre may not have been ready yet. The cost for CBM to produce Hombre for their use doesn't include the usual high profit margin included in the price of commodity chips like the CL450 FMV chip. Hombre, like other RISC based CPUs, needed more memory, memory bandwidth and caches than the 68k Amiga, making the total system cost higher. Accumulator architectures like the 6502 and poor code density classic RISC architectures like PA-RISC and MIPS disappeared from general purpose use for this reason. General purpose CPU use needs caches to avoid long memory latencies and this was/is expensive. CBM and Motorola had a competitive advantage with the 68k Amiga cache, memory and memory bandwidth miser but only used it to go cheaper instead of upgrading it to go higher performance like Intel did with inferior x86 technology. The grass is greener on the other side of the fence until the hype and propaganda is dispelled. Either DSP or PA-RISC fixed point 3D hardware would be outdated and difficult to use for general purpose use today but a 68060 with fast memory Amiga was already able to play Doom, Strife, Heretic, Hexen and Quake with simple compiles even though it was designed for the low power embedded market and was never clocked up like a 8-stage pipeline with small caches should have been. With more caches, new silicon and a few more upgrades, I expect a 68060 core would be surprisingly modern and high performance, at least compared to the most popular ARM CPU cores like the Cortex-A53. The SiFive U74 core doesn't have a SIMD unit but outperforms the Cortex-A53 and can play at least Pentium III era games. The 68k ISA would gain performance from using the RISC-V SiFive U74 core design and it is very similar to the 68060 design.

Lou Quote:

Re: SNES Doom code ... wouldn't have helped Amiga since SNES used the 65816... Should have ported it to a SuperCPU-equipped C64. :) (yes I realize the 3D code was for SuperFX but the SuperCPU is ~6x faster than the SNES' 3.57 Mhz cpu and perhaps it could all run on the SuperCpu... The RAD-DOOM port did a great job degrading the graphics...

The SNES Doom code may have helped if the Amiga had a newer AT&T DSP chip (SuperFX chip is based on AT&T DSP1). Then again, a CD32 with fast memory is less of an upgrade than a SNES Doom cartridge and plays Doom without reducing the quality. A CD32 with a 68k CPU upgrade and fast memory is about equivalent to a SNES Doom cartridge DSP, SRAM and ROM upgrade and can play the game as intended. SuperCPU is a CPU and memory upgrade but porting Doom is not easy without a large flat address space. Doom likely never would have appeared on x86 until the 80386 and its large flat address space. Doom requires 4MiB of memory on x86 with relatively good code density while the SNES 65816 CPU has poor code density and only 256kiB of memory total despite a 1990 release. You can bank on any 6502 family conversions being cut down because there is no large flat address space.

@Lou

Quote:

Lou wrote: @Karlos I think he's saying that the FMV 'cartridge' for the CD32 gave it a MIPS accelerator that could have been potentially used for other purposes by other software. aka ala the SuperFX chip for the SNES... Re: SNES Doom code ... wouldn't have helped Amiga since SNES used the 65816... Should have ported it to a SuperCPU-equipped C64. :) (yes I realize the 3D code was for SuperFX but the SuperCPU is ~6x faster than the SNES' 3.57 Mhz cpu and perhaps it could all run on the SuperCpu... The RAD-DOOM port did a great job degrading the graphics...

SNES's Doom source code was created from the Doom engine's map format documentation.

Argonaut's SuperFX evolved into ARC (Argonaut RISC Core) business and its business model is similar to ARM's.

UK has at least two mass-produced "cheap RISC" families.

Like ARM, ARC has evolved into a 64-bit variant as ARCv3. Both ARM and ARC have good code density.

Both ARM and ARC address 65K's slow road map issues.

In 1995, Argonaut was split into Argonaut Technologies Limited (ATL), which had a variety of technology projects, and Argonaut Software Limited (ASL).

In 2009, ARC International was acquired by Virage Logic. In 2010, Virage was acquired by Synopsys, and ARC processors became part of the Synopsys DesignWare series.

ARC have been licensed by more than 200 organizations and are shipped in more than 1.5 billion products per year.

Meanwhile, Commodore Semiconductor Group is dead due to brain-dead leadership.

Last edited by Hammer on 19-Jul-2024 at 12:23 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

The SNES Doom code may have helped if the Amiga had a newer AT&T DSP chip (SuperFX chip is based on AT&T DSP1).

SuperFX is not based on AT&T DSP1. Super FX chip is a little-endian 16-bit RISC processor aimed at 3D.

SuperFX has 16 16-bit general purpose registers (R0 to R15), 13 specific purpose registers and it's pipelined i.e. loading the next instructions as one is executed.

Quote:

Hammer may be suggesting more. 1. Cheaper AT&T DSP hardware using existing Amiga memory is possible for 3D, MPEG decoding and Doom. 2. Hombre could have been used for 3D, MPEG decoding and Doom if a more powerful, flexible and expensive solution is wanted. 3. CBM ignored their organically developed DSP, Hombre and Amiga chipset tech choosing higher cost and more specialized foreign MIPS based tech for FMV hardware. The FMV hardware MIPS-X CPU is not very general purpose using 24 bit GP registers and a 2kiB instruction buffer instead of instruction cache. More useful is the fast CL450 FMV chip 512kiB or 1MiB DRAM controller with addressable memory from the 68k and possibly the additional and fast memory the 68k needs. I expect CBM went with the 512kiB memory option and the additional memory is probably not added for AmigaOS use by default making it less useful for Doom.

CL450 includes an interface with 68K or x86 bus.

CL450 host interface has a 20-bit address and 16-bit data.
CL450 DRAM controller (local frame buffer) has a 10-bit address and 16-bit data.
CL450 is optimized to be coupled with Philips' 68070 CPU (68000-based license clone).

Commodore's FMV module is a #metoo CD-i which has a plug-in MPEG-1 Cartridge for VCD.

Unlike DSP3210, CL450 is not optimized for 68020/68030 32-bit bus.

Quote:

Hombre may not have been ready yet. The cost for CBM to produce Hombre for their use doesn't include the usual high profit margin included in the price of commodity chips like the CL450 FMV chip. Hombre, like other RISC based CPUs, needed more memory, memory bandwidth and caches than the 68k Amiga, making the total system cost higher.

Not correct.

68040's 1.2 million transistor budget exceeds the entire PS1's 1 million transistor budget chipset budget.

Amiga Hombre has a 1 million transistor budget.

IBM's two PowerPC 602's 1 million transistor budget is generous for the 3DO M2 project.

Matsushita paid $100 million USD for 3DO M2 exclusivity. https://www.sfgate.com/business/article/3do-swaps-m2-for-money-3309490.php

3DO has used Matsushita's $100 million payment to develop 3rd generation 3DO MX.

3MB 3D RISC-based games console target group are 3DO, Saturn, and PS1 that are in-sync with gaming PC's typical protected mode DOS games' 3 to 4 MB system requirements.

Amiga AGA's 2MB RAM configuration is outside the 3MB configuration 3D games console target group.

Again, develop a game console with a 1 million transistor budget with the compute power of PS1 from 68K ISA. 68040 already exceeded the 1 million transistor budget.

You can't use the X86 example for 68K when the X86 world has large economies of scale for fat-size X86 CPUs.

Motorola wasn't able to transition large economies of scale from 68000 to fat-size 68040, let alone the 68060.

Computation performance is a priority for 3D games over code density.

There's a reason why "post-RISC" X86 CPUs have grouped certain X86 instructions in different speed grades (i.e. AMD's fast single, fast double, and microcode decoders or Intel's simple, complex, and microcode decoders) and direct compiler design involvement e.g. Intel C++ compiler.

Over time with the transistor budget increases, slower X86 instructions are moved into the faster decode group.

Fat-size X86 wasn't involved with the game console market until AMD's K7 Duron (Xbox prototype) and Intel's Pentium III/Celeron Coppermine-128K L2 (original Xbox).


https://www.mat.uc.pt/~rps/processors/amd_2000_06_05.html
AMD's Duron price in the year 2000 in 1000 unit quantities

700MHz AMD Duron processor $192
650MHz AMD Duron processor $154
600MHz AMD Duron processor $112


https://www.minneapolisfed.org/about-us/monetary-policy/inflation-calculator
Y2000 inflation-adjusted for 1994.

700MHz AMD Duron processor $165.27
650MHz AMD Duron processor $132.56
600MHz AMD Duron processor $96.41

The prices are lower when they are large volumes. X86's clock speed vs price doesn't remain static.

Quote:

Accumulator architectures like the 6502 and poor code density classic RISC architectures like PA-RISC and MIPS disappeared from general purpose use for this reason. General purpose CPU use needs caches to avoid long memory latencies and this was/is expensive. CBM and Motorola had a competitive advantage with the 68k Amiga cache, memory and memory bandwidth miser but only used it to go cheaper instead of upgrading it to go higher performance like Intel did with inferior x86 technology. The grass is greener on the other side of the fence until the hype and propaganda is dispelled. Either DSP or PA-RISC fixed point 3D hardware would be outdated and difficult to use for general purpose use today but a 68060 with fast memory Amiga was already able to play Doom, Strife, Heretic, Hexen and Quake with simple compiles even though it was designed for the low power embedded market and was never clocked up like a 8-stage pipeline with small caches should have been. With more caches, new silicon and a few more upgrades, I expect a 68060 core would be surprisingly modern and high performance, at least compared to the most popular ARM CPU cores like the Cortex-A53.

You're hiding the 68060's cost.

Inflation-adjusted for 1994, PS4 APU has a USD $60 cost. In 2012, PS4 APU had USD $100 cost. The game console budget parameters are similar across generations.

Reference
https://allthingsd.com/20131119/teardown-shows-sonys-playstation-4-costs-381-to-build/

Amiga Hombre's two chips have an estimated $40 manufacturing cost.

That's the cost parameters you are given for game consoles and an A1200-like desktop computer has near a game console cost parameters.

TF1260 has a software-driven overclock feature and 68060 Rev1 (3.3V) is a below-par overclocker.

Prove the Amiga market has 1.2 million users who are willing to spend 1.2 million PowerMacs in 1994. Your market intelligence is flawed.

The 68K core needs to be redesigned with a restricted transistor budget which focuses on fast 3D bias instructions e.g. 68030M-3D. Other 68K instructions not involved with 3D are grouped in the slow decoder path. The direction is based on leadership change.


Quote:

The SiFive U74 core doesn't have a SIMD unit but outperforms the Cortex-A53 and can play at least Pentium III era games. The 68k ISA would gain performance from using the RISC-V SiFive U74 core design and it is very similar to the 68060 design.

Pentium III era games have SSE SIMD support i.e. DirectX6's geometry pipeline is SSE and 3DNow SIMD optimized.

The original Xbox's Pentium III-Coppermine-128K has an SSE baseline.


PS: For my A1200, I switch to RPi CM4 PiStorm32-Lite configuration for improved WHDLoad games compatibility e.g. Brian the Lion AGA, Lion Heart, Golden Axe, Battle Squadron, Metro Siege (non-WHDload), Final Fight Enhanced (ECS 2MB Chip RAM), Banshee AGA and ReShoot R AGA works fine. There's a backward compatibility difference between RPi CM4 and RPi 4B with PiStorm32-Lite.

Last edited by Hammer on 19-Jul-2024 at 03:48 AM.
Last edited by Hammer on 19-Jul-2024 at 03:39 AM.
Last edited by Hammer on 19-Jul-2024 at 03:35 AM.
Last edited by Hammer on 19-Jul-2024 at 03:27 AM.
Last edited by Hammer on 19-Jul-2024 at 03:26 AM.
Last edited by Hammer on 19-Jul-2024 at 03:18 AM.
Last edited by Hammer on 19-Jul-2024 at 03:05 AM.
Last edited by Hammer on 19-Jul-2024 at 02:59 AM.
Last edited by Hammer on 19-Jul-2024 at 02:53 AM.
Last edited by Hammer on 19-Jul-2024 at 01:28 AM.
Last edited by Hammer on 19-Jul-2024 at 01:21 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

matthey wrote: Hammer may be suggesting more. 1. Cheaper AT&T DSP hardware using existing Amiga memory is possible for 3D, MPEG decoding and Doom. 2. Hombre could have been used for 3D, MPEG decoding and Doom if a more powerful, flexible and expensive solution is wanted. 3. CBM ignored their organically developed DSP, Hombre and Amiga chipset tech choosing higher cost and more specialized foreign MIPS based tech for FMV hardware.

Let's synthesize more:

CBM ignored their organically developed Amiga chipset tech choosing higher cost and specialized foreign alien hardware.

BTW the first article (centered on the DSP & audio) of the new short series on this topic is almost ready: I'll publish it either today evening or tomorrow (CET).
Quote:

Hombre may not have been ready yet. The cost for CBM to produce Hombre for their use doesn't include the usual high profit margin included in the price of commodity chips like the CL450 FMV chip. Hombre, like other RISC based CPUs, needed more memory, memory bandwidth and caches than the 68k Amiga, making the total system cost higher. Accumulator architectures like the 6502 and poor code density classic RISC architectures like PA-RISC and MIPS disappeared from general purpose use for this reason. General purpose CPU use needs caches to avoid long memory latencies and this was/is expensive. CBM and Motorola had a competitive advantage with the 68k Amiga cache, memory and memory bandwidth miser but only used it to go cheaper instead of upgrading it to go higher performance like Intel did with inferior x86 technology.

People don't understand why code density is so much important and why processors which aren't good at that requires much more cache / memory / bandwidth.

Last interesting post on this topic: https://www.linkedin.com/feed/update/urn:li:activity:7217700538035970048/

Foundries are having problem scaling with SRAM technology on new processes. And processors are requiring more of that for performance (especially ARM's AArch64, which isn't good on that)...

HP's PA-RISC simply sucked at that and required MASSIVE L1 & L2 caches (like... Itanium!). Which are EXPENSIVE.

1 + 1 = 2? Let's see if people understand...

Hammer Quote:

SuperFX is not based on AT&T DSP1. Super FX chip is a little-endian 16-bit RISC processor aimed at 3D.

It appears you are correct. SNES cartridges used different chips with the 3 most common in order being the following.

1. SA1 - 6502 family CPU, memory and chipset upgrade of SNES hardware
2. DSP-n - NEC μPD77C25 DSP based on Bell Labs/AT&T DSP1
3. SuperFX - early custom RISC architecture CPU/GPU which became ARC architecture

The DSP and SuperFX chips were used for some of the same 2D and 3D calculations but the SuperFX chip was a later more specialized version. Doom used the SuperFX chip.

Hammer Quote:

CL450 includes an interface with 68K or x86 bus. CL450 host interface has a 20-bit address and 16-bit data. CL450 DRAM controller (local frame buffer) has a 10-bit address and 16-bit data. CL450 is optimized to be coupled with Philips' 68070 CPU (68000-based license clone). Commodore's FMV module is a #metoo CD-i which has a plug-in MPEG-1 Cartridge for VCD. Unlike DSP3210, CL450 is not optimized for 68020/68030 32-bit bus.

That is at least partially true. The CL450 fast memory may have only been 16 bit but it could have been clocked high enough to make up for it (Atari Falcon scenario?). The limited address lines may not be a problem with hardware translation tricks other than the max controller mem of 1MiB. It sounds like the CL450 hardware is big endian by default.

CBM was working with AT&T to create an optimal DSP interface with the Amiga including DMA and interrupts. CBM may have delayed Amiga AT&T DSP implementations due to interface bottlenecks. I have heard rumors that CBM waited for new AT&T DSP chips with the support they wanted. Reasonably fast memory is required or the DSP is going to create more memory contention than the CPU and chip memory contention that was already a problem. A DSP is relatively cheap to add but the support hardware is difficult as low as CBM was aiming with the CD32. CBM should have been aiming higher with the base CD32 and Amiga 1200 though as they were stripped down and barely low end when introduced.

Hammer Quote:

68040's 1.2 million transistor budget exceeds the entire PS1's 1 million transistor budget chipset budget. Amiga Hombre has a 1 million transistor budget. IBM's two PowerPC 602's 1 million transistor budget is generous for the 3DO M2 project.

There were a lot of ignorant decisions back then with regard to caches. RISC CPUs for consoles had too small of instructions caches. Many CPUs for consoles did not have any data caches when even a small data cache would have made a big difference. The PS1 chose to use a scratchpad memory instead of a small data cache which may have been fine in the age of no OS and hit the hardware consoles but is a horrible decision in the age of thin OSs and compiled code. The 68k line has issues too with a jump from tiny 68020/68030 256 byte direct mapped caches (12,288 transistors for 68020) to 68040 4kiB I+D 4-way set associative caches (393,216 transistors if direct mapped but more because 4-way). Motorola needed something between the 68030 and 68040 as far as caches like their XCF5102 ColdFire/68040 hybrid with 2kiB-I, 1kiB-D, improved 68040 6-stage decoupled fetch and execution pipelines, 3.3V and fully static for operating at any frequency up to max. It would have been perfect for consoles but Motorola dropped 68040 compatibility as the 68k was headed for the basement as ColdFire and customers were directed to buy PPC instead. Motorola/Freescale upper management didn't understand the importance of code density either and now they are owned by a Dutch business.

cdimauro Quote:

People don't understand why code density is so much important and why processors which aren't good at that requires much more cache / memory / bandwidth.

I think a big part of the problem is that it is easy for humans to underestimate the importance of code density. From PPC code to 68k code is about a 50% reduction in code size. The naive first thought is that 50% smaller code means a 50% smaller instruction cache can be used. From the RISC-V research, a 75% smaller instruction cache is more equivalent. For example, a PPC 128kiB instruction cache is roughly the performance of a 68k 32kiB instruction cache. The 68k L1 instruction cache is almost like having a small L2 instruction cache for free in comparison to the PPC but it is faster to access than any L2. Most L2 caches are shared for instructions and data so this leaves more room in the L2 for data. Less time and energy is wasted reloading CPU code and data from memory leaving more memory bandwidth for a GPU. Less memory is needed as all the code is compressed in memory.

Code density is not everything for computer performance but is kind of like body fat percentage as a prediction of runner performance. A higher percentage of body fat is generally less muscle and more weight. A runner with 30% body fat is not going to beat a runner with 10% body fat very often. A runner with 15% body fat may beat a runner with 10% body fat though, even though the 5% extra body fat is a handicap. In general, it is better to be mean and lean than fat and slow when on the go.

Code density of most popular ISAs (roughly from fat to lean)
Itanium
Alpha
PA-RISC
MIPS
SPARC
PPC
ARM
ARM64/AArch64
RISCV64IMC
x86-64
RISCV32IMC
x86
SH-3
Thumb1
Thumb2
68k

The 7 fattest contenders are out of the race. AArch64 and x86-64 have some muscle and are in the lead but have mediocre code density. The leanest contenders may not have enough muscle to compete, except for the 68k but it doesn't get much love from developers even though it is loved by users.

cdimauro Quote:

Last interesting post on this topic: https://www.linkedin.com/feed/update/urn:li:activity:7217700538035970048/ Foundries are having problem scaling with SRAM technology on new processes. And processors are requiring more of that for performance (especially ARM's AArch64, which isn't good on that)... HP's PA-RISC simply sucked at that and required MASSIVE L1 & L2 caches (like... Itanium!). Which are EXPENSIVE. 1 + 1 = 2? Let's see if people understand...

Yes, SRAM scaling has hit the wall which is huge for caches and threatens to end Moore's Law quickly. New tech is necessary for CPU chips to move forward anywhere close to the pace they were before and this may take awhile or may permanently change the way chips are produced. For example, NOR non-volatile flash memory stopped scaling and can't even be used on smaller processes. There are alternatives with advantages and disadvantages but in many cases external chips are used instead (RP2040 SoC for example). This is not good for integration and lowering cost though. A stop in scaling makes the older processes more competitive. It should benefit good code density CISC processors which have more logic and less caches. This is off topic for Amiga which is decades behind the technology curve and there is no concept of competitive technology in Amiga Neverland. The Amiga has turned into the opposite of the original Amiga Corporation philosophy.

Last edited by matthey on 20-Jul-2024 at 02:11 AM.

@matthey

Quote:

I think a big part of the problem is that it is easy for humans to underestimate the importance of code density. From PPC code to 68k code is about a 50% reduction in code size. The naive first thought is that 50% smaller code means a 50% smaller instruction cache can be used. From the RISC-V research, a 75% smaller instruction cache is more equivalent. For example, a PPC 128kiB instruction cache is roughly the performance of a 68k 32kiB instruction cache. The 68k L1 instruction cache is almost like having a small L2 instruction cache for free in comparison to the PPC but it is faster to access than any L2. Most L2 caches are shared for instructions and data so this leaves more room in the L2 for data. Less time and energy is wasted reloading CPU code and data from memory leaving more memory bandwidth for a GPU. Less memory is needed as all the code is compressed in memory.

You're not factoring in microarchitecture's complexity that consumes higher transistor budgets.

Microarchitecture's complexity needs to be traded with the L1 cache's transistor budgets.

68060 consumes 2.1 million transistors with 8KB+8KB cache while PowerPC 603e consumes 2.6 million transistors with 16KB+16KB cache and a fully pipelined FPU.

PowerPC has a “fused� multiply-add (FMA) instruction: a single instruction reads three operands, multiplies two operands and adds the third to the product, and writes the sum in the result operand. PowerPC is strong for floating point-based 3D, but pixel operations are usually integers.

CISC CPUs like X86 have "fused" integer and floating point math with memory operations. X86 focused on higher clock speed and rapid SIMD inclusion to drive its performance improvements. X86's FMA3 feature arrives later in AVX2. X86 conserves load instruction while it's a separate instruction issue for PowerPC.

There are features when processing 3D games during Quake 3's X86 vs PPC comparisons e.g. C++ function's stack and GPR-FPR transfer hardware optimisations.

All designs have compromises and trade-offs.

At the end of the day, it's Quake, Quake 2, and Quake 3 benchmarks that matter.

Last edited by Hammer on 20-Jul-2024 at 02: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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

It appears you are correct. SNES cartridges used different chips with the 3 most common in order being the following. 1. SA1 - 6502 family CPU, memory and chipset upgrade of SNES hardware 2. DSP-n - NEC μPD77C25 DSP based on Bell Labs/AT&T DSP1 3. SuperFX - early custom RISC architecture CPU/GPU which became ARC architecture The DSP and SuperFX chips were used for some of the same 2D and 3D calculations but the SuperFX chip was a later more specialized version. Doom used the SuperFX chip.

It wouldn't matter for most gamers when the delivered "game experience" matters more than technical specs i.e. "you're selling a dream" - David Pleasance on the interactive entertainment industry.

Quote:

That is at least partially true. The CL450 fast memory may have only been 16 bit but it could have been clocked high enough to make up for it (Atari Falcon scenario?). The limited address lines may not be a problem with hardware translation tricks other than the max controller mem of 1MiB. It sounds like the CL450 hardware is big endian by default.

80 ns access usually has 140 ns read/write cycle FP DRAM i.e. 7.1 Mhz.

CL450 guarantees fast RISC instructions for MPEG decoding for the given memory bandwidth.

Remember, A1200's AGA and Chip RAM (e.g. 7.1 MB/s writeL from the CPU side) displays 60 fps in ClickBoom's Quake 320x200p and 31 fps in 640x200p when there's sufficient compute power. With 30 fps in 640x200p, you can't do more than that with a 15 kHz NTSC TV display.

A1200/CD32 needs compute power.

Quote:

CBM was working with AT&T to create an optimal DSP interface with the Amiga including DMA and interrupts. CBM may have delayed Amiga AT&T DSP implementations due to interface bottlenecks. I have heard rumors that CBM waited for new AT&T DSP chips with the support they wanted. Reasonably fast memory is required or the DSP is going to create more memory contention than the CPU and chip memory contention that was already a problem. A DSP is relatively cheap to add but the support hardware is difficult as low as CBM was aiming with the CD32. CBM should have been aiming higher with the base CD32 and Amiga 1200 though as they were stripped down and barely low end when introduced.

CBM's PA-RISC is semi-customised for 3D i.e. it's not a standard PA-RISC.

68K path would need to be semi-customised for 3D.

_________________
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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Hammer Quote:

You're not factoring in microarchitecture's complexity that consumes higher transistor budgets. Microarchitecture's complexity needs to be traded with the L1 cache's transistor budgets. 68060 consumes 2.1 million transistors with 8KB+8KB cache while PowerPC 603e consumes 2.6 million transistors with 16KB+16KB cache and a fully pipelined FPU.

The 603(e) has a single precision FPU to save die area and transistors so double precision operations have a longer latency and throughput than a pipelined double precision FPU. The 68040 has a partially pipelined extended precision FPU that is outperformed by the newer PPC 603(e) but easily outperforms the older 80486. Many compromises were made with restrictive transistor budgets back then and it wasn't just for the 68k.

Year | CPU | Pipeline | Caches | Transistors
1990 68040 6-stage 4kiB_I+D_4-way 1,170,000
1994 68060 8-stage 8kiB_I+D_4-way 2,530,000
1994 PPC603 4-stage 8kiB_I+D_2-way 1,600,000
1995 PPC602 4-stage 4kiB_I+D_2-way 1,000,000
1995 PPC603e 4-stage 16kiB_I+D_4-way 2,600,000

Compared to the PPC602, the 68040 uses more transistors for a deeper pipeline, 4-way set associative caches instead of 2-way and a partially pipelined extended precision FPU instead of a fully pipelined single precision FPU which doesn't leave much for the partial microcoding wasted transistors that isn't necessary with the 68060. Comparing the PPC603e and 68060, the PPC603e has double the data cache but the performance of half the instruction cache due to the code density difference. Considering the 68060 transistors are used on the deeper pipeline to boost ILP and clock speed, branch cache/prediction unit, a 2nd barrel shifter for the 2nd execution pipe, a multi-banked data cache for both execution pipes in parallel and an instruction buffer to decouple the fetch pipeline and execution pipelines, I don't see much 68k specific tax. The 68060 outperforms the PPC603e at shift, MUL, cache/mem accesses and most integer operations. The PPC603e has a small advantage in FPU performance due to better single precision performance and more GP FPU registers while the 68060 generally has better FPU instruction latency timings for double/extended precision and CISC mem-reg operations. The 68060 uses its transistor budget for extended precision 68k software compatibility while the PPC603e targets single precision performance which is good for 3D but not C compilers which defaulted to double precision. I still don't see any major 68k architecture tax like x86. Even back then with tiny caches compared to today, the 68060 code density advantage offsets any PPC603(e) RISC pipeline savings advantage.

Hammer Quote:

PowerPC has a “fused� multiply-add (FMA) instruction: a single instruction reads three operands, multiplies two operands and adds the third to the product, and writes the sum in the result operand. PowerPC is strong for floating point-based 3D, but pixel operations are usually integers.

Floating point FMA instructions would be good for the 68k too. They simplify algorithms and improve code density. The 68k was locked away in the basement before it received high end upgrades. The 68060 FPU was a compromise for embedded use where a strong FPU is usually not needed. It's actually a good FPU for a minimalist FPU. We would like to have a stronger and better featured FPU which is more common today with larger transistor budgets. It was frustrating that the 68k FPU seemed to be diminishing in some ways with each 68k FPU upgrade even as overall performance improved.

Last edited by matthey on 20-Jul-2024 at 12:38 PM.
Last edited by matthey on 20-Jul-2024 at 06:38 AM.