@babsimov

Quote:

To their defence, I find that the Ranger chipset proposed by Jay Miner was perhaps a little better with the VRAM, but in fact it did not provide enough. Not even a 256 color mode in 1988, it's disappointing from my point of view. Besides it seems that in fact the ECS and the AGA are in fact the Ranger without the management of the VRAM https://retrocomputing.stackexchange.com/questions/2706/what-exactly-was-the-amiga-ranger/2707#2707 http://eab.abime.net/showthread.php?t=77091 https://eab.abime.net/showthread.php?t=86674&page=55 Moreover, in Brian Bagnall's recent books, the Ranger is mentioned and it does not have the 128 color mode that is often mentioned. The 7th plan is in fact a monochrome plan of 1024x1024 which functions in parallel with the displays of the OCS. It was to have something in front of the monochrome mode of the Atari ST. But obligation of VRAM to display that.

For Amiga 2000 Unix workstations which require high-resolution high color modes, the Amiga Ranger chipset was dumped for Commodore A2410 which is based on the PC market's Texas Instruments TMS34010.

Amiga 2000's design originated from Commodore Germany and they have their PC clone mindset.

Commodore A2410 is equipped with 2MB 100ns ZIP RAM and 1 MB videoframe buffer. AmigaOS didn't support RTG during Commodore's existence.

Commodore A2410's TMS34010 didn't progress the Amiga's graphics chipset architecture and served as a distraction.

TMS34010 was released in 1986 and it was used in arcade video games, wannabe TIGA standard, and DOS AutoCAD. TIGA wasn't a clone PC standard like VESA SVGA, IBM 8514/A, and IBM VGA.

TMS34020 was released in 1988 with 3D support via a floating point coprocessor.

SGI defeated most of them and heavily influenced PC's and N64's 3D hardware acceleration architecture. OpenGL cloner named NVIDIA defeated SGI.

Since 1994, Windows NT 3.5 supports OpenGL. Microsoft didn't like the outsider graphics ecosystem to control the Windows platform, hence creating the competing Direct3D.

Valve's founder was the head of Windows 95's DirectDraw efforts and Windows 1.x/2.x/3.x DOS. Valve promoted and developed Proton which is a competent Direct3D clone for Linux-based SteamOS that largely killed Vulkan on the desktop PCs.

Last edited by Hammer on 02-Jun-2023 at 04:55 AM.
Last edited by Hammer on 02-Jun-2023 at 04:38 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: Amiga 2000's design originated from Commodore Germany and they have their PC clone mindset.

The A2000 was a good design. It combined the A1000 with an expansion bus in a practical form factor, as well as allowing for the possibility of using industry standard (ie. PC) cards. The box and power supply was big enough to handle anything you put in it - including NewTek's Video Toaster, which didn't fit in the A3000.

Sure it was inspired by the PC, but that's what Jay Miner wanted too. It's also what customers wanted. NASA started with A1000's, but quickly switched to the A2000 when it came out. Many of my friends had A2000s.

Quote:

AmigaOS didn't support RTG during Commodore's existence.

This is not exactly true. EGS was released in 1992. Compatibility with existing programs wasn't great, but it did work with a number of popular applications and software that only used 'vanilla' OS functions. For stuff that didn't work you still had the original chipset.

Comparing that to PCs of the day, most applications ran in DOS and only knew about text or 'original' CGA/EGA/VGA, which cards had to support 100% in hardware. Not all PCs supported later video cards in the OS. For example I have an Amstrad PC2086 with 8086 CPU and on-board SVGA graphics. Windows 3.x will not run in EGA, VGA or SVGA because Microsoft never produced an 8086 driver for it.

This has nothing to do with planar vs packed. VGA in Windows on PCs was planar too. On a suitably powerful Amiga conversion from chunky to planar only takes a small proportion of CPU time, such that a 50MHz 030 can match a 40MHZ 386DX running Doom, and Shapeshifter emulates a color Mac at practically the same speed on AGA.

In the end it really doesn't matter. The Amiga's design was what it was, and software was designed to work with that. In more modern times accelerator cards became fast enough that it wasn't an issue, and RTG software matured to the point where most applications work on the Workbench screen and/or use RTG when available. This has been true since the mid 90's.

Last edited by bhabbott on 03-Jun-2023 at 02:28 PM.

@bhabbott

Quote:

bhabbott wrote: @Hammer Quote: Hammer wrote: AmigaOS didn't support RTG during Commodore's existence. This is not exactly true. EGS was released in 1992. Compatibility with existing programs wasn't great, but it did work with a number of popular applications and software that only used 'vanilla' OS functions. For stuff that didn't work you still had the original chipset.

EGS was NOT part of the Amiga o.s..

The o.s. never supported RTG: only the planned 4.0 version did it, but it was a WiP and never released.
Quote:

Comparing that to PCs of the day, most applications ran in DOS and only knew about text or 'original' CGA/EGA/VGA, which cards had to support 100% in hardware. Not all PCs supported later video cards in the OS. For example I have an Amstrad PC2086 with 8086 CPU and on-board SVGA graphics. Windows 3.x will not run in EGA, VGA or SVGA because Microsoft never produced an 8086 driver for it.

If "the day" was 1992, who cares about the 8086?!?
Quote:

This has nothing to do with planar vs packed. VGA in Windows on PCs was planar too.

Wrong: it was packed AND planar.
Quote:

On a suitably powerful Amiga conversion from chunky to planar only takes a small proportion of CPU time, such that a 50MHz 030 can match a 40MHZ 386DX running Doom,

Benchmark (exactly the same Doom version should be used for both systems and with the same optimizations and best compilers at the time)?
Quote:

and Shapeshifter emulates a color Mac at practically the same speed on AGA.

Having which resolution and colour depth?

@cdimauro

Quote:

cdimauro wrote: @bhabbott EGS was NOT part of the Amiga o.s..

So? Neither was MUI, TCP/IP etc. Amiga OS was designed to be extendible via patches and shared libraries.

Quote:

If "the day" was 1992, who cares about the 8086?!?

The people who had one? The PC2086 was introduced in 1989 and still being sold in 1991.

Quote:

Wrong: it was packed AND planar.

Windows 3.x on VGA ran in CGA 640x200 in 2 colors, EGA 640x350 in 16 colors, and VGA 640x480 in 16 colors, all of which were planar. Only lores modes such as 320x200 in 4 colors (CGA) and 256 colors (VGA) were packed (EGA 320x200 in 16 colors was planar).

Quote:

Benchmark (exactly the same Doom version should be used for both systems and with the same optimizations and best compilers at the time)?

Of course. :)

The PC version was highly optimized. It took a while to do the same on the Amiga, and still could be better. I did some testing today on Doom Attack and found that - as I suspected - it C2P's the whole screen even when running in a smaller window.

Quote:

Quote: and Shapeshifter emulates a color Mac at practically the same speed on AGA. Having which resolution and colour depth?

According to YouTube videos I have seen, yes. It's quite sad to see SimCity 2000 running faster in Shapeshifter than the native Amiga version on the same machine.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: @bhabbott EGS was NOT part of the Amiga o.s.. So? Neither was MUI, TCP/IP etc. Amiga OS was designed to be extendible via patches and shared libraries.

Nevertheless, all those are NOT part of the Amiga o.s. but they external components.

As I've stated before, the Amiga o.s. never supported RTG.

On the exact contrary: it was designed to be absolutely and strictly linked to the Amiga chipset. Which is clearly evident to anyone which has studied and/or used its APIs.
Quote:

Quote: If "the day" was 1992, who cares about the 8086?!? The people who had one? The PC2086 was introduced in 1989 and still being sold in 1991.

Which means that those people made a wrong choice, having bought an obsolete system.

Because you know what happens with obsolete systems, right? They are... abandoned.
Quote:

Quote: Wrong: it was packed AND planar. Windows 3.x on VGA ran in CGA 640x200 in 2 colors, EGA 640x350 in 16 colors, and VGA 640x480 in 16 colors, all of which were planar. Only lores modes such as 320x200 in 4 colors (CGA) and 256 colors (VGA) were packed (EGA 320x200 in 16 colors was planar).

So, you've confirmed that such graphic cards support BOTH planar and packed graphics...

BTW, 2 colors mode isn't planar (-only): it's both planar AND packed.
Quote:

Quote: Benchmark (exactly the same Doom version should be used for both systems and with the same optimizations and best compilers at the time)? Of course. :) The PC version was highly optimized. It took a while to do the same on the Amiga, and still could be better.

It would be nice to compare both optimizations to see if they got the same attention.
Quote:

I did some testing today on Doom Attack and found that - as I suspected - it C2P's the whole screen even when running in a smaller window.

Sorry, didn't get it: could you please better clarify it?
Quote:

Quote: Having which resolution and colour depth? According to YouTube videos I have seen, yes. It's quite sad to see SimCity 2000 running faster in Shapeshifter than the native Amiga version on the same machine.

That's strange. Colour Macs used high resolutions and colour depths, which are a big problem with AGA, since the chipset is hogging almost all available bandwidth. Not even counting the chunky-to-planar operation which was needed for displaying the framebuffer.

@Hammer

Quote:

1987 IBM VGA is slow despite throwing K7 Athlon XP 2200+ (1800 Mhz) at it. https://www.youtube.com/watch?v=octArwHpaiY

No way! It's like watching Quake on a full screen Amiga! I've never seen a PC so slow.

Quote:

For playing Quake and enough CPU power, Amiga OCS HAM mode beats IBM VGA!

It actually looks full speed. It would lack the 6-bit resolution of VGA. But HAM would make up for lack of 256 colour palette. Of course HAM can do close to hi colour.

I'm not aware of any copper modes to increase palette. Would likely work by switching palette colours per line. But whole lines would be restricted in colours.

@cdimauro

Quote:

It would have been packed, if this graphic format was used, instead.

I wonder now if Mitchy dog had any bearing on this decision.

Quote:

Jay Miner has stated that planar was used because it was more efficient compared to packed. So, this decision has driven the design implementation.

He gave some examples of low colour depths. But then he kept going to 5 or 6 bits where planar has gone beyond its usefulness. At least for single pixels it's the least efficient plotting at that depth.

Quote:

Hum. I don't recall this statement, but if it's true then it's even worse: planar is definitely NOT suitable for 3D graphics.

It may not be in the video. But I can give a reference for it if you have the material. From Commodore: The Amiga Years. Pg 62. From idx on pg 513.

Quote:

Indeed. Packed, at the same color depth, completely destroys planar graphics in terms of performance for rendering 3D stuff.

I don't know how many colours it used on screen. I don't even know exactly how it did render the screen. I imagine, if it was used the hardware as intended, the blitter would have been used to draw polygon outlines and then filled in. So like a primitive version of hardware 3d. Needing to deal with multiple planes would have taxed it. But optimised programming would have organised pallette so blits would be kept to a minimum.

The above chapter also talks about how they reduced sprite engine in favour of blitter. Given blitter needed copying on each plane a better sprite engine may have been better. Since once set in memory you didn't need to worry about depth.

Quote:

How much it was used the HAM mode? Very very little. It was nice for static graphics, for sure, but for common user experience wasn't much useful.

It did feature on box covers. Any paint package worth it's salt included it so you could play with digitised pictures. Although still, it still gave the Amiga that edge above the rest, so nice for a background.

Quote:

BTW and from what I recall, Jay Miner wanted to remove it from the design, but it was late and it would have left a big hole on the chip, so they decided to keep it. That to show that it wasn't even considered useful from the team.

Yes I recall something similar as well. As a contrast, for Akiko, it had space for the chunky converter. I wonder what is more useful, HAM or C2P. Well, hardware C2P wasn't used much and was limited to CD32, best for 68020. I would say HAM wins here, even if it was planar.

Quote:

"Just" read all my articles and you'll get a very close idea of how it would have been. However you need to allocate some time for it, because it's like reading a book (I've written a lot of stuff).

Yes I noticed that after seeing how many chapters you wrote on the subject.,

Quote:

Exactly. The graphic was already... ready for accessing the CLUT.

Direct credit.

Quote:

WinUAE could be modified to test it.

Yes I keep reading comments about using it for that purpose.

Quote:

Then imagine how much worse was it with planar graphics...

Increasingly worse for smaller pixels. Games that worked in blocks of 16 or 32 pixels would be best. Such as a scroller where they could just write new blocks in quickly on the edge of a bitmap.

Quote:

Yes, it's an advantage in this case, but it's worse if you need to access single pixel's data, since you have to change the bitplanes mask using the infamous I/O ports.

Even in hardware that would be inefficient updating single bits.

Quote:

That's why you've to "split" graphic accesses per single planes, to reduce (to 4 time) the masks programming.

That makes VGA look slightly more dynamic. Since it can work with bit planes as well as byte planes or pixel planes. I recall a funny thread about Doom when Carmack was explaining how it rendered to VGA in planes. Someone thought he meant bit planes. No that would be terrible. Lol.

Last edited by Hypex on 04-Jun-2023 at 04:00 PM.

Just a drive by, but there's nothing about HAM that particularly requires planar pixels. I have a few experimental HAM modes in MC64K (not committed yet) and they work perfectly well with chunky pixels.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: [quote]Hum. I don't recall this statement, but if it's true then it's even worse: planar is definitely NOT suitable for 3D graphics. It may not be in the video. But I can give a reference for it if you have the material. From Commodore: The Amiga Years. Pg 62. From idx on pg 513.

I don't have it. Anyway, if it's reported there then to me it's enough that you confirmed it.
Quote:

Quote: Indeed. Packed, at the same color depth, completely destroys planar graphics in terms of performance for rendering 3D stuff. I don't know how many colours it used on screen.

Usually 16 colors were used on 3D games, as a compromise between the graphic quality and rendering speed.
Quote:

I don't even know exactly how it did render the screen. I imagine, if it was used the hardware as intended, the blitter would have been used to draw polygon outlines and then filled in. So like a primitive version of hardware 3d. Needing to deal with multiple planes would have taxed it. But optimised programming would have organised pallette so blits would be kept to a minimum.

The problem with 3D is that you can have many small triangles, which is a disaster if they have to be rendered using the Blitter.

With packed/chunky, you can easily decide to use the CPU for rendering such small triangles (since it's much faster than setting-up the Blitter AND then draw the graphic with it), or use a combination of CPU and Blitter with a modified Bresenham's algorithm to render one horizontal line at the time (until the full triangle is rendered), or just use the Blitter to draw the triangle's sides and then filling it (as I've explained in one of my articles).
Quote:

The above chapter also talks about how they reduced sprite engine in favour of blitter. Given blitter needed copying on each plane a better sprite engine may have been better. Since once set in memory you didn't need to worry about depth.

The two things weren't mutually-exclusive.

Maybe it was due to the overall transistors budget, but the Blitter is located on the Agnus chip (which is the biggest one) and the sprite engine on Denise (which was smaller, AFAIR). So, those decisions weren't influencing both chips and it could have been possible to have a better sprite engine AND the current Blitter design IF the OVERALL transistors budget wasn't the (real) problems.
Quote:

Quote: How much it was used the HAM mode? Very very little. It was nice for static graphics, for sure, but for common user experience wasn't much useful. It did feature on box covers. Any paint package worth it's salt included it so you could play with digitised pictures. Although still, it still gave the Amiga that edge above the rest, so nice for a background.

But very limited and not part of the most common user experience scenarios / usages...
Quote:

Quote: BTW and from what I recall, Jay Miner wanted to remove it from the design, but it was late and it would have left a big hole on the chip, so they decided to keep it. That to show that it wasn't even considered useful from the team. Yes I recall something similar as well. As a contrast, for Akiko, it had space for the chunky converter. I wonder what is more useful, HAM or C2P. Well, hardware C2P wasn't used much and was limited to CD32, best for 68020. I would say HAM wins here, even if it was planar.

Neither were needed. It could have been possible to easily introduce at least 8 bit packed/chunky mode on AGA without requiring the ridiculous C2P hardware converter which was added on Akiko.

Maybe I'll write another article to explain it.

HAM, well, you already know what I think about it.
Quote:

Quote: Then imagine how much worse was it with planar graphics... Increasingly worse for smaller pixels. Games that worked in blocks of 16 or 32 pixels would be best. Such as a scroller where they could just write new blocks in quickly on the edge of a bitmap.

That's what I've also explained on my articles.
Quote:

Quote: Yes, it's an advantage in this case, but it's worse if you need to access single pixel's data, since you have to change the bitplanes mask using the infamous I/O ports. Even in hardware that would be inefficient updating single bits.

It depends. If you want to "randomly" change single pixels, then reprogramming the mask via I/O ports kills performances, so in this case it's better to use the "chained" mode (the usual VGA mode 13h: only 320x200 with 256 colors, because all 4 planes keep exactly the same content) or use a framebuffer in memory and then copy it to the VRAM splitting the operation in 4 parts (one for each plane).

@Hypex

Quote:

Hypex wrote: @Hammer Quote: 1987 IBM VGA is slow despite throwing K7 Athlon XP 2200+ (1800 Mhz) at it. https://www.youtube.com/watch?v=octArwHpaiY No way! It's like watching Quake on a full screen Amiga! I've never seen a PC so slow.

Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode.

At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card.
Quote:

Quote: For playing Quake and enough CPU power, Amiga OCS HAM mode beats IBM VGA! It actually looks full speed. It would lack the 6-bit resolution of VGA. But HAM would make up for lack of 256 colour palette. Of course HAM can do close to hi colour. I'm not aware of any copper modes to increase palette. Would likely work by switching palette colours per line. But whole lines would be restricted in colours.

Whatever. The thing is that in the real world it never existed a so much powerful CPU at the time that allowed to use HAM mode for games.

We had... what was available! Everything else is an impossible wishful thinking...


@Karlos

Quote:

Karlos wrote: Just a drive by, but there's nothing about HAM that particularly requires planar pixels. I have a few experimental HAM modes in MC64K (not committed yet) and they work perfectly well with chunky pixels.

Exactly! A packed/chunky HAM mode is not only possible, but even more efficient.

@cdimauro

Quote:

cdimauro wrote: @Hypex Quote: Hypex wrote: @cdimauro Yes I recall something similar as well. As a contrast, for Akiko, it had space for the chunky converter. I wonder what is more useful, HAM or C2P. Well, hardware C2P wasn't used much and was limited to CD32, best for 68020. I would say HAM wins here, even if it was planar. Neither were needed. It could have been possible to easily introduce at least 8 bit packed/chunky mode on AGA without requiring the ridiculous C2P hardware converter which was added on Akiko. Maybe I'll write another article to explain it.

Here we go: Beyond Akiko: grafica packed al minor costo usando i bitplane

The article is in Italian, but it can be easily translated with DeepL, Google Translate, ChatGPT, etc.

Enjoy!

@Karlos

Given HAM is made up of control words and then colour values it could have made sense to have a control plane and colour plane each with a packed value of each. Even a control plane then three other planes with RGB values. In some ways this would be similar to early Commodore bitmaps where colours had their own space mapping blocks of back and foreground colours. With the bitmap data separate. It was all separated into different spaces. So, HAM really is a quirk as well, since it doesn't exactly map out a bitmap in the usual way but divides control and colour values into a set of planes.

@Hypex

I think "control words" might be a bit grand. Ok, the upper bitplane pair decides how the remaining bitplanes are to be interpreted. You can still do that in chunky. It's not really necessary to separate kr out.

For MC64K, I did make a chunky ham mode that has only 5 bits per gun. However, it has 3 control bits that allow any of the guns to be set simultaneously, e.g. 000xxxxx gives a palette entry x (from a 15 bit RGB) and 111xxxxx sets red green and blue to x. Thus you get all possible 32 grey scale shades for free, without having to use a palette entry.

Last edited by Karlos on 14-Jun-2023 at 11:22 PM.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

This is not exactly true. EGS was released in 1992. Compatibility with existing programs wasn't great, but it did work with a number of popular applications and software that only used 'vanilla' OS functions. For stuff that didn't work you still had the original chipset.

The context of this topic is gaming i.e. specifically Doom games that triggered Amiga's chunky vs planar pixel debate.

Viona Development's EGS wasn't Commodore's in-house RTG standard and it's a failure.

EGS was first presented with the EGS 110/24 card (GVP) at the World of Commodore/Amiga show in New York in April 1992, but its compatibility with most Amiga applications was limited. GVP Spectrum 110/24 card has a 4999 DM price tag in Q2 1992. LOL

Meanwhile...
https://archive.org/details/bub_gb_hqQJaNzN9IcC/page/n603/mode/2up
PC Mag 1992-08, page 604 of 664,
Diamond Speedstar 24 (ET4000AX ISA) has $169 USD

EGS does NOT fix my early 1992 era Amiga 3000's lack of AGA compatibility and Amiga 4000/030 didn't exist in Q4 1992.

There's a mid-range gap between Amiga 1200 and Amiga 4000/040. My dad's 386DX-33 with ET4000AX PC clone purchase in 1992 covered AGA-era games.

Your EGS counterargument is pointless for Amiga's core market which is gaming.
Video Toaster-related Amiga sales can't sustain Commodore.

It's a good thing PiStorm and Raspberry Pi 3A 4B / CM4 exist to end this ridiculous Amiga addon prices.

Quote:

Comparing that to PCs of the day, most applications ran in DOS and only knew about text or 'original' CGA/EGA/VGA, which cards had to support 100% in hardware. Not all PCs supported later video cards in the OS. For example I have an Amstrad PC2086 with 8086 CPU and on-board SVGA graphics. Windows 3.x will not run in EGA, VGA or SVGA because Microsoft never produced an 8086 driver for it.

For Doom-type games, PC SVGA clone cards like ET4000AX speed up VGA's framebuffer performance.

Being "VGA" is meaningless without factoring implementation's performance.

In 1992 for $1300 AUD, it was 386DX-33 with onboard L2 cache and ET4000AX PC clone. Amiga 1200 was priced above $1000 AUD and it has supply issues during Q4 1992.

For Doom, 386DX-33 with ET4000AX PC's performance is similar to an Amiga 1200 with 68030 @ 40 Mhz CPU accelerator card.

The gaming PC minority still outnumbers the entire full 32-bit bus-equipped Amiga user base (A500/A2000 with 32-bit 68020/68030/68040, A1200/020, A3000/030, A3000T/040 A4000/030 and A4000/040) e.g. Doom PC unit sales.

https://doom.fandom.com/wiki/Sales
the PC versions of Doom and Doom II have likely sold over 4 million copies combined

My Dad can spend about $1200 AUD for our Amiga 500 + 1084S monitor in 1989. Our family budget for computers is about $1000 AUD per financial year and this budgeting pattern continued by me.

In 1993 Australia, the 486SX-33 with SVGA PC clone reached $1500 AUD price range and it's about $1000 USD in the United States.

Gateway's price-performance ratio beats Commodore.

Do you want to debate PC Clone vs Amiga AGA prices between late 1992 to late 1993? You're not going to win.

Last edited by Hammer on 17-Jun-2023 at 03:04 AM.
Last edited by Hammer on 16-Jun-2023 at 04:26 AM.
Last edited by Hammer on 16-Jun-2023 at 04:22 AM.
Last edited by Hammer on 16-Jun-2023 at 04:20 AM.
Last edited by Hammer on 16-Jun-2023 at 04:08 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hypex

Quote:

No way! It's like watching Quake on a full screen Amiga! I've never seen a PC so slow

After my Dad bought ex-corporate IBM Model 55SX (386SX-16,x 387 FPU, 5 MB RAM, onboard IBM VGA) in 1990, IBM VGA is slow for Amiga 500 era games.

VGA's performance is dependent on the hardware implementation.

Quote:

It actually looks full speed. It would lack the 6-bit resolution of VGA. But HAM would make up for lack of 256 colour palette. Of course HAM can do close to hi colour. I'm not aware of any copper modes to increase palette. Would likely work by switching palette colours per line. But whole lines would be restricted in colours.

VGA's 256 color mode is 8-bit.

For 256 colour-capable display adapters in 1987, IBM has the following SKUs
1. MCGA (1986 e.g. IBM PS/2 Model 30)
2. VGA
3. 8514 that evolved into XGA.

256-color VGA games ran fine on MCGA as long as they stay to the basic 320×200 256-color mode (from a palette of 262,144, Mode 13h) and didn't attempt to use VGA-specific features such as multiple screen pages.

VGA cloners cause downward costs on IBM VGA and 8514/A.

ET4000AX was a fast VGA framebuffer for Doom and Amiga OCS / AGA era 2D games.

Last edited by Hammer on 16-Jun-2023 at 04:59 AM.
Last edited by Hammer on 16-Jun-2023 at 04:57 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card.

For Quake, Amiga 500's NTSC HAM mode can deliver 18 to 19 FPS with a fast Pentium II 266 / 300 Mhz level soft 68040 CPU (RTG mode has ~60 FPS). 1985-era Amiga 1000's OCS HAM mode should be able to deliver similar results.

The Amiga 1200 can deliver double the performance of 16-bit OCS/ECS i.e. 41 fps. Faster performance is expected when Emu68's Chip RAM performance reaches 7.1 MB/s. It's currently limited to about 5.1 MB/s.


Quote:

Whatever. The thing is that in the real world it never existed a so much powerful CPU at the time that allowed to use HAM mode for games. We had... what was available! Everything else is an impossible wishful thinking...

PiStorm-Emu68's RTG with stock clock speed Raspberry Pi 3A can deliver about 60 fps Quake demo3 320x200 which is about Pentium II 266 to Celeron 300A level.

In terms of IPC, ARM Cortex A53 (dual instruction issue per cycle with RISC) is weaker than Pentium II / Pentium III ( (three instruction issues per cycle with CISC).

Amiga 500's 16-bit OCS is bottlenecking the PiStorm-Emu68's soft 68040 CPU to about 30% of its potential.

Needs something faster than 68060 Rev6 @ 100 Mhz or AC68080 @ 85 Mhz e.g. 68080 @ 200 Mhz which is in line with 1996 era Pentium 166 and 200 Mhz.

Don't focus on ARM Cortex A53's 1.5 Ghz clock speed i.e. it's BS, but it's cheap and low power consumption (for standard A500/A1200 PSU).

PiStorm32 Lite with Emu68 and stock Raspberry Pi 4B (ARM Cortex A72 @ 1.5 Ghz, three instruction issues per cycle) can deliver ~97 fps Quake demo3 320x200 RTG which is about Pentium III 600 Mhz level.

Last edited by Hammer on 16-Jun-2023 at 05:51 AM.
Last edited by Hammer on 16-Jun-2023 at 05:40 AM.
Last edited by Hammer on 16-Jun-2023 at 05:37 AM.
Last edited by Hammer on 16-Jun-2023 at 05:34 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card.

Quote:

I don't have it. Anyway, if it's reported there then to me it's enough that you confirmed it.

Thanks. A summary would be Miner had a contact at Singer and along with Ron Nicholson was able to visit for a tour of their Link military flight simulator. Which was the size of a UPS delivery truck. The space it took up made it a huge computer impressed by it's graphical ability. Nicholson wanted to simulate the graphics and shrink it down into a smaller computer. The blitter was designed to accommodate this by moving images around.

I found a video which looks like it would be the one. While it may look quaint now days with simple ground texturing the air craft are quite detailed for the time and it all looks smooth. F/A 18 Interceptor looks like it in a poor mans way of speaking. I can see what they were going for. But I think they set their heights too high though I did read of ideas like parallel blitters that never made it in.

https://www.youtube.com/watch?v=uy8sJ9AxvYI

Quote:

Usually 16 colors were used on 3D games, as a compromise between the graphic quality and rendering speed.

Yes that makes sense.

Quote:

The problem with 3D is that you can have many small triangles, which is a disaster if they have to be rendered using the Blitter.

They would have needed to check the size and do small ones via CPU. The blitter needs setup obviously, so if the amount of writes to it outweighed just plotting it by hand, apart from the overhead of the operation it makes sense to do it by hand.

Quote:

With packed/chunky, you can easily decide to use the CPU for rendering such small triangles (since it's much faster than setting-up the Blitter AND then draw the graphic with it), or use a combination of CPU and Blitter with a modified Bresenham's algorithm to render one horizontal line at the time (until the full triangle is rendered), or just use the Blitter to draw the triangle's sides and then filling it (as I've explained in one of my articles).

Yes being able to directly plot pixels would make it easy. I imagine on the Amiga drawing the line sides then doing a fill with blitter would be a common technique. Of course the blitter can draw a texture but it's too limited and the result can look like a cartoon.

I thought one way of doing texture mapping would be to use the texture feature to draw objects one line a time with a texture. But, at only 16 pixels wide, it's very short, even though it can be used to draw a rotated line with some math to plot the minterms. Apart from being real inefficient doing it this way the real deal breaker is it cannot warp textures so would be of no practical value in trying to blit a texture map.

Quote:

The two things weren't mutually-exclusive.

No. At the time 8 sprites may have been acceptable. Width was limited as was palette but at least they could be unlimited height and multiplex.

Quote:

Maybe it was due to the overall transistors budget, but the Blitter is located on the Agnus chip (which is the biggest one) and the sprite engine on Denise (which was smaller, AFAIR). So, those decisions weren't influencing both chips and it could have been possible to have a better sprite engine AND the current Blitter design IF the OVERALL transistors budget wasn't the (real) problems.

I agree it would have been overall transistors. And at some point they needed to come to a decision with what it will do and the resources they have. The usual balance between features and compromise.

Quote:

But very limited and not part of the most common user experience scenarios / usages...

Just a limited bonus. It would have been better if the Workbench wasn't so limited. A HAM image as backdrop would have been cool. Sure it needed 6 planes and it ruled out hires. But a desktop being limited to 4 colours for so many years didn't look good for a computer that could allegedly display real images.

Quote:

Neither were needed. It could have been possible to easily introduce at least 8 bit packed/chunky mode on AGA without requiring the ridiculous C2P hardware converter which was added on Akiko.

On the CD32 this would have been better since it was marketed as a games machine. In reality a games machine for Amiga fans. Though at the time a console would been expected to have more than a simple framebuffer for 3d rendering. At least some hardware to assist in 3d.

Quote:

It depends. If you want to "randomly" change single pixels, then reprogramming the mask via I/O ports kills performances, so in this case it's better to use the "chained" mode (the usual VGA mode 13h: only 320x200 with 256 colors, because all 4 planes keep exactly the same content) or use a framebuffer in memory and then copy it to the VRAM splitting the operation in 4 parts (one for each plane).

In that case keeping the same mask would be best. Not sure how such a mask would have worked on the Amiga apart from being in the custom map with bitmap pointers. Not even a parallel blitter would have helped with single or random pixel writes I tend to think.


Quote:

Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card.

So that's causing the slow down. Yes 8.6 FPS is better. Just still a bit short of the 35 FPS standard used in Doom itself. Always wondered why it wasn't 30 FPS. 35 FPS looks like a best case scenario and not what was common on the average PC when it came out.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card. For Quake, Amiga 500's NTSC HAM mode can deliver 18 to 19 FPS with a fast Pentium II 266 / 300 Mhz level soft 68040 CPU (RTG mode has ~60 FPS). 1985-era Amiga 1000's OCS HAM mode should be able to deliver similar results. The Amiga 1200 can deliver double the performance of 16-bit OCS/ECS i.e. 41 fps. Faster performance is expected when Emu68's Chip RAM performance reaches 7.1 MB/s. It's currently limited to about 5.1 MB/s. Quote: Whatever. The thing is that in the real world it never existed a so much powerful CPU at the time that allowed to use HAM mode for games. We had... what was available! Everything else is an impossible wishful thinking... PiStorm-Emu68's RTG with stock clock speed Raspberry Pi 3A can deliver about 60 fps Quake demo3 320x200 which is about Pentium II 266 to Celeron 300A level. In terms of IPC, ARM Cortex A53 (dual instruction issue per cycle with RISC) is weaker than Pentium II / Pentium III ( (three instruction issues per cycle with CISC). Amiga 500's 16-bit OCS is bottlenecking the PiStorm-Emu68's soft 68040 CPU to about 30% of its potential. Needs something faster than 68060 Rev6 @ 100 Mhz or AC68080 @ 85 Mhz e.g. 68080 @ 200 Mhz which is in line with 1996 era Pentium 166 and 200 Mhz. Don't focus on ARM Cortex A53's 1.5 Ghz clock speed i.e. it's BS, but it's cheap and low power consumption (for standard A500/A1200 PSU). PiStorm32 Lite with Emu68 and stock Raspberry Pi 4B (ARM Cortex A72 @ 1.5 Ghz, three instruction issues per cycle) can deliver ~97 fps Quake demo3 320x200 RTG which is about Pentium III 600 Mhz level.

Nevertheless, the question is always the same: those comparisons as totally irrelevant and useless. Because such monster CPUs weren't available at the time.

Besides that, HAM mode is NOT suitable for games due to the graphical artifacts which it generates.

Plus, it's limited to 16 color shades, whereas VGA offered 64 shades since 1987 and that allowed to reproduce more realistic colors (even using just 256 colors. But it was possible to change some colors each scan line by reprogramming some RAMDAC's entries, like the Copper allowed with the Amiga chipset. However I never tried and I don't know how many of them can be changed during the horizontal blank period).

Now one question to you: why you became a PiStorm evangelist, since it lacks 68K's PMMU and 80bit FPU precision... exactly like the Apollo core's 68080 which you continuously bashed for exactly the same things?

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card. Quote: I don't have it. Anyway, if it's reported there then to me it's enough that you confirmed it. Thanks. A summary would be Miner had a contact at Singer and along with Ron Nicholson was able to visit for a tour of their Link military flight simulator. Which was the size of a UPS delivery truck. The space it took up made it a huge computer impressed by it's graphical ability. Nicholson wanted to simulate the graphics and shrink it down into a smaller computer. The blitter was designed to accommodate this by moving images around. I found a video which looks like it would be the one. While it may look quaint now days with simple ground texturing the air craft are quite detailed for the time and it all looks smooth. F/A 18 Interceptor looks like it in a poor mans way of speaking. I can see what they were going for. But I think they set their heights too high though I did read of ideas like parallel blitters that never made it in. https://www.youtube.com/watch?v=uy8sJ9AxvYI

This was like Sci-Fi for a mainstream commercial product like the computers available at the time for the masses. It was impossible to get something which is even resembling it.

And, as I've said before, the Blitter is NOT suited for such kind of tasks because of the planar graphics.

So, if this was the aim for such changes to the Blitter, then it was totally non-realistic to achieve the goal.
Quote:

Quote: The problem with 3D is that you can have many small triangles, which is a disaster if they have to be rendered using the Blitter. They would have needed to check the size and do small ones via CPU. The blitter needs setup obviously, so if the amount of writes to it outweighed just plotting it by hand, apart from the overhead of the operation it makes sense to do it by hand.

Yes, but the 68000 sucks at setting / clearing single bits (common case for small triangles) in memory: it's horrible slow. And you've to do it 4 times (for a 16 colors screen).
Quote:

Quote: With packed/chunky, you can easily decide to use the CPU for rendering such small triangles (since it's much faster than setting-up the Blitter AND then draw the graphic with it), or use a combination of CPU and Blitter with a modified Bresenham's algorithm to render one horizontal line at the time (until the full triangle is rendered), or just use the Blitter to draw the triangle's sides and then filling it (as I've explained in one of my articles). Yes being able to directly plot pixels would make it easy. I imagine on the Amiga drawing the line sides then doing a fill with blitter would be a common technique.

That was the way at the time, because the Blitter was very fast at filling polygon areas.
Quote:

Of course the blitter can draw a texture but it's too limited and the result can look like a cartoon.

Those "textures" were very limited because you can only use very very limited and fixed patters, like for reproducing a reticulate net effect used for simulating shadows, for example.

Whereas the packed implementation that I've suggested on one article of my series is able to perform a limited "texture mapping" by allowing to draw any image. It's limited because it doesn't take into account the zoom, rotate, and perspective: it's just like filling an area with an image. But, hey, better than nothing and WAY better than what the Amiga Blitter offered.
Quote:

I thought one way of doing texture mapping would be to use the texture feature to draw objects one line a time with a texture. But, at only 16 pixels wide, it's very short, even though it can be used to draw a rotated line with some math to plot the minterms. Apart from being real inefficient doing it this way the real deal breaker is it cannot warp textures so would be of no practical value in trying to blit a texture map.

It suffers from the same limits of the Amiga Blitter. Besides that, this is more or less what I've proposed on my article.
Quote:

Quote: But very limited and not part of the most common user experience scenarios / usages... Just a limited bonus. It would have been better if the Workbench wasn't so limited. A HAM image as backdrop would have been cool. Sure it needed 6 planes and it ruled out hires.

Hum. I don't agree. The major problem with HAM is represented by the artifacts that it produces. It's good only for displaying static images, or pre-computed animations (where the fringing is reduced to the minimum via smoothing a bit the hard transitions).
Quote:

But a desktop being limited to 4 colours for so many years didn't look good for a computer that could allegedly display real images.

Hey, don't tell it to Bruce, which found 8 colours great with his... Amiga 1200.
Quote:

Quote: Neither were needed. It could have been possible to easily introduce at least 8 bit packed/chunky mode on AGA without requiring the ridiculous C2P hardware converter which was added on Akiko. On the CD32 this would have been better since it was marketed as a games machine. In reality a games machine for Amiga fans. Though at the time a console would been expected to have more than a simple framebuffer for 3d rendering. At least some hardware to assist in 3d.

Exactly, but at least a native packed support could have helped a lot, due to the limited speed of CPUs of the time: the C2P was a heavy operation for them.
Quote:

Quote: It depends. If you want to "randomly" change single pixels, then reprogramming the mask via I/O ports kills performances, so in this case it's better to use the "chained" mode (the usual VGA mode 13h: only 320x200 with 256 colors, because all 4 planes keep exactly the same content) or use a framebuffer in memory and then copy it to the VRAM splitting the operation in 4 parts (one for each plane). In that case keeping the same mask would be best. Not sure how such a mask would have worked on the Amiga apart from being in the custom map with bitmap pointers.

It couldn't have worked on the Amiga. The "trick" with the EGA (because it started with such graphic cards) worked because the maps allowed to select different memory banks/chips in parallel, whereas on the Amiga all memory chips are connected together forming a single bank.

So, there's no way to access single memory chips in parallel.

That's the reason why the chipset had a limited memory bandwidth, whereas EGA had much more bandwidth (the graphic chipset was able to access the memory chips in parallel) which allowed it to display 640x350 screen with 16 colors at 60Hz (AFAIR) whereas the Amiga was limited to 640x200@60Hz (NTSC) or 640x256@50Hz (PAL).

VGA did better with its 640x480 at 72Hz (AFAIR) or up to 800x600 reprogramming the registers.
Quote:

Not even a parallel blitter would have helped with single or random pixel writes I tend to think.

Parallel Blitters accessing each one a specific memory chip / bank would have allowed it. But the Amiga worked only with a single bank, unfortunately.
Quote:

Quote: Quake is running at 360x480 (the so called Y-Mode) on the video, which is more than double the pixels on the usual 320x200 NTSC on Amiga, or roughly double the pixels on 320x256 PAL mode. At 320x200 it runs at 8,6FPS: more than 2.5 times better compared to the 3,2FPS of 360x480. Which is quite acceptable for such very old and limited VGA card. So that's causing the slow down. Yes 8.6 FPS is better. Just still a bit short of the 35 FPS standard used in Doom itself. Always wondered why it wasn't 30 FPS. 35 FPS looks like a best case scenario and not what was common on the average PC when it came out.

It should 36 FPS because it's half of the 72Hz of VGA refresh rate.

@cdimauro

HAM is suitable for some games if you know how to use it. A poster on EAB has an example of a scrolling tile engine in which every tile left edge begins with a palette colour and HAM does the rest giving lots of shade and brightness variations. The fringing that would be visible on the left edge of the display is hidden behind a sprite status bar. An early tech demo of his engine is shown here:

https://youtu.be/L1s5Vxb9BBY

_________________
Doing stupid things for fun...