clb wrote on 2023-09-24, 16:24:

On my test system, 80 MHz 486 with ISA bus at 10.0 MHz, it looks like the fast rep outsb method takes about 30-31 scanlines in vblank to write new 768 bytes, whereas the slow manual out path code takes 39-40 scanlines.

With the 286+ rep outsb instruction sequence and ISA bus at 10.0 MHz one can just about make it.

31.47kHz is what, 32 us per line? 30x32 means 768 bytes in ~1ms = ~768KB/s

ISA System Architecture Third Ed wrote:

duration of an ISA bus cycle accessing an 8-bit device defaults to four wait states unless shortened by NOWS# (to 3, 4, or 5 BCLK cycles) or lengthened by CHRDY. The default bus cycle ends at the trailing edge of the fifth data time.

Theoretical ISA speed limit for 8bit IO is 3 cycles per transaction, default is 6 cycles (4 wait states). 10MHz/ 3-6 = somewhere between 3.3MB/s and 1.6MB/s.
There definitely are waitstates being inserted by the VGA chip when accessing palette registers, ~11 in your particular case!
This means some VGA chip vendors simply screwed up by not inserting enough delay.

Then we get to ISA overclocking. It would be interesting to see how chip vendors derive the wait state delays they are inserting, are those fixed number of cycles or are they running timers and only inserting enough delay to meet their internal timing requirements. Is your ~30 scanlines on 10MHz bus card doing same ~30 scanlines on slowed down ISA bus? or does it still insert 11 wait states on 5MHz bus.

Another question arises, are numbers of wait stated constant on all VGA IO ports? Were there VGA chip vendors ignorantly inserting same delays indifferent to accessed port? You could argue 0x3C6-3C9 Palette access needs some delay, but how about 0x3C0/0x3C4/0x3CE ? are they all equally slow? I suppose a poorly designed VGA will just give everything same fixed delay and call it a day.

clb wrote on 2023-09-25, 07:30:

...
Or alternatively I got something wrong with the test code..

Maybe you want to check my VGA REP OUTSB test, I ported Wolf3D ASM code to C:

https://github.com/viti95/FastDoom/blob/maste … ASTDOOM/i_vga.c (VGA_TestFastSetPalette)

clb wrote on 2023-09-25, 07:30:

...
Or alternatively I got something wrong with the test code..

Maybe it breaks down on faster system than the one you use for testing, also some chipsets are slower than others, I think I remember something about later VIA inserting ISA wait states on their own. Might be one of those things you cant easily test on users random config and need a database inside the program for full picture. Something like "Works on current setup, known to be broken when X". You could also benchmark ISA transaction length for different cards.

S3 cards (up to ViRGE/DX, Trio3D/Savage seem to fix that) do have palette corruption at PCI bus speeds above 44-45 MHz; this is especially apparent in Mode 0x13, since S3 cards actually use pixel clock halved (25.12/2 = 12.6 MHz) in this mode, and the RAMDAC seems to not being able to properly process writes to the palette, dropping the data.

I also experienced this issue with regular PCI bus speeds (33.3 Mhz) while experimenting with tweaked 160x200 256 color mode (which needs poking around extended registers to enable DCLK/2 divider, as sequencer index 1 divider does not work in 256 color modes on the S3), and while working on e.g. Matrox or NVidia, on S3 cards I had exactly the same palette corruption.

wbc wrote on 2023-09-25, 19:37:

S3 cards (up to ViRGE/DX, Trio3D/Savage seem to fix that) do have palette corruption at PCI bus speeds above 44-45 MHz; this is especially apparent in Mode 0x13, since S3 cards actually use pixel clock halved (25.12/2 = 12.6 MHz) in this mode, and the RAMDAC seems to not being able to properly process writes to the palette, dropping the data.

I have seen palette corruption with every S3 cards that I have except the Trio3D/2X one when the PCI bus is running at 37.5 MHz, making them overclocker unfriendly.