In my experience, the VSync range for usual LCD monitors is 50Hz to 70 or 75Hz. High-end LCD monitors seem to top out at 240 Hz, new-ish TVs often support 24Hz and 48Hz modes, a typical SVGA CRT will take 50Hz to 160Hz (altough 50Hz is quite headache inducing....)
That's just the native LCD modes. They all support much higher vsyncs through their built-in scan converters.
That's just your OS (or graphics driver) doing the sensible thing of not listing anything greater than the native mode.
PS: Until variable refresh rate (VRR) came along for LCDs, they were all fixed frequency native. Anything other than native required the scan converter. And even with a VRR advertised badge you can't be sure it isn't just marketing and it's still just using the scan converter to lie about what the LCD can do.
It's a tall order to add VRR to LCD. They at least have a bunch of drive biasing to manage to compensate for slouchy response times. It affects colour and contrast too. To maintain that visual quality at different scan rates requires programmable controls with voltages beyond the fixed levels and ideally a formula for calculating the biases. And there's probably more to it than that.
It kind of reflects the history of CRTs before them. They too were fixed frequency for the most part until the 1990s when they started getting the user settings with an on-screen-display (OSD). This represented the amalgamation of the complex adjustments into a single mixed signal chip. Making the construction cheaper ... but presumably also locked into that architecture that has given us the 30 kHz minimum hsync.
PPS: And a conditional prediction: If OLED makes it on to cheap production lines then it will be an easy fit for VRR and should wipe out all LCD production. The scan converter drops down to only a couple of scan lines instead of being the whole display.
That's just your OS (or graphics driver) doing the sensible thing of not listing anything greater than the native mode.
On my main PC, I configure all my timings by hand (indeed because windows won't give you weird ones like 2560x960 90Hz) and anything over 75Hz on that random LCD I've got hooked up as a secondary screen won't sync.
I never heard of LCDs having a fixed refresh rate, can you give me a source on that?
On my main PC, I configure all my timings by hand (indeed because windows won't give you weird ones like 2560x960 90Hz) and anything over 75Hz on that random LCD I've got hooked up as a secondary screen won't sync.
Huh, interesting ...
I never heard of LCDs having a fixed refresh rate, can you give me a source on that?
They have a scan converter between the video in and the LCD. They've always been like that ... until very recently on the expensive gaming monitors that is. Variable refresh is a difficult thing for LCDs to handle. Fixed single frequency 75, 60 and 50 Hz were it. It is possible that dual frequency 60/75 was done for some LCDs but it's just as likely they relied on the monitor's scan converter to handle it.
Just got this driver running at 1024x600 @ 50Hz with the P2 clock at 315MHz with the following reduced blanking timing. I've seen LCD panels available in that resolution but not sure if they'd like this timing.
The 16bpp colour image I see on my monitor is looking very nice and stable. For a full frame image, it would need to be fed data at a rate of 1024 words every 33us or so, or over 61MB/s to keep up. HyperRAM could do this.
To get to 1024x768 at 50Hz would require just a tad over 400MHz so I am not game to try it.
Those blanking times are in dot clocks and scan lines, right? Reduced blanking doesn't mean almost nothing at all!
EDIT: Is that working on your monitor?
To get to 1024x768 at 50Hz would require just a tad over 400MHz so I am not game to try it.
That is too much for the revB chip. It might go with refrigeration. It would be producing a lot of heat and the die would need to be maintained below 20 degC.
Those blanking times are in dot clocks and scan lines, right? Reduced blanking doesn't mean almost nothing at all!
EDIT: Is that working on your monitor?
It is working, as I mentioned before this Dell monitor is awesome and takes about anything you throw at it unless it is below about 28kHz and 49Hz. It has a great scaler too.
Just back on the raw LCD panel thing, these don't care about vertical refresh at all, they just use a dot clock. Many of the panels don't even have a minimum frequency for how fast you advance the dot clock, but will provide a typical value eg 30 MHz. Some of them do spec a minimum dot clock frequency, for values I have seen maybe +/- 15% variation from typical seems to be the range. However I suspect even these go well below the minimum dotclock frequency
Those LCD spec allowances are for a lock range of the native mode. They certainly aren't for the purpose of making new modes from. Otherwise the monitor will fall back on something like page flipping in the scan converter. These can feel shaky when moving windows.
With this modification to use more LUT RAM I think I've removed all vestiges of the original intent for only 640/320 pixel wide displays. So now it is essentially parametrically controlled (within limits). For text I think it would need to be an even number of 8 bit columns, though I should try out an odd value to see what actually happens. It will need to be less than 128 columns which works well for up to 1024x600 which is about the limit anyway for "reasonably" overclocked P2s, but it could be setup as less than 80 columns too, opening up the possibility of narrower / taller displays.
For graphics modes I think I need to check out the various odd word and long cases now, because 720 wide displays for example do not fit nicely into 32 bit longs for all colour depths, neither does pixel doubled 800 wide graphics with 400 source pixels. Both 320/640 and 512/1024 wide is okay. I may need to have a copy routine that handles an additional 1-3 bytes of data at the end. I haven't really seen how unaligned transfers work with this driver. Perhaps a block transfer slows down significantly in that case. It's probably not ideal.
The good thing is with this change is that it frees up 50 more longs in COG RAM now. Luxury! I'll definitely have room for display regions.
Ah, true, extending the blanking is an option. You might end up with a black region at the bottom of the monitor if it thinks the mode has higher resolution than you are supplying.
Tony's prompt about using large vertical blanking times to get lower vsync rates got me thinking that maybe that's how VRR is done. Since varying the dot clock would be tough to handle.
Took a little searching to find - There sure isn't any general info about how any of them work in online articles. Anyway, here's snippet from AMD's FreeSync code for Linux:
I think that's enough to tell me that varying vtotal is a primary component of how AdaptiveSync/FreeSync control the field rate. Presumably GSync is similar. The missing info is more detailed in exactly how that is signalled to the receiving monitor.
I have added display regions to my DVI driver. Took about 19 longs but I think that is slightly bloated as there is some duplication I hope to resolve by further optimizing the sequence. You now can have multiple display regions of any size (height) in different modes being displayed on the screen.
Testing proceeds, I need to make sure the 256 entry palette can be loaded in per scanline.
The option of having multiple mice on the screen is very weird too...
I can think of applications for multiple 'cursors' - eg one example from machining is the cutting tool icon that traverses around a toolpath window as the job progresses. You still want a separate mouse cursor for pushing buttons etc, but the cutting tool icon stays in the window showing the toolpath progression. I think its a useful feature
Text cursors are straighforward, each region has two of them. The graphics mouse is different, each region gets its own mouse co-ordinate but only one mouse can be drawn in its region. You can't have different mice in the same region. It still could open up something interesting, if different COGs have different parts of the screen under independent control. There could also be a way to link these mice together into a single mouse to have it dynamically change from one region to the next as it needs to for different colour depths, but software will have to manage some of that process as the mouse co-ordinates change and it moves from one region to the next.
There could potentially be a flag in each region to indicate whether the region shares a common mouse coordinate from the previous region, or uses its own one. Still need to think about it...
Also, speaking of mice, it might be nice to have the ability for it to flash, so you could use it also to emulate a text cursor in some graphics mode, like a simple sprite with a vertical line etc. I was thinking of adding in a control to flash it but I guess you could always flip pointers from one null image (with 0 mask) to the real image to achieve it, that would save me a couple of longs, so I'll probably leave it for now.
I'd say that even the text cursors aren't that useful unless you cram an entire terminal emulation in there. Whatever code one might hook up to it to provide line editing can prob. handle the cursor itself (esp. with the flashing attribute).
The mouse pointer sprite image and mask is read in from hub RAM. You could have a series of them and flip a pointer to select which image to display in the next frame. Sprites are coded for the colour depth.
I'm thinking of posting the documentation for what I have so far to see how people react to it. It's almost done so any suggestions may not make it in, but if there are obviously worthwhile things to put in I might be able to consider it while I am still making changes.
I am looking into possible analog support right now.
I'd say that even the text cursors aren't that useful unless you cram an entire terminal emulation in there. Whatever code one might hook up to it to provide line editing can prob. handle the cursor itself (esp. with the flashing attribute).
I think having a text cursor is useful if you want to see where you are typing. Managing the flashing in the video driver automatically is helpful and stops the code having to periodically intervene to flash it manually and keep the flash rate consistent etc, though of course it is possible to do entirely in software. I support two cursors so in a text UI you might have an old school block cursor for the mouse, and an underscore type for the text entry. I made the blink phase selectable too, so one flashing cursor can be seen with another if they are at the same location.
This makes me think about having both left-handed and right-handed wireless mice. It seems like that could be a good interface for quickly manipulating some things, like machines or 3D screen content.
Ok, that makes it really easy to change the cursor shape as you're in different areas of the screen. So you can have an hourglass mouse pointer (not that we'll ever wait for anything to complete on P2... )
Last time I tried to use my left hand for moving the mouse pointer it was about as useful as working with the screen rotated 90 degrees.
A joystick in the off-hand works surprisingly well, though. Better even because that leaves your strong hand free. I remember being fasinated watching a draftsman working with high-end CAD software about 20 years back where he had this device called a "space ball" in his left hand and the mouse in his right hand. The space ball, without any buttons, provided, I think, all six degrees of camera control. Leaving the mouse for editing of the 3D structures.
I'm both left and right-handed, but I don't change button press.
I change (fingers) when using the left hand, I use long finger to left button and index finger to right button.
I'm both left and right-handed, but I don't change button press.
I change (fingers) when using the left hand, I use long finger to left button and index finger to right button.
I'm Left-handed which means I'm also adept as using a mouse right-handed; lefties are forced to adapt by an uncaring world ;-)
I used to swap the mouse buttons, and when I needed IT to remote into my machine to fix something it was quite amusing watching them flounder terribly as they just couldn't perform the mental mapping necessary to operate the mouse buttons.
These days I just leave the buttons in the default state and change fingers as you describe; it helps to keep IT on-side, and I sometimes share a computer with my wife who is a rightie.
I'm getting an analog VGA signal out now, at the same time as DVI from the same COG
However the colours are wrong and I am not sure what is going on. It's as if another colour like green or blue channel is coming out the red channel pins instead of red, when I swap over to DVI to compare it. It looks like real green and real blue is okay, any pure red appear to come out black on the screen, but I need to make some proper colour patterns to see what is up.
I thought I setup the colorspace converter correctly but perhaps I didn't, or maybe there is a short on my breakout AV board? I hope it's not a bug in the P2. I don't think it is a bad pin because I do get some colour coming out red on the screen from other channels (maybe I have a bad cable). It's rather weird and I don't get it yet.
Here are my mappings and the DAC settings in the streamer command ($F in the DAC nibble), and I apply dacmod_s to the base sync pin and dacmode_c to the 3 pins up from that:
'configure analog colour mappings
mov b, #128
ror b, #8
setcy b 'red uses bits 31:24
ror b, #8
setci b 'green uses bits 23:16
ror b, #8
setcq b 'blue uses bits 15:8
'enable DVI and RGB VGA
setcmod #%10_01_0_000_1
...
m_rf long $7fb60000 + H_VISIBLE 'visible 8x4b for LUT lookup
dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync is 123-ohm, 3.3V
dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B are 75-ohm, 2.0V
Might be partially my monitor levels - If I send $ff000000 I see a dim red now, but the weird thing is on other parts of the screen there are other characters that are brighter red than this. It's like a bleed of one colour into another, or maybe I have something wrong in the colour space thing.
Comments
Do they? I've not seen any that go above 75Hz or so (except those specifically advertised as supporting high refresh rates, of course).
PS: Until variable refresh rate (VRR) came along for LCDs, they were all fixed frequency native. Anything other than native required the scan converter. And even with a VRR advertised badge you can't be sure it isn't just marketing and it's still just using the scan converter to lie about what the LCD can do.
It's a tall order to add VRR to LCD. They at least have a bunch of drive biasing to manage to compensate for slouchy response times. It affects colour and contrast too. To maintain that visual quality at different scan rates requires programmable controls with voltages beyond the fixed levels and ideally a formula for calculating the biases. And there's probably more to it than that.
It kind of reflects the history of CRTs before them. They too were fixed frequency for the most part until the 1990s when they started getting the user settings with an on-screen-display (OSD). This represented the amalgamation of the complex adjustments into a single mixed signal chip. Making the construction cheaper ... but presumably also locked into that architecture that has given us the 30 kHz minimum hsync.
PPS: And a conditional prediction: If OLED makes it on to cheap production lines then it will be an easy fit for VRR and should wipe out all LCD production. The scan converter drops down to only a couple of scan lines instead of being the whole display.
On my main PC, I configure all my timings by hand (indeed because windows won't give you weird ones like 2560x960 90Hz) and anything over 75Hz on that random LCD I've got hooked up as a secondary screen won't sync.
I never heard of LCDs having a fixed refresh rate, can you give me a source on that?
They have a scan converter between the video in and the LCD. They've always been like that ... until very recently on the expensive gaming monitors that is. Variable refresh is a difficult thing for LCDs to handle. Fixed single frequency 75, 60 and 50 Hz were it. It is possible that dual frequency 60/75 was done for some LCDs but it's just as likely they relied on the monitor's scan converter to handle it.
V_VISIBLE = 600 V_FP = 2 ' 10 V_SYNC = 2 V_BP = 2 '33 H_FP = 8 '16 H_SYNC = 8 '96 H_BP = 8 '48 H_VISIBLE = 1024 HZ = 50 V_SYNC_POLARITY = SYNC_NEG H_SYNC_POLARITY = SYNC_NEGThe 16bpp colour image I see on my monitor is looking very nice and stable. For a full frame image, it would need to be fed data at a rate of 1024 words every 33us or so, or over 61MB/s to keep up. HyperRAM could do this.
To get to 1024x768 at 50Hz would require just a tad over 400MHz so I am not game to try it.
EDIT: Is that working on your monitor?
It is working, as I mentioned before this Dell monitor is awesome and takes about anything you throw at it unless it is below about 28kHz and 49Hz. It has a great scaler too.
The values are in dot clocks and scanlines yes.
Horizontal frequency is same as 640x480 60Hz, difference is 625 lines instead of 525.
If pixel clock = 25.2MHz:
800 pixels/line = 31.5kHz, 625 lines = 50.4Hz
806 pixels/line = 31.265kHz, 625 lines = 50.02Hz
If pixel clock = 25.0MHz:
800 pixels/line = 31.25kHz, 625 lines = 50.0Hz
For graphics modes I think I need to check out the various odd word and long cases now, because 720 wide displays for example do not fit nicely into 32 bit longs for all colour depths, neither does pixel doubled 800 wide graphics with 400 source pixels. Both 320/640 and 512/1024 wide is okay. I may need to have a copy routine that handles an additional 1-3 bytes of data at the end. I haven't really seen how unaligned transfers work with this driver. Perhaps a block transfer slows down significantly in that case. It's probably not ideal.
The good thing is with this change is that it frees up 50 more longs in COG RAM now. Luxury! I'll definitely have room for display regions.
Took a little searching to find - There sure isn't any general info about how any of them work in online articles. Anyway, here's snippet from AMD's FreeSync code for Linux:
} else if (in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE && refresh_range >= MIN_REFRESH_RANGE_IN_US) { in_out_vrr->adjust.v_total_min = calc_v_total_from_refresh(stream, in_out_vrr->max_refresh_in_uhz); in_out_vrr->adjust.v_total_max = calc_v_total_from_refresh(stream, in_out_vrr->min_refresh_in_uhz);I think that's enough to tell me that varying vtotal is a primary component of how AdaptiveSync/FreeSync control the field rate. Presumably GSync is similar. The missing info is more detailed in exactly how that is signalled to the receiving monitor.
PS: Code copied from https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
Testing proceeds, I need to make sure the 256 entry palette can be loaded in per scanline.
The option of having multiple mice on the screen is very weird too...
I can think of applications for multiple 'cursors' - eg one example from machining is the cutting tool icon that traverses around a toolpath window as the job progresses. You still want a separate mouse cursor for pushing buttons etc, but the cutting tool icon stays in the window showing the toolpath progression. I think its a useful feature
There could potentially be a flag in each region to indicate whether the region shares a common mouse coordinate from the previous region, or uses its own one. Still need to think about it...
Also, speaking of mice, it might be nice to have the ability for it to flash, so you could use it also to emulate a text cursor in some graphics mode, like a simple sprite with a vertical line etc. I was thinking of adding in a control to flash it but I guess you could always flip pointers from one null image (with 0 mask) to the real image to achieve it, that would save me a couple of longs, so I'll probably leave it for now.
I'm thinking of posting the documentation for what I have so far to see how people react to it. It's almost done so any suggestions may not make it in, but if there are obviously worthwhile things to put in I might be able to consider it while I am still making changes.
I am looking into possible analog support right now.
I think having a text cursor is useful if you want to see where you are typing. Managing the flashing in the video driver automatically is helpful and stops the code having to periodically intervene to flash it manually and keep the flash rate consistent etc, though of course it is possible to do entirely in software. I support two cursors so in a text UI you might have an old school block cursor for the mouse, and an underscore type for the text entry. I made the blink phase selectable too, so one flashing cursor can be seen with another if they are at the same location.
A joystick in the off-hand works surprisingly well, though. Better even because that leaves your strong hand free. I remember being fasinated watching a draftsman working with high-end CAD software about 20 years back where he had this device called a "space ball" in his left hand and the mouse in his right hand. The space ball, without any buttons, provided, I think, all six degrees of camera control. Leaving the mouse for editing of the 3D structures.
I change (fingers) when using the left hand, I use long finger to left button and index finger to right button.
I'm Left-handed which means I'm also adept as using a mouse right-handed; lefties are forced to adapt by an uncaring world ;-)
I used to swap the mouse buttons, and when I needed IT to remote into my machine to fix something it was quite amusing watching them flounder terribly as they just couldn't perform the mental mapping necessary to operate the mouse buttons.
These days I just leave the buttons in the default state and change fingers as you describe; it helps to keep IT on-side, and I sometimes share a computer with my wife who is a rightie.
However the colours are wrong and I am not sure what is going on. It's as if another colour like green or blue channel is coming out the red channel pins instead of red, when I swap over to DVI to compare it. It looks like real green and real blue is okay, any pure red appear to come out black on the screen, but I need to make some proper colour patterns to see what is up.
I thought I setup the colorspace converter correctly but perhaps I didn't, or maybe there is a short on my breakout AV board? I hope it's not a bug in the P2. I don't think it is a bad pin because I do get some colour coming out red on the screen from other channels (maybe I have a bad cable). It's rather weird and I don't get it yet.
Here are my mappings and the DAC settings in the streamer command ($F in the DAC nibble), and I apply dacmod_s to the base sync pin and dacmode_c to the 3 pins up from that:
'configure analog colour mappings mov b, #128 ror b, #8 setcy b 'red uses bits 31:24 ror b, #8 setci b 'green uses bits 23:16 ror b, #8 setcq b 'blue uses bits 15:8 'enable DVI and RGB VGA setcmod #%10_01_0_000_1 ... m_rf long $7fb60000 + H_VISIBLE 'visible 8x4b for LUT lookup dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync is 123-ohm, 3.3V dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B are 75-ohm, 2.0V