Unreleased Amiga chipset better than anything today?

[TEG]

Originally Posted by Promilus

ECS had no improvement on CPU performance EXCEPT A3k. And they did solve one of the problems with faster CPUs on Amiga by using workaround with CHIP-RAM organization. So if chipset accesses chipram it's 16bit, if CPU does that it's 32b.

Let me fully understand here. It was done this way to do not touch Blitter/Copper right?

I mean a redesign of the chipset to be 32bits access too, would have been possible, right? (or there was timing problems or anything else?)

[Bruce Abbott]

Originally Posted by idrougge

Note that the CD32 is a console and you are talking about computer games now. Even on the Amiga, which was a computer, fighting games sold exceptionally well.

We are talking about player preferences, not platforms. I fully accept that fighting games were more popular on consoles than they were on PCs.

Compare the PC hit chart to the console hit charts for measure, then say fighting games weren't popular.

A few fighting games were popular. Many more other genres were more popular.

And thus it is irrelevant for the CD32, which does not have a mouse and keyboard and is not aimed at older gamers.

But a mouse and keyboard can easily be plugged into it, and 'older gamers' was a market conventional consoles weren't tapping into. My argument is that the CD32 could have captured that market, especially since it was an Amiga (whose capabilities were well known to both 'older' and 'younger' players).

BTW I did buy a mouse for my PlayStation, thinking it would be useful playing more sophisticated games. But I never did because nothing suitable came my way. That mouse is going to be rewired for the Amiga.

Do separate the Amiga and the CD32 here. Different audiences, different setting, different input methods.

Narrow minded thinking.

And what are you trying to say by bringing up Rise of the Robots — which every Amiga owner (except the reviewer in CD32 Gamer, which awarded it a 90 % score) knows is dosh?

Because ROTR was exalted as being a game ideally suited to the CD32, but it flopped.

[AestheticDebris]

Originally Posted by Bruce Abbott

But a mouse and keyboard can easily be plugged into it, and 'older gamers' was a market conventional consoles weren't tapping into. My argument is that the CD32 could have captured that market, especially since it was an Amiga (whose capabilities were well known to both 'older' and 'younger' players).

The market for traditional console games is and was vastly larger than the market for games that ran on computers. It's why Commodore (and others like Amstrad) wanted a piece of that pie. A console that was really only good for playing the kinds of games people didn't play on consoles wasn't a winning strategy.

Originally Posted by Bruce Abbott

Because ROTR was exalted as being a game ideally suited to the CD32, but it flopped.

Some would argue both of those can be true.

[grelbfarlk]

Originally Posted by AestheticDebris

The market for traditional console games is and was vastly larger than the market for games that ran on computers. It's why Commodore (and others like Amstrad) wanted a piece of that pie. A console that was really only good for playing the kinds of games people didn't play on consoles wasn't a winning strategy.

And Commodore really liked that business strategy. You build one little widget and keep building it without changes for 5 years at a minimum. After a while it gets cheaper and cheaper to build it. And if you control it well enough you can make people pay you to release things for it. Then you plan the next one out, but these cycles are well defined in the console world, not the computer world, at least when these things were taking place.

[Promilus]

Originally Posted by TEG

Let me fully understand here. It was done this way to do not touch Blitter/Copper right?

I mean a redesign of the chipset to be 32bits access too, would have been possible, right? (or there was timing problems or anything else?)

Everything WAS possible. 32bit blitter and copper, faster blitter and copper. Everything. It's always tough b*tch called compatibility which bites back and takes longer to find workaround.

The idea was to write chipram from fast CPU faster... as at some point it generally is faster to do more stuff in software rather than let blitter and copper duo have some fun. Exactly because blitter and copper are 16bit and run at constant speed. But doing most of the work in FAST then copying it to CHIP still takes a lot of time. Hence 32b access to CHIP RAM during CPU mem access slot makes perfect sense as it doubles the throughput with relatively low cost of ICs.
Things I described as possible was not only theoretically possible, they were made into AAA chipset. And more. Obviously the biggest compatibility issues were with "more" part but on register level ECS compatibility was retained (but not timings). Either way I'd love to see AAA instead of AA... It probably would not save commodore but at least we'd have even better machines to turbo charge after 30 years... and pretty possible without the need for 3rd party RTG.

[TEG]

Originally Posted by Promilus

Either way I'd love to see AAA instead of AA... It probably would not save commodore but at least we'd have even better machines to turbo charge after 30 years... and pretty possible without the need for 3rd party RTG.

Yeah, I agree because we would so have another essence of the Amiga, a different touch of hardware combinations/limitations and so another taste of the very particular magic which can be created.

[hammer]

Originally Posted by Promilus

Everything WAS possible. 32bit blitter and copper, faster blitter and copper. Everything. It's always tough b*tch called compatibility which bites back and takes longer to find workaround.

The idea was to write chipram from fast CPU faster... as at some point it generally is faster to do more stuff in software rather than let blitter and copper duo have some fun. Exactly because blitter and copper are 16bit and run at constant speed. But doing most of the work in FAST then copying it to CHIP still takes a lot of time. Hence 32b access to CHIP RAM during CPU mem access slot makes perfect sense as it doubles the throughput with relatively low cost of ICs.
Things I described as possible was not only theoretically possible, they were made into AAA chipset. And more. Obviously the biggest compatibility issues were with "more" part but on register level ECS compatibility was retained (but not timings). Either way I'd love to see AAA instead of AA... It probably would not save commodore but at least we'd have even better machines to turbo charge after 30 years... and pretty possible without the need for 3rd party RTG.

Refer to Apollo-Core's SAGA implementation i.e. it has backwards compatibility with AGA and reasonably fast RTG. Apollo-Core's SAGA has a turtle mode.

Classic Amiga chipset has added complexity with DMA slot issues.

Before X86's UEFI era, the IA-32 PC starts with 8086's 16 bit real mode, and 386 OS can switch to 386's protected mode. A similar approach was used for AMD's X86-64 Long mode. The assumption is legacy software wouldn't be aware of the new mode, hence the hardware legacy mode default.

The alternate timeline of Amiga's evolution would be like the PC with hit-the-metal MDA/CGA/EGA/VGA legacy but with Amiga's hit-the-metal OCS/ECS/AGA legacy.

Beyond either VGA or AGA, it's Windows GDI/GDI+/DirectX or Amiga's RTG. Windows 7/2008 Direct2D(DirectWrite) has replaced legacy GDI/GDI+.

In modern times, PS5's Zen 2 CPU has additional customizations to replicate Jaguar's timings and latency in a backward compatibility mode. PS5 and PS4 Pro's 36 CU GPUs have strict topology design issues with PS4's 18 CU design. PlayStation 4 and 5 are the closest to old-school hit-the-metal.

PC has graphics APIs that have resource tracking to support many hardware performance levels from laptops to workstations/servers. This is also applicable to Xbox's evolution. Like the PC's DirectX, Xbox Series X's 52 CU doesn't follow Sony's strict 4X/2X scaling from Xbox One X's 40 CU, and Xbox One's 12 CU scaling. Xbox One X/Series X has a virtual machine GPU hypervisor that can target hardware performance profiles of lesser Xbox One and Xbox Series S machines.

Xbox One X dev kit has a 44CU GCN variant that can replicate the retail Xbox One X (40 CU), Xbox One S (12 CU higher speed), and Xbox One(12 CU original) performance profiles and this hypervisor technology was carried over to Xbox Serise S/X.

With lots of money and skills, backward compatibility can be solved.

[hammer]

Originally Posted by Bruce Abbott

Not entirely true. The ability to switch between NTSC and PAL is quite useful for games,

I'm in PAL country, I rarely use NTSC mode. Most Amiga games are in PAL countries.

Originally Posted by Bruce Abbott

and the 2MB ChipRAM is too.

My Amiga 3000's stock SKU has a 1MB Chip, 1 MB Fast RAM, and Kickstart 2.04 ROM configuration. 1 MB Fast RAM's DRAM chips can be moved into Chip RAM slots since they are not ZIP RAMs.

When Commodore's 2 MB Chip RAM configuration was being shipped, CPU-driven 3D games were also in vogue, hence the need for Fast RAM.

When 3D games matter, a 2 MB CHip RAM configuration cuts A1200/CD32's raw hardware performance in half.

Originally Posted by Bruce Abbott

Productivity mode is more about 'serious' applications than games of course. However the Mac and ST both had a large number of hires monochrome games that could be ported to the Amiga, which would look much nicer on a VGA screen than flickery PAL or NTSC interlace.

ECS is not competitive in 1990 when baseline VGA has 16 colors non-interlacing 640x480p. VGA's 16 colors non-interlacing 640x480p existed since 1987 and the VGA cloners made it cheap and evolved upon it.

Apple Mac II has 16 colors with 640×480p or 256 colors with 512×384p without tricks like HAM modes.
https://en.wikipedia.org/wiki/Macintosh_II

To work around the "No New Chips" directive, Amiga 3000's designers wasted four 80ns 256K chips for Ambre flicker fixer for the framebuffer to create flicker free 16 colors with a 640x512 display. The 32-bit Chip RAM is wasted with 16-bit ECS.

Originally Posted by Bruce Abbott

But the big problem with ECS for games was that it had any enhancements at all. Making a game ECS only would severly limit its audience. Using productivity mode would be even more restricting. The Amiga just didn't have a large enough user base to permit such things.

Due to the Ambre flicker fixer, I didn't use ECS's 4 color productivity modes when I have my Amiga 3000.

Originally Posted by Bruce Abbott

However making use of features that didn't break compatibility was OK. A game could have extra graphics and sound with 2MB, and NTSC/PAL switching for region-independent higher frame rate or detail. You may argue that these aren't earth-shattering enhancements, but they aren't nothing.

They are "nothing burgers" for Amiga gaming.

[hammer]

Originally Posted by Bruce Abbott

That's right, but you don't see hammer dissing his exalted ET4000AX ISA bus graphics card for that fact.

False narrative.

ET4000AX with 386DX-based PC has 32-bit system RAM + 16-bit ISA bus + ET4000AX's discrete high-speed 16-bit VRAM or 32-bit DRAM depending on SKU.

ET4000AX's raster processing on video memory is NOT being disturbed by the CPU's I/O access.

386DX-33 has 33 Mhz 32-bit system memory.

486SX-33 has 33 Mhz 32-bit system memory.
486DX2-66 has 33 Mhz 32-bit system memory.
486DX-50 has 50 Mhz 32-bit system memory.

ET4000AX by itself is useless.

For the 1992 to 1993 era, A1200 needs at least 33 Mhz 68020 / 68030 with 32-bit Fast RAM to counter fast 386DX-33 and 386DX-40-based PCs. I support DP's argument on CPU-accelerated A1200 game bundles for 1993.

[hammer]

Originally Posted by Bruce Abbott

What a ridiculous statement. One might as well say that a 16 bit ISA VGA card 'wasted' the 32 bit bus in a 386DX PC, or that a PCI video card 'wasted' the 64 bit bus in a Pentium system.

ET4000AX is displaying fast VGA's chunky pixels 256 colors without HAM tricks, hence no HAM-related overheads.


Did you miss AGA 256 color mode vs HAM6 vs HAM8 comparison?
[ Show youtube player ]
Results:
47.23 fps for AGA's 256-color mode.
39.91 fps for AGA's HAM8 mode.
39.94 fps for AGA's HAM6 mode. The Alice is showing its bottleneck.
HAM mode incurs a performance penalty.

ET4000AX's raster operations have a 32-bit core at 65 Mhz with a 32-bit 40 Mhz video memory clock.

On raster operations, ET4000AX is less bottlenecked compared to Denise or Lisa. At least Lisa has a 32-bit design at a lowish clock speed

https://bigbookofamigahardware.com/b...uct.aspx?id=23

A3000+ According to Dave Haynie

"The Amiga 3000+ was the first computer based on the Pandora chipset (which was later dubbed AA, then AGA). Revision 0 of this system first booted successfully in February of 1991, thanks due to a chip revision that got the display logic actually working. This is revision 1, which completed the audio subsystem, and moved to surface-mount components.

As the name suggests, this system was being designed as a drop-in replacement for the existing Amiga 3000 motherboard. In addition to the features everyone knows from the Amiga 3000, and from later computers such as the Amiga 4000, the Amiga 3000+ sported the AT&T DSP3210 digital signal processor as a coprocessor.

You can see quite a bit of support circuitry for the DSP in the upper lefthand corner of this board. There was an audio CODEC here, designed to allow 16-bit, 2-channel recording and playback. This was very cutting edge at the time, such chips, common today, where just becoming available. In addition, there was a separate mono CODEC with hardware phase correction, which supported modem protocols up to V32. The actual DSP was located above and to the right of the CPU.

Note: this is the real Amiga 3000+, very rare. Most of the Amiga 3000+ type systems out, whether boards or whole computers, are actually the scaled-down "AA3000", which was after the A3000+ had been cancelled, by the Bill Sydnes administration, as a product." - Dave Haynie


A3000's 32-bit Chip RAM design was in place for this AGA evolution upgrade that was completed in Feb 1991! Lisa is ready for A3000's 32-bit RAM! AGA could have been Xmas Q1 1991 player! You're defending fools like Bill Sydnes administration.

[Bruce Abbott]

Originally Posted by hammer

Classic Amiga chipset has added complexity with DMA slot issues.

...and more complex features like sprites, copper, dual playfield, overscan etc., that were much more difficult to accurately reproduce than the simple CRTC in a PC CGA/EGA/VGA card. This was a big stumbling block because many Amiga games and demos relied on exact operation of the hardware, whereas most PC programs avoided doing fancy stuff that might be incompatible on some graphics cards.

Another example of a platform with this issue is the Amstrad CPC. Though it uses the same CRTC as the PC, coders on the CPC pushed the envelope much more to get fancy effects that relied on exact operation of the graphics hardware. But at least 3 different CRTC chips were used at various times along with 2 different gate arrays, with the result that some demos only work properly on machines with certain chip combinations.

PCs had issues too. But there was one fundamental difference - PC gamers didn't care so much about compatibility. If an older DOS game didn't work it wasn't a big deal, because they were mostly only interested in playing newer games. Ironically, the fact that hardware wasn't always 100% compatible was just accepted as part of life in the PC world, whereas Amiga fans tended to overreact when some game or demo didn't work 100% on a new model.

The alternate timeline of Amiga's evolution would be like the PC with hit-the-metal MDA/CGA/EGA/VGA legacy but with Amiga's hit-the-metal OCS/ECS/AGA legacy.

Beyond either VGA or AGA, it's Windows GDI/GDI+/DirectX or Amiga's RTG.

Yes.

However the Amiga didn't really get that far during its official lifespan, and as a retro platform it is expected to have original hardware (or an exact emulation of it).

With lots of money and skills, backward compatibility can be solved.

Money, skills... and insane performance that makes software emulation viable. A modern 'Amiga' would simply emulate an entire classic Amiga in software without having to reproduce any of the original hardware features. At this point there is no Amiga (or PC) chipset - just APIs and (unspecified) hardware with drivers that implement them.

[Bruce Abbott]

Originally Posted by hammer

Note: this is the real Amiga 3000+, very rare. Most of the Amiga 3000+ type systems out, whether boards or whole computers, are actually the scaled-down "AA3000", which was after the A3000+ had been cancelled, by the Bill Sydnes administration, as a product." - Dave Haynie
[/i]

A3000's 32-bit Chip RAM design was in place for this AGA evolution upgrade that was completed in Feb 1991! Lisa is ready for A3000's 32-bit RAM! AGA could have been Xmas Q1 1991 player! You're defending fools like Bill Sydnes administration.

The A3000+ should have been cancelled. The A3000 was grossly overpriced and the A3000+ would have been no different. Dave Haynie should have been working on an AGA replacement for the A500 (ie. the A1200), and a low cost mid-range machine that would have been ready to go when Bill Sydnes asked for it.

Commodore needed a more advanced low end model to replace the aging A500, not expensive big box machines. Zorro III was a disappointing compromize (sorry Dave, but it needs to be said). The eventual replacement for the A2000 would have PCI slots as well as Zorro II.

[Promilus]

AAA was capable of being low end position and high end as well. All depends on configuration. But the last cog was always CPU and there just wasn't any relatively cheap and powerful enough to handle new more or less 3D titles, even with new chipset with abundance of chipmem, great bandwidth, chunky pixels in hardware and of course 32b blitter(s). And it was designed to handle 030 but 040 was kind of problematic. So... yeah, that's why fixed, tightly integrated chipset is great for consoles, not so great for computers.

[Bruce Abbott]

Originally Posted by Promilus

AAA was capable of being low end position and high end as well. All depends on configuration. But the last cog was always CPU and there just wasn't any relatively cheap and powerful enough to handle new more or less 3D titles,

3D always taxed both the CPU and graphics hardware, but the big problem was that the bar was constantly being raised. A stock Amiga 1000 did an excellent job of reproducing the wireframe 3D in the vector graphics arcade game Star Wars (I played this game a lot at the arcades so it was great to have it on the Amiga). A stock Amiga was also powerful enough to do a good job of solid 3D simulators such as FA-18 Interceptor and Indianapolis 500.

But of course that wasn't good enough for fans, who wanted more 'realism' - thus the push for texture mapped 3D, more detailed objects, lighting effects, higher frame rates and higher resolution. Hardware could be 1000 times more powerful and still not enough to sate this appetite.

even with new chipset with abundance of chipmem, great bandwidth, chunky pixels in hardware and of course 32b blitter(s). And it was designed to handle 030 but 040 was kind of problematic. So... yeah, that's why fixed, tightly integrated chipset is great for consoles, not so great for computers.

Fixed anything is not good when the demand for more powerful hardware is increasing exponentially.

The original Amiga chipset was 'tightly integrated' in that the CPU shared memory with the chipset in an interleaved fashion that didn't slow it down much. However as soon as you included FastRAM this integration vanished. Now the CPU is independent of the chipset and can go as fast as it wants - which is a good thing for computers, especially when the chipset can do stuff like blitting and line drawing independently while the CPU is doing other things.

But of course the CPU has to slow down when accessing ChipRAM to feed graphics data into the chipset, which was a problem for code that used the CPU to render graphics. The answers to that were to a) improve ChipRAM write bandwidth, and/or b) offload rendering to a chipset which could do it faster.

If you specify that the chipset's capabilities are fixed then increasing write bandwidth is your only option. That was the initial technique used by PCs, until graphics chips with hardware 3D were developed. Today we also see this on the Amiga, where an insanely powerful CPU can produce graphics performance we could only dream of back in the day, despite the slow 2D chipset. And current systems are not even as efficient as they could be. With proper write caching a fast CPU would be able to render at full video frame rate without significant loading.

[hammer]

Originally Posted by Bruce Abbott

...and more complex features like sprites, copper, dual playfield, overscan etc.,

The Copper is part of the Agnus. Agnus is the DMA controller (DMAC). Copper's popular use case is racing the beam and modifying Denise's registers instead of using the CPU like on the Atari ST.

The Amiga chipset has hardware extensions for 2D scrolling games since the 68000 CPU couldn't deliver 7.1 mips for 7.1 Mhz clock speed and memory bus.

Amiga chipset compartmentalized most 2D visual effects processing within the custom chips domain, hence it's easier to change the CPU (within certain limits) when compared to Atari ST/STe.

Originally Posted by Bruce Abbott

that were much more difficult to accurately reproduce than the simple CRTC in a PC CGA/EGA/VGA card.

Rendition Verite v1000's 25 Mhz MIPS-based RISC CPU emulates VGA and it's very slow.

In modern computing, PS4 has timing backward compatibility issues between CPU and GPU, hence the reason for spending extra silicon budget for PS4 timing matching on PS4 Pro and PS5. PS4's game design assumptions will be PC laptop friendly. "Resource tracking" is a major feature of PC's graphics API management.

Originally Posted by Bruce Abbott

This was a big stumbling block because many Amiga games and demos relied on exact operation of the hardware, whereas most PC programs avoided doing fancy stuff that might be incompatible on some graphics cards.

PC's Doom delivers a superior perspective parallax effect instead of Amiga's "onion" layered fake parallax effect.

Doom is both a tech demo and a game. A500/A600's recent Grind also serves both as a tech demo and a game. Dread couldn't work on 68K with enabled caches due to cache coherent incompetence issues.

Originally Posted by Bruce Abbott

Another example of a platform with this issue is the Amstrad CPC. Though it uses the same CRTC as the PC, coders on the CPC pushed the envelope much more to get fancy effects that relied on exact operation of the graphics hardware. But at least 3 different CRTC chips were used at various times along with 2 different gate arrays, with the result that some demos only work properly on machines with certain chip combinations.

This is Amstrad CPC's problem and there are only 3 million units.

Originally Posted by Bruce Abbott

PCs had issues too. But there was one fundamental difference - PC gamers didn't care so much about compatibility. If an older DOS game didn't work it wasn't a big deal, because they were mostly only interested in playing newer games. Ironically, the fact that hardware wasn't always 100% compatible was just accepted as part of life in the PC world, whereas Amiga fans tended to overreact when some game or demo didn't work 100% on a new model.

For PCs, being IBM PC compatible is a priority over other wannabe PC standards e.g. TIGA.

Intel didn't play with Motorola's 68000 vs 68020 instruction set changes.

Intel's 386 approach has compartmentalized backward compatibility in real mode 86 and 286 protected mode.

DOSbox has CPU cycle settings to approximate hardware performance profiles for certain early DOS games that used hardware's performance as a timing method. Games that are PC clone aware have game design factors in faster PCs.

Windows 3.0 offered API and driver abstraction for TIGA i.e. Texas Instruments convince Microsoft that the internal interfaces to its Windows operating system had to be adaptable instead of hard-coded since all versions of Windows prior to Windows 3.0 were "hard-coded" to specific graphics hardware.

Originally Posted by Bruce Abbott

Yes.

However the Amiga didn't really get that far during its official lifespan, and as a retro platform it is expected to have original hardware (or an exact emulation of it).

Money, skills... and insane performance that makes software emulation viable. A modern 'Amiga' would simply emulate an entire classic Amiga in software without having to reproduce any of the original hardware features. At this point there is no Amiga (or PC) chipset - just APIs and (unspecified) hardware with drivers that implement them.

FYI, the latest GPUs from AMD and NVIDIA still have VGA compatibility mode while Intel has removed VGA compatibility from ARC series GPUs.

The major issue for DOS gaming on 1st generation Core series PCI slot-equipped PC hardware is sound cards since modern PC BIOS doesn't allocate the necessary IRQs, hence SBemu project was created. https://github.com/crazii/SBEMU

Due to NVIDIA's dominance and Shader Model 6 wave intrinsics, this pressured AMD to follow NVIDIA's wave size 32 on RDNA architecture i.e. API abstraction has limits. AMD lost GCN's wave64 argument while it's a win for NVIDIA's CUDA's wave 32 size.

PC Direct3D12 and Shader Model 6.6 are closer to the metal, and this is driven by maximizing the game's performance which is influenced by game consoles and NVIDIA's CUDA hardware architecture.

[hammer]

Originally Posted by Bruce Abbott

The A3000+ should have been cancelled. The A3000 was grossly overpriced and the A3000+ would have been no different. Dave Haynie should have been working on an AGA replacement for the A500 (ie. the A1200), and a low cost mid-range machine that would have been ready to go when Bill Sydnes asked for it.

FYI, A3000+ R&D was later recycled and turned into A4000 without Ambre Flicker Fixer, DSP, and SCSI. A4000 kept the 68030 bus from A3000+ and Commodore designed a gimped A3640 card for 68040. A3640 with 68040 has a ~$400 cost with A3000T/030 vs A3000T/040 cost difference.

Before Bill Sydnes's administration, AGA itself was a quick development fork from AAA R&D since Commodore recognized the competition's advancement. Bill Sydnes has a "PC Jr" mentality and promoted ECS beyond its useful competitive life span.

Dave Haynie is responsible for big box Amigas and it's up to Commodore's upper management to allocate human and material resources for A500's replacement.

In the big corporate world, employees must follow management directives. Don't argue against the "boss" e.g. Elon Musk firing engineers who disagree with him in Tesla.

In SpaceX, major shareholders installed mechanical engineer Gwynne Shotwell as president and chief operating officer to balance Elon Musk's direction.

Tesla's major shareholder installed economist Robyn Denholm as chairwoman is less engineering competent when compared to Gwynne Shotwell.

Originally Posted by Bruce Abbott

Commodore needed a more advanced low end model to replace the aging A500, not expensive big box machines. Zorro III was a disappointing compromize (sorry Dave, but it needs to be said). The eventual replacement for the A2000 would have PCI slots as well as Zorro II.

Don't blame Dave Haynie. Understand "big corporate" dynamics i.e. Bill Sydnes' corporate position's role to allocate correct resources and direction.

A2000's Zorro II is 16-bit and it's obsolete since A1200's expansion connector is a 32-bit data bus with a 24-bit memory address from 68EC020 CPU and Budgie is a cutdown 32-bit Super Buster. A1200 is effectively a cutdown A3000+ AGA.

[hammer]

Originally Posted by Bruce Abbott

3D always taxed both the CPU and graphics hardware, but the big problem was that the bar was constantly being raised. A stock Amiga 1000 did an excellent job of reproducing the wireframe 3D in the vector graphics arcade game Star Wars (I played this game a lot at the arcades so it was great to have it on the Amiga). A stock Amiga was also powerful enough to do a good job of solid 3D simulators such as FA-18 Interceptor and Indianapolis 500.

Raytracing is the compute power blackhole.

Throwing RTX 4090 on CyberPunk 2077's raytracing overdrive needs pixel construction ticks from DLSS.

Sub-pixel density for geometry is useless, hence the hardware accelerated geometry culling.

Originally Posted by Bruce Abbott

But of course that wasn't good enough for fans, who wanted more 'realism' - thus the push for texture mapped 3D, more detailed objects, lighting effects, higher frame rates and higher resolution. Hardware could be 1000 times more powerful and still not enough to sate this appetite.

Most modern "big" GPUs from AMD (RX 68x0 XT/RX 7800 XT 16 GB or higher) and NVIDIA (RTX 3080 12 GB/RTX 4070 Ti 12 GB or higher) can handle "traditional" raster-shader 3D at 4K resolution. NVMe 3.0 (~3.5 to 4.0 GB/s) is a requirement for good texture streaming.

Again, raytracing is the compute power blackhole.

Originally Posted by Bruce Abbott

Fixed anything is not good when the demand for more powerful hardware is increasing exponentially.

The original Amiga chipset was 'tightly integrated' in that the CPU shared memory with the chipset in an interleaved fashion that didn't slow it down much. However as soon as you included FastRAM this integration vanished. Now the CPU is independent of the chipset and can go as fast as it wants - which is a good thing for computers, especially when the chipset can do stuff like blitting and line drawing independently while the CPU is doing other things.

Agnus/Alice was designed around 68000's 2-clock cycle memory access issue and it's a mismatch with a 32-bit ALU equipped 68020 CPU with a 32-bit hardware barrel shifter.

A1200 needs 32-bit Fast RAM to enable full performance for 68EC020 and AGA chipset.

Imagine if the 68020/68030 CPU has 1 IPC 32-bit SIMD DSP extension for pack_INT8 and pack_INT16 operations. Only a few instructions are needed for 3D software render while the slower scalar instructions can handle the host OS processing.

Modern X86-64's fastest instructions are the AVX SIMD extensions.

Itanium's VLIW attempted to bring MIMD style into general-purpose compute processing vs the hardware OOOE instruction-level parallelism.

[Bruce Abbott]

Originally Posted by hammer

Rendition Verite v1000's 25 Mhz MIPS-based RISC CPU emulates VGA and it's very slow.

V1000 was an outlier. The exception proves the rule!

PC's Doom delivers a superior perspective parallax effect instead of Amiga's "onion" layered fake parallax effect.

Parallax scrolling

Parallax scrolling is a technique in computer graphics where background images move past the camera more slowly than foreground images, creating an illusion of depth in a 2D scene of distance. The technique grew out of the multiplane camera technique used in traditional animation since the 1930s.

The Amiga's 2D parallax effects are not 'fake', they are an accurate representation of the effect used in traditional animation.

Perspective parallax is a different effect which is inherent to 3D. But Doom didn't do a particularly good job of it. The textures of the mountains in the background are very poor, and appear to be very close, unlike eg. the distant mountains in Shadow of the Beast. The PlayStation had a similar problem with with games like Tomb Raider. Fog or darkness was often applied to hide the limited depth, but It wasn't uncommon to 'hit the sky' at the walls of an 'outside' room.

Originally Posted by hammer

This is Amstrad CPC's problem and there are only 3 million units.

'Only' 3 million units.

This was the PC's problem too. Clone cards used various CRTC chips just like the CPC did. With EGA and VGA it was even more of an issue because CRTC functionality was embedded into custom gate arrays. Many cards were not fully compatible with the original IBM adapters. Some specified 'full register compatibility' as an advantage over other cards that weren't, but sensible coders avoided doing tricky stuff that might break on some cards.

For PCs, being IBM PC compatible is a priority over other wannabe PC standards e.g. TIGA.

TIGA was PC compatible. You see, any card that can be plugged into a PC is PC compatible by definition. Most business PCs in the 80's (and many in the early 90's too) had MDA or Hercules mono. Most games used CGA or EGA. That's a huge incompatibility right there, but nobody said that MDA was a 'wannabe PC standard'.

TIGA was actually the impetus for Microsoft to make Windows graphics card agnostic, a smart move that 'accelerated' the development of more powerful graphics chips because the designers didn't have to worry about being compatible at the hardware level. Graphics card manufacturers then provided drivers as binary 'blobs' that further discouraged banging the hardware directly, giving them total freedom to design it however they liked.

[AmigaHope]

Originally Posted by Bruce Abbott

That's a huge incompatibility right there, but nobody said that MDA was a 'wannabe PC standard'.

Unless I'm mistaken, most textmode software used abstraction to communicate with the display so I think MDA is an exception to the need for hardware compatibility. That's why early non-IBM-compatible MS-DOS machines could still use most textmode software.

[Bruce Abbott]

Originally Posted by AmigaHope

Unless I'm mistaken, most textmode software used abstraction to communicate with the display so I think MDA is an exception to the need for hardware compatibility. That's why early non-IBM-compatible MS-DOS machines could still use most textmode software.

Printing text through the BIOS was horribly slow, especially on a 4.77MHz 8088. Programs that wanted good performance generally wrote directly to video memory. Lotus 1-2-3 is one famous example.

IBM PC compatible

MS-DOS provided adequate functionality for character-oriented applications... However, in order to provide maximum performance and leverage hardware features (or work around hardware bugs), PC applications quickly developed beyond the simple terminal applications that MS-DOS supported directly. Spreadsheets, WYSIWYG word processors, presentation software and remote communication software established new markets that exploited the PC's strengths, but required capabilities beyond what MS-DOS provided. Thus, from very early in the development of the MS-DOS software environment, many significant commercial software products were written directly to the hardware, for a variety of reasons:

- A program that wrote directly to video memory could achieve output rates 5 to 20 times faster than making system calls. Turbo Pascal used this technique from its earliest versions...

- Even for standard business applications, speed of execution was a significant competitive advantage. Integrated software Context MBA... was... very portable but too slow to be truly usable on a PC. [Lotus] 1-2-3 was written in x86 assembly language and performed some machine-dependent tricks. It was so much faster that it quickly surpassed Context MBA's sales.