kdr wrote on 2021-12-24, 20:57:

I don't think EGA 4bpp has to be any slower than CGA 2bpp, because one of the big features of EGA graphics is the capability to modify all four colour planes with a single 8-bit memory write.

This "big feature" of the EGA card doesn't help if all you do is "painting sprites from main memory into screen memory". Also, to set up the graphics controller, you need to do 8-bit port I/O. AT-class computers typically add a lot of wait-state between 8-bit I/O cycles (called "recovery time"), to be compatible with the awfully slow port I/O on the PC/XT. There are some situations where the graphics controller is a win, like byte-aligned screen-to-screen copies on FIFO-less cards, or painting two-color graphics. Some native EGA games make use of the fast screen-to-screen copy feature by placing the sprites into off-screen memory. Typical multi-standard games don't do that, though. In essence, you often get to shuffle twice as much data, and also have to talk to the Graphics Controller on how to distribute the data you shuffle around.

kdr wrote on 2021-12-24, 20:57:

So far the only objective benchmarks suggested are the video tests from Check It and Landmark, which seem oriented towards text […]
Show full quote

So far the only objective benchmarks suggested are the video tests from Check It and Landmark, which seem oriented towards text mode performance. Any others out there?

I don't think EGA 4bpp has to be any slower than CGA 2bpp, because one of the big features of EGA graphics is the capability to modify all four colour planes with a single 8-bit memory write. The main performance limitation is the wait states that the EGA imposes on the CPU when reading/writing video RAM.

The original EGA chipset from IBM (along with the first clone EGA chipset from Chips & Technologies) clocks the video RAM at the dot clock frequency, which is 14.318Mhz for the 320x200 and 640x200 modes. The chipset sequencer coordinates the CRT and CPU accesses to video RAM. Over the course of 32 clock cycles the sequencer provides 5 opportunities to access the video RAM. The CRT needs 2 out of 5 accesses in 320 pixel modes and 4 out of 5 accesses in 640 pixel modes. When the CPU wants to read/write to video RAM, the video chipset inserts wait states until an access opportunity becomes available. (This will be quite a few wait states in the 640 pixel modes!)

So I think on these early EGA cards, the video RAM would actually be *faster* in 640x350 mode (since it uses a 16.257Mhz clock) as compared to 640x200 mode (which is using the standard 14.318Mhz clock). There's a "bandwidth" bit in the SR01 register that determines whether the CPU gets 1 access or 3 accesses during each 32 cycle group. I wonder what happens if you program the sequencer to give the CPU 3 accesses in a 640 pixel mode (which should starve the CRT of its required accesses). It might be safe to do so during the vertical blanking, providing a brief window of high performance access to the video RAM...

Anyhow, at some point the video chipsets began to incorporate a FIFO buffer, so that the CPU writes into the buffer and can be released immediately without any wait states, and also switched to clocking the video RAM with a faster clock that was decoupled from the video dot clock. Did any EGA chipsets use these techniques? The early VGA chipsets used essentially the same design as the original EGA, adding a whole bunch of wait states to synchronize the CPU writes with the gaps in the CRT reads.

It's possible to test EGA performance with FastDoom and a fast CPU. I've been testing it and almost all ISA 8-bit EGA cards can't get past ~13 fps (320x200 16 colors) and ~6.5 fps (640x200 16 colors). In all tests the EGA mode is slower than CGA on those cards, getting above 23 fps. EGA modes on ISA 8-bit VGA cards are much faster, also near 23 fps. So clearly there must be something very wrong with earlier EGA cards, I'm still trying to find the culprit.

EDIT: FastDoom copies the full backbuffer to the VRAM in a single pass, plane by plane. Also it uses page flipping to avoid tearing.

On classic CGA/EGA/VGA cards, there is no separate memory clock and pixel clock, instead, the memory timing is derived from the pixel clock (or the double pixel clock in 320-pixel modes). The pixel clock on CGA and low-res EGA is 14.318MHz, whereas the pixel clock on VGA is around 25 MHz. As the memory clock is nearly twice as fast, this would explain the increased speed on VGA cards. I expect FastDoom to yield a slightly higher frame rate if you just use the top 200 scanlines in 640x350 instead all 200 scanline in 640x200, because in 640x350, the pixel/memory clock is increased to 16.257 MHz.

You're right, 640x350 is a little bit faster, but nothing crazy (about 5%, depending on the card). I'm developing a benchmark for all kinds of graphics cards (source code is available but haven't finished a release yet, https://github.com/viti95/V95bench if interested). Here are the results for a Trident Paradise PVGA-1A (ISA 8-bit VGA) and a Cirrus Logic GD-510/520 (also ISA 8-bit VGA) on a fast 486DX4-100.

EDIT: Added Trident Paradise PEGA-1A results (ISA 8-bit EGA). These cards are utterly slow.

ViTi95 wrote on 2022-02-11, 09:12:

You're right, 640x350 is a little bit faster, but nothing crazy (about 5%, depending on the card). I'm developing a benchmark for all kinds of graphics cards (source code is available but haven't finished a release yet, https://github.com/viti95/V95bench if interested). Here are the results for a Trident Paradise PVGA-1A (ISA 8-bit VGA) and a Cirrus Logic GD-510/520 (also ISA 8-bit VGA) on a fast 486DX4-100.

EDIT: Added Trident Paradise PEGA-1A results (ISA 8-bit EGA). These cards are utterly slow.

This looks interesting! I just checked the Github page and I'm not seeing a binary yet. Do you have one you can upload for us to experiment with?

Isn't binaries available on Releases page ? https://github.com/viti95/V95Bench/releases
It seems that V95Bench_0.0.4.zip (you can see it after clicking on Assets) contains binaries

EGA not only has to transfer memory data over the bus, but there are a lot of port writes to change planes etc. Ports were typically held back with wait-state-like delays to ensure that old 8088 era cards would still work. Micheal Abrash's articles from DDJ complain how the 486 took 66 cycles for one port write when programming the VGA.

zyga64 wrote on 2023-02-21, 09:00:

Isn't binaries available on Releases page ? https://github.com/viti95/V95Bench/releases
It seems that V95Bench_0.0.4.zip (you can see it after clicking on Assets) contains binaries

Oops, my mistake. I didn't see that at all. It seems like every GitHub page I visit looks slightly different and I still struggle to figure out where the binaries are half the time. Thank you.

To me the "releases" link on GitHub pages looks like a blank subheading with no entries below it, so I end up overlooking it.

ViTi95 wrote on 2022-02-11, 09:12:

You're right, 640x350 is a little bit faster, but nothing crazy (about 5%, depending on the card). I'm developing a benchmark for all kinds of graphics cards (source code is available but haven't finished a release yet, https://github.com/viti95/V95bench if interested). Here are the results for a Trident Paradise PVGA-1A (ISA 8-bit VGA) and a Cirrus Logic GD-510/520 (also ISA 8-bit VGA) on a fast 486DX4-100.

EDIT: Added Trident Paradise PEGA-1A results (ISA 8-bit EGA). These cards are utterly slow.

Thanks for creating this! From experience I've always noticed that EGA often seems to be the slowest of all modes. Like, VGA games seem actually faster on an XT than the same games ran in EGA mode with an EGA card (not that I'd recommend VGA on an XT anyway, but you get the point 😁). It also seems that the dual-head VGA cards that can operate in EGA mode are often faster than true EGA cards. I'll put your software to the test and find out 😀