@bhabbott

You have a lot of variables in your methodology. I would have stated by not doing any C2P or copy at all, just let the game render into it's fast buffer and time that. Call this the basic render time.

Compared to the normal game, this allows you to determine the actual fraction of the total time "preparing for screen" which in this case is the C2P step.

Next, try it with just copying the chunky pixels to the chip ram, which is your theoretical best "copy speed" routine.

Invert FPS rate to get time per frame for the three values (render, render + C2P, render + copy).

You can deduct the basic render time from each result and you are left with a reasonable estimate of the pure C2P step and the pure copy step in each case.

-edit-

One other thing to note, you are comparing the 020/Fast/Akiko to the 020/Blitter C2P code running on an 030. I don't know that this is an optimum C2P solution for 030/28MHz. The routine I tested was specifically tuned for best possible performance on 030. It's possible higher frame rates could've been achieved with this or another C2P method.

Last edited by Karlos on 11-Dec-2024 at 07:50 PM.
Last edited by Karlos on 11-Dec-2024 at 03:30 PM.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

bhabbott wrote: @Karlos Quote: Karlos wrote: Right, you will forgve me for my skepticism here, but here are the results from a range of C2P scenarios, conducted on a real 030 accelerator for CD32. It's an oddball being clocked at ~70MHz but if you have found a copy-speed, or even near-copy-speed C2P routine for 256 colour mode, you need to share it with the world. I for one would be extremely interested! Note how I said "practically copy speed in Doom". Here are my results (DoomAttack, timedemo3):- "c2p_optimized" (normal AGA c2p routine) - 10.1 fps "fake chunky" (copy FastRAM to ChipRAM) - 10.85 fps, 7% faster. "fake RTG" (copy FastRAM to FastRAM) - 12.65 fps, 25% faster "Fake RTG" direct (no copy) - 13.27 fps, 31% faster So direct copy made the game go 7% faster, practically unnoticeable. Not shown here is blitter-assisted c2p, which on my machine was the same frame rate as a direct copy (measured 10.93 fps). FYI, here are some results for a CD32 with 8MB FastRAM compared to an A1200 with 28MHz 030:- Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps) Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps) Amiga A1200 030/28Mhz 64Mb (Optimised 020 C2P) - 17732 realtics (4.2 fps) Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps) So using Akiko increased the frame rate by 49%, making it as fast as an A1200 with 28MHz 030.

DoomAttack also supports Graffiti's chunky pixels.

DoomAttack's benchmark should be able to Graffiti chunky pixels without the addon Graffiti decoder.

Last edited by Hammer on 11-Dec-2024 at 01:03 PM.

_________________
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

I don't think Graffiti was as simple as a proper chunky linear framebuffer. If memory serves, you had to configure a number of bit planes and logically adjacent "chunky" pixel bytes were spread over them.

_________________
Doing stupid things for fun...

@Karlos

VGA Mode X's chunky pixels are spread across four planes since VGA's video memory wasn't fast enough. VGA Mode X processes four pixels in parallel via VGA's four-plane oriented hardware.

--------------
For Graffiti's chunky pixels via 4 bitplanes

1st pixel is byte 0 in bitplane 0
2nd pixel is byte 0 in bitplane 1
3rd pixel is byte 0 in bitplane 2
4th pixel is byte 0 in bitplane 3

5th pixel is byte 1 in bitplane 0
6th pixel is byte 1 in bitplane 1
7th pixel is byte 1 in bitplane 2
8th pixel is byte 1 in bitplane 3

9th pixel is byte 2 in bitplane 0
and 'etc'.

The concept is similar to VGA four-plane chunky pixels parallel processing. Extra raster decoder hardware is needed for Graffiti's chunky pixels.

VGA has extra hardware to translate the CPU's sequential writes to four parallel pixel writes with four ALU operations applied to them. Graffiti with C= Amiga chipset doesn't have VGA's extra translation hardware, hence it would be software-driven.

Reference
https://wiki.icomp.de/wiki/Graffiti

Graffiti raster decoder allows OCS/ECS/AGA Amigas to display chunky pixel 256 colors which is largely bounded by Chip RAM / DMA slots bandwidth.

Both VGA and Amiga have to work around with the slow memory performance.

IBM has C2P experience with EGA and figured out an improved design for VGA.

Without the C65 engineer's distraction (wasting about 1 year on C65 R&D), AAA with 32-bit FP DRAM configuration would be AA500+ and CD32.

32-bit AAA with 32-bit FP DRAM configuration is backward compatible with Amiga OCS. AAA has chunky pixels.

An engineer from the LSI group (supported C65) created the technical specifications for AA while the bulk of the Amiga group's engineers focused on AAA and Hombre.

Hombre recycled AAA display IP with Amiga OCS backward compatibility removed.

Corporate mismanagement is a major issue for Commodore.

The information about the 4MB requirement for chunky pixels from https://en.wikipedia.org/wiki/AA%2B_Chipset is a load of BS.
The person who wrote "Commodore did not add chunky pixels to AGA at the time because RTG required at least 68020 (not 68EC020 as in A1200) with 4 MB memory at least" is BS.

Refer to Commodore - The Final Years book.

-------------------

Last edited by Hammer on 12-Dec-2024 at 12:26 AM.
Last edited by Hammer on 11-Dec-2024 at 11:24 PM.
Last edited by Hammer on 11-Dec-2024 at 11:22 PM.
Last edited by Hammer on 11-Dec-2024 at 11:15 PM.

_________________
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

@Hypex
From Commodore - The Final Year,

Quote:

Meeting with Mehdi After Mehdi Ali became President of Commodore International, he had begun taking over other departments within the company but had left engineering alone. In August of 1989 he began to engage with engineering. He asked Jeff Porter and Henri Rubin to present an overview of the engineering department history, showing the total expense by year, number of engineers, and sales from 1984 to 1990. Porter seized the opportunity to push for a larger budget and more engineers for his department. Commodore typically spent 2% of its sales on Research & Development. In 1989, the engineering department had 101 employees and a total budget of $17.5 million. Estimating $1 billion in sales for 1990, Porter proposed a 3% spend on R&D with a $25.3 million budget and 141 employees. It was a massive increase from the previous year but still well below the $46.5 million budget of 253 engineers under Marshall Smith in 1985. (Skip) Linda, Monica, and Mary were supposed to be done in the summer of 1989, but by September they were not even close. It became clear the AAA chipset was not running on schedule. “It was just very complex,� explains Ed Hepler. “Complex chips like that take two or three years to develop and compared to other companies, we had a very limited staff working on things.� (Skip) Although Victor Andrade was supposed to have been working on AAA all year, he had instead been working on the 4510 chipset until the middle of October 1989, at which time he began on AAA. By then it was clear they could not meet the early 1990 schedule for working silicon. With only two engineers per chip (and not dedicated ones at that) it would be impossible to meet the schedule. “There is usually one designer, one circuit designer, and one layout person per chip and that's sort of how things went,� says Hepler. “If you look at the way companies build chips these days, there are far more people working on a chip than back then.� Commodore could have made a comparatively minor R&D investment by hiring three new chip engineers, which would cost the company in the neighborhood of $200,000 per year to deliver the chips on time. For some reason, that never happened.

Commodore didn't hire or allocate enough chip engineers for AAA e.g. C65 distraction.


------------------

For comparison with NVIDIA's 1996 year, Huang laid off more than half of Nvidia's employees—then around 100—and focused the company's remaining resources on developing a graphics accelerator product optimized for processing triangle primitives: the RIVA 128. By the time the RIVA 128 was released in August 1997, Nvidia was down to about 40 employees and only had enough money left for about one month of payroll.

Despite Nvidia's disappointing failure to deliver on its Dreamcast contract, Irimajiri somehow managed to convince Sega's management to invest $5 million into Nvidia. Years later, Huang explained that this was all the money Nvidia had left at the time, and that Irimajiri's "understanding and generosity gave us six months to live".

Last edited by Hammer on 12-Dec-2024 at 12:43 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: [quote]Commodore didn't hire or allocate enough chip engineers for AAA e.g. C65 distraction.

Would more engineers have helped? I doubt it. IMO two engineers working on each chip was already too many.

The real problem was that the AAA spec was too ambitious. They should have started with AA or less, and built on that if necessary. Then It could been out in 1990 instead of ECS.

It would have:-
- 8 bitplanes - usable for 256 colors, dual playfield, HAM8.
- HAM6/8 in hires.
- 8-bit chunky.
- 18 or 24 bit color palette.
- 64 pixel wide 16 color sprites.
- No 31kHz modes. Instead it would have a tightly-coupled scan-doubler option that made all screen modes work on a VGA monitor.

Paula would get a buffered serial port.

With those reduced specs they would be able to get it out quickly without distracting engineers from other projects. They also wouldn't have engineers working on the A3000 and CDTV.

The C65 would be treated similarly. It would have 16 color chunky screen modes and a 4096 color palette - but not 256 colors with 8 bitplanes - so it wouldn't compete against the Amiga. It would be released in 1989.

This would all be done with a minimum number of engineers per chip. Other engineers would be working on the computers to put them in. They would all be working towards getting machines out by critical dates, not messing around adding extra features or making side projects... in an ideal world.

Of course in the real world that didn't happen, and it was all the fault of the engineers who were too busy trying to create what they wanted, not what the market wanted. Then they blamed their failure on management - which, in a way, was true. Management put too much trust in their engineers. When management cracked the whip they did good, as we saw with the A500 and A1200.

@Karlos

Quote:

Karlos wrote: @bhabbott You have a lot of variables in your methodology.

Nope. I kept the variables to a minimum.

I was only interested in the effect it would have on Doom. Other uses would just muddy the waters, and concentrating purely on c2p time would be misleading. Real world applications are what matter.

Quote:

I would have stated by not doing any C2P or copy at all, just let the game render into it's fast buffer and time that. Call this the basic render time.

I did that. You can calculate back from those times if you want, but it makes no difference. I show the results relative to the stock c2p routine because the question is how much better might chunky, RTG, direct to FastRAM etc. be, not how much slower is what we actually have than theoretical alternatives.

Quote:

Invert FPS rate to get time per frame for the three values (render, render + C2P, render + copy).

I don't care about time per frame for each contributor, only the resulting frame rate.

Quote:

One other thing to note, you are comparing the 020/Fast/Akiko to the 020/Blitter C2P code running on an 030. I don't know that this is an optimum C2P solution for 030/28MHz. The routine I tested was specifically tuned for best possible performance on 030. It's possible higher frame rates could've been achieved with this or another C2P method.

On my A1200 with Blizzard 1230-IV and 60ns RAM blitter c2p is slightly faster than regular c2p. As you say, this could be different on other boards.

I can only test what I have. Other people are welcome to do their own tests and publish the results. However to be 'apples to apples' it has to be DoomAttack with Timedemo 3 in standard settings (320x200 NTSC or PAL, high detail, 2 steps down from max window size, 2134 gameticks).

Unfortunately, though many Amiga fans must have CD32s and/or A1200s with suitable hardware, few have felt like sharing so far. I guess that means it isn't that important to them. Fair enough. Back in the day it wasn't important to many of us because we didn't have Doom and there were plenty of good games to play that didn't need c2p.

@bhabbott

It matters if you are trying to prove there's an "almost copyspeed C2P for 030", which is what led to this tangent. A routine is either (almost) copyspeed or it isn't. Running as part of a complex application I don't know how you can draw solid results reliably on a single component, compared to testing that component in isolation.

I accept your benchmark results, I just don't accept the conclusion drawn from them. The fact is that the contributions to the time per frame for rendering and conversion don't necessarily scale linearly and certainly not proportionally as the clock speed increases. The Akiko workflow adds a fixed performance limit that your 020 doesn't hit, but a fast 030 does. The time taken to read a frames worth of data from fast, stream it in and out of Akiko and then onto chip ram all using the CPU is bandlimited first by the custom chips bus to/from Akiko and then by the contended writes to chip ram.

As your CPU performance increases this chunk of time approaches an immovable constant while your render time per frame gets smaller. In short, the time per frame you spend doing the C2P becomes more and more important.

It was clear from the benchmarking results I had ran when trying to work out if Akiko would help TKG on 030/CD32 that software C2P on the 030 surpasses it but it was equally clear from the benchmark that said software C2P was not copy speed either. When you do get to copyspeed on 040/060 it's almost all down to the speed of code running in the cache, working on data in the cache and confronted with the fundamental write speed limit of chip ram.

I'd be interested to see the same tests run on your two configurations. It will only attempt the Akiko test if it's found - though you might want to comment out the cache manipulation (disabled write allocation during conversion, else Akiko read back is wrong) on 020 as the test was designed for 030 as that was specifically my target.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

Would more engineers have helped? I doubt it. IMO two engineers working on each chip was already too many. The real problem was that the AAA spec was too ambitious. They should have started with AA or less, and built on that if necessary. Then It could been out in 1990 instead of ECS.

1. You missed "not dedicated ones at that".

2. You missed "Victor Andrade was supposed to have been working on AAA all year, he had instead been working on the 4510 chipset until the middle of October 1989".

AAA lacks focused development.

After the NV2 debacle, 1996 NVIDIA focused on RiVA 128 (NV3)'s development.

Last edited by Hammer on 12-Dec-2024 at 11:27 PM.
Last edited by Hammer on 12-Dec-2024 at 11:24 PM.

_________________
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

@Karlos

Quote:

Karlos wrote: @bhabbott It matters if you are trying to prove there's an "almost copyspeed C2P for 030", which is what led to this tangent.

This isn't a tangent - it directly relates to the OP, who asks if the Amiga could have supported chunky pixels in hardware with 'minimal' changes. The relevance is that Akiko was indeed a hardware solution involving 'minimal' changes, and yet once the CPU performance gets to 50MHz 030 level the difference between it and a purely software solution is nil to negative.

But would a less 'minimal' hardware change have been good enough to justify developing it? Again it comes down to whether you think a 7% real-world improvement is worth it. IMO from a performance perspective it doesn't, because the difference is so small as to be practically unnoticeable. Still, having a 'proper' chunky mode would be cool, even it didn't make much difference in practice. Once in there it could be improved (by eg. increasing ChipRAM bandwidth).

Quote:

As your CPU performance increases this chunk of time approaches an immovable constant while your render time per frame gets smaller. In short, the time per frame you spend doing the C2P becomes more and more important.

True, but so does the time for a straight copy. For a hardware chunky mode to be useful it has to offer more than '7% faster frame rate in Doom'. I would say that yes, it does offer more - but more for the convenience and perception of suitability than performance. If the Amiga had a chunky hardware mode then John Carmack might have looked at it more favorably.

Quote:

It was clear from the benchmarking results I had ran when trying to work out if Akiko would help TKG on 030/CD32 that software C2P on the 030 surpasses it... I'd be interested to see the same tests run on your two configurations. It will only attempt the Akiko test if it's found - though you might want to comment out the cache manipulation (disabled write allocation during conversion, else Akiko read back is wrong) on 020 as the test was designed for 030 as that was specifically my target.

You want me to try TKG on my A1200? I did try Alien Breed 3D on it once, though I don't remember which version that was. Unfortunately I didn't find the game compelling enough to keep it. However if getting it running on my machine isn't too onerous I will give it go.

Thanks for encouraging me to try something I otherwise wouldn't have. This is what retro-computing is all about!

@Hypex

Quote:

Hypex wrote: Taking the above into consideration I think the best way to achieve it and be easily engineered into the design was a direct mode that skipped the parallel to serial conversion altogether and read it directly from the plane. This would have placed a direct colour index into the hardware. For 1 bitplane this would have been direct anyway with a 1:1 conversion. For more it just becomes multiples of 16 bits so two bytes per plane. So up to 6 planes the max pixel data is 96 bits wide or 12 bytes. 6 individual parallel 16 bit reads then become sequential 16 bit reads. Depending on hardware configuration a group of 16 bits could be read in parallel or serial. The point here is it could read the data directly and skip the conversion since the CLUT value is ready to go. It makes sense if it would be restricted to powers of two so only supporting 2, 4 or 16 colours. Since that is also easier to manage in software. But, what's interesting is if you do the maths, oddly enough, any odd bpp like 3 and 5 can fit in the same space. That is, 16x3 bpp is 6 bytes and 16x5 bpp is 10 bytes. Even 6 bpp, with 16x6 is 12 bytes. No matter what is the pixel width it's always aligned to 16 bits.

Yes, this should work. Furthermore you can read 4 bitplanes in hires and use the data to create 256 colors in lores. This is what Graffiti does. To make it more useful the bitplanes should be interleaved so that each read comes from a different plane, which is 'simply' a matter of advancing each bitplane address by eg. 2 words instead of one.

I wouldn't bother with the 'odd' bpp options, since no other hardware has done this and the rendering math could be tricky. 2, 4 and 16 colors yes, since this would be useful in emulators or to reproduce the graphics of lesser machines like the Amstrad CPC. A 'double-lores' (160 pixel) resolution resolution would also be useful, both for this and to reduce the number of pixels for higher performance.

Quote:

It's been said an A500 could have displayed a 256 colour chunky screen. That the bandwidth was there.

Not really. The bandwidth in lores is practically maxed out like it is in a hires 16 color screen. This is why 256 colors on the A500 wouldn't be very useful (still would be nice though). Lowering the resolution to 160 pixels wide fixes this.

Another thing that would be nice is tiled colors. Since you want 256 palette entries anyway, it would nice if different color banks could be selected with the copper or another bitplane, so you could have up to 256 colors on a '16 color' screen (with 16 banks of 16 colors per tile). You could have 16 color text in 2 bitplanes by making each tile 8 pixels wide, which could make text-based applications a lot faster. This corresponds to one bitplane being 'chunky', while the other is 1 pixel per bit. The chunky bitplane specifies the 'foreground' and 'background' color in each tile, while the pixel bitplane selects between foreground and background for each pixel. Or you could make both chunky with eg. 2 bits in one bitplane selecting 4 colors, with the other having 4 bits selecting between 16 colors (for a total of 64 colors) but at half the resolution.

Quote:

So, what do you guys think? Does that look like something that would have been feasible? Or is there something I have missed such as reading in blocks of 16 bits but still only processing each pixel one bit at a time? In any case that data is some where.

Probably would be some issues, but nothing like AGA.

This is why I am interested in the Amiga Replacement Project. If we can create HDL equivalents of the original Agnus and Denise then we can modify them to add extra modes.

@bhabbott

Quote:

Paula would get a buffered serial port.

Mary has the Paula upgrades.

Since Paula wasn't partitioned from Agnus/Alice, Mary depends on Andrea.

Andrea was delayed for about 1 year due to C65 distraction.

Commodore - The Final Years,

Pandora

By late 1989, the 32-bit AAA project was getting bogged down.
According to Dave Haynie, several factors allowed the project to slip.
“The first reason was that the chip group didn’t get enough
resources so they couldn’t advance the chip technology fast
enough,� he says. “It really was a matter of not reinvesting enough
money in the technology. We had plenty of hard work, which is why
we kept up as well as we did.�

The second reason was that Commodore was taking on too many
projects. [i]James Redfield complained that his staff, especially Victor
Andrade, was spending too much time cleaning up problems in the
4510 and ECS Agnus chips. Andrea development was essentially
suspended until those other two chipsets were in production.

While they waited for AAA, the engineers realized it would be an
especially long time before the low-end Amigas would get a new
chipset. On September 13, 1989, George Robbins wrote a memo
proposing a new chipset somewhere between ECS and AAA
capabilities.

Ted Lenthe, already overwhelmed with the number of chips in
production, was hardly pleased to see one more chipset added to
the mix. He wondered if Robbins was opening a Pandora’s box by
forcing Commodore to work on two Amiga chipsets simultaneously,
and thus the name stuck. “It was originally called Pandora,� says
Dave Haynie. In Greek mythology, Pandora was the first human
woman created by the gods.

Robbins ended his memo with a section tellingly titled, “Lessons
Learned from ECS Fiasco�:
Make sure of what you want up front, even if it takes a while.
Make sure it's worth doing by the time it gets done.
Make sure the project is adequately and continually staffed.
Make sure management is aware of the benefits expected.
Make sure there is a program for getting the chips into systems
ASAP!!!
Make sure to minimize software impact/dependencies.


-------------------
ECS wasted time from #metoo monochrome and color productivity modes.

AAA's Andrea (Agnus's replacement) was delayed which is the core chip for Mary (Paula's replacement) and Monica (Denise's replacement).

Alice is based on ECS Agnus B 2MB.

ECS Agnus A 1 MB was ready for A500's 1989 release.

Without ECS Agnus B 2MB, there's no Alice 2MB. It's possible to modify ECS Agnus A 1MB for Alice 1 MB evolution path.

Without the C65 distraction, ECS Agnus B's bug-fixing pace would be faster.

--------
Victor Andrade joined AMD in 1991 and has been involved in the design of the custom arrays for the various X86 processor families developed at AMD since then. Andrade joined the K7 Athlon team. https://ieeexplore.ieee.org/author/37603722200
Andrade was involved with 45 nm K10 Phenom II and 32 nm Bulldozer-based SKUs.

Last edited by Hammer on 13-Dec-2024 at 04:41 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

@bhabbott

Not TKG itself though you are more than welcome to of course. If does not have the Akiko code. It's the Akiko/C2P benchmark tool I posted a link to. The source is on GitHub but I can provide a binary. I'll probably need to remove the CACR modification if you are going to test that on an 020. I suspect you might get undefined behaviour otherwise.

As for tkg, you will probably struggle on 030/28. The latest compiles binaries are currently in The Zone on EAB. You would need an existing installation of the game to put them in. Assuming you have those, options I would recommend are switching to 1x2 pixelmode (F9 to toggle) and simple lighting (F8 to toggle) and 2/3 screensize (F10 to toggle) Also, make sure you use the non 040/060 builds as they use a lot of specific optimisations for those processors and may not run.

Last edited by Karlos on 13-Dec-2024 at 07:31 AM.
Last edited by Karlos on 13-Dec-2024 at 07:31 AM.

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @bhabbott Quote: Paula would get a buffered serial port. Mary has the Paula upgrades. Since Paula wasn't partitioned from Agnus/Alice, Mary depends on Andrea. Andrea was delayed for about 1 year due to C65 distraction.

Whether the C65 was a 'distraction' depends on whether you think it was worth it or not. I would have liked to see it come out, but not as late as it did. The proximate reason it took too long was that they tried to do too much and weren't constrained by a release date. Had that been done it wouldn't have been a 'distraction'.

You talk about Mary depending on Andrea. This illustrates the real reason AAA slipped behind schedule - they were trying to do too much. If they didn't even have the resources for 'cleaning up problems in the 4510 and ECS Agnus chips' what hope did they have of completing the much more complex AAA?

We didn't need AAA. It was not only too ambitious, but also would cost too much for low-end machines - which made it a bust. A chipset that can't be deployed across the whole range is useless. Thankfully someone had the sense to realize this and start working on AA in parallel, but that's what they should have been doing from the beginning.

Quote:

Robbins ended his memo with a section tellingly titled, “Lessons Learned from ECS Fiasco�: Make sure of what you want up front, even if it takes a while. Make sure it's worth doing by the time it gets done. Make sure the project is adequately and continually staffed. Make sure management is aware of the benefits expected. Make sure there is a program for getting the chips into systems ASAP!!! Make sure to minimize software impact/dependencies.[i]

All good advice.

AAA failed to meet any of those requirements, and just throwing more staff at it wouldn't fix the other problems. Why not? In projects like this productivity doesn't scale linearly. They could have put 100 engineers on it and still not made the progress that was needed - you would just have people tripping over each other.

Quote:

Without ECS Agnus B 2MB, there's no Alice 2MB. It's possible to modify ECS Agnus A 1MB for Alice 1 MB evolution path.

And again we see that the chipset was evolving bit by bit, not in big jumps. This is typically how R&D works. Trying to make a big leap is where you get into trouble.

However I believe they could have modified Agnus and Denise more without too much effort, just not in the direction they went. As you say, the 31kHz mode was a waste of time. But that's where Jay Miner was going, and it continued his legacy. The Hedley monitor was another example of the engineers going the wrong way. They weren't interested in games and so couldn't see it.

Quote:

Without the C65 distraction, ECS Agnus B's bug-fixing pace would be faster.

I didn't think it would have made much difference. The real problem with the C65 was lack of a firm specification that made sense and was stuck to, which would have meant it was finished by 1989.

As Robbins said - take the time to make sure the spec is complete, and that management is aware of the benefits (ie. that the product is marketable) and that there are machines to put it in. AAA would never be suitable for the A500 segment so it wasn't worth doing. The 15 engineers working on it were wasting their time. ECS should have focused on matching VGA's gaming features (ie. 256 color chunky lores). If they had just done that and nothing else it would have been far better. Other AGA features could be added in the next revision, which would be easier because they were building on what they had, not trying to do it all at once.

This thread is very relevant to the above. I wish we had circuit diagrams for Agnus and Denise so we could point to parts of it and say - cut here, add this, insert that, and bingo - packed pixels!

@bhabbott

Quote:

You talk about Mary depending on Andrea. This illustrates the real reason AAA slipped behind schedule - they were trying to do too much. If they didn't even have the resources for 'cleaning up problems in the 4510 and ECS Agnus chips' what hope did they have of completing the much more complex AAA?

2 MB Chip RAM was pushed into ECS Agnus B since the canceled Ranger had 2MB Chip RAM spec.

ECS Agnus B with 16-bit 2MB Chip RAM works on A500 Rev6A's jumper configs.

A3000 has Ramsey 32-bit Chip RAM with 16-bit ECS complexity. From A3000's 32-bit Chip RAM with 16-bit ECS, 32-bit Lisa was designed with A3000Plus's AA being the result.

A1000Plus (with AA) was the cost reduction for A3000Plus.

A3000 was an important factor 32-bit/16-bit AA hybrid.

Quote:

@bhabbott We didn't need AAA. It was not only too ambitious, but also would cost too much for low-end machines - which made it a bust. A chipset that can't be deployed across the whole range is useless. Thankfully someone had the sense to realize this and start working on AA in parallel, but that's what they should have been doing from the beginning.

AAA scales from VRAM to FP DRAM with 64-bit and 32-bit models. Commodore needs it when It focuses on it.

3DO effectively delivered most of AAA's gaming display/audio capabilities. 3DO's MADAM (Agnus role) can access both 2MB FP DRAM and 1 MB VRAM as non-uniform "Chip RAM".

Atari Falcon's 16-bit audio didn't help Atari's TOS 68K platform. .e. 10,000 to 15,000 unit sales.

3DO M2 (with UMA 66Mhz 64bit bus) was completed in 1995 and Panasonic facked it up.

Quote:

@bhabbott And again we see that the chipset was evolving bit by bit, not in big jumps. This is typically how R&D works. Trying to make a big leap is where you get into trouble. However I believe they could have modified Agnus and Denise more without too much effort, just not in the direction they went. As you say, the 31kHz mode was a waste of time. But that's where Jay Miner was going, and it continued his legacy. The Hedley monitor was another example of the engineers going the wrong way. They weren't interested in games and so couldn't see it.

Hedley monitor didn't factor in mass production factor and followed Jack Tramiel's low cost games and higher cost business hard product segmentation idealogy.

I didn't say 31 kHz mode was a waste of time since VGA had a scan line doubler for 200 lines modes (for PC VGA gaming with 31 kHz monitors).

Commodore needs to leverage thier millions production run into business resolution mode capable with gaming. Jack Tramiel's product segmentation model needs to be ditched.

31 kHz mode for DoublePAL 320x256 is not transparent for existing Amiga games. I am okay with A3000's Amber gaming results with a PC VGA monitor, it's too bad Amber's double scan line feature wasn't integrated into Lisa. Amber's deinterlace with extra expensive framebuffer is not needed with AGA/AAA.

Andrea replaces Agnus,
Monica replaces Denise, 64bit models has two Monica.
Mary replaces Paula,
Linda replaces Amber, and enables typical action gaming resolution to be displayed on 31 khz monitors. 64bit models has two Linda.

Quote:

@bhabbott As Robbins said - take the time to make sure the spec is complete, and that management is aware of the benefits (ie. that the product is marketable) and that there are machines to put it in. AAA would never be suitable for the A500 segment so it wasn't worth doing.

Minus backward compability, AAA's display IP is recycled for Amiga Hombre e.g. Amiga CD3D games console and HP was going to fabciate it.

AAA's 64bit model wouldn't be in A500 type machine e.g. 64bit 2 MB VRAM is expensive. Must be 3DO's 1 MB VRAM with 2MB FP DRAM hybrid which Amiga Hombre also supports.

Without 3D, AAA dies like ET6000.

Last edited by Hammer on 15-Dec-2024 at 10:14 PM.
Last edited by Hammer on 15-Dec-2024 at 01:15 PM.
Last edited by Hammer on 15-Dec-2024 at 01:14 PM.
Last edited by Hammer on 15-Dec-2024 at 01:13 PM.
Last edited by Hammer on 15-Dec-2024 at 01:11 PM.
Last edited by Hammer on 15-Dec-2024 at 01:08 PM.
Last edited by Hammer on 15-Dec-2024 at 01:04 PM.
Last edited by Hammer on 15-Dec-2024 at 12:59 PM.
Last edited by Hammer on 15-Dec-2024 at 12:48 PM.
Last edited by Hammer on 15-Dec-2024 at 12:47 PM.
Last edited by Hammer on 15-Dec-2024 at 12:42 PM.
Last edited by Hammer on 15-Dec-2024 at 12:32 PM.

_________________
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