It means just the raw data rate how fast can the video card receive data from bus.

Comparing two cards with a same CPU and motherboard (bus speed), it takes constant amount of time for the CPU to calculate data to be written to video card, but if other card takes double the time to transfer the data, the screen can be updated half as often.

For instance, there are 8-bit ISA cards and 16-bit ISA cards, so just based on bus width the other could transfer two bytes per bus cycle while the other could transfer just one byte per bus cycle. But there are other factors as well, like the video controller might have to add wait states to bus cycles if there is some internal operation happening in the video controller (video memory read or refresh cycle, so the memory can't be written until a bit later) etc, so the CPU just has to wait longer.

So regarding your Doom example, it does use double buffering, but the ability how fast the video card can receive data determines if you can transfer enough data in certain amount of time so you can flip the buffer 35 times per second or just 23 etc. By making the game area smaller, less data needs to be calculated by CPU and also transferred to video memory, so this increases how often you can flip the buffer to make smoother game. So it is not the swapping of buffer that takes time, but how long it takes to complete the data transfer before you can switch the buffer.

This should be in Marvin. This forum is for DOS games on modern systems.

Moved to Marvin.

Jepael wrote:

It means just the raw data rate how fast can the video card receive data from bus. […]
Show full quote

It means just the raw data rate how fast can the video card receive data from bus.

Comparing two cards with a same CPU and motherboard (bus speed), it takes constant amount of time for the CPU to calculate data to be written to video card, but if other card takes double the time to transfer the data, the screen can be updated half as often.

For instance, there are 8-bit ISA cards and 16-bit ISA cards, so just based on bus width the other could transfer two bytes per bus cycle while the other could transfer just one byte per bus cycle. But there are other factors as well, like the video controller might have to add wait states to bus cycles if there is some internal operation happening in the video controller (video memory read or refresh cycle, so the memory can't be written until a bit later) etc, so the CPU just has to wait longer.

So regarding your Doom example, it does use double buffering, but the ability how fast the video card can receive data determines if you can transfer enough data in certain amount of time so you can flip the buffer 35 times per second or just 23 etc. By making the game area smaller, less data needs to be calculated by CPU and also transferred to video memory, so this increases how often you can flip the buffer to make smoother game. So it is not the swapping of buffer that takes time, but how long it takes to complete the data transfer before you can switch the buffer.

I should have written it explicitly but the assumption was there is no categorical difference in the bus bandwidth/latency. I understand how the difference between 8-bit and 16-bit ISA, or between ISA and VLB relates to the speed at which the buffer on the graphics card can be filled.

However, the conclusion then is that there is little or no difference between a fast and a slow graphics card using the same bus technology. The only exception if I understand you correctly would be the use of or lack of MPDRAM (Multiport DRAM), and/or faster video RAM in general.

There are pretty big differences in throughput between chips. Some were more efficient with the bus than others, interleaving and such.

Now, that's a fascinating thread!
Btw, did any of those graphics cards use any kind of data compression, like RLE ?
I know that this was possible on the LPT port in ECP-Mode (I'm reading a book about this right now).
This way it was possible to increase speed from 2MiB/s to about 8MiB/s on the parallel port.
Of course, this required special software which did the compression in the first place.
Maybe some drivers for these cards did support something like this (maybe for Win 3.x or a DOS CAD program) ?
Or was this not necessary because of dirty-rectangle tricks ?
I'm just curious. Sorry if that's a bit off-topic.. ^^

if you take ISA cards, the speed difference comes from say three things mainly, the speed of the graphic ram, the speed of the ramdac and the chipset. back in the isa days the chipset really didn't do a whole lot, it basically routed ram out the ramdac and muxed the clocks for resolution timings, layered the bitplanes.

now, you had good chipsets and bad chipsets. maybe internally some chipsets were 8bit, some might be 16bit internally. maybe you had a 32bit internal datapath card!

Remember, old VGA cards didnt have internal hardware bitblit commands for moving ram internally. if you have VGA which uses 64kb ram at 0xA0000 address, and you move some ram from say 0xA000:0 to 0xA000:2, the cpu executes a 'movsw' command on si + di. the cpu reads the value of that 0xA000:0 into the mmu, and write it back out. thus doing a full round trip on the isa bus...

there was a time when abusing DMA to to memory to memory transfer was faster than having the CPU do it, but once you hit 386 and start using MOVSD, you can move chunks faster than the old DMA chip routines.

now once you move to vlb + pci svga cards, they had hardware bitblt functionality.

I also know on some chipsets that had dram instead of sram's you could reprogram the dram wait states for faster access..

BloodyCactus wrote:

if you take ISA cards, the speed difference comes from say three things mainly, the speed of the graphic ram, the speed of the r […]
Show full quote

if you take ISA cards, the speed difference comes from say three things mainly, the speed of the graphic ram, the speed of the ramdac and the chipset. back in the isa days the chipset really didn't do a whole lot, it basically routed ram out the ramdac and muxed the clocks for resolution timings, layered the bitplanes.

now, you had good chipsets and bad chipsets. maybe internally some chipsets were 8bit, some might be 16bit internally. maybe you had a 32bit internal datapath card!

Remember, old VGA cards didnt have internal hardware bitblit commands for moving ram internally. if you have VGA which uses 64kb ram at 0xA0000 address, and you move some ram from say 0xA000:0 to 0xA000:2, the cpu executes a 'movsw' command on si + di. the cpu reads the value of that 0xA000:0 into the mmu, and write it back out. thus doing a full round trip on the isa bus...

there was a time when abusing DMA to to memory to memory transfer was faster than having the CPU do it, but once you hit 386 and start using MOVSD, you can move chunks faster than the old DMA chip routines.

now once you move to vlb + pci svga cards, they had hardware bitblt functionality.

I also know on some chipsets that had dram instead of sram's you could reprogram the dram wait states for faster access..

Interesting, do you happen to know how the bit blitting of VLB/PCI cards work? Is it part of VESA (VBE) or something else? How do you use it when programming?

fractal5 wrote:

Interesting, do you happen to know how the bit blitting of VLB/PCI cards work? Is it part of VESA (VBE) or something else? How do you use it when programming?

In the simplest form, you could just move blocks from one place in video memory to another place. You'd specify a source-rectangle and a destination rectangle (by setting some hardware registers), and it would perform the copy.
Later hardware (I think only PCI) could also perform hardware-blits from system memory to videomemory and vice versa.
Basically it's a sort of DMA controller integrated in the graphics chip, which generates the proper addresses to read and write words.

Once you get into the more advanced Windows accelerator territory, you also had blit-operations that can perform extra operations on-the-fly, such as scaling (sometimes even with filtering) and conversion of pixel format. Eg, you could blit a bitmap of 320x200 in 16-bit colour to a 1024x768 screen in 32-bit colour.