I finally got a #9 GXE VL bus card which I am planning to use
with XFree86 2.0 once it's released.  However, I noticed some
odd behaviour while using it under both DOS and NeXTSTEP 3.1.

Unless I disable the internal cache, after a brief period of
time (until the cache begins to fill I imagine), the text on
the screen is somewhat mangled.  It is not complete garbage but
it is definitely somewhat corrupted.  Once NeXTSTEP gets into
VGA mode, this is manifested as a sqare area around the cursor
being damaged and leaving a trail of droppings as it goes.
Again, if I disable the internal cache on the motherboard,
things work OK (though, I suspect somewhat slower).

I'm not sure whether this is a problem with the #9 card, the
motherboard (I suspect), or DOS/NeXTSTEP.  A friend of mine
has an identical motherboard and has run it with an ATI GUP
(though not a VL bus version) and I'm wondering if I should
try to exchange the #9 for a VL bus ATI GUP.

The motherboard is a 486/33, AMI BIOS (12/12/93), not sure of
the chipset (SIS I believe).  If anyone has ideas or has had
similar experiences, I'd appreciate hearing from you.

Thanks!
Gary
--
Gary Thompson                                                gthomp...@lgc.com
Landmark Graphics  Houston, TX      Phone: (713) 560-1262  Fax: (713) 560-1277
     "Vending machines SHOULD respond to a [finger] request with a list
          of all items currently available for purchase..." -RFC1288

The framebuffer memory on your video card is being cached.  You need to
disable caching of that range of memory, in the AMI BIOS setup.

--
David Wexelblat <d...@mtgzfs3.att.com>  (908) 957-5871  Fax: (908) 957-5305
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

XFree86 requests should be addressed to <xfre...@physics.su.oz.au>

"If you don't expect too much from me, you might not be let down."
        -- Gin Blossoms, "Hey Jealousy"

Have not heard of any problems with the latest rev level of #9 cards
VLB or ISA with XS3 and NetBSD-0.8 or FreeBSD

Cheers,
        Amancio

--
This message brought to you by the letters X and S and the number 3
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail ha...@netcom.com    |  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming

The stated problem is more akined to a server problem rather than
a caching problem. The clue is that when the machine is running
with the internal cache disabled the graphic commands are probably
not being delivered fast enough to the cards. In the S3 928 databook
is not well stated how to determine when the graphic engine is
free for doing bitblts at least is different than the old S3 911 cards.

The S3 928 graphic queue is  16 entries deep and the S3 interface provides
for checking only 8 queue entries. For bitblt operations, the proper way to
wait is to check for the graphic engine to be idle, if you don't you will
get strange behavior.

At any rate we have tested the #9 S3 928 VLB with a fast 486DX266 and
found no such anomalies with XS3.

Since, the stated problem is with a commercial product I would suggest
to contact #9 and ask them if they have a solution to the problem.
Must say that #9s technical support is top-notch.

        Hope this helps,
        Amancio
--
This message brought to you by the letters X and S and the number 3
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail ha...@netcom.com    |  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming