eddman wrote on 2025-07-16, 22:58:
I understand not having too many refresh rates as it would just bloat the standards, but I don't understand why they chose what they chose. Why go with 75 and not, say, 74 instead?
I only understand a bit of this because of messing with old XFree86 recently and the video timing howto (https://tldp.org/HOWTO/XFree86-Video-Timings- … OWTO/specs.html)
The relevant numbers in a Modeline are HTotal and VTotal. These are not just the resolution but extra time involved for non-displayed "pixels" like blanking interval, front porch back porch, sync pulses, etc.
Basically old cards only have a discrete set of dot-clocks (in MHz).
The horizontal frequency is the dot clock divided by HTotal, and old monitors can often only handle one or a small set of discrete ones (such as 31.5 kHz, 35.15 kHz, and 35.5 kHz per xf86config) too.
HTotal has to be a multiple of 8 (usually?).
So a standard VGA card has only 25.175 and 28.32 MHz dot clocks on the card.
That gives two possible HTotal values to maintain the HTotal*31.5 kHz=dot clock: 800 and 900
So XFree86's default 640x480 @ 60 Hz uses a dot clock of 25.175, and HTotalxVTotal of 800x525; that maintains 25175000/800 = 31468.75 Hz HorizSync and produces 25175000/800/525 = 59.94 Hz VertRefresh.
720x400 text mode and friends goes along with the 28.32 clock.
800@600 @ 56 Hz uses a dot clock of 36 and maintains a HorizSync of 35.15 kHz, and HTotalxVTotal of 1024x625 producing 56.25 Hz. Looks like 35.5 kHz went with 1024x768 @ 87 interlaced Hz.
It's interesting that the padding added to the displayed resolution to obtain HTotal often ends up being the displayed resolution of the next highest resolution... not sure if there was some circuitry reason for that.
Back to the question - in this restricted environment where the dot clock, and the ratio of the dot clock to HTotal have to be constrained to discrete values, and then VTotal correspondingly has to be within some restricted range to maintain the desired aspect ratio and blanking/porch/sync timings - that would naturally produce some refresh rate. So the question is did they pick a desired refresh rate and work backward - or pick the dot clock and HorizSync rate and then determine what refresh rates were possible? were particular dot clocks or HorizSync rates desirable for physics or economics reasons like the availability of oscillators at that frequency?
I'm not sure what dot clocks or horiz sync frequencies they may have wanted to avoid either; for example the Cirrus 542x data book suggests avoiding frequencies that are close to the memory frequency for interference reasons, and if you are close to the memory frequency, there is an option to just use the memory frequency as the dot clock rather than trying to generate a second one.
