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 😀

Ozzuneoj wrote on 2021-02-26, 06:20:

Wow, this is blast from the past.

Funny timing though... Here we are a little over 3 years since I posted this, and the day before you posted this I sorted through my now-much-larger video card collection. I now have so many dedicated EGA\CGA cards and VGA+EGA cards that I must have a pretty large percentage of the different EGA-capable chipsets in existence. I would love to compare these in an XT and a 386.

*sigh* Yet another benchmarking test I need to do, right after ISA and VLB cards on 386, 486 and 586 systems.

Whelp, here we are 3 more years in the future and I recently came into possession of a true EGA monitor that actually works -and- a huge variety of other EGA video cards from the '80s.

If anyone can help me come up with some way to measure and record performance in a program or game utilizing EGA graphics modes (preferably a lower resolution and one of the higher EGA resolutions) I have the hardware to do lots of testing.

Is it possible to program some very simple application that allows the user to select a graphics mode from a list, switch to that graphics mode, start a timer, fill the screen with pixels, move around some sprites of varying sizes and complexity, and then stop the timer to give a score based on how long it took to perform this task? I am no programmer, especially when we're talking about such low-level stuff, but I think if such a thing doesn't exist it would be really cool to have one made.

I would even take a stab at it if anyone can advise me on whether this is a realistic endeavor for a beginner to program. Ideally it would run on anything from the 8088 on up, with a practical useful limit in the fast-386 to slow-486 range (since most people are just going to be using VGA at that point).

Ozzuneoj wrote on 2024-07-16, 22:30:

If anyone can help me come up with some way to measure and record performance in a program or game utilizing EGA graphics modes (preferably a lower resolution and one of the higher EGA resolutions) I have the hardware to do lots of testing.

Oh, I'm afraid I'm just a layman here. 😅
I'm not so much into fast-paced games, either.
However, flight simulators were quite demanding in the 80s, I think.
The simulator Falcon A.T. seems to support EGA in 640x200 mode, for example, in order to be able to draw cockpit instruments.
Maybe there are more of such games.

Jo22 wrote on 2024-07-17, 02:01:

Oh, I'm afraid I'm just a layman here. 😅 I'm not so much into fast-paced games, either. However, flight simulators were quite de […]
Show full quote

Ozzuneoj wrote on 2024-07-16, 22:30:

If anyone can help me come up with some way to measure and record performance in a program or game utilizing EGA graphics modes (preferably a lower resolution and one of the higher EGA resolutions) I have the hardware to do lots of testing.

Oh, I'm afraid I'm just a layman here. 😅
I'm not so much into fast-paced games, either.
However, flight simulators were quite demanding in the 80s, I think.
The simulator Falcon A.T. seems to support EGA in 640x200 mode, for example, in order to be able to draw cockpit instruments.
Maybe there are more of such games.

Yeah, EGA games exist but I have no way to benchmark them in some "scientific" way since this long predates frame rate counters.

If there are any existing DOS graphics benchmarks that are still being produced, I would think it wouldn't be too hard to add support for EGA graphics modes... but I honestly don't know of any. All of the ones I have used are quite old.

Ozzuneoj wrote on 2024-07-16, 22:30:

If anyone can help me come up with some way to measure and record performance in a program or game utilizing EGA graphics modes (preferably a lower resolution and one of the higher EGA resolutions) I have the hardware to do lots of testing.

FastDoom, though you'll need 0.9.4 for 640x200 with FDOOME.

My benchmark data (using a 1.4Ghz Tualatin with a VIA Apollo133T board) shows the following results for cards with TTL output with a timedemo of Doom 1.9 shareware demo1:

Paradise PEGA2A - 39.239 (FDOOMEGA) / 22.371 (FDOOME)
Realtek RTG3102 - 39.353 (FDOOMEGA) / 22.991 (FDOOME)
Tseng ET3000AX - 43.601 (FDOOMEGA) / 30.262 (FDOOME)

I should get around to trying my other cards with TTL output at some point. It's amazing how awful the RTG3102 is for a 16-bit card.

DEAT wrote on 2024-07-18, 00:32:

FastDoom, though you'll need 0.9.4 for 640x200 with FDOOME. […]
Show full quote

Ozzuneoj wrote on 2024-07-16, 22:30:

If anyone can help me come up with some way to measure and record performance in a program or game utilizing EGA graphics modes (preferably a lower resolution and one of the higher EGA resolutions) I have the hardware to do lots of testing.

FastDoom, though you'll need 0.9.4 for 640x200 with FDOOME.

My benchmark data (using a 1.4Ghz Tualatin with a VIA Apollo133T board) shows the following results for cards with TTL output with a timedemo of Doom 1.9 shareware demo1:

Paradise PEGA2A - 39.239 (FDOOMEGA) / 22.371 (FDOOME)
Realtek RTG3102 - 39.353 (FDOOMEGA) / 22.991 (FDOOME)
Tseng ET3000AX - 43.601 (FDOOMEGA) / 30.262 (FDOOME)

I should get around to trying my other cards with TTL output at some point. It's amazing how awful the RTG3102 is for a 16-bit card.

Interesting. I guess that could work for later PCs. If I want to see if there's any difference between cards on very slow systems (8088, 286, slow 386 etc.) Doom will be way too heavy, but it's definitely a start. Thanks!

Sounds like a cool open source project to start on GitHub: "EGAmark" or "EGAbench". An EGA benchmarking tool that could be run on any PC clone, 8088 and up, so written to run in Real Mode, not using any 186+ instructions, etc.

Let's have a brainstorm. What modes and features should it test? Frame rates at the various text and graphics modes? Copying memory from system RAM to video RAM, copying memory within video RAM (does EGA even support that?), pallette cycling, perhaps other EGA-specific hardware features, etc.

And such a tool should be forgiving in terms of EGA compatibility. So that way, the tool can be used to test the EGA perfomance of VGA cards too, as well as possible emulators and VMs and such, as well as more problematic EGA clones, in so far those exist.

What other (synthetic) benchmarks would be useful to add to such a tool?

(EGA hardware compatibility checking/reporting would be nice to have as a feature too, but would better be left to another specialized tool, to prevent scope creep, at least at first.)