@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: That's a very minor change on the C2P logic / implementation. Certainly it does NOT require a NEW idea... That's your problem.

I've no problems, because I understand how the C2P logic works and it's implemented.

In short: you need to fetch a packed/chunky 8-bit screen and the C2P will work exactly in the same way, because the input is always is a sequence of bytes = 8 bits. The output is variable: you can decide to take the first 5 bitplanes, for example, or the first 6, there's no change at all in the logic.

That's elementary stuff to understand, Hammer, and you do NOT need new ideas to implement and output (and only that) of 8 bitplanes instead of 5/6.

@cdimauro

Quote:

It's just 16 bit: there are no 32 bits.

A3000 has 32-bit Chip RAM like in AA Amigas.

Last edited by Hammer on 03-Sep-2024 at 06:04 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Neither the time machine: those were just ideas yet to be discussed. THEN they need to be finalized. Again, from Commodore - The Final Years, Quote: AA First Prototypes Back in September 1989, George Robbins proposed an intermediate level Amiga chipset, called Pandora, to bridge the gap until AAA appeared. The chipset, consisting of a graphics chip called Lisa and an improved Agnus called Alice, was supposed to be ready in early 1990. Rubin had given the go ahead and six chip engineers had been working full time under the project leader, Bob Raible. (skip) As work progressed on the graphics chip, Lisa, it became clear that the timeline was too ambitious. Jeff Porter set a more realistic expectation of late 1990. As Porter predicted, CSG produced the first prototype chips by late November 1990 and testing began. By early December, the team felt the Lisa chip would be delivered ahead of schedule. All but the color table was working, a problem Raible felt he could overcome with a hack. (skip) The AA chips continued to be revised and tested through early 1991 until they were good enough to use in the A1000 Plus and A3000 Plus prototypes. Dave Haynie managed to boot up his A3000 Plus with AmigaOS and the AA chipset in February 1991. (skip) By March 27, when the tested AA chips were ready, the list of stable features was impressive. AA could display 256 colors from a palette of 16 million colors. It could theoretically play 24-bit digital video (although presently it could only display 8-bit video) due to a four times increase in bandwidth (and using the digital-to-analog converter chip in the A3000 Plus). It could use 64-bit sprites, which could now be controlled in the border areas. It had the aforementioned new 8-bit HAM mode, called Super HAM. And finally, the scan doubling and deinterlacing hardware, formerly on Amber, was now handled right on the chip. There were also nine features the engineers discussed in October 1989 which had not yet been implemented, including: 16-bit processor support, 8 MB chip RAM, 16- and 24-bit color modes, faster HAM modes, and a simple integrated digital-to-analog converter (for the low-end Amigas). They also had a list of 10 other features they wanted to add to the AA chipset, primarily in Paula, including: high density floppy support, 16 bit sound, audio input support, (skip) The key words are in bold letters i.e. "Rubin had given the go ahead".

I've seen it, thanks, but again: what's the point here?

And BTW: was Rubin an IBM guy?

@cdimauro

Quote:

cdimauro wrote: In short: you need to fetch a packed/chunky 8-bit screen and the C2P will work exactly in the same way, because the input is always is a sequence of bytes = 8 bits. The output is variable: you can decide to take the first 5 bitplanes, for example, or the first 6, there's no change at all in the logic. That's elementary stuff to understand, Hammer, and you do NOT need new ideas to implement and output (and only that) of 8 bitplanes instead of 5/6.

Officially, CDTV-CR's hardware C2P should not exist. This extra feature is done in rebellion.

_________________
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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: It's just 16 bit: there are no 32 bits. A3000 has 32-bit Chip RAM like in AA Amigas.

That's a completely different thing and it's about the CPU (and only this) interface.

AA was like ECS: a 16-bit chipset. They are the same, from this perspective. Perspective = only the chipset.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: In short: you need to fetch a packed/chunky 8-bit screen and the C2P will work exactly in the same way, because the input is always is a sequence of bytes = 8 bits. The output is variable: you can decide to take the first 5 bitplanes, for example, or the first 6, there's no change at all in the logic. That's elementary stuff to understand, Hammer, and you do NOT need new ideas to implement and output (and only that) of 8 bitplanes instead of 5/6. Officially, CDTV-CR's hardware C2P should not exist. This extra feature is done in rebellion.

I don't care about officiality or not.

I only care about an effective implementation, and it was reported that the C2P logic was ALREDY IMPLEMENTED on the CDTV-CR: hidden or not, that's totally irrelevant on this part of the discussion.

Whereas the CD32 team worked on a NEW (NEW!) idea which they have reported being underlined on a lunch break and implemented in one day.

Those are the FACTs that YOU, not me!, have reported. And which are contracting each other (which is another fact).

Now... work time.

@cdimauro

Quote:

cdimauro wrote: I've seen it, thanks, but again: what's the point here?

My point, engineers can debate and argue, but without Rubin's "go-ahead", it's futile.


Quote:

And BTW: was Rubin an IBM guy?

For Henri Rubin, from https://en.wikipedia.org/wiki/Residual-current_device

Quote:

The world's first high-sensitivity earth leakage protection system (i.e. a system capable of protecting people from the hazards of direct contact between a live conductor and earth), was a second-harmonic magnetic amplifier core-balance system, known as the magamp, developed in South Africa by Henri Rubin. Electrical hazards were of great concern in South African gold mines, and Rubin, an engineer at the company C.J. Fuchs Electrical Industries of Alberton Johannesburg, initially developed a cold-cathode system in 1955 which operated at 525 V and had a tripping sensitivity of 250 mA. Prior to this, core balance earth leakage protection systems operated at sensitivities of about 10 A. The cold cathode system was installed in a number of gold mines and worked reliably. However, Rubin began working on a completely novel system with greatly improved sensitivity, and by early 1956, he had produced a prototype second-harmonic magnetic amplifier-type core balance system (South African Patent No. 2268/56 and Australian Patent No. 218360). The prototype magamp was rated at 220 V, 60 A and had an internally adjustable tripping sensitivity of 12.5–17.5 mA. Very rapid tripping times were achieved through a novel design, and this combined with the high sensitivity was well within the safe current–time envelope for ventricular fibrillation determined by Charles Dalziel of the University of California, Berkeley, USA, who had estimated electrical shock hazards in humans. This system, with its associated circuit breaker, included overcurrent and short-circuit protection. In addition, the original prototype was able to trip at a lower sensitivity in the presence of an interrupted neutral, thus protecting against an important cause of electrical fire. Following the accidental electrocution of a woman in a domestic accident at the Stilfontein gold mining village near Johannesburg, a few hundred F.W.J. 20 mA magamp earth leakage protection units were installed in the homes of the mining village during 1957 and 1958. F.W.J. Electrical Industries, which later changed its name to FW Electrical Industries, continued to manufacture 20 mA single phase and three phase magamp units. At the time that he worked on the magamp, Rubin also considered using transistors in this application, but concluded that the early transistors then available were too unreliable. However, with the advent of improved transistors, the company that he worked for and other companies later produced transistorized versions of earth leakage protection.

https://ipsearch.ipaustralia.gov.au/patents/1957029312
Henri Rubin's Australian Patent No. 218360.

Last edited by Hammer on 03-Sep-2024 at 06:40 AM.
Last edited by Hammer on 03-Sep-2024 at 06:37 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

@cdimauro I don't care about officiality or not.

Being "official" is important within the Commodore's corporate context. Context matters.


Quote:

I only care about an effective implementation, and it was reported that the C2P logic was ALREDY IMPLEMENTED on the CDTV-CR: hidden or not, that's totally irrelevant on this part of the discussion.

Hardware C2P is unofficially implemented for CDTV-CR.


Quote:

Whereas the CD32 team worked on a NEW (NEW!) idea which they have reported being underlined on a lunch break and implemented in one day.

1. It wasn't NEW for Hedley Davis. The "NEW" POV depends on the participants's POV. Context matters.

2. Actual hardware implementation is done by Hedley Davis.

3. Note the "I came in the next morning and Hedley had completed it already, just from the sketch" statement. Hedley Davis has encountered this C2P issue in the CDTV-CR project, hence the very quick execution. LOL.

The software team's requirement made Hedley Davis's unofficial C2P into an official feature.

Last edited by Hammer on 03-Sep-2024 at 06:32 AM.
Last edited by Hammer on 03-Sep-2024 at 06:30 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Officially, CDTV-CR's hardware C2P should not exist. This extra feature is done in rebellion.

Where did you got this informations from? Never heard of it before, and cannot seem to find it anywhere

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: @Hammer Where did you got this informations from? Never heard of it before, and cannot seem to find it anywhere

I posted the following book quote on https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=45301&forum=25&start=0&viewmode=flat&order=0#872569


Again, from Commodore - The Final Years, https://www.kickstarter.com/projects/1462758959/commodore-the-final-years-book

Quote:

“In the CDTV-CR there's a bitplane-to-pixel converter. I was told, ‘No, you can't do that,’ by this guy who wanted to be the boss.� Davis wanted it so badly, he decided to trick his boss. “He wanted a list of all the features that we're putting in the CDTV-CR design so that this is what we agreed to do,� says Davis. “I write a list of these nine features that we were putting in the CDTV-CR and I hand it to him and he takes it. I know he's not going to fucking read it or pay attention to it or really think about it. He's just bossing me around and just being the boss.� One of those features was the forbidden bitplane-to-pixel converter, disguised slightly. “The CDTV-CR comes out and lo and behold there is this bitplane-to-pixel converter,� recalls Davis. “He's like, ‘I can't believe you did that, it wasn't on the list. We had an agreement and you're going to be fired.’� Davis insisted the item was on the list. “He's like, ‘It wasn't on the list.’ I said get the list out. It was at like number eight and I worded it so I never used the nouns ‘bitplane to pixel converter’ but rather came up with some obtuse wording about allowing better graphics processing by minimizing processor overhead for conversion between bitplane or whatever. It was in there but I tricked him by putting it in such a way because I knew he wouldn't read it.�

Last edited by Hammer on 04-Sep-2024 at 12:48 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

cdimauro wrote: That's a completely different thing and it's about the CPU (and only this) interface. AA was like ECS: a 16-bit chipset. They are the same, from this perspective. Perspective = only the chipset.

ECS didn't exploit 32-bit Chip RAM. The "go ahead" for 8 bitplanes capable AA chipset R&D can be given before September 1989.

Due to memory access improvements, ECS Copper can be effective 2X over OCS Copper, but without Fast RAM, ECS is still gimped.

C65's R&D was independent of Henri Rubin since it came from Commodore LSI group.

Last edited by Hammer on 04-Sep-2024 at 01:00 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

In which chip was it implemented?

There's some prototypes running, it would be interesting to check for it.

https://amiga.resource.cx/mod/cdtv2.html

https://amiga.resource.cx/photos/photo2.pl?id=cdtv2&pg=1&res=hi&lang=en

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: I've seen it, thanks, but again: what's the point here? My point, engineers can debate and argue, but without Rubin's "go-ahead", it's futile.

Of course.
Quote:

Quote: And BTW: was Rubin an IBM guy? For Henri Rubin, from https://en.wikipedia.org/wiki/Residual-current_device

It was a joke, Hammer. Relax.

Do you recall that you are always complaining about Commodore's management which was made by PC guys?

Hence my question / joke: was Rubin a PC guy? Rhetoric question, of course: it wasn't, despite making mistakes (BTW, it was a technical guy, anyway).

Clear now?
Quote:

Hammer wrote: @cdimauro Quote: @cdimauro I don't care about officiality or not. Being "official" is important within the Commodore's corporate context. Context matters. Quote: I only care about an effective implementation, and it was reported that the C2P logic was ALREDY IMPLEMENTED on the CDTV-CR: hidden or not, that's totally irrelevant on this part of the discussion. Hardware C2P is unofficially implemented for CDTV-CR.

Totally irrelevant. It's an INTERNAL information / component, and the fact that it wasn't officially announced changes absolutely nothing when talking about implementing the feature on other chips.
Quote:

Quote: Whereas the CD32 team worked on a NEW (NEW!) idea which they have reported being underlined on a lunch break and implemented in one day. 1. It wasn't NEW for Hedley Davis. The "NEW" POV depends on the participants's POV. Context matters. 2. Actual hardware implementation is done by Hedley Davis. 3. Note the "I came in the next morning and Hedley had completed it already, just from the sketch" statement. Hedley Davis has encountered this C2P issue in the CDTV-CR project, hence the very quick execution. LOL. The software team's requirement made Hedley Davis's unofficial C2P into an official feature.

Not according to what YOU have reported.

In fact, Davis has implemented the specs & draft coming from the other three engineers.

Again, that's what YOU've reported.
Quote:

Hammer wrote: @pixie Quote: pixie wrote: @Hammer Where did you got this informations from? Never heard of it before, and cannot seem to find it anywhere I posted the following book quote on https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=45301&forum=25&start=0&viewmode=flat&order=0#872569 Again, from Commodore - The Final Years, https://www.kickstarter.com/projects/1462758959/commodore-the-final-years-book Quote: “In the CDTV-CR there's a bitplane-to-pixel converter. I was told, ‘No, you can't do that,’ by this guy who wanted to be the boss.� Davis wanted it so badly, he decided to trick his boss. “He wanted a list of all the features that we're putting in the CDTV-CR design so that this is what we agreed to do,� says Davis. “I write a list of these nine features that we were putting in the CDTV-CR and I hand it to him and he takes it. I know he's not going to fucking read it or pay attention to it or really think about it. He's just bossing me around and just being the boss.� One of those features was the forbidden bitplane-to-pixel converter, disguised slightly. “The CDTV-CR comes out and lo and behold there is this bitplane-to-pixel converter,� recalls Davis. “He's like, ‘I can't believe you did that, it wasn't on the list. We had an agreement and you're going to be fired.’� Davis insisted the item was on the list. “He's like, ‘It wasn't on the list.’ I said get the list out. It was at like number eight and I worded it so I never used the nouns ‘bitplane to pixel converter’ but rather came up with some obtuse wording about allowing better graphics processing by minimizing processor overhead for conversion between bitplane or whatever. It was in there but I tricked him by putting it in such a way because I knew he wouldn't read it.�

Part of the list -> official. Easy...
Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: That's a completely different thing and it's about the CPU (and only this) interface. AA was like ECS: a 16-bit chipset. They are the same, from this perspective. Perspective = only the chipset. ECS didn't exploit 32-bit Chip RAM.

Neither AGA, with the exception of only fetching the content for display & sprites.
Quote:

The "go ahead" for 8 bitplanes capable AA chipset R&D can be given before September 1989. Due to memory access improvements, ECS Copper can be effective 2X over OCS Copper, but without Fast RAM, ECS is still gimped.

That's what I've already suggested on my previous articles.
Quote:

C65's R&D was independent of Henri Rubin since it came from Commodore LSI group.

All PC guys, right?

@Hammer

Quote:

Hammer wrote: CDTV-CR's hardware C2P wasn't supposed to exist.

As far as we know it didn't.

Quote:

CDTV-CR has two extra custom chips not found in other Amigas i.e. Beauty 391246-01 and Grace 391245-02 (includes Gary/Gayle role) CDTV-CR also includes a system on a chip CSG 4510 that was developed for C65.

According to the Amiga Hardware Database:-

"the newly introduced custom chips, Grace and Beauty, both have their equivalents in the original CDTV."

"Beauty drives the LCD display on the front panel, handles the buttons and the infrared port. It communicates with the rest of the system through the 4510 microcontroller chip."

"Custom chips
...
Grace - system address decoder
Beauty - front panel controller"

I doubt any C2P functionality is hidden in Beauty, given that it isn't connected to the system bus. Denise is exactly the same chip as in the A600. So that only leaves Grace, the 'system address decoder'. If, as you say, it had similar functionality to Gayle, it might have been possible to put a C2P converter it - though it would need a 16-bit data bus connection to be efficient (Gayle only has an 8-bit control port).

@cdimauro

Quote:

cdimauro wrote: The CDTV-CR comes out and lo and behold there is this bitplane-to-pixel converter

What's a 'bitplane-to-pixel converter'? What every Denise has in it, that's what! We need more than this terse description to show that the CDTV-CR had hardware C2P (that's chunky to planar, not 'bitplane to pixel').

I also question what use it would have be been, given that even 6 bitplanes was a severe strain on performance. I wonder what they expected it to be used for.

In any case, the C2P circuitry in Akiko must be significantly different from anything in the CDTV-CR. Even if Grace had something similar in it, they would still have to create an 8 bitplane 32-bit version that could be squeezed into Akiko.

@bhabbott

Quote:

@bhabbott What's a 'bitplane-to-pixel converter'? What every Denise has in it, that's what! We need more than this terse description to show that the CDTV-CR had hardware C2P (that's chunky to planar, not 'bitplane to pixel').

From Commodore - The Final Years,
Quote:

Davis insisted the item was on the list. “He's like, ‘It wasn't on the list.’ I said get the list out. It was at like number eight and I worded it so I never used the nouns ‘bitplane to pixel converter’ but rather came up with some obtuse wording about allowing better graphics processing by minimizing processor overhead for conversion between bitplane or whatever. It was in there but I tricked him by putting it in such a way because I knew he wouldn't read it.�

Focus on "minimizing processor overhead for conversion between bitplane or whatever".


Quote:

@bhabbott I also question what use it would have be been, given that even 6 bitplanes was a severe strain on performance. I wonder what they expected it to be used for. In any case, the C2P circuitry in Akiko must be significantly different from anything in the CDTV-CR. Even if Grace had something similar in it, they would still have to create an 8 bitplane 32-bit version that could be squeezed into Akiko.

OCS/ECS's "dual playfield" feature has up to 6 bitplanes.

AGA's CPU link is 32-bit wide.

From http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html

"The hardware may be viewed as a device which accepts 32 8-bit chunky pixels and outputs 8 long words of bitplane data."

Last edited by Hammer on 04-Sep-2024 at 09:31 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

Neither AGA, with the exception of only fetching the content for display & sprites.

1. AGA is good enough to display 61 fps 320x200p 256 colors Quake demo1 with a fast enough CPU (e.g. CM4 Emu68 @ 1.8Ghz).

Using the same CPU power (RPi 4B Emu68 @ 1.8Ghz), OCS/ECS can do 28.9 fps EHB or 25 fps HAM6.

AGA can do 30 fps 640x200p 256 colors Quake demo1 with a fast enough CPU.

The Quake test shows AGA's 32-bit CPU to 32-bit Chip RAM link is 2X over the OCS/ECS counterpart.

For 2D beat-em-up, OpenBOR's AGA display is also tested with similar results.

It's faster than my recycled ET4000AX ISA on Pentium 166Mhz.

My point with Quake and OpenBOR tests, as long the composer processing source can generate frames at a certain pace, AGA is good enough until the release of Diablo's or StarCraft's 640x480p 256 colors which recommends a Pentium class CPU with PCI and DirectDraw accelerated SVGA card.

It wouldn't be to your liking since AGA's primary 2D composer hardware wasn't substantially updated i.e. AGA Blitter is about 60 percent faster due to memory bandwidth increase.

Like ET6000's strong 2D performance, AAA's stronger 2D performance was canceled due to 3D considerations.

AGA would be a dead duck in 1996.


2. AGA's target goal is entry-level SVGA's 640x480p with 256 colors from 16.77 million color palette since VGA's 640x480p 16 colors from 262,144 color palette were dated in the early 1990s.

In the early 1990s, many low-end SVGA cards have 16.77 million color palette is optional.

On paper, AGA looks reasonable.

Between ET4000AX vs C= AGA, I'm okay with AGA.

Last edited by Hammer on 04-Sep-2024 at 08:54 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Using the same CPU power (RPi 4B Emu68 @ 1.8Ghz), OCS/ECS can do 28.9 fps EHB or 25 fps HAM6

ADoom in EHB 320x200 is steadily above 30 FPS on both ECS and OCS, even with Pi Zero 2 at 1 GHz.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Nice article with the appropriate amount of depth.

It would appear that other than external consultants missing from the equation, Commodore Amiga was a clash of Suits vs. Revolution Engineers. There doesn't seem to have been any or enough Evolution Engineers.

What Suits love are Evolution Engineers. They slowly inch forward a marketed product, providing just enough innovation while keeping the costs low and profit margins high. Unlike Revolution Engineers who have to be constantly reined in from their "Pie in the Sky" MO.

Revolution Engineers compromise via hacks. Evolution Engineers compromise by constantly mining and distilling ongoing R&D projects for useful and implementable innovations that fit timelines and budgets.

The right balance of the two types of engineers is critical, as Intel found out the hard way when having too many Evolution Engineers allowed AMD to revolutionise the desktop, HEDT, workstation, and server CPUs landscape.

_________________
All the way, with 68k

@kolla

Quote:

kolla wrote: @Hammer Quote: Using the same CPU power (RPi 4B Emu68 @ 1.8Ghz), OCS/ECS can do 28.9 fps EHB or 25 fps HAM6 ADoom in EHB 320x200 is steadily above 30 FPS on both ECS and OCS, even with Pi Zero 2 at 1 GHz.

My RPi 4B and CM4 usage removes any CPU related bottlenecks and focus on display adapter capability bottlenecks.

My reason for SAM's Quake port usage is due to HAM6 and EHB display mode support.

ADoom doesn't have HAM6 display mode.

Last edited by Hammer on 05-Sep-2024 at 03:37 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@agami

Lower ranked skillful engineers can debate and argue, but it's nearly futile without the "go ahead" from Henri Rubin.

My cited CDTV-CR's example shows a rouge engineer attempting to improve the Amiga graphics architecture's processing efficiency without approval.

Commodore UK's takeover plan would have removed ineffective managers.

Henri Rubin have given AA with 8 bitplanes project's approval on Sep 1989. Jeff Porter argued for 8 bitplanes with 16 million colors in 1987!

For 8 bitplanes with 16 million colors plan, Henri Rubin could have given the approval before Sep 1989.

C65's 256 color VIC-III chipset R&D's approval given by Commodore LSI's Ted Lenthe.

From Commodore - The Final Years
Quote:

VIC-III Once his boss, Ted Lenthe, approved of a new set of chips, the 33-year-old Gardei began work on a true successor to the legendary VIC-II chip, with backward compatibility and improved graphics modes. By early November 1987 he had mostly figured out the required video timing for his new 4567 chip. To prove the design, he produced a simulation of a CMOS version of the 6567 VIC-II chip. “I showed him working SILOS simulations of the 4567 video chip and we all decided this would not be hard to do,� he says ominously. The VIC-III was perhaps the most important aspect of the new system. In fact, it was exactly what Bil Herd would have wanted to create the C128. With it, the C128 would have made a more powerful impact and perhaps spurred on new game development, making the C128 a mega-hit rather than a modest success it became. The VIC-III would retain backward compatibility with its predecessor chip, unlike the VIC-II, which did not support the VIC video chip modes found in the VIC-20. This would give the VIC-III backward compatibility with C64 software, while adding new graphical modes.

Ted Lenthe is head of Commodore LSI group.

From Commodore - The Final Years, 4 colors with 64 color palette high res Denise compromise

Quote:

The next day, Gerard Bucas called together a meeting between members of the LSI team (Ted Lenthe, Bob Raible, and Victor Andrade) and the system engineers (Jeff Porter, George Robbins, and Bob Welland), along with Hedley Davis from system software and Andy Finkel from the Amiga software group. The LSI group had spent the past year getting the monochrome hi-res Denise to work and did not want to invest an extensive amount of work into the chip when, in their minds, it was obvious something new was needed. 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. At the end of the meeting, the engineers agreed to implement his new scheme, subject to more analysis.

Lower bar effort with the 4 colors with 64 color palette high res Denise.



Continuing from Commodore - The Final Years,
Quote:

AAA Chipset, (skip) Then, after Welland left, the next generation chipset plans sat in limbo until around June 1988, (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.� Engineer Bob Raible soon noted the project was “slipping at a nice predictable rate of one week per week.� AAA was to join the ECS, Amiga 3000 and C65 as yet another project where the deadline was constantly slipping. Something was happening in Commodore. Either all of the management, previously capable, decided all at once to allow their projects to fall hopelessly behind, or there was a root cause. Most engineers felt they knew the root and the solution. Commodore needed an HR department, and it needed to hire more engineers for the vital project. “The AAA chipset had four chips, and there was really only one person working on each one as far as the main architect,� explains Hepler. “I don't have a problem with that, but we could have used some extra support helping to simulate and so forth.� 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.

Unfocused R&D efforts split between C65 and AAA.


Unix group's personnel has expanded.
Quote:

Continuing from Commodore - The Final Years, One of the first members of Commodore’s new Unix team was Randall Howard, who had previously worked with George at Mark Williams on the Coherent Operating system Commodore had purchased. The Unix group soon expanded to around four programmers. “There were a lot of those little teams around,� says Nesbitt. Ominously, Commodore's engineering group jumped from 49 engineers in 1987 to 86 engineers in 1988. It was the C900 project all over again, one that had proven costly and helped bring Commodore close to its destruction. “That was definitely a failure of management, one that I didn't fully appreciate at the time, but in retrospect I can see it was just fatal,� says Nesbitt.

Commodore's R&D spread is not mastering a single technical area i.e. Amiga's core graphics architecture improvements.

NVIDIA's R&D and Microsoft's R&D wasn't this crazy.

Commodore attempted compete against MS/SCO's Xenix (C= AMIX), ATI/Tseng Labs/S3/other SVGA cloners (C= AAA) and Nintendo (C= C65) at the same time.

Microsoft has manpower issues during Windows 1.x with IBM OS/2 project grabbing most of MS's OS engineers with MS Excel group and a tiny few OS engineers keeping Windows 2.X project alive.

Intel's 3 nm process node Arrow Lake has beaten 3 nm process node Qualcomm's Elite X. Pat Gelsinger's Intel is back. With Arrow Lake, Intel is back on my purchase list.

Qualcomm Elite X would be the victim from Intel vs AMD intense competition.

Last edited by Hammer on 05-Sep-2024 at 04:46 AM.
Last edited by Hammer on 05-Sep-2024 at 04:44 AM.
Last edited by Hammer on 05-Sep-2024 at 04:39 AM.
Last edited by Hammer on 05-Sep-2024 at 04:35 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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB