> That was a very nice article on calculating display modes, if you know what
> X and Y you want. What if I'm going the other way, I know what my
> monitor and video card can do, and want to work out X and Y?
O.K. - that can be done as well. Basically the same formulas apply, you just
go through them in another order.
> Lets say I know (from playing with xvidtune, I think it was) that my
> monitor can do 64.79 horizontal, and 117.24 vertical.
O.K. - I for now assume a fixed frequency monitor with that values.
This already locks down the vtotal: 553 lines.
However if the monitor isn't fixed-frequency with respect to the vertical
frequency, we can still adjust that value later.
> Lets also say that I want 640 pixels inside a netscape window. That's
> 640, plus 16 for the scroll bar, plus 40 for the left and right margin,
> plus 4 for the window frame, or either 692 or 700 pixels across.
O.K. - let's see: You want a width of about 700. O.K.
That gives (using my rule of thumb) a htotal of 840, i.e. 140 for the
border (20%).
Further calculations yield a placement of the sync pulse start at 700+23
pixels.
Now let's make sure all is divisible by 8 ... 700 needs rounding up to 704
(I round up, as You will rather want a little more space, than a little
less.):
"700x???" ??? 704 728 800 840 ??? ??? ??? ???
As of now, the pixelclock is still not determined. O.K.
pixclock=hsync*htotal=54.4MHz.
If you have a programmable clock, all is well here. You should be able to
set it reasonably close to 54.4 MHz.
In case you don't there are two scenarios: 1. Your monitor is multisync, and
you can cope with a slightly lower refresh. Then just use a slightly lower
available clock. 2. The monitor is monosync or you do not want to have a
lower hsync. Then you need to adjust htotal.
Example: The next clock you have is 55MHz. That yields a total of 848. This
is so small of a change, that you need not distribute the extra space evenly
between presync and postsync. Just adjust 840->848 and be done with it.
This yields a hfreq of 64.86, which is so close to 64.79 (about 1/1000 aka
0.1% off), that the monitor can't notice it.
More extreme example: The next clock is 60MHz. That yields a total of 928.
The extra 88 pixels should be distributed 1:2 to pre and postsync, yielding
something like
"700x???" 60.0 704 760 832 928 ??? ??? ??? ???
This yields a hfreq of 64.66, which is again close enough to 64.79 (about
0.2% off).
> Lets also say that I want to run as many vertical lines as I can,
O.K. Now we have two possible ways to think about the line number:
As said, if I consider the monitor fixed, I get vtotal=553 lines.
Using my rule of thumb, that allows for 503 lines visible giving
"700x503" 54.4 704 728 800 840 503 ??? ??? 553
Note, that you can substitute any of the abovementioned higher modes for the
horizontal timings and pixclock, as this does not influence vertical timing.
Using the 1/3rd rule you get
"700x503" 54.4 704 728 800 840 503 520 522 553
Another point of view is looking at the aspect ratio of the pixels. Monitors
have a 4:3 aspect ratio for width:height. To get square pixels with a
screen-filling mode, one must have width/4==height/3 or height=528 must
hold. Now this might get a little tight for the border, but you can try:
"700x528" 54.4 704 728 800 840 528 536 538 553
This mode might not be adjustable to be within borders or it might show
retrace stripes.
If the monitor is not fixed sync, you could sacrifice a little vrefresh for
square pixels and enough border by using:
"700x528" 54.4 704 728 800 840 528 563 565 634
However this has only vsync=102.1Hz.
> and wonder what the tradeoff is between refresh rate and lines
> (and want at least 100 HZ vertical).
O.K. - that last exeample should have shown that - right ?
> Finally, assume a 230 dot clock,
This is not needed. The mode is so small, that it is not limited by maximum
dotclock. If you would really _have_ to use that clock, you would need to
place 3550 pixels on a line. Not good - even if one use horizontal
pixeldoubling - At pixel-quadrupling we'd get reasonable resolutions.
Fortunately using less than the maxclock is rarely a problem.
> and then how does the bit depth affect this whole thing?
This does not affect the monitor timing at all - or at least it should.
Some cards slightly change their interpretation of the timing, when depth
changes, but that is usually just a matter of compensating by adding/
subtracting 8 (or 1 for lines) on the individual timings.
However the bit depth can influence the maximum available pixelclock.
The point is, that the memory on the graphics card has a limited bandwidth.
Let's assume we have a 300MB/s bandwidth limit on the card memory.
With a maximum pixel clock of 230MHz, this has no influence for 8 bit modes,
as 8 bit modes at worst require 230MB/s, as they only need 1 byte/pixel.
16 bit modes however require 2 byte/pixel, thus limiting the maximum pixel
clock to 150MHz, and 32 bit modes need 4byte/pixel i.e. 75MHz.
The 24 bit modes (real packed 24, not 24/32 modes, where we have 8 unused
bits) are special. If the architecture does proper caching in a FIFO, you
can use 100MHz, i.e. 3byte/pixel.
There might be broken designs, that need to do 2 32 bit accesses to get at
the 24 bit packed data when unaligned, which would mean 5 32 bit accesses
for 4 pixels, i.e 60MHz ... I really hope no such design exists - would be
sick.
> (I don't know my monitor's bandwidth limit, nor do I know how to
> determine it.)
Basically The Pixclock should not go over the bandwidth. Usually nothing
really bad will happen if you exceed it (contrary to what happens when you
exceed hsync). The image will get blurry, as the input amplifier can not
evenly amplify anymore above that frequency.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
