Huh, okay, I've clearly been following an incorrect rule. I was puzzled why your latest adjustments worked when they were at a lower hsync frequency than I thought would work.
I've now got 960x600 using just 320 MHz sysclock. All I had to do was move the hsync to the centre of hblank. Larger or smaller makes no diff. EDIT: In fact I can now even go smaller on hblanking! Although, I'm in no rush to push that any further. EDIT2: Couldn't help meself.
_clkfreq = 320_000_000 'system clock frequency must be at least 250 MHz for DVI/HDMI
rx = 960 ' x600 'minimum hblank of 80, and hsync must be equilateral within hblank
ry = 64
ry1 = 268 ' 1920x1200
vbp = 9 ' 50.3 Hz 'minimum vblank of 12 (vblank = vfp + vp + vbp = 1 + 2 + 9)
Well, here's 640x600 on the same Dell U2412M 1920x1200 DVI monitor. The vertical is nice and sharp.
EDIT: Grr, the forum converts these images when uploaded for embedding only! ... That's better as a file for download.
@Wuerfel_21 said:
350 MHz or higher is just really glitchy/unstable IME. 320 is totally fine though.
I was playing with the ADCs the other day and found them wandering off centre when I was at 350 MHz, whereas 300 MHz stayed stable for me. Didn't try anything in between.
@Yanomani said:
I believe you can dial it down a litle bit (Sysclk). till near 308 MHz, targetting Vesa CVT reduced blaking standards.
These are very reduced already. Those minimums I've written in the comments aren't just a common tested set of rules, they're extra tight blanking times that'll only work over the digital links.
Only way to go lower on sysclock is to drop below 50 Hz vsync.
So the timing is right.
Each pixel is mapped exactly to 2x2 pixel.
What still bothers me is the non-linearity of the pixel brightness.
I will have to play around with the monitor.
Pic,
New rule as per my post #92, following your earlier example even: Make hsync symmetrically centred within hblank: Eg: I'll be using the values below as my default from now:
m_bs long $70810000 + hdmi_base<<17 + 16 'before sync
m_sn long $70810000 + hdmi_base<<17 + 48 'sync
m_bv long $70810000 + hdmi_base<<17 + 16 'before visible
EDIT: Oh, and I've decided that the minimum vblank of 8 was too low as well. Again, you'd previously adjusted the before-sync to a higher value which I assumed meant you needed more. I also found one of my displays needed eleven as well. I've upped minimum vblank to 12 now.
PS: I'd love to find an actual standard that defines these as rules rather than big lists of mode numbers.
PPS: My experience suggests TV designers completely ignore VESA, and monitor designers only partly follow where it doesn't conflict with what I assume is other standards that they're already working with. CVT, like GTF before it, has never seemed to work.
PS: I'd love to find an actual standard that defines these as rules rather than big lists of mode numbers.
PPS: My experience suggests TV designers completely ignore VESA, and monitor designers only partly follow where it doesn't conflict with what I assume is other standards that they're already working with. CVT, like GTF before it, has never seemed to work.
IMHO, it would be really hard to achieve some agreement between all players involved, otherwise, why ever would EDIDs went that big?
No one will ever want to lose a chance of advertising the most unnoticeable characteristics of their products, as the upmost groundbreaking sollution, fresh from their R&D, to any yet unknown difficulty?
"Start by convincing almost everyone they've must experiencing some problem, and offer them a marketeable sollution."
Cool, found confirmation of my understanding of Variable Refresh Rate (VRR) in one of the many extensions listed on Wikipedia:
Bit 7 Seamless dynamic video timing change:
0 = not supported
1 = supported with fixed horizontal pixel rate and dynamic vertical blanking
I'd worked out that VRR relies on fixing the pixel rate to max data rate capable of the display/cable/controller. Then simply adjusting vblank as needed on a field by field basis to match the generated frame rate.
So, using the minimum hblanking as default is a given in this scenario.
I'd already had some supporting evidence of that by the fact that: A) Displayport is a fixed rate data link and, B ) that Displayport is where VRR got started from.
@Wuerfel_21 said:
350 MHz or higher is just really glitchy/unstable IME. 320 is totally fine though.
I was playing with the ADCs the other day and found them wandering off centre when I was at 350 MHz, whereas 300 MHz stayed stable for me. Didn't try anything in between.
At ~350 MHz ADCs have "stable" and "less stable" fields: 1 MHz frequency change can give much more or much less noise. I didn't made measurements, I simply did ADC->DAC->speaker and listened to the noise.
HDMI video modes I tried at 354/357 MHz are stable.
P2 at my eval board starts to lose stability somewhere at 370 MHz and is unusable at 380 MHz. Simple programs can start at 410 MHz but this is not really 410 MHz (the test program was a sine wave generator - the audible frequency started to drop at about 400 MHz, it seems PLL gave up.
If you can, its worth hooking a frequency counter on to make sure you're getting the MHz you're asking for. I remember during temperature testing the MHz would slip away under warmer conditions
The usual case, the warmer the room temp the slower the PLL will go. And the slower the core logic will function at too. On the flip side, cooling the package raises the max frequency obtainable.
Chip intentionally re-tuned the PLL for revB to self-limit just below the crash point of the cogs. It is a borderline tuning though, anecdotal experiences say glitches or crash conditions can still occur when the PLL is limiting the sysclock frequency. Not to mention the frequency is unstable while doing that anyway.
IMHO, the subject of PLL/VCO behaviour is very addicting, full of implications, and prone to be a good source for some food for thougth.
I must confess I've been eagerly waiting for the next move any of the moderators will do, in order to follow an apparently unnoticed (yet long-missed, still) suggestion of @rogloh, the OP of "P2 DVI/VGA driver"-thread, for splitting some posts about the "PLL/VCO"-subject.:
Been working on changing the timings into the important parameters and deriving the timings from them. Here's my latest effort using Pic's HDMI code as the reference.
I guess it should be pointed out that my method assumes a digital link, DVI/HDMI. Ie: Using reduced blanking as basis of certain fixed timings.
Comments
Huh, okay, I've clearly been following an incorrect rule. I was puzzled why your latest adjustments worked when they were at a lower hsync frequency than I thought would work.
I've now got 960x600 using just 320 MHz sysclock. All I had to do was move the hsync to the centre of hblank. Larger or smaller makes no diff. EDIT: In fact I can now even go smaller on hblanking! Although, I'm in no rush to push that any further. EDIT2: Couldn't help meself.
_clkfreq = 320_000_000 'system clock frequency must be at least 250 MHz for DVI/HDMI rx = 960 ' x600 'minimum hblank of 80, and hsync must be equilateral within hblank ry = 64 ry1 = 268 ' 1920x1200 vbp = 9 ' 50.3 Hz 'minimum vblank of 12 (vblank = vfp + vp + vbp = 1 + 2 + 9)I believe you can dial it down a litle bit (Sysclk). till near 308 MHz, targetting Vesa CVT reduced blaking standards.
350 MHz or higher is just really glitchy/unstable IME. 320 is totally fine though.
Well, here's 640x600 on the same Dell U2412M 1920x1200 DVI monitor. The vertical is nice and sharp.
EDIT: Grr, the forum converts these images when uploaded for embedding only! ... That's better as a file for download.
I was playing with the ADCs the other day and found them wandering off centre when I was at 350 MHz, whereas 300 MHz stayed stable for me. Didn't try anything in between.
These are very reduced already. Those minimums I've written in the comments aren't just a common tested set of rules, they're extra tight blanking times that'll only work over the digital links.
Only way to go lower on sysclock is to drop below 50 Hz vsync.
The vertical alignment of the scaling already fits once.
All lines are always two pixels high.
So the timing is right.
Each pixel is mapped exactly to 2x2 pixel.
What still bothers me is the non-linearity of the pixel brightness.
I will have to play around with the monitor.
Pic,
New rule as per my post #92, following your earlier example even: Make hsync symmetrically centred within hblank: Eg: I'll be using the values below as my default from now:
EDIT: Oh, and I've decided that the minimum vblank of 8 was too low as well. Again, you'd previously adjusted the before-sync to a higher value which I assumed meant you needed more. I also found one of my displays needed eleven as well. I've upped minimum vblank to 12 now.
PS: I'd love to find an actual standard that defines these as rules rather than big lists of mode numbers.
PPS: My experience suggests TV designers completely ignore VESA, and monitor designers only partly follow where it doesn't conflict with what I assume is other standards that they're already working with. CVT, like GTF before it, has never seemed to work.
IMHO, it would be really hard to achieve some agreement between all players involved, otherwise, why ever would EDIDs went that big?
No one will ever want to lose a chance of advertising the most unnoticeable characteristics of their products, as the upmost groundbreaking sollution, fresh from their R&D, to any yet unknown difficulty?
"Start by convincing almost everyone they've must experiencing some problem, and offer them a marketeable sollution."
Cool, found confirmation of my understanding of Variable Refresh Rate (VRR) in one of the many extensions listed on Wikipedia:
I'd worked out that VRR relies on fixing the pixel rate to max data rate capable of the display/cable/controller. Then simply adjusting vblank as needed on a field by field basis to match the generated frame rate.
So, using the minimum hblanking as default is a given in this scenario.
I'd already had some supporting evidence of that by the fact that: A) Displayport is a fixed rate data link and, B ) that Displayport is where VRR got started from.
At ~350 MHz ADCs have "stable" and "less stable" fields: 1 MHz frequency change can give much more or much less noise. I didn't made measurements, I simply did ADC->DAC->speaker and listened to the noise.
HDMI video modes I tried at 354/357 MHz are stable.
P2 at my eval board starts to lose stability somewhere at 370 MHz and is unusable at 380 MHz. Simple programs can start at 410 MHz but this is not really 410 MHz (the test program was a sine wave generator - the audible frequency started to drop at about 400 MHz, it seems PLL gave up.
If you can, its worth hooking a frequency counter on to make sure you're getting the MHz you're asking for. I remember during temperature testing the MHz would slip away under warmer conditions
The usual case, the warmer the room temp the slower the PLL will go. And the slower the core logic will function at too. On the flip side, cooling the package raises the max frequency obtainable.
Chip intentionally re-tuned the PLL for revB to self-limit just below the crash point of the cogs. It is a borderline tuning though, anecdotal experiences say glitches or crash conditions can still occur when the PLL is limiting the sysclock frequency. Not to mention the frequency is unstable while doing that anyway.
Finding the exact timing has always been a problem, and it won't change.
It is therefore inevitable to have to adjust the values for each monitor type.
The EDIDs are only of limited help.
@evanh
I will try your values when the opportunity arises.
IMHO, the subject of PLL/VCO behaviour is very addicting, full of implications, and prone to be a good source for some food for thougth.
I must confess I've been eagerly waiting for the next move any of the moderators will do, in order to follow an apparently unnoticed (yet long-missed, still) suggestion of @rogloh, the OP of "P2 DVI/VGA driver"-thread, for splitting some posts about the "PLL/VCO"-subject.:
https://forums.parallax.com/discussion/comment/1526988/#Comment_1526988
Also reiterated by @evanh, at the "Requests for threads to be moved"-thread:
https://forums.parallax.com/discussion/comment/1527063/#Comment_1527063
and, sure, by myself, just here...
Been working on changing the timings into the important parameters and deriving the timings from them. Here's my latest effort using Pic's HDMI code as the reference.
I guess it should be pointed out that my method assumes a digital link, DVI/HDMI. Ie: Using reduced blanking as basis of certain fixed timings.
EDIT: Fixed a bug
EDIT2: small code update