Here's how I got my multiple fixed-frequency, as oposed to
multi-scanning monitor to work.  Multi-scanning monitors are much more
forgiving, mine only accepts one fixed frequency for each graphics
mode, so it had to be configured carefully.  The enclose software,
wasn't written by me I've just collected it together, so I can't take
any responsibility for it's reliability.


This all started out as a email reply to a request for help, I
collected together all the useful utilities for configuring X386.
Please feal free to enhance.

				Michael Hamilton (hamilton@wcc.govt.nz)

Background:

The monitor draws dots at a given rate for each video mode.  This is
measured in MHz, and one example might be 35Mhz.  The video card and
monitor need to be using the same rate.  The video card must also tell
the monitor when to begin each line of dots, and allow it enough time
to draw the line and get back to the start for a new one, timings
measured in KHz.  Similarly the card has to tell the monitor when to
go back to the top of the screen, and this is measured in Hz (eg
55Hz).

Objective:

Tell your video card reasonable values for your monitor that balance
the dot rate, and horizontal and vertical refresh signals.  Reasonable
means ones your monitor is capable of.

Method:

First big milestone - correctly work out how many clocks and what
values they have.  Get the number of clocks wrong and and configuring
any but the first clock will be unlikely.  What you are doing is
finding out a list of "registers" that X386 will index into.  The
clock.exe program will tell you what your SVGA CARD (et3000/4000 only)
will support in the way of clock registers.  You can also figure this
out from your SVGA CARD manual and DOS utilities (vmode.exe).  X386
"startx" under linux will give an approximate clocks reading - but
it's inexact due to the interuptable nature of a real operating
system, but it will hopefully get the number of clocks, and ball-park
figures (only for cards it "understands", ie et3000/4000 are good
prospects). Try all methods to verify the number of clocks, and use vmode
or documentation to firm up your actual clock values.

Of the given clocks, maybe only a few are used by your MONITOR.  You
must list ALL the clock numbers in your Xconfig file, so that X386
indexes them correctly, but the monitor vga-modes may only use a
subset, so the /usr/lib/X11/Xconfig file maps which clocks to use for
which VGA modes, hence lines starting "36 800..."

Second milestone - find out what you monitor will support in the way of
clocks.  Look for figures like 35.2 MHz for 800x600 graphics mode.
"MHz" is a big clue when reading your MONITOR manual. There will be a
value for each video mode the monitor supports.  Don't get confused
with other numbers in KHz or Hz (you'll need those later).

There is DOS timings program posted that will help, its included as a
zip here.  You run it under DOS, and it dumps out the values used by
DOS for a given SVGA mode.  It will in fact tell you every thing you
need to know for an et4000 (except how many clocks there are).  It
reads the magic numbers out of the VGA cards registers.  BUT I suspect
it sometimes reads the wrong numbers, so you have to know what good
ones look like, ie. don't trust it completely, use it as a guide or
for verification.

Use the enclosed awk script to figure out whether timings exactly
match your monitors capabilities, for fixed freq, or roughly match for
multi-freq.

E.g. I used the following restrictions for the "video tutorial" and
kept trying the awk scipt until I got an exact match (start with
a guess from the database)...

Run the awk script:

      res 35.2 800 832 956 988 600 601 603 624

Results:
For settings 35.2 800 832 956 988 600 601 603 624
Refresh rate: 57.1 Hz             <--- Match to you monitor manual.
Horizontal sync rate: 35.6 KHz    <--- Match to you monitor manual.
Sync pulse time:  3.5 usec        <--- Sync pulse should be 3-4 usec.
Sync pulse offsets: 32 and 32     <--- 
Vert sync pulse time: 56.1 usec   <--- Vert sync should be 50-300 usec. 
                                       in this case OK, but maybe a bit low -
 				       try again?

I would suggest working on 640x480 first, as its usually the first
clock and the most standard as far as monitors go - see VESA settings
in the vga database.  It's also a good bet in case you've got the
number of clocks wrong.  Once I figured out how many clocks my card
had, everything just worked - fantastic.  But my new SVGA card is
treading on my floppy driver card - so I've had to de-install it, so I
hope you have more luck than me.

The awk script included here has been hacked a little to fix a couple
of small problems I had with it under ultrix - it should work fine on
most awks. By the way, the int() function is brocken on my linux gawk,
so if you are going to use gawk under linux you might have to change
int(x) to sprintf ( "%d", x ), or similar.

The awk script has a small shell script wrapper so you can run it like
a program.

Awk original posting:
--- start of included posting ---
Date: Sat, 30 May 92 13:40:51 -0400
From: jrs@world.std.com (Rick Sladkey)
Sender: owner-linux-activists@joker.cs.hut.fi
To: linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
Cc: linux-activists@joker.cs.hut.fi
Subject: Overview of common source of X11 VGA problems.
In-Reply-To: <9205300944.AA10720@wind.UUCP>
References: <9205300944.AA10720@wind.UUCP>
X-Mn-Key: X11

>>>>> On 30 May 92 09:44:24 CDT (Sat), wind!greg@plains.NoDak.edu said:

greg> There appears to be two groups of experience with X11.  There is the
greg> group that reports back that they got X11 up and running with very few
greg> problems and are pleased with the result.  Then there is the group (like
greg> our shop) which cannot get a stable display and are frustrated because
greg> X11 is otherwise functioning normal, responding to the mouse and keyboard
greg> commands.

I am a third group.  I frittered away a couple of days getting a stable
display and have been happy tweaking it since.

greg> (g): The Crystal-Scan's vertical frequency is 45-90Hz and the horizontal
greg>      frequency is 31.5 - 37. kilohertz.

I have the exact monitor you describe but on a 33/386,  circa Dec 1990.
old.

greg> (g): Well the Crystal-Scan really isn't a 'true' multi-frequency monitor.
greg>      It can handle multiple-frequencies but only those that correspond
greg>      to particular resolutions, for example 800x600.

I do not have any problems syncing.  I can sync at any range within the
stated values.  

After numerous failed attempts to get anything other than 640x480 by copying
values from the database, I wrote an awk program based on the tutorial.
Every setting the program came up with worked on the first try.

Here is the program.  It is not very refined but maybe some others can
make use of it.  To work correctly, it is critical that the clocks values
be correct.  This is another common cause of displays that won't sync when
calculations show that they should.

It works two ways.  One, give it a clock and desired horizontal sync and
it gives you highest refresh settings more or less per the tutorial.
It can also be used to examine existing settings and give a little report
on them.

Here is an example run.
My SpeedSTAR clocks are: Clocks        25 28 33 36 40 45 50 63

$ res 36 37
For a 36 MHz clock and 37 kHz max horiz sync:
Min horiz frame length: 976
Min horiz viewing image: 784
Min vert frame length: 617
Min vert viewing image: 588
Max refresh rate: 59.8 Hz
Std horiz sync pulse length: 136
Horiz surplus ticks: 192
Our horiz sync pulse time:  4.0 usec
Recommended settings:
            36   784  808  952  976   588  588  593  617
$

Rick Sladkey
jrs@world.std.com

--- end of included posting ---
