NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/pcclone/32bit/924

Internet Message Format | 1992-12-29 | 4.0 KB

Path: sparky!uunet!gatech!destroyer!gumby!yale!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!bson
From: [e-mail] (Jan Brittenson)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Dell svr4 Issue 2.2 + NEC 5FG + video card ? = max resolution
Date: 29 Dec 92 17:57:44
Organization: nil
Lines: 66
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: churchy.gnu.ai.mit.edu
In-reply-to: [e-mail]'s message of 28 Dec 92 16:56:50 GMT

In article <[e-mail]> [e-mail] (Tan Bronson) writes:

 > I was wondering what video cards people were using with the NEC 5FG
 > and what resolution they were using. My understanding is that to get
 > the maximum resolution of 1280x1024 on this monitor one needs 135Mhz
 > of bandwidth and standard VGA can not go that high due to the cable.

   This is only half the truth. You can get 1280 visible dots
horizontally with a 95 MHz dot clock. However, the horizontal
resolution possible is usually not the limiting factor, but the
vertical is. It's pointless to have a horizontal resolution of 1280 if
you can only get 600 vertically -- the picture will be strteched
vertically since the resolution won't match the proportions of the
monitor. What limits the _vertical_ resolution is the maximum line
clock (Hsync frequency) of the monitor and the lowest refresh rate
(Vsync frequency) that you find tolerable. For instance, if you
monitor is capable of 68 kHz horizontally, and you find 64 Hz refresh
to be acceptable, then you *may* be able to tweak the timing to get a
full 1280x1024.

   In general, though, I find the ``more resolution is better'' mania
to be pure and utter nonsense, except for some very specific
applications, like desktop publishing (but if you can afford
FrameMaker, then you're hardly paying out of your own personal income
-- and we both know what the better HP and Tek monitors cost). In
general, 933x695 at 72 Hz will look vastly superior to 1024x768 at
64 Hz. Just use a smaller font.

   Cables can be a problem, too, but you can always split the R, G,
and B signals into three separate 50 ohm coaxial cables and then put
them back into a regular 15-pin SVGA connector at the monitor. The
solution is trivial, and not too expensive. These types of splitters
may be a little difficult to find though, since most of the ``all
cables $5.95 or less'' type of outfits will never have heard of it.
You can always make them yourself; use plain regular nickel BNC
connectors.

   I'm still gathering sync info for monitors to include in the ModeDB
database. Once I've distributed, you can easily just try out different
video boards in the database and see what ModeDB timing you will get,
to see if there's any improvement. Before you go buy it. It also comes
with an extensive tutorial that explains the basics of video timing
(without ``rules-of-thumb'' hocus pocus), how to read the ModeDB
timing, and how to tweak it (to center the image, for instance). It
explains aspect ratios, how to calculate what range of aspect ratios
meaningful for you and your monitor, and how to use this to generate
the ModeDB database.

   I still need timing info for a lot more monitors. The response has
been weak so far, to say the least. I *will* gather the info if I so
have to resort to faxing every vendor separately. I for one am fed up
with the total chaos and lack of simple methodical approaches for
setting the timing up. It is fundamentally so simple I'm nearly
dumbstruck no one has cranked out a toolkit like this before.

   I also could need a few more to proof-read the tutorial mentioned:
send me the technical data (including sync timing if in the
instruction booklet) for your monitor, and I'll send you a copy of the
tutorial. Please specify whether you'd like it on paper (need your
snail address then), in uuencoded DVI form, or GNU's texinfo. If there
is no technical data, please at least mail me the snail address and
phone (fax preferably) of the manufacturer/importer/vendor.

--
                        -- Jan Brittenson
                           [e-mail]