JP3641354B2 - 分散型のコンピュータ・システム - Google Patents
分散型のコンピュータ・システム Download PDFInfo
- Publication number
- JP3641354B2 JP3641354B2 JP22133297A JP22133297A JP3641354B2 JP 3641354 B2 JP3641354 B2 JP 3641354B2 JP 22133297 A JP22133297 A JP 22133297A JP 22133297 A JP22133297 A JP 22133297A JP 3641354 B2 JP3641354 B2 JP 3641354B2
- Authority
- JP
- Japan
- Prior art keywords
- controller
- server
- video
- bus
- processor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2294—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by remote test
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
- Bus Control (AREA)
- Digital Computer Display Output (AREA)
- Information Transfer Between Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、分散型コンピュータ・システムに関し、更に特定すれば、ホスト・コンピュータ（「ホスト」）であって、当該ホストとは物理的に接続されておらず、このホストから離れた場所に位置する端末からアクセス可能なホストに関するものである。遠隔端末は、ホストのリセットまたは障害処理の間に発生する一連のビデオ画面のような、記憶されている一連のビデオ画面にアクセスすることができる。この一連のビデオ画面は、次に遠隔端末に配置されているコンピュータ管理者による再生が可能である。これらビデオ画面への遠隔アクセスにより、管理者は、ホストのオペレーティング・システムがどのようにリセットに応答するのか、即ち、ホスト・システムが障害を発生した場合の原因として可能性のあるものを判定することができる。ホストには、プリント回路基板（「ＰＣＢ」）が設けられており、ホストを収容するバックプレーン(backplane)に挿入することができる。ＰＣＢは、プロセッサと、ホストへの電力が失われた場合でも前述の一連のビデオ画面を記憶しているメモリとを備えている。
【０００２】
【従来の技術】
分散型コンピュータ・システムは、一般的によく知られている。かかるシステムは、多数のコンピュータ・ワークステーション上で実行される(hosted)アプリケーション・プログラム間での通信が可能である。分散型コンピュータ・システムには多数の種類があり、多くの場合、それらの通信能力の地理的範囲によって分類されている。分散型コンピュータ・システムの地理的広さ(geographical breadth)を分類するために用いられる用語には、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、およびワイド・エリア・ネットワーク（ＷＡＮ）がある。
【０００３】
増々普及しつつある分散型コンピュータ・システムの多くは、ファイル・サーバ（「サーバ」）を採用している。ファイルまたはデータは、サーバ内のホストによって管理される。サーバが特に有用なのは、サーバによって、記憶されているファイルに対するワークステーションの高速アクセスが可能になる点にある。したがって、ファイル・サーバは、ファイルを編成(orchestrate)するだけでなく、ファイルの機密保護、ファイル・バックアップ等の保守も行う、オペレーティング・システム・プログラム（普及しているオペレーティング・システムには、例えば、Windows NT（登録商標）がある）に応答するホスト・コンピュータを具現化するものである。
【０００４】
サーバ内においてホストの機能を維持することの重要な一面に、ホストから離れた場所からホストを管理すること、より具体的には、物理的にサーバに連結されているワークステーションから離れた場所にあるホストを管理することがあげられる。最近の傾向として、業務に使用するサーバの数が確実に増加している。今日では、サーバは、１カ所に集中させたメインフレームを採用するのではなく、業務実体の各位置毎等のように自由に用いられている。しかしながら、分散した場所に配置された多くのサーバ・ホストを管理するために利用可能な資金は減少しつつある。これらのサーバに置かれているデータは業務には非常に重要であるが、単一のサービス現場からそれらの適正な動作を確保するための手段は、未だに不十分である。管理者が遠隔地にあるサーバ設置現場まで移動して問題を解決するというようなことは、実用的でないだけでなく、サーバのダウンタイム（動作不能時間）に付随する出費は膨大なものとなる。
【０００５】
多くのオペレーティング・システム、またはこれらオペレーティング・システムと関連するアプリケーションは、しばしば、バーチャル・ターミナル即ち仮想端末と呼ばれている遠隔地からのホストへのアクセスを許可する。仮想端末は物理的にホストに接続されていないが、ホストの所定の動作の遠隔制御を許している。コンパック・コンピュータ社（Compaq Computer Corp.）から入手可能なCOMPAQ Server Manager/R （登録商標）およびCOMPAQ Insight Manager（登録商標）（「ＣＩＭ」）のような製品は、単一の遠隔地から分散されたサーバのネットワークを管理する際に付随する問題のいくつかに対処しようとしたものである。これらの製品は、特に、管理者に遠隔サーバの障害を警告し、遠隔地からのサーバのリセットや、サーバ・コンソール上に提供される所定の情報へのアクセスを可能にする。
【０００６】
所定のサーバ機能、得に、サーバのネットワーク内における１台以上のサーバをリセットするために必要な機能の遠隔制御を可能にすることは、確かに有益である。サーバの障害によって発生するダウンタイムは、いずれにしても、分散型コンピュータ・システムを動作させる際に生じる恐らく最も高くつく時間である。サーバの障害は、しばしばサーバ・ホストの「クラッシュ」と呼ばれるが、その原因は多数ある。サーバ・ハードウエア、サーバ・オペレーティング・システム、またはサーバ上で実行されるアプリケーション・プログラムに関連するあらゆる数の誤動作や設計フローが、サーバ・クラッシュの要因となり得る。サーバがクラッシュを起こすと、多くの場合ファイル・アクセスが不可能となり、障害の原因が突き止められるまで、業務記録は一時的にアクセス不能となる。
【０００７】
【発明が解決しようとする課題】
サーバから離れて位置する管理者が、警告を受け、障害を発生したサーバをリセットする以上の処置を行うことができれば、極めて有益であろう。特に、管理者がサーバの障害原因を判定し、彼／彼女が、今後の障害発生の前に、それらを防止できるようになれば、有益であろう。障害の防止は、クラッシュしたサーバをリセットすることと同様に重要である。
【０００８】
通常、障害の原因は、サーバがクラッシュした時点に、サーバのコンソール上に表示される。更に、リセット時（または「ブート」時）には、サーバ・ホストのハードウエアまたはオペレーティング・システム・ソフトウエアにおける異常を検出することができる。これらの異常は、管理者が対処しなければ、将来の障害に発展する可能性がある。したがって、サーバのリセット中（または障害中）だけでなく、サーバのリセット／障害に至る間にも、サーバ・ホストのコンソール上に表示されるものへのアクセスが得られれば有益である。サーバのコンソール上に表示されるビデオ画面（即ち、一連のビデオ画面）内の情報は、サーバの障害またはリセット時に生成されるが、遠隔地にいる管理者が、既存のサーバの障害または潜在的な障害を判定（および望ましくは解決）するのに、役立つであろう。
【０００９】
サーバのリセットまたは障害により発生するビデオ画面は、オペレーティング・システムによってホスト・サーバのコンソール上に表示される一連のビデオ画面の変化、システム基本入出力システム（「ＢＩＯＳ」）、サーバのアプリケーション・プログラム、またはその他のシステム・ソフトウエアから成る。特に、２種類の連続画面変化を捕獲することは、サーバの管理者には特別な関心事であろう。既存の障害または今後の障害を解決するためには、サーバの障害に先だって、かかる一連の画面変化やリセットに続く一連の画面変化を、管理者に与えることは有益であろう。サーバのコンソール上に表示されるサーバ障害画面の例には、マイクロソフト社（Microsoft Corp.）のWindows NT：登録商標）の「ブルー・スクリーンズ(blue screens)」、およびノベル社（Novell Corp.）のnetware（登録商標）のABENDメッセージがあり、これらは、それぞれのオペレーティング・システムがクラッシュしたときに、サーバのコンソール上に現れる。これらの画面は、プロセッサの故障表示(processor fault indicia)、システム・ソフトウエア・ルーチンのアドレス、および関連のあるシステム・メモリの内容のような情報を提供する。サーバのリセット時に、通常、前述のオペレーティング・システムに付随する起動時自己検査（「ＰＯＳＴ」）コードが幾つかのシステム診断を行い、検出された障害に関する情報を、サーバ・コンソールの画面に表示する。したがって、連続画面を捕獲し、遠隔管理部署においてそれらを再生するための手段が望まれている。
【００１０】
ハードウエアおよびソフトウエアの問題に加えて、サーバへの電力が中断した場合にも、サーバは障害を発生する可能性がある。しかしながら、電力が中断した場合は、障害の前に何が起こったのかについての画面変化は全て失われる。したがって、サーバは、サーバへの電力が失われても、リセットおよび障害時の画面変化をセーブするための機構を備えていることが必要である。このようにすることにより、記憶されている画面変化を遠隔地にいる管理者が後日読むことができるので、有益である。このための望ましい機構は、停電の間、画面情報を保持することができる機構であり、該機構内の重要なユニットにのみ選択的に電力を供給することができるものである。したがって、好ましくはサーバのシャーシ内に実装可能なＰＣＢ上に実現される機構が必要とされる。このＰＣＢは、ホスト・サーバに接続し、ホストから出力される画面情報を記憶し、サーバへの電力が遮断されたときでも情報を保持する保持媒体を含むことが望ましい。
【００１１】
遠隔地およびサーバ間の通信は、Amerian National standards Institute（「ＡＮＳＩ」）の端末エミュレーション・プロトコルのような、業界において一般的に知られている、テキストを基本とする接続プロトコルを通じて行われる。端末エミュレーション・プロトコルはある水準の機能を提供するが、他のプロトコル、即ち、単純なネットワーク管理プロトコル（「ＳＮＭＰ」）、サーバ管理情報の通信用プロトコルのような、アプリケーション・レイヤ・プロトコルを可能にするプロトコルを、サーバおよび遠隔地間の二地点間（「ＰＰＰ：point-to-point 」）通信リンク上においてサポートすることが望ましい。サーバが、複数の通信プロトコルを用いて遠隔地と通信するためのシステムを実現するＰＣＢを含む場合、遠隔地がサーバと通信する際にサポートするプロトコル（即ち、テキストを基本とするプロトコル、ＰＰＰ等）のどれを使用しているのかを、ＰＣＢ上のサブシステムが判定することが望ましい。
【００１２】
【課題を解決するための手段】
上記した従来例の問題点は、本発明の遠隔通信システムによってほぼ解決される。本発明の遠隔通信システムは、サーバ上の拡張バスに接続可能なサーバ・コントローラを採用する。好ましくは、サーバ・コントローラは、ＥＩＳＡ拡張バスに接続可能なエッジ・コネクタを有するＰＣＢ上に実現される。サーバ・コントローラは、ビデオ・アドレス範囲内のライト（書き込み）・サイクルを検出する検出ロジックを含む。ライト・サイクルは、ビデオ・コントローラに送出される表示データも拡張バス上に配列されたときに、開始される。したがって、検出ロジックは拡張バスを監視して(snoop)表示データを発見し、表示データをコントローラ・メモリに複写、即ち記憶する。
【００１３】
コントローラ・メモリは、検出ロジックと同様、サーバ・コントローラのＰＣＢ上に実現され、複数のバッファを含む。コントローラ・メモリに向けて送出される表示データはローカル・フレーム・バッファに格納され、ローカル・フレーム・バッファはこの表示データをフレーム毎に記憶する。以前の表示データのフレーム即ち画面を現在の表示データのフレーム即ち画面と比較し、それにより、変化が生じた場合にそれを表示することができる。変化は、サーバの表示装置に登録されると、これもコントロール・メモリと連携する現（カレント）シーケンス・バッファ内に記憶される。現シーケンス・バッファは、サーバの障害またはリセットに先だって発生した一連のビデオ画面変化、サーバの最新のリセット後に発生した一連のビデオ画像変化、および最新のリセットに先だって発生した一連のビデオ画面変化という、３種類の変化を記憶する。障害によるビデオ画面変化（即ち、ブルー・スクリーンズまたはABENDメッセージ）だけでなく、現在および以前のリセットによるビデオ画面変化も記憶することにより、管理者は、サーバの障害理由、または今後の障害の可能性について判定することができる。
【００１４】
管理者はサーバから離れて位置する端末を用いて、コントローラ・メモリ内に記憶されている様々な連続ビデオ画面変化のいずれでも検索することができる。サーバ・コントローラは、遠隔端末から送られてくる異なるタイプの通信プロトコルを認識することができる。サーバ・コントローラ内のローカル・プロセッサは、各プロトコル専用の状態マシンを用いることによって、送られてくる通信プロトコルを認識することができる。送られてくる文字または文字グループにしたがって、状態マシンは、通信プロトコルがテキストに基づくプロトコルか、ＰＰＰプロトコルか、または予備ＰＰＰプロトコル(pre-PPP protocol)かについての判定を行うことができる。先に記した種々のプロトコルは、例えば、電話線または直接直列接続を通じて帯域外接続(out-of-band connection)を行う際に用いられるインターネットワーク・プロトコル(internetworking protocol)として頻繁に用いられているプロトコルとして、当業者にはよく知られている。これは、遠隔端末（ターミナル）からの多数のプロトコルに対応し(service)、入来するプロトコルおよびそれが定義する利点を検出する能力を有している。したがって、送られてくるプロトコルとは無関係に、プロセッサは、通信情報に作用して、これをコントローラ・メモリに送出するように構成される。これによって、コントローラ・メモリは、通信プロトコル上で実施される指令に応答して、様々な連続ビデオ画面を発信することができる。
【００１５】
検出ロジック、コントローラ・メモリ、プロセッサおよび通信ユニットは、ＰＣＢ上に構築されたシステムとしてコンパイルされる。サーバへの電力が絶たれた場合、拡張バスを通じてＰＣＢに供給される主電源も絶たれる。しかしながら、ＰＣＢは、拡張バスからの電力が停止しても、所定の動作機能(vital function)を維持するように構成されている。ＰＣＢは、二次電源または電池を採用しており、拡張バスの電力が停止した場合、二次電源により、プロセッサおよびコントローラ・メモリに、そして選択的に通信ユニットに電力を供給する。電池は、コントローラ・メモリ内に記憶されているビデオ画面情報を保持するのに十分な時間にわたって、プロセッサおよびコントロール・メモリの能力を維持するだけでなく、これらの間の通信も維持することができる。通信ユニットが遠隔端末によってアクセスされていない場合、電池から通信ユニットへの電力は停止させる。このために、遮断（デカップリング）回路が設けられており、通信ユニットが使用されていない場合、電池の不要な電力漏出を防止する。
【００１６】
プロセッサとコントローラ・メモリが位置するＰＣのプレーン（または部分）と、通信ユニットが位置するＰＣＢのプレーンとの間に、第１の遮断（デカップリング）ユニットが設けられている。また、プロセッサおよびコントローラ・メモリ・プレーンと、検出ロジックが位置するＰＣＢのプレーンと間に、第２の遮断ユニットが設けられている。これによって、検出ユニットは、プレーン間で電力を遮断するだけでなく、プレーン間を接続する信号導体も遮断するように機能する。プレーン間における電力の遮断および３ステート信号は、電池電源上の電荷保存に役立つので、サーバのダウンタイム中に連続ビデオ画面変化を記憶維持するために必要な電力を最大限利用することができる。
【００１７】
【発明の実施の形態】
本発明は様々な変更や代替形態が可能であるが、その具体的な実施例を、一例として図面に示し以下に詳細に説明する。しかしながら、図面やその説明は、開示される特定形態に本発明を限定しようとするのではなく、逆に、特許請求の範囲によって規定される本発明の主旨および範囲に該当するあらゆる変更物、均等物および代替物が、本発明に含まれるものである。
【００１８】
まず図１を参照すると、コンピュータ・システム１０のブロック図が示されている。コンピュータ・システム１０は、ファイルの記憶および検索を行う任意のシステム、ファイル・サーバとして機能するシステム、アプリケーション・サーバ、または分散型コンピュータ・システムにおいて公知である他のサーバを含むことが好ましい。システム１０は、ホスト中央演算装置、即ちサーバＣＰＵ１２を含み、ＣＰＵローカル・バスを介して、メモリ・コントローラ１４に結合されている。ＣＰＵ１２は、所定の命令を実施するためのデータ演算装置を含み、とりわけ、実行ユニット、制御／タイミング・ユニットおよび種々のレジスタという基本的構造を有する。代表的なＣＰＵ１２は、インテル社（Intel Corp.）が製造するペンティアム（Pentium（登録商標））プロセッサを含む。
【００１９】
メモリ・コントローラ１４は、ＣＰＵローカル・バスおよびシステム・メモリ１６間のデータ転送を指揮する。メモリ・コントローラ１４は、種々のアドレシング技法に応答し、システム・メモリ１６内の様々な記憶セル・アーキテクチャに対応するように構成されている。適切なアーキテクチャは、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）またはスタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）である。メモリ・コントローラ１４は、ＣＰＵ１２と同期して動作し、システム・メモリとの間に最大転送帯域を確保することが好ましい。
【００２０】
本発明の一実施例によれば、ＣＰＵ１２は、周辺要素インターフェース（「ＰＣＩ」）バスに結合されている。バス・インターフェース・ユニット１８が、ＰＣＩバスおよび拡張バス間のバス・ブリッジとして動作する。バス・インターフェース・ユニット１８はバッファを含み、ＰＣＩバスおよび拡張バス間におけるデータおよびアドレス信号の転送を制御する。こうすることにより、バス・インターフェース・ユニット１８は、クロック速度が異なる可能性がありかつ異なるプロトコルで動作するバスを通じて送出されるデータ間のインターフェースとして機能する。好ましくは、拡張バスは、拡張業界標準アーキテクチャ（「ＥＩＳＡ」）バス・コンフィギュレーションから成る。
【００２１】
拡張バスには、ビデオ・コントローラ２０が接続されている。ビデオ・コントローラ２０は、それに接続されているディスプレイすなわち表示装置２４を制御するために用いられる。ビデオ・コントローラ２０は、ビデオ・グラフィクス・アレイ（「ＶＧＡ」）コントローラのような、一般的に使用されているビデオ・コントローラである。ビデオ・コントローラ２０は、拡張バス上のアドレスに応答し、対応するデータをビデオ・メモリ２２に送出する。ビデオ・メモリ２２は、ビデオ・コントローラ２０が表示装置２４上に表示するビデオ・データを記憶する。表示装置２４は、ビデオ・データを受け取ることができるいずれかのコンソールまたはモニタを含み、好適な表示装置２４は、陰極線管（「ＣＲＴ」）、あるいは液晶表示装置（「ＬＣＤ」）である。ビデオ・コントローラ２０およびビデオ・メモリ２２を、以降一括してビデオ・サブシステムと呼ぶことにする。
【００２２】
サーバ１０には、サーバ１０のリセット後の連続ビデオ画面変化だけでなく、サーバ１０の障害前の連続ビデオ画面変化もセーブする機構が内蔵(retrofit)されている。これを行う機構は、サーバへの電源停止に影響されないものでなければならず、更に、記憶されているビデオ画面を遠隔端末に送出する能力を有していなければならない。かかる機能は、サーバ・コントローラ２６によって実行される。サーバ・コントローラ２６は、サーバ１０のシャーシ内に結合され、拡張バスに接続可能である。この場合、コントローラ２６は、サーバ１０から離れて位置する端末からアクセス可能である。好適実施例によれば、遠隔端末２８は、電話線通信装置を介して、サーバ・コントローラ２６に結合される。電話線通信装置の一例は、遠隔端末２８およびサーバ・コントローラ２６双方に内蔵されているモデムである。遠隔端末２８は、表示装置（例えば、ＣＲＴ）および入力装置（例えば、キーボード）を含む。
【００２３】
一実施例によれば、サーバ・コントローラ２６は、コンパック・コンピュータ社から入手可能なソフトウエアによって動作する。具体的には、該ソフトウエアは、コンパック・コンピュータ社の、遠隔端末２８上で動作可能なCompaq Insight Manager（「ＣＩＭ」）という製品名のソフトウエアである。ＣＩＭは、サーバ・コントローラ２６に装填されているファームウエアにアクセスし、例えば、サーバ・コントローラ２６に記憶されている種々のビデオ画面変化の再生を行うことができる。
【００２４】
サーバ・コントローラ２６のハードウエアおよびファームウエア構造は、ＣＩＭを用いて構成された遠隔端末による遠隔アクセスおよび制御を利用可能とする。サーバ・コントローラ２６に追加されるハードウエアおよび付随するコードにより、サーバ１０が障害を発生した後でも、システム管理者はサーバ・コントローラ２６に発信する(dial into)ことができ、その後サーバ・コントローラ２６と通信し、障害の前またはリセットの後に発生した表示装置２４の一連の画面変化を見ることができる。
【００２５】
サーバ・コントローラ２６内のファームウエアまたはコードは、遠隔端末２８と通信するために用いられるコンソール・アプリケーション・コードとして機能する。図２のａは、コンソール・アプリケーションが遠隔端末２８上に表示する初期メニュー画面の画面表示である。システム管理者がサーバ・コントローラに発信したときはいつでも、この画面表示が発生する。管理者は、メニュー項目のいずれかを選択することができる。彼または彼女がメニュー項目４を選択した場合、管理者は、彼または彼女の遠隔端末２８において、サーバ・コントローラ２６内に記憶されている一連のビデオ画面を見ることができる。ここでは、次にあげる３種類の異なる連続ビデオ画面変化を再生することができる。
【００２６】
（i）サーバ１０の以前のリセット後に発生した一連のビデオ画面
（ii）サーバ１０の現リセットの後に発生した一連のビデオ画面
（iii）サーバ１０の障害の前に発生した一連のビデオ画面
ここでは、上述の（i）〜（iii）における連続ビデオ画面のことを、「現リセット・シーケンス」、「前リセット・シーケンス」、および「障害シーケンス」と呼ぶことにし、これらを一括して「再生シーケンス」と呼ぶことにする。
【００２７】
図２のｂは、システム管理者がサーバ・コントローラ２６に前述のシーケンスのいずれかを表示するよう命令するために用いる、メニュー画面の画面表示である。図２のｃは、システム管理者がサーバ・コントローラ２６に、現リセット・シーケンス、前リセット・シーケンス、および障害シーケンスのいずれかの再生開始や一時停止を行ったり、再生速度を変化させるように命令するために用いるメニュー画面の画面表示である。
【００２８】
現リセット・シーケンスは、サーバ１０の最新のリセットの直後に発生した一連のビデオ画面変化から成る。前リセット・シーケンスは、サーバ１０の最新のリセット前に発生したリセットの直後に発生した一連のビデオ画面変化から成る。障害シーケンスは、サーバ１０のリセット、障害または停電の直前に発生した一連のビデオ画面変化から成る。サーバ・コントローラ２６が、障害シーケンスのために、サーバ１０のリセットまたは停電の前に記憶する画面変化数、あるいは前リセット・シーケンスまたは現リセット・シーケンスに続いて記憶する画面変化数は、サーバ・コントローラ２６が所与の再生シーケンスに使用可能なバッファ空間の量によって決定される。
【００２９】
図３には、サーバ１０内のメモリ・アドレス空間およびＩ／Ｏアドレス空間の部分が示されている。メモリ・アドレス範囲［０ｘＢ０００〜０ｘＢＦＦＦＦ］は、ビデオ・メモリ２２内に位置するビデオ・フレーム・バッファのために予約されている。Ｉ／Ｏアドレス範囲［０ｘ０３Ｂ４〜０ｘ０３ＢＡ］および［０ｘ０３Ｃ０〜０ｘ０３ＤＡ］は、ビデオ・コントローラ２０内のビデオ制御レジスタに指定されている。ＣＰＵ１２は、ビデオ制御レジスタに値を書き込むことによって、表示装置２４の様々な動作を制御する。フレーム・バッファ・メモリのアドレス範囲およびビデオ制御レジスタのＩ／Ｏアドレス範囲のことを、ここでは一括してビデオ・アドレス範囲、即ち、ビデオ・サブシステムに送られるデータのためのアドレス範囲と呼ぶことにする。
【００３０】
表示装置２４は、テキスト・モードにある場合、行列から成るマトリクスに組織される。例えば、一般的な表示画面構成は、２５ｘ８０である。したがって、２０００（＝２５ｘ８０）箇所の文字位置が、表示装置２４上において使用可能である。表示装置２４上の各位置は、フレーム・バッファ内に対応するワード（即ち、２バイト）を有する。このワードの下位バイトは、文字値（例えば、アスキー文字集合における文字「Ａ」に対する０ｘ４１）を含み、このワードの上位バイトは対応する属性（色、前面および背面の輝度、文字を点滅させるか否か等のような属性）を含む。ＣＰＵ１２は、ビデオ・メモリ２２内の適切なフレーム・バッファ位置に値を書き込み、表示装置２４上に所望の文字および属性を表示させる。文字および表示に対する属性を含むフレーム・バッファ内のビデオ・データのことを、ここでは表示データと呼ぶことにする。上述の例では、表示画面全体を表わす表示データを記憶するために、４０００バイト［すなわち、２０００位置ｘ（各位置毎に２バイト）、文字に１バイトおよび属性に１バイト］のフレーム・バッファが用いられる。
【００３１】
以下にあげる３つの例は、ビデオ制御レジスタの多くの使用法のいくつかを示す。尚、ビデオ制御レジスタのアドレスは、Ｉ／Ｏアドレス空間内に予約されている。第１に、ＣＰＵ１２はビデオ制御レジスタのアドレス（即ち、アドレス範囲［０ｘ０３Ｂ４〜０ｘ０３ＢＡ］およびアドレス範囲［０ｘ０３Ｃ０〜０ｘ０３ＤＡ］に書き込みを行い、例えば、表示装置２４上のカーソルの位置および属性を制御する。第２に、ＣＰＵ１２はビデオ制御レジスタに書き込みを行い、例えば、ビデオ・モードをカラー・モードから白黒モードに、またはその逆に変更する。第３に、ビデオ制御レジスタは、多数の画面を記憶することができるビデオ・メモリ２２内の開始アドレスを指定することができる。第３の例では、ビデオ・メモリ２２は、１画面分の表示データを記憶するのに必要な記憶位置よりも多い記憶位置を含むものと仮定する。
【００３２】
ビデオ・メモリ２２が６４ＫＢのメモリを含む（即ち、フレーム・バッファに６４ＫＢが使用可能）と仮定した場合、フレーム・バッファが１画面分の表示データを記憶するために用いるのは４０００バイトに過ぎないので、フレーム・バッファは一度に多数の表示データの集合を格納することができる。ＣＰＵ１２は、ビデオ制御レジスタに書き込みを行い、表示装置２４上に表示させる表示データの最初の集合の、ビデオ・メモリ２２内の開始アドレスを指定する。ビデオ・コントローラに関する情報、より具体的には、上述の代表的な制御機能の多くを実行するためのビデオ制御レジスタを使用するＶＧＡコントローラに関する情報は、とりわけ、Cirrus Logic Corp., Part no. CL-GD542xから入手可能である。
【００３３】
ビデオ・コントローラ２０は、拡張バス（好ましくは、ＥＩＳＡバス）上に発生されたアドレスをデコードし、ビデオ・アドレス範囲内においてバス・サイクルに応答する。ビデオ・コントローラ２０は、ビデオ・メモリ２２内に記憶されている表示データを表示装置２４に送るだけでなく、ＣＰＵ１２がビデオ制御レジスタに書き込んだデータに応答して、表示装置２４を制御する。したがって、ビデオ・メモリ２２は文字および属性情報を格納し、一方ビデオ制御レジスタは表示装置２４を制御する情報を格納する。
【００３４】
ビデオ・コントローラ２０と同様に、サーバ・コントローラ２６も拡張バス上のアドレスをデコードし、ビデオ・サブシステムへの書き込みを検出する。ビデオ・アドレス範囲への書き込みを検出した場合、サーバ・コントローラ２６は、ビデオ・アドレス範囲に書き込まれたデータを、サーバ・コントローラ２６内に記憶する。この動作のことを、「監視：スヌーピング：(snooping)」と呼ぶ。即ち、サーバ・コントローラ２６は、他のサブシステム（即ち、ビデオ・サブシステム２０、２２）に対しての表示データの１つ以上の画面を得る。データはサーバ・コントローラ２６上で複製され、サーバ・コントローラ２６が、ビデオ・メモリ２２のフレーム・バッファ内にある情報、およびビデオ・コントローラ２０のビデオ制御レジスタ内にある情報のミラー・コピー(mirror copy)を保持するようにする。拡張バスを監視してビデオ・アドレス範囲内のデジタル信号を発見することにより、ＣＰＵ１２が認めるビデオ・サブシステムへの書き込みは１回のみでも、二重記憶の実行が可能となる。重要なのは、監視は、サーバ・コントローラ２６によって割り込みを生じないように(non-intrusive)行われることである。ビデオ・サブシステムに対して供給されるべきデータは、ビデオ・サブシステムに進み、サーバ・コントローラ２６によって変更や削除をされることがない。
【００３５】
図４には、サーバ・コントローラ２６の詳細なブロック図が示されている。サーバ・コントローラ２６は、拡張バスに結合された検出ロジック３０を備えている。コントローラ・メモリ３２が、コントローラ・バスを介して、検出ロジック３０に結合されている。検出ロジック３０は、例えば、プログラマブル・アレイ・ロジック（「ＰＡＬ」）回路において一般的に見られるような、組み合わせられた連続的なロジック素子から成る。制御ロジック４０、アドレス・バッファ４２およびデータ・トランシーバ４４についての詳細は、それらの関係を論じた後に説明する。検出ロジック３０内のこれら３つのユニットは、サーバ・コントローラ２６の様々な構成要素、即ち、コントローラ・メモリ３２およびその中の様々なバッファの性能を最大に高めるためのものである。したがって、これら３つの要素４０、４２、４４の説明は、再生シーケンスの検討および様々なバッファがどのようにしてこれらのシーケンスを記憶するのかについての検討が終了してから、行うことにする。
【００３６】
サーバ・コントローラ２６の一部として、プロセッサ３４は、コントローラ・バス上の情報、即ち、検出ロジック３０およびコントローラ・メモリ３２間の情報、または通信ユニット３６およびコントローラ・メモリ３２間の情報のいずれかを編成しなければならない。プロセッサ３４は、命令セットに応答し、例えば、実行ユニット、メモリ、入出力装置、および１つ以上のレジスタを内蔵したマイクロプロセッサまたはマイクロコントローラを含む。プロセッサ３４は、埋め込みシステム(embedded system)の用途に用いられるマイクロプロセッサを代表するものである。コントローラ・メモリ３２は、複数のデジタル記憶素子から成る。本発明の一実施例では、コントローラ・メモリ３２は、疑似スタティックＲＡＭから成る。通信ユニット３６は、サーバ・コントローラ２６から離れて配置された遠隔端末２８に対して通信可能な装置を含む。通信ユニット３６は、遠隔端末２８から送られてくるアナログ呼び出し信号(ARGN:analog ring signal)に応答して、遠隔端末２８に返送する通信信号(COMM. SIG)を生成する。好ましくは、通信ユニット３６はモデムを備えている。通信ユニット３６は、更に、プロセッサ３４に結合された直列ポート、およびサーバ・コントローラ２６外部の直列ポートに結合され遠隔端末２８と通信するためのモデムも想定している。
【００３７】
プロセッサ３４は、再生シーケンスをコントローラ・メモリ３２に記憶する。プロセッサ３４は、再生シーケンスを、表示画面の集合全体を表わす連続表示データとして、コントローラ・メモリ３２内に記憶することも可能である。しかしながら、これは、コントローラ・メモリ３２を使用する方法としては比較的非効率的であり、したがって再生シーケンスを構成してコントローラ・メモリ３２内に記憶されるビデオ画面の数は比較的少ない。本発明では、プロセッサ３４は、一連の表示画面全体の代わりに、一連の表示「変化」として再生シーケンスを効率的に記憶するように表示データを処理する点で効果的である。画面内の変化を表わす表示データの量は、画面全体を表わす表示データ量より大幅に少ない。したがって、現リセット・シーケンス、前リセット・シーケンスおよび障害シーケンス（即ち、再生シーケンス）は、基準画面、即ち「開始」画面からの変化として表わされる。
【００３８】
図５には、コントローラ・メモリ３２内の種々のバッファが示されている。これらのバッファは、プロセッサ３４によって用いられて、再生シーケンスの処理や記憶を行うためのものである。ローカル・フレーム・バッファ４８は、ビデオ・メモリ２２へのライト・アクセスの間に監視された表示データを格納する。即ち、検出ロジック３０が拡張バスを監視し、ビデオ・サブシステムに向けて送られてくるデータを、ローカル・フレーム・バッファ４８に記憶する。スナップショット・バッファ５０は、ローカル・フレーム・バッファ４８からの現表示データの、プロセッサ３４によって作成された、コピー即ちスナップショットを格納する。一時スナップショット・バッファ５２も、ローカル・フレーム・バッファ４８からの現表示データのスナップショットを格納する。一時スナップショット・バッファ５２は、画面変化、特に画面のスクロールが素早く行われる場合に、再生シーケンスを見やすくするために用いられる。
【００３９】
現リセット・シーケンス・バッファ５４は、最新のリセット・シーケンスに関連する情報を格納する。即ち、現リセット・シーケンス・バッファ５４は、最新のリセットで始まり、現リセット・シーケンス・バッファ５４が満杯になると終了する画面変化を格納する。現リセット・シーケンス・バッファ５４が満杯になった後に発生する画面変化は無視される。前リセット・シーケンス・バッファ５６は、最新のリセット・シーケンスの直前のリセット・シーケンスに関連する情報を格納する。即ち、前リセット・シーケンス・バッファ５６は、最新のリセットに前に発生したリセット時に開始し、前リセット・シーケンス・バッファ５６が満杯になったとき、または次のリセットが発生したときに終了する画面変化を格納する。前リセット・シーケンス・バッファ５６が満杯になった後に発生した画面変化は無視される。
【００４０】
現シーケンス・バッファ５８は、最新の画面変化を、バッファ５８内に納まるだけ格納する。障害シーケンス・バッファ６０は、サーバ１０の最新のリセット直前の障害シーケンスに関連する情報を格納する。即ち、障害シーケンス・バッファ６０は、最新のリセットで終了する画面変化を格納し、最新のリセット直前に発生した画面変化を、その中に納まるだけ格納する。
【００４１】
障害開始バッファ６４は、障害シーケンス・バッファ６０に関連するビデオ画面表示の表示データを格納する。障害開始バッファ６４は、障害シーケンスにおける初期画面画像（即ち、「基準」画面画像）を格納し、結果的に、障害シーケンス・バッファ６０内の最初の変化が適用される画面画像を格納する。初期状態では、障害開始バッファ６４は空白画面である。障害シーケンス・バッファ６０がオーバーフローした場合、超過分の変化は文字および属性に変換され、障害開始バッファ６４に記憶される。したがって、障害開始バッファ６４は、比較的長い時間期間の間に画面上の少数の文字だけが何回も変化するような場合に、有用性が高い初期画面画像を提供する。現開始バッファ６２は、現シーケンス・バッファ５８に関して、同一の機能を提供する。
【００４２】
サーバ１０のリセットまたは障害は、サーバ・コントローラ２６のリセットの原因にならないものである。しかしながら、サーバ・コントローラ２６は、以下のリセット・イベントに関する情報を検出し保持する。即ち、サーバ１０の給電開始、サーバ１０の電力遮断、および拡張バスのリセットである。特に、サーバ・コントローラ２６は、RSTDRV EISAバス信号には応答せず、単にRSTDRVのアサートを検出するに過ぎない。リセットが発生した場合、または電力がサーバ１０から遮断された場合でも、サーバ・コントローラ２６は動作を維持し、遠隔端末２８上の表示のために、再生シーケンスを保存する。サーバ・コントローラ２６を収納する同一ＰＣＢ上に、二次電源が設けられており、再生シーケンスが維持されることを保証する。しかしながら、必要であれば、ＣＰＵ１２にアクセス可能なサーバ・コントローラ２６の所定のレジスタ位置に所定の一連の値を書き込むことによって、ソフトウエアの制御の下でサーバ・コントローラ２６をリセットすることも可能である。
【００４３】
サーバ１０のリセットが発生した場合、ポインタを変化させて、現リセット・シーケンス・バッファ５４が前リセット・シーケンス・リセット・バッファ５６になるようにし、更に前リセット・シーケンス・バッファ５６がフラッシュ（一掃）され、現リセット・シーケンス・バッファ５４になる。サーバのリセットによっても、現シーケンス・バッファ５８が障害シーケンス・バッファ６０になり、障害シーケンス・バッファ６０がフラッシュされ、現シーケンス・バッファ５８となる。また、リセット時にも、現開始バッファ６２は障害開始バッファ６４となり、障害開始バッファ６４はフラッシュされ、現開始バッファ６２となる。
サーバ・コントローラ２６は、サーバ１０の自動サーバ復元（「ＡＳＲ」）リセット(automatic server recovery reset)を実行するように構成されている。サーバ・コントローラ２６がサーバ１０の障害を検出した場合、所定の時間の間（典型的には、３０秒）待ってから、サーバ１０をリセットする。
【００４４】
以下に述べるのは、サーバ１０のリセット、それに続いて障害、更にそれに続いてリセットが発生する例示的なシーケンスである。最初にサーバ１０を起動し、サーバ１０をリセットする。リセット時に、サーバ・コントローラ２６は、前リセット・シーケンス・バッファ５６から情報をフラッシュし、障害シーケンス・バッファ６０をフラッシュし、更に障害開始バッファ６４をフラッシュする。バッファ５６、６０、６４をフラッシュする間、前リセット・シーケンス・バッファ５６と現リセット・シーケンス・バッファ５４との交換が、バッファ６０、５８間の交換およびバッファ６４、６２間の交換と同時に行われる。したがって、リセットにより、バッファ５４、５８、６２からそれぞれバッファ５６、６０、６４へ情報の移動が生ずる。リセット時に、サーバ１０のソフトウエアは、ＰＯＳＴ処理の実行、および表示装置２４上の文字表示を開始する。
【００４５】
サーバ・コントローラ２６は、ＰＯＳＴ処理に付随する画面変化を、現リセット・シーケンス・バッファ５４および現シーケンス・バッファ５８に記憶する。一旦現リセット・シーケンス・バッファ５４が満杯になったなら、サーバ・コントローラ２６は画面変化をそこに記憶するのを中止する。現シーケンス・バッファが満杯になった場合、サーバ・コントローラ２６は最も古い画面変化を現シーケンス・バッファ５８から除去し、新たな画面変化の記憶のための余裕を作り、現開始バッファ６２を修正して古い画面変化を記憶させる。このように、バッファ５８はＦＩＦＯレジスタと同様に動作し、超過した情報をバッファ６２に送出する。以下で説明するが、バッファ５８、６２の組み合わせ（バッファ６０、６４と交換された場合）は、最新の障害以前のビデオ画像の障害シーケンス全体を表わす。
【００４６】
リセット−障害−リセットの３段階の例における第２段階においてサーバ１０の障害が発生した場合、ビデオ画面のシーケンスが表示装置２４上に生成され、この障害、および可能であれば障害の理由を示す。これらの画面は、Novell NetwareからのABENDメッセージまたはMicrosoft NTのブルー・スクリーンとして使用可能な、多くのサーバ・オペレーティング・システムの一部として、自動的に表示される。障害が発生して３０秒後、サーバ・コントローラ２６はサーバ１０上でＡＳＲリセットを実行する。ＡＳＲリセットの間に、リセット−障害−リセット例における２回目のリセットが発生する。１回目のリセットと同様、このリセットによって、サーバ・コントローラ２６はバッファ５６、６０、６４をフラッシュする一方、バッファ５６，６０，６４のバッファ５４，５８，６２との交換をそれぞれ行うことができる。
【００４７】
また、１回目のリセットと同様、サーバ１０は再びＰＯＳＴ処理を起動し、文字を表示装置２４に送出する。サーバ・コントローラ２６は、ＰＯＳＴ処理の結果生じたリセットの後に発生した画面変化を、現リセット・シーケンス・バッファ５４および現シーケンス・バッファ５８に記憶する。前リセット・シーケンス・バッファ５６は、ここで、最初のパワー・オン・リセットに付随する一連の画面変化を格納し、障害シーケンス・バッファ６０および障害開始バッファ６４は、ここで、当該障害までに至る一連の画面変化を格納する。前リセット・シーケンス・バッファ５６内に格納されている初期リセットによる画面変化とは異なり、現リセット・シーケンス・バッファ５４は、２回目のリセット（即ちＡＳＲリセット）に関連するリセットによる画面変化を格納する。
【００４８】
ビデオ画面全体とは異なり、ビデオ画像の変化は、現リセット・シーケンス・バッファ５４、前リセット・シーケンス・バッファ５６、現シーケンス・バッファ５８および障害シーケンス・バッファ６０内には、パケットとして記憶される。バッファ５４、５６、５８、６０内の各パケットは、指定された長さの一連のバイトで構成される。パケットは「タイプ」にしたがって類別され、パケット・タイプは、その長さならびに最初のバイト（バイト０）、およびパケット長が１バイトより長い場合は２番目のバイト（バイト１）によって判定される。パケット・タイプ、および遠隔端末２８上のサーバ・コントローラ２６が各タイプに応じて行う作用は以下の表１の通りである。
【００４９】
【表１】
【００５０】
このリストに示す各パケット・タイプに用いた二進コード・フォーマットは、次の表２の通りである。
【００５１】
【表２】
【００５２】
表示文字列パケット・タイプにおけるバイト３、４、および後続バイトは、表示すべきヌルで終了する文字列を含む。この文字列は、少なくとも２文字にヌルの終端を加えた長さでなければならないので、その長さは５より大きい。したがって、長さ検査を用いて、繰り返し文字パケットから識別可能である。変化が１文字を含むのみである場合、その変化は繰り返し回数が１の繰り返し文字パケット、または単一文字パケットとして記憶する。
【００５３】
図５に示したコントローラ・メモリ３２内に位置する種々のバッファの機能は、図６および図７のフローチャートの説明において、より明白となろう。なお、図６および図７は、プロセッサ３４が、バッファ４８〜５２に送出される表示データを処理し、バッファ５４〜６４のいずれかに再生シーケンスを記憶する際に実行するステップを示すフローチャートである。
【００５４】
図６を参照すると、ステップ７０において、プロセッサ３４がローカル・フレーム・バッファ４８をチェックして、ビデオ制御レジスタを通じて、いずれかのビデオ・モード変化が起きているか否かについて検査を行う。ビデオ・モード変更の例は、グラフィックス・モードおよびテキスト・モード間の変更、または画面サイズの変更、即ち、表示装置の行数および列数の少なくとも一方の変更である。再生シーケンスの記憶が可能になる前に、プロセッサ３４は、ステップ７２において、現ビデオ・モードが有効なテキスト・モードであるか否かについて判定を行わなければならない。有効なテキスト・モードでない場合、プロセッサ３４は、ビデオ・モードが有効なテキスト・モードになるまで待ち、次いでプロセッサ３４は、ステップ７４において、ローカル・フレーム・バッファ４８からの現表示の集合（ビデオ制御レジスタ内に指定される開始アドレスによって示される）を、一時スナップショット・バッファ５２にコピーする。
次に、プロセッサ３４は、ステップ７６において、一時スナップショット・バッファ５２の内容を、スナップショット・バッファ５０の内容と比較して、画面スクロールが行われたか否かについて判定を行う。スクロールが行われていた場合、プロセッサ３４は、ステップ７８において、画面スクロール・パケットを適切なバッファに記憶する。
【００５５】
そして、プロセッサ３４は、スナップショット・バッファ５０および一時スナップショット・バッファ５２の先頭から開始して、それらを比較し変更するための一連のステップを開始することができる。プロセッサは、ステップ８０において、バッファ５０，５２の現バイトを比較し、変化を探す。ステップ８２に示すように、変化が発見された場合、プロセッサ３４はステップ８４において、その変化を用いて、スナップショット・バッファ５０を更新する。次に、プロセッサ３４は、ステップ８６において、この変化をパケットに変換する。ステップ８８において現バッファ５４、５８、６２に選択的に入力されるのは、パケットに変換された変化である。次に、プロセッサ３４はステップ８０に戻って他の変化を探し、ステップ８２において、プロセッサがバッファ５０、５２における表示データ間にもはや変化がないと判定するまで、ステップ８２、８４、８６、８８を繰り返す。
一旦プロセッサ３４が、ステップ８２においてもはや変化がないと判定したなら、プロセッサ３４は、ステップ９０において、カーソル位置が変化したか否かについて判定を行う。位置が変化していた場合、プロセッサ３４は、ステップ９２において、ステップ８８で実行したのと同様の方法で、移動カーソル・パケットを現バッファ５４、５８、６２に記憶する。カーソル位置が変化していない場合、既存のカーソル位置へのパケットのリライトを実施する。
【００５６】
次に図７を参照する。図７には、図６のステップ８８を実行する際に行われるステップの一層詳しいフローチャートが示されている。プロセッサ３４は、ステップ９４において、現リセット・シーケンス・バッファ５４が満杯か否かについて判定を行う。即ち、ステップ９４は、バッファ５４に送られたパケットにより当該バッファが満杯になったか否かを示す。バッファ５４が満杯でない場合、プロセッサ３４は、ステップ９６において、現パケットを現リセット・シーケンス・バッファ５４に送出する。ステップ９８において、現シーケンス・バッファ５８が満杯となりこれ以上パケットを受け入れることができないか否かを、プロセッサ３４が判定する。満杯の場合、プロセッサ３４は、ステップ１００において、最も古いパケットを現シーケンス・バッファ５８から除去し、その後、この最も古いパケットを文字／属性ワードに変換する。この除去されたパケットの文字／属性ワードは、次いでステップ１０２において、現開始バッファ６２に送出される。プロセッサ３４は、ステップ９８において、現シーケンス・バッファ５８はパケットを受け入れられない程満杯ではないと判定するまで、ステップ９８、１００、１０２を繰り返す。満杯ではないと判定した時点で、プロセッサ３４は、ステップ１０４において、パケットを現シーケンス・バッファ５８に入力する。
【００５７】
以下の表３及び表４（表４は表３の続き）に示すのは、Ｃ言語の関数find_change()のコードのフラグメント（断片）である。これは、プロセッサ３４が図６のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００５８】
【表３】
【表４】
【００５９】
以下に示すのは、Ｃ言語の関数put_packet()のコードの断片であり、プロセッサ３４が図７のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００６０】
【表５】
【００６１】
次に図８を参照する。図８には、プロセッサ３４が遠隔端末２８上にビデオ画面のリセット・シーケンスを再生する際に実行するステップを表わす、フローチャートが示されている。管理者はまず現リセット・シーケンスまたは前リセット・シーケンスは再生する必要があるか否かについて判定を行う。プロセッサ３４は、現リセット・シーケンス・バッファ５４または前リセット・シーケンス・バッファ５６を、それぞれ、再生すべきリセット・バッファとして選択することによって応答する。システム管理者がサーバ・コントローラ２６にリセット・シーケンスの一方を再生するように命令すると、プロセッサ３４は、ステップ１０６において、リセット・バッファには表示すべきパケットが未だあるか否かについて判定を行う。表示すべきパケットがある場合、プロセッサ３４は、ステップ１０８において、リセット・シーケンス・バッファから次のパケットを読み出し、当該パケットを文字列に変換する。次に、プロセッサ３４は、ステップ１１０において、この文字列を遠隔端末２８に送信することによって、文字列を遠隔端末２８上に表示する。プロセッサ３４がステップ１０６において表示すべきパケットがもはやないと判定するまで、プロセッサ３４はステップ１０６、１０８、１１０を繰り返す。
【００６２】
以下の表６に示すのは、Ｃ言語の関数video_reset_play()のコードの断片であり、プロセッサ３４が図８のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００６３】
【表６】
【００６４】
図９には、プロセッサが障害シーケンスを遠隔端末２８上に再生する際に実行するステップを表わす、フローチャートが示されている。システム管理者がサーバ・コントローラ２６に障害シーケンスを再生するように命令すると、プロセッサは、ステップ１１２において、障害バッファ６４内に表示すべき文字が未だあるか否かについて判定を行う。尚、現開始バッファ６２および障害開始バッファ６４は、画面自体ではなく、画面変化を記憶するバッファ（即ち、バッファ５４〜６０）内にあるパケットの代わりに、文字（即ち、文字／属性対から成るワード）を格納するものである。バッファ６４内に未だ表示すべき文字がある場合、プロセッサ３４は、ステップ１１４において、障害開始バッファ６４から次の文字を読み出し、その文字を遠隔端末２８に送信することによって、遠隔端末２８上にその文字を表示する。プロセッサがステップ１１２において障害開始バッファ６４内にはもはや表示すべき文字がないと判定するまで、プロセッサ３４はステップ１１２、１１４を繰り返す。尚、文字は障害開始バッファ６４から消去されるのではなく、文字のコピーが取られるようにしていることを注記しておく。
【００６５】
一旦プロセッサ３４がステップ１１２において障害開始バッファ６４における文字全てを表示したと判定したなら、プロセッサ３４は、ステップ１１６において、表示すべき別のパケットを障害シーケンス・バッファ６０内で検索する。別のパケットがない場合、プロセッサ３４は障害シーケンスの再生を終了する。その他の場合、プロセッサ３４は、ステップ１１８において、パケットをＡＮＳＩ文字列に変換する。次に、プロセッサ３４は、ステップ１２０において、その文字列を遠隔端末２８に送信することによって、その文字列を遠隔端末２８上に表示する。プロセッサ３４は、ステップ１１６において障害シーケンス・バッファ６０内のパケット全てを表示したと判定するまで、ステップ１１６、１１８、１２０を繰り返す。
【００６６】
以下の表７及び表８は、Ｃ言語の関数video_failure_play()のコードのフラグメントであり、プロセッサ３４が図９のフローチャートに示した機能を周期的に実行する際に使用可能である。なお、表８は表７の続きである。
【００６７】
【表７】
【表８】
【００６８】
再生シーケンスの再生は、管理者が図２のｃに示したメニューに応答して、スペース・キーを押圧したときに開始する。再生は、文字およびエスケープ・シーケンスのストリームを遠隔端末に送り、シーケンス・バッファ内の情報を表示することから成る。文字の中には制御文字があり（アスキー値で０〜３１および１２７）、実際の文字を表示するのではなく、ベルを鳴らす等の機能を行う。その結果、これら表示不可文字の１つがローカル・フレーム・バッファ４８内に現れた場合、実際にはスペースまたは同様に見える表示可能文字のいずれかとして遠隔端末に送られる。エスケープ・シーケンス（エスケープ文字（アスキー値0x1B)で始まる文字列）は、カーソルの移動、画面のクリア、および現表示カラーの変更というような他の作用を行うために用いられる。サーバ・コントローラ２６は、文字０〜３１、１２７、２２５以外の全ての文字を変化させずに送信する。これらの文字は、以下の表８に示すように、アスキー・バイトにリマップされる。
【００６９】
【表９】
【００７０】
以下に示すのは、サーバ・コントローラ２６によって送出されるエスケープ・シーケンスであり、ここで＼x1BがＥＳＣ文字である。Compaq Insight Manager (CIM)アプリケーションを遠隔端末２８上で実行している場合、サーバ・コントローラ２６は所定の標準外エスケープ・シーケンスを送信し、ＣＩＭと通信を行う。これらの標準外エスケープ・シーケンスは、以下の表９において、アステリスクで示すことにする。
【００７１】
【表１０】
【００７２】
上記表１０において、「＋」文字が印されているエスケープ・シーケンスは、白黒モードにおいて用いられるカラー・エスケープ・シーケンスのみである。黒および高輝度の黒を除く全てのカラーは、白または高輝度の白に変換される。
【００７３】
サーバ・コントローラ２６がＣＩＭと通信していないとき、高輝度背景カラーは対応外となり、通常の輝度と同一のカラーとして送られる。前景がこの通常輝度のカラーである場合、以下の表１０にしたがって未だ見ることができるように、前景カラーのリマッピングを行う。
【００７４】
【表１１】
【００７５】
次に図１０のａ〜ｅを参照する。障害シーケンスの画面ショット(screen shot)の例が示されている。画面シーケンスは、遠隔端末２８上にサーバ・コントローラ２６によって表示された再生シーケンスの例である。図１０のａは、サーバ起動時の典型的な初期画面の画面ショットである。この画面は、システム・コンフィギュレーションに関する様々な項目を示す。図１０のｂは、典型的なWINDOWS NTのローダ画面の画面ショットである。ユーザには、複数のブートするNTカーネル間から選択する機会が与えられる。図１０のｃは典型的なNTのブート画面の画面ショットである。このスクリーンは、カーネルの構築バージョン、システム・メモリ量、プロセッサのコンフィギュレーション等を含む。図１０のｄは、サーバ１０の表示装置２４がホストＣＰＵ１２によってグラフィック・モードに設定されたことを示すパケットを再生シーケンスが含むときに、この再生シーケンスの間に、サーバ・コントローラ２６によって遠隔端末２８上に表示されたメッセージを示す。図１０のｅは、典型的なNTのブルー・スクリーンの画面ショットである。
【００７６】
拡張バス（好ましくは、ＥＩＳＡバス）を監視してビデオ・サブシステムへの書き込みを見つけ出すことによって、サーバ・コントローラ２６は、リアル・タイムでビデオ・データの更新を得て、再生シーケンスの再生を実現可能にする。加えて、拡張バスを監視してビデオ・サブシステムへの書き込みを見つけ出すことによって、サーバ・コントローラ２６は、サーバ１０には割り込みをかけない(non-intrusive)方法で、より具体的には、拡張バス帯域には割り込みをかけずに、ビデオ・データの更新を得ることができる。他の方策には、割り込みをかけ非リアル・タイムでビデオ・データを得るものもある。例えば、COMPAQ Server Manager/R （「ＳＭＲ」）という製品は、ＥＩＳＡバス・サイクルの主導権(mastership)をアサートし、サーバ１０のビデオ・メモリ２２内のデータを得る。ＳＭＲは、こうすることにより、表示データの一部をビデオ・メモリ２２からそれ自体のメモリに周期的にコピーする。コピーされたデータは、次に、ビデオ・データの以前のコピーと比較され、画面変化が判定される。ＳＭＲのバス支配法は、ＥＩＳＡバス上のトラフィック増大を招くという欠点があり、他のＥＩＳＡバス・マスタに、余分なバス仲裁遅延を付加することになる。
【００７７】
再び図４を参照しながら、検出ロジック３０内の様々なブロック４０〜４４についての説明を行う。検出ロジック３０は、アドレス・バッファ４２、データ・トランシーバ４４、ならびにＥＩＳＡバスおよびコントローラ・バス間に結合された制御ロジック４０から成る。制御ロジック４０およびプロセッサ３４は、HOLDおよびHLDA（HOLD承認）信号によって結合されている。アドレス・バッファ４２、データ・トランシーバ４４、および制御ロジック４０は協同して表示データを監視し、その後、コントローラ・メモリ３２の一部を形成するローカル・フレーム・バッファ４８（図５）にデータを書き込む。
【００７８】
コントローラ・メモリ３２は、プロセッサ３４および検出ロジック３０の双方がコントローラ・メモリ３２を変更するという点において、プロセッサ３４および検出ロジック３０間で共有されるリソースである。コントローラ・メモリ３２は、単一ポートの疑似スタティックＲＡＭから成る。したがって、検出ロジック３０は、プロセッサ３４からサイクルを盗み、コントローラ・メモリ３２にビデオ・データを書き込む。ライト・サイクルがビデオ・サブシステムに発生すると、検出ロジック３０はライト・サイクルをデコードし、プロセッサ３４をオンに維持し、ビデオ・データをコントローラ・メモリ３２に書き込む。サーバ・コントローラ２６は、ビデオ・データをビデオ・サブシステムに書き込むと同時に、ビデオ・データをコントローラ・メモリ３２に書き込み、サーバ１０上での通常のビデオ・アクティビティを持続させる利点がある。
【００７９】
制御ロジック４０は、拡張バスからアドレス信号を受け取り、ビデオ・アドレス範囲にあるアドレスの存在をデコードする。ビデオ・アドレス範囲内のアドレスが拡張バス・アドレス信号上に現れた場合、制御ロジック４０は、プロセッサ３４へのHOLD信号をアサートすることによって、プロセッサ３４をオンに保持し、コントローラ・メモリ３２に対するアービトレーション（仲裁）を行う。プロセッサ３４はHLDAをアサートし、コントローラ・バスの所有権を制御ロジック４０に与える。
【００８０】
制御ロジック４０は、ビデオ・サブシステムへのライト・サイクル完了の前に、コントローラ・バスの所有権を得ることができ、かつ、コントローラ・メモリ３２にビデオ・データを書き込めることを、保証しなければならない。これを行うために、制御ロジック４０は、ＥＩＳＡ拡張バス内の所定の信号を利用する。制御ロジック４０は、ＥＩＳＡ拡張バスにおいて得ることができるEXRDY信号を利用する。拡張バスがＩＳＡバスである場合、制御ロジック４０はCHRDY信号を利用する。いずれの場合でも、EXRDYまたはCHRDYは、制御ロジック４０がコントローラ・バスの所有権を得るまで、ビデオ・サブシステムへの拡張バスのライト・サイクルを遅らせるように機能する。
【００８１】
拡張バスのSTART#信号がアサートしている間に、ＥＩＳＡ拡張バス（拡張バス）のBCLK信号の立ち上がりエッジ上において、制御ロジック４０は拡張バスのアドレス信号からアドレスをラッチする。制御ロジック４０は、拡張バス上の他の信号、即ち、BCLK、START、およびW_Rを検査し、バス・サイクルがライト・サイクルか否かについて判定を行う。バス・サイクルがライト・サイクルでない場合、制御ロジック４０は、HOLD信号をディアサートすることにより、コントローラ・バスに対する仲裁を中止する。バス・サイクルがライト・サイクルである場合、データ・トランシーバ４４が、ビデオ・データを拡張バスのデータ信号からコントローラ・メモリ３２に送り込むことによって、拡張バスのCMD#信号の立ち上がりエッジ上でライト・サイクルを完了する。制御ロジック４０がEXRDY信号をローに駆動すると、CDM#の立ち上がりエッジは遅れを生じる。
【００８２】
仲裁レイテンシ（制御ロジック４０がHOLDをアサートし、プロセッサ３４がHLDAを付与するまでの時間）が、ビデオ・アドレス範囲にライト・サイクルを設定するのに必要な時間を超過する場合、制御ロジック４０は拡張バス上のEXRDY信号をローに駆動し、遅延サイクルを挿入する。即ち、CMD#の立ち上がりエッジを遅らせる。EXRDY信号がローに駆動されると、現在ライト・サイクルを実行中の拡張バスのマスタに、ライト・サイクルの受け取り側がデータを受け取る準備ができていないことを示す。典型的に、プロセッサ３４は、HLDAを制御ロジック４０に十分早く付与し、制御ロジック４０がEXRDYをアサートする必要がないようにしている。したがって、サーバ・コントローラ２６の監視は、典型的に、非割り込みである。
【００８３】
制御ロジック４０は、以前に拡張バスのアドレス信号からラッチしたアドレスを、コントローラ・メモリ３２のローカル・フレーム・バッファ内の対応する位置に変換し、更に変換したアドレスをアドレス・バッファ４２に供給し、このアドレス・バッファ４２がコントローラ・バス上に変換したアドレスを送り込む。次に、制御ロジック４０は、制御信号をデータ・トランシーバ４４、アドレス・バッファ４２およびコントローラ・バスに対して発生し、コントローラ・メモリ３２の、アドレス・バッファ４２によって駆動された変換後のアドレスに、拡張バスのデータ信号からの表示データを書き込む。制御ロジック４０は、表示データのブロック転送終了まで、即ち、ビデオ・サブシステムへのバーストまたは連続(back-to-back)ライト・サイクルの間、プロセッサ３４をオンのまま保持する。ビデオ・サブシステムへのバースト・ライト・サイクルまたは連続ライト・サイクルの場合、割り込みの可能性がある（遅延サイクルを誘発する）のは最初のサイクルだけである。
【００８４】
拡張バスからコントローラ・メモリ３２へのビデオ・サブシステムに対するライト・サイクルを監視する際、拡張バスおよびコントローラ・バスが異なるクロック信号を有するので、これらのバス間で同期を取る必要がある。このためには、正確な通信状態を保証するために（即ち、不安定の可能性を低下させるために）、双方のバスから多数の同期点を必要とする。したがって、有効なライト・サイクルが開始する最も早い時点、および当該ライト・サイクルまたは一連のライト・サイクルが終了する最も早い時点を判定することは有利である。したがって、有効なサイクルがライト・サイクルでないことを最も早い時点で判定してHOLDをニゲートし、コントローラ・バスの所有権をプロセッサ３４に返すことが必要である。これによって、プロセッサ３４は、再生シーケンスの実行のような、必要な機能の実行が可能となる。加えて、いつ有効ライト・サイクルが開始するのかを判定し、必要であれば、EXRDYをローに駆動し、これによって遅延サイクルを挿入することも有利である。
【００８５】
拡張バスのクロック信号BCLKは、ライト・サイクルの開始や終了を判定する際には、特に有用ではない。何故なら、このクロック信号はそのいずれとも、即ち、START#の立ち下がりエッジまたはCMD#の立ち上がりエッジのいずれとも同期することが保証されていないからである。ＥＩＳＡバスのタイミング仕様に関する詳細な説明について、ＥＩＳＡ仕様改訂３．１２版(EISA Specification Revision 3.12)を引用する。この内容は、この言及により、本願にも含まれているものとする。
【００８６】
拡張バスのライト／リード信号(W_R)がライト・サイクルを示している場合は、該信号は、拡張バスのアドレス信号(LA)と同じように早くは有効にはならない。ＥＩＳＡバスの仕様によれば、W_Rは、START#がニゲート状態にあるときのBCLKの立ち上がりエッジまで、その有効性を確認することができない。制御ロジック４０は、ライト・サイクルが発生しているか否かについて判定を行い、それ自体はリード・サイクルに応答しないが、代わりにビデオ・サブシステムがリード・サイクルに応答できるようにしなければならない。
【００８７】
ＥＩＳＡ拡張バス信号START#およびCMD#は、START#のニゲートおよびCMD#のアサートに関して、互いに連続して発生することは保証されていない。即ち、これらの２信号は重なり合ったり、その間にギャップが生じる可能性がある。このため、START#の立ち下がりエッジをサイクルの開始を示すために用い、CMD#の立ち上がりエッジをサイクルの終了を示すために用いるために、開始から終了までのサイクル全体を示すことを望む式(equation)は、START#のニゲートとCMD#のアサートとの間の潜在的なギャップを覆うために、何らかの入力を有さなければならない。
【００８８】
例えば、ＥＩＳＡバス・ブリッジとしてバス・インターフェース・ユニット１８を用いた、殆どのバス・インターフェースの実施においては、BCLKがローでSTART#がアサートされてローになると、W_Rは有効になることが本発明者によって規定された。この情報は、有効なライト・サイクルの開始および終了を判定する際に役に立つ。尚、本発明は、次の式で表わされる、透明ラッチ制御信号(transparent latch control signal) N_STARTを採用する。
【００８９】
【数１】
N_START = !BCLK * !START# + N_START * CMD#
したがって、N_STARTは、BCLKがローでSTART#がアサートされたときにアサートされ、CMD#がアサートされてローとなるまでアサートされたまま留まり、前述のSTART#およびCMD#間のギャップを覆うことになる。
【００９０】
ＥＩＳＡ拡張バスのアドレス信号がビデオ・アドレス範囲にあるときに真となる、追加の信号EARLY_DECODEを定義する。
EARLY_DECODE，W_R、CMD#およびN_STARTを組み合わせることにより、有効なライト・サイクルは次のように定義される。
【００９１】
【数２】
VALID_CYCLEを用いると、EXRDYは、VALID_CYCLEがアサートされ、プロセッサ３４が未だHLDAをアサートしていないときにアサートされる。次いで、EXRDYは、HLDAが付与されるBCLKの次の立ち下がりエッジまで、アサートされたまま維持される。
【００９２】
このように、制御ロジック４０はN_STARTを用いて、EXRDYに対するＥＩＳＡのタイミング要件を満足し、したがって典型的な状況では割り込みを発生させない、即ち、ビデオ・サブシステムに対する処理では遅延サイクルを導入させないという利点がある。また、ＥＩＳＡ拡張バスおよびコントローラ・バスはクロック信号が異なるので、制御ロジック４０は、N_STARTを用いて、ＥＩＳＡ拡張バスおよびコントローラ・バス間の同期を取る。N_STARTを用いることによって（即ち、BCLKがローの期間）、制御ロジック４０は、有効なライト・サイクルを判定する際に、START#の立ち上がりエッジ（少なくとも６０ナノ秒遅く発生する。即ち、BCLKの立ち上がりエッジと同期して発生する）を用いる場合よりも、同期時間において少なくとも６０ナノ秒の優位を享受するという利点がある。
【００９３】
図１１のタイミング図は、ＥＩＳＡ拡張バス信号BCLK、START#、CMD#、LA、W_RのEARLY_DECODE、HOLD、N_START、VALID_CYCLE、およびEXRDY信号に対する関係を示している。図１１が示すビデオ・ライト・サイクルは、プロセッサ３４がHLDAを十分に早く付与しないため、制御ロジック４０がEXRDYをローに駆動し、第２のビデオ・ライト・サイクルに続いて遅延サイクルを挿入しなければならない場合である。第１および第２のビデオ・ライト・サイクルは、連続ビデオ・ライト・サイクルを構成する。本発明によれば、第２のビデオ・ライト・サイクルは、第１のライト・サイクルが遅延サイクルを誘発しても、遅延サイクルを誘発しないという利点がある。BCLKのエッジには１〜１４まで連続的に付番してあり、図１１の説明の明確化を図っている。図１１に示すHLDA信号は、プロセッサ３４からのHLDA信号を、ＥＩＳＡ拡張バスのクロックBCLKと同期させたものである。
【００９４】
ＥＩＳＡバス・インターフェース１８は、ビデオ・サブシステムに書き込みを行いたいＣＰＵ１２の代わりに、BCLKの立ち下がりエッジ２付近で、LA信号上にビデオ・アドレス範囲のアドレスを発生する。制御ロジック４０は、これに応答して、EARLY_DECODE信号をアサートする。その後すぐに、制御ロジック４０はプロセッサ３４へのHOLDをアサートする。HOLD信号がアサートされるのは、EARLY_DECODE信号がアサートされるときであり、VALID_CYCLE信号がアサートされ続ける限りHOLD信号もアサートされたままでいる。VALID_CYCLEの間中、HOLDをアサートさせ続けることによって、制御ロジック４０は、コントローラ・メモリ３２へのビデオ・データの書き込みが完了するまで、コントローラ・バスの所有権を保持する。加えて、HOLD信号は、EARLY_DECODEがアサートされ、無効タイマ(defeat timer)が終了していない場合にも（以下で論ずる）、アサートされる。HOLD信号はプロセッサ３４のクロックと同期している。BCLKの立ち上がりエッジ３で、バス・インターフェース１８はSTART#（アクティブ・ローの信号）をアサートし、このサイクルのアドレス・フェーズを開始する。バス・インターフェース１８はW_R信号をアサートし、ライト・サイクルであることを示す。
【００９５】
BCLKの立ち下がりエッジ４において、BCLKがローとなり、START#がアサートされてローとなるので、これに応答して制御ロジック４０はN_STARTをアサートする。N_STARTは、BCLKの立ち上がりエッジ５でCMD#がアサートされてローになるまで、アサートされたままでいる。アクティブなN_STARTは、W_Rが有効であることを意味し、W_Rはライト・サイクルを示し、EARLY_DECODEはビデオ・アドレス範囲内のアドレスを示すので、制御ロジック４０は対応してVALID_CYCLEをアサートする。BCLKの立ち下がりエッジ４の後にアサートされたVALID_CYCLEに応答して、（本例では）HLDAが未だ付与されていないので、制御ロジック４０はEXRDYをローに駆動する。本例では、HLDAが付与されるのは、BLCKの立ち上がりエッジ５付近である。制御ロジック４０は、HLDAが付与されるBCLKの次の立ち下がりエッジ、即ち、BCLKの立ち下がりエッジ６の後まで、EXRDYをローに駆動し続ける。何故なら、EXRDYはBCLKの立ち下がりエッジ上でバス・インターフェース・ユニット１８によってサンプリングされ、一方、CMD#はアサートされてローとなるからである。
【００９６】
バス・インターフェース・ユニット１８は、BCLKの立ち上がりエッジ５の後、CMD#をアサートしてローとし、START#をディアサートしてハイとして、ライト・サイクルのデータ・フェーズを開始する。先に注記したように、ここでは、START#の立ち上がりエッジおよびDMD#の立ち下がりエッジは、ＥＩＳＡ拡張バスの仕様によれば、間隔が開くかあるいは重なり合う可能性がある。前述のように、N_STARTはこのギャップを覆うことにより、VALID_CYCLEが有効なビデオ・ライト・サイクルを最初から最後まで示すことができるという利点がある。
CMD#がアサートされてローとなっている間のBLCKの立ち下がりエッジ、即ち、BCLKの立ち下がりエッジ６でローに駆動されたEXRDYに応答して、バス・インターフェース・ユニット１８は、BCLKの立ち上がりエッジ９で１クロック・サイクル余計にCMD#のディアサート（ハイ）を遅らせることによって、余分なBCLKサイクルを待つ、即ち、遅延サイクル（または待機サイクル）を挿入する。CDM#をディアサートしてハイとすることによって、ライト・サイクルの終了を示す。
【００９７】
LA信号上のアドレスは、第２のライト・サイクルの間ビデオ範囲にあり続けるので、制御ロジック４０はEARLY_DECODEをアサートし続け、対応してHOLDもアサートし続けることにより、アサートされたHLDAによって表わされるように、第２のバス・サイクルの終了時までコントローラ・バスの所有権を保持する。
BCLKの立ち上がりエッジ９の後、バス・インターフェース・ユニット１８は（ＥＩＳＡブリッジングを用いて）START#をアサートし、第２のビデオ・ライト・サイクルのアドレス・フェーズの開始を表わす。第２のライト・サイクルは、第１のライト・サイクルと同様であるが、制御ロジック４０が既にコントローラ・バスの所有権を有しているので、EXRDYは第２のライト・サイクルの間、ニゲートされない（ローにならない）点で相違する。したがって、バス・インターフェース・ユニット１８は、BLCKの立ち上がりエッジ１３付近で（即ち、第１のライト・サイクルにおけるよりも１クロック・サイクル分早く）CMD#をディアサートしてハイとし、第２のライト・サイクルのデータ・フェーズを終了する。
また、第２のビデオ・ライト・サイクルは、連続ビデオ・ライト・サイクルではないことも表しており、このサイクルでは、制御ロジック４０がEXRDYをローに駆動して遅延サイクルを挿入する必要がないように、HLDAを十分に早く付与するようにしている。
【００９８】
本発明の一実施例では、サーバ・コントローラ２６は、ビデオ・コントローラ２０とビデオ・メモリ２２から成る、サーバ１０のビデオ・サブシステムに類似したコントローラ・ビデオ・サブシステム（図示せず）を更に備えている。コントローラ・ビデオ・サブシステムは、システム・コンフィギュレーション・ソフトウエアによって選択的にディゼーブルすることができる。コントローラ・ビデオ・サブシステムはＩＳＡ装置である。コントローラ・ビデオ・サブシステムをイネーブルすると、サーバ・コントローラ２６は、ＥＩＳＡ拡張バスのEXRDY信号ではなく、ＩＳＡバスの信号CHRDYをニゲートする。
【００９９】
コントローラ・ビデオ・サブシステムの目的は、サーバ１０上のＶＧＡコントローラがＰＣＩ ＶＧＡコントローラである場合、ビデオ・データの書き込み動作が拡張バス上に現れるようにすることである。これがないと、ＰＣＩ ＶＧＡコントローラがビデオ・ライトをデコードしこれに応答するので、バス・インターフェース・ユニット１８にビデオ・ライトをＥＩＳＡ拡張バスに送出させないようになる。その結果、ＥＩＳＡ拡張バス上にはビデオ・ライト・サイクルがなくなる。即ち、サーバ・コントローラ２６が監視するビデオ・ライト・サイクルがなくなってしまう。したがって、ＰＣＩ ＶＧＡコントローラがシステム内にある場合、ユーザはサーバ・コントローラ２６上のコントローラ・ビデオ・サブシステムをイネーブルし、ＰＣＩ ＶＧＡコントローラをディゼーブルすることにより、ビデオ・ライト・サイクルの監視および再生シーケンスの捕獲ができるようにしなければならない。
【０１００】
バス・インターフェース・ユニット１８（即ち、ＥＩＳＡバス・ブリッジ）の実現においては、拡張バスのアドレス信号上のアドレスを駆動し、拡張バス（即ち、ＥＩＳＡバス）上の当該アドレスをラッチし駆動して、有効なサイクルの終了時に、当該有効サイクルの後に発生するアイドル・サイクルの間、アドレス信号が浮動しないようにすることは一般的である。この状態では、制御ロジック４０にEARLY_DECODE信号をアサートさせ、結果的に、比較的長い時間にわたってプロセッサ３４へのHOLDを連続的にアサートさせる。その結果、プロセッサ３４は不必要に飢える(starved)ことになる。この問題に対する１つの解決策は、CMD#の立ち上がりエッジ上で、サイクルの終了時にHOLDをニゲートすることであろう。しかしながら、その結果、制御ロジック４０は、EXRDYをニゲートして遅れを導入することにより、１ブロックの連続ライト・サイクルの各ライト・サイクル毎に、制御バスの仲裁を再度行い、ＥＩＳＡ拡張バスおよびコントローラ・バス間で再度同期をとらなければならない。
【０１０１】
本発明は、無効タイマを用いて、上述の問題を解決する。制御ロジック４０は、ＥＩＳＡ拡張バスのアドレス信号が未だビデオ・アドレス範囲内のアドレスを有する場合、サイクルの後に所定数のBCLKを計数するカウンタを備えている。START#がアサートされることなく、カウンタが終了カウントに到達した場合、制御ロジック４０はHOLDをニゲートし、制御ロジック４０がビデオ・アドレス範囲内のアドレスをデコードすることによる次のSTART#のアサートまで、HOLDをアサートしない。
【０１０２】
このように、無効タイマを用いることにより、制御ロジック４０は、制御ロジック４０がSTART#のアサートまで待ってHOLDをアサートする場合に可能となるよりも早く、HOLDをアサートし、ビデオ・サブシステムへのビデオ・データの書き込みの間に遅延サイクルを導入しなくても済む可能性が高くなるという利点がある。更に、無効タイマは、制御ロジック４０をイネーブルし、１ブロックの連続有効ビデオ・ライト・サイクルの間、HOLDをアサート状態に保持することにより、ビデオ・サブシステムへのビデオ・データの書き込みの間、サーバ１０に遅延サイクルを導入するのを回避するという利点もある。
【０１０３】
遠隔端末２８は、通信ユニット３６を介して、サーバ・コントローラ２６との通信接続を確立する。遠隔端末２８およびサーバ・コントローラ２６間の接続は、一般的に、帯域外接続(out-of-band connection)または非同期接続と呼ばれている。帯域外接続とは、ローカル・エリア・ネットワーク・イーサネット接続のような標準的なネットワーク媒体を通じてではなく、電話線または直接直列接続を介して確立されるネットワーク接続のことである。帯域外接続を設けることにより、サーバ・コントローラ２６は、サーバ１０が通常に機能している場合、またはオペレーティング・システムのクラッシュや、サーバ１０が接続されているローカル・エリア・ネットワーク上の障害のような障害が発生した場合のいずれの場合にも、遠隔端末２８との通信を確立することができる。
【０１０４】
第１のモードでは、遠隔端末２８は、ＡＮＳＩの端末エミュレーション・プロトコルを用いて、サーバ・コントローラ２６との接続を確立する。このプロトコルのことを以降テキスト・プロトコルと呼ぶことにする。第２のモードでは、遠隔端末２８は、サーバ・コントローラ２６と二地点間プロトコル（ＰＰＰ：point-to-point protocol）を確立する。ＰＰＰについては、Internet Engineering Task Force (「IETF」）に記載されている。そのUniform Resource Locator（「ＵＲＬ」）は、http://www.ietf.cnri.reston.va.us/home.htmlである。特に、ＲＦＣ１６６１、１６６２、１６６３は本発明に関連があり、この言及により本願にも含まれているものとする。遠隔端末２８がサーバ・コントローラ２６を呼び出すと、サーバ・コントローラ２６のプロセッサ３４上で実行するサーバ・コントローラ２６のソフトウエアは、２つのデータ・リンク・レイヤ・プロトコルの内どちらを、遠隔端末２８が使用しているのかを自動的に判定するという利点がある。
【０１０５】
第１のモードでは、サーバ・コントローラ・コンソール・アプリケーションと呼ばれる、サーバ・コントローラ２６のソフトウエアの一部が、テキスト・プロトコルを用いて、遠隔端末２８と通信する。サーバ・コントローラ・コンソール・アプリケーションは、遠隔端末２８が、再生シーケンスの閲覧(viewing)のようなサーバ・コントローラ２６の様々な構成にアクセスできるようにする。加えて、サーバ・コントローラ・コンソール・アプリケーションは、、遠隔リセットの実行、警報およびログイン情報の管理、遠隔地からのコンソールへのアクセス、サーバ１０のイベント・ログ、エラー・ログおよびステータス・ログの閲覧を、システム管理者に可能とする。図２のａ〜ｃを再び参照すると、サーバ・コントローラ・コンソール・アプリケーションの３種類のメニュー画面が示されている。遠隔端末２８は、通常、コンピュータであり、既知の製品であるSYMANTEC pcANYWHEREまたはDATASTORM TECHNOLOGY ProComm のような、種々の販売会社から入手可能な一般的なＡＮＳＩの端末エミュレーション・ソフトウエア・アプリケーションを実行することによって、サーバ・コントローラ２６と通信を行う。
【０１０６】
第２のモードでは、遠隔端末２８は、ローカル・エリア・ネットワーク（ＬＡＮ）のそれと同様のＰＰＰ接続を通じて、サーバ・コントローラ２６とのＴＣＰ／ＩＰリンクを確立する。遠隔端末２８はCOMPAQ Insight Manager (CIM)を実行し、ＴＣＰ／ＩＰ接続を通じてサーバ・コントローラ２６との通信を行う。サーバ・コントローラ２６は、２つの方法で、ＣＩＭと通信を行う。すなわち、第１に、サーバ・コントローラ２６は、TELNET接続を通じてＣＩＭと通信を行い、テキスト・プロトコルを用いる第１モードと全く同様に、サーバ・コントローラ・コンソール・アプリケーションを実行する。
【０１０７】
第２に、サーバ・コントローラ２６は、サーバ１０を管理する目的のために、ＣＩＭに対して、SNMPパケットの送受信を行う。例えば、サーバ１０はサーバ１０上の障害またはその他のイベントを検出し、SNMPトラップ・パケットを、サーバ・コントローラ２６を通じて、遠隔端末２８上で実行中のＣＩＭに送り、サーバ１０が接続されているＬＡＮ上のクライアント上でＣＩＭが実行されているかのように、システム管理者にそのイベントについて通知する。加えて、サーバ１０の障害の場合、サーバ・コントローラ２６はその障害を検出し、SNMPトラップ・パケットをＣＩＭに自動的に送る。この第２のモード、即ち、ＰＰＰ接続によるモードでは、サーバ・コントローラ２６は、同時に、サーバ・コントローラ・コンソール・アプリケーションおよびSNMPパケットによって、遠隔端末２８と通信を行うこともできる。
【０１０８】
ＣＩＭによるサーバ１０の管理の別の例は、遠隔端末２８がサーバ・コントローラ２６を通じて「要求獲得」SNMPパケットをサーバ１０に送り、サーバのサブシステムの１つの状態(health)のような、サーバに関する管理情報を要求することである。サーバ・コントローラ２６はSNMPパケットをオペレーティング・システムに送出する。オペレーティング・システムは、要求された情報を集め、「応答獲得」パケットをサーバ・コントローラ２６に送る。一方、サーバ・コントローラ２６はパケットをＣＩＭに送出する。
【０１０９】
WINDOWS NTのRemote Access Services （ＲＡＳ）は、ＰＰＰ接続を確立し、ヌル・モデム(null-modem)によって接続された２台のコンピュータ間の通信を提供する。ＮＴ ＲＡＳはこのＰＰＰ接続を確立する、所有権を主張する方法(proprietary method)を用いる。この方法のことを以降「予備ＰＰＰプロトコル」(pre-PPP protocol)と呼ぶことにする。これは２台のコンピュータ間で１対の文字列を交換するためのものである。接続を確立したい第１のコンピュータが、文字列"CLIENT"を第２のコンピュータに送る。次に、第２のコンピュータは、"CLIENT"文字列を受け取った後、文字列"CLIENTSERVER"を第１のコンピュータに送る。一旦この２つの文字列の交換が行われたなら、２台のコンピュータは必要な文字パケットの交換に進み、ＰＰＰ接続を確立する。標準的なＰＰＰ接続では、この２つの文字列の初期交換は必要でない。サーバ・コントローラ２６は、ヌル・モデムを通じたＮＴ ＲＡＳとのＰＰＰ接続、および標準的なＰＰＰプロトコルを用いた遠隔端末２８とのＰＰＰ接続の双方を確立することができる。
【０１１０】
次に図１２を参照すると、サーバ・コントローラ２６がどの通信プロトコルが遠隔端末２８から送られているのかをどのようにして検出するのかを示すフローチャートが示されている。遠隔端末２８が接続を確立する前に、サーバ・コントローラ２６のソフトウエアは、ステップ１３０において、サーバ・コントローラ２６のソフトウエアの中にある３つの状態マシンをリセットする。テキスト・プロトコル、ＰＰＰプロトコル、および予備ＰＰＰプロトコルという有効なプロトコル各々に１つの状態マシンが存在する。
【０１１１】
サーバ・コントローラ２６が通信ユニット３６からの割り込みを待っている間、プロセッサ３４は再生シーケンスを処理することができる。キャリア信号がサーバ・コントローラ２６上で受信されたとき、コントローラ２６内のソフトウエアは、ステップ１３４において、状態マシンをリセットし、ステップ１３６においてタイマを設定する。一実施例では、タイマは３０秒後に終了するように設定される。サーバ・コントローラ２６のソフトウエアは、ステップ１３８において、タイマが終了したか否かについて判定を行う。タイマが終了していた場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４０において、サーバ・コントローラ２６内の上位タスクに、プロトコルはテキスト・プロトコルであると伝達することによって、プロトコルがテキスト・プロトコルであることを宣言する。
【０１１２】
遠隔端末２８から文字または信号を受信する前に、サーバ・コントローラ２６内のソフトウエアはビデオ画面変化を処理することができる。一旦割り込みが発生し、文字または信号の存在が示されたなら、サーバ・コントローラ２６のソフトウエアは、ステップ１４２において、「無キャリア」信号が通信ユニット３６から送られて、遠隔端末２８からキャリアの損失が示されたか否かについて判定を行う。キャリアが失われていた場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４４において、タイマをクリアし、ステップ１３０に戻る。
【０１１３】
ステップ１４２において「無キャリア」信号が受信されなかった場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４６において、文字が受信されたか否かについて判定を行う。受信されていない場合、サーバ・コントローラ２６のソフトウエアはステップ１３８に戻り、タイマが終了するのを待つか、あるいは信号または文字が到達したことを示す割り込みが受信されるのを待つ。
【０１１４】
ステップ１４６において文字が受信された場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４８において、その文字を３つのプロトコルの状態マシンに渡す。ステップ１５０において、状態マシンに有効なプロトコルを検出したものがない場合、サーバ・コントローラ２６のソフトウエアはステップ１３８に戻る。ステップ１５０において、状態マシンの内の１つが有効なプロトコルを検出した場合、サーバ・コントローラ２６のソフトウエアはステップ１５２においてタイマをクリアし、次にステップ１５４において、３つのプロトコルの内どれが検出されたのかを上位タスクに宣言する。
【０１１５】
プロセッサ３４は、図１１の説明において述べた通信ユニット３６のような種々の割り込みソースからの割り込みを受け取るように構成されている。プロセッサ３４は、割り込み記述子テーブルを備えており、テーブル内の各エントリが、割り込みソースに対応する割り込みサービス・ルーチンを参照する。割り込みソースの１つが割り込みを発生した場合、プロセッサ３４は、この割り込みソースに対応する割り込み記述子テーブル内のエントリによって参照される、割り込みサービス・ルーチンの実行を開始する。割り込みサービス・ルーチンはサーバ・コントローラ２６のソフトウエアの一部であり、プロセッサ３４上で実行する。通信ユニット３６は、遠隔端末２８からの文字、あるいは「キャリア」または「無キャリア」のような信号の受信時に、プロセッサ３４に割り込みをかけるように構成されている。割り込みサービス・ルーチンは、プロセッサ３４上で実行する他のソフトウエア・タスクと通信を行い、遠隔端末２８との通信に便宜を図る。
【０１１６】
最初に、即ち、遠隔端末２８がサーバ・コントローラ２６との接続を確立する前に、通信ユニット３６に対応する割り込み記述子テーブルのエントリは、プロトコル検出割り込みサービス・ルーチンへの参照によって、分類される(populate)。プロトコル検出割り込みサービス・ルーチンは、サーバ・コントローラ２６のソフトウエアの、３つのプロトコル状態マシンを含む部分である。また、プロトコル検出割り込みサービス・ルーチンは、サーバ・コントローラ２６のソフトウエアの、通信ユニット３６から入来する文字を受け取るソフトウエアの部分でもある。プロトコル検出割り込みサービス・ルーチンによって受け取られる各文字は、３つのプロトコル状態マシンへの入力として作用する。
【０１１７】
一旦ステップ１４０またはステップ１５４のいずれかにおいて有効なプロトコルが検出されたことが上位タスクに通知されたなら、上位タスクは、検出された特定のプロトコルに専用の割り込みサービス・ルーチンへの参照により、通信ユニット３６に対応する割り込み記述子テーブルのエントリを分類する。ＰＰＰおよび予備ＰＰＰプロトコルは、同じ割り込みサービス・ルーチンを有する。
【０１１８】
表１２〜１６（表１２には表１３が、表１３には表１４が、表１５には表１６が、それぞれ連続する）に示される補足資料は、ＰＰＰ割り込みサービス・ルーチンの部分のアセンブリ言語によるソース・コード・リストである。このコード部分は、割り込みサービス・ルーチンがどのようにして入来する文字を受け取って処理し、有効なＰＰＰパケット全体の有効性の判断および／またはこのＰＰＰパケットの形成を行うかを示したものである。一旦ＰＰＰパケットが形成されたなら、割り込みサービス・ルーチンは、当該パケットの存在に関して、サーバ・コントローラ２６のソフトウエアの上位タスクに通知する。
【０１１９】
【表１２】
【表１３】
【表１４】
【表１５】
【表１６】
【０１２０】
次に図１３を参照すると、テキスト・プロトコルの状態マシンを表わす状態図が示されている。テキスト・プロトコルの状態マシンが３つの連続したアスキー「リターン」文字（0X20）を検出した場合、遠隔端末２８から有効なテキスト・プロトコルが検出されたことを示す。TEXT_INT状態１５６において、状態マシンがキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_ONE状態１５７に遷移する。その他の場合、状態マシンはTEXT_INT状態１５６に留まる。TEXT_ONE状態１５７において、状態マシンがキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_TWO状態１５８に遷移する。その他の場合、状態マシンはTEXT_INIT状態１５６に戻る。TEXT_TWO状態１５８において、状態機械がキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_DETECTED状態１５９に遷移する。その他の場合、状態マシンはTEXT_INIT状態１５６に戻る。状態マシンがTEXT_DETECTED状態１５９になった場合、サーバ・コントローラ２６のソフトウエアの上位タスクに、有効なテキスト・プロトコルが検出されたことを通知する。
【０１２１】
図１４は、予備ＰＰＰの状態マシンを表わす状態図が示されている。予備ＰＰＰ状態マシンが文字列"CLIENT"を検出した場合、遠隔端末２８から有効な予備ＰＰＰプロトコルが検出され、対応して文字列"CLIENTSERVER"を遠隔端末２８に送信することを示す。CLIENT_INT状態１６２において、状態マシンが「Ｃ」を受け取った場合、状態マシンはCLIENT_C状態１６３に遷移する。その他の場合、状態マシンはCLIENT_INT状態１６２に留まる。CLIENT_C状態１６３において、状態マシンが「Ｌ」を受け取った場合、状態マシンはCLINET_L状態１６４に遷移する。この進展は、以降の状態１６４、１６５、１６６の各々についても維持され、文字列"CLIENT"の可能な受け取りを示す。この文字列が完全に受け取られなかった場合、CLIENT_INIT状態１６２に戻る遷移が行われる。文字列全体を受け取ったときに、状態マシンはCLIENT_DETECTED状態１６８に遷移し、サーバ・コントローラ２６のソフトウエアにおける上位タスクに、有効な予備ＰＰＰプロトコルが検出されたことを通知する。
【０１２２】
以下に示すのは、有効なＰＰＰパケットを形成する文字列のフォーマットである。
【０１２３】
SYNCH ADDRESS CONTROL PROTOCOL ... data ... CRClow CRChigh SYNCH
SYNCH文字は１６進数の値０ｘ７Ｅで表され、ADDRESS文字は１６進数の値０ｘＦＦで表され、CONTROL文字は１６進数の値０ｘ０３で表わされる。ADDRESSおよびCONTROL文字は任意であるが、一方がある場合、両方の文字がなければならない。PROTOCOL文字（群）は、最初のバイトの最下位ビット（ＬＳＢ）に応じて、１バイトまたは２バイトとなる。最初のバイトの最下位ビットがセットされている（即ち、１）場合、PROTOCOL文字は、圧縮された１プロトコル・バイトのみから成る。最初のバイトのＬＢＳがクリアされている（即ち、０）場合、PROTOCOL文字は、圧縮されていない２プロトコル・バイトから成り、第１のバイトが下位バイト、第２のバイトが上位バイトとなる。「データ」バイトはパケットのペイロードである。ＣＲＣlowおよびＣＲＣhigh文字は、それぞれ、データ・バイト上の巡回冗長度チェック（ＣＲＣ）の下位および上位バイトから成る。
【０１２４】
図１５を参照すると、ＰＰＰの状態マシンを表わす状態図が示されている。ＰＰＰの状態マシンが有効なＰＰＰパケットを検出した場合、遠隔端末２８から有効なＰＰＰプロトコルが検出されたことを示す。PPP_INIT状態１７０において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、状態マシンはPPP_INT状態１７０に留まる。PPP_SYNCH状態１７２において、状態マシンがADDRESS文字を受け取ると、PPP_ADDRESS状態１７４に遷移する。その他の場合、状態マシンはPPP_CONTROL状態１７６に遷移する。PPP_ADDRESS状態１７４において、状態マシンがCONTROL文字を受け取ると、状態マシンはPPP_CONTROL状態１７６に遷移する。あるいは、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、状態マシンはPPP_INT状態１７０に遷移する。PPP_CONTROL状態１７６において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、文字のＬＳＢがクリアされているなら、PPP_NOT_COMPRESSED状態１７８に遷移し、この文字を非圧縮２プロトコル・バイトの下位バイトとして扱い、この文字のＬＳＢがセットされているなら、PPP_COMPRESSED状態１８０に遷移し、この文字を単一の圧縮プロトコル・バイトとして扱う。PPP_NOT_COMPRESSED状態１７８において、状態マシンがSYNC文字を受け取ると、PPP_SYNCH１７２状態に遷移する。その他の場合、状態マシンはPPP_COMPRESSED状態１８０に遷移し、非圧縮２プロトコル・バイトの上位バイトとしてこの文字を扱う。PPP_COMPRESSED状態１８０において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_DETECTED状態１８２に遷移する。その他の場合、状態マシンはPPP_COMPRESSED状態１８０に留まり、この文字をデータまたはＣＲＣバイトとして扱う。状態マシンがPPP_DETECTED状態１８２に到達した場合、サーバ・コントローラ２６のソフトウエア内の上位タスクに、有効なＰＰＰプロトコルが検出されたことを通知する。
【０１２５】
サーバ・コントローラ２６は、任意のダイアル・バック・セキュリティ(dial-back security)機能を備え、無許可のユーザがサーバ・コントローラ２６を通じてサーバ１０を不正に変更するのを防止する。サーバ・コントローラ２６のコンソール・アプリケーション・ソフトウエアを用いて、システム管理者は、各々ユーザ名、パスワードおよび電話番号を含むユーザ・プロファイルのリストを構成する。ユーザが発信してきた場合、サーバ・コントローラ２６はユーザからユーザ名およびパスワードを受信し、ユーザ・プロファイルのリストからそのユーザ名およびパスワードを確認し、そして切断する。ユーザ名およびパスワードがユーザ・プロファイルのリストにおいて確認された場合、サーバ・コントローラ２６は、ユーザ・プロファイルのリスト内にある対応する電話番号を呼び出す。許可されているユーザには、遠隔アクセスは通常通りに進む。万一侵入者が有効なユーザ名およびパスワードを得ても、しかしながら、侵入者には呼び出しがかからないので、侵入者はサーバ１０への接続を失うことになる。
【０１２６】
サーバ・コントローラ２６は、ユーザが発信してきたときに用いられたのと同じ通信プロトコルによって、許可されたユーザに呼び出しをかけるという利点がある。例えば、ユーザが予備ＰＰＰプロトコルを用い、WINDOWS NT機からヌル・モデムを通じて接続した場合、サーバ・コントローラ２６は予備ＰＰＰプロトコルを用いてこのNT機に呼び出しをかける。遠隔端末は、それが発信したのと同じプロトコルを用いてサーバ・コントローラ２６と通信することを期待する場合が多いので、これは有用である。
【０１２７】
次に図１６を参照すると、ＰＣＢ２００上に配置された、サーバ・コントローラ２６の様々な構成要素が示されている。ＰＣＢ２００は、複数のプレーン(plane)即ち部分に分離されている。第１部分２０２は拡張バス・インターフェース・ユニット２０４および検出ロジック３０を収容する。第２部分２０６はプロセッサ３０およびコントローラ・メモリ３２、ならびに参照番号２０８で示す二次電源（即ち、電池）を収容する。第３部分２１０は通信ユニット（即ち、モデム）３６を収容する。部分２０２、２０６、２１０は、第１の遮断ユニット２１２および第２の遮断ユニット２１４として示す１対の遮断ユニットによって、互いに分離されている。
【０１２８】
ＰＣＢ２００への電力は、通常、ＰＣＢ２００を接続可能な拡張バスから、エッジ・コネクタ２１６を介して供給される。エッジ・コネクタ２１６のピンの内１本は、第１、第２および第３部分２０２、２０６、２１０にそれぞれ供給される主要電源ＶＤＤのために用いられる。表示データは拡張バスから監視され、エッジ・コネクタ２１６の恐らく数本のピンを通じて、インターフェース・ユニット２０４を通じて検出ロジック３０に送出される。例えば、サーバの停電の間にＶＤＤが失われると、遮断ユニット２１２は２つの機能を果たす。まず、第１部分２０２内の電力用導体を、第２部分２０６の電力用導体から切断する。より具体的には、第１部分２０２内のＶＤＤ導体は、遮断ユニット２１２によって、第２部分２０６内の電力用導体または導体群から切断される。第２に、第１部分２０２内の信号用導体は、第２部分２０６内の信号用導体から切断される。信号用導体が切断されると、信号用導体は三状態化する(tri-stated)。
【０１２９】
第１の遮断ユニット２１２と同様、第２の遮断ユニット２１４も電力用導体および信号用導体を切断する。拡張バスからＶＤＤが遮断され、更に通信ユニット３６が遠隔端末２８からの通信を検出できなくなった場合、第２の遮断ユニット２１４はその切断処理を実行する。しかしながら、ＶＤＤが得られる場合、または遠隔端末２８が通信プロトコルを送っている場合、第２の遮断ユニット２１４は、第２および第３部分２０８、２１０間の結合を行う。
【０１３０】
遮断ユニット２１２、２１４は、電力用導体上にクイック・スイッチを備え、更に信号用導体間にバッファ／ドライバ機能を有する双方向トランシーバを備えていることが好ましい。クイック・スイッチは、National Semiconductor Corp.およびTexas Instruments, Inc.等の販売会社から入手可能であり、共通の制御入力（即ち、出力イネーブルOE入力）を有するパッケージ化されたＪＦＥＴのアレイとして形成されている。双方向トランシーバは、高容量性負荷を駆動するのに非常に適しており、高速で動作する。適切な双方向トランシーバは、integrated Device Technology, Inc.またはTexas Instruments, Inc. から、三状態出力機能を有する高速ＣＭＯＳトランシーバとして入手可能である。
【０１３１】
エッジ・コネクタ２１６のピンの１つには、充電用導体２２０が結合されている。充電用導体２２０は、拡張バスから供給されＶＤＤよりも高く設定された電圧を受けるように構成されている。一実施例によれば、充電用導体２２０上の所望の電圧は１２ボルトであり、この場合、ＶＤＤは５ボルトである。充電用導体２２０によって供給される電圧は、電池２０８を充電するだけでなく、スイッチング・レギュレータ２２２のスイッチングをイネーブルするように作用する。例えば、充電用導体２２０内の電荷がスレショルド値よりも低下した場合、スイッチング・レギュレータ２２２は、第２部分２０６および恐らく第３部分２１０に電池２０８を結合するように機能する。逆に、充電用導体２２０上の電荷がスレショルド値を超過している場合、電池２０８からの出力（即ち、ＶＤＤＢ）は第２部分２０６および第３部分２１０には結合されない。代わりに、後者の場合、そこにＶＤＤが供給される。ダイオード２２４を用いて、導体２２０上の電荷を終了させる期間中、電池２０８の放電を防止する。
【０１３２】
呼び出し指示器２２６が、第２部分２０６と同じ電力プレーンに結合されている。具体的には、呼び出し指示器２２６は、ＶＤＤがない期間中、導体２２８上のＶＤＤＢを受け取り、ＶＤＤがある場合ＶＤＤを受け取る。したがって、呼び出し指示器２２６は、主電源または二次電源のいずれかから電力を維持し、入来するアナログ呼び出しARNG信号を検出する。ARNGの受信時に、呼び出し指示器２２６は、デジタル呼び出しＤＲＮＧ信号を通じて、結果的に得られる通信プロトコルを通信ユニット３６に送出する。常に呼び出し指示器２２６に電力を維持することによって、入来する呼び出しの検出は、ＶＤＤの状態には無関係に、常に可能となる。
【０１３３】
図１７は、ＶＤＤがＶＤＤＢよりもスレショルド量だけ少なくなったか否かについて判定を行う際に使用される比較器２３０を示す。ＶＤＤが偶然許容可能なスレショルドを越えて低下した場合、比較器２３０はVDDOFF信号を生成する。VDDOFF信号は、第１遮断ユニット２１２の遮断出力イネーブルOEピン上に現れる。これによって、拡張バスによって供給されるＶＤＤが電池２０８によって供給されるＶＤＤＢよりも低くなった場合に、比較器２３０は、信号用導体および電力用導体の遮断を行う。
【０１３４】
図１８は、デジタル呼び出しDRNG信号の動作、ならびに第２部分２０６および第３部分２１０間の電力用導体および信号用導体の遮断に対するその効果について示すものである。通信ユニット３６への電力が最初にオフになっている場合、通信ユニット３６へのDRNG信号はプロセッサ３４に割り込みを発生する。こうして、プロセッサ３４は、通信ユニット３６に呼び出し信号があることを通知され、これにより、プロセッサ３４はMDMACT信号を通じてそれ自体の割り込みを承認し、かつMDMPWR信号を通じてモデムへの電力供給を承認する。より具体的には、MDMPWR信号は第２の遮断ユニット２１４の出力イネーブルOE入力に供給される。入来する呼び出しを示すMDMPWRを受信すると、第２の遮断ユニット２１４は、第２部分２０６および第３部分２１０間に延びる電力用導体および信号用導体を結合する。本質的には、DRNGは、通信ユニット３６がオンかオフかを示す信号によってゲートされ、このゲートの出力が、プロセッサ３４への割り込みとなる。プロセッサ３４が割り込みを受け取ったときはいつでも、プロセッサ３４のＶＤＤＢからの電力は通信ユニット３６に供給される。通信ユニット３６への電力がオンである場合、割り込みはアサートされない。
【０１３５】
本発明は多種多様のコンピュータ・システム、多種多様の電気的構成物、多種多様のＰＣＢおよび多種多様の通信プロトコルを用いた応用が可能であることは、本開示から当業者には明らかであろう。更に、ここに示しかつ記載した本発明の形態は、現状における好適な実施例として捕らえるべきことは理解されよう。特許請求の範囲に記載してある本発明の主旨および範囲から逸脱することなく、様々な修正や変更が可能である。したがって、特許請求の範囲はかかる修正や変更全てを含むものとして解釈し、この明細書および図面は限定的な意味ではなく例示的な意味で捕らえるべきことを意図するものである。
【図面の簡単な説明】
【図１】本発明による、遠隔端末からアクセス可能なサーバ・コントローラを用いて構成を変更したホスト・サーバのブロック図である。
【図２】遠隔端末からのアクセスに応答して、サーバ・コントローラが遠隔端末の表示画面に送出する、３種類の画面表示メニューを示す図である。
【図３】図１に示したビデオ・メモリおよびビデオ制御レジスタ（ビデオ・コントローラ内）に使用可能なメモリ・アドレス空間およびＩ／Ｏアドレス空間の部分を示す図である。
【図４】サーバ・コントローラの詳細ブロック図である。
【図５】図４に示すプロセッサによって用いられ、サーバＣＰＵから拡張バスに送られる一連のビデオ画面の処理および記憶を行うための種々のバッファのブロック図である。
【図６】所定の連続ビデオ画面を記憶する際に、サーバ・コントローラによって実行されるステップを示すフローチャートである。
【図７】所定の連続ビデオ画面を記憶する際に、サーバ・コントローラによって実行されるステップを示すフローチャートである。
【図８】遠隔端末上でリセット時のビデオ画面シーケンスを再生する際に、図４のプロセッサが実行するステップを示すフローチャートである。
【図９】遠隔端末上で障害時のビデオ画面シーケンスを再生する際に、図４のプロセッサが実行するステップを示すフローチャートである。
【図１０】代表的な障害時画面シーケンスとして提示する表示シーケンスを表わす図である。
【図１１】拡張バスの侵入および非侵入が発生する２つの別個のビデオ・ライト・サイクルを示す、種々のＥＩＳＡ拡張バス信号のタイミング図である。
【図１２】遠隔端末によって使用可能な種々の通信プロトコルを検出する際に、サーバ・コントローラが実行するステップを示すフローチャートである。
【図１３】遠隔端末から送られたテキスト通信プロトコルを検出する際に使用する、テキスト・プロトコルの状態マシンを示す状態図である。
【図１４】遠隔端末から送られた予備二地点間（ＰＰＰ）通信プロトコルを検出する際に使用する、予備ＰＰＰプロトコルの状態マシンを示す状態図である。
【図１５】遠隔端末から送られたＰＰＰ通信プロトコルを検出する際に使用する、ＰＰＰのプロトコル状態マシンを示す状態図である。
【図１６】拡張バス上で結合するように構成されたＰＣＢ上で実施されるサーバ・コントローラを示すブロック図である。
【図１７】図１６の前記ＰＣＢ内に配置されている電力プレーン間に延在する信号導体を遮断する際に使用する比較ロジックを示す図である。
【図１８】通信ユニットが遠隔端末から信号を受信している間に、信号導体を結合し、通信ユニットの電力プレーンに給電するために用いられる信号を示す説明図である。
【発明の属する技術分野】
本発明は、分散型コンピュータ・システムに関し、更に特定すれば、ホスト・コンピュータ（「ホスト」）であって、当該ホストとは物理的に接続されておらず、このホストから離れた場所に位置する端末からアクセス可能なホストに関するものである。遠隔端末は、ホストのリセットまたは障害処理の間に発生する一連のビデオ画面のような、記憶されている一連のビデオ画面にアクセスすることができる。この一連のビデオ画面は、次に遠隔端末に配置されているコンピュータ管理者による再生が可能である。これらビデオ画面への遠隔アクセスにより、管理者は、ホストのオペレーティング・システムがどのようにリセットに応答するのか、即ち、ホスト・システムが障害を発生した場合の原因として可能性のあるものを判定することができる。ホストには、プリント回路基板（「ＰＣＢ」）が設けられており、ホストを収容するバックプレーン(backplane)に挿入することができる。ＰＣＢは、プロセッサと、ホストへの電力が失われた場合でも前述の一連のビデオ画面を記憶しているメモリとを備えている。
【０００２】
【従来の技術】
分散型コンピュータ・システムは、一般的によく知られている。かかるシステムは、多数のコンピュータ・ワークステーション上で実行される(hosted)アプリケーション・プログラム間での通信が可能である。分散型コンピュータ・システムには多数の種類があり、多くの場合、それらの通信能力の地理的範囲によって分類されている。分散型コンピュータ・システムの地理的広さ(geographical breadth)を分類するために用いられる用語には、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、およびワイド・エリア・ネットワーク（ＷＡＮ）がある。
【０００３】
増々普及しつつある分散型コンピュータ・システムの多くは、ファイル・サーバ（「サーバ」）を採用している。ファイルまたはデータは、サーバ内のホストによって管理される。サーバが特に有用なのは、サーバによって、記憶されているファイルに対するワークステーションの高速アクセスが可能になる点にある。したがって、ファイル・サーバは、ファイルを編成(orchestrate)するだけでなく、ファイルの機密保護、ファイル・バックアップ等の保守も行う、オペレーティング・システム・プログラム（普及しているオペレーティング・システムには、例えば、Windows NT（登録商標）がある）に応答するホスト・コンピュータを具現化するものである。
【０００４】
サーバ内においてホストの機能を維持することの重要な一面に、ホストから離れた場所からホストを管理すること、より具体的には、物理的にサーバに連結されているワークステーションから離れた場所にあるホストを管理することがあげられる。最近の傾向として、業務に使用するサーバの数が確実に増加している。今日では、サーバは、１カ所に集中させたメインフレームを採用するのではなく、業務実体の各位置毎等のように自由に用いられている。しかしながら、分散した場所に配置された多くのサーバ・ホストを管理するために利用可能な資金は減少しつつある。これらのサーバに置かれているデータは業務には非常に重要であるが、単一のサービス現場からそれらの適正な動作を確保するための手段は、未だに不十分である。管理者が遠隔地にあるサーバ設置現場まで移動して問題を解決するというようなことは、実用的でないだけでなく、サーバのダウンタイム（動作不能時間）に付随する出費は膨大なものとなる。
【０００５】
多くのオペレーティング・システム、またはこれらオペレーティング・システムと関連するアプリケーションは、しばしば、バーチャル・ターミナル即ち仮想端末と呼ばれている遠隔地からのホストへのアクセスを許可する。仮想端末は物理的にホストに接続されていないが、ホストの所定の動作の遠隔制御を許している。コンパック・コンピュータ社（Compaq Computer Corp.）から入手可能なCOMPAQ Server Manager/R （登録商標）およびCOMPAQ Insight Manager（登録商標）（「ＣＩＭ」）のような製品は、単一の遠隔地から分散されたサーバのネットワークを管理する際に付随する問題のいくつかに対処しようとしたものである。これらの製品は、特に、管理者に遠隔サーバの障害を警告し、遠隔地からのサーバのリセットや、サーバ・コンソール上に提供される所定の情報へのアクセスを可能にする。
【０００６】
所定のサーバ機能、得に、サーバのネットワーク内における１台以上のサーバをリセットするために必要な機能の遠隔制御を可能にすることは、確かに有益である。サーバの障害によって発生するダウンタイムは、いずれにしても、分散型コンピュータ・システムを動作させる際に生じる恐らく最も高くつく時間である。サーバの障害は、しばしばサーバ・ホストの「クラッシュ」と呼ばれるが、その原因は多数ある。サーバ・ハードウエア、サーバ・オペレーティング・システム、またはサーバ上で実行されるアプリケーション・プログラムに関連するあらゆる数の誤動作や設計フローが、サーバ・クラッシュの要因となり得る。サーバがクラッシュを起こすと、多くの場合ファイル・アクセスが不可能となり、障害の原因が突き止められるまで、業務記録は一時的にアクセス不能となる。
【０００７】
【発明が解決しようとする課題】
サーバから離れて位置する管理者が、警告を受け、障害を発生したサーバをリセットする以上の処置を行うことができれば、極めて有益であろう。特に、管理者がサーバの障害原因を判定し、彼／彼女が、今後の障害発生の前に、それらを防止できるようになれば、有益であろう。障害の防止は、クラッシュしたサーバをリセットすることと同様に重要である。
【０００８】
通常、障害の原因は、サーバがクラッシュした時点に、サーバのコンソール上に表示される。更に、リセット時（または「ブート」時）には、サーバ・ホストのハードウエアまたはオペレーティング・システム・ソフトウエアにおける異常を検出することができる。これらの異常は、管理者が対処しなければ、将来の障害に発展する可能性がある。したがって、サーバのリセット中（または障害中）だけでなく、サーバのリセット／障害に至る間にも、サーバ・ホストのコンソール上に表示されるものへのアクセスが得られれば有益である。サーバのコンソール上に表示されるビデオ画面（即ち、一連のビデオ画面）内の情報は、サーバの障害またはリセット時に生成されるが、遠隔地にいる管理者が、既存のサーバの障害または潜在的な障害を判定（および望ましくは解決）するのに、役立つであろう。
【０００９】
サーバのリセットまたは障害により発生するビデオ画面は、オペレーティング・システムによってホスト・サーバのコンソール上に表示される一連のビデオ画面の変化、システム基本入出力システム（「ＢＩＯＳ」）、サーバのアプリケーション・プログラム、またはその他のシステム・ソフトウエアから成る。特に、２種類の連続画面変化を捕獲することは、サーバの管理者には特別な関心事であろう。既存の障害または今後の障害を解決するためには、サーバの障害に先だって、かかる一連の画面変化やリセットに続く一連の画面変化を、管理者に与えることは有益であろう。サーバのコンソール上に表示されるサーバ障害画面の例には、マイクロソフト社（Microsoft Corp.）のWindows NT：登録商標）の「ブルー・スクリーンズ(blue screens)」、およびノベル社（Novell Corp.）のnetware（登録商標）のABENDメッセージがあり、これらは、それぞれのオペレーティング・システムがクラッシュしたときに、サーバのコンソール上に現れる。これらの画面は、プロセッサの故障表示(processor fault indicia)、システム・ソフトウエア・ルーチンのアドレス、および関連のあるシステム・メモリの内容のような情報を提供する。サーバのリセット時に、通常、前述のオペレーティング・システムに付随する起動時自己検査（「ＰＯＳＴ」）コードが幾つかのシステム診断を行い、検出された障害に関する情報を、サーバ・コンソールの画面に表示する。したがって、連続画面を捕獲し、遠隔管理部署においてそれらを再生するための手段が望まれている。
【００１０】
ハードウエアおよびソフトウエアの問題に加えて、サーバへの電力が中断した場合にも、サーバは障害を発生する可能性がある。しかしながら、電力が中断した場合は、障害の前に何が起こったのかについての画面変化は全て失われる。したがって、サーバは、サーバへの電力が失われても、リセットおよび障害時の画面変化をセーブするための機構を備えていることが必要である。このようにすることにより、記憶されている画面変化を遠隔地にいる管理者が後日読むことができるので、有益である。このための望ましい機構は、停電の間、画面情報を保持することができる機構であり、該機構内の重要なユニットにのみ選択的に電力を供給することができるものである。したがって、好ましくはサーバのシャーシ内に実装可能なＰＣＢ上に実現される機構が必要とされる。このＰＣＢは、ホスト・サーバに接続し、ホストから出力される画面情報を記憶し、サーバへの電力が遮断されたときでも情報を保持する保持媒体を含むことが望ましい。
【００１１】
遠隔地およびサーバ間の通信は、Amerian National standards Institute（「ＡＮＳＩ」）の端末エミュレーション・プロトコルのような、業界において一般的に知られている、テキストを基本とする接続プロトコルを通じて行われる。端末エミュレーション・プロトコルはある水準の機能を提供するが、他のプロトコル、即ち、単純なネットワーク管理プロトコル（「ＳＮＭＰ」）、サーバ管理情報の通信用プロトコルのような、アプリケーション・レイヤ・プロトコルを可能にするプロトコルを、サーバおよび遠隔地間の二地点間（「ＰＰＰ：point-to-point 」）通信リンク上においてサポートすることが望ましい。サーバが、複数の通信プロトコルを用いて遠隔地と通信するためのシステムを実現するＰＣＢを含む場合、遠隔地がサーバと通信する際にサポートするプロトコル（即ち、テキストを基本とするプロトコル、ＰＰＰ等）のどれを使用しているのかを、ＰＣＢ上のサブシステムが判定することが望ましい。
【００１２】
【課題を解決するための手段】
上記した従来例の問題点は、本発明の遠隔通信システムによってほぼ解決される。本発明の遠隔通信システムは、サーバ上の拡張バスに接続可能なサーバ・コントローラを採用する。好ましくは、サーバ・コントローラは、ＥＩＳＡ拡張バスに接続可能なエッジ・コネクタを有するＰＣＢ上に実現される。サーバ・コントローラは、ビデオ・アドレス範囲内のライト（書き込み）・サイクルを検出する検出ロジックを含む。ライト・サイクルは、ビデオ・コントローラに送出される表示データも拡張バス上に配列されたときに、開始される。したがって、検出ロジックは拡張バスを監視して(snoop)表示データを発見し、表示データをコントローラ・メモリに複写、即ち記憶する。
【００１３】
コントローラ・メモリは、検出ロジックと同様、サーバ・コントローラのＰＣＢ上に実現され、複数のバッファを含む。コントローラ・メモリに向けて送出される表示データはローカル・フレーム・バッファに格納され、ローカル・フレーム・バッファはこの表示データをフレーム毎に記憶する。以前の表示データのフレーム即ち画面を現在の表示データのフレーム即ち画面と比較し、それにより、変化が生じた場合にそれを表示することができる。変化は、サーバの表示装置に登録されると、これもコントロール・メモリと連携する現（カレント）シーケンス・バッファ内に記憶される。現シーケンス・バッファは、サーバの障害またはリセットに先だって発生した一連のビデオ画面変化、サーバの最新のリセット後に発生した一連のビデオ画像変化、および最新のリセットに先だって発生した一連のビデオ画面変化という、３種類の変化を記憶する。障害によるビデオ画面変化（即ち、ブルー・スクリーンズまたはABENDメッセージ）だけでなく、現在および以前のリセットによるビデオ画面変化も記憶することにより、管理者は、サーバの障害理由、または今後の障害の可能性について判定することができる。
【００１４】
管理者はサーバから離れて位置する端末を用いて、コントローラ・メモリ内に記憶されている様々な連続ビデオ画面変化のいずれでも検索することができる。サーバ・コントローラは、遠隔端末から送られてくる異なるタイプの通信プロトコルを認識することができる。サーバ・コントローラ内のローカル・プロセッサは、各プロトコル専用の状態マシンを用いることによって、送られてくる通信プロトコルを認識することができる。送られてくる文字または文字グループにしたがって、状態マシンは、通信プロトコルがテキストに基づくプロトコルか、ＰＰＰプロトコルか、または予備ＰＰＰプロトコル(pre-PPP protocol)かについての判定を行うことができる。先に記した種々のプロトコルは、例えば、電話線または直接直列接続を通じて帯域外接続(out-of-band connection)を行う際に用いられるインターネットワーク・プロトコル(internetworking protocol)として頻繁に用いられているプロトコルとして、当業者にはよく知られている。これは、遠隔端末（ターミナル）からの多数のプロトコルに対応し(service)、入来するプロトコルおよびそれが定義する利点を検出する能力を有している。したがって、送られてくるプロトコルとは無関係に、プロセッサは、通信情報に作用して、これをコントローラ・メモリに送出するように構成される。これによって、コントローラ・メモリは、通信プロトコル上で実施される指令に応答して、様々な連続ビデオ画面を発信することができる。
【００１５】
検出ロジック、コントローラ・メモリ、プロセッサおよび通信ユニットは、ＰＣＢ上に構築されたシステムとしてコンパイルされる。サーバへの電力が絶たれた場合、拡張バスを通じてＰＣＢに供給される主電源も絶たれる。しかしながら、ＰＣＢは、拡張バスからの電力が停止しても、所定の動作機能(vital function)を維持するように構成されている。ＰＣＢは、二次電源または電池を採用しており、拡張バスの電力が停止した場合、二次電源により、プロセッサおよびコントローラ・メモリに、そして選択的に通信ユニットに電力を供給する。電池は、コントローラ・メモリ内に記憶されているビデオ画面情報を保持するのに十分な時間にわたって、プロセッサおよびコントロール・メモリの能力を維持するだけでなく、これらの間の通信も維持することができる。通信ユニットが遠隔端末によってアクセスされていない場合、電池から通信ユニットへの電力は停止させる。このために、遮断（デカップリング）回路が設けられており、通信ユニットが使用されていない場合、電池の不要な電力漏出を防止する。
【００１６】
プロセッサとコントローラ・メモリが位置するＰＣのプレーン（または部分）と、通信ユニットが位置するＰＣＢのプレーンとの間に、第１の遮断（デカップリング）ユニットが設けられている。また、プロセッサおよびコントローラ・メモリ・プレーンと、検出ロジックが位置するＰＣＢのプレーンと間に、第２の遮断ユニットが設けられている。これによって、検出ユニットは、プレーン間で電力を遮断するだけでなく、プレーン間を接続する信号導体も遮断するように機能する。プレーン間における電力の遮断および３ステート信号は、電池電源上の電荷保存に役立つので、サーバのダウンタイム中に連続ビデオ画面変化を記憶維持するために必要な電力を最大限利用することができる。
【００１７】
【発明の実施の形態】
本発明は様々な変更や代替形態が可能であるが、その具体的な実施例を、一例として図面に示し以下に詳細に説明する。しかしながら、図面やその説明は、開示される特定形態に本発明を限定しようとするのではなく、逆に、特許請求の範囲によって規定される本発明の主旨および範囲に該当するあらゆる変更物、均等物および代替物が、本発明に含まれるものである。
【００１８】
まず図１を参照すると、コンピュータ・システム１０のブロック図が示されている。コンピュータ・システム１０は、ファイルの記憶および検索を行う任意のシステム、ファイル・サーバとして機能するシステム、アプリケーション・サーバ、または分散型コンピュータ・システムにおいて公知である他のサーバを含むことが好ましい。システム１０は、ホスト中央演算装置、即ちサーバＣＰＵ１２を含み、ＣＰＵローカル・バスを介して、メモリ・コントローラ１４に結合されている。ＣＰＵ１２は、所定の命令を実施するためのデータ演算装置を含み、とりわけ、実行ユニット、制御／タイミング・ユニットおよび種々のレジスタという基本的構造を有する。代表的なＣＰＵ１２は、インテル社（Intel Corp.）が製造するペンティアム（Pentium（登録商標））プロセッサを含む。
【００１９】
メモリ・コントローラ１４は、ＣＰＵローカル・バスおよびシステム・メモリ１６間のデータ転送を指揮する。メモリ・コントローラ１４は、種々のアドレシング技法に応答し、システム・メモリ１６内の様々な記憶セル・アーキテクチャに対応するように構成されている。適切なアーキテクチャは、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）またはスタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）である。メモリ・コントローラ１４は、ＣＰＵ１２と同期して動作し、システム・メモリとの間に最大転送帯域を確保することが好ましい。
【００２０】
本発明の一実施例によれば、ＣＰＵ１２は、周辺要素インターフェース（「ＰＣＩ」）バスに結合されている。バス・インターフェース・ユニット１８が、ＰＣＩバスおよび拡張バス間のバス・ブリッジとして動作する。バス・インターフェース・ユニット１８はバッファを含み、ＰＣＩバスおよび拡張バス間におけるデータおよびアドレス信号の転送を制御する。こうすることにより、バス・インターフェース・ユニット１８は、クロック速度が異なる可能性がありかつ異なるプロトコルで動作するバスを通じて送出されるデータ間のインターフェースとして機能する。好ましくは、拡張バスは、拡張業界標準アーキテクチャ（「ＥＩＳＡ」）バス・コンフィギュレーションから成る。
【００２１】
拡張バスには、ビデオ・コントローラ２０が接続されている。ビデオ・コントローラ２０は、それに接続されているディスプレイすなわち表示装置２４を制御するために用いられる。ビデオ・コントローラ２０は、ビデオ・グラフィクス・アレイ（「ＶＧＡ」）コントローラのような、一般的に使用されているビデオ・コントローラである。ビデオ・コントローラ２０は、拡張バス上のアドレスに応答し、対応するデータをビデオ・メモリ２２に送出する。ビデオ・メモリ２２は、ビデオ・コントローラ２０が表示装置２４上に表示するビデオ・データを記憶する。表示装置２４は、ビデオ・データを受け取ることができるいずれかのコンソールまたはモニタを含み、好適な表示装置２４は、陰極線管（「ＣＲＴ」）、あるいは液晶表示装置（「ＬＣＤ」）である。ビデオ・コントローラ２０およびビデオ・メモリ２２を、以降一括してビデオ・サブシステムと呼ぶことにする。
【００２２】
サーバ１０には、サーバ１０のリセット後の連続ビデオ画面変化だけでなく、サーバ１０の障害前の連続ビデオ画面変化もセーブする機構が内蔵(retrofit)されている。これを行う機構は、サーバへの電源停止に影響されないものでなければならず、更に、記憶されているビデオ画面を遠隔端末に送出する能力を有していなければならない。かかる機能は、サーバ・コントローラ２６によって実行される。サーバ・コントローラ２６は、サーバ１０のシャーシ内に結合され、拡張バスに接続可能である。この場合、コントローラ２６は、サーバ１０から離れて位置する端末からアクセス可能である。好適実施例によれば、遠隔端末２８は、電話線通信装置を介して、サーバ・コントローラ２６に結合される。電話線通信装置の一例は、遠隔端末２８およびサーバ・コントローラ２６双方に内蔵されているモデムである。遠隔端末２８は、表示装置（例えば、ＣＲＴ）および入力装置（例えば、キーボード）を含む。
【００２３】
一実施例によれば、サーバ・コントローラ２６は、コンパック・コンピュータ社から入手可能なソフトウエアによって動作する。具体的には、該ソフトウエアは、コンパック・コンピュータ社の、遠隔端末２８上で動作可能なCompaq Insight Manager（「ＣＩＭ」）という製品名のソフトウエアである。ＣＩＭは、サーバ・コントローラ２６に装填されているファームウエアにアクセスし、例えば、サーバ・コントローラ２６に記憶されている種々のビデオ画面変化の再生を行うことができる。
【００２４】
サーバ・コントローラ２６のハードウエアおよびファームウエア構造は、ＣＩＭを用いて構成された遠隔端末による遠隔アクセスおよび制御を利用可能とする。サーバ・コントローラ２６に追加されるハードウエアおよび付随するコードにより、サーバ１０が障害を発生した後でも、システム管理者はサーバ・コントローラ２６に発信する(dial into)ことができ、その後サーバ・コントローラ２６と通信し、障害の前またはリセットの後に発生した表示装置２４の一連の画面変化を見ることができる。
【００２５】
サーバ・コントローラ２６内のファームウエアまたはコードは、遠隔端末２８と通信するために用いられるコンソール・アプリケーション・コードとして機能する。図２のａは、コンソール・アプリケーションが遠隔端末２８上に表示する初期メニュー画面の画面表示である。システム管理者がサーバ・コントローラに発信したときはいつでも、この画面表示が発生する。管理者は、メニュー項目のいずれかを選択することができる。彼または彼女がメニュー項目４を選択した場合、管理者は、彼または彼女の遠隔端末２８において、サーバ・コントローラ２６内に記憶されている一連のビデオ画面を見ることができる。ここでは、次にあげる３種類の異なる連続ビデオ画面変化を再生することができる。
【００２６】
（i）サーバ１０の以前のリセット後に発生した一連のビデオ画面
（ii）サーバ１０の現リセットの後に発生した一連のビデオ画面
（iii）サーバ１０の障害の前に発生した一連のビデオ画面
ここでは、上述の（i）〜（iii）における連続ビデオ画面のことを、「現リセット・シーケンス」、「前リセット・シーケンス」、および「障害シーケンス」と呼ぶことにし、これらを一括して「再生シーケンス」と呼ぶことにする。
【００２７】
図２のｂは、システム管理者がサーバ・コントローラ２６に前述のシーケンスのいずれかを表示するよう命令するために用いる、メニュー画面の画面表示である。図２のｃは、システム管理者がサーバ・コントローラ２６に、現リセット・シーケンス、前リセット・シーケンス、および障害シーケンスのいずれかの再生開始や一時停止を行ったり、再生速度を変化させるように命令するために用いるメニュー画面の画面表示である。
【００２８】
現リセット・シーケンスは、サーバ１０の最新のリセットの直後に発生した一連のビデオ画面変化から成る。前リセット・シーケンスは、サーバ１０の最新のリセット前に発生したリセットの直後に発生した一連のビデオ画面変化から成る。障害シーケンスは、サーバ１０のリセット、障害または停電の直前に発生した一連のビデオ画面変化から成る。サーバ・コントローラ２６が、障害シーケンスのために、サーバ１０のリセットまたは停電の前に記憶する画面変化数、あるいは前リセット・シーケンスまたは現リセット・シーケンスに続いて記憶する画面変化数は、サーバ・コントローラ２６が所与の再生シーケンスに使用可能なバッファ空間の量によって決定される。
【００２９】
図３には、サーバ１０内のメモリ・アドレス空間およびＩ／Ｏアドレス空間の部分が示されている。メモリ・アドレス範囲［０ｘＢ０００〜０ｘＢＦＦＦＦ］は、ビデオ・メモリ２２内に位置するビデオ・フレーム・バッファのために予約されている。Ｉ／Ｏアドレス範囲［０ｘ０３Ｂ４〜０ｘ０３ＢＡ］および［０ｘ０３Ｃ０〜０ｘ０３ＤＡ］は、ビデオ・コントローラ２０内のビデオ制御レジスタに指定されている。ＣＰＵ１２は、ビデオ制御レジスタに値を書き込むことによって、表示装置２４の様々な動作を制御する。フレーム・バッファ・メモリのアドレス範囲およびビデオ制御レジスタのＩ／Ｏアドレス範囲のことを、ここでは一括してビデオ・アドレス範囲、即ち、ビデオ・サブシステムに送られるデータのためのアドレス範囲と呼ぶことにする。
【００３０】
表示装置２４は、テキスト・モードにある場合、行列から成るマトリクスに組織される。例えば、一般的な表示画面構成は、２５ｘ８０である。したがって、２０００（＝２５ｘ８０）箇所の文字位置が、表示装置２４上において使用可能である。表示装置２４上の各位置は、フレーム・バッファ内に対応するワード（即ち、２バイト）を有する。このワードの下位バイトは、文字値（例えば、アスキー文字集合における文字「Ａ」に対する０ｘ４１）を含み、このワードの上位バイトは対応する属性（色、前面および背面の輝度、文字を点滅させるか否か等のような属性）を含む。ＣＰＵ１２は、ビデオ・メモリ２２内の適切なフレーム・バッファ位置に値を書き込み、表示装置２４上に所望の文字および属性を表示させる。文字および表示に対する属性を含むフレーム・バッファ内のビデオ・データのことを、ここでは表示データと呼ぶことにする。上述の例では、表示画面全体を表わす表示データを記憶するために、４０００バイト［すなわち、２０００位置ｘ（各位置毎に２バイト）、文字に１バイトおよび属性に１バイト］のフレーム・バッファが用いられる。
【００３１】
以下にあげる３つの例は、ビデオ制御レジスタの多くの使用法のいくつかを示す。尚、ビデオ制御レジスタのアドレスは、Ｉ／Ｏアドレス空間内に予約されている。第１に、ＣＰＵ１２はビデオ制御レジスタのアドレス（即ち、アドレス範囲［０ｘ０３Ｂ４〜０ｘ０３ＢＡ］およびアドレス範囲［０ｘ０３Ｃ０〜０ｘ０３ＤＡ］に書き込みを行い、例えば、表示装置２４上のカーソルの位置および属性を制御する。第２に、ＣＰＵ１２はビデオ制御レジスタに書き込みを行い、例えば、ビデオ・モードをカラー・モードから白黒モードに、またはその逆に変更する。第３に、ビデオ制御レジスタは、多数の画面を記憶することができるビデオ・メモリ２２内の開始アドレスを指定することができる。第３の例では、ビデオ・メモリ２２は、１画面分の表示データを記憶するのに必要な記憶位置よりも多い記憶位置を含むものと仮定する。
【００３２】
ビデオ・メモリ２２が６４ＫＢのメモリを含む（即ち、フレーム・バッファに６４ＫＢが使用可能）と仮定した場合、フレーム・バッファが１画面分の表示データを記憶するために用いるのは４０００バイトに過ぎないので、フレーム・バッファは一度に多数の表示データの集合を格納することができる。ＣＰＵ１２は、ビデオ制御レジスタに書き込みを行い、表示装置２４上に表示させる表示データの最初の集合の、ビデオ・メモリ２２内の開始アドレスを指定する。ビデオ・コントローラに関する情報、より具体的には、上述の代表的な制御機能の多くを実行するためのビデオ制御レジスタを使用するＶＧＡコントローラに関する情報は、とりわけ、Cirrus Logic Corp., Part no. CL-GD542xから入手可能である。
【００３３】
ビデオ・コントローラ２０は、拡張バス（好ましくは、ＥＩＳＡバス）上に発生されたアドレスをデコードし、ビデオ・アドレス範囲内においてバス・サイクルに応答する。ビデオ・コントローラ２０は、ビデオ・メモリ２２内に記憶されている表示データを表示装置２４に送るだけでなく、ＣＰＵ１２がビデオ制御レジスタに書き込んだデータに応答して、表示装置２４を制御する。したがって、ビデオ・メモリ２２は文字および属性情報を格納し、一方ビデオ制御レジスタは表示装置２４を制御する情報を格納する。
【００３４】
ビデオ・コントローラ２０と同様に、サーバ・コントローラ２６も拡張バス上のアドレスをデコードし、ビデオ・サブシステムへの書き込みを検出する。ビデオ・アドレス範囲への書き込みを検出した場合、サーバ・コントローラ２６は、ビデオ・アドレス範囲に書き込まれたデータを、サーバ・コントローラ２６内に記憶する。この動作のことを、「監視：スヌーピング：(snooping)」と呼ぶ。即ち、サーバ・コントローラ２６は、他のサブシステム（即ち、ビデオ・サブシステム２０、２２）に対しての表示データの１つ以上の画面を得る。データはサーバ・コントローラ２６上で複製され、サーバ・コントローラ２６が、ビデオ・メモリ２２のフレーム・バッファ内にある情報、およびビデオ・コントローラ２０のビデオ制御レジスタ内にある情報のミラー・コピー(mirror copy)を保持するようにする。拡張バスを監視してビデオ・アドレス範囲内のデジタル信号を発見することにより、ＣＰＵ１２が認めるビデオ・サブシステムへの書き込みは１回のみでも、二重記憶の実行が可能となる。重要なのは、監視は、サーバ・コントローラ２６によって割り込みを生じないように(non-intrusive)行われることである。ビデオ・サブシステムに対して供給されるべきデータは、ビデオ・サブシステムに進み、サーバ・コントローラ２６によって変更や削除をされることがない。
【００３５】
図４には、サーバ・コントローラ２６の詳細なブロック図が示されている。サーバ・コントローラ２６は、拡張バスに結合された検出ロジック３０を備えている。コントローラ・メモリ３２が、コントローラ・バスを介して、検出ロジック３０に結合されている。検出ロジック３０は、例えば、プログラマブル・アレイ・ロジック（「ＰＡＬ」）回路において一般的に見られるような、組み合わせられた連続的なロジック素子から成る。制御ロジック４０、アドレス・バッファ４２およびデータ・トランシーバ４４についての詳細は、それらの関係を論じた後に説明する。検出ロジック３０内のこれら３つのユニットは、サーバ・コントローラ２６の様々な構成要素、即ち、コントローラ・メモリ３２およびその中の様々なバッファの性能を最大に高めるためのものである。したがって、これら３つの要素４０、４２、４４の説明は、再生シーケンスの検討および様々なバッファがどのようにしてこれらのシーケンスを記憶するのかについての検討が終了してから、行うことにする。
【００３６】
サーバ・コントローラ２６の一部として、プロセッサ３４は、コントローラ・バス上の情報、即ち、検出ロジック３０およびコントローラ・メモリ３２間の情報、または通信ユニット３６およびコントローラ・メモリ３２間の情報のいずれかを編成しなければならない。プロセッサ３４は、命令セットに応答し、例えば、実行ユニット、メモリ、入出力装置、および１つ以上のレジスタを内蔵したマイクロプロセッサまたはマイクロコントローラを含む。プロセッサ３４は、埋め込みシステム(embedded system)の用途に用いられるマイクロプロセッサを代表するものである。コントローラ・メモリ３２は、複数のデジタル記憶素子から成る。本発明の一実施例では、コントローラ・メモリ３２は、疑似スタティックＲＡＭから成る。通信ユニット３６は、サーバ・コントローラ２６から離れて配置された遠隔端末２８に対して通信可能な装置を含む。通信ユニット３６は、遠隔端末２８から送られてくるアナログ呼び出し信号(ARGN:analog ring signal)に応答して、遠隔端末２８に返送する通信信号(COMM. SIG)を生成する。好ましくは、通信ユニット３６はモデムを備えている。通信ユニット３６は、更に、プロセッサ３４に結合された直列ポート、およびサーバ・コントローラ２６外部の直列ポートに結合され遠隔端末２８と通信するためのモデムも想定している。
【００３７】
プロセッサ３４は、再生シーケンスをコントローラ・メモリ３２に記憶する。プロセッサ３４は、再生シーケンスを、表示画面の集合全体を表わす連続表示データとして、コントローラ・メモリ３２内に記憶することも可能である。しかしながら、これは、コントローラ・メモリ３２を使用する方法としては比較的非効率的であり、したがって再生シーケンスを構成してコントローラ・メモリ３２内に記憶されるビデオ画面の数は比較的少ない。本発明では、プロセッサ３４は、一連の表示画面全体の代わりに、一連の表示「変化」として再生シーケンスを効率的に記憶するように表示データを処理する点で効果的である。画面内の変化を表わす表示データの量は、画面全体を表わす表示データ量より大幅に少ない。したがって、現リセット・シーケンス、前リセット・シーケンスおよび障害シーケンス（即ち、再生シーケンス）は、基準画面、即ち「開始」画面からの変化として表わされる。
【００３８】
図５には、コントローラ・メモリ３２内の種々のバッファが示されている。これらのバッファは、プロセッサ３４によって用いられて、再生シーケンスの処理や記憶を行うためのものである。ローカル・フレーム・バッファ４８は、ビデオ・メモリ２２へのライト・アクセスの間に監視された表示データを格納する。即ち、検出ロジック３０が拡張バスを監視し、ビデオ・サブシステムに向けて送られてくるデータを、ローカル・フレーム・バッファ４８に記憶する。スナップショット・バッファ５０は、ローカル・フレーム・バッファ４８からの現表示データの、プロセッサ３４によって作成された、コピー即ちスナップショットを格納する。一時スナップショット・バッファ５２も、ローカル・フレーム・バッファ４８からの現表示データのスナップショットを格納する。一時スナップショット・バッファ５２は、画面変化、特に画面のスクロールが素早く行われる場合に、再生シーケンスを見やすくするために用いられる。
【００３９】
現リセット・シーケンス・バッファ５４は、最新のリセット・シーケンスに関連する情報を格納する。即ち、現リセット・シーケンス・バッファ５４は、最新のリセットで始まり、現リセット・シーケンス・バッファ５４が満杯になると終了する画面変化を格納する。現リセット・シーケンス・バッファ５４が満杯になった後に発生する画面変化は無視される。前リセット・シーケンス・バッファ５６は、最新のリセット・シーケンスの直前のリセット・シーケンスに関連する情報を格納する。即ち、前リセット・シーケンス・バッファ５６は、最新のリセットに前に発生したリセット時に開始し、前リセット・シーケンス・バッファ５６が満杯になったとき、または次のリセットが発生したときに終了する画面変化を格納する。前リセット・シーケンス・バッファ５６が満杯になった後に発生した画面変化は無視される。
【００４０】
現シーケンス・バッファ５８は、最新の画面変化を、バッファ５８内に納まるだけ格納する。障害シーケンス・バッファ６０は、サーバ１０の最新のリセット直前の障害シーケンスに関連する情報を格納する。即ち、障害シーケンス・バッファ６０は、最新のリセットで終了する画面変化を格納し、最新のリセット直前に発生した画面変化を、その中に納まるだけ格納する。
【００４１】
障害開始バッファ６４は、障害シーケンス・バッファ６０に関連するビデオ画面表示の表示データを格納する。障害開始バッファ６４は、障害シーケンスにおける初期画面画像（即ち、「基準」画面画像）を格納し、結果的に、障害シーケンス・バッファ６０内の最初の変化が適用される画面画像を格納する。初期状態では、障害開始バッファ６４は空白画面である。障害シーケンス・バッファ６０がオーバーフローした場合、超過分の変化は文字および属性に変換され、障害開始バッファ６４に記憶される。したがって、障害開始バッファ６４は、比較的長い時間期間の間に画面上の少数の文字だけが何回も変化するような場合に、有用性が高い初期画面画像を提供する。現開始バッファ６２は、現シーケンス・バッファ５８に関して、同一の機能を提供する。
【００４２】
サーバ１０のリセットまたは障害は、サーバ・コントローラ２６のリセットの原因にならないものである。しかしながら、サーバ・コントローラ２６は、以下のリセット・イベントに関する情報を検出し保持する。即ち、サーバ１０の給電開始、サーバ１０の電力遮断、および拡張バスのリセットである。特に、サーバ・コントローラ２６は、RSTDRV EISAバス信号には応答せず、単にRSTDRVのアサートを検出するに過ぎない。リセットが発生した場合、または電力がサーバ１０から遮断された場合でも、サーバ・コントローラ２６は動作を維持し、遠隔端末２８上の表示のために、再生シーケンスを保存する。サーバ・コントローラ２６を収納する同一ＰＣＢ上に、二次電源が設けられており、再生シーケンスが維持されることを保証する。しかしながら、必要であれば、ＣＰＵ１２にアクセス可能なサーバ・コントローラ２６の所定のレジスタ位置に所定の一連の値を書き込むことによって、ソフトウエアの制御の下でサーバ・コントローラ２６をリセットすることも可能である。
【００４３】
サーバ１０のリセットが発生した場合、ポインタを変化させて、現リセット・シーケンス・バッファ５４が前リセット・シーケンス・リセット・バッファ５６になるようにし、更に前リセット・シーケンス・バッファ５６がフラッシュ（一掃）され、現リセット・シーケンス・バッファ５４になる。サーバのリセットによっても、現シーケンス・バッファ５８が障害シーケンス・バッファ６０になり、障害シーケンス・バッファ６０がフラッシュされ、現シーケンス・バッファ５８となる。また、リセット時にも、現開始バッファ６２は障害開始バッファ６４となり、障害開始バッファ６４はフラッシュされ、現開始バッファ６２となる。
サーバ・コントローラ２６は、サーバ１０の自動サーバ復元（「ＡＳＲ」）リセット(automatic server recovery reset)を実行するように構成されている。サーバ・コントローラ２６がサーバ１０の障害を検出した場合、所定の時間の間（典型的には、３０秒）待ってから、サーバ１０をリセットする。
【００４４】
以下に述べるのは、サーバ１０のリセット、それに続いて障害、更にそれに続いてリセットが発生する例示的なシーケンスである。最初にサーバ１０を起動し、サーバ１０をリセットする。リセット時に、サーバ・コントローラ２６は、前リセット・シーケンス・バッファ５６から情報をフラッシュし、障害シーケンス・バッファ６０をフラッシュし、更に障害開始バッファ６４をフラッシュする。バッファ５６、６０、６４をフラッシュする間、前リセット・シーケンス・バッファ５６と現リセット・シーケンス・バッファ５４との交換が、バッファ６０、５８間の交換およびバッファ６４、６２間の交換と同時に行われる。したがって、リセットにより、バッファ５４、５８、６２からそれぞれバッファ５６、６０、６４へ情報の移動が生ずる。リセット時に、サーバ１０のソフトウエアは、ＰＯＳＴ処理の実行、および表示装置２４上の文字表示を開始する。
【００４５】
サーバ・コントローラ２６は、ＰＯＳＴ処理に付随する画面変化を、現リセット・シーケンス・バッファ５４および現シーケンス・バッファ５８に記憶する。一旦現リセット・シーケンス・バッファ５４が満杯になったなら、サーバ・コントローラ２６は画面変化をそこに記憶するのを中止する。現シーケンス・バッファが満杯になった場合、サーバ・コントローラ２６は最も古い画面変化を現シーケンス・バッファ５８から除去し、新たな画面変化の記憶のための余裕を作り、現開始バッファ６２を修正して古い画面変化を記憶させる。このように、バッファ５８はＦＩＦＯレジスタと同様に動作し、超過した情報をバッファ６２に送出する。以下で説明するが、バッファ５８、６２の組み合わせ（バッファ６０、６４と交換された場合）は、最新の障害以前のビデオ画像の障害シーケンス全体を表わす。
【００４６】
リセット−障害−リセットの３段階の例における第２段階においてサーバ１０の障害が発生した場合、ビデオ画面のシーケンスが表示装置２４上に生成され、この障害、および可能であれば障害の理由を示す。これらの画面は、Novell NetwareからのABENDメッセージまたはMicrosoft NTのブルー・スクリーンとして使用可能な、多くのサーバ・オペレーティング・システムの一部として、自動的に表示される。障害が発生して３０秒後、サーバ・コントローラ２６はサーバ１０上でＡＳＲリセットを実行する。ＡＳＲリセットの間に、リセット−障害−リセット例における２回目のリセットが発生する。１回目のリセットと同様、このリセットによって、サーバ・コントローラ２６はバッファ５６、６０、６４をフラッシュする一方、バッファ５６，６０，６４のバッファ５４，５８，６２との交換をそれぞれ行うことができる。
【００４７】
また、１回目のリセットと同様、サーバ１０は再びＰＯＳＴ処理を起動し、文字を表示装置２４に送出する。サーバ・コントローラ２６は、ＰＯＳＴ処理の結果生じたリセットの後に発生した画面変化を、現リセット・シーケンス・バッファ５４および現シーケンス・バッファ５８に記憶する。前リセット・シーケンス・バッファ５６は、ここで、最初のパワー・オン・リセットに付随する一連の画面変化を格納し、障害シーケンス・バッファ６０および障害開始バッファ６４は、ここで、当該障害までに至る一連の画面変化を格納する。前リセット・シーケンス・バッファ５６内に格納されている初期リセットによる画面変化とは異なり、現リセット・シーケンス・バッファ５４は、２回目のリセット（即ちＡＳＲリセット）に関連するリセットによる画面変化を格納する。
【００４８】
ビデオ画面全体とは異なり、ビデオ画像の変化は、現リセット・シーケンス・バッファ５４、前リセット・シーケンス・バッファ５６、現シーケンス・バッファ５８および障害シーケンス・バッファ６０内には、パケットとして記憶される。バッファ５４、５６、５８、６０内の各パケットは、指定された長さの一連のバイトで構成される。パケットは「タイプ」にしたがって類別され、パケット・タイプは、その長さならびに最初のバイト（バイト０）、およびパケット長が１バイトより長い場合は２番目のバイト（バイト１）によって判定される。パケット・タイプ、および遠隔端末２８上のサーバ・コントローラ２６が各タイプに応じて行う作用は以下の表１の通りである。
【００４９】
【表１】
このリストに示す各パケット・タイプに用いた二進コード・フォーマットは、次の表２の通りである。
【００５１】
【表２】
表示文字列パケット・タイプにおけるバイト３、４、および後続バイトは、表示すべきヌルで終了する文字列を含む。この文字列は、少なくとも２文字にヌルの終端を加えた長さでなければならないので、その長さは５より大きい。したがって、長さ検査を用いて、繰り返し文字パケットから識別可能である。変化が１文字を含むのみである場合、その変化は繰り返し回数が１の繰り返し文字パケット、または単一文字パケットとして記憶する。
【００５３】
図５に示したコントローラ・メモリ３２内に位置する種々のバッファの機能は、図６および図７のフローチャートの説明において、より明白となろう。なお、図６および図７は、プロセッサ３４が、バッファ４８〜５２に送出される表示データを処理し、バッファ５４〜６４のいずれかに再生シーケンスを記憶する際に実行するステップを示すフローチャートである。
【００５４】
図６を参照すると、ステップ７０において、プロセッサ３４がローカル・フレーム・バッファ４８をチェックして、ビデオ制御レジスタを通じて、いずれかのビデオ・モード変化が起きているか否かについて検査を行う。ビデオ・モード変更の例は、グラフィックス・モードおよびテキスト・モード間の変更、または画面サイズの変更、即ち、表示装置の行数および列数の少なくとも一方の変更である。再生シーケンスの記憶が可能になる前に、プロセッサ３４は、ステップ７２において、現ビデオ・モードが有効なテキスト・モードであるか否かについて判定を行わなければならない。有効なテキスト・モードでない場合、プロセッサ３４は、ビデオ・モードが有効なテキスト・モードになるまで待ち、次いでプロセッサ３４は、ステップ７４において、ローカル・フレーム・バッファ４８からの現表示の集合（ビデオ制御レジスタ内に指定される開始アドレスによって示される）を、一時スナップショット・バッファ５２にコピーする。
次に、プロセッサ３４は、ステップ７６において、一時スナップショット・バッファ５２の内容を、スナップショット・バッファ５０の内容と比較して、画面スクロールが行われたか否かについて判定を行う。スクロールが行われていた場合、プロセッサ３４は、ステップ７８において、画面スクロール・パケットを適切なバッファに記憶する。
【００５５】
そして、プロセッサ３４は、スナップショット・バッファ５０および一時スナップショット・バッファ５２の先頭から開始して、それらを比較し変更するための一連のステップを開始することができる。プロセッサは、ステップ８０において、バッファ５０，５２の現バイトを比較し、変化を探す。ステップ８２に示すように、変化が発見された場合、プロセッサ３４はステップ８４において、その変化を用いて、スナップショット・バッファ５０を更新する。次に、プロセッサ３４は、ステップ８６において、この変化をパケットに変換する。ステップ８８において現バッファ５４、５８、６２に選択的に入力されるのは、パケットに変換された変化である。次に、プロセッサ３４はステップ８０に戻って他の変化を探し、ステップ８２において、プロセッサがバッファ５０、５２における表示データ間にもはや変化がないと判定するまで、ステップ８２、８４、８６、８８を繰り返す。
一旦プロセッサ３４が、ステップ８２においてもはや変化がないと判定したなら、プロセッサ３４は、ステップ９０において、カーソル位置が変化したか否かについて判定を行う。位置が変化していた場合、プロセッサ３４は、ステップ９２において、ステップ８８で実行したのと同様の方法で、移動カーソル・パケットを現バッファ５４、５８、６２に記憶する。カーソル位置が変化していない場合、既存のカーソル位置へのパケットのリライトを実施する。
【００５６】
次に図７を参照する。図７には、図６のステップ８８を実行する際に行われるステップの一層詳しいフローチャートが示されている。プロセッサ３４は、ステップ９４において、現リセット・シーケンス・バッファ５４が満杯か否かについて判定を行う。即ち、ステップ９４は、バッファ５４に送られたパケットにより当該バッファが満杯になったか否かを示す。バッファ５４が満杯でない場合、プロセッサ３４は、ステップ９６において、現パケットを現リセット・シーケンス・バッファ５４に送出する。ステップ９８において、現シーケンス・バッファ５８が満杯となりこれ以上パケットを受け入れることができないか否かを、プロセッサ３４が判定する。満杯の場合、プロセッサ３４は、ステップ１００において、最も古いパケットを現シーケンス・バッファ５８から除去し、その後、この最も古いパケットを文字／属性ワードに変換する。この除去されたパケットの文字／属性ワードは、次いでステップ１０２において、現開始バッファ６２に送出される。プロセッサ３４は、ステップ９８において、現シーケンス・バッファ５８はパケットを受け入れられない程満杯ではないと判定するまで、ステップ９８、１００、１０２を繰り返す。満杯ではないと判定した時点で、プロセッサ３４は、ステップ１０４において、パケットを現シーケンス・バッファ５８に入力する。
【００５７】
以下の表３及び表４（表４は表３の続き）に示すのは、Ｃ言語の関数find_change()のコードのフラグメント（断片）である。これは、プロセッサ３４が図６のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００５８】
【表３】
以下に示すのは、Ｃ言語の関数put_packet()のコードの断片であり、プロセッサ３４が図７のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００６０】
【表５】
次に図８を参照する。図８には、プロセッサ３４が遠隔端末２８上にビデオ画面のリセット・シーケンスを再生する際に実行するステップを表わす、フローチャートが示されている。管理者はまず現リセット・シーケンスまたは前リセット・シーケンスは再生する必要があるか否かについて判定を行う。プロセッサ３４は、現リセット・シーケンス・バッファ５４または前リセット・シーケンス・バッファ５６を、それぞれ、再生すべきリセット・バッファとして選択することによって応答する。システム管理者がサーバ・コントローラ２６にリセット・シーケンスの一方を再生するように命令すると、プロセッサ３４は、ステップ１０６において、リセット・バッファには表示すべきパケットが未だあるか否かについて判定を行う。表示すべきパケットがある場合、プロセッサ３４は、ステップ１０８において、リセット・シーケンス・バッファから次のパケットを読み出し、当該パケットを文字列に変換する。次に、プロセッサ３４は、ステップ１１０において、この文字列を遠隔端末２８に送信することによって、文字列を遠隔端末２８上に表示する。プロセッサ３４がステップ１０６において表示すべきパケットがもはやないと判定するまで、プロセッサ３４はステップ１０６、１０８、１１０を繰り返す。
【００６２】
以下の表６に示すのは、Ｃ言語の関数video_reset_play()のコードの断片であり、プロセッサ３４が図８のフローチャートに示した機能を周期的に実行する際に使用可能である。
【００６３】
【表６】
図９には、プロセッサが障害シーケンスを遠隔端末２８上に再生する際に実行するステップを表わす、フローチャートが示されている。システム管理者がサーバ・コントローラ２６に障害シーケンスを再生するように命令すると、プロセッサは、ステップ１１２において、障害バッファ６４内に表示すべき文字が未だあるか否かについて判定を行う。尚、現開始バッファ６２および障害開始バッファ６４は、画面自体ではなく、画面変化を記憶するバッファ（即ち、バッファ５４〜６０）内にあるパケットの代わりに、文字（即ち、文字／属性対から成るワード）を格納するものである。バッファ６４内に未だ表示すべき文字がある場合、プロセッサ３４は、ステップ１１４において、障害開始バッファ６４から次の文字を読み出し、その文字を遠隔端末２８に送信することによって、遠隔端末２８上にその文字を表示する。プロセッサがステップ１１２において障害開始バッファ６４内にはもはや表示すべき文字がないと判定するまで、プロセッサ３４はステップ１１２、１１４を繰り返す。尚、文字は障害開始バッファ６４から消去されるのではなく、文字のコピーが取られるようにしていることを注記しておく。
【００６５】
一旦プロセッサ３４がステップ１１２において障害開始バッファ６４における文字全てを表示したと判定したなら、プロセッサ３４は、ステップ１１６において、表示すべき別のパケットを障害シーケンス・バッファ６０内で検索する。別のパケットがない場合、プロセッサ３４は障害シーケンスの再生を終了する。その他の場合、プロセッサ３４は、ステップ１１８において、パケットをＡＮＳＩ文字列に変換する。次に、プロセッサ３４は、ステップ１２０において、その文字列を遠隔端末２８に送信することによって、その文字列を遠隔端末２８上に表示する。プロセッサ３４は、ステップ１１６において障害シーケンス・バッファ６０内のパケット全てを表示したと判定するまで、ステップ１１６、１１８、１２０を繰り返す。
【００６６】
以下の表７及び表８は、Ｃ言語の関数video_failure_play()のコードのフラグメントであり、プロセッサ３４が図９のフローチャートに示した機能を周期的に実行する際に使用可能である。なお、表８は表７の続きである。
【００６７】
【表７】
再生シーケンスの再生は、管理者が図２のｃに示したメニューに応答して、スペース・キーを押圧したときに開始する。再生は、文字およびエスケープ・シーケンスのストリームを遠隔端末に送り、シーケンス・バッファ内の情報を表示することから成る。文字の中には制御文字があり（アスキー値で０〜３１および１２７）、実際の文字を表示するのではなく、ベルを鳴らす等の機能を行う。その結果、これら表示不可文字の１つがローカル・フレーム・バッファ４８内に現れた場合、実際にはスペースまたは同様に見える表示可能文字のいずれかとして遠隔端末に送られる。エスケープ・シーケンス（エスケープ文字（アスキー値0x1B)で始まる文字列）は、カーソルの移動、画面のクリア、および現表示カラーの変更というような他の作用を行うために用いられる。サーバ・コントローラ２６は、文字０〜３１、１２７、２２５以外の全ての文字を変化させずに送信する。これらの文字は、以下の表８に示すように、アスキー・バイトにリマップされる。
【００６９】
【表９】
以下に示すのは、サーバ・コントローラ２６によって送出されるエスケープ・シーケンスであり、ここで＼x1BがＥＳＣ文字である。Compaq Insight Manager (CIM)アプリケーションを遠隔端末２８上で実行している場合、サーバ・コントローラ２６は所定の標準外エスケープ・シーケンスを送信し、ＣＩＭと通信を行う。これらの標準外エスケープ・シーケンスは、以下の表９において、アステリスクで示すことにする。
【００７１】
【表１０】
上記表１０において、「＋」文字が印されているエスケープ・シーケンスは、白黒モードにおいて用いられるカラー・エスケープ・シーケンスのみである。黒および高輝度の黒を除く全てのカラーは、白または高輝度の白に変換される。
【００７３】
サーバ・コントローラ２６がＣＩＭと通信していないとき、高輝度背景カラーは対応外となり、通常の輝度と同一のカラーとして送られる。前景がこの通常輝度のカラーである場合、以下の表１０にしたがって未だ見ることができるように、前景カラーのリマッピングを行う。
【００７４】
【表１１】
次に図１０のａ〜ｅを参照する。障害シーケンスの画面ショット(screen shot)の例が示されている。画面シーケンスは、遠隔端末２８上にサーバ・コントローラ２６によって表示された再生シーケンスの例である。図１０のａは、サーバ起動時の典型的な初期画面の画面ショットである。この画面は、システム・コンフィギュレーションに関する様々な項目を示す。図１０のｂは、典型的なWINDOWS NTのローダ画面の画面ショットである。ユーザには、複数のブートするNTカーネル間から選択する機会が与えられる。図１０のｃは典型的なNTのブート画面の画面ショットである。このスクリーンは、カーネルの構築バージョン、システム・メモリ量、プロセッサのコンフィギュレーション等を含む。図１０のｄは、サーバ１０の表示装置２４がホストＣＰＵ１２によってグラフィック・モードに設定されたことを示すパケットを再生シーケンスが含むときに、この再生シーケンスの間に、サーバ・コントローラ２６によって遠隔端末２８上に表示されたメッセージを示す。図１０のｅは、典型的なNTのブルー・スクリーンの画面ショットである。
【００７６】
拡張バス（好ましくは、ＥＩＳＡバス）を監視してビデオ・サブシステムへの書き込みを見つけ出すことによって、サーバ・コントローラ２６は、リアル・タイムでビデオ・データの更新を得て、再生シーケンスの再生を実現可能にする。加えて、拡張バスを監視してビデオ・サブシステムへの書き込みを見つけ出すことによって、サーバ・コントローラ２６は、サーバ１０には割り込みをかけない(non-intrusive)方法で、より具体的には、拡張バス帯域には割り込みをかけずに、ビデオ・データの更新を得ることができる。他の方策には、割り込みをかけ非リアル・タイムでビデオ・データを得るものもある。例えば、COMPAQ Server Manager/R （「ＳＭＲ」）という製品は、ＥＩＳＡバス・サイクルの主導権(mastership)をアサートし、サーバ１０のビデオ・メモリ２２内のデータを得る。ＳＭＲは、こうすることにより、表示データの一部をビデオ・メモリ２２からそれ自体のメモリに周期的にコピーする。コピーされたデータは、次に、ビデオ・データの以前のコピーと比較され、画面変化が判定される。ＳＭＲのバス支配法は、ＥＩＳＡバス上のトラフィック増大を招くという欠点があり、他のＥＩＳＡバス・マスタに、余分なバス仲裁遅延を付加することになる。
【００７７】
再び図４を参照しながら、検出ロジック３０内の様々なブロック４０〜４４についての説明を行う。検出ロジック３０は、アドレス・バッファ４２、データ・トランシーバ４４、ならびにＥＩＳＡバスおよびコントローラ・バス間に結合された制御ロジック４０から成る。制御ロジック４０およびプロセッサ３４は、HOLDおよびHLDA（HOLD承認）信号によって結合されている。アドレス・バッファ４２、データ・トランシーバ４４、および制御ロジック４０は協同して表示データを監視し、その後、コントローラ・メモリ３２の一部を形成するローカル・フレーム・バッファ４８（図５）にデータを書き込む。
【００７８】
コントローラ・メモリ３２は、プロセッサ３４および検出ロジック３０の双方がコントローラ・メモリ３２を変更するという点において、プロセッサ３４および検出ロジック３０間で共有されるリソースである。コントローラ・メモリ３２は、単一ポートの疑似スタティックＲＡＭから成る。したがって、検出ロジック３０は、プロセッサ３４からサイクルを盗み、コントローラ・メモリ３２にビデオ・データを書き込む。ライト・サイクルがビデオ・サブシステムに発生すると、検出ロジック３０はライト・サイクルをデコードし、プロセッサ３４をオンに維持し、ビデオ・データをコントローラ・メモリ３２に書き込む。サーバ・コントローラ２６は、ビデオ・データをビデオ・サブシステムに書き込むと同時に、ビデオ・データをコントローラ・メモリ３２に書き込み、サーバ１０上での通常のビデオ・アクティビティを持続させる利点がある。
【００７９】
制御ロジック４０は、拡張バスからアドレス信号を受け取り、ビデオ・アドレス範囲にあるアドレスの存在をデコードする。ビデオ・アドレス範囲内のアドレスが拡張バス・アドレス信号上に現れた場合、制御ロジック４０は、プロセッサ３４へのHOLD信号をアサートすることによって、プロセッサ３４をオンに保持し、コントローラ・メモリ３２に対するアービトレーション（仲裁）を行う。プロセッサ３４はHLDAをアサートし、コントローラ・バスの所有権を制御ロジック４０に与える。
【００８０】
制御ロジック４０は、ビデオ・サブシステムへのライト・サイクル完了の前に、コントローラ・バスの所有権を得ることができ、かつ、コントローラ・メモリ３２にビデオ・データを書き込めることを、保証しなければならない。これを行うために、制御ロジック４０は、ＥＩＳＡ拡張バス内の所定の信号を利用する。制御ロジック４０は、ＥＩＳＡ拡張バスにおいて得ることができるEXRDY信号を利用する。拡張バスがＩＳＡバスである場合、制御ロジック４０はCHRDY信号を利用する。いずれの場合でも、EXRDYまたはCHRDYは、制御ロジック４０がコントローラ・バスの所有権を得るまで、ビデオ・サブシステムへの拡張バスのライト・サイクルを遅らせるように機能する。
【００８１】
拡張バスのSTART#信号がアサートしている間に、ＥＩＳＡ拡張バス（拡張バス）のBCLK信号の立ち上がりエッジ上において、制御ロジック４０は拡張バスのアドレス信号からアドレスをラッチする。制御ロジック４０は、拡張バス上の他の信号、即ち、BCLK、START、およびW_Rを検査し、バス・サイクルがライト・サイクルか否かについて判定を行う。バス・サイクルがライト・サイクルでない場合、制御ロジック４０は、HOLD信号をディアサートすることにより、コントローラ・バスに対する仲裁を中止する。バス・サイクルがライト・サイクルである場合、データ・トランシーバ４４が、ビデオ・データを拡張バスのデータ信号からコントローラ・メモリ３２に送り込むことによって、拡張バスのCMD#信号の立ち上がりエッジ上でライト・サイクルを完了する。制御ロジック４０がEXRDY信号をローに駆動すると、CDM#の立ち上がりエッジは遅れを生じる。
【００８２】
仲裁レイテンシ（制御ロジック４０がHOLDをアサートし、プロセッサ３４がHLDAを付与するまでの時間）が、ビデオ・アドレス範囲にライト・サイクルを設定するのに必要な時間を超過する場合、制御ロジック４０は拡張バス上のEXRDY信号をローに駆動し、遅延サイクルを挿入する。即ち、CMD#の立ち上がりエッジを遅らせる。EXRDY信号がローに駆動されると、現在ライト・サイクルを実行中の拡張バスのマスタに、ライト・サイクルの受け取り側がデータを受け取る準備ができていないことを示す。典型的に、プロセッサ３４は、HLDAを制御ロジック４０に十分早く付与し、制御ロジック４０がEXRDYをアサートする必要がないようにしている。したがって、サーバ・コントローラ２６の監視は、典型的に、非割り込みである。
【００８３】
制御ロジック４０は、以前に拡張バスのアドレス信号からラッチしたアドレスを、コントローラ・メモリ３２のローカル・フレーム・バッファ内の対応する位置に変換し、更に変換したアドレスをアドレス・バッファ４２に供給し、このアドレス・バッファ４２がコントローラ・バス上に変換したアドレスを送り込む。次に、制御ロジック４０は、制御信号をデータ・トランシーバ４４、アドレス・バッファ４２およびコントローラ・バスに対して発生し、コントローラ・メモリ３２の、アドレス・バッファ４２によって駆動された変換後のアドレスに、拡張バスのデータ信号からの表示データを書き込む。制御ロジック４０は、表示データのブロック転送終了まで、即ち、ビデオ・サブシステムへのバーストまたは連続(back-to-back)ライト・サイクルの間、プロセッサ３４をオンのまま保持する。ビデオ・サブシステムへのバースト・ライト・サイクルまたは連続ライト・サイクルの場合、割り込みの可能性がある（遅延サイクルを誘発する）のは最初のサイクルだけである。
【００８４】
拡張バスからコントローラ・メモリ３２へのビデオ・サブシステムに対するライト・サイクルを監視する際、拡張バスおよびコントローラ・バスが異なるクロック信号を有するので、これらのバス間で同期を取る必要がある。このためには、正確な通信状態を保証するために（即ち、不安定の可能性を低下させるために）、双方のバスから多数の同期点を必要とする。したがって、有効なライト・サイクルが開始する最も早い時点、および当該ライト・サイクルまたは一連のライト・サイクルが終了する最も早い時点を判定することは有利である。したがって、有効なサイクルがライト・サイクルでないことを最も早い時点で判定してHOLDをニゲートし、コントローラ・バスの所有権をプロセッサ３４に返すことが必要である。これによって、プロセッサ３４は、再生シーケンスの実行のような、必要な機能の実行が可能となる。加えて、いつ有効ライト・サイクルが開始するのかを判定し、必要であれば、EXRDYをローに駆動し、これによって遅延サイクルを挿入することも有利である。
【００８５】
拡張バスのクロック信号BCLKは、ライト・サイクルの開始や終了を判定する際には、特に有用ではない。何故なら、このクロック信号はそのいずれとも、即ち、START#の立ち下がりエッジまたはCMD#の立ち上がりエッジのいずれとも同期することが保証されていないからである。ＥＩＳＡバスのタイミング仕様に関する詳細な説明について、ＥＩＳＡ仕様改訂３．１２版(EISA Specification Revision 3.12)を引用する。この内容は、この言及により、本願にも含まれているものとする。
【００８６】
拡張バスのライト／リード信号(W_R)がライト・サイクルを示している場合は、該信号は、拡張バスのアドレス信号(LA)と同じように早くは有効にはならない。ＥＩＳＡバスの仕様によれば、W_Rは、START#がニゲート状態にあるときのBCLKの立ち上がりエッジまで、その有効性を確認することができない。制御ロジック４０は、ライト・サイクルが発生しているか否かについて判定を行い、それ自体はリード・サイクルに応答しないが、代わりにビデオ・サブシステムがリード・サイクルに応答できるようにしなければならない。
【００８７】
ＥＩＳＡ拡張バス信号START#およびCMD#は、START#のニゲートおよびCMD#のアサートに関して、互いに連続して発生することは保証されていない。即ち、これらの２信号は重なり合ったり、その間にギャップが生じる可能性がある。このため、START#の立ち下がりエッジをサイクルの開始を示すために用い、CMD#の立ち上がりエッジをサイクルの終了を示すために用いるために、開始から終了までのサイクル全体を示すことを望む式(equation)は、START#のニゲートとCMD#のアサートとの間の潜在的なギャップを覆うために、何らかの入力を有さなければならない。
【００８８】
例えば、ＥＩＳＡバス・ブリッジとしてバス・インターフェース・ユニット１８を用いた、殆どのバス・インターフェースの実施においては、BCLKがローでSTART#がアサートされてローになると、W_Rは有効になることが本発明者によって規定された。この情報は、有効なライト・サイクルの開始および終了を判定する際に役に立つ。尚、本発明は、次の式で表わされる、透明ラッチ制御信号(transparent latch control signal) N_STARTを採用する。
【００８９】
【数１】
N_START = !BCLK * !START# + N_START * CMD#
したがって、N_STARTは、BCLKがローでSTART#がアサートされたときにアサートされ、CMD#がアサートされてローとなるまでアサートされたまま留まり、前述のSTART#およびCMD#間のギャップを覆うことになる。
【００９０】
ＥＩＳＡ拡張バスのアドレス信号がビデオ・アドレス範囲にあるときに真となる、追加の信号EARLY_DECODEを定義する。
EARLY_DECODE，W_R、CMD#およびN_STARTを組み合わせることにより、有効なライト・サイクルは次のように定義される。
【００９１】
【数２】
【００９２】
このように、制御ロジック４０はN_STARTを用いて、EXRDYに対するＥＩＳＡのタイミング要件を満足し、したがって典型的な状況では割り込みを発生させない、即ち、ビデオ・サブシステムに対する処理では遅延サイクルを導入させないという利点がある。また、ＥＩＳＡ拡張バスおよびコントローラ・バスはクロック信号が異なるので、制御ロジック４０は、N_STARTを用いて、ＥＩＳＡ拡張バスおよびコントローラ・バス間の同期を取る。N_STARTを用いることによって（即ち、BCLKがローの期間）、制御ロジック４０は、有効なライト・サイクルを判定する際に、START#の立ち上がりエッジ（少なくとも６０ナノ秒遅く発生する。即ち、BCLKの立ち上がりエッジと同期して発生する）を用いる場合よりも、同期時間において少なくとも６０ナノ秒の優位を享受するという利点がある。
【００９３】
図１１のタイミング図は、ＥＩＳＡ拡張バス信号BCLK、START#、CMD#、LA、W_RのEARLY_DECODE、HOLD、N_START、VALID_CYCLE、およびEXRDY信号に対する関係を示している。図１１が示すビデオ・ライト・サイクルは、プロセッサ３４がHLDAを十分に早く付与しないため、制御ロジック４０がEXRDYをローに駆動し、第２のビデオ・ライト・サイクルに続いて遅延サイクルを挿入しなければならない場合である。第１および第２のビデオ・ライト・サイクルは、連続ビデオ・ライト・サイクルを構成する。本発明によれば、第２のビデオ・ライト・サイクルは、第１のライト・サイクルが遅延サイクルを誘発しても、遅延サイクルを誘発しないという利点がある。BCLKのエッジには１〜１４まで連続的に付番してあり、図１１の説明の明確化を図っている。図１１に示すHLDA信号は、プロセッサ３４からのHLDA信号を、ＥＩＳＡ拡張バスのクロックBCLKと同期させたものである。
【００９４】
ＥＩＳＡバス・インターフェース１８は、ビデオ・サブシステムに書き込みを行いたいＣＰＵ１２の代わりに、BCLKの立ち下がりエッジ２付近で、LA信号上にビデオ・アドレス範囲のアドレスを発生する。制御ロジック４０は、これに応答して、EARLY_DECODE信号をアサートする。その後すぐに、制御ロジック４０はプロセッサ３４へのHOLDをアサートする。HOLD信号がアサートされるのは、EARLY_DECODE信号がアサートされるときであり、VALID_CYCLE信号がアサートされ続ける限りHOLD信号もアサートされたままでいる。VALID_CYCLEの間中、HOLDをアサートさせ続けることによって、制御ロジック４０は、コントローラ・メモリ３２へのビデオ・データの書き込みが完了するまで、コントローラ・バスの所有権を保持する。加えて、HOLD信号は、EARLY_DECODEがアサートされ、無効タイマ(defeat timer)が終了していない場合にも（以下で論ずる）、アサートされる。HOLD信号はプロセッサ３４のクロックと同期している。BCLKの立ち上がりエッジ３で、バス・インターフェース１８はSTART#（アクティブ・ローの信号）をアサートし、このサイクルのアドレス・フェーズを開始する。バス・インターフェース１８はW_R信号をアサートし、ライト・サイクルであることを示す。
【００９５】
BCLKの立ち下がりエッジ４において、BCLKがローとなり、START#がアサートされてローとなるので、これに応答して制御ロジック４０はN_STARTをアサートする。N_STARTは、BCLKの立ち上がりエッジ５でCMD#がアサートされてローになるまで、アサートされたままでいる。アクティブなN_STARTは、W_Rが有効であることを意味し、W_Rはライト・サイクルを示し、EARLY_DECODEはビデオ・アドレス範囲内のアドレスを示すので、制御ロジック４０は対応してVALID_CYCLEをアサートする。BCLKの立ち下がりエッジ４の後にアサートされたVALID_CYCLEに応答して、（本例では）HLDAが未だ付与されていないので、制御ロジック４０はEXRDYをローに駆動する。本例では、HLDAが付与されるのは、BLCKの立ち上がりエッジ５付近である。制御ロジック４０は、HLDAが付与されるBCLKの次の立ち下がりエッジ、即ち、BCLKの立ち下がりエッジ６の後まで、EXRDYをローに駆動し続ける。何故なら、EXRDYはBCLKの立ち下がりエッジ上でバス・インターフェース・ユニット１８によってサンプリングされ、一方、CMD#はアサートされてローとなるからである。
【００９６】
バス・インターフェース・ユニット１８は、BCLKの立ち上がりエッジ５の後、CMD#をアサートしてローとし、START#をディアサートしてハイとして、ライト・サイクルのデータ・フェーズを開始する。先に注記したように、ここでは、START#の立ち上がりエッジおよびDMD#の立ち下がりエッジは、ＥＩＳＡ拡張バスの仕様によれば、間隔が開くかあるいは重なり合う可能性がある。前述のように、N_STARTはこのギャップを覆うことにより、VALID_CYCLEが有効なビデオ・ライト・サイクルを最初から最後まで示すことができるという利点がある。
CMD#がアサートされてローとなっている間のBLCKの立ち下がりエッジ、即ち、BCLKの立ち下がりエッジ６でローに駆動されたEXRDYに応答して、バス・インターフェース・ユニット１８は、BCLKの立ち上がりエッジ９で１クロック・サイクル余計にCMD#のディアサート（ハイ）を遅らせることによって、余分なBCLKサイクルを待つ、即ち、遅延サイクル（または待機サイクル）を挿入する。CDM#をディアサートしてハイとすることによって、ライト・サイクルの終了を示す。
【００９７】
LA信号上のアドレスは、第２のライト・サイクルの間ビデオ範囲にあり続けるので、制御ロジック４０はEARLY_DECODEをアサートし続け、対応してHOLDもアサートし続けることにより、アサートされたHLDAによって表わされるように、第２のバス・サイクルの終了時までコントローラ・バスの所有権を保持する。
BCLKの立ち上がりエッジ９の後、バス・インターフェース・ユニット１８は（ＥＩＳＡブリッジングを用いて）START#をアサートし、第２のビデオ・ライト・サイクルのアドレス・フェーズの開始を表わす。第２のライト・サイクルは、第１のライト・サイクルと同様であるが、制御ロジック４０が既にコントローラ・バスの所有権を有しているので、EXRDYは第２のライト・サイクルの間、ニゲートされない（ローにならない）点で相違する。したがって、バス・インターフェース・ユニット１８は、BLCKの立ち上がりエッジ１３付近で（即ち、第１のライト・サイクルにおけるよりも１クロック・サイクル分早く）CMD#をディアサートしてハイとし、第２のライト・サイクルのデータ・フェーズを終了する。
また、第２のビデオ・ライト・サイクルは、連続ビデオ・ライト・サイクルではないことも表しており、このサイクルでは、制御ロジック４０がEXRDYをローに駆動して遅延サイクルを挿入する必要がないように、HLDAを十分に早く付与するようにしている。
【００９８】
本発明の一実施例では、サーバ・コントローラ２６は、ビデオ・コントローラ２０とビデオ・メモリ２２から成る、サーバ１０のビデオ・サブシステムに類似したコントローラ・ビデオ・サブシステム（図示せず）を更に備えている。コントローラ・ビデオ・サブシステムは、システム・コンフィギュレーション・ソフトウエアによって選択的にディゼーブルすることができる。コントローラ・ビデオ・サブシステムはＩＳＡ装置である。コントローラ・ビデオ・サブシステムをイネーブルすると、サーバ・コントローラ２６は、ＥＩＳＡ拡張バスのEXRDY信号ではなく、ＩＳＡバスの信号CHRDYをニゲートする。
【００９９】
コントローラ・ビデオ・サブシステムの目的は、サーバ１０上のＶＧＡコントローラがＰＣＩ ＶＧＡコントローラである場合、ビデオ・データの書き込み動作が拡張バス上に現れるようにすることである。これがないと、ＰＣＩ ＶＧＡコントローラがビデオ・ライトをデコードしこれに応答するので、バス・インターフェース・ユニット１８にビデオ・ライトをＥＩＳＡ拡張バスに送出させないようになる。その結果、ＥＩＳＡ拡張バス上にはビデオ・ライト・サイクルがなくなる。即ち、サーバ・コントローラ２６が監視するビデオ・ライト・サイクルがなくなってしまう。したがって、ＰＣＩ ＶＧＡコントローラがシステム内にある場合、ユーザはサーバ・コントローラ２６上のコントローラ・ビデオ・サブシステムをイネーブルし、ＰＣＩ ＶＧＡコントローラをディゼーブルすることにより、ビデオ・ライト・サイクルの監視および再生シーケンスの捕獲ができるようにしなければならない。
【０１００】
バス・インターフェース・ユニット１８（即ち、ＥＩＳＡバス・ブリッジ）の実現においては、拡張バスのアドレス信号上のアドレスを駆動し、拡張バス（即ち、ＥＩＳＡバス）上の当該アドレスをラッチし駆動して、有効なサイクルの終了時に、当該有効サイクルの後に発生するアイドル・サイクルの間、アドレス信号が浮動しないようにすることは一般的である。この状態では、制御ロジック４０にEARLY_DECODE信号をアサートさせ、結果的に、比較的長い時間にわたってプロセッサ３４へのHOLDを連続的にアサートさせる。その結果、プロセッサ３４は不必要に飢える(starved)ことになる。この問題に対する１つの解決策は、CMD#の立ち上がりエッジ上で、サイクルの終了時にHOLDをニゲートすることであろう。しかしながら、その結果、制御ロジック４０は、EXRDYをニゲートして遅れを導入することにより、１ブロックの連続ライト・サイクルの各ライト・サイクル毎に、制御バスの仲裁を再度行い、ＥＩＳＡ拡張バスおよびコントローラ・バス間で再度同期をとらなければならない。
【０１０１】
本発明は、無効タイマを用いて、上述の問題を解決する。制御ロジック４０は、ＥＩＳＡ拡張バスのアドレス信号が未だビデオ・アドレス範囲内のアドレスを有する場合、サイクルの後に所定数のBCLKを計数するカウンタを備えている。START#がアサートされることなく、カウンタが終了カウントに到達した場合、制御ロジック４０はHOLDをニゲートし、制御ロジック４０がビデオ・アドレス範囲内のアドレスをデコードすることによる次のSTART#のアサートまで、HOLDをアサートしない。
【０１０２】
このように、無効タイマを用いることにより、制御ロジック４０は、制御ロジック４０がSTART#のアサートまで待ってHOLDをアサートする場合に可能となるよりも早く、HOLDをアサートし、ビデオ・サブシステムへのビデオ・データの書き込みの間に遅延サイクルを導入しなくても済む可能性が高くなるという利点がある。更に、無効タイマは、制御ロジック４０をイネーブルし、１ブロックの連続有効ビデオ・ライト・サイクルの間、HOLDをアサート状態に保持することにより、ビデオ・サブシステムへのビデオ・データの書き込みの間、サーバ１０に遅延サイクルを導入するのを回避するという利点もある。
【０１０３】
遠隔端末２８は、通信ユニット３６を介して、サーバ・コントローラ２６との通信接続を確立する。遠隔端末２８およびサーバ・コントローラ２６間の接続は、一般的に、帯域外接続(out-of-band connection)または非同期接続と呼ばれている。帯域外接続とは、ローカル・エリア・ネットワーク・イーサネット接続のような標準的なネットワーク媒体を通じてではなく、電話線または直接直列接続を介して確立されるネットワーク接続のことである。帯域外接続を設けることにより、サーバ・コントローラ２６は、サーバ１０が通常に機能している場合、またはオペレーティング・システムのクラッシュや、サーバ１０が接続されているローカル・エリア・ネットワーク上の障害のような障害が発生した場合のいずれの場合にも、遠隔端末２８との通信を確立することができる。
【０１０４】
第１のモードでは、遠隔端末２８は、ＡＮＳＩの端末エミュレーション・プロトコルを用いて、サーバ・コントローラ２６との接続を確立する。このプロトコルのことを以降テキスト・プロトコルと呼ぶことにする。第２のモードでは、遠隔端末２８は、サーバ・コントローラ２６と二地点間プロトコル（ＰＰＰ：point-to-point protocol）を確立する。ＰＰＰについては、Internet Engineering Task Force (「IETF」）に記載されている。そのUniform Resource Locator（「ＵＲＬ」）は、http://www.ietf.cnri.reston.va.us/home.htmlである。特に、ＲＦＣ１６６１、１６６２、１６６３は本発明に関連があり、この言及により本願にも含まれているものとする。遠隔端末２８がサーバ・コントローラ２６を呼び出すと、サーバ・コントローラ２６のプロセッサ３４上で実行するサーバ・コントローラ２６のソフトウエアは、２つのデータ・リンク・レイヤ・プロトコルの内どちらを、遠隔端末２８が使用しているのかを自動的に判定するという利点がある。
【０１０５】
第１のモードでは、サーバ・コントローラ・コンソール・アプリケーションと呼ばれる、サーバ・コントローラ２６のソフトウエアの一部が、テキスト・プロトコルを用いて、遠隔端末２８と通信する。サーバ・コントローラ・コンソール・アプリケーションは、遠隔端末２８が、再生シーケンスの閲覧(viewing)のようなサーバ・コントローラ２６の様々な構成にアクセスできるようにする。加えて、サーバ・コントローラ・コンソール・アプリケーションは、、遠隔リセットの実行、警報およびログイン情報の管理、遠隔地からのコンソールへのアクセス、サーバ１０のイベント・ログ、エラー・ログおよびステータス・ログの閲覧を、システム管理者に可能とする。図２のａ〜ｃを再び参照すると、サーバ・コントローラ・コンソール・アプリケーションの３種類のメニュー画面が示されている。遠隔端末２８は、通常、コンピュータであり、既知の製品であるSYMANTEC pcANYWHEREまたはDATASTORM TECHNOLOGY ProComm のような、種々の販売会社から入手可能な一般的なＡＮＳＩの端末エミュレーション・ソフトウエア・アプリケーションを実行することによって、サーバ・コントローラ２６と通信を行う。
【０１０６】
第２のモードでは、遠隔端末２８は、ローカル・エリア・ネットワーク（ＬＡＮ）のそれと同様のＰＰＰ接続を通じて、サーバ・コントローラ２６とのＴＣＰ／ＩＰリンクを確立する。遠隔端末２８はCOMPAQ Insight Manager (CIM)を実行し、ＴＣＰ／ＩＰ接続を通じてサーバ・コントローラ２６との通信を行う。サーバ・コントローラ２６は、２つの方法で、ＣＩＭと通信を行う。すなわち、第１に、サーバ・コントローラ２６は、TELNET接続を通じてＣＩＭと通信を行い、テキスト・プロトコルを用いる第１モードと全く同様に、サーバ・コントローラ・コンソール・アプリケーションを実行する。
【０１０７】
第２に、サーバ・コントローラ２６は、サーバ１０を管理する目的のために、ＣＩＭに対して、SNMPパケットの送受信を行う。例えば、サーバ１０はサーバ１０上の障害またはその他のイベントを検出し、SNMPトラップ・パケットを、サーバ・コントローラ２６を通じて、遠隔端末２８上で実行中のＣＩＭに送り、サーバ１０が接続されているＬＡＮ上のクライアント上でＣＩＭが実行されているかのように、システム管理者にそのイベントについて通知する。加えて、サーバ１０の障害の場合、サーバ・コントローラ２６はその障害を検出し、SNMPトラップ・パケットをＣＩＭに自動的に送る。この第２のモード、即ち、ＰＰＰ接続によるモードでは、サーバ・コントローラ２６は、同時に、サーバ・コントローラ・コンソール・アプリケーションおよびSNMPパケットによって、遠隔端末２８と通信を行うこともできる。
【０１０８】
ＣＩＭによるサーバ１０の管理の別の例は、遠隔端末２８がサーバ・コントローラ２６を通じて「要求獲得」SNMPパケットをサーバ１０に送り、サーバのサブシステムの１つの状態(health)のような、サーバに関する管理情報を要求することである。サーバ・コントローラ２６はSNMPパケットをオペレーティング・システムに送出する。オペレーティング・システムは、要求された情報を集め、「応答獲得」パケットをサーバ・コントローラ２６に送る。一方、サーバ・コントローラ２６はパケットをＣＩＭに送出する。
【０１０９】
WINDOWS NTのRemote Access Services （ＲＡＳ）は、ＰＰＰ接続を確立し、ヌル・モデム(null-modem)によって接続された２台のコンピュータ間の通信を提供する。ＮＴ ＲＡＳはこのＰＰＰ接続を確立する、所有権を主張する方法(proprietary method)を用いる。この方法のことを以降「予備ＰＰＰプロトコル」(pre-PPP protocol)と呼ぶことにする。これは２台のコンピュータ間で１対の文字列を交換するためのものである。接続を確立したい第１のコンピュータが、文字列"CLIENT"を第２のコンピュータに送る。次に、第２のコンピュータは、"CLIENT"文字列を受け取った後、文字列"CLIENTSERVER"を第１のコンピュータに送る。一旦この２つの文字列の交換が行われたなら、２台のコンピュータは必要な文字パケットの交換に進み、ＰＰＰ接続を確立する。標準的なＰＰＰ接続では、この２つの文字列の初期交換は必要でない。サーバ・コントローラ２６は、ヌル・モデムを通じたＮＴ ＲＡＳとのＰＰＰ接続、および標準的なＰＰＰプロトコルを用いた遠隔端末２８とのＰＰＰ接続の双方を確立することができる。
【０１１０】
次に図１２を参照すると、サーバ・コントローラ２６がどの通信プロトコルが遠隔端末２８から送られているのかをどのようにして検出するのかを示すフローチャートが示されている。遠隔端末２８が接続を確立する前に、サーバ・コントローラ２６のソフトウエアは、ステップ１３０において、サーバ・コントローラ２６のソフトウエアの中にある３つの状態マシンをリセットする。テキスト・プロトコル、ＰＰＰプロトコル、および予備ＰＰＰプロトコルという有効なプロトコル各々に１つの状態マシンが存在する。
【０１１１】
サーバ・コントローラ２６が通信ユニット３６からの割り込みを待っている間、プロセッサ３４は再生シーケンスを処理することができる。キャリア信号がサーバ・コントローラ２６上で受信されたとき、コントローラ２６内のソフトウエアは、ステップ１３４において、状態マシンをリセットし、ステップ１３６においてタイマを設定する。一実施例では、タイマは３０秒後に終了するように設定される。サーバ・コントローラ２６のソフトウエアは、ステップ１３８において、タイマが終了したか否かについて判定を行う。タイマが終了していた場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４０において、サーバ・コントローラ２６内の上位タスクに、プロトコルはテキスト・プロトコルであると伝達することによって、プロトコルがテキスト・プロトコルであることを宣言する。
【０１１２】
遠隔端末２８から文字または信号を受信する前に、サーバ・コントローラ２６内のソフトウエアはビデオ画面変化を処理することができる。一旦割り込みが発生し、文字または信号の存在が示されたなら、サーバ・コントローラ２６のソフトウエアは、ステップ１４２において、「無キャリア」信号が通信ユニット３６から送られて、遠隔端末２８からキャリアの損失が示されたか否かについて判定を行う。キャリアが失われていた場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４４において、タイマをクリアし、ステップ１３０に戻る。
【０１１３】
ステップ１４２において「無キャリア」信号が受信されなかった場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４６において、文字が受信されたか否かについて判定を行う。受信されていない場合、サーバ・コントローラ２６のソフトウエアはステップ１３８に戻り、タイマが終了するのを待つか、あるいは信号または文字が到達したことを示す割り込みが受信されるのを待つ。
【０１１４】
ステップ１４６において文字が受信された場合、サーバ・コントローラ２６のソフトウエアは、ステップ１４８において、その文字を３つのプロトコルの状態マシンに渡す。ステップ１５０において、状態マシンに有効なプロトコルを検出したものがない場合、サーバ・コントローラ２６のソフトウエアはステップ１３８に戻る。ステップ１５０において、状態マシンの内の１つが有効なプロトコルを検出した場合、サーバ・コントローラ２６のソフトウエアはステップ１５２においてタイマをクリアし、次にステップ１５４において、３つのプロトコルの内どれが検出されたのかを上位タスクに宣言する。
【０１１５】
プロセッサ３４は、図１１の説明において述べた通信ユニット３６のような種々の割り込みソースからの割り込みを受け取るように構成されている。プロセッサ３４は、割り込み記述子テーブルを備えており、テーブル内の各エントリが、割り込みソースに対応する割り込みサービス・ルーチンを参照する。割り込みソースの１つが割り込みを発生した場合、プロセッサ３４は、この割り込みソースに対応する割り込み記述子テーブル内のエントリによって参照される、割り込みサービス・ルーチンの実行を開始する。割り込みサービス・ルーチンはサーバ・コントローラ２６のソフトウエアの一部であり、プロセッサ３４上で実行する。通信ユニット３６は、遠隔端末２８からの文字、あるいは「キャリア」または「無キャリア」のような信号の受信時に、プロセッサ３４に割り込みをかけるように構成されている。割り込みサービス・ルーチンは、プロセッサ３４上で実行する他のソフトウエア・タスクと通信を行い、遠隔端末２８との通信に便宜を図る。
【０１１６】
最初に、即ち、遠隔端末２８がサーバ・コントローラ２６との接続を確立する前に、通信ユニット３６に対応する割り込み記述子テーブルのエントリは、プロトコル検出割り込みサービス・ルーチンへの参照によって、分類される(populate)。プロトコル検出割り込みサービス・ルーチンは、サーバ・コントローラ２６のソフトウエアの、３つのプロトコル状態マシンを含む部分である。また、プロトコル検出割り込みサービス・ルーチンは、サーバ・コントローラ２６のソフトウエアの、通信ユニット３６から入来する文字を受け取るソフトウエアの部分でもある。プロトコル検出割り込みサービス・ルーチンによって受け取られる各文字は、３つのプロトコル状態マシンへの入力として作用する。
【０１１７】
一旦ステップ１４０またはステップ１５４のいずれかにおいて有効なプロトコルが検出されたことが上位タスクに通知されたなら、上位タスクは、検出された特定のプロトコルに専用の割り込みサービス・ルーチンへの参照により、通信ユニット３６に対応する割り込み記述子テーブルのエントリを分類する。ＰＰＰおよび予備ＰＰＰプロトコルは、同じ割り込みサービス・ルーチンを有する。
【０１１８】
表１２〜１６（表１２には表１３が、表１３には表１４が、表１５には表１６が、それぞれ連続する）に示される補足資料は、ＰＰＰ割り込みサービス・ルーチンの部分のアセンブリ言語によるソース・コード・リストである。このコード部分は、割り込みサービス・ルーチンがどのようにして入来する文字を受け取って処理し、有効なＰＰＰパケット全体の有効性の判断および／またはこのＰＰＰパケットの形成を行うかを示したものである。一旦ＰＰＰパケットが形成されたなら、割り込みサービス・ルーチンは、当該パケットの存在に関して、サーバ・コントローラ２６のソフトウエアの上位タスクに通知する。
【０１１９】
【表１２】
次に図１３を参照すると、テキスト・プロトコルの状態マシンを表わす状態図が示されている。テキスト・プロトコルの状態マシンが３つの連続したアスキー「リターン」文字（0X20）を検出した場合、遠隔端末２８から有効なテキスト・プロトコルが検出されたことを示す。TEXT_INT状態１５６において、状態マシンがキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_ONE状態１５７に遷移する。その他の場合、状態マシンはTEXT_INT状態１５６に留まる。TEXT_ONE状態１５７において、状態マシンがキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_TWO状態１５８に遷移する。その他の場合、状態マシンはTEXT_INIT状態１５６に戻る。TEXT_TWO状態１５８において、状態機械がキャリッジ・リターン文字を受け取った場合、状態マシンはTEXT_DETECTED状態１５９に遷移する。その他の場合、状態マシンはTEXT_INIT状態１５６に戻る。状態マシンがTEXT_DETECTED状態１５９になった場合、サーバ・コントローラ２６のソフトウエアの上位タスクに、有効なテキスト・プロトコルが検出されたことを通知する。
【０１２１】
図１４は、予備ＰＰＰの状態マシンを表わす状態図が示されている。予備ＰＰＰ状態マシンが文字列"CLIENT"を検出した場合、遠隔端末２８から有効な予備ＰＰＰプロトコルが検出され、対応して文字列"CLIENTSERVER"を遠隔端末２８に送信することを示す。CLIENT_INT状態１６２において、状態マシンが「Ｃ」を受け取った場合、状態マシンはCLIENT_C状態１６３に遷移する。その他の場合、状態マシンはCLIENT_INT状態１６２に留まる。CLIENT_C状態１６３において、状態マシンが「Ｌ」を受け取った場合、状態マシンはCLINET_L状態１６４に遷移する。この進展は、以降の状態１６４、１６５、１６６の各々についても維持され、文字列"CLIENT"の可能な受け取りを示す。この文字列が完全に受け取られなかった場合、CLIENT_INIT状態１６２に戻る遷移が行われる。文字列全体を受け取ったときに、状態マシンはCLIENT_DETECTED状態１６８に遷移し、サーバ・コントローラ２６のソフトウエアにおける上位タスクに、有効な予備ＰＰＰプロトコルが検出されたことを通知する。
【０１２２】
以下に示すのは、有効なＰＰＰパケットを形成する文字列のフォーマットである。
【０１２３】
SYNCH ADDRESS CONTROL PROTOCOL ... data ... CRClow CRChigh SYNCH
SYNCH文字は１６進数の値０ｘ７Ｅで表され、ADDRESS文字は１６進数の値０ｘＦＦで表され、CONTROL文字は１６進数の値０ｘ０３で表わされる。ADDRESSおよびCONTROL文字は任意であるが、一方がある場合、両方の文字がなければならない。PROTOCOL文字（群）は、最初のバイトの最下位ビット（ＬＳＢ）に応じて、１バイトまたは２バイトとなる。最初のバイトの最下位ビットがセットされている（即ち、１）場合、PROTOCOL文字は、圧縮された１プロトコル・バイトのみから成る。最初のバイトのＬＢＳがクリアされている（即ち、０）場合、PROTOCOL文字は、圧縮されていない２プロトコル・バイトから成り、第１のバイトが下位バイト、第２のバイトが上位バイトとなる。「データ」バイトはパケットのペイロードである。ＣＲＣlowおよびＣＲＣhigh文字は、それぞれ、データ・バイト上の巡回冗長度チェック（ＣＲＣ）の下位および上位バイトから成る。
【０１２４】
図１５を参照すると、ＰＰＰの状態マシンを表わす状態図が示されている。ＰＰＰの状態マシンが有効なＰＰＰパケットを検出した場合、遠隔端末２８から有効なＰＰＰプロトコルが検出されたことを示す。PPP_INIT状態１７０において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、状態マシンはPPP_INT状態１７０に留まる。PPP_SYNCH状態１７２において、状態マシンがADDRESS文字を受け取ると、PPP_ADDRESS状態１７４に遷移する。その他の場合、状態マシンはPPP_CONTROL状態１７６に遷移する。PPP_ADDRESS状態１７４において、状態マシンがCONTROL文字を受け取ると、状態マシンはPPP_CONTROL状態１７６に遷移する。あるいは、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、状態マシンはPPP_INT状態１７０に遷移する。PPP_CONTROL状態１７６において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移する。その他の場合、文字のＬＳＢがクリアされているなら、PPP_NOT_COMPRESSED状態１７８に遷移し、この文字を非圧縮２プロトコル・バイトの下位バイトとして扱い、この文字のＬＳＢがセットされているなら、PPP_COMPRESSED状態１８０に遷移し、この文字を単一の圧縮プロトコル・バイトとして扱う。PPP_NOT_COMPRESSED状態１７８において、状態マシンがSYNC文字を受け取ると、PPP_SYNCH１７２状態に遷移する。その他の場合、状態マシンはPPP_COMPRESSED状態１８０に遷移し、非圧縮２プロトコル・バイトの上位バイトとしてこの文字を扱う。PPP_COMPRESSED状態１８０において、状態マシンがSYNCH文字を受け取ると、状態マシンはPPP_DETECTED状態１８２に遷移する。その他の場合、状態マシンはPPP_COMPRESSED状態１８０に留まり、この文字をデータまたはＣＲＣバイトとして扱う。状態マシンがPPP_DETECTED状態１８２に到達した場合、サーバ・コントローラ２６のソフトウエア内の上位タスクに、有効なＰＰＰプロトコルが検出されたことを通知する。
【０１２５】
サーバ・コントローラ２６は、任意のダイアル・バック・セキュリティ(dial-back security)機能を備え、無許可のユーザがサーバ・コントローラ２６を通じてサーバ１０を不正に変更するのを防止する。サーバ・コントローラ２６のコンソール・アプリケーション・ソフトウエアを用いて、システム管理者は、各々ユーザ名、パスワードおよび電話番号を含むユーザ・プロファイルのリストを構成する。ユーザが発信してきた場合、サーバ・コントローラ２６はユーザからユーザ名およびパスワードを受信し、ユーザ・プロファイルのリストからそのユーザ名およびパスワードを確認し、そして切断する。ユーザ名およびパスワードがユーザ・プロファイルのリストにおいて確認された場合、サーバ・コントローラ２６は、ユーザ・プロファイルのリスト内にある対応する電話番号を呼び出す。許可されているユーザには、遠隔アクセスは通常通りに進む。万一侵入者が有効なユーザ名およびパスワードを得ても、しかしながら、侵入者には呼び出しがかからないので、侵入者はサーバ１０への接続を失うことになる。
【０１２６】
サーバ・コントローラ２６は、ユーザが発信してきたときに用いられたのと同じ通信プロトコルによって、許可されたユーザに呼び出しをかけるという利点がある。例えば、ユーザが予備ＰＰＰプロトコルを用い、WINDOWS NT機からヌル・モデムを通じて接続した場合、サーバ・コントローラ２６は予備ＰＰＰプロトコルを用いてこのNT機に呼び出しをかける。遠隔端末は、それが発信したのと同じプロトコルを用いてサーバ・コントローラ２６と通信することを期待する場合が多いので、これは有用である。
【０１２７】
次に図１６を参照すると、ＰＣＢ２００上に配置された、サーバ・コントローラ２６の様々な構成要素が示されている。ＰＣＢ２００は、複数のプレーン(plane)即ち部分に分離されている。第１部分２０２は拡張バス・インターフェース・ユニット２０４および検出ロジック３０を収容する。第２部分２０６はプロセッサ３０およびコントローラ・メモリ３２、ならびに参照番号２０８で示す二次電源（即ち、電池）を収容する。第３部分２１０は通信ユニット（即ち、モデム）３６を収容する。部分２０２、２０６、２１０は、第１の遮断ユニット２１２および第２の遮断ユニット２１４として示す１対の遮断ユニットによって、互いに分離されている。
【０１２８】
ＰＣＢ２００への電力は、通常、ＰＣＢ２００を接続可能な拡張バスから、エッジ・コネクタ２１６を介して供給される。エッジ・コネクタ２１６のピンの内１本は、第１、第２および第３部分２０２、２０６、２１０にそれぞれ供給される主要電源ＶＤＤのために用いられる。表示データは拡張バスから監視され、エッジ・コネクタ２１６の恐らく数本のピンを通じて、インターフェース・ユニット２０４を通じて検出ロジック３０に送出される。例えば、サーバの停電の間にＶＤＤが失われると、遮断ユニット２１２は２つの機能を果たす。まず、第１部分２０２内の電力用導体を、第２部分２０６の電力用導体から切断する。より具体的には、第１部分２０２内のＶＤＤ導体は、遮断ユニット２１２によって、第２部分２０６内の電力用導体または導体群から切断される。第２に、第１部分２０２内の信号用導体は、第２部分２０６内の信号用導体から切断される。信号用導体が切断されると、信号用導体は三状態化する(tri-stated)。
【０１２９】
第１の遮断ユニット２１２と同様、第２の遮断ユニット２１４も電力用導体および信号用導体を切断する。拡張バスからＶＤＤが遮断され、更に通信ユニット３６が遠隔端末２８からの通信を検出できなくなった場合、第２の遮断ユニット２１４はその切断処理を実行する。しかしながら、ＶＤＤが得られる場合、または遠隔端末２８が通信プロトコルを送っている場合、第２の遮断ユニット２１４は、第２および第３部分２０８、２１０間の結合を行う。
【０１３０】
遮断ユニット２１２、２１４は、電力用導体上にクイック・スイッチを備え、更に信号用導体間にバッファ／ドライバ機能を有する双方向トランシーバを備えていることが好ましい。クイック・スイッチは、National Semiconductor Corp.およびTexas Instruments, Inc.等の販売会社から入手可能であり、共通の制御入力（即ち、出力イネーブルOE入力）を有するパッケージ化されたＪＦＥＴのアレイとして形成されている。双方向トランシーバは、高容量性負荷を駆動するのに非常に適しており、高速で動作する。適切な双方向トランシーバは、integrated Device Technology, Inc.またはTexas Instruments, Inc. から、三状態出力機能を有する高速ＣＭＯＳトランシーバとして入手可能である。
【０１３１】
エッジ・コネクタ２１６のピンの１つには、充電用導体２２０が結合されている。充電用導体２２０は、拡張バスから供給されＶＤＤよりも高く設定された電圧を受けるように構成されている。一実施例によれば、充電用導体２２０上の所望の電圧は１２ボルトであり、この場合、ＶＤＤは５ボルトである。充電用導体２２０によって供給される電圧は、電池２０８を充電するだけでなく、スイッチング・レギュレータ２２２のスイッチングをイネーブルするように作用する。例えば、充電用導体２２０内の電荷がスレショルド値よりも低下した場合、スイッチング・レギュレータ２２２は、第２部分２０６および恐らく第３部分２１０に電池２０８を結合するように機能する。逆に、充電用導体２２０上の電荷がスレショルド値を超過している場合、電池２０８からの出力（即ち、ＶＤＤＢ）は第２部分２０６および第３部分２１０には結合されない。代わりに、後者の場合、そこにＶＤＤが供給される。ダイオード２２４を用いて、導体２２０上の電荷を終了させる期間中、電池２０８の放電を防止する。
【０１３２】
呼び出し指示器２２６が、第２部分２０６と同じ電力プレーンに結合されている。具体的には、呼び出し指示器２２６は、ＶＤＤがない期間中、導体２２８上のＶＤＤＢを受け取り、ＶＤＤがある場合ＶＤＤを受け取る。したがって、呼び出し指示器２２６は、主電源または二次電源のいずれかから電力を維持し、入来するアナログ呼び出しARNG信号を検出する。ARNGの受信時に、呼び出し指示器２２６は、デジタル呼び出しＤＲＮＧ信号を通じて、結果的に得られる通信プロトコルを通信ユニット３６に送出する。常に呼び出し指示器２２６に電力を維持することによって、入来する呼び出しの検出は、ＶＤＤの状態には無関係に、常に可能となる。
【０１３３】
図１７は、ＶＤＤがＶＤＤＢよりもスレショルド量だけ少なくなったか否かについて判定を行う際に使用される比較器２３０を示す。ＶＤＤが偶然許容可能なスレショルドを越えて低下した場合、比較器２３０はVDDOFF信号を生成する。VDDOFF信号は、第１遮断ユニット２１２の遮断出力イネーブルOEピン上に現れる。これによって、拡張バスによって供給されるＶＤＤが電池２０８によって供給されるＶＤＤＢよりも低くなった場合に、比較器２３０は、信号用導体および電力用導体の遮断を行う。
【０１３４】
図１８は、デジタル呼び出しDRNG信号の動作、ならびに第２部分２０６および第３部分２１０間の電力用導体および信号用導体の遮断に対するその効果について示すものである。通信ユニット３６への電力が最初にオフになっている場合、通信ユニット３６へのDRNG信号はプロセッサ３４に割り込みを発生する。こうして、プロセッサ３４は、通信ユニット３６に呼び出し信号があることを通知され、これにより、プロセッサ３４はMDMACT信号を通じてそれ自体の割り込みを承認し、かつMDMPWR信号を通じてモデムへの電力供給を承認する。より具体的には、MDMPWR信号は第２の遮断ユニット２１４の出力イネーブルOE入力に供給される。入来する呼び出しを示すMDMPWRを受信すると、第２の遮断ユニット２１４は、第２部分２０６および第３部分２１０間に延びる電力用導体および信号用導体を結合する。本質的には、DRNGは、通信ユニット３６がオンかオフかを示す信号によってゲートされ、このゲートの出力が、プロセッサ３４への割り込みとなる。プロセッサ３４が割り込みを受け取ったときはいつでも、プロセッサ３４のＶＤＤＢからの電力は通信ユニット３６に供給される。通信ユニット３６への電力がオンである場合、割り込みはアサートされない。
【０１３５】
本発明は多種多様のコンピュータ・システム、多種多様の電気的構成物、多種多様のＰＣＢおよび多種多様の通信プロトコルを用いた応用が可能であることは、本開示から当業者には明らかであろう。更に、ここに示しかつ記載した本発明の形態は、現状における好適な実施例として捕らえるべきことは理解されよう。特許請求の範囲に記載してある本発明の主旨および範囲から逸脱することなく、様々な修正や変更が可能である。したがって、特許請求の範囲はかかる修正や変更全てを含むものとして解釈し、この明細書および図面は限定的な意味ではなく例示的な意味で捕らえるべきことを意図するものである。
【図面の簡単な説明】
【図１】本発明による、遠隔端末からアクセス可能なサーバ・コントローラを用いて構成を変更したホスト・サーバのブロック図である。
【図２】遠隔端末からのアクセスに応答して、サーバ・コントローラが遠隔端末の表示画面に送出する、３種類の画面表示メニューを示す図である。
【図３】図１に示したビデオ・メモリおよびビデオ制御レジスタ（ビデオ・コントローラ内）に使用可能なメモリ・アドレス空間およびＩ／Ｏアドレス空間の部分を示す図である。
【図４】サーバ・コントローラの詳細ブロック図である。
【図５】図４に示すプロセッサによって用いられ、サーバＣＰＵから拡張バスに送られる一連のビデオ画面の処理および記憶を行うための種々のバッファのブロック図である。
【図６】所定の連続ビデオ画面を記憶する際に、サーバ・コントローラによって実行されるステップを示すフローチャートである。
【図７】所定の連続ビデオ画面を記憶する際に、サーバ・コントローラによって実行されるステップを示すフローチャートである。
【図８】遠隔端末上でリセット時のビデオ画面シーケンスを再生する際に、図４のプロセッサが実行するステップを示すフローチャートである。
【図９】遠隔端末上で障害時のビデオ画面シーケンスを再生する際に、図４のプロセッサが実行するステップを示すフローチャートである。
【図１０】代表的な障害時画面シーケンスとして提示する表示シーケンスを表わす図である。
【図１１】拡張バスの侵入および非侵入が発生する２つの別個のビデオ・ライト・サイクルを示す、種々のＥＩＳＡ拡張バス信号のタイミング図である。
【図１２】遠隔端末によって使用可能な種々の通信プロトコルを検出する際に、サーバ・コントローラが実行するステップを示すフローチャートである。
【図１３】遠隔端末から送られたテキスト通信プロトコルを検出する際に使用する、テキスト・プロトコルの状態マシンを示す状態図である。
【図１４】遠隔端末から送られた予備二地点間（ＰＰＰ）通信プロトコルを検出する際に使用する、予備ＰＰＰプロトコルの状態マシンを示す状態図である。
【図１５】遠隔端末から送られたＰＰＰ通信プロトコルを検出する際に使用する、ＰＰＰのプロトコル状態マシンを示す状態図である。
【図１６】拡張バス上で結合するように構成されたＰＣＢ上で実施されるサーバ・コントローラを示すブロック図である。
【図１７】図１６の前記ＰＣＢ内に配置されている電力プレーン間に延在する信号導体を遮断する際に使用する比較ロジックを示す図である。
【図１８】通信ユニットが遠隔端末から信号を受信している間に、信号導体を結合し、通信ユニットの電力プレーンに給電するために用いられる信号を示す説明図である。
Claims (4)
- サーバ・コントローラにおいて、
コントローラ・メモリとプロセッサとの間に配置されたコントローラ・バスと、
サーバと関連する拡張バスと前記コントローラ・バスとの間に結合されており、前記拡張バス上の表示データの書き込みサイクルを検出し、該表示データを、前記書き込みサイクルが終了する前に、前記コントローラ・メモリに送る検出ロジックと
を備え、
前記プロセッサは、前記コントローラ・バスのマスタシップを前記検出ロジックに許可して、該検出ロジックが前記拡張バス上に信号をアサートして、前記コントローラ・バスの他のマスタシップが前記検出ロジックに許可されるまで、書き込みサイクルの終了を阻止するよう構成されている
ことを特徴とするサーバ・コントローラ。 - 請求項１記載のサーバ・コントローラにおいて、
前記検出ロジックは、前記書き込みサイクルの終了の後に前記拡張バスのクロック・サイクルの所定数をカウントするデフィート・タイマを備え、
前記検出ロジックは、前記所定数の拡張バスのクロック・サイクルが終了すると、前記コントローラ・バスのマスタシップを放棄するよう構成されている
ことを特徴とするサーバ・コントローラ。 - 請求項１又は２記載のサーバ・コントローラにおいて、前記検出ロジックは、ビデオ・アドレス範囲内で生じた書き込みサイクルを復号化するよう構成されていることを特徴とするサーバ・コントローラ。
- 拡張バスを介してサーバからビデオ・コントローラへ送られる表示データの書き込みサイクルをスヌーピングする方法において、
ビデオ・アドレス範囲中で生じる表示デバイスに向けられた表示データの書き込みサイクルを検出するステップと、
コントローラ・メモリに結合されている検出ロジックによって、前記拡張バス上に信号をアサートして書き込みサイクルの終了を阻止することにより、コントローラ・バスのマスタシップを取得するステップと、
前記書き込みサイクルの中で生じる前記表示データを、前記表示データが前記ビデオ・コントローラに送られるのとほぼ同時に、前記コントローラ・メモリに送るステップと、
前記書き込みサイクルの終了時に、前記検出ロジックによって、前記コントローラ・バスのマスタシップを廃棄するステップと
を含むことを特徴とする方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US697678 | 1996-08-17 | ||
| US08/697,678 US6233634B1 (en) | 1996-08-17 | 1996-08-17 | Server controller configured to snoop and receive a duplicative copy of display data presented to a video controller |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10116255A JPH10116255A (ja) | 1998-05-06 |
| JP3641354B2 true JP3641354B2 (ja) | 2005-04-20 |
Family
ID=24802102
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22133297A Expired - Lifetime JP3641354B2 (ja) | 1996-08-17 | 1997-08-18 | 分散型のコンピュータ・システム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6233634B1 (ja) |
| EP (1) | EP0825536B1 (ja) |
| JP (1) | JP3641354B2 (ja) |
| DE (1) | DE69718859T2 (ja) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6026218A (en) * | 1997-06-11 | 2000-02-15 | Sun Microsystems, Inc. | Computer system employing a bus snooping multimedia subsystem for implementing video multicast transactions |
| JP4046804B2 (ja) * | 1997-06-26 | 2008-02-13 | 富士通株式会社 | サーバの情報提供装置、サーバの情報提供プログラムを記録したコンピュータ読み取り可能な記録媒体およびサーバの情報提供方法 |
| US6750876B1 (en) * | 1997-11-16 | 2004-06-15 | Ess Technology, Inc. | Programmable display controller |
| US20060069657A1 (en) * | 1998-10-01 | 2006-03-30 | Freeny Charles C Jr | Multiple customer and multiple location PC service provider system |
| EP1145218B1 (en) * | 1998-11-09 | 2004-05-19 | Broadcom Corporation | Display system for blending graphics and video data |
| US6636222B1 (en) * | 1999-11-09 | 2003-10-21 | Broadcom Corporation | Video and graphics system with an MPEG video decoder for concurrent multi-row decoding |
| US6661422B1 (en) * | 1998-11-09 | 2003-12-09 | Broadcom Corporation | Video and graphics system with MPEG specific data transfer commands |
| US6798420B1 (en) | 1998-11-09 | 2004-09-28 | Broadcom Corporation | Video and graphics system with a single-port RAM |
| US7982740B2 (en) | 1998-11-09 | 2011-07-19 | Broadcom Corporation | Low resolution graphics mode support using window descriptors |
| US6768774B1 (en) | 1998-11-09 | 2004-07-27 | Broadcom Corporation | Video and graphics system with video scaling |
| US6577861B2 (en) * | 1998-12-14 | 2003-06-10 | Fujitsu Limited | Electronic shopping system utilizing a program downloadable wireless telephone |
| US20020099886A1 (en) * | 1999-05-17 | 2002-07-25 | Emerson Theodore F. | System and method for controlling remote console functionality assist logic |
| US6664969B1 (en) * | 1999-11-12 | 2003-12-16 | Hewlett-Packard Development Company, L.P. | Operating system independent method and apparatus for graphical remote access |
| US20020082927A1 (en) * | 2000-11-22 | 2002-06-27 | Borenstein Nathaniel S. | Intelligent caching routers |
| US6724360B2 (en) * | 2001-04-25 | 2004-04-20 | Citizen Watch Co., Ltd. | Antiferroelectric liquid crystal display |
| US20030041162A1 (en) * | 2001-08-27 | 2003-02-27 | Hochmuth Roland M. | System and method for communicating graphics images over a computer network |
| US20030058248A1 (en) * | 2001-09-21 | 2003-03-27 | Hochmuth Roland M. | System and method for communicating graphics over a network |
| US20030065864A1 (en) * | 2001-10-03 | 2003-04-03 | Dell Products L.P. | System and method supporting remote data processing system management |
| US6874060B2 (en) | 2001-12-07 | 2005-03-29 | Dell Products L.P. | Distributed computer system including a virtual disk subsystem and method for providing a virtual local drive |
| US7287107B2 (en) * | 2002-01-04 | 2007-10-23 | Hewlett-Packard Development Company, L.P. | Method and apparatus for passive PCI throttling in a remote server management controller |
| US7038696B2 (en) * | 2002-01-04 | 2006-05-02 | Hewlett-Packard Development Company | Method and apparatus for implementing color graphics on a remote computer |
| US7293102B2 (en) * | 2002-03-26 | 2007-11-06 | Hewlett-Packard Development Company | Method and apparatus for storing data and replaying stored data in a temporally accurate manner |
| US8063916B2 (en) | 2003-10-22 | 2011-11-22 | Broadcom Corporation | Graphics layer reduction for video composition |
| US7403204B2 (en) * | 2004-08-23 | 2008-07-22 | Hewlett-Packard Development Company, L.P. | Method and apparatus for managing changes in a virtual screen buffer |
| US8825833B2 (en) * | 2005-03-30 | 2014-09-02 | International Business Machines Corporation | Tracking computer system configuration changes with corresponding message responses |
| US8949404B2 (en) * | 2005-05-24 | 2015-02-03 | Hewlett-Packard Development Company, L.P. | Acquiring graphical operating system post-failure screen |
| US7944451B2 (en) * | 2007-07-31 | 2011-05-17 | Hewlett-Packard Development Company, L.P. | Providing pixels from an update buffer |
| US20090055157A1 (en) * | 2007-08-23 | 2009-02-26 | Beyond Blades Ltd. | Server Having Remotely Manageable Emulated Functions |
| JP5180729B2 (ja) * | 2008-08-05 | 2013-04-10 | 株式会社日立製作所 | 計算機システム及びバス割当方法 |
| CN102479138A (zh) * | 2010-11-29 | 2012-05-30 | 鸿富锦精密工业（深圳）有限公司 | 利用图像进行错误侦测的系统及方法 |
| JP5889848B2 (ja) * | 2013-08-28 | 2016-03-22 | 京セラドキュメントソリューションズ株式会社 | 情報処理端末、印刷用プログラム、印刷装置及び印刷システム |
| TW201509151A (zh) * | 2013-08-30 | 2015-03-01 | Ibm | 具安全防護連結之遠端診斷的方法與電腦程式產品及實施該方法之資訊設備 |
| US10789197B2 (en) * | 2017-05-12 | 2020-09-29 | Jinghui Zhu | Methods and system for providing software defined microcontroller unit (MCU) |
| US11550281B2 (en) | 2017-05-12 | 2023-01-10 | Gowin Semiconductor Corporation | Method and system for providing programmable microcontroller unit (MCU) using two-phase configuration process |
| JP6706278B2 (ja) * | 2018-03-27 | 2020-06-03 | キヤノン株式会社 | 情報処理装置、及び情報処理方法 |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4232377A (en) | 1979-04-16 | 1980-11-04 | Tektronix, Inc. | Memory preservation and verification system |
| US4281315A (en) * | 1979-08-27 | 1981-07-28 | Bell Telephone Laboratories, Incorporated | Collection of messages from data terminals using different protocols and formats |
| EP0079885A4 (en) | 1981-05-27 | 1984-03-01 | Mostek Corp | POWER SUPPLY CONTROL FOR AN INTEGRATED CIRCUIT. |
| US4866600A (en) * | 1983-04-27 | 1989-09-12 | Tandy Corporation | Computer video control system |
| US4528459A (en) | 1983-06-10 | 1985-07-09 | Rockwell International Corporation | Battery backup power switch |
| JPS61133454A (ja) * | 1984-12-03 | 1986-06-20 | Hitachi Ltd | 端末制御方式 |
| US4777626A (en) | 1984-12-22 | 1988-10-11 | Tokyo Electric Co., Ltd. | Memory device having backup power supply |
| US4683469A (en) * | 1985-03-14 | 1987-07-28 | Itt Corporation | Display terminal having multiple character display formats |
| US4924210A (en) * | 1987-03-17 | 1990-05-08 | Omron Tateisi Electronics Company | Method of controlling communication in an ID system |
| US4984211A (en) | 1988-02-16 | 1991-01-08 | Texas Instruments Incorporated | Battery backup bus scheme for an ECL BiCMOS SRAM |
| JPH0695350B2 (ja) | 1988-08-12 | 1994-11-24 | 三菱電機株式会社 | Ｉｃメモリカード用バッテリ回路 |
| US5043919A (en) * | 1988-12-19 | 1991-08-27 | International Business Machines Corporation | Method of and system for updating a display unit |
| US5063494A (en) * | 1989-04-12 | 1991-11-05 | Unisys Corporation | Programmable data communications controller |
| US5170266A (en) * | 1990-02-20 | 1992-12-08 | Document Technologies, Inc. | Multi-capability facsimile system |
| US5617532A (en) * | 1990-10-18 | 1997-04-01 | Seiko Epson Corporation | Information processing apparatus and data back-up/restore system for the information processing apparatus |
| CA2072198A1 (en) | 1991-06-24 | 1992-12-25 | Scott C. Farrand | Remote console emulator for computer system manager |
| CA2072178A1 (en) | 1991-06-24 | 1992-12-25 | Said S. Saadeh | Innate bus monitor for computer system manager |
| DE69232164T2 (de) * | 1991-08-22 | 2002-07-18 | Sun Microsystems, Inc. | Netzwerkvideoanbietergerät und-verfahren |
| US5282194A (en) * | 1992-08-17 | 1994-01-25 | Loral Aerospace Corporation | Interactive protocol analysis system |
| US5353415A (en) * | 1992-10-02 | 1994-10-04 | Compaq Computer Corporation | Method and apparatus for concurrency of bus operations |
| US5451933A (en) | 1992-10-19 | 1995-09-19 | Motorola, Inc. | Computer card having power switching capability |
| WO1994022253A1 (en) * | 1993-03-20 | 1994-09-29 | International Business Machines Corporation | Method and apparatus for extracting connection information from protocol headers |
| US5384747A (en) | 1994-01-07 | 1995-01-24 | Compaq Computer Corporation | Circuit for placing a memory device into low power mode |
| US5567993A (en) | 1994-06-23 | 1996-10-22 | Dallas Semiconductor Corporation | Programmable power supply system and methods |
| US5623599A (en) * | 1994-07-29 | 1997-04-22 | International Business Machines Corporation | Method and apparatus for processing a synchronizing marker for an asynchronous remote data copy |
| US5884028A (en) * | 1994-07-29 | 1999-03-16 | International Business Machines Corporation | System for the management of multiple time-critical data streams |
| US5537533A (en) * | 1994-08-11 | 1996-07-16 | Miralink Corporation | System and method for remote mirroring of digital data from a primary network server to a remote network server |
| US5615334A (en) * | 1994-10-07 | 1997-03-25 | Industrial Technology Research Institute | Memory reflection system and method for reducing bus utilization and device idle time in the event of faults |
| US5796566A (en) * | 1996-08-16 | 1998-08-18 | Compaq Computer Corporation | Printed circuit board having conductors which can be decoupled for isolating inactive integrated circuits connected thereto |
| US5857074A (en) * | 1996-08-16 | 1999-01-05 | Compaq Computer Corp. | Server controller responsive to various communication protocols for allowing remote communication to a host computer connected thereto |
-
1996
- 1996-08-17 US US08/697,678 patent/US6233634B1/en not_active Expired - Lifetime
-
1997
- 1997-08-13 DE DE69718859T patent/DE69718859T2/de not_active Expired - Lifetime
- 1997-08-13 EP EP19970306154 patent/EP0825536B1/en not_active Expired - Lifetime
- 1997-08-18 JP JP22133297A patent/JP3641354B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69718859T2 (de) | 2003-10-09 |
| JPH10116255A (ja) | 1998-05-06 |
| US6233634B1 (en) | 2001-05-15 |
| EP0825536B1 (en) | 2003-02-05 |
| EP0825536A2 (en) | 1998-02-25 |
| EP0825536A3 (en) | 1999-03-10 |
| DE69718859D1 (de) | 2003-03-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3790333B2 (ja) | 分散型のコンピュータ・システム | |
| JP3641354B2 (ja) | 分散型のコンピュータ・システム | |
| JPH10105486A (ja) | 分散型のコンピュータ・システム | |
| US5796566A (en) | Printed circuit board having conductors which can be decoupled for isolating inactive integrated circuits connected thereto | |
| US7429990B2 (en) | Network management card for use in a system for screen image capturing | |
| JP4146089B2 (ja) | パーソナルコンピュータにリモートアクセスするためのシステム | |
| US6189109B1 (en) | Method of remote access and control of environmental conditions | |
| WO2007036091A1 (fr) | Systeme d’affichage multiecran et procede de reglage automatique du mode d’affichage | |
| US6128285A (en) | Monitoring of a packet telephony device via a control device | |
| US7734948B2 (en) | Recovery of a redundant node controller in a computer system | |
| US6819322B2 (en) | Method and apparatus for detecting potential lock-up conditions in a video graphics controller | |
| US9608884B2 (en) | System and method for remote management of a computer | |
| KR100399086B1 (ko) | 애플리케이션 크래시후의 비디오 스택으로의 액세스 유지 | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| Cisco | Using Debug Commands | |
| JP3465637B2 (ja) | サーバ及びその制御方法 | |
| TWI766567B (zh) | 多屏幕顯示控制裝置 | |
| CN117850851A (zh) | 一种高可靠且热升级友好的虚拟交换机软件系统 | |
| JP2000013467A (ja) | 回線モニタ方法および回線モニタ装置 | |
| JPS6385821A (ja) | 端末装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040421 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040421 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040528 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050114 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050121 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100128 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100128 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110128 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120128 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130128 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |