From: pmacdona@sanjuan (Peter MacDonald)
Subject: X, ET4000 and mice
Date: 9 May 92 22:23:27 GMT
Contrary to popular belief, having an ET4000 doesn't automatically
let you run X386. I have seen reports of some ET4000 cards that just
don't work.
Myself, I set up X under DELL UNIX at work using an ET4000 Ammazing card:
no problem. Now I am trying it at home with an ET4000 vga2max card with Linix.
Using the default "640x480" mode, it gives me four images on the screen,
complete with four pointers, four xterms, etc. I have mucked around for 4-5
hours trying different monitor settings, but no joy. It seems that Clock must
be wrong (half?) or something. I also found a 800x600 mode that gives me
6 windows! The card seems to have something called Hicolor mode (32K colors
I think).
Also, I have one of those switchable mouse (ACE). The logitech setting
works not at all, while with the MS setting, the buttons work but the mouse
movement doesn't. Using another alternate mouse, a logitech only (2button)
causes eratic movement.
Fortunately, I am just borrowing this equipment from work, so am not
saddled with it. But, the moral is: If you think just getting an
ET4000 card will let you run X with no problems, maybe.
Configuring the monitor section alone can be very tough. Anyone know
why you can install a VGA card under DOS, and it can display just fine
without knowing anything about the monitor? The card just uses various
Video Clock, Horz Sync, and Vert Sync combos. If the monitor doesn't
support it, you get the "Outer Limits" on screen.
But not X386. I like flexibility, but I think maybe a more usable
configuration would be one that just lets you supply the Clock/VSync/HSync,
and it would try some intelligent monitor timings. Actually, have tried
going through the video tutorial by Chin Fang. Even tried developing
a spreadsheet under oleo to do the calculations. But the real solution
is to use C code, and then incorporate it into a server as a configuration
option.
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 06:21:17 GMT
pmacdona@sanjuan (Peter MacDonald) writes:
>
>Contrary to popular belief, having an ET4000 doesn't automatically
>let you run X386. I have seen reports of some ET4000 cards that just
>don't work.
>
>Myself, I set up X under DELL UNIX at work using an ET4000 Ammazing card:
>no problem. Now I am trying it at home with an ET4000 vga2max card with Linix.
>Using the default "640x480" mode, it gives me four images on the screen,
>complete with four pointers, four xterms, etc. I have mucked around for 4-5
>hours trying different monitor settings, but no joy. It seems that Clock must
>be wrong (half?) or something. I also found a 800x600 mode that gives me
>6 windows! The card seems to have something called Hicolor mode (32K colors
>I think).
ah! but i already thought of this! one of the few nonstandard patches i
have applied to the server is the hiclock patch (which was discussed in
comp.unix.sysv386). if you find your clock halues are high, try adding
the line
vendor "hiclock"
in the vga256 section. i'd be interested to know if this works.
>
>Also, I have one of those switchable mouse (ACE). The logitech setting
>works not at all, while with the MS setting, the buttons work but the mouse
>movement doesn't. Using another alternate mouse, a logitech only (2button)
>causes eratic movement.
>
>Fortunately, I am just borrowing this equipment from work, so am not
>saddled with it. But, the moral is: If you think just getting an
>ET4000 card will let you run X with no problems, maybe.
>Configuring the monitor section alone can be very tough. Anyone know
>why you can install a VGA card under DOS, and it can display just fine
>without knowing anything about the monitor? The card just uses various
>Video Clock, Horz Sync, and Vert Sync combos. If the monitor doesn't
>support it, you get the "Outer Limits" on screen.
>
>But not X386. I like flexibility, but I think maybe a more usable
>configuration would be one that just lets you supply the Clock/VSync/HSync,
>and it would try some intelligent monitor timings. Actually, have tried
>going through the video tutorial by Chin Fang. Even tried developing
>a spreadsheet under oleo to do the calculations. But the real solution
>is to use C code, and then incorporate it into a server as a configuration
>option.
what a great idea! let me know when you're done! :-)
zorst
[obz@sisd.kodak.com]
--
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]
From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 07:40:07 GMT
In article <1992May10.062117.5370@sisd.kodak.com>
obz@sisd.kodak.com (Orest Zborowski COMP) writes:
>pmacdona@sanjuan (Peter MacDonald) writes:
>>
>>But not X386. I like flexibility, but I think maybe a more usable
>>configuration would be one that just lets you supply the Clock/VSync/HSync,
>>and it would try some intelligent monitor timings. Actually, have tried
>>going through the video tutorial by Chin Fang. Even tried developing
>>a spreadsheet under oleo to do the calculations. But the real solution
>>is to use C code, and then incorporate it into a server as a configuration
>>option.
>
>what a great idea! let me know when you're done! :-)
>
>zorst
>[obz@sisd.kodak.com]
>--
I believe somebody posted it a while ago on comp.unix.sysv386. Just aak
it over there.
H.J.
From: fangchin@leland.Stanford.EDU (Chin Fang)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 09:22:56 GMT
In article < 1992May10.062117.5370@sisd.kodak.com>,
obz@sisd.kodak.com (Orest Zborowski COMP) writes:
|> pmacdona@sanjuan (Peter MacDonald) writes:
|> >But not X386. I like flexibility, but I think maybe a more usable
|> >configuration would be one that just lets you supply the Clock/VSync/HSync,
|> >and it would try some intelligent monitor timings. Actually, have tried
|> >going through the video tutorial by Chin Fang. Even tried developing
|> >a spreadsheet under oleo to do the calculations. But the real solution
|> >is to use C code, and then incorporate it into a server as a configuration
|> >option.
|> what a great idea! let me know when you're done! :-)
I whole heartedly agree the timing stuff should be done in a manner that's
transparent to general users. But I will tell a bit of background why the
tutorial was written in the manner it is ...
The way I look at the timing calculation is basically a mult-objective
optimization problem. (Let's use non-interlace and multisync monitors for
discussion purpose) It is because
(1) if you want high resolution => you get low refresh rate
(2) on the other hand, if you want high refresh rate => you can't get
high resolution
So, some compromise has to be reached (thus multi-objective), and this
compromise is *really* subjective, varying from person to person, quite
tough to meet using a program :(
And, there are *real* constraints as well. The biggest constraint usually is
a monitor's horizontal sync upper limit, this is the main constraint for most
people. Normally most people have a video adapter which has far more capability
than his/her monitor (primarily due to cost). In addition, some early SVGA
cards using crystals don't have certain desirable dot-clocks, and that's
another constraint. Third one is the available display memory, which is
getting less important as 1MB equipped SVGAs and better are becoming more
common. There are few others that I will not elaborate here.
In short, this is a classical constrained optimization problem. One way
to solve it is to use Danzig's simplex method [a] or a simplex method
with BFGS update nonlinear programming [b] afterwards for polishing (geez,
what a fussy guy :). However, the big trouble I had (and still having!) is
that there is no way I can 100% sure about the constraint values that *my
program* gets. That is, it's not that hard to write a C code,
probing the hardware, and obtaining constraints discussed above. But
without extensive testing and validation, the timing suggested by such a code
would be almost untrust-worthy as a random guess as soon as it is used on
a unknown hardware. Thus it would be really imprudent to release it.
Therefore, I often look at the descriptions (in fact, basic algorithm in
disguise) in the timing tutorial with regret. Simply because mathematically
it's a very easy problem, but it is also ill-posed due to the fact that part
of the problem formulation data are not guaranteed to be i) available and
ii) accurate. Given the situation of the commodity PC market, I doubt such
a code would work for many :(
David Wexelblat at AT&T Bell Laboratories started collecting timing info
for various hardware a while back, primarily in comp.unix.sysv386. Early
on I naively thought that soon this database would grow very significantly
and thus I would have a good base to train a neural network code [c],
which, after trained using data in this database, would provide a good guess
(more precisely, interpolation, as neural network <=> glorified data
interpolator). But after months, even the latest version of X386 timing
data base is not as extensive as I would like to see. So another regret...
The problem is still nagging me however :) ...
Have a nice weekend.
Chin Fang
fangchin@leland.stanford.edu
=============================================================================
PS. yes, this is a nerdy post. But I believe some people must be thinking
more or less along the same line, so I list two references below
[a] D.G.Luenberger, Linear and Nonlinear Programming. Addison-Wesley,
Reading, Mass, 2nd, 1984, Chapter 3.
[b] op.cit, Chapter 9.
[c] Burnod, Adaptive Neural Network. Prentice Hall. 1992