SYNC polarity tells the monitor which mode it's supposed to switch to:

That's the original IBM VGA and 8514 standard.

Later on, non-IBM SVGA appeared, with the 800 x 600 resolution.
Of course, it wasn't possible to select the 600-line mode using SYNC polarity alone, and monitors had to use additional methods.

Grzyb wrote on 2024-01-28, 14:19:

SYNC polarity tells the monitor which mode it's supposed to switch to: sync.jpg That's the original IBM VGA and 8514 standard. […]
Show full quote

SYNC polarity tells the monitor which mode it's supposed to switch to:
sync.jpg
That's the original IBM VGA and 8514 standard.

Later on, non-IBM SVGA appeared, with the 800 x 600 resolution.
Of course, it wasn't possible to select the 600-line mode using SYNC polarity alone, and monitors had to use additional methods.

Won't the HSYNC polarity being negative clash with detecting HSYNC itself? Since it needs to go high every hsync period to properly cause flyback of the beam?
I'd guess VSYNC polarity can still be detected from observing it change into it's intended value when HSYNC goes high (from 0V to 5V or whatever, when it starts), but won't negative HSYNC polarity (it lowering during HSYNC) cause issues detecting HSYNC? How does the monitor detect if it's to retrace (activating the coils) when it goes high or low if it's diffent in different polarity modes?

Afaik on an EGA, the VSYNC polarity also determines the pins used during active display (to select EGA or CGA mode in the monitor (mode 1 vs mode 2 it's called I think)? Then what effect does HSYNC have there (on a EGA monitor)? Or will the monitor simply fail in that case (since HSYNC is behaving inverted, it's no longer valid)? Or is the signal actually 3 states (positive,negative,inactive)?

If the idle and active states are swapped, won't the signal be unreliable because the active driving or non-driving states are essentially useless (no way to determine if it's driving (retracing) or idle(normal display))?

Say you say it's positively decoded:
1(5V)=retracing now
0(0V)=not retracing

All's fine in that case, since the retracing can be driven directly from that (only some simple transformation to higher voltage).

Then if you'd reverse that (negative sync):
0(0V)=retracing
1(5V)=not retracing

Now you'd have the issue of not being able to differentiate and seperating the two cases, as 0V both means to drive the coils(0V=retracing if negative sync) and not retracing(0V=not retracing, if positively sync).
The same issue with the voltage swapped (but reversed).

So there's no way to tell if the VGA wants to retrace or not, as the signal would (looking it at it from a binary on/off state) become unreliable to tell one from the other (sync vs non-sync states are both defined to be the same)?

Also, unless the HSYNC's driving (retracing) state if dormant, you can't count lines (so can't reliable detect VSYNC based on the length of a VSYNC pulse), thus even VSYNC's positive/negative information is useless? Or does it simply count the lines by detecting raw state changes (high-low-high as well as low-high-low)?

superfury wrote on 2024-01-28, 19:56:

Won't the HSYNC polarity being negative clash with detecting HSYNC itself? Since it needs to go high every hsync period to properly cause flyback of the beam?

Most of the early VGA monitors have a clever sync detection circuit that uses a combination of XOR gates and one-shot timers which detects the edges of the sync signal and also determines if the incoming sync is mostly high (with low sync pulses) or mostly low (with high sync pulses). The horizontal and vertical sync polarity detectors are then used to switch in different circuits for the vertical oscillator.

Later SVGA monitors measured the hsync frequency to switch between modes and typically the sync polarity had no effect unless the input hsync was 31.5khz - this is because there are only four combinations of sync polarity and they were already in use for "legacy" modes.

superfury wrote on 2024-01-28, 19:56:

Afaik on an EGA, the VSYNC polarity also determines the pins used during active display (to select EGA or CGA mode in the monitor (mode 1 vs mode 2 it's called I think)? Then what effect does HSYNC have there (on a EGA monitor)? Or will the monitor simply fail in that case (since HSYNC is behaving inverted, it's no longer valid)? Or is the signal actually 3 states (positive,negative,inactive)?

Positive VSYNC makes the EGA monitor behave like CGA: 200 lines, RGBI
Negative VSYNC selects the native EGA mode: 350 lines, RRGGBB

HSYNC should always be positive on EGA.

Grzyb wrote on 2024-01-28, 21:02:

Positive VSYNC makes the EGA monitor behave like CGA: 200 lines, RGBI Negative VSYNC selects the native EGA mode: 350 lines, RRG […]
Show full quote

superfury wrote on 2024-01-28, 19:56:

Afaik on an EGA, the VSYNC polarity also determines the pins used during active display (to select EGA or CGA mode in the monitor (mode 1 vs mode 2 it's called I think)? Then what effect does HSYNC have there (on a EGA monitor)? Or will the monitor simply fail in that case (since HSYNC is behaving inverted, it's no longer valid)? Or is the signal actually 3 states (positive,negative,inactive)?

Positive VSYNC makes the EGA monitor behave like CGA: 200 lines, RGBI
Negative VSYNC selects the native EGA mode: 350 lines, RRGGBB

HSYNC should always be positive on EGA.

Then why add the capability of making HSYNC negative? What's the purpose of that?

superfury wrote on 2024-01-28, 23:57:

Then why add the capability of making HSYNC negative? What's the purpose of that?

Probably because it was cheap to generate both, and it provided more flexibility with devices connected to the feature connector.

GloriousCow wrote on 2024-01-29, 18:15:

superfury wrote on 2024-01-28, 23:57:

Then why add the capability of making HSYNC negative? What's the purpose of that?

Probably because it was cheap to generate both, and it provided more flexibility with devices connected to the feature connector.

Does negative HSYNC on EGA have any effect on the monitor at all?

Also, what effect does the VGA hsync/vsync polarity really have on a CRT? Does it change something in the monitor?

superfury wrote on 2024-01-31, 19:17:

Also, what effect does the VGA hsync/vsync polarity really have on a CRT? Does it change something in the monitor?

The VGA monitor runs at a fixed frequency of 31.5kHz horizontal, but can operate at 350 visible lines, 400 visible lines or 480 visible lines. Standard VGA monitors typically decode the sync polarity to choose one of three internally pre-set picture heights, so that the picture always fills (around) the same amout of space.

mkarcher wrote on 2024-01-31, 22:39:

superfury wrote on 2024-01-31, 19:17:

Also, what effect does the VGA hsync/vsync polarity really have on a CRT? Does it change something in the monitor?

The VGA monitor runs at a fixed frequency of 31.5kHz horizontal, but can operate at 350 visible lines, 400 visible lines or 480 visible lines. Standard VGA monitors typically decode the sync polarity to choose one of three internally pre-set picture heights, so that the picture always fills (around) the same amout of space.

So basically it adjusts the horizontal retrace's vertical distance to fill that size (including blanking areas)?

Because software can decide to give more or less horizontal retraces in a frame?

superfury wrote on 2024-02-01, 08:12:

So basically it adjusts the horizontal retrace's vertical distance to fill that size (including blanking areas)?

Yeah, that's a valid way to look at it.

superfury wrote on 2024-02-01, 08:12:

Because software can decide to give more or less horizontal retraces in a frame?

You should be aware that the total line count in a 350-line frame and a 400-line frame is equal (IIRC 449 lines). The 350-line frame just has more blanking, which should not be displayed as black letterbox bars in 350-line mode. So the total count of horizontal retraces is the same, but the count of horizontal retraces during the actual image content is lower.

mkarcher wrote on 2024-02-01, 21:18:

You should be aware that the total line count in a 350-line frame and a 400-line frame is equal (IIRC 449 lines). The 350-line frame just has more blanking, which should not be displayed as black letterbox bars in 350-line mode. So the total count of horizontal retraces is the same, but the count of horizontal retraces during the actual image content is lower.

Yes, that's very important!

If HSYNC=31.5kHz and VSYNC=60Hz, then it must be the 480-line mode - no need to look at the SYNC polarity, it's enough to measure the frequencies.
If HSYNC=31.5kHz and VSYNC=70Hz, then it may be the 350- or the 400-line mode - the only way to tell them apart is by looking at the SYNC polarity.

Grzyb wrote on 2024-02-01, 22:12:

If HSYNC=31.5kHz and VSYNC=60Hz, then it must be the 480-line mode - no need to look at the SYNC polarity, it's enough to measure the frequencies.

Before monitors had control processors (i.e. up around to 35kHz HSYNC), measuring the sync frequency was more involved than looking at the SYNC polarity. Most VGA monitors synchronize anything between 58Hz and 72Hz, and nothing in their circuitry depends on the sync. Back in the time with a fixed-HSYNC VGA monitor, I experimented with adding extra blanking to lower the refresh rate (to make games run at like 65fps instead of 35fps when it missed every second frame), and found out that adding extra vertical front/back porch did not change the picture size. You could add that much blanking to the 400 line mode to get to 60 Hz - as long as the SYNC polarity indicated 400 lines, the image height was appropriate for 400 lines.

On the other hand, changing sync polarities did not change the capture range of the vertical oscillator - only the VHOLD control on the back of the monitor did.

mkarcher wrote on 2024-02-01, 22:31:

Grzyb wrote on 2024-02-01, 22:12:

If HSYNC=31.5kHz and VSYNC=60Hz, then it must be the 480-line mode - no need to look at the SYNC polarity, it's enough to measure the frequencies.

Before monitors had control processors (i.e. up around to 35kHz HSYNC), measuring the sync frequency was more involved than looking at the SYNC polarity. Most VGA monitors synchronize anything between 58Hz and 72Hz, and nothing in their circuitry depends on the sync. Back in the time with a fixed-HSYNC VGA monitor, I experimented with adding extra blanking to lower the refresh rate (to make games run at like 65fps instead of 35fps when it missed every second frame), and found out that adding extra vertical front/back porch did not change the picture size. You could add that much blanking to the 400 line mode to get to 60 Hz - as long as the SYNC polarity indicated 400 lines, the image height was appropriate for 400 lines.

On the other hand, changing sync polarities did not change the capture range of the vertical oscillator - only the VHOLD control on the back of the monitor did.

So then what effect does the polarities actually have on the CRT signal? Does the monitor ignore blanking (like cutting it off the image by disabling the beam (done anyways) and deflection to stay at the left border)? What about horizontal scanline moving effects like the copper demo? Won't that fail?

superfury wrote on 2024-02-02, 07:04:

So then what effect does the polarities actually have on the CRT signal? Does the monitor ignore blanking (like cutting it off the image by disabling the beam (done anyways) and deflection to stay at the left border)? What about horizontal scanline moving effects like the copper demo? Won't that fail?

The polarity of the sync signal does not change how the video signal is processed by the CRT logic. In most monitors that support different sync polarities, the first stage in sync processing is converting the sync signal to a fixed polarity. Furthermore, a monitor is not an oscilloscope. In an oscilloscope, the deflection is held at the left border until a trigger condition is detected. This works especially well because the oscilloscope uses electric deflection. In CRTs, the magnetic deflection is performed using an L/C tank circuit which can not be "held". As far as I know, PC monitors do not create a "blacker than black" level during an active snychronization phase.

The copper bars are clipped by the graphics card, which always outputs black during the whole "blanking" interval. The blanking interval is always bigger than the sync pulse width - unless you let VileR get close to your CRTC. 😉 I don't understand what you try to ask about copper bars that might be related to sync pulse shape, width or polarity.

mkarcher wrote on 2024-02-02, 22:27:

superfury wrote on 2024-02-02, 07:04:

So then what effect does the polarities actually have on the CRT signal? Does the monitor ignore blanking (like cutting it off the image by disabling the beam (done anyways) and deflection to stay at the left border)? What about horizontal scanline moving effects like the copper demo? Won't that fail?

The polarity of the sync signal does not change how the video signal is processed by the CRT logic. In most monitors that support different sync polarities, the first stage in sync processing is converting the sync signal to a fixed polarity. Furthermore, a monitor is not an oscilloscope. In an oscilloscope, the deflection is held at the left border until a trigger condition is detected. This works especially well because the oscilloscope uses electric deflection. In CRTs, the magnetic deflection is performed using an L/C tank circuit which can not be "held". As far as I know, PC monitors do not create a "blacker than black" level during an active snychronization phase.

The copper bars are clipped by the graphics card, which always outputs black during the whole "blanking" interval. The blanking interval is always bigger than the sync pulse width - unless you let VileR get close to your CRTC. 😉 I don't understand what you try to ask about copper bars that might be related to sync pulse shape, width or polarity.

What I mean with the copper bars is does blanking affect the display enable signal in any way (input status 1 register's bit 0)?

superfury wrote on 2024-02-02, 22:44:

What I mean with the copper bars is does blanking affect the display enable signal in any way (input status 1 register's bit 0)?

The display enable signal is true (i.e. bit 0 is clear) if the current character counter is smaller than or equal to the horizontal display end value, and the current line counter is smaller than or equal to the vertical display end value. The display enable signal is not affected by palette settings. Copper bars work by re-programming the palette entry for some color, typically color 0 during a single scan-line.

EDIT: this is wrong. copperbars are rendered in the overscan area. So they turn off as soon as "blanking start" is reached, and the turn on again as soon as blanking end is reached.

mkarcher wrote on 2024-02-03, 07:28:

superfury wrote on 2024-02-02, 22:44:

What I mean with the copper bars is does blanking affect the display enable signal in any way (input status 1 register's bit 0)?

The display enable signal is true (i.e. bit 0 is clear) if the current character counter is smaller than or equal to the horizontal display end value, and the current line counter is smaller than or equal to the vertical display end value. The display enable signal is not affected by palette settings. Copper bars work by re-programming the palette entry for some color, typically color 0 during a single scan-line.

So copper bars don't render on overscan? Even though overscan is through the DAC? So effects from the DAC will work strangely (wrong scanline) for the left half of screen's overscan if overscan color is set to DAC entry #0 on VGA? Because display is still disabled there? That's either the remainder of the overscan just before horizontal total or horizontal display skew's clocks following it?

superfury wrote on 2024-02-03, 10:33:

So copper bars don't render on overscan? Even though overscan is through the DAC? So effects from the DAC will work strangely (wrong scanline) for the left half of screen's overscan if overscan color is set to DAC entry #0 on VGA? Because display is still disabled there? That's either the remainder of the overscan just before horizontal total or horizontal display skew's clocks following it?

Sorry, I mixed that up. Copper bars do render on overscan. I should not have written about "display end", I should have written about "blanking start".

mkarcher wrote on 2024-02-03, 12:58:

superfury wrote on 2024-02-03, 10:33:

So copper bars don't render on overscan? Even though overscan is through the DAC? So effects from the DAC will work strangely (wrong scanline) for the left half of screen's overscan if overscan color is set to DAC entry #0 on VGA? Because display is still disabled there? That's either the remainder of the overscan just before horizontal total or horizontal display skew's clocks following it?

Sorry, I mixed that up. Copper bars do render on overscan. I should not have written about "display end", I should have written about "blanking start".

The main issue is when "blanking end" after "retrace end" horizontally (as well as retrace usually) it's on the next scanline? So when the horizontal retrace and blanking ends, before the start of the next video memory being rendered (until horizontal total and after that the horizontal display enable skew, if used. So basically back porch until start of active display from VGA pov), the DAC will start outputting on the next scanline. But since the active display isn't started yet, the input status 1 register bit 0 is still indicating 'retrace'? So the software would think it's either on the next scanline or not yet? Is the DAC color assumed 'set' during the start of horizontal retarce (which gives correct results) or assumed from the end of 'retrace' (which would be incorrect as the back porch's overscan area is there as well)?