@Hammer

Quote:

Mehdi Ali is a walking disaster.

FTFY.

He described his time there as "achieving major operational turnaround". Well, that's certainly one way to spin it.

Anyway, I stand by my conviction: All AGA machines, without exception, should've included 1MB (maybe 512K if you really wanted to cheap out) of 32-bit fast ram as standard. The Amiga design philosophy since OCS was that the CPU and custom chips had equal access to memory (which wasn't true of course since the CC would get priority if there was contention). It's clear that this stopped working as soon as any CPU can access every cycle and since the 020 was the minimum pairing for AGA, the only way it can run at full speed is with its own memory.

All this talk about not needing it is basically nonsense and misses the point. If it has existed it would have been used. Show me a game developer that doesn't try use the minimum tools they are given. In the other thread we hear about the feats needed to save precious chip RAM. The idea that fast ram could be used for other things just doesn't enter anyone's thinking because they are so set in the mindset of what was and not what could've been. When did we become so incurious and rigid? Hardly in the Amiga spirit of the computer for the creative mind if you ask me.

Let's take a simple example: Music. Sure, you need chip ram for the samples, but if your patterns are in fast ram you could have many more without wasting chip (also the player code will likely be faster and need less CPU time). Rather than having a fixed sequence you can introduce subtle variations of each pattern that can be switched based on various cues. Action sensitive music suddenly becomes trivial.

Or something else. Reduction of disk swapping by simply caching assets that you do need in chip ram but not *all the time*, cached in fast memory.

No redesign of AGA necessary, just don't ship it with the most gimped CPU setup you can conceive of.

Last edited by Karlos on 09-Oct-2022 at 12:34 PM.
Last edited by Karlos on 09-Oct-2022 at 12:30 PM.

_________________
Doing stupid things for fun...

@All

In the retro demoscene, the AGA chipset is still a beast in the hands of the good coder.

It is actually amazing that after so many years there are still so many people coding to push the AGA machines to their limits.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Not really...

https://www.youtube.com/watch?v=s1lVS4tW33g

its rendered in chunky and converted to planar..
P2C and you waste CPU cycles doing it.
CHIP ram is so slow you time to waste few CPU cycles in between writes.
you can't upscale anything.. too slow..

In old days pre-AGA, there more 2D effects, and no texture mapping, back then there no P2C.

Last edited by NutsAboutAmiga on 09-Oct-2022 at 01:30 PM.
Last edited by NutsAboutAmiga on 09-Oct-2022 at 01:26 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

I don't really understand all the technical aspects of the chipset but as a simple user ...

I voted good/better than most computers, as we are talking 92-93. In reality though AGA machines became available Nov/Dec 92 (late 93 CD32). With the right monitor AGA was good for the price. The monitor issue (few options available that work with all AGA modes & expensive) was very frustrating so that was a big let-down with AGA.

Trouble was by 1994 it was 'barely hanging in there' & by 1995 slow but usable, which it kind of still is to this day if your using it for specific undemanding things or just for a hobby/fun.

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

Quote:

Let's take a simple example: Music. Sure, you need chip ram for the samples, but if your patterns are in fast ram you could have many more without wasting chip (also the player code will likely be faster and need less CPU time).

Lets talk about Amiga music.

The DMA based Amiga design allows music to play basically "for free".
Samples are stored as PCM in chipmemory.
Lets for example say your "tone" to play is 32KB in size.
These 32KB will loaded and player, and mixed by the AMIGA chipset.
This loading used DMA, the CPU does not need to copy the wave.

To play the tone the CPU only needs to do 5 MOVE instruction to the chipset, to tell it do play the note.
This is what I like about Amiga.
The Amiga design is very easy to use.
The Amiga design is super efficient.

All you need to do is 5 assembly instruction and the hardware will play for you the complete audio, and it does not matter if this is 10,000 byte long or 50,000, or 100,000 - you only need 5 instructions to play it.

Playing SNDFX is very easy to code, and need to CPU time. Also a MODplayer needs only a few percent of the 68000 CPU to run. For doing normal AMIGA like modplayer music, you don't need more CPU power. The pattern for a MOD song not need much space, you only a handful of bytes for a song.

In regards of music modplayer, having some MB fastmem would not change much.
I think a greater impact would having more chipmem - as the musician could then use more instruments.

@Gunnar

More chip ram requires a redesigned AGA to implement the sex and free beer 8MB feature which is missing the point I am making. Without changing the overall design of the architecture or driving costs through the roof, the best improvement that could've been made for AGA machines is to have made sure they all had some fast memory installed by default. Your baseline CPU performance alone would be around 4x what the A500 was capable of.

None of the 2MB chip would then be wasted on code, non-media assets and whatever else the OS may have loaded into memory by the time you even load the game because it would all be in fast.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Without changing the overall design of the architecture or driving costs through the roof

You are right. Good point. I fully agree on this.


I personal feeling is, that this was solved already, as you could easily plug very affordable memory expansions.

Hammer Quote:

There's very little IPC difference between 68030 and 68020.

The small 256 byte 68030 data cache avoided the slow memory bus, especially where there was no fast memory. It was enough to significantly lower the cost of local stack/frame variables, stack function args/returns and simple datatypes in memory. The 68030 gained performance over the 68020 with higher clock speed ratings as well.

Hammer Quote:

AGA install base building should have started from Xmas 1991. C) 1992, A1200 with 68EC020-25 (25 Mhz) and apply minor overclock to 28 Mhz like today's PC GPU OC AIB vendors. This SKU includes Fast RAM. This SKU competes against fast 386DX-33-based gaming PCs.

The 68EC020 had fewer address line pins (16MiB max) resulting in a cost savings which was nice. The 68EC030 removed the MMU so the major difference was the data cache, cache bursts and higher clock ratings. The 68020 had chips rated up to 33MHz but the parts with high ratings were often more expensive and/or in limited supply which may not be acceptable for high volume production. The 68030 went up to 50MHz while the 68EC030 stopped at 40MHz. Maybe a 68EC020@28MHz was ok and a 68EC030@28MHz was likely possible although it may have been more advisable to use 33MHz rated parts in cramped Amiga wedge cases (28.36MHz PAL, 28.64MHz NTSC). A 68EC030@28MHz should have competed nicely against the 386DX@33MHz at the low end without breaking the bank.

Hammer Quote:

386DX-25 runs Wing Commander VGA pretty well and this is the entry machine for free Doom shareware taster. Organize time exclusive game bundle deal that uses 68EC020 @ 28 Mhz. Amiga's out-of-the-box Wing Commander bundle is an embarrassment with stock Amiga 1200 since the performance was crap. Nintendo's Wing Commander SNES release was supported by an out-of-the-box SuperFX CPU accelerator in the game cartridge.

Adding expensive chips into cartridges for a single game is not any better logic than including games that performed poorly on the base hardware. The Amiga was much easier to upgrade than the SNES but CBM wouldn't do it. It's like they thought upgrading the hardware was too risky and it might not sell but actually not upgrading the hardware is riskier as it becomes obsolete.

Hammer Quote:

Amiga may have a separate Wing Commander + 68EC020 @ 28 Mhz accelerator bundle SKU for stock Amiga 1200.

It would have made sense to bundle an accelerator with ram like David Pleasance wanted especially for the Wing Commander bundle.

Hammer Quote:

D) 1993, A1200 with 68LC040-25 and Fast RAM. This SKU competes against Apple's Quadra 605 with 68LC040-25 with a $1000 USD price tag and comparable priced 486SX-25/486SX-33-based gaming PCs. These "official" accelerated A1200 SKUs close the gap between entry-level A1200 and A4000/030 (68EC030/68882). Doom-type games don't use FPU.

Sure, but a 68040 based Amiga wouldn't be for the low end base model in 1993. The Amiga should have had a more competitive product here as well but CBM probably wasn't buying enough 68040s to get volume discounts to compete. Amiga customers weren't excited about CBM 68040 accelerators because they were terrible so they bought 3rd party accelerators instead. Multiple 3rd part accelerator producers didn't get large volume discounts like CBM could have. Another CBM opportunity missed.

Hammer Quote:

My approach is to mitigate user base bleed to the PC and SNES platforms and buy enough time for Amiga Hombre.

The Sega Genesis should probably be thrown in with the SNES at well (low cost consoles). It was very popular in the U.S. even though the Amiga CD32 initially outsold the Sega (Genesis) Mega CD in the UK. Hombre would have likely competed in the high end console market with the Sony Playstation, Sega Saturn and 3DO. I'm not sure the Hombre console would have been an Amiga Hombre either although it could have been 3D on top of the Amiga chipset with not too much extra expense.

Hammer Quote:

Commodore's ECS wasn't competitive against Amiga add-on graphics cards with PC SVGA chipsets e.g. EGS 28/24 = Cirrus Logic GD5426 Retina = NCR 77C22E+ Visiona = IMS G300C Piccolo = Cirrus Logic GD5426 Piccolo SD64 = Cirrus Logic GD5434 Rainbow II = Analog Devices ADV7120 Rainbow III = Inmos G365 Domino = Tseng Labs ET4000 Merlin = Tseng Labs ET4000W32 Picasso II = Cirrus Logic GD5426 Tseng Labs ET4000AX ISA comes in either 32-bit DRAM or fast 16-bit VRAM. Tseng Labs ET4000AX ISA with 32-bit DRAM smashed Commodore's ECS into the ground.

Most of those early Amiga Zorro gfx cards were expensive and not that great. Integrated graphics skips the gfx bus bottleneck and eliminates copying bitmaps around but ECS failed to upgrade the basic support of resolutions and colors. Later Amiga gfx cards used Zorro III, had better (V)RAM, had better gfx chips generations ahead of ECS/AGA and had improving RTG software. They were expensive too but at least a big improvement compared to ~1985-1987 OCS/ECS technology and a modest improvement compared to AGA (~1988-1990 technology).

@cdimauro

Quote:

cdimauro wrote: The system clock speed for NTSC Amigas is 7.16 megahertz (PAL Amigas 7.09 megahertz). The clock for the blitter is the system clock.

I think Gunnar is talking about blitter cycle frequency, not the system clock frequency. Blitter operations occur in multiples of 2 system clocks, ie. 3.58MHz.

Blitter Hardware
Quote:

The minimum blitter cycle is four ticks; the maximum is eight ticks. Use of the A register is always free. Use of the B register always adds two ticks to the blitter cycle. Use of either C or D is free, but use of both adds another two ticks. Thus, a copy cycle, using A and D, takes four clock ticks per cycle; a copy cycle using B and D takes six ticks per cycle, and a generalized bit copy using B, C, and D takes eight ticks per cycle. When in line mode, each pixel takes eight ticks.

Quote:

Quote: An OCS game with 5 planes (32 color) had about 37% DMA available for the Blitter. No, it had more. You made a mistake on the calculation because you made a wrong assumption. Here's the reference: https://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html The calculation isn't that easy / straightforward and requires multiple things to be taking into account to get a realistic / real-world value.

Please tell us what the 'real-world' values are (I won't do it myself because as you say it 'isn't that easy' so I would probably get it wrong - and that site is a security risk according to Firefox).

Quote:

However it was very modest. After 7 (SEVEN) years...

And?

Quote:

I think that from 7 to 28Mhz in 7 (SEVEN) years should have been possible. If you take into account how much the chips frequencies increased over that long period.

1984 typical DRAM speed:- 150ns
1992 typical DRAM speed:- 80ns

Not that much faster. To get much faster speeds the DRAM would have to be operated in fast page mode (which is more complicated and has several restrictions) and/or with a wider bus. Doing that while maintaining 100% compatibility would be tricky.

You focus on the time frame as if having a stable hardware platform was a bad thing. Imagine if Commodore constantly released a new chipset as chips got faster. Games would have system requirement like "Requires AAAAA 'fatso' Agnus chip (fitted to A500+++ rev 9b, sold between March 1988 and April 1989)". Except that wouldn't happen much because developers wouldn't want to cut off owners of earlier models, so they would continue coding for the older chipset.

Whenever Commodore made even the smallest change Amiga fans complained about it breaking compatibility, which was a significant problem for a platform with relatively small market and few models. When designing AGA this was uppermost in their minds. How well would the A1200 be received if the majority of existing games wouldn't work on it? Not well. But making radical changes to the chipset was bound to create large incompatibilities. So they avoided making changes that were too radical. Expanding the blitter from 16 to 32 bit would be a big undertaking that could be hard to get right. So they chose the safer option.

As it was a large number of problems did occur during development of the AGA chipset, which is why Commodore kept the hardware details secret and told developers to go through the OS (which knew how to deal with chipset 'bugs'). Even Commodore themselves didn't know the exact details of AGA until it was finalized.

You can moan all you want about the timeframe and level of improvement made, but I won't. I am glad that they didn't do anything too radical. I was sick of having to dump a platform just as I was getting to know it. 35 years later I still have only barely scratched the surface of OCS, and know even less about AGA.

Last edited by bhabbott on 10-Oct-2022 at 03:50 AM.
Last edited by bhabbott on 10-Oct-2022 at 02:21 AM.

@Hammer

Quote:

Hammer wrote: Apple released Quadra 605 with 68LC040-25 for $1000 USD in October 1993.

LC040? Yuk.

Apple released a plethora of under-performing 68k models that confused the market. By 1995 they were practically bankrupt, and only survived because Microsoft bailed them out. Just look at Apple to see where Commodore would have gone if they had continuously released new models as faster chips became available.

Quote:

Real Amiga 4000T, 68040 @ 25 MHz, 12 MB Fast RAM was running Amiga Sprite Engine "Final Fight" at 60 fps.

And the A4000 was no more expensive than similarly equipped name-brand PCs at the time. But customers still didn't buy it because - it wasn't IBM compatible! Which is perfectly understandable when all the latest hot games were being developed for the PC, not for the Amiga. This was not going to change no matter what hardware Commodore produced. The market was shifting. People who had a 'cheap' home computer like the C64 or Amiga 500 were now ready to drop several k on a stonking new 486 - to play games. 5 years earlier they wouldn't have considered it because the PC was perceived as a business machine.

@Karlos

Quote:

Karlos wrote: @Hammer Commodore couldn't even solder the caps on the 3640 the right way round, either. It wasn't their finest product.

According to this site the reversed capacitor issue was caused by an error in the CAD program they used - so not exactly their fault.

Issues like like this are not unheard of, even in famous brands. In the late 1990s to early 2000s a huge quantity of PC motherboards were manufactured with bad capacitors. This capacitor plague also affected other consumer products.

When the A1200 came out I desperately wanted RAM expansion boards for it to sell in my shop. MTEC announced one so I bough 50 of them without evaluating them. Unfortunately I had already sold a few when I discovered they had a nasty bug in the refresh circuit. If the CPU ran code out of Chip RAM only and didn't access Fast RAM for more than ~30 seconds, the refresh would fail and memory would get corrupted. I sent them all back to the European supplier and eventually got replacements that worked.

Armchair designers don't seem to appreciate how hard it is to get complex products like these working properly, especially with the constant pressure to get them out quickly. The list of hardware bugs found in various Amiga models is extensive, and this was not just due to Commodore management not hiring enough engineers. Other companies had similar issues. Acorn screwed up the Christmas release of the Electron because the ULA didn't work properly. The Timex Sinclair 2068 has a horrible kludge in it to clean up bad analog video on its ULA. I could go on, but you get the idea. We are lucky that Commodore managed to fix most of the problems and produce reliable machines that still work 30 years later.

The A3640 wasn't the finest design, but it did the job and was relatively cheap. The RAM speed issue was partly due to putting Fast RAM on the motherboard (a more expensive design would put it on the accelerator card for tighter coupling and fastest access). Of course the owner could always upgrade the card to a faster one as they became available, which they soon did. This continued the tradition of the A2000 with 3rd party manufacturers producing faster cards.

Quote:

The AGA machines had a knack of hobbling the CPU performance at launch.

There is always a tension between performance, price, and development time. Every home computer has suffered from one compromise or another, and many have had serious hardware bugs that reduced performance. The C64 is perhaps one of the worst. Due to bug in the 6522 VIA used in the VIC20, the IEC port had to be bitbanged - which made the floppy drive much slower. The later VIAs used in the C64 didn't suffer from this bug, but they were stuck with bitbanging for compatibility. In the C64 it was even worse though, because those lovely sprites etc. blocked the CPU on some video lines, making disk transfer speeds even slower. This problem could have been sorted out if they had more time, but they didn't.

In the end the C64 beat the competition despite its horribly slow drive, and 3rd parties found ways to speed it up. The most peculiar thing about this flaw is that it makes the C64 more interesting to retro enthusiasts. It is very satisfying to install JiffyDOS and revel in the newfound huge speed up obtained, whereas if it ran at full speed originally there would be nothing to do and no sense of achievement. Similarly with the Amiga, many of us enjoy 'souping up' our machines to levels of performance or features that some think it should have had in the first place.

@Gunnar

Quote:

Gunnar wrote: Quote: Let's take a simple example: Music. Sure, you need chip ram for the samples, but if your patterns are in fast ram you could have many more without wasting chip (also the player code will likely be faster and need less CPU time). Lets talk about Amiga music. The DMA based Amiga design allows music to play basically "for free". Samples are stored as PCM in chipmemory. Lets for example say your "tone" to play is 32KB in size. These 32KB will loaded and player, and mixed by the AMIGA chipset. This loading used DMA, the CPU does not need to copy the wave. To play the tone the CPU only needs to do 5 MOVE instruction to the chipset, to tell it do play the note. This is what I like about Amiga. The Amiga design is very easy to use. The Amiga design is super efficient. All you need to do is 5 assembly instruction and the hardware will play for you the complete audio, and it does not matter if this is 10,000 byte long or 50,000, or 100,000 - you only need 5 instructions to play it. Playing SNDFX is very easy to code, and need to CPU time. Also a MODplayer needs only a few percent of the 68000 CPU to run. For doing normal AMIGA like modplayer music, you don't need more CPU power. The pattern for a MOD song not need much space, you only a handful of bytes for a song. In regards of music modplayer, having some MB fastmem would not change much. I think a greater impact would having more chipmem - as the musician could then use more instruments.

The main reason for the Amiga custom chip's hardware acceleration is due to the 68000 CPU is pretty weak for the intended performance target and the concept for multimedia-enhanced general-purpose CPU wasn't in Motorola's 68K roadmap.

For the Amiga Hombre chipset's Nathaniel features the following:
1. +100 Mhz 64-bit PA-RISC CPU IP includes 64-bit SIMD and is modified with graphics processing-related instructions. Special Function Unit (SFU) SIMD extension for rasterizing multiple pixels with a single 64-bit operation.

2. DMA engine and Blitter with fixed-point (integer) arithmetic 3D texture mapping and Gouraud shading using trapezoids as primitives.

3. 64-bit RISC-like Copper co-processor.

4. 16-bit resolution sound processor with twelve voices.

5. Similar to Playstation 3D performance level-like solution with an OpenGL target.

6. Floating Point Register file is included. Full double precision floating point unit seems to be optional, hence Commodore targeted single precision floating point format like in modern gaming PC GPUs. HPC GPU has better double-precision floating point support.

Amiga Hombre chipset is a 64-bit 3D game console that can be reused for a desktop computer.

----
Modern PC GPU has multiple fixed functions rasterizing Z-buffer hardware and texture units and these are the main fundamental differences between GPU and DSP e.g. CELL SPUs.

PC GPU development path was heavily influenced by SGI and PC OpenGL/Direct3D cloners targeted mainstream price targets. Due to GLQuake's influence, the gaming PC has assimilated SGI characteristics.

OpenGL was replaced by the Vulkan API which was based on AMD/EA DICE Mantle API that was influenced by PS4 and Xbox One low-level graphics APIs.

Like later AMD Mantle API, EA has contributed middleware software for the Amiga and 3DO platforms.

Recent PC GPUs include BVH hardware for BVH accelerated raytracing and Tensor cores.

Like the Amiga, modern PC hardware evolution is driven by gaming PC and game console markets. All major recent PC hardware development is driven to close the ecosystem gap between game consoles and gaming PC. Microsoft's Xbox team handles all Windows client R&D while Valve's SteamOS handles WIndows DirectX-based gaming on Linux-Vulkan via Valve's Proton.

Intel's CPU development such as Golden Cove's improvement is mostly driven by the quest for a strong single-thread and low-latency "PC gaming CPU" and it's the same for AMD Zen 4's design direction.

Intel ARC GPU development is also mostly driven by the gaming PC market and associated productivity toolchains e.g. Blender 3D, Unreal 3D and 'etc'. It's the same for NVIDIA's CUDA and AMD's rDNA 3's design directions.

In summary, PC gaming is one of the major core drivers for AMD's, Intel's, and NVIDIA's design improvements.

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

@matthey

Quote:

The small 256 byte 68030 data cache avoided the slow memory bus, especially where there was no fast memory. It was enough to significantly lower the cost of local stack/frame variables, stack function args/returns and simple datatypes in memory. The 68030 gained performance over the 68020 with higher clock speed ratings as well.

256 bytes is too small for a noticeable difference. IPC is for instructions per clock and I'm aware of 68030's higher clock speed.

Competent 030 and 020 accelerators have competent Fast RAM designs. An incompetent 030 CPU (de)accelerator product without Fast Memory will be driven off the market.


Quote:

Adding expensive chips into cartridges for a single game is not any better logic than including games that performed poorly on the base hardware

SuperFX's 16-bit RISC design wasn't expensive.


Quote:

Most of those early Amiga Zorro gfx cards were expensive and not that great. Integrated graphics skips the gfx bus bottleneck and eliminates copying bitmaps around but ECS failed to upgrade the basic support of resolutions and colors. Later Amiga gfx cards used Zorro III, had better (V)RAM, had better gfx chips generations ahead of ECS/AGA and had improving RTG software. They were expensive too but at least a big improvement compared to ~1985-1987 OCS/ECS technology and a modest improvement compared to AGA (~1988-1990 technology).

There are economies of scale issues. PC's S3 Tro 64 and ET4000AX were cheap while Amiga equivalence is costly.

_________________
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: The main reason for the Amiga custom chip's hardware acceleration is due to the 68000 CPU is pretty weak for the intended performance target and the concept for multimedia-enhanced general-purpose CPU wasn't in Motorola's 68K roadmap.

This is total crap. The 68000 was much more powerful than other CPUs of the day. Compare it to the 8088 that IBM chose for the PC (they considered the 68000 but it was too expensive, not available in large quantities, and not so easy to port 8080 code to). The 68000 was chosen by manufacturers of workstations who saw its potential for a mainframe-like OS.

When the Amiga was designed the term 'multimedia computer' didn't exist. The Amiga's combination of powerful CPU and efficient hardware showed that it was possible.

Quote:

For the Amiga Hombre chipset's Nathaniel features the following: 1. +100 Mhz 64-bit PA-RISC CPU IP includes 64-bit SIMD and is modified with graphics processing-related instructions. Special Function Unit (SFU) SIMD extension for rasterizing multiple pixels with a single 64-bit operation.

Hombre was little more than a concept - a flawed concept because it relied on very specific hardware at a time when the computer industry was moving to commodity hardware. Hombre was trying to make the Amiga into yet another proprietary platform that would fail.

Quote:

Modern PC GPU has multiple fixed functions rasterizing Z-buffer hardware and texture units and these are the main fundamental differences between GPU and DSP e.g. CELL SPUs. [snip] In summary, PC gaming is one of the major core drivers for AMD's, Intel's, and NVIDIA's design improvements.

All irrelevant. What modern PCs are doing is of no interest to retro computer fans. We are here because we don't want to keep up with the latest developments. We just want to do some cool stuff on our 25 year old machines, like we did when they were new.

@bhabbott

Quote:

All irrelevant. What modern PCs are doing is of no interest to retro computer fans. We are here because we don't want to keep up with the latest developments. We just want to do some cool stuff on our 25 year old machines, like we did when they were new.

Thanks for speaking for the rest of us. Just as I was struggling to articulate why it is that I frequent this forum.

_________________
All the way, with 68k

@Hammer

Quote:

Hammer wrote: There are economies of scale issues. PC's S3 Tro 64 and ET4000AX were cheap while Amiga equivalence is costly.

Ah yes, the S3 Trio, one of the most over-hyped and disappointing 'graphic accelerator' cards for the PC.

Economy of scale was an issue for sure. The market for PC graphics cards was way larger, so amortized development cost was much lower. Many Amiga RTG cards used PC graphics chips, and some used entire cards. But Amiga hardware manufacturers didn't have the purchasing power to get the chips as cheaply (if at all), and even a simple bus adapter card might cost more to produce than the actual graphics card itself. Add in the usual advertising costs etc. and the retail price balloons.

This had nothing to with the Amiga specifically, it would have affected any platform with a smaller market share. But it didn't actually matter because most of those who needed an RTG card had the money and could justify the price. Only the low end missed out, and that was full of users so 'poor' that they couldn't even justify buying games for their stock machines.

But the AGA chipset was still good 'bang for the buck' when you consider that it wasn't just a graphics chipset. It was also a sound card, a floppy drive controller that could do all kinds of interesting formats, a DRAM controller, serial port etc. It was the equivalent of the integrated chipsets found in PC motherboards today. As such it provided a hardware standard for the Amiga that could be relied upon, rather than the PC's plethora of cards that didn't always play nice. That was very important for a platform with smaller market.

"Yeah but", you say, "AGA didn't have the power of S3 Trio etc., so it was no good even if cheap". No good for games that also needed a Pentium class CPU and loads of RAM, yes. But plenty good enough for the kinds of games that a stock A1200 could realistically run. And plenty good enough to have lots of fun with!

If only Amiga fans could purge their PC envy they might start to enjoy the Amiga instead of spending all their time making irrelevant comparisons.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Again: totally irrelevant. The most sold Amigas where the 500, 600 and 1200. Your A500 and A600 remark is irrelevant to this topic.

Which topic? I was talking about what developers should care of: the most common / sold Amiga platforms.

This is the only thing which matters.
Quote:

Why don't you look at AIBB's MemTest benchmark for A1200-NF and A4000/040? http://amiga.resource.cx/perf/aibb.pl?amiga=1200&testgroup=int&testgroup=float&order=mem&ref=a1200 MemTest Amiga 1200/NF scored 1.0 (reference) Amiga 4000/040 with A3640 scored 1.23 VS A1200's Fast RAM add-ons and 68020 CPU accelerators DKB 1202 with just stock 68020 @ 14 Mhz and DKB s Fast RAM design scored 2.17 Blizzard 1200 with just stock 68020 @ 14 Mhz and Phase 5's Fast RAM design scored 2.17 Blizzard 1220 with just 68020 @ 28 Mhz and Phase 5's Fast RAM design scored 3.63 ACA 1220 with 68020 @ 20 Mhz with ACA's Fast RAM design scored 3.04 ACA 1220 with 68020 @ 33 Mhz with ACA's Fast RAM design scored 4.22

Again: irrelevant.
Quote:

My WinUAE's A1200 with Fast Memory expansion approximation [REMOVED THE BIG IMAGE] When comparing my WinUAE's A1200 with Fast Memory expansion approximation, ACA 1220's Fast RAM implementation is FASTER

Are you kidding? ACA had FASTER processors AND memories! So this is OBVIOUS!!!

Bah...

@Gunnar

Quote:

Gunnar wrote: @cdimauro My friend Cesare Di Mauro, The AMIGA has many clocks, 28Mhz, 14MHz, 7Mhz, 3.5Mhz Even with the 28MHz clock effectively the Amiga DMA system runs on 3.5 MHz. The Blitter does all its "work" on these 3.5 clock event. The Blitter is part of AGNUS Amiga chip. AGNUS has all clocks connected.

I know it, but there's an additional clock: the E-clock (0.7Mhz).

Anyway, not relevant here.
Quote:

Quote: The system clock speed for NTSC Amigas is 7.16 megahertz (PAL Amigas 7.09 megahertz). The clock for the blitter is the system clock. The Blitter needs for each operation: 8 clock at 28.0 MHz 4 clock at 14.0 MHz 2 clock at 7.0 MHz 1 clock at 3.5 MHz

I've just reported what the Amiga Hardware Manual said about the specific question.
Quote:

Quote: No, it had more. You made a mistake on the calculation because you made a wrong assumption. Here's the reference: https://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html The calculation isn't that easy / straightforward and requires multiple things to be taking into account to get a realistic / real-world value. The DMA calculation depends on many factors, how big is the Copperlist, does the game use Overscan? There is never only one correct result - its game depending. As ballpark result my numbers are good.

I know that there are different scenarios, but your numbers are still not real/realistic. Yesterday evening I spent some free time to get some concrete data.

I'm assuming a very simple scenario which is also, more or less, the BEST case.
I assume that the game / demo has a 320 screen (NTSC or PAL) with no overscan and no scrolling and using 5 bitplanes.
I assume that one full raster line was used by the Copper to setup all display (colors, bitplane registers, etc.). I can also remove that from the calculations, but it's just one raster line and it's also typical on the Amiga.
I also assume that all 4 audio channels are used (which is typical use case).
Besides that, there is the usual memory refresh DMA slots that are always used.

I think that it make sense and it's very close to the reality. At least as best case scenario for the Blitter and available slots for it.

Now the numbers (per single frame):

NTSC (200 lines):
Total slots	59212
Used slots	21818
Free slots	37394
Free slots (percentage)	63%
Free slots per bitplane	13%

PAL (256 lines):
Total slots	70512
Used slots	27866
Free slots	42646
Free slots (percentage)	60%
Free slots per bitplane	12%

AGA FMode 3 (64-bit fetch), 5 bitplanes, NTSC (200 lines):
Total slots	59212
Used slots	6818
Free slots	52394
Free slots (percentage)	88%
Free slots per bitplane	18%

AGA FMode 3 (64-bit fetch), 5 bitplanes, PAL (256 lines):
Total slots	70512
Used slots	8666
Free slots	61846
Free slots (percentage)	88%
Free slots per bitplane		18%

AGA FMode 3 (64-bit fetch), 8 bitplanes, NTSC (200 lines):
Total slots	59212
Used slots	9818
Free slots	49394
Free slots (percentage)	83%
Free slots per bitplane		17%

AGA FMode 3 (64-bit fetch), 8 bitplanes, PAL (256 lines):
Total slots	70512
Used slots	12506
Free slots	58006
Free slots (percentage)	82%
Free slots per bitplane		16% 

NTSC:
Slots needed per 7 bitplanes	88%
Slots needed per 8 bitplanes	101%

PAL:
Slots needed per 7 bitplanes	85%
Slots needed per 8 bitplanes	97%

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Mehdi Ali is a walking disaster. FTFY. He described his time there as "achieving major operational turnaround". Well, that's certainly one way to spin it. Anyway, I stand by my conviction: All AGA machines, without exception, should've included 1MB (maybe 512K if you really wanted to cheap out) of 32-bit fast ram as standard. The Amiga design philosophy since OCS was that the CPU and custom chips had equal access to memory (which wasn't true of course since the CC would get priority if there was contention). It's clear that this stopped working as soon as any CPU can access every cycle and since the 020 was the minimum pairing for AGA, the only way it can run at full speed is with its own memory. All this talk about not needing it is basically nonsense and misses the point. If it has existed it would have been used. Show me a game developer that doesn't try use the minimum tools they are given. In the other thread we hear about the feats needed to save precious chip RAM. The idea that fast ram could be used for other things just doesn't enter anyone's thinking because they are so set in the mindset of what was and not what could've been. When did we become so incurious and rigid? Hardly in the Amiga spirit of the computer for the creative mind if you ask me. Let's take a simple example: Music. Sure, you need chip ram for the samples, but if your patterns are in fast ram you could have many more without wasting chip (also the player code will likely be faster and need less CPU time). Rather than having a fixed sequence you can introduce subtle variations of each pattern that can be switched based on various cues. Action sensitive music suddenly becomes trivial.

Gunnar already replied and I agree with him.

Now I ask you: do you think that we, developers, didn't used the slow-mem (and fast-mem)? Yes, we did it! How do you think that Fighin' Spirit (and USA Racing) provided so much graphics and sound effects? The 512kB where absolutely NOT enough for keeping all that stuff!

But the problem is that such ram was NOT accessible by the chipset. So, we were forced to use the CPU to transfer memory from slow to chip mem (because the Amiga has no DMA for doing copy operations, like PCs), wasting A LOT of CPU time.

That's the point.

Having had MORE chip ram would have allowed us to have better effects or more fluid games.
Quote:

Or something else. Reduction of disk swapping by simply caching assets that you do need in chip ram but not *all the time*, cached in fast memory.

We did it as well.
Quote:

No redesign of AGA necessary, just don't ship it with the most gimped CPU setup you can conceive of.

Also, but it then becomes more expensive...

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: The system clock speed for NTSC Amigas is 7.16 megahertz (PAL Amigas 7.09 megahertz). The clock for the blitter is the system clock. I think Gunnar is talking about blitter cycle frequency, not the system clock frequency. Blitter operations occur in multiples of 2 system clocks, ie. 3.58MHz. Blitter Hardware Quote: The minimum blitter cycle is four ticks; the maximum is eight ticks. Use of the A register is always free. Use of the B register always adds two ticks to the blitter cycle. Use of either C or D is free, but use of both adds another two ticks. Thus, a copy cycle, using A and D, takes four clock ticks per cycle; a copy cycle using B and D takes six ticks per cycle, and a generalized bit copy using B, C, and D takes eight ticks per cycle. When in line mode, each pixel takes eight ticks. Quote: [quote]An OCS game with 5 planes (32 color) had about 37% DMA available for the Blitter. No, it had more. You made a mistake on the calculation because you made a wrong assumption. Here's the reference: https://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html The calculation isn't that easy / straightforward and requires multiple things to be taking into account to get a realistic / real-world value.

Please tell us what the 'real-world' values are (I won't do it myself because as you say it 'isn't that easy' so I would probably get it wrong - and that site is a security risk according to Firefox). [/quote]
Np. I did all calculations. Enjoy...
Quote:

Quote: However it was very modest. After 7 (SEVEN) years... And? Quote: I think that from 7 to 28Mhz in 7 (SEVEN) years should have been possible. If you take into account how much the chips frequencies increased over that long period. 1984 typical DRAM speed:- 150ns 1992 typical DRAM speed:- 80ns

I was NOT talking about memory but it was about processors.
Quote:

Not that much faster. To get much faster speeds the DRAM would have to be operated in fast page mode (which is more complicated and has several restrictions) and/or with a wider bus. Doing that while maintaining 100% compatibility would be tricky.

That's the point and it was possible.

And there's also another solution which doesn't required to have a 32-bit or 64-bit Blitter to use it. Just thing about it, and maybe you'll get it.

But it was fundamental to have a Blitter operating with much higher frequencies. Which was possible at the time.
Quote:

You focus on the time frame as if having a stable hardware platform was a bad thing. Imagine if Commodore constantly released a new chipset as chips got faster. Games would have system requirement like "Requires AAAAA 'fatso' Agnus chip (fitted to A500+++ rev 9b, sold between March 1988 and April 1989)". Except that wouldn't happen much because developers wouldn't want to cut off owners of earlier models, so they would continue coding for the older chipset. Whenever Commodore made even the smallest change Amiga fans complained about it breaking compatibility, which was a significant problem for a platform with relatively small market and few models. When designing AGA this was uppermost in their minds. How well would the A1200 be received if the majority of existing games wouldn't work on it? Not well. But making radical changes to the chipset was bound to create large incompatibilities. So they avoided making changes that were too radical. Expanding the blitter from 16 to 32 bit would be a big undertaking that could be hard to get right. So they chose the safer option. As it was a large number of problems did occur during development of the AGA chipset, which is why Commodore kept the hardware details secret and told developers to go through the OS (which knew how to deal with chipset 'bugs'). Even Commodore themselves didn't know the exact details of AGA until it was finalized.

Again? It took SEVEN years for the AGA, and it was crap!
Quote:

You can moan all you want about the timeframe and level of improvement made, but I won't. I am glad that they didn't do anything too radical. I was sick of having to dump a platform just as I was getting to know it. 35 years later I still have only barely scratched the surface of OCS, and know even less about AGA.

Bah... you're a parrot.