JPH06202970A - データ経路を可能にする方法、装置およびデータ処理システム - Google Patents

Abstract

(57)【要約】 【目的】 システム・バスに大きな負担をかけることな
く多くの情報を取り扱うことができるようにする。 【構成】 第１の処理装置および第２の処理装置間の
遠隔バス上のデータ経路を可能にする要求を受け取り、
遠隔バスが要求されたデータ経路を扱うことができるか
どうか判断し、遠隔バスが要求されたデータ経路を扱う
ことができるならば遠隔バス上のデータ経路を可能にす
る。それに加えて、第１の処理装置と第２の処理装置間
の遠隔バス上のデータ経路を可能にする要求を受け取る
ための装置、遠隔バスが要求されたデータ経路を扱うこ
とができるかどうか判断するための装置、遠隔バスが要
求されたデータ経路を扱うことができるならば遠隔バス
上のデータ経路を可能にするための装置、を含むデータ
経路を可能にするための装置を提供する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データ経路を可能にす
ることに、とくに遠隔バス上のデータ経路を可能にする
技術に関連する。

【０００２】

【従来の技術】コンピュータシステムは現在、グラフィ
ックス、ビデオおよび他のデータ形式の様々な種類を同
時に表示している。しかし、多くのコンピュータシステ
ムは、ディスプレイ上のデータのすべての型を同時に更
新し表示するために十分な帯域幅資源を持たない。ある
コンピュータシステムは、これらの形式、型およびデー
タ量のすべてを扱うためにシステムバスの帯域幅を増や
すことによってこの問題を解決する。結果として、利用
者がマルチメディア適用業務においてのように情報のい
っそう多くの型を要請するにつれ、システムバスは、メ
イン・プロセッサによって直接利用され必要とされる情
報以外の情報でいっぱいになってしまう。

【０００３】マルチバス・システムは、利用される大量
の情報を扱うために知られているが、異なるバス上のバ
スおよび装置間の調整は難しい。代表的には、バス・ブ
リッジは、バス間のメッセージを転送するためにバスの
各側に装置を設置することによりバスを調整するため
に、米国特許４，９３５，８９４に記述されるように使
用される。

【０００４】

【発明が解決しようとする課題】上述のように、多くの
コンピュータシステムは、ディスプレイ上のデータのす
べての型を同時に更新し表示するに十分な帯域幅資源を
持たない。これらのデータ量のすべてを扱うためにシス
テムバスの帯域幅を増やすと、利用者がマルチメディア
適用業務におけるようにいっそう多くの情報を要請する
につれ、システムバスは、メイン・プロセッサによって
直接利用され必要とされる情報以外の情報でいっぱいに
なってしまうという問題がある。本発明は、この問題を
解決しようとするものである。

【０００５】

【課題を解決するための手段】本発明は、第１の処理装
置および第２の処理装置間の遠隔バス上のデータ経路を
可能にする要求を受け取り、遠隔バスが要求されたデー
タ経路を扱うことができるかどうか判断し、遠隔バスが
要求されたデータ経路を扱うことができるならば遠隔バ
ス上のデータ経路を可能にする方法を提供する。それに
加えて、本発明は、第１の処理装置と第２の処理装置間
の遠隔バス上のデータ経路を可能にする要求を受け取る
ための装置、遠隔バスが要求されたデータ経路を扱うこ
とができるかどうか判断するための装置、遠隔バスが要
求されたデータ経路を扱うことができるならば遠隔バス
上のデータ経路を可能にするための装置、を含むデータ
経路を可能にするための装置を提供する。

【０００６】

【実施例】図１は、本発明の好ましい実施例によって使
用された典型的デジタルコンピュータ１００の高水準ブ
ロック図である。コンピュータは、メモリ１２０、入力
装置１３０および出力装置１４０に接続したメイン・プ
ロセッサ１１０を含む。メイン・プロセッサ１１０は、
ひとつのプロセッサまたは複数のプロセッサを含む。入
力装置１３０は、キーボード、マウス、タブレットまた
は他の型の入力装置を含む。出力装置１４０は、テキス
ト・モニタ、プロッタまたは他の型の出力装置を含む。
メイン・プロセッサはまた、グラフィックス・アダプタ
２００を通して、グラフィックス・ディスプレイのよう
なグラフィックス出力装置１５０に接続する。グラフィ
ックス・アダプタ２００は、バス１６０上のメイン・プ
ロセッサ１１０からグラフィックスに関する命令を受け
取る。バス１６０は、また、他のアダプタと通信するた
めに使用される。グラフィックス・アダプタは、バス１
６０を通してメイン・プロセッサから受け取った命令
を、グラフィックス・アダプタ・プロセッサ２２０がグ
ラフィックス・アダプタ・メモリ２３０に結合した状態
で実行する。

【０００７】グラフィックス・アダプタ内のグラフィッ
クス・プロセッサは、それらの命令を実行しこれらの命
令に基づいてフレーム・バッファ２４０を更新する。プ
リミティブ（基本立体、primitives）の特定の型を生成
するために、グラフィック・プロセッサ２２０はまた、
特殊化された生成ハードウェアを含む。フレーム・バッ
ファ２４０は、グラフィックス出力装置上に表示される
ためにあらゆるピクセルのデータを含む。RAMDAC（ラン
ダム・アクセス・メモリー・デジタル・アナログ変換
器）２５０は、グラフィックス・ディスプレイ１５０に
提供されるように、フレーム・バッファに保存されたデ
ィジタル・データをRGB信号に変換する。それによりメ
イン・プロセッサから要求されたグラフィックス出力が
生成される。グラフィックス・アダプタはまた、直接メ
イン・プロセッサ・バス１６０に接続していないマルチ
メディア・バス２６０を通して他のアダプタと通信す
る。本発明は、マルチメディア・バス２６０の使用を指
向している。

【０００８】マルチメディア・バス２６０の２つの好ま
しい実施例がある。それぞれは、要求されたシステムの
特性に基づいて選ばれる。これらの実施例は、ビデオ転
送チャネル（VTC）、ビデオ転送チャネル・スタンドア
ロン（VTC-SA）として以下に記述される。各々のチャネ
ルのまた、以下に記述される共通の特長および差異を持
つ。

【０００９】図２は、メイン・プロセッサ・バス３０５
と並列するVTC３００の高水準ブロック図である。メイ
ン・プロセッサ・バスは、メイン・プロセッサ３１５、
グラフィックス・アダプタ３１０、他のアダプタ３２
０、３３０および他の可能なアダプタに接続する。VTC
は同様に、グラフィックス・アダプタ３１０、他のアダ
プタ３２０、３３０および他の可能なアダプタに接続す
る。アダプタ３２０および３３０には、ビデオ圧縮器、
外部アナログ・ソースのビデオ・ディジタイザ、ビデオ
拡張器、あるいは、（MIDI音楽アダプタのような）マル
チメディア・アダプタなどの多くのものがある。本実施
例において、メイン・プロセッサ・バスは、VTCに接続
していない他のアダプタに接続することもできる。しか
し本実施例において、VTCはメイン・プロセッサ・バス
上のアダプタにのみ接続することができる。

【００１０】図３は、メイン・プロセッサ・バス３５５
をもつVTC-SA ３５０の高水準ブロック図である。メイ
ン・プロセッサ・バスは、メイン・プロセッサ３６５お
よびグラフィックス・アダプタ３６０に接続する。メイ
ン・プロセッサ・バスは、他のアダプタ３７０および３
８０に接続していない。VTC-SAは、グラフィックス・ア
ダプタ３６０、マルチメディア・アダプタ３７０、３８
０およびおそらくは他のマルチメディアアダプタに接続
する。アダプタ３７０および３８０は、ビデオ圧縮器、
外部アナログ・ソースのビデオ・ディジタイザ、ビデオ
拡張器あるいは、（MIDI音楽インターフェースのよう
な）マルチメディア・アダプタなどであってよい。

【００１１】本実施例において、メイン・プロセッサ・
バスは、VTCに接続していない他のアダプタに接続する
ことができる。それに加えて、本実施例において、VTC-
SAはメイン・プロセッサ・バス上にないマルチメディア
・アダプタに接続することができる。これが本実施例の
スタンドアロン特性である。VTCおよびVTC-SAは、以下
により詳細に記述される。

【００１２】ビデオ転送チャネルCVTC ビデオ転送チャネルCVTCは、特にビデオ表示データおよ
びオーディオ・データのような時間の厳密なデータのア
ダプタ間の高速度通信用に意図されたバスである。VTC
は、マイクロ・チャネル、他のコンピュー入出力装置ま
たはメモリーバスへの付属物のように見えるが、完全に
独立したクロックおよび制御によって動いている。これ
に対してVTC-SAは、命令通信、応答および圧縮マルチメ
ディア・データを含む自己制御バスとして動くことがで
きる。

【００１３】VTC-SA以外においては、VTCは一般に自己
制御コンピュータ・バスではない。すなわち、それは一
般に、アダプタが初期化され、メイン・プロセッサ・バ
スまたはマイクロ・チャネル（ＩＢＭ社の商標）のよう
な制御チャネルを通して制御されることを要求する。PC
ファミリー１（ISA）バスまたは他のローカルに定義さ
れたバスのような、他のバスを使用することもできる。
VTCは、データ、およびこのデータをアダプタ間の直直
接路で転送するのに必要な最小限の情報を運ぶ。

【００１４】VTCを使用している互換性には、異なるレ
ベルがある。カードのプラグ互換性のためには、VTC自
身以外にパッケージング、コネクタ、電力、冷却、ソフ
トウェア型モデル、その他の多くの面で互換性を持たな
ければならない。これらは、具体的な実施上の詳細によ
って保証される。同じ電気的、入出力モデルが使用され
るならば、VTC付属チップを異なるVTC付属カード上で使
用することができる。基礎VTC論理的構造が一定なの
で、上記に関して異なるチップも、同じVTC設計マクロ
を使用することができる。VTCは、IBM PS/2（ＩＢＭ社
の商標）の中にある補助ビデオ拡張とは異なる特定の機
能を提供し、それと共存することができる。

【００１５】VTCは、主に圧縮されていないユーザ表示
情報、とくにピクセルを機械内で通信することを指向し
ている。それは、同様に他のデータを運ぶこともでき
る。典型的にはビデオ・アダプタの全入出力要求は、同
じアダプタの非圧縮ビデオ要求の１%である。したがっ
て一般に、VTC上の十分な帯域幅が、入出力データおよ
び制御信号のために存在するはずである。

【００１６】VTCは、様々な表示特長のために使用され
る構造化インターフェースである。構造により、システ
ムおよび機構の全範囲、そして広範囲の効率機能にわた
って、互換性を維持することができる。

【００１７】好ましい実施例の中で、VTCは論理上、多
重送信制御フィールドに指定された絶対的アドレス指定
をもつ３２ビット・バスである。それは、同時並行の実
時間動作を直接支持するマルチ・マスタ、マルチ・スレ
ーブ・バスであることが好ましい。バス上のすべての信
号およびオペレーションは、クロック同期であることが
好ましい。それは、提供された機能のために最小限の信
号線を必要とするように設計されている。１６データビ
ットおよび６４データビットでの実施が、好ましい実施
例の中で同様に支持されている。

【００１８】物理的および電気の層は、製品ファミリで
使用される科学技術ファミリの特性に合った高レベル・
データ速度のために設計される。結果として、バス信号
線あたりのスループットは、多くの従来のバス設計にお
けるものより高い。

【００１９】VTCは、典型的にディスプレイ・アダプ
タ、いくつかの処理および入出力機構などのいくつかの
装置に接続する双方向性データ・チャネルであることが
好ましい。VTCが提供しようとする主なデータ・タイプ
は、拡張デジタル・ビデオまたはグラフィックスであ
る。VTCはディスプレイ・アダプタのディスプレイ・メ
モリにアクセスを提供し、そうすることによってVTC上
のデータ転送のタイミングは、モニタ・スキャン速度の
ようなすべての操作ディスプレイ・パラメータから独立
している。VTCはまた、関連装置間のビデオの通信経路
を提供する。

【００２０】好ましい実施例において、VTCまたはVTC-S
Aに付随したハードウェアは、マスタまたはスレーブ装
置であることができる。マスタ装置は、他の装置への、
あるいはそれからのデータ転送を始める装置である。典
型的マスター装置は、ライブ・デジタル・ビデオのソー
スである。スレーブ装置は、マスタ装置によって書かれ
る、あるいは読まれる装置である。典型的スレーブ装置
は、ディスプレイ・アダプタである。

【００２１】ひとつの物理的装置が、マスタおよびスレ
ーブとして機能することもできる。ディスプレイ・アダ
プタ・スレーブは、VTCを通してそのディスプレイ・メ
モリにアクセスを提供する。スレーブが、RGBとオーバ
ーレイ平面またはグラフィックスと原イメージのような
複数の層を持つならば、好ましい実施例において、これ
らのすべては、最大機能性を提供するためVTCを通して
アクセス可能である。マスタは、スレーブをアドレスづ
けし、制御フィールドの他の適切な情報とともに、読み
書きする標本の量および起動アドレスを指定することに
よって、すべての転送を始める。これらは、制御フィー
ルドに参照して以下に詳述される。好ましい実施例にお
いて、VTCスレーブは、相互に作用している個々のマス
タのためのコンテクスト・メモリを必要としない。マス
タは、制御フィールドの中で転送に必要なコンテクスト
情報を供給する。マスタ、スレーブ間の通信のために必
要な付加コンテクスト情報は、マスタに保持される。複
数のマスタは、同時にVTCに付随することができる。複
数のマスタは、複数のより遅いチャネルの同時処理操作
と同様な機能が可能な時、割り込んでアクセスする。複
数のスレーブも同様にVTCに付随することができる。そ
れらは、VTC転送オペレーションの間にアドレスされ
る。

【００２２】VTCの共用は、行動パラメータの使用を通
して修正されるラウンドロビンの非先取りのハードウェ
ア仲裁を通して達成されるのが好ましい。結果として生
ずる仲裁動作は、階層的複数のラウンドロビン・リング
のそれに似ている。ラウンドロビンの行動のパラメータ
および順序は、ソフトウェアに組み込まれているのが好
ましいスケジューリング・アルゴリズムによって決定さ
れる。ソフトウェアによって決定されたパラメータは、
所与の構成の装置および要求（例えばウィンドウ）にと
って静的であり、したがって、同時並行のマルチ・マス
タ活動を伴う動的再構成の間を除いて、ソフトウェア上
の実時間要求は存在しない。

【００２３】マスタがVTCを許可されたならば、マスタ
は明白にそれを放棄するまで、つまりリングの次のマス
タに制御（仲裁トークン）を渡すまで、制御を保持す
る。ラウンドロビン作用を修正する行動パラメータは、
各マスタが許可されたVTCを保持することができる最大
時間、および以前の許可から同じマスタが再び許可され
るまでの最小遅延時間である。仲裁システムのいっそう
完全な説明が、以下になされる。マスタの中で行動パラ
メータを実行するためのレジスタが、以下に同様に記述
される。

【００２４】転送の間、たとえばマスタがスレーブにデ
ータを送りしているとき、ひとつのマスタからのデータ
が同時に複数のスレーブに「放送される」ことが可能で
ある。これは、VTC上の信号を送信することなくVTC上に
転送されたデータを受け取る（直接アドレスされた以外
の）付加的スレーブによって実行される。この動作は、
VTCのオペレーションには影響せず、ここでは「スヌー
ピング」と呼ばれる。スヌーピング装置は、必要に応じ
てピクセル開始アドレスを翻訳することに対して責任が
あり、マスタおよびスレーブVTC転送のじゃまをしては
ならない。すなわちそれは、いずれのラインも、特にペ
ーシング・ラインを駆動しない。

【００２５】VTCは、基本入出力バスとしてのマイクロ
・チャネル（ＩＢＭ社の商標）とともに使用される一
方、入出力バスなしの使用から入出力バスの広い種類の
使用にまで範囲を広げることができる。そうすることに
よって、アーキテクチャのシステム・インタフェース層
は、レジスタ・マッピング、割り込み使用その他の理由
のために変化する。たとえば、エントリ・レベルPS/2
は、ファミリ I (AT）バスを持つシステムでVTCを実行
することを選ぶであろう。マイクロ・チャネルまたは関
連したホスト入出力バスに直接アクセスを持たないゲス
トカード（基本カード上の）は、直列バス（例えばCのI
乗）の可能性を含むローカル入出力バスとともにVTCを
実行するために設計される。このようなケースにおい
て、アーキテクチャの物理的、電気的層で実行されるバ
ージョンは、ここで示す最初のバージョンと異なるかも
しれない。

【００２６】スタンドアロンービデオ転送チャネル（VTC-SA） VTC-SAは、コンピュータの他のバスには接続しない付随
するビデオ装置に直接通信を提供する。VTC-SA命令によ
って、命令に対する応答、圧縮ビデオ・データ、および
通常の非圧縮ビデオ・ピクセルは、バスを通して運ばれ
る。この付加的な補助データの全帯域幅は、ビデオ・ピ
クセル・ローディングと比較したとき、本質的に小さ
い。この構成は、グラフィックス・アダプタおよびビデ
オ機能に対するピン計数を減少させる。というのは単に
ビデオ・ピクセル接続を提供するために必要な少数のピ
ン数でその他の必要な通信がなされるからである。この
付加的な補助データは、ここにVTCを定義した同じ制御
機構を使用してVTC-SAを介して送られる。グラフィック
ス・アダプタは、他の機構に対してホストとして機能
し、VTC-SAスレーブとして作用しながら、システムバス
およびVTC-SA間の単純で効果的な通信用インタフェース
を提供する。ある種の機能、行動および命令は、CPUか
らの一貫した開始動作を可能にするために、ホスト以外
のすべてのVTC-SA装置について定義される。

【００２７】好ましい実施例において、いつでも多くと
も一つの能動マスタおよび一つのスレーブが存在する。
しかし、いくつかのマスタおよびスレーブは、時間領域
マルチプレクスされていてよい。マスタは、仲裁トーク
ンの受け取りおよび受諾を通して能動マスタとなり、仲
裁トークンを送り出すことによって、活動中のマスタで
あることを止める。スレーブは、能動マスタによってア
ドレスされることによって能動スレーブになる。それ
は、異なるスレーブが能動マスタによってアドレスされ
るとき、または仲裁トークンが能動マスタから送り出さ
れるとき、能動スレーブであるのを止める。能動マスタ
は、一つ以上のスレーブとの間でデータ転送を始め、実
行する。すべての転送は、以下に定義するバスラインを
使用して始められ、管理され、実行される。

【００２８】VTC-SAは、マイクロ・チャネルのような汎
用入出力バスに直接接続するのが難しいビデオ機能を構
築する問題の解決策として、関心をひくものである。こ
の状況は、実装、電気的ローディング、費用、あるいは
接続すべきバスがないことを含む様々な理由のために起
こり得る。この関心はさらに、ビデオ機能の費用を最小
にしながら、グラフィックス・アダプタにピン、費用の
前もった決定を加えないという要求を含む。性能もま
た、VTC自身のためだけではなく、ビデオ機能や他のタ
スク間のデータフローを管理し、通信規約を処理しなけ
ればならないCPUソフトウェアおよび入出力バスに対す
るシステムのためにも、考慮しなければならない主要項
目である。

【００２９】VTCはむしろ、マイクロ・チャネルのよう
な既存の入出力チャネルの付属物である。VTCは、グラ
フィックス・アダプタを含むVTC付随装置間の非圧縮ま
たは生のビデオ・ピクセルを運ぶ。このような構成は、
ビデオ機能およびディスプレイ・アダプタがとにかくマ
イクロ・チャネルに接続すると仮定される場合、適切で
ある。この場合VTCは、そのようなアダプタに構成され
一貫したインターフェースを提供し、アダプタ間のパス
に、生ビデオのために最適化されたパスを提供する。し
かし多くのシステムでは、実装および他の構築上の制約
によって、上記のような構成を構築する際に使用された
仮定が変更される。

【００３０】VTC-SAによって、ビデオ機能はグラフィッ
クス・サブシステムの一部分のように見られ、そしてマ
イクロ・チャネルにも他のシステムまたは入出力バスに
も接続しない。実際、グラフィックス・アダプタはマイ
クロ・チャネルよりむしろシステムバスに接続する。そ
の場合、ビデオ機能がマイクロ・チャネルに接続してい
るとしても、比較的長いフレックス・ケーブルがビデオ
機能およびグラフィックス・アダプタ間に必要とされ、
それは非合理的な効率問題を起こす。グラフィックス・
アダプタ・システムの一部としてのビデオ機能のこの見
方は、ビデオ機能がグラフィックス・アダプタ上のゲス
ト・カードである場合の実装に、反映される。補助デー
タフローを支持するために付加的なバスを構成すること
も可能であるが、この目的のために既存のピン、インタ
フェース・ロジックおよび有効な帯域幅を使用すること
に我々の関心がある。したがって、ビデオ機能がグラフ
ィックス・アダプタ・システムの範囲内に存在し動作す
ることを許容するアーキテクチャが必要である。

【００３１】多くの理由のために、VTCの使用はすで
に、グラフィックス・ハードウェア・システム環境にビ
デオ機能を組み込む問題の好ましい解解決策みなされて
いる。その理由は説明容易であるが、本件の範囲外であ
る。

【００３２】VTC-SAの設計に関するひとつの非常に重要
な要求は、この構成を実行するために必要なグラフィッ
クス・アダプタ機能の設計をできる限り単純にするとい
うことである。あるトレードオフはこの理由で、ビデオ
機能およびソフトウェアにいくぶん最少限度よりわずか
に多い負担を置いて、作られる。その結果得られる設計
は、バッファー付き直接記憶アクセス機能（DMA）とし
て現れ、グラフィックス・アダプタで容易に実行され、
同様にすべてのビデオ機能やソフトウェアで同様に容易
に実行される。ソフトウェアは待ち行列を管理しなけれ
ばならないが、待ち行列は絶えず構成され、ソフトウェ
アはビデオ機能へのPIOまたはソフトウェア制御されたD
MAを実行しなくてもよいので、一般に入出力マップまた
はメモリ・マップビデオ機能と比較されるとき、効率は
増大し構成はより簡単になっている。

【００３３】VTCがビデオ機能およびグラフィックス・
アダプタ間にあると、VTCに対するピンはすでに割り当
てられ、VTCインターフェースは存在し、VTC-SAを実行
するためにビデオ・サブシステムから要求されるものた
めに全VTC帯域幅が使用可能である。

【００３４】支持されなければならないデータフローを
理解することは、ビデオ機能への付加的なバスが使用さ
れるされないに関わらず、適当な接続機構を設計するた
めに必要である。ビデオ機能への、そして、からのデー
タフローは一般に、ホストからビデオ機能への命令、そ
れらの命令への応答、ホスト・システムからビデオ機能
への圧縮データ（ビデオ）、ビデオ機能からホストへの
圧縮データ（ビデオ）、ビデオ機能からグラフィックス
・アダプタへの非圧縮ピクセル、グラフィックス・アダ
プタからビデオ機能への非圧縮ピクセル、ビデオ機能間
の非圧縮ビデオ、から成る。そしてグラフィックス・ア
ダプタとビデオ機能（双方向性）間の信号情報、から成
る。

【００３５】これらのすべてが、すべてのビデオ・アダ
プタで必要なわけではない。たとえば、圧縮されたデー
タは、明らかに圧縮器および解凍器によってのみ必要で
ある。グラフィックス・アダプタおよびビデオ機能間の
信号情報が、ほころびのない更新タイミングおよび複数
バッファ・ディスプレイ管理のために存在する。

【００３６】しかし、これらのデータフローの最初の２
つである命令および応答は、すべての機能にとって必要
である。最少限度、ビデオ機能は、PORまたは機械構成
時に、構成され診断を行うことができなければならず、
利用者およびスクリーンの管理制御は、CPUおよびすべ
ての機能間で実行されなければならない。

【００３７】これらのデータフローの各々の帯域幅要求
を調べることは、役に立つ。VTCの主な問題は、非圧縮
または生のビデオ・ピクセルの転送である。これらの流
れに対する帯域幅は、表示ウィンドウのサイズに強く依
存する。ビデオ・ウィンドウに必要な帯域幅はおもに、
例外はあるが、ウィンドウサイズの機能である。好まし
い実施例において、帯域幅はウィンドウの面積に比例す
る。したがって帯域幅要求は、ウィンドウサイズを管理
することによっていくぶん管理することができる。

【００３８】ひとつのウィンドウからの帯域幅は、毎秒
あたりのフレーム数（fps）を減らすことによっては容
易に減らされない。そうするためには、遅い更新によっ
て動きが悪化するのを受認しながら、機能中の全フレー
ムをバッファする必要がある。システムの能力に負担を
かけすぎる傾向があるマルチ・ウィンドウにとっては、
動的に必要とされるようにいくつかのフレームまたはフ
レームのある部分を落とすことは利益がある。この場
合、機能に付加的なローカル・メモリを要するか、さも
なければイメージ品質が劣化する。

【００３９】生ビデオの複数の同時並行データフロー
が、存在することがある。たとえば、ビデオ電話CODEC
は、遠隔ビデオ・ソースをあるサイズのウィンドウ中に
表示し、ローカル・ビデオ・ソースを異なるサイズの異
なるウィンドウ中に表示する。ある設計の中で、アナロ
グ・ビデオ入力回線はまた、ディジタル化されたローカ
ルビデオ信号をVTCを経由して圧縮器に渡す。たとえば
テープ上の記録に対するNTSCを生成しているビデオ出力
アダプタは、グラフィック・オーバレイを含むウィンド
ウの内容を抜き出していることがある。同時並行操作に
対するそのような帯域幅要求はすべて、付加的なもので
ある。ある付加的帯域幅は、VTC-SAに付随した装置とCP
U間の命令および制御メッセージのために必要である。

【００４０】VTC自身でなければディスプレイ・メモリ
の帯域幅というように特定のハードウェア設計に負担を
かけすぎる可能性が常に存在する。したがって、ソフト
ウェアは資源管理を実行し、正しく動くと確信できる唯
一の活動が起動されることを保証しなければならない。
そのような保証は、表示されたビデオ・ウィンドウのサ
イズを制限するとか、表示される（しかし通常デジタル
またはアナログ出力ではない）ウィンドウの品位を次第
に落とすとかの様々な方法で得ることができる。VTCを
使用している間のウィンドウの漸進的品位低下を説明す
る。

【００４１】VTC-SA構造の好ましい実施例の主な特長
は、VTCへのアウト、VTCからのインの補助データのシス
テムメモリ内での２つの一方向待ち行列を含む。グラフ
ィックス・アダプタは、これらの待ち行列をアクセスす
るために最初のパーティーDMA（バスマスタ）を実行す
る。グラフィックス・アダプタはアウトおよびインのデ
ータストリームのために小さいオンチップ・バッファを
含む。VTC装置はVTCマスタとして（グラフィックス・ア
ダプタは、VTCスレーブである）、アウトおよびインの
バッファにアクセスする。VTCへの、そして、からのす
べての補助データは、定義された割り込み形式を使用し
て２つのシステム待ち行列に割り込む。CPU（または他
の装置）は、ビデオ機能とのすべての通信のためにシス
テム待ち行列に読み書きを行い、グラフィックス・アダ
プタは、システム待ち行列およびオンチップ・バッファ
のためのポインタ・レジスタを含む。

【００４２】VTCおよびVTC-SAバスライン定義 好ましい実施例において、VTCおよびVTC-SAは３２ビッ
ト・データ・チャネル、３個の制御線およびクロックを
含む。それらは論理上３２ビット幅で、１６ビット電気
バージョンが３２ビット情報を１６ビット短ワードの対
に直列化する。好ましいビット番号付けは、ときどき
「ビッグ・エンディアン」と呼ばれる規格規則に従う。
バスのラインは、以下に述べる通り、３２ビット実現で
あることが好ましい: データ（０〜３１）: 双方向性データ クロック（３２）: ひとつの装置により駆動される間
断なく実行しているマスタ・クロック。すべてのマスタ
およびスレーブ論理への入力。 データ／制御（３３）: 活性マスタによって駆動され
る。VTCを通して書かれたデータが制御フィールドかデ
ータであるかを指示する。 マスタ準備（３４）: 書込み転送間に有効データを提
示していること、または読取り転送間にデータを受けと
る準備ができていることを示すために、活性マスタによ
って活性に駆動される。 スレーブ準備 （３５）: 書込み転送間にデータを受け
とる準備ができていること、または読取り転送間に有効
データを提示していることを示すために、活性スレーブ
によって活性に駆動される。

【００４３】データ（０〜３１）ラインは、それがVTC
書込み転送を実行しているとき、制御フィールドに書き
込みをしているとき、仲裁トークンを送っているとき
に、活性マスタによって駆動される。VTC読取り転送が
進行中であるとき、データ・ラインは活性スレーブによ
って駆動される。マスタおよびスレーブのドライバは、
三状態である。クロック（３２）ラインは、間断なく実
行している一定の周波数クロックである。この信号は、
VTCのすべてのオペレーションのために使用される。入
力タイミングのために、すべてのVTCインタフェース・
ロジックが、クロックラインを使用する。ひとつの活性
クロック・ドライバが存在する。データ／制御（３３）
ラインは、マスタがデータまたは制御フィールド、およ
びデータ・ライン上の仲裁トークンを運転しているかど
うか指示する。どのマスタもデータ・ラインを運転して
いないとき、あるいは活性マスタがデータ（例えばピク
セル）値を駆動しているとき、データ／制御ラインは
「データ」（高レベル）状態にある。

【００４４】活性マスタがデータ・ライン上の制御フィ
ールドまたは仲裁トークンを駆動しているとき、データ
／制御ラインは「CTL」（制御）（低レベル）状態にあ
る。好ましい制御フィールドおよび仲裁トークンは、以
下に記述される。ドライバは、三状態である。すべての
マスタがラインを三状態のままにするとき、あいまいさ
を避けるために、データ／制御ライン上に少くともひと
つの受動プルアップが存在する。書込み転送間に、マス
タ準備は、現在のクロック・サイクル間にマスタがデー
タ・ライン上に有効データを駆動していることを示すた
めに、活性に駆動される。このデータは、活性スレーブ
によって受け取られることが期待されている。マスタ準
備ラインが非活性のとき、このことはデータ・ライン上
の値が有効ではなく、スレーブによって無視されなけれ
ばならないことを示す。読取り転送間に、マスタ準備ラ
インの活性状態は、次のクロック・サイクル間に有効な
データが受取られることを示し、マスタ準備ラインの非
活性状態は、いまから２つのクロック・サイクルの間に
存在するデータは受け取られず、参加スレーブは、その
サイクル間に有効データを駆動してはならないことを示
す。有効でないデータ・ライン値は、『気にしない』で
ある。

【００４５】ドライバは三状態であることが好ましい。
マスタ準備上の少くともひとつの受動プルアップが、す
べてのマスタがラインを三状態のままにするとき、あい
まいさを避けるために存在する。スレーブ準備ライン
は、読取り、書込みおよびマスタ、スレーブを逆にして
マスタ準備ラインと同様に定義される。読取り転送の
間、それはスレーブによって有効データがデータ・ライ
ン上に駆動されることを示す。書込み転送の間、活性状
態は、次のクロック・サイクル間に提示されたデータが
受け取られることを示し、スレーブ準備ラインの非活性
状態は、活性マスタがいまから２クロック・サイクル間
データ・ライン上に有効を駆動してはならないことを示
す。ドライバは、三状態であることが好ましいことをこ
こで繰り返す。すべてのスレーブがラインを三状態のま
まにするとき、あいまいさを避けるためにスレーブ準備
上に少くともひとつの受動プルアップが存在する。

【００４６】VTCの１６ビット電気バージョンは、１６
のデータ・ラインしかないことを除いては、上記と同じ
バスライン定義を持つことが好ましい。１６ビット・バ
ージョンの中で、全３２ビット・バージョンのデータ・
ラインに現れる３２ビット値は、１６ビット値の対に直
列化される。好ましい実施例において、１６ビットを使
用するVTC上のオペレーションは、３２ビット・オペレ
ーションの直列化バージョンである。１６ビット装置
へ、あるいはこれから送り出されたデータは、１６ビッ
ト短ワードの対として送り出された整数個の３２ビット
・ワードから成る。このような場合、最初の短ワードが
上位の１６ビット（０ー１５）、つまり０、１バイトを
含み、２番目の短ワードが、下位ビット（１６ー３
１）、つまり２、３バイトを含む。

【００４７】３２ビットと１６ビット間の相互接続は可
能で、すべての３２ビットまたは１６ビット実現バージ
ョン中で支持される必要はない。１６ビットおよび３２
ビットバージョンが相互接続されている場合、１６ビッ
ト装置の１６個のデータラインは、全３２ビットVTCの
最上位ビット（０ー１５）に接続する。３２ビット装置
は１６ビット装置に送り出すすべての３２ビット・ワー
ドを直列化するが、データが他の３２ビット装置にだけ
導かれるときには、３２ビット装置はすべての３２ビッ
トを駆動することができる。すべての１６ビット・マス
タおよびスレーブは、制御フィールド（データ／制御
「低レベル」によって送り出されたデータ）の１６のMS
Bの値に注意するして、情報または仲裁トークンが自己
のためのものであるのか、制御フィールドが３２ビット
・ワードまたは２つの１６ビット短ワードとして送られ
ているのかを判断する。３２ビット・マスタおよびスレ
ーブは、１６ビットスレーブおよびマスタと通信すると
き１６ビット形式を使用する。他の面と同じように、マ
スタはスレーブが通信する特性を支持し、この特性を示
すスレーブからのコンテクスト情報を受け取らない。１
６ビット転送は、制御フィールドの１ビットによって示
される。

【００４８】VTCの６４ビット電気バージョンは、６４
のデータ・ラインがあることを除いて、３２ビット・バ
ージョンと同じバス・ライン定義を持つ。６４ビットお
よび１６ビット装置間の相互接続の支持はオプションで
ある。それが支持されるならば、１６ビット・スレーブ
およびマスタの相互接続に関する要求は上記と同じであ
る。VTCの６４ビット・バージョンは、１６ビット装置
との相互接続への同様の配慮をもって、３２ビット・バ
ージョンと同様の方法で制御フィールド情報を伝達す
る。３２ビット制御ワードは、データ（３２ー６３）が
未定義のまま３２ビット・ワードとして送る。６４デー
タビットを支持するマスタおよびスレーブは、各クロッ
ク・サイクルに３２ビット・ワードの対としてデータを
転送する。データ（０ー３１）のワードはデータ（３２
ー６３）のワードに先行する。マスタは、どのスレーブ
が６４ビット転送を支持するか、知っていなければなら
ない。６４ビット転送は、制御フィールドの中の１ビッ
トによって示される。

【００４９】VTCおよびVTC-SA操作 書込み転送、読取り転送、データ転送およびペーシング
のために好ましい手順を以下に記述する。 書込み転送 図４を参照すると、書込み転送は次に述べる通り実行さ
れる。第１のステップで、なんの転送も進行していない
とき、「マスタ準備」および「スレーブ準備」は非活性
（高レベル）である。第２のステップで、データライン
上の仲裁トークンを次のマスタに移すことによって、直
前の活性マスタがバスの制御を次のマスタに渡す。トー
クンは、データ／-Ctlが低いときデータ・ライン上の保
留されたセットの値のひとつ、すなわち特別制御フィー
ルドである。直前のマスタは、データ・ライン上のトー
クン値とともに「マスタ準備」およびデータ／-Ctlを低
レベルに駆動することによって、仲裁トークンを送る。
次のマスタは、仲裁トークン制御フィールドの「次のマ
スタ」サブフィールドがそれ自身の識別番号(ID)と等し
いことを見つけることによって、仲裁トークンを受け取
る。

【００５０】どの装置もこのとき「スレーブ準備」を駆
動しないので、その値はすべてのマスタによって無視さ
れる。（「スレーブ準備」は、直前のスレーブによって
非活性に駆動されていて、この時には典型的には非活性
である。）第３のステップの中で、トークンを受け取っ
ているマスタは、転送を始めるか、あるいは第２のステ
ップと同じ方法でトークンを次のマスタに伝える。第４
のステップで、新しい活性マスタは、VTC制御フィール
ド値の形で設定情報を選ばれたスレーブ装置に転送す
る。この情報は、データ／-Ctlが低レベルで「マスタ準
備」が活性の状態でデータ・ラインに送られる。この設
定情報は、目標とされたスレーブのアドレスを含む。第
５のステップで、スレーブは最初はどのラインを運転し
ていない。それは第１の制御フィールドを通してアドレ
スされたあと、「スレーブ準備」を活性（低レベル）に
駆動し、その入力FIFOがいっぱいでないとの仮定で、さ
らにデータを受ける準備ができていることを示す。マス
タによって送り出された制御情報の最初の２つのワード
にしたがって、スレーブは「スレーブ準備」を使用して
データ・フローをペース配分する。第６のステップの中
で、すべての必要な制御フィールドがスレーブに渡され
たならば、マスタはVTCを通してデータワードをクロッ
クする。マスタは、データ・ライン上に有効データを駆
動している各クロック・サイクルについて「マスタ準
備」を活性に駆動する。

【００５１】準備のできた有効データを持たないとき、
マスタは「マスタ準備」を非活性に駆動して、バスに空
きサイクルを生ずる。第７のステップで、スレーブによ
って受け取られた制御およびデータワードが、そのVTC
入力FIFOバッファに置かれる。FIFOバッファがほとんど
いっぱいになると、スレーブは「スレーブ準備」を非活
性（高レベル）に駆動し、２クロック・サイクル後マス
タがデータ・ワードを書き込めないようにする。第８の
ステップで、スレーブは制御フィールドによって示され
た方法でそのアドレスに転送されたデータを保存する。
第９のステップで、いったん転送が始められると、マス
タおよびスレーブは完了するまで転送処理を続けなけれ
ばならない。第１０のステップで、転送が完了したと
き、マスタはVTCを保つか、あるいは放棄する。マスタ
がVTCを保つならば、必要なデータがその後に続く必要
な制御フィールド（少くともひとつ、そして直前の転送
と異なるもの）を書くことによって、もうひとつの転送
を行う。次のマスタに仲裁トークンを送り出すことによ
って、マスタはVTCを放棄する。転送が完了したとき、
スレーブは「スレーブ準備」を非活性に駆動し、このラ
インを三状態にする。

【００５２】読取り転送 図５を参照すると、読取り転送は、以下に述べる通り実
行される。読取り転送は、これらの例外を除いて書込み
転送に似ている。第１に、マスタからスレーブに書かれ
た制御フィールドが、読取り転送が要求されたことを示
す。第２に、マスタはスレーブに制御フィールドを送り
出したあと、「マスタ準備」を高レベルに駆動し、デー
タ・ラインを三状態にし、スレーブがデータで応答する
のを待つ。マスタは、スレーブ準備が非活性になるのを
少くとも１サイクル待ってからデータ上の値を有効な帰
されたデータとして翻訳する。

【００５３】スレーブは、データを送り出す前に、少く
とも１サイクル「スレーブ準備」を非活性に駆動する。
第３に、スレーブが転送応答としてマスタへ送信するデ
ータを持つとき、スレーブは、データ・ライン上のデー
タを駆動し、有効データがデータ・ライン上にあること
を示すためにスレーブ準備ラインを活性にする。第４
に、マスタが「スレーブ準備」が非活性であることを発
見すると、マスタはデータを受け取る能力に従って「マ
スタ準備」を駆動する。スレーブは、制御フィールドを
受け取り後、最初に「スレーブ準備」を非活性に駆動し
た後の最初の２つのクロック期間中にペース配分するた
めに、「マスタ準備」の値を無視する。第５に、スレー
ブは、それがデータ・ライン上へ有効データを運転して
いるときはいつでも、「スレーブ準備」を活性にする。
送り出す有効データを持たないとき、スレーブは「スレ
ーブ準備」を非活性にする。第６に、スレーブは、制御
フィールドFOの長さサブフィールドに示されるのと同じ
数のデータ項目（例えばピクセル）を送り出す。

【００５４】第７に、読取り転送が完了したあと、マス
タは「マスタ準備」を非活性にし、スレーブは「スレー
ブ準備」を非活性にする。第８に、マスタは、データ、
データ／-Ctlおよび関連する「マスタ準備」を駆動する
前に「スレーブ準備」が非活性なことを発見しなければ
ならない。第９に、マスタは、次のマスタに仲裁トーク
ンを送ることによってVTCを放棄するか、または少なく
ともひとつの制御フィールドを送ることにより別の転送
を開始する。

【００５５】データ転送プロシージャ スレーブを通るデータは、そのローカルメモリまたはレ
ジスタから来るかまたはこれに入れられ、スレーブがそ
のすべてのローカル・アドレスを生成する。好ましい実
施例において、ピクセルのアドレス指定は行セグメント
の形で存在し、それはひとつのピクセルに退化すること
ができる。個々のデータワードまたはピクセルのアドレ
ス指定は、開始アドレスおよび各転送のはじめに制御フ
ィールドに送られた他の情報に基づいて、スレーブによ
って内部的に実行される。

【００５６】データが転送される前に、該当する制御フ
ィールドがスレーブに送り出されなければならない。こ
れらのフィールドは、マスタおよびスレーブ識別番号、
アドレス指定情報、転送（読取りまたは書込み）の方向
および他の情報を含む。あるスレーブの実施において、
転送を実行するために必要な情報のうちいくつかは、転
送された情報すなわちマスタ・デバイス識別番号または
転送ウインドウ識別番号（WID）を使用して間接的に指
示される、ローカルメモリに含まれていてもよいる。こ
のことは、VTCおよび他のすべての装置に当てはまる。

【００５７】制御フィールドの転送は、データ書込み操
作に似ており、制御フィールドがバス上に送られるクロ
ック・サイクル間に、データ／-Ctlがマスタによって低
レベルにされることを除いては、同じバスタイミングを
使用する。マスタが実行する同じまたは異なるスレーブ
への連続転送のサイズは、好ましい実施例において、マ
スタがVTCに許可される時間の最大長（クロック・サイ
クルの数）を制限する仲裁動作パラメータによってのみ
制限される。各転送のサイズは、０から制御フィールド
FOに指定される最大値にわたり、同じ仲裁動作パラメー
タによって制限される。

【００５８】ペーシング すべてのスレーブは、データおよび制御情報が受け取ら
れる入力FIFO機能を含む。FIFOのサイズは、VTC構造に
よって指定されるのではなく、スレーブの設計により決
まる。すべてのスレーブは、制御フィールドの転送を含
むすべての操作の間に指定されたペーシング機構を支持
しなければならない。各スレーブによって要求されたFI
FO全サイズは、内部待ち時間およびVTC転送要求を行う
速度のような因子に依存する。

【００５９】データ転送は、VTC主クロックの１サイク
ルにつき１ワードの割合で通常起こる。活性マスタまた
は活性スレーブは、バスに１つ以上のアイドル・サイク
ルを強制することによって、有効データ率を減らすこと
ができる。この効果は、それぞれ活性マスタおよびスレ
ーブによって駆動される、「マスタ準備」および「スレ
ーブ準備」ラインの使用によって制御される。どの装置
が２つのラインのうちどちらを駆動するかという選択
は、読取りおよび書込み転送のどちらに関しても同じで
ある。しかしデータフローの方向によってラインの意味
論は変化する。

【００６０】書込み転送間、そしてマスタによる制御フ
ィールドの書込み間に、活性マスタは、データ・ライン
に有効データを駆動していることを示すために、「マス
タ準備」を活性（低レベル）にする。マスタは、送り出
す有効データを持たない時のように、有効データを駆動
していない時はいつでも、「マスタ準備」を非活性にす
る。VTCを放棄するとき仲裁トークンを送ったあと、マ
スタは、１サイクル間「マスタ準備」を非活性にし、こ
のラインを三状態にする。スレーブが制御情報（フィー
ルドFO）の転送を通してマスタによってアドレス指定さ
れると、スレーブは、マスタが各連続したクロック・サ
イクル間にデータを送り続けるまたは続けないことを示
すために、「スレーブ準備」を駆動する。書込み転送中
のバスサイクル中の「スレーブ準備」の活性（低レベ
ル）の値は、２番目の後続サイクルで送られるデータが
受け取られることを示す。バスサイクル中の「スレーブ
準備」の非活性の値は、２番目の後続バスサイクルが有
効データを含まず、そのサイクル中データ・ライン上の
値が無視されることを示す。

【００６１】VTC読取り転送は、（制御フィールドでは
なく）データフローの方向が逆になることを除いては、
書込み転送に似ている。そして「マスタ準備」および
「スレーブ準備」の任務は、読取りデータ転送間は同様
に逆になる。スレーブは、データ・ライン上の有効デー
タを駆動していることを示すために「スレーブ準備」を
活性にし、有効データがないことを示すために非活性に
する。マスタは、２番目の後続データワードが受け取ら
れることを示すために「マスタ準備」を活性にし、２番
目の後続バスサイクルが非活性「スレーブ準備」ととも
にアイドル状態になければならないことを示すために非
活性にする。

【００６２】好ましい実施例において、３つの例外があ
る。第１に、スレーブが活性マスタによって制御フィー
ルドFOを通して最初にアドレス指定されたとき、パイプ
ライン遅延のために２クロック・サイクル間「スレーブ
準備」は非活性にされる。これは、読取り転送に対する
制御フィールドの書込み転送および書込みに当てはま
る。マスタは、これら２クロック・サイクル間「スレー
ブ準備」が活性であるかのように制御フィールドを送り
続ける。そしてスレーブは、このデータを受け取り、処
理することができなければならない。第３のサイクル・
ペーシングの開始は上記のとおりである。第２に、上記
と同様に、読取り転送のはじめ、制御フィールドがスレ
ーブに受け取られた後、スレーブが要求されたデータを
返す準備ができているとき、スレーブは、「スレーブ準
備」が非活性になる最初のサイクルから２クロック・サ
イクル間「マスタ準備」の値を無視する。マスタは、ス
レーブから送られるデータを受け取り、処理することが
できなければならない。第３に、仲裁トークンは「スレ
ーブ準備」の値に関係なく送られる。これが必要なの
は、この間「スレーブ準備」が常に非活性、三状態であ
り、仲裁トークンが（スレーブではなく）マスタによっ
て受け取られるからである。

【００６３】読取りまたは書込み転送が完了したとき、
活性スレーブが１サイクル「スレーブ準備」を非活性
（高レベル）にし、このラインを三状態にする。書込み
転送および読取り転送の下では、各転送の終わりに上記
のように、活性マスタが、「マスタ準備」を駆動する。

【００６４】VTCおよびVTC-SA制御フィールド マスタ装置からスレーブに送り出される制御情報は、VT
C制御フィールドと呼ばれるワードに組織される。これ
らは、VTC上の転送を実行するのに必要なすべての情報
を含み、Ｆ０、Ｆ１、Ｆ２等と名づけられるこれらの制
御フィールドは、図６ないし８に示され、以下に記述さ
れる。

【００６５】好ましい実施例において、仲裁トークン
は、制御フィールドと同じ機構を使用して転送される。
各フィールドの最初の（最上位の）４ビットは、ワード
の残りの２８ビットを含むフィールドＦ０−Ｆ１４の識
別(ID)を指定する。４つのMSBの値は、Ｆｎ制御フィー
ルド名の数値の部分と等しい。仲裁トークンは、制御フ
ィールドの特別のケースで、４つのMSBの中で示される
特有の数、１５または「１１１１」ビットを持つ。

【００６６】好ましい実施例において、VTCの操作を決
定するために指定される一組の３個のフィールド、Ｆ
０、Ｆ１およびＦ２が存在する。マスタがＶＴＣに許可
されると、マスタはピクセルの転送を始めるためにこれ
らの３個のフィールドを転送する。（スレーブが２４ビ
ットより大きい開始アドレスを必要とする場合、Ｆ３を
２４個のMSBを指定するために書き込まなければならな
い。）ＦＯは、常に最初に書かれなければならない。そ
れは、スレーブおよびマスタのアドレスを含んでいて、
正しいスレーブが残っているフィールドおよびデータを
受け取り応答することを確認するために必要である。例
えばピクセルを含まない転送に対するＦ１のように、フ
ィールドが転送に必要でないならば、それは省略され
る。他のフィールドは、どんな順序で書かれてもよい。
マスタがVTCの制御を得るとき、マスタは、それらまた
は他の装置が以前に書かれたフィールドの内容について
何も知ることができない。アドレス指定されたスレーブ
との転送を実行するのに必要なフィールド値は、転送が
実行される前にマスタによって送られなければならな
い。

【００６７】マスタは、該当するVTC制御フィールドを
書いたあと、データ転送を開始する。転送が完了したと
き、マスタは他の転送を始める。そのような連続した転
送を始めるために、マスタは少くともひとつのVTC制御
フィールドを送り出さなければならない。次の転送が異
なるスレーブへのものならば、Ｆ０は他の制御フィール
ドに先行しなければならない。それが同じスレーブへの
ものならば、フィールドはどんな順序でもよい。転送さ
れないフィールドは、その直前の値を保持する。多数の
短い転送を実行する際の最大効率のために、マスタは値
が変化したフィールド（たとえば、開始アドレス）のみ
を送ることを選んでもよい。

【００６８】Ｆ０制御フィールド この制御フィールドは、図６（Ａ）を参照して以下に記
述される。制御フィールド・ビットは、次に述べる通り
である: ビット０ー３:（４ビット）フィールドID = Ｆ０ついて
「００００」ビット。すべてのビットは、すべてのスレ
ーブによって復号される。 ビット４ :３２ビット制御フィールド。「１」の時、こ
の制御フィールドが１つの３２ビット・ワードとしてVT
C上にあることを示す。「０」の時、このフィールドが
２個の連続１６ビットの半ワードとしてあることを示
す。 ビット５:読み取り／書き込み転送。「１」の時、読取
り転送が次に続くことを示す。「０」の時、書込み転送
を示す。

【００６９】ビット６:３２ビット転送。「１」の時、
次の転送がデータ・ライン０〜３１を使用することを示
す。「０」の時、データ・ライン０〜１５が使用され、
データ・ライン１６〜３１は「気にしない（ドントケ
ア）」を示す。１６ビットの実施においては「０」にセ
ットされていなければならない。

【００７０】ビット７:６４ビット転送。「１」の時、
次の転送がデータ・ライン０〜６３を使用することを示
す。「０」の時、「３２ビット転送」の値に基づいて、
データ・ライン０〜３１または０〜１５が使用され、残
りのデータ・ライン（３２〜６３）または（１６〜６
３）は「気にしない」を示す。制御フィールドは、けっ
してデータ・ライン（３２〜６３）を使用しない。この
ビットは、３２ビットおよび１６ビットの実施において
「０」にセットされていなければならない。

【００７１】ビット８ー１１:（４ビット）スレーブ識
別番号(ID)。アドレス指定されたスレーブ装置の４ビッ
ト・アドレスを指定する。 ビット１２ー１５:（４ビット）マスタ識別番号。この
制御フィールドを書き込み、次の転送を実行するマスタ
装置の４ビット・アドレスを指定する。 ビット１６、１７: アドレス指定モード: Ｆ２（そし
てＦ３）で指定された開始アドレスの意味を指定する: ００：ピクセル・モード。開始アドレスは、ビットマッ
プ・ウィンドウからのピクセル・オフセットで、「長
さ」はピクセル計数である。ビット・マップはアダプタ
およびウィンドー操作システム環境によって完全なスク
リーンまたは特定のウィンドウを意味する。ピクセル計
数およびワード計数間の関係は、「フォーマット」によ
って示される。 ０１：絶対データ・モード。開始アドレスは、アダプタ
・メモリのからのバイト・オフセットで、「長さ」はバ
イト数である。データワード（「長さ」合計まで）につ
き４バイトがある。MSB（ビット０〜7）が最初にある。
ウィンドウ識別番号、フレーム・バッファ識別番号、形
式、クリップおよびストライドは、このモードでは無視
される。

【００７２】１０：保留。 １１：レジスタ・モード。開始アドレスは、アダプタの
レジスタ・アドレス空間のベースである。さもなければ
絶対データ・モードと同じである。 ビット１８ー３１：（１４ビット）長さ。ピクセルまた
はバイトで、後続の転送の長さを指定する。上記アドレ
ス指定モードを参照されたい。長さは符号なし２進数整
数で、０から２＊＊１４ー１にわたる。長さが０なら
ば、転送データを記述するパラメータ（Ｆ０の、クリッ
プ、読み込み／書き込み、アドレス・モード、Ｆ１の、
６４ビット転送、３２ビット転送、Ｆ２およびＦ３の、
開始アドレス）は未定義で、それらの値は「気にしな
い」である。

【００７３】Ｆ１制御フィールド この制御フィールドは、図６（Ｂ）を参照して以下に説
明する。制御フィールド・ビットは、次に述べる通りで
ある: ビット０ー３:（４ビット）フィールド識別番号は、Ｆ
１に対して「０００１」ビットである。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドが、ひとつの３２ビット・ワードと
してVTC上にあることを示す。「０」の時、このフィー
ルドが２個の連続１６ビット半ワードとしてあることを
示す。

【００７４】ビット５: クリップ。「１」の時、転送
データがメモリに書かれなるべきでないいピクセルを含
み、スレーブは内部的にクリッピングを実行しなければ
ならないことを示す。「０」の時、マスタは、必要なク
リッピングがマスタによって実行され、スレーブは内部
クリッピングを実行する必要がないことを示す。このビ
ットは、ピクセル・アドレス指定モードの書込み転送の
ためにだけ定義される。 ビット６: 保留領域。マスタは、「０」を書き込まな
ければならず、スレーブは無視しなければならない。

【００７５】ビット７:ストライド。「１」の時、スレ
ーブは転送ピクセルを、開始アドレスから始まり２ずつ
増加するアドレスへ保存する。「０」の時、アドレスは
転送ピクセルにつき１ピクセル増加する。ピクセル・モ
ードで書込み転送のためにだけ定義され、それ以外はマ
スタは「０」を書き込む。 ビット８ー１５:（８ビット）フレーム・バッファ識別
番号:フレーム・バッファ識別番号は、このピクセル・
アドレスにおいてどのバッファがアドレス指定されてい
るか指定する。１つ以上のバッファをもつディスプレイ
アダプタに有益である。値は、スレーブに特有である。

【００７６】ビット１６ー２３:（８ビット）WID：ウイ
ンドウ識別番号：ウィンドウIDは、スレーブに使用され
たウィンドウ識別番号を指定する。どのウィンドウがア
ドレス指定されているか示す。値はスレーブに特有で、
ウィンドウ管理ソフトウェアによって使用された同じWI
D値である必然はない。このまたは他のウィンドウの中
でピクセルを保護するために、スレーブによって直接ま
たは間接的に使用される。

【００７７】ビット２４ー３１:（８ビット）フォーマ
ット:１ピクセル内のビット数および１ワード内のピク
セル数を含むピクセルについてのデータ形式。データ形
式は、ピクセル転送すなわちＦ１が「０Ｘ００」のアド
レス・モードにのみ関する。他のアドレスモードには、
ピクセル・データ形式は適用できない。データ形式は、
以下により詳細に記述される。

【００７８】Ｆ２制御フィールド この制御フィールドは、図６Ｃへの参照によって以下に
記述される。制御フィールド・ビットは、次に述べる通
りである: ビット０ー３:（４ビット）フィールド識別番号はＦ２
に対して「００１０」ビットである。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドが、ひとつの３２ビット・ワードと
してVTC上にあることを示す。「０」の時、このフィー
ルドが、２個の連続１６ビット半ワードとしてあること
を示す。 ビット５ー７: マスタは、「０００」を書き込まなけ
ればならなく、スレーブは無視しなければならない。 ビット８ー３１:（２４ビット）開始アドレス。上記Ｆ
１で指定されたアドレス指定モードに従って、ピクセル
またはバイト単位である。転送に必要な開始アドレスが
２４ビットより長い時、Ｆ２は最下位の２４ビットを含
む。

【００７９】Ｆ３制御フィールド 好ましい実施例において、Ｆ３はオプションである。ア
ドレス指定スレーブが開始アドレスを指定するのに２４
ビットより多くを要求する時のみ使用される。この制御
フィールドは、図７（Ａ）への参照によって以下に記述
される。制御フィールド・ビットは、次に述べる通りで
ある: ビット０ー３: （４ビット）識別番号は、Ｆ３に対し
て「００１１」ビットである。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドが、ひとつの３２ビット・ワードと
してVTC上にあることを示す。「０」の時、このフィー
ルドが、２個の連続１６ビット半ワードとしてあること
を示す。 ビット５ー７： 保留領域。マスタは、「０００」を書
き込まなければならず、スレーブは無視しなければなら
ない ビット８ー３１: （２４ビット）開始アドレス。上記Ｆ
１で指定されたアドレス指定モードに従って、ピクセル
またはバイト単位である。合計４８ビットの開始アドレ
スの最上位２４ビットは、Ｆ３の内容と結合する。

【００８０】Ｆ４制御フィールド Ｆ４は、装置間の特有な状況情報を示すのに使用され
る。それは、データ転送を始める時には要求されない。
信号転送は、長さが０のＦ０，およびＦ４から成る。こ
の場合マスタは、典型的データ転送においてアドレス指
定されたスレーブと同じ装置であるかもしれない点に、
注意されたい。この制御フィールドは、図７（Ｂ）を参
照して以下に記述される。制御フィールド・ビットは、
次に述べる通りである: ビット０ー３: （４ビット)フィールド識別番号は、Ｆ
４に対して「０１００」ビットである。すべてのビット
はすべてのスレーブによって復号される。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドが、ひとつの３２ビット・ワードと
してVTC上にあることを示す。「０」の時、このフィー
ルドが、２個の連続１６ビット半ワードとしてあること
を示す。 ビット５: 命令: フレーム・バッファ（FB）識別番号
へのスイッチ。「１」の時、マスタは、WIDによって指
定されたウインドウ識別番号を、FB識別番号によって指
定されたフレーム・バッファ識別番号に切り換えるよう
スレーブに命令する。これらのフィールドは、フィール
ドＦ１に定義されるのと同じ意味を持つ。「切換え」
は、スレーブからディスプレイまたは他の出力のために
使用されたFB識別番号を切換えることを意味し、データ
転送によって実行されるアドレス指定およびアクセスに
影響しない。「０」の時、命令は意味されない。

【００８１】ビット６: 状態: FB IDへの切換え完
了。「１」の時、マスタはスレーブに、上記命令と同じ
意味をもって、フレーム・バッファ切換えが完了された
ことを示す。この場合、マスタが上記命令においてアド
レス指定されたスレーブと同じ装置であるかもしれな
い、またはその逆であるかもしれない点に、注意された
い。「０」の時、状態は示されない。 ビット７: 状態: FB IDへのドローイング（drawing）
完了。「１」の時、マスタは、ドローイングが完了し、
WIDによって指定されたエリアのフレーム・バッファFB
IDに一時的に保存されていることを示す。これは、ス
レーブに、衝突無しにこのエリア（FB ID、WID）を読
み書きできることを示す。この場合マスタは、上記命令
においてアドレス指定されたスレーブであるかもしれな
い、またはその逆であるかもしれない点に注意された
い。「０」の時、状態は意味されない。

【００８２】ビット８ー１５:（８ビット）FB ID。フ
レーム・バッファの識別番号が示される。意味は、フィ
ールドＦ１に関してと同じである。 ビット１６ー２３:（８ビット）WID。ウインドウ識別番
号が示される。意味は、フィールドＦ１に関してと同じ
である。 ビット２４ー３１:（８ビット）保留領域。マスタは
「０」を書き込まなければならず、スレーブは無視しな
ければならない。

【００８３】Ｆ５制御フィールド Ｆ５は、装置間の特有なタイミング情報を示すのに使用
される。それは、データ転送を始める時には要求されな
い。信号転送は、長さが０のＦ０、およびＦ５から成
る。この場合、マスタは、典型的データ転送の中でアド
レス指定されたスレーブと同じ装置であるかもしれない
点に、注意されたい。この制御フィールドは、図８
（Ａ）を参照して以下に記述される。制御フィールド・
ビットは、次に述べる通りである: ビット０ー３:（４ビット）フィールド識別番号はＦ５
に対して「０１０１」ビットである。すべてのビットは
すべ てのスレーブによって復号される。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドがひとつの３２ビット・ワードとし
てVTC上にあることが示される。「０」の時、このフィ
ールドが２個の連続１６ビット・ハーフワードとしてあ
ることが示される。

【００８４】ビット５ー１６:（１２ビット）保留領
域。マスタは、「０」を書き込まなければならなく、ス
レーブは無視しなければならない。 ビット１７: 偶数／奇数。「１」の時、マスタは、
「開始VBI」（ビット１８）が後続のインターレース形
式において偶数フィールドに関することを示す。「０」
の時、マスタは、奇数フィールドが参照されることを示
す。非インターレース・システムは、「１」を書き込ま
なければならない。ビット１８が「０」である時、この
ビットは定義されず、スレーブはこれを無視しなければ
ならない。 ビット１８ : 開始VBI。「１」の時、マスタは、その
表示機能の垂直帰線消去間隔（VBI）が、最近開始した
ことを示す。インターレース・システムのおける後続フ
ィールドの偶数または奇数識別が、ビット１７によって
示される。「０」の時、状態は意味されない。

【００８５】ビット１９: 開始ライン。「１」の時、
マスタは、ラインの表示が最近始まったことを示す。言
及されたラインが、ライン番号、ビット（２０ー３１）
で示される。「０」の時、状態は意味されない。 ビット２０ー３１: （１２ビット）ライン番号。ビッ
ト１９によって最近表示を開始したことが示されるライ
ン番号を示す。番号付は、非インターレース・システム
において最初に表示されたラインに対し「０」から開始
する。

【００８６】Ｆ６−Ｆ１４制御フィールド 好ましい実施例において、これらの制御フィールドは、
将来の使用のためにとっておかれる。マスタは、これら
の制御フィールドを使用してはならない。 仲裁トークン（Ｆ１５） この制御フィールドは、図８（Ａ）を参照して以下に記
述される。制御フィールド・ビットは、次に述べる通り
である: ビット０ー３:（４ビット）フィールド識別番号は、仲
裁トークン（Ｆ１５）に対して「１１１１」ビットであ
る。 ビット４: ３２ビット制御フィールド。「１」の時、
この制御フィールドがひとつの３２ビット・ワードとし
てVTC上にあることが示される。「０」の時、このフィ
ールドが２個の連続１６ビット半ワードとしてあること
が示される。

【００８７】ビット５ー７: 保留領域。マスタは、
「０」を書き込まなければならなく、スレーブは無視し
なければならない。 ビット８ー１５:（８ビット）次のマスタ識別番号。ビ
ット（１２ー１５）は、仲裁トークンが送られるマスタ
識別番号である。ビット（８ー１１）は予備領域で、０
でなければならない。装置は、「００００」であるビッ
ト（８ー１１）を含む全８ビットを復号しなければなら
ない。 ビット１６ー２３：（８ビット）直前マスタの識別番
号。ビット（２０ー２３）は、仲裁トークンを送り出し
ているマスタの識別番号(ID)である。ビット(１６ー１
９）は保留領域で、０でなければならない。装置は、０
０００であるビット（１６ー１９）を含むすべての８ビ
ットを復号しなければならない。 ビット２４ー３１: 保留、マスタが０を送りスレーブは
無視しなければならない。

【００８８】VTCおよびVTC-SA仲裁 VTCの仲裁機能は、行動パラメータによって修正される
ラウンドロビンである。ラウンドロビンは、トークン通
過機構によって実行される。現在活性なVTCマスタ装置
がバスを放棄するときはいつでも、それは仲裁トークン
をこのドキュメントの中でネクスト・レディ（次に準備
のできている）と呼ばれるもうひとつのマスタにうつ
す。トークンの受け取り、あるいは、宛先は、トークン
を渡しているマスタに指定されたマスタ識別番号であ
る。各々のマスタのトークン宛先の値はソフトウェアに
よって、操作可能なすべてのマスタが論理的リングにあ
り、トークンは、リングを通して各サイクルに一度すべ
てのマスタを通過するように準備される。他の実現にお
いて、トークンは、実行されたスケジューリング・アル
ゴリズムに従って異なるマスタに渡される。

【００８９】トークンを受け取っているマスタがVTCを
使用する必要がない、あるいは、その時（仲裁動作パラ
メータを通して）VTCを使用することを禁じられている
ならば、マスタは論理的リングの中の次のマスタにトー
クンを渡す。仲裁トークンの初期設定は、各装置がトー
クン宛先およびスケジューリング動作でテストされプロ
グラムされた後、行われる。そのとき、システム中のト
ークン無しに、どのマスタ装置も仲裁トークンを送るた
めにソフトウェアによって導かれることができる。それ
によって仲裁トークン論理的リング機構を初期状態にす
る。VTC装置中のタイムアウト例外条件検出機能が、初
期設定に先立ち使用禁止にされる。

【００９０】VTC-SAにおいて、ホスト（グラフィック
ス）アダプタは、各装置が初期設定を確認して応答する
ことができるように、VTC装置上の可能な装置へのトー
クン送り出しを開始する。各装置中の初期設定動作は、
装置にVTCを通してCPUから送られたデータを受けること
を要求し、応答は同じ機構を使用して、VTCを通して戻
される。

【００９１】ラウンドロビン作用を修正する行動パラメ
ータは、各マスタが許可されてからVTCを保持すること
ができる最大時間、および直前の許可から同じマスタが
ふたたび許可されるまでの最小限の遅延時間である。こ
れらの時間量は、VTCクロック信号のサイクル数によっ
て指定される。それらは、各マスタ装置中のレジスタの
中で指定される。仲裁動作は、ソフトウェアまたは装置
設計によって確立された行動の規則によって制限され
る。マスタ装置がどれくらいVTCの制御を保持すること
ができるかに関して、VTCには本来的な電気的または物
理的制限は存在しない。

【００９２】好ましい実施例において、活性マスタおよ
びスレーブは、起こっている事象の制限時間内で作用し
なければならない。すべての制限が、クロック信号のサ
イクル装置にある。第１に、仲裁トークンを受け取る
際、マスタは例えば２サイクルで、転送を始める、ある
いはトークンを次のマスタに渡す。第２に、転送の完了
の際、活性マスタは、例えば２サイクルでトークンを転
送する、あるいは他の転送を開始しなければならない。
第３に、フィールドＦ０によってアドレス指定された
際、活性スレーブは、例えば１０サイクル内に、「スレ
ーブ準備」活性で応答しなければならない。

【００９３】いくつかの可能な例外条件は、注意を要す
る。第１に、転送を開始せず、またトークンを受け取り
トークンを渡したりもしないマスタ。第２に、転送を完
了した時、トークンを送るのに失敗したマスタ。第３
に、転送が完了していないのに、トークン送り出すマス
タ。第４に、活性マスタでないのに、トークンを送り出
しているマスタ。第５に、読取りまたは書込み転送中に
Ｆ０を通してアドレス指定されたことに応答しないスレ
ーブ。第６に、スレーブによって受け取られた不正確な
データあるいは制御フィールド値。第７に、Ｆ０の長さ
フィールドと一致しない実際の転送長。第８に、転送さ
れた値と異なる、VTCバス上に受け取られた値。

【００９４】どのマスタまたはスレーブも、例外条件の
検出を実行することができる。転送またはトークン通過
に参加していないことのある装置によって発見すること
のできる条件は以下の項目を含む。第１に、仲裁トーク
ンが送られており、かつ次のマスタがクロック・サイク
ルの好ましい制限時間内で応答しないこと。第２に、
「マスタ準備」がクロック・サイクルの好ましい限界よ
り長い間非活性であるのに、仲裁トークンが送られない
こと。第３に、仲裁トークンが送られた後、制御フィー
ルドが送られる前に、データが送られたこと。第４に、
「前」のマスタが、前の「次」のマスタと異なる場合に
仲裁トークンが送られていること。第５に、Ｆ０を通し
てアドレス指定された後、クロック・サイクルの好まし
い制限時間内にスレーブが「スレーブ準備」を活性にし
ないこと。第６に、（「長さ」項目が転送される前に）
転送中にクロック・サイクルの好ましい限界より長い間
「スレーブ準備」が非活性であること。第７に、１転送
間に、「長さ」データ項目（「スレーブ準備」活性で）
より多く作られたこと。

【００９５】グラフィックス・アダプタ VTC-SA付随装置へのホストとして動くグラフィックス・
アダプタは、VTC-SAの好ましい実施例を実行するため
に、特定の方法で特定の機能を実行しなければならな
い。グラフィックス・アダプタは、指定された機能に加
えて、そのディスプレイ・バッファにVTCを通してのア
クセスを提供しなければならない。ディスプレイ・バッ
ファをアクセスする機能は、ここに記述されない。典型
的にグラフィックス・アダプタは、ディスプレイ・バッ
ファをアクセスするためにVTCスレーブとして動く。

【００９６】ローカル・バッファ メイン・メモリ中のアウト・バッファは、VTCを通してV
TC装置に獲得される前に、システムバスを通してシステ
ム・メモリから得られたデータを保存する。メイン・メ
モリ中のイン・バッファは、システムバスを通してシス
テム・メモリに書かれる前に、VTCを通してVTC装置から
送り出されたデータを保存する。これらのバッファ長
は、少くとも３２バイト（８ワード）である。より小さ
い主イン・バッファも可能であるが、システム効率は小
さいバッファのために悪くなるので、推薦されない。イ
ンおよびアウト・バッファがそれぞれ２つの異なるプロ
セスによってアクセスされるとき、バスインターフェー
スおよびVTCインターフェースは、同時二重ポート読み
書きアクセスを支持する必要がない。

【００９７】これらの２個のバッファのそれぞれは、関
連する計数レジスタをもっている。アウト計数レジスタ
は、アウト・バッファで有効なデータ量を示す。イン計
数レジスタは、イン・バッファでデータのために有効な
スペース量を示す。これらのレジスタはVTCを通して読
むことができる。バッファ・アドレス指定は、数多くの
方法で実行することができる。計数レジスタは、ひとつ
のポートされたバッファにおける現在アドレスを含むよ
うにしてもよく、または、独立した読取りおよび書込み
ポインタ間の差を含むようにしてもよい。

【００９８】システム・バス・インターフェース VTC-SAの適用業務の中で、グラフィックス・アダプタ
は、CPUバス上のバスマスタである。グラフィックス・
アダプタは、VTC-SAを支持する２つのシステム待ち行列
にアクセスする。このように、グラフィックス・アダプ
タは、待ち行列を指すオンボード・ポインタの２つのセ
ットを持つ。典型的にこれらのポインタは、各待ち行列
の上、下、読取り、書き込みポジションのためにあり、
待ち行列につき４つのレジスタを要求する。レジスタ・
サイズは、システム設計に依存する。ポインタは、実メ
モリアドレスを使用する。

【００９９】グラフィックス・アダプタの上のシステム
待ち行列ポインタによって、グラフィックス・アダプタ
は、各待ち行列で有効なデータ量およびスペースを容易
に識別することができる。ソフトウェアもまた、これら
のポインタ・レジスタを調べることにより、各待ち行列
で有効なスペースおよびデータ量を判断することができ
る。

【０１００】グラフィックス・アダプタは、待ち行列バ
スマスタの活動を使用禁止にするプログラム可能な機能
を持たなければならない。これは、不正確なアドレス範
囲にアクセスする可能性があるので、不注意にグラフィ
ックス・アダプタにバスマスタの活動が必要なことを示
さないで、システムがシステム待ち行列ポインタを再方
向付けすることができるようにするために必要とされ
る。

【０１０１】好ましい実施例において、VTC-SAを支持す
る待ち行列中のすべてのデータが３２ビット（１ワー
ド）の整数倍数から成り、全体的な語の境界上、等価的
には４の整数倍数であるバイト・アドレス上にあるなら
ば、実施が単純化される。グラフィックス・アダプタ
は、VTC-SAに対する２つの待ち行列においてこの制約に
したがうデータを信頼することができるので、任意のア
ドレスが許される場合に必要とされるようなバイト回転
その他を実行する必要がない。

【０１０２】グラフィックス・アダプタは、自身がシス
テムバス・マスタであり、VTC-SA待ち行列およびをバッ
ファを維持するためにバス支配権を使用している状態
で、支持するよう設計された他のプロセスに加えて、VT
C-SAの目的のための２つのプロセスを支持する。これら
は、アウト・バッファを満杯にし、関連するアウト待ち
行列を空に保とうとすること、そしてイン・バッファを
空に、関連するイン待ち行列を満杯に保とうとすること
を含む。

【０１０３】手続き的に、グラフィックス・アダプタ
は、次に述べる通り、システム待ち行列およびVTC-SAオ
ンボード・バッファを管理する。アウト・バッファが有
効なスペースを持ち、アウト待ち行列が有効なデータを
持つときはいつでも、グラフィックス・アダプタはシス
テムバスのための仲裁を試みる。仲裁が許可されると、
グラフィックス・アダプタは、待ち行列からバッファ
へ、バッファのより小さいスペースと待ち行列のデータ
をバス許可期間の限界まで転送する。

【０１０４】イン・バッファが有効なデータを持ち、イ
ン待ち行列が有効なスペースを持つときはいつでも、グ
ラフィックス・アダプタはシステムバスのための仲裁を
試みる。仲裁が許可されると、グラフィックス・アダプ
タはバッファから待ち行列へ、バッファのより小さいデ
ータと待ち行列のスペースを、バス許可期間の限界まで
転送する。

【０１０５】バッファが単一ポートである場合、システ
ムバスが許可されるとき要求されたバッファがVTC活動
で忙しいならば、グラフィックス・アダプタは、バスお
よびバス・インタフェース回路の設計によっては、バス
活動を終了するかまたはペース配分しなければならない
ことがある。

【０１０６】アウト待ち行列からのデータ読み取りが完
了すると、アウト待ち行列の読み取りポインタはグラフ
ィックス・アダプタによって更新される。それによりCP
Uは、アウト待ち行列の新しい有効なスペース量を判断
することができる。同時に、グラフィックス・アダプタ
はアウト・バッファに関連した有効なデータ計数を更新
し、VTC装置がこのバッファの有効なデータ量を判断で
きるようにする。

【０１０７】イン待ち行列へのデータ書き込みが完了す
ると、イン待ち行列の書き込みポインタはグラフィック
ス・アダプタによって更新される。それによりCPUは、
イン待ち行列の新しい有効なデータ量を判断することが
できる。同時に、グラフィックス・アダプタはイン・バ
ッファに関連する有効なスペース計数を更新し、VTC装
置がこのバッファの有効なスペース量を判断することが
できるようにする。

【０１０８】システムバス活動が要求されるような、イ
ン・バッファに有効なデータがあるかどうか、アウト・
バッファに有効なスペースがあるかどうかの決定は、計
数レジスタまたは同様の機能を提供している他の回線に
基づく。この決定は、それぞれインまたはアウト・バッ
ファへとの間の活性VTC転送が完了した後、なされなけ
ればならない。この理由は、転送量の評価を早くしすぎ
ているので、こうしないとシステムバス・マスタが標準
バーストより少ないデータ量を転送し、システムバスや
VTCの使用が不十分になり待ち時間が増大するからであ
る。

【０１０９】たとえば、イン・バッファが最初は空で、
VTC装置が３２バイト（８ワード）転送を開始したなら
ば、グラフィックス・アダプタのバスマスタは、すべて
の８ワードがイン・バッファに移るまで転送を始めては
ならない。VTC転送が完了するまでバス仲裁が始まらな
いならば、この結果が保証される。

【０１１０】同時に、システムバスまたはVTCを通して
転送されるデータの量が８ワードより少ない場合があ
る。この場合例えば３２バイトのデータ・ストリームは
保証されない。バッファへの、そしてからの現VTC転送
が完了したとき、システムバス・インターフェースは、
標準バーストより短いシステムバス転送になるけれど
も、次のVTC転送を待たないで、バッファの完了した内
容を処理しなければならない。さもなければ、重要なデ
ータの短いが容認できない待ち時間が起こる可能性があ
る。

【０１１１】グラフィックス・アダプタは、バス支配権
機能の使用のために争っている複数の内部タスクを持つ
ので、仲裁方式が必要である。VTC-SA待ち行列およびバ
ッファ管理プロセスは、グラフィックス・アダプタのバ
ス支配権内でもっとも高い優先度を持つタスクでなけれ
ばならない。これは、通常VTC補助データはバッファあ
ふれおよび下位桁あふれを避けるための期限をもつ実時
間であること、そして頻繁にサービスする必要があると
いうことの結果である。同様に、グラフィックス・アダ
プタは、保証された適時サービスを支持するために、CP
Uバスまたはマイクロ・チャネルで高い優先度を持たな
ければならない。再び、これは頻繁なサービスが必要な
結果である。

【０１１２】同様に、システム待ち行列を管理するソフ
トウェアは、しばしば実行しなければならず、高優先度
または頻繁な保証スケジューリングを持たなければなら
ない。

【０１１３】グラフィックス・アダプタからCPUへの割
り込みの必要性は、一般にはない。これは、システムに
依存する効率問題であって、この全般的アーキテクチャ
の範囲を越えている。たとえば、アウト待ち行列が空で
あるとか、イン待ち行列が最大限であることを示す割り
込みは、待ち行列の適時サービスを保証するために、い
くつかのソフトウェア・アーキテクチャに役立つでかも
しれない。

【０１１４】システム・データ・バッファへのポインタ
を含むことによって、遠まわしのレベルを利用する待ち
行列が実行される。これは、VTCインターフェースに何
の影響も持たない。

【０１１５】VTCインターフェース 好ましい実施例において、グラフィックス・アダプタお
よびVTC装置間で補助データが渡される転送において、
グラフィックス・アダプタがVTCスレーブのように動作
する。

【０１１６】アウト・バッファからデータを検索するた
めに、VTC装置がマスタとして動作する。データを検索
する前に、VTC装置は、どれくらいのデータがアウト・
バッファで得られるか判断するためにVTCを通してアウ
ト計数レジスタを読む。それから（または後で）VTCを
通して、受け取られたアウト計数レジスタ値によって指
定されたデータ量の、グラフィックス・アダプタからの
読み込み転送を実行する。アウト・バッファは、VTC装
置によってFIFOとして扱われる。すなわち、固定された
開始アドレスはそのような転送のために使用される。

【０１１７】内へ向かうデータの送信は、同様である。
すなわち、VTC装置はVTCを支配し、グラフィックス・ア
ダプタからイン計数レジスタを読取る。それは続いて、
受け取られたイン計数値で指定されたデータスペース量
のグラフィックス・アダプタへの書き込み転送を実行す
ることができる。アウト転送でのように、固定アドレス
がイン・バッファ書き込み転送のために使用される。

【０１１８】インおよびアウト・バッファに対する計数
レジスタは、該当する数多くの３２ビットのワード、デ
ータまたはスペースを示す符号なし２進数整数である。
それらは、ひとつのVTCワードの範囲内で各々１６ビッ
トのフィールドを占める。

【０１１９】典型的に、グラフィックス・アダプタは、
計数レジスタ中の重要な情報のために４〜６ビットだけ
を必要とする。もっと重要なことは、定数ビットはゼロ
でなければならないということである。例えば、８ワー
ドバッファには９つの可能な値（０〜８）があり、それ
には４ビットが必要であることに注意されたい。

【０１２０】計数フィールドは３２ビット・ワードの数
を示すが、メモリ中のVTC転送およびレジスタ・アドレ
ス指定モードは長さをバイト数として指定することに注
意されたい。VTCのバイト・カウントは、他の適用業務
に役立つであろう。補助データ転送実行しているVTC装
置は、上記長さフィールドを、VTC Ｆ０制御ワードの長
さフィールドに変換するとき、４のファクタとしての差
の原因となる。

【０１２１】２個のアドレスは、イン、アウト計数レジ
スタおよびイン、アウト・バッファの上記機能を実行す
るためにVTCを通して指定される。上記のように、１が
計数フィールドの転送を読むように、イン計数およびア
ウト計数レジスタがアクセスされる。ひとつの実施例
は、計数レジスタをアドレス・モード「１０」、現在予
約、および開始アドレス「０」にマップすることであ
る。インおよびアウトバッファは、同じアドレスを使用
してアクセスされる。アウトは読取り転送を使用し、イ
ンは書込み転送を使用する。もうひとつの実施例は、イ
ンおよびアウト・バッファをアドレス・モード「１
１」、レジスタ・モード、および開始アドレス「０」に
マップすることである。上述の実施例が両方共使用され
るならば、そのような転送の間、VTCの開始アドレス・
フィールド（Ｆ２）を無視することが可能である。これ
はVTC上のオーバーヘッドを最小化する。

【０１２２】グラフィックス・アダプタは、VTC-SAホス
ト・アダプタを実行するために、非常に基礎的なVTCマ
スタ能力を必要とする。それらは、指定されたVTC識別
番号へ仲裁トークンを送信し、受け取られた場合、同じ
VTC識別番号へ仲裁トークンを続けて送信すること、あ
るいは受け取られた場合、VTC仲裁トークンの送信を中
止し、システムにトークンが受け取られたことを示すこ
とである。これらの能力によって、システムはどのVTC
識別番号が装置を設置したか判断し、すべてのVTC装置
を初期状態にすることができる。定常状態操作の中で、
初期設定の後、グラフィックス・アダプタは、トークン
が受け取られる度に、他のVTCマスタ活動を実行しない
で、続けて所定の識別番号にトークンを再送信する。VT
Cマスタ能力は、VTC-SA要求外の他の理由のために必要
とされるならば、グラフィックス・アダプタに含められ
てもよい。

【０１２３】VTCはマスタおよびスレーブによるすべて
の転送のペース配分を本来的に許すが、バス効率および
システム効率を維持するために、補助データ転送に特定
の効率要求が含まれる。

【０１２４】計数レジスタの読取りは、実現できる限り
速く完了されなければならない。VTCクロック・サイク
ルは、計数データ値が活性的にVTCに置かれるまで、VTC
ライン「スレーブ準備」を非準備状態に保持しているグ
ラフィックス・アダプタで経過してもよい。アウト・バ
ッファからの読取り転送は、活性の返されたデータをVT
Cに置き始めるまで、非準備VTCクロック・サイクルを持
つことができる。続いて、要求された読取り転送データ
は、２クロック・サイクルにつき１ワードまたはより速
い速度で転送されなければならない。１６ビットVTCに
とって、これはクロック・サイクル毎に半ワードを意味
する。３２ビットVTCにとって、これは、多くとも１つ
の非準備サイクルと交互になるよりも複数サイクル上の
１ワードを意味する。

【０１２５】イン・バッファへの書き込み転送のタイミ
ング要求は、同様であり、VTCマスタ装置は、VTC制御フ
ィールドを書いた後に、データを書き始める。グラフィ
ックス・アダプタ（VTCスレーブ）は、数多くの非準備
サイクルを生ずる。これらは転送の間、転送ワード数足
す例えば３、に限られていなければならない。グラフィ
ックス・アダプタのVTC FIFOまたはFIFOが、ディスプレ
イ・バッファをアクセスする最近の前のVTC転送で既に
占められている場合、上記に対する例外がなければなら
ないかもしれない。グラフィックス・アダプタは、指定
された値以上の、計数レジスタの連続した読取り間に間
隔が存在すると仮定することができる。

【０１２６】ビデオ機構機能 VTC付随ビデオ機能は、アウト待ち行列およびバッフ
ァ、イン待ち行列およびバッファから成り、出発および
到着データ経路を経たホスト・システムのすべてのデー
タ通信を実行する。次に、VTC装置へ、あるいはからの
補助データに当てはまるデータ形式にふれながら説明す
る。

【０１２７】VTC-SAアーキテクチャは、ひとつ以上のVT
C装置をもつ機械構成でよく機能する。説明を単純化す
るために、ただひとつの装置をもつ状況が最初に記述さ
れる。あとの部分で、複数のデバイスでの使用のための
装置要求および動作を説明する。

【０１２８】VTC装置は、アウト・バッファのデータ量
およびイン・バッファのスペース量を判断するために、
グラフィックス・アダプタをポールする。アウト・バッ
ファに有効なデータがあり、VTC装置にそのデータを受
け取るスペースがあるならば、VTC読取り転送を実行し
このデータを読み込む。装置は、内部バッファに小さい
スペースしかなければ、得られるデータ量より少ない量
を読む。よいシステム設計は、VTC装置がデータのため
に常にスペースを持つようにしなければならない。しか
しこれは、このアーキテクチャの範囲を越える様々な因
子に依存するので保証されない。

【０１２９】VTC装置は、データタイプに従って、受信
データを適当に処理する。これは、どのデータが命令を
構成しているか、どれが圧縮されたデータ（たとえば、
ビデオ）であるかを判断し、次に、それに従い命令また
は圧縮されたデータを処理することを含む。

【０１３０】VTC装置がシステムへ送信するデータを持
つならば、イン・バッファで得られるスペース量を判断
するために、グラフィックス・アダプタをポールする。
それは続いて、送り出されるのを待っているデータのよ
り小さい量およびイン・バッファに得られるスペース量
を、VTCを通し書き込み転送を使用して、イン・バッフ
ァへ転送する。

【０１３１】多くのケースにおいては同時に１つ以上の
VTC付随機能を支持することは必要でない。したがっ
て、複数のVTC装置のために下にリストされた機能は、
そのようなシステムのために意図されたアダプタでは実
行する必要がないかもしれない。

【０１３２】付随するVTC機能が複数あるならば、初期
化の間に１つの装置が分配装置として指定され、他の装
置は代替装置とみなされる。分配装置はすべての出発デ
ータを扱い、それは該当する代替装置に渡される。代替
装置は、分配装置の制御の下に、到着データを直接イン
・バッファ（したがって待ち行列）に移す。分配装置
は、加えて、出発データを代替装置に経路付け、必要な
場合代替装置からの到着データ転送を制御して、ただ１
つのVTC装置のように動く。

【０１３３】すべてのVTC装置は、最初に初期化された
とき、ただ１つのVTC装置であるように動く。好ましい
実施例において、VTC 装置に、CPUから命令を受け取る
まで異なった動きをするよう命令することはできないの
で、このことは必要である。

【０１３４】読取り転送で分配装置によって受け取られ
た出発データが、異なる（代替）装置へのパケットのヘ
ッダであるとき、通信規約は次に述べる通りである。第
１に、分配装置は、検索されるべきパケットの存在およ
び長さを示して、メッセージを目標代替装置に渡す。
（全パケットが最初に分配装置によって保持される必要
はない。）第２に、代替装置は分配装置からデータを読
む。全パケットが読まれるまで、必要ならば読取りが繰
り返される。第３に、代替装置は、パケット受け取りの
完了を示すメッセージを分配装置に送る。

【０１３５】パケットを分配装置から代替装置へ転送す
る際に、分配装置はVTC装置に補助データを転送するた
めに、グラフィックス・アダプタと同じように動く。し
かし分配装置は、データストリームにコード化された宛
先および長さフィールドを調べることによって、代替装
置に送ろうと意図されたデータのみが代替装置に送信さ
れるようにし、同様に代替装置は、意図されたデータの
み読取ることを保証される。典型的に、分配器は他のVT
C装置に補助データを再送信するのに使用するために別
々のデータバッファーを含む。

【０１３６】代替装置へ再方向付けしたパケットは、分
配装置における待ち時間を伴う。すなわちパージングお
よび再方向付けは、十分なバッファ機能があり、全体の
待ち時間がシステムレベルの問題を起こさない限り、オ
ンボード・プロセッサの援助を含む可能性がある。プロ
セッサに援助された再方向付けは、単純な設計におい
て、通常およそ１０usより多い付加待ち時間を負っては
ならない。１００usから１msのオーダの付加的待ち時間
は、通常問題を起こさない。

【０１３７】分配装置以外の、複数の設置VTC装置およ
び（代替）装置がシステムへ送信するデータを持つと
き、通信規約は次に述べる通りである。第１に、代替装
置は、イン・バッファの使用を要求して分配装置にメッ
セージを送り出す。第２に、分配装置が現在パケットの
送信を完了すると、分配装置は代替装置に、イン・バッ
ファが代替装置によって今所有されることを示すメッセ
ージを送る。第３に、それから代替装置は全く分配装置
のように動き、有効なデータおよびスペース量に従って
イン・バッファへデータを書き込む。第４に、イン・バ
ッファへの代替装置のデータ書き込みが完了すると、代
替装置はイン・バッファの制御を返すメッセージを分配
装置に送る。

【０１３８】代替装置がイン・バッファを使用している
とき、分配装置を含む他のいかなる装置も、イン・バッ
ファにデータを書かない。この規則に対する例外は、代
替装置がイン待ち行列の所有者のための制限時間を破
り、エラー状態が起こった時である。このような場合、
分配装置は代替装置に割り込みメッセージを送り出し、
次にパケットのイン・バッファへの書き込みを開始す
る。そのようなパケットは、エラーが発見されたという
事実を示す。そのようなエラーおよび回復が起こると
き、システムのイン待ち行列は、記述ワードの直前の長
さフィールドが指定するのとは異なるロケーションに次
のパケット・フラグを持つ。パージングソフトウェア
は、新しいフラグ・ワードを見つけ、長さ および次の
フラグ・ワードを通して検査することによって、回復し
なければならない。

【０１３９】分配装置は、現パケットの送信を完了する
まで、要求している代替装置にイン・バッファの所有権
を与えることができない点に注意されたい。これに要す
る時間は、パケットサイズ、頻繁度、イン・バッファを
アクセスする待ち時間、グラフィックス・アダプタによ
るイン待ち行列にイン・バッファを空にする待ち時間お
よびスペースがイン待ち行列にあるかどうか、に依存す
る。２つ以上の代替装置がイン・バッファの使用を要求
するとき、ある順序に従ってアクセスが与えられなけれ
ばならず、いくつかの代替装置は付加的待ち時間を持
つ。これらの理由のために、イン・バッファを得ている
代替装置の待ち時間に関する保証は、イン待ち行列をパ
ージするソフトウェアを含む全システムの効率がカバー
されない限り、この明細書の範囲を越えている。

【０１４０】システムおよび（分配器だけでなく）あら
ゆるVTC装置間で通信されたデータは、パケットにあ
る。パケットサイズは、必ずしもシステム待ち行列また
はインおよびアウト・バッファのサイズに関係がなく、
したがって必ずしもVTCデータ転送のサイズに関係がな
い。代替装置にデータを分配し、代替装置からデータを
集める上の記述において、これらのデータパケットは、
分配装置から検索されるか、あるいは代替装置からグラ
フィックス・アダプタに送られるデータ量を決定する。
複数のVTC装置があるとき、代替装置は、全パケットを
検索するために導かれる。同様に、代替装置がデータを
イン待ち行列に書き込んでいるとき、代替装置がイン待
ち行列を制御する間、全パケットが書き込まれる。しか
し、パケットがひとつのVTC転送で通信されることは、
必要ではなく一般に実際的でない。

【０１４１】バス初期化 好ましい実施例において、VTCおよびVTC-SA装置は、VTC
休止状態において電源が立ち上がる。装置は設計および
スロット配線の関数であるVTC装置識別番号で立ち上が
る。たとえば、最大数４つのVTC装置が設置可能なクラ
スのシステムがありうる。各装置は、２つの識別番号ビ
ットを除いてすべてのビットが固定されるよう、チップ
設計またはカード配線を通して設計され、この２つのビ
ットはVTCコネクタに関連づけられる。最大４つの各コ
ネクタは、それらの２ビットに特有の設定を行う。

【０１４２】VTC装置のホストとなるグラフィックス・
アダプタが、固定VTC識別番号に関連づけられる。グラ
フィックス・アダプタの識別番号は、それらが電源投入
と通信する装置のように、すべてのVTC-SA装置に設計さ
れる。CPUは、トークンが返されたかどうか見るため
に、順番にVTCトークンを各可能なVTC識別番号へ送信す
るようグラフィックス・アダプタに命令し、VTC装置の
存在を発見することができる。装置を初期化するために
CPUは、初期化命令をアウト待ち行列に入れ、GAのアウ
ト待ち行列をセットし、アウト待ち行列を許可し、グラ
フィックス・アダプタに引き続き特定のVTC装置にトー
クンに送るよう命令する。すべてのVTC装置は、トーク
ンを送り出す際に使用する、固定で初期の次のマスタ識
別番号で立ち上がる。その識別番号は、すべてのグラフ
ィックス・アダプタによって使用される識別番号と同一
である。指定VTC装置は、アウト・バッファにデータが
存在するかどうかのためにグラフィックス・アダプタを
ポールし、続いてアウト・バッファを通してCPUからデ
ータ・パケットを読む。それが有効な応答を持つとき、
イン・バッファを通して応答を返す。他の装置を初期化
するためにCPUは、第１の装置にトークンを送り出すの
をやめるようグラフィックス・アダプタに命令し、上記
操作が各々の付加装置について繰り返される。

【０１４３】すべての装置が初期化され、２つ以上の装
置があるならば、１つの装置が分配装置として指定さ
れ、他の装置は代替装置として指定される。各装置は、
仲裁トークンを指定された装置へ送信するために、次の
マスタ値を通してセットされる。それによってラウンド
ロビンのすべての装置が構成される。複数デバイスがあ
るならば、ここで記述される場合を除いて代替装置は、
アウト待ち行列にアクセスしない、あるいはイン待ち行
列にデータ送信をしないよう命令される。分配装置以外
の装置のために、アウト待ち行列が分配装置に存在し、
イン待ち行列は、分配装置によって許可されるときのみ
使用される。

【０１４４】漸進的品質低下 本発明は、VTCまたはVTC-SAの帯域幅の効果的利用を提
供しながら、過負荷状況において必要に応じて操作し、
利用者がソースの数および型とディスプレイ品質との均
衡を決定できるようにする、漸進的品質低下に向けられ
ている。

【０１４５】図９は、ビデオを表示するためのグラフィ
ックス・アダプタと組合わさって本発明の好ましい実施
例を利用しているビデオ・アダプタを図示する。ビデオ
・アダプタ６００は、NTSCアナログ信号またはその他の
ビデオ入力バス６０５の上のビデオ入力信号を受け取
る。ビデオ・プロセッサ６１５は、アナログ・ビデオ入
力信号を受け取りディジタル化し、ディジタル化の結果
を、VTC、VTC-SAまたは他の型のバスであるバス６１０
上のデータを送るに先立ち、バッファ６２０に保存す
る。好ましい実施例において、バッファは、ビデオ・デ
ータがバッファのどこに保存されているかを示すための
ヘッド・ポインタ６２５およびテール・ポインタ６３０
をもつ循環性バッファである。着信アナログ・データが
ディジタル化されると、データはバッファ６２０に保存
され、ヘッド・ポインタを更新する。好ましい実施例に
おいて、バッファは循環性メモリであり、ビデオ・デー
タのおよそ１フレームを持つ。グラフィックス・アダプ
タ６５０は、ビデオ・バス上のビデオ・アダプタ６００
および他のソースからデータを受け取るグラフィックス
・プロセッサ６５５を含み、ディスプレイ６６５上に表
示するためにフレーム・バッファ６６０にそのビデオ・
データをロードする。

【０１４６】図１０は、表示されているデータの品質を
漸進的に低下させる方法を図示するフロー・チャートで
ある。第１のステップ７００で、アダプタ・プロセッサ
６１５は、ビデオ入力バス６０５上のアナログ・ビデオ
入力データを受け取り、ディスプレイのためにそのデー
タをディジタル化する。ステップ７０５で、ビデオ・ア
ダプタは、ヘッド・ポインタがびテール・ポインタを含
んでいるかどうか見るためにヘッドおよびテール・ポイ
ンタを比較して、バッファ６２０が満杯であるかどうか
判断する。フレーム・バッファが満杯でなければ、ステ
ップ７１０で、アダプタ・プロセッサは、バッファ６２
０にディジタル化データをロードし、次にテール・ポイ
ンタ６３０を更新する。アダプタ・プロセッサが同様に
バス６１０を通してバッファからグラフィックス・アダ
プタにデータを転送する一方、このプロセスはステップ
７００、７０５および７１０間で続く。

【０１４７】バッファ６２０が満杯で、ビデオ・アダプ
タが以前に保存されたディジタル化データをグラフィッ
クス・アダプタに転送することができないことを示して
いるならば、処理はステップ７１５に続く。ステップ７
１５で、アダプタ・プロセッサは、バッファに保存され
ている現フレームを消去する。アダプタ・プロセッサ
は、テール・ポインタを、バッファに保存された直前の
フレームまたは部分の終わりまで動かすだけで、これを
達成する。ステップ７２０で、アダプタ・プロセッサは
ディジタル化されたばかりのデータを廃棄する。ステッ
プ７２５で、アダプタ・プロセッサはさらにアナログ・
データを受け取り、そのデータをディジタル化する。ス
テップ７３０で、最新のディジタル化データが廃棄され
たものと同じフレームからであるならば、その新しいフ
レーム・データが再び廃棄される７２０に処理は続く。
しかし、新しくディジタル化されたデータが新しいフレ
ームからならば、処理は、アダプタ・プロセッサが再び
バッファが満杯であるかどうか判断するステップ７０５
に戻る。ほとんどの状況下では、バッファは、他のビデ
オ・フレームの入力を始めるための、多量のスペースを
持たなければならない。好ましい漸進的品質低下技術の
利点の１つは、ビデオ・フレームまたは他の型のデータ
・グループが必要に応じて廃棄されるということであ
る。すなわち、フレームが廃棄されるのは、ビデオ・ア
ダプタが着信データを保存したり転送したりできない時
だけである。それに加えて、幾つかのアダプタがより大
きい優先度を持つ種類の優先方式の場合、低い優先度を
持つビデオ・アダプタが一般に多くのフレームを廃棄
し、オーバーロード条件が起こる。

【０１４８】システム待ち行列 好ましい実施例において、VTC-SAのために２個のシステ
ム待ち行列、アウト待ち行列およびイン待ち行列があ
る。さらに多くの待ち行列を実行することもできる。ハ
ードウェアによるこれらの待ち行列の実アドレスは、ソ
フトウェア制御の下で動的に変わることができる。しか
し、依然として各方向に１つの待ち行列が存在する。待
ち行列ポインタの動的位置決めは、データ収集機能を提
供することがある。２つの待ち行列は、図１１のメイン
・メモリの中で図示される。すべてのアドレスは、全ワ
ード境界（３２ビット）、つまり４の整数倍数である。
好ましい実施例において、単純化のために、ワードの小
数部分は転送も受け取りもされない。

【０１４９】各待ち行列が能動であるとき、トップおよ
びボトムポインタは固定であるが待ち行列が使用禁止の
とき、ある条件の下で変わる。読取りおよび書込みポイ
ンタは、待ち行列との間でデータを読み書きしているプ
ロセス（システムまたはグラフィックス・アダプタ）に
よって、使用され更新される。

【０１５０】待ち行列中のデータは、パケットに組織さ
れる。出て行くデータのために、システムは連続する完
全なパケットを作り、それらをアウト待ち行列に置く。
各パケットは、パージングを助けるためのフラグ・ワー
ドおよびパケットの長さと宛先（VTCデバイスＩＤ）を
含む記述ワード、また同様にデータが命令を含むかデー
タを含むか示す指標から始まる。これらのワードの詳細
は、「データ形式」に含まれる。VTC装置へのデータお
よび命令の混合が、この機構を使用して、ひとつのアウ
ト待ち行列にインターリーブされる。

【０１５１】アウト待ち行列中のすべてのデータは、フ
ラグ・ワードおよび正しい値の記述ワードをもつ完全な
パケットにある。この制限は、初期化の間にアウト待ち
行列に置かれる最初のデータを含むすべてのデータに当
てはまる。これは、VTC装置によるデータのK高信頼障害
許容パージングを可能にする。パケットが完全になるま
で、パケットの部分が加えられるであろう。

【０１５２】イン待ち行列のすべてのデータは、アウト
待ち行列のデータと同様に制約される。それは、完全な
パケットから成る。各パケットは、長さ、VTCソースデ
バイスおよび応答またはデータを示す記述ワードが続
く、フラグ・ワードから始まる。

【０１５３】VTC装置によってイン待ち行列に置かれた
すべてのデータは、完全なパケットから成る。この制限
は、データが複数のVTC装置からのものであっても、初
期化の間に待ち行列に置かれた最初のデータを含むすべ
てのデータに当てはまる。この制限は、ソフトウェアに
よるイン待ち行列の高信頼度の耐障害パージングを支持
する。アウト待ち行列と同様に、この制限は、完全なパ
ケットが同時に待ち行列に置かれることを要求しない。
パケットが完全になるまで、パケットの部分が加えられ
る。

【０１５４】パージングタスクは、フラグをイン待ち行
列の最初のワードとみなし、長さを次のフラグを指すオ
フセットとみなす。このようにして、高信頼パージング
が保証される。ソース識別番号および応答データ指標
は、イン待ち行列のデータを処理しなければならないほ
かのタスクまたはルーチンへデータを方向づけるため
に、使用される。メモリの複数のエリアがイン待ち行列
に使用されているとき、データはポインタ使用を参照し
て導かれる。

【０１５５】例えば４kBページをもつ仮想記憶であるシ
ステムにおいて、設計中にページ基本アドレスの別々の
テーブルを含むことによって、各待ち行列は１ページよ
り大きくなることができる。テーブルは、グラフィック
ス・アダプタおよびCPUによってアクセス可能でなけれ
ばならない。そしてその値は固定でなければならない。

【０１５６】イン待ち行列は、まだパージされていない
データが残っていて、パージング・タスクがすべてのデ
ータのパージングを完了する限り、一時的に使用禁止と
なっている待ち行列によっていつでも再マップされるこ
とができる。

【０１５７】アウト待ち行列違い、イン待ち行列が待ち
行列ポインタを使用して動的に動かされるならば、一般
にメモリの個別の各区域において完全なパケットを保証
することはできない。VTC装置およびグラフィックス・
アダプタは、必要に応じて、データをイン待ち行列に置
き、一般にグラフィックス・アダプタによるメモリアク
セスは、パケット・エンドポイントと一致しない。イン
待ち行列に使用されるメモリの各区域が完全なパケット
のみを含むということは、ソフトウェアが、データがグ
ラフィックス・アダプタから受け取られたあと、必要に
応じてメモリ区域間でデータを動かすならば、保証する
ことができる。

【０１５８】待ち行列は、システム・メモリの付加的デ
ータ・バッファへのポインタのセットとして実行される
ことができる。適応性およびシステム効率について利点
があるかもしれない。間接待ち行列が実行されること
は、VTCインターフェースに影響しない。間接待ち行列
は、システムに依存するオプションである。

【０１５９】待ち行列は、また、間接そして直接データ
の混合として実行される。たとえば主待ち行列は、直接
または間接を示す命令ワードから成っているパケット
（故障許容パージングを助ける）、ポインタ・ワード
（間接データのためにのみ存在する）、直接間接に関係
なく実データの長さを示す長さワード、およびこのパケ
ットに直接モードが使用される場合直接データ、を含
む。

【０１６０】図１１は、VTC-SAバス上のアダプタおよび
メイン・プロセッサ間のメッセージまたはデータの橋渡
しのための待ち行列システムの、好ましい実施例を示
す。メイン・プロセッサ４００は、イン待ち行列４１２
およびアウト待ち行列４１４を含む主記憶装置４１０に
接続する。メイン・プロセッサは、システムバス４１８
を通して同様にグラフィックス・アダプタ４２０のグラ
フィックス・プロセッサ４２５に接続する。グラフィッ
クス・プロセッサは、イン待ち行列のトップ、ボトム、
ヘッド、テール、およびアウト待ち行列のトップ、ボト
ム、ヘッド、テールを含む橋絡レジスタ、および各バッ
ファのための計数とイン・バッファ、アウト・バッファ
を含む、グラフィックス・メモリ４３０に接続する。グ
ラフィックス・プロセッサは、VTC-SA ４５０を通して
アダプタ１、４４０およびアダプタ２、４４５に同様に
接続する。

【０１６１】主記憶装置のアウト待ち行列は、VTC-SA上
のアダプタの１つにメイン・プロセッサから送り出され
たメッセージまたはデータを含む。イン待ち行列は、VT
C-SA上のアダプタの１つから送り出されたメイン・プロ
セッサへのメッセージを含む。グラフィックス・メモリ
の橋絡レジスタは、主記憶装置のイン待ち行列およびア
ウト待ち行列へのポインタを含む。グラフィックス・メ
モリのイン・バッファおよびアウト・バッファは、アダ
プタ上のメイン・プロセッサ間のメッセージ・パケット
の送信のためにある。

【０１６２】図１２は、アダプタの１つにメイン・プロ
セッサからメッセージまたはデータを提供するための待
ち行列システムの使用を図示している、フロー・チャー
トである。第１のステップ５００で、メイン・プロセッ
サは主記憶装置のアウト待ち行列にメッセージをロード
し、次に、メッセージがアウト待ち行列に加えられたこ
とを示すために、アウト待ち行列のためのヘッド・レジ
スタを更新するために、グラフィックス・アダプタに直
接メッセージを送り出す。ステップ５０５で、グラフィ
ックス・アダプタは、アウト・バッファ計数をチェック
することによって、グラフィックス・メモリのアウト・
バッファが満杯であるかどうか定期的に判断する。

【０１６３】それが最大限ならば、グラフィックス・ア
ダプタ・プロセッサは、データがアウト・バッファに入
れられるかどうか判断するために定期的にバッファをポ
ールする。アウト・バッファが満杯ならば、ステップ５
１０でグラフィックス・プロセッサは、アウト待ち行列
に対するヘッド・ポインタが１を加えたテール・ポイン
タ・アドレスと等しいかどうか判断して、主記憶装置の
アウト待ち行列にデータがさらに存在するかどう判断す
る。等しいならば、主記憶装置のアウト待ち行列の中に
残っているメッセージはない。アウト待ち行列にデータ
が残っているならば、グラフィックス・アダプタは、ア
ウト待ち行列からシステムバスを通してデータを読むこ
とができ、アウト・バッファにそれをロードし、それに
よりアウト・バッファ計数を増やす。それに加えてグラ
フィックス・アダプタは、アウト待ち行列のその部分が
読まれたことを示すためにアウト待ち行列へのテール・
レジスタを更新する。

【０１６４】ステップ５２０で、アダプタは、アウト・
バッファにメッセージまたはデータがあるかどうか、定
期的にグラフィッ クス・プロセッサに問い合わせる。
データがアウト・バッファにあるならば、ステップ５２
５でアダプタはグラフィックス・プロセッサを通してア
ウト・バッファを読む。アウト・バッファを読んだアダ
プタのためにアウト・バッファのデータがあるならば、
アダプタはデータのために処理を実行する。さもなけれ
ば、アダプタはそのデータを該当するアダプタへ送信す
るか、あるいは該当するアダプタに、有効なデータがあ
り、請求があれば該当するアダプタにそのデータを提供
することを知らせる。いずれの場合も、アダプタがデー
タがアウト・バッファにさらに存在するかどうか判断す
るためにグラフィックス・プロセッサに問合せをする、
ステップ５２０に処理は戻る。

【０１６５】図１３は、待ち行列システムを使用してい
るメイン・プロセッサにメッセージまたはデータを送り
出しているアダプタを示すフロー・チャートである。第
１のステップ５５０で、アダプタはグラフィックス・プ
ロセッサ４２５を通してグラフィックス・メモリのイン
・バッファにメッセージまたはデータをロードする。イ
ン・バッファのために有効なスペースの計数が、適切に
減らされる。ステップ５６０で、グラフィックス・アダ
プタは、メイン・プロセッサ４００を通して主記憶装置
のイン待ち行列にイン・バッファからメッセージをロー
ドする。グラフィックス・プロセッサは、イン・レジス
タのためのヘッド・ポインタおよびイン・バッファのた
めの計数を更新する。

【０１６６】ステップ５７０で、メイン・プロセッサ
は、メッセージがイン待ち行列で待機しているかどうか
判断するためにグラフィックス・アダプタを定期的にポ
ールする。待機メッセージがイン待ち行列になければ、
メイン・プロセッサは、待機メッセージがあるかどうか
判断するためにグラフィックス・プロセッサのイン・ポ
インタを定期的にポールし続ける。代替実施例におい
て、メイン・プロセッサは単に、メッセージが待機して
いることを示すグラフィックス・プロセッサからメッセ
ージまたは割り込みを待つ。メッセージが待機している
ならば、ステップ５８０で、メイン・プロセッサはイン
待ち行列からメッセージを読み、グラフィックス・プロ
セッサがグラフィックス・メモリのイン待ち行列への該
当するテール・レジスタを更新することを要求する。

【０１６７】代替実施例において、橋絡（ブリッジ）レ
ジスタは、バス上の各アダプタに１つ以上の、複数のイ
ンおよびアウト・バッファを含む。それに加えて、同様
に各アダプタに１つ以上の、複数のインおよびアウト待
ち行列が主記憶装置に保持される。さらに、別々のレジ
スタは、データが送り出されているアドレスを示すため
にグラフィックス・メモリに含められる。それに加え
て、他の処理機能に対する橋絡レジスタおよびプロセッ
サが、VTC-SA上の他のアダプタに置かれる。それに加え
て、橋絡はそれ自身VTC-SA上の別のアダプタになること
ができる。

【０１６８】好ましい実施例において、VTC-SAバス上の
アダプタの１つが、VTC-SA上のアダプタを待つメッセー
ジがあるかどうか判断するために定期的にグラフィック
ス・アダプタに問合せをする、バス分配装置として指定
される。これは、VTC-SAバスの初期化の間に準備され
る。しかし、メイン・プロセッサは定期的に異なるアダ
プタがバス分配装置になるよう要求する。それに加え
て、各アダプタがメッセージがアウト・バッファで待機
しているかどうか問合せ、メッセージが待機していると
該当するアダプタに知らせる、複数分配装置状況が利用
される。

【０１６９】バス・データ経路の確立 好ましい実施例において、メイン・プロセッサは、遠隔
VTCまたはVTC-SAビデオ・バス上にどのデータ経路が設
定されるかを制御する。メイン・プロセッサもシステム
バスも遠隔バスの上にないので、VTCおよびVTC-SAバス
はメイン・プロセッサから遠隔である。すなわち、メイ
ン・プロセッサは遠隔バスに通信するために、バス橋絡
またはそのようなものを初期化しなければならない。メ
イン・プロセッサは、ビデオ・バス上のアダプタ間の各
接続のための利用者または適用業務の要求に応答する。
それによって、利用者適用業務の制御の下の中央制御シ
ステムを維持する。

【０１７０】図１４は、これらのデータ経路がどのよう
に本発明の好ましい実施例を使用して設定されているか
を示すフロー・チャートである。第１のステップ８００
で、メイン・プロセッサは初期化間に、ビデオ・バス上
のアダプタのリストを作る。ステップ５１０で、メイン
・プロセッサは、初期化間に起こるであろうVTCまたはV
TC-SAバス上の幾つかのアダプタのためにアドレスを設
定する。お互いと通信する際に、ビデオ・バス上の幾つ
かのアダプタが、これらのアドレスを使用する。初期化
プロセスの詳細が上に記述されている。ステップ８２０
で、メイン・プロセッサは、バス上のをデータ経路を許
可するまたは使用禁止にする、利用者または適用業務か
らの要求を受け取る。メイン・プロセッサはまた、送信
メッセージのために上記プロセスを使用して、VTCまた
はVTC-SAバス上のアダプタの１つからこの要求を受け取
る。

【０１７１】ステップ８３０で、メイン・プロセッサ
は、要求されたデータ経路を可動（イネーブル）にする
か不動にするか決める。幾つかの基準を使用することが
できる。たとえば、VTCまたはVTC-SAバスは、単に要求
を扱うための十分な帯域幅を持たないかもしれない。プ
ロセッサはまた、可動にされた幾つかのデータストリー
ム間の優先度方式を確立することができる。メイン・プ
ロセッサがデータ経路を可動にも不動にもしないと決め
ると、メイン・プロセッサは利用者または適用業務にそ
のことを通信し、処理はステップ８２０に戻り、メイン
・プロセッサは次の可動あるいは不動の要求を待つ。

【０１７２】プロセッサがデータ経路を可動にするか、
あるいは不動にすると決心するならば、メイン・プロセ
ッサは、上述したメッセージを送るためのプロセスを使
用してビデオ・バス上のアダプタにそれらのデータ経路
の使用を開始または終了するよう通知する。メイン・プ
ロセッサは、許可されたデータ経路に対する、時間長ま
たは他の制限を提供する。例えば、メイン・プロセッサ
は、ビデオ・アダプタがひとつの着信ビデオ信号に１０
秒のビデオ・ディスプレイを提供するよう要求するかも
しれない。それに加えてメイン・プロセッサは、アダプ
タがさらに命令を受け取るまで、与えられたフレーム上
に着信ビデオ信号を凍結するようビデオ・アダプタに要
求することができる。

【０１７３】ステップ８５０で、メイン・プロセッサ
は、データ・ストリームが来るとグラフィックス・アダ
プタに知らせる。グラフィックス・アダプタが常にビデ
オ・バス上のスレーブであるならば、そのような通知は
必要でない。しかし、そのような通知によって、グラフ
ィックス・アダプタは着信データストリームを予期する
ことができ、そのようなデータストリームを援助する適
当な行動をとることができる。

【０１７４】ビデオ・アダプタは、着信データが終わ
る、あるいはプロセッサがそれを中断するまたは終らせ
るよう要求するまで、データ処理および、グラフィック
ス・アダプタへまたはお互いへのデータストリームの提
供を続ける。

【０１７５】データ形式 これは、VTCおよびVTC-SA構造のデータ形式（フォーマ
ット）層を指定する。特定の形式を識別するためにフィ
ールドＦ１ビットを判断する方法は、（１、２、４、
８、１２、１６、２４、３２）で始まるリストから１ピ
クセルのビット数を示すビット（２４ー２７）、そして
１から始まるビット（２４ー１７）の値である。したが
って、RGBa３２は「８」または「１０００」ビットを持
つ。より大きいピクセル・サイズを割り当てることもで
きる。ビット（２８ー３１）は、RGBが「０」型で、指
標が「１」型であるピクセル形式を示す。他の型を割り
当てることもできる。上記形式は図１５に示される。

【０１７６】RGBアルファ３２ このデータ形式は、図１５（Ａ）を参照して以下に述べ
られる。フィールドビットは、Ｆ１ビット（２４ー３
１）が「１０００００００」で、赤、緑、青およびアル
ファのそれぞれが８ビットである。示されるように、３
２ビット・ワードは１つのRGBAピクセルを含む。赤、
緑、青は、０から２５５まで変動する８ビット符号無し
２進整数として表された、ガンマ訂正値（非線形）であ
る。アルファは、宛先ピクセルが以下の数式を含む、書
込み転送の完了における混合パラメータである。 アルファ＊（転送されたデータ値）＋（１ーアルファ）
＊（「他の」バッファにおける値） ここで「他の」バッファは、スレーブよって仮定された
異なるフレーム・バッファであり、この他のバッファの
ピクセル・アドレスは、書き込み転送に使用されたもの
と同じである。スレーブは、混合アルファを実行する必
要はない。読取り転送においてアルファは定義されず、
スレーブは、「０」を書き込まなければならない。

【０１７７】RGB１６ このデータ形式は、図１５（Ｂ）を参照して以下に述べ
られる。フィールドビットは、Ｆ１ビット（２４ー３
１）が「０１１０００００」で、５ビットの赤、６ビッ
トの緑、５ビットの青である。３２ビット・ワードは、
２個のRGB１６ピクセルを含む。１つの３２ビットワー
ドの２つのピクセルは、左から右にディスプレイに現れ
るという順序にある。左端ピクセルはVTCデータワード
のビット０から、右端ピクセルはビット１６から始ま
る。

【０１７８】RGB８ このデータ形式は、図１５（Ｃ）を参照して以下に述べ
られる。フィールドビットは、Ｆ１ビット（２４ー３
１）が「０１００ ００００」で、３ビットの赤、３ビ
ットの緑、２ビット青をもつフィールドある。示される
ように、３２ビット・ワードは４つのRGB８ピクセルを
含む。１つの３２ビットワードの４つのピクセルは、左
から右にディスプレイに現れるという順序にある。左端
ピクセルはVTCデータワードのビット０から、右端ピク
セルはビット２４から始まる。

【０１７９】指標８ このデータ形式は、図１５（Ｄ）を参照して以下に述べ
られる。フィールドビットは、Ｆ１ビット（２４ー３
１）が「０１００ ０００１」で、８ビットのパレット
指標を持つ。パレット内容は、VTCによって指定されな
い。それらは、他の手段によって指定され受諾されなけ
ればならない。３２ビット・ワードは、４つの指標８ピ
クセルを含む。上記ピクセル（０、１、２、４）は、左
から右にディスプレイに現れる順序にある。RGB8は実
際、グラフィックス・アダプタの指標８の特定の値とし
て実行されるが、RGB８はビットの特定の符号化およ
び、パレットが使用されるならばパレットの特定の設定
を、定義する。しかし指標８は本質的には、特定のパレ
ット設定を意味しない。従って、指標８の使用は、スク
リーン上に表示される場合、それ自体データ値の適当な
翻訳を保証しない 。

【０１８０】データ形式、すなわち構文および意味は、
VTC-SA操作の３つのエリアにおける一貫した操作に必要
である。第１に、フラグ、記述ワード、長さおよび他の
制約を含むパケットにおいて。第２に、VTC装置および
その応答への命令において。第３に、複数のVTC装置間
のメッセージにおいて。VTC装置への圧縮されたデータ
は、ここに指定する必要はない。このような形式は、コ
ード化あるいは復号されている規格、あるケースにおい
てはCODECシステムが構成される方法に依存する。

【０１８１】パケット パケットは、２つのヘッダ・ワード、フラグおよび記述
子、およびこれに続くいくつかのデータ・ワードから成
る。含まれたワード数は、記述ワードの中で示される。
ひとつのワードは、この仕様のために、３２ビットであ
る。パケットは、データ、またはひとつ以上の命令ある
いは応答を含む。データを、命令および応答と同じパケ
ットの中で混ぜることはできない。

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

【０１８３】ビット０: データ／命令： 値が「１」
の時、後に続くパケットが、たとえば圧縮ビデオのよう
なデータを含むことを示す。値が「０」の時、パケット
がVTC装置に送られているならば、パケットが命令ある
いは命令の順序を含むことを示す。値が「０」の時、パ
ケットがVTC装置から送られているならば、パケットが
以前に発行された命令へのメッセージまたは応答を含む
ことを示す。保留されたビット１ー３および８１５:
パケットを作っている装置およびタスクが、「０」を書
き込む。データの受取側は、値を無視する。 ビット１６ー３１： 長さ: このフィールドは、次の
フラグ・ワードより前にこのワードに続いているデータ
のワード数（それぞれ３２ビット）を示す符号無し整数
を含む。値がゼロの時、次のワードがフラグ・ワードで
あることを示す。長さフィールドの中で指定されるよう
に、パケット・データは複数のデータ・ワードから成
る。VTCインターフェースからの各ワードの最初のバイ
トは、ビット０から始まる左端である。すなわち、待ち
行列スタートが、待ち行列終了より低く、データのバイ
トがより高いアドレスに加えられるならば、各ワードの
低位アドレス・バイトはVTCワードの左にマップされ
る。１６ビットVTC実現において、左のハーフワード
は、右半分より前に送られる。

【０１８４】転送されるパケットのサイズ制限は、符号
化および復号プロセスのバッファ管理および複数の待ち
行列中のプロセスの待ち時間、のような理由のために、
ほとんどの適用業務において必要とされる。１つのプロ
セス中のより長いパケットは、バッファ要求および待ち
時間を増やし、すべての他のプロセスのパケットを無く
して、時間を消費する。一方、より短いパケットはオー
バーヘッドを増やす。オーバーヘッドは、システム待ち
行列をパージし、構成するソフトウェアの中でもっとも
顕著である。ほとんどのパケットが非常に小さいサイズ
になる場合を除き、２ワードパケット・ヘッダのための
VTCオーバーヘッドは無視してよい。もっとも大きい帯
域幅に対する最適のパケットサイズは、パケットサイズ
を含む、全ソフトウエア・アーキテクチャ、ネットワー
クおよびDASD通信規約に依存する。

【０１８５】絶対的パケットサイズ制限、あるいは制限
に依存する適用業務を生成する公式がこのアーキテクチ
ャに必要かどうかは、未定である。VTC-SAの一部として
指定されるかどうかに関係なく、待ち時間のためにパケ
ットサイズには十分注意しなければならない。

【０１８６】本発明が特定の実施例の参照によって上に
述べられたが、この分野の技術者には他の実施例があり
得ることが明らかである。将来、より多いまたは少ない
装置間通信を伴う、より大きい帯域幅およびより多くの
装置の必要性がでてくるであろう。同時に、例えば限ら
れたデータラインのより大きい帯域幅に対するより大き
いクロック速度を可能にするような、異なる科学技術が
可能になるであろう。橋絡をもつ複数のVTCは実行可能
となり、VTCSの数だけ 倍になる効果的スループットを
生じるであろう。例えば光学部品を使用している、ボッ
クス間バスへの橋絡が、生産されるであろう。このよう
な拡張のために、ここに含まれた論理的定義は、我々が
知るかぎり適当である。科学技術が進むにつれ、VTCま
たはVTC-SA上の要求と平行して、今日一般的な電気的論
理レベルの使用は廃止されるであろう。将来の低電圧電
気信号レベルまたは光学信号は明らかに可能であるが、
今日の信号レベル、つまり初期の実現には、明らかにプ
ラグ交換可能ではない。したがって上述の記述は、請求
項によって定義される本発明の有効範囲を制限するもの
ではない。

【０１８７】

【発明の効果】本発明によると、システム・バスに大き
な負担をかけることなく多くの情報を取り扱うことがで
きる。

【図面の簡単な説明】

【図１】発明の好ましい実施例により使用された典型的
デジタルコンピュータ１００の高水準ブロック図であ
る。

【図２】本発明の第１の好ましい実施例におけるメイン
・プロセッサ・バスと並列するビデオ転送チャネル（VT
C）の高水準ブロック図である。

【図３】本発明の第２の好ましい実施例におけるメイン
・プロセッサ・バスのあるビデオ転送チャネル・スタン
ドアロン（VTC-SA）の高水準ブロック図である。

【図４】本発明の好ましい実施例に従って書込み転送を
図示しているタイミング図である。

【図５】発明の好ましい実施例における読取り転送のタ
イミング図である。

【図６】図６（Ａ）ないし（Ｃ）は、発明の好ましい実
施例に従って使用された幾つかの制御フィールドの図で
ある。

【図７】図７（Ａ）および（Ｂ）は、発明の好ましい実
施例に従って使用された幾つかの制御フィールドの図で
ある。

【図８】図８（Ａ）および（Ｂ）は、発明の好ましい実
施例に従って使用された幾つかの制御フィールドの図で
ある

【図９】図９は、本発明の好ましい実施例におけるグラ
フィックス・アダプタおよびビデオ・アダプタのブロッ
ク図である。

【図１０】図１０は、表示されていた徐々に劣化するデ
ータのための好ましい方法を図示しているフロー・チャ
ートである。

【図１１】図１１は、本発明の好ましい実施例に従った
投影システムのブロック図である。

【図１２】図１２は、本発明の好ましい実施例に従った
待ち行列システムの使用を図示しているフロー・チャー
トである。

【図１３】図１３は、本発明の好ましい実施例に従った
待ち行列システムの使用を図示しているフロー・チャー
トである。

【図１４】図１４は、本発明の好ましい実施例に従って
データ経路を使用禁止または可能にするフロー・チャー
トである。

【図１５】図１５（Ａ）ないし（Ｄ）は、本発明の好ま
しい実施例に従ったデータフォーマットを示す図であ
る。

【符号の説明】

１００．．．．コンピュータ １１０．．．．主プロセッサ １２０．．．．主メモリ １６０．．．．バス ２００．．．．グラフィックス・アダプタ ２２０．．．．グラフィックス・アダプタ・プロセッサ

Claims (7)

【特許請求の範囲】
1. 【請求項１】 第１の処理装置と第２の処理装置との間
   の遠隔バス上にデータ経路を可能にする要求を受け取る
   ステップと、 上記遠隔バスが要求されたデータ経路を取り扱うことが
   できるかどうか判断するステップと、 上記遠隔バスが要求されたデータ経路を取り扱うことが
   できるならば上記遠隔バス上にデータ経路を可能にする
   ステップと、 を含むデータ経路を可能にする方法。
2. 【請求項２】 上記データ経路を可能にするステップ
   は、要求されたデータ経路を可能にするために上記処理
   装置の少なくとも一つに要求を送ることを含む請求項１
   に記載の方法。
3. 【請求項３】 上記遠隔バス上に複数のデータ経路を可
   能にするステップを含む請求項２に記載の方法。
4. 【請求項４】 上記複数のデータ経路を可能にするステ
   ップは、複数のデータ経路が上記遠隔バスの使用を同時
   に争うことを可能にする請求項３に記載の方法。
5. 【請求項５】 上記複数のデータ経路を可能にするステ
   ップは、可能にされた各データ経路を優先付けすること
   を含む請求項４に記載の方法。
6. 【請求項６】 第１の処理装置と第２の処理装置との間
   の遠隔バス上にデータ経路を可能にする要求を受け取る
   手段と、 上記遠隔バスが要求されたデータ経路を取り扱うことが
   できるかどうか判断する手段と、 上記遠隔バスが要求されたデータ経路を取り扱うことが
   できるならば上記遠隔バス上にデータ経路を可能にする
   手段と、 を含むデータ経路を可能にする装置。
7. 【請求項７】 データを処理するプロセッサと、 処理すべきデータを記憶するメモリと、 遠隔バス上の第１処理手段と、 上記遠隔バス上の第２処理手段と、 上記第１処理手段と上記第２処理手段との間の遠隔バス
   上にデータ経路を可能にする要求を受け取る手段と、 上記プロセッサに含まれ、上記遠隔バスが上記メモリに
   記憶されたデータからのデータ経路を取り扱うことがで
   きるかどうかを判断する手段と、 上記遠隔バスが要求されたデータ経路を取り扱うことが
   できるならば上記遠隔バス上にデータ経路を可能にする
   手段と、 を備えるデータ処理システム。