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 08:21 AM.
Last edited by Hammer on 03-May-2024 at 07:57 AM.

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

@Hammer

Quote:

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

@bhabbott

Quote:

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!

I'm already aware of the Siamese System.

Quote:

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?

Is that your "640K is enough for everybody"?


Quote:

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 definitive A500 has at least the ECS Agnus A and Rev6A motherboard or greater.

I have 1988 A500 Rev 5 and 1989 A500 Rev 6A.

Quote:

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.

ECS Denise is a direct drop-in Denise replacement. Most A500s have this potential.

Amiga Ranger "7 bitplanes" comes with a memory bandwidth increase, unless 16-bit Chip RAM access memory cycles are improved.

EHB's 64 color is not flexible when compared to AGA's 64 color mode.

Last edited by Hammer on 25-May-2024 at 05:30 AM.
Last edited by Hammer on 25-May-2024 at 05:25 AM.

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

@cdimauro

Quote:

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.

Imagination Technologies is owned by Canyon Bridge, a private equity fund ultimately owned by the Chinese government (CPC). CPC has its custom RISC-V mandate.

https://www.theregister.com/2024/05/01/riscv_support_android_pulled/
Google pulls RISC-V support from generic Android kernel.

Qualcomm has Oryon which is AArch64 clone via Nuvia buyout.

Strong CPU R&D companies can create their independent AArch64 clone e.g. AMD's K12 AArch64 clone which is based on ZEN's R&D, Apple's M series and Qualcomm Oryon AArch64 clones.

https://www.notebookcheck.net/AMD-Sound-Wave-ARM-APU-for-Windows-reportedly-in-works-with-strong-NPU-performance.839360.0.html
AMD is working on another AArch64 clone under the Sound Wave APU project.

AMD's K12 was pitched for Nintendo Switch competition.

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

It's just that it would be better for multiple playfields to have their own color registers. This would have made porting arcade, X68000 and NeoGeo games to the Amiga easier and more faithful. It wouldn't have taken many transistors to make the Amiga the arcade in the home for the 1990s like it was in the late 1980s. AGA was a moderate improvement but still lagged the x68000 and NeoGeo which often had full arcade quality game ports as well as arcade quality games made for them.

Both x68000 (under 200,000 units) and NeoGeo (1.18 million units sold) are dead ends due to PC's Doom.

SNES's 60 million units beaten NeoGeo's 1.18 million units.

Quote:

AAA supporting VRAM and DRAM implies that VRAM offered additional performance over the best possible DRAM performance. Supporting both memory types likely used a few more transistors but it shouldn't have been a problem in the early 1990s as C= was building prototype chips of AAA with it. How much more competitive would AGA with VRAM and x8 OCS chip mem bandwidth have been especially for the high end Amiga market? How much more competitive would AA+ have been with x16 chip mem bandwidth from VRAM and a 28MHz clock speed? Should the Ranger chipset have received a can you make it so it can use VRAM or DRAM and lets see where VRAM prices go instead of a never and bury it response from C= upper management?

1987-era VRAM example is NEC uPD41264C-12 with serial access of 40 ns time max and Row access of 120 ns time.
https://www.ardent-tool.com/datasheets/NEC_uPD41264.pdf

Pixel workload is usually sequential i.e. serial access mode.

Need an ASIC that can keep up with 25 Mhz effective memory performance.

From key original Los Gatos Amiga engineers led 3DO, 1993 era 3DO's VRAM has serial access of 20 ns time max which is about 50 Mhz effective.

Both MADAM @ 25 Mhz and CLIO (24 Mhz) can access 1 MB VRAM.
MADAM and ARM60 can access 2 MB 80 ns DRAM.

1993 3DO's 3D acceleration is OpenLara capable. This shows 3DO is capable against PS1.
https://www.youtube.com/watch?v=avHZmZY5-ls

Most 3DO games didn't show 3DO's power difference from fast 386DX and 486SX PCs since ARM60 @ 12.5 Mhz is just 68030-40 / 386SX-40 class CPUs.

Software sells the hardware.

_________________
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