








		      Information for Tseng Chipset Users

     The XFree86 Project, Inc.	Dirk H. Hohndel, Koen Gadeyne and others.

				  16 May 1997



1.  Supported chipsets

The Tseng chipsets supported by XFree86 are ET3000, ET4000, ET4000/W32 and
ET6000. Accelerated features of the ET4000/W32p and ET6000 are supported by the
SVGA driver. For details about the separate accelerated 8bpp (=256 color)
ET4000/W32 and ET6000 server, refer to README.W32.

Things that are known NOT to work with the SVGA server in this version (XFree86
3.3) are some ET4000W32 ISA cards (they hang the machine... Use the W32 server
XF86_W32 for these cards!), and acceleration on ET4000W32i cards.

In the rest of this document, "8bpp" is short for "8 bits per pixel", which
means a 256-color mode. Similarly, 15bpp refers to 32768 colors, 16bpp to 65536
colors , 24bpp to a "packed" 16 million color mode, and 32bpp to a "sparse" 16
million color mode (at 32bpp, only 24 of the 32 bits are actually used, hence
the "sparse").

15bpp is only used here to differentiate it from 16bpp, but they are both nor-
mally referred to as 16bpp. 15bpp is actually 16bpp with a 5-5-5 color weight
(wasting one bit per pixel), while 16bpp is, well, 16bpp, with 5-6-5 color
weight.


2.  ET4000 driver features

The SVGA driver for ET4000 chipsets supports all color depths (8, 15, 16, 24
and 24 bpp) on most ET4000 chips starting with the ET4000W32i. The ET4000W32
only supports 8bpp. Depending on the RAMDAC and the support code in the SVGA
server, some cards may only support a few of these color depths, or even only
8bpp.

On W32p chips all color depths are supported on the supported RAMDACs (cur-
rently ICS5341, STG170x and Chrontel CH8398). These modes are also accelerated.
On W32i chips, only AT&T49x compatible RAMDACs will support 16 and 24 bpp
modes, and there is no acceleration support (yet).

W32p revision a and b chips are limited to 1 MB of video memory in linear mem-
ory modes with acceleration (i.e. in 16/24/32 bpp modes). This is a hardware
limitation.

Cards with a RAMDAC that is not yet supported will be limited in a similar man-
ner as the older cards, i.e. to a maximum pixel clock of 86 MHz, whilst they
actually might be able to go up to 135 MHz. As a result, 1280x1024 modes will
only be possible when using interlacing, and non-interlaced modes are limited


 Information for Tseng Chipset Users





 Information for Tseng Chipset Users



to about 1024x768 at 75 Hz refresh.

For a non-interlaced 1280x1024x(256 colors) at say 135-MHz, you need a w32p
(with its 16-bit RAMDAC bus) with a multiplexing RAMDAC so that the w32p sees
only (135/2 = 67.5) MHz, not 135 MHz. This requires special code only provided
for cards using the ICS5341 GENDAC or the STG170x. This code seems to work fine
for most people, except, with the ICS5341, for a small band of frequencies
around 90MHz.

Linear memory mode (especially important for some DGA clients, and required for
16/24/32 bpp modes) is supported on all ET4000W32i and ET4000W32p cards, but
not on the ET4000W32. On ET4000W32p revision a and b, linear memory is limited
to 1 MB.

For the higher color depths (16, 24 and 32 bpp), linear memory mode is
REQUIRED. It is enabled by default in these modes. There is no need to specify
that in the XF86Config file. Please read the section on linear memory below: it
contains some vital information on how to avoid serious problems.

To force linear memory mode at 8bpp modes, put the following in the Device sec-
tion of your XF86Config:

       Option "linear"

Acceleration support is present, and enabled by default, for W32p chips (not
yet for W32i, but that's being worked on). This is based on the new XFree86
acceleration interface (XAA). See also README.W32.

If you have problems with acceleration, acceleration can be disabled by putting
the following in the Device section of your XF86Config:

       Option "noaccel"

On some (fast) systems, acceleration may cause occasional font corruption.
Until this problem is fixed, font acceleration may be disabled using the fol-
lowing in the Device section of your XF86Config:

       Option "xaa_no_color_exp"


3.  ET6000 driver features

In addition to the features in the ET4000 driver, the SVGA ET6000 server sup-
ports all possible color depths in the SVGA server: 8bpp, 16bpp (both at 5-5-5
and 5-6-5 color resolutions), 24bpp and 32 bpp.

In order to be able to run at a depth of 16bpp, 24bpp, or 32bpp, and to improve
performance at 8bpp, linear addressing must be enabled.

Linear memory mode (as opposed to the default, banked memory layout) is sup-
ported. It is required and enabled by default for the 16/24/32 bpp modes.  For
8bpp, the default is banked mode.

To force linear memory at 8bpp, put the following in the SVGA section of your








 Information for Tseng Chipset Users



XF86Config:

       Option "linear"

Acceleration is supported and is enabled by default, and accelerates all color
depths on the ET6000. Acceleration can be disabled by adding the following in
the Device section of your XF86Config:

       Option "noaccel"

The hardware cursor is supported in all color depths. Due to a hardware limita-
tion in the ET6000, only a limited set of colors is supported (2 significant
bits per color component). This may cause some (small) cursor color errors. If
absolute cursor color accuracy is required, the hardware cursor should not be
enabled. However, in most applications, this will not be a problem. The hard-
ware cursor can be enabled using

       Option "hw_cursor"

There is a problem with the hardware cursor at high dotclocks (above approx.
110MHz) at which point the cursor does strange things when partly off the left-
hand side of the screen.

Doublescan modes currently don't work with the hardware cursor: only the top
half of the cursor is visible. If you want to use DoubleScan modes (320x200 is
a popular one), then do not enable the hardware cursor.

On some fast systems, acceleration may cause occasional font corruption. Until
this problem is fixed, font acceleration may be disabled using the following in
the Device section of your XF86Config:

       Option "xaa_no_color_exp"

When using accelerated high color-depths (24bpp and 32bpp), high-resolution
modes (starting somewhere around 800x600) may cause temporary "garbage" lines
to the right of the screen while the accelerator is busy. The garbage should
not be persistent: it should go away as soon as the server is left alone. This
is a memory bandwidth problem, and thus cannot be resolved (except by not
allowing such modes at all, which is what is done in the current driver).

Ignoring it is one option (it isn't destructive). Disabling acceleration in the
Device section of the XF86Config file is another option: since the accelerator
is not being used, there is ample bandwidth to avoid such problems.


4.  Clock selection problems with some ET4000 boards

XFree86 has some problems getting the clock selection right with some ET4000
boards when the server is started from a high-resolution text mode.  The clock
selection is always correct when the server is started from a standard 80x25
text mode.

This problem is indicated when the reported clocks are different when the
server is started from the high-resolution text mode from what they are when it








 Information for Tseng Chipset Users



is started from the 80x25 text mode.  To allow the server to work correctly
from the high-resolution text mode, there are some Option flags that may be set
in XF86Config.	To find out which flags to set, start the server with the
-probeonly flag from an 80x25 text mode and look at the information printed by
the server.  If the line:

       VGAXXX: ET4000: Initial hibit state: low


is printed, put the following in the SVGA, VGA16 and VGA2 sections of your
XF86Config:

       Option "hibit_low"


If the line:

       VGAXXX: ET4000: Initial hibit state: high


is printed, put the following in the SVGA, VGA16 and VGA2 sections of your
XF86Config:

       Option "hibit_high"


5.  Basic configuration

It is recommended that you generate an XF86Config file using the XF86Setup' or
xf86config' program, which should produce a working high-resolution 8bpp con-
figuration. You may want to include mode timings in the Monitor section that
better fit your monitor (e.g 1152x864 modes). The driver options are described
in detail in the next section; here the basic options are hinted at.

If graphics redrawing goes wrong on accelerated chips (ET4000W32p and ET6000),
first try the "noaccel"; option, which disables all accelerated functions.


6.  general options in the XF86Config file

The following options are of particular interest to the Tseng driver. Each of
them must be specified in the svga' driver section of the XF86Config file,
within the Screen subsections of the depths to which they are applicable (you
can enable options for all depths by specifying them in the Device section).

      Option "noaccel"
	    (ET4000W32p, et6000) This option will disable the use of any accel-
	    erated functions. This is likely to help with some problems related
	    to DRAM timing, high dot clocks, and bugs in accelerated functions,
	    at the cost of performance (which will still be reasonable on a
	    local or PCI bus).	This option applies only to those chips where
	    acceleration is supported (currently ET4000W32p and ET6000).










 Information for Tseng Chipset Users



      Option "fast_dram" "slow_dram"
	    These options set the DRAM speed of certain cards where it applies.

	    The "slow_dram" option is always enabled on ET4000, and ET4000W32.
	    If enabled, it slows down DRAM timing, which may avoid some memory-
	    related problems. If your card starts up with a black screen (and
	    possibly a system hang), this option might be needed.  Not sup-
	    ported on ET6000.

	    The "fast_dram" option will cause the driver to speed up DRAM tim-
	    ings, which may also avoid screen-related problems (streaking,
	    stripes, garbage, ...). It may also increase those very same
	    effects. Not supported on ET6000.

      videoram 1024 (or another value)	 (all chips)
	    This option will override the detected amount of video memory, and
	    pretend the given amount of memory is present on the card. This is
	    useful on cards with 2Mbyte of memory whose DRAM configuration is
	    not compatible with the way the driver enables the upper megabyte
	    of memory, or if the memory detection goes wrong. It must be speci-
	    fied in the Device section.

      Clockchip "et6000"  (et6000)
	    This enables programmable clocks, but obviously only on the et6000.
	    It must be specified in the Device section. Normally the server
	    will automatically use this feature when it detects an ET6000. Use
	    it only when you suspect auto-detection is not working. Note that
	    some frequencies may be unstable (resulting in a `Wavy' screen).
	    Only tried and tested frequencies (like the default clocks) are
	    guaranteed to be stable. If this happens, try a slightly different
	    frequency in the modeline (like 0.5 MHz more or less). The monitor
	    should still be capable of syncing to this frequency, but the
	    clockchip may already be outside an unstable region.

      Option "linear"  (ET4000W32i, ET4000W32p, ET6000)
	    This enables linear addressing, which is the mapping of the entire
	    framebuffer to a high address beyond system memory, making the full
	    length of the framebuffer directly accessible. In this way, slow
	    SVGA bank switching (where only a small fraction of the framebuffer
	    is visible at one time) is not necessary. It enhances performance
	    at 256 colors, and is currently required for 16bpp, 24bpp, and
	    32bpp.

      MemBase 0xE0000000. (or a different address) (ET4000W32, ET6000)
	    This sets the physical memory base address of the linear frame-
	    buffer. It must be specified in the Device section. It may be
	    required for non-PCI linear addressing configurations, and might be
	    useful for PCI-based systems where auto-detection fails. However,
	    almost all PCI systems will not need this.

	    Read the section on linear memory base address issues below!

	    Read the section on linear memory base address issues below!  (Mes-
	    sage repeated on purpose)








 Information for Tseng Chipset Users



	    Use this option ONLY if you have trouble with the default MemBase
	    used by the server, or if the server explicitly states that you
	    must provide one.

      Option "pci_retry" (ET4000W32p on PCI bus, ET6000)
	    This enables the PCI bus retry function, which is a performance
	    enhancing mode for PCI bus-based systems, where the VGA controller
	    will put the PCI bus in a hold state (sort of like wait-states)
	    when the server tries to start a new accelerated operation but the
	    accelerator is still busy with the previous operation.

	    This is the fastest way to drive a VGA card (no busy-waiting loops
	    needed), but it also stresses some hardware that is timing-depen-
	    dent (tape drives, sound cards, etc). See also the trouble shooting
	    section.


7.  linear memory base address (MemBase) issues

First a WARNING: defining a bad MemBase may cause serious injury or death (to
your operating system, of course). Especially defining the MemBase to be inside
the range of system memory is a ticket to hell.

Rule #1: first, let the server find a memory base by itself, without specifying
it. Make sure you "sync" all files to disk and close all critical applications.
Make sure nothing bad will happen to your filesystems if you have to jump for
the power switch soon.

The most critical cards are the ET4000W32p rev a and rev b on VESA local bus
(VLB). The server will autodetect a linear base address that doesn't work on
all systems.

If the server gets it wrong, you may end up with a severe system crash (e.g.
if it maps the video memory right on top of your system memory). If this hap-
pens, RESET IMMEDIATELY. Do not try to shut down cleanly, because the X-server,
thinking it writes to the VGA memory, will write to system memory instead, and
you'll by writing corrupted data to disk. If you did a sync prior to starting
the server, there will be no harm done (only a filesystem check which should
end up clean). DO NOT attempt to redirect the server output to a file on the
system you're testing on (that will write data after you synced).

These are worst-case scenarios, and it is very unlikely this will happen to
you. The text above is to make sure you are properly prepared, so that nothing
serious happens.

When the server can't find a working linear memory base, it's time to experi-
ment. The rest of this section deals with that.

Choosing a suitable MemBase can be quite tricky. If you have no way of deter-
mining the MemBase your card uses, trying to put it a few Mb above the system
memory is a good first guess. E.g. if you have 16 Mb of RAM, defining MemBase
0x01000000 (=16M) or 0x01400000 (=20M) may work.

However, this may only work on non-PCI systems, as those mostly map all








 Information for Tseng Chipset Users



hardware above the 2GB mark. But then again, on PCI systems the server is
almost always able to detect the correct linear memory base address. The only
exception are those systems with more than one PCI VGA card.

On most VESA local bus (VLB) boards, there is an additional problem with
address decoding. Some motherboards only decode the first 32, 64 or 128 MB of
address space (a good pointer is to check the amount of DRAM that can be
installed on the board: it will at least decode as much address space as it
supports DRAM).

On such boards, you MUST specify a MemBase inside that range, or the actual
address may wrap back onto system memory. That is why the general guideline of
putting the MemBase just above the system memory is a sound one: it stands most
chance of actually being inside the decoded address range of the board. Unless
your motherboard's entire memory space is filled with RAM.

If you don't know how much memory address space your motherboard decodes (and
who does?), try using a "non-trivial" address, like 0x1FC00000, which has
enough bits set to "1" to work on any motherboard, even if a few are not
decoded. Keep in mind that using for example 0x10000000 may end up right on top
of your system memory if the motherboard doesn't decode all upper address bits.
You will only do that once.

Some other VLB boards can only map the linear framebuffer above the 1GB mark
(0x80000000 and up), so you must use a MemBase that is higher or equal to
0x80000000.

Unfortunately, there is no easy way to tell what system you have (these details
are mostly not in the motherboard manuals). Trial and error is the only road to
success here. The server code will provide a default that works on most
boards... but yours won't be one of those, of course.

There are some limits as to where the linear memory base may be put. On any
ET4000W32, it must have a 4MB granularity (i.e. it can be put at 16M or at 20M,
but not at 18M). On ET6000, it needs a 16M granularity (note: the ET6000 driver
should be able to determine the linear memory base automatically, so you should
never need to define MemBase in the first place).

On ET4000W32i, things are worse: the linear address base is hardwired on the
card, and there is no reliable way to read it back from the card. You need to
know the address in some way, and specify it. The current code does an intelli-
gent guess at it, but this is no guarantee.


8.  Mode issues

The accelerated driver on ET4000W32p and ET6000 uses 1K bytes of scratch space
in video memory. Consequently, a 1024x1024 virtual resolution should not be
used with a 1Mbyte card.

The use of a higher dot clock frequencies has a negative effect on the perfor-
mance of graphics operations on non-et6000 cards (the effect is much less, or
even non-existing, on ET6000 cards), especially BitBlt, when little video mem-
ory bandwidth is left for drawing. Memory bandwidth is the speed at which data








 Information for Tseng Chipset Users



can be pumped into the memory while the RAMDAC is pulling it out to display it
on the screen.

Higher dot-clocks (mostly related to higher resolutions) consume more band-
width, so that less of it is left for drawing into the framebuffer. With a
working accelerator, things become increasingly crammed, because modern accel-
erators can consume huge amounts of bandwidth (but they also give you high
speeds in return). High color depths also need extra bandwidth.

If you are short on memory bandwidth (see the separate section on this) and
experience blitting slowness or screen "glitches", try using the lowest dot
clock that is acceptable; for example, on a 14" or 15" screen 800x600 with high
refresh (50 MHz dot clock) is not so bad, with a large virtual screen.

Tseng chips are mostly known for their (very) good memory bandwidth, so you
should only start to see problems in the higher regions.

It does not make much sense performance-wise to use the highest clock (85 MHz)
for 1024x768 at 76 Hz on a 1 MB ET4000W32; the card will very slow, because
there is almost no bandwidth left for drawing. A 75 MHz dot clock results in 70
Hz which should be acceptable. If you have a monitor that supports 1024x768 at
76 Hz with a 85 MHz dot clock, an 1MB card is a poor match anyway.

The ET4000W32i and ET4000W32p have a special feature that almost doubles memory
bandwidth (+70%) using "interleaving" between the two banks. Upgrading to 2MB
is a real bonus on these cards.

ET6000-based cards however use MDRAM (multi-bank DRAM), which is much faster
than DRAM. Some 4 MB systems, with 4 MDRAM chips will also do interleaving,
which should give virtually unlimited memory bandwidth: theoretically >1GB/sec,
comparing to the already neat 90MB/sec on a 1MB ET4000W32i/p card). Most 4MB
models have only 2 MDRAM chips (as do the 2MB models). So far for the marketing
hype: a real ET6000 card is limited to somewhere around 225 MB/sec.


9.  Acceleration issues

The XFree Acceleration Architecture makes extensive use of the unused video
memory on the VGA card. If there is not enough free video memory, some acceler-
ation features will be disabled or crippled, resulting in less performance.

To avoid this from happening, try to keep an absolute minimum of 16 kb of free
memory, in addition to the 1kb already reserved by the accelerator.

In practice, this small amount of memory should not be a problem. Most cards
nowadays have 2 MB of video memory, and running 1280x1024 still leaves plenty
of memory unused. Even a 1600x1200 desktop will leave over 170kb unused, which
will then be used by the accelerator to enhance performance.

Most 1MB cards cannot display modes larger than 1024x768 with a decent refresh
rate, leaving 256kb unused.











 Information for Tseng Chipset Users



10.  ET6000 memory size facts and fiction

The ET6000 uses a special kind of video memory called MDRAM (multi-bank DRAM).
It may have a non-power-of-two amount of MDRAM: 2.25 or even 4.50 MB.  Espe-
cially 2.25 MB MDRAM is popular, since this can support 1024x768 at 24bpp with-
out needing 4MB of RAM.

There are a few less intuitive problems with this.

First of all, All memory above the 4 MB limit is a waste of money, because the
ET6000 cannot use this memory for anything at all. There are boards with 4.5 MB
around, but that extra 0.5 MB is a waste. The ET6000 can only refresh 4 MB of
(M)DRAM (refresh register). It can only access 64 banks of 64KB in VGA mode
(bank select register). All accelerated commands use a 22-bit address (=4MB)
inside the video memory. You get the idea...

And Secondly (more importantly): you may not have 2.25 MB at all! There have
been several reports about ET6000 cards that were sold with (supposedly) 2.25
MB of MDRAM, but which turned out to be standard 2MB MDRAM cards.  People have
been having trouble with these all along, since sometimes the X-server used to
detect this as 2.25 MB (or even 2.5 MB) due to internal chip design and also
due to faulty BIOSs. This memory detection problem has been fixed now, and the
server should detect the correct amount of memory.

Do NOT define the amount of memory in the XF86Config yourself, unless you are
absolutely sure about the amount. There is a simple way to determine the amount
of MDRAM on your card beyond doubt.

Look at the video card. There is one large chip with 204 pins on it, which is
the ET6000. One socketed rectangular chip, mostly with a sticker on it,is the
BIOS. The remaining chips are (mostly) 2 or 4 other large square chips on it
with the following markings:

MDRAM MD9xy	("xy" is a two-digit number) SJ-5-100  (this may differ, but it
will have the same layout)

and a nice logo next to all that with 4 diamonds and the name "MoSys" under-
neath.

The "xy" number tells you how much MEGABITS are in that one chip.

The amount of RAM on the card is then:

("xy" * number_of_MDRAM_chips) / 8    Mbytes

On my board, there are two MD908 chips, which means I have

(08 * 2) / 8 = 2 MB of MDRAM.

Boards with two MD909 chips have 2.25 MB, etc.

Current MDRAM chips are MD904, MD906, MD908, MD909, MD910, MD916, MD918 and
MD920.









 Information for Tseng Chipset Users



11.  ET6000 memory bandwidth hype and the impact on video modes

Tseng has always had wet dreams about memory bandwidth, and their press
announcements about the ET6000 memory bandwidth are no exception.

They claim the ET6000 using MDRAM is capable of reaching an incredible 1.2
Gbytes/sec of bandwidth. That would surpass just about everything on the market
(even SGI).

And that would be true, _if_ they actually used the fastest available MDRAMs on
their boards, which they don't. The stunning 1.2 GByte mark is only reached
when using 4 MDRAM chips at their max clock rate of 166 MHz. But due to design
limitations, the first-generation ET6000 can only drive the memories at 92 MHz
(that will change when the ET6300 hits the streets).

This means the max. theoretical bandwidth available on current ET6000 boards is
"only" 360 MB/sec on boards with 2 MDRAM chips, and 720 MB/sec on boards with 4
MDRAM chips. And this assumes a best-case situation (=extremely long bursts --
the MDRAMs use a shared address/data bus, much like the PCI bus does). In the
real world, unaligned accesses both from the PCI bus and the accelerator will
reduce the effective available bandwidth. The current ET6000 boards peak out at
about 225 MB/sec, with 2 or 4 MDRAMs.

Memory bandwidth limits the maximum resolution you can use at a given color
depth. The ET6000 RAMDAC can cope with 135 MHz in any situation. But the RAM
cannot. At 32bpp (sparse 16M color mode), using a 135 MHz pixel clock would
require a memory bandwidth of 135*4 = 540 MB/sec, which the current ET6000
boards simply cannot cope with. And then you still need some spare bandwidth
for the PCI bus and the accelerator.

That is why some modes will be refused, depending on your MDRAM memory layout,
even if the amount of memory would permit such a mode. See also the trouble
shooting section to see what can happen if too little memory bandwidth is
available.


12.  Linear addressing and 16bpp/24bpp/32bpp modes

Currently the 16-bit (32768 or 65536 colors), 24-bit (16M colors, packed
pixel), and 32-bit (16M colors, sparse) pixel support in the SVGA server
requires linear addressing. (This restriction may be removed in a future ver-
sion, but with nearly all new cards using the PCI bus (where linear addressing
poses no problem), removing the linear addressing requirement presently has a
lower priority than other features.) Option "linear" can be specified in a
depth-specific screen section to enable linear addressing; a MemBase setting
(in the device section) is probably also required on non-PCI based systems, and
optionally on PCI systems that have trouble finding out for themselves where
the MemBase is.

Non-PCI cards are not (or not well) supported in linear memory mode at this
moment. Some of them don't support it at all, and some of the ones that do have
so many address decoding bugs that it isn't feasible to provide a working solu-
tion.









 Information for Tseng Chipset Users



For the most part, many of the accelerated features in the 8bpp server have
been implemented to support 16, 24, and 32 bpp modes for the W32p and the
ET6000. So although there are now up to 4 times as many bits to display, the X
server shouldn't feel overly sluggish. Note also that the 24bpp and 32bpp modes
are only supported on a limited set of cards, and with at least 2Mb of memory.

An ET6000 with 2.25 MB MDRAM is cheap-and-sound, since it can support exactly
1024x768 at 24bpp (using all available video memory). On all other video cards,
you need at least 4MB of video memory to do this. With only 2MB of (M)DRAM,
960x720 is the best you can hope for.

In the XF86Config "Screen" section, a "Display" subsection must be defined for
each depth that you want to run, with separate Modes and virtual screen size.
Example (2Mb of video memory):

     Section "screen"
	 SubSection "Display"
	     Depth 8
	     Virtual 1280 1024
	     ViewPort 0 0
	     Modes "640x480" "800x600" "1024x768"
	 EndSubSection
	 SubSection "Display"
	     Depth 16
	     Virtual 1024 992
	     ViewPort 0 0
	     Modes "640x480" "800x600" "1024x768"
	 EndSubSection
	 SubSection "Display"
	     Depth 24
	     Virtual 960 720
	     ViewPort 0 0
	     Modes "640x480" "800x600"
	 EndSubSection
	 SubSection "Display"
	     Depth 32
	     Virtual 832 600
	     ViewPort 0 0
	     Modes "640x480" "800x600"
	 EndSubSection
     EndSection


13.  Trouble shooting with the SVGA Tseng driver

First of all, make sure that the default modes selected from your XF86Config
are supported by your monitor, i.e. make sure the horizontal sync limit is cor-
rect. It is best to start with standard 640x480x256 with a 25.175 MHz clock (by
specifying a single horizontal sync of 31.5) to make sure the driver works on
your configuration. The default mode used will always be the first mode listed
in the modes line, with the highest dot clock listed for that resolution in the
timing section.

Note that some VESA standard mode timings may give problems on some monitors








 Information for Tseng Chipset Users



(try increasing the horizontal sync pulse, i.e. the difference between the mid-
dle two horizontal timing values, or try multiples of 16 or 32 for all of the
horizontal timing parameters).

      There is a video signal, but the screen doesn't sync.
	    You are using a mode that your monitor cannot handle. If it is a
	    non-standard mode, maybe you need to tweak the timings a bit. If it
	    is a standard mode and frequency that your monitor should be able
	    to handle, try to find different timings for a similar mode and
	    frequency combination.

      Horizontal jitter at high dot clocks.
	    This problem shows up especially when drawing operations such as
	    scrolling or blitting are in progress. There is currently no easy
	    fix for this, You can try the "fast_dram" option, or use a lower
	    dot clock. If that is not sufficient, the "noaccel" option will
	    almost always help (it leaves more bandwidth for the RAMDAC). In
	    most cases, this is caused by the video memory not being able to
	    provide pixel data to the RAMDAC fast enough, so it gets fed with
	    garbage.

      `Wavy' screen.
	    Horizontal waving or jittering of the whole screen, continuously
	    (independent from drawing operations). You are probably using a dot
	    clock that is too high; it is also possible that there is interfer-
	    ence with a close MCLK. Try a lower dot clock (sometimes even drop-
	    ping it by 0.5 MHz may work). You can also try to tweak the mode
	    timings; try increasing the second horizontal value somewhat.
	    Here's a 65 MHz dot clock 1024x768 mode (about 60 Hz) that might
	    help:

		  "1024x768"	 65	 1024 1116 1228 1328	 768  783  789	818

      Crash or hang after start-up (probably with a black screen).
	    Try the "noaccel" option. Check that the BIOS settings are OK; in
	    particular, disable caching of 0xa0000-0xaffff. Disabling hidden
	    DRAM refresh may also help.

      Crash, hang, or trash on the screen after a graphics operation.
	    This may be related to a bug in one of the accelerated functions,
	    or a problem with the BitBLT engine. Try the "noaccel" option.
	    Also check the BIOS settings.

      `ACL: TIMEOUT' messages from the server.
	    Same as for the above entry. However, on some systems, the problem
	    will not go away no matter what you do. It may be related to the
	    operating system you use (it has only been seen on Linux systems,
	    and even then it depends on the kernel versions). Sometimes, choos-
	    ing another MemBase may help.

      Occasional erroneous pixels in text, pixel dust when moving window-frame
	    Probably related to MCLK setting that is too high (can happen with
	    linear addressing even though banked mode runs OK). Most (if not
	    all) ET6000 cards are sold with the MCLK slightly over clocked for








 Information for Tseng Chipset Users



	    performance (the current norm is 90 or 92 MHz), which may cause
	    these problems. There is currently no fix for this. If the pixel
	    dust is only temporary (it disappears as soon as nothing moves on
	    the screen anymore), then memory bandwidth is probably the cause.
	    The only solution is to disable acceleration, or, if that doesn't
	    help, using a lower pixel clock.

      Textmode is not properly restored
	    This has been reported on some configurations. Sometimes a Chipset
	    line will fix this. Normally you should be able to restore the
	    textmode font using a utility that sets it (setfont, runx, restore-
	    font on Linux).

      Mostly black or blue screen when using accelerated driver features
	    If you are seeing a mostly black or blue screen, with only a few
	    icons (pixmaps) displayed, this section applies to you.

	    There can be several causes for this.

	    One is if the amount of memory is not detected (or specified) cor-
	    rectly. If the server's autodetection mechanism detects too much
	    memory, accelerated features will not work. Define the amount of
	    memory in the XF86Config file. This seems to happen sometimes on
	    some 2.25 MB ET6000 cards, where the server detects 2.5 MB instead
	    (add videoram "2304" in this particular case).

	    If that doesn't help, disabling acceleration (option "noaccel") is
	    the only solution.

      Problems with DMA hardware (floppy, tape)
	    On some systems, the accelerated server will interfere with other
	    hardware that uses ISA DMA. Most notably is the PC floppy con-
	    troller and sound cards. The floppy interface cannot cope with
	    inordinately long bus-holds, which may occur during large acceler-
	    ated operations.  The Linux-ftape module for example (a floppy-tape
	    driver) will generate lots of "write error" messages when running a
	    backup or restore operation while the X-server is in use. These
	    errors should not be fatal, but that all depends on how well the
	    operating system handles these conditions. Linux seems to cope.

	    There are two possible solutions: disable acceleration using the
	    "noaccel" option, or disable PCI-retry (which is causing the large
	    bus delays) by removing the "pci_retry" option.  This will cause a
	    very small slowdown of accelerated operations.

	    The "pci_retry" option applies not only to the PCI bus systems, but
	    has a similar effect on other busses.

For other screen drawing related problems, try the "noaccel" option.

As a final fallback, consider trying the separate accelerated W32 server. It is
more mature, and has been tested more extensively as a result. See README.W32.

If you are having driver-related problems that are not addressed by this








 Information for Tseng Chipset Users



document, or if you have found bugs in accelerated functions, you can try con-
tacting the XFree86 team.

In fact, reports (success or failure) are very welcome, especially on configu-
rations that have not been tested. You can do this via the BetaReport form
(mail it to report@XFree86.org). You may want to keep an eye on forthcoming
beta releases at www.xfree86.org.

     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/tseng.sgml,v 3.15.2.9 1997/06/01 12:33:37 dawes Exp $





     $XConsortium: tseng.sgml /main/6 1996/10/27 11:06:09 kaleb $















































 Information for Tseng Chipset Users





































































				   CONTENTS



1.  Supported chipsets	..................................................... 1

2.  ET4000 driver features  ................................................. 1

3.  ET6000 driver features  ................................................. 2

4.  Clock selection problems with some ET4000 boards  ....................... 3

5.  Basic configuration  .................................................... 4

6.  general options in the XF86Config file  ................................. 4

7.  linear memory base address (MemBase) issues  ............................ 6

8.  Mode issues  ............................................................ 7

9.  Acceleration issues  .................................................... 8

10. ET6000 memory size facts and fiction  ................................... 9

11. ET6000 memory bandwidth hype and the impact on video modes	............ 10

12. Linear addressing and 16bpp/24bpp/32bpp modes  ......................... 10

13. Trouble shooting with the SVGA Tseng driver ............................ 11



























				       i



$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.tseng,v 3.24.2.9 1997/06/01 12:41:32 dawes Exp $
