Pixel clock in Hz = ((Visible pixels on a line + border, blanking and sync pixels) * (visible number of lines + border, blanking and sync lines)) * Framerate in Hz

For example VGA 640x480 resolution has has total of 800 pixels per line (of which only 640 are information), 525 lines total per frame (of which 480 are information) and 59.94Hz refresh rate
800 * 525 * 59.94 = 25.175MHz, the VGA standard pixel clock

I can't figure out how you do the calculation, there are several things I don't know, I don't know where the values 800 and 525 came from, I don't know what values to use to calculate the minimum Pixel Clock of my monitor.

Could you explain how the maximum 80MHz value was calculated?

There might be some background stuff that helps you in here, or PCEM might do it in an idiosyncratic way..

https://tldp.org/HOWTO/XFree86-Video-Timings- … OWTO/index.html

Edit: gah bedtime I guess, you never said PCEM 🤣 but anyway, timing and screenmode basics in that link.

vico wrote on 2024-04-19, 03:42:

I can't figure out how you do the calculation, there are several things I don't know, I don't know where the values 800 and 525 came from, I don't know what values to use to calculate the minimum Pixel Clock of my monitor.

800 pixels fer line and 525 lines per frame are the VGA 60Hz resolution standard, someone came up with these values multiple decades ago at IBM and every VGA monitor and card uses these values or close approximations when outputting the standard VGA resolution.

Could you explain how the maximum 80MHz value was calculated?

The 80MHz maximum is the physical limit of your monitor, it is only able to sync up to pixel clocks up to 80MHz, while also needing to follow maximum line rate which is 60kHz and maximem frame rate which is 75Hz. Panel resolution is 1024 x 768 pixels.

According to these specs, this is an attempt to calculate lower level details of the maximum the monitor can handle :
*Maximum Pixels per line = Pixel Clock / Line Rate = 8000000 / 60000 = 1333.3333...
*Maximum lines per frame = Line Rate / Frame Rate = 60000 / 75 = 800

These figures also include not just visible pixels but also borders, blanking and sync portions.

Since the monitor native resolution is 1024 x 768, this leaves 1333 - 1024 = 309 pixels for all the horizonntal offscreen parts on a line, and 800 - 768 = 32 lines for vertical bits beyond the active image.

A line is composed of 4 parts :
* Sync pulse
* Left blanking + border (commonly called Back Porch, because it is after the sync pulse)
* Active line (the actual visible pixels)
* Right blanking + border (commonly called Front Porch, because it is before the sync pulse)

Similarly a frame is composed of 4 parts too :
* Sync pulse
* Top blanking + border (vertical back porch)
* Active frame (the actual visible lines)
* Bottom blanking + border (vertical front porch)

Active line takes 1024 of these pixels, the remaining 309 are divided up to the sync and porches according to some standards and implementation details, i.e. sync pulse must be more than 1µs long) For example if you need to shift image toward left, you increase front porch pixel count and reduce back porch while making sure the total pixel count remains same. If it doesn't, the image timings change and this leads to a different resolution to the monitor.
Similar things for vertical centering, you reduce one porch by the same amount you incerase another.

----

Now to your original problem, you mentioned the image is too wide. This means that while the monitor synced up to the timings, there are simply too many pixels per line to fit into the visible portion. A solution is to increase pixel clock and increase porches to maintain the timings. Each increment of pixel clock makes the pixels narrower, and if porches are not increased the timings will also change. There will be a point where the image will fit onto the screen with just the right amount of border outside it.

To make this easier, what kind of resolution are you wanting, and what kind of timing values do you know ? All of these parameters are interrelated, and if you know some you can calculate the others.

For example to find pixel clock you do :
Pixel Clock = Pixels per Line * Line Rate
Pixel Clock = Pixels per Line * (Frame Rate * Lines per Frame)
As before, per line and per frame figures include blanking and sync portions, they can never be ignored.

This is a neat site that can be most helpful : https://tomverbeure.github.io/video_timings_calculator

Tiido wrote on 2024-04-19, 04:50:

According to these specs, this is an attempt to calculate lower level details of the maximum the monitor can handle :
*Maximum Pixels per line = Pixel Clock / Line Rate = 8000000 / 60000 = 1333.3333...
*Maximum lines per frame = Line Rate / Frame Rate = 60000 / 75 = 800

These calculatons are misleading, as the way they are performed they assume the maximum line rate and the maximum frame rate are used at the same time. This might well be true for the "signature mode" of that monitor, which might be 1024x768 @ 75Hz. On the other hand, maybe the monitor supports 1024x768 only at up to 72Hz, and 75Hz can only be used at 800x600. The absolute maximum pixels per line is calculated by "maximum pixel clock / minimum line rate", which is 80.000/31 = 2580. The absolute maximum lines per frame are similarly calculated as "maximum line rate / minimum frame rate", which is 60.000 / 56 = 1071. These two numbers I calculated are standalone numbers, and can't apply at the same time. You get the maximum number of pixels per line if the time for each line is as long as possble (i.e. line rate 31kHz) - only in that case you get 2580 pixels packed into a single line. But you only get the maxmum number of lines in a frame if lines are as short as possible (i.e. line rate 60kHz).

The general explanation of video timings in your post are quite descriptive and seems correct.

For LCD montors, stuff is more complicated, though: Those monitors try to regenerate the original pixels of the VGA signal, and then scale that digitized image to the panel resolution. To regenerate the original pixels, the monitor needs to know how many pixels there are on a line. There is no indication for the pixel clock on the VGA connector, so the monitor needs to reconstruct the pixel clock from the line clock by knowing how many total pixels there are per line, and then it will sample the amount of pixels it guesses to be the number of active pixels for the current display mode. The "picture width" control on an LCD monitor typically influences how many total pixels the monitor assumes, but not how many active pixels the monitor assumes. This concept works fine for "standard resolutions": The monitor has a table of common combinations of horizontal/vertical frequencies built in, which map them to the corresponding resolution. For example if the frequences are 35.2kHz/56Hz, the monitor assumes there are 800 pixels per line, and 600 lines per frame. Arcade machines on the other hand often run at resolutions which are uncommon in PC use, and not recognized by LCD monitors.

If you add enough front porch/back porch to a video timing, you might get the monitor to sample for the full active time of the signal (which makes the image no longer being "too wide"), but if the monitor doesn't guess the amount of active pixels during that time correctly, the image will be flickery and/or washed out.

Those calculations apply perfectly on the side that generates the image, which is what is being dealth with and what will allow to calculate pixel clock for the custom resolution that is bein created while giving info about how all the other parameters fit in and possibly make a resolution with right timings for satisfactory image. All the custom resolution creation things work on these calculations and I was using them as example to "verify" monitor capability it presents and how is was a reasonably close or even exact match to its specification of 1024 x 768 at 75Hz, perhaps if the actual 1024 x 768 @ 75Hz spec calls for some more specific timings that exceed 80MHz pixel clock then there can be mismatch between what fits in the pixel clock wanted and possible and other aspects you mention appear such as only 72Hz at standard 1024 x 768 resolution etc.

But the LCD sampling issue is a big one, but it depends very much on what resolution is the software needing customisation feeding to the monitor and what options are there to get a more closer match and get satisfactory display.

I haven't had much luck with my monitor spec values, but I have used some values calculated with https://tomverbeure.github.io/video_timings_calculator.
At the end I used this configuration:

. . . device_video_clock 21.384-25.175 / 31.5 / 59.375-60 display_adjust generate_clocky display_mode generate . . . […]
Show full quote

.
.
.
device_video_clock 21.384-25.175 / 31.5 / 59.375-60
display_adjust generate_clocky
display_mode generate
.
.
.

With which I have a well-proportioned and centered image at 640x480 60Hz.
Thanks everyone for your help.