@rogloh said:
So really, you have several options here...
Ow, sorry, that was a big write up. I think I've got over my frustration. Realising that some modes are best left fixed. Too many uncooperative old monitors out there.
None of these options require you to change or add any timing structures in the driver which it seems you were doing.
I'm working with existing the text demo code. Way too hard to work out to use the driver from scratch.
As to why there are different names in the text driver vs lower level video driver, I am actually hoping to combine them to use the same set of regular names like (VGA,SVGA,XGA,WXGA,UXGA) in the next release. I just need to modify one of the VGA constants for the output type to RGB instead of VGA to avoid namespace collisions.
I am also thinking of allowing these names to be passed into the timing value for initDisplay() and my code would detect them to avoid needing to use RES_640x480 etc. I could do this if some upper bits were used to indicate the constant vs the address. This would eliminate the need to call getTiming(RES_800x600) etc (as done in case 1 above), and you could just do this which I think is probably the simplest it can be while remaining generic enough to cover all options needed:
Here's the new function in the driver I'm now using when DVI_VIDEO_TYPE = 1 in the text demo program. It sits right below the createCustomTiming() function in p2videodrv.spin2. Sharing the description of timing structure.
@evanh said:
First limit I hit is the timing structure has a limit of
9 bits for vertical back porch. Modern monitors can handle far greater vblank now.
Interesting you've hit that limit. So far I've been able to get by with the ranges supported. I think I might be able to extend the 5th long to allow extended VBP's to be specified when they exceed 9 bits. I'd probably overload it with breezeway and colourburst settings, given they would be exclusive groups of parameters in the different output modes.
@rogloh said:
I'd probably overload it with breezeway and colourburst settings, given they would be exclusive groups of parameters in the different output modes.
That'd be great to have 16 bits just for the back porch.
I don't know for vbp. But the vfp and vsync are already plenty big. They work fine as both small values in all modes, even the old PC modes. Moving the sync away from the bottom of the visible just shifts the picture up the screen.
EDIT: Well, maybe not the old modes. Turns out there is use for some front porch on CRT monitors. The existing 8 bits is heaps though.
Okay, I'll take that back about the front porch. Putting sync in middle of blanking is best for CRTs. DVI devices don't seem to care. I'll be using vfp from now on. Which means need same size store for both front and back porches.
EDIT: I do wonder how VRR works in detail in this respect. Does the sync get put in the middle of the blanking even then? Not really a concern here though. Just pondering.
EDIT2: Updated computeCustomDvi()
PUB computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor, vblank
{{
So there is a total of four effective parameters to build complete HDMI timings from:
1 - sysclock frequency (sysfrq)
2 - horzontal resolution (hres)
3 - vertical resolution (vres)
4 - vertical frequency (vfrq)
Remaining timings are:
dotfrq (>= 25 MHz) = sysfrq / 10
htot = hres + 80
hfp = 8
hsw = 64
hbp = 8
vtot = dotfrq / htot / vfrq
vblank = vtot - vres
vsw = 2
vfp = (vblank - vsw) / 2
vbp = vblank - vsw - vfp
}}
p2freq #>= 250_000_000 'min DVI link speed
p2freq <#= MAXVCO_HZ 'max sysclock
divisor := 10 'fixed ratio dot-clock
vfreq #>= 10 'sane minimum
hres &= $7f8 '8-bit range (x8)
vres &= $7ff '11-bit range
long[timing][0] := 0 'auto compute clock mode
long[timing][1] := p2freq
long[timing][2] := (8 & $7f) << 24 'hfp
long[timing][2] |= (64 & $ff) << 16 'hs
long[timing][2] |= (8 & $ff) << 8 'hbp
long[timing][2] |= hres >> 3
r := divisor * vfreq * (hres+80)
vblank := ((p2freq + r/2) / r - vres) #> 12 'min blanking is 12
r := (vblank - 2) >> 1
r <#= $ff 'max front porch
long[timing][3] := r << 23 'vfp
long[timing][3] |= 2 << 20 'vs
r := vblank - 2 - r
r <#= $1ff 'max back porch
long[timing][3] |= r << 11 'vbp
long[timing][3] |= vres
long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor
long[timing][5] := ((8 << 1) & $ff00)
long[timing][5] |= ((64 >> 4) & $f0)
long[timing][5] |= ((8 >> 8) & $f)
long[timing][6] := 0
'Calculate final vertical scan frequency (in tenths of hertz)
' vblank := long[timing][3].[30..23] + 2 + long[timing][3].[19..11]
' r := (hres + 80) * (vres + vblank) 'htot * vtot
' r := (p2freq + r/2) / r 'vfreq = dotfreq / (htot * vtot)
return timing
@evanh said:
Okay, I'll take that back about the front porch. Putting sync in middle of blanking is best for CRTs. DVI devices don't seem to care. I'll be using vfp from now on. Which means need same size store for both front and back porches.
I could possibly try to give 7 more bits to VBP and 9 more bits to VFP to split them evenly with 64k max lines possible in each or I could perhaps give one less bit to each (32k lines) and 2 bits more to the VSYNC (32 lines max). It still seems massive to go that big though for the porches. Maybe 12 bits each is enough.
Operating a mode right now (using a different driver): 480x270@50Hz with 350 MHz sysclock.
35 MHz / (480 + 80 = 560) = 62.5 kHz hfreq
hfreq / 50 Hz = 1250 vtot
270 / 1250 = 21.6 % is visible lines.
Might be limited to something like 1000 vblanking. The TV doesn't like it if I push further.
EDIT: vtot of 1276 is working. So maybe 1023 is max vblank.
EDIT2: BTW: That was 502-2-502. If I bias it to 1-2-1003 it still works. Which means it's the whole blanking that's important.
To keep things easy I think I could probably just allocate an extra nibble to each vertical porch allowing 13 bits 8k for VFP and 12 bits for VBP (4k). Should be heaps. Maybe no need for any more vsync bits.
I've been reading up more on VRR monitors. Turns out, as is often the case, the early cheaper models don't do a good job.
LCDs have a history of being difficult to tune the LCD's drive parameters. It affects motion blur particularly badly but also colour quality and contrast. And that's the main reason for limited refresh rates. And even to the point of not being sync'd at all. The basic panel used to be built for only one refresh rate so feeding it something else required the scan converter to desync the two sides, video input and LCD, from each other.
So the trend to allowing wider range of refreshes is producing various quality issues. Particularly with cheap VRR spec'd monitors.
What I've found out is there is an optional feature that really is needed on them all, called "Low Framerate Compensation". Here's the blurb from AMD:
Low framerate compensation (LFC), allows FreeSync technology to work when the framerate falls below the minimum refresh rate of the display. When the framerate drops below the minimum refresh rate of the display, frames are duplicated and displayed multiple times so that they can sync to a refresh rate that is within the displays refresh rate range. For example, a display with a 60 – 144Hz refresh rate, would be able to sync the frames of a game running at 40 FPS, by doubling them so that the display could sync and run at 80 Hz. A display with LFC effectively results in the removal of the minimum refresh rate boundary. All displays in the FreeSync Premium and FreeSync Premium Pro tier are certified to meet mandatory LFC requirements.
So, with LFC, aside from the gaming advantages, because the monitor can run the LCD at double/triple the refreshes of the video input, this in turn allows the LCD drive parameters to stay in a narrower working range and therefore better quality display.
@evanh said:
What I've found out is there is an optional feature that really is needed on them all, called "Low Framerate Compensation". Here's the blurb from AMD:
Low framerate compensation (LFC), allows FreeSync technology to work when the framerate falls below the minimum refresh rate of the display. When the framerate drops below the minimum refresh rate of the display, frames are duplicated and displayed multiple times so that they can sync to a refresh rate that is within the displays refresh rate range. For example, a display with a 60 – 144Hz refresh rate, would be able to sync the frames of a game running at 40 FPS, by doubling them so that the display could sync and run at 80 Hz. A display with LFC effectively results in the removal of the minimum refresh rate boundary. All displays in the FreeSync Premium and FreeSync Premium Pro tier are certified to meet mandatory LFC requirements.
So, with LFC, aside from the gaming advantages, because the monitor can run the LCD at double/triple the refreshes of the video input, this in turn allows the LCD drive parameters to stay in a narrower working range and therefore better quality display.
Interesting. They give an example of 40Hz, but I wonder how far that can be pushed ?
@jmg said:
Interesting. They give an example of 40Hz, but I wonder how far that can be pushed ?
nVidia lists down to 1 Hz for all their certified models. AMD doesn't make it clear. Probably manufacturer dependant. I would expect 1 Hz will be the default for all because nVidia appears to require that.
That's the thing, once the repeat feature (LFC) is in place, it can repeat indefinitely. Kind of like DRAM doing self refresh.
Roger,
Oh, is that what you've already done with hfp, hbp, and hsyncpixels? I note all of those are being placed in timing[5] as well as timing[2]. And the shifts being done work out for that too.
Yes any horizontal blanking and sync additional bits are already in the lower 16 bits of this timing[5] long if they need to be extended. That's already part of the existing driver.
Probably would be good to have a fan or heatsink to control the temperature rise of the module when the user code is pushing things at such limits! At least for long term use.
I was thinking of @CJMJ 3D printed module holder... maybe that could have a small fan attached to the back for overclocking experiments in a convenient form factor....
Preparing parts for the project A 3D printed holder. A heatsink
I think you would get more heat out of the chip going from the back side, but you will have to take off the conformal coating from the grid of vias.
Comments
Ow, sorry, that was a big write up. I think I've got over my frustration. Realising that some modes are best left fixed. Too many uncooperative old monitors out there.
I'm working with existing the text demo code. Way too hard to work out to use the driver from scratch.
Sounds promising. Especially since using the preset modes is going to be common practice.
Here's the new function in the driver I'm now using when DVI_VIDEO_TYPE = 1 in the text demo program. It sits right below the
createCustomTiming()function in p2videodrv.spin2. Sharing the description of timing structure.PUB computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor {{ So there is a total of four effective parameters to build complete HDMI timings from: 1 - sysclock frequency (sysfrq) 2 - horzontal resolution (hres) 3 - vertical resolution (vres) 4 - vertical frequency (vfrq) Remaining timings are: dotfrq (>= 25 MHz) = sysfrq / 10 htot = hres + 80 hfp = 8 hsw = 64 hbp = 8 vtot = dotfrq / htot / vfrq vfp = 1 vsw = 2 vbp (>= 9) = vtot - vres - 3 }} p2freq #>= 250_000_000 p2freq <#= MAXVCO_HZ divisor := 10 vfreq #>= 10 'sane minimum hres &= $7f8 '8-bit range (x8) vres &= $7ff '11-bit range long[timing][0] := 0 'auto compute clock mode long[timing][1] := p2freq long[timing][2] := (8 & $7f) << 24 'hfp long[timing][2] |= (64 & $ff) << 16 'hs long[timing][2] |= (8 & $ff) << 8 'hbp long[timing][2] |= hres >> 3 long[timing][3] := (1 & $ff) << 23 'vfp long[timing][3] |= (2 & 7) << 20 'vs r := divisor * vfreq * (hres+80) r := ((p2freq + r/2) / r - vres - 3) #> 9 r <#= $1ff long[timing][3] |= r << 11 'vbp long[timing][3] |= vres long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor long[timing][5] := ((8 << 1) & $ff00) long[timing][5] |= ((64 >> 4) & $f0) long[timing][5] |= ((8 >> 8) & $f) long[timing][6] := 0 'Calculate final vertical scan frequency (in tenths of hertz) ' r := (hres + 80) * (vres + 3 + r) 'htot * vtot ' r := (p2freq + r/2) / r 'vfreq = dotfreq / (htot * vtot) return timingLol, DVI output at 1280x1024@25Hz still using 350 MHz sysclock.
Interesting you've hit that limit. So far I've been able to get by with the ranges supported. I think I might be able to extend the 5th long to allow extended VBP's to be specified when they exceed 9 bits. I'd probably overload it with breezeway and colourburst settings, given they would be exclusive groups of parameters in the different output modes.
That'd be great to have 16 bits just for the back porch.
How many bits is realistic? I'd probably save some to potentially extend the VFP and VSYNC portions too.
I don't know for vbp. But the vfp and vsync are already plenty big. They work fine as both small values in all modes, even the old PC modes. Moving the sync away from the bottom of the visible just shifts the picture up the screen.
EDIT: Well, maybe not the old modes. Turns out there is use for some front porch on CRT monitors. The existing 8 bits is heaps though.
EDIT2: Time for some more testing ...
Okay, I'll take that back about the front porch. Putting sync in middle of blanking is best for CRTs. DVI devices don't seem to care. I'll be using vfp from now on. Which means need same size store for both front and back porches.
EDIT: I do wonder how VRR works in detail in this respect. Does the sync get put in the middle of the blanking even then? Not really a concern here though. Just pondering.
EDIT2: Updated
computeCustomDvi()PUB computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor, vblank {{ So there is a total of four effective parameters to build complete HDMI timings from: 1 - sysclock frequency (sysfrq) 2 - horzontal resolution (hres) 3 - vertical resolution (vres) 4 - vertical frequency (vfrq) Remaining timings are: dotfrq (>= 25 MHz) = sysfrq / 10 htot = hres + 80 hfp = 8 hsw = 64 hbp = 8 vtot = dotfrq / htot / vfrq vblank = vtot - vres vsw = 2 vfp = (vblank - vsw) / 2 vbp = vblank - vsw - vfp }} p2freq #>= 250_000_000 'min DVI link speed p2freq <#= MAXVCO_HZ 'max sysclock divisor := 10 'fixed ratio dot-clock vfreq #>= 10 'sane minimum hres &= $7f8 '8-bit range (x8) vres &= $7ff '11-bit range long[timing][0] := 0 'auto compute clock mode long[timing][1] := p2freq long[timing][2] := (8 & $7f) << 24 'hfp long[timing][2] |= (64 & $ff) << 16 'hs long[timing][2] |= (8 & $ff) << 8 'hbp long[timing][2] |= hres >> 3 r := divisor * vfreq * (hres+80) vblank := ((p2freq + r/2) / r - vres) #> 12 'min blanking is 12 r := (vblank - 2) >> 1 r <#= $ff 'max front porch long[timing][3] := r << 23 'vfp long[timing][3] |= 2 << 20 'vs r := vblank - 2 - r r <#= $1ff 'max back porch long[timing][3] |= r << 11 'vbp long[timing][3] |= vres long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor long[timing][5] := ((8 << 1) & $ff00) long[timing][5] |= ((64 >> 4) & $f0) long[timing][5] |= ((8 >> 8) & $f) long[timing][6] := 0 'Calculate final vertical scan frequency (in tenths of hertz) ' vblank := long[timing][3].[30..23] + 2 + long[timing][3].[19..11] ' r := (hres + 80) * (vres + vblank) 'htot * vtot ' r := (p2freq + r/2) / r 'vfreq = dotfreq / (htot * vtot) return timingI could possibly try to give 7 more bits to VBP and 9 more bits to VFP to split them evenly with 64k max lines possible in each or I could perhaps give one less bit to each (32k lines) and 2 bits more to the VSYNC (32 lines max). It still seems massive to go that big though for the porches. Maybe 12 bits each is enough.
I'd be tempted to change the driver to use the same stored value for both porches.
Operating a mode right now (using a different driver): 480x270@50Hz with 350 MHz sysclock.
35 MHz / (480 + 80 = 560) = 62.5 kHz hfreq
hfreq / 50 Hz = 1250 vtot
270 / 1250 = 21.6 % is visible lines.
Might be limited to something like 1000 vblanking. The TV doesn't like it if I push further.
EDIT: vtot of 1276 is working. So maybe 1023 is max vblank.
EDIT2: BTW: That was 502-2-502. If I bias it to 1-2-1003 it still works. Which means it's the whole blanking that's important.
I expect that VRR capable monitors will allow much higher blanking again.
To keep things easy I think I could probably just allocate an extra nibble to each vertical porch allowing 13 bits 8k for VFP and 12 bits for VBP (4k). Should be heaps. Maybe no need for any more vsync bits.
Yep. That'll do. Sounds like it helps on the code size in the driver.
I've been reading up more on VRR monitors. Turns out, as is often the case, the early cheaper models don't do a good job.
LCDs have a history of being difficult to tune the LCD's drive parameters. It affects motion blur particularly badly but also colour quality and contrast. And that's the main reason for limited refresh rates. And even to the point of not being sync'd at all. The basic panel used to be built for only one refresh rate so feeding it something else required the scan converter to desync the two sides, video input and LCD, from each other.
So the trend to allowing wider range of refreshes is producing various quality issues. Particularly with cheap VRR spec'd monitors.
What I've found out is there is an optional feature that really is needed on them all, called "Low Framerate Compensation". Here's the blurb from AMD:
So, with LFC, aside from the gaming advantages, because the monitor can run the LCD at double/triple the refreshes of the video input, this in turn allows the LCD drive parameters to stay in a narrower working range and therefore better quality display.
Interesting. They give an example of 40Hz, but I wonder how far that can be pushed ?
nVidia lists down to 1 Hz for all their certified models. AMD doesn't make it clear. Probably manufacturer dependant. I would expect 1 Hz will be the default for all because nVidia appears to require that.
That's the thing, once the repeat feature (LFC) is in place, it can repeat indefinitely. Kind of like DRAM doing self refresh.
Which is why vblank from the video card can now dynamically grow and shrink enormously.
Roger,
Oh, is that what you've already done with hfp, hbp, and hsyncpixels? I note all of those are being placed in timing[5] as well as timing[2]. And the shifts being done work out for that too.
Yes any horizontal blanking and sync additional bits are already in the lower 16 bits of this timing[5] long if they need to be extended. That's already part of the existing driver.
Where is this? I'm working from p2textdriver0.93.zip from here - https://forums.parallax.com/discussion/170676/p2-dvi-vga-driver/p1
It's from my yet to be released documentation I've been collating...
Stop cheating! :P
I think you would get more heat out of the chip going from the back side, but you will have to take off the conformal coating from the grid of vias.