678 lines
27 KiB
Plaintext
678 lines
27 KiB
Plaintext
From: Digestifier <Linux-Misc-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Misc@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Misc@senator-bedfellow.mit.edu
|
|
Date: Sat, 10 Sep 94 15:14:25 EDT
|
|
Subject: Linux-Misc Digest #734
|
|
|
|
Linux-Misc Digest #734, Volume #2 Sat, 10 Sep 94 15:14:25 EDT
|
|
|
|
Contents:
|
|
Compaq Pentiúm. Anybody ? (Anders Ostling)
|
|
Re: Xconfig for 320x200 or similar mode? (Christopher M. May)
|
|
Re: 320x200 X resolution? (Christopher M. May)
|
|
Re: driver wanted for NE3200 (Donald Becker)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: anos@elmrd6.ineab.ikea.se (Anders Ostling)
|
|
Subject: Compaq Pentiúm. Anybody ?
|
|
Date: 10 Sep 94 18:53:44 +0200
|
|
|
|
|
|
Hi all
|
|
|
|
I'm curious if there is anybody in netland that have made a brand new system
|
|
like a Compaq Pentium/60 w buildin ethernet, graphics and SCSI adapters, to
|
|
run with Linux ? We have 40+ new systems like that, and some of our users
|
|
have been so delighted with my Linux box that they want to run Linux on their
|
|
boxes too. But, as I said, they have got these new wonderful, but not very
|
|
common, pheripial equipment ...
|
|
|
|
One of the guys have Linux up and running on the IDE disk (there is both IDE
|
|
and SCSI), so Linux works ok. The next big problems seems to be graphics (
|
|
read Xfree...). I do bealive that the adapter has a Cirrus Logic chipset, but
|
|
I'm not sure. Anyway, I can remember reading about Xfree 3.x support for the
|
|
Compaq Qvision (same brand), so it might just work later this autumn. Anybody
|
|
that know when 3.1 will be available ?
|
|
|
|
Last, but not least, these systems also has properity ethernet adapters. I
|
|
cant get any vender to tell me that they are compatible with anything :-), so
|
|
I guess a new MAC driver will be needed in order to get on the net...
|
|
|
|
/Anders
|
|
|
|
--
|
|
+-------------------------------------------------------------------------+
|
|
| Internet anos@ineab.ikea.se |
|
|
| _ _ Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling |
|
|
| \ \ \ IKEA Northern Europe AB, Sweden |
|
|
| _/ _/ _/ |
|
|
+-------------------------------------------------------------------------+
|
|
|
|
|
|
------------------------------
|
|
|
|
From: cmay@titan.ucs.umass.edu (Christopher M. May)
|
|
Crossposted-To: comp.os.linux.help
|
|
Subject: Re: Xconfig for 320x200 or similar mode?
|
|
Date: 10 Sep 1994 17:52:35 GMT
|
|
|
|
Benjamin Alman (alman@myhost.subdomain.domain) wrote:
|
|
: Does anyone know how to get a 320x200 or similar resolution in XFree386
|
|
: 2.1.1 ??? I have an ATI GUP video card, and a CTX CPS-1560 monitor...
|
|
|
|
A while ago, some kind soul posted a C program which automatically
|
|
calculates modeDB entries based on dot-clock frequency and
|
|
horizontal sync frequency.
|
|
|
|
I cannot take any credit for this program, which is based on
|
|
information from the Videomodes.doc provided with XFree.
|
|
I also cannot take any credit (or be held responsible)
|
|
if use of this program causes damage to your equipment.
|
|
Use at your own risk. (*sigh*).
|
|
|
|
It did, however, allow me to find a 320x240 video mode I can
|
|
use to play DOOM on my SONY CPD-1304 *Multiscan* monitor.
|
|
|
|
After you cut the source from this article, and compile
|
|
it, you can get a 320x240 mode with:
|
|
|
|
xmode -dcf 12 -hsf 29.5
|
|
|
|
refresh rate for this mode: 28.26Hz
|
|
percent of hfl used: 75.37%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
320x240 12 320 352 392 424 240 243 247 252
|
|
|
|
I had to add some values to the vertical timing to correct
|
|
some weird linearity problem on my monitor (top horiz lines spaced wider...)
|
|
Of course this refresh rate is really low, (although it looks fine to me )
|
|
I was able to sync to higher rates, but the size was off, so I just
|
|
dropped the dot clock, until I had a mode I didn't have to manually
|
|
enlarge.
|
|
|
|
Notice that 320x200 is not a 4:3 aspect ratio. You can probably
|
|
edit xmode.c to give a 320x200 aspect, but I like a little border,
|
|
so 320x240 works for me.
|
|
|
|
The original post from the author of xmode.c follows my .signature
|
|
--
|
|
|
|
-Chris May, Computer Science, University of MA, Amherst
|
|
- Technical Assistant, P.C. Maintenance Lab
|
|
|
|
|
|
cloister@u.washington.edu (cloister bell) writes:
|
|
|
|
>i read through VideoModes.doc, and worked through the steps for creating a
|
|
>video mode, and well, i was pleased to find that the results actually worked.
|
|
>but it occurs to me that someone has to have written a utility to do this
|
|
>automatically. something that would take a dcf value and a hsf value and give
|
|
>you back a line that you can stick in your Xconfig file. has anyone seen
|
|
>something like this?
|
|
|
|
ok, so maybe it's bad form to answer my own question, but i'm going to anyway.
|
|
since i posted the question, i decided it couldn't be that hard to write such a
|
|
utility, and i turned out to be correct. it was really easy, in fact, which is
|
|
why it surprises me that no such utility is included with the linux
|
|
distribution (at least, not with slackware 2.0, which is what i used).
|
|
|
|
anyway, the following utility takes as input values for your dot clock and
|
|
horizontal sync frequency and an optional horizontal sync pulse length, and
|
|
gives you back a line of numbers you can stick in your Xconfig file. read the
|
|
header comment for details:
|
|
|
|
/*------------------------------8< cut here 8< ------------------------------*/
|
|
/* XFree86 video mode timing generator for Linux. use this to create video
|
|
* modes for your Xconfig file from dot clock values and horizontal sync
|
|
* frequencies. */
|
|
|
|
/* to see why all this works, read /usr/X11/etc/VideoModes.doc. I don't claim
|
|
* that this program is anything other than a quick hack because i didn't want
|
|
* to calculate another video mode manually. one was enough. :) */
|
|
|
|
/* all the usual public domain stuff applies to this software:
|
|
* copyright jason black, 1994. you are free to copy, redistribute, and use
|
|
* this software to your heart's content provided that you leave this comment
|
|
* intact when you redistribute, that you always include this source file when
|
|
* redistributing, and that you don't go trying to sell this to anyone to make
|
|
* a profit. if you are redistributing on floppy disk, magtape, or any other
|
|
* removable media, then you may charge up to as much as the media costs.
|
|
* basically, i don't want anyone trying to in any way limit availability of
|
|
* this program, nor do i wany anyone trying to make a profit off my labor. */
|
|
|
|
/* this program should be easy to compile, as it doesn't do anything even
|
|
* remotely sneaky. compile it like this:
|
|
|
|
gcc xmode.c -o xmode
|
|
|
|
* this program is also easy to use. invoke it with no flags to get usage
|
|
* information. here are two sample runs of the program so you can see how
|
|
* easy it is:
|
|
|
|
foo> xmode -dcf 85 -hsf 64
|
|
refresh rate for this mode: 60.03Hz
|
|
percent of hfl used: 72.88%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
1032x774 85 1032 1064 1384 1416 774 777 786 812
|
|
|
|
foo> xmode -dcf 85 -hsf 56.5 -hsp 3.5
|
|
warning: refresh rate is less than 60Hz for this mode.
|
|
refresh rate for this mode: 54.47Hz
|
|
percent of hfl used: 76.90%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
1200x900 85 1200 1232 1528 1560 900 903 911 945
|
|
|
|
both of the above are actual results i got on my machine, and both were
|
|
functional video modes. the 1200x900 was too flickery to be usable, however,
|
|
which is why the less than 60Hz refresh rate warning is in there.
|
|
|
|
* note that while this program produces video modes that work, you will
|
|
* almost certainly have to tweak the hspstart and hspend values for your
|
|
* monitor. the program places the hsp more or less in the middle of the
|
|
* scanline, which may not be the best place for it for you. tweaking should
|
|
* be done in accordance with the tutorial in VideoModes.doc. specifically,
|
|
* hspstart, hspend, and hfl are the only numbers you should have to really
|
|
* mess with. hspstart and hspend should both be changed by the same amount if
|
|
* you change either. incrementing or decrementing hspstart and hspend will
|
|
* move the display right or left. incrementing or decrementing hfl will
|
|
* stretch or shrink the width of the display. all increments to these
|
|
* numbers must be in multiples of 8, as must horizontal timing numbers
|
|
* themselves. */
|
|
|
|
#include <stdio.h>
|
|
|
|
void main(int argc, char **argv);
|
|
void usage(char *argv0);
|
|
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen);
|
|
|
|
void main(int argc, char **argv)
|
|
{
|
|
float
|
|
/* input values: */
|
|
dcf = -1, /* dot clock frequency - from command line */
|
|
hsf = -1, /* horizontal sync frequency - from command line */
|
|
hsplen =3.8, /* length of horiz. sync pulse in microseconds */
|
|
|
|
/* calculated output values: */
|
|
hr = -1, /* horizontal resolution - calculated */
|
|
hspstart = -1, /* horizontal sync pulse start - calculated */
|
|
hspend = -1, /* horizontal sync pulse end - calculated */
|
|
hfl = -1, /* horizontal frame length - calculated */
|
|
vr = -1, /* vertical resolution - calculated */
|
|
vspstart = -1, /* vertical sync pulse start - calculated */
|
|
vspend = -1, /* vertical sync pulse end - calculated */
|
|
vfl = -1, /* vertical frame length - calculated */
|
|
|
|
/* intermediate values: */
|
|
hsp = -1, /* length of horiz. sync pulse in clock ticks */
|
|
linetime = -1, /* microseconds it takes for one scan line */
|
|
vsp = -1, /* length of vert. sync pulse in linetime units */
|
|
rr = -1 /* refresh rate */
|
|
;
|
|
|
|
int done = 0, hfl_last_tweaked = 0;
|
|
|
|
process_args(argc, argv, &dcf, &hsf, &hsplen);
|
|
|
|
/* now begins the fun stuff */
|
|
|
|
hfl = (int)(1000.0 * dcf / hsf); /* time for one scan line in dcf ticks */
|
|
hr = (int)(0.8 * hfl); /* shouldn't try and display more than 80% of hfl */
|
|
|
|
/* we need to engineer things so that hsp length is between 3.5 and 4 micro-
|
|
* seconds, and so that hfl - hfr = hsp (in clock pulses), and so that hfl,
|
|
* hfr, and hsp are divisible by 8. */
|
|
hsp = hsplen * dcf; /* 3.8 is in microseconds, hsp is in hsf clock pulses */
|
|
|
|
hsp -= (int)hsp % 8; /* force hsp to be a multiple of 8; round down */
|
|
hfl -= (int)hfl % 8; /* same for hfl */
|
|
hr -= (int)hr % 8; /* same for hr */
|
|
|
|
while(!done)
|
|
if(abs(hsp - (hfl - hr)) < 8) /* hsp and (hfl-hr) must be at most 8 apart */
|
|
done = 1;
|
|
else
|
|
{
|
|
if(hsp > (hfl - hr)) /* hfl and hr are too close together */
|
|
if(hfl_last_tweaked) /* alternately lower hr or raise hfl */
|
|
{
|
|
hr -= 8;
|
|
hfl_last_tweaked = 0;
|
|
}
|
|
else
|
|
{
|
|
hfl += 8;
|
|
hfl_last_tweaked = 1;
|
|
}
|
|
else if(hsp < hfl - hr) /* hfl and hr are too far apart */
|
|
if(hfl_last_tweaked) /* alternately raise hr or lower hfl */
|
|
{
|
|
hr += 8;
|
|
hfl_last_tweaked = 0;
|
|
}
|
|
else
|
|
{
|
|
hfl -= 8;
|
|
hfl_last_tweaked = 1;
|
|
}
|
|
else /* hfl - hr equals hsp. yay! */
|
|
done = 1; /* this is redundant, but who cares? */
|
|
}
|
|
hspstart = hr + 32; /* where the hsp pulse starts; 32 is magic. */
|
|
hspend = hr + 32 + hsp; /* where the hsp pulse ends */
|
|
hfl = hr + 32 + hsp + 32; /* calculate new hfl for that pulse configuration */
|
|
|
|
/* now we're done with the horizontal numbers. do a couple of checks: */
|
|
if (hr/hfl > 0.8)
|
|
fprintf(stderr,"warning: these values use more than 80%% of the hfl.\n");
|
|
rr = 1000*dcf/hfl;
|
|
if (rr < 60)
|
|
fprintf(stderr,"warning: refresh rate is less than 60Hz for this mode.\n");
|
|
fflush(stderr); /* just in case */
|
|
|
|
/* now do the vertical numbers */
|
|
vr = (int)(0.75 * hr); /* that 4:3 hr:vr screen ratio */
|
|
vfl = (int)(1.05 * vr); /* inverse of vr = .95 * vfl; we already know vr */
|
|
|
|
linetime = hfl / dcf; /* microseconds it takes for once scan line */
|
|
vsp = 150.0/linetime; /* number of scanlines worth of vsp */
|
|
vspstart = vr + 3; /* where the vsp pulse starts. 3 = guard time */
|
|
vspend = vr + 3 + vsp; /* where the vsp pulse ends; vspstart + vsp */
|
|
|
|
printf("refresh rate for this mode: %5.2fHz\n",rr);
|
|
printf("percent of hfl used: %5.2f%%\n",100*hr/hfl);
|
|
printf("mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl\n");
|
|
printf("%dx%d %d %d %d %d %d %d %d %d %d\n",
|
|
(int)hr,(int)vr,(int)dcf,
|
|
(int)hr,(int)hspstart,(int)hspend,(int)hfl,
|
|
(int)vr,(int)vspstart,(int)vspend,(int)vfl);
|
|
}
|
|
|
|
void usage(char *argv0)
|
|
{
|
|
fprintf(stderr,
|
|
"usage: %s -dcf dot_clock_freq -hsf horizontal_sync_freq [-hsp hsplen]\n",
|
|
argv0);
|
|
fprintf(stderr," -dcf is in MHz, no default value\n");
|
|
fprintf(stderr," -hsf is in kHz, no default value\n");
|
|
fprintf(stderr," -hsp is in microseconds, default value = 3.8\n");
|
|
exit(1);
|
|
}
|
|
|
|
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen)
|
|
{
|
|
int i;
|
|
|
|
if (argc < 5) usage(argv[0]);
|
|
if (argc%2 != 1)
|
|
{
|
|
fprintf(stderr,"error: each arg must be a name, value pair\n");
|
|
usage(argv[0]);
|
|
}
|
|
|
|
for(i = 1; i < argc; i+=2)
|
|
if(!strcmp(argv[i],"-dcf"))
|
|
sscanf(argv[i+1],"%f",dcf);
|
|
else if (!strcmp(argv[i],"-hsf"))
|
|
sscanf(argv[i+1],"%f",hsf);
|
|
else if (!strcmp(argv[i],"-hsp"))
|
|
sscanf(argv[i+1],"%f",hsplen);
|
|
else
|
|
{
|
|
fprintf(stderr,"unknown argument %s\n",argv[i]);
|
|
usage(argv[0]);
|
|
}
|
|
|
|
/* make sure both required args were given */
|
|
if(*dcf == -1 || *hsf == -1)
|
|
{
|
|
fprintf(stderr,"you must specify at least -dcf and -hsf values\n");
|
|
usage(argv[0]);
|
|
}
|
|
}
|
|
/*------------------------------8< cut here 8< ------------------------------*/
|
|
--
|
|
+-------------------------------------------------+---------------------------+
|
|
|tactical nuclear sdi stealth nsafood signature. | cloister@u.washington.edu |
|
|
+-------------------------------------------------+---------------------------+
|
|
|
|
|
|
------------------------------
|
|
|
|
From: cmay@titan.ucs.umass.edu (Christopher M. May)
|
|
Crossposted-To: comp.os.linux.development
|
|
Subject: Re: 320x200 X resolution?
|
|
Date: 10 Sep 1994 17:58:42 GMT
|
|
|
|
CLAYTON MICHAEL O'NEILL (cs339014@bit.com) wrote:
|
|
: Christopher Wiles (a0017097@wsuaix.csc.wsu.edu) wrote:
|
|
|
|
: : Seriously, IMHO Doom will probably be more useable in the promised
|
|
: : pixel-doubling mode than in a straight 320x200. Easier to make things
|
|
: : look innocent when the boss walks in ... "Hey, you're not actually
|
|
: : _working_ in 320x200, are you?"
|
|
|
|
Benjamin Alman (alman@myhost.subdomain.domain) wrote:
|
|
: Does anyone know how to get a 320x200 or similar resolution in XFree386
|
|
: 2.1.1 ??? I have an ATI GUP video card, and a CTX CPS-1560 monitor...
|
|
|
|
A while ago, some kind soul posted a C program which automatically
|
|
calculates modeDB entries based on dot-clock frequency and
|
|
horizontal sync frequency.
|
|
|
|
I cannot take any credit for this program, which is based on
|
|
information from the Videomodes.doc provided with XFree.
|
|
I also cannot take any credit (or be held responsible)
|
|
if use of this program causes damage to your equipment.
|
|
Use at your own risk. (*sigh*).
|
|
|
|
It did, however, allow me to find a 320x240 video mode I can
|
|
use to play DOOM on my SONY CPD-1304 *Multiscan* monitor.
|
|
|
|
After you cut the source from this article, and compile
|
|
it, you can get a 320x240 mode with:
|
|
|
|
xmode -dcf 12 -hsf 29.5
|
|
|
|
refresh rate for this mode: 28.26Hz
|
|
percent of hfl used: 75.37%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
320x240 12 320 352 392 424 240 243 247 252
|
|
|
|
I had to add some values to the vertical timing to correct
|
|
some weird linearity problem on my monitor (top horiz lines spaced wider...)
|
|
Of course this refresh rate is really low, (although it looks fine to me )
|
|
I was able to sync to higher rates, but the size was off, so I just
|
|
dropped the dot clock, until I had a mode I didn't have to manually
|
|
enlarge.
|
|
|
|
Notice that 320x200 is not a 4:3 aspect ratio. You can probably
|
|
edit xmode.c to give a 320x200 aspect, but I like a little border,
|
|
so 320x240 works for me.
|
|
|
|
The original post from the author of xmode.c follows my .signature
|
|
--
|
|
|
|
-Chris May, Computer Science, University of MA, Amherst
|
|
- Technical Assistant, P.C. Maintenance Lab
|
|
|
|
|
|
cloister@u.washington.edu (cloister bell) writes:
|
|
|
|
>i read through VideoModes.doc, and worked through the steps for creating a
|
|
>video mode, and well, i was pleased to find that the results actually worked.
|
|
>but it occurs to me that someone has to have written a utility to do this
|
|
>automatically. something that would take a dcf value and a hsf value and give
|
|
>you back a line that you can stick in your Xconfig file. has anyone seen
|
|
>something like this?
|
|
|
|
ok, so maybe it's bad form to answer my own question, but i'm going to anyway.
|
|
since i posted the question, i decided it couldn't be that hard to write such a
|
|
utility, and i turned out to be correct. it was really easy, in fact, which is
|
|
why it surprises me that no such utility is included with the linux
|
|
distribution (at least, not with slackware 2.0, which is what i used).
|
|
|
|
anyway, the following utility takes as input values for your dot clock and
|
|
horizontal sync frequency and an optional horizontal sync pulse length, and
|
|
gives you back a line of numbers you can stick in your Xconfig file. read the
|
|
header comment for details:
|
|
|
|
/*------------------------------8< cut here 8< ------------------------------*/
|
|
/* XFree86 video mode timing generator for Linux. use this to create video
|
|
* modes for your Xconfig file from dot clock values and horizontal sync
|
|
* frequencies. */
|
|
|
|
/* to see why all this works, read /usr/X11/etc/VideoModes.doc. I don't claim
|
|
* that this program is anything other than a quick hack because i didn't want
|
|
* to calculate another video mode manually. one was enough. :) */
|
|
|
|
/* all the usual public domain stuff applies to this software:
|
|
* copyright jason black, 1994. you are free to copy, redistribute, and use
|
|
* this software to your heart's content provided that you leave this comment
|
|
* intact when you redistribute, that you always include this source file when
|
|
* redistributing, and that you don't go trying to sell this to anyone to make
|
|
* a profit. if you are redistributing on floppy disk, magtape, or any other
|
|
* removable media, then you may charge up to as much as the media costs.
|
|
* basically, i don't want anyone trying to in any way limit availability of
|
|
* this program, nor do i wany anyone trying to make a profit off my labor. */
|
|
|
|
/* this program should be easy to compile, as it doesn't do anything even
|
|
* remotely sneaky. compile it like this:
|
|
|
|
gcc xmode.c -o xmode
|
|
|
|
* this program is also easy to use. invoke it with no flags to get usage
|
|
* information. here are two sample runs of the program so you can see how
|
|
* easy it is:
|
|
|
|
foo> xmode -dcf 85 -hsf 64
|
|
refresh rate for this mode: 60.03Hz
|
|
percent of hfl used: 72.88%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
1032x774 85 1032 1064 1384 1416 774 777 786 812
|
|
|
|
foo> xmode -dcf 85 -hsf 56.5 -hsp 3.5
|
|
warning: refresh rate is less than 60Hz for this mode.
|
|
refresh rate for this mode: 54.47Hz
|
|
percent of hfl used: 76.90%
|
|
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
|
|
1200x900 85 1200 1232 1528 1560 900 903 911 945
|
|
|
|
both of the above are actual results i got on my machine, and both were
|
|
functional video modes. the 1200x900 was too flickery to be usable, however,
|
|
which is why the less than 60Hz refresh rate warning is in there.
|
|
|
|
* note that while this program produces video modes that work, you will
|
|
* almost certainly have to tweak the hspstart and hspend values for your
|
|
* monitor. the program places the hsp more or less in the middle of the
|
|
* scanline, which may not be the best place for it for you. tweaking should
|
|
* be done in accordance with the tutorial in VideoModes.doc. specifically,
|
|
* hspstart, hspend, and hfl are the only numbers you should have to really
|
|
* mess with. hspstart and hspend should both be changed by the same amount if
|
|
* you change either. incrementing or decrementing hspstart and hspend will
|
|
* move the display right or left. incrementing or decrementing hfl will
|
|
* stretch or shrink the width of the display. all increments to these
|
|
* numbers must be in multiples of 8, as must horizontal timing numbers
|
|
* themselves. */
|
|
|
|
#include <stdio.h>
|
|
|
|
void main(int argc, char **argv);
|
|
void usage(char *argv0);
|
|
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen);
|
|
|
|
void main(int argc, char **argv)
|
|
{
|
|
float
|
|
/* input values: */
|
|
dcf = -1, /* dot clock frequency - from command line */
|
|
hsf = -1, /* horizontal sync frequency - from command line */
|
|
hsplen =3.8, /* length of horiz. sync pulse in microseconds */
|
|
|
|
/* calculated output values: */
|
|
hr = -1, /* horizontal resolution - calculated */
|
|
hspstart = -1, /* horizontal sync pulse start - calculated */
|
|
hspend = -1, /* horizontal sync pulse end - calculated */
|
|
hfl = -1, /* horizontal frame length - calculated */
|
|
vr = -1, /* vertical resolution - calculated */
|
|
vspstart = -1, /* vertical sync pulse start - calculated */
|
|
vspend = -1, /* vertical sync pulse end - calculated */
|
|
vfl = -1, /* vertical frame length - calculated */
|
|
|
|
/* intermediate values: */
|
|
hsp = -1, /* length of horiz. sync pulse in clock ticks */
|
|
linetime = -1, /* microseconds it takes for one scan line */
|
|
vsp = -1, /* length of vert. sync pulse in linetime units */
|
|
rr = -1 /* refresh rate */
|
|
;
|
|
|
|
int done = 0, hfl_last_tweaked = 0;
|
|
|
|
process_args(argc, argv, &dcf, &hsf, &hsplen);
|
|
|
|
/* now begins the fun stuff */
|
|
|
|
hfl = (int)(1000.0 * dcf / hsf); /* time for one scan line in dcf ticks */
|
|
hr = (int)(0.8 * hfl); /* shouldn't try and display more than 80% of hfl */
|
|
|
|
/* we need to engineer things so that hsp length is between 3.5 and 4 micro-
|
|
* seconds, and so that hfl - hfr = hsp (in clock pulses), and so that hfl,
|
|
* hfr, and hsp are divisible by 8. */
|
|
hsp = hsplen * dcf; /* 3.8 is in microseconds, hsp is in hsf clock pulses */
|
|
|
|
hsp -= (int)hsp % 8; /* force hsp to be a multiple of 8; round down */
|
|
hfl -= (int)hfl % 8; /* same for hfl */
|
|
hr -= (int)hr % 8; /* same for hr */
|
|
|
|
while(!done)
|
|
if(abs(hsp - (hfl - hr)) < 8) /* hsp and (hfl-hr) must be at most 8 apart */
|
|
done = 1;
|
|
else
|
|
{
|
|
if(hsp > (hfl - hr)) /* hfl and hr are too close together */
|
|
if(hfl_last_tweaked) /* alternately lower hr or raise hfl */
|
|
{
|
|
hr -= 8;
|
|
hfl_last_tweaked = 0;
|
|
}
|
|
else
|
|
{
|
|
hfl += 8;
|
|
hfl_last_tweaked = 1;
|
|
}
|
|
else if(hsp < hfl - hr) /* hfl and hr are too far apart */
|
|
if(hfl_last_tweaked) /* alternately raise hr or lower hfl */
|
|
{
|
|
hr += 8;
|
|
hfl_last_tweaked = 0;
|
|
}
|
|
else
|
|
{
|
|
hfl -= 8;
|
|
hfl_last_tweaked = 1;
|
|
}
|
|
else /* hfl - hr equals hsp. yay! */
|
|
done = 1; /* this is redundant, but who cares? */
|
|
}
|
|
hspstart = hr + 32; /* where the hsp pulse starts; 32 is magic. */
|
|
hspend = hr + 32 + hsp; /* where the hsp pulse ends */
|
|
hfl = hr + 32 + hsp + 32; /* calculate new hfl for that pulse configuration */
|
|
|
|
/* now we're done with the horizontal numbers. do a couple of checks: */
|
|
if (hr/hfl > 0.8)
|
|
fprintf(stderr,"warning: these values use more than 80%% of the hfl.\n");
|
|
rr = 1000*dcf/hfl;
|
|
if (rr < 60)
|
|
fprintf(stderr,"warning: refresh rate is less than 60Hz for this mode.\n");
|
|
fflush(stderr); /* just in case */
|
|
|
|
/* now do the vertical numbers */
|
|
vr = (int)(0.75 * hr); /* that 4:3 hr:vr screen ratio */
|
|
vfl = (int)(1.05 * vr); /* inverse of vr = .95 * vfl; we already know vr */
|
|
|
|
linetime = hfl / dcf; /* microseconds it takes for once scan line */
|
|
vsp = 150.0/linetime; /* number of scanlines worth of vsp */
|
|
vspstart = vr + 3; /* where the vsp pulse starts. 3 = guard time */
|
|
vspend = vr + 3 + vsp; /* where the vsp pulse ends; vspstart + vsp */
|
|
|
|
printf("refresh rate for this mode: %5.2fHz\n",rr);
|
|
printf("percent of hfl used: %5.2f%%\n",100*hr/hfl);
|
|
printf("mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl\n");
|
|
printf("%dx%d %d %d %d %d %d %d %d %d %d\n",
|
|
(int)hr,(int)vr,(int)dcf,
|
|
(int)hr,(int)hspstart,(int)hspend,(int)hfl,
|
|
(int)vr,(int)vspstart,(int)vspend,(int)vfl);
|
|
}
|
|
|
|
void usage(char *argv0)
|
|
{
|
|
fprintf(stderr,
|
|
"usage: %s -dcf dot_clock_freq -hsf horizontal_sync_freq [-hsp hsplen]\n",
|
|
argv0);
|
|
fprintf(stderr," -dcf is in MHz, no default value\n");
|
|
fprintf(stderr," -hsf is in kHz, no default value\n");
|
|
fprintf(stderr," -hsp is in microseconds, default value = 3.8\n");
|
|
exit(1);
|
|
}
|
|
|
|
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen)
|
|
{
|
|
int i;
|
|
|
|
if (argc < 5) usage(argv[0]);
|
|
if (argc%2 != 1)
|
|
{
|
|
fprintf(stderr,"error: each arg must be a name, value pair\n");
|
|
usage(argv[0]);
|
|
}
|
|
|
|
for(i = 1; i < argc; i+=2)
|
|
if(!strcmp(argv[i],"-dcf"))
|
|
sscanf(argv[i+1],"%f",dcf);
|
|
else if (!strcmp(argv[i],"-hsf"))
|
|
sscanf(argv[i+1],"%f",hsf);
|
|
else if (!strcmp(argv[i],"-hsp"))
|
|
sscanf(argv[i+1],"%f",hsplen);
|
|
else
|
|
{
|
|
fprintf(stderr,"unknown argument %s\n",argv[i]);
|
|
usage(argv[0]);
|
|
}
|
|
|
|
/* make sure both required args were given */
|
|
if(*dcf == -1 || *hsf == -1)
|
|
{
|
|
fprintf(stderr,"you must specify at least -dcf and -hsf values\n");
|
|
usage(argv[0]);
|
|
}
|
|
}
|
|
/*------------------------------8< cut here 8< ------------------------------*/
|
|
--
|
|
+-------------------------------------------------+---------------------------+
|
|
|tactical nuclear sdi stealth nsafood signature. | cloister@u.washington.edu |
|
|
+-------------------------------------------------+---------------------------+
|
|
|
|
|
|
------------------------------
|
|
|
|
From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
|
|
Crossposted-To: comp.os.linux.help
|
|
Subject: Re: driver wanted for NE3200
|
|
Date: 8 Sep 1994 17:14:07 -0400
|
|
|
|
In article <34eeru$2fg@lkxc01.telecom.ptt.nl>,
|
|
Andre Addicks <A.Addicks@telecom.ptt.nl> wrote:
|
|
>can somebody tell me if there a driver available for a NE3200
|
|
>network adapter ?
|
|
|
|
No, there isn't. And one is unlikely to be written.
|
|
|
|
--
|
|
Donald Becker becker@cesdis.gsfc.nasa.gov
|
|
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
|
|
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
|
|
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
|
|
|
|
------------------------------
|
|
|
|
|
|
** FOR YOUR REFERENCE **
|
|
|
|
The service address, to which questions about the list itself and requests
|
|
to be added to or deleted from it should be directed, is:
|
|
|
|
Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.misc) via:
|
|
|
|
Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Misc Digest
|
|
******************************
|