Hi!
I was trying to add a custom resolution to my list of resolutions in the hope that a lower resolution that adhered to my monitor's aspect ratio (16:10) would be less taxing on the graphics hardware and enable me to play some games with a higher framerate. Alas, all my efforts to use the DTD Calculator to add custom resolutions to my computer have been unsuccessful. In the process, I took a lot of notes about what things in the DTD Calculator application did or meant. I will try to share them to the best of my recollection here in the hopes of sharing knowledge and improving software. I'm probably going to go into a bit more detail than some care about, and I'm probably going to cover some topics that some people already know about, so please bear with me.
Also, it's entirely possible that I worry too much about stuff, or that I'm entirely wrong in some of my notes. If I've misunderstood something, please correct me.
I have a Mobile Intel 965 Express Chipset in a Dell Inspiron 1525 laptop that runs Windows Vista 32-bit. I have attached a Diagnostic Report from the graphic driver software package.
DiagnosticReport.txt 2k .txt file
My default Calculated DTD:
Code:
Code:
[CODE]DE 21 A0 70 50 84 1F 30 20 20 56 00 4B CF 10 00 00 18
[/CODE]
And attached is a photo of the interpretation of this DTD.
DTD Calculator - 01 Default DTD.png 63k .png file
First, was just understanding some of the values. Active Pixels/Lines? Blank Pixels/Lines? Start/End of Sync Pulse? End of Blanking Interval? Sync Offset? Sync Width? I needed some help.
http://software.intel.com/en-us/articles/custom-resolutions-on-intel-graphics/
Okay, this was fairly simple.
Code:
Code:
[CODE]H Active Pixels
H Start of Sync Pulse = H Active Pixels + H Sync Offset
H End of Sync Pulse = H Start of Sync Pulse + H Sync Width
H End of Blanking Interval = H Active Pixels + H Blank Pixels
H Active Pixels = 1440
H Blank Pixels = 112
H Sync Offset = 32
H Sync Width = 32
H Start of Sync Pulse = 1440 + 32 = 1472
H End of Sync Pulse = 1472 + 32 = 1504
H End of Blanking Interval = 1440 + 112 = 1552
V Active Lines
V Start of Sync Pulse = V Active Lines + V Sync Offset
V End of Sync Pulse = V Start of Sync Pulse + V Sync Width
V End of Blanking Interval = V Active Lines + V Blank Lines
V Active Lines = 900
V Blank Lines = 31
V Sync Offset = 5
V Sync Width = 6
V Start of Sync Pulse = 900 + 5 = 905
V End of Sync Pulse = 905 + 6 = 911
V End of Blanking Interval = 900 + 31 = 931
[/CODE]
Or in some other terms:
Code:
Code:
[CODE]Right Picture Border = H Sync Offset = 32
H Sync Pulse = H Sync Width = 32
Left Picture Border = H Blank Pixels - (H Sync Offset + H Sync Width)
Left Picture Border = 112 - (32 + 32) = 112 - 64 = 48
H Total Pixels = H Active Pixels + Right Picture Border + H Sync Pulse + Left Picture Border
H Total Pixels = 1440 + 32 + 32 + 48 = 1552
Lower Picture Border = V Sync Offset = 5
V Sync Pulse = V Sync Width = 6
Upper Picture Border = V Blank Lines - (V Sync Offset + V Sync Width)
Upper Picture Border = 31 - (5 + 6) = 31 - 11 = 20
V Total Lines = V Active Lines + Lower Picture Border + V Sync Pulse + Upper Picture Border
V Total Lines = 900 + 5 + 6 + 20 = 931
[/CODE]
So where did the numbers come from? Thankfully, the application points most of this out for us, and with some help from a
Wikipedia article on EDID I managed. I've color-coded the important parts, after that I ran out of easily distinguishable colors.
Code:
Code:
[CODE]00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 (Byte Reference Numbers)
DE 21 A0 70 50 84 1F 30 20 20 56 00 4B CF 10 00 00 18
[/CODE]
DE 21 A0 70 50 84 1F 30 20 20 56 00 4B CF 10 00 00 18
Byte 10 = 0x56 = (binary) 0101 0110
Byte 11 = 0x00 = (binary) 0000 0000
H Active Pixels = 0x5A0 = 1440
First Half (bits 7-4; first 4 bits from the left) of Byte 04 (5) and all of Byte 02 (A0)
H Blank Pixels = 0x070 = 112
Second Half (bits 3-0; last 4 bits from the left) of Byte 04 (0) and all of Byte 03 (70)
V Active Lines = 0x384 = 900
First Half (bits 7-4) of Byte 07 (3) and all of Byte 05 (84)
V Blank Lines = 0x01F = 31
Second Half (bits 3-0) of Byte 07 (0) and all of Byte 06 (1F)
H Sync Offset = 0x020 = 32
First Quarter (bits 7-6; first 2 bits from the left) of Byte 11 (0) and all of Byte 08 (20)
H Sync Width = 0x20 = 32
Second Quarter (bits 5-4; second set of 2 bits from the left) of Byte 11 (0) and all of Byte 09 (20)
V Sync Offset = 0x05 = 5
Third Quarter (bits 3-2; third set of 2 bits from the left) of Byte 11 (0) and the First Half (bits 7-4) of Byte 10 (5)
V Sync Width= 0x06 = 6
Fourth Quarter (bits 1-0; fourth set of 2 bits from the left) of Byte 11 (0) and the Second Half (bits 3-0) of Byte 10 (6)
The following parts I just have no idea what to do with, but here they are anyway:
H Image Size (mm) = 0x14B = 331
First Half (bits 7-4) of Byte 14 (1) and all of Byte 12 (4B)
V Image Size (mm) = 0x0CF = 207
Second Half (bits 3-0) of Byte 14 (0) and all of Byte 13 (CF)
H Border (each side in pixels) = 0
Byte 15 (00)
V Border (each side in pixels) = 0
Byte 16 (00)
Byte 17 is a bitmap, so it's full of stuff!
0x18 = 0001 1000
Bit 7, Interlaced: 0 (Off)
Bits 6-5, Stereo: 00 (No stereo)
Bits 4-3, Sync type: 11 (Digital separate)
Bit 2, if digital separate VSync polarity: 0 (negative)
Bit 1, Digital: HSync polarity: 0 (negative)
Bit 0, 2-way line-interleaved stereo, if bits 4–3 are not 00: 0
First problem, familiarization, solved!
Second, I was presented with two Pixel Clock values.
DTD Calculator - 02 Pixel Clock.png 66k .png file
One value is from the Hex value (0x21DE, or 8670), which is marked as being in "kHz", and the other value is calculated from that into MHz (86.7). The problem here is that 8670 kHz does
not equal 86.7 MHz. 8670 kHz would be 8.67 MHz. So I did some digging.
http://www.mcamafia.de/mcapage0/timecalc.htm (Even though this reference seems to have been for an older CRT, the math still seems to be sound.)
http://electronics.stackexchange.com/questions/14828/how-do-i-calculate-needed-pixel-clock-frequency
Pixel Clock appears to be calculated like so:
Pixel Clock (Hz) = H Total Pixels * V Total Lines * Refresh rate in Hz
Per the information in DTD Calculator for my default DTD, that would be:
Pixel Clock (Hz) = 1552 * 931 * 60.0036542 Hz
Pixel Clock (Hz) = 86699999.9974304 Hz
Or 86.6999999974304 MHz, which is really close to the 86.7 MHz from the DTD Calculator. So what about that 8670 kHz value?
Well, 0x21DE in hexadecimal
really does equal 8670. However, I saw this:
Quote:
Originally Posted by
http://en.wikipedia.org/wiki/Extended_display_identification_data#EDID_1.3_data_format
EDID Detailed Timing Descriptor
Bytes 0-1: Pixel clock in 10 kHz units. (0.01–655.35 MHz, little-endian)
In simple terms, "little-endian" means that the number is displayed in backward segments (least significant bits, such as those influencing the "ones column", are given first instead of last). So the Bytes 0-1 values of "DE 21" become "21 DE" or "0x21DE" when reading them normally.
However! The important part was this (emphasis mine), "Pixel clock in
10 kHz units". Ah-hah! The Pixel Clock in the DTD is given in
10 kHz units, not just
single kHz units. So that means that 8670 10-kHz = 86700 kHz. 86700 kHz
does indeed equal 86.7 MHz. It may be worth noting that the first Standard Timing included with the application, 1920x1080p @ 60Hz, illustrates this a bit more cleanly. Second problem, Pixel Clock, solved!
Related, it seems that the refresh rate gets calculated based off of the given Pixel Clock and Total Pixels (H Total Pixels * V Total Lines). Is there a reason it isn't the other way around (calculate Pixel Clock based on dimensions and a given Refresh Rate)?
So, having now a better understanding of this stuff, I sought to make a custom DTD for my computer to try to run games at lower resolutions (below 1440x900) but that remained at my monitor's native aspect ratio (16:10). I decided to try 960x600 for Active Resolution. My final worries were keeping the Pixel Clock, Refresh Rate, dimensions, and sync timings to something that my monitor could handle gracefully (I had read warnings that incorrect settings could damage monitors, so naturally I was a bit worried). I opted to try to keep the refresh rate at 60 Hz and the Pixel Clock to something that seemed in line with the Standard DTDs and my default DTD. I went about it, did some fiddling with the Blanking/Sync dimensions and Pixel Clock to ensure a refresh rate of 60 Hz, and came up with this using DTD Calculator:
60 18 C2 52 31 58 C8 20 62 5A 22 0F 4B CF 10 00 00 18
I had run the application as administrator. I added a custom DTD slot. I got the calculated DTD, and I wrote it to the registry. I can confirm that it is
in the registry where it seems like it should be. I restarted, and the custom resolution did not show up. I thought it might be a banned resolution in the Video BIOS, so I tried to make one a few pixels off, saved, restarted, and still nothing. Maybe I'm just doing something... really wrong. Or I missed some really basic step somewhere.
I note that this thread has seen relatively little activity for a while, and that probably has something to do with the age of chipsets that benefit from this software. I thought I'd post anyway and see what happened. Hope some of the information is helpful to someone! Thank you to Archibael, Paul, and Wo0zy for their work!
P.S.: The link to instructions under the About tab in the application that points to
http://isnwiki.jot.com/WikiHome/Articles/111111431 no longer works. Also, I apologize for the massive wall of text that this post became. It was originally just "Help! What did I do wrong?"