[Q}] *Sigh* old-old et4000/X corruption of text modes..
jason
I've seen the question (and answer) posted earlier but it'd expired
by the time i tried to read it.. bleah.
3 other users and I all have et4000 based video cards.. and are running
Xfree 1.2 under Linux. The problem is that if you use a video more > 80x25
(something like 100x40 or 132x43 etc..), when you switch back to a VC,
or you kill the Xserver (using ctrl + backspace etc..), your text mode
gets corrupted.. and so far .. i've only found a reboot of the machine
is able to get out of this (yuk).
Any ideas how to get X *not* to do this or how to resume the text mode
prperly (however you want to phrase it) ? No, running in 80x25 just
isn't good enough outside of X ..
Appreciate any suggestions (and it'll save 3 other people bugging others
and posting :).
-jason
--
jason andrade ja...@coombs.anu.EDU.AU
Home: +613-7237185 ja...@carnegie.bf.rmit.OZ.AU
Work: +613-6603141 s91...@yallara.cs.rmit.OZ.AU
david.e.wexelblat
Define "corrupted". There are two cases that I've heard of:
1) The screen has lost sync when you switch back to text mode
2) The screen is fine, but the text itself is garbled.
(1) should be fixed in 1.3; we're still trying to figure out (2), which
seems to be a Linux-only phenomenon (or it well could be that you Linux
folks are the only ones who use other than 25x80 text mode).
--
David Wexelblat <dw...@mtgzfs3.att.com> (908) 957-5871 Fax: (908) 957-5627
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748
XFree86 requests should be addressed to <xfr...@physics.su.oz.au>
"How many times must good men die? How many tears will the children cry,
'til we suffer no more sadness? Oh, stop the madness. Stop all the madness."
-- Molly Hatchet, Fall Of The Peacemakers.
James A Conger II
Define "corrupted". There are two cases that I've heard of:
1) The screen has lost sync when you switch back to text mode
2) The screen is fine, but the text itself is garbled.
I had a case of "2" with a 2 year old PerfectView ET4000 card from
ViewSonic. The ROM copyright message said it was some sort of STB card.
Also, I had problems with 1024x768 mode in X and in Windows: pixels
would get randomly "left behind" when I moved a window.
I called ViewSonic and complained politely. They just as politely sent
me a free ROM upgrade. I now have v5.1 instead of v1.0 ROMS and the
copyright message now says I have an STB ERGO card. The text mode problem
"2" is gone and the random pixel problems seem to be gone, too.
Try your dealers/manufacturers. New ROMs might help.
Jim
--
James A. Conger II |jco...@magnus.acs.ohio-state.edu (personal)
Electrical Engineering Student|con...@cis.ohio-state.edu, osu-cis!conger (work)
The Ohio State University |con...@nes.nersc.gov (DOE Education Programs)
|CompuServe: 71213,54 (checked every 1-2 days)
david.e.wexelblat
Rabbit droppings (as I call the phenomemnon you describe :->) are almost
exclusively caused by hardware problems. Some things that I have seen that
cause this:
1) Video memory (0xA0000-0xAFFFF) is being cached. Video memory
should NEVER be cached.
2) Bus speed set too high for the video card to handle.
3) Bus speed set too low for the video card to handle (really -
I've had things work fine on an 11Mhz bus, and flake out on
an 8.33Mhz bus).
4) Dot-clock too high for video memory speed. Usually shows up in
cheap boards with 80 or 100ns DRAMs, and the video mode is using
a dot-clock above about 50MHz. A GOOD board should have 70 or
even 60ns DRAMs.
5) Poorly-designed 0-wait-state circuitry. Some boards go bonkers
at high dot-clock settings if the ISA-bus 0-wait-state mode is
enabled (which is usually is). In my experience, this problem
starts out as rabbit-droppings, and as the dot-clock gets higher,
can actually lock up the bus (and thereby hang the system).
In your case, changing the BIOS may have changed some of the timing
parameters between the ET4000 and the video memory, hence resolving the
problem on the bus itself.
This should probably be in the FAQ somewhere.