| X Modeline | |
| Resolution | 0 | |
| H Frequency | 0 | |
| V Frequency | Hz | |
| Pixel Clock | MHz | |
| H Resolution | 0 | |
| H Front Porch | 0 | |
| H Sync Pulse | 0 | |
| H Back Porch | 0 | |
| H Blank | 0 | 0 |
| H Total | 0 | 0 |
| V Resolution | 0 | |
| V Front Porch | 0 | |
| V Sync Pulse | 0 | |
| V Back Porch | 0 | |
| V Blank | 0 | 0 |
| V Total | 0 | 0 |
| H Sync Polarity | ||
| V Sync Polarity | ||
| Scan | ||
| H Position | ||
| V Position |
This is a tool for manually creating custom non-standard video timings. Use at your own risk, this tool does not validate the timings in any way! Custom signals can and have destroyed monitors! Particularly 80s and early 90s CRTs are at a high risk of becoming smoke machines.
The tool is work-in-progress, may have bugs and information on this page may be inaccurate.
The modeline is used with X Windowing System, and is the closest thing to a standard format for VGA signals. You'll find many calculators using this format, thus an automatic one is not implemented here. CSync and Doublescan flags are currently unsupported.
VGA timings are also used by digital interfaces such as DVI, HDMI and even Displayport in some capacity. This editor can be useful with digital displays for overclocking or manual creation of QFT modes, as examples.
GTF is a widely used standard from 1999. It was designed with older displays in mind, and is a good bet for most multisync CRTs.
CVT is a newer standard that superceded GTF in 2002.
CVT Reduced Blanking is for use with digital displays that do not need large porches to wait for a beam to travel around.
DMT is a set of predefined resolutions and timings. Many of these do not conform to either GTF or CVT.
Early versions of CVT required all of the horizontal values to be divisible by eight due to hardware limitations of the time. Later this requirement was lifted, and isn't enforced in this editor (a toggle might be implemented). Older systems may have problems with precise timings, and even 2010s GPUs can be allergic to non-divisible visible areas. CRTs themselves do not parse horizontal pixels and will not have issues with this.
These serve a few purposes, but the main reason to mess with them is to position the visible area properly on CRT displays, preferrably in the most geometrically optimal time of the scanout. If the porches are too small, the picture can be cut out or have major distortion.
Porches can also be used to hide geometric problems. As an example, some Diamondtrons struggle with vertical linearity on the top part of the picture at high refresh rates. This can be hidden away inside a large vertical back porch, at a cost of slightly lower resolution and/or refresh rate.
Many CRT monitors include position and size controls, however these often have sweet-spots for linearity, doing those adjustments on the source side instead can be highly beneficial.
Large porches can reduce brightess, however some CRT monitors such as many Diamondtrons have options to compensate for this (Edge Lock). Porch widths can also drive up your pixel-clock, which may impact signal clarity, or exceed your maximum DAC speed altogether.
Zero-pixel porchesThese are used in a few standard resolutions like 1024x768i 43Hz, however many systems consider them invalid. Use with caution.
All displays, including LCDs, have a range of horizontal and vertical frequencies they can operate in. Refer to your displays manual for supported ranges.
Quite a few multisync displays allow you to exceed their vertical refresh rate. Most such monitors seem to tolerate it well.
Exceeding your maximum horizontal frequency is highly inadvisable, and most monitors do not allow you to do it anyway for good reasons. If you're overclocking your vertical, make sure this value doesn't go out of range.
Horizontal frequency is how many horizontal lines a second your display
is drawing. It can be simply calculated by V Total * Refresh Rate.
Most systems do not support arbitrary precision clocks. Expect some quantization error, your carefully set refresh rate may not be replicated accurately.
For analog video, pixel clock is an entierly source-side concept, most if not all CRTs are completely indifferent to this value. However, analog circuitry usually cannot keep up with arbitrarily frequent pixel transitions, quality loss is inevitable at high enough pixel clocks.
Your DAC however will have a hard pixel clock limit. The last GPU RAMDACs were usually 400MHz. Some workstation cards were capable of 500MHz. Many basic adapters go only up to 150-200MHz, but some Displayport-to-VGA adapters can operate even at 600MHz.
Monitors may use these to determine what mode is being displayed. What exactly these convey depends entierly on the monitor and what standards it follows, if any. Many monitors appear completely indifferent to pulse polarities.
Vesa CVT uses them in the following way:
| Horizontal | Vertical | Timing |
|---|---|---|
| Negative | Positive | CVT Standard CRT |
| Positive | Negative | CVT Reduced Blanking |
| Positive | Positive | Non-CVT Timing |
| Negative | Negative | Non-CVT Timing |
Similiarly to polarity, the linecount of the vertical sync pulse can be interpreted in different ways, or not at all.
Vesa CVT uses them to convey aspect ratio:
| Vertical Sync Width | Aspect Ratio | Notes |
|---|---|---|
| 3 or less | Not used by CVT | Reserved for existing DMT and GTF timings |
| 4 | 4:3 | |
| 5 | 16:9 | |
| 6 | 16:10 | |
| 7 | 5:4 (1280x1024) 15:9 (1280x768) |
|
| 8 | Reduced Blank Timings v2 | Digital displays understand horizontal pixel counts and can calculate aspect ratio themselves |
| 9 | Reserved | |
| 10 | Non-standard | Can be used for manufacturer specific timings |
Do note that several industry standard resolutions violate these rules, and many displays predate this table.
Made by your favorite 2hu fan 01/12/2021
Last modified 04/01/2022
https://gitlab.com/kosshi/vgatimingeditor