JPH0792654B2 - ビデオ・データ・フレーム伝送方法および装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】関連特許出願 以下に列挙した特許出願は、本出願に関連して出願さ
れ、現在継続中の特許出願であり、本明細書中で引用す
ることにより、本明細書の一部を構成するものである。

【０００２】（１）米国特許出願第９６７４８９号、１
９９２年１０月２３日出願（本出願の基礎になる米国特
許出願と同日出願）、発明の名称「リモート・バス上の
データ通路を使用許可する方法および装置」（Ｍｅｔｈ
ｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｅｎａｂ
ｌｉｎｇ Ｄａｔａ Ｐａｔｈｓ ｏｎ ａ Ｒｅｍｏ
ｔｅ Ｂｕｓ）。

【０００３】（２）米国特許出願第９６７４８８号、１
９９２年１０月２３日出願（本出願の基礎になる米国特
許出願と同日出願）、発明の名称「バス・ブリッジを介
したデータ通信方法および装置」（Ｍｅｔｈｏｄ ａｎ
ｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｍｍｕｎｉｃａ
ｔｉｎｇ Ｄａｔａ Ａｃｒｏｓｓ ａ Ｂｕｓ Ｂｒ
ｉｄｇｅ）。

【０００４】本発明はデータ伝送の過負荷を処理するこ
とに関し、さらに具体的には、マルチフレーム・イメー
ジを徐々に品質低下（ｇｒａｄｕａｌ ｄｅｇｒａｄａ
ｔｉｏｎ）させる技術に関するものである。

【０００５】なお、本明細書の記述は本件出願の優先権
の基礎たる米国特許出願第０７／９６７，４８７号（１
９９２年１０月２３日出願）の明細書の記載に基づくも
のであって、当該米国特許出願の番号を参照することに
よって当該米国特許出願の明細書の記載内容が本明細書
の一部分を構成するものとする。

【０００６】

【従来の技術】現在のコンピュータ・システムでは、多
種多様のグラフィックス、ビデオ、およびその他の形体
のデータを同時に表示している。しかし、多くのコンピ
ュータ・システムは、これらのすべてのタイプのデータ
をディスプレイ上で同時に更新し、表示するのに十分な
バンド幅の資源をもっていない。

【０００７】あるコンピュータ・システムでは、単に処
理できる以上のデータをユーザが要求するのを禁止する
ことにより、この問題を解決している。すなわち、コン
ピュータ・システムは、このような過負荷が起こるのを
禁止するために、まずすべてのソースより起こるピーク
要求量が最小限使用可能な資源をこえないようにしてい
る。例えば、ユーザがディスプレイ上に任意の時点にオ
ープンできるビデオ・ウィンドウの数が制限される場合
がある。しかしこの解決法によると、ソースまたはウィ
ンドウの数とビデオ表示品質との間のトレードオフの関
係において、ユーザがどれだけのデータ・ソースを表示
するかを判断することができない。また、要求量は常に
ピークであるとは限らず、また供給量は常に最小である
とは限らないので、使用可能な資源を効率よく使用する
ことができない。

【０００８】他のシステムでは、表示されるデータの各
フレームを、必要とするバンド幅を小さくするために品
質低下（ｄｅｇｒａｄｅ）させる種々の手法を採用して
いる。例えば、米国特許第４，７０３，４３９号では、
表示されるイメージの解像度を変えることによって過負
荷を回避している。しかし、このような手法によるとき
は、視覚的不快感を与えないような形で、解像度を低下
させるためには大量のビデオ処理が必要になる。

【０００９】別の公知手法では、到来ビデオ・ソースの
フレーム・レート（ｆｒａｍｅ ｒａｔｅ）を変えてい
る。例えば、毎秒１６フレームのビデオ・ソースを毎秒
８フレームのビデオ・ソースに変更してから、表示のた
めに伝送している。しかし、フレーム・レートが異なる
複数のビデオ・ソースが同時にスクリーンに表示される
場合があるので、どのビデオ・ソースのフレーム・レー
トを調整し、またはフレーム・レートの調整に割り振る
かが困難である。加えて、過負荷は非常に一時的な過負
荷である場合があり、フレーム・レートの調整が不要で
ある場合がある。

【００１０】

【発明が解決しようとする課題】本発明は上述した従来
技術の問題を解決することを目的にしている。

【００１１】

【課題を解決するための手段】このような目的を達成す
るために、請求項１に記載の発明は、表示すべきビデオ
・データのフレームを伝送する方法であって、 ａ）ビデオ・データのフレームの少なくとも一部を受信
するステップと、 ｂ）受信したビデオ・データをバッファにストアできる
かどうかを判断するステップと、 ｃ）受信したビデオ・データをバッファにストアできる
と判断した場合は、受信したビデオ・データをバッファ
にストアするステップと、 ｄ）受信したビデオ・データをバッファにストアできな
いと判断した場合は、ビデオ・データのフレームのどの
ビデオ・データも消去するステップと を具えたことを特徴とする。

【００１２】請求項２に記載の発明は、請求項１に記載
のビデオ・データ・フレーム伝送方法において、前記ス
トアするステップは、受信したビデオ・データを待ち行
列バッファにストアするステップと、待ち行列バッファ
を指しているポインタを更新するステップとを含むこと
を特徴とする。

【００１３】請求項３に記載の発明は、請求項２に記載
のビデオ・データ・フレーム伝送方法において、前記消
去するステップは、待ち行列バッファ内のロケーション
を指しているポインタを、消去するデータ・フレームの
前に移動するステップを含むことを特徴とする。

【００１４】請求項４に記載の発明は、請求項３に記載
のビデオ・データ・フレーム伝送方法において、ストア
されたビデオ・データを表示するステップをさらに具え
たことを特徴とする。

【００１５】請求項５に記載の発明は、請求項４に記載
のビデオ・データ・フレーム伝送方法において、ストア
されたビデオ・データを、該ビデオ・データの表示の前
にディスプレイ・アダプタへ伝送するステップをさらに
具えたことを特徴とする。

【００１６】請求項６に記載の発明は、請求項５に記載
のビデオ・データ・フレーム伝送方法において、受信し
たビデオ・データをディジタル化するステップをさらに
具えたことを特徴とする。

【００１７】請求項７に記載の発明は、表示すべきビデ
オ・データのフレームを伝送する装置であって、 ａ）ビデオ・データのフレームの少なくとも一部を受信
する手段と、 ｂ）受信したビデオ・データをバッファにストアできる
かどうかを判断する手段と、 ｃ）受信したビデオ・データをバッファにストアできる
と判断した場合は、受信したビデオ・データをバッファ
にストアする手段と、 ｄ）受信したビデオ・データをバッファにストアできな
いと判断した場合は、ビデオ・データのフレームのどの
ビデオ・データも消去する手段と を具えたことを特徴とする。

【００１８】請求項８に記載の発明は、請求項７に記載
のビデオ・データ・フレーム伝送装置において、前記ス
トアする手段は、受信したビデオ・データを待ち行列バ
ッファにストアする手段と、待ち行列バッファを指して
いるポインタを更新する手段とを含むことを特徴とす
る。

【００１９】請求項９に記載の発明は、請求項８に記載
のビデオ・データ・フレーム伝送装置において、前記消
去する手段は、待ち行列バッファ内のロケーションを指
しているポインタを、消去するデータ・フレームの前に
移動する手段を含むことを特徴とする。

【００２０】請求項１０に記載の発明は、請求項９に記
載のビデオ・データ・フレーム伝送装置において、スト
アされたビデオ・データを表示する手段をさらに具えた
ことを特徴とする。

【００２１】請求項１１に記載の発明は、請求項１０に
記載のビデオ・データ・フレーム伝送装置において、ス
トアされたビデオ・データを、該ビデオ・データの表示
の前にディスプレイ・アダプタへ転送する手段をさらに
具えたことを特徴とする。

【００２２】請求項１２に記載の発明は、請求項１１に
記載のビデオ・データ・フレーム伝送装置において、受
信したビデオ・データをディジタル化する手段をさらに
具えたことを特徴とする。

【００２３】請求項１３に記載の発明は、表示すべきビ
デオ・データのフレームを伝送するデータ処理システム
であって、 ａ）データを処理するプロセッサと、 ｂ）処理すべきデータをストアするメモリと、 ｃ）前記プロセッサに接続されたビデオ・アダプタであ
って、 ｉ）ビデオ・データのフレームの少なくとも一部を受信
する手段と、 ｉｉ）受信したビデオ・データをバッファにストアでき
るかどうかを判断する手段と、 ｉｉｉ）受信したビデオ・データをバッファにストアで
きると判断した場合は、受信したビデオ・データをバッ
ファにストアする手段と、 ｉｖ）受信したビデオ・データをバッファにストアでき
ないと判断された場合は、ビデオ・データのフレームの
どのビデオ・データも消去する手段とを有するビデオ・
アダプタと、 ｄ）ストアされたビデオ・データを、前記プロセッサの
指示を受けて前記ビデオ・アダプタから表示するディス
プレイと を具えたことを特徴とする。

【００２４】

【実施例】以下では、本発明の特徴および利点をさらに
理解するために、添付図面を参照して、本発明について
詳しく説明する。

【００２５】図１は、本発明の好適実施例で使用される
代表的なディジタル・コンピュータ１００を示すハイレ
ベル・ブロック図である。コンピュータはメイン・プロ
セッサ１１０を含み、メイン・プロセッサ１１０はメモ
リ１２０、入力デバイス１３０および出力デバイス１４
０に接続されている。メイン・プロセッサ１１０はシン
グル・プロセッサで構成することも、マルチプロセッサ
で構成することも可能である。入力デバイス１３０とし
ては、キーボード、マウス、タブレットその他のタイプ
の入力デバイスにすることが可能である。出力デバイス
１４０としては、テキスト・モニタ、プロッタ、その他
のタイプの出力デバイスにすることが可能である。メイ
ン・プロセッサは、グラフィックス・ディスプレイなど
のグラフィックス出力デバイス１５０にグラフィックス
・アダプタ２００を介して接続することも可能である。
グラフィックス・アダプタ２００は、グラフィックスに
関する命令を、バス１６０を通してメイン・プロセッサ
１１０から受信する。バス１６０は、他のアダプタと通
信するためにも使用できる。バス１６０経由でメイン・
プロセッサから命令を受け取ると、グラフィックス・ア
ダプタは、グラフィックス・アダプタ・メモリ２３０に
接続されたグラフィックス・アダプタ・プロセッサ２２
０と共にその命令を実行する。グラフィックス・アダプ
タ内のグラフィックス・プロセッサはこれらの命令を実
行し、その命令に基づいてフレーム・バッファ２４０を
更新する。グラフィックス・プロセッサ２２０として
は、描写（ｒｅｎｄｅｒｉｎｇ）すべき特定タイプのプ
リミティブを描写する専用描写・ハードウェアを有して
もよい。フレーム・バッファ２４０は、グラフィックス
出力デバイスに表示するピクセルごとにそのデータを収
めている。ＲＡＭＤＡＣ（ランダム・アクセス・メモリ
Ｄ／Ａ（ディジタル−アナログ・コンバータ）２５０
は、フレーム・バッファにストアされたディジタル・デ
ータを、グラフィックス・ディスプレイ１５０に送るＲ
ＧＢ信号に変換することによって、メイン・プロセッサ
からの所望グラフィックス出力を描写する。グラフィッ
クス・アダプタは、メイン・プロセッサ・バス１６０に
直結されていないマルチメディア・バス２６０経由で他
のアダプタと通信することも可能である。本発明は、マ
ルチメディア・バス２６０を使用することを目的として
いる。

【００２６】本発明によるマルチメディア・バス２６０
の好適実施例として、２つの場合について説明するが、
必要とするシステムの特性に応じて一方が好適となる。
１つは、ビデオ転送チャネル（ｖｉｄｅｏ ｔｒａｎｓ
ｆｅｒ ｃｈａｎｎｅｌ：ＶＴＣ）の場合の実施例であ
り、もう１つは、ビデオ転送チャネル−独立型（ｖｉｄ
ｅｏ ｔｒａｎｓｆｅｒ ｃｈａｎｎｅｌ−ｓｔａｎｄ
ａｌｏｎｅ：ＶＴＣ−ＳＡ）の場合の実施例である。
これらのチャネルの各々は共通する機能をいくつか備
え、また異なる機能をいくつか備えているが、これらに
ついても以下で説明する。

【００２７】図２は、メイン・プロセッサ・バス３０５
と並列のＶＴＣ３００を示すハイレベル・ブロック図で
ある。メイン・プロセッサ・バスはメイン・プロセッサ
３１５に接続されると共に、グラフィックス・アダプタ
３１０および他のアダプタ３２０、３３０に接続され、
可能ならば、他のアダプタにも接続されている。ＶＴＣ
はまたグラフィックス・アダプタ３１０および他のアダ
プタ３２０、３３０にも接続され、可能ならば、他のア
ダプタにも接続されている。アダプタ３２０、３３０と
しては、ビデオ・コンプレッサ（ｖｉｄｅｏ ｃｏｍｐ
ｒｅｓｓｏｒ）、外部アナログ・ソースのビデオ・ディ
ジタイザ（ｖｉｄｅｏ ｄｉｇｉｔｉｚｅｒ）、ビデオ
・デコンプレッサ（ｖｉｄｅｏ ｄｅｃｏｍｐｒｅｓｓ
ｏｒ）、または、多数の他のタイプのマルチメディア・
アダプタ（ＭＩＤＩミュージック・アダプタなど）の１
つにすることができる。この実施例では、メイン・プロ
セッサ・バスはＶＴＣに接続されていない他のアダプタ
に接続することが可能である。しかしながらこの実施例
では、ＶＴＣはメイン・プロセッサ・バス上のアダプタ
にだけ接続することができる。

【００２８】図３は、メイン・プロセッサ・バス３５５
に並列のＶＴＣ−ＳＡ３５０を示すハイレベル・ブロッ
ク図である。メイン・プロセッサ・バスはメイン・プロ
セッサ３６５に接続されると共に、グラフィックス・ア
ダプタ３６０に接続されている。メイン・プロセッサ・
バスは他のアダプタ３７０、３８０に接続されていな
い。ＶＴＣ−ＳＡはグラフィックス・アダプタ３６０と
マルチメディア・アダプタ３７０、３８０に接続され、
他のマルチメディア・アダプタに接続されている場合も
ある。アダプタ３７０、３８０は、ビデオ・コンプレッ
サ、外部アナログ・ソースのビデオ・ディジタイザ、ビ
デオ・デコンプレッサ、または、多数の他のタイプのマ
ルチメディア・アダプタ（ＭＩＤＩミュージック・イン
タフェースなど）の１つにすることができる。この実施
例では、メイン・プロセッサ・バスは、ＶＴＣに接続さ
れていない他のアダプタに接続することが可能である。
さらに、この実施例では、ＶＴＣ−ＳＡは、メイン・プ
ロセッサ・バス上にないマルチメディア・アダプタに接
続することができる。従って、この実施例は独立型（ス
タンドアローン）である。

【００２９】以下では、ＶＴＣおよびＶＴＣ−ＳＡにつ
いて詳しく説明する。

【００３０】ビデオ転送チャネル（ＶＴＣ） ＶＴＣは、タイム・クリティカル（ｔｉｍｅ−ｃｒｉｔ
ｉｃａｌ−即時処理）データ、特にビデオ表示データお
よび可能ならば、オーディオ・データのアダプタ相互間
における高速な通信を目的としたバスである。ＶＴＣ
は、マイクロ・チャネル（Ｍｉｃｒｏ Ｃｈａｎｎｅ
ｌ）や他のコンピュータＩ／Ｏまたはメモリ・バスに従
属するものと見ることができるが、その動作は完全に独
立したクロックとコントロールの下で行われる。これに
対してＶＴＣ−ＳＡは、自己完結型（ｓｅｌｆ−ｃｏｎ
ｔａｉｎｅｄ）バスとして動作することができる。この
中には、コマンド、応答、および圧縮されたマルチメデ
ィア・データの通信が含まれる。

【００３１】ＶＴＣ−ＳＡ以外のインプリメンテーショ
ンでは、ＶＴＣは、一般的には、自己完結型コンピュー
タ・バスではない。すなわち、一般的には、メイン・プ
ロセッサ・バスまたはマイクロ・チャネル（Ｍｉｃｒｏ
Ｃｈａｎｎｅｌ−ＩＢＭ社の商標）などの制御チャネ
ルを介してアダプタを初期設定し、制御する必要があ
る。ＰＣファミリ１（ＩＳＡ）バスや他のローカルに定
義されたバスなどの、他のバスを使用することも可能で
ある。ＶＴＣ上には、データ、およびアダプタ間の直接
通路上でデータを転送するために最小限必要な情報が搬
送される。

【００３２】ＶＴＣの使用する際の互換性は、いくつか
の異なるレベルになっている。カードのプラグ互換性
（ｐｌｕｇ−ｃｏｍｐａｔｉｂｉｌｉｔｙ）をもたせる
ためには、ＶＴＣ自体は別として、パッケージング、コ
ネクタ、電源、冷却、ソフトウェア・モデルその他の、
多くの面で互換性がなければならない。これらは、個々
のインプリメンテーションの詳細によって保証すること
ができる。ＶＴＣに接続されるチップは、同じ電子的お
よび入出力モデルに従っていれば、異なるＶＴＣ接続カ
ードに使用することが可能である。これらの点で異なる
チップは、その基礎となるＶＴＣロジック・アーキテク
チャが一定であるので、同じＶＴＣ設計マクロを使用す
ることができる。ＶＴＣは、ＩＢＭ ＰＳ／２（ＩＢＭ
社の商標）に見られる補助ビデオ拡張機能（Ａｕｘｉｌ
ｉａｒｙ Ｖｉｄｅｏ Ｅｘｔｅｒｎｓｉｏｎ）とは異
なる、固有の機能を備えているが、ＶＴＣをこの拡張機
能と共存させることが可能である。

【００３３】ＶＴＣは、非圧縮（ｕｎｃｏｍｐｒｅｓｓ
ｅｄ）のユーザ表示情報、特にピクセルをマシン内でや
りとりすることを主目標としている。ＶＴＣは他のデー
タを搬送する能力も備えている。典型的には、ビデオ・
アダプタに対する総入出力要求は、同じアダプタに要求
される非圧縮ビデオ・データ量の１％のオーダであるの
で、一般的には、ＶＴＣ上には、入出力データと制御信
号を搬送する十分なバンド幅があまる。

【００３４】ＶＴＣは、各種の表示機能に使用できるア
ーキテクチャに基づくインタフェースである。このアー
キテクチャによれば、広範囲にわたるシステムおよび機
能、ならびに、広範囲のパフォーマンス能力にわたって
互換性を保つことができる。

【００３５】本発明の好適実施例では、ＶＴＣは論理的
に３２ビット・バスであり、暗黙アドレスがマルチプレ
ックス制御フィールドに指定されている。また、同時並
行リアルタイム・オペレーションを直接にサポートする
マルチマスタ、マルチスレーブ・バスにすることが好ま
しい。バス上の信号とオペレーションはすべて、クロッ
ク同期式にすることが好ましい。ＶＴＣは、提供される
機能に必要な信号ライン数を最小化する設計になってい
る。好適実施例では、１６データ・ビットおよび６４デ
ータ・ビット構成のインプリテーションもサポートして
いる。

【００３６】物理層と電気層は、種々のプロダクト群で
想定されているテクノロジ群の特性と整合する高データ
・レートを実現する設計になっている。その結果、バス
信号ライン当たりのスループットは、多くの従来バスの
設計による場合よりも高くなっている。

【００３７】ＶＴＣは例えば、ディスプレイ・アダプタ
およびいくつかの処理機構や入出力機構といった、複数
のデバイスに接続することができる、双方向データ・チ
ャネルにするのが好ましい。ＶＴＣが目標とする主なデ
ータ・タイプは、非圧縮ディジタル・ビデオまたはグラ
フィックスである。ＶＴＣはディスプレイ・アダプタの
ディスプレイ・メモリに対するアクセスを提供し、その
場合、ＶＴＣ経由のデータ転送のタイミングを、モニタ
・スキャン・レートといった、すべての動作上のディス
プレイ・パラメータから独立させることができる。ま
た、ＶＴＣは、関係するデバイス間におけるビデオの通
信経路も提供する。

【００３８】好適実施例では、ＶＴＣまたはＶＴＣ−Ｓ
Ａに接続されるハードウェアは、マスタ・デバイスにす
ることも、スレーブ・デバイスにすることもできる。マ
スタ・デバイスとは、別のデバイスとの間でやりとりさ
れるデータの転送を開始するデバイスである。マスタ・
デバイスの代表例としては、生の（ｒａｗ）ディジタル
・ビデオのソース（発生源）がある。スレーブ・デバイ
スとは、マスタ・デバイスによって読み書きされるデバ
イスである。スレーブ・デバイスの代表例としては、デ
ィスプレイ・アダプタがある。

【００３９】単一の物理デバイスをマスタとしても、ス
レーブとしても動作させることも可能である。ディスプ
レイ・アダプタ・スレーブは、ＶＴＣを通してディスプ
レイ・メモリにアクセスすることができる。スレーブが
ＲＢＧやオーバレイ・プレーン（ｏｖｅｒｌａｙ ｐｌ
ａｎｅ）またはグラフィックス・イメージや自然イメー
ジなどの複数の層を有する場合は、好適実施例では、こ
れらのすべてをＶＴＣ経由でアクセス可能にして、最大
の機能が発揮されるようにしている。マスタは、スレー
ブのアドレスを指定し、読み書きするサンプルの開始ア
ドレスおよび量を、制御フィールドに入っている他の関
係情報と一緒に指定することによって、すべての転送を
開始する。これらについては、制御フィールドを参照し
ながら、あとで詳しく説明する。好適実施例では、ＶＴ
Ｃスレーブは、スレーブとやりとりする個別マスタの各
々のためにコンテキスト・メモリをもつ必要がない。転
送のために必要なコンテキスト情報は、マスタが制御フ
ィールドに入れて提供する。マスタとスレーブの間で通
信するために必要な追加コンテキスト情報はマスタに保
存されている。複数のマスタをＶＴＣに同時に接続する
ことが可能である。複数のマスタはそれぞれのアクセス
を時間的にインタリーブするので、複数の低速チャネル
を同時に動作させるのと同等のパフォーマンスが得られ
る。同様に、複数のスレーブをＶＴＣに接続することが
可能である。これらのアドレス指定は、ＶＴＣ転送オペ
レーション時に行われる。

【００４０】ＶＴＣの共用は、ラウンド・ロビン非優先
ハードウェア仲裁方式（ｒｏｕｎｄ−ｒｏｂｉｎ，ｎｏ
ｎ−ｐｒｅｅｍｐｔｉｖｅ ｈａｒｄｗａｒｅ ａｒｂ
ｉｔｒａｔｉｏｎ）で行うことが好ましく、その変更は
行動パラメータ（ｂｅｈａｖｉｏｒａｌ ｐａｒａｍｅ
ｔｅｒ）の使用によって行われる。その結果の仲裁行動
は、階層化した複数ラウンド・ロビン・リングのそれと
同じである。ラウンド・ロビンの行動パラメータと順序
は、ソフトウェアで実現することが好ましいスケジュー
リング・アルゴリズムによって判断される。このソフト
ウェアによって判断されるパラメータは、デバイスと必
要物（例えば、ウィンドウ）の構成が与えられていると
き静的であるので、複数のマスタが同時に活動するよう
に動的に再構成するとき必要になる場合があることを除
けば、ソフトウェアをリアルタイムにする必要はない。

【００４１】あるマスタがＶＴＣを許可されたとき、そ
のマスタは、明示にＶＴＣを放棄するまで制御権を保持
していることが好ましい。この場合、ＶＴＣを放棄した
時点で、そのマスタからリング内の次のマスタへ制御権
（仲裁トークン）が渡される。ラウンド・ロビンのアク
ションを変更する行動パラメータには、各マスタがＶＴ
Ｃを許可されたあとＶＴＣを保持することのできる最大
時間量と、以前に許可されたときから再び同じマスタが
許可を得ることができるまでの最小遅れ時間（ｍｉｎｉ
ｍｕｍ ｄｅｌａｙ）とがある。仲裁方式の詳しい説明
は後述する。行動パラメータをマスタで実行するための
レジスタについても後述する。

【００４２】マスタがデータをスレーブへ送るときのよ
うに、転送の際に、あるマスタからのデータを複数のス
レーブに同時に「ブロードキャスト」することが可能で
ある。これは、ＶＴＣ上のどの信号も駆動することな
く、追加のスレーブ（直接にアドレス指定されたスレー
ブ以外の）がＶＴＣ上で転送されるデータを受信するこ
とによって実現される。このアクションはＶＴＣのオペ
レーションに影響を及ぼすことがなく、以下では、この
アクションを「スヌーピング」（ｓｎｏｏｐｉｎｇ）と
呼ぶことにする。スヌープ・デバイス（ｓｎｏｏｐｉｎ
ｇ ｄｅｖｉｃｅ）は必要時にピクセル開始アドレスを
変換することを受け持ち、マスタとスレーブのＶＴＣ転
送に干渉してはならない。つまり、スヌープ・デバイス
はどのラインも、特にどのペーシング（ｐａｃｉｎｇ−
歩調合わせ）ラインも駆動することができない。

【００４３】ＶＴＣは、基本入出力バスをマイクロ・チ
ャネル（ＩＢＭ社の商標）として使用することが好まし
いが、その用途を種々の入出力バスまで拡張できるの
で、どの入出力バスなしでも使用することができる。そ
の場合は、レジスタ・マッピング、割込みの使用、その
他の理由により、アーキテクチャのシステム・インタフ
ェース層が変更される場合がある。例えば、エントリ・
レベルのＰＳ／２は、ファミリ１（ＡＴ）バスをもつシ
ステムにＶＴＣを採用することを選択することができ
る。マイクロ・チャネルや関係ホスト入出力バスに直接
にアクセスできないゲスト・カード（ベース・カード上
の）は、シリアル・バス（例えば、Ｉ−ｓｑｕａｒｅｄ
−Ｃ）の可能性を含めて、ローカル入出力バスと一緒に
ＶＴＣを実装するように設計することが可能である。そ
のような場合には、アーキテクチャの物理層および電気
層を実装バージョンは、ここで説明している基本バージ
ョンと異なる場合がある。

【００４４】ビデオ転送チャネル−独立型（ＶＴＣ−ＳＡ） ＶＴＣ−ＳＡは、コンピュータ内の他のどのバスにも接
続することができない、接続されたビデオ・デバイスと
直接に通信できるようにする。ＶＴＣ−ＳＡコマンドと
共に、コマンドに対する応答と圧縮ビデオ・データは、
通常の非圧縮ビデオ・ピクセルと一緒にバス上を搬送さ
れる。この付加的な補助データの総バンド幅は、ビデオ
・ピクセルの負荷量と比べると、ほとんど重要でない。
単にビデオ・ピクセルと接続するためにだけ必要なピン
数は少なくすることができ、これらのピンは、その他の
必要な通信を行うためにも使用できるので、この構成に
よると、グラフィックス・アダプタおよびビデオ機構の
双方のためのピン数を少なくすることができる。この付
加的な補助データは、ＶＴＣについて上述した同じ制御
メカニズムを使用してＶＴＣ−ＳＡ上を送信される。グ
ラフィックス・アダプタは他の機構のホストの役割を果
たし、システム・バスとＶＴＣ−ＳＡ間の単純で、効果
的な通信インタフェースとなると同時に、ＶＴＣ−ＳＡ
スレーブとして働く。ある種の機能、行動、およびコマ
ンドは、ホストを除くすべてのＶＴＣ−ＳＡデバイスに
ついて定義されているので、ＣＰＵからの開始作業は統
一化されている。

【００４５】好適実施例では、どの時点においても、ア
クティブ・マスタは最大でも１つであり、スレーブも１
つである。しかし、複数のマスタとスレーブを時分割多
重化（ｔｉｍｅ−ｄｏｍａｉｎ ｍｕｌｔｉｐｌｅｘｅ
ｄ）することが可能である。マスタは、仲裁トークンを
受信し、受諾することによってアクティブ・マスタとな
り、仲裁トークンを送出することによってアクティブ・
マスタであることを停止する。スレーブは、アクティブ
・マスタによってアドレス指定されると、アクティブ・
スレーブになる。スレーブは、別のスレーブがアクティ
ブ・マスタによってアドレス指定されるか、仲裁トーク
ンがアクティブ・マスタから送信されると、アクティブ
・スレーブであるこを停止する。アクティブ・マスタ
は、１つまたは２つ以上のスレーブとのデータ転送を開
始し、実行する。すべての転送の開始、管理、および実
行は、下述するバス・ラインを使用して行われる。

【００４６】ＶＴＣ−ＳＡは、マイクロ・チャネルなど
の汎用入出力バスとの直接接続が困難であるビデオ機構
（ｖｉｄｅｏ ｆｅａｔｕｒｅｓ）を構築するという問
題を解決することが動機となっている。このような問題
が起こる理由としては、パッケージング（実装技術）、
電気的負荷、コスト、接続できるこの種のバスの欠如な
どのように、いくつかある。動機しては、さらに、コス
トの主な要因であるピンをグラフィックス・アダプタに
追加しないで、ビデオ機構のコストを最小化または低減
化するという要求がある。ＶＴＣ自体のパフォーマンス
だけではなく、入出力バスや、通信プロトコルを処理
し、ビデオ機構および他のタスク間を流れるデータ・フ
ローを管理する必要のあるＣＰＵソフトウェア・システ
ムのパフォーマンスも重要な考慮事項になっている。

【００４７】ＶＴＣは、マイクロ・チャネルなどの既存
の入出力チャネルに対する単なる付属品ではない。ＶＴ
Ｃは、グラフィックス・アダプタを含む、ＶＴＣ接続デ
バイス間で非圧縮すなわち生のビデオ・ピクセルを搬送
するからである。このような構成が適している場合とし
ては、ビデオ機構とディスプレイ・アダプタがなんらか
の方法でマイクロ・チャネルに接続している場合があ
る。その場合には、ＶＴＣはアダプタ間で受渡しされる
生のビデオの最適化通路となると同時に、アーキテクチ
ャに基づくこれらのアダプタの統一インタフェースとな
る。しかし、多くのシステムでは、パッケージングや他
のアーキテクチャ上の制約があるために、ダイヤグラム
を構築する際に使用される上記想定は変更されている。

【００４８】ＶＴＣ−ＳＡでは、ビデオ機構はグラフィ
ックス・サブシステムの一部と見られ、マイクロ・チャ
ネルにも、他のシステムや入出力バスにも接続されな
い。実際には、グラフィックス・アダプタはマイクロ・
チャネルにではなく、システム・バスに接続される。そ
の場合、ビデオ機構をマイクロ・チャネルに接続する必
要がある場合であっても、ビデオ機構とグラフィックス
・アダプタの間に比較的長いフレキシブル・ケーブルが
必要とされるので、パフォーマンスが不当に低下すると
いう問題が起こる。ビデオ機構をグラフィックス・アダ
プタ・システムの一部と見るこの見方は、パッケージン
グに反映させることが可能であり、その場合は、ビデオ
機構はグラフィックス・アダプタ上のゲスト・カードと
なる。補助データ・フローをサポートするために追加バ
スを構築することも可能であるが、本発明を動機づけた
のは、既存のピンとインタフェース・ロジックおよび使
用可能なバンド幅をその目的のために使用することであ
る。従って、ビデオ機構をグラフィックス・アダプタ・
システム内に置いて、動作できるようにするアーキテク
チャが必要になる。

【００４９】多くの重大な理由から、ＶＴＣの使用は、
ビデオ機構をグラフィックス・ハードウェア環境に統合
化するという問題を解決する好適な解決手法としてすで
に受け取られている。この決定の背景となった理由を説
明することは簡単であるが、これは本明細書の範囲外で
あるので、その説明を省略する。

【００５０】ＶＴＣ−ＳＡの設計で取り上げた非常に重
要な要件の１つは、この構成を実現するために必要なグ
ラフィックス・アダプタ機能の設計をできるかぎり単純
に維持することである。この理由のために、いくつかの
トレードオフが生じ、ビデオ機構とソフトウェアの負担
が可能な限りの最小限の負担より若干大きくなってい
る。その結果として得た設計は、グラフィックス・アダ
プタに容易に実現することができ、これはバッファ付き
直接メモリ・アクセス（ＤＭＡ）機能に見える。同様
に、すべてのビデオ機構にも、ソフトウェアにも容易に
実現することができる。ソフトウェアがキュー（待ち行
列）を管理する必要があるが、キューのアーキテクチャ
（設計構造）は統一化されており、ソフトウェアがビデ
オ機構へのＰＩＯ（ｐｒｏｇｒａｍｍｅｄ Ｉ／Ｏ−プ
ログラム式入出力）またはソフトウェア制御のＤＭＡを
実行する必要がないので、入出力マップ式またはメモリ
・マップ式ビデオ機構に比べると、全体的にパフォーマ
ンスが向上し、より単純化する。

【００５１】ＶＴＣがビデオ機構とグラフィックス・ア
ダプタの間に置かれていて、ＶＴＣ用のピンがすでに割
り振られていて、ＶＴＣインタフェースが存在している
とすると、ビデオ・サブシステムがどのような目的を必
要としているかに関係なく、ＶＴＣバンド幅全体を利用
して、ＶＴＣ−ＳＡを実現することができる。

【００５２】ビデオ機構に対する追加のバスを使用する
かどうかに関係なく、正しい接続メカニズムを設計する
ためには、サポートする必要のあるデータ・フローの理
解が必要である。ビデオ機構に受け渡しされるデータ・
フローには、一般的に、ホストからビデオ機構へのコマ
ンド、これらのコマンドに対する応答、ホストシステム
から、ビデオ機構への圧縮データ（ビデオ）、ビデオ機
構からホストへの圧縮データ（ビデオ）、ビデオ機構か
らグラフィックス・アダプタへの非圧縮ピクセル、グラ
フィックス・アダプタからビデオ機構への非圧縮ピクセ
ル、ビデオ機構間の非圧縮ビデオ、およびグラフィック
ス・アダプタとビデオ機構間の情報通知（双方向）があ
る。

【００５３】これらはすべてが、すべてのビデオ・アダ
プタで必要になるとは限らない。例えば、圧縮データを
必要とするのは、コンプレッサ（圧縮）とデコンプレッ
サ（圧縮解除）だけであることは明らかである。グラフ
ィックス・アダプタとビデオ機構間の情報通知は、更新
タイミングとマルチバッファ表示管理を切れ目なく行う
ためのものである。

【００５４】しかし、これらのデータ・フローの最初の
２つ、つまりコマンドと応答はすべての機構で必要にな
る。最低限、ビデオ機構はＰＯＲ（パワー・オン・リセ
ット）時または構成時に診断を実行できるように構成さ
れていなければならない。また、ＣＰＵとすべての機構
の間でユーザとスクリーンの管理制御が実現されている
ことも必要である。

【００５５】これらのデータ・フローの各々に必要なバ
ンド幅を調べることは有用である。ＶＴＣが取り扱った
主要問題は、非圧縮または生のビデオ・ピクセルを搬送
することである。これらのフローのバンド幅は、表示さ
れるウィンドウのサイズに大きく依存する。

【００５６】どのビデオ・ウィンドウの場合も、必要と
するバンド幅は、若干の例外はあるが、大部分がウィン
ドウ・サイズを関数となる。好適実施例では、バンド幅
はウィンドウの面積に比例している。従って、必要とす
るバンド幅は、ウィンドウ・サイズを管理することによ
ってある程度管理が可能である。

【００５７】単一ウィンドウからのバンド幅は、毎秒当
たりのフレーム数（ｆｐｓ）を減らしても容易には減少
しない。そのようにすると、フレーム全体をビデオ機構
のバッファに入れる必要が起こると同時に、更新が遅い
ために起こる人為的なモーションの低下をそのまま受け
入れる必要が起こることになる。複数ウィンドウは、シ
ステムの能力を過負荷にする傾向にあるが、一部のフレ
ームまたはフレームの部分を必要時に動的に除去するよ
うにすると、利点が得られる。しかし、機構に追加的な
ローカル・メモリが必要になり、イメージ品質が低下す
るという犠牲を伴うことになる。

【００５８】複数の生のビデオのデータ・フローが同時
に存在する場合がある。例えば、ビデオ・ホンＣＯＤＥ
Ｃは、リモート・ビデオ・ソースをあるサイズのウィン
ドウに表示し、ローカル・ビデオ・ソースを別サイズの
別のウィンドウに表示することができる。ある設計で
は、アナログ・ビデオ入力回路は、ディジタル化ローカ
ル・ビデオ信号をＶＴＣ経由でコンプレッサに渡すこと
も可能になっている。例えば、テープに記録するために
ＮＴＳＣを出力するビデオ出力アダプタは、グラフィッ
ク・オーバレイを含む、ウィンドウの内容を抽出するこ
とが可能になっている。同時並行オペレーションに必要
なこれらのバンド幅は、すべて付加的なものである。Ｖ
ＴＣ−ＳＡに接続されたデバイスとＣＰＵとの間のコマ
ンドおよび制御のために、ある程度の付加的バンド幅が
必要である。

【００５９】どのハードウェア設計の場合も、つ過負荷
状態となるシナリオが常に存在する。まり、ＶＴＣ自体
ではなければ、ディスプレイ・メモリのバンド幅におい
てである。従って、ソフトウェアは資源管理を行って、
正しく実行されるように保証できるアクティビティだけ
が活動化されるように保証しなければならない。このよ
うな保証を得るには、様々な方法が可能である。例え
ば、表示されるビデオ・ウィンドウのサイズを制限する
方法、表示される（しかし、通常はディジタルまたはア
ナログの出力でない）ウィンドウの品質を徐々に低下さ
せる方法がある。ＶＴＣを使用しながらウィンドウの品
質を低下させる方法については、後述する。

【００６０】ＶＴＣ−ＳＡ構造の好適実施例の主要な特
徴としては、ＶＴＣへＯＵＴする補助データおよびＶＴ
ＣからＩＮする補助データ用にシステム・メモリに設け
た２つの単方向キューがある。グラフィックス・アダプ
タは第一の部分的ＤＭＡ（バス・マスタ）を実行しこれ
らのキューをアクセスする。グラフィックス・アダプタ
はデータ・ストリームを入出力する小容量のオンチップ
・バッファを備えており、ＶＴＣデバイスは入出力バッ
ファをＶＴＣマスタとしてアクセスする（グラフィック
ス・アダプタがＶＴＣスレーブである）。ＶＴＣと受け
渡しされるすべての補助データは定義されたインタリー
ブ形式を用いてインタリーブされて、２つのシステム・
キューに入れられ、ＣＰＵ（または他のデバイス）がビ
デオ機構とのすべての通信のためにシステム・キューを
読み書きする。グラフィックス・アダプタはシステム・
キューおよびオンチップ・バッファのためのポインタ・
レジスタを内蔵している。

【００６１】ＶＴＣおよびＶＴＣ−ＳＡバス・ラインの定義 好適実施例では、ＶＴＣおよびＶＴＣ−ＳＡは３２ビッ
ト・データ・チャネルを有し、これに３つの制御ライン
とクロックが加わっている。これらは論理的に３２ビッ
ト幅になっている。この場合、１６ビット電気規格バー
ジョンでは、３２ビット情報は直列化されて、１対の１
６ビット短ワードが得れる。好適実施例では、ビット番
号付けは、「ビッグ・エンディアン」（ｂｉｇ ｅｎｄ
ｉａｎ）とも呼ばれる、標準規則に従っている。

【００６２】バスのラインは、好ましくは３２ビットで
あり、次のとおりである。

【００６３】ＤＡＴＡ（０−３１）：双方向データ。

【００６４】ＣＬＯＣＫ（３２）：連続動作のマスタ・
クロック。単一のデバイスにより駆動され、すべてのマ
スタおよびスレーブ・ロジックへ入力される。

【００６５】ＤＡＴＡ／−ＣＴＬ（３３）：アクティブ
なマスタによって駆動され、ＶＴＣ経由で書かれるデー
タが制御フィールドであるかデータであるかを示してい
る。 ＭＡＳＴＥＲＲＤＹ（３４）：アクティブなマスタによ
ってアクティブに駆動され、ライト（書込み）転送時に
は有効なデータを提示していることを示し、リード（読
取り）転送時にはデータを受け取る用意にあることを示
している。

【００６６】ＳＬＡＶＥＲＤＹ（３５）：アクティブな
スレーブによって駆動され、ライト転送時にはデータを
受け取る用意にあることを示し、リード転送時には有効
なデータを提示していることを示している。

【００６７】ＤＡＴＡ（０−３１）がアクティブなマス
タによって駆動されるのは、アクティブ・マスタがＶＴ
Ｃライト転送を実行したり、制御フィールドを書いた
り、仲裁トークンを送出したりするときである。また、
ＤＡＴＡラインがアクティブ・スレーブによって駆動さ
れるのは、ＶＴＣリード転送が進行中のときである。マ
スタとスレーブのドライバは、好ましくは、トライ・ス
テート（ｔｒｉ−ｓｔａｔｅ）になっている。ＣＬＯＣ
Ｋ（３２）は、連続動作の定周波数クロックであること
が好ましい。この信号は、ＶＴＣのすべてのオペレーシ
ョンのために使用される。すべてのＶＴＣインタフェー
ス・ロジックはＣＬＯＣＫラインを、タイミングをとる
ための入力として使用する。１つのクロック・ドライバ
がアクティブになっていることが好ましい。ＤＡＴＡ／
−ＣＴＬ（３３）は、マスタがＤＡＴＡライン上でデー
タを駆動しているか、または制御フィールドおよび仲裁
トークンを駆動しているかを示している。どのマスタも
ＤＡＴＡラインを駆動していないとき、あるいはアクテ
ィブ・マスタがデータ（例えば、ピクセル）値を駆動し
ているとき、ＤＡＴＡ／−ＣＴＬラインは“ＤＡＴＡ”
（高）状態にある。アクティブ・マスタがＤＡＴＡライ
ン上で制御フィールドまたは仲裁トークンを駆動してい
るとき、ＤＡＴＡ／−ＣＴＬラインは“ＣＴＬ”（低）
状態にある。以下では、好適実施例による制御フィール
ドおよび仲裁トークンについて説明する。ドライバはト
ライ・ステートであることが好ましい。すべてのマスタ
がＤＡＴＡ／−ＣＴＬラインをトライ・ステートのまま
にしておくときのあいまいさを避けるために、ＤＡＴＡ
／−ＣＴＬラインには少なくとも１つのパッシブ・プル
アップ（ｐａｓｓｉｖｅ ｐｕｌｌ−ｕｐ）が存在す
る。ＭＡＳＴＥＲＲＤＹは、ライト転送時には、アクテ
ィブに駆動され、現クロック・サイクル期間にマスタが
ＤＡＴＡライン上で有効なデータを駆動していることを
示す。このデータはアクティブ・スレーブによって受信
されるものと期待される。ＭＡＳＴＥＲＲＤＹラインが
インアクティブのときは、ＤＡＴＡライン上の値が有効
でなく、スレーブによって無視すべきであることを示し
ている。リード転送時には、ＭＡＳＴＥＲＲＤＹライン
のアクティブ状態は、次のクロック・サイクル後のクロ
ック・サイクル期間に有効なデータが受け付けられるこ
とを示し、ＭＡＳＴＥＲＲＤＹラインのインアクティブ
状態は、その後の２クロック・サイクル期間に存在する
データは受け付けられないず、参加するスレーブはその
サイクル期間に有効データを駆動してはならないことを
示している。有効でないＤＡＴＡラインの値は「無視し
てよい」（‘ｄｏｎ’ｔ ｃａｒｅ’）。好ましくは、
ドライバはトライ・ステートになっている。すべてのマ
スタがＭＡＳＴＥＲＲＤＹラインをトライ・ステートの
ままにしておくときの、あいまいさを避けるために、Ｍ
ＡＳＴＥＲＲＤＹラインには少なくとも１つのパッシブ
・プルアップが存在する。ＳＬＡＶＥＲＤＹラインは、
リードとライトがあり、またマスタとスレーブが反対に
なっている点を除けば、ＭＡＳＴＥＲＲＤＹラインと同
じように定義されている。リード転送時には、有効なデ
ータがスレーブによってＤＡＴＡライン上に駆動されて
いることを示している。ライト転送時には、アクティブ
状態は、次のクロック・サイクルのあとのクロック・サ
イクル期間に提示されたデータが受け付けられることを
示している。ＳＬＡＶＥＲＤＹラインのインアクティブ
状態は、アクティブ・マスタがその後の２クロック・サ
イクル期間にＤＡＴＡライン上で有効データを駆動して
はならないことを示している。この場合も、ドライバは
トライ・ステートであることが好ましい。すべてのスレ
ーブがＳＬＡＶＥＲＤＹラインをトライ・ステートのま
まにしておくときの、あいまいさを避けるために、ＳＬ
ＡＶＥＲＤＹライン上に少なくとも１つのパッシブ・プ
ルアップが存在している。

【００６８】ＶＴＣの１６ビット電気規格バージョン
は、ＤＡＴＡラインが１６本だけである点を除けば、バ
ス・ライン定義を上述したものと同じにすることが好ま
しい。１６ビット・バージョンでは、完全３２ビット・
バージョンのＤＡＴＡライン上に現れる３２ビット値
は、１対の１６ビット値に直列化される。好適実施例で
は、１６ビットを使用するＶＴＣのオペレーションは、
３２ビット・オペレーションを直列化したバージョンで
ある。１６ビット・デバイスとの間で受け渡しされるデ
ータは、好ましくは、１６ビット短ワードの対として送
信される整数個の３２ビット・ワードからなっている。
その場合、最初の短ワードは上位１６ビット（０−１
５）すなわち等価的にバイト０と１からなっている。各
対からの２番目の短ワードは下位ビット（１６−３１）
すなわち等価的にバイト２と３からなっている。

【００６９】３２ビットと１６ビット間の相互接続は可
能であるが、必ずしも、すべての３２ビットまたは１６
ビット実装バージョンでサポートする必要はない。１６
ビット・バージョンと３２ビット・バージョンが相互接
続されるときは、１６ビット・デバイスの１６データ・
ラインは完全３２ビットＶＴＣの上位ビット（０−１
５）に接続される。３２ビット・デバイスは１６ビット
・デバイスへ送られるすべての３２ビット・ワードを直
列化する一方で、３２ビット・デバイスは、データが他
の３２ビット・デバイスだけに送られるとき、すべての
３２ビット・ワードを駆動することができる。すべての
１６ビット・マスタとスレーブは制御フィールドの１６
個のＭＳＢ（上位１６ビット）の値（ＤＡＴＡ／−ＣＴ
Ｌを「低」にして送られるデータ）を記録しておき、情
報または仲裁トークンが自分宛に送られてきたものかど
うかを判断し、制御フィールドが３２ビット・ワードと
して送られてきたか、２個の１６ビット短ワードとして
送られてきたかを判断する。３２ビット・マスタとスレ
ーブは、１６ビット・スレーブおよびマスタと通信する
とき、１６ビット形式を使用する。他の場合と同様に、
マスタは、マスタが通信するスレーブの特性をサポート
し、これらの特性を示したコンテキスト情報をスレーブ
から受信しない。１６ビット転送は、制御フィールドの
中のビットによって示される。

【００７０】ＶＴＣの６４ビット電気規格バージョン
は、ＤＡＴＡラインが６４本である点を除けば、バス・
ライン定義を３２ビット・バージョンと同じにすること
が好ましい。６４ビット・デバイスと１６ビット・デバ
イス間の相互接続のサポートはオプションである。サポ
ートする場合は、その要件は、１６ビット・スレーブと
マスタ間を上述したように相互接続する場合と同じであ
る。６４ビット・バージョンのＶＴＣは、３２ビット・
バージョンと同じ方法で制御フィールド情報を伝え、そ
の考慮点は１６ビット・デバイスと相互接続する場合と
同じである。３２ビット制御ワードは３２ビット・ワー
ドとして送信されるが、ＤＡＴＡ（３２−６３）は未定
義のままである。共に６４データ・ビットをサポートす
るマスタとスレーブは、各クロック・サイクルでデータ
を３２ビット・ワードの対として転送する。その順序
は、ＤＡＴＡ（０−３１）のワードがＤＡＴＡ（３２−
６３）のワードの前に置かれるようになっている。マス
タは、どのスレーブが６４ビット転送をサポートしてい
るかを知っていなければならない。６４ビット転送は制
御フィールドの中のビットによって示される。

【００７１】ＶＴＣおよびＶＴＣ−ＳＡのオペレーション 以下では、ライト転送、リード転送、データ転送、およ
びペーシング（歩調合わせ）の好適プロシージャについ
て説明する。

【００７２】ライト転送 図４を参照して、好適実施例におけるライト転送につい
て説明する。最初のステップにおいて、転送が進行中で
はないときは、ＭＡＳＴＥＲＲＤＹとＳＬＡＶＥＲＤＹ
はインアクティブ（高）になっている。第２ステップに
おいて、前のアクティブ・マスタは、データ・ライン上
の仲裁トークンを次のマスタへ送ることによって、バス
制御権を次のマスタへ引き渡す。トークンは、ＤＡＴＡ
／−ＣＴＬが低にあるときのＤＡＴＡライン上の予約さ
れた値セットの１つである。つまり、特殊制御フィール
ドである。前のマスタは、ＭＡＳＴＥＲＲＤＹとＤＡＴ
Ａ／−ＣＴＬを共に低に駆動することによって、ＤＡＴ
Ａライン上のトークン値と一緒に仲裁トークンを送信す
る。次のマスタは、仲裁トークン制御フィールドの「次
マスタ」サブフィールドが自身のＩＤと一致しているこ
とを認めると、仲裁トークンを受け取る。この時点で
は、どのデバイスもＳＬＡＶＥＲＤＹを駆動せず、その
値はすべてのマスタによって無視される（ＳＬＡＶＥＲ
ＤＹは、前のスレーブによってインアクティブに駆動さ
れているので、この時点では一般的にインアクティブに
なっている）。第３ステップにおいて、トークンを受け
取ったマスタは、転送を開始するか、あるいは第２ステ
ップと同様にトークンを次のマスタへ引き渡す。第４ス
テップにおいて、新しいアクティブ・マスタはセットア
ップ情報をＶＴＣ制御フィールド値の形で、選択したス
レーブ・デバイスへ送信する。この情報は、ＤＡＴＡ／
−ＣＴＬを低にし、ＭＡＳＴＥＲＲＤＹをアクティブに
してＤＡＴＡライン上を送信される。このセットアップ
情報は、目標となるスレーブのアドレスを含んでいる。
第５ステップにおいて、スレーブは初期状態ではどのラ
インも駆動していない。第１制御フィールドを通してア
ドレス指定されると、ＳＬＡＶＥＲＤＹをアクティブ
（低）に駆動し、その入力ＦＩＦＯがいっぱいことを確
認して、追加データを受け取る用意があることを通知す
る。制御情報の最初の２ワードがマスタから送信される
と、スレーブはＳＬＡＶＥＲＤＹを使用してデータ・フ
ローを歩調合わせする。第６ステップにおいて、必要と
する制御フィールドがすべてスレーブに渡されると、マ
スタはデータ・ワードのクロックをとってＶＴＣ上を送
出する。マスタは各クロック・サイクルごとにＭＡＳＴ
ＥＲＲＤＹをアクティブに駆動し、その時ＤＡＴＡライ
ン上の有効データを駆動する。有効データが準備状態に
ないときは、ＭＡＳＴＥＲＲＤＹをインアクティブに駆
動するので、バス上にアイドル・サイクルが現れる。第
７ステップにおいて、スレーブが受信した制御ワードと
データ・ワードがそのＶＴＣ入力ＦＩＦＯバッファに入
れられる。ＦＩＦＯバッファがほぼいっぱいになると、
スレーブはＳＬＡＶＥＲＤＹをインアクティブ（高）に
駆動し、マスタがその後の２クロック・サイクルの間、
データ・ワードを書くことを禁止する。第８ステップに
おいて、スレーブは転送されてきたデータを、制御フィ
ールドで指示されたようにアドレスにストアする。第９
ステップにおいて、一度転送が開始されると、マスタと
スレーブは、転送が完了するまで転送の処理を続けなけ
ればならない。第１０ステップにおいて、転送が完了し
たとき、マスタはＶＴＣをそのまま保持することも、手
放すこともできる。マスタがＶＴＣを保持するときは、
必要とする制御フィールド（つまり、少なくとも１つ
の、前の転送と異なるフィールド）とそのあとに置かれ
た必要なデータを書くことによって別の転送を行うこと
ができる。マスタは、仲裁トークンを次のマスタへ送る
ことによってＶＴＣを手放す。転送が完了すると、スレ
ーブはＳＬＡＶＥＲＤＹをインアクティブに駆動し、こ
のラインをトライ・ステートにする。

【００７３】リード転送 図５を参照して、好適実施例におけるリード転送につい
て説明する。リード転送は、次の例外を除き、ライト転
送と同じである。第一に、マスタからスレーブへ書かれ
る制御フィールドは、リード転送が要求されたことを示
している。第二に、マスタは制御フィールドをスレーブ
へ送った後、ＭＡＳＴＥＲＲＤＹを高に駆動し、ＤＡＴ
Ａラインをトライ・ステートにし、スレーブが応答して
データを返してくるのを待つ。マスタは、少なくとも１
サイクルの間、ＳＬＡＶＥＲＤＹがインアクティブにな
るのを待ってから、ＤＡＴＡライン上の値を有効な返却
データであると解釈する。スレーブは少なくとも１サイ
クルの間、ＳＬＡＶＥＲＤＹをインアクティブに駆動し
てからデータを送信する。第三に、転送要求に応答して
マスタへ送るべきデータがスレーブにあると、スレーブ
はＤＡＴＡライン上のデータを駆動し、ＳＬＡＶＥＲＤ
Ｙラインをアクティブに駆動して、有効データがＤＡＴ
Ａライン上にあることを示す。第四に、マスタはＳＬＡ
ＶＥＲＤＹがインアクティブであることを検出すると、
データを受け取ることができることに応じて、ＭＡＳＴ
ＥＲＲＤＹの駆動を開始する。スレーブは、制御フィー
ルドを受信した後、最初にＳＬＡＶＥＲＤＹをインアク
ティブに駆動した後の最初の２クロック周期の間、歩調
をとる目的で、ＭＡＳＴＥＲＲＤＹの値を無視する。第
五に、スレーブは、ＤＡＴＡライン上に有効データを駆
動する時に、ＳＬＡＶＥＲＤＹをアクティブに駆動す
る。送るべき有効データがないと、スレーブはＳＬＡＶ
ＥＲＤＹをインアクティブに駆動する。第六に、スレー
ブは、制御フィールドＦ０中の長さサブフィールド中に
指定されている数と同数のデータ項目（例えば、ピクセ
ル）を送信する。第七に、リード転送が完了すると、マ
スタはＭＡＳＴＥＲＲＤＹをインアクティブに駆動し、
スレーブはＳＬＡＶＥＲＤＹをインアクティブに駆動す
る。第八に、マスタは、ＤＡＴＡ、ＤＡＴＡ／−ＣＴＬ
および関連のＭＡＳＴＥＲＲＤＹを駆動する前に、ＳＬ
ＡＶＥＲＤＹがインアクティブであることを検出してい
なければならない。第九に、マスタは仲裁トークンを次
のマスタへ送出することによってＶＴＣを手放すか、あ
るいは少なくとも一つの制御フィールドを送信すること
によって別の転送を開始する。

【００７４】データ転送プロシージャ スレーブに入力されまたは出力されるデータは、スレー
ブが生成したすべてのローカル・アドレスを用いてその
ローカル・メモリまたはレジスタに入出力される。好適
実施例では、ピクセルのアドレス指定は、水平線セグメ
ントの形で行われるので、単一のピクセルに縮減するこ
とができる。個別データ・ワードまたはピクセルのアド
レス指定は、各転送の開始時に制御フィールドに入れて
送られる開始アドレスおよび他の情報に基づいて、スレ
ーブによって内部で行われる。

【００７５】データが転送される前に、該当制御フィー
ルドをスレーブに送らなければならない。これらのフィ
ールドは、マスタおよびスレーブのＩＤ、アドレス指定
情報、転送の方向（リードまたはライト）、ならびにそ
の他の情報を収めている。ある種のスレーブの実施例で
は、転送を行うために必要な情報の一部をローカル・メ
モリに置いておき、送信される情報、つまり、マスタ・
デバイスＩＤまたは転送元ウィンドウＩＤ（ＷＩＤ）を
使用して間接的に参照することができる。

【００７６】このことは、ＶＴＣおよび他のすべてのデ
バイスから見える。

【００７７】制御フィールドの送信は、同じバス・タイ
ミングを用いており、データ書込みオペレーションと似
ているが、制御フィールドがバス上を送信されるクロッ
ク・サイクル期間にＤＡＴＡ／−ＣＴＬがマスタによっ
て低に駆動される点が異なる。

【００７８】同一または異なるスレーブとの間でマスタ
が行うことができる連続転送の数とサイズは、本好適実
施例のアーキテクチャでは、マスタにＶＴＣを許可でき
る最大時間の長さ（クロック・サイクルの数）を制限す
る仲裁行動パラメータだけによって制限される。各転送
のサイズは、０から制御フィールドＦ０に指定可能な最
大値までであり、これもまた同じ仲裁行動パラメータに
よって制限される。

【００７９】歩調合わせ すべてのスレーブは、データと制御情報を受け入れるた
めの入力ＦＩＦＯ機能を備えていることが好ましい。Ｆ
ＩＦＯのサイズはＶＴＣアーキテクチャでは規定されて
いない。これはスレーブの設計に特有のものである。す
べてのスレーブは、制御フィールドの送信を含めて、す
べてのオペレーション時に特定された歩調合わせメカニ
ズムをサポートできる必要がある。各スレーブが必要と
する総ＦＩＦＯサイズは、ＶＴＣ転送要求を引き受ける
ときの内部待ち時間やスピードなどの要因に依存する。

【００８０】データ転送は、通常、ＶＴＣマスタ・クロ
ックの各サイクル毎に１ワード行われる。アクティブ・
マスタとアクティブ・スレーブのどちらも、バス上の１
または２以上のサイクルを強制的にアイドル・サイクル
にすることによって実効データ・レートを低下させるこ
とが可能である。この作用は、ＭＡＳＴＥＲＲＤＹライ
ンとＳＬＡＶＥＲＤＹラインを使用し、それぞれアクテ
ィブ・マスタとアクティブ・スレーブが駆動することに
よって制御される。どちらのデバイスがこれらの２ライ
ンのどちらを駆動するかの選択は、リード転送とライト
転送のどちらも同じであるが、これらのラインの意味
は、データ・フローの方向によって変化する。

【００８１】ライト転送時とマスタによる制御フィール
ドの書込み時に、アクティブ・マスタはＭＡＳＴＥＲＲ
ＤＹをアクティブ（低）に駆動して、ＤＡＴＡライン上
で有効データを駆動していることを示す。送信すべき有
効データがないときのように、有効データを駆動しない
ときはいつでも、ＭＡＳＴＥＲＲＤＹをインアクティブ
に駆動する。ＶＴＣを手放すときは仲裁トークンを送信
したあと、ＭＡＳＴＥＲＲＤＹを１サイクルの間インア
クティブに駆動し、このラインをトライ・ステートにす
る。制御情報（フィールドＦ０）の送信によって、スレ
ーブがマスタによってアドレス指定されると、スレーブ
はＳＬＡＶＥＲＤＹを駆動して、マスタが各連続するク
ロック・サイクル期間にデータの送信を続けることがで
きるか、あるいはできないかを示す。ライト転送のバス
・サイクル期間におけるＳＬＡＶＥＲＤＹのアクティブ
（低）は、そのあとに続く次のサイクル期間に送信され
たデータが受け取られることを示している。バス・サイ
クル期間にＳＬＡＶＥＲＤＹの値がインアクティブであ
ることは、そのあとに続くサイクルの次のバス・サイク
ルには有効データが含まれていないので、そのサイクル
期間のＤＡＴＡライン上の値が無視されることを示して
いる。

【００８２】ＶＴＣリード転送は、データ・フロー（制
御フィールドではない）の方向が反対になり、同じよう
に、ＭＡＳＴＥＲＲＤＹとＳＬＡＶＥＲＤＹの役割がデ
ータ読取り転送時に反対になる点を除けば、ライト転送
と同じである。スレーブはＳＬＡＶＥＲＤＹをアクティ
ブに駆動して、ＤＡＴＡライン上で有効なデータを駆動
していることを示し、インアクティブに駆動して、有効
データがないことを示す。マスタはＭＡＳＴＥＲＲＤＹ
をアクティブに駆動して、そのあとに続くデータの次の
データ・ワードが受け取られることを示し、インアクテ
ィブに駆動して、その後に続くデータの次のバス・サイ
クルはＳＬＡＶＥＲＤＹをインアクティブにしてアイド
ルにすべきであることを示す。好適実施例では、以上説
明してきたことには、３つの例外がある。第１の例外
は、スレーブが制御フィールドＦ０を通してアクティブ
・マスタによって初めてアドレス指定されたとき、その
スレーブは、パイプライン遅延が原因で２クロック・サ
イクルの間、ＳＬＡＶＥＲＤＹをインアクティブのまま
にできることである。これは、ライト転送の場合にも、
リード転送のときの制御フィールドの書込みの場合にも
適用される。マスタは、これらの２クロック・サイクル
期間にＳＬＡＶＥＲＤＹがアクティブであったものとし
て、制御フィールドとデータの送信を続けることができ
る。またスレーブは、このデータを受信して処理できな
ければならない。第３サイクルから始まって、歩調合わ
せが上述したように行われる。第２の例外は、上記と同
様に、スレーブが要求データを返却する準備状態にある
ときにおいて、制御フィールドがスレーブによって受信
された後のリード転送の開始時にＳＬＡＶＥＲＤＹがイ
ンアクティブにされるとスレーブは、最初のサイクルか
らの２クロック・サイクルの間ＭＡＳＴＥＲＲＤＹの値
を無視することである。従ってマスタは、スレーブから
送られてくるデータを受信して処理できなければならな
い。第３の例外は、仲裁トークンは、ＳＬＡＶＥＲＤＹ
の値に関係なく送信されることである。これが必要なの
は、この時間の間、ＳＬＡＶＥＲＤＹを常にインアクテ
ィブで、トライ・ステートにしておくべきであり、仲裁
トークンがマスタ（スレーブではない）によって受信さ
れるためである。

【００８３】リードまたはライト転送が完了すると、ア
クティブ・スレーブは１サイクルの間ＳＬＡＶＥＲＤＹ
をインアクティブ（高）に駆動し、このラインをトライ
・ステートにする。各転送が終了すると、アクティブ・
マスタはライト転送およびリード転送において説明した
ようにＭＡＳＴＥＲＲＤＹを駆動する。

【００８４】ＶＴＣおよびＶＴＣ−ＳＡ制御フィールド マスタ・デバイスによりスレーブへ送られる制御情報
は、ＶＴＣ制御フィールドと呼ばれるワードに編成され
ている。これらは、ＶＴＣ経由の転送を行うために必要
な情報のすべてを収めており、Ｆ０，Ｆ１，Ｆ２などの
ように名前が付けられている。これらの制御フィールド
は図６〜図１２に示されており、その説明は以下のとお
りである。

【００８５】好適実施例では、仲裁トークンは制御フィ
ールドと同じメカニズムを使用して送信される。各フィ
ールドの最初（上位）の４ビットはフィールドＦ０〜Ｆ
１４のＩＤを指定しており、残りの２８ビットはワード
の内容が入っている。４個のＭＳＢ（上位ビット）の値
は、Ｆｎ制御フィールド名の数字部分に一致している。
仲裁トークンは制御フィールドの特殊ケースであり、独
自の番号１５、つまり、‘１１１１’ｂをもち、これは
４個のＭＳＢに示されている。

【００８６】好適実施例では、３つのフィールド、Ｆ
０，Ｆ１，Ｆ２があり、これらはＶＴＣのオペレーショ
ンを定めるために指定される。マスタにＶＴＣが許可さ
れる毎に、マスタはピクセルの転送を開始するためにこ
れらの３フィールドを送信する（スレーブの場合は、２
４ビットより大きい開始アドレスを必要とするので、２
４個のＭＳＢを指定するためにＦ３も書く必要があ
る）。Ｆ０は必ず最初に書かなければならない。Ｆ０は
マスタだけでなく、スレーブのアドレスも収めており、
正しいスレーブが残りのフィールドとデータを受信し
て、それに応答できるようにするために必要である。フ
ィールドが転送で必要のない場合は、例えばピクセルを
含んでいない転送におけるＦ１は、省略することが可能
である。他のフィールドはどの順序に書くことも可能で
ある。マスタがＶＴＣの制御権を受け取ったとき、マス
タは、マスタまたは別のデバイスが以前に書いていた可
能性のあるフィールドの内容についてなにも想定するこ
とはできない。アドレス指定したデバイスとの間で転送
を行うために必要なフィールド値がある場合は、マスタ
がその値を送信してからでなければ、どの転送を行うこ
ともできない。

【００８７】マスタは該当のＶＴＣ制御フィールドを書
いたあと、データ転送を開始する。その転送が完了した
あと、マスタは別の転送を開始することができる。この
ように転送を連続して開始するには、マスタは少なくと
も１つのＶＴＣ制御フィールドを送信しなければならな
い。後続の転送が別のスレーブに対するものである場合
は、Ｆ０が他の制御フィールドの前に置かれていなけれ
ばならない。後続の転送が同じスレーブに対するもので
ある場合は、フィールドはどの順序であっても構わな
い。送信されないフィールドには前の値が暗黙的に残っ
ている。短い転送を多数行うときのパフォーマンスを最
大にするために、マスタは、値が変更されたフィールド
（例えば、開始アドレス）だけを送信することを選択す
ることが可能である。

【００８８】Ｆ０制御フィールド 以下では、図６を参照してこの制御フィールドについて
説明する。好適実施例では、制御フィールドのビットは
次のとおりである。

【００８９】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘００００’ｂ（Ｆ０を表す）。すべてのビットが
すべてのスレーブによってデコードされる。

【００９０】ビット４：３２ビット制御フィールド。こ
のビットが‘１’のときは、この制御フィールドが単一
３２ビット・ワードとしてＶＴＣ上に与えられることを
示す。‘０’のときは、このフィールドが２つの連続す
る１６ビット・ハーフ・ワードとして与えられることを
示す。

【００９１】ビット５：Ｒ／−Ｗ（リード／ライト）転
送。このビットが‘１’のときは、リード転送が後に続
くことを示す。‘０’のときは、ライト転送であること
を示す。ビット６：３２ビット転送。このビットが
‘１’のときは、後続の転送がＤＡＴＡライン０〜３１
を使用することを示す。‘０’のときは、ＤＡＴＡライ
ン０〜１５が使用され、ＤＡＴＡライン１６〜３１は無
視されること（“ｄｏｎ’ｔ ｃａｒｅ”）を示す。１
６ビット構成では、‘０’にセットしておかなければな
らない。

【００９２】ビット７：６４ビット転送。このビットが
‘１’のときは、後続の転送がＤＡＴＡライン０〜６３
を使用することを示す。‘０’のときは、「３２ビット
転送」の値に応じて、ＤＡＴＡライン０〜３１または０
〜１５が使用され、残りのＤＡＴＡライン（１６〜６
３）または（３２〜６３）は無視されることを示す。制
御フィールドはＤＡＴＡライン（３２〜６３）を使用し
ない。このビットは、３２ビット構成と１６ビット構成
では‘０’にセットしておかなければならない。

【００９３】ビット８−１１：（４ビット）スレーブＩ
Ｄ。アドレス指定するスレーブ・デバイスの４ビット・
アドレスを指定する。

【００９４】ビット１２−１５：（４ビット）マスタＩ
Ｄ。この制御フィールドを書いて後続の転送を行う、マ
スタ・デバイスの４ビット・アドレスを指定する。

【００９５】ビット１６、１７：アドレス指定モード。
Ｆ２（およびＦ３）に指定された開始アドレスの意味を
指定する。

【００９６】００：ピクセル・モード。開始アドレス
は、ビット・マップ・ウィンドウのベースを基準とした
ピクセルであり、Ｌｅｎｇｔｈ（長さ）はピクセル・カ
ウントである。「ビット・マップ」は、アダプタとウィ
ンドウ環境に応じて、スクリーン全体または特定のウィ
ンドウを意味する。ピクセル・カウントとワード・カウ
ントとの関係はＦｏｒｍａｔ（書式）で指定する。

【００９７】０１：絶対データ・モード。開始アドレス
は、アダプタ・メモリのベースを基準としたバイトであ
り、ｌｅｎｇｔｈ（長さ）はバイト・カウントである。
データ・ワード当たり４バイト（最大Ｌｅｎｇｔｈの合
計まで）がある。ＭＢＳ（ビット０−７）が最初であ
る。ウィンドウＩＤ、フレーム・バッファＩＤ、書式、
クリップおよびストライドは、このモードでは無視され
る。

【００９８】１０：予約済。

【００９９】１１：レジスタ・モード。開始アドレス
は、アダプタのレジスタ・アドレス空間のベースであ
る。その他は、絶対データ・モードと同じである。

【０１００】ビット１８−３１：（１４ビット）Ｌｅｎ
ｇｔｈ（長さ）。そのあとに続く転送の長さをピクセル
数またはバイト数で指定する。上述のアドレス指定モー
ドを参照。Ｌｅｎｇｔｈは符号なし２進整数であり、そ
の範囲は０から２＊＊１４−１（２の１４−１乗）でで
ある。Ｌｅｎｇｔｈ＝０のときは、転送データ（Ｆ０で
はクリップ、Ｒ／−Ｗ、アドレス指定モード、Ｆ１では
６４ビット転送、３２ビット転送、Ｆ２とＦ３では開始
アドレス）を記述するパラメータは未定義であるので、
その値は無視される（“ｄｏｎ’ｔ ｃａｒｅ”）。

【０１０１】Ｆ１制御フィールド 図７を参照して、この制御フィールドについて説明す
る。好適実施例では、制御フィールドのビットは次のと
おりである。

【０１０２】ビット０−３（４ビット）フィールドＩＤ
＝‘０００１’ｂ（Ｆ１を表す）。

【０１０３】ビット４：３２ビット制御フィールド。
‘１’のときは、この制御フィールドが単一の３２ビッ
ト・ワードとしてＶＴＣ上を送られることを示す。
‘０’のときは、このフィールドが２つの連続する１６
ビット・ハーフ・ワードとして送られることを示す。

【０１０４】ビット５：クリップ。このビットが‘１’
のときは、転送されるデータがメモリに書かれないピク
セルを含んでいる場合があり、スレーブは内部でクリッ
ピングを行う必要があることを示す。‘０’のときマス
クは、必要なクリッピングがマスタによって行われたの
で、スレーブは内部クリッピングを行う必要がないこと
を示す。このビットは、ピクセル・アドレス指定モード
のライト転送の場合にだけ定義される。

【０１０５】ビット６：予約済。マスタは‘０’と書い
ておかなければならない。スレーブは無視しなければな
らない。

【０１０６】ビット７：ストライド。‘１’のときは、
スレーブは、開始アドレスから始まって、２ずつインク
リメントするアドレスに転送ピクセルをストアする。
‘０’のときは、アドレスは転送されるピクセルごとに
１ピクセルずつインクリメントする。ピクセル・モード
のライト転送の場合だけ定義される。その他の場合は、
マスタは‘０’と書いておかなければならない。

【０１０７】ビット８−１５：（８ビット）ＦＢ Ｉ
Ｄ：フレーム・バッファＩＤ。このピクセル・アドレス
のどのバッファをアドレス指定するかを指定する。２つ
以上のバッファをもつディスプレイ・アダプタの場合に
有用である。この値はスレーブに特有のものである。

【０１０８】ビット１６−２３：（８ビット）ＷＩＤ：
ウィンドウＩＤ。スレーブで使用されるウィンドウＩＤ
値を指定する。どのウィンドウがアドレス指定されるか
を示している。この値はスレーブに特有のものであり、
必ずしも、ウィンドウ管理ソフトウェアで使用されるＷ
ＩＤ値と同じである必要はない。スレーブが直接に、あ
るいは間接に使用して、このウィンドウまたは他のウィ
ンドウのピクセルを保護することができる。

【０１０９】ビット２４−３１：（８ビット）Ｆｏｒｍ
ａｔ（形式）：ピクセルのデータ書式であり、ピクセル
当たりのビット数およびワード当たりのピクセル数が含
まれる。データ書式はピクセル転送の場合にのみを意味
する。つまり、アドレス指定モードがＦ１＝０ｘ００の
ときだけである。他のアドレス指定モードの場合は、ピ
クセルのデータ形式は適用外である。データ形式につい
ては、あとで詳しく説明する。

【０１１０】Ｆ２制御フィールド 図８を参照して、この制御フィールドについて説明す
る。好ましくは、制御フィールドのビットは次のとおり
である。

【０１１１】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘００１０’ｂ（Ｆ２を表す）。

【０１１２】ビット４：３２ビット制御フィールド。
‘１’のときは、この制御フィールドが単一３２ビット
・ワードとしてＶＴＣ上に与えられることを示す。
‘０’のときは、このフィールドは２つの連続１６ビッ
ト・ハーフ・ワードとして与えられることを示す。

【０１１３】ビット５−７：予約済。マスタは‘００
０’と書いておかなければならない。スレーブは無視し
なければならない。

【０１１４】ビット８−３１：（２４ビット）開始アド
レス。上記のＦ１に指定されたアドレス指定モードに応
じて、ピクセル数またはバイト数で指定する。転送に必
要な開始アドレスの長さが２４ビットをこえている場合
は、Ｆ２は最下位２４ビットを収めている。

【０１１５】Ｆ３制御フィールド 好適実施例では、Ｆ３はオプションである。これが使用
されるのは、開始アドレスを指定するのに２４ビット以
上を必要とするスレーブをアドレス指定するときだけで
ある。以下では、図９を参照して、この制御フィールド
について説明する。好適実施例では、制御フィールドの
ビットは次のとおりである。

【０１１６】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘００１１’ｂ（Ｆ３を表す）。

【０１１７】ビット４：３２ビット制御フィールド。
‘１’のときは、この制御フィールドが単一３２ビット
・ワードとしてＶＴＣ上にあたえられることを示す。
‘０’のときは、このフィールドは２つの連続１６ビッ
ト・ハーフ・ワードとして与えられることを示す。

【０１１８】ビット５−７：予約済。マスタは‘００
０’と書いておかなければならない。スレーブは無視し
なければならない。

【０１１９】ビット８−３１：（２４ビット）開始アド
レス。上記のＦ１に指定されたアドレス指定モードに応
じて、ピクセル数またはバイト数で指定する。上位２４
ビットはＦ３の内容と結合されて、４８ビットの開始ア
ドレスが得られる。

【０１２０】Ｆ４制御フィールド Ｆ４は、デバイス間で特定のステータス情報を通知する
ために使用される。これは、データ転送を開始する場合
には不要である。通知転送は、Ｌｅｎｇｔｈ＝０のＦ０
だけからなる場合と、Ｆ０とＦ４からなる場合とがあ
る。この場合、マスタは代表的なデータ転送でアドレス
指定されるスレーブと同じデバイスにすることが可能で
ある。以下では、図１０を参照して、この制御フィール
ドについて説明する。好ましくは、制御フィールドのビ
ットは次のとおりである。

【０１２１】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘０１００’ｂ（Ｆ４を表す）。すべてのビットが
すべてのスレーブによりデコードされる。

【０１２２】ビット４：３２ビット制御フィールド。
‘１’のときは、この制御フィールドが単一３２ビット
・ワードとしてＶＴＣ上に与えられることを示す。
‘０’のときは、このフィールドが２つの連続１６ビッ
ト・ハーフ・ワードとして与えられることを示す。

【０１２３】ビット５：コマンド：ＦＢ ＩＤへスイッ
チ。‘１’のときは、マスタは、ＷＩＤで指定されたウ
ィンドウＩＤをＦＢ ＩＤで指定されたフレーム・バッ
ファＩＤへスイッチするようにスレーブに指示する。こ
れらのフィールドはフィールドＦ１で定義されているも
のと同じ意味をもっている。「スイッチ」とは、スレー
ブからのディスプレイまたは他の出力で使用されるＦＢ
ＩＤをスイッチすることを意味し、データ転送で行わ
れるアドレス指定とアクセスには影響しない。‘０’の
ときは、コマンドの指定がないものとみなされる。

【０１２４】ビット６：ステータス：ＦＢ ＩＤへのス
イッチ完了。‘１’のときは、マスタは、フレーム・バ
ッファへのスイッチが完了したことをスレーブに通知
し、その意味は上記コマンドと同じである。この場合の
マスタを、上記のコマンドの場合にアドレス指定される
スレーブと同じデバイスにすること、およびその逆にす
ることが可能である。‘０’のときは、ステータスの指
定がないものとみなされる。

【０１２５】ビット７：ステータス：ＦＢ ＩＤへの退
避（ｄｒａｗｉｎｇ）完了。このビットが‘１’のとき
は、マスタは、退避が完了し、ＷＩＤで指定された個所
のフレーム・バッファＦＢ ＩＤ中で一時的に中止され
ていることを通知する。これは、スレーブが競合するこ
となく、この個所（ＦＢ ＩＤとＷＩＤ）を読み書きで
きることをスレーブに通知するために使用される。この
場合のマスタを上記のコマンドの場合にアドレス指定さ
れるスレーブにすること、およびその逆にすることが可
能である。‘０’のときは、ステータスの指定がないも
のとみなされる。

【０１２６】ビット８−１５：（８ビット）ＦＢ Ｉ
Ｄ。通知されたフレーム・バッファのＩＤ番号。意味は
フィールドＦ１の場合と同じである。

【０１２７】ビット１６−２３：（８ビット）ＷＩＤ。
通知されたウィンドウＩＤ番号。意味はフィールドＦ１
の場合と同じである。

【０１２８】ビット２４−３１：（８ビット）予約済。
マスタは‘０’と書いておかなければならない。スレー
ブは無視しなければならない。

【０１２９】Ｆ５制御フィールド Ｆ５は、デバイス間で特定のタイミング情報を通知する
ために使用される。これは、データ転送を開始する場合
には不要である。通知転送は、Ｌｅｎｇｔｈ＝０のＦ０
だけからなる場合と、Ｆ０とＦ５からなる場合とがあ
る。この場合のマスタは代表的なデータ転送でアドレス
指定されるスレーブと同じデバイスにすることが可能で
ある。以下では、図６Ｆを参照して、この制御フィール
ドについて説明する。好ましくは、制御フィールドのビ
ットは次のとおりである。

【０１３０】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘０１００’ｂ（Ｆ５を表す）。すべてのビットは
すべてのスレーブでデコードされる。

【０１３１】ビット４：３２ビット制御フィールド。
‘１’のときは、この制御フィールドが単一３２ビット
・ワードとしてＶＴＣ上に与えられることを示す。
‘０’のときは、このフィールドは２つの連続１６ビッ
ト・ハーフ・ワードとして与えられることを示す。

【０１３２】ビット５−１６：（１２ビット）予約済。
マスタは‘０’と書いておかなければならない。スレー
ブは無視しなければならない。

【０１３３】ビット１７：偶数／奇数。‘１’のとき
は、マスタは、「ＶＢＩ開始」（ビット１８）がインタ
レース形式でそのあとに続く偶数フィールドを参照する
ことを通知する。‘０’のときは、マスタは、奇数フィ
ールドが参照されることを通知する。非インタレース・
システムは‘１’と書いておかなければならない。ビッ
ト１８が‘０’のときは、このビットは未定義であるの
で、スレーブは無視しなければならない。

【０１３４】ビット１８：ＶＢＩ開始。‘１’のときマ
スタは、そのディスプレイ機能の垂直ブランク・インタ
ーバル（ＶＢＩ）が最近開始されたことを通知する。イ
ンタレース・システムでは、あとに続くフィールドが偶
数であるか、奇数であるかは、ビット１７で示される。
‘０’のときは、ステータスが指定されていない。

【０１３５】ビット１９：ライン開始。‘１’のとき
は、マスタは、ラインの表示が最近開始されたことを通
知する。参照されるラインはライン番号ビット（２０−
３１）に示されている。‘０’のときは、ステータスが
指定がされていない。

【０１３６】ビット２０−３１：（１２ビット）ライン
番号。最近表示を開始したものとしてビット１９で参照
されるライン番号を示す。番号付けは、非インタレース
・システムでは、最初に表示されるラインを‘０’とし
て開始する。

【０１３７】Ｆ６−Ｆ１４制御フィールド 好適実施例では、これらの制御フィールドは将来の使用
に備えて予約されている。マスタは、これらの制御フィ
ールドを使用してはならない。

【０１３８】仲裁トークン（Ｆ１５） 以下では、図６Ｆを参照してこの制御フィールドについ
て説明する。好適実施例では、制御フィールドのビット
は次のとおりである。

【０１３９】ビット０−３：（４ビット）フィールドＩ
Ｄ＝‘１１１１’ｂ（仲裁トークン（Ｆ１５）を表
す）。

【０１４０】ビット４：３２制御フィールド。‘１’の
ときは、この制御フィールドが単一３２ビット・ワード
としてＶＴＣ上に与えられることを示す。‘０’のとき
は、このフィールドは２つの連続１６ビット・ハーフ・
ワードとして与えられることを示す。

【０１４１】ビット５−７：予約済。マスタは‘００
０’と書いておかなければならない。スレーブは無視し
なければならない。

【０１４２】ビット８−１５：（８ビット）次マスタＩ
Ｄ。ビット（１２−１５）は、仲裁トークンが送られる
マスタのＩＤである。ビット（８−１１）は予約済であ
り、０にしておかなければならない。デバイスはビット
（８−１１）＝‘００００’を含む全８ビットをデコー
ドしなければならない。

【０１４３】ビット１６−２３：（８ビット）前マスタ
ＩＤ。ビット（２０−２３）は、仲裁トークンを送るマ
スタのＩＤである。ビット（１６−１９）は予約済であ
り、０にしておかなければならない。デバイスはビット
（１６−１９）＝‘０００’を含む全８ビットをデコー
ドしなければならない。

【０１４４】ビット２４−３１：予約済。マスタは０を
送信しなければならない。スレーブは無視しなければな
らない。

【０１４５】ＶＴＣおよびＶＴＣ−ＳＡの仲裁 ＶＴＣの仲裁機能はラウンド・ロビン方式になってお
り、これは行動パラメータによって変更される。ラウン
ド・ロビンは、トークン・パッシング・メカニズムによ
って行われる。現在アクティブのＶＴＣマスタデバイス
がバスを手放すときは、本明細書で「ネクスト・レデ
ィ」（Ｎｅｘｔ Ｒｅａｄｙ）と呼ぶ別のマスタに仲裁
トークンを送る。トークンの受取側、つまり、宛先は、
ＩＤがトークンを受け渡すマスタによって指定されたマ
スタである。マスタの各々におけるトークン宛先の値
は、オペレーション状態にあるすべてのマスタが論理的
リング内に置かれ、リングを通る各サイクルごとに一
回、トークンがすべてのマスタを通過するように、ソフ
トウェアによって配置されている。別の実施例では、実
装されたスケジューリング・アルゴリズムに従って異な
るマスタにトークンを渡すことも可能である。

【０１４６】トークンを受け取る側のマスタがＶＴＣを
使用する必要がないとき、あるいはそのときＶＴＣを使
用することが禁止されていた（仲裁行動パラメータによ
って）場合は、論理的リング内の次のマスタへトークン
を渡す。仲裁トークンの初期設定は、各デバイスがテス
トされたあと行われ、そのトークン宛先とスケジューリ
ング行動でプログラムされる。その時点でトークンがシ
ステムにないときは、仲裁トークンを送るようにソフト
ウェアによって任意のマスタ・デバイスが指示され、仲
裁トークンの論理的リング・メカニズムを初期設定する
ことができる。ＶＴＣデバイス内のタイムアウト例外条
件検出機能は、初期設定前に禁止される。

【０１４７】ＶＴＣ−ＳＡでは、ホスト（グラフィック
ス）アダプタは、可能とされるＶＴＣデバイスの各々へ
トークンの送出を開始し、各デバイスがその応答として
初期設定確認ができるようにする。各デバイスが以後の
初期設定作業を行うためには、デバイスはＣＰＵからＶ
ＴＣ経由で送られてきたデータを受信する必要があり、
応答は同じメカニズムを使用してＶＴＣ経由で返送され
る。

【０１４８】ラウンド・ロビン・アクションを変更する
行動パラメータは、各マスタにＶＴＣが許可されたあと
ＶＴＣを保持できる最大時間量と、以前に許可を得たあ
と、再び同じマスタがＶＴＣの許可を得ることができる
までの最小待ち時間がある。これらの時間量は、ＶＴＣ
クロック信号のサイクル数で指定する。これらは、各マ
スタ・デバイスのレジスタに指定される。

【０１４９】仲裁行動の制限は、ソフトウェアによっ
て、あるいはデバイス設計によって設定された行動ルー
ルによって課される。マスタデバイスがどれだけの時間
ＶＴＣの制御権を保持できるかについては、電気的に
も、物理的にも、内在的制限はない。

【０１５０】好適実施例では、アクティブ・マスタとス
レーブは、あるイベント（事象）が起こったときに指定
された時間制限内に、ある種のアクションをとらなけれ
ばならない。すべての制限は、クロック信号のサイクル
単位になっている。第一に、仲裁トークンを受け取った
とき、マスタは例えば（２）サイクル以内に転送を開始
するか、あるいは例えば（２）サイクル以内にトークン
を次のマスタへ渡さなければならない。第二に、転送が
完了したとき、マスタは例えば（２）サイクル以内にト
ークンを送信するか、あるいは別の転送を開始しなけれ
ばならない。第三に、フィールドＦ０でアドレス指定さ
れたとき、アクティブ・スレーブは例えば（１０）サイ
クル以内にＳＬＡＶＥＲＤＹをアクティブにして応答し
なければならない。

【０１５１】起こり得る例外条件によっては、注意が必
要になるものもある。第一は、トークンを受け取ったと
き、マスタが転送を開始したり、トークンを渡したりし
ない場合である。第二は、転送を完了したとき、マスタ
がトークンを送信できない場合である。第三は、転送が
完了しなかったとき、マスタがトークンを送信した場合
である。第四は、アクティブ・マスタでないとき、マス
タがトークンを送信した場合である。第五は、リード転
送またはライト転送において、スレーブがＦ０でアドレ
ス指定されたとき、それに応答しない場合である。第六
は、正しくないデータまたは制御フィールドの値がスレ
ーブによって受信された場合である。第七は、実際の送
信長さがＦ０のＬｅｎｇｔｈフィールドに一致していな
い場合である。第八は、ＶＴＣバス経由で受信した値が
送信されたものと同じでない場合である。

【０１５２】どのマスタまたはスレーブも、いくつかの
例外条件を検出できるようにすることが可能である。転
送またはトークン・パッシングに参加していないデバイ
スによって検出できる条件としては、次のものがある。
第一は、仲裁トークンが送信されたが、次のマスタがク
ロック・サイクルの好適時間制源内に応答しない場合で
ある。第二は、クロック・サイクルの好適制限をこえて
ＭＡＳＴＥＲＲＤＹがインアクティブにある間、仲裁ト
ークンが送信されない場合である。第三は、仲裁トーク
ンが送信されたあと制御フィールドが送信される前にデ
ータが送信された場合である。第四は、「前の」マスタ
が前の「次の」マスタと同じでない場合に仲裁トークン
が送信された場合である。第五は、ＦＯでアドレス指定
されたあと、スレーブがクロック・サイクルの好適制源
内にＳＬＡＶＥＲＤＹをアクティブに駆動しなかった場
合である。第六は、ＳＬＡＶＥＲＤＹが転送期間にクロ
ック・サイクルの好適制限をこえて（‘Ｌｅｎｇｔｈ’
項目が転送される前）インアクティブであった場合であ
る。第七は、いずれかの転送期間に（ＳＬＡＶＥＲＤＹ
をアクティブにして）‘Ｌｅｎｇｔｈ’データ項目より
多い項目が生成された場合である。

【０１５３】グラフィックス・アダプタ ＶＴＣ−ＳＡ接続デバイスのホストの働きをするグラフ
ィックス・アダプタはＶＴＣ−ＳＡの好適実施例を実現
するためには、ある種の機能を特定の方法で実行しなけ
ればならない。グラフィックス・アダプタは、指定され
た機能のほかに、ＶＴＣを通してそのディスプレイ・バ
ッファをアクセスできるようになっていなければならな
い。ディスプレイ・バッファをアクセスする機能の説明
は、ここでは省略する。代表例として、グラフィックス
・アダプタはディスプレイ・バッファをアクセスＶＴＣ
スレーブとして働く。

【０１５４】ローカル・バッファ メイン・メモリ中の出力（Ｏｕｔ）バッファは、そのあ
とでデータをＶＴＣ経由でＶＴＣデバイスが取得する前
にシステム・バス上でシステム・メモリから取得したデ
ータをストアしておくためのものである。メイン・メモ
リ中の入力（Ｉｎ）バッファは、データがシステム・バ
スを経由してシステム・メモリに書かれる前にＶＴＣ経
由でＶＴＣデバイスから送られてきたデータをストアし
ておくためのものである。これらのバッファの各々は、
少なくとも３２バイト（８ワード）長であることが好ま
しい。原理的には、もっと小さいバッファも可能である
が、バッファを小さくすると、システム・パフォーマン
スが低下することになるので、望ましくない。入力バッ
ファと出力バッファは、それぞれ２つの異なるプロセ
ス、つまり、バス・インタフェースとＶＴＣインタフェ
ースによりアクセスできるが、これらは、同時デュアル
・ポート読み書きアクセスをサポートする必要はない。

【０１５５】これらの２つのバッファは、各々に関連す
るカウント・レジスタをもっている。出力（Ｏｕｔ）カ
ウント・レジスタは、出力バッファに入れることができ
るデータの量を示している。入力（Ｉｎ）カウント・レ
ジスタは、入力バッファに入れることができるデータ空
間の量を示している。これらのレジスタはどちらも、Ｖ
ＴＣ経由で読み取ることができる。バッファのアドレス
指定方式は、いろいろな方法が可能である。カウント・
レジスタは、単一ポート・バッファに実際の現アドレス
を格納するようにすることも、独立のリード（Ｒｅａ
ｄ）ポインタとライト（Ｗｒｉｔｅ）ポインタとの差を
格納するようにすることもできる。

【０１５６】システム・バス・インタフェース 本発明が目的とするＶＴＣ−ＳＡの応用例では、グラフ
ィックス・アダプタはＣＰＵバス上のバス・マスタにな
っている。グラフィックス・アダプタは、ＶＴＣ−ＳＡ
をサポートするために専用化された２つのシステム・キ
ュー（待ち行列）をアクセスする。そのために、グラフ
ィックス・アダプタは、これらのキューをポイントする
２組のポインタをボード上に有する。これらのポインタ
の代表的なものは、各キューのトップ、ボトム、リー
ド、およびライト位置を指しているので、キューごとに
４つのレジスタが必要である。レジスタのサイズは、シ
ステム設計によって決まる。ポインタは実メモリ・アド
レスを使用する。

【０１５７】グラフィックス・アダプタ上のシステム・
キュー・ポインタを用いて、グラフィックス・アダプタ
は、各キューに残っているデータ量とスペース量を容易
に確かめることができる。また、これらのポインタ・レ
ジスタをソフトウェアで調べて、各キューに残っている
スペース量とデータ量を確かめることもできる。

【０１５８】グラフィックス・アダプタは、キュー・バ
ス・マスタのアクティビティを禁止するプログラム機能
を有することが必要である。これが必要とされるのは、
バス・マスタのアクティビティが必要であるとグラフィ
ックス・アダプタに誤って通知しないようにシステムが
システム・キュー・ポインタをリダイレクトして、正し
くないアドレス範囲がアクセスされるのを防止するため
である。

【０１５９】好適実施例では、ＶＴＣ−ＳＡをサポート
するキューの中のすべてのデータが３２ビット（１ワー
ド）の整数倍になっており、ワード全体の境界、つま
り、４の整数倍のバイト・アドレス上に境界合わせされ
ていれば、その実現は簡単である。グラフィックス・ア
ダプタは、ＶＴＣ−ＳＡの両方のシステム・キューにお
いてこの定数の後に続いて置かれているデータを頼るこ
とができるので、バイト回転などを行う必要がない。こ
のバイト回転などは、任意的なアドレスが許容される場
合に必要になるものである。

【０１６０】システム・バス・マスタであり、バス・マ
スタの権限を使用してＶＴＣ−ＳＡキューとバッファを
管理するグラフィックス・アダプタはそれがサポートす
るように設計されている他のプロセスのほかに、ＶＴＣ
−ＳＡの目的のために２つのプロセスをサポートしてい
る。これらとしては、出力バッファをいっぱいに保ち、
関連の出力キューを空に保つプロセスおよび入力バッフ
ァを空に保ち、関連の入力キューをいっぱいに保つプロ
セスがある。

【０１６１】手順としては、グラフィックス・アダプタ
は、システム・キューおよびＶＴＣ−ＳＡオンボード・
バッファを次のように管理する。出力バッファに利用可
能なスペースがあり、出力キューに利用可能なデータが
あると、グラフィックス・アダプタはシステム・バスの
仲裁を試みる。仲裁が許可されると、グラフィックス・
アダプタは、バッファ中のスペース量とキュー中のデー
タ量のうち少ない方を、バス許可期間のリミットまでキ
ューからバッファへ転送する。

【０１６２】入力バッファに利用可能なデータがあり、
入力キューに利用可能なスペースがあると、グラフィッ
クス・アダプタはシステム・バスの仲裁を試みる。仲裁
が許可されると、グラフィックス・アダプタは、バッフ
ァ中のデータ量とキュー中のスペース量のうち少ない方
を、バス許可期間のリミットまでバッファからキューへ
転送する。

【０１６３】バッファが単一ポートであり、システム・
バスが許可された時点で必要とするバッファがＶＴＣア
クティビティで使用中であれば、グラフィックス・アダ
プタは、バスおよびバス・インタフェース回路の設計に
応じて、バス・アクティビティを中止または歩調合わせ
する必要がある。

【０１６４】出力キューからのデータ読取りが完了する
と、出力キューのリード・ポインタはグラフィックス・
アダプタによって更新される。これにより、ＣＰＵは出
力キュー中の利用可能な新しい空間の量を判断すること
ができる。これと同時に、グラフィックス・アダプタは
出力バッファに関連する利用可能なデータ・カウントを
更新し、ＶＴＣデバイスがこのバッファ中の利用可能な
データ量を判断できるようにする。

【０１６５】入力キューへのデータ書込みが完了する
と、入力キューのライト・ポインタはグラフィックス・
アダプタによって更新される。これにより、ＣＰＵは入
力キュー中の利用可能な新しい空間の量を判断すること
ができる。これと同時に、グラフィックス・アダプタは
入力バッファに関連する利用可能な空間のカウントを更
新し、ＶＴＣデバイスがこのバッファ中の利用可能なデ
ータ量を判断できるようにする。

【０１６６】入力バッファ中に利用可能なデータがある
かどうか、あるいは出力バッファ中に利用可能な空間が
あるかどうか、その結果、システム・バス・アクティビ
ティが必要であるかどうかの判断は、カウンタ・レジス
タまたは同じような機能をもつ他の回路に基づいて行わ
れる。この判断は、それぞれ入力バッファまたは出力バ
ッファとの間のアクティブＶＴＣ転送が完了がしたあと
行うべきである。その理由は、そのようにしないと、転
送量の見積もりを行うのが早すぎるために、システム・
バス・マスタが通常のバーストよりも少ない量のデータ
を転送し、その結果システム・バスの使用効率が低下
し、場合によっては、ＶＴＣの使用効率が低下し、待ち
時間が増加するためである。

【０１６７】例えば、入力バッファが初期状態において
空であり、ＶＴＣデバイスが３２バイト（８ワード）の
転送を開始する場合は、グラフィックス・アダプタのバ
ス・マスタは、８ワードすべてが入力バッファに置かれ
るまでは転送を開始してはならない。この結果は、ＶＴ
Ｃ転送が完了するまでバス仲裁が開始されないようにす
れば、保証される。

【０１６８】これと同時に、重要なケースとして、シス
テム・バス上またはＶＴＣ上を転送されるデータ量が８
ワード未満である場合がある。つまり、例えば、３２バ
イトの倍数のデータ・ストリームであることが保障され
ない場合がある。バッファとの間の現在のＶＴＣ転送が
完了したとき、システム・バス・インタフェースは、そ
の結果通常のバーストよりも短いシステム・バス転送と
なる場合であっても、以後のＶＴＣ転送を待つことな
く、バッファの全内容を処理しなければならない。さも
ないと、少量の重要データに許容し得ない待ち時間が生
じることになる。

【０１６９】グラフィックス・アダプタは、バス・マス
タ権限機能の使用を争奪する複数の内部タスクを有する
場合があるため、仲裁方式が必要になる。ＶＴＣ−ＳＡ
キューおよびバッファ管理プロセスは、グラフィックス
・アダプタのバス・マスタ権限内で最高優先度のタスク
である必要がある。これは、ＶＴＣ補助データが通常リ
アルタイムであり、バッファ・オーバフローまたはアン
ダフローを避けるために達成しなければならないデッド
ラインがあり、頻繁なサービスが必要であるという事実
に基づくものである。同様に、グラフィックス・アダプ
タには、ＣＰＵバスまたはマイクロ・チャネル上で高い
優先度をもたせて、タイムリーなサービスを保障する必
要がある。この場合も、これは、頻繁なサービスが必要
なためである。

【０１７０】同様に、システム・キューを管理するソフ
トウェアは実行頻度を高くする必要があるので、高い優
先度あるいは保障された高いスケジューリング頻度を有
する。

【０１７１】グラフィックス・アダプタからＣＰＵに割
込みをかける必要性は、一般的には確立されていない。
これはシステムに依存するパフォーマンス上の問題であ
り、この一般的アーキテクチャの範囲をこえている。例
えば、出力キューが空であること、あるいは入力キュー
がいっぱいであることを通知するといった、割込みはキ
ューのサービスをタイムリーに行うことを保証するため
に、ある種のソフトウェア・アーキテクチャで有用であ
る。

【０１７２】システム・データ・バッファを指すポイン
タを含めることによって、間接的処置（ｉｎｄｉｒｅｃ
ｔｉｏｎ）レベルを利用するキューを実装することが可
能である。これは、ＶＴＣインタフェースには影響しな
い。

【０１７３】ＶＴＣインタフェース 好適実施例では、補助データがグラフィックス・アダプ
タとＶＴＣデバイスとの間で受け渡しされる転送におい
ては、グラフィックス・アダプタはＶＴＣスレーブとし
て働く。

【０１７４】出力バッファからデータを取り出す場合
は、ＶＴＣデバイスはマスタとして働く。データを取り
出す前に、ＶＴＣデバイスはＶＴＣを介して出力カウン
ト（Ｏｕｔ Ｃｏｕｎｔ）レジスタを読み取って、出力
バッファにデータがどれだけ残っているかを判断する。
その時点で（またはあとで）、ＶＴＣデバイスは、受信
した出力カウント・レジスタ値に指定されたデータ量ま
でのリード転送を、グラフィックス・アダプタからＶＴ
Ｃ経由で行うことができる。出力バッファは、ＶＴＣデ
バイスによってＦＩＦＯとして扱われる。従って、固定
開始アドレスがそのような転送のために用いられる。

【０１７５】インバウンド・データの送信も同じように
行われる。すなわち、ＶＴＣデバイスはＶＴＣの制御権
を受け取り、グラフィックス・アダプタから入力カウン
ト（Ｉｎ Ｃｏｕｎｔ）レジスタを読み取る。そのあ
と、受信した入力カウント値に示されたデータ・スペー
ス量までのライト転送をグラフィックス・アダプタに対
して行うことができる。出力転送の場合と同様に、入力
バッファ・ライト転送でも固定アドレスが使用される。

【０１７６】入力バッファおよび出力バッファのカウン
ト・レジスタは、３２ビット・ワードの個数またはデー
タもしくはスペースのうち、該当するものを符号なし２
進整数で示している。これらの各々は、単一ＶＴＣワー
ド内の１６ビット・フィールドに置かれている。

【０１７７】通常は、グラフィックス・アダプタは、カ
ウント・レジスタ内の有意情報用として４〜６ビットだ
けを必要とする。より上位の定数ビットはゼロとしてお
くべきである。例えば、８ワード・バッファのときは、
取り得る値は０〜８までの９個であるので、４ビットが
必要である。

【０１７８】カウント・フィールドは３２ビット・ワー
ドの個数を示しているが、メモリ・アドレス指定および
レジスタ・アドレス指定モードでのＶＴＣ転送では、長
さをバイト・カウントで指定している。ＶＴＣのバイト
・カウントは、他のアプリケーションでも使用できる。
補助的なデータ転送を行うＶＴＣデバイスは、上記の長
さフィールドからＶＴＣ Ｆ０制御ワード内の長さフィ
ールドに変換するとき、その差、つまり、係数４を考慮
に入れる。

【０１７９】入力および出力カウント・レジスタならび
に入力および出力バッファの上記機能を実行するため
に、ＶＴＣ上に２つのアドレスが指定される。入力カウ
ント・レジスタと出力カウント・レジスタは、上述した
ように、カウント・フィールドの１つのリード転送とし
てアクセスされる。一実施例では、カウント・レジスタ
は、現在予約済になっているアドレス・モード‘１０’
と開始アドレス‘０’にマップされる。入力と出力バッ
ファは同じアドレスを用いてアクセスされる。出力はリ
ード転送を使用し、入力はライト転送を使用する。別の
実施例では、入力と出力バッファは、アドレス・モード
‘１１’、レジスタ・モード、および開始アドレス
‘０’にマップされる。上記実施例の両方が用いられる
場合は、そのような転送時にＶＴＣの開始アドレス・フ
ィールド（Ｆ２）を完全に無視できるので、ＶＴＣ上の
オーバヘッドが最小になる。

【０１８０】グラフィックス・アダプタは、ＶＴＣ−Ｓ
Ａホスト・アダプタを実現するために、非常に基本的な
ＶＴＣマスタ機能を必要とする。その機能とは、仲裁ト
ークンを指定したＶＴＣ ＩＤへ送信し、仲裁トークン
を受信した時それを同じＶＴＣ ＩＤへ継続的に再送す
るか、あるいはその受信時にＶＴＣ仲裁トークンを中止
し、トークンを受信したことをシステムに通知する機能
である。これらの機能により、システムは、どのＶＴＣ
ＩＤがデバイスを導入しているかを判断して、すべて
のＶＴＣデバイスを初期設定することができる。定常状
態のオペレーションでは、初期化が終わると、グラフィ
ックス・アダプタは、他のＶＴＣマスタ・アクティビテ
ィを実行することなく、トークンが受信されるたびにト
ークンを指定したＩＤへ継続的に再送する。ＶＴＣ−Ｓ
Ａの要求を越える他の理由からＶＴＣマスタ機能が必要
であれば、その機能をグラフィックス・アダプタに組み
入れることが可能である。

【０１８１】ＶＴＣは本来的にマスタとスレーブの双方
によるすべての転送の歩調合わせを行うが、バス効率と
システム・パフォーマンスを維持するために、補助デー
タ転送のパフォーマンスを向上するための機能も含まれ
ている。

【０１８２】カウント・レジスタの読取りは、できる限
り高速に完了させる必要がある。カウント・データ値を
アクティブな状態でＶＴＣ上に送出する前に、グラフィ
ックス・アダプタがＶＴＣラインのＳＬＡＶＥＲＤＹを
ノン・レディ（ｎｏｎ−ｒｅａｄｙ）状態に保持したま
ま、ＶＴＣクロック・サイクルを通過させることが可能
である。出力バッファからのリード転送では、アクティ
ブな返却データをＶＴＣ上に送出し始める前にＶＴＣク
ロック・サイクルをノン・レディ状態にすることが可能
である。そのあと、要求されたリード転送データは、２
クロック・サイクル当たり１ワードの割合で、あるいは
もっと高速に転送する必要がある。１６ビットＶＴＣで
は、これは各クロック・サイクルごとに１個のハーフ・
ワードが転送されることを意味する。３２ビットＶＴＣ
では、これは、最大でも１個のノン・レディ・サイクル
との交互に発生するサイクルで１ワードが転送されるこ
とを意味する。入力バッファへライト転送するときに必
要なタイミング条件も同じである。つまり、ＶＴＣマス
タ・デバイスは、ＶＴＣ制御フィールドを書いた直後に
データを書き始めることができる。グラフィックス・ア
ダプタ（ＶＴＣスレーブ）はいくつかのノット・レディ
・サイクルを発生することができる。これらは、そのよ
うな期間に転送されるワード数に例えば３を加えたもの
までに制限しておく必要がある。上記には例外がある。
それは、グラフィックス・アダプタのＶＴＣ ＦＩＦＯ
が直前のディスプレイ・バッファをアクセスするＶＴＣ
転送ですでに占有されている場合である。グラフィック
ス・アダプタは、指定された値よりも大か等しいインタ
ーバルが、カウント・レジスタの連続する読取りの間に
存在するものと想定することができる。

【０１８３】ビデオ機構の機能 ＶＴＣ接続のビデオ機構は、ホスト・システムとのデー
タ通信をすべて、出力キューおよびバッファならびに入
力キーおよびバッファを有するアウトバウンド・データ
通路とインバウンド・データ通路を経由して行う。以下
では、ＶＴＣデバイスとの間で受け渡す補助データ・ス
トリームに適用されるデータ書式およびその依存関係に
ついて説明する。

【０１８４】ＶＴＣ−ＳＡアーキテクチャは、１または
２以上のＶＴＣデバイスが接続されている構成の場合に
すぐれたパフォーマンスを発揮する。説明を簡単にする
ために、最初に、１台のデバイスだけからなる構成の場
合について説明する。そのあとのセクションでは、複数
のデバイスを使用するときのデバイス要件と行動につい
て説明する。

【０１８５】ＶＴＣデバイスはグラフィックス・アダプ
タにポーリングして、出力バッファ中のデータ量と入力
バッファ中のスペース量を判断する。出力バッファにデ
ータが残っていて、ＶＴＣデバイスがそのデータを受け
入れるための空間をもっていると、ＶＴＣデバイスはＶ
ＴＣリード転送を行って、そのデータを読み取る。デバ
イスは、内部バッファに残っているスペースの方が少な
ければ、残っているデータ量よりも少ないデータを読み
取ることが可能である。ＶＴＣデバイスがデータ用のス
ペースを常に残しておくように配慮したシステム設計が
望ましいが、その場合は、このアーキテクチャの範囲を
こえる非常に多数の要因によって左右されるので、この
アーキテクチャでは保証されない。

【０１８６】ＶＴＣデバイスは、受信したデータについ
て、データ・タイプに応じて、見合った処理を行う。つ
まり、どのデータがコマンドを構成し、どれがビデオの
ような圧縮データであるかを判断し、その判断に従って
コマンドまたは圧縮データを処理する。

【０１８７】ＶＴＣデバイスはシステムへ送るべきデー
タをもっていると、グラフィックス・アダプタをポーリ
ングして入力バッファに残っているスペースの量を判断
する。そのあと、ＶＴＣデバイスは、送信待ちになって
いるデータ量と入力バッファに残っているスペース量の
うち少ない方を、ＶＴＣライト転送を使用してＶＴＣ経
由で入力バッファへ転送する。

【０１８８】多くの場合、２つ以上のＶＴＣ接続機構を
同時にサポートする必要はない。従って、複数のＶＴＣ
デバイスの場合の以下に列挙した機能は、この種のシス
テムを意図したアダプタでは、実装させる必要はない。

【０１８９】接続されたＶＴＣ機構が２つ以上あるとき
は、１つのＶＴＣ機構は初期設定時にディストリビュー
タ（Ｄｉｓｔｒｉｂｕｔｏｒ）として指定され、他のデ
バイスはすべて代替デバイス（Ａｌｔｅｒｎａｔｅ）と
して参照される。ディストリビュータはすべてのアウト
バウンド・データを処理し、これは適切な代替デバイス
へ渡される。代替デバイスは、ディストリビュータの制
御の下で、インバウンド・データを直接に入力バッファ
に（従って、入力キューにも）送り込む。ディストリビ
ュータの働きは単独のＶＴＣデバイスと全く同じである
が、追加機能として、アウトバウンド・データを代替デ
バイスへ転送し、代替デバイスからのインバウンド・デ
ータ転送を必要時に制御する。

【０１９０】すべてのＶＴＣデバイスは、初めて初期設
定されるとき、初期状態では単独のＶＴＣデバイスであ
るかのように動作する。事実、好適実施例では、これが
必要であるのは、ＣＰＵからコマンドを受け取るまで
は、これらのデバイスに異なった動作を行うように指示
できないためである。

【０１９１】リード転送でディストリビュータが受信す
るアウトバウンド・データの一部が別の（代替）デバイ
スあてのパケットのヘッダである場合は、そのプロトコ
ルは次のようになっている。第一に、ディストリビュー
タは取り出すべきパケットの存在と長さを示したメッセ
ージをターゲット代替デバイスに引き渡す（初期状態で
は、パケット全体をディストリビュータに保持させる必
要はない）。第二に、代替デバイスはディストリビュー
タからのデータを読み取る。パケット全体が読み取られ
るまで、必要に応じて読取りが繰返し行われる。第三
に、代替デバイスはパケットの受信を完了したことを示
したメッセージをディストリビュータへ送信する。

【０１９２】パケットをディストリビュータから代替デ
バイスへ転送するとき、ディストリビュータは、グラフ
ィックス・アダプタが補助データをＶＴＣデバイスへ転
送するときと同じように行動する。しかし、ディストリ
ビュータは、データ・ストリームにコーディングされた
宛先フィールドと長さフィールドを調べることによっ
て、代替デバイスあてのデータだけが代替デバイスへ送
信されるように配慮し、同じように、代替デバイスは自
分あてのデータ量だけを読み取るように配慮される。一
般的には、ディストリビュータは、補助データを他のＶ
ＴＣデバイスへ再送するとき使用される、別のデータ・
バッファを備えている。

【０１９３】パケットを代替デバイスへリダイレクトす
るには、ディストリビュータに若干の待ち時間が生じる
ことになる。つまり、解析（ｐａｒｓｉｎｇ）とリダイ
レクトのためには、十分なバッファ能力があり、総待ち
時間がシステム・レベルの問題を引き起こさない限り、
オンボード・プロセッサの援助が必要になることがあ
る。プロセッサ援助によるリダイレクトを行ったとき、
単純設計で起こる追加待ち時間が通常約１０ｕｓをこえ
てはならない。追加待ち時間が１００ｕｓ〜１ｍｓのオ
ーダのとき、通常問題が起こってはならない。

【０１９４】複数のＶＴＣデバイスが導入されていて、
ディストリビュータ以外のデバイス（代替）がシステム
へ送るデータをもっている場合は、そのプロトコルは次
のとおりである。第一に、代替デバイスは入力バッファ
の使用を要求するメッセージをディストリビュータへ送
信する。第二に、ディストリビュータはその現パケット
の送信を完了すると、ディストリビュータは、入力バッ
ファが代替デバイスによって現在所有されていることを
示すメッセージを代替デバイスへ返送する。第三に、代
替デバイスはディトリビュータと全く同様に行動し、残
っているデータとスペースの量に従ってデータを入力バ
ッファに書き出す。第四に、代替デバイスがデータを入
力バッファに書くのを完了すると、代替デバイスはメッ
セージをディストリビュータへ送って、入力バッファの
制御権を返却する。代替デバイスが入力バッファを使用
している間は、ディストリビュータを含む、他のどのデ
バイスも、データを入力バッファに書くことはできな
い。これには例外がある。それは、入力キューを所有で
きる時間制限に代替デバイスが違反するというエラー条
件が起こったときである。そのような場合は、ディスト
リビュータは優先使用（Ｐｒｅｅｍｐｔ）メッセージを
代替デバイスへ送って、パケットを入力バッファに書く
ことを始める。おそらくこのようなパケットは、エラー
が検出されたことを示す。そのようなエラーが起こっ
て、回復が行われると、システムの入力キューの中に
は、記述ワード内の前の長さフィールドが指示していな
いロケーションに次のパケット・フラグが入っている可
能性がある。解析ソフトウェアは、新しいフラグ・ワー
ドを見つけ、長さと後続のフラグ・ワードを通して確か
めることによって、回復を行う必要がある。

【０１９５】ディストリビュータは、その現パケットの
送信を完了するまでは、入力バッファの所有権を要求側
代替デバイスへ渡すことはできない。そのために必要に
なる時間量は、入力バッファをアクセスするときのパケ
ット・サイズ、頻度および待ち時間、グラフィックス・
アダプタが入力バッファを入力キューに解放するときの
待ち時間、および入力キューにスペースがあるかどうか
によって左右される。また、入力バッファの使用を要求
する代替デバイスが２つ以上のときは、一定の順序でア
クセス権を与える必要があるので、一部の代替デバイス
に追加の待ちが生じすることになる。以上の理由のため
に、代替デバイスが入力バッファを獲得するときの待ち
時間の保証は、入力キューを解析するソフトウェアを含
めて、システム全体のパフォーマンスが問題となるので
なければ、本明細書の範囲をこえるものである。

【０１９６】システムといずれかのＶＴＣデバイス（デ
ィストリビュータだけでなく）間でやり取りされるデー
タは、パケットの形になっている。パケット・サイズ
は、システムキューまたは入力および出力バッファのサ
イズに関係がるとは限らない。従ってＶＴＣデータ転送
のサイズと関係があるとは限らない。データを代替デバ
イスへ配布し、代替デバイスからデータを収集する場合
の上述の説明では、ディトリビュータから取り出される
データ量や代替デバイスからグラフィックス・アダプタ
へ送信されるデータ量は、それぞれこれらのデータ・パ
ケットによって決まる。複数のＶＴＣデバイスが存在す
るときは、代替デバイスはパケット全体だけを取り出す
ように指示される。同様に、代替デバイスがデータを入
力キューに書くときは、代替デバイスが入力キューを制
御している期間の間に、パケット全体だけを書くことが
できる。しかし、パケットを１回のＶＴＣ転送でやりと
りする必要がなく、一般にそうすることは実用的でな
い。

【０１９７】バスの初期設定 好適実施例では、ＶＴＣおよびＶＴＣ−ＳＡデバイス
は、ＶＴＣ上で静止状態で電源が投入される。デバイス
は、設計とスロット配線に依存する。ＶＴＣデバイスＩ
Ｄを使用して電源が投入される。例えば、ある種のシス
テムでは、最大４台のＶＴＣデバイスが導入されている
場合がある。この場合は、各デバイスはチップ設計また
はカード配線によって、２個のＩＤビットを除くビット
はすべて固定され、この他の２ビットはＶＴＣコネクタ
に配線されるように設計されている。最大４個までの各
コネクタは、これらの２ビットについて固有の値を有す
る。

【０１９８】ＶＴＣデバイスのホストとなるグラフィッ
クス・アダプタは、固定ＶＴＣ ＩＤにハード布線され
ていることが好ましい。グラフィックス・アダプタのＩ
Ｄは電源投入により通信するデバイスとして設計時にす
べてのＶＴＣ−ＳＡデバイスに組み込まれる。ＣＰＵの
指示を受けて、グラフィックス・アダプタは、ＶＴＣト
ークンを可能とされる各ＶＴＣ ＩＤへ送り、その見返
りとして、トークンが返却されたかどうかを確かめ、こ
れによりＶＴＣデバイスが存在することを検出する。デ
バイスを初期設定するために、ＣＰＵは初期設定コマン
ドを出力キューに置き、ＧＡ内の出力キューをセットア
ップし、出力キューを使用可能にし、その特定のＶＴＣ
デバイスへトークンを継続的に送るようにグラフィック
ス・アダプタに指示する。すべてのＶＴＣデバイスは、
トークンを送るときに使用される固定の初期次マスタＩ
Ｄを使用して電源が投入されるが、このＩＤはホストと
なるすべてのグラフィックス・アダプタで使用されるも
のと同じである。その指定されたＶＴＣデバイスは、次
に、出力バッファにデータが存在するかどうかを問い合
わせるためにグラフィックス・アダプタをポーリング
し、そのあと、ＣＰＵからのデータ・パケットを出力バ
ッファから読み取る。返すことのできる応答があるとき
は、入力バッファを経由してその応答を返送する。他の
デバイスを初期設定するために、ＣＰＵの指示を受け
て、グラフィックス・アダプタは最初のデバイスへトー
クンを送信することを中止し、他のデバイスの各々につ
いて上記オペレーションが繰り返される。

【０１９９】デバイスが２以上存在するとき、すべての
デバイスが初期設定されると、１つのデバイスがディス
トリビュータとして指名され、他のデバイスはすべて代
替デバイスとして指名される。各デバイスに次マスタ値
がセットされ、トークンを特定されたデバイスへ送信す
る。これによりすべてのデバイスはラウンド・ロビン構
成に配置される。

【０２００】複数のデバイスが存在する場合は、代替デ
バイスは、以下に説明する場合を除き、出力キューを照
会したり、入力キューへデータを送信したりすることは
できない。ディトリビュータ以外のデバイスの場合は、
出力キューはディストリビュータに置かれており、入力
キューはディストリビュータが許可したときだけ使用で
きる。

【０２０１】段階的品質低下 本発明は、過負荷状態において必要に応じて動作して、
ＶＴＣまたはＶＴＣ−ＳＡのバンド幅の利用効率を向上
させると共に、ソースの数およびタイプと表示品質との
間のバランスをユーザが判断できるようにする段階的品
質低下を目的としている。図１３は、本発明の好適実施
例をグラフィックス・アダプタと併用してビデオを表示
するためのビデオ・アダプタを示している。ビデオ・ア
ダプタ６００はビデオ入力バス６０５上のビデオ入力信
号を受信する。ビデオ入力信号はＮＴＳＣアナログ信号
または類似する信号にすることができる。ビデオ・プロ
セッサ６１５はアナログ・ビデオ入力信号を受信し、デ
ィジタル化して、そのディジタル化の結果をバッファ６
２０にストアしておく。データは、そのあとで、ＶＴ
Ｃ、ＶＴＣ−ＳＡまたはその他のタイプのバスであるバ
ス６１０上を転送される。好適実施例では、バッファは
循環バッファであり、ヘッド・ポインタ（ｈｅａｄ ｐ
ｏｉｎｔｅｒ）６２５とテール・ポインタ（ｔａｉｌ
ｐｏｉｎｔｅｒ）６３０でビデオ・データがバッファの
どこにストアされているかを示している。到来アナログ
・データがディジタル化されると、そのデータはバッフ
ァ６２０にストアされ、ヘッド・ポインタを更新する。
バスが許していると、アダプタ・プロセッサはバッファ
６２０からデータを読み取り、テール・ポインタ６３０
を更新し、データをバス６１０経由でグラフィックスプ
ロセッサへ送信する。好適実施例では、バッファは循環
メモリであり、１フレーム相当のビデオ・データを保持
している。グラフィックス・アダプタ６５０はグラフィ
ックス・プロセッサ６５５を含んでおり、このプロセッ
サはビデオ・アダプタ６００のほかに、他のソースから
もデータをビデオ・バス経由で受信し、そのビデオ・デ
ータをフレーム・バッファ６６０にロードして、ディス
プレイ６６５上に表示する。

【０２０２】図１４は、表示されるデータの品質を徐々
に低下させる好適方法を示すフローチャートである。第
一ステップ７００において、アダプタ・プロセッサ６１
５はビデオ入力バス６０５上のアナログ・ビデオ入力デ
ータを受信し、将来の表示のためにそのデータをディジ
タル化する。ステップ７０５において、ビデオ・アダプ
タは、ヘッド・ポインタとテール・ポインタを比較し、
ヘッド・ポインタが折り返されてテール・ポインタまで
達していたかどうかを確かめることによって、バッファ
６２０がいっぱいかどうかを判断する。フレーム・バッ
ファがいっぱいでなければ、ステップ７１０において、
アダプタ・プロセッサはディジタル化したデータをバッ
ファ６２０にロードし、テール・ポインタ６３０を更新
する。このプロセスはステップ７００，７０５および７
１０の間で続けられ、その間、アダプタ・プロセッサも
データをバッファからバス６１０を経由してグラフィッ
クス・アダプタへ転送している。

【０２０３】バッファ６２０がいっぱいであって、ビデ
オ・アダプタが以前に格納したディジタル化されたデー
タをグラフィックス・アダプタへ送ることができないと
きは、処理はステップ７１５まで続けられる。ステップ
７１５において、アダプタ・プロセッサはバッファにス
トアされている現フレームを消去する。アダプタ・プロ
セッサは消去を、単にテール・ポインタをバッファにス
トアされている前のフレームまたはその一部の最後に移
動することにより行う。ステップ７２０において、アダ
プタ・プロセッサは、ディジタル化されたばかりのデー
タを破棄する。ステップ７２５において、アダプタ・プ
ロセッサは追加のアナログ・データを受信して、そのデ
ータをディジタル化する。ステップ７３０において、最
後にディジタル化したデータが破棄されたものと同じフ
レームからのものであれば、処理はステップ７２０まで
続けられ、そこでその新しいフレームデータは再び破棄
される。しかし、最後にディジタル化されたデータが新
しいフレームからのものであれば、処理はステップ７０
５へ戻り、アダプタ・プロセッサは、バッファがいっぱ
いであるかどうかを再び判断する。殆どの場合、バッフ
ァには、別のビデオ・フレームの受け入れを開始するだ
けの十分な余地を用意しておく必要がある。

【０２０４】好適実施例による段階的品質低下手法の利
点の１つは、ビデオ・フレームまたは他のタイプのデー
タ・グループが必要時にだけ破棄されることである。す
なわち、フレームが破棄されるのは、ビデオ・アダプタ
がすべての到来データのストアおよび送信をできないと
きだけである。さらに、種々のアダプタに高い優先度を
もたせることができる別の種類の優先方式によれば、優
先度の低いビデオ・アダプタは、過負荷状態が起こった
とき、破棄されるフレームが多くなるのが一般的であ
る。

【０２０５】システム・キュー 好適実施例では、ＶＴＣ−ＳＡ用のシステム・キューに
は、出力キューと入力キューの２つがある。キューをも
っと増やすことも可能である。ハードウェアから見たと
きの、これらのキューの実際のアドレスは、ソフトウェ
ア制御の下で動的に変更することが可能である。しか
し、各方向別にもう１つのキューがある。キュー・ポイ
ンタを動的に位置付けると、データ収集機能が得られ
る。これらの２つのキューは図１５に示すように、メイ
ン・メモリに置かれている。すべてのアドレスは、全ワ
ード（３２ビット）境界上に、つまり、４の整数倍の位
置に置いておくのが好ましい。好適実施例では、単純化
のためワードの端数が送受されない。

【０２０６】トップ・ポインタとボトム・ポインタは、
各キューがアクティブの間固定されているが、場合によ
っては、キューがディスエーブルである間に変更するこ
とも可能である。リード・ポインタとライト・ポインタ
はそれぞれキューからデータを読み、またはキューにデ
ータを書くプロセス（システムまたはグラフィックス・
アダプタ）によって使用され、更新される。

【０２０７】キューの中のデータはパケットに編成され
る。出力データの場合は、システムは完全なパケットを
一を他の後に続けて組み立てて、それを出力キューに入
れる。各パケットは分類を容易にするためのフラグ・ワ
ードならびに、パケットの長さと宛先（ＶＴＣデバイス
ＩＤ）およびデータ内容がコマンドであるかデータであ
るかを示す標識を収めた記述ワードから始まる。これら
のワードの詳細は「データ形式」の個所に説明されてい
る。ＶＴＣデバイスへ送られるデータとコマンドの組合
せはこのメカニズムを用いて単一出力キューにインタリ
ーブされる。

【０２０８】出力キューに置かれた全データは、フラグ
・ワードおよび正しい値の記述ワードと共に、完全なパ
ケットに入っている。この制約は、初期設定時に出力キ
ューに置かれた最初のデータを含めて、すべてのデータ
に適用される。これにより、ＶＴＣデバイスは、高信頼
で、フォルト・トレラントなデータ解析を行うことがで
きる。この制約は、完全なパケットを一度にキューに置
かなければならないことを意味するものではない。パケ
ットが完成されるまで、パケットを部分的に追加してい
くことが可能である。

【０２０９】入力キューに置かれたすべてのデータも、
出力キューのデータと同じように制約される。入力キュ
ーは完全なパケットを有する。各パケットはフラグ・ワ
ードから始まり、長さ、ＶＴＣソース・デバイス、およ
び応答またはデータを示す記述ワードがそのあとに置か
れている。

【０２１０】任意のＶＴＣデバイスによって入力キュー
に置かれた全てのデータは完全なパケットからなってい
る。この制約は、初期設定時にキューに置かれた最初の
データを含めて、すべてのデータに適用され、データが
複数のＶＴＣデバイスから生じる場合であっても適用さ
れる。この制約があるため、ソフトウェアは入力キュー
を高信頼で、フォルト・トレラントな解析を行うことが
できる。出力キューの場合と同様に、この制約は、完全
パケットを一度にキューに置かなければならないことを
意味するものではない。パケットが完成されるまで、パ
ケットを部分的に追加していくことが可能である。

【０２１１】解析タスクは入力キューに置かれた最初の
ワードとしてのフラグおよび次のフラグを指すオフセッ
トである長さを探し出す。このようにして、高信頼の解
析が保証される。ソースＩＤおよび応答またはデータ標
識は、入力キューに置かれたデータを処理する他のタス
クまたはルーチンへデータを送るために使用することが
できる。メモリの複数の区域が入力キュー用に使用され
ている場合は、ポインタを使用すると、参照によってデ
ータを送ることが可能である。

【０２１２】例えば、４ＫＢページの仮想メモリ・シス
テムでは、各キューは、一定順序のページ・ベース・ア
ドレスからなる別テーブルを設計に含めることによっ
て、１ページより大きくすることが可能である。このテ
ーブルはグラフィックス・アダプタとＣＰＵの両方がア
クセスできること、およびその値が固定していることが
必要である。

【０２１３】入力キューは、まだ解析されていないデー
タが保存されていて、解析タスクがすべてのデータを順
番に解析することを完了しているかぎり、キューを一時
的に使用禁止することによって、いつでも再マッピング
することができる。

【０２１４】出力キューと異なり、入力キューがキュー
・ポインタを用いて動的に移動されたときは、一般に、
メモリの各独立領域に完全なパケットが置かれることが
保障できない。ＶＴＣデバイスとグラフィックス・アダ
プタは、必要時にデータを入力キューに入れ、一般的
に、グラフィックス・アダプタによるメモリ・アクセス
はパケット・エンド・ポイントに位置合わせされない。
入力キュー用に使用されるメモリの各独立領域が完全な
パケットだけを有することの確認は、データがグラフィ
ックス・アダプタから受信されたあと必要に応じてソフ
トウェアでデータをメモリ領域間で移動させれば、行う
ことができる。

【０２１５】キューは、システム・メモリ内の追加デー
タ・バッファを指すポインタ・セットとして実現するこ
とが可能である。柔軟性とシステム・パフォーマンスの
面で利点が得られる。間接的キューが実現されているか
否かは、ＶＴＣインタフェースに影響を与えない。間接
的キューはシステム依存オプションである。

【０２１６】キューは、間接データと直接データの組合
せとして実現することも可能である。例えば、メイン・
キューには、直接か間接かを示すコマンド・ワード（こ
れはフォルト・トレラント解析を行う上でも役立つ）、
ポインタ・ワード（これは間接データのときだけ存在す
る）、直接か間接かに関係なく、実際のデータの長さを
示す長さワード、およびこのパケットに直接モードが使
用されている場合は、直接データからなるパケットが置
かれる。

【０２１７】図１５は、ＶＴＣ−ＳＡバス上のメイン・
プロセッサとアダプタ間でやりとりされるメッセージま
たはデータのブリッジとなるキューイング・システムの
好適実施例を示す図である。メイン・プロセッサ４００
はメイン・メモリ４１０に接続され、メイン・メモリ４
１０は入力キュー４１２と出力キュー４１４を含んでい
る。メイン・プロセッサはシステム・バス４１８を挟ん
でグラフィックス・アダプタ４２０のグラフィックス・
プロセッサ４２５にも接続されている。グラフィックス
・プロセッサはグラフィックス・メモリ４３０に接続さ
れ、グラフィックス・メモリ４３０は、入力キューのト
ップ、ボトム、ヘッドおよびテール、出力キューのトッ
プ、ボトム、ヘッドおよびテールなどを含む複数のブリ
ッジ・レジスタ、および入力バッファと出力バッファを
各バッファのカウントと共に含んでいる。グラフィック
ス・プロセッサはＶＴＣ−ＳＡ ４５０を挟んで第１ア
ダプタ４４０と第２アダプタ４４５にも接続されてい
る。

【０２１８】メイン・メモリ中の出力キューは、メイン
・プロセッサからＶＴＣ−ＳＡ上のアダプタの１つに送
られるメッセージまたはデータを収めている。入力キュ
ーは、ＶＴＣ−ＳＡ上のアダプタの１つからメイン・プ
ロセッサへ送られるメッセージを収めている。グラフィ
ックス・メモリに置かれたブリッジ・レジスタは、メイ
ン・メモリ内の入力キューと出力キューを指すポインタ
を含んでいる。グラフィックス・メモリ内の入力バッフ
ァと出力バッファは、メイン・プロセッサとアダプタ間
でメッセージのパケットを受け渡すために使用される。

【０２１９】図１６は、キューイング・システムを使用
してメッセージまたはデータをメイン・プロセッサから
アダプタの１つへ送信するときのステップを示すフロー
チャートである。最初のステップ５００において、メイ
ン・プロセッサはメッセージをメイン・メモリ内の出力
キューにロードし、そのあとメッセージを直接にグラフ
ィックス・アダプタへ送って出力キューのヘッド・レジ
スタを更新し、メッセージが出力キューに追加されたこ
とを通知する。ステップ５０５において、グラフィック
ス・アダプタは、グラフィックス・メモリ内の出力バッ
ファがいっぱいであるかどうかを、出力バッファ・カウ
ントを調べることによって定期的に判断する。いっぱい
であれば、グラフィックス・アダプタのプロセッサは再
び定期的にバッファをポーリングし、データを出力バッ
ファに入れることができるかどうかを判断する。出力バ
ッファがいっぱいでなければ、ステップ５１０におい
て、グラフィックス・プロセッサはメイン・メモリ内の
出力キューにまだデータがあるかどうかを、出力キュー
のヘッド・ポインタがテール・ポインタ・アドレスに１
を加えた値に等しいかどうかを確かめることによって判
断する。等しければ、メイン・メモリ内の出力キューに
メッセージが残っていない。出力キューにデータが残っ
ていれば、グラフィックス・アダプタは、システム・バ
スを通して出力キューからデータを読み取って、それを
出力バッファにロードできるので、出力バッファ・カウ
ントが増加する。さらに、グラフィックス・アダプタ
は、出力キューの一部が読み取られたことを示すよう
に、出力キューのテール・レジスタを更新する。

【０２２０】ステップ５２０において、アダプタは、出
力バッファにメッセージまたはデータがあるかどうかに
ついて、グラフィックス・プロセッサに定期的に照会す
る。出力バッファにデータがあれば、ステップ５２５に
おいて、アダプタはグラフィックス・プロセッサを通し
て出力バッファを読み取る。出力バッファに入っている
データがその出力バッファを読み取ったアダプタに対す
るものであれば、アダプタはその部分のデータの処理を
完了している。そうでなければ、アダプタはそのデータ
を該当するアダプタへ送るか、あるいはデータがあるこ
とを該当するアダプタに通知し、要求があったとき、そ
のデータを該当するアダプタへ送る。どちらの場合も、
処理はステップ５２０へ戻り、そこで、アダプタはグラ
フィックス・プロセッサへの照会を続け、出力バッファ
にデータが残っているかどうかを確かめる。

【０２２１】図１７は、アダプタがキューイング・シス
テムを使用してメッセージまたはデータをメイン・プロ
セッサへ送信するときのステップを示すフローチャート
である。最初のステップ５５０において、アダプタはメ
ッセージまたはデータをグラフィックス・メモリ内の入
力バッファにグラフィックス・プロセッサ４２５を通し
てロードする。入力バッファに残っているスペース・カ
ウントは、その分だけ減少する。ステップ５６０におい
て、グラフィックス・アダプタはメッセージを入力バッ
ファからメイン・プロセッサ４００を通してメイン・メ
モリ内の入力キューにロードする。次にグラフィックス
・プロセッサは入力レジスタのヘッド・ポインタと入力
バッファのカウントを更新する。

【０２２２】ステップ５７０において、メイン・プロセ
ッサは、入力キューで待ちになっているメッセージがあ
るかどうかを確かめるために、グラフィックス・アダプ
タを定期的にポーリングする。入力キューで待ちになっ
ているメッセージがなければ、メイン・プロセッサは、
待ちになっているメッセージがあるかどうか確かめるた
めに、グラフィックス・プロセッサの入力ポインタを定
期的にポーリングし続ける。別の実施例では、メイン・
プロセッサが単にメッセージを待つことも、メッセージ
が待ちにあるとことを示す割込みがグラフィックス・プ
ロセッサから送られてくるのを待つこともできる。メッ
セージが待ちにあると、ステップ５８０において、メイ
ン・プロセッサはそのメッセージを入力キューから読み
取って、グラフィックス・プロセッサがグラフィックス
・メモリ内の入力キューの該当テール・レジスタを更新
するように要求する。

【０２２３】別の実施例では、ブリッジ・レジスタに、
バス上の各アダプタごとに１つまたはそれ以上の割合
で、複数の入力バッファと出力バッファを含めることが
可能である。さらに、複数の入力キューと出力キュー
を、この場合も各アダプタごとに１つのまたはそれ以上
の割合でメイン・メモリに置いておくことも可能であ
る。さらに、データが送られるアドレスを示すために、
別のレジスタをグラフィックス・メモリに含めることも
可能である。さらに、ブリッジ・レジスタと他の処理機
能用のプロセッサを、ＶＴＣ−ＳＡ上の別のアダプタ中
に配置することも可能である。さらに、ブリッジ自体を
ＶＴＣ−ＳＡ上の別アダプタとすることも可能である。

【０２２４】好適実施例では、ＶＴＣ−ＳＡバス上のア
ダプタの１つは、バス・ディストリビュータとして指名
されており、このディストリビュータはＶＴＣ−ＳＡ上
のアダプタのいずれかで待ちになっているメッセージが
あるかどうかを確かめるために、グラフィックス・アダ
プタに定期的に照会する。これは好ましくはＶＴＣ−Ｓ
Ａバスの初期化の間にセットアップされる。しかし、メ
イン・プロセッサは、別のアダプタがバス・ディストリ
ビュータになることを定期的に要求することができる。
さらに、マルチディストリビュータ環境を利用すること
も可能である。このような環境では、各アダプタは、出
力バッファに待ちになっているメッセージがあるかどう
かを定期的に照会し、待ちになっているメッセージがあ
ると、そのことを該当するアダプタに通知する。

【０２２５】バス・データ通路の確立 好適実施例では、メイン・プロセッサは、リモートＶＴ
ＣまたはＶＴＣ−ＳＡビデオ・バス上でどのデータ通路
をセットアップするかを制御する。メイン・プロセッサ
とシステム・バスのどちらもリモート・バス上に置かれ
ていないので、ＶＴＣおよびＶＴＣ−ＳＡバスはメイン
・プロセッサから離れている。つまり、メイン・プロセ
ッサは、リモート・バスと通信するためにはバス・ブリ
ッジまたは類似手段を利用しなければならない。メイン
・プロセッサは、ビデオ・バス上のアダプタ間の接続要
求がユーザまたはアプリケーションから出されると、そ
の要求に応答することによって、中央制御システムをユ
ーザ・アプリケーションの制御下に置いている。

【０２２６】図１８は、本発明の好適実施例を使用して
これらのデータ通路がどのようにセットアップされるか
を示すフローチャートである。最初のステップ８００に
おいて、メイン・プロセッサは初期設定時にビデオ・バ
ス上のアダプタのリストを作成する。ステップ５１０に
おいて、メイン・プロセッサはＶＴＣまたはＶＴＣ−Ｓ
Ａバス上の種々のアダプタのアドレスをセットアップす
るが、これは初期設定時に行うことも可能である。ビデ
オ・バス上の種々アダプタはこれらのアドレスを使用し
て、相互に通信を行う。初期設定プロセスの詳細は上述
したとおりである。ステップ８２０において、メイン・
プロセッサはバス上の所望データ通路を使用可能または
使用禁止する要求をユーザまたはアプリケーションから
受け取る。メイン・プロセッサは、メッセージ送信の場
合の上述したプロセスを用いて、ＶＴＣまたはＶＴＣ−
ＳＡバス上のアダプタの１つからこの要求を受け取るこ
とも可能である。ステップ８３０において、メイン・プ
ロセッサは、要求された所望データ通路を使用可能にす
るか、使用禁止にするかを判断する。各種の判断基準が
使用できる。例えば、ＶＴＣまたはＶＴＣ−ＳＡバス
は、要求を処理するだけの十分なバンド幅をもっていな
い場合がある。プロセッサは、使用可能にされた各種デ
ータ・ストリーム間で優先方式を設定することも可能で
ある。メイン・プロセッサがデータ通路を使用可能また
は使用禁止にしないと判断したときは、メイン・プロセ
ッサはそのことをユーザまたはアプリケーションに返答
し、処理はステップ８２０に戻って、メイン・プロセッ
サは使用可能または使用禁止要求に対する別の要求を待
つことになる。

【０２２７】データ通路を使用可能または使用禁止にす
るとプロセッサが判断すると、メイン・プロセッサはメ
ッセージ送信の場合の上述したプロセスを用いてデータ
通路を開始または終了するようにビデオ・バス上のアダ
プタに通知する。メイン・プロセッサは、使用可能にし
たデータ通路に時間制限またはその他の制限のみを設定
することができる。例えば、メイン・プロセッサは、ビ
デオ・アダプタが到来ビデオ信号を１０秒間ビデオ表示
するように要求することができる。さらに、メイン・プ
ロセッサは、アダプタが後の指示を受け取るまで、到来
ビデオ信号を特定のフレーム上に凍結するようにビデオ
・アダプタに要求することができる。ステップ８５０に
おいて、メイン・プロセッサは、データ・ストリームが
到来していることをグラフィックス・アダプタに通知す
ることができる。グラフィックス・アダプタが常にビデ
オ・バス上のスレーブである場合は、このような通知は
必ずしも必要でない。しかし、このような通知がある
と、グラフィックス・アダプタは到来データ・ストリー
ムを予想して、そのデータ・ストリームが現れるのを促
進するなんらかの適切な処置をとることができる。

【０２２８】ビデオ・アダプタは、到来データ・ストリ
ームが終わる時まで、あるいはプロセッサがデータ処理
を一時中止または終了するようにビデオ・アダプタに要
求するまで、データ処理を続け、データ・ストリームを
グラフィックス・アダプタへまたは互いに送り続ける。

【０２２９】データ形式 ここでは、ＶＴＣおよびＶＴＣ−ＳＡアーキテクチャの
データ書式層について説明する。フィールドＦ１ビット
がある書式の形式を指定することを示すのはビット（２
４−２７）であり、これは、（１、２、４、８、１２、
１６、２４、３２）で始まるリストからの、ピクセル当
たりのビット数を示し、ビット（２４−２７）の値は１
から始まる。従って、ＲＧＢａ３２は‘８’すなわち
‘１０００’ｂである。もっと大きなピクセル・サイズ
を割り振ることが可能である。ビット（２８−３１）は
ピクセル書式のタイプを指定する。ＲＧＢはタイプ
‘０’であり、インデックスはタイプ‘１’である。他
のタイプを割り振ることも可能である。以上説明した書
式を図１９〜図２０に示す。

【０２３０】ＲＧＢａｌｐｈａ３２ 以下では、図１９を参照して、このデータ書式について
説明する。フィールド・ビットは、好ましくはフィール
ドＦ１ビット（２４−３１）＝‘１０００ ００００’
となっており、レッド、グリーン、ブルー、およびアル
ファの各々は８ビットになっている。３２ビット・ワー
ドは図示のように１個のＲＧＢａピクセルを収めてい
る。レッド、グリーンおよびブルーはガンマ補正（非線
形）値であり、０〜２５５の範囲の８ビット２進符号な
し整数で表されている。アルファは混色パラメータであ
り、ライト転送が完了すると、宛先ピクセルは次のよう
になる。

【０２３１】 ａｌｐｈａ＊（転送データ値）＋（１−ａｌｐｈａ）＊ （「他の」バッファに置かれた値） 上記において、「他の」バッファとは、スレーブが想定
する別のフレーム・バッファであり、この他のバッファ
中のピクセル・アドレスはライト転送で使用されるもの
と同じである。スレーブはアルファ混色を行う必要はな
い。リード転送では、アルファは未定義であるので、ス
レーブは‘０’と書いておかなければならない。

【０２３２】ＲＧＢ１６ 以下では、図２０を参照して、このデータ書式について
説明する。フィールド・ビットは、好ましくはフィール
ドＦ１ビット（２４−３１）＝‘０１１０ ００００’
となっており、レッド５ビット、グリーン６ビット、ブ
ルー５ビットになっている。３２ビット・ワードは２個
のＲＧＢ１６ピクセルを収めている。１個の３２ビット
・ワードに入っている２個のピクセルは、ディスプレイ
に左から右へ現れる順序になっており、左端ピクセルは
ＶＴＣデータ・ワードのビット０から始まり、右端ピク
セルはビット１６から始まっている。

【０２３３】ＲＧＢ８ 以下では、図２１を参照して、このデータ書式について
説明する。フィールド・ビットは、好ましくはフィール
ドＦ１ビット（２４−３１）＝‘０１００ ００００’
となっており、レッド３ビット、グリーン３ビット、ブ
ルー２ビットになっている。３２ビット・ワードは、図
示のように４個のＲＧＢ８ピクセルを収めている。１個
の３２ビット・ワードに入っている４個のピクセルは、
ディスプレイに左から右へ現れる順序になっており、左
端ピクセルはＶＴＣデータ・ワードのビット０から始ま
り、右端ピクセルはビット２４から始まっている。

【０２３４】Ｉｎｄｅｘ８ 以下では、図２２を参照して、このデータ書式について
説明する。フィールド・ビットは、好ましくはフィール
ドＦ１ビット（２４−３１）＝‘０１００ ０００１’
となっており、パレット・インデックスは８ビットにな
っている。パレット内容はＶＴＣでは指定されない。こ
の内容は他の手段で指定するか、その内容に一致させて
おく必要がある。３２ビットワードは４個のＩｎｄｅｘ
８ピクセルを含む。上記のピクセル（０、１、２、４）
の順序はディスプレイに左から右へ表示される順序にな
っている。ＲＧＢ８は実際には、Ｉｎｄｅｘ８の特定の
値としてグラフィックス・アダプタに取り入れることが
できるが、ＲＧＢ８はビットの特定のコード化を定義
し、パレットが使用されていれば、パレットの特定の設
定値を定義するものである。他方、Ｉｎｄｅｘ８はどの
特定パレット設定値も意味していない。従って、Ｉｎｄ
ｅｘ８を使用しただけでは、スクリーンに表示されると
きデータ値は正しく解釈されない。

【０２３５】データ書式、つまり、構文と意味は、ＶＴ
Ｃ−ＳＡオペレーションの次の３つの面でオペレーショ
ンを統一化するために必要になるものである。第一は、
フラグと記述ワード、長さその他の制約条件を含むパケ
ットにおいてである。第二は、ＶＴＣデバイスに対する
コマンドとその応答においてである。第三は、複数のＶ
ＴＣデバイス間のメッセージにおいてである。ＶＴＣデ
バイスへ送られる圧縮データはここでは指定する必要は
ない。これらの形式はコード化またはデコードされる標
準に依存し、場合によって、ＣＯＤＥＣシステムがどの
ように構築され、構成されるかによって左右される。

【０２３６】ＰＡＣＫＥＴＳ 好適実施例では、パケットは２つのヘッダ・ワード、つ
まり、フラグ・ワードおよび記述ワードを有し、そのあ
とに複数のデータ・ワードが続く。パケットに含まれる
ワードの数は、記述ワードに示されている。ワードは、
本明細書では、３２ビットになっている。パケットはデ
ータか、１つまたは２つ以上のコマンドまたは応答のど
ちらかを収めている。データは、コマンドおよび応答と
同じパケットに混在することはない。

【０２３７】パケットの構文は、フラグ、記述子、およ
びデータ内容（記述子の長さフィールドで指定されたワ
ード数）からなっている。パケットのフラグ、記述子、
およびデータ部分は次のように定義されている。フラグ
・ワードの値は０ｘ０００００１ＦＦになっている。記
述子ビットは次のとおりである。

【０２３８】ビット０：データ／−コマンド：値が
‘１’のときは、そのあとに続くパケットはデータ、例
えば、圧縮ビデオを含んでいることを意味する。値が
‘０’のときは、パケットがＶＴＣデバイスへ送出され
る場合は、コマンドまたはコマンド列を含んでいること
を意味する。また、値が‘０’のときは、パケットがＶ
ＴＣデバイスから送られてくる場合は、メッセージまた
は前に出されたコマンドに対する応答を含んでいること
を意味する。

【０２３９】ビット１−３および８−１５：予約済：パ
ケットを生成するデバイスおよびタスクは‘０’と書い
ておく。データの受信側はこの値を無視する。

【０２４０】ビット１６−３１：長さ：このフィールド
は、次のフラグ・ワードの前のこのワードのあとに続く
データのワード（各３２ビット）数を指定した符号なし
整数を含んでいる。値がゼロのときは、次のワードがフ
ラグ・ワードであることを示す。

【０２４１】パケット・データは、長さフィールドに指
定された数のデータ・ワードから構成されている。ＶＴ
Ｃインタフェースから見たとき、各ワードの最初のバイ
トは左端にあり、ビット０から始まる。つまり、キュー
先頭がキュー終端よりも下位アドレスにあり、データの
バイトが１ずつ増えていく上位バイトに追加される場合
は、各ワード内の下位アドレスはＶＴＣワードの左部分
にマッピングされる。１６ビットＶＴＣ構成では、左の
ハーフ・ワードは右のハーフ・ワードより先に送信され
る。

【０２４２】送信されるパケットのサイズは、コード化
およびデコード・プロセスにおけるバッファ管理ならび
にキューに置かれた複数のプロセスの待ち時間といった
理由により、大部分のアプリケーションにおいて制限を
される必要がある。あるプロセスにおいてパケットが長
いことは、他の全てプロセスにおいてパケットがない時
間が長くなり、バッファ要求量と待ち時間が増加するこ
とを意味する。他方、パケットが短いときは、オーバヘ
ッドが増加する。オーバヘッドはシステム・キューを解
析し、構築するソフトウェアにおいて最も発生しやす
い。２つのワード・パケット・ヘッダが原因で起こるＶ
ＴＣオーバヘッドは、大部分のパケットが非常に小さい
サイズに近づかなければ、無視し得るものである。最大
バンド幅ストリームについての最適なパケット・サイズ
は、ソフトウェア・アーキテクチャ全体およびネットワ
ークならびにそのパケット・サイズを含む使用されるＤ
ＡＳＤプロトコルに左右されるものである。

【０２４３】絶対的パケット・サイズの制約に関係な
く、つまり、アプリケーション依存の制約を発生する公
式に関係なく、このアーキテクチャで必要なのはＴＢＤ
である。ＶＴＣ−ＳＡの一部として指定されるかどうか
に関係なく、待ち時間の理由からパケット・サイズに十
分な注意が必要である。

【０２４４】結論 特定の実施例を参照して本発明について詳しく説明して
きたが、他の実施例も可能であることは当業者に明らか
である。将来の要件によっては、バンド幅を大きくしま
たデバイス数を増やし、場合によっては、多かれ少なけ
れ、デバイス間の通信が必要になることがある。同時
に、与えられたデータ・ライン数において、バンド幅を
大きくするためにクロック速度を高速化する別のテクノ
ロジが開発される場合もある。ブリッジを備えた複数の
ＶＴＣが実現すれば、ＶＴＣ数に相当する係数倍の実効
スループットが得られるであろう。例えば、光を利用し
たボックス間バスへのブリッジが作られるかもしれな
い。これまでに述べたロジック定義は、発明者の知る範
囲において、このような拡張に適している。ＶＴＣまた
はＶＴＣ−ＳＡに対する要求と並行して、テクノロジが
進歩すると、現在普及している電気的ロジック水準の使
用は時代後れとなるであろう。将来、低電圧電気信号レ
ベルまたは光信号が可能になることは明らかであり、現
在の信号レベル、従って初期のインプリメンテーション
とプラグ・コンパチブルでなくなることは明らかであ
る。従って、上述の説明は、特許請求の範囲に明確化さ
れている本発明の範囲を限定するものではない。

【０２４５】

【発明の効果】本発明によれば、過負荷状態において必
要に応じて動作して、ＶＴＣまたはＶＴＣ−ＳＡのバン
ド幅の利用効率を向上させると共に、ソースの数および
タイプと表示品質との間のバランスをユーザが判断でき
るようにする段階的品質低下が可能となる。

【図面の簡単な説明】

【図１】本発明の好適実施例で使用される代表的なディ
ジタル・コンピュータを示すハイレベル・ブロック図で
ある。

【図２】本発明の第１好適実施例によるビデオ転送チャ
ネル（ＶＴＣ）およびこれと並列のメイン・プロセッサ
・バスを示すハイレベル・ブロック図である。

【図３】本発明の第２好適実施例によるビデオ転送チャ
ネル−独立型（ＶＴＣ−ＳＡ）およびこれと並列のメイ
ン・プロセッサ・バスを示すハイレベル・ブロック図で
ある。

【図４】本発明の好適実施例によるライト（書込み）転
送を示すタイミング図である。

【図５】本発明の好適実施例によるリード（読取り）転
送を示すタイミング図である。

【図６】本発明の好適実施例で使用される各種制御フィ
ールドを示す図である。

【図７】本発明の好適実施例で使用される各種制御フィ
ールドを示す図である。

【図８】本発明の好適実施例で使用される各種制御フィ
ールドを示す図である。

【図９】本発明の好適実施例で使用される各種制御フィ
ールドを示す図である。

【図１０】本発明の好適実施例で使用される各種制御フ
ィールドを示す図である。

【図１１】本発明の好適実施例で使用される各種制御フ
ィールドを示す図である。

【図１２】本発明の好適実施例で使用される各種制御フ
ィールドを示す図である。

【図１３】本発明の好適実施例で使用される好適グラフ
ィックス・アダプタとビデオ・アダプタを示すブロック
図である。

【図１４】表示されるデータを徐々に品質低下（ｄｅｇ
ｒａｄｅ）させるための好適方法を示すフローチャート
である。

【図１５】本発明の好適実施例による表示システムを示
すブロック図である。

【図１６】本発明の好適実施例によるキュー（ｑｕｅｕ
ｅｉｎｇ−待ち行列）システムの使用を示すフローチャ
ートである。

【図１７】本発明の好適実施例によるキュー（ｑｕｅｕ
ｅｉｎｇ−待ち行列）システムの使用を示すフローチャ
ートである。

【図１８】本発明の好適実施例によるデータ通路を使用
禁止または使用可能にするステップを示すフローチャー
トである。

【図１９】本発明の好適実施例によるデータ形式を示す
図である。

【図２０】本発明の好適実施例によるデータ形式を示す
図である。

【図２１】本発明の好適実施例によるデータ形式を示す
図である。

【図２２】本発明の好適実施例によるデータ形式を示す
図である。

【符号の説明】

１００ ディジタル・コンピュータ １１０ メイン・プロセッサ １２０ メモリ １３０ 入力デバイス １４０ 出力デバイス １５０ グラフィックス出力デバイス １６０ バス ２００ グラフィックス・アダプタ ２２０ グラフィックス・アダプタ・プロセッサ ２３０ グラフィックス・アダプタ・メモリ ２４０ フレーム・バッファ ２５０ ＲＭＡＤＡＣ ２６０ マルチメディア・バス ３００ ＶＴＣ ３０５ メイン・プロセッサ・バス ３１０ グラフィックス・アダプタ ３１５ メイン・プロセッサ ３２０ アダプタ ３３０ アダプタ ３５０ ＶＴＣ−ＳＡ ３５５ メイン・プロセッサ・バス ３６０ グラフィックス・アダプタ ３６５ メイン・プロセッサ ３７０ アダプタ ３８０ アダプタ ４００ メイン・プロセッサ ４１０ メイン・メモリ ４１２ 入力キュー ４１４ 出力キュー ４１８ システム・バス ４２０ グラフィックス・アダプタ ４２５ グラフィックス・プロセッサ ４３０ グラフィックス・メモリ ４４０ 第１アダプタ ４４５ 第２アダプタ ４５０ ＶＴＣ−ＳＡ ６００ ビデオ・アダプタ ６０５ ビデオ入力バス ６１０ バス ６１５ ビデオ・プロセッサ ６２０ バッファ ６２５ ヘッド・ポインタ ６３０ テール・ポインタ ６５０ グラフィックス・アダプタ ６５５ グラフィックス・プロセッサ ６６０ バッファ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０９Ｇ 5/12 9471−5Ｇ

Claims (13)

【特許請求の範囲】
1. 【請求項１】 表示すべきビデオ・データのフレームを
   伝送する方法であって、 ａ）ビデオ・データのフレームの少なくとも一部を受信
   するステップと、 ｂ）受信したビデオ・データをバッファにストアできる
   かどうかを判断するステップと、 ｃ）受信したビデオ・データをバッファにストアできる
   と判断した場合は、受信したビデオ・データをバッファ
   にストアするステップと、 ｄ）受信したビデオ・データをバッファにストアできな
   いと判断した場合は、ビデオ・データのフレームのどの
   ビデオ・データも消去するステップと を具えたことを特徴とするビデオ・データ・フレーム伝
   送方法。
2. 【請求項２】 請求項１に記載のビデオ・データ・フレ
   ーム伝送方法において、前記ストアするステップは、受
   信したビデオ・データを待ち行列バッファにストアする
   ステップと、待ち行列バッファを指しているポインタを
   更新するステップとを含むことを特徴とするビデオ・デ
   ータ・フレーム伝送方法。
3. 【請求項３】 請求項２に記載のビデオ・データ・フレ
   ーム伝送方法において、前記消去するステップは、待ち
   行列バッファ内のロケーションを指しているポインタ
   を、消去するデータ・フレームの前に移動するステップ
   を含むことを特徴とするビデオ・データ・フレーム伝送
   方法。
4. 【請求項４】 請求項３に記載のビデオ・データ・フレ
   ーム伝送方法において、ストアされたビデオ・データを
   表示するステップをさらに具えたことを特徴とするビデ
   オ・データ・フレーム伝送方法。
5. 【請求項５】 請求項４に記載のビデオ・データ・フレ
   ーム伝送方法において、ストアされたビデオ・データ
   を、該ビデオ・データの表示の前にディスプレイ・アダ
   プタへ伝送するステップをさらに具えたことを特徴とす
   るビデオ・データ・フレーム伝送方法。
6. 【請求項６】 請求項５に記載のビデオ・データ・フレ
   ーム伝送方法において、受信したビデオ・データをディ
   ジタル化するステップをさらに具えたことを特徴とする
   ビデオ・データ・フレーム伝送方法。
7. 【請求項７】 表示すべきビデオ・データのフレームを
   伝送する装置であって、 ａ）ビデオ・データのフレームの少なくとも一部を受信
   する手段と、 ｂ）受信したビデオ・データをバッファにストアできる
   かどうかを判断する手段と、 ｃ）受信したビデオ・データをバッファにストアできる
   と判断した場合は、受信したビデオ・データをバッファ
   にストアする手段と、 ｄ）受信したビデオ・データをバッファにストアできな
   いと判断した場合は、ビデオ・データのフレームのどの
   ビデオ・データも消去する手段と を具えたことを特徴とするビデオ・データ・フレーム伝
   送装置。
8. 【請求項８】 請求項７に記載のビデオ・データ・フレ
   ーム伝送装置において、前記ストアする手段は、受信し
   たビデオ・データを待ち行列バッファにストアする手段
   と、待ち行列バッファを指しているポインタを更新する
   手段とを含むことを特徴とするビデオ・データ・フレー
   ム伝送装置。
9. 【請求項９】 請求項８に記載のビデオ・データ・フレ
   ーム伝送装置において、前記消去する手段は、待ち行列
   バッファ内のロケーションを指しているポインタを、消
   去するデータ・フレームの前に移動する手段を含むこと
   を特徴とするビデオ・データ・フレーム伝送装置。
10. 【請求項１０】 請求項９に記載のビデオ・データ・フ
    レーム伝送装置において、ストアされたビデオ・データ
    を表示する手段をさらに具えたことを特徴とするビデオ
    ・データ・フレーム伝送装置。
11. 【請求項１１】 請求項１０に記載のビデオ・データ・
    フレーム伝送装置において、ストアされたビデオ・デー
    タを、該ビデオ・データの表示の前にディスプレイ・ア
    ダプタへ転送する手段をさらに具えたことを特徴とする
    ビデオ・データ・フレーム伝送装置。
12. 【請求項１２】 請求項１１に記載のビデオ・データ・
    フレーム伝送装置において、受信したビデオ・データを
    ディジタル化する手段をさらに具えたことを特徴とする
    ビデオ・データ・フレーム伝送装置。
13. 【請求項１３】 表示すべきビデオ・データのフレーム
    を伝送するデータ処理システムであって、 ａ）データを処理するプロセッサと、 ｂ）処理すべきデータをストアするメモリと、 ｃ）前記プロセッサに接続されたビデオ・アダプタであ
    って、 ｉ）ビデオ・データのフレームの少なくとも一部を受信
    する手段と、 ｉｉ）受信したビデオ・データをバッファにストアでき
    るかどうかを判断する手段と、 ｉｉｉ）受信したビデオ・データをバッファにストアで
    きると判断した場合は、受信したビデオ・データをバッ
    ファにストアする手段と、 ｉｖ）受信したビデオ・データをバッファにストアでき
    ないと判断された場合は、ビデオ・データのフレームの
    どのビデオ・データも消去する手段とを有するビデオ・
    アダプタと、 ｄ）ストアされたビデオ・データを、前記プロセッサの
    指示を受けて前記ビデオ・アダプタから表示するディス
    プレイとを具えたことを特徴とするデータ処理システ
    ム。