I've moved that instruction, from where it was, back into the hsync subroutine and it's fixed the issue.
hsync
xcont m_bs, hsync0 'generate horizontal FP blanking
xzero m_sn, hsync1 'generate the sync pulse
wrlong status, statusaddr 'update the sync status per line
dobreeze xcont m_br, hsync0 'do breezeway before colour burst
setcq cq 'reapply CQ for PAL colour changes
doburst xcont m_cb, colourburst 'do the PAL/NTSC colour burst
flipref xor cq, palflipcq 'toggle PAL colour output per scanline
bp _ret_ xcont m_bv, hsync0 'generate the back porch
Holy cow! E-EDID is ghastly! ... It looks like what I'm after is called DisplayID. I'm guessing it was introduced alongside DisplayPort. It details supporting of VRR features.
@rogloh said:
I have a Pioneer plasma TV (1366x768) to test with over HDMI or VGA, ...
That's the weirdest resolution. 1366 doesn't divide by 8. Now you've pointed it out I see that my Dick Smith TV is also spec'd exactly the same native resolution ... and neither driver works ... okay, Eric's one simply can't do exactly that resolution since it's locked to multiples of 8. Your one just stops displaying anything above 1360 horizontal ...
EDIT: Correction, Eric's driver needs multiples of 16 to behave. ie: An even number of columns ... Been all the way up to 1600x900 with this driver - 370 MHz sysclock, 24 Hz refresh.
Your driver also rounds to multiples of 8, and also has a character column glitch with odd number of columns ... and still no picture above 1360 ... the TV reports no mode detected, nor invalid, but also not auto-power-down.
EDIT2: LOL, guess what? Putting that damn front porch XCONT back where you had it fixes the hi-res limitation. Must just be a coincidence it hit right on the 1366 point.
My driver can go up to 1920x1200 at 60Hz with VGA. It works on my Dell monitor at native resolution, but it needs a specific timing setup to sync right, only possible once I obtained it for that model from somewhere online.
I'll probably have to look into this xcont moving thing at somet point if you think it is a bug and causes sync issues, can't say I was really paying a lot of attention at 1.45am to what you were saying.
Update: I think the Pioneer can accept both 1360 and 1368 pixel widths as well, IIRC.
Huh, you know you can free up a lump of cogRAM in your driver. Those two "interlaced" sync overlays are sitting in the initial ORG 0 section. They should really have their own ORGs.
EDIT: Oh, nevermind. I see that space is the font cache.
@rogloh said:
My driver can go up to 1920x1200 at 60Hz with VGA.
I can get the prop2 DVI output doing 1920x1200 But at only 15 Hz refresh. TV not happy. Best I can get displayed is 1920x768@24. Of course, with the native LCD res being lower, not all pixels are there anyway.
EDIT: Actually, with a 16:9 aspect display, a 2:1 resolution looks nice. So something like 800x400 or 1024x512 or 1280x640 ... Hehe, I guess that means an 8x16 font still isn't tall enough when pixels are square.
In my wandering about looking up EDID programming, I came across the odd disparaging comments like display drivers don't bother with much beyond the basics ...
Well, having now decoded the data stored in my TV, I'm not surprised that drivers don't use much info from the devices. It just reads like a fixed set for the whole product range! There's no specifics that are correct for the model. The only info probably correct is the EDID supported standard and year of firmware revision.
EDIT: I guess PC monitors will be better. After all, EDID was always a PC thing from the outset.
The annoying part is my TV is really flexible timings wise. It just doesn't advertise it .... the craziest part is it even has an FD tagged "Range Limits" descriptor block defined. But the parameters are just not anything like reality. PS: They're not broken, they are a reasonable range. Just not what the TV can actually do.
PPS: When I say it doesn't advertise it: There is a flag to say if it supports "continuous frequency" or not. And it ain't set.
I found this EDID decoder software in C that can display human readable EDID data, how good/accurate it is I'm not sure, but I extracted my own plasma TV EDID string after plugging it into my Mac and extracting the data. I've attached the source code for this program, you need to compile it then feed it the EDID hex string as file data.
Once the monitor was connected, on my MAC I first extracted the EDID hex data string using this command, but I am not sure what command Windows/Linux would have to get it. ioreg -l | grep -5 IODisplayEDID
Here's what it output... RLs-MacBook-Pro:edid roger$ ./edid-decode plasma.edid
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 1e 6d 01 00 01 01 01 01 01 15
version: 01 03
basic params: 80 10 09 78 0a
chroma info: ee 91 a3 54 4c 99 26 0f 50 54
established: a1 08 00
standard: 71 4f 81 80 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 a0 5a 00 00 00 1e
descriptor 2: 1b 21 50 a0 51 00 1e 30 48 88 35 00 a0 5a 00 00 00 1c
descriptor 3: 00 00 00 fd 00 3a 3e 1e 53 10 00 0a 20 20 20 20 20 20
descriptor 4: 00 00 00 fc 00 4c 47 20 54 56 0a 20 20 20 20 20 20 20
extensions: 01
checksum: e2
EDID version: 1.3
Manufacturer: GSM Model 1 Serial Number 16843009
Made in week 1 of 2011
Digital display
Maximum image size: 16 cm x 9 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6396, 0.3300
Green: 0.2998, 0.5996
Blue: 0.1503, 0.0595
White: 0.3125, 0.3291
Established timings supported:
720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
Standard timings supported:
1152x864@75Hz 4:3 HorFreq: 67500 Hz Clock: 108.000 MHz
1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 67500 Hz
Detailed mode: Clock 84.750 MHz, 160 mm x 90 mm
1360 1432 1568 1776 hborder 0
768 771 776 798 vborder 0
-hsync +vsync
VertFreq: 59 Hz, HorFreq: 47719 Hz
Monitor ranges (GTF): 58-62Hz V, 30-83kHz H, max dotclock 160MHz
Monitor name: LG TV
Has 1 extension blocks
Checksum: 0xe2 (valid)
CTA extension block
Extension version: 3
51 bytes of CTA data
Video data block
VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz
VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz
VIC 4 1280x720@60Hz 16:9 (native) HorFreq: 45000 Hz Clock: 74.250 MHz
VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz
VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz
VIC 33 1920x1080@25Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 34 1920x1080@30Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Audio data block
AC-3, max channels 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 640 kHz
Linear PCM, max channels 2
Supported sample rates (kHz): 192 96 48 44.1 32
Supported sample sizes (bits): 24 20 16
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 1.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 225MHz
Extended HDMI video details:
3D present
3D-capable-VIC mask present
3D: Side-by-side (half, horizontal)
3D: Top-and-bottom
3D VIC indices: 2 3 4 5 9 11
VIC index 0 supports side-by-side (half, horizontal)
VIC index 1 supports side-by-side (half, horizontal)
VIC index 9 supports side-by-side (half, horizontal)
VIC index 5 supports side-by-side (half, horizontal)
VIC index 3 supports side-by-side (half, horizontal)
Extended tag: Colorimetry data block
xvYCC601
xvYCC709
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm
1920 2008 2052 2200 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 60 Hz, HorFreq: 33750 Hz
Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm
1280 1390 1430 1650 hborder 0
720 725 730 750 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 45000 Hz
Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 67500 Hz
Checksum: 0x31 (valid)
One or more of the timings is out of range of the Monitor Ranges:
Vertical Freq: 24 - 75 Hz
Horizontal Freq: 15625 - 67500 Hz
Maximum Clock: 148.500 MHz
Ya, 160 mm x 90 mm is the sort of rubbish I'm seeing here too. And 58-62 Vfreq! That's stupid small range. I bet it's completely wrong and the monitor your TV can actually do a wide range.
Oh, and the very end has a different set of limits:
@rogloh said:
I found this EDID decoder software in C that can display human readable EDID data, how good/accurate it is I'm not sure, but I extracted my own plasma TV EDID string after plugging it into my Mac and extracting the data. I've attached the source code for this program, you need to compile it then feed it the EDID hex string as file data.
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 36 83 01 ee 01 01 01 01 01 14
version: 01 03
basic params: 80 a0 5a 78 0a
chroma info: 0d c9 a0 57 47 98 27 12 48 4c
established: 21 08 00
standard: 81 80 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 40 84 63 00 00 1e
descriptor 2: 01 1d 00 72 51 d0 1e 20 6e 28 55 00 40 84 63 00 00 1e
descriptor 3: 00 00 00 fc 00 54 56 0a 20 20 20 20 20 20 20 20 20 20
descriptor 4: 00 00 00 fd 00 30 3e 0e 46 0f 00 0a 20 20 20 20 20 20
extensions: 01
checksum: f4
EDID version: 1.3
Manufacturer: MTC Model ee01 Serial Number 16843009
Made in week 1 of 2010
Digital display
Maximum image size: 160 cm x 90 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6250, 0.3398
Green: 0.2802, 0.5947
Blue: 0.1552, 0.0703
White: 0.2832, 0.2978
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
Standard timings supported:
1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 67500 Hz
Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
1280 1390 1430 1650 hborder 0
720 725 730 750 vborder 0
+hsync +vsync
VertFreq: 60 Hz, HorFreq: 45000 Hz
Monitor name: TV
Monitor ranges (GTF): 48-62Hz V, 14-70kHz H, max dotclock 150MHz
Has 1 extension blocks
Checksum: 0xf4 (valid)
CTA extension block
Extension version: 3
40 bytes of CTA data
Video data block
VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz
VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz
VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz
VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz
VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz
VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz
VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 17 720x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 27.000 MHz
VIC 22 1440x576i@50Hz 16:9 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz
VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz
VIC 7 1440x480i@60Hz 16:9 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 6 1440x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 27.000 MHz
VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz
Audio data block
Linear PCM, max channels 2
Supported sample rates (kHz): 48 44.1 32
Supported sample sizes (bits): 24 20 16
AC-3, max channels 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 640 kHz
Speaker allocation data block
Speaker map:
FL/FR - Front Left/Right
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 1.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 225MHz
Extended tag: Video capability data block
YCbCr quantization: No Data (0)
RGB quantization: Selectable (via AVI Q) (1)
PT scan behaviour: Support both over- and underscan (3)
IT scan behaviour: Always Underscanned (2)
CE scan behaviour: Support both over- and underscan (3)
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
0 native detailed modes
Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm
1920 2448 2492 2640 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
VertFreq: 50 Hz, HorFreq: 56250 Hz
Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
1280 1720 1760 1980 hborder 0
720 725 730 750 vborder 0
+hsync +vsync
VertFreq: 50 Hz, HorFreq: 37500 Hz
Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
1920 2008 2052 2200 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 60 Hz, HorFreq: 33750 Hz
Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm
1920 2448 2492 2640 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
VertFreq: 50 Hz, HorFreq: 28125 Hz
Checksum: 0x1d (valid)
One or more of the timings is out of range of the Monitor Ranges:
Vertical Freq: 24 - 60 Hz
Horizontal Freq: 15625 - 67500 Hz
Maximum Clock: 148.500 MHz
Different to what I found in the EDID but still wrong:
One or more of the timings is out of range of the Monitor Ranges:
Vertical Freq: 24 - 60 Hz
Horizontal Freq: 15625 - 67500 Hz
Maximum Clock: 148.500 MHz
Oh, I wonder if that's the spread of ranges found in the various fixed modes. And it's reporting the spread as not fitting the spec'd limits. That would add up.
EDIT: Yep, that's exactly it. It is comparing against the parameters found from an $FD tagged "Range Limits" descriptor block.
Yeah, the limits in the EDID may not actually mean anything. The detailed resolutions are totally good to use as-is though. That's what PCs do (and you can force graphics cards to emit many wonderful custom modes like 720x540@160Hz by overriding EDID data in the registry)
Obviously the common modes work. Don't need any data to tell me that. If the displays aren't going to be accurate about reporting their limits then EDID isn't of much value.
@rogloh said:
My driver can go up to 1920x1200 at 60Hz with VGA. It works on my Dell monitor at native resolution, but it needs a specific timing setup to sync right, only possible once I obtained it for that model from somewhere online.
Is that a 2410F or some other model? What is your sysclock for that? How much time in % do you have per line and per flyback( I'm not sure what it is called on an LCD)
No it's a 2405FPW LCD model. I used 308MHz sysclock. Here's the timing I have for 1920x1200. Blanking interval is 160/(160+1920) or ~7.7% per scanline and 35/(1200+35) or ~2.8% per frame.
wuxga_timing ' experimental 1920x1200@60Hz for Dell 2405FPW at 77*4 MHz YMMV
long CLK308MHz
long 308000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | (80<<8 ) |(1920/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_NEG<<31) | ( 3<<23) | ( 6<<20) | ( 26<<11) | 1200
long 2<<8
long 0
long 0 ' reserved for CFRQ parameter
I also found a timing online that works cleanly at 1920x1080 @ 60Hz on this monitor too without pixel stretching or resampling. This is at a lower 277MHz sysclock.
customtiming
long 0 ‘ automatically setup clock
long 277000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (vid.SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | ( 80 <<8 ) |(1920/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 8 bit 8 bits 3 bits 9 bits 11 bits
long (vid.SYNC_NEG<<31) | ( 3<<23) | ( 5<<20) | ( 23<<11) | 1080
long 2<<8
'_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi
' 8 bits 8 bits 8 bits 4 bits 4 bits
long 0
long 0 ‘ reserved for CFRQ parameter
Roger,
Time to clean up that structure:
- As you know, I'm keen on the modeline timings becoming 16-bit per timing component.
- The system clock mode value can be ditched completely now you've got the auto-generate code.
- I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.
To complicate things with how the driver starts up, as I've recently discovered, the SETXFRQ concern doesn't apply to DVI/HDMI at all. Apart from the obvious fixed sysclock/10, the dot clock frequency isn't strongly specified to each video mode because the video resolution and dot clock don't have to be guessed at by the monitor/TV. The digital link naturally conveys these parameters exactly. As such, refresh rates and blankings can be wide ranging and thereby have no need for specific mode clock rates. So, setup approach becomes quite different.
PS: To sum up: In both approaches, sysclock frequency is not specified by the video mode. Well, there is a minimum of 250 MHz for digital links but that's not a video mode limit. And I think it'd be ill advised to go smaller than sysclock/2 in any mode.
@evanh said:
- I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.
What I'd like to do is have a specified refresh rate in the structure instead of the usual pixel rate. Then derive the pixel rate. A lot less divides this way.
@evanh said:
Roger,
Time to clean up that structure:
- As you know, I'm keen on the modeline timings becoming 16-bit per timing component.
- The system clock mode value can be ditched completely now you've got the auto-generate code.
- I'm also thinking the clock frequency should be removed too. Set it separately and then read clkfreq global in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.
To complicate things with how the driver starts up, as I've recently discovered, the SETXFRQ concern doesn't apply to DVI/HDMI at all. Apart from the obvious fixed sysclock/10, the dot clock frequency isn't strongly specified to each video mode because the video resolution and dot clock don't have to be guessed at by the monitor/TV. The digital link naturally conveys these parameters exactly. As such, refresh rates and blankings can be wide ranging and thereby have no need for specific mode clock rates. So, setup approach becomes quite different.
PS: To sum up: In both approaches, sysclock frequency is not specified by the video mode. Well, there is a minimum of 250 MHz for digital links but that's not a video mode limit. And I think it'd be ill advised to go smaller than sysclock/2 in any mode.
I'll have think about your suggestions as it's a lot of work to go change all this and test etc, and it affects every different output type as well. How big is this new timing structure going to be and how flexible is it? Do you have a proposed structure to show?
We could remove the PLL clock mode parameter but I believe I've used the clock frequency of a video mode before I switch into it so it can control other things like memory driver timing etc. The PLL clock mode parameter is already optional but could be handy to have around if you need to finely manage it yourself for some reason. For the P2 beginners it is also handy to have the driver automatically setup the PLL in the stock video modes because you then don't need to worry about setting all this up in advance. Timing already gets complex enough.
@evanh said:
What I'd like to do is have a specified refresh rate in the structure instead of the usual pixel rate. Then derive the pixel rate. A lot less divides this way.
Maybe we just need a tool that can take the refresh rate and auto generate the timing structure from that. I do already have an API that can customize a timing structure from some parameters. Maybe refresh rate could be another input, or just create another API to build the structure based on desired refresh rate and resolution... that might be better really.
@rogloh said:
How big is this new timing structure going to be and how flexible is it? Do you have a proposed structure to show?
Nothing special. Just the simple parts I've listed.
word 60 ' Vertical Frequency (Refresh Rate)
word 1200 ' Vertical Visible
word 3 ' Vertical Front Porch
word (vid.SYNC_NEG<<15) | 6 'bit15 is VSync Polarity, [14:0] is VSync Width
word 26 ' Vertical Back Porch
word 1920 ' Horizontal Visible
word 48 ' Horizontal Front Porch
word (vid.SYNC_POS<<15) | 32 'bit15 is HSync Polarity, [14:0] is HSync Width
word 80 ' Horizontal Back Porch
@rogloh said:
Maybe we just need a tool that can take the refresh rate and auto generate the timing structure from that. I do already have an API that can customize a timing structure from some parameters. Maybe refresh rate could be another input, or just create another API to build the structure based on desired refresh rate and resolution... that might be better really.
The driver is already doing that in various ways. This structure is only used for passing parameters. It's not stored in the active display cogRAM. For example, each needed streamer component is picked from the structure and embedded into its relevant mode words.
The interfacing spin code in the driver for embedding all those values can all be bolstered to perform different/alternative calculations.
Only a single divide! Pixel frequency would need to be capped to half of sysclock frequency. It's up to the user to make that fit.
EDIT: I guess it's only one divide when using preset timings anyway. Where it does make a difference is when dynamically calculating the blanking times from a smaller set of parameters.
My old DVI monitor is funny when DVI linked. It is sort of fixated with supporting the old PC graphics modes. As in it doesn't like accepting much other than them. But it doesn't have any need of the old VGA timings for those modes so as long as the vfreq and resolution matches, then it'll display the image.
Completely different story when plugged in with an analogue VGA cable though. Excepting the sync positions, deviate a few percent from the known timings and all bets are off.
Ah, got it. With DVI link, excepting the old PC modes, max v-blanking is only 35 lines! That sucks. And h-res has to be in multiples of 16, but this is no issue. And, excepting the old PC modes again, an arbitrary minimum resolution of 450x450, I think, too. Practical min resolution with flexible timings is 464x450.
So, it's not too fussy about the resolutions but is very fussy about v-blanking. That explains why, previously, the higher resolution modes all worked - because they generally defaulted to tight blankings. At least h-blanking seems to be more forgiving.
Comments
Okay, this will be it. I can see you've reordered the hsync XCONTs. For something called "breezeway" by the looks. At least that's a why.
Oh, for some reason you've moved
outside the
hsyncsubroutine. So not all hblanking calls will start with a front porch.Probably some sort of optimization, to buy time or more cycles for the mouse sprite or to save instruction space etc...
I've moved that instruction, from where it was, back into the
hsyncsubroutine and it's fixed the issue.hsync xcont m_bs, hsync0 'generate horizontal FP blanking xzero m_sn, hsync1 'generate the sync pulse wrlong status, statusaddr 'update the sync status per line dobreeze xcont m_br, hsync0 'do breezeway before colour burst setcq cq 'reapply CQ for PAL colour changes doburst xcont m_cb, colourburst 'do the PAL/NTSC colour burst flipref xor cq, palflipcq 'toggle PAL colour output per scanline bp _ret_ xcont m_bv, hsync0 'generate the back porchHoly cow! E-EDID is ghastly! ... It looks like what I'm after is called DisplayID. I'm guessing it was introduced alongside DisplayPort. It details supporting of VRR features.
That's the weirdest resolution. 1366 doesn't divide by 8. Now you've pointed it out I see that my Dick Smith TV is also spec'd exactly the same native resolution ... and neither driver works ... okay, Eric's one simply can't do exactly that resolution since it's locked to multiples of 8. Your one just stops displaying anything above 1360 horizontal ...
EDIT: Correction, Eric's driver needs multiples of 16 to behave. ie: An even number of columns ... Been all the way up to 1600x900 with this driver - 370 MHz sysclock, 24 Hz refresh.
Your driver also rounds to multiples of 8, and also has a character column glitch with odd number of columns ... and still no picture above 1360 ... the TV reports no mode detected, nor invalid, but also not auto-power-down.
EDIT2: LOL, guess what? Putting that damn front porch XCONT back where you had it fixes the hi-res limitation. Must just be a coincidence it hit right on the 1366 point.
My driver can go up to 1920x1200 at 60Hz with VGA. It works on my Dell monitor at native resolution, but it needs a specific timing setup to sync right, only possible once I obtained it for that model from somewhere online.
I'll probably have to look into this xcont moving thing at somet point if you think it is a bug and causes sync issues, can't say I was really paying a lot of attention at 1.45am to what you were saying.
Update: I think the Pioneer can accept both 1360 and 1368 pixel widths as well, IIRC.
Huh, you know you can free up a lump of cogRAM in your driver. Those two "interlaced" sync overlays are sitting in the initial ORG 0 section. They should really have their own ORGs.
EDIT: Oh, nevermind. I see that space is the font cache.
I can get the prop2 DVI output doing 1920x1200
But at only 15 Hz refresh. TV not happy. 
Best I can get displayed is 1920x768@24. Of course, with the native LCD res being lower, not all pixels are there anyway.
EDIT: Actually, with a 16:9 aspect display, a 2:1 resolution looks nice. So something like 800x400 or 1024x512 or 1280x640 ... Hehe, I guess that means an 8x16 font still isn't tall enough when pixels are square.
In my wandering about looking up EDID programming, I came across the odd disparaging comments like display drivers don't bother with much beyond the basics ...
Well, having now decoded the data stored in my TV, I'm not surprised that drivers don't use much info from the devices. It just reads like a fixed set for the whole product range! There's no specifics that are correct for the model.
The only info probably correct is the EDID supported standard and year of firmware revision.
EDIT: I guess PC monitors will be better. After all, EDID was always a PC thing from the outset.
The annoying part is my TV is really flexible timings wise. It just doesn't advertise it .... the craziest part is it even has an FD tagged "Range Limits" descriptor block defined. But the parameters are just not anything like reality. PS: They're not broken, they are a reasonable range. Just not what the TV can actually do.
PPS: When I say it doesn't advertise it: There is a flag to say if it supports "continuous frequency" or not. And it ain't set.
I found this EDID decoder software in C that can display human readable EDID data, how good/accurate it is I'm not sure, but I extracted my own plasma TV EDID string after plugging it into my Mac and extracting the data. I've attached the source code for this program, you need to compile it then feed it the EDID hex string as file data.
Once the monitor was connected, on my MAC I first extracted the EDID hex data string using this command, but I am not sure what command Windows/Linux would have to get it.
ioreg -l | grep -5 IODisplayEDIDHere's what it output...
RLs-MacBook-Pro:edid roger$ ./edid-decode plasma.edidExtracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 1e 6d 01 00 01 01 01 01 01 15 version: 01 03 basic params: 80 10 09 78 0a chroma info: ee 91 a3 54 4c 99 26 0f 50 54 established: a1 08 00 standard: 71 4f 81 80 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 a0 5a 00 00 00 1e descriptor 2: 1b 21 50 a0 51 00 1e 30 48 88 35 00 a0 5a 00 00 00 1c descriptor 3: 00 00 00 fd 00 3a 3e 1e 53 10 00 0a 20 20 20 20 20 20 descriptor 4: 00 00 00 fc 00 4c 47 20 54 56 0a 20 20 20 20 20 20 20 extensions: 01 checksum: e2 EDID version: 1.3 Manufacturer: GSM Model 1 Serial Number 16843009 Made in week 1 of 2011 Digital display Maximum image size: 16 cm x 9 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6396, 0.3300 Green: 0.2998, 0.5996 Blue: 0.1503, 0.0595 White: 0.3125, 0.3291 Established timings supported: 720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz Standard timings supported: 1152x864@75Hz 4:3 HorFreq: 67500 Hz Clock: 108.000 MHz 1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 67500 Hz Detailed mode: Clock 84.750 MHz, 160 mm x 90 mm 1360 1432 1568 1776 hborder 0 768 771 776 798 vborder 0 -hsync +vsync VertFreq: 59 Hz, HorFreq: 47719 Hz Monitor ranges (GTF): 58-62Hz V, 30-83kHz H, max dotclock 160MHz Monitor name: LG TV Has 1 extension blocks Checksum: 0xe2 (valid) CTA extension block Extension version: 3 51 bytes of CTA data Video data block VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz VIC 4 1280x720@60Hz 16:9 (native) HorFreq: 45000 Hz Clock: 74.250 MHz VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz VIC 33 1920x1080@25Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz VIC 34 1920x1080@30Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz Audio data block AC-3, max channels 6 Supported sample rates (kHz): 48 44.1 32 Maximum bit rate: 640 kHz Linear PCM, max channels 2 Supported sample rates (kHz): 192 96 48 44.1 32 Supported sample sizes (bits): 24 20 16 Vendor-specific data block, OUI 000c03 (HDMI) Source physical address 1.0.0.0 Supports_AI DC_36bit DC_30bit DC_Y444 Maximum TMDS clock: 225MHz Extended HDMI video details: 3D present 3D-capable-VIC mask present 3D: Side-by-side (half, horizontal) 3D: Top-and-bottom 3D VIC indices: 2 3 4 5 9 11 VIC index 0 supports side-by-side (half, horizontal) VIC index 1 supports side-by-side (half, horizontal) VIC index 9 supports side-by-side (half, horizontal) VIC index 5 supports side-by-side (half, horizontal) VIC index 3 supports side-by-side (half, horizontal) Extended tag: Colorimetry data block xvYCC601 xvYCC709 Underscans PC formats by default Basic audio support Supports YCbCr 4:4:4 Supports YCbCr 4:2:2 1 native detailed modes Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm 1920 2008 2052 2200 hborder 0 540 542 547 562 vborder 0 +hsync +vsync interlaced VertFreq: 60 Hz, HorFreq: 33750 Hz Detailed mode: Clock 74.250 MHz, 160 mm x 90 mm 1280 1390 1430 1650 hborder 0 720 725 730 750 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 45000 Hz Detailed mode: Clock 148.500 MHz, 160 mm x 90 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 67500 Hz Checksum: 0x31 (valid) One or more of the timings is out of range of the Monitor Ranges: Vertical Freq: 24 - 75 Hz Horizontal Freq: 15625 - 67500 Hz Maximum Clock: 148.500 MHzYa,
160 mm x 90 mmis the sort of rubbish I'm seeing here too. And 58-62 Vfreq! That's stupid small range. I bet it's completely wrong and the monitor your TV can actually do a wide range.Oh, and the very end has a different set of limits:
That looks much more reasonable. I wonder how it found those.
Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 36 83 01 ee 01 01 01 01 01 14 version: 01 03 basic params: 80 a0 5a 78 0a chroma info: 0d c9 a0 57 47 98 27 12 48 4c established: 21 08 00 standard: 81 80 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 40 84 63 00 00 1e descriptor 2: 01 1d 00 72 51 d0 1e 20 6e 28 55 00 40 84 63 00 00 1e descriptor 3: 00 00 00 fc 00 54 56 0a 20 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fd 00 30 3e 0e 46 0f 00 0a 20 20 20 20 20 20 extensions: 01 checksum: f4 EDID version: 1.3 Manufacturer: MTC Model ee01 Serial Number 16843009 Made in week 1 of 2010 Digital display Maximum image size: 160 cm x 90 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6250, 0.3398 Green: 0.2802, 0.5947 Blue: 0.1552, 0.0703 White: 0.2832, 0.2978 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz Standard timings supported: 1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 67500 Hz Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm 1280 1390 1430 1650 hborder 0 720 725 730 750 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 45000 Hz Monitor name: TV Monitor ranges (GTF): 48-62Hz V, 14-70kHz H, max dotclock 150MHz Has 1 extension blocks Checksum: 0xf4 (valid) CTA extension block Extension version: 3 40 bytes of CTA data Video data block VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz VIC 20 1920x1080i@50Hz 16:9 HorFreq: 28125 Hz Clock: 74.250 MHz VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz VIC 19 1280x720@50Hz 16:9 HorFreq: 37500 Hz Clock: 74.250 MHz VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz VIC 18 720x576@50Hz 16:9 HorFreq: 31250 Hz Clock: 27.000 MHz VIC 17 720x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 27.000 MHz VIC 22 1440x576i@50Hz 16:9 HorFreq: 15625 Hz Clock: 27.000 MHz VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz VIC 3 720x480@60Hz 16:9 HorFreq: 31469 Hz Clock: 27.000 MHz VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz VIC 7 1440x480i@60Hz 16:9 HorFreq: 15734 Hz Clock: 27.000 MHz VIC 6 1440x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 27.000 MHz VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz VIC 32 1920x1080@24Hz 16:9 HorFreq: 27000 Hz Clock: 74.250 MHz Audio data block Linear PCM, max channels 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 AC-3, max channels 6 Supported sample rates (kHz): 48 44.1 32 Maximum bit rate: 640 kHz Speaker allocation data block Speaker map: FL/FR - Front Left/Right Vendor-specific data block, OUI 000c03 (HDMI) Source physical address 1.0.0.0 Supports_AI DC_36bit DC_30bit DC_Y444 Maximum TMDS clock: 225MHz Extended tag: Video capability data block YCbCr quantization: No Data (0) RGB quantization: Selectable (via AVI Q) (1) PT scan behaviour: Support both over- and underscan (3) IT scan behaviour: Always Underscanned (2) CE scan behaviour: Support both over- and underscan (3) Underscans PC formats by default Basic audio support Supports YCbCr 4:4:4 Supports YCbCr 4:2:2 0 native detailed modes Detailed mode: Clock 148.500 MHz, 1600 mm x 900 mm 1920 2448 2492 2640 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync VertFreq: 50 Hz, HorFreq: 56250 Hz Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm 1280 1720 1760 1980 hborder 0 720 725 730 750 vborder 0 +hsync +vsync VertFreq: 50 Hz, HorFreq: 37500 Hz Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm 1920 2008 2052 2200 hborder 0 540 542 547 562 vborder 0 +hsync +vsync interlaced VertFreq: 60 Hz, HorFreq: 33750 Hz Detailed mode: Clock 74.250 MHz, 1600 mm x 900 mm 1920 2448 2492 2640 hborder 0 540 542 547 562 vborder 0 +hsync +vsync interlaced VertFreq: 50 Hz, HorFreq: 28125 Hz Checksum: 0x1d (valid) One or more of the timings is out of range of the Monitor Ranges: Vertical Freq: 24 - 60 Hz Horizontal Freq: 15625 - 67500 Hz Maximum Clock: 148.500 MHzDifferent to what I found in the EDID but still wrong:
Max Vfreq is 75 Hz in reality.
Oh, I wonder if that's the spread of ranges found in the various fixed modes. And it's reporting the spread as not fitting the spec'd limits. That would add up.
EDIT: Yep, that's exactly it. It is comparing against the parameters found from an $FD tagged "Range Limits" descriptor block.
So EDID is a write-off. ... or, I suppose EDID could be treated as a safe starting point. Like a recommended range.
Yeah, the limits in the EDID may not actually mean anything. The detailed resolutions are totally good to use as-is though. That's what PCs do (and you can force graphics cards to emit many wonderful custom modes like 720x540@160Hz by overriding EDID data in the registry)
Obviously the common modes work. Don't need any data to tell me that. If the displays aren't going to be accurate about reporting their limits then EDID isn't of much value.
EDID: Everyone Does It Differently.
Sorry. I’ll see myself out…
I need a silly giggle after that.
Is that a 2410F or some other model? What is your sysclock for that? How much time in % do you have per line and per flyback( I'm not sure what it is called on an LCD)
No it's a 2405FPW LCD model. I used 308MHz sysclock. Here's the timing I have for 1920x1200. Blanking interval is 160/(160+1920) or ~7.7% per scanline and 35/(1200+35) or ~2.8% per frame.
wuxga_timing ' experimental 1920x1200@60Hz for Dell 2405FPW at 77*4 MHz YMMV long CLK308MHz long 308000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | (80<<8 ) |(1920/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_NEG<<31) | ( 3<<23) | ( 6<<20) | ( 26<<11) | 1200 long 2<<8 long 0 long 0 ' reserved for CFRQ parameterI also found a timing online that works cleanly at 1920x1080 @ 60Hz on this monitor too without pixel stretching or resampling. This is at a lower 277MHz sysclock.
customtiming long 0 ‘ automatically setup clock long 277000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (vid.SYNC_POS<<31) | ( 48<<24) | ( 32<<16) | ( 80 <<8 ) |(1920/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 8 bit 8 bits 3 bits 9 bits 11 bits long (vid.SYNC_NEG<<31) | ( 3<<23) | ( 5<<20) | ( 23<<11) | 1080 long 2<<8 '_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi ' 8 bits 8 bits 8 bits 4 bits 4 bits long 0 long 0 ‘ reserved for CFRQ parameterRoger,
Time to clean up that structure:
- As you know, I'm keen on the modeline timings becoming 16-bit per timing component.
- The system clock mode value can be ditched completely now you've got the auto-generate code.
- I'm also thinking the clock frequency should be removed too. Set it separately and then read
clkfreqglobal in the driver. The only wobbly part about this is how to determine an appropriate SETXFRQ value for analogue video ports. Eric's driver relies on always having a layer of code like his text mode setup code to generate this for the driver.To complicate things with how the driver starts up, as I've recently discovered, the SETXFRQ concern doesn't apply to DVI/HDMI at all. Apart from the obvious fixed sysclock/10, the dot clock frequency isn't strongly specified to each video mode because the video resolution and dot clock don't have to be guessed at by the monitor/TV. The digital link naturally conveys these parameters exactly. As such, refresh rates and blankings can be wide ranging and thereby have no need for specific mode clock rates. So, setup approach becomes quite different.
PS: To sum up: In both approaches, sysclock frequency is not specified by the video mode. Well, there is a minimum of 250 MHz for digital links but that's not a video mode limit. And I think it'd be ill advised to go smaller than sysclock/2 in any mode.
What I'd like to do is have a specified refresh rate in the structure instead of the usual pixel rate. Then derive the pixel rate. A lot less divides this way.
I'll have think about your suggestions as it's a lot of work to go change all this and test etc, and it affects every different output type as well. How big is this new timing structure going to be and how flexible is it? Do you have a proposed structure to show?
We could remove the PLL clock mode parameter but I believe I've used the clock frequency of a video mode before I switch into it so it can control other things like memory driver timing etc. The PLL clock mode parameter is already optional but could be handy to have around if you need to finely manage it yourself for some reason. For the P2 beginners it is also handy to have the driver automatically setup the PLL in the stock video modes because you then don't need to worry about setting all this up in advance. Timing already gets complex enough.
Maybe we just need a tool that can take the refresh rate and auto generate the timing structure from that. I do already have an API that can customize a timing structure from some parameters. Maybe refresh rate could be another input, or just create another API to build the structure based on desired refresh rate and resolution... that might be better really.
Nothing special. Just the simple parts I've listed.
word 60 ' Vertical Frequency (Refresh Rate) word 1200 ' Vertical Visible word 3 ' Vertical Front Porch word (vid.SYNC_NEG<<15) | 6 'bit15 is VSync Polarity, [14:0] is VSync Width word 26 ' Vertical Back Porch word 1920 ' Horizontal Visible word 48 ' Horizontal Front Porch word (vid.SYNC_POS<<15) | 32 'bit15 is HSync Polarity, [14:0] is HSync Width word 80 ' Horizontal Back PorchThe driver is already doing that in various ways. This structure is only used for passing parameters. It's not stored in the active display cogRAM. For example, each needed streamer component is picked from the structure and embedded into its relevant mode words.
The interfacing spin code in the driver for embedding all those values can all be bolstered to perform different/alternative calculations.
vtot = vvis + vfp + vs + vbp
htot = hvis + hfp + hs + hbp
pixelfreq = vfreq * vtot * htot
SETXFRQ divider = $8000_0000 * pixelfreq / clkfreq
Only a single divide! Pixel frequency would need to be capped to half of sysclock frequency. It's up to the user to make that fit.
EDIT: I guess it's only one divide when using preset timings anyway. Where it does make a difference is when dynamically calculating the blanking times from a smaller set of parameters.
My old DVI monitor is funny when DVI linked. It is sort of fixated with supporting the old PC graphics modes. As in it doesn't like accepting much other than them. But it doesn't have any need of the old VGA timings for those modes so as long as the vfreq and resolution matches, then it'll display the image.
Completely different story when plugged in with an analogue VGA cable though. Excepting the sync positions, deviate a few percent from the known timings and all bets are off.
Ah, got it. With DVI link, excepting the old PC modes, max v-blanking is only 35 lines! That sucks. And h-res has to be in multiples of 16, but this is no issue. And, excepting the old PC modes again, an arbitrary minimum resolution of 450x450, I think, too. Practical min resolution with flexible timings is 464x450.
So, it's not too fussy about the resolutions but is very fussy about v-blanking. That explains why, previously, the higher resolution modes all worked - because they generally defaulted to tight blankings. At least h-blanking seems to be more forgiving.
Pity these limits aren't being specified in EDID.