@ppcamiga1

This is actually an interesting area of discussion.

Recently, I wanted to assess the actual performance of Akiko at this task, on a 68030 equipped CD32. Specifically I wanted to know if it had any legs. Conventional wisdom is that it's basically useless after you get to 020+Fast

So I wrote a program with various test cases and a user over at EAB was kind enough to test it on their somewhat exotic 70MHz 68030.

Long story short, Akiko is actually pretty fast at doing the job but you need to disable the Cache Write Allocation flag before you try to talk to it on an 030+.

One of the tests is a theoretical limit test where we wtite and read back 8 longs just from/to CPU registers. It saturates the bus here and we get a conversion rate of around 9 million pixels / second:

Quote:

Case 3: Akiko C2P (Limit) Register to Akiko to Register throughput, CACR Write Allocation Disabled. No initialisation needed. Elapsed: 128092 ticks, 180 ms [20 frames, 111 fps] Perf : 9073529 bytes/second

The FPS rating there is just for the workload on a 320x256x8 display.

The issue is that you have to transfer the data from Fast, to Akilo and then to Chip:

Quote:

Case 5: Akiko C2P (Naive) Chunky read from Fast, planar write to Chip, CACR Write Allocation Disabled. No initialisation needed. Elapsed: 328831 ticks, 463 ms [20 frames, 43 fps] Perf : 3534479 bytes/second

This immediately kills you. Compare this to Kalm's 030 optimised code;

Quote:

Case 8: Kalms C2P (c2p1x1_8_c5_030_2) Chunky read from Fast, planar write to Chip. Initialisation Elapsed: 268881 ticks, 379 ms [20 frames, 52 fps] Perf : 4322531 bytes/second

So we are already faster than Akiko here. But we are also 70MHz. The trick to the C2P code is that it does a lot of the ALU work while the longs are still being written out to chip memory. There isn't much uou can do in the Akiko version here, it's all data transfer as it is.

Out of interest, I decided to see what happens when the destination planes are in Fast memory:

Quote:

Case 9: Akiko C2P (Naive) Chunky read from Fast, planar write to Fast, CACR Write Allocation Disabled. No initialisation needed. Elapsed: 156646 ticks, 220 ms [20 frames, 90 fps] Perf : 7419573 bytes/second ... Case 11: Kalms C2P (c2p1x1_8_c5_030_2) Chunky read from Fast, planar write to Fast. Initialisation Elapsed: 240479 ticks, 338 ms [20 frames, 59 fps] Perf : 4833048 bytes/second

So the real issue with Akiko is that you can't shovel the data fast enough due to chip ram overheads.

The real critical hit punch in the dick is that Akiko has DMA. It manages DMA buffers for the CD drive, for example. If it were able to write the converted planar data to a chip ram location itself, you'd save some of the overhead.

See: https://eab.abime.net/showthread.php?t=117632

_________________
Doing stupid things for fun...

@Karlos

The problem is with "optimized C2P" code requires discovery R&D and it's not standard in the official SDK.

_________________
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

@kolla

Quote:

Indeed. Hence Apple was dabbling with alternatives... you know what I did for summer job at university in 1996? Installing mkLinux - remember mkLinux? And for that matter, remember Apple/UX and Copland? People at Apple knew very well they were up shit creek when it came to OS, and that they needed a rescue.

A/UX provides a familiar MacOS 7 WIMP GUI. Like AMIX, it has AT&T's Unix license issues.
Copland is directionless.

Quote:

Amiga had "Amix", but no real plans for it, instead (apparently) they were going with WinNT for the "next generation" PA-RISC based Amiga.

AMIX's AT&T license is not cheap.

Quote:

Same, DEC Alphas with WinNT, OpenVMS (which I presume what you mean with "VMX/X Window"?) and Tru64 aka OSF/1. Then SparcStation labs with Solaris, and SGI labs with tonloads of Indy's with Irix. Me installing mkLinux on the "mac lab" machines with dual-boot option was parallel to many PC labs already dual-booting Win95 and Linux... having Linux on the PowerMacs brought them into the common regime for all *ix systems. MacOS and Windows on student labs were frequently "reinstalled" by wipe, format and unpack from Linux.

Our Mac labs are usually allocated to journalism subjects.

_________________
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

@ppcamiga1

Quote:

ppcamiga1 wrote: @Rob DOOM on 020 plus akiko plus FAST runs better than affordable 386 in 1994.

Bullshit. Your statement is not true for SX1's 1994 release year.

David Pleasance and Psygnosis push for upgraded CD32 with marginal cost increase was during CD32's development phase.

CD32 FMV module has 512 KB local RAM and the $50 CL450 SoC has a license MIPS-X RISC CPU @ 40Mhz (about 40 MIPS). A no-brainer as to why the MIPS CPU family was selected for Sony's PS1 and PS2 i.e. "cheap RISC CPU".

CD32 couldn't use the CD32 FMV module's MIPS CPU for general-purpose Amiga games.


CD32's FMV module has the following:

1. 24-bit DAC (STM's STV8438CV) for 16.7 million colors display.

2. MPEG-1 decoder (C-Cube CL450, 352 x 240 pixels @ 30hz, 352 x 288 pixels at 25 Hz, pixel interpolation and frame duplication to produce output formats of 704 x 240 pixels at 60 Hz or 704 x 288 pixels at 50 Hz ),

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/060803.PDF

CL450 has about 398K transistors with up to 40 MHz (about 40 MIPS from MIPS-X RISC CPU). CL450 includes a semi-custom MIPS-X RISC CPU with some assist hardware. In quantities of 100K or more per year, the price is less than $50 in 1992. CL450 inherited MIPS-X's instruction set.

3. LSI l64111qc (Digital Audio Decoder, 16-bit DAC),

4. 512 KB local RAM, NEC 423260 DRAM 4Mbit (512 KB) with 80 ns.

5. Lattice ispLSI 1024-60LJ CPLD.

Commodore is willing to spend on this non-core business by following the failed CDI.

Commodore says NO to MIPS RISC processor @ 40 Mhz for Amiga's general-purpose games.

Commodore says NO to 512 KB Fast RAM for Amiga's general-purpose games.

Commodore says NO to 24-bit color 704 x 288p for Amiga's general-purpose games.

Commodore says NO to 16-bit stereo audio for Amiga's general-purpose games.

The argument against $20 DSP3210 is implemented on CD32's higher FMV module with a very narrow functionality!

Last edited by Hammer on 14-Jun-2024 at 03:06 AM.
Last edited by Hammer on 14-Jun-2024 at 03:03 AM.
Last edited by Hammer on 14-Jun-2024 at 02:49 AM.
Last edited by Hammer on 14-Jun-2024 at 02:36 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

@ppcamiga0.5

Quote:

ppcamiga0.5 wrote: agami is well known ng hater...

I'm not just your average well known Amiga NG hater, I have reached "Alligator Tier" in the Official NG-H8R Club.

But that doesn't change the fact that the A1200 was a machine for a market segment which Commodore itself didn't yet understand. It was not the gaming computer which A500 owners saw as a necessary upgrade.

Maybe if they first started with the CD32 for the gamers, and the A4000 for the game devs and creative pros, they might have seen more A500 users make the shift.

The existing A500 install base was the only well from which they could draw water. Based on their finances in early 1993, Commodore would've needed to sell 1 million CD32s in the first year to avoid bankruptcy. Unlikely, but they had a better chance with CD32 than with A1200.

The A1200 could then have come in late 1993 or 1994, with HDD + Fast RAM as standard, as the semi-pro creative dream machine that it was for the many of us who liked games but wanted more, yet could not swing the asking price of an A4000.

The C= engineers made good spaghetti, but Commodore's slinging technique didn't see much of it even reach the proverbial wall.
Carmack could've made Doom a 12-month Amiga exclusive, and it still wouldn't have saved C= from bankruptcy.

_________________
All the way, with 68k

@Hammer

Quote:

Hammer wrote: @Karlos The problem is with "optimized C2P" code requires discovery R&D and it's not standard in the official SDK.

You forgot a wall of text around unrelated chipset performance and price. Are you feeling ok? Do you need assistance?

_________________
Doing stupid things for fun...

Irving Gould killed Commodore. Treated it like a slush fund for his lavish lifestyle and wouldn't allow R&D to happen because he was taking too much out in remuneration. A lot of people blame Mehdi Ali, but he was put there by Gould for good reason.
Source
Source
Source

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@A1200

Quote:

A1200 wrote: Irving Gould killed Commodore. Treated it like a slush fund for his lavish lifestyle and wouldn't allow R&D to happen because he was taking too much out in remuneration. A lot of people blame Mehdi Ali, but he was put there by Gould for good reason.

This "Gould killed Commodore" narrative needs to be addressed.

Your first source is a hit piece which makes Jack Tramiel out to be the hero and Gould the villain. Your other sources aren't much better. There is too much wrong in them to correct in one off-topic post, so I will just summarize the facts:-

1. Gould didn't 'kill' Commodore. The proximate cause of Commodore's collapse was Jack Tramiel. He delivered the fatal wound that nobody could prevent from bleeding out.

2. Fans hate hearing this, but the Amiga's demise was inevitable. Gould supported it to the end, swimming against the tide even though all the industry pundits were bleating 'PC' the whole time.

3. Gould wasn't tech savvy or a shrewd businessman - if he was than Commodore would have gone all-in on PCs from the start and the Amiga wouldn't exist. But that didn't make him a villain except in the eyes of shareholders who were only interested in maximizing profits.

You say Gould 'treated Commodore like a slush fund for his lavish lifestyle' and 'wouldn't allow R&D to happen'. These are lies.

Your source says:-
Quote:

Gould treated Commodore like a bank with a drunk loans officer. In 1989 Commodore sales were in free fall. They had few new products in the pipeline and serious competitors were taking market share left and right but Gould still saw fit to more than double his compensation to $1.25M ($2.25M in 2018 dollars). In 1990, when Commodore only made $1.5M in profit, Gould increased his salary to $1.75M

The person who wrote this obviously never owned a business, or if they did they aren't being honest. In 1989 Commodore made sales of $939 million for a profit of $50.1 million. (source). Amiga sales were up 50% on the previous year, and would continue to climb at an even steeper rate until 1992. Under those circumstances, drawing a miserable $1.2 million from a business whose sole purpose is to make money for its owners isn't unreasonable.

In 1989 Commodore had many products 'in the pipeline'. The author of this article simply doesn't seem to be aware of them. There certainly was plenty of R&D going on - perhaps even too much. You could argue that much of it was going in the wrong direction and I would agree, which wasn't on Gould except for his letting the engineers have a free reign instead of forcing them to focus on the right stuff. But most Amiga fans wouldn't have either, without the benefit of hindsight (some not even then).

For a more accurate account of Commodore's adventures with many interesting facts that most fans aren't aware of I recommend the book 'Commodore the Final Years' by Brian Bagnall, which covers the period from 1987 to 1994. His earlier book 'Commodore the Amiga Years' is also worth reading.

When you read these books, don't fall into the trap of just picking out bits that support a preconceived narrative. Instead, think about what you would have done if you were 'in the hot seat' back then, with an unknown future. And don't be a Mary Sue. If you conclude that you would have made the Amiga a force to be reckoned with that would beat the PC and Mac then I will call BS.

Last edited by bhabbott on 14-Jun-2024 at 06:25 PM.

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Hammer wrote: @Karlos The problem is with "optimized C2P" code requires discovery R&D and it's not standard in the official SDK. You forgot a wall of text around unrelated chipset performance and price. Are you feeling ok? Do you need assistance?

Don't encourage him. I hope he continues this new spam-free posting style.

Hammer may be obnoxious but he does have a point - though not the one he thinks he is making. Commodore freely admitted that their C2P code wasn't 'optimized'. Oh dear black mark against them eh? But neither was the rest of their code. Graphics library was written in C. In OS 3.0 some routines were 'down-coded' to asm to improve efficiency and/or save ROM space, but they still suffered from being generic (which is the price you pay for having a function in the OS).

A game can afford to optimize for a specific use that may not be OS complaint. Most 'optimized' C2P routines are either 'hardwired' for a particular resolution, or use ugly self-modifying code that can't be put in ROM. Such optimization was quite rightly left up to 3rd party developers. Was IBM derided for not providing 'optimized' VGA code to make John Carmack's games run faster? Of course not. He had to figure it out for himself. We should be thankful that Commodore provided a hook to insert our own C2P hardware or software into the OS, rather than just throwing the hardware out there and expecting developers to figure out how to use it (like IBM did).

However not having optimized C2P code did make complaints about the lack of chunky hardware more valid. For that reason alone Akiko C2P was a good thing, even if it wasn't as good as optimized code on faster CPUs. It's just unfortunate that Commodore didn't think of doing it earlier, or even better giving AGA a true chunky mode. Even though it wouldn't have made any difference to games like Doom that needed a fast CPU anyway, it would have made life a bit easier for developers and - perhaps more importantly - improved perception of the Amiga's relevancy in a world dominated by PCs.

Akiko is better than even optimized C2P on a stock CD32 or one with FastRAM. On faster CPUs it's less useful due to being held back by the 14MHz motherboard. An Akiko chip on the accelerator card of an A1200 or A4000 wouldn't suffer from this, and so could be just as fast if not faster than software C2P. Strangely, even though many accelerator cards were made for those machines after the CD32 was released, none included C2P hardware. This suggests that it wasn't an issue for most fans, who simply assumed the faster CPU alone would be sufficient.

Commodore might have improved perceptions by creating optimized code that they could tout as 'just as fast as native chunky on a 50MHz 030 or better'. But that wouldn't help the stock A1200 or CD32. IMO it was better to let 3rd parties do the optimization. Most game developers didn't trust the OS and would probably create their own C2P code anyway.

Last edited by bhabbott on 14-Jun-2024 at 07:59 PM.

@bhabbott

I was genuinely worried he might not be feeling himself.

As can be seen from the results of the tests, Akiko is already faster than the fastest 030 routine (or at least one of the fastest) on the fastest physical 030 (~71MHz!) while on the same 14 MHz bus it on is today, let alone any hypothetical accelerator local bus. It's the transfer to chip ram that knackers everything, even given the terrible PIO non-DMA implementation.

Doing C2P from fast memory back to planes in fast memory via Akiko is significantly faster than the software C2P.

As I said, the own goal was not implementing something to mitigate that read back and write out to chip ram. Akiko has DMA capability, if all you had to do was set some pointer registers and write to it, it could've been a good implementation.

Last edited by Karlos on 14-Jun-2024 at 08:21 PM.

_________________
Doing stupid things for fun...

@Karlos

When you say: 'It's the transfer to chip ram that knackers everything' do you mean:
- 'had not be this and it would be faster then this 70 mhz 030' or
- is it still faster then 70 mhz 030 but could be way faster?

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

@bhabbott

Same team! I was just surfacing the more prevalent information about Gould. I didn't write that stuff, just summarised it. I do own all of Bagnall's books so I have read the history, admittedly not for a while.

So whilst your counter is robust, there's ways about talking to people. I didn't lie, I read the articles and took that from it, from the "chasing of easy money" (i.e. sticking to existing revenue streams) to the PET jet, which is the preserve of big banks, not home computer companies, certainly not in those days.

Jack Tramiel wanted to raise cash through creating more shares - Gould wouldn't allow it through risk of losing control. If true (I am scared to write anything now), then dilution could have happened at a level that didn't hit on a control pain point.

I appreciate your counter to the financials. All I would say is when the going gets tough, he could have helped the cashflow by taking little or nothing. Regardless of the optics, in the UK (I don't know about the States) if you draw a hefty amount then the thing goes belly-up soon after, there can be consequences if creditors are left high and dry and the shareholders/board have given themselves a payout.

The Mary Sue bias is a new one on me, so I have learned something (reminds me of, but not the same, as the Pollyanna Principle). But there's no need to predetermine how I am going to draw conclusions from a book and take me to task as an Amiga evangelical - you don't know me. In your defence, the Amiga community does draw in a lot of oddballs and fantasists and so perhaps you are just wary.

Be nice to discuss things with you when operating at the same level - I have business experience and been around Amigas since the early 90s so I think we would get along if we saw the whites of each other's eyes.

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@pixie

Quote:

pixie wrote: @Karlos When you say: 'It's the transfer to chip ram that knackers everything' do you mean: - 'had not be this and it would be faster then this 70 mhz 030' or - is it still faster then 70 mhz 030 but could be way faster?

The tests showed that a basic Fast to Akiko to Fast conversion would achieve about 90fps for 320*256 8-bit. Kalm's optimised C2P routine gets about 56 under the same conditions. This was for a 70 MHz 68030.

As soon as the destination is chip ram, we get limited. Kalm's routine is, of course, designed around this, where ALU operations on register data carry on while slow chip ram writes are pending. For Akiko all you can do is read the data from Akiko and then write it to chip, with no way do any more of the workload while those writes are ongoing. So the situation reverses now and Kalm's CPU code is faster. However, it's not dramatically so. Kalm's routine now slows to about 52 FPS, and Akiko way down to 45.

_________________
Doing stupid things for fun...

@Karlos

70MHz? That poor chip. Unless it is getting some active cooling?

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Hammer wrote: @Karlos The problem is with "optimized C2P" code requires discovery R&D and it's not standard in the official SDK. You forgot a wall of text around unrelated chipset performance and price. Are you feeling ok? Do you need assistance?

"Development time" is related.

Commodore's official position on the chunky pixels issue:

From 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!

John Carmark's 1994 statement mirrors Ken Dyke's statement during CD32's development.

Commodore being aware of "chunky pixels" problem in 1992 is late.

Nintendo were developing their "chunky pixels" capable SNES since its reveal in September 1987 to 1990's release. SNES has one less problem.

Last edited by Hammer on 15-Jun-2024 at 08:59 AM.
Last edited by Hammer on 15-Jun-2024 at 08:53 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

@bhabbott

Quote:

A game can afford to optimize for a specific use that may not be OS complaint. Most 'optimized' C2P routines are either 'hardwired' for a particular resolution, or use ugly self-modifying code that can't be put in ROM. Such optimization was quite rightly left up to 3rd party developers. Was IBM derided for not providing 'optimized' VGA code to make John Carmack's games run faster? Of course not. He had to figure it out for himself. We should be thankful that Commodore provided a hook to insert our own C2P hardware or software into the OS, rather than just throwing the hardware out there and expecting developers to figure out how to use it (like IBM did).

Wrong.

1. Mode 13h, however, allows the programmer to access the VGA in "chunky" in a linear fashion.

2. Mode X was first published in July 1991 in Dr. Dobb's Journal.

3. Doom wasn't the only texture map 3D game during 1991 to 1993 e.g.

https://www.youtube.com/watch?v=n5JVohTGPgw
IndyCar Racing (Papyrus Design Group) in 1993.

https://www.youtube.com/watch?v=GyaISAkDkZY
Ultima Underworld: The Stygian Abyss in 1992.

https://www.youtube.com/watch?v=jJdz7x9hpUA
Frontier: Elite 2 PC version 1993.

https://youtu.be/uQwAE2EWdl0?t=1818
Geoff Crammond's Formula One Grand Prix PC version has texture-mapped 3D in 1991!

1991 released Wing Commander 2 PC version benefited from VGA's chunky pixels.
Wing Commander 3's 1994 release has textured map 3D.

For the PC, there's a large wave of texture-mapped 3D game releases in 1994 e.g.
Descent,
Doom II,
Wing Commander 3,
Wing Commander Armada,
Heretic (Doom engine license),
System Shock,
Star Wars: TIE Fighter,
Rise of the Triad (modified version of the Wolfenstein 3D engine),
The Elder Scrolls: Arena,
Magic Carpet,
NASCAR Racing (Papyrus Design Group)

Gaming PC can stand against 3DO, Saturn and PS1.

Meanwhile, Intel's revenue is mostly from 486 sales from 1992 to 1994.

From https://www.intel.fr/content/dam/doc/report/history-1994-annual-report.pdf
Intel reported the following
1. In 1994's fourth quarter, Pentium unit sales accounted for 23 percent of Intel's desktop processor volume.
2. Millions of Pentiums were shipped.
3. During Q4 1993 and 1994, a typical PC purchase was a computer featuring the Intel 486 chip.
4. Net 1994 revenue reached $11.5 billion.
5. Net 1993 revenue reached $8.7 billion.
6. Growing demand and production for Intel 486 resulted in a sharp decline in sales for Intel 386 from 1992 to 1993.
7. Sales of the Intel 486 family comprised the majority of Intel's revenue during 1992, 1993, and 1994.
8. Intel reached its 6 to 7 million Pentiums shipped goal during 1994. This is only 23 percent unit volume.
9. Intel's primary revenue home market is the USA, a superpower.

Early 1990s PC's intense vendor competition and rapid 3D games release pacing supports each other.

Only a fake-gamer would focus on Doom's impact.

Last edited by Hammer on 15-Jun-2024 at 02:16 AM.
Last edited by Hammer on 15-Jun-2024 at 02:02 AM.
Last edited by Hammer on 15-Jun-2024 at 01: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 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

Quote:

1. Gould didn't 'kill' Commodore. The proximate cause of Commodore's collapse was Jack Tramiel. He delivered the fatal wound that nobody could prevent from bleeding out.

Fluff with no details.

1. Under Jack Tramiel's Commodore, it didn't further develop MOS/CSG 65xx CPU family in a timely fashion which led to many microcomputer platforms exiting from MOS/CSG 65xx CPU for 16-bit and 32-bit era.

One of those microcomputer platform vendor was Acorn who designed their ARM1 with the aid from VLSI.

Jack Tramiel's Atari selected 68000 instead of MOS/CSG 65xx.

Bagnall's book is missing many components from other sources.

I have read Bagnall's book e.g. Hi-Res Denise "taped out" in Jan 1987.

From Bagnall's book, the direction for Amiga ECS is a "low ball" monochrome Mac and Atari ST.

Ignoring IBM's EGA's "640 x 350p x 16 colors" and PGC's 640 x 480p x 256 colors. 1987's Windows 2.0 used EGA's "640 x 350p x 16 color" and VGA's "640 x 480p x 16 color".

Hi-Res Denise moved from monochrome 8369R1 to a four-color 8373 version.

------------------
DataQuest's VGA sales passed the 1 million mark in 1987.

According to Dataquest November 1989, VGA crossed more than 50 percent market share in 1989 i.e. 56%.
http://bitsavers.trailing-edge.com/components/dataquest/0005190_PC_Graphics_Chip_Sets--Product_Analysis_1989.pdf

Low-End PC Graphics Market Share by Standard Type
Estimated Worldwide History and Forecast

Total low-end PC graphic chipset shipment history and forecast
1987 = 9.2. million, VGA 16.4% market share i.e. 1.5088 million VGA.
1988 = 11.1 million, VGA 34.2% i.e. 1.51 million VGA.
1989 = 13.7 million, VGA 54.6% i.e. 3.80 million VGA.
1990 = 14.3 million, VGA 66.4% i.e. 9.50 million VGA.
1991 = 15.8 million, VGA 76.6% i.e. 12.10 million VGA.
1992 = 16.4 million, VGA 84.2% i.e. 13.81 million VGA.
1993 = 18.3 million, VGA 92.4% i.e. 16.9 million VGA.

The estimate for the Amiga AGA install base is about 600,000 units. PC VGA crushed the Amiga AGA.
------------------

Back to Bagnall's book, Commodore engineers notice Mac II's 256 color capabilities and VGA around early September 1987.

By November 23 (1987), the logic design for the new Color Hi-Res Denise was complete, and layout work began. Samples by XMas 1987.

My comment: VGA's mode 13h is from 1986's MCGA's mode 13h. IBM PCG's 640x480p, 256 colors and PGC monitor use cases were reused for IBM's MCGA, VGA and 8514. SVGA clones were released late 1987 e.g. ET3000.

Back to Bagnall's book, "Porter specifically wanted 1000 by 800 resolution with 8 bit planes and 16 million colors."

Notice Porter's "8 bit planes" focus wasn't factoring VGA's 8-bit chunky pixels.

Thomas Rattigan’s departure in 1987 caused a management shakeup.

Combine this information with "read my lips, no new chips" directive during A3000's R&D.

In comparison, the PC has a solid 256 color chunky pixels use case and the 386 includes a hardware barrel shifter. Windows 2.0 has graphics driver model, Mac ports of MS Excel, MS Word and Aldus PageMaker.

Nintendo has a solid 256 colors chunky pixels Mode 7 plan.

It's confusion with Commodore's R&D.
-----------------
Back to Bagnall's book, US Marketing of A500... confusion reigns.

Quote:

Although the Amiga 1000 marketing was, by all accounts, a resounding failure, Frank Leonardi remained in charge as Commodore’s VP of marketing. Leonardi came from Apple and was part of Gould’s earlier plan to remake Commodore into a business computer company. Gould and his executives still wanted to be like Apple, rather than revelling in Commodore’s natural strengths. As a result, it seemed like Commodore was abandoning the low-cost home computer market it had once dominated.

Leonardi's mistake is attempting to copy Apple's distribution channels without Steve Job's agreements with Bill Gates on MS Excel/Word and other business software vendors.

Leonardi didn't realize A500 didn't have a stable high-resolution mode for business.

Commodore's European operations didn't follow Leonardi's mistakes i.e. focus on C64's market for the A500.

Amiga's graphics architecture not being partitioned would make Amiga's graphics evolution harder.

Last edited by Hammer on 15-Jun-2024 at 09:03 AM.
Last edited by Hammer on 15-Jun-2024 at 08:31 AM.
Last edited by Hammer on 15-Jun-2024 at 08:26 AM.
Last edited by Hammer on 15-Jun-2024 at 04:55 AM.
Last edited by Hammer on 15-Jun-2024 at 03:12 AM.
Last edited by Hammer on 15-Jun-2024 at 03:03 AM.
Last edited by Hammer on 15-Jun-2024 at 03:00 AM.
Last edited by Hammer on 15-Jun-2024 at 02:53 AM.
Last edited by Hammer on 15-Jun-2024 at 02:15 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

@Karlos

so, had we have had an gfx chip similar to aga on the expansion board it could have taken advantage of it. I guess a cheap one might do the trick handled with some fast ram and give a few more perceived speed to a cd32 then a 030 accelerator (if it was also able to provide with an hi color workbench)

I never understood why it took so long to make an expansion board that was able to use a gfx board on amiga 1200, it took until phase5 bvision.

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

@bhabbott

Fast C2P did not exist, at least not for games, there were some DEMOS that run really nice, I always wondered why DEMO groups did not make games, back in 1994/95, fast Forword today, why the fu*k do we keep talking about this, the only way to get proper 3D game experience buying proper 3D graphics card. Software rendering looks ugly or its slow. You can’t compete with hardware T&L, hardware shaders, and all the other stuff, that the graphics cards provides.

Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:34 AM.
Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:32 AM.

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

@pixie

It was hardware and software problem, AmigaOS did not have graphic drivers, before CyberGraphics & Picasso96

it had videomodes and that was it.
P96 drivers are patching the graphics library, this is how its integrated.

Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:30 AM.
Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:30 AM.
Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:29 AM.
Last edited by NutsAboutAmiga on 15-Jun-2024 at 08:27 AM.

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