Grzyb wrote on 2025-01-27, 13:31:

BTW: what's that program you're using?
I want to try it with mine 8800CS...

That is a program that I wrote for scanning SVGA video mode number space (video modes 14h - 7Fh) using CRT Terminator. The program won't unfortunately work without CRT Terminator, since it uses a feedback loop back to DOS.

I.e. the test program initializes a video mode, and then CRT Terminator identifies and tells DOS back what the current video mode is, so the test program is then able to treat it accordingly. (along with printing the vsync, hsync and pixel clock rates)

I haven't yet released this test program for CRT Terminator end users, though I am working towards that goal. (it'll live in https://github.com/juj/crt_terminator/tree/main/DOS )

Jo22 wrote on 2025-01-27, 13:38:

That's an interesting topic. For cards that multiple mode numbers for 800x600 16c, different timings are being used sometimes. I […]
Show full quote

That's an interesting topic.
For cards that multiple mode numbers for 800x600 16c, different timings are being used sometimes.
Ie, that mode 6Ah has no interlacing but 102h has interlacing.

"With some VESA video boards, mode 6AH selects a faster (noninterlaced) screen refresh rate that is much more pleasing to the eye. "

Source: https://ftp.zx.net.nz/pub/Patches/ftp.microso … n-us/82/734.HTM

I think you're overinterpreting it...

The fact that the faster refresh rate is non-interlaced doesn't imply that the slower is interlaced.

I think it's related to the fact that the original 800 x 600 x 16 mode used 56 Hz refresh - painful indeed, so they quickly added the 60 Hz option...

Seriously, I can't imagine any need for interlaced 800 x 600 x 16.

noshutdown wrote on 2025-01-27, 13:30:

i understand now, thx man. but can you tell other vga cards that can only process 4bits in a cycle?
i guess pvga1, wd90c00 and chips82c450 fall into that catgory, but have no datasheet on et3000, ati18800 and realteks.

I don't have time to experiment now...

I would search for cards with the fastest crystal <50 MHz - and no other frequency source, like a clockchip - and measure the frequencies in 256-color modes...

Normal VGA frequencies:
640 x 400 - 31.5 kHz, 70 Hz
640 x 480 - 31.5 kHz, 60 Hz
...suggest 1 cycle per pixel.

Frequencies below VGA suggest 2 cycles per pixel, like in the 8800:

The Trident 8800 chips have a problem with 256 color modes, as they always double
the pixels output in 256 color mode. Thus a 640x400 256 color mode (5Ch) actually
uses a 1280x400 frame, requiring at least a multi sync monitor.
This problem is fixed on the 8900.

Grzyb wrote on 2025-01-27, 15:04:

Frequencies below VGA suggest 2 cycles per pixel, like in the 8800: The Trident 8800 chips have a problem with 256 color modes, […]
Show full quote

Frequencies below VGA suggest 2 cycles per pixel, like in the 8800:

The Trident 8800 chips have a problem with 256 color modes, as they always double
the pixels output in 256 color mode. Thus a 640x400 256 color mode (5Ch) actually
uses a 1280x400 frame, requiring at least a multi sync monitor.
This problem is fixed on the 8900.

i heard that the trident8800 had bugs, but didn't quite understand how it works or what trouble it causes, can you explain it in details? and what about the wrap around bug?
"they always double the pixels output in 256 color mode", could it be incorrected persisted from the 320*200*256c mcga mode which needed to be doubled, or just had to do so as it could only process 4bits per cycle?
both pvga1/wd90c00 and chips82c450 datasheet said that 256color modes need higher clocks than 16color modes of same resolution, does that indicate that they have that bug aswell?
as i said, no datasheet of et3000, ati18800 and realteks yet...
this thread also made me suddenly understand why most isa cards with 2mb ram still can't support 800*600*24bit or 1024*768*16bit mode.

Grzyb wrote on 2025-01-27, 15:04:

Frequencies below VGA suggest 2 cycles per pixel, like in the 8800: The Trident 8800 chips have a problem with 256 color modes, […]
Show full quote

Frequencies below VGA suggest 2 cycles per pixel, like in the 8800:

The Trident 8800 chips have a problem with 256 color modes, as they always double
the pixels output in 256 color mode. Thus a 640x400 256 color mode (5Ch) actually
uses a 1280x400 frame, requiring at least a multi sync monitor.
This problem is fixed on the 8900.

Neither the Trident TVGA8816CSC2 and ASKA ZyMOS POACH 51 cards that I have appear to do this. They both output a 640x400 video mode and not a 1280x400 video mode.

They do however both have a nonstandard hsync rate (not 31.5 kHz), so indeed a multisync monitor is needed. But the "frame" is just regular 640 pixels horizontally.

Trident TVGA8816CSC2:

ASKA ZyMOS POACH 51:

(Some other adapters, e.g. ATI 28800 and Alliance Semi ProMotion3210 do actually have a bug like that, they don't implement the 1:2 Dot Clock register in VGA, resulting in 320x200 being double-clocked horizontally 640 pixels wide. Of course the analog VGA line does not see or care about that, since it does not carry a pixel clock)

noshutdown wrote on 2025-01-27, 16:23:

"they always double the pixels output in 256 color mode", could it be incorrected persisted from the 320*200*256c mcga mode which needed to be doubled

The VGA/MCGA 320x200 video mode is not clock-doubled, but it is only scandoubled (each scanline is scanned out twice). So it is actually a 320x400 video mode that gets scanned out. 98% of the adapters that I have tested do not clock-double (== output 640x400) this mode - only few rare ones do, which I consider to be a bug. (since original IBM VGA adapter did not do this) I.e. those adapters disregard the 1:2 Dot Option register in the VGA register space.

Of course any of this is only observable via the Feature Connector, and not on the analog VGA line, since the analog VGA line does not carry pixel clock information that would specify what the horizontal resolution of the image is. Only the Feature Connector has a pixel clock line.

noshutdown wrote on 2025-01-27, 16:23:

i heard that the trident8800 had bugs, but didn't quite understand how it works or what trouble it causes, can you explain it in details? and what about the wrap around bug?
"they always double the pixels output in 256 color mode", could it be incorrected persisted from the 320*200*256c mcga mode which needed to be doubled, or just had to do so as it could only process 4bits per cycle?
both pvga1/wd90c00 and chips82c450 datasheet said that 256color modes need higher clocks than 16color modes of same resolution, does that indicate that they have that bug aswell?

I don't know about the wrap around bug.

The fact that 256-color modes need 2 cycles/pixel is *not* a bug.
It's a limitation of the original VGA - designed primarily for 16-color modes, and closely related to EGA, which was 16-color-only:
Re: 16-bit ISA EGA card?

I guess it's also related to video memory bandwidth limits.
See eg. this story about TVGA9000C - "Input not supported" error when resolution set to 800x600 256 color
The TVGA9000C can do non-interlaced 800 x 600 x 256, but it doesn't work with slow memory chips.

Double-scanning of 200-line modes is a completely different thing.

noshutdown wrote on 2025-01-27, 16:23:

and what about the wrap around bug?

VGA adapters have a Display Start Address register, that allows one to specify the memory address into VRAM where the top-left corner of the video framebuffer resides. So scanning out pixel data from the framebuffer will start from that memory address.

This register is used to implement hardware scrolling and double-buffering (page flipping).

The video memory in Mode 13h is 320*200=64000 bytes.

If one set the starting address to be > 256KB - 64000 bytes, then as the adapter scans out pixels, it will reach an address value greater than 256KB as it moves towards the bottom right corner of the screen.

Since the original VGA card had only 256KB of RAM, at that point it just wrapped around back to 0.

That was actually an useful feature for hardware scrolling, since one could treat the video memory as an infinite panning RAM area. And software did start to rely on that behavior, famously in Commander Keen 4-6.

(you can find a source code example at https://github.com/juj/crt_terminator/blob/ma … ROLL/SCROLL.CPP that utilizes this effect)

But as SVGA adapters added more than 256KB of RAM, they could not break this wraparound behavior since it was relied upon. Majority of SVGA adapter vendors realized this, and implemented their cards accordingly to have two operating modes, one that wraps for Mode 13h, and one that doesn't, for the new >= 640x480 256c video modes.

But a couple of vendors (Trident, Tseng, Alliance Semi that I know of) dropped the ball and didn't realize to implement this compatibility (according to John Carmack on Lex Fridman's podcast, "nobody realized", but that was a gross exaggeration - almost everyone did get it right).

Trident and Alliance Semi fixed their later adapters as soon as they became aware of the incompatibility. Tseng Labs never did, but had the bug in all of their adapters, until their IP becoming obsoleted in the ATI buyout.

Grzyb wrote on 2025-01-27, 17:03:

The fact that 256-color modes need 2 cycles/pixel is *not* a bug.

Agreed. And that is a separate thing from the output video mode being double wide horizontally. For example, the original IBM VGA adapter also needed 2 cycles/pixel for 320x200, but it still used its 1:2 Dot Clock option to halve the output pixel clock for the mode out to Feature Connector.

clb wrote on 2025-01-27, 16:52:

Neither the Trident TVGA8816CSC2 and ASKA ZyMOS POACH 51 cards that I have appear to do this. They both output a 640x400 video mode and not a 1280x400 video mode.

They do however both have a nonstandard hsync rate (not 31.5 kHz), so indeed a multisync monitor is needed. But the "frame" is just regular 640 pixels horizontally.

Well, I was just quoting that old "Programming Trident chips" document - it may be somewhat inaccurate.

But your screenshots seem to support that:
- the card with 40 MHz crystal produces 20 MHz pixel clock
- the card with 44.9 MHz crystal produces 22.45 MHz pixel clock

It's clearly 2 crystal cycles per pixel.

Grzyb wrote on 2025-01-27, 17:22:

Well, I was just quoting that old "Programming Trident chips" document - it may be somewhat inaccurate. […]
Show full quote

clb wrote on 2025-01-27, 16:52:

Neither the Trident TVGA8816CSC2 and ASKA ZyMOS POACH 51 cards that I have appear to do this. They both output a 640x400 video mode and not a 1280x400 video mode.

They do however both have a nonstandard hsync rate (not 31.5 kHz), so indeed a multisync monitor is needed. But the "frame" is just regular 640 pixels horizontally.

Well, I was just quoting that old "Programming Trident chips" document - it may be somewhat inaccurate.

But your screenshots seem to support that:
- the card with 40 MHz crystal produces 20 MHz pixel clock
- the card with 44.9 MHz crystal produces 22.45 MHz pixel clock

It's clearly 2 crystal cycles per pixel.

Yeah, that makes sense.

What I meant to say about that statement is that it writes the train of logic as "2 clocks/pixel, therefore mode is 1280x400, therefore multisync monitor is needed." But the second "therefore" is odd, because even if it were 1 clock/pixel, (40MHz and 44.9 MHz pixel clock respectively), it would still not produce a 31.5 kHz hsync with those timing geometries, so a multisync monitor would be needed anyways.

And the first "therefore" is odd since as is seen on the Feature Connector output, there is definitely a "Clock /2" divider circuit on the card that is activated for this mode, so those video modes do clock out as a 640x400 geometry from Feature Connector.

BTW, that "Pixel clock" frequency you measure on the Feature Connector is the same as the CLK input of the RAMDAC, right?

Grzyb wrote on 2025-01-27, 17:49:

BTW, that "Pixel clock" frequency you measure on the Feature Connector is the same as the CLK input of the RAMDAC, right?

I'm not sure there is a specific rule whether the Feature Connector PXCLK has to be the same as the RAMDAC CLK, though in this case, looking at the TVGA8816CSC2 card RAMDAC datasheet (BT476), I do not find it to have a shifter that would shift 2x 4-bit palette nybbles to the full 8-bit word, so it does seem like for this card, the Feature Connector PXCLK will be the same as the RAMDAC CLK. (the nybble combining occurs inside the 8800CS chip)

A (CRT) monitor that handles 640x400 can handle 1280x400 just fine if the only difference is the dot clock. The requirement for a 'multi-sync' monitor is a result of non-VGA horizontal frequency.

*to generate vga signal, the ramdac must keep reading video ram for all time, which takes up much of the video ram bandwidth. how can video chip write into video ram at the same time? and what designs are used to improve this?
*does the ramdac read directly from video ram, or from the video chip?

In the original design, the 'sequencer' reads from video memory and sends raw pixels to the 'attribute controller'. On EGA the next step is output to the monitor, but VGA has the additional step of the RAMDAC conversion which looks up an RGB color from the palette and generates analog output.

Early VGA cards have a fixed interleave between how many memory cycles are dedicated to the sequencer and how many are available for CPU access (similar to Amiga chipmem). Later cards mostly use burst transfers and buffering to enable a more efficient sharing of bandwidth, though dual-ported VRAM was also used on high-end cards.

Grzyb wrote on 2025-01-27, 17:49:

BTW, that "Pixel clock" frequency you measure on the Feature Connector is the same as the CLK input of the RAMDAC, right?

This is how it is supposed to be. The feature connector is meant to be placed "between" the logic that generates the 8-bit color values and the RAMDAC. Depending on some levels on the feature connector, it can either be used to grab the pixel values from the feature connector to a different card (like the CRT Terminator!), or you can inject pixel values by asking the VGA logic to tristate their output (used for example on video decoder cards).

Anything exceeding 8-bit pixels is non-standard. You get 16-color modes after the EGA attribute controller expanding it to 64 colors and the VGA "color page" logic adding 2 extra bits, so they are 8 bits per pixel as well. (Yeah, I know, you can also run the VGA card in a 4 bit "color page" + 4 bit from the attribute controller mode instead)

Grzyb wrote on 2025-01-27, 17:03:

I don't know about the wrap around bug. […]
Show full quote

I don't know about the wrap around bug.

The fact that 256-color modes need 2 cycles/pixel is *not* a bug.
It's a limitation of the original VGA - designed primarily for 16-color modes, and closely related to EGA, which was 16-color-only:
Re: 16-bit ISA EGA card?

I guess it's also related to video memory bandwidth limits.
See eg. this story about TVGA9000C - "Input not supported" error when resolution set to 800x600 256 color
The TVGA9000C can do non-interlaced 800 x 600 x 256, but it doesn't work with slow memory chips.

Double-scanning of 200-line modes is a completely different thing.

now that we know that some svga cards behaves like the original ibm vga in that they can only process 4 bits per cycle before sending to ramdac, resulting in halved pixel clock in 256color modes, is it possible to find out all cards with this behavior?
here are some likely suspects: pvga1/wd90c00, chips82c451/450, tseng et3000. no idea on the ati18800.
note that cards with 256kb maximum do not matter, obviously they don't need any high pixel clock.

noshutdown wrote on 2025-01-30, 17:13:

note that cards with 256kb maximum do not matter, obviously they don't need any high pixel clock.

256 KB is enough for 640 x 400 x 256.

VGA can do 640 x 400 x 16 @ 70 Hz, using the 25.175 MHz pixel clock.
But it can't do 640 x 400 x 256.

That's probably the easiest way to tell apart 4 bits/cycle chips from 8 bits/cycle ones...
If it can do 640 x 400 x 256 @ 70 Hz, it must be 8 bits/cycle.
If it doesn't provide 640 x 400 x 256 at all, or only provides it at below-VGA frequencies - it must be 4 bits/cycle.

Grzyb wrote on 2025-01-30, 18:23:

256 KB is enough for 640 x 400 x 256. […]
Show full quote

256 KB is enough for 640 x 400 x 256.

VGA can do 640 x 400 x 16 @ 70 Hz, using the 25.175 MHz pixel clock.
But it can't do 640 x 400 x 256.

That's probably the easiest way to tell apart 4 bits/cycle chips from 8 bits/cycle ones...
If it can do 640 x 400 x 256 @ 70 Hz, it must be 8 bits/cycle.
If it doesn't provide 640 x 400 x 256 at all, or only provides it at below-VGA frequencies - it must be 4 bits/cycle.

That is likely true in most, if not all cases.

For one, WD90C00 supports 640x400x256. There is a special register setting for it (pg. 100 of the WD90C00 manual)

Grzyb wrote on 2025-01-30, 18:23:

If it can do 640 x 400 x 256 @ 70 Hz, it must be 8 bits/cycle.

Or it has a 50MHz clock source. So add that to your rule of thumb: If it can do 640 x 400 x 256 @ 70 Hz, and does not have a 50MHz crystal or a clock synthesizer chip capable of generating that frequency, it must support 8 bits/cycle.