JPH10116254A

JPH10116254A - 分散型のコンピュータ・システム

Info

Publication number: JPH10116254A
Application number: JP9221329A
Authority: JP
Inventors: Scott R Gready; アール・スコット・グレディ; Wesley M Ellinger; ウエスリー・エム・エリンガー; Gordon R Clark; ゴードン・アール・クラーク
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1996-08-16
Filing date: 1997-08-18
Publication date: 1998-05-06
Anticipated expiration: 2017-08-18
Also published as: EP0825535A2; JP3790333B2; JP2006155641A; EP0825535B1; DE69719420D1; EP0825535A3; US5852720A; DE69719420T2; US6173340B1

Abstract

(57)【要約】【課題】コンピュータの障害をホストＣＰＵから離れ
た遠隔地の端末でも知ることができるようにする。【解決手段】サーバＣＰＵ１２、ビデオ・コントロー
ラ２０、及びサーバ・コントローラ２６は拡張バスによ
り接続されており、コンピュータの故障の前の時間中の
及びコンピュータのリセットの後の第２の時間中にＣＰ
Ｕからビデオ・コントローラに送られた表示データが、
ビデオ・メモリ２２に記憶されるとともに、サーバ・コ
ントローラ中のメモリにも記憶される。遠隔端末２８は
サーバ・コントローラ中のメモリにアクセスして読み出
し、記憶された表示データの変化を判断することによ
り、障害の発生を知ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散型コンピュー
タ・システムに関し、更に特定すれば、ホスト・コンピ
ュータ（「ホスト」）であって、当該ホストとは物理的
に接続されておらず、このホストから離れた場所に位置
する端末からアクセス可能なホストに関するものであ
る。遠隔端末は、ホストのリセットまたは障害処理の間
に発生する一連のビデオ画面のような、記憶されている
一連のビデオ画面にアクセスすることができる。この一
連のビデオ画面は、次に遠隔端末に配置されているコン
ピュータ管理者による再生が可能である。これらビデオ
画面への遠隔アクセスにより、管理者は、ホストのオペ
レーティング・システムがどのようにリセットに応答す
るのか、即ち、ホスト・システムが障害を発生した場合
の原因として可能性のあるものを判定することができ
る。ホストには、プリント回路基板（「ＰＣＢ」）が設
けられており、ホストを収容するバックプレーン(backp
lane)に挿入することができる。ＰＣＢは、プロセッサ
と、ホストへの電力が失われた場合でも前述の一連のビ
デオ画面を記憶しているメモリとを備えている。

【０００２】

【従来の技術】分散型コンピュータ・システムは、一般
的によく知られている。かかるシステムは、多数のコン
ピュータ・ワークステーション上で実行される(hosted)
アプリケーション・プログラム間での通信が可能であ
る。分散型コンピュータ・システムには多数の種類があ
り、多くの場合、それらの通信能力の地理的範囲によっ
て分類されている。分散型コンピュータ・システムの地
理的広さ(geographical breadth)を分類するために用い
られる用語には、例えば、ローカル・エリア・ネットワ
ーク（ＬＡＮ）、メトロポリタン・エリア・ネットワー
ク（ＭＡＮ）、およびワイド・エリア・ネットワーク
（ＷＡＮ）がある。

【０００３】増々普及しつつある分散型コンピュータ・
システムの多くは、ファイル・サーバ（「サーバ」）を
採用している。ファイルまたはデータは、サーバ内のホ
ストによって管理される。サーバが特に有用なのは、サ
ーバによって、記憶されているファイルに対するワーク
ステーションの高速アクセスが可能になる点にある。し
たがって、ファイル・サーバは、ファイルを編成(orche
strate)するだけでなく、ファイルの機密保護、ファイ
ル・バックアップ等の保守も行う、オペレーティング・
システム・プログラム（普及しているオペレーティング
・システムには、例えば、Windows NT（登録商標）があ
る）に応答するホスト・コンピュータを具現化するもの
である。

【０００４】サーバ内においてホストの機能を維持する
ことの重要な一面に、ホストから離れた場所からホスト
を管理すること、より具体的には、物理的にサーバに連
結されているワークステーションから離れた場所にある
ホストを管理することがあげられる。最近の傾向とし
て、業務に使用するサーバの数が確実に増加している。
今日では、サーバは、１カ所に集中させたメインフレー
ムを採用するのではなく、業務実体の各位置毎等のよう
に自由に用いられている。しかしながら、分散した場所
に配置された多くのサーバ・ホストを管理するために利
用可能な資金は減少しつつある。これらのサーバに置か
れているデータは業務には非常に重要であるが、単一の
サービス現場からそれらの適正な動作を確保するための
手段は、未だに不十分である。管理者が遠隔地にあるサ
ーバ設置現場まで移動して問題を解決するというような
ことは、実用的でないだけでなく、サーバのダウンタイ
ム（動作不能時間）に付随する出費は膨大なものとな
る。

【０００５】多くのオペレーティング・システム、また
はこれらオペレーティング・システムと関連するアプリ
ケーションは、しばしば、バーチャル・ターミナル即ち
仮想端末と呼ばれている遠隔地からのホストへのアクセ
スを許可する。仮想端末は物理的にホストに接続されて
いないが、ホストの所定の動作の遠隔制御を許してい
る。コンパック・コンピュータ社（Compaq Computer Co
rp.）から入手可能な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 Co
rp.）が製造するペンティアム（Pentium（登録商標））
プロセッサを含む。

【００１９】メモリ・コントローラ１４は、ＣＰＵロー
カル・バスおよびシステム・メモリ１６間のデータ転送
を指揮する。メモリ・コントローラ１４は、種々のアド
レシング技法に応答し、システム・メモリ１６内の様々
な記憶セル・アーキテクチャに対応するように構成され
ている。適切なアーキテクチャは、ダイナミック・ラン
ダム・アクセス・メモリ（ＤＲＡＭ）またはスタティッ
ク・ランダム・アクセス・メモリ（ＳＲＡＭ）である。
メモリ・コントローラ１４は、ＣＰＵ１２と同期して動
作し、システム・メモリとの間に最大転送帯域を確保す
ることが好ましい。

【００２０】本発明の一実施例によれば、ＣＰＵ１２
は、周辺要素インターフェース（「ＰＣＩ」）バスに結
合されている。バス・インターフェース・ユニット１８
が、ＰＣＩバスおよび拡張バス間のバス・ブリッジとし
て動作する。バス・インターフェース・ユニット１８は
バッファを含み、ＰＣＩバスおよび拡張バス間における
データおよびアドレス信号の転送を制御する。こうする
ことにより、バス・インターフェース・ユニット１８
は、クロック速度が異なる可能性がありかつ異なるプロ
トコルで動作するバスを通じて送出されるデータ間のイ
ンターフェースとして機能する。好ましくは、拡張バス
は、拡張業界標準アーキテクチャ（「ＥＩＳＡ」）バス
・コンフィギュレーションから成る。

【００２１】拡張バスには、ビデオ・コントローラ２０
が接続されている。ビデオ・コントローラ２０は、それ
に接続されているディスプレイすなわち表示装置２４を
制御するために用いられる。ビデオ・コントローラ２０
は、ビデオ・グラフィクス・アレイ（「ＶＧＡ」）コン
トローラのような、一般的に使用されているビデオ・コ
ントローラである。ビデオ・コントローラ２０は、拡張
バス上のアドレスに応答し、対応するデータをビデオ・
メモリ２２に送出する。ビデオ・メモリ２２は、ビデオ
・コントローラ２０が表示装置２４上に表示するビデオ
・データを記憶する。表示装置２４は、ビデオ・データ
を受け取ることができるいずれかのコンソールまたはモ
ニタを含み、好適な表示装置２４は、陰極線管（「ＣＲ
Ｔ」）、あるいは液晶表示装置（「ＬＣＤ」）である。
ビデオ・コントローラ２０およびビデオ・メモリ２２
を、以降一括してビデオ・サブシステムと呼ぶことにす
る。

【００２２】サーバ１０には、サーバ１０のリセット後
の連続ビデオ画面変化だけでなく、サーバ１０の障害前
の連続ビデオ画面変化もセーブする機構が内蔵(retrofi
t)されている。これを行う機構は、サーバへの電源停止
に影響されないものでなければならず、更に、記憶され
ているビデオ画面を遠隔端末に送出する能力を有してい
なければならない。かかる機能は、サーバ・コントロー
ラ２６によって実行される。サーバ・コントローラ２６
は、サーバ１０のシャーシ内に結合され、拡張バスに接
続可能である。この場合、コントローラ２６は、サーバ
１０から離れて位置する端末からアクセス可能である。
好適実施例によれば、遠隔端末２８は、電話線通信装置
を介して、サーバ・コントローラ２６に結合される。電
話線通信装置の一例は、遠隔端末２８およびサーバ・コ
ントローラ２６双方に内蔵されているモデムである。遠
隔端末２８は、表示装置（例えば、ＣＲＴ）および入力
装置（例えば、キーボード）を含む。

【００２３】一実施例によれば、サーバ・コントローラ
２６は、コンパック・コンピュータ社から入手可能なソ
フトウエアによって動作する。具体的には、該ソフトウ
エアは、コンパック・コンピュータ社の、遠隔端末２８
上で動作可能なCompaq Insight Manager（「ＣＩＭ」）
という製品名のソフトウエアである。ＣＩＭは、サーバ
・コントローラ２６に装填されているファームウエアに
アクセスし、例えば、サーバ・コントローラ２６に記憶
されている種々のビデオ画面変化の再生を行うことがで
きる。

【００２４】サーバ・コントローラ２６のハードウエア
およびファームウエア構造は、ＣＩＭを用いて構成され
た遠隔端末による遠隔アクセスおよび制御を利用可能と
する。サーバ・コントローラ２６に追加されるハードウ
エアおよび付随するコードにより、サーバ１０が障害を
発生した後でも、システム管理者はサーバ・コントロー
ラ２６に発信する(dial into)ことができ、その後サー
バ・コントローラ２６と通信し、障害の前またはリセッ
トの後に発生した表示装置２４の一連の画面変化を見る
ことができる。

【００２５】サーバ・コントローラ２６内のファームウ
エアまたはコードは、遠隔端末２８と通信するために用
いられるコンソール・アプリケーション・コードとして
機能する。図２のａは、コンソール・アプリケーション
が遠隔端末２８上に表示する初期メニュー画面の画面表
示である。システム管理者がサーバ・コントローラに発
信したときはいつでも、この画面表示が発生する。管理
者は、メニュー項目のいずれかを選択することができ
る。彼または彼女がメニュー項目４を選択した場合、管
理者は、彼または彼女の遠隔端末２８において、サーバ
・コントローラ２６内に記憶されている一連のビデオ画
面を見ることができる。ここでは、次にあげる３種類の
異なる連続ビデオ画面変化を再生することができる。

【００２６】（i）サーバ１０の以前のリセット後に発
生した一連のビデオ画面（ii）サーバ１０の現リセットの後に発生した一連のビ
デオ画面（iii）サーバ１０の障害の前に発生した一連のビデオ
画面ここでは、上述の（i）〜（iii）における連続ビデオ画
面のことを、「現リセット・シーケンス」、「前リセッ
ト・シーケンス」、および「障害シーケンス」と呼ぶこ
とにし、これらを一括して「再生シーケンス」と呼ぶこ
とにする。

【００２７】図２のｂは、システム管理者がサーバ・コ
ントローラ２６に前述のシーケンスのいずれかを表示す
るよう命令するために用いる、メニュー画面の画面表示
である。図２のｃは、システム管理者がサーバ・コント
ローラ２６に、現リセット・シーケンス、前リセット・
シーケンス、および障害シーケンスのいずれかの再生開
始や一時停止を行ったり、再生速度を変化させるように
命令するために用いるメニュー画面の画面表示である。

【００２８】現リセット・シーケンスは、サーバ１０の
最新のリセットの直後に発生した一連のビデオ画面変化
から成る。前リセット・シーケンスは、サーバ１０の最
新のリセット前に発生したリセットの直後に発生した一
連のビデオ画面変化から成る。障害シーケンスは、サー
バ１０のリセット、障害または停電の直前に発生した一
連のビデオ画面変化から成る。サーバ・コントローラ２
６が、障害シーケンスのために、サーバ１０のリセット
または停電の前に記憶する画面変化数、あるいは前リセ
ット・シーケンスまたは現リセット・シーケンスに続い
て記憶する画面変化数は、サーバ・コントローラ２６が
所与の再生シーケンスに使用可能なバッファ空間の量に
よって決定される。

【００２９】図３には、サーバ１０内のメモリ・アドレ
ス空間およびＩ／Ｏアドレス空間の部分が示されてい
る。メモリ・アドレス範囲［０ｘＢ０００〜０ｘＢＦＦ
ＦＦ］は、ビデオ・メモリ２２内に位置するビデオ・フ
レーム・バッファのために予約されている。Ｉ／Ｏアド
レス範囲［０ｘ０３Ｂ４〜０ｘ０３ＢＡ］および［０ｘ
０３Ｃ０〜０ｘ０３ＤＡ］は、ビデオ・コントローラ２
０内のビデオ制御レジスタに指定されている。ＣＰＵ１
２は、ビデオ制御レジスタに値を書き込むことによっ
て、表示装置２４の様々な動作を制御する。フレーム・
バッファ・メモリのアドレス範囲およびビデオ制御レジ
スタのＩ／Ｏアドレス範囲のことを、ここでは一括して
ビデオ・アドレス範囲、即ち、ビデオ・サブシステムに
送られるデータのためのアドレス範囲と呼ぶことにす
る。

【００３０】表示装置２４は、テキスト・モードにある
場合、行列から成るマトリクスに組織される。例えば、
一般的な表示画面構成は、２５ｘ８０である。したがっ
て、２０００（＝２５ｘ８０）箇所の文字位置が、表示
装置２４上において使用可能である。表示装置２４上の
各位置は、フレーム・バッファ内に対応するワード（即
ち、２バイト）を有する。このワードの下位バイトは、
文字値（例えば、アスキー文字集合における文字「Ａ」
に対する０ｘ４１）を含み、このワードの上位バイトは
対応する属性（色、前面および背面の輝度、文字を点滅
させるか否か等のような属性）を含む。ＣＰＵ１２は、
ビデオ・メモリ２２内の適切なフレーム・バッファ位置
に値を書き込み、表示装置２４上に所望の文字および属
性を表示させる。文字および表示に対する属性を含むフ
レーム・バッファ内のビデオ・データのことを、ここで
は表示データと呼ぶことにする。上述の例では、表示画
面全体を表わす表示データを記憶するために、４０００
バイト［すなわち、２０００位置ｘ（各位置毎に２バイ
ト）、文字に１バイトおよび属性に１バイト］のフレー
ム・バッファが用いられる。

【００３１】以下にあげる３つの例は、ビデオ制御レジ
スタの多くの使用法のいくつかを示す。尚、ビデオ制御
レジスタのアドレスは、Ｉ／Ｏアドレス空間内に予約さ
れている。第１に、ＣＰＵ１２はビデオ制御レジスタの
アドレス（即ち、アドレス範囲［０ｘ０３Ｂ４〜０ｘ０
３ＢＡ］およびアドレス範囲［０ｘ０３Ｃ０〜０ｘ０３
ＤＡ］に書き込みを行い、例えば、表示装置２４上のカ
ーソルの位置および属性を制御する。第２に、ＣＰＵ１
２はビデオ制御レジスタに書き込みを行い、例えば、ビ
デオ・モードをカラー・モードから白黒モードに、また
はその逆に変更する。第３に、ビデオ制御レジスタは、
多数の画面を記憶することができるビデオ・メモリ２２
内の開始アドレスを指定することができる。第３の例で
は、ビデオ・メモリ２２は、１画面分の表示データを記
憶するのに必要な記憶位置よりも多い記憶位置を含むも
のと仮定する。

【００３２】ビデオ・メモリ２２が６４ＫＢのメモリを
含む（即ち、フレーム・バッファに６４ＫＢが使用可
能）と仮定した場合、フレーム・バッファが１画面分の
表示データを記憶するために用いるのは４０００バイト
に過ぎないので、フレーム・バッファは一度に多数の表
示データの集合を格納することができる。ＣＰＵ１２
は、ビデオ制御レジスタに書き込みを行い、表示装置２
４上に表示させる表示データの最初の集合の、ビデオ・
メモリ２２内の開始アドレスを指定する。ビデオ・コン
トローラに関する情報、より具体的には、上述の代表的
な制御機能の多くを実行するためのビデオ制御レジスタ
を使用するＶＧＡコントローラに関する情報は、とりわ
け、Cirrus Logic Corp., Part no. CL-GD542xから入手
可能である。

【００３３】ビデオ・コントローラ２０は、拡張バス
（好ましくは、ＥＩＳＡバス）上に発生されたアドレス
をデコードし、ビデオ・アドレス範囲内においてバス・
サイクルに応答する。ビデオ・コントローラ２０は、ビ
デオ・メモリ２２内に記憶されている表示データを表示
装置２４に送るだけでなく、ＣＰＵ１２がビデオ制御レ
ジスタに書き込んだデータに応答して、表示装置２４を
制御する。したがって、ビデオ・メモリ２２は文字およ
び属性情報を格納し、一方ビデオ制御レジスタは表示装
置２４を制御する情報を格納する。

【００３４】ビデオ・コントローラ２０と同様に、サー
バ・コントローラ２６も拡張バス上のアドレスをデコー
ドし、ビデオ・サブシステムへの書き込みを検出する。
ビデオ・アドレス範囲への書き込みを検出した場合、サ
ーバ・コントローラ２６は、ビデオ・アドレス範囲に書
き込まれたデータを、サーバ・コントローラ２６内に記
憶する。この動作のことを、「監視：スヌーピング：(s
nooping)」と呼ぶ。即ち、サーバ・コントローラ２６
は、他のサブシステム（即ち、ビデオ・サブシステム２
０、２２）に対しての表示データの１つ以上の画面を得
る。データはサーバ・コントローラ２６上で複製され、
サーバ・コントローラ２６が、ビデオ・メモリ２２のフ
レーム・バッファ内にある情報、およびビデオ・コント
ローラ２０のビデオ制御レジスタ内にある情報のミラー
・コピー(mirror copy)を保持するようにする。拡張バ
スを監視してビデオ・アドレス範囲内のデジタル信号を
発見することにより、ＣＰＵ１２が認めるビデオ・サブ
システムへの書き込みは１回のみでも、二重記憶の実行
が可能となる。重要なのは、監視は、サーバ・コントロ
ーラ２６によって割り込みを生じないように(non-intru
sive)行われることである。ビデオ・サブシステムに対
して供給されるべきデータは、ビデオ・サブシステムに
進み、サーバ・コントローラ２６によって変更や削除を
されることがない。

【００３５】図４には、サーバ・コントローラ２６の詳
細なブロック図が示されている。サーバ・コントローラ
２６は、拡張バスに結合された検出ロジック３０を備え
ている。コントローラ・メモリ３２が、コントローラ・
バスを介して、検出ロジック３０に結合されている。検
出ロジック３０は、例えば、プログラマブル・アレイ・
ロジック（「ＰＡＬ」）回路において一般的に見られる
ような、組み合わせられた連続的なロジック素子から成
る。制御ロジック４０、アドレス・バッファ４２および
データ・トランシーバ４４についての詳細は、それらの
関係を論じた後に説明する。検出ロジック３０内のこれ
ら３つのユニットは、サーバ・コントローラ２６の様々
な構成要素、即ち、コントローラ・メモリ３２およびそ
の中の様々なバッファの性能を最大に高めるためのもの
である。したがって、これら３つの要素４０、４２、４
４の説明は、再生シーケンスの検討および様々なバッフ
ァがどのようにしてこれらのシーケンスを記憶するのか
についての検討が終了してから、行うことにする。

【００３６】サーバ・コントローラ２６の一部として、
プロセッサ３４は、コントローラ・バス上の情報、即
ち、検出ロジック３０およびコントローラ・メモリ３２
間の情報、または通信ユニット３６およびコントローラ
・メモリ３２間の情報のいずれかを編成しなければなら
ない。プロセッサ３４は、命令セットに応答し、例え
ば、実行ユニット、メモリ、入出力装置、および１つ以
上のレジスタを内蔵したマイクロプロセッサまたはマイ
クロコントローラを含む。プロセッサ３４は、埋め込み
システム(embedded system)の用途に用いられるマイク
ロプロセッサを代表するものである。コントローラ・メ
モリ３２は、複数のデジタル記憶素子から成る。本発明
の一実施例では、コントローラ・メモリ３２は、疑似ス
タティックＲＡＭから成る。通信ユニット３６は、サー
バ・コントローラ２６から離れて配置された遠隔端末２
８に対して通信可能な装置を含む。通信ユニット３６
は、遠隔端末２８から送られてくるアナログ呼び出し信
号(ARGN:analog ring signal)に応答して、遠隔端末２
８に返送する通信信号(COMM. SIG)を生成する。好まし
くは、通信ユニット３６はモデムを備えている。通信ユ
ニット３６は、更に、プロセッサ３４に結合された直列
ポート、およびサーバ・コントローラ２６外部の直列ポ
ートに結合され遠隔端末２８と通信するためのモデムも
想定している。

【００３７】プロセッサ３４は、再生シーケンスをコン
トローラ・メモリ３２に記憶する。プロセッサ３４は、
再生シーケンスを、表示画面の集合全体を表わす連続表
示データとして、コントローラ・メモリ３２内に記憶す
ることも可能である。しかしながら、これは、コントロ
ーラ・メモリ３２を使用する方法としては比較的非効率
的であり、したがって再生シーケンスを構成してコント
ローラ・メモリ３２内に記憶されるビデオ画面の数は比
較的少ない。本発明では、プロセッサ３４は、一連の表
示画面全体の代わりに、一連の表示「変化」として再生
シーケンスを効率的に記憶するように表示データを処理
する点で効果的である。画面内の変化を表わす表示デー
タの量は、画面全体を表わす表示データ量より大幅に少
ない。したがって、現リセット・シーケンス、前リセッ
ト・シーケンスおよび障害シーケンス（即ち、再生シー
ケンス）は、基準画面、即ち「開始」画面からの変化と
して表わされる。

【００３８】図５には、コントローラ・メモリ３２内の
種々のバッファが示されている。これらのバッファは、
プロセッサ３４によって用いられて、再生シーケンスの
処理や記憶を行うためのものである。ローカル・フレー
ム・バッファ４８は、ビデオ・メモリ２２へのライト・
アクセスの間に監視された表示データを格納する。即
ち、検出ロジック３０が拡張バスを監視し、ビデオ・サ
ブシステムに向けて送られてくるデータを、ローカル・
フレーム・バッファ４８に記憶する。スナップショット
・バッファ５０は、ローカル・フレーム・バッファ４８
からの現表示データの、プロセッサ３４によって作成さ
れた、コピー即ちスナップショットを格納する。一時ス
ナップショット・バッファ５２も、ローカル・フレーム
・バッファ４８からの現表示データのスナップショット
を格納する。一時スナップショット・バッファ５２は、
画面変化、特に画面のスクロールが素早く行われる場合
に、再生シーケンスを見やすくするために用いられる。

【００３９】現リセット・シーケンス・バッファ５４
は、最新のリセット・シーケンスに関連する情報を格納
する。即ち、現リセット・シーケンス・バッファ５４
は、最新のリセットで始まり、現リセット・シーケンス
・バッファ５４が満杯になると終了する画面変化を格納
する。現リセット・シーケンス・バッファ５４が満杯に
なった後に発生する画面変化は無視される。前リセット
・シーケンス・バッファ５６は、最新のリセット・シー
ケンスの直前のリセット・シーケンスに関連する情報を
格納する。即ち、前リセット・シーケンス・バッファ５
６は、最新のリセットに前に発生したリセット時に開始
し、前リセット・シーケンス・バッファ５６が満杯にな
ったとき、または次のリセットが発生したときに終了す
る画面変化を格納する。前リセット・シーケンス・バッ
ファ５６が満杯になった後に発生した画面変化は無視さ
れる。

【００４０】現シーケンス・バッファ５８は、最新の画
面変化を、バッファ５８内に納まるだけ格納する。障害
シーケンス・バッファ６０は、サーバ１０の最新のリセ
ット直前の障害シーケンスに関連する情報を格納する。
即ち、障害シーケンス・バッファ６０は、最新のリセッ
トで終了する画面変化を格納し、最新のリセット直前に
発生した画面変化を、その中に納まるだけ格納する。

【００４１】障害開始バッファ６４は、障害シーケンス
・バッファ６０に関連するビデオ画面表示の表示データ
を格納する。障害開始バッファ６４は、障害シーケンス
における初期画面画像（即ち、「基準」画面画像）を格
納し、結果的に、障害シーケンス・バッファ６０内の最
初の変化が適用される画面画像を格納する。初期状態で
は、障害開始バッファ６４は空白画面である。障害シー
ケンス・バッファ６０がオーバーフローした場合、超過
分の変化は文字および属性に変換され、障害開始バッフ
ァ６４に記憶される。したがって、障害開始バッファ６
４は、比較的長い時間期間の間に画面上の少数の文字だ
けが何回も変化するような場合に、有用性が高い初期画
面画像を提供する。現開始バッファ６２は、現シーケン
ス・バッファ５８に関して、同一の機能を提供する。

【００４２】サーバ１０のリセットまたは障害は、サー
バ・コントローラ２６のリセットの原因にならないもの
である。しかしながら、サーバ・コントローラ２６は、
以下のリセット・イベントに関する情報を検出し保持す
る。即ち、サーバ１０の給電開始、サーバ１０の電力遮
断、および拡張バスのリセットである。特に、サーバ・
コントローラ２６は、RSTDRV EISAバス信号には応答せ
ず、単にRSTDRVのアサートを検出するに過ぎない。リセ
ットが発生した場合、または電力がサーバ１０から遮断
された場合でも、サーバ・コントローラ２６は動作を維
持し、遠隔端末２８上の表示のために、再生シーケンス
を保存する。サーバ・コントローラ２６を収納する同一
ＰＣＢ上に、二次電源が設けられており、再生シーケン
スが維持されることを保証する。しかしながら、必要で
あれば、ＣＰＵ１２にアクセス可能なサーバ・コントロ
ーラ２６の所定のレジスタ位置に所定の一連の値を書き
込むことによって、ソフトウエアの制御の下でサーバ・
コントローラ２６をリセットすることも可能である。

【００４３】サーバ１０のリセットが発生した場合、ポ
インタを変化させて、現リセット・シーケンス・バッフ
ァ５４が前リセット・シーケンス・リセット・バッファ
５６になるようにし、更に前リセット・シーケンス・バ
ッファ５６がフラッシュ（一掃）され、現リセット・シ
ーケンス・バッファ５４になる。サーバのリセットによ
っても、現シーケンス・バッファ５８が障害シーケンス
・バッファ６０になり、障害シーケンス・バッファ６０
がフラッシュされ、現シーケンス・バッファ５８とな
る。また、リセット時にも、現開始バッファ６２は障害
開始バッファ６４となり、障害開始バッファ６４はフラ
ッシュされ、現開始バッファ６２となる。サーバ・コン
トローラ２６は、サーバ１０の自動サーバ復元（「ＡＳ
Ｒ」）リセット(automatic server recovery reset)を
実行するように構成されている。サーバ・コントローラ
２６がサーバ１０の障害を検出した場合、所定の時間の
間（典型的には、３０秒）待ってから、サーバ１０をリ
セットする。

【００４４】以下に述べるのは、サーバ１０のリセッ
ト、それに続いて障害、更にそれに続いてリセットが発
生する例示的なシーケンスである。最初にサーバ１０を
起動し、サーバ１０をリセットする。リセット時に、サ
ーバ・コントローラ２６は、前リセット・シーケンス・
バッファ５６から情報をフラッシュし、障害シーケンス
・バッファ６０をフラッシュし、更に障害開始バッファ
６４をフラッシュする。バッファ５６、６０、６４をフ
ラッシュする間、前リセット・シーケンス・バッファ５
６と現リセット・シーケンス・バッファ５４との交換
が、バッファ６０、５８間の交換およびバッファ６４、
６２間の交換と同時に行われる。したがって、リセット
により、バッファ５４、５８、６２からそれぞれバッフ
ァ５６、６０、６４へ情報の移動が生ずる。リセット時
に、サーバ１０のソフトウエアは、ＰＯＳＴ処理の実
行、および表示装置２４上の文字表示を開始する。

【００４５】サーバ・コントローラ２６は、ＰＯＳＴ処
理に付随する画面変化を、現リセット・シーケンス・バ
ッファ５４および現シーケンス・バッファ５８に記憶す
る。一旦現リセット・シーケンス・バッファ５４が満杯
になったなら、サーバ・コントローラ２６は画面変化を
そこに記憶するのを中止する。現シーケンス・バッファ
が満杯になった場合、サーバ・コントローラ２６は最も
古い画面変化を現シーケンス・バッファ５８から除去
し、新たな画面変化の記憶のための余裕を作り、現開始
バッファ６２を修正して古い画面変化を記憶させる。こ
のように、バッファ５８はＦＩＦＯレジスタと同様に動
作し、超過した情報をバッファ６２に送出する。以下で
説明するが、バッファ５８、６２の組み合わせ（バッフ
ァ６０、６４と交換された場合）は、最新の障害以前の
ビデオ画像の障害シーケンス全体を表わす。

【００４６】リセット−障害−リセットの３段階の例に
おける第２段階においてサーバ１０の障害が発生した場
合、ビデオ画面のシーケンスが表示装置２４上に生成さ
れ、この障害、および可能であれば障害の理由を示す。
これらの画面は、Novell NetwareからのABENDメッセー
ジまたはMicrosoft NTのブルー・スクリーンとして使用
可能な、多くのサーバ・オペレーティング・システムの
一部として、自動的に表示される。障害が発生して３０
秒後、サーバ・コントローラ２６はサーバ１０上でＡＳ
Ｒリセットを実行する。ＡＳＲリセットの間に、リセッ
ト−障害−リセット例における２回目のリセットが発生
する。１回目のリセットと同様、このリセットによっ
て、サーバ・コントローラ２６はバッファ５６、６０、
６４をフラッシュする一方、バッファ５６，６０，６４
のバッファ５４，５８，６２との交換をそれぞれ行うこ
とができる。

【００４７】また、１回目のリセットと同様、サーバ１
０は再びＰＯＳＴ処理を起動し、文字を表示装置２４に
送出する。サーバ・コントローラ２６は、ＰＯＳＴ処理
の結果生じたリセットの後に発生した画面変化を、現リ
セット・シーケンス・バッファ５４および現シーケンス
・バッファ５８に記憶する。前リセット・シーケンス・
バッファ５６は、ここで、最初のパワー・オン・リセッ
トに付随する一連の画面変化を格納し、障害シーケンス
・バッファ６０および障害開始バッファ６４は、ここ
で、当該障害までに至る一連の画面変化を格納する。前
リセット・シーケンス・バッファ５６内に格納されてい
る初期リセットによる画面変化とは異なり、現リセット
・シーケンス・バッファ５４は、２回目のリセット（即
ちＡＳＲリセット）に関連するリセットによる画面変化
を格納する。

【００４８】ビデオ画面全体とは異なり、ビデオ画像の
変化は、現リセット・シーケンス・バッファ５４、前リ
セット・シーケンス・バッファ５６、現シーケンス・バ
ッファ５８および障害シーケンス・バッファ６０内に
は、パケットとして記憶される。バッファ５４、５６、
５８、６０内の各パケットは、指定された長さの一連の
バイトで構成される。パケットは「タイプ」にしたがっ
て類別され、パケット・タイプは、その長さならびに最
初のバイト（バイト０）、およびパケット長が１バイト
より長い場合は２番目のバイト（バイト１）によって判
定される。パケット・タイプ、および遠隔端末２８上の
サーバ・コントローラ２６が各タイプに応じて行う作用
は以下の表１の通りである。

【００４９】

【表１】

【００５０】このリストに示す各パケット・タイプに用
いた二進コード・フォーマットは、次の表２の通りであ
る。

【００５１】

【表２】

【００５２】表示文字列パケット・タイプにおけるバイ
ト３、４、および後続バイトは、表示すべきヌルで終了
する文字列を含む。この文字列は、少なくとも２文字に
ヌルの終端を加えた長さでなければならないので、その
長さは５より大きい。したがって、長さ検査を用いて、
繰り返し文字パケットから識別可能である。変化が１文
字を含むのみである場合、その変化は繰り返し回数が１
の繰り返し文字パケット、または単一文字パケットとし
て記憶する。

【００５３】図５に示したコントローラ・メモリ３２内
に位置する種々のバッファの機能は、図６および図７の
フローチャートの説明において、より明白となろう。な
お、図６および図７は、プロセッサ３４が、バッファ４
８〜５２に送出される表示データを処理し、バッファ５
４〜６４のいずれかに再生シーケンスを記憶する際に実
行するステップを示すフローチャートである。

【００５４】図６を参照すると、ステップ７０におい
て、プロセッサ３４がローカル・フレーム・バッファ４
８をチェックして、ビデオ制御レジスタを通じて、いず
れかのビデオ・モード変化が起きているか否かについて
検査を行う。ビデオ・モード変更の例は、グラフィック
ス・モードおよびテキスト・モード間の変更、または画
面サイズの変更、即ち、表示装置の行数および列数の少
なくとも一方の変更である。再生シーケンスの記憶が可
能になる前に、プロセッサ３４は、ステップ７２におい
て、現ビデオ・モードが有効なテキスト・モードである
か否かについて判定を行わなければならない。有効なテ
キスト・モードでない場合、プロセッサ３４は、ビデオ
・モードが有効なテキスト・モードになるまで待ち、次
いでプロセッサ３４は、ステップ７４において、ローカ
ル・フレーム・バッファ４８からの現表示の集合（ビデ
オ制御レジスタ内に指定される開始アドレスによって示
される）を、一時スナップショット・バッファ５２にコ
ピーする。次に、プロセッサ３４は、ステップ７６にお
いて、一時スナップショット・バッファ５２の内容を、
スナップショット・バッファ５０の内容と比較して、画
面スクロールが行われたか否かについて判定を行う。ス
クロールが行われていた場合、プロセッサ３４は、ステ
ップ７８において、画面スクロール・パケットを適切な
バッファに記憶する。

【００５５】そして、プロセッサ３４は、スナップショ
ット・バッファ５０および一時スナップショット・バッ
ファ５２の先頭から開始して、それらを比較し変更する
ための一連のステップを開始することができる。プロセ
ッサは、ステップ８０において、バッファ５０，５２の
現バイトを比較し、変化を探す。ステップ８２に示すよ
うに、変化が発見された場合、プロセッサ３４はステッ
プ８４において、その変化を用いて、スナップショット
・バッファ５０を更新する。次に、プロセッサ３４は、
ステップ８６において、この変化をパケットに変換す
る。ステップ８８において現バッファ５４、５８、６２
に選択的に入力されるのは、パケットに変換された変化
である。次に、プロセッサ３４はステップ８０に戻って
他の変化を探し、ステップ８２において、プロセッサが
バッファ５０、５２における表示データ間にもはや変化
がないと判定するまで、ステップ８２、８４、８６、８
８を繰り返す。一旦プロセッサ３４が、ステップ８２に
おいてもはや変化がないと判定したなら、プロセッサ３
４は、ステップ９０において、カーソル位置が変化した
か否かについて判定を行う。位置が変化していた場合、
プロセッサ３４は、ステップ９２において、ステップ８
８で実行したのと同様の方法で、移動カーソル・パケッ
トを現バッファ５４、５８、６２に記憶する。カーソル
位置が変化していない場合、既存のカーソル位置へのパ
ケットのリライトを実施する。

【００５６】次に図７を参照する。図７には、図６のス
テップ８８を実行する際に行われるステップの一層詳し
いフローチャートが示されている。プロセッサ３４は、
ステップ９４において、現リセット・シーケンス・バッ
ファ５４が満杯か否かについて判定を行う。即ち、ステ
ップ９４は、バッファ５４に送られたパケットにより当
該バッファが満杯になったか否かを示す。バッファ５４
が満杯でない場合、プロセッサ３４は、ステップ９６に
おいて、現パケットを現リセット・シーケンス・バッフ
ァ５４に送出する。ステップ９８において、現シーケン
ス・バッファ５８が満杯となりこれ以上パケットを受け
入れることができないか否かを、プロセッサ３４が判定
する。満杯の場合、プロセッサ３４は、ステップ１００
において、最も古いパケットを現シーケンス・バッファ
５８から除去し、その後、この最も古いパケットを文字
／属性ワードに変換する。この除去されたパケットの文
字／属性ワードは、次いでステップ１０２において、現
開始バッファ６２に送出される。プロセッサ３４は、ス
テップ９８において、現シーケンス・バッファ５８はパ
ケットを受け入れられない程満杯ではないと判定するま
で、ステップ９８、１００、１０２を繰り返す。満杯で
はないと判定した時点で、プロセッサ３４は、ステップ
１０４において、パケットを現シーケンス・バッファ５
８に入力する。

【００５７】以下の表３及び表４（表４は表３の続き）
に示すのは、Ｃ言語の関数find_change()のコードのフ
ラグメント（断片）である。これは、プロセッサ３４が
図６のフローチャートに示した機能を周期的に実行する
際に使用可能である。

【００５８】

【表３】

【表４】

【００５９】以下に示すのは、Ｃ言語の関数put_packet
()のコードの断片であり、プロセッサ３４が図７のフロ
ーチャートに示した機能を周期的に実行する際に使用可
能である。

【００６０】

【表５】

【００６１】次に図８を参照する。図８には、プロセッ
サ３４が遠隔端末２８上にビデオ画面のリセット・シー
ケンスを再生する際に実行するステップを表わす、フロ
ーチャートが示されている。管理者はまず現リセット・
シーケンスまたは前リセット・シーケンスは再生する必
要があるか否かについて判定を行う。プロセッサ３４
は、現リセット・シーケンス・バッファ５４または前リ
セット・シーケンス・バッファ５６を、それぞれ、再生
すべきリセット・バッファとして選択することによって
応答する。システム管理者がサーバ・コントローラ２６
にリセット・シーケンスの一方を再生するように命令す
ると、プロセッサ３４は、ステップ１０６において、リ
セット・バッファには表示すべきパケットが未だあるか
否かについて判定を行う。表示すべきパケットがある場
合、プロセッサ３４は、ステップ１０８において、リセ
ット・シーケンス・バッファから次のパケットを読み出
し、当該パケットを文字列に変換する。次に、プロセッ
サ３４は、ステップ１１０において、この文字列を遠隔
端末２８に送信することによって、文字列を遠隔端末２
８上に表示する。プロセッサ３４がステップ１０６にお
いて表示すべきパケットがもはやないと判定するまで、
プロセッサ３４はステップ１０６、１０８、１１０を繰
り返す。

【００６２】以下の表６に示すのは、Ｃ言語の関数vide
o_reset_play()のコードの断片であり、プロセッサ３４
が図８のフローチャートに示した機能を周期的に実行す
る際に使用可能である。

【００６３】

【表６】

【００６４】図９には、プロセッサが障害シーケンスを
遠隔端末２８上に再生する際に実行するステップを表わ
す、フローチャートが示されている。システム管理者が
サーバ・コントローラ２６に障害シーケンスを再生する
ように命令すると、プロセッサは、ステップ１１２にお
いて、障害バッファ６４内に表示すべき文字が未だある
か否かについて判定を行う。尚、現開始バッファ６２お
よび障害開始バッファ６４は、画面自体ではなく、画面
変化を記憶するバッファ（即ち、バッファ５４〜６０）
内にあるパケットの代わりに、文字（即ち、文字／属性
対から成るワード）を格納するものである。バッファ６
４内に未だ表示すべき文字がある場合、プロセッサ３４
は、ステップ１１４において、障害開始バッファ６４か
ら次の文字を読み出し、その文字を遠隔端末２８に送信
することによって、遠隔端末２８上にその文字を表示す
る。プロセッサがステップ１１２において障害開始バッ
ファ６４内にはもはや表示すべき文字がないと判定する
まで、プロセッサ３４はステップ１１２、１１４を繰り
返す。尚、文字は障害開始バッファ６４から消去される
のではなく、文字のコピーが取られるようにしているこ
とを注記しておく。

【００６５】一旦プロセッサ３４がステップ１１２にお
いて障害開始バッファ６４における文字全てを表示した
と判定したなら、プロセッサ３４は、ステップ１１６に
おいて、表示すべき別のパケットを障害シーケンス・バ
ッファ６０内で検索する。別のパケットがない場合、プ
ロセッサ３４は障害シーケンスの再生を終了する。その
他の場合、プロセッサ３４は、ステップ１１８におい
て、パケットをＡＮＳＩ文字列に変換する。次に、プロ
セッサ３４は、ステップ１２０において、その文字列を
遠隔端末２８に送信することによって、その文字列を遠
隔端末２８上に表示する。プロセッサ３４は、ステップ
１１６において障害シーケンス・バッファ６０内のパケ
ット全てを表示したと判定するまで、ステップ１１６、
１１８、１２０を繰り返す。

【００６６】以下の表７及び表８は、Ｃ言語の関数vide
o_failure_play()のコードのフラグメントであり、プロ
セッサ３４が図９のフローチャートに示した機能を周期
的に実行する際に使用可能である。なお、表８は表７の
続きである。

【００６７】

【表７】

【表８】

【００６８】再生シーケンスの再生は、管理者が図２の
ｃに示したメニューに応答して、スペース・キーを押圧
したときに開始する。再生は、文字およびエスケープ・
シーケンスのストリームを遠隔端末に送り、シーケンス
・バッファ内の情報を表示することから成る。文字の中
には制御文字があり（アスキー値で０〜３１および１２
７）、実際の文字を表示するのではなく、ベルを鳴らす
等の機能を行う。その結果、これら表示不可文字の１つ
がローカル・フレーム・バッファ４８内に現れた場合、
実際にはスペースまたは同様に見える表示可能文字のい
ずれかとして遠隔端末に送られる。エスケープ・シーケ
ンス（エスケープ文字（アスキー値0x1B)で始まる文字
列）は、カーソルの移動、画面のクリア、および現表示
カラーの変更というような他の作用を行うために用いら
れる。サーバ・コントローラ２６は、文字０〜３１、１
２７、２２５以外の全ての文字を変化させずに送信す
る。これらの文字は、以下の表８に示すように、アスキ
ー・バイトにリマップされる。

【００６９】

【表９】

【００７０】以下に示すのは、サーバ・コントローラ２
６によって送出されるエスケープ・シーケンスであり、
ここで＼x1BがＥＳＣ文字である。Compaq Insight Mana
ger(CIM)アプリケーションを遠隔端末２８上で実行して
いる場合、サーバ・コントローラ２６は所定の標準外エ
スケープ・シーケンスを送信し、ＣＩＭと通信を行う。
これらの標準外エスケープ・シーケンスは、以下の表９
において、アステリスクで示すことにする。

【００７１】

【表１０】

【００７２】上記表１０において、「＋」文字が印され
ているエスケープ・シーケンスは、白黒モードにおいて
用いられるカラー・エスケープ・シーケンスのみであ
る。黒および高輝度の黒を除く全てのカラーは、白また
は高輝度の白に変換される。

【００７３】サーバ・コントローラ２６がＣＩＭと通信
していないとき、高輝度背景カラーは対応外となり、通
常の輝度と同一のカラーとして送られる。前景がこの通
常輝度のカラーである場合、以下の表１０にしたがって
未だ見ることができるように、前景カラーのリマッピン
グを行う。

【００７４】

【表１１】

【００７５】次に図１０のａ〜ｅを参照する。障害シー
ケンスの画面ショット(screen shot)の例が示されてい
る。画面シーケンスは、遠隔端末２８上にサーバ・コン
トローラ２６によって表示された再生シーケンスの例で
ある。図１０のａは、サーバ起動時の典型的な初期画面
の画面ショットである。この画面は、システム・コンフ
ィギュレーションに関する様々な項目を示す。図１０の
ｂは、典型的なWINDOWS NTのローダ画面の画面ショット
である。ユーザには、複数のブートするNTカーネル間か
ら選択する機会が与えられる。図１０のｃは典型的なNT
のブート画面の画面ショットである。このスクリーン
は、カーネルの構築バージョン、システム・メモリ量、
プロセッサのコンフィギュレーション等を含む。図１０
のｄは、サーバ１０の表示装置２４がホストＣＰＵ１２
によってグラフィック・モードに設定されたことを示す
パケットを再生シーケンスが含むときに、この再生シー
ケンスの間に、サーバ・コントローラ２６によって遠隔
端末２８上に表示されたメッセージを示す。図１０のｅ
は、典型的なNTのブルー・スクリーンの画面ショットで
ある。

【００７６】拡張バス（好ましくは、ＥＩＳＡバス）を
監視してビデオ・サブシステムへの書き込みを見つけ出
すことによって、サーバ・コントローラ２６は、リアル
・タイムでビデオ・データの更新を得て、再生シーケン
スの再生を実現可能にする。加えて、拡張バスを監視し
てビデオ・サブシステムへの書き込みを見つけ出すこと
によって、サーバ・コントローラ２６は、サーバ１０に
は割り込みをかけない(non-intrusive)方法で、より具
体的には、拡張バス帯域には割り込みをかけずに、ビデ
オ・データの更新を得ることができる。他の方策には、
割り込みをかけ非リアル・タイムでビデオ・データを得
るものもある。例えば、COMPAQ ServerManager/R
（「ＳＭＲ」）という製品は、ＥＩＳＡバス・サイクル
の主導権(mastership)をアサートし、サーバ１０のビデ
オ・メモリ２２内のデータを得る。ＳＭＲは、こうする
ことにより、表示データの一部をビデオ・メモリ２２か
らそれ自体のメモリに周期的にコピーする。コピーされ
たデータは、次に、ビデオ・データの以前のコピーと比
較され、画面変化が判定される。ＳＭＲのバス支配法
は、ＥＩＳＡバス上のトラフィック増大を招くという欠
点があり、他のＥＩＳＡバス・マスタに、余分なバス仲
裁遅延を付加することになる。

【００７７】再び図４を参照しながら、検出ロジック３
０内の様々なブロック４０〜４４についての説明を行
う。検出ロジック３０は、アドレス・バッファ４２、デ
ータ・トランシーバ４４、ならびにＥＩＳＡバスおよび
コントローラ・バス間に結合された制御ロジック４０か
ら成る。制御ロジック４０およびプロセッサ３４は、HO
LDおよびHLDA（HOLD承認）信号によって結合されてい
る。アドレス・バッファ４２、データ・トランシーバ４
４、および制御ロジック４０は協同して表示データを監
視し、その後、コントローラ・メモリ３２の一部を形成
するローカル・フレーム・バッファ４８（図５）にデー
タを書き込む。

【００７８】コントローラ・メモリ３２は、プロセッサ
３４および検出ロジック３０の双方がコントローラ・メ
モリ３２を変更するという点において、プロセッサ３４
および検出ロジック３０間で共有されるリソースであ
る。コントローラ・メモリ３２は、単一ポートの疑似ス
タティックＲＡＭから成る。したがって、検出ロジック
３０は、プロセッサ３４からサイクルを盗み、コントロ
ーラ・メモリ３２にビデオ・データを書き込む。ライト
・サイクルがビデオ・サブシステムに発生すると、検出
ロジック３０はライト・サイクルをデコードし、プロセ
ッサ３４をオンに維持し、ビデオ・データをコントロー
ラ・メモリ３２に書き込む。サーバ・コントローラ２６
は、ビデオ・データをビデオ・サブシステムに書き込む
と同時に、ビデオ・データをコントローラ・メモリ３２
に書き込み、サーバ１０上での通常のビデオ・アクティ
ビティを持続させる利点がある。

【００７９】制御ロジック４０は、拡張バスからアドレ
ス信号を受け取り、ビデオ・アドレス範囲にあるアドレ
スの存在をデコードする。ビデオ・アドレス範囲内のア
ドレスが拡張バス・アドレス信号上に現れた場合、制御
ロジック４０は、プロセッサ３４へのHOLD信号をアサー
トすることによって、プロセッサ３４をオンに保持し、
コントローラ・メモリ３２に対するアービトレーション
（仲裁）を行う。プロセッサ３４はHLDAをアサートし、
コントローラ・バスの所有権を制御ロジック４０に与え
る。

【００８０】制御ロジック４０は、ビデオ・サブシステ
ムへのライト・サイクル完了の前に、コントローラ・バ
スの所有権を得ることができ、かつ、コントローラ・メ
モリ３２にビデオ・データを書き込めることを、保証し
なければならない。これを行うために、制御ロジック４
０は、ＥＩＳＡ拡張バス内の所定の信号を利用する。制
御ロジック４０は、ＥＩＳＡ拡張バスにおいて得ること
ができるEXRDY信号を利用する。拡張バスがＩＳＡバス
である場合、制御ロジック４０はCHRDY信号を利用す
る。いずれの場合でも、EXRDYまたはCHRDYは、制御ロジ
ック４０がコントローラ・バスの所有権を得るまで、ビ
デオ・サブシステムへの拡張バスのライト・サイクルを
遅らせるように機能する。

【００８１】拡張バスのSTART#信号がアサートしている
間に、ＥＩＳＡ拡張バス（拡張バス）のBCLK信号の立ち
上がりエッジ上において、制御ロジック４０は拡張バス
のアドレス信号からアドレスをラッチする。制御ロジッ
ク４０は、拡張バス上の他の信号、即ち、BCLK、STAR
T、および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#間のギャップを覆うことになる。

【００９０】ＥＩＳＡ拡張バスのアドレス信号がビデオ
・アドレス範囲にあるときに真となる、追加の信号EARL
Y_DECODEを定義する。EARLY_DECODE，W_R、CMD#およびN
_STARTを組み合わせることにより、有効なライト・サイ
クルは次のように定義される。

【００９１】

【数２】VALID_CYCLE = N_START * EARLY_DECODE * W_R
+VALID_CYCLE * !CMD# VALID_CYCLEを用いると、EXRDYは、VALID_CYCLEがアサ
ートされ、プロセッサ３４が未だHLDAをアサートしてい
ないときにアサートされる。次いで、EXRDYは、HLDAが
付与されるBCLKの次の立ち下がりエッジまで、アサート
されたまま維持される。

【００９２】このように、制御ロジック４０はN_START
を用いて、EXRDYに対するＥＩＳＡのタイミング要件を
満足し、したがって典型的な状況では割り込みを発生さ
せない、即ち、ビデオ・サブシステムに対する処理では
遅延サイクルを導入させないという利点がある。また、
ＥＩＳＡ拡張バスおよびコントローラ・バスはクロック
信号が異なるので、制御ロジック４０は、N_STARTを用
いて、ＥＩＳＡ拡張バスおよびコントローラ・バス間の
同期を取る。N_STARTを用いることによって（即ち、BCL
Kがローの期間）、制御ロジック４０は、有効なライト
・サイクルを判定する際に、START#の立ち上がりエッジ
（少なくとも６０ナノ秒遅く発生する。即ち、BCLKの立
ち上がりエッジと同期して発生する）を用いる場合より
も、同期時間において少なくとも６０ナノ秒の優位を享
受するという利点がある。

【００９３】図１１のタイミング図は、ＥＩＳＡ拡張バ
ス信号BCLK、START#、CMD#、LA、W_RのEARLY_DECODE、H
OLD、N_START、VALID_CYCLE、およびEXRDY信号に対する
関係を示している。図１１が示すビデオ・ライト・サイ
クルは、プロセッサ３４がHLDAを十分に早く付与しない
ため、制御ロジック４０がEXRDYをローに駆動し、第２
のビデオ・ライト・サイクルに続いて遅延サイクルを挿
入しなければならない場合である。第１および第２のビ
デオ・ライト・サイクルは、連続ビデオ・ライト・サイ
クルを構成する。本発明によれば、第２のビデオ・ライ
ト・サイクルは、第１のライト・サイクルが遅延サイク
ルを誘発しても、遅延サイクルを誘発しないという利点
がある。BCLKのエッジには１〜１４まで連続的に付番し
てあり、図１１の説明の明確化を図っている。図１１に
示すHLDA信号は、プロセッサ３４からのHLDA信号を、Ｅ
ＩＳＡ拡張バスのクロックBCLKと同期させたものであ
る。

【００９４】ＥＩＳＡバス・インターフェース１８は、
ビデオ・サブシステムに書き込みを行いたいＣＰＵ１２
の代わりに、BCLKの立ち下がりエッジ２付近で、LA信号
上にビデオ・アドレス範囲のアドレスを発生する。制御
ロジック４０は、これに応答して、EARLY_DECODE信号を
アサートする。その後すぐに、制御ロジック４０はプロ
セッサ３４へのHOLDをアサートする。HOLD信号がアサー
トされるのは、EARLY_DECODE信号がアサートされるとき
であり、VALID_CYCLE信号がアサートされ続ける限りHOL
D信号もアサートされたままでいる。VALID_CYCLEの間
中、HOLDをアサートさせ続けることによって、制御ロジ
ック４０は、コントローラ・メモリ３２へのビデオ・デ
ータの書き込みが完了するまで、コントローラ・バスの
所有権を保持する。加えて、HOLD信号は、EARLY_DECODE
がアサートされ、無効タイマ(defeat timer)が終了して
いない場合にも（以下で論ずる）、アサートされる。HO
LD信号はプロセッサ３４のクロックと同期している。BC
LKの立ち上がりエッジ３で、バス・インターフェース１
８はSTART#（アクティブ・ローの信号）をアサートし、
このサイクルのアドレス・フェーズを開始する。バス・
インターフェース１８はW_R信号をアサートし、ライト
・サイクルであることを示す。

【００９５】BCLKの立ち下がりエッジ４において、BCLK
がローとなり、START#がアサートされてローとなるの
で、これに応答して制御ロジック４０はN_STARTをアサ
ートする。N_STARTは、BCLKの立ち上がりエッジ５でCMD
#がアサートされてローになるまで、アサートされたま
までいる。アクティブなN_STARTは、W_Rが有効であるこ
とを意味し、W_Rはライト・サイクルを示し、EARLY_DEC
ODEはビデオ・アドレス範囲内のアドレスを示すので、
制御ロジック４０は対応してVALID_CYCLEをアサートす
る。BCLKの立ち下がりエッジ４の後にアサートされたVA
LID_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の
立ち上がりエッジ１３付近で（即ち、第１のライト・サ
イクルにおけるよりも１クロック・サイクル分早く）CM
D#をディアサートしてハイとし、第２のライト・サイク
ルのデータ・フェーズを終了する。また、第２のビデオ
・ライト・サイクルは、連続ビデオ・ライト・サイクル
ではないことも表しており、このサイクルでは、制御ロ
ジック４０がEXRDYをローに駆動して遅延サイクルを挿
入する必要がないように、HLDAを十分に早く付与するよ
うにしている。

【００９８】本発明の一実施例では、サーバ・コントロ
ーラ２６は、ビデオ・コントローラ２０とビデオ・メモ
リ２２から成る、サーバ１０のビデオ・サブシステムに
類似したコントローラ・ビデオ・サブシステム（図示せ
ず）を更に備えている。コントローラ・ビデオ・サブシ
ステムは、システム・コンフィギュレーション・ソフト
ウエアによって選択的にディゼーブルすることができ
る。コントローラ・ビデオ・サブシステムはＩＳＡ装置
である。コントローラ・ビデオ・サブシステムをイネー
ブルすると、サーバ・コントローラ２６は、ＥＩＳＡ拡
張バスのEXRDY信号ではなく、ＩＳＡバスの信号CHRDYを
ニゲートする。

【００９９】コントローラ・ビデオ・サブシステムの目
的は、サーバ１０上のＶＧＡコントローラがＰＣＩＶ
ＧＡコントローラである場合、ビデオ・データの書き込
み動作が拡張バス上に現れるようにすることである。こ
れがないと、ＰＣＩＶＧＡコントローラがビデオ・ラ
イトをデコードしこれに応答するので、バス・インター
フェース・ユニット１８にビデオ・ライトをＥＩＳＡ拡
張バスに送出させないようになる。その結果、ＥＩＳＡ
拡張バス上にはビデオ・ライト・サイクルがなくなる。
即ち、サーバ・コントローラ２６が監視するビデオ・ラ
イト・サイクルがなくなってしまう。したがって、ＰＣ
ＩＶＧＡコントローラがシステム内にある場合、ユー
ザはサーバ・コントローラ２６上のコントローラ・ビデ
オ・サブシステムをイネーブルし、ＰＣＩＶＧＡコン
トローラをディゼーブルすることにより、ビデオ・ライ
ト・サイクルの監視および再生シーケンスの捕獲ができ
るようにしなければならない。

【０１００】バス・インターフェース・ユニット１８
（即ち、ＥＩＳＡバス・ブリッジ）の実現においては、
拡張バスのアドレス信号上のアドレスを駆動し、拡張バ
ス（即ち、ＥＩＳＡバス）上の当該アドレスをラッチし
駆動して、有効なサイクルの終了時に、当該有効サイク
ルの後に発生するアイドル・サイクルの間、アドレス信
号が浮動しないようにすることは一般的である。この状
態では、制御ロジック４０にEARLY_DECODE信号をアサー
トさせ、結果的に、比較的長い時間にわたってプロセッ
サ３４へのHOLDを連続的にアサートさせる。その結果、
プロセッサ３４は不必要に飢える(starved)ことにな
る。この問題に対する１つの解決策は、CMD#の立ち上が
りエッジ上で、サイクルの終了時にHOLDをニゲートする
ことであろう。しかしながら、その結果、制御ロジック
４０は、EXRDYをニゲートして遅れを導入することによ
り、１ブロックの連続ライト・サイクルの各ライト・サ
イクル毎に、制御バスの仲裁を再度行い、ＥＩＳＡ拡張
バスおよびコントローラ・バス間で再度同期をとらなけ
ればならない。

【０１０１】本発明は、無効タイマを用いて、上述の問
題を解決する。制御ロジック４０は、ＥＩＳＡ拡張バス
のアドレス信号が未だビデオ・アドレス範囲内のアドレ
スを有する場合、サイクルの後に所定数のBCLKを計数す
るカウンタを備えている。START#がアサートされること
なく、カウンタが終了カウントに到達した場合、制御ロ
ジック４０はHOLDをニゲートし、制御ロジック４０がビ
デオ・アドレス範囲内のアドレスをデコードすることに
よる次のSTART#のアサートまで、HOLDをアサートしな
い。

【０１０２】このように、無効タイマを用いることによ
り、制御ロジック４０は、制御ロジック４０がSTART#の
アサートまで待ってHOLDをアサートする場合に可能とな
るよりも早く、HOLDをアサートし、ビデオ・サブシステ
ムへのビデオ・データの書き込みの間に遅延サイクルを
導入しなくても済む可能性が高くなるという利点があ
る。更に、無効タイマは、制御ロジック４０をイネーブ
ルし、１ブロックの連続有効ビデオ・ライト・サイクル
の間、HOLDをアサート状態に保持することにより、ビデ
オ・サブシステムへのビデオ・データの書き込みの間、
サーバ１０に遅延サイクルを導入するのを回避するとい
う利点もある。

【０１０３】遠隔端末２８は、通信ユニット３６を介し
て、サーバ・コントローラ２６との通信接続を確立す
る。遠隔端末２８およびサーバ・コントローラ２６間の
接続は、一般的に、帯域外接続(out-of-band connectio
n)または非同期接続と呼ばれている。帯域外接続とは、
ローカル・エリア・ネットワーク・イーサネット接続の
ような標準的なネットワーク媒体を通じてではなく、電
話線または直接直列接続を介して確立されるネットワー
ク接続のことである。帯域外接続を設けることにより、
サーバ・コントローラ２６は、サーバ１０が通常に機能
している場合、またはオペレーティング・システムのク
ラッシュや、サーバ１０が接続されているローカル・エ
リア・ネットワーク上の障害のような障害が発生した場
合のいずれの場合にも、遠隔端末２８との通信を確立す
ることができる。

【０１０４】第１のモードでは、遠隔端末２８は、ＡＮ
ＳＩの端末エミュレーション・プロトコルを用いて、サ
ーバ・コントローラ２６との接続を確立する。このプロ
トコルのことを以降テキスト・プロトコルと呼ぶことに
する。第２のモードでは、遠隔端末２８は、サーバ・コ
ントローラ２６と二地点間プロトコル（ＰＰＰ：point-
to-point protocol）を確立する。ＰＰＰについては、I
nternet EngineeringTask Force (「IETF」）に記載さ
れている。そのUniform Resource Locator（「ＵＲ
Ｌ」）は、http://www.ietf.cnri.reston.va.us/home.h
tmlである。特に、ＲＦＣ１６６１、１６６２、１６６
３は本発明に関連があり、この言及により本願にも含ま
れているものとする。遠隔端末２８がサーバ・コントロ
ーラ２６を呼び出すと、サーバ・コントローラ２６のプ
ロセッサ３４上で実行するサーバ・コントローラ２６の
ソフトウエアは、２つのデータ・リンク・レイヤ・プロ
トコルの内どちらを、遠隔端末２８が使用しているのか
を自動的に判定するという利点がある。

【０１０５】第１のモードでは、サーバ・コントローラ
・コンソール・アプリケーションと呼ばれる、サーバ・
コントローラ２６のソフトウエアの一部が、テキスト・
プロトコルを用いて、遠隔端末２８と通信する。サーバ
・コントローラ・コンソール・アプリケーションは、遠
隔端末２８が、再生シーケンスの閲覧(viewing)のよう
なサーバ・コントローラ２６の様々な構成にアクセスで
きるようにする。加えて、サーバ・コントローラ・コン
ソール・アプリケーションは、、遠隔リセットの実行、
警報およびログイン情報の管理、遠隔地からのコンソー
ルへのアクセス、サーバ１０のイベント・ログ、エラー
・ログおよびステータス・ログの閲覧を、システム管理
者に可能とする。図２のａ〜ｃを再び参照すると、サー
バ・コントローラ・コンソール・アプリケーションの３
種類のメニュー画面が示されている。遠隔端末２８は、
通常、コンピュータであり、既知の製品であるSYMANTEC
pcANYWHEREまたはDATASTORM TECHNOLOGY ProComm のよ
うな、種々の販売会社から入手可能な一般的なＡＮＳＩ
の端末エミュレーション・ソフトウエア・アプリケーシ
ョンを実行することによって、サーバ・コントローラ２
６と通信を行う。

【０１０６】第２のモードでは、遠隔端末２８は、ロー
カル・エリア・ネットワーク（ＬＡＮ）のそれと同様の
ＰＰＰ接続を通じて、サーバ・コントローラ２６とのＴ
ＣＰ／ＩＰリンクを確立する。遠隔端末２８はCOMPAQ I
nsight Manager (CIM)を実行し、ＴＣＰ／ＩＰ接続を通
じてサーバ・コントローラ２６との通信を行う。サーバ
・コントローラ２６は、２つの方法で、ＣＩＭと通信を
行う。すなわち、第１に、サーバ・コントローラ２６
は、TELNET接続を通じてＣＩＭと通信を行い、テキスト
・プロトコルを用いる第１モードと全く同様に、サーバ
・コントローラ・コンソール・アプリケーションを実行
する。

【０１０７】第２に、サーバ・コントローラ２６は、サ
ーバ１０を管理する目的のために、ＣＩＭに対して、SN
MPパケットの送受信を行う。例えば、サーバ１０はサー
バ１０上の障害またはその他のイベントを検出し、SNMP
トラップ・パケットを、サーバ・コントローラ２６を通
じて、遠隔端末２８上で実行中のＣＩＭに送り、サーバ
１０が接続されているＬＡＮ上のクライアント上でＣＩ
Ｍが実行されているかのように、システム管理者にその
イベントについて通知する。加えて、サーバ１０の障害
の場合、サーバ・コントローラ２６はその障害を検出
し、SNMPトラップ・パケットをＣＩＭに自動的に送る。
この第２のモード、即ち、ＰＰＰ接続によるモードで
は、サーバ・コントローラ２６は、同時に、サーバ・コ
ントローラ・コンソール・アプリケーションおよびSNMP
パケットによって、遠隔端末２８と通信を行うこともで
きる。

【０１０８】ＣＩＭによるサーバ１０の管理の別の例
は、遠隔端末２８がサーバ・コントローラ２６を通じて
「要求獲得」SNMPパケットをサーバ１０に送り、サーバ
のサブシステムの１つの状態(health)のような、サーバ
に関する管理情報を要求することである。サーバ・コン
トローラ２６はSNMPパケットをオペレーティング・シス
テムに送出する。オペレーティング・システムは、要求
された情報を集め、「応答獲得」パケットをサーバ・コ
ントローラ２６に送る。一方、サーバ・コントローラ２
６はパケットをＣＩＭに送出する。

【０１０９】WINDOWS NTのRemote Access Services
（ＲＡＳ）は、ＰＰＰ接続を確立し、ヌル・モデム(nul
l-modem)によって接続された２台のコンピュータ間の通
信を提供する。ＮＴＲＡＳはこのＰＰＰ接続を確立す
る、所有権を主張する方法(proprietary method)を用い
る。この方法のことを以降「予備ＰＰＰプロトコル」(p
re-PPP protocol)と呼ぶことにする。これは２台のコン
ピュータ間で１対の文字列を交換するためのものであ
る。接続を確立したい第１のコンピュータが、文字列"C
LIENT"を第２のコンピュータに送る。次に、第２のコン
ピュータは、"CLIENT"文字列を受け取った後、文字列"C
LIENTSERVER"を第１のコンピュータに送る。一旦この２
つの文字列の交換が行われたなら、２台のコンピュータ
は必要な文字パケットの交換に進み、ＰＰＰ接続を確立
する。標準的なＰＰＰ接続では、この２つの文字列の初
期交換は必要でない。サーバ・コントローラ２６は、ヌ
ル・モデムを通じたＮＴＲＡＳとのＰＰＰ接続、およ
び標準的なＰＰＰプロトコルを用いた遠隔端末２８との
ＰＰＰ接続の双方を確立することができる。

【０１１０】次に図１２を参照すると、サーバ・コント
ローラ２６がどの通信プロトコルが遠隔端末２８から送
られているのかをどのようにして検出するのかを示すフ
ローチャートが示されている。遠隔端末２８が接続を確
立する前に、サーバ・コントローラ２６のソフトウエア
は、ステップ１３０において、サーバ・コントローラ２
６のソフトウエアの中にある３つの状態マシンをリセッ
トする。テキスト・プロトコル、ＰＰＰプロトコル、お
よび予備ＰＰＰプロトコルという有効なプロトコル各々
に１つの状態マシンが存在する。

【０１１１】サーバ・コントローラ２６が通信ユニット
３６からの割り込みを待っている間、プロセッサ３４は
再生シーケンスを処理することができる。キャリア信号
がサーバ・コントローラ２６上で受信されたとき、コン
トローラ２６内のソフトウエアは、ステップ１３４にお
いて、状態マシンをリセットし、ステップ１３６におい
てタイマを設定する。一実施例では、タイマは３０秒後
に終了するように設定される。サーバ・コントローラ２
６のソフトウエアは、ステップ１３８において、タイマ
が終了したか否かについて判定を行う。タイマが終了し
ていた場合、サーバ・コントローラ２６のソフトウエア
は、ステップ１４０において、サーバ・コントローラ２
６内の上位タスクに、プロトコルはテキスト・プロトコ
ルであると伝達することによって、プロトコルがテキス
ト・プロトコルであることを宣言する。

【０１１２】遠隔端末２８から文字または信号を受信す
る前に、サーバ・コントローラ２６内のソフトウエアは
ビデオ画面変化を処理することができる。一旦割り込み
が発生し、文字または信号の存在が示されたなら、サー
バ・コントローラ２６のソフトウエアは、ステップ１４
２において、「無キャリア」信号が通信ユニット３６か
ら送られて、遠隔端末２８からキャリアの損失が示され
たか否かについて判定を行う。キャリアが失われていた
場合、サーバ・コントローラ２６のソフトウエアは、ス
テップ１４４において、タイマをクリアし、ステップ１
３０に戻る。

【０１１３】ステップ１４２において「無キャリア」信
号が受信されなかった場合、サーバ・コントローラ２６
のソフトウエアは、ステップ１４６において、文字が受
信されたか否かについて判定を行う。受信されていない
場合、サーバ・コントローラ２６のソフトウエアはステ
ップ１３８に戻り、タイマが終了するのを待つか、ある
いは信号または文字が到達したことを示す割り込みが受
信されるのを待つ。

【０１１４】ステップ１４６において文字が受信された
場合、サーバ・コントローラ２６のソフトウエアは、ス
テップ１４８において、その文字を３つのプロトコルの
状態マシンに渡す。ステップ１５０において、状態マシ
ンに有効なプロトコルを検出したものがない場合、サー
バ・コントローラ２６のソフトウエアはステップ１３８
に戻る。ステップ１５０において、状態マシンの内の１
つが有効なプロトコルを検出した場合、サーバ・コント
ローラ２６のソフトウエアはステップ１５２においてタ
イマをクリアし、次にステップ１５４において、３つの
プロトコルの内どれが検出されたのかを上位タスクに宣
言する。

【０１１５】プロセッサ３４は、図１１の説明において
述べた通信ユニット３６のような種々の割り込みソース
からの割り込みを受け取るように構成されている。プロ
セッサ３４は、割り込み記述子テーブルを備えており、
テーブル内の各エントリが、割り込みソースに対応する
割り込みサービス・ルーチンを参照する。割り込みソー
スの１つが割り込みを発生した場合、プロセッサ３４
は、この割り込みソースに対応する割り込み記述子テー
ブル内のエントリによって参照される、割り込みサービ
ス・ルーチンの実行を開始する。割り込みサービス・ル
ーチンはサーバ・コントローラ２６のソフトウエアの一
部であり、プロセッサ３４上で実行する。通信ユニット
３６は、遠隔端末２８からの文字、あるいは「キャリ
ア」または「無キャリア」のような信号の受信時に、プ
ロセッサ３４に割り込みをかけるように構成されてい
る。割り込みサービス・ルーチンは、プロセッサ３４上
で実行する他のソフトウエア・タスクと通信を行い、遠
隔端末２８との通信に便宜を図る。

【０１１６】最初に、即ち、遠隔端末２８がサーバ・コ
ントローラ２６との接続を確立する前に、通信ユニット
３６に対応する割り込み記述子テーブルのエントリは、
プロトコル検出割り込みサービス・ルーチンへの参照に
よって、分類される(populate)。プロトコル検出割り込
みサービス・ルーチンは、サーバ・コントローラ２６の
ソフトウエアの、３つのプロトコル状態マシンを含む部
分である。また、プロトコル検出割り込みサービス・ル
ーチンは、サーバ・コントローラ２６のソフトウエア
の、通信ユニット３６から入来する文字を受け取るソフ
トウエアの部分でもある。プロトコル検出割り込みサー
ビス・ルーチンによって受け取られる各文字は、３つの
プロトコル状態マシンへの入力として作用する。

【０１１７】一旦ステップ１４０またはステップ１５４
のいずれかにおいて有効なプロトコルが検出されたこと
が上位タスクに通知されたなら、上位タスクは、検出さ
れた特定のプロトコルに専用の割り込みサービス・ルー
チンへの参照により、通信ユニット３６に対応する割り
込み記述子テーブルのエントリを分類する。ＰＰＰおよ
び予備ＰＰＰプロトコルは、同じ割り込みサービス・ル
ーチンを有する。

【０１１８】表１２〜１６（表１２には表１３が、表１
３には表１４が、表１５には表１６が、それぞれ連続す
る）に示される補足資料は、ＰＰＰ割り込みサービス・
ルーチンの部分のアセンブリ言語によるソース・コード
・リストである。このコード部分は、割り込みサービス
・ルーチンがどのようにして入来する文字を受け取って
処理し、有効なＰＰＰパケット全体の有効性の判断およ
び／またはこのＰＰＰパケットの形成を行うかを示した
ものである。一旦ＰＰＰパケットが形成されたなら、割
り込みサービス・ルーチンは、当該パケットの存在に関
して、サーバ・コントローラ２６のソフトウエアの上位
タスクに通知する。

【０１１９】

【表１２】

【表１３】

【表１４】

【表１５】

【表１６】

【０１２０】次に図１３を参照すると、テキスト・プロ
トコルの状態マシンを表わす状態図が示されている。テ
キスト・プロトコルの状態マシンが３つの連続したアス
キー「リターン」文字（0X20）を検出した場合、遠隔端
末２８から有効なテキスト・プロトコルが検出されたこ
とを示す。TEXT_INT状態１５６において、状態マシンが
キャリッジ・リターン文字を受け取った場合、状態マシ
ンはTEXT_ONE状態１５７に遷移する。その他の場合、状
態マシンはTEXT_INT状態１５６に留まる。TEXT_ONE状態
１５７において、状態マシンがキャリッジ・リターン文
字を受け取った場合、状態マシンはTEXT_TWO状態１５８
に遷移する。その他の場合、状態マシンはTEXT_INIT状
態１５６に戻る。TEXT_TWO状態１５８において、状態機
械がキャリッジ・リターン文字を受け取った場合、状態
マシンはTEXT_DETECTED状態１５９に遷移する。その他
の場合、状態マシンはTEXT_INIT状態１５６に戻る。状
態マシンがTEXT_DETECTED状態１５９になった場合、サ
ーバ・コントローラ２６のソフトウエアの上位タスク
に、有効なテキスト・プロトコルが検出されたことを通
知する。

【０１２１】図１４は、予備ＰＰＰの状態マシンを表わ
す状態図が示されている。予備ＰＰＰ状態マシンが文字
列"CLIENT"を検出した場合、遠隔端末２８から有効な予
備ＰＰＰプロトコルが検出され、対応して文字列"CLIEN
TSERVER"を遠隔端末２８に送信することを示す。CLIENT
_INT状態１６２において、状態マシンが「Ｃ」を受け取
った場合、状態マシンはCLIENT_C状態１６３に遷移す
る。その他の場合、状態マシンはCLIENT_INT状態１６２
に留まる。CLIENT_C状態１６３において、状態マシンが
「Ｌ」を受け取った場合、状態マシンはCLINET_L状態１
６４に遷移する。この進展は、以降の状態１６４、１６
５、１６６の各々についても維持され、文字列"CLIENT"
の可能な受け取りを示す。この文字列が完全に受け取ら
れなかった場合、CLIENT_INIT状態１６２に戻る遷移が
行われる。文字列全体を受け取ったときに、状態マシン
はCLIENT_DETECTED状態１６８に遷移し、サーバ・コン
トローラ２６のソフトウエアにおける上位タスクに、有
効な予備ＰＰＰプロトコルが検出されたことを通知す
る。

【０１２２】以下に示すのは、有効なＰＰＰパケットを
形成する文字列のフォーマットである。

【０１２３】SYNCH ADDRESS CONTROL PROTOCOL ... dat
a ... CRC_low CRC_high SYNCH SYNCH文字は１６進数の値０ｘ７Ｅで表され、ADDRESS文
字は１６進数の値０ｘＦＦで表され、CONTROL文字は１
６進数の値０ｘ０３で表わされる。ADDRESSおよびCONTR
OL文字は任意であるが、一方がある場合、両方の文字が
なければならない。PROTOCOL文字（群）は、最初のバイ
トの最下位ビット（ＬＳＢ）に応じて、１バイトまたは
２バイトとなる。最初のバイトの最下位ビットがセット
されている（即ち、１）場合、PROTOCOL文字は、圧縮さ
れた１プロトコル・バイトのみから成る。最初のバイト
のＬＢＳがクリアされている（即ち、０）場合、PROTOC
OL文字は、圧縮されていない２プロトコル・バイトから
成り、第１のバイトが下位バイト、第２のバイトが上位
バイトとなる。「データ」バイトはパケットのペイロー
ドである。ＣＲＣ_lowおよびＣＲＣ_high文字は、それぞ
れ、データ・バイト上の巡回冗長度チェック（ＣＲＣ）
の下位および上位バイトから成る。

【０１２４】図１５を参照すると、ＰＰＰの状態マシン
を表わす状態図が示されている。ＰＰＰの状態マシンが
有効なＰＰＰパケットを検出した場合、遠隔端末２８か
ら有効なＰＰＰプロトコルが検出されたことを示す。PP
P_INIT状態１７０において、状態マシンがSYNCH文字を
受け取ると、状態マシンはPPP_SYNCH状態１７２に遷移
する。その他の場合、状態マシンはPPP_INT状態１７０
に留まる。PPP_SYNCH状態１７２において、状態マシン
がADDRESS文字を受け取ると、PPP_ADDRESS状態１７４に
遷移する。その他の場合、状態マシンはPPP_CONTROL状
態１７６に遷移する。PPP_ADDRESS状態１７４におい
て、状態マシンがCONTROL文字を受け取ると、状態マシ
ンはPPP_CONTROL状態１７６に遷移する。あるいは、状
態マシンがSYNCH文字を受け取ると、状態マシンはPPP_S
YNCH状態１７２に遷移する。その他の場合、状態マシン
はPPP_INT状態１７０に遷移する。PPP_CONTROL状態１７
６において、状態マシンがSYNCH文字を受け取ると、状
態マシンはPPP_SYNCH状態１７２に遷移する。その他の
場合、文字のＬＳＢがクリアされているなら、PPP_NOT_
COMPRESSED状態１７８に遷移し、この文字を非圧縮２プ
ロトコル・バイトの下位バイトとして扱い、この文字の
ＬＳＢがセットされているなら、PPP_COMPRESSED状態１
８０に遷移し、この文字を単一の圧縮プロトコル・バイ
トとして扱う。PPP_NOT_COMPRESSED状態１７８におい
て、状態マシンがSYNC文字を受け取ると、PPP_SYNCH１
７２状態に遷移する。その他の場合、状態マシンはPPP_
COMPRESSED状態１８０に遷移し、非圧縮２プロトコル・
バイトの上位バイトとしてこの文字を扱う。PPP_COMPRE
SSED状態１８０において、状態マシンがSYNCH文字を受
け取ると、状態マシンはPPP_DETECTED状態１８２に遷移
する。その他の場合、状態マシンはPPP_COMPRESSED状態
１８０に留まり、この文字をデータまたはＣＲＣバイト
として扱う。状態マシンがPPP_DETECTED状態１８２に到
達した場合、サーバ・コントローラ２６のソフトウエア
内の上位タスクに、有効なＰＰＰプロトコルが検出され
たことを通知する。

【０１２５】サーバ・コントローラ２６は、任意のダイ
アル・バック・セキュリティ(dial-back security)機能
を備え、無許可のユーザがサーバ・コントローラ２６を
通じてサーバ１０を不正に変更するのを防止する。サー
バ・コントローラ２６のコンソール・アプリケーション
・ソフトウエアを用いて、システム管理者は、各々ユー
ザ名、パスワードおよび電話番号を含むユーザ・プロフ
ァイルのリストを構成する。ユーザが発信してきた場
合、サーバ・コントローラ２６はユーザからユーザ名お
よびパスワードを受信し、ユーザ・プロファイルのリス
トからそのユーザ名およびパスワードを確認し、そして
切断する。ユーザ名およびパスワードがユーザ・プロフ
ァイルのリストにおいて確認された場合、サーバ・コン
トローラ２６は、ユーザ・プロファイルのリスト内にあ
る対応する電話番号を呼び出す。許可されているユーザ
には、遠隔アクセスは通常通りに進む。万一侵入者が有
効なユーザ名およびパスワードを得ても、しかしなが
ら、侵入者には呼び出しがかからないので、侵入者はサ
ーバ１０への接続を失うことになる。

【０１２６】サーバ・コントローラ２６は、ユーザが発
信してきたときに用いられたのと同じ通信プロトコルに
よって、許可されたユーザに呼び出しをかけるという利
点がある。例えば、ユーザが予備ＰＰＰプロトコルを用
い、WINDOWS NT機からヌル・モデムを通じて接続した場
合、サーバ・コントローラ２６は予備ＰＰＰプロトコル
を用いてこのNT機に呼び出しをかける。遠隔端末は、そ
れが発信したのと同じプロトコルを用いてサーバ・コン
トローラ２６と通信することを期待する場合が多いの
で、これは有用である。

【０１２７】次に図１６を参照すると、ＰＣＢ２００上
に配置された、サーバ・コントローラ２６の様々な構成
要素が示されている。ＰＣＢ２００は、複数のプレーン
(plane)即ち部分に分離されている。第１部分２０２は
拡張バス・インターフェース・ユニット２０４および検
出ロジック３０を収容する。第２部分２０６はプロセッ
サ３０およびコントローラ・メモリ３２、ならびに参照
番号２０８で示す二次電源（即ち、電池）を収容する。
第３部分２１０は通信ユニット（即ち、モデム）３６を
収容する。部分２０２、２０６、２１０は、第１の遮断
ユニット２１２および第２の遮断ユニット２１４として
示す１対の遮断ユニットによって、互いに分離されてい
る。

【０１２８】ＰＣＢ２００への電力は、通常、ＰＣＢ２
００を接続可能な拡張バスから、エッジ・コネクタ２１
６を介して供給される。エッジ・コネクタ２１６のピン
の内１本は、第１、第２および第３部分２０２、２０
６、２１０にそれぞれ供給される主要電源ＶＤＤのため
に用いられる。表示データは拡張バスから監視され、エ
ッジ・コネクタ２１６の恐らく数本のピンを通じて、イ
ンターフェース・ユニット２０４を通じて検出ロジック
３０に送出される。例えば、サーバの停電の間にＶＤＤ
が失われると、遮断ユニット２１２は２つの機能を果た
す。まず、第１部分２０２内の電力用導体を、第２部分
２０６の電力用導体から切断する。より具体的には、第
１部分２０２内のＶＤＤ導体は、遮断ユニット２１２に
よって、第２部分２０６内の電力用導体または導体群か
ら切断される。第２に、第１部分２０２内の信号用導体
は、第２部分２０６内の信号用導体から切断される。信
号用導体が切断されると、信号用導体は三状態化する(t
ri-stated)。

【０１２９】第１の遮断ユニット２１２と同様、第２の
遮断ユニット２１４も電力用導体および信号用導体を切
断する。拡張バスからＶＤＤが遮断され、更に通信ユニ
ット３６が遠隔端末２８からの通信を検出できなくなっ
た場合、第２の遮断ユニット２１４はその切断処理を実
行する。しかしながら、ＶＤＤが得られる場合、または
遠隔端末２８が通信プロトコルを送っている場合、第２
の遮断ユニット２１４は、第２および第３部分２０８、
２１０間の結合を行う。

【０１３０】遮断ユニット２１２、２１４は、電力用導
体上にクイック・スイッチを備え、更に信号用導体間に
バッファ／ドライバ機能を有する双方向トランシーバを
備えていることが好ましい。クイック・スイッチは、Na
tional Semiconductor Corp.およびTexas Instruments,
Inc.等の販売会社から入手可能であり、共通の制御入
力（即ち、出力イネーブルOE入力）を有するパッケージ
化されたＪＦＥＴのアレイとして形成されている。双方
向トランシーバは、高容量性負荷を駆動するのに非常に
適しており、高速で動作する。適切な双方向トランシー
バは、integrated Device Technology, Inc.またはTexa
s Instruments, Inc. から、三状態出力機能を有する高
速ＣＭＯＳトランシーバとして入手可能である。

【０１３１】エッジ・コネクタ２１６のピンの１つに
は、充電用導体２２０が結合されている。充電用導体２
２０は、拡張バスから供給されＶＤＤよりも高く設定さ
れた電圧を受けるように構成されている。一実施例によ
れば、充電用導体２２０上の所望の電圧は１２ボルトで
あり、この場合、ＶＤＤは５ボルトである。充電用導体
２２０によって供給される電圧は、電池２０８を充電す
るだけでなく、スイッチング・レギュレータ２２２のス
イッチングをイネーブルするように作用する。例えば、
充電用導体２２０内の電荷がスレショルド値よりも低下
した場合、スイッチング・レギュレータ２２２は、第２
部分２０６および恐らく第３部分２１０に電池２０８を
結合するように機能する。逆に、充電用導体２２０上の
電荷がスレショルド値を超過している場合、電池２０８
からの出力（即ち、ＶＤＤＢ）は第２部分２０６および
第３部分２１０には結合されない。代わりに、後者の場
合、そこにＶＤＤが供給される。ダイオード２２４を用
いて、導体２２０上の電荷を終了させる期間中、電池２
０８の放電を防止する。

【０１３２】呼び出し指示器２２６が、第２部分２０６
と同じ電力プレーンに結合されている。具体的には、呼
び出し指示器２２６は、ＶＤＤがない期間中、導体２２
８上のＶＤＤＢを受け取り、ＶＤＤがある場合ＶＤＤを
受け取る。したがって、呼び出し指示器２２６は、主電
源または二次電源のいずれかから電力を維持し、入来す
るアナログ呼び出しARNG信号を検出する。ARNGの受信時
に、呼び出し指示器２２６は、デジタル呼び出しＤＲＮ
Ｇ信号を通じて、結果的に得られる通信プロトコルを通
信ユニット３６に送出する。常に呼び出し指示器２２６
に電力を維持することによって、入来する呼び出しの検
出は、ＶＤＤの状態には無関係に、常に可能となる。

【０１３３】図１７は、ＶＤＤがＶＤＤＢよりもスレシ
ョルド量だけ少なくなったか否かについて判定を行う際
に使用される比較器２３０を示す。ＶＤＤが偶然許容可
能なスレショルドを越えて低下した場合、比較器２３０
はVDDOFF信号を生成する。VDDOFF信号は、第１遮断ユニ
ット２１２の遮断出力イネーブルOEピン上に現れる。こ
れによって、拡張バスによって供給されるＶＤＤが電池
２０８によって供給されるＶＤＤＢよりも低くなった場
合に、比較器２３０は、信号用導体および電力用導体の
遮断を行う。

【０１３４】図１８は、デジタル呼び出しDRNG信号の動
作、ならびに第２部分２０６および第３部分２１０間の
電力用導体および信号用導体の遮断に対するその効果に
ついて示すものである。通信ユニット３６への電力が最
初にオフになっている場合、通信ユニット３６へのDRNG
信号はプロセッサ３４に割り込みを発生する。こうし
て、プロセッサ３４は、通信ユニット３６に呼び出し信
号があることを通知され、これにより、プロセッサ３４
はMDMACT信号を通じてそれ自体の割り込みを承認し、か
つMDMPWR信号を通じてモデムへの電力供給を承認する。
より具体的には、MDMPWR信号は第２の遮断ユニット２１
４の出力イネーブルOE入力に供給される。入来する呼び
出しを示すMDMPWRを受信すると、第２の遮断ユニット２
１４は、第２部分２０６および第３部分２１０間に延び
る電力用導体および信号用導体を結合する。本質的に
は、DRNGは、通信ユニット３６がオンかオフかを示す信
号によってゲートされ、このゲートの出力が、プロセッ
サ３４への割り込みとなる。プロセッサ３４が割り込み
を受け取ったときはいつでも、プロセッサ３４のＶＤＤ
Ｂからの電力は通信ユニット３６に供給される。通信ユ
ニット３６への電力がオンである場合、割り込みはアサ
ートされない。

【０１３５】本発明は多種多様のコンピュータ・システ
ム、多種多様の電気的構成物、多種多様のＰＣＢおよび
多種多様の通信プロトコルを用いた応用が可能であるこ
とは、本開示から当業者には明らかであろう。更に、こ
こに示しかつ記載した本発明の形態は、現状における好
適な実施例として捕らえるべきことは理解されよう。特
許請求の範囲に記載してある本発明の主旨および範囲か
ら逸脱することなく、様々な修正や変更が可能である。
したがって、特許請求の範囲はかかる修正や変更全てを
含むものとして解釈し、この明細書および図面は限定的
な意味ではなく例示的な意味で捕らえるべきことを意図
するものである。

【図面の簡単な説明】

【図１】本発明による、遠隔端末からアクセス可能なサ
ーバ・コントローラを用いて構成を変更したホスト・サ
ーバのブロック図である。

【図２】遠隔端末からのアクセスに応答して、サーバ・
コントローラが遠隔端末の表示画面に送出する、３種類
の画面表示メニューを示す図である。

【図３】図１に示したビデオ・メモリおよびビデオ制御
レジスタ（ビデオ・コントローラ内）に使用可能なメモ
リ・アドレス空間およびＩ／Ｏアドレス空間の部分を示
す図である。

【図４】サーバ・コントローラの詳細ブロック図であ
る。

【図５】図４に示すプロセッサによって用いられ、サー
バＣＰＵから拡張バスに送られる一連のビデオ画面の処
理および記憶を行うための種々のバッファのブロック図
である。

【図６】所定の連続ビデオ画面を記憶する際に、サーバ
・コントローラによって実行されるステップを示すフロ
ーチャートである。

【図７】所定の連続ビデオ画面を記憶する際に、サーバ
・コントローラによって実行されるステップを示すフロ
ーチャートである。

【図８】遠隔端末上でリセット時のビデオ画面シーケン
スを再生する際に、図４のプロセッサが実行するステッ
プを示すフローチャートである。

【図９】遠隔端末上で障害時のビデオ画面シーケンスを
再生する際に、図４のプロセッサが実行するステップを
示すフローチャートである。

【図１０】代表的な障害時画面シーケンスとして提示す
る表示シーケンスを表わす図である。

【図１１】拡張バスの侵入および非侵入が発生する２つ
の別個のビデオ・ライト・サイクルを示す、種々のＥＩ
ＳＡ拡張バス信号のタイミング図である。

【図１２】遠隔端末によって使用可能な種々の通信プロ
トコルを検出する際に、サーバ・コントローラが実行す
るステップを示すフローチャートである。

【図１３】遠隔端末から送られたテキスト通信プロトコ
ルを検出する際に使用する、テキスト・プロトコルの状
態マシンを示す状態図である。

【図１４】遠隔端末から送られた予備二地点間（ＰＰ
Ｐ）通信プロトコルを検出する際に使用する、予備ＰＰ
Ｐプロトコルの状態マシンを示す状態図である。

【図１５】遠隔端末から送られたＰＰＰ通信プロトコル
を検出する際に使用する、ＰＰＰのプロトコル状態マシ
ンを示す状態図である。

【図１６】拡張バス上で結合するように構成されたＰＣ
Ｂ上で実施されるサーバ・コントローラを示すブロック
図である。

【図１７】図１６の前記ＰＣＢ内に配置されている電力
プレーン間に延在する信号導体を遮断する際に使用する
比較ロジックを示す図である。

【図１８】通信ユニットが遠隔端末から信号を受信して
いる間に、信号導体を結合し、通信ユニットの電力プレ
ーンに給電するために用いられる信号を示す説明図であ
る。

───────────────────────────────────────────────────── フロントページの続き (71)出願人 591030868 20555 ＳｔａｔｅＨｉｇｈｗａｙ 249，Ｈｏｕｓｔｏｎ，Ｔｅｘａｓ 77070，ＵｎｉｔｅｄＳｔａｔｅｓｏｆＡｍｅｒｉｃａ (72)発明者ウエスリー・エム・エリンガーアメリカ合衆国テキサス州77064，ヒューストン，ウエスト・ロード 10939，ナンバー 1904 (72)発明者ゴードン・アール・クラークアメリカ合衆国テキサス州77380，ザ・ウッドランズ，ウエスト・レイシー・オーク・サークル 2106

Claims

【特許請求の範囲】

【請求項１】コンピュータにおいて、ホスト中央処理装置（ＣＰＵ）と、ＣＰＵとビデオ・コントローラとの間に結合された拡張
バスと、拡張バスに接続され、コンピュータの障害前の第１の時
間中及びコンピュータのリセットの後の第２の時間中に
ＣＰＵからビデオ・コントローラに送られた表示データ
を記憶するコントローラ・メモリを有するサーバ・コン
トローラとを備えることを特徴とするコンピュータ。
【請求項２】請求項１記載のコンピュータにおいて、
拡張バスは、ＥＩＳＡバスであることを特徴とするコン
ピュータ。
【請求項３】請求項１記載のコンピュータにおいて、
ビデオ・コントローラは、ビデオ・メモリに結合され、
それによって、ビデオ・コントローラとサーバ・コント
ローラとは共に、ビデオ・アドレス範囲中のアドレス情
報に応答して、ビデオ・メモリとコントローラ・メモリ
との両方に表示データを同時に記憶することを特徴とす
るコンピュータ。
【請求項４】請求項１記載のコンピュータにおいて、
ホストＣＰＵは、ローカルＣＰＵバスに接続されている
ことを特徴とするコンピュータ。
【請求項５】請求項４記載のコンピュータにおいて、
ローカルＣＰＵバスと拡張バスとの間に結合されたバス
・インターフェース・ユニットを更に備えることを特徴
とするコンピュータ。
【請求項６】請求項１記載のコンピュータにおいて、
サーバ・コントローラは、拡張バスと前記コントローラ
・メモリとの間に結合され拡張バスを介してビデオ・コ
ントローラに送られる表示データをモニタし、その後、
表示データをコントローラ・メモリに書き込む検出ロジ
ックを備えることを特徴とするコンピュータ。
【請求項７】請求項６記載のコンピュータにおいて、
表示データは、ＣＰＵが表示データをビデオ・コントロ
ーラに書き込む間に、拡張バスを介して送られることを
特徴とするコンピュータ。
【請求項８】請求項１記載のコンピュータにおいて、
コントローラ・メモリは、ビデオ・コントローラに送られる表示データの現在の表
示スクリーン情報を記憶するローカル・フレーム・バッ
ファと、ローカル・フレーム・バッファから送られる表示データ
の現在の表示スクリーン情報を受け取る一時スナップシ
ョット・バッファと、ローカル・フレーム・バッファから送られる表示データ
の前の表示スクリーン情報を受け取るスナップショット
・バッファと、一時スナップショット・バッファとスナップショット・
バッファとの間に結合され、表示データの前の表示スク
リーン情報と現在の表示スクリーン情報との間の変化を
判断する比較ロジックとを備えることを特徴とするコン
ピュータ。
【請求項９】請求項８記載のコンピュータにおいて、
コントローラ・メモリは、第２の時間中の前記変化を記
憶する現リセット・シーケンス・バッファを更に備える
ことを特徴とするコンピュータ。
【請求項１０】請求項８記載のコンピュータにおい
て、コントローラ・メモリは、現開始バッファに結合さ
れた現シーケンス・バッファを更に備えており、前記変
化は、現シーケンス・バッファに送られ、そこからのオ
ーバーフローは、すべて、第１の時間の間に現開始バッ
ファに送られることを特徴とするコンピュータ。
【請求項１１】サーバ・コントローラにおいて、サーバに結合しサーバから送られる表示データの存在を
判断する検出ロジックと、検出ロジックに結合され、ローカル・フレーム・バッフ
ァと現リセット・シーケンス・バッファとを有するコン
トローラ・メモリとを備えており、ローカル・フレーム
・バッファは、表示データの現在の表示スクリーン情報
を記憶するように構成され、現リセット・シーケンス・
バッファは、表示データの現在の表示スクリーン情報
と、サーバが第１のリセットを受け取る前の時間中の表
示データの前の表示スクリーン情報との間の変化を記憶
するように構成されていることを特徴とするサーバ・コ
ントローラ。
【請求項１２】請求項１１記載のサーバ・コントロー
ラにおいて、表示データの現在の表示スクリーンと前の
表示スクリーンとの間の変化は、デジタル・データのパ
ケットとして表現されることを特徴とするサーバ・コン
トローラ。
【請求項１３】請求項１２記載のサーバ・コントロー
ラにおいて、デジタル・データのパケットは、現在の表
示スクリーン情報又は前の表示スクリーン情報のどちら
かを記憶する際に用いられるバイナリ値の組よりも小さ
なバイナリ値を有することを特徴とするサーバ・コント
ローラ。
【請求項１４】請求項１２記載のサーバ・コントロー
ラにおいて、デジタル・データのパケットは、表示され
る文字を示す１バイトのデータと、表示される文字に与
えられる属性を示す１バイトのデータとを含み、属性
は、色と輝度とを含むグループから選択されることを特
徴とするサーバ・コントローラ。
【請求項１５】請求項１２記載のサーバ・コントロー
ラにおいて、パケットは、サーバが第１のリセットを受
け取る後に生じる一連のビデオ・スクリーン情報の変化
を表す列に配列されていることを特徴とするサーバ・コ
ントローラ。
【請求項１６】請求項１１記載のサーバ・コントロー
ラにおいて、現リセット・シーケンス・バッファは、サ
ーバから離間して配置された端末によってアクセスがな
され、端末上に、サーバが第１のリセットを受け取った
後に生じる一連のビデオ・スクリーンの変化を表示する
ように構成されることを特徴とするサーバ・コントロー
ラ。
【請求項１７】請求項１１記載のサーバ・コントロー
ラにおいて、表示データの現在及び前の表示スクリーン情報の間の変
化を、第１のリセットより前の第２のリセットをサーバ
が受け取る際に記憶する前リセット・シーケンス・バッ
ファを更に備えており、前リセット・シーケンス・バッファは、サーバから離間
して配置された端末によってアクセスがなされ、端末上
に、サーバが第２のリセットを受け取る後に生じる一連
のビデオ・スクリーンの変化を表示するように構成さ
れ、現リセット・シーケンス・バッファは、端末によっ
てアクセスがなされ、端末上に、サーバが第１のリセッ
トを受け取った後に生じる一連のビデオ・スクリーンの
変化を表示するように構成されることを特徴とするサー
バ・コントローラ。
【請求項１８】サーバ・コントローラであって、サーバに結合されサーバから送られる表示データの存在
を判断する検出ロジックと、検出ロジックに結合され、ローカル・フレーム・バッフ
ァと現シーケンス・バッファとを有するコントローラ・
メモリとを備えており、ローカル・フレーム・バッファ
は、表示データの現在の表示スクリーン情報を記憶する
ように構成され、現シーケンス・バッファは、表示デー
タの現在の表示スクリーン情報と、サーバが故障する前
の時間中の表示データの前の表示スクリーン情報との間
の変化を記憶するように構成されていることを特徴とす
るサーバ・コントローラ。
【請求項１９】請求項１８記載のサーバ・コントロー
ラにおいて、表示データの現在及び前の表示スクリーン
情報の間の変化は、デジタル・データのパケットとして
表現されることを特徴とするサーバ・コントローラ。
【請求項２０】請求項１９記載のサーバ・コントロー
ラにおいて、デジタル・データのパケットは、現在又は
先の表示スクリーン情報のどちらかを記憶する際に用い
られるバイナリ値の組よりも小さなバイナリ値を有する
ことを特徴とするサーバ・コントローラ。
【請求項２１】請求項１９記載のサーバ・コントロー
ラにおいて、デジタル・データのパケットは、表示され
る文字を示す１バイトのデータと、該文字の属性を示す
１バイトのデータとを含み、属性は、色と輝度とを含む
グループから選択されることを特徴とするサーバ・コン
トローラ。
【請求項２２】請求項１９記載のサーバ・コントロー
ラにおいて、パケットは、サーバが故障した後に生じる
一連のビデオ・スクリーン情報の変化を表す列に配列さ
れていることを特徴とするサーバ・コントローラ。
【請求項２３】請求項１９記載のサーバ・コントロー
ラにおいて、現シーケンス・バッファは、サーバから離
間して配置された端末によってアクセスがなされ、端末
上に、サーバが故障した後に生じる一連のビデオ・スク
リーンの変化を表示するように構成されることを特徴と
するサーバ・コントローラ。
【請求項２４】サーバからビデオ・コントローラに送
られる一連の表示スクリーン情報にアクセスする方法に
おいて、サーバからビデオ・コントローラに送られる現在の表示
スクリーン情報を、ローカル・フレーム・バッファに記
憶する記憶ステップと、現在の表示スクリーン情報を、ローカル・フレーム・バ
ッファに先に記憶された前の表示スクリーン情報と比較
して、スクリーン変化パケットを作成するステップと、サーバの故障の直前の第１の時間中とサーバのリセット
の直後の第２の時間中との間に生じる複数のスクリーン
変化パケットとしてコンパイルされた一連の表示スクリ
ーン情報に対して、記憶及び比較のステップを反復する
ステップと、サーバから離間して配置された端末によりスクリーン変
化パケットをアクセスして端末に表示スクリーン情報を
表示するアクセス・ステップとからなることを特徴とす
る方法。
【請求項２５】請求項２４記載の方法において、記憶
ステップは、拡張バスを、拡張バスを介してサーバから
送られた特定アドレス範囲中のアドレスに関してスヌー
ピングすることを含むことを特徴とする方法。
【請求項２６】請求項２４記載の方法において、アク
セス・ステップは、端末から、複数のスクリーン変化パ
ケットを記憶するように構成されたバッファに結合され
たモデムに、遠隔ダイアリングするステップを含むこと
を特徴とする方法。