cdimauro Quote:

Yes, this is the context: 1990. And to be more precise, it's about what changes to the ECS chipset were needed to achieve that WITHOUT violating the "no new chips" directive. Do you think that adding such VRAM support was still possibile (e.g.: not many transistors required. Remaining on the ECS budget)? From what you've written it should have been possible. I'm not an expert on that, but to me it smells that you need much more transistors to change the arbitration logic and adding several buffers; at least.

It's too difficult to know or even guess what the ECS transistor budget increase was as it defies logic based on the technology at the time. Upper management was not adapting to the changing technology fast enough which is why they had the "no new chips" directive so late for ECS and then relatively splurged on transistors for AGA 2 years later as they obviously quickly reversed course with minimal planning and a shortage of development time for AGA.

cdimauro Quote:

Yes, AGA was already on a better position because there was the OK from management to create fatter chips. However they (engineers) failed again because they added the bare minimum without introducing the most important things (e.g.: a Blitter with higher clock).

I wouldn't say the blitter was one of "the most important things" anymore for AGA. It was a basic thing that should have been increased and the engineers didn't have enough time or there was compatibility issues. A 68030 CPU could already outperform the original blitter and even a lower clocked 68020 has a barrel shifter so it is not a complete disaster for AGA. AGA was a rush job due to "no new chips" planning by management while AA+ is what AGA should have been.

cdimauro Quote:

Understood, but maybe '87/88 was too early for the VRAM and prices were too high.

VRAM was too expensive for the low end is 1987-1988 but the option for the high end would have made high end Amigas shine. The X68000 was released in 1987 and came with 1 MiB of VRAM. It was very expensive but it wasn't just the VRAM raising the cost. I expect a VRAM option for ECS in 1990 would have been practical and was needed for high end Amigas to keep them competitive. The 1993 3DO Console used 1MiB of VRAM as did the later PS1 while the Saturn used 1.5MiB of VRAM. C= would have been pushing the envelope to use 2 MiB of VRAM in the 1993 CD32 but the VRAM may have compensated for the cheaper minimalist chipset and CPU in both performance and cost.

cdimauro Quote:

Exactly, but the point is that a core with 100% synthesized logic is needed to have a 68k processor (whatever it was. 68060 is better, of course) suitable to be ported to modern fabrication processes. This is the bare minimum required. And this is especially needed if you want to make changes to it, to make it more modern. How much this cost and if this is possible, are the big questions...

The 68060 may have started as 100% synthesizable logic until custom blocks were optimized for it. The 68060 was sold as a commodity chip so this made sense. ColdFire v5 was never sold as a commodity chip but prepared for and licensed for embedded SoC chips where 100% synthesizable logic was desirable back then. ARM changed this and became more competitive in PPA when they started offering more optimized custom blocks a la carte.

https://www.arm.com/products/silicon-ip-physical Quote:

Physical Implementation for POP IP and Artisan Physical IP Physical implementation is required to take a processor from RTL to silicon. This step ­- optimizing power, performance, area and cost - is crucial but can be complex, time-consuming and costly. Arm POP (Processor Optimized Package) IP leverages our market-leading processor knowledge with Artisan Physical IP products to deliver the most efficient and highest-performance Arm processor implementations for our licensees. This powerful, combined solution accelerates core hardening so designers can spend more time on SoC and software integration and get to market faster.

Using POP for ARM cores is optional and there is a 0.5% royalty charged to the fab for using it that can be expected to be passed on to the customer. Qualcomm has accused ARM of trying to use licensed IP through the fab to force their customers to use only ARM IP including POP and GPUs. This could cut out the middle man like Qualcomm who design SoCs forcing their customers to license directly from ARM as well as use ARM's CPU core reference designs, ARM's POP and ARM's GPUs. ARM could raise licensing and royalty costs to fabs in a less than transparent way too. This is very bad news for businesses that license GPUs for SoCs but likely good for customers who want to license non-ARM GPUs for SoCs, at least until the GPU businesses go out of business. The decision by Imagination Technologies to use RISC-V cores for GPU management looks much better in this light and maybe they saw the writing on the wall from ARM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Yes, AGA was already on a better position because there was the OK from management to create fatter chips. However they (engineers) failed again because they added the bare minimum without introducing the most important things (e.g.: a Blitter with higher clock). I wouldn't say the blitter was one of "the most important things" anymore for AGA. It was a basic thing that should have been increased and the engineers didn't have enough time or there was compatibility issues. A 68030 CPU could already outperform the original blitter and even a lower clocked 68020 has a barrel shifter so it is not a complete disaster for AGA. AGA was a rush job due to "no new chips" planning by management while AA+ is what AGA should have been.

Yes, but an improved Blitter could have easily outperformed both 68020 and 68030.

At the AGA time maybe a 28Mhz could have been possibile which is crazy fast even remaining 16-bit and 100% compatibile with the original.
Quote:

cdimauro Quote: Understood, but maybe '87/88 was too early for the VRAM and prices were too high. VRAM was too expensive for the low end is 1987-1988 but the option for the high end would have made high end Amigas shine. The X68000 was released in 1987 and came with 1 MiB of VRAM. It was very expensive but it wasn't just the VRAM raising the cost. I expect a VRAM option for ECS in 1990 would have been practical and was needed for high end Amigas to keep them competitive. The 1993 3DO Console used 1MiB of VRAM as did the later PS1 while the Saturn used 1.5MiB of VRAM. C= would have been pushing the envelope to use 2 MiB of VRAM in the 1993 CD32 but the VRAM may have compensated for the cheaper minimalist chipset and CPU in both performance and cost.

High-end is not a problem, because we expect that those machines to be expensive.

However the cash cow was presented by the low-end market and I would rather have focused on this, keeping an option for the high-end (DRAM for low-end, VRAM for high-end. For example). This is the only "escape" way that I see to circumvent the idiot management of the time, like the Amiga 3000 has shown (e.g.: "no new chips" but it had Amber, which is a completely new one, and plenty of RAM attached to it).
Quote:

cdimauro Quote: Exactly, but the point is that a core with 100% synthesized logic is needed to have a 68k processor (whatever it was. 68060 is better, of course) suitable to be ported to modern fabrication processes. This is the bare minimum required. And this is especially needed if you want to make changes to it, to make it more modern. How much this cost and if this is possible, are the big questions... The 68060 may have started as 100% synthesizable logic until custom blocks were optimized for it. The 68060 was sold as a commodity chip so this made sense. ColdFire v5 was never sold as a commodity chip but prepared for and licensed for embedded SoC chips where 100% synthesizable logic was desirable back then.

That could be a good starting point, then.
Quote:

ARM changed this and became more competitive in PPA when they started offering more optimized custom blocks a la carte. https://www.arm.com/products/silicon-ip-physical Quote: Physical Implementation for POP IP and Artisan Physical IP Physical implementation is required to take a processor from RTL to silicon. This step ­- optimizing power, performance, area and cost - is crucial but can be complex, time-consuming and costly. Arm POP (Processor Optimized Package) IP leverages our market-leading processor knowledge with Artisan Physical IP products to deliver the most efficient and highest-performance Arm processor implementations for our licensees. This powerful, combined solution accelerates core hardening so designers can spend more time on SoC and software integration and get to market faster. Using POP for ARM cores is optional and there is a 0.5% royalty charged to the fab for using it that can be expected to be passed on to the customer. Qualcomm has accused ARM of trying to use licensed IP through the fab to force their customers to use only ARM IP including POP and GPUs.

Interesting. That's a nice option to get better performances / more efficiency.
Quote:

This could cut out the middle man like Qualcomm who design SoCs forcing their customers to license directly from ARM as well as use ARM's CPU core reference designs, ARM's POP and ARM's GPUs. ARM could raise licensing and royalty costs to fabs in a less than transparent way too. This is very bad news for businesses that license GPUs for SoCs but likely good for customers who want to license non-ARM GPUs for SoCs, at least until the GPU businesses go out of business. The decision by Imagination Technologies to use RISC-V cores for GPU management looks much better in this light and maybe they saw the writing on the wall from ARM.

Exactly. ARM is playing dirty with its customers. If it keeps the same new licensing models, there will a be a massive move towards RISC-V. Especially now that Imagination has announced the new revamped GPUs (DX11 class, but they look promising) and with the new RISC-V agreement.

ARM is risking A LOT. Not in short term, but in the long term it might loose a big part of its business.

@cdimauro

Quote:

You clearly know nothing how the Amiga worked, right?

Bullshit.

Quote:

Gary: The Gary chip provides bus traffic control signals for the A500/A600/A2000 address and data bus. It was a consolidation of a large amount of descrete 74-series components and PALs on the A1000.

I'm aware.

Gary was replaced by Fat Gray (A3000/A4000/"A1000Jr") or Gayle (A1200).

Gayle was integrated into Akiko (CD32).

Quote:

Ramsey: Found only in the A3000 series and A4000T machines, the Ramsey is responsible for addressing RAM and producing DMA addressing, particularly with regards to the motherboard SCSI controller.

SDAC is needed for the DMA interface with the SCSI controller.

Ramsey's 32-bit memory controller functions were integrated into Budgie in A1200.

Budgie has a 16-bit buffered link to Gayle's PCMCIA.

Budgie was integrated into Akiko.

Quote:

Agnus: The Agnus is responsible for controlling around 25 system DMA channels, the generation of various system clocks in some Amiga's, and for addressing Chip RAM. Infact, Chip Memory is so called because it's addressable by the system's custom chips, unlike Fast Memory. Do you know what the article was talking about? I don't think so, looking at the above chip descriptions.

Reminder, RTG doesn't rely on Agnus/Chip RAM bus side.

My argument is to leave Amiga OCS as is for legacy software and build a non-legacy graphics solution on Ramsey's Fast RAM bus side. My argument is fat PS3's "PS2 on a chip" legacy approach.

Mucking around with backward compatibility while evolving the graphics design slows down progress.

By default, evolved Amiga should remain in legacy mode until a mode change request.

Meanwhile, PS1 was in a development prototype stage in June 1992 when Kutaragi unveiled a proprietary CD-ROM-based system he had been secretly working on which played 3D games.

When compared to Sony or 3DO, Commodore is behind when compared to Sony's June 1992 PS1 stage and 3DO's May 1992 Consumer Electronics Show demo.

Last edited by Hammer on 03-May-2024 at 09:21 AM.
Last edited by Hammer on 03-May-2024 at 08:57 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: Reminder, RTG doesn't rely on Agnus/Chip RAM bus side.

That's right. RTG doesn't rely on any specific hardware. You could have RTG going through an I/O port with the display being generated on a completely separate device. One example is the Siamese System which uses a serial port or Ethernet connection to a Windows PC. It works surprisingly well!

But this thread is about what could have been done to give ECS better performance. To which I say - nothing could realistically have been done, and nothing needed to be done. ECS already had more in it than anyone would use! I could argue for putting different stuff in it, but what would be the point?

In 1990 over a million OCS Amigas had been sold. This was the user base that would determine what titles would be produced in the future. A few ECS machines weren't going to change that. The only minor improvements that would be utilized were those that provided optional enhancements, such as more ChipRAM for caching more data etc. Anything that required the ECS chipset would not garner the required sales to make it profitable, making that feature practically worthless.

Take 7 bitplane 'extra-extra halfbrite' for example. Ignoring the bandwidth it would suck, who would use it? The Amiga already had 6 bitplane extra-halfbrite since 1986, yet very few programs made use of it.