Subject: Linux-Misc Digest #734
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 10 Sep 94 15:14:25 EDT

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: [email-masked] (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 [email-masked]                         |
  | _  _    Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling       |
  |  \  \  \             IKEA Northern Europe AB, Sweden                    |
  | _/ _/ _/                                                                |
  +-------------------------------------------------------------------------+

------------------------------

From: [email-masked] (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 ([email-masked]) 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

[email-masked] (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.  | [email-masked] |
+-------------------------------------------------+---------------------------+

------------------------------

From: [email-masked] (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 ([email-masked]) wrote:
: Christopher Wiles ([email-masked]) 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 ([email-masked]) 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

[email-masked] (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.  | [email-masked] |
+-------------------------------------------------+---------------------------+

------------------------------

From: [email-masked] (Donald Becker)
Crossposted-To: comp.os.linux.help
Subject: Re: driver wanted for NE3200
Date: 8 Sep 1994 17:14:07 -0400

In article <[email-masked]>,
Andre Addicks <[email-masked]> 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                                     [email-masked]
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: [email-masked]

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: [email-masked]

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
******************************