@cdimauro

Quote:

cdimauro wrote: Sure, and the processor was using HALF of the available bandwidth because those geniuses weren't able to check the CPU memory requests every two cycles instead of every four: what a gargantuan endeavour required it...

Refer to the "read my lips, no new chips" directive, and the typical Commodore headless chicken directionless R&D.


Quote:

Not even counting the bugs of Zorro III which crippled the memory bandwidth. How long do you still want to defend those incompetents?

Commodore's R&D budget also supports Commodore's PC clone business.

Zorro III is competitive against EISA.

NEC-led "VESA Local Bus" is another level.

Amiga's equivalent should be a local CPU bus with an additional feature designed for partitioned graphics add-on.

AGP or single PEG (PCIe 16 lanes for graphics) proves a single fast slot for graphics is enough for a gaming PC market.

_________________
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: @cdimauro Quote: cdimauro wrote: Sure, and the processor was using HALF of the available bandwidth because those geniuses weren't able to check the CPU memory requests every two cycles instead of every four: what a gargantuan endeavour required it... Refer to the "read my lips, no new chips" directive,

Which has clearly proved a lie, looking at the FACTs: new chips were developed.
Quote:

and the typical Commodore headless chicken directionless R&D.

Same for the engineers, according to what you also have reported here.
Quote:

Quote: Not even counting the bugs of Zorro III which crippled the memory bandwidth. How long do you still want to defend those incompetents? Commodore's R&D budget also supports Commodore's PC clone business.

Sure: they were both Commodore's businesses.
Quote:

Zorro III is competitive against EISA.

But EISA was NOT the answer to Zorro III! That's a complete LIE. Do you agree?
Quote:

NEC-led "VESA Local Bus" is another level. Amiga's equivalent should be a local CPU bus with an additional feature designed for partitioned graphics add-on.

Yes, but the engineers struggle to bring those additional features: they were sitting idle for YEARS since the A1000...

@cdimauro

Quote:

Which has clearly proved a lie, looking at the FACTs: new chips were developed.

Not a lie since the prototype A500 Rev6 has the full ECS tested.

ECS was intended for A500/A2000.

A3000 was known as A2001.

Quote:

Same for the engineers, according to what you also have reported here.

Similar-ranking engineers need leadership.

Quote:

But EISA was NOT the answer to Zorro III! That's a complete LIE. Do you agree?

Zorro III was in development within a similar time frame as Extended Industry Standard Architecture (EISA).

The difference is EISA standard was released in 1988.

Intel introduced their first EISA chipset (and also their first chipset in the modern sense of the word) as the 82350 in September 1989.

_________________
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: @cdimauro Quote: Which has clearly proved a lie, looking at the FACTs: new chips were developed. Not a lie since the prototype A500 Rev6 has the full ECS tested.

Tested -> not in production.
Quote:

ECS was intended for A500/A2000.

Intended -> not in production.
Quote:

A3000 was known as A2001.

Known, but not being. The A3000 was quite different when it went in production.

Anyway, the thing haven't changed: NEW chips were developed (and you continue to avoid talking about Amber. Why?), and the "Read my lips, no new chips" statement is a pure lie to justify the engineering team failures.
Quote:

Quote: Same for the engineers, according to what you also have reported here. Similar-ranking engineers need leadership.

AND knowledge & vision & expertise on how to evolve the platform, which they have shown to lack.
Quote:

Quote: But EISA was NOT the answer to Zorro III! That's a complete LIE. Do you agree? Zorro III was in development within a similar time frame as Extended Industry Standard Architecture (EISA). The difference is EISA standard was released in 1988. Intel introduced their first EISA chipset (and also their first chipset in the modern sense of the word) as the 82350 in September 1989.

You repeated exactly what I've stated before, but you haven't answered my question.

Haynie's statement was a lie or not? It's very simple: you've to write "yes" or "no".

I understand that he's a myth for you, but... don't be like Fonzarelli.

@cdimauro

Quote:

Tested -> not in production.

Red herring. That's your assertion.

Quote:

Intended -> not in production.

Red herring. That's your assertion.

Quote:

Anyway, the thing haven't changed: NEW chips were developed (and you continue to avoid talking about Amber. Why?), and the "Read my lips, no new chips" statement is a pure lie to justify the engineering team failures.

Context is important. You misused "read my lips, no new chips".

Quote:

You repeated exactly what I've stated before, but you haven't answered my question. Haynie's statement was a lie or not? It's very simple: you've to write "yes" or "no". I understand that he's a myth for you, but... don't be like Fonzarelli.

I don't have to answer you. You're not my boss.

The English language has double meanings and you haven't mastered this. This is the difference between a native English speaker and an English second language speaker.

A Commodore-centric point of view would have PC's 32-bit EISA being the answer to 32-bit Zorro III. Hint: A Commodore "reality distortion field" which is understandable from a Commodore employee.

In the real world, PC clone's 32-bit EISA is a response to IBM's 32-bit MCA.

My position is 32-bit Zorro III is competitive against the PC clone's 32-bit EISA.

-----------------
For Quake demo1 320x200 with a similar 1.8 Ghz 3 instruction issue cycle out-of-order CPU compute power, Amiga AGA's CPU to 32-bit Chip RAM IO efficiency has no problems blowing away PC clone's 16-bit ISA IO efficiency.

Amiga AGA's CPU to 32-bit Chip RAM IO with Lisa display efficiency can sustain Quake demo1 320x200p at 61 fps average or 640x200p at 30 fps average. For display solution, Lisa's 32-bit bandwidth is good enough for texture map 3D gaming on 15 kHz TVs and other 15 kHz RGB monitors.

Last edited by Hammer on 05-Aug-2024 at 02:15 AM.
Last edited by Hammer on 05-Aug-2024 at 02:13 AM.
Last edited by Hammer on 05-Aug-2024 at 02:06 AM.
Last edited by Hammer on 05-Aug-2024 at 02:03 AM.
Last edited by Hammer on 05-Aug-2024 at 01:56 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: @cdimauro Quote: Tested -> not in production. Red herring. That's your assertion. Quote: Intended -> not in production. Red herring. That's your assertion.

LOL. I don't even reply here, because it's simply ridiculous...
Quote:

Quote: Anyway, the thing haven't changed: NEW chips were developed (and you continue to avoid talking about Amber. Why?), and the "Read my lips, no new chips" statement is a pure lie to justify the engineering team failures. Context is important.

No, I think that more important is about KNOWLEDGE. You don't know how chips are created in the industry.
Quote:

You misused "read my lips, no new chips".

Really? And how? You've also shown how NEW FEATURE were introduced in the ECS chipset, with new chips.

Plus, you systematically avoid to answer about the AMBER chip, which was... completely new. Which clearly proves your intellectual dishonesty.
Quote:

Quote: You repeated exactly what I've stated before, but you haven't answered my question. Haynie's statement was a lie or not? It's very simple: you've to write "yes" or "no". I understand that he's a myth for you, but... don't be like Fonzarelli. I don't have to answer you. You're not my boss.

Oh, sure. You don't like to answer to things which puts in bad share your hero, right?
Quote:

The English language has double meanings and you haven't mastered this. This is the difference between a native English speaker and an English second language speaker.

Then explain me the meaning of this:

The whole of the PC industry came up with EISA, which was very much their answer to Zorro III.
Quote:

A Commodore-centric point of view would have PC's 32-bit EISA being the answer to 32-bit Zorro III. Hint: A Commodore "reality distortion field" which is understandable from a Commodore employee. In the real world, PC clone's 32-bit EISA is a response to IBM's 32-bit MCA.

Which means that the above is a LIE.

Even because EISA came up well BEFORE Zorro III, and this is another FACT.
Quote:

My position is 32-bit Zorro III is competitive against the PC clone's 32-bit EISA.

Totally irrelevant on this part of the discussion.
Quote:

----------------- For Quake demo1 320x200 with a similar 1.8 Ghz 3 instruction issue cycle out-of-order CPU compute power, Amiga AGA's CPU to 32-bit Chip RAM IO efficiency has no problems blowing away PC clone's 16-bit ISA IO efficiency. Amiga AGA's CPU to 32-bit Chip RAM IO with Lisa display efficiency can sustain Quake demo1 320x200p at 61 fps average or 640x200p at 30 fps average. For display solution, Lisa's 32-bit bandwidth is good enough for texture map 3D gaming on 15 kHz TVs and other 15 kHz RGB monitors.

Now you started the Hammer's PADDING...

@cdimauro

Quote:

@cdimauro You don't know how chips are created in the industry.

Your "Intel culture" is meanless from at least two senior Commodore engineer's points of view.

PS; Brian Bagnall's Commodore - The Final Years includes "Intel hate" for Intel's bias towards Compaq.

Quote:

@cdimauro Really? And how? You've also shown how NEW FEATURE were introduced in the ECS chipset, with new chips.

It's called "work in progress".

ECS is not new. "Read my lips, no new chips"'s original context overrides your assertion.

Quote:

@cdimauro Plus, you systematically avoid to answer about the AMBER chip, which was... completely new.

AMBER's product development includes add-on devices for A500 and A2000. Read Brian Bagnall's Commodore - The Final Years.

A500's AMBER addon is canceled.

As mentioned in Brian Bagnall's Commodore - The Final Years, AMBER with a high-speed framebuffer is a costly workaround for stable "business" 640x400/512p 16 colors and it was not needed during the AGA generation.

Quote:

@cdimauro Which clearly proves your intellectual dishonesty.

That's bullshit.


Quote:

From Brian Bagnall's Commodore - The Final Years, Amber Flicker Fixer By 1988, the Amiga was starting to lose its graphical lead over other computers. Months earlier, in April 1987, VGA was released for the IBM PS/2 computer. This soon became a graphical standard for other PC clones. VGA produced 640×480 screens with 16 colors, and 320×200 with 256 colors. And most importantly, the display was non-interlaced, unlike Amiga’s Hi-Res graphics. “This was a failure of the Amiga's architecture, the core chipset itself, in order to produce the type of video that by that point had become common,� remarks Bryce Nesbitt. “The Amiga was a game console that got too big for its britches." TV is interlaced video and it's the right thing if you're just playing on a TV, and it's almost certainly the wrong thing if you are playing on a computer monitor. It's especially the wrong thing for text. When they started out they were going for a game console, they weren't going for a general-purpose computer.� (skip) Hedley Davis had previously proposed a general deinterlacer card for the A2000 to Henri Rubin, who had noncommittally told Davis that it “may end up being very important.� (skip) Davis interviewed and hired a new engineer, Scott Hood, who would develop the flicker fixer for the A3000, allowing output to the popular NEC MultiSync monitor. Davis called his chip Amber, and he also assigned Hood to work on a video adapter card for the Amiga 2000 called the A2320 flicker fixer. (skip) The A2320 board also contained expensive memory in order to buffer the interlaced images. “That was a lot of memory,� says Nesbitt. “In those days the amount of memory that represented one frame of video was significant. That also had to be high speed static RAM.� Nesbitt feels the solution was an expensive hack. “That was a kludge,� he says “The proper place to put this was in the chipset and give it the ability to produce progressive video. It's not proper to put an expensive piece of electronics on the output of your chipset in order to fix a problem like this.� The result would increase the cost of the A3000 significantly. “From a company point of view, it was a reflection of a sort of weakness in the silicon group,� says Nesbitt. “If you really were on top of making these chips and you were able to make changes to the chips, and you had the original team and you could iterate it, you would have put the progressive scan right on the silicon in version 3.0.�

The original Amiga team's Ranger chipset was canceled by management, hence the blame is on management.

Commodore management dismantled the original Amiga team, hence the blame is on management.

Removing Amber doesn't affect Amiga's core graphics architecture.

The joint A3000 and A2000's A2320 development shows your intellectual dishonesty. The Amber chip is not unique for A3000.

Quote:

From Brian Bagnall's Commodore - The Final Years, (skip) on September 20, 1988 they were ready to internally release an advance copy to developers. Rather than calling the disk a Kickstart disk, they referred to it as a Jumpstart disk because of the preview nature of the libraries. The West Coast engineers also replaced the despised Amiga checkmark icon with their original Amiga boing ball. Rubin was able to demonstrate Productivity Mode on both the Hi-Res chipset in an Amiga 2000 computer and using an A2024 monitor.

ECS's "Productivity Mode" was operational with A2000 on September 20, 1988.

Commodore's internal 16-bit Amigas has ECS operational! You're wrong.


https://www.youtube.com/watch?v=cicSBLsJtuc
A500 Rev 3's with ECS,

1. issues with ECS Denise i.e. missing pin 34 support. Needs a jumper wire mod from Denise's pin 34 to Gary's pin 26.

2. Kickstart 2's extra wire mod.

1989 released A500 rev6A motherboard supports the full ECS without jumper wire mods i.e. "it just works". This is why purchased my second A500 rev6A motherboard in 2022 to duplicate my 1989 A500 rev 6A purchase.

I have a 1988 released A500 rev5 when my school friend abandoned it for a 486DX33 PC clone.

Quote:

Now you started the Hammer's PADDING...

My point, you're barking at the wrong tree.

A1200's AGA is sufficient against VGA mode 13h/mode X resolution modes that dominated 1993 to 1994 gaming PCs.

Last edited by Hammer on 05-Aug-2024 at 11:38 AM.
Last edited by Hammer on 05-Aug-2024 at 11:29 AM.
Last edited by Hammer on 05-Aug-2024 at 11:18 AM.
Last edited by Hammer on 05-Aug-2024 at 07:17 AM.
Last edited by Hammer on 05-Aug-2024 at 07:16 AM.
Last edited by Hammer on 05-Aug-2024 at 07:14 AM.
Last edited by Hammer on 05-Aug-2024 at 07:08 AM.

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

@cdimauro

Quote:

Which means that the above is a LIE. Even because EISA came up well BEFORE Zorro III, and this is another FACT.

Extended Industry Standard Architecture was announced in September 1988.

"The first EISA computer announced was the HP Vectra 486 in October 1989. The first EISA computers to hit the market were the Compaq Deskpro 486 and the SystemPro"


vs

The Amiga 3000 project stalled when it missed CeBIT 1988 (March 1988). "Porter expected to show the new A3000 at the March 1988 Hanover Fair".

After many delays, Zorro III was released with A3000's June 1990 release.

Quote:

From Commodore - The Final Years, Dragging On Engineering had made plans during the summer of 1987, but almost no one was able to begin new projects, even late in the year, because they were still occupied with finishing off old projects. Dave Haynie, who was supposed to be working on the new Amiga 3000 computer, instead helped Bob Welland, who was having difficulty completing the accelerator board for the A2000. All Haynie had to show for his A3000 was a wishlist of features he hoped to include.

The A3000 project is before the EISA agreement!

Last edited by Hammer on 05-Aug-2024 at 07:41 AM.
Last edited by Hammer on 05-Aug-2024 at 07:41 AM.
Last edited by Hammer on 05-Aug-2024 at 07:34 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: @cdimauro Quote: @cdimauro You don't know how chips are created in the industry. Your "Intel culture" is meanless from at least two senior Commodore engineer's points of view.

Your lack of silicon industry culture is really embarrassing. Why don't you talk of things that you've at least some clue, instead of spreading to the world how much ignorant you are?
Quote:

PS; Brian Bagnall's Commodore - The Final Years includes "Intel hate" for Intel's bias towards Compaq.

And who "funny" cares?
Quote:

Quote: @cdimauro Really? And how? You've also shown how NEW FEATURE were introduced in the ECS chipset, with new chips. It's called "work in progress".

Guess what: ECS had SEVERAL features which were introduced and required new chips for it.
Quote:

ECS is not new.

ECS required NEW chips. So, it's new.
Quote:

"Read my lips, no new chips"'s original context overrides your assertion.

That's on your fantasy world, because you need to justify the failures of your hero, otherwise you don't sleep the night.
Quote:

Quote: @cdimauro Plus, you systematically avoid to answer about the AMBER chip, which was... completely new. AMBER's product development includes add-on devices for A500 and A2000. Read Brian Bagnall's Commodore - The Final Years. A500's AMBER addon is canceled.

Where? There's no proof of that.
Quote:

As mentioned in Brian Bagnall's Commodore - The Final Years, AMBER with a high-speed framebuffer is a costly workaround for stable "business" 640x400/512p 16 colors and it was not needed during the AGA generation.

Really?
Quote:

Quote: @cdimauro Which clearly proves your intellectual dishonesty. That's bullshit.

Well, it's the FIRST time that you openly speak about AMBER, dear my intellectual dishonesty, so what do you expected from me?
Quote:

Quote: From Brian Bagnall's Commodore - The Final Years, Amber Flicker Fixer By 1988, the Amiga was starting to lose its graphical lead over other computers. Months earlier, in April 1987, VGA was released for the IBM PS/2 computer. This soon became a graphical standard for other PC clones. VGA produced 640×480 screens with 16 colors, and 320×200 with 256 colors. And most importantly, the display was non-interlaced, unlike Amiga’s Hi-Res graphics. “This was a failure of the Amiga's architecture, the core chipset itself, in order to produce the type of video that by that point had become common,� remarks Bryce Nesbitt. “The Amiga was a game console that got too big for its britches." TV is interlaced video and it's the right thing if you're just playing on a TV, and it's almost certainly the wrong thing if you are playing on a computer monitor. It's especially the wrong thing for text. When they started out they were going for a game console, they weren't going for a general-purpose computer.� (skip) Hedley Davis had previously proposed a general deinterlacer card for the A2000 to Henri Rubin, who had noncommittally told Davis that it “may end up being very important.� (skip) Davis interviewed and hired a new engineer, Scott Hood, who would develop the flicker fixer for the A3000, allowing output to the popular NEC MultiSync monitor. Davis called his chip Amber, and he also assigned Hood to work on a video adapter card for the Amiga 2000 called the A2320 flicker fixer. (skip) The A2320 board also contained expensive memory in order to buffer the interlaced images. “That was a lot of memory,� says Nesbitt. “In those days the amount of memory that represented one frame of video was significant. That also had to be high speed static RAM.� Nesbitt feels the solution was an expensive hack. “That was a kludge,� he says “The proper place to put this was in the chipset and give it the ability to produce progressive video. It's not proper to put an expensive piece of electronics on the output of your chipset in order to fix a problem like this.� The result would increase the cost of the A3000 significantly. “From a company point of view, it was a reflection of a sort of weakness in the silicon group,� says Nesbitt. “If you really were on top of making these chips and you were able to make changes to the chips, and you had the original team and you could iterate it, you would have put the progressive scan right on the silicon in version 3.0.� The original Amiga team's Ranger chipset was canceled by management, hence the blame is on management.

Which was ok: too much expensive for the time. That's what wasn't needed by Commodore.
Quote:

Commodore management dismantled the original Amiga team, hence the blame is on management.

That was a shame, since incapable engineers were left, which ruined the platform.
Quote:

Removing Amber doesn't affect Amiga's core graphics architecture.

Of course: it's as alien to the Amiga as your beloved DSP...
Quote:

The joint A3000 and A2000's A2320 development shows your intellectual dishonesty. The Amber chip is not unique for A3000.

From YOUR text:

a new engineer, Scott Hood, who would develop the flicker fixer for the A3000

That was the reason why we've AMBER = (COMPLETELY) NEW chip.

Why don't you read what YOU write?!?
Quote:

Quote: From Brian Bagnall's Commodore - The Final Years, (skip) on September 20, 1988 they were ready to internally release an advance copy to developers. Rather than calling the disk a Kickstart disk, they referred to it as a Jumpstart disk because of the preview nature of the libraries. The West Coast engineers also replaced the despised Amiga checkmark icon with their original Amiga boing ball. Rubin was able to demonstrate Productivity Mode on both the Hi-Res chipset in an Amiga 2000 computer and using an A2024 monitor. ECS's "Productivity Mode" was operational with A2000 on September 20, 1988. Commodore's internal 16-bit Amigas has ECS operational!

Operational does NOT mean production-ready...
Quote:

You're wrong.

About what?
Quote:

https://www.youtube.com/watch?v=cicSBLsJtuc A500 Rev 3's with ECS, 1. issues with ECS Denise i.e. missing pin 34 support. Needs a jumper wire mod from Denise's pin 34 to Gary's pin 26. 2. Kickstart 2's extra wire mod.

Irrelevant?
Quote:

1989 released A500 rev6A motherboard supports the full ECS without jumper wire mods i.e. "it just works". This is why purchased my second A500 rev6A motherboard in 2022 to duplicate my 1989 A500 rev 6A purchase.

Have you tried to use the Super-High Res mode?
Quote:

I have a 1988 released A500 rev5 when my school friend abandoned it for a 486DX33 PC clone.

Irrelevant: it's a motherboard...
Quote:

Quote: Now you started the Hammer's PADDING... My point, you're barking at the wrong tree. A1200's AGA is sufficient against VGA mode 13h/mode X resolution modes that dominated 1993 to 1994 gaming PCs.

Are you bipolar? Several times you said that it wasn't enough for compete, and now that it was enough.

Look: FIRST make peace with yourself and THEN come back here...
Quote:

Hammer wrote: @cdimauro Quote: Which means that the above is a LIE. Even because EISA came up well BEFORE Zorro III, and this is another FACT. Extended Industry Standard Architecture was announced in September 1988. "The first EISA computer announced was the HP Vectra 486 in October 1989. The first EISA computers to hit the market were the Compaq Deskpro 486 and the SystemPro" vs The Amiga 3000 project stalled when it missed CeBIT 1988 (March 1988). "Porter expected to show the new A3000 at the March 1988 Hanover Fair".

So? Was the world aware that the Amiga 3000 have brought the Zorro III?
Quote:

After many delays, Zorro III was released with A3000's June 1990 release.

And the world finally knew Zorro III...
Quote:

Quote: From Commodore - The Final Years, Dragging On Engineering had made plans during the summer of 1987, but almost no one was able to begin new projects, even late in the year, because they were still occupied with finishing off old projects. Dave Haynie, who was supposed to be working on the new Amiga 3000 computer, instead helped Bob Welland, who was having difficulty completing the accelerator board for the A2000. All Haynie had to show for his A3000 was a wishlist of features he hoped to include. The A3000 project is before the EISA agreement!

Before the ANNOUCEMENT. The agreement between the parties was clearly (!) BEFORE it...


BTW, you still have avoided to explain the meaning of this:

The whole of the PC industry came up with EISA, which was very much their answer to Zorro III.

You stated that I can't get it because I'm not a native speaker. Now you, native speaker, have the chance to explain its meaning.

So, the question: does it mean that EISA was designed to oppose / compete with Zorro III?

Care to clarify this, Mr. Fonzarelli?

The whole chunky thing is spilling across all the threads but I'm just going to say it here, because "graphics" is the relevant topic.

Akiko C2P is not terrible at all, it's pretty much as close to instantaneous as you can get. I was surprised by this but rest code I wrote and had tested pretty much demonstrates it. As soon as you have written your 8 longs, at the maximum transfer rate of the bus, you can start reading them back, already converted.

What is terrible is the way you are forced to use it, especially the manual read back of planar data and push to chip. That step ultimately kills it dead. The other problem is datacache on 68030+. You need to be wary of it while converting because your writes will get write allocated in the cache and you can't read back the data. To fix that you need to disable WA during the conversion or *maybe* (I didn't test this) you can read back from an aliased location.

Unfortunately there just doesn't seem to be any way to fix the workflow limitation here. The missed opportunity here is for Akiko to push the planes to chip directly. This would have required some auto incrementing plane pointer registers (or one and a plane size register with the assumption of contiguous planes). Akiko already had some DMA capabilities for dealing with the CD.

Last edited by Karlos on 06-Aug-2024 at 07:28 AM.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

Your lack of silicon industry culture is really embarrassing. Why don't you talk of things that you've at least some clue, instead of spreading to the world how much ignorant you are? Quote:

False. The original context for "read my lips, not new chips" is important, NOT your ignorance.

Quote:

Guess what: ECS had SEVERAL features which were introduced and required new chips for it.

Fact: From Commodore's engineers, ECS is not considered as "new" since runs on older A500/A2000 ECS compliant motherboard designs.

C= Alice and Lisa can't be installed on A500/A2000/A3000.

Quote:

Well, it's the FIRST time that you openly speak about AMBER, dear my intellectual dishonesty, so what do you expected from me?

You're asserting your arguments out of ignorance without Commodore's internal timelines knowledge.

I already told you AMBER is designed for [b]existing A2000 and A3000.

Quote:

Of course: it's as alien to the Amiga as your beloved DSP...

Replacing Budgie/AA Gayle for Ramsey/four PLL bridge chips/Fat Gary still enables AA's operations.

Real alien is your beloved "little endian" PCMCIA with five PLL chips (byte swaps) i.e. U45, U46, U47, U41, U42.


Quote:

That was the reason why we've AMBER = (COMPLETELY) NEW chip. Why don't you read what YOU write?!?

Fact: From Commodore's engineers, ECS is not considered "new" since runs on older A500/A2000 designs.

AMBER is designed for existing A2000 and A3000.

Quote:

Operational does NOT mean production-ready.

Fact: From Commodore's engineers, ECS is not considered "new" since ECS runs on older A500/A2000 designs.

Commodore has "releasable state" (e.g. monochrome high resolution Denise ) and it didn't go into production.

Quote:

About what?

Fact: From Commodore's engineers, ECS is not considered "new" since runs on older A500/A2000 designs.


Quote:

Irrelevant?

It's relevant i.e. C= ECS compliant motherboards are real.


Quote:

Are you bipolar? Several times you said that it wasn't enough for compete, and now that it was enough. Look: FIRST make peace with yourself and THEN come back here...

I already stated two pathways for AGA's chunky problem i.e.

1. Supply a "game ready" optimized Blitter C2P code sample as part of standard SDK.

or

2. Include chunky pixels mode in hardware.

Commodore needs to execute one of the pathways.

Many mainstream 3rd party game developers couldn't be bothered with figuring out a software workaround for Amiga's chunky pixels problem.

Akiko C2P is the hardware workaround solution with a smaller install base.

Quote:

Have you tried to use the Super-High Res mode?

Irrelevant?

Quote:

So? Was the world aware that the Amiga 3000 have brought the Zorro III?

So, Dave Haynie wasn't aware of his Zorro III creation?

Dave Haynie is a Commodore hardware engineer.

Consider who made the Zorro III vs EISA comparison. Context is important.

The world doesn't revolve around you.

Quote:

And the world finally knew Zorro III...

As above.

Last edited by Hammer on 06-Aug-2024 at 08:27 AM.
Last edited by Hammer on 06-Aug-2024 at 08:21 AM.
Last edited by Hammer on 06-Aug-2024 at 08:15 AM.
Last edited by Hammer on 06-Aug-2024 at 08:07 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

@Karlos

Quote:

Karlos wrote: The whole chunky thing is spilling across all the threads but I'm just going to say it here, because "graphics" is the relevant topic.

Indeed. Let's see if the bot finally understands it.
Quote:

Akiko C2P is not terrible at all, it's pretty much as close to instantaneous as you can get. I was surprised by this but rest code I wrote and had tested pretty much demonstrates it. As soon as you have written your 8 longs, at the maximum transfer rate of the bus, you can start reading them back, already converted. What is terrible is the way you are forced to use it, especially the manual read back of planar data and push to chip. That step ultimately kills it dead. The other problem is datacache on 68030+. You need to be wary of it while converting because your writes will get write allocated in the cache and you can't read back the data. To fix that you need to disable WA during the conversion or *maybe* (I didn't test this) you can read back from an aliased location. Unfortunately there just doesn't seem to be any way to fix the workflow limitation here. The missed opportunity here is for Akiko to push the planes to chip directly. This would have required some auto incrementing plane pointer registers (or one and a plane size register with the assumption of contiguous planes). Akiko already had some DMA capabilities for dealing with the CD.

That's a clear example of how Commodore's engineers had no creativity neither vision on how to improve the platform.

The best would have been to directly implement the packed/chunky graphics, and it wouldn't have required a lot of efforts (as I've written on my article on this specific argument)

But even this one-day solution was completely ruined by their incompetence, since without using the DMA (which, as you stated, was already in the chip) it wasted half of the performance.

Only Commodore's engineers made it possible...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Your lack of silicon industry culture is really embarrassing. Why don't you talk of things that you've at least some clue, instead of spreading to the world how much ignorant you are? Quote: False. The original context for "read my lips, not new chips" is important, NOT your ignorance.

Which context? You don't know how (new) chips are made, but you continue to defend the incompetents which wasted all those opportunities.
Quote:

Quote: Guess what: ECS had SEVERAL features which were introduced and required new chips for it. Fact: From Commodore's engineers, ECS is not considered as "new"

What's considered from them is irrelevant: the reality is that new revisions require new mask, hence new chips.

Whether to take advantage of this or not it's entirely up to engineers that can take this opportunity.
Quote:

since runs on older A500/A2000 ECS compliant motherboard designs. C= Alice and Lisa can't be installed on A500/A2000/A3000.

Neither ECS on some of those older machines:
https://bigbookofamigahardware.com/bboah/product.aspx?id=1478
The later 8375 parts (318069 -16/17 and -18/19) are C= spare parts for the earlier pin-out 8372A 1MB and 8372B 2MB Agnus used in the A500/2000 & A3000 respectively. They have VBB markings, and will require a field mod on the motherboard in most cases, as one signal pin's use has changed.

https://bigbookofamigahardware.com/bboah/product.aspx?id=1487
The Super-Denise may only be paired with the 8372/8375-series of ECS Agnus chips. They will not work with the OCS 8370/8371 or the earlier DIP Agnus chips.

Pay particular attention to the last one, because it's the most important.
Quote:

Quote: Well, it's the FIRST time that you openly speak about AMBER, dear my intellectual dishonesty, so what do you expected from me? You're asserting your arguments out of ignorance without Commodore's internal timelines knowledge. I already told you AMBER is designed for existing A2000 and A3000.

Ignorance? This:

a new engineer, Scott Hood, who would develop the flicker fixer for the A3000

is what YOU have reported, right?

Could you please explain me its meaning?
Quote:

Quote: Of course: it's as alien to the Amiga as your beloved DSP... Replacing Budgie/AA Gayle for Ramsey/four PLL bridge chips/Fat Gary still enables AA's operations. Real alien is your beloved "little endian" PCMCIA with five PLL chips (byte swaps) i.e. U45, U46, U47, U41, U42.

Then tell more about the IDE interface: is it big endian? Is it a natural fit to the Amiga ecosystem?
Quote:

Quote: That was the reason why we've AMBER = (COMPLETELY) NEW chip. Why don't you read what YOU write?!? Fact: From Commodore's engineers, ECS is not considered "new" since runs on older A500/A2000 designs.

Repeating it like a parrot doesn't change the situation.
Quote:

AMBER is designed for existing A2000 and A3000.

See above: I've reported YOUR words.
Quote:

Quote: Operational does NOT mean production-ready. Fact: From Commodore's engineers, ECS is not considered "new" since ECS runs on older A500/A2000 designs.

PARROT MODE ON...
Quote:

Commodore has "releasable state" (e.g. monochrome high resolution Denise ) and it didn't go into production.

Releasable? Based on what?
Quote:

Quote: About what? Fact: From Commodore's engineers, ECS is not considered "new" since runs on older A500/A2000 designs.

PARROT MODE ON...
Quote:

Quote: Irrelevant? It's relevant i.e. C= ECS compliant motherboards are real.

See above: not always.

Where is the backward compatibility with those chips? Weren't they supposed to be those chips the same = interchangeable?
Quote:

Quote: Are you bipolar? Several times you said that it wasn't enough for compete, and now that it was enough. Look: FIRST make peace with yourself and THEN come back here... I already stated two pathways for AGA's chunky problem i.e. 1. Supply a "game ready" optimized Blitter C2P code sample as part of standard SDK.

You never opened an Amiga SDK, right? Here is it:
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html

WriteChunkyPixels -- write the pen number value of a rectangular array of pixels starting at a specified x,y location and continuing through to another x,y location within a certain RastPort. (V40)
[...]
===chunky-to-planar conversion HW:

GfxBase->ChunkyToPlanarPtr is either NULL, or a pointer to a HW register used to aid in the process of converting 8-bit chunky pixel data into the bit-plane format used by the Amiga custom display chips. If NULL, then such hardware is not present.
[...]
Since WriteChunkyPixels is not (currently) particularly fast on systems without the chunky-to-planar hardware, time critical applications (games, etc) may want to use their own custom conversion routine if GfxBase->ChunkyToPlanarPtr is NULL, and call WriteChunkyPixels() otherwise.

That's part of the Amiga o.s. 3.1 / CD32...
Quote:

or 2. Include chunky pixels mode in hardware.

That's the obvious conclusion which everybody know...
Quote:

Commodore needs to execute one of the pathways. Many mainstream 3rd party game developers couldn't be bothered with figuring out a software workaround for Amiga's chunky pixels problem.

The software workaround is already available, but it doesn't resolve the problem.
Quote:

Akiko C2P is the hardware workaround solution with a smaller install base.

And a very bad one, since your beloved engineers implemented a castrated solution which HALVED its performance.
Quote:

Quote: Have you tried to use the Super-High Res mode? Irrelevant?

Absolutely no: the ECS Denise is the only one which allows to display a Super-High Res mode.

So, again: have you tried it?
Quote:

Quote: So? Was the world aware that the Amiga 3000 have brought the Zorro III? So, Dave Haynie wasn't aware of his Zorro III creation?

What?!? That was NOT the point! Aren't you really able to understand a simple text in YOUR native language?
Quote:

Dave Haynie is a Commodore hardware engineer.

Which stated this:

The whole of the PC industry came up with EISA, which was very much their answer to Zorro III.

Do you agree with him?
Quote:

Consider who made the Zorro III vs EISA comparison. Context is important.

Yes, and it was YOUR beloved engineer: see above.
Quote:

The world doesn't revolve around you.

I've just reported the history, which clearly shows that the above is a pure lie.
Quote:

Quote: And the world finally knew Zorro III... As above.

Again, you aren't able to get it. In YOUR native language.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: @cdimauro You don't know how the things work the silicon industry and continue to talk Irreverent.

No, that's simply a fact.
Quote:

Commodore's "no new chips" directive has its internal Commodore context.

Internal? Who cares? They can say whatever they want to defend their incompetence, but the silicon industry works in certain (which I tried to explain to you, but you still don't get).
Quote:

"Read my lips, no new chips" is a "chant" or "slogan" from Commodore management. https://dictionary.cambridge.org/dictionary/english/chant

Sure. And it still was a lie. FACTs: new chips were developed...
Quote:

For the most part, the A3000 has 32-bit upgrades for the CPU, Fast RAM, Zorro slots, and Chip RAM but the core Amiga graphics architecture remained in their 16-bit variant which is common with ECS-compliant A500 and A2000.

Sure, but crippled: Chip mem accesses are like a 68000.

Only Commodore's engineers made it possible..
Quote:

After removing the original Amiga team's governance over the Amiga R&D, similar ranking Commodore engineers are bickering among themselves on 32-bit Amiga graphics architecture upgrade, hence 16-bit ECS was the fallback option.

Even sticking with 16-bit it could have been MUCH better and faster.
Quote:

Henri Rubin didn't show strong leadership. Examples of road map debates: Jeff Porter has "8 bitplanes with 16 million colors". Dale Luck preferred 16-bit color before moving to 24-bit color. There are more arguments.

People with vision.
Quote:

Quote: You completely missed the context (!) and, specifically, YOUR words: A quick fix would be turning EHB into a proper arbitrary 64-color mode instead of a shadow 32-color set. EHB was a quick fix (as we know, it was a "last minute" change to Denise), but NOT the change that you're asking for, which requires a radical change in the chipset and TRIPLING the registers used for what you've suggested. OCS's EHB was designed under 1985's CSG's chip fabrication capability e.g. 5-micron NMOS process node.

My proposal was compatible with that.
Quote:

C65 used CGS's newer 2-micron CMOS process node. AA Alice used CGS's newer 1.5-micron CMOS process node. During 1990, Commodore was promoting C65 among the 3rd party game developer community when Wing Commander was released in 1990. Quote: From Commodore - The Final Years Commodore’s Large Scale Integration department, headed by Bob Olah, began preliminary investigations in July 1985 into a CMOS 6502 chip which Lenthe called the 55C02. (He eventually shortened the name to 5502.) The LSI group would design the chip using 3 micron CMOS. (skip) On his own, he decided to resurrect the 5502 project, this time using 2 micron CMOS. He dubbed the new chip the 4502. “All new CMOS custom chips were given the series number of 4000 and up, so 4502 was the obvious choice,� he says. “The 4502 core development started in late 1985. The original designers were myself and Charles Hauck.� My argument is coupled with process node improvements with CSG.

Which Commodore's engineer didn't took concrete advantage.

Do you have even a rough idea of what means moving from a 5u to 2u process? It's am ENOURMOUS step which could have allowed TONs of much more RADICAL changes.

Anyway, I still haven't took this factor in my articles.
Quote:

For ECS Denise, Quote: From Commodore - The Final Years (skip) The arguments they made won over Gerard Bucas, and the team accepted that a 12-bit color table and 8 color registers would be too complex to work into the current chip. However, Bob Welland compromised and presented a case for a simpler scheme to allow a 6-bit color palette (64 colors) and only 4 additional color registers. (skip) A few days later, on September 7, Hedley Davis proposed an alternative plan. Instead of putting the color function in a chip, he proposed a 640 by 400 31 KHz scan converter card. The solution would not rely on VGA multisync monitors, but instead would output through the RGB (Red Green Blue color model) port to existing Amiga monitors. The device cost $31.50 in parts for the A2000 board and $40.50 for the A500 board. That's September 1987. ECS mode has an additional four color registers and a 64-color palette.

I know it. But that was a proposal.
Quote:

ECS mode's 8-color with the existing 12-bit palette was rejected due to complexity. LOL

Is it fun? I've to recall you that was about YOUR beloved engineers.
Quote:

A flicker fixer (AMBER) alternative was proposed for A2000 and A500.

The project was for the A3000. Then also A2000 took advantage (not the A500).
Quote:

Unlike ECS 640x400p mode, AGA has a common 16.7 million color palette across 15 kHz and hi-res 31 kHz modes.

Well, with a 1.5u process...
Quote:

Quote: @cdimauro Thanks for showing again how much ignorant you're, since you have no clue at all of how the AGA chipset worked. First of all, you haven't noticed the big bands at the left and right sides. I did notice them and I find them as acceptable compromises

That's because you like demos and not real games: that wasn't an option for the regular Amiga games.
Quote:

i.e. good enough for SNES, it's good enough for Amiga AGA.

Here you don't know how the Amiga and the SNES worked. Specifically, how their graphic controllers worked.

In fact, the SNES had NO big bands at the sides. An horizontal resolution of 256 pixels for it does NOT mean that it has bands at the side: it only means (and it was!) that the system used a DIFFERENT clock to generate the video signal. So, 256 pixels were more or less "overlapped" (taking the same space) of the Amiga's 320 pixels.
Quote:

Quote: @cdimauro Now I explain you why, taking the Blitz documention. http://docs.amiblitz.de/blitzprogrammers/0143.html The number of sprites available will depend on the type of display and the fetchmode settings Most AGA modes will require the display to be shrunk horizontally for 8 sprites to be displayed. [...] Note that it is unrealistic to display more than 4 bitplanes and have more than 3 sprite channels available, the adjust required results in a very narrow display indeed. (cutting your defamation bullshit) Don't assume. I'm aware of the gotchas with AGA.

Then don't reply to my precise statements, since I was reporting the pure FACTs about the AGA.
Quote:

https://youtu.be/33kH9DdNznA?t=588 For the background layer, use the Copper to multiplex the 128-pixel wide 16-color sprites. The 16 colors sprite needs to be ganged. My 64-bit sprite statement assumes Copper multiplexing e.g. tree line background, multiple buildings background, some mountain range background, some clouds background, and 'etc'.

The bands... but I've already told you that you like demos and not games, right?
Quote:

All hardware has design compromises.

Obvious...
Quote:

Did you assume my "higher colors" statement to be strictly 256 colors?

Well, the above video is quite distant from that...
Quote:

In the past, I did state Fast RAM is recommended with 256-color action AGA gaming e.g. Turrcian 2 AGA. I'm aware of AGA's composition capability gotchas. AGA's 2D composition capability issue wouldn't be a problem if the CPU side's frame buffer composition performance was fast enough.

I've already given you my opinion about that: impossible at the Amiga time.
Quote:

https://www.youtube.com/watch?v=5scuw8lgEDc With fast enough compute power, AGA can display 256 color Beats Of Rage. The PC style strong compute with near-dumb frame buffer method.

Again? With PiStorm? When do you start looking at the reality?
Quote:

Note why I prefer cheap compute power from RISC processor approach.

I don't.
Quote:

You haven't realized why I'm biased towards compute power, hint: I'm aware of AGA's composition capability limitations. AGA's 2D composition capability is mostly for backward compatibility and some advancement. AGA's Chip RAM connection with the CPU is fast enough to display generated frames from the CPU side e.g. 61 fps 320x200 with 256 colors.

And you haven't realized that this is out of the context AKA how the things worked at the Amiga time.
Quote:

https://www.youtube.com/watch?v=A39vwT2w5po&t=0s Final Fight AGA tech demo Machine: physical A4000T, gimped 68040 @ 25 MHz, 12 MB Fast RAM Resolution: 320×224 pixels Depth: 7 bitplanes (128 colors) Background layer: 15 colors with 384×144 pixels 68040's compute power needs to be cheap, hence it wouldn't be 68K.

Again: see above. You propose impossible solutions at the time.
Quote:

Quote: Thanks for proving that the hardware guys had no clue on what the developers needed, and it was a software guy that had to tell it to them. Don't stereotype, one of Amiga engineer's road map debaters called for a 3D focus chipset in 1987, but his person didn't have the authority to tell others what to do.

3D on 1987?!? But you understand that those people were just dreamers, without a clue of what was really needed at the time?
Quote:

Jeff Porter called for "8 bitplanes with 16 million colors" i.e. mooooore colors.

How? Which solution have him proposed?
Quote:

Ex-Amiga engineers led 3DO has chunky pixels.

OF COURSE! What do you expected on 1993, still planar graphics?!?
Quote:

My point with Ken Dyke's statement is to show how your "Amiga manual" argument is insufficient.

See above: it was enough. Commodore provided TONs of documentation, examples, and tools for developers.

However, most of the games directly accessed the hardware. And even here, the Hardware manual was more than enough.

Your example brings nothing to that situation.
Quote:

Quote: No, I don't and I don't care because it's completely out of context. It's reverent due to marketplace competition.

Do you understand that you're talking of AFTER the CD32?

That's why I've stated that it's out of context: you're dreaming about impossible things, with the Commodore which was already gone.
Quote:

Quote: @cdimauro Besides that, you continue to completely missi the context: - Magic Carpet -> 1994 - Doom -> 1993. So, Doom appeared by magic? Doom was in development in 1992.

Indeed. How it was developed? Telling to the world what's boiling? How it worked? How it was implemented?

And, more important, which SDK they used? It's a question, not a statement.
Quote:

Raven Software's September 1993 released ShadowCaster has 3D engine improvements after Wolfenstein 3D (May 1992). John Carmack wrote the ShadowCaster 3D engine during his technology research after id Software completed Wolfenstein 3D. ShadowCaster 3D (released in Sep 1993) engine improvements are between Wolfenstein 3D (released in May 1992) and Doom (released in Dec 1993). Magic Carpet was in development in 1993, https://eab.abime.net/showpost.php?p=903812&postcount=17 Magic Carpet's developer focused on chunky pixel graphics effects. PC has established a chunky pixel foundation before the mentioned games' releases.

See above. Then tell me which SDK they have used.
Quote:

Quote: @cdimauro BTW, have you ever opened an Amiga manual? I don't think so. Guess what: they were the Amiga's SDK... Irrelevant. Again, where's the "game ready" optimized blitter C2P sample code in Commodore's 1993 Amiga SDK?

I've already provided it you, since you never opened the Amiga documentation in your life.
Quote:

The main reason for hardware chunky pixels is to make it easier for game programmers to reach the desired graphics effects at acceptable performance.

Tell it to Commodore's engineers...
Quote:

In 1993, some 3rd party game developers were able to release a Wolf3D-like engine on Amiga https://youtu.be/8BnYHHVhJJs?t=988 Legends of Valour was released in 1992 for the MS-DOS. The Amiga/Atari ST version requires additional development time and it was released in 1993. Legends of Valour first began development in May 1991. On the chunky pixels issue, there is less consistency on the Amiga.

Same here: which SDK was used for it?
Quote:

Quote: @cdimauro Thanks for confirming that the hardware guys had still no clue of what was really needed for the C2P, and they created this logic without a DMA (which was available on Akiko), so forcing the CPU to be fully busy on that and DOUBLING the conversion time. Only Amiga engineers made it possible. Ah, and BTW, this was already too late, since we're talking about the CD32. Another proof that the Amiga engineers never understood what was needed for developers and evolved the platform accordingly... Again, where's the "game ready" optimized blitter C2P sample code in Commodore's 1993 Amiga SDK?

See above.
Quote:

------------ Reminder, IBM VGA chunky pixels are very slow. There's a reason why IBM lost the VGA market.

Whatever, but it was important to introduce this graphic card.

@cdimauro

Quote:

@cdimauro No, that's simply a fact.

Your misapplied fact doesn't account for Commodore management's slogan context.

"Commodore The Final Years" reveals ECS mode being distinct from normal Amiga modes.

From Commodore engineering's POV, ECS is for A500, A2000, and A2001 renamed into A3000. Full ECS is tested on older A2000 and A500.

Your retail release point of view is invalid for Commodore management's "read my lips, no new chips" A3000 R&D memo e.g. canceled VRAM-enabled Super A500/A3000 and canceled AA3000+ (for 1991 release using the existing A3000 case).

Meanwhile, the C65 project has CSG's 2-micron process node.

Meanwhile, the Atari TT030 has a 256-color mode released in 1990 with a $2995 price tag and didn't have economies of scale.

Quote:

@cdimauro Internal? Who cares? They can say whatever they want to defend their incompetence, but the silicon industry works in certain (which I tried to explain to you, but you still don't get).

"Commodore The Final Years" book allocates specific blame on certain Commodore personnel who caused strategic damage to Commodore's US operations.

"Commodore the Inside Story- The Untold Tale of a Computer Giant" book blames specific Commodore national subsidiary for A600's debacle, European mainland sales rorts from two Commodore national subsidiaries, and Mehdi Ali and Bill Sydnes.

Quote:

@cdimauro Sure. And it still was a lie. FACTs: new chips were developed...

Your argument is based on external retail product releases, NOT from Commodore's internal "read my lips, no new chips" context. Fact: Full ECS has been tested on A500/A2000.

Removing Commodore management's "read my lips, no new chips" original context is your problem.

Quote:

@cdimauro Sure, but crippled: Chip mem accesses are like a 68000.

It wouldn't solve Turrcian 2 AGA's Fast RAM recommendation.


Read http://amiga.resource.cx/mod/access.html
Quote:

Access incorporates an improved Chip RAM interface which couples it directly to the processor, giving twice as fast memory read performance as of a standard A1200. (skip) Access incorporates the core Amiga chips only: Alice, Paula, Denise and 8520 CIAs. Other chips seen in AGA Amigas designs (Gayle, Budgie) are replaced by a fresh new chip design, offering benefits which among others allowes the increased processor access speed to Chip RAM.

A 3rd party UK company already improved Gayle and Budgie to allow for 2X CPU access into Chip RAM.

A 32-bit bus clean sheet 140 ns (7.1 Mhz effective) read/write cycle FP DRAM wouldn't solve the shared memory bus bottleneck issues.

My point with Quake benchmarks with AGA display is to prove 320x200p 256 colors 61 fps and 640x200p 256 colors 30 fps with existing CPU access into Chip RAM which are good enough for TV's 15 kHz display gaming.


Quote:

@cdimauro Even sticking with 16-bit it could have been MUCH better and faster.

It depends on lower latency FP DRAM prices and availability.

FP DRAM 80 ns access usually has a 140 ns read/write cycle e.g. A1200's FP DRAM chips.

ET4000AX's FP DRAM can be down to 60 ns access and its memory interleave with multiple memory controllers.

Diamond SpeedSTAR24 (with ET4000AX and Samsung-branded KM44C256CP super-fast 60ns access DRAMs). KM44C256CP 60 ns access would have a 110 ns read/write cycle i.e. 9 Mhz effective. Memory interleave can hide latencies.

Quote:

@cdimauro Which Commodore's engineer didn't took concrete advantage. Do you have even a rough idea of what means moving from a 5u to 2u process? It's am ENOURMOUS step which could have allowed TONs of much more RADICAL changes.

I'm only reporting CSG's 2-micron fab capability targeting C65's chipset.

Quote:

@cdimauro Is it fun? I've to recall you that was about YOUR beloved engineers.

Commodore LSI is another engineering group that pushed back after time-wasting monochrome hi-res Denise.

If you don't have proper authority with HR control, you're just solo'ing seeking cooperation with similarly ranked engineers.

Quote:

@cdimauro The project was for the A3000. Then also A2000 took advantage (not the A500).

A3000 did not have a monopoly over Amber and it was removed from A3000+ follow-on. Irving Gould's interview shows A3000 in 1990 and A3000+ in 1991.

Commodore PC's Jeff Frank's advocated for the Amiga to stay in the low end while PC has mid to high-end segments. Bill Sydnes liked Jeff Frank's advocacy and replaced Jeff Porter.
Jeff Porter was moved to the CDTV project.

Pro-PC advocates made up excuses about freezing AA.

When AA project was unfrozen after "more than six months", Commodore was back to the situation that was in March 1991.

From about April 1991 to Feb 1992 (Mehdi Ali's directive for A1200) was mostly time-wasting on ECS and PCs as per Jeff Frank's advocacy.

Jeff Frank directed AA600's high-level specifications, hence the barebone 68EC020-16, 2 MB shared Chip RAM, and existing AA from A3000+. Such specifications are no threat to 386DX-33 or Am386DX-40-based PCs.

Quote:

@cdimauro Here you don't know how the Amiga and the SNES worked. Specifically, how their graphic controllers worked. In fact, the SNES had NO big bands at the sides. An horizontal resolution of 256 pixels for it does NOT mean that it has bands at the side: it only means (and it was!) that the system used a DIFFERENT clock to generate the video signal. So, 256 pixels were more or less "overlapped" (taking the same space) of the Amiga's 320 pixels.

Irreverent. The overall horizontal pixels are similar.

I rather have a lively background compared to a dead background layer in Fightin' Spirit.


Quote:

@cdimauro Then don't reply to my precise statements, since I was reporting the pure FACTs about the AGA.

Don't defame me.


Quote:

@cdimauro The bands... but I've already told you that you like demos and not games, right?

Irreverent.


Quote:

@cdimauro Again? With PiStorm? When do you start looking at the reality?

The primary display is AGA. The heavy lifting 2D compositing is done by the CPU's compute and barrel shifter power.

Unlike other game platforms, "Cheap RISC" wasn't available for the Amiga.

https://www.youtube.com/watch?v=M6Uf_CSa7RI
Mortal Kombat 2 on 386DX. Some cheap RISC CPU @ 40 Mhz beat this CPU.

https://www.youtube.com/watch?v=NudEusAMzr0
Mortal Kombat 2 on Colani 486DLC @ 40Mhz clone i.e. the fake 486.


Quote:

@cdimauro I don't.

That's your problem. Motorola's 68K was pushed out from the mainstream gaming scene for valid reasons.


Quote:

@cdimauro And you haven't realized that this is out of the context AKA how the things worked at the Amiga time.

Like many others, this is why I shifted to a gaming PC in 1992.

Quote:

@cdimauro OF COURSE! What do you expected on 1993, still planar graphics?!? [quote] So, 3DO appeared from magic in its 1993 release year? 3DO's chunky pixels are from its design conception from its project leadership BEFORE its 1993 release year. You flip-flop from retail release POV to armchair project lead. Do you only respond to competitors' product releases like the failed Commodore's #metoo administrators? The project lead "What If" is BEFORE the product's release date. [quote] @cdimauro See above: it was enough. Commodore provided TONs of documentation, examples, and tools for developers. However, most of the games directly accessed the hardware. And even here, the Hardware manual was more than enough.

Apparently, Commodore SDK wasn't good enough for Commodore software engineer, Ken Dyke. This is repeated by John Carmark who doesn't give a damn about creating a software workaround for Amiga's chunky pixel issue.

Many mainstream game developers who focused on texture-mapped 3D targeted the gaming PCs, the "3MB RAM equipped game consoles" group, and the 040 Mac/PowerMac.

Again, https://bigbookofamigahardware.com/bboah/product.aspx?id=1604
Quote:

The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

You're claim of Commodore SDK being enough flies in the face of real-world reality.


Quote:

@cdimauro Whatever, but it was important to introduce this graphic card.

IBM introduced the use cases and target goals for SVGA cloners.

Last edited by Hammer on 12-Aug-2024 at 06:46 AM.

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

@cdimauro

Quote:

@cdimauro Which context? You don't know how (new) chips are made, but you continue to defend the incompetents which wasted all those opportunities.

You argued from the product release stage instead of the internal engineering stage while this topic is about the armchair "What if" technical lead.

You're not consistent.

Quote:

@cdimauro What's considered from them is irrelevant: the reality is that new revisions require new mask, hence new chips. Whether to take advantage of this or not it's entirely up to engineers that can take this opportunity.

You argued from the product release stage instead of the internal engineering stage while this topic is about armchair "What if" technical lead.

Commodore management's read "my lips, no new chips" is an internal memo during the internal engineering stage.

You're not consistent.

Quote:

Neither ECS on some of those older machines: https://bigbookofamigahardware.com/bboah/product.aspx?id=1478 The later 8375 parts (318069 -16/17 and -18/19) are C= spare parts for the earlier pin-out 8372A 1MB and 8372B 2MB Agnus used in the A500/2000 & A3000 respectively. They have VBB markings, and will require a field mod on the motherboard in most cases, as one signal pin's use has changed.

8375 with 318069 -16/17 and -18/19 markings have PAL/NTSC pin-related issues i.e. baked in.

A500 Rev 6A's 2MB Chip RAM jumper configuration is designed for 8372AB 318069-03 just like 8372A 318069-02 that comes with the A500 rev 6A. 8372AB and 8372A are PAL/NTSC parts without the baked-in PAL/NTSC selection.

Your 8375 baked-in NTSC/PAL issue is a red herring to A3000's 8372AB and A500 rev6's inherent 8372AB support.

Quote:

You never opened an Amiga SDK, right? Here is it: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html WriteChunkyPixels -- write the pen number value of a rectangular array of pixels starting at a specified x,y location and continuing through to another x,y location within a certain RastPort. (V40) [...] ===chunky-to-planar conversion HW: GfxBase->ChunkyToPlanarPtr is either NULL, or a pointer to a HW register used to aid in the process of converting 8-bit chunky pixel data into the bit-plane format used by the Amiga custom display chips. If NULL, then such hardware is not present. [...] Since WriteChunkyPixels is not (currently) particularly fast on systems without the chunky-to-planar hardware, time critical applications (games, etc) may want to use their own custom conversion routine if GfxBase->ChunkyToPlanarPtr is NULL, and call WriteChunkyPixels() otherwise.

WriteChunkyPixels API call is very slow on Akiko-less AGA Amigas.

Quote:

From http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html (skip) BUGS Not very fast on systems without chunky-to-planar conversion hardware.

Gotchas is real. You omitted the gotchas BUG section.

Your "You never opened an Amiga SDK" is FALSE.

This is why I stated "game ready" Blitter-optimized C2P since I'm already aware of WriteChunkyPixels API's very slow performance on Akiko-less Amigas.

3rd party Blitter-optimized C2P would NOT be needed if WriteChunkyPixels API is fast enough for games on Akiko-less Amigas.

Grind and Dread games aren't dependent on AmigaOS 3.1's WriteChunkyPixels API since this API is very slow without hardware acceleration.

Grind and Dread games aren't dependent on AmigaOS 3.1's WriteChunkyPixels API since this API is very slow without hardware acceleration.

You're intellectually dishonest.

Quote:

Absolutely no: the ECS Denise is the only one which allows to display a Super-High Res mode. So, again: have you tried it?

Irreverent.

The "high-res" focus is stable Productivity 640 x 480p or D-NTSC 640x400p or D-PAL 640x512p without including overscan.

Super-High Res has aspect ratio issues on 4:3 monitors.

Above 640x480p is 800x600p and 1024x768p.

Quote:

PARROT MODE ON...

You argued from the product release stage instead of the internal engineering stage while this topic is about the armchair "What if" technical lead.

You flip-flop between product release and armchair "What if" technical lead.

You're not consistent.

Last edited by Hammer on 13-Aug-2024 at 04:15 AM.
Last edited by Hammer on 12-Aug-2024 at 07:54 AM.
Last edited by Hammer on 12-Aug-2024 at 07:50 AM.
Last edited by Hammer on 12-Aug-2024 at 07:42 AM.

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

@cdimauro

The main reason for "read my lips, no new chips" for Amiga's core graphics architecture context.

From Commodore - The Final Years,

Quote:

CeBIT Hannover At the annual CeBIT show in Hannover, Germany, held March 8 to 15, 1989, Commodore had lots of products to show. But the only new Amiga system was the A2500UX, a repackaging of the trusty Amiga 2000. Retail pricing and a release date had not yet been determined. Commodore also debuted the PC 30-III, PC 50-III, and PC 60-II. Henri Rubin unveiled a number of Zorro-II expansion cards, a culmination of his earlier strategy to upgrade the existing A2000. The expansions shown at CeBIT included the A2232 serial interface, A2091 SCSI controller, A2630 processor accelerator card with memory, A2024 Hedley Hi-Res, A2350 frame grabber/genlock/video adapter card, Arcnet Cards, Novell Netware for Amiga, and the Lowell Hi-Res Graphics Card

Notice "Lowell Hi-Res Graphics Card" i.e. this is the Texas Instruments TSM34010 card. https://bigbookofamigahardware.com/bboah/product.aspx?id=1439

Henri Rubin's strategy is the upgrade add-on cards for A2000.

Henri Rubin is the major factor for Amiga's 1986 to 1988 lost years.

Henri Rubin is responsible for #metoo monochrome hi-res Denise time wasting debacle.

Last edited by Hammer on 16-Aug-2024 at 01:53 AM.
Last edited by Hammer on 16-Aug-2024 at 01:52 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