Was anyone else disappointed with the A1200?

[Bruce Abbott]

Originally Posted by hammer

It wasn't realistic for most mainstream game studios when Amiga lost its premier game platform status around 1992.

The Amiga never really had premier game platform status. In the gaming market, what makes a platform 'premier' is how many copies of a game you can sell. The Amiga didn't have a machine which could produce a sufficiently large user base until around 1987 when the A500 came out. But by that time IBM had introduced the PC-AT with 80286 and EGA in 1984, and PS/2 with 25 MHz 80386DX and VGA in April 1987. As a result the Amiga and PC were neck-in-neck for games, with both platforms seeing a similar number of titles being released each year.

Take for example that 'premier' Amiga game from 1986, Defender of the Crown. It showed off the Amiga's amazing graphics and sound, yet in 1987 it was ported to the PC in EGA and CGA. Why would they 'murder' it like that? Because PC gamers would lap it up even in crappy CGA, and because the PC was just as popular a gaming platform (globally) as the Amiga. We see the same pattern with other games. Far more Amiga games were ported to the PC than vice versa. Why?

In 1992 the average PC was a 386SX with 1MB RAM and standard VGA, no more powerful than an A1200. Yet far more games were produced for PC VGA than AGA, despite the A4000 having similar performance to a 486. The reason - not the hardware, but the much larger installed base and ubiquity of the PC.

Now you might say what you meant by 'premier' was not that the Amiga was the most important or leading platform, but that it had the best gaming hardware. But in that case what about the X68000? Sure it was unknown outside Japan (just like the A1000 was unknown outside the US in 1985-6), but it had hardware rivaling the best arcade machines. And it was introduced in 1987 just like the A500. Shouldn't we be holding that up as the 'premier game platform'?

From Xmas 1989 to Xmas 1991, the Amiga was the premier games platform with many games optimized for the Amiga that showed superiority over Atari ST.

But in 1991 there were more games released for the PC than the Amiga (628 vs 518 according to Moby Games). And those PC games were 'optimized' for the PC! Sure the Amiga crushed the ST, but that wasn't the competitor it had to worry about.

Commodore doesn't have 1st party game studios like Nintendo to promote near-uniform SNES game optimizations.

IBM didn't have 1st party game studios. Neither did Compaq, Dell, Packard Bell, Acer, and a thousand 'OEM' PC clone manufacturers. Yet that didn't stop the PC from becoming the 'premier' computer gaming platform.

Commodore Amiga Technical Support (CATS) is not geared for games like Nintendo's.

The Amiga wasn't a gaming console. It had an advanced multitasking OS capable of doing a lot more, as Jay Miner intended. CATS was geared to support Amiga OS and hardware - but you wouldn't get much support for hardware banging games because Commodore didn't do that themselves and so didn't have code for you to cadge. Unsurprisingly, neither did Microsoft.

Microsoft ported Doom twice i.e. Windows 3.1/WinG/Win32's WinDoom and Windows 95/DirectDraw's Doom95.

They had to do it themselves because John Carmack refused to make a Windows version. But...

WinDoom

WinDoom was a preliminary port of Doom v1.8 to Microsoft Windows 3.1x by a team initially founded by Gabe Newell, with Robert Hess as the primary engineer, using the newly developed Win32s and WinG technologies. This port never made it past beta testing due to the impending release of Windows 95 and because of performance issues on period hardware.

Originally Posted by hammer

Microsoft DirectX has more gaming API coverage when compared to Commodore's AmigaOS 3.1.

DirectX

Microsoft DirectX is a collection of application programming interfaces (APIs) for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms...

The first version of DirectX was released in September 1995 as the Windows Game SDK.

Direct3D

Direct3D is a graphics application programming interface (API) for Microsoft Windows. Part of DirectX, Direct3D is used to render three-dimensional graphics in applications where performance is important, such as games. Direct3D uses hardware acceleration if it is available on the graphics card...

Initial release: June 2, 1996

Amiga OS 3.1 was introduced in 1993. It added a whole 1 function to Amiga OS 3.0 graphics library (WriteChunkyPixels) to support Akiko c2p. Apart from that Amiga OS 3.0, introduced in 1992, was practically the same as far as games were concerned. What was Microsoft doing to support game developers in 1992?

Hardly surprising that Commodore wasn't doing anything in 1995, but they didn't need to. By 1993 they had already given game developers everything they needed to produce OS friendly games.

But hey, there's no denying that Commodore not being around in 1995 was disappointing...

[pandy71]

Originally Posted by Gorf

This would be a total waste of bandwidth!

A much more simple and elegant solution: 16bit chunky BYPASS:
Read from RAM and but the 16bit chunky colour values directly on the DAC pins.
Co Copper, no Lisa, no CLUT - just RAM-->DAC

AGA support 8 bit bypass so technically you can use RAMDAC supporting 8 bit bus (such as Sierra SC11481, SC11486, SC11488) and produce HiColor video.

[Gorf]

Originally Posted by pandy71

AGA support 8 bit bypass so technically you can use RAMDAC supporting 8 bit bus (such as Sierra SC11481, SC11486, SC11488) and produce HiColor video.

That's not really a full bypass - although the Register name would suggest that.

BYPASS=0
Bitplanes are scrolled and prioritized normally, but bypass color table and 8 bit wide data appear on R(7:0)

So data in chipram is still planar, only the colour-lookup is skipped in this mode.
This is rather useless.

I am talking about a full Bypass for chunky 16bit values:
read a 16bit word and pass that value directly to R(4:0), G(5:0), R(4:0)

(add a shift register, to read 4 16bit values at once and feed the values to the DAC one after the other ...)

in DoubleCAS mode (64bit reads) this would give you a HiRES (640x256) screen with 16bit per pixel
(use LoRES for leaving some DMA cycles free for Blitter and CPU)

[TCD]

Originally Posted by Bruce Abbott

The Amiga never really had premier game platform status.

For specific European releases it most likely had. There were quite a few titles between 1990 and 1993 published in Europe that were developed 'primarily' for the Amiga platform. Granted those were dwarfed by Japanese and US sales numbers, but a few of them actually made it from Europe to those markets.

[sokolovic]

Originally Posted by TCD

For specific European releases it most likely had. There were quite a few titles between 1990 and 1993 published in Europe that were developed 'primarily' for the Amiga platform. Granted those were dwarfed by Japanese and US sales numbers, but a few of them actually made it from Europe to those markets.

+1. Actually, not only it had this status but there was also quite a few big houses (or incoming big houses) targeting the Amiga platform first.
We have mentionned them already, probably in this very looping thread.

[AestheticDebris]

Originally Posted by sokolovic

It cannot be discounted either that modern devs are working on their spare time with no, or little, financial retribution, for a niche platform and not any market perspective.

Sure, that's a fair comment. But they also have access to much more powerful toolkits and emulation which allow you to dig around inside the timing of things in ways that weren't practical back in the day.

If it were easy, we'd have seen swathes of Wolfenstein clones flooding the market back when it was the big thing and we really haven't over all these years. Some sort of hardware C2P solution was clearly necessary, the question is whether Akiko was really enough. The somewhat premature demise of CD32 means we'll never know for sure.

[pandy71]

Originally Posted by Gorf

That's not really a full bypass - although the Register name would suggest that.

BYPASS=0
Bitplanes are scrolled and prioritized normally, but bypass color table and 8 bit wide data appear on R(7:0)

So data in chipram is still planar, only the colour-lookup is skipped in this mode.
This is rather useless.

I am talking about a full Bypass for chunky 16bit values:
read a 16bit word and pass that value directly to R(4:0), G(5:0), R(4:0)

(add a shift register, to read 4 16bit values at once and feed the values to the DAC one after the other ...)

in DoubleCAS mode (64bit reads) this would give you a HiRES (640x256) screen with 16bit per pixel
(use LoRES for leaving some DMA cycles free for Blitter and CPU)

This is full bypass, mentioned Sierra RAMDAC's use two 8 bit writes to create 15 bit HiColor. So if you use bypass mode and Sierra RAMDAC 8 bit 640 pixels will be 320 pixel 15 bit video.

You are complaining about OCS\ECS\AGA not able to form chunky organization in planar based memory - to do so your modulo registers should allow interleaving at pixel level not line level. You can try to add some C2P after bypass - then you need to have small memory and some shuffle logic so you can threat each 4, 8 pixels on bitplane as chunky (or packed planar) - in theory using shires single bitplane you can have 160 pixel at 8 bit chunky or 320 pixel packed planar. Using two shires bitplanes you can have 320 pixel 8 bit chunky or 640 pixel packed planar.
This and modulo may even work efficiently (let say even lines are left half and odd lines right half of such chunky).

[sandruzzo]

Let me see it Again: Over The top!

Lea $dff180,a5

move.l $00001111,(a5)+ ; $180-2 at once!
move.l $22223333,(a5)+ ; $184-6 at once!

How is that possible? How was Motorola able to do so?? Some sourcery

How does copper work? The exact same way but with redundancy:

dc.w $0180,$0000
dc.w $0182,$1111
.....

First Copper has to point to the register ($180(, and then it has to store the value... WIth one small change, without any new bus/mem logic, you can almost double the Move performance:

dc.w $0180,$0000 ; load and store the first register
dc.w $1111 ; store new data to $0182
dc.w $2222 ; store new data to $0184

Do this with CAS and DoubleCas for even faster performance with few changes if any! It doesn't seem rocket science to me...

[Gorf]

Originally Posted by pandy71

This is full bypass,

No it is not, since these 8 bits are still spread across 8 different bitplanes
This is not a chunky mode nor is it a real 16bit mode.

You are complaining about OCS\ECS\AGA not able to form chunky organization in planar based memory

The memory in the Amiga is not "planar based".
It is of the shelf DRAM in a continuous address region.
How the data in such region is organized or what such data represents is entirely up to the system.

- to do so your modulo registers should allow interleaving at pixel level not line level.

You don't need interleaving or modulo registers in my simplistic bypass approach ... ok, you need one register defining the length of a line, but that's it.

You can try to add some C2P after bypass

what for?
That defies the purpose of such bypass.

then you need to have small memory and some shuffle logic ...

no no no
you are thinking WAY to complicated!

no need to shuffle anything around - just grab one word of data from ChipRAM at one single address and but that exact word, without any alteration, to the data-lines of the DAC/Vidiot

[Gorf]

Originally Posted by sandruzzo

Let me see it Again: Over The top!

dc.w $0180,$0000 ; load and store the first register
dc.w $1111 ; store new data to $0182
dc.w $2222 ; store new data to $0184

Registers don't work like RAM
You need to select (specify) one (1) and the chip will expect data for this specific register and not for any other

How is that possible? How was Motorola able to do so?? Some sourcery

It serializes the writes

[pandy71]

Originally Posted by Gorf

no no no
you are thinking WAY to complicated!

No, no, no - to form chunky in Amiga you need single bitplane - 1280 pixel wide super hires will give you 160 pixel wide chunky.
Hires 640 will give you 80 pixel wide chunky.
If you need more horizontal pixels then you need to fold more bitplanes but Amiga chipset prevent possibility to set bitplane pointers to form chunky like structure (for example BPL1PTH/BPL1PTL at $10000, BPL2PTH/BPL2PTL at $10002, BPL3PTH/BPL3PTL at$10004, BPL4PTH/BPL4PTL at $10006).
If this could be possible then C2P will be straightforward at the end let say composer.

Originally Posted by Gorf

No it is not, since these 8 bits are still spread across 8 different bitplanes
This is not a chunky mode nor is it a real 16bit mode.

But RAMDAC is not aware of this and it will interpret data as chunky.
With external logic you can do C2P.

Originally Posted by Gorf

The memory in the Amiga is not "planar based".
It is of the shelf DRAM in a continuous address region.
How the data in such region is organized or what such data represents is entirely up to the system.

Of course not - it is interpreted by Agnus (Alice) and Denise (Lisa) as planar (i've used incorrect wording).

Originally Posted by Gorf

You don't need interleaving or modulo registers in my simplistic bypass approach ... ok, you need one register defining the length of a line, but that's it.

Well your simplistic approach is not implemented by Amiga chipset and this is issue.

Originally Posted by Gorf

what for?
That defies the purpose of such bypass.

To "fix" chipset of course. And it not defies anything - this is like modifier of data feed by chipset.

Originally Posted by Gorf

no need to shuffle anything around - just grab one word of data from ChipRAM at one single address and but that exact word, without any alteration, to the data-lines of the DAC/Vidiot

As i pointed earlier - you can do this easily if you are able to set single bitplane and convert it to chunky nibbles/bytes - if you can accept limited resolution then it is fine - limit for OCS is 80 pixels (40 hicolor) and for ECS/AGA 160 pixels (80 hicolor).
Alternatively you can use UHRES logic and for example set some video frame buffer from $A00000 to $B80000 so you can get additional chunky plane.

[Gorf]

Originally Posted by pandy71

No, no, no - to form chunky in Amiga ....

forget about how it is traditionally done on the Amiga -that has nothing to do with my simple approach.
Scrap that from your mind for a moment.

you need single bitplane ...

No.
You need a "wordplane" - or simpler: just one continuous region of memory.

But RAMDAC is not aware of this and it will interpret data as chunky.
With external logic you can do C2P.

Again: that defies entirely the purpose of my approach.
Forget all c2p or p2c.
That has no place in my idea.

Of course not - it is interpreted by Agnus (Alice) and Denise (Lisa) as planar (i've used incorrect wording).

And the Bypass is there to change exactly that!
Forget Denise/Lisa - she is totally sitting on the bench in this game.
Agnus needs to do only one thing:
Call one sequential memory address after the other - just a +1 loop

Well your simplistic approach is not implemented by Amiga chipset and this is issue.

Really, Sherlock!


Of course it is not! That is why I outlined this idea!

[AestheticDebris]

Originally Posted by sandruzzo

First Copper has to point to the register ($180(, and then it has to store the value... WIth one small change, without any new bus/mem logic, you can almost double the Move performance:

dc.w $0180,$0000 ; load and store the first register
dc.w $1111 ; store new data to $0182
dc.w $2222 ; store new data to $0184

And how is the copper supposed to know that $1111 and $2222 are additional parameters and not, in fact, copper instructions? Or are you proposing an entirely different copper, meaning you'd need support for both versions of copper list to remain compatible? And how often do you need to write to that many sequential registers?

Designing something entirely different is easy (personally I'd expand the number of registers a copper write can access if I were doing that, but that's just me) - designing it and keeping it compatible with what already exists is the hard part.

[pandy71]

Originally Posted by Gorf

forget about how it is traditionally done on the Amiga -that has nothing to do with my simple approach.
Scrap that from your mind for a moment.

Once again - this is Amiga so i strictly consider chunky with all Amiga specifics.

In non Amiga case you just design chunky or hi color or true color plane organization and there is no need to talk about bypass.

Originally Posted by Gorf

No.
You need a "wordplane" - or simpler: just one continuous region of memory.

So in case of Amiga single bitplane.

Originally Posted by Gorf

Again: that defies entirely the purpose of my approach.
Forget all c2p or p2c.
That has no place in my idea.

Your idea not work for Amiga and in other cases than Amiga it is irrelevant.

Originally Posted by Gorf

And the Bypass is there to change exactly that!
Forget Denise/Lisa - she is totally sitting on the bench in this game.
Agnus needs to do only one thing:
Call one sequential memory address after the other - just a +1 loop

As i pointed earlier - use single bitplane to get what you propose.

Originally Posted by Gorf

Really, Sherlock!


Of course it is not! That is why I outlined this idea!

Wakey wakey sleeping beauty - this is Amiga forum - once again doing graphics card from ground you are free to use any memory and data organization but in case of Amiga you simply need to adapt already existing design. So or you need to accept single bitplane limitations or use few bitplanes but with quasi chunky way so they can be considered as single large bitplane. This is impossible as Amiga display hardware was designed in a way to prevent creating single large bitplane - modulo granularity is simply too high - at some point you are going to recreate A2024 idea.

[Gorf]

Originally Posted by pandy71

Once again - this is Amiga so i strictly consider chunky with all Amiga specifics.

Which makes no sense in this context ...
I think I made this clear over an over...

I presented an idea, how a very simple 16bit chunky output could have been archived.

In non Amiga case you just design chunky or hi color or true color plane organization and there is no need to talk about bypass.

Of course it is a solution FOR an Amiga - that is why you need to bypass Denice/Alice - hence the name ...
Not so hard to understand - is it?

Your idea not work for Amiga and in other cases than Amiga it is irrelevant.

OMG!
We are talking here since hundreds of pages of alternative solutions ...

This was just my answer to sandruzzo's idea of a modified Copper that would provide higher resolution "copper chunky"

To this I said it would be much easier and more bandwidth efficient to just create a Bypass and feed the DAC/Vidiot directly

Wakey wakey sleeping beauty - this is Amiga forum

You don't say ...

Please follow the thread and the arguments

This is just simple proposal how 16bit chunky (without CLUT) could have been realized with minimal changes - ON AN AGA AMIGA

So I present an idea, what could have been done differently and saying so explicitly from the very beginning - and your criticism is: "but that is not how they did it"

Really??

[hammer]

Originally Posted by pandy71

No, no, no - to form chunky in Amiga you need single bitplane - 1280 pixel wide super hires will give you 160 pixel wide chunky.

Hires 640 will give you 80 pixel wide chunky.
If you need more horizontal pixels then you need to fold more bitplanes but Amiga chipset prevent possibility to set bitplane pointers to form chunky like structure (for example BPL1PTH/BPL1PTL at $10000, BPL2PTH/BPL2PTL at $10002, BPL3PTH/BPL3PTL at$10004, BPL4PTH/BPL4PTL at $10006).
If this could be possible then C2P will be straightforward at the end let say composer.

Graffiti uses Hires 4 bitplanes or SHires 2 bitplanes for 320x256 8-bit chunky pixels.

This is assuming the Amiga remains in Chip RAM-only configuration. 3D needs compute power and stock 68EC020 @ 7 Mhz effective is weak.

The entire Lisa/Chip RAM display path can be bypassed if there's a display adapter on faster Fast RAM and faster compute processor i.e. DSP3210 @ 25 Mhz or 68EC020-25 or higher.

With a bypass display model, an Amiga game or application with chunky pixel usage would trigger the switch over to the new display adapter.
32 bit x 50 Mhz memory bus is 200 MB/s which rivals 3DO's.

CD32 FMV card has a separate chunky pixels display path from AGA. This is a cheap SVGA-like display.
CD32 FMV card's chunky pixels display has 24 bit true color display at Hollywood framerates.

Too bad the FMV card wasn't a general purpose for the Amiga use case i.e. 3D math accelerator, fast MPEG decode, chunky pixels display, and local Fast RAM.

Bitplanes for 2D action.
Chunky pixels for 3D action.

SNES has 256 color chunky pixels mode, but still needs cheap DSP or SuperFX math acceleration.

[grelbfarlk]

A1200 needed at least blast processing.

Taking advantage of a hardware feature in the Yamaha YM7101 VDP graphics processor's DMA unit. On a Mega Drive, it is possible to change the colour palette during the H-blank interval by "DMA-ing" (a.k.a. "blasting") information into CRAM (Color RAM). However, doing so has the (usually) unwanted side effect of creating CRAM dots - rogue pixels which would corrupt the image if the trick was used too often.

Despite this, mid-frame colour palette changes were not unusual on the Mega Drive - Sonic the Hedgehog uses this trick whenever it needs to display water in Labyrinth Zone, and masks the CRAM dots by drawing a flickering water surface sprite roughly where the palette changeover occurs.

However, if the programmer knew when these CRAM Dots were likely to appear, a screen could be drawn just by rapidly changing the palette (i.e. the whole image would be drawn with the CRAM dots glitch). Initially it was thought that this technique could be used to generate 256-colour images.

With EGS 110/24 A1200 could:

• 4 or 8 MB VRAM - 25 ns serial access, 80 ns random access
• the VRAM can be directly accessed by the 68030 or 68040 on the host Combo card
• eight SIMM sockets accept only special 1 MB GVP VRAM-SIMMs in groups of four
• 64 bit interleaved VRAM access
• up to 440 MB/s graphics data bus bandwidth with interleave
• max 576 MB/s blockwrite data bandwidth
• 50 MB/s CPU bus bandwidth - higher in burst mode
• double buffered true colour animations at 720×480 with 318 frames per second
• 64×64 pixels built-in hardware cursor

[hammer]

Originally Posted by Bruce Abbott

The Amiga never really had premier game platform status.

Hint: PC VGA games that didn't use VGA's full 256 color capability and were ported from the Amiga OCS/ECS. Similar artwork quality results are due to the lowest common denominator.

For example, [ Show youtube player ]
PC VGA's Lotus 3 artwork quality is similar to the Amiga OCS version.

When PC VGA artwork quality games kicked in, Amiga OCS struggled.

Originally Posted by Bruce Abbott

In the gaming market, what makes a platform 'premier' is how many copies of a game you can sell.

Artwork influence.

"Atari ST" artwork influence on Amiga OCS.

"Amiga OCS" artwork influence on PC VGA.

Originally Posted by Bruce Abbott

The Amiga didn't have a machine which could produce a sufficiently large user base until around 1987 when the A500 came out. But by that time IBM had introduced the PC-AT with 80286 and EGA in 1984, and PS/2 with 25 MHz 80386DX and VGA in April 1987. As a result the Amiga and PC were neck-in-neck for games, with both platforms seeing a similar number of titles being released each year.

You missed the "Atari ST" effect.

"Atari ST" artwork influence on Amiga OCS games.
"Amiga OCS" artwork influence on PC VGA games

-----
Mode 13h is available on 1986 MCGA. 1987 VGA encapsulates MCGA.

VGA's display parameters and 256-color use case were based on IBM PGA!
Stock PGA monitor can be tweaked for VGA monitor use.

There is a continuous R&D for IBM PC's 256-color use case. Cloners made VGA cheap.

Originally Posted by Bruce Abbott

Take for example that 'premier' Amiga game from 1986, Defender of the Crown. It showed off the Amiga's amazing graphics and sound, yet in 1987 it was ported to the PC in EGA and CGA. Why would they 'murder' it like that? Because PC gamers would lap it up even in crappy CGA, and because the PC was just as popular a gaming platform (globally) as the Amiga. We see the same pattern with other games. Far more Amiga games were ported to the PC than vice versa. Why?

Defender of the Crown was released in November 1986, before A500's April 1987 release. There are not enough A1000 units to make the difference i.e. just a few Tiger tanks against hordes of T-34 tanks.

According to Dataquest November 1989, VGA crossed more than 50 percent market share in 1989 i.e. 56%.
http://bitsavers.trailing-edge.com/c...lysis_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. Wing Commander VGA and Windows 3.0 1990 releases.
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.

https://arstechnica.com/gaming/2017/...-of-commodore/
27,000 A1000?
1987 Amiga sales are 400,000 sales which is not bad against VGA's 1.5 million VGA sales.
1988 Amiga sales are +600,000 sales which is not bad against VGA's 1.51 million VGA sales.
1989 Amiga sales are +640,000 sales against VGA's 3.80 million VGA sales.
1990 Amiga sales are +810,000 sales against VGA's 9.50 million VGA sales. Wing Commander VGA and Windows 3.0 1990 releases.
1991 Amiga sales are 1 million sales against VGA's 12.10 million VGA sales.
1992 Amiga sales fall to 780,000 sales. A600 was released, A500 was canceled, and a $366 million loss.

The estimate for the Amiga AGA install base is about 600,000 units. Around 500,000 AGA units were gained in the 1993 year.

PC VGA needs killer apps for its "Defender of the Crown" moment e.g. the twin Wing Commander VGA and Windows 3.0 1990 releases. VGA sales experienced a large-scale sales jump.

https://dosdays.co.uk/topics/Manufac...tseng_labs.php
By 1991, according to IDC, Tseng Labs held a 25% market share in the total VGA market.

When there were 12.10 million VGA in 1991, about 2.66 million were Tseng Labs VGA clones.

Somebody is ignoring market intelligence.

Originally Posted by Bruce Abbott

In 1992 the average PC was a 386SX with 1MB RAM and standard VGA, no more powerful than an A1200.

"The average PC" argument is flawed.

From https://www.intel.fr/content/dam/doc...ual-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.

Due to PC vendors directly competing against each other, fast X86 CPUs are being bundled, hence creating a self-sustain cycle for the faster X86 PCs with a downward pressure on the distributor's profit margins.

For Australia :
1. during 1992, 386DX-33/40 PC reaches the A500 with 1084S monitor 1989 price range.
2. during 1993, 486SX-33 PC reaches the A500 with 1084S monitor 1989 price range.

Without intense competition, the PC world stagnates e.g. Intel's "quad-core forever" until AMD releases Ryzen.

Originally Posted by Bruce Abbott

Yet far more games were produced for PC VGA than AGA, despite the A4000 having similar performance to a 486.

Nope. A4000/040's A3640 has a gimped memory bus. A4000/040's asking price is nearly that of the Pentium 60-based PC clone.

A4000/040@25Mhz's Doom performance is above A1200 with 68030 @ 50Mhz. [ Show youtube player ]
486SX-25's Doom II performance [ Show youtube player ]
386DX-33 with ET4000AX's Doom [ Show youtube player ]

In absolute terms, 486's VLB (VESA Local Bus) is faster than the Super Buster's Zorro III and Ramsey bus that is designed for 68030 sync mode 25 Mhz.

486SX-33, 486DX-33, and 486DX2-66 have VLB and memory at 33 Mhz.

Amiga's near equivalent is 3rd party CPU accelerator with Local Fast RAM beyond the sync mode of 25 Mhz.

A4000/040 is a joke with a hacked-in 68040 A3640 card. Commodore didn't have a native 68040-based Amiga. An A4000/040 owner would need to purchase something like CPU-less WarpEngine with 040 bus coupled with local Fast RAM and reuse A3640's 68040-25 CPU.

The price difference between A3000T/030 and A3000T/040 is about $400 for an A3640 card.

A3000/A4000 wasn't partitioned like Commodore Canada/Amitech's A2200 clone (CD32 + Amitech's Agent 88).

Originally Posted by Bruce Abbott

The reason - not the hardware, but the much larger installed base and ubiquity of the PC.

Not releasing $1000 USD based 68LC040 based Amiga to counter the 486SX-33 based PC in 1993 was Commodore's fault.

Commodore didn't counter the Am386DX-40-based PC in 1992 with an Amiga equivalent is Commodore's fault. Commodore (driven by Commodore Germany's agenda) sold PC clones in the mid-price range instead!

The Amiga doesn't have a clone market where clone vendors find gaps in the price segments and offer an Amiga solution.

Commodore Canada had the right idea with Amitech's A2200 clones that are based on mass-produced CD32 cards.

Commodore could have sold CD32 motherboards to Amiga cloners who could plug the gaps in Amiga's product stack.

Commodore ran out of time and the warehouse was locked up.

Again, http://archive.computerhistory.org/r...-05-01-acc.pdf
Page 86 of 417, DataQuest 1995

1994 Worldwide Microprocessor Market Share Ranking.

For 1994 Market Share
1. Intel, 73.2%
2. AMD, 8.6%
3. Motorola, 5.2%
4. IBM, 2.2%

Motorola's revenue in 1994 was less than AMD's.
-------------

Supply Base for 32-Bit Microprocessors—1994,
For Product's Share of Total 32-Bit-and-Up MPU Market 1994
Page 89 of 417,

68000, 17%
80386SX/SL, 3%
80386DX, 3%
80486SX, 16%
80486DX, 21%
683XX, 9%
68040, 3%
68030, 1%
68020, 3%
80960, 4%
AM29000, 1%
32X32, 3%
R3000/R4000, 1%
Sparc, 1%
Pentium, 4%
Others, 10%

Motorola wasn't able to convert 68000's success for 68020, 68030 and 68040.

Originally Posted by Bruce Abbott

Now you might say what you meant by 'premier' was not that the Amiga was the most important or leading platform, but that it had the best gaming hardware. But in that case what about the X68000? Sure it was unknown outside Japan (just like the A1000 was unknown outside the US in 1985-6), but it had hardware rivaling the best arcade machines. And it was introduced in 1987 just like the A500. Shouldn't we be holding that up as the 'premier game platform'?

1. X68000 is not in the $1000 USD (about $1500 AUD) price range. X68000 has attracted some Japanese game developers.

2. X68000 platform is a single source. X68000's unit sales are less than 200,000, worse than AGA's total install base.
The Sharp x68000 was the workstation for several Japanese studios used for their art assets, also its hardware was very close to Capcom's CPS arcade board.

SNES was the preferred mass deployment for Capcom's CPS games.

3. PC clone army beats NEC's X86-based PC-98 samurai.

4. Fujitsu's X86-based FM Towns samurai was also defeated by PC clones.

Solo samurai or Jedi was no match against a clone army i.e. "Death by a thousand cuts" or "Quantity has a quality all its own".

ARM's approach is to engage against the X86 with a clone army of its own i.e. clone army vs droid army.

Apple, Sony(PlayStation), and Nintendo exceptional solos that mastered their market niche.

Originally Posted by Bruce Abbott

But in 1991 there were more games released for the PC than the Amiga (628 vs 518 according to Moby Games). And those PC games were 'optimized' for the PC! Sure the Amiga crushed the ST, but that wasn't the competitor it had to worry about.

IBM didn't have 1st party game studios. Neither did Compaq, Dell, Packard Bell, Acer, and a thousand 'OEM' PC clone manufacturers. Yet that didn't stop the PC from becoming the 'premier' computer gaming platform.

Flawed argument. IBM lost "1st party" PC leadership to Wintel and PC clone collective. Furthermore, IBM doesn't own MS-DOS.

PC VGA doesn't need Copper tricks for displaying more than 32 colors.

Compaq is a PC cloner that was part of "the gang of nine". The gang of nine would be headless without Microsoft's MS-DOS/Windows.

Originally Posted by Bruce Abbott

The Amiga wasn't a gaming console.

Amiga has a "game console" hardware generation transition behavior.

Originally Posted by Bruce Abbott

It had an advanced multitasking OS capable of doing a lot more, as Jay Miner intended.

Most Amiga games have "kick-the-OS" behavior.

Originally Posted by Bruce Abbott

CATS was geared to support Amiga OS and hardware - but you wouldn't get much support for hardware banging games because Commodore didn't do that themselves and so didn't have code for you to cadge. Unsurprisingly, neither did Microsoft.

Wrong.

1. PC VGA doesn't need extra "Copper tricks" for displaying more than 32 colors. A simple 1 byte for 256 colors.

2. Windows 95 is a transition from MS-DOS to Windows NT. Microsoft understands backward compatibility with MS-DOS games and apps.

As a 1st party developer for the Windows PC platform, Microsoft ported Doom twice.

Originally Posted by Bruce Abbott

They had to do it themselves because John Carmack refused to make a Windows version. But...

WinDoom

Microsoft is the 1st party for Microsoft DOS and Microsoft Windows platform, NOT IBM.

IBM doesn't own MS-DOS. IBM has a non-exclusive license of MS-DOS known as PC-DOS.

IBM doesn't own Microsoft Windows 3.x.

You need a separate Microsoft Windows 3.x license for OS/2's Windows 3.x compatibility.

Originally Posted by Bruce Abbott

Amiga OS 3.1 was introduced in 1993. It added a whole 1 function to Amiga OS 3.0 graphics library (WriteChunkyPixels) to support Akiko c2p.

That's nearly pointless when there are only 100,000 CD32 shipped and 65,000 CD32 motherboards frozen in the warehouse.

"Less than 1 day job Akiko C2P" didn't even make to AGA baseline.

Originally Posted by Bruce Abbott

Apart from that Amiga OS 3.0, introduced in 1992, was practically the same as far as games were concerned.

PC VGA doesn't need extra "Copper tricks" for displaying more than 32 colors.

Originally Posted by Bruce Abbott

What was Microsoft doing to support game developers in 1992?

https://devblogs.microsoft.com/oldne...9-00/?p=108661

From Raymond Chen of Microsoft

By far, the most popular so-called DOS Extender in the early 1990’s was DOS/4GW. MS-DOS game compatibility occupied a very large portion of my time during Windows 95 development, so I saw a lot of DOS Extender banners, most frequently the DOS/4GW banner.
....
Both Windows and the DOS/4GW DPMI server implement the DPMI interface, so the DOS/4GW DPMI client used standard DPMI calls to communicate with both servers.

This was great for application compatibility, because if there was some issue with how the DOS/4GW client communicated with the DOS/4GW server, we just had to fix it once, and it fixed a lot of games. On the other hand, if the issue couldn’t be fixed, it broke a lot of games.

High risk, high reward.

Miraculously, most games just worked despite running under a different DPMI server from what they were originally developed with. There were occasional issues with specific games. Popular ones include games which assumed that all memory was physical and games which assumed the interrupt flag was unvirtualized, but for the most part, things worked well enough that the remaining issues could be treated as app-specific bugs.

There are more stories like this e.g. user input.

Originally Posted by Bruce Abbott

Hardly surprising that Commodore wasn't doing anything in 1995, but they didn't need to. By 1993 they had already given game developers everything they needed to produce OS friendly games.

Where's your OS-friendly 2D action game example?

Where's the optimized blitter C2P for AGA install base majority?

Have you realized why Commodore thinking about "A1200 on a chip"?

Does Reshoot Proxima 3 run on AmigaOS 4.1 FE without UAE? Hint: it doesn't run.

Does Reshoot Proxima 3 run on AmigaOS 3.1 on Draco? Hint: it doesn't run.

Does Elf Mania run on AmigaOS 4.1 FE without UAE? Hint: it doesn't run.

Does Elf Mania run on AmigaOS 3.1 on Draco? Hint: it doesn't run.

Commodore tried to be a Mac, but the Amiga is NOT a Mac. Every Amiga NG initiative thinks Amiga is like Mac and they failed! You're in lala land to think that the Amiga's core revenue markets are in non-games.

Again, Commodore is a master of none.

[TCD]

Originally Posted by grelbfarlk

double buffered true colour animations at 720×480 with 318 frames per second

I'm not sure that would have been enough. I would say it is crucial to deliver 320 frames per second. Then we'd all be using Commodore phones today!

[hammer]

Originally Posted by TEG

Good remark. They never tried to push the advantage of the machine where it excelled. Mired in the idea that the games market was not for Commodore Business Machines.

However, they did not push any further to acquire a studio to promote professional software for I what know.

Commodore released Amiga Vision in 1992.

Commodore tried to be "IBM", hence Commodore Business Mmachines, but Commodore's core revenue streams are from C64 and A500.

Commodore's PC business is mostly driven by Commodore West Germany's self-interest. Commodore delivered ATI's 1st big OEM contract.

The problem is Commodore West Germany's A2000 (1987) didn't have a stable high-resolution mode for business use cases and the A2000 wasn't mass-produced like the A500. By defeating Amiga Ranger in 1987, it killed Amiga's stable high resolution for business use cases near Windows 2.0's Dec 1987 introduction. For the larger DTP and GUI professional office markets, A2000 was hobbled from the beginning.

A2024 wasn't a mass-produced monitor and crap refresh rates.

Apple Macintosh delivered stable high resolution for DTP, WYSIWYG word processing like MS Word, and GUI spreadsheets like MS Excel for the masses. These are larger markets compared to the Video Toaster niche market.

MS gained experience from the MacOS and ported Mac's MS Excel and MS Word 2.x to Windows 2.x.

Mac port Excel 2.1 for Windows 2.0 was released in 1988.
Mac port Word 2.0 for Windows 2.0 was released in 1989.

This sets the groundwork for the 1990's Windows 3.0 tsunamis.

ECS's 1990 release was too late when PC's Windows 2.x had MS Excel and MS Word Mac ports with PC's VGA in the late 1980s.

MS Word 2.0 Mac port for Windows 2.x knocked out Word Prefect for MS-DOS. Amiga's Word Prefect 4.x and 5.x ports are based on the MS-DOS version instead of the GUI Mac version. Microsoft's growing dominance in the PC office market diminished IBM's OS/2 chances.

Commodore's "soft drink CEO" lacks craftsmanship.

VGA monitor is based on IBM's earlier PGA monitor.

From Commodore Germany's POV for my 1992-1993 price range, buy a Commodore PC, not the Amiga.

Apple didn't have PC loyalists like Commodore West Germany (which later transferred into Escom). Apple is loyal to its in-house platforms.