  Tseng チップセットユーザ向けの情報
  The XFree86 Project, Inc.  Dirk H. Hohndel, Koen Gadeyne and
  others.
  03 Nov 1998
  The X Japanese Documentation Project
  03 Feb 1999
  ____________________________________________________________

  目次

  1. サポートしているチップセット
  2. 用語
  3. ET4000 ドライバの機能
  4. ET6000 ドライバの機能
  5. 一部の ET4000 ボードにおけるクロック値選択の問題
  6. テキストモードの復元に関する問題
  7. 基本設定
  8. XF86Config ファイルの全体に関するオプション
  9. リニアメモリのベースアドレス(MemBase)に関する事項
     9.1 MemBase 値を変えようとする「前に」知っておくべきこと
     9.2 MemBase 値の選択
     9.3 別のアプローチ
     9.4 他の試みが全て失敗したら…
     9.5 制限
     9.6 リニアモードでは単に動作しないボードがあります
     9.7 リニアアドレスが間違っているかどうかはどうやって調べるのですか?

  10. モードの問題
  11. アクセラレーションの問題
  12. ET6000 メモリサイズの嘘と真実
  13. ET6000 のメモリバンド幅に関する誇大広告と、ビデオモードへの影響
  14. リニアアドレッシングと 16bpp/24bpp/32bpp モード
  15. SVGA Tseng ドライバに関するトラブルシューティング
  16. 謝辞

  ______________________________________________________________________

  1.  サポートしているチップセット

  XFree86 がサポートしている Tseng チップセットは ET3000, ET4000,
  ET4000/W32, ET6000 です。SVGA ドライバは ET4000/W32, W32i, W32p,
  ET6000 のアクセラレーション機能もサポートしています。SVGA サーバとは別
  になっている 8bpp(=256 色)の ET4000/W32, ET6000 サーバに関する詳しい情
  報については、README.W32 を参照してください。

  お使いのハードウェアで XF86_SVGA が動作しない場合以外では、XF86_W32 を
  使うべきではない点に注意してください。W32 サーバに関する新規開発は行わ
  れていません。全ての労力は SVGA サーバに投入されるようになりました。

  現在のバージョン(XFree86 3.3.1)の SVGA サーバでは、ET4000W32 ISA カー
  ドの一部は動作しないことが明らかになっています(マシンがハングしてしま
  います…)。このようなカードの場合には W32 サーバ(XF86_W32) を使ってく
  ださい。

  2.  用語

  本ドキュメントの以降の記述では、"8bpp" を "8 bit per pixel" の略語とし
  ます。これは 256 色モードのことです。同様に、15bpp は 32768色モード
  を、16bpp は 65536 色モードを、 24bpp は "packed 形式" の 1600万色モー
  ドを、32bpp は "sparse 形式" の1600万色モードを示します(32bpp モードで
  も実際に使われるのは 32ビット中 24 ビットです。だから "sparse (疎な)形
  式" なのです)。

  ここでは 16bpp と区別するためだけに 15bpp を使いますが、通常はどちらも
  16bpp と言われます。15bpp は実際には 16bpp で、色の重みが 5-5-5 になっ
  ています(ピクセルごとに 1 ビット分が無駄になります)。一方、16bpp は
  16bpp で、色の重みが 5-6-5 となっています。

  3.  ET4000 ドライバの機能

  ET4000 チップセット用の SVGA ドライバは、ET4000W32i 以降のほとんどの
  ET4000 チップに対して全ての色の深さ(8, 15, 16, 24,32 bpp) をサポートし
  ています。ET4000W32 は 8bpp しかサポートしていません。RAMDAC と SVGA
  の対応コードに依存して、一部のカードでは色の深さの一部あるいは 8bpp だ
  けしかサポートしていないこともあります。

  W32i チップと W32p チップの場合、対応している RAMDAC (現在は ICS5341,
  STG170x ,Chrontel CH8398)で全ての色の深さがサポートされています。これ
  らのモードではアクセラレーションも有効です。

  W32p ボードの一部の実装においては、リニアメモリモードで使えるビデオメ
  モリが 1MB に制限されています。これはハードウェアの制限なので、ドライ
  バで解決することはできません。XFree86 では 16/24/32bpp モードを使うた
  めにリニアメモリが必要なので、ハイカラーやトゥルーカラーのアプリケー
  ションを使う場合には、このようなカードは極めて不便になってしまいま
  す(このようなモードでは大抵ビデオメモリを大量に使います)。

  さらに、このようなカードはリニアモードではアクセラレーションをサポート
  していません。これはドライバのコードを書くときの設計判断です。もしリニ
  アモードでアクセラレーションをサポートすれば、ビデオメモリは 768kB し
  か使えないでしょうし、ドライバのコードは倍くらい複雑になってしまうで
  しょう。

  まだサポートされていない RAMDAC を積んだカードは、古いカードと同じよう
  な制限を受けます。つまり、実際にはピクセルクロック値を 135MHz まで上げ
  られるところを最大値 86MHz に制限されます。その結果、1280x1024 モード
  はインタレースモードでしか使えず、非インタレースモードではリフレッシュ
  レート 75 Hz の 1024x768 程度に制限されます。

  W32 タイプのカードで非インタレースの 1280x1024x(256 色) 135MHz を使う
  には、RAMDAC の多重化の機能を持つ w32p(16 ビットの RAMDAC バスを搭載)
  が必要です。というのも、w32p は 135MHz ではなく (135/2 = 67.5) MHz し
  か参照しないからです。これにより、ICS5341 GENDAC, STG170x, CH8398 のい
  ずれかを使っているカード専用の特別なコードが必要となります。このコード
  は大抵の場合うまく動作するようですが、ICS5341 を使う場合だけは例外で、
  90MHz 付近の周波数で小さい縞が現われます。

  リニアメモリモード(特に xf86quake 等の DGA クライアントでは重要)は、全
  ての ET4000W32i, ET4000W32p カードでサポートされていますが、 ET4000W32
  ではサポートされていません。詳しくはリニアメモリに関するセクションを参
  照してください。リニアメモリに関する重要事項がいくつかあります。

  色の深さが大きい場合、リニアメモリモードは必要です。これらのモードの場
  合には、リニアメモリモードはデフォルトで有効になります。 XF86Config
  ファイルで指定する必要はありません。後述のリニアメモリに関するセクショ
  ンを参照してください。このセクションには、困難な問題を回避するための重
  要な情報が書かれています。

  8bpp モードで強制的に「バンク切替え」モードにするには(リニアメモリモー
  ドがデフォルトです)、以下の行を XF86Config ファイルの Device セクショ
  ンに以下の行を追加してください:

    Option "no_linear"

  W32 系と ET6000 系の全てのチップにおいてアクセラレーションはサポートさ
  れており、デフォルトで有効になっています。アクセラレーションのサポート
  は XFree86 の新しいアクセラレーションインタフェース(XAA)に基づいていま
  す。

  アクセラレーションを使っていて問題が起こる場合には、以下の行を
  XF86Config ファイルの Device セクションに追加して、アクセラレーション
  を無効にすることができます:

    Option "noaccel"

  PCI システムの一部(つまり、ET6000 や ET4000W32p だけ)では、アクセラレ
  ーションを使うとフォントが壊れてしまうことが時々起こります。この原因は
  多分、Tseng PCI デバイスには「プリフェッチ不可能」属性が設定されている
  ことを無視するシステム BIOS が、おかしな書き込みを行うことです。このよ
  うな BIOS は、"write combining(書き込み連結)"(または "byte merging")
  と呼ばれる PCI の機能を Tseng ビデオカードに対して有効にしますが、カー
  ドはこれを認めません。一部のシステムでは、 BIOS 設定において手動で
  Write Combining 機能(WC と省略されることもあります)の有効・無効を切替
  えることができます。VGA メモリアパーチャに対して WC が無効になっている
  ことを確認してください。

  システム上でフォントが壊れるけれど BIOS では手動で WC を無効にすること
  ができない場合、XF86Config ファイルの Device セクションに以下の行を追
  加してフォントのアクセラレーションを無効にすることができます:

    Option "xaa_no_color_exp"

  この設定を行うと X サーバの性能が落ちる点に注意してください。

  4.  ET6000 ドライバの機能

  ET4000 ドライバの機能に加え、SVGA ET6000 サーバは SVGA サーバで利用可
  能な全ての色の深さをサポートしています: 8bpp, 16bpp(色解像度は 5-5-5
  と 5-6-5 の両方), 24bpp, 32bpp.

  リニアメモリモード(VGA のデフォルトと逆で、バンク切替えレイアウトです)
  がサポートされています。リニアメモリモードは 16/24/32bpp モードの場合
  には必要であり、デフォルトで有効になります。8bpp の場合は、PCI カード
  ではリニアモードがデフォルトで、ISA/VLB カードではバンク切替えモードが
  デフォルトです。

  8bpp で強制的にリニアメモリモードにするには、XF86Config ファイルの
  SVGA セクションに以下の行を追加します:

    Option "linear"

  アクセラレーションがサポートされており、デフォルトで有効になっていま
  す。 ET6000 では全ての色の深さでアクセラレーションが有効です。
  XF86Config のデバイスセクションに以下の行を追加することで、アクセラレ
  ーションを無効にすることができます:

    Option "noaccel"

  全ての色の深さにおいて、ハードウェアカーソルがサポートされています。
  ET6000 のハードウェアの制限により、使える色の集合だけは制限されていま
  す(色の要素ごとに上位 2 ビット)。その結果、カーソルの色が(少し)おかし
  くなることがあります。カーソルの色が絶対に正確であることが必要な場合に
  は、ハードウェアカーソルを有効にしてはなりません。しかし、大抵のアプリ
  ケーションでは色の狂いは問題にならないでしょう。ハードウェアカーソルを
  有効にするには以下の指定を行います:

    Option "hw_cursor"

  ドットクロック値が高い(100MHz 辺りを越える値)ときにハードウェアカーソ
  ルを使うと問題が起こります。この問題は、画面の左半面から一部が出た時に
  カーソルが指す場所がおかしくなるというものです。

  ET6000 チップの古いリビジョンでは今のところ、ダブルスキャンモードでは
  ハードウェアカーソルが使えません。具体的には、カーソルの上半分しか表示
  されない状態になります。ダブルスキャンモード(320x200 がよく使われます)
  を使いたければ、ハードウェアカーソルを有効にしてはいけません。最近の
  ET6000 カードと ET6100 カードでは、この問題は現われません。

  一部の PCI システムでは、アクセラレーションを使うとフォントが壊れるこ
  とが時々起こります。先に説明したように、この原因はシステムの BIOS のバ
  グか、あるいは BIOS における write combining 機能の設定ミスです。BIOS
  を修正したり、オプションを強制的に無効にできない場合には、 XF86Config
  ファイルの Device セクションに以下の行を追加することにより、フォントの
  アクセラレーションを無効にすることができます:

    Option "xaa_no_color_exp"

  色の深さが大きいとき(24bpp, 32bpp)にアクセラレーションを用いると、高解
  像度モード(800x600 辺りより大きい解像度)で問題が起こります。これは、ア
  クセラレータの動作時に画面の右に一時的に「ゴミ」の線が現われるというも
  のです。ゴミはずっと残るわけではないはずです。これはサーバが解放されれ
  ばすぐに消えるはずです。この問題はメモリのバンド幅によるもので、回避す
  ることはできません(このようなモードを全く使わないという回避方法だけが
  あり、現在のドライバではこれを行っています)。

  この問題を無視するというのも一つの手です(破壊的な問題ではありませんか
  ら)。XF86Config ファイルの Device セクションでアクセラレーションを無効
  にするという方法もあります。アクセラレータが使われないので、このような
  問題を起こさないだけの広いバンド幅が確保できます。

  5.  一部の ET4000 ボードにおけるクロック値選択の問題

  XFree86 では、高解像度のテキストモードからサーバを起動すると、ET4000
  ボードの一部についてクロック値の選択を行うことができません。標準の
  80x25 のテキストモードからサーバを起動すると、クロック値の選択は必ず正
  しく行えます。

  サーバを高解像度のテキストモードから起動したときと、80x25 のテキストモ
  ードから起動したときで通知されるクロック値が異なる場合、この問題が起こ
  る可能性があります。高解像度のテキストモードからでもサーバを正しく動作
  させるために、XF86Config で指定できるオプションがいくつか用意されてい
  ます。セットするフラグを見つけるために、まずは 80x25 のテキストモード
  から -probeonly フラグを付けてサーバを起動し、サーバが出力する情報を見
  ましょう。

    VGAXXX: ET4000: Initial hibit state: low

  という行が出力された場合、XF86Config ファイルの SGVA, VGA16, VGA32 セ
  クションに次の行を追加します:

    Option "hibit_low"

    VGAXXX: ET4000: Initial hibit state: high

  という行が出力された場合には、XF86Config ファイルの SGVA, VGA16, VGA32
  セクションに次の行を追加します:

    Option "hibit_high"

  6.  テキストモードの復元に関する問題

  XFree86 1.3 では、一部で起こっていたテキスト復元の問題を軽減しようとし
  て、オプション ``force_bits'' が用意されていました。現在はこのオプショ
  ンの動作がデフォルトになっているので、このオプションそのものはなくなり
  ました。以前のテキスト復元の問題は、XFree86 2.0 では軽減されていること
  と思います。

  7.  基本設定

  XF86Config の作成には、XF86Setup プログラムまたは xf86config プログラ
  ムを使うことをお勧めします。これらのプログラムは、高解像度の 8bpp の設
  定できちんと動作する XF86Config ファイルを作ってくれるはずです。よりモ
  ニタに適したモード(例: 1152x864 モード)のタイミング値を Monitor セク
  ションに追加してもよいでしょう。ドライバのオプションの詳細については、
  次のセクションで説明します。ここでは基本的なオプションを簡単に説明しま
  す。

  アクセラレーションが使えるチップ(ET4000W32 と ET6000)でグラフィックス
  の再描画がおかしくなる場合には、まず "noaccel" を試してみてください。
  このオプションはアクセラレーション機能を全て無効にします。

  8.  XF86Config  ファイルの全体に関するオプション

  以下のオプションは Tseng ドライバのためのものです。各オプションは、
  XF86Config ファイル内の svga ドライバのセクションにある、オプションが
  適用できる色の深さの Screen サブセクションで指定しなければなりませ
  ん(Device セクションで指定すれば、全ての色の深さにおいてオプションを有
  効にすることができます)。

     Option "noaccel"
        (ET4000W32p, et6000) このオプションはアクセラレーション機能を無
        効にします。これにより、DRAM のタイミングや高いドットクロック
        値、アクセラレーション機能のバグに関連する問題が解決することが多
        いのですが、性能が犠牲になってしまいます(ローカルバスや PCI バス
        ではそれでも十分でしょう)。このオプションはアクセラレーションが
        サポートされているチップに対してのみ有効です。

     Option "fast_dram" "slow_dram"
        このオプションは、特定のカードの DRAM のスピードを設定します。カ
        ードは DRAM のスピードの設定ができるものでなければなりません。

        "slow_dram" オプションは ET4000 と ET4000W32 では常に有効にされ
        ます。有効になっている場合、DRAM のタイミングは遅くなり、メモリ
        関連の問題をいくらか避けることができます。起動時に画面が真っ暗に
        なる(システムがハングすることもあります)カードでは、このオプショ
        ンが必要かもしれません。 "fast_dram" オプションは、ドライバに
        DRAM のタイミングを速くさせます。これによっても画面関係の問
        題(筋、縞、ゴミ等)が直ることがあります。これらの問題をひどくする
        こともあります。一般的に、これらのオプションは危険です。サーバを
        起動した途端にマシンをクラッシュさせることもあります。注意して
        使ってください。

     option "w32_interleave_off" "w32_interleave_on"   (W32i, W32p)
        メモリインタリーブのオン/オフを指定します。W32i と W32p チップで
        は、ビデオメモリが 2MB 以上ある場合にメモリのバンド幅が広くなり
        ます。通常、 VGA BIOS は W32i と W32p を正しいモードに設定しま
        す。メモリのサイズ決定やインタリーブに関する問題の疑いがあれば、
        このオプションの周りをいじってみると状況が改善するかもしれませ
        ん。悪化することもあるかもしれませんが。これらのオプションは通常
        は必要ないものです。というのも、サーバが正しい値を自動的に使うか
        らです。このオプションにおかしな設定をすると、表示が全く変になっ
        てしまうでしょう。

     option "pci_burst_off" "pci_burst_on"   (W32p)
        PCI カードを使っている場合、このオプションは W32p チップの PCI
        バースト転送の有効/無効を切替えます。通常は、まともな BIOS なら
        マザーボードと VGA カードの設定を合わせるのですが、両者が一致し
        ていない場合には画面にゴミが出るでしょう(マウスの通った跡など)。
        これらのオプションを使うと、W32p のバースト転送の設定をマザーボ
        ードの設定と合わせることができます。

     videoram 1024 (または別の値)   (全てのチップ)
        このオプションは検出されたビデオメモリの量を上書きし、指定された
        量のメモリがカードに載っているかのように動作させます。このオプ
        ションは、カードにメモリが 2MB 載っているけれど DRAM の構成がド
        ライバがメモリの上位 1MB の部分を有効にする方法と互換でない場合
        や、メモリの検出がうまく行かない場合に役に立ちます。このオプショ
        ンは Device セクションで指定しなければなりません。

     Clockchip "et6000"  (et6000)
        このオプションはプログラマブルクロックを有効にしますが、明らかに
        ET6000 でしか使えません。このオプションは Device セクションで指
        定しなければなりません。サーバは ET6000 を検出すると通常、プログ
        ラマブルクロックを自動的に使います。このオプションを使うのは、自
        動検出がうまく動作していない疑いがあるときだけにしましょう。周波
        数によっては不安定になることがある(画面が「波打って」しまいま
        す)点に注意してください。安定だと保証できるのは、(デフォルトのク
        ロック値のように)試してみた周波数だけです。画面が乱れた場合に
        は、少しだけ異なる値(0.5MHz ずれている値など)を試してください。
        モニタはこの周波数に同期できるはずですが、クロックチップがこれで
        不安定な領域の外に出てくれるかもしれません。

     Option "linear"  (ET4000W32i, ET4000W32p, ET6000)
        このオプションはリニアアドレッシングを有効にします。これにより、
        フレームバッファ全体がシステムメモリより上位のアドレスにマップさ
        れ、フレームバッファ全体に直接アクセスできるようになります。この
        方法を使うと、遅い SVGA のバンク切替えが不要になります(バンク切
        替えでは、同時にフレームバッファの一部しか参照できません)。リニ
        アアドレッシングは 256 色時には性能が向上しますし、現在のところ
        16bpp, 24bpp, 32bpp では必ず使わなければなりません。

     MemBase 0xE0000000 (あるいは別のアドレス) (ET4000W32, ET6000)
        このオプションはリニアフレームバッファの物理メモリのベースアドレ
        スを設定します。このオプションは Device セクションで指定しなけれ
        ばなりません。このオプションは PCI でない場合のリニアアドレッシ
        ングの設定ではたぶん必要ですし、PCI ベースのシステムでも自動検出
        に失敗する時に役に立つかもしれません。しかし、ほとんど全ての PCI
        システムではこのオプションは不要です。後述のリニアメモリベースア
        ドレスに関する事項を読んでください!

        後述のリニアメモリベースアドレスに関する事項を読んでください!
        (ちゃんとした理由があってメッセージを繰り返しています。)
        このオプションを使うのは、サーバが使うデフォルトの MemBase 値で
        問題が起こる場合か、サーバがアドレスの指定を明示的に求めた場合だ
        けにしてください。

     Option "pci_retry" (ET4000W32p(PCI バス用), ET6000)
        このオプションは PCI バスのリトライ機能を有効にします。この機能
        は、ローカルバスや PCI バスベースのシステムにおける性能向上モー
        ドです。サーバが新しいアクセラレーション付き操作を開始しようとし
        ているけれど、アクセラレータがまだ前の操作のためにビジー状態に
        なっている時に、VGA コントローラはバスをホールド状態(待ち状態の
        ようなものです)にします。

        これは VGA カードを動かすための最速の方法(ビジー待ちループが不
        要)ですが、タイミング依存のデバイス(テープドライブ、サウンドカー
        ド等)に負担をかけてしまいます。トラブルシューティングのセクショ
        ンも参照してください。

  9.  リニアメモリのベースアドレス(MemBase)に関する事項

  最初に警告です: MemBase 値に誤った値を定義すると、(もちろんオペレー
  ティングシステムに)重大な被害を与えたり、殺したりします。特に、MemBase
  値にシステムメモリの範囲内の値を定義するのは、地獄への片道切符を渡すの
  と同じことです。

  9.1.  MemBase 値を変えようとする「前に」知っておくべきこと

  規則 #1: まずは、指定するのではなく、サーバ自身にメモリベース値を見つ
  けさせましょう。必ず全てのファイルをディスクに "sync" し、重要なアプリ
  ケーションも全て終了させてください。電源スイッチを即座に切る羽目になっ
  ても、絶対ファイルシステムに悪影響が出ないようにしておきましょう。

  最も危険なカードは VESA ローカルバス(VLB)用の ET4000W32p のリビジョン
  a と b です。このサーバはリニアベースアドレスを自動検出しますが、この
  値は全てのシステムでうまく使えるわけではありません。

  ほとんど危険のないカードは PCI バス用のカードです。PCI BIOS は通常正し
  い MemBase 値を割り当ててくれるので、以下に述べるようなごちゃごちゃし
  たことは全く行う必要がありません。

  サーバが間違った MemBase 値を取得した場合、システムがひどくクラッシュ
  してしまうかもしれません(例: ビデオメモリがシステムメモリとちょうど重
  なってしまった場合)。この場合、即座にリセットしてください。正常に
  シャットダウンしようとしてはいけません。というのも、X サーバが VGA メ
  モリへの書き込みを行っていると思いながら、実はシステムメモリへの書き込
  みを行ってしまうのです。つまり、壊れたデータがディスクに書き込まれてし
  まいます。サーバを起動する前に sync を実行していれば、被害は全く出ない
  (正常終了しなければならないファイルシステムのチェックだけ)でしょう。サ
  ーバの出力をテストを行っているシステムのファイルにリダイレクトしてはい
  けません(sync の後にデータを書き込むことになってしまいます)。

  これは最悪のケースのシナリオなので、こうなってしまうことは滅多にないで
  しょう。上記の説明は、読者の皆さんに適切な準備を必ずしてもらい、被害を
  出さないようにするためのものです。

  サーバが使えるリニアメモリベース値を見つけられない時には、実験を行うし
  かありません。これについて、このセクションの残りの部分で説明します。

  9.2.  MemBase 値の選択

  適切な MemBase を見つける作業は実にトリッキーです。カードが使っている
  MemBase 値を決める方法がない場合、システムメモリの数 MB 上の位置を試す
  のが最初の推定として良いものでしょう。例えば、メモリを 16MB 積んでいる
  システムの場合、MemBase 値に 0x01000000 (=16M) や 0x01400000 (=20M) を
  定義するとうまく動作するかもしれません。

  しかし、これは PCI でないシステムでしか動作しないと思います。というの
  も、PCI システムは大抵、2GB の点も越えて全てのハードウエアをマップする
  からです。しかし、繰り返しになりますが、PCI のシステムではサーバは正し
  いリニアベースアドレスをほぼ確実に検出することができます。唯一の例外は
  複数の PCI 用 VGA カードが付いているシステムの場合です。

  VESA ローカルバス(VLB)ボードの大部分では、アドレスのデコードに関する問
  題が別にあります。ほとんどのマザーボードはアドレス空間の最初の 32, 64,
  128 MB しか展開しません(これを確認する良い方法は、ボードに装着できる
  DRAM の最大量を調べることです。DRAM をサポートしている分のアドレス空間
  だけは少なくとも展開できるでしょう)。

  このようなボードの場合は、この範囲に収まる MemBase 値か、あるいはシス
  テムメモリに回り込んで戻ってくるような実アドレスを指定しなければなりま
  せん。後者の場合に、128MB のアドレスしかデコードしないシステムに対して
  MemBase を 128MB に設定すると、実際にはアドレス 0 としてデコードされま
  す。この値はおそらく、ちょうどカーネルメモリが配置されている場所でしょ
  う。これが、MemBase をシステムメモリのすぐ上に配置するという一般的なガ
  イドラインが最初に挙げられる理由です。こうしておくと、デコードされたボ
  ードのアドレス範囲の内部に実際に入っている見込みが十分あります。ただ
  し、これはマザーボードのメモリ空間全体が RAM で占められていない場合の
  ことです。

  9.3.  別のアプローチ

  マザーボードがデコードするメモリアドレス空間空間の大きさがわからない場
  合、0x1FC00000 のような「自明でない」アドレスを試してみましょう。この
  アドレスには"1" にセットされたビットがあり、たとえ一部がデコードされな
  くても全てのマザーボードでも動作します。0x10000000 等を使うと、マザー
  ボードがアドレスの上位ビットをデコードしない場合には、システムメモリと
  アドレスがちょうど重なってしまうことがある点を覚えておいてください。こ
  れを行うのは一度だけでしょう。

  9.4.  他の試みが全て失敗したら…

  一部の VLB ボードは 1GB を越える領域(0x80000000 以上)にしかリニアフレ
  ームバッファをマップできません。したがって、0x80000000 以上の MemBase
  値を使わなければなりません。

  この他にも、16MB 以下の領域にしかリニアフレームバッファをマップできな
  い VLB ボードがあります。ですから、メモリを 12MB 以下にしてシステムを
  起動して、MemBase 値を 0x00C00000 (=12M) に指定してみるのもよいでしょ
  う。 (一部のオペレーティングシステムでは、起動時にパラメータを指定して
  メモリの大きさを制限することができます。このようなオペレーティングシス
  テムでは、メモリの大きさを変えてみるためにコンピュータを分解する必要は
  ありません。)

  残念ながら、使っているシステムにアドレスを教えてやるための簡単な方法は
  存在しません(大抵の場合、詳しいことはマザーボードのマニュアルに書かれ
  ていません)。成功するためには試行錯誤しかないのです。サーバのコードで
  は大部分のボードでうまく動作するデフォルト値を用意しているのですが、こ
  こを読んでいるからには当然、読者の皆さんがお使いのボードはこれに該当し
  ていないのでしょう…。

  9.5.  制限

  リニアメモリのベース値を配置する場所については、制限がいくつかありま
  す。 ET4000W32 系の全てのボードでは、4MB 単位で指定しなければなりませ
  ん(つまり 16MB, 20MB に配置できますが、18M には配置できません)。
  ET6000 の場合には、16MB 単位で指定する必要があります(ET6000 ドライバは
  自動的にリニアメモリのベース値を決められるはずですので、そもそも
  MemBase 値を指定する必要はないはずです)。

  ET4000W32i の場合は面倒です。リニアアドレスのベース値はカードがハード
  ウェア的に持っているので、これをカードから読み戻す確実は方法がありませ
  ん。そこで、何らかの方法でこのアドレスを調べ、指定してやる必要がありま
  す。現在のコードでは賢い方法で推定しているのですが、保証はできません。

  ISA カードならば話はずっと簡単です。ISA では 24 個のアドレス線しか使わ
  ないので、リニアメモリは 16MB の範囲に収まらなければ「なりません」。
  ET4000 カードでは 4MB 単位でリニアメモリを指定しなければならないことも
  考慮に入れると、リニアメモリを使いたい場合には、マシンのシステムメモリ
  を 12MB より多くしてはならないということになります。したがって、ISA カ
  ードの場合に現実的に使える MemBase 値は 0x00C00000 だけです。この値は
  ISA の W32 カードをサーバが検出した場合に、サーバが自動的に選択する値
  でもあります。

  警告: コンピュータに 12MB を越えるシステムメモリを積んではいけません。
  積んでいる場合には、12MB を越える領域のメモリへのアクセスを全て無効に
  しなければなりません。一部のオペレーティングシステムでは、利用できるメ
  モリの量を起動時に指定することができるので、リニアメモリを使おうとする
  度に物理的にメモリを取り外す必要はありません。

  9.6.  リニアモードでは単に動作しないボードがあります

  その通りです。そういう場合は、運が悪いのです。

  動作しない理由は少なくとも 2 つ考えられます。

  最初の理由はありふれています。ボードのメーカーがリニアアドレッシングを
  使うために必要な配線やハードウェアを省いていることです。つまり、どんな
  に努力しても問題を解決することはできません。リニアアドレッシングが物理
  的に不可能なのですから。

  2番目の理由は、現在の XFree86 の Tseng 用のリニアアドレッシングのコー
  ドが、ボードの設計が想定している方法と互換でないことです。XFree86 の
  Tseng 用のコードでは、(ISA, VLB, PCI いずれも含む)バスのアドレス線と
  Tseng VGA チップのアドレス線が 1:1 で対応していることを想定していま
  す。こういうことはあまりないと思うので、たぶん原因ではないでしょう。

  このように 1:1 に対応していないボードもごくまれにあります(例: 2つのア
  ドレス線を入れ換えているもの)。このタイプのハードウェアをサポートする
  ことは可能ですが、現時点では実装は行っていません。

  他には、ボードがアドレスをデコードするハードウェアを外部に持っている場
  合があります。このハードウェアは、バスのアドレス線の数と VGA チップに
  繋がるアドレス線の数(少ない)を合わせるためのものです。

  このようなボードの 1 つは、3 つの NOR ゲート(74F02 チップ 1 つ)を使っ
  て 6 つの上位アドレスの線を W32i チップの 3 つのアドレスピンに接続して
  います。これは明らかに 2:1 のマッピングを表し、1:1 のマッピングではあ
  りません。したがって、このボードは XFree86 のリニアモード実装方法とは
  「互換」ではありません。

  9.7.  リニアアドレスが間違っているかどうかはどうやって調べるのですか?

  単純な話では: 全く動作しない、マシンが凍ってしまう、クラッシュしてしま
  う、その他諸々の問題が起きた時です。

  しかし、必ずしも明らかなわけではありません。問題が起こらないこともあり
  ます。単に画面が真っ黒になったり、画面にゴミが表示されたりしますが、ス
  クリーンに何も描画されません。最初のアプリケーションを起動した時にコア
  ダンプすることもあります。
  このような場合にアクセラレーションを有効にしていたら、ほぼ確実にサーバ
  の出力に"WAIT_ACL: timeout" というメッセージが複数回現われているでしょ
  う。この理由は、アクセラレータのレジスタもリニアメモリにマップされてい
  ることです。そして、もしリニアメモリが動作しなければ、アクセラレータも
  動作しません。

  しかし、WAIT_ACL のメッセージは必ずしもリニアメモリアドレスの誤りを意
  味するわけではない点に注意してください。このメッセージが出力される原因
  は他にもたくさんあります。しかし、8bpp のバンク切り替えモードの時には
  このメッセージが全く現われない場合には、リニアメモリの問題を考えるとよ
  いでしょう(「バンク切り替え」は「リニア」の反対のモードです。
  XF86Config ファイル中で "option linear" が指定されていなければ、デフォ
  ルトでバンク切り替えモードとなります)。

  10.  モードの問題

  ET4000W32/W32i/W32p と ET6000 におけるアクセラレーション付きのドライバ
  は、少なくとも 1KB の作業用空間をビデオメモリ上に必要とします。した
  がって、アクセラレーションを使う場合には、1MB のカードでは 1024x1024
  の仮想解像度は使えないはずです。これは、2.25MB の ET6000 カードの場
  合、 24bpp 時には 1024x768 モードでアクセラレーションが使えないという
  ことでもあります。なぜなら、表示で全てのメモリが使われてしまうからで
  す。

  同じことが ET6000 のハードウェアカーソルでも言えます。ハードウェアカー
  ソルも空きのビデオメモリを 1MB 必要とします。これだけのメモリが利用で
  きなければ、ハードウェアカーソルは使用できません。

  ET6000 でないカードの場合、高いドットクロック周波数を使うと、グラ
  フィックス操作の性能に悪影響が出ます(ET6000 の場合は影響がずっと小さい
  か、全く存在しません)。特に BitBlt 操作と、描画に使えるビデオメモリの
  バンド幅がほとんど残っていない時に性能が悪くなります。メモリのバンド幅
  は、 RAMDAC が画面に表示するためにデータを吸い出す間に、データがメモリ
  に送り込まれる速度です。

  ドットクロック値を高くすると(普通は高解像度と関連します)より多くのバン
  ド幅を使うので、フレームバッファに描画を行うためのバンド幅は少なくなり
  ます。アクセラレータが動作していると、データはいよいよ詰め込まれるよう
  になります。なぜなら、最近のアクセラレータは大量のバンド幅を使うことが
  できるからです(しかし、その代わりに高速に動作します)。色の深さが大きい
  と、さらに多くのバンド幅を必要とします。

  メモリのバンド幅が足りず(この話題に関する別のセクションを参照してくだ
  さい)動作が遅くなったり画面の「不調」が起こった場合には、指定できるう
  ちで最も遅いドットクロック値を試してください。例えば 14 インチや 15 イ
  ンチの画面で解像度を 800x600 とし、リフレッシュレートを高くし(ドットク
  ロック値が 50MHz)、仮想解像度を大きく取るのは悪くない考えです。

  Tseng チップは大抵メモリのバンド幅が(大変)良いことで知られています。で
  すから、問題が起こるのは高いクロック値の場合だけのはずです。

  メモリが 1 MB の ET4000W32 で、76Hz の時に解像度を 1024x768 にする場
  合、ドットクロック値を高く(85MHz)しても性能を上げるためには無意味で
  す。描画のためのバンド幅がほとんど残らなくなり、カードの動作がとても遅
  くなるでしょう。ドットクロックを 75MHz にすると 70Hz となり、この値な
  ら問題ないはずです。76Hz 時に 1024x768 を ドットクロック値 85MHz でサ
  ポートするモニタを使っている場合には、メモリ 1MB のカードはいずれにせ
  よ貧弱と言えます。

  ET4000W32i と ET4000W32p は、2つのバンク間での「インタリーブ」を用いて
  メモリのバンド幅をほとんど倍(+70%)にするという特殊な機能を持っていま
  す。これらのカードは 2MB にアップグレードすると大変効果があります。こ
  れは W32 カードや ET6000 カードには当てはまりません。

  11.  アクセラレーションの問題

  XFree Acceleration Architecture は VGA カードの未使用のビデオメモリを
  最大限に利用します。空いているビデオメモリの量が十分でなければ、アクセ
  ラレーション機能の一部が無効になったり制限されたりします。この場合には
  性能は悪くなります。

  そうならないようにするためには、既にアクセラレータが予約している 1KB
  に加えて、最低限 16KB の空きメモリを絶対に確保しましょう。

  実際には、これだけの小量のメモリを確保しても問題にはならないはずです。
  最近のカードの大部分はビデオメモリが 2MB あるので、1280x1024 モードで
  も多くのメモリが未使用のままです。デスクトップを 1600x1200 にしてさ
  え、 170KB 以上が未使用のままです。この領域はアクセラレータが性能向上
  のために使います。

  1MB カードのほとんどでは、256KB を未使用状態にすると、ちゃんとしたリフ
  レッシュレートで 1024x768 より大きいモードの表示を行えません。

  ある機能にアクセラレーションを効かせるために空きメモリを使う順序は以下
  のようになります。

  未使用のビデオメモリが全くないい場合(つまり、ビデオメモリが全て表示メ
  モリに使われている場合)には、アクセラレーションは全く使用できません。
  ET6000 でハードウェアカーソルを使うことさえできません。

  ハードウェアカーソルが有効で(ET6000 のみ)、かつビデオメモリが少なくと
  も 1KB 空いている場合、1KB がハードウェアカーソルのために使われます。

  この後に少なくとも 1KB 空きメモリが残っていれば、アクセラレーション機
  能もほとんどが有効になります。この際には追加のビデオメモリがさらに 1KB
  予約されます。

  まだ空きメモリがある場合、追加のアクセラレーション機能がいくつか有効に
  なります。これらの機能は、仮想スクリーンの幅と色の深さ(bpp)に依存し
  て、空きのビデオメモリをさらに必要とします。追加のアクセラレーション機
  能が使えるならば、サーバは使用するメモリの量を出力するでしょう。

  これでもまだビデオメモリが空いていれば、この領域はピックスマップの
  キャッシュとして使われます。これを使うと、小さなパターンやイメージをビ
  デオメモリに保持することができるので、必要となる度に毎回ビデオメモリに
  転送する必要が無くなります。バスを使ってビデオメモリにイメージを転送す
  る方法は、アクセラレータを使ってピックスマップキャッシュから表示メモリ
  に blit 操作を行わせる方法と比べてずっと時間がかかるので、このキャッ
  シュは有効です。

  12.  ET6000 メモリサイズの嘘と真実

  ET6000 は MDRAM (複数バンク DRAM)と呼ばれる特殊な種類のビデオメモリを
  使っています。このカードは 2 の乗数でない量の MDRAM(2.25MB や 4.50MB)
  を積んでいることがあります。特に 2.25MB MDRAM が一般的です。というの
  も、 RAM が 4MB 無くても 24bpp で 1024x768 をサポートできるからです。

  このカードについては分かりにくい問題がいくつかあります。

  まず最初に、4MB の制限を越えるようなメモリは全てお金の無駄です。なぜな
  ら、ET6000 はこのようなメモリを全く使うことができないからです。4.5MB
  くらいメモリを積んでいるボードもありますが、4MB を越える分の 0.5MB は
  無駄になります。 ET6000 がリフレッシュできる (M)DRAM は 4MB だけです
  (リフレッシュレジスタ)。このカードは VGA モードだと 64KB のバンク 64
  個にしかアクセスできません(バンク選択レジスタ)。アクセラレーション付き
  のコマンドの全ては、ビデオメモリ内部では 22 ビット(=4MB)のアドレスを使
  います。これでお分かりかと思いますが…ET6000 には 4MB の限界を越えるメ
  モリを使う方法は存在しません。

  次に(こちらの方が重要なのですが)、2.25MB のカードを使うことはできませ
  ん! ET6000 カードに関する報告がいくつかあるのですが、これによると
  ET6000 カードは MDRAM を 2.25 MB (たぶん)積んでいるものとして売られて
  いますが、これは標準の 2MB DRAM カードであることが明らかになっていま
  す。多くの人がこのカードを使ってずっとトラブル続きでしたが、これは使用
  した X サーバがメモリを 2.25MB(あるいは 2.5MB)として検出したためです。
  誤った値が検出されるのは、チップの内部的な設計や、BIOS の内容が誤って
  いるためです。このようなメモリ検出に関する問題は既に修正されているの
  で、サーバは正しい量のメモリを検出できるはずです。

  メモリの量が絶対に正しいという自信が無い限り、自分自身でメモリの量を
  XF86Config ファイルに指定してはいけません。

  カードに載っている MDRAM を量を確実に調べるための簡単な方法がありま
  す。

  ビデオカードを見てください。カードには ピンが 204 個付いている大きい
  チップがありますが、これが ET6000 です。ソケットに刺さっている長方形の
  チップ(大抵ステッカーが貼られていますが)が BIOS です。残りの大きいチッ
  プとしては、(大抵)以下のような印が付いている大きな正方形のチップ 2 つ
  か 4 つあります。

  MDRAM MD9xy     ("xy" は 2 桁の数字です) SJ-5-100  (これは違うかもしれ
  ませんが、レイアウトは同じでしょう)

  これら全ての隣には、4つの菱形の下に "MoSys" という名前をあしらった素敵
  なロゴがあります。

  "xy" の数字を見ると、1 つのチップのメガビットでのサイズが分かります。

  したがって、カードに載っている RAM の量は次のようになります:

  ("xy" * [MDRAM チップの数]) / 8    MB

  筆者のボードには、MD908 チップが 2 つ載っていたので、MDRAM の量は

  (08 * 2) / 8 = 2 MB

  ということになります。同様に MD909 チップを 2つ 積んでいるボードのメモ
  リは 2.25MB のようになります。

  現時点で存在する MDRAM チップには、MD904, MD906, MD908, MD909, MD910,
  MD916, MD918, MD920 があります。

  13.  ET6000 のメモリバンド幅に関する誇大広告と、ビデオモードへの影響

  Tseng はメモリのバンド幅について妄想を持っているようで、ET6000 のバン
  ド幅に関する報道関係へのアナウンスも例外ではありません。

  Tseng は、MDRAM を使っている ET6000 は 1.2GB/秒のバンド幅が出せるとい
  う信じられないことを言っています。これでは市場に出ているどんな製品も
  (SGI のグラフィックスワークステーションさえ)上回ってしまいます。

  「もし」利用できる最速の MDRAM を実際にボードに載せていれば、これは本
  当になるでしょうが、そんな RAM は載せていません。聞こえの良い 1.2GB と
  いう数字は、4 つの MDRAM チップを最大のクロックレートである 166MHz で
  使った時に出るものです。しかし設計による制限のため、最初の世代の
  ET6000 はメモリを 92MHz でしか駆動できません(ET6100 や ET6300 が出れば
  この数値は変わるでしょう)。

  つまり、現在の ET6000 ボードで実現できる理論的な最大のバンド幅は「たっ
  た」 320 MB/秒(MDRAM チップを 2 つ載せたボード)か 720MB/秒(MDRAM チッ
  プを 4 つ載せたボード)なのです。さらに、これは最善の場合を想定した数字
  です(すなわち、ここではバースト転送を極めて長いものとしていますが、実
  際には MDRAM は PCI バスと同様にアドレスバスやデータバスを共有しま
  す)。現実には、PCI バスとアクセラレータ両方から来る順序が不定のアクセ
  スにより、利用できるバンド幅の実効値はもっと低くなります。現在の
  ET6000 ボードの最大性能は、DRAM が 2 つまたは 4 つの場合で約 225MB/秒
  です。

  プレスリリースをどんなに見たところで、ET6000 のメモリのバスは 32 ビッ
  トです(128 ビットではありません。いずれにしても、この数字はチップ内の
  アクセラレータのデータ経路だけです)。つまり、このチップの 16 ビットバ
  スでは、MDRAM チップ 2 つだけでバスの容量を全て使ってしまいます。
  ET6000 ボードにメモリチップが 4 つ載っていても、メモリのバンド幅が増え
  るわけではありません。

  ある色の深さで利用できる最大の解像度は、メモリのバンド幅による制限を受
  けます。ET6000 の RAMDAC はどんな場合でも 135MHz でうまく動作できま
  す。しかし、RAM についてはそうではありません。32bpp (sparse 形式の
  1600万色モード)でピクセルクロック値を 135MHz にすると、メモリのバンド
  幅は 135*4 = 540 MB/秒が必要となります。これは現在の ET6000 ではどう
  やっても扱えません。PCI バスやアクセラレータの場合には、バンド幅をもっ
  と節約する必要があります。

  以上が、あるモードのために十分なメモリがあっても、MDRAM のメモリ配置に
  よっては使えないモードがある理由です。利用できるメモリのバンド幅が足り
  ない場合に起こる問題については、トラブルシューティングのセクションを参
  照してください。

  14.  リニアアドレッシングと 16bpp/24bpp/32bpp モード

  現在は 16 ビット(32768 色または 65536 色)、24 ビット(1600万色、packed
  形式)、32 ビット(1600万色、sparse 形式)のピクセルを SVGA サーバでサポ
  ートするには、リニアアドレッシングが必要です。この制限は将来のバージョ
  ンではなくなるかもしれませんが、最近のカードはほとんど全てが PCI バス
  を使っているので(リニアアドレッシングが問題となりません)、リニアアド
  レッシングを必須でなくすることの優先度は他の機能よりも低くなっていま
  す。深さ別に指定する Screen セクションで Option "linear" を指定する
  と、リニアアドレッシングを有効にすることができます。PCI ベースでないシ
  ステムの場合には、たぶん MemBase 値も設定する(Device セクション)必要が
  あるでしょう。また、自力で MemBase の場所を発見できない PCI システムの
  場合は、追加的な設定が必要です。

  現時点では、PCI でないカードはリニアメモリモードでサポートされていませ
  ん(あるいはうまくサポートされていません)。全くサポートしていないカード
  もありますし、アドレスのデコードにバグがあってうまく動作しないカードも
  あります。

  W32 と ET6000 の場合は大抵、8bpp サーバのアクセラレーション付き機能の
  多くは、16, 24, 32bpp モードをサポートするように実装されています。した
  がって、表示するビット数は 4 倍までになりますが、X サーバが重くなりす
  ぎることは無いはずです。24bpp と 32bpp は一部のカードでしかサポートさ
  れていない点と、少なくともメモリが 2MB あるカードでしかサポートされて
  いない点に注意してください。

  2.25MB の MDRAM を積んだ ET6000 はお買い得です。というのも、(利用可能
  なメモリを全て使って) 24bpp で 1024x768 をちょうどサポートできるからで
  す。他のビデオカードの場合は、これを行うためには少なくともビデオメモリ
  が 4MB 必要です。(M)DRAM が 2MB しかないと、期待できる最大の大きさは
  960x720 です。

  XF86Config ファイルの "Screen" セクションでは、実行しようと考えている
  全ての色の深さに対して "Display" サブセクションを定義しなければなりま
  せん。"Display" サブセクションではそれぞれ、Modes 値、仮想スクリーンの
  サイズを定義します。例(ビデオメモリ 2MB の場合)を以下に示します:
       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

  15.  SVGA Tseng ドライバに関するトラブルシューティング

  まず最初に、XF86Config で指定した中から選択したデフォルトのモードが、
  お使いのディスプレイでサポートされていることを確かめてください。つま
  り、水平同期の範囲が正しいことを確かめます。最初は(水平周波数 31.5 だ
  けを指定することにより)クロック値 25.175MHz で標準の 640x480x256 を使
  い、お使いの機器構成でドライバが動作することを確かめるとよいでしょう。
  使用されるデフォルトのモードは必ず、モード行に最初に書かれている行で、
  タイミングのセクションに書かれている、その解像度に対してリストされた最
  も高いドットクロック値を持つものになります。

  一般的なヒントをいくつか挙げておきます:

  o  Device セクションに Option "slow_dram" を追加します。

  o  Device セクションに Option "pci_burst_off" を追加します。

  o  Device セクションに Option "w32_interleave_off" を追加します。

  o  Hercules のモノクロのアダプタが付いていれば、これを外します。
     ET4000/W32 シリーズの多くの構成は、システムにこのカードがあると動作
     しません。

  o  ローカルバスが 33MHz で動作するマザーボードを入手します。
     ET4000/W32 ボードの多く(全てではなくても)は、50MHz のバスでは確実に
     動作がおかしくなります。待ち状態を 1 つか 2 つ入れる必要があるかも
     しれませんが、何はともあれまず試してください。

  o  マシンをコールドブートします。XF86_SVGA を実行する前には、(他の X
     サーバを含めて)ビデオハードウェアを変にするものを実行してはいけませ
     ん。

  o  ET6000 カードの場合は、Device セクションでチップセットに "et6000"
     を指定してみてください。このカードは通常、PCI バスから自動検出を行
     います。しかし一部のシステムでは、別のオンボードの VGA カードが載っ
     ていると(これを無効にしてあっても)ET6000 が間違った方のカードを使お
     うとすることがあります。

  VESA 標準モードタイミングの一部は、モニタによっては問題を起こすことに
  注意してください(水平同期パルスを増やすか(つまり、真中の 2 つの水平タ
  イミング値を増やす)、あるいは水平タイミングのパラメータを全て 16 や 32
  の倍数にしてみてください)。

     ビデオ信号は出ていますが、画面が同期しない
        モニタが扱えないモードを使っています。これが非標準のモードであれ
        ば、タイミングを少しずらす必要があるかもしれません。モニタが扱え
        るはずである標準のモードと周波数であれば、同様のモードと組み合わ
        せに対する別のタイミングを見つけてください。

     ドットクロック値を高くすると水平方向にぶれる
        この問題は、スクロールや blit 操作のような描画機能の動作中に特に
        顕著になります。現時点ではこの問題の簡単な解決方法はありません
        が、 "fast_dram" オプションを試したり、ドットクロック値を下げる
        などしてみてください。それでも不十分であれば、"noaccel" オプショ
        ンを使えばほぼ確実に問題が解決するでしょう(RAMDAC が使えるバンド
        幅が多くなるためです)。ほとんどの場合、この原因は RAMDAC に十分
        速くピクセルデータを送ることができないビデオメモリにあり、そのた
        めにゴミが出るのです。

     画面が「波打つ」
        画面全体が(描画操作とは無関係に)ずっと水平に揺れたり震えたりしま
        す。たぶんドットクロック値が高すぎるのでしょう。また、近い MCLK
        値が衝突していることも考えられます。このような場合には、ドットク
        ロック値を低くしてみましょう(0.5MHz だけ下げればうまく動作するこ
        ともあります)。モードのタイミングをずらしてみてもよいでしょう。
        水平方向の 2 番目の値を少し増やしてみてください。うまく動作する
        と思われる、ドットクロック値が 65MHz の 1024x768 (約 60Hz)の例を
        以下に示します:

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

     起動の後にクラッシュやハングする(たぶん画面は真っ暗になります)
        "noaccel" オプションを試してください。BIOS の設定が正しいことを
        確認してください。特に、0xa0000-0xaffff のキャッシュは無効にして
        ください。裏 DRAM のリフレッシュを無効にしても問題が解決するかも
        しれません。

        Linux システムの場合は、カーネルで「APM」(電源管理)のサポートを
        有効にしていると、X サーバが省電力モードや画面が真っ暗な状態で起
        動することがあります。APM のサポートを無効にしてカーネルを再構築
        してください。

     グラフィックス操作を行った後にクラッシュやハングしたり、画面にゴミ
        が表示される
        これはアクセラレーション付きの機能のいずれかのバグか、BitBLT エ
        ンジンの問題に関係するかもしれません。"noaccel" オプションを試し
        てください。また、BIOS の設定も確かめてください。

     サーバが `ACL: TIMEOUT' というメッセージを出力する
        前の項目と同じです。しかし一部のシステムでは、問題はどうやっても
        解決できません。これは使っているオペレーティングシステムに関連し
        ているかもしれません(この問題は Linux だけで見られ、カーネルのバ
        ージョンにまで依存します)。MemBase 値を変えると問題が解決するこ
        ともあります。

     テキスト中のピクセルが時々狂ったり、ウィンドウの枠を動かした時にゴ
        ミピクセルが出る
        おそらく MCLK 値の設定が高すぎることに関係しています(バンク切り
        替えモードで OK であっても、リニアアドレッシングモードで問題が起
        こることがあります)。(全てでなくとも)ほとんどの ET6000 カードは
        性能を出すために MCLK を少しオーバークロックして売っており(現在
        の標準値は 90 か 92 MHz です)、これにより問題が起こることがあり
        ます。現時点ではこれを解決する方法はありません。ゴミピクセルが一
        時的なもの(スクリーン上で動くものが無くなるとすぐ消える)であれ
        ば、おそらくメモリのバンド幅が原因です。唯一の解決方法はアクセラ
        レーションを無効にすることか、(これで解決しなければ)ピクセルク
        ロック値を低くすることです。

     テキストモードがうまく復元できない
        この問題は一部の機器で報告されています。Chipset 行の設定で問題が
        解決することがあります。通常はテキストモードのフォントをセットす
        るユーティリティを使えば、うまく復元ができるはずです(Linux の場
        合は setfont, runx, restorefont)。

     ドライバのアクセラレーション付きの機能を使うと、画面が真っ暗や真っ
        青になる
        アイコン(ピックスマップ)をいくつか表示しただけで画面が真っ暗や
        真っ青になるになる場合には、このセクションの内容が当てはまりま
        す。

        この現象には原因がいくつかあります。

        原因の 1 つはメモリの量が正しく検出(指定)されていないことです。
        サーバの自動検出機構が検出した値が多すぎる場合、アクセラレーショ
        ン付きの機能は動作しないでしょう。この場合には XF86Config ファイ
        ルでメモリの量を定義してください。この問題はメモリ 2.25 MB の
        ET6000 カードの一部で時々起こり、サーバが 2.25MB ではなく 2.5MB
        と検出するようです(この場合に限れば、videoram "2304" を追加して
        ください)。

        これでうまくいかない場合には、アクセラレーションを無効にする(オ
        プション "noaccel")しか解決方法はありません。

     DMA ハードウェアに関する問題(フロッピー、テープ)
        一部のシステムでは、アクセラレーション付きのサーバは ISA DMA を
        使う他のハードウェアと衝突します。最も顕著なのは、PC のフロッピ
        ーコントローラとサウンドカードです。フロッピーインタフェースは、
        バスを長く占有されすぎるとうまく動作できません。このような状態は
        アクセラレーション付きの大量の操作を行った時に起こります。例え
        ば、Linux-ftape モジュール(フロッピー-テープのドライバ)は、X サ
        ーバの使用中にバックアップの作成や書き戻しの操作を行うと、大量の
        「書き込みエラー」メッセージを出力します。このエラーは致命的なも
        のではありませんが、それはオペレーティングシステムがこういった情
        報をいかにうまく処理するかにかかっています。Linux はうまく処理す
        るようですが。

        解決法は 2 通り考えられます。"noaccel" オプションを使ってアクセ
        ラレーションを無効にするか、"pci_retry" を削除して PCI のリトラ
        イ機能(この機能はバスの遅延を大きくします)を無効にすることです。
        これにより、アクセラレーション付きの操作が少しだけ遅くなります。

        "pci_retry" が適用されるのは PCI バスのシステムだけではなく、他
        のバスの場合にも同様の影響を与えます。

     "Cannot read colourmap from VGA.  Will restore with default" という
        エラーが出る
        このエラーメッセージが出た場合、サーバは RAMDAC を正しく初期化で
        きず、デフォルトのカラーマップを復元しようとしています。一部のサ
        ポートされていない RAMDAC の場合、この動作は全ての色がまとめて削
        除されてしまうという悪影響を及ぼし、色がおかしくなってしまった
        り、画面が完全に真っ黒になってしまうでしょう。こうなった場合に
        は、XF86Config ファイルの Device セクションに ramdac "normal" と
        いう行を追加しましょう。大抵の場合、色の問題はこれで解決します。

     サーバが報告する ModeLine の値がピクセルクロックの半分だけなのです
        が?
        ET4000W32p カードを 8bpp で使う場合、75MHz 以上のクロックを使う
        一部のモード(例: ピクセルクロック値が 95MHz の 1152x910 モー
        ド)では、X サーバの出力に以下のメッセージが含まれます。

        (--) SVGA: Mode "1152x910" will use pixel multiplexing

        And later, when the accepted modelines are reported:

        (**) SVGA: Mode "1152x910": mode clock =  47.500

        ピクセルの多重化が行われているので、これは正常な動作です。クロッ
        クパルスごとにピクセル 2 つが RAMDAC に送られるため、半分のク
        ロックしか必要としません。

  他に画面描画関連の問題があれば、"noaccel" オプションを試してください。

  このドキュメントに書かれていないドライバ関連の問題に出会ったり、アクセ
  ラレーション付きの機能にバグを見つけた場合には、XFree86 チームに連絡し
  てください。

  実際のところ、報告(成功・失敗のいずれでも)は大歓迎です。特に、今までテ
  ストが行われていない機器構成の場合は助かります。報告を行うには、
  BetaReport フォーム を使います(report@XFree86.org 宛にメールで送ってく
  ださい)。www.xfree86.org に現われるベータリリースを待つのも良いでしょ
  う。

  16.  謝辞

  基本部分は古い XF86_W32 からもらいました。全ての Tseng のカードで SVGA
  サーバを動かすために、このコードを広範囲に渡って利用しました。ですか
  ら、このコードは今でもそれなりに有効と言えます。

  Glenn G. Lai さんがオリジナルの XF86_W32 サーバを書きました。これは
  Dirk Hohndel さんと Koen Gadeyne さんが修正し、対応ハードウェアを増や
  しました。

  Jerry J. Shekhel さん(jerry@msi.com) は筆者(GGL) にメモリ 1M の Mirage
  ET4000/W32 VLB ボードをくださいました。初期開発(X_W32)はこのカードを
  使って行いました。

  X11R6 と XFree86 プロジェクトには XF86_W32 の基本コードを頂きました。

  Hercules Computer Technology Inc. さんには、XF86_W32 の開発のために筆
  者(GGL)にメモリ 2MB の Hercules Dynamite Pro VLB ボードを貸していただ
  きました。また、XFree86 プロジェクトに Dynamite Power PCI を寄付してい
  ただきました。DHH がこのボードを使ってサーバの拡張を行いました。

  Tseng Labs さんには(KMG に) ET6000 ベースのボード(Jazz Multimedia G-
  Force 128)を寄付していただきました。これにより ET6000 コードの開発が大
  きく進みました。また、ET6100 の評価用ボードも提供していただきました。

  Heiko Eissfeldt さんには ET4000W32p_rev_b ボードを提供していただきまし
  た。これにより、rev_a と rev_b のボードのサポートを改善することができ
  ました。

  Gyorgy Krajcsovits さんには ET4000W32p + CH8398 ボードを提供していただ
  きました。素晴らしいことです!

  多くのテスタの方が X_W32 とそれに続く XF86_W32 にフィードバックを送っ
  てくれました。筆者の手落ちで X_W32 をテストしてくださった方は把握でき
  ていないのですが、XF86_W32 のテストに参加してくださった方々の名前を以
  下に挙げさせていただきます:

     Linux:
        bf11620@coewl.cen.uiuc.edu (Byron Thomas Faber)
        dlj0@chern.math.lehigh.edu (David Johnson)
        peterc@a3.ph.man.ac.uk (Peter Chang)
        dmm0t@rincewind.mech.virginia.edu (David Meyer)
        nrh@philabs.Philips.COM (Nikolaus R. Haus)
        jdooley@dbp.caltech.edu (James Dooley)
        thumper@hitchcock.eng.uiowa.edu (Timothy Paul Schlie)
        klatta@pkdla5.syntex.com (Ken Latta)
        robinson@cnj.digex.net (Andrew Robinson)
        reggie@phys.washington.edu (Reginald S. Perry)
        sjm@cs.tut.fi (M{kinen Sami J)
        engel@yacc.central.de (C. Engelmann) use cengelm@gwdg.de
        postgate@cafe.net (Richard Postgate)
        are1@cec.wustl.edu (Andy Ellsworth)
        bill@celtech.com (Bill Foster)

      FreeBSD:
        ljo@ljo-slip.DIALIN.CWRU.Edu (L Jonas Olsson)

  SVGA Tseng サーバのコードの開発に参加してくださった方々もいます(このリ
  ストは不完全です):

  o  Glenn G. Lai

  o  Dirk H. Hohndel

  o  Koen Gadeyne

  o  OEyvind Aabling

  o  Dejan Ilic

  o  Mark Vojkovich

  o  Harald Nordgard Hansen

  o  David Bateman

  o  Gyorgy Krajcsovits

  o  Kurt Olsen

  $XFree86: xc/programs/Xserver/hw/xfree86/doc/Japanese/README.tseng,v 1.1.2.2 1999/11/26 15:23:21 hohndel Exp $

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

