JP3861925B2 - エミュレーション装置およびその方法 - Google Patents

Description

本発明は、エミュレーション装置およびその方法に関し、詳しくは少なくとも演算処理部、記憶部、入出力部を備えたコンピュータである実行マシン上で、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置及びその方法に関する。

従来、この種のエミュレーション装置としては、特開平５−４６４０６号に開示されているように、ターゲットマシンのＯＳファンクションコール、ＢＩＯＳファンクションコールやＩ／Ｏ命令、さらには割り込みテーブルなどを、個々にエミュレーションすることで、ターゲットマシン用に作られたアプリケーションプログラムを実行マシン上で実行可能とする仮想計算機エミュレーション装置が知られている。

こうしたエミュレーション装置では、特定の中央演算処理部（以下、ＣＰＵという）に備えられた機能を用い、エミュレーションを行なうべき命令が実行されたり、エミュレーションを行なうべきアドレスやＩ／Ｏがアクセスされた時、これをトラップして、ターゲットマシン上でいかなる処理を実行しようとしているかを解析し、同様の結果が実行マシン上で得られるよう、予め用意した代替処理を実行するのである。例えば、ターゲットマシンにおいて所定の機能が割り当てられたＩ／Ｏアドレスをアクセスする命令が実行されようとした場合には、これを特権命令の処理としてトラップし、いかなる機能を実現しようとしているかを解析し、同様の処理がなされるよう実行マシンのＩ／Ｏアドレスに対する書込処理を実行するのである。

しかしながら、従来のエミュレーション装置では、あるターゲットマシンを実行マシン上で完全にエミュレートすることは、エミュレーションプログラムが巨大なものとなってしまうことから、実際には実現困難であるという問題があった。したがって、通常のエミュレーション装置では、ＯＳが定義しているファンクションコールと、多用されるＩ／Ｏアクセス等を中心に、ある程度の範囲をエミュレートしているに過ぎない。

また、エミュレーションを容易にするため、ディスクのアクセスや描画命令などの一連の処理からなる機能を単位としてエミュレートするのが一般的であり、この場合には、アプリケーションソフトウェアが、各機能を構成する個々の処理を直接実行しようとすると、正常にエミュレートすることができないという問題があった。

ターゲットマシンにせよ実行マシンにせよ、それらのアーキテクチャは、それらのマシンの開発の歴史や開発時の制約などを背負っており、単純明快な構成に終始することは期待し難い。細部に立ち入ると、様々な例外や付加機能等を有しており、単純なエミュレーションでは、到底対応できないのである。このため、マシンを構成するあらゆる処理、機能について完全なエミュレーションを実現しようとすると、エミュレーション装置の構成も複雑なものとなり、エミュレーション用のプログラムも複雑化し巨大化するという問題があった。特にこうした問題は、ハードディスクなどの外部記憶装置をアクセスする場合に、既存のファイルシステムとの関係、あるいは周辺機器制御するデバイスドライバの実現方法を巡って顕在化する。

本発明のエミュレーション装置およびその方法は、こうした問題を解決し、あるターゲットマシンのアーキテクチャの大部分を、他の実行マシン上でエミュレートすることを目的としてなされ、次の構成を採った。

本発明の第１のエミュレーション装置は、
少なくとも演算処理部、記憶部、入出力部およびハードディスクを備えたコンピュータである実行マシン上で、所定バイト数のデータを単位とし、該単位のデータを前記ハードディスクにおいて、トラック、セクタを用いて管理するディスクシステムを用い、該ハードディスクから、前記実行マシンとは、データの入出力用の手続を定義したＢＩＯＳおよびディスクシステムを用いてデータの処理を行なう点で共通するオペレーティングシステムをロードして、前記実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
前記実行マシンの起動時に、少なくとも二つのタスクが実行できる論理空間を前記実行マシンに確保するタスク管理手段と、
該確保された論理空間に、前記実行マシン用に用意されたＢＩＯＳをロードし、実行可能な状態に展開する実行マシンＢＩＯＳ展開手段と、
前記実行マシン用のＢＩＯＳが実行可能に展開された前記一つの論理空間に、該展開された実行マシン用のＢＩＯＳを呼び出す所定のファンクションコールを実現するプログラムを実行可能に読み込む実行マシン処理プログラム読込手段と、
前記確保された他の論理空間に、前記ターゲットマシン用に用意されたＢＩＯＳをロードし、所定のファンクションコールを利用して実行可能な状態に展開するターゲットマシンＢＩＯＳ展開手段と、
前記ターゲットマシン用のＢＩＯＳが実行可能に展開された前記他の論理空間に、該展開されたターゲットマシン用のＢＩＯＳを呼び出す該ターゲットマシンの前記ファンクションコールに対応したアプリケーションプログラムを読み込むターゲットマシンプログラム読込手段と
該展開されたターゲットマシン用のＢＩＯＳが前記アプリケーションプログラムから前記システムコールを用いて呼び出されたとき、この呼出を取得して、該呼び出されたＢＩＯＳと等価な機能を有する前記実行マシン用のＢＩＯＳを呼び出す呼出手段と
を備えたことを要旨としている。

このエミュレーション装置に対応した第２のエミュレーション方法の発明は、
少なくとも演算処理部、記憶部、入出力部およびハードディスクを備えたコンピュータである実行マシン上で、所定バイト数のデータを単位とし、該単位のデータを前記ハードディスクにおいて、トラック、セクタを用いて管理するディスクシステムを用い、該ハードディスクから、前記実行マシンとは、データの入出力用の手続を定義したＢＩＯＳおよびディスクシステムを用いてデータの処理を行なう点で共通するオペレーティングシステムをロードして、前記実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
前記実行マシンの起動時に、少なくとも二つのタスクが実行できる論理空間を前記実行マシンに確保し、
該確保された一つの論理空間に、前記実行マシン用に用意されたＢＩＯＳをロードし、実行可能な状態に展開し、
前記実行マシン用のＢＩＯＳが実行可能に展開された前記一つの論理空間に、該展開された実行マシン用のＢＩＯＳを呼び出す所定のファンクションコールを実現するプログラムを実行可能に読み込み、
前記確保された他の論理空間に、前記ターゲットマシン用に用意されたＢＩＯＳをロードし、所定のファンクションコールを利用して実行可能な状態に展開し、
前記ターゲットマシン用のＢＩＯＳが実行可能に展開された前記他の論理空間に、該展開されたターゲットマシン用のＢＩＯＳを呼び出す該ターゲットマシンの前記ファンクションコールに対応したアプリケーションプログラムを読み込み、
該展開されたターゲットマシン用のＢＩＯＳが前記アプリケーションプログラムから前記システムコールを用いて呼び出されたとき、この呼出を取得して、該呼び出されたＢＩＯＳと等価な機能を有する前記実行マシン用のＢＩＯＳを呼び出すこと
を要旨としている。

このエミュレーション装置またはその方法によれば、実行マシンの起動時に、実行マシンには少なくとも二つのタスクが実行できる論理空間が確保され、このタスクの一つに実行マシン用に用意されたＢＩＯＳが実行可能に展開され、他のタスクにターゲットマシン用に用意されたＢＩＯＳが実行可能に展開される。ターゲットマシン用のＢＩＯＳがアプリケーションプログラム（オペレーティングシステムも含む）から呼ばれたとき、この呼出を取得して、呼び出されたＢＩＯＳと等価な機能を有する実行マシン用のＢＩＯＳが呼び出される。したがって、ターゲットマシン用のＢＩＯＳの呼出を等価な機能を有する実行マシン用のＢＩＯＳで代替でき、エミュレーションを簡略に構成できるという利点がある。

ここで、実行マシンに接続されたハードディスクの記憶領域に、所定の大きさの領域を確保し、該領域を該ターゲットマシンの仮想的なハードディスクとして扱う仮想ディスク確保手段と、
前記実行マシン用のＢＩＯＳが実行可能に展開された前記一つのタスクに、該展開された実行マシン用のＢＩＯＳを利用して該実行マシンに所定のファンクションコールを実現するプログラムを実行可能に読み込む実行マシン処理プログラム読込手段と、
前記ターゲットマシン用のＢＩＯＳが実行可能に展開された前記他のタスクに、該展開されたターゲットマシン用のＢＩＯＳを利用する該ターゲットマシンのファンクションコールに対応したプログラムを読み込むターゲットマシンプログラム読込手段と
を設けることも可能である。この場合には、第５発明において、ＢＩＯＳを展開したのに対して、ＢＩＯＳを利用して実行マシンに所定の所定のファンクションコールを実現することができる。したがって、両マシンに対応するファンクションコールが存在する場合には、これを呼び出す構成とすれば良く、エミュレーションの精度を向上し、かつエミュレーション装置を容易に構成することができる。

ここで、ターゲットマシンプログラム読込手段によりファンクションコールに対応したプログラムの読み込みの後に、該ターゲットマシン用のオペレーティングシステムを構築するためのファイルを読み出すオペレーティングシステム読出手段と、該読み出したファイルを用いて、前記実行マシンに、前記ターゲットマシン用のオペレーティングシステムを構築するシステム構築手段とを備えた構成を採ることも可能である。この場合には、ターゲットマシンのオペレーティングシステムを実行マシンに容易に構築することができる。

次に、本発明の第２のエミュレーション装置について説明する。第２のエミュレーション装置は、
少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込む第１の組込手段と、
該第１の組込手段による前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込むオペレーティングシステム組込手段と、
該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込む第２の組込手段と、
前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させる起動手段と
を備えたことを要旨とする。

また、このエミュレーション装置に対応した発明である第２のエミュレーション方法は、
少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するにデバイスドライバを組み込んで動作する周辺装置を備えた実行マシン上で、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込み、
該デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込み、
該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込み、
前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させること
を要旨としている。

このエミュレーション装置またはその方法は、実行マシンのオペレーティングシステムにデバイスを組み込んで使用される周辺装置のエミュレーションに関するものであり、実行マシン用のデバイスドライバとターゲットマシン用のデバイスドライバが存在する場合に、ターゲットマシンに用意されたオペレーティングシステムに組み込まれるデバイスドライバの少なくとも呼出側を組み込み、ターゲットマシン上でこの周辺装置が呼び出されると、この呼出を取得して、実行マシンに組み込まれたデバイスドライバを起動する。この構成によれば、両マシンのデバイスドライバの少なくとも一部をそのまま利用して、周辺装置のエミュレーションを容易に行なうことができる。なお、周辺装置としては、光磁気ディスク，フレキシブルディスク，ハードディスク，ＣＤ−ＲＯＭ等の記憶装置のみならず、モータやソレノイドなどのアクチュエータを駆動する装置、ＭＩＤＩ装置、スキャナ、プリンタなど、デバイスドライバを用いる総ての周辺装置に適用可能である。

次に、本発明の第３のエミュレーション装置について説明する。本発明の第３のエミュレーション装置は、
少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込む第１の組込手段と、
該実行マシン用のデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りする際に用いる第１のバッファと、
該第１の組込手段による前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込むオペレーティングシステム組込手段と、
該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込む第２の組込手段と、
該ターゲットマシンのデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りするのに用いる第２のバッファと、
前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させると共に、前記第１のバッファと前記第２のバッファとの間で、前記周辺装置との間でやり取りするデータの転送を行なわせる転送手段と
を備えることを要旨とする。

また、このエミュレーション装置に対応した第３のエミュレーション方法は、
少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込み、
該実行マシン用のデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りする際に用いる第１のバッファを用意し、
前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込み、
該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込み、
該ターゲットマシンのデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りするのに用いる第２のバッファを用意し、
前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させると共に、第１のバッファと前記第２のバッファとの間で、前記周辺装置との間でやり取りするデータの転送を行なわせること
を要旨としている。

このエミュレーション装置またはその方法によれば、周辺機器のアクセスに必要な実行マシン用のデバイスドライバを実行可能に組み込むと共に、そのデバイスドライバによるアクセスに必要な第１のバッファを用意し、その後、ターゲットマシン用のオペレーティングシステムを組み込む。このオペレーティングシステムには、周辺機器用のターゲットマシンのデバイスドライバの少なくとも呼出側を組み込み、これと共に、ターゲットマシンのデバイスドライバを用いた前記周辺機器のアクセスに必要な第２のバッファを用意する。この状態で、ターゲットマシンがデバイスドライバを用いた前記周辺機器のアクセスを行なおうとすると、第２のデバイスドライバの呼出側が呼び出される。この呼出を取得し、実行マシンのデバイスドライバを起動して、周辺装置へのアクセスを実行させると共に、第１のバッファと第２のバッファとの間でデータの転送が行なわれる。この結果、周辺装置に対するアクセスがエミュレートされ、ターゲットマシンから実行マシン用の周辺装置をアクセスすることが可能となる。

なお、第３のエミュレーション装置またその方法において、転送手段を、第１のバッファのデータ量と第２のバッファのデータ量との差異に基づいて、所定回数の転送を行なう手段とすることができる。この場合には、両デバイスドライバが管理しているバッファの大きさが異なっていても、データの転送を容易を行なうことができる。

以上説明した本発明の構成・作用を一層明らかにするために、以下本発明の好適な実施例について説明する。図１は、本実施例のエミュレーション装置の構成を概念的に示すブロック図である。このエミュレーション装置は、実際には、ＰＣ−ＡＴ機と互換性を有するＤＯＳ／Ｖ機（ＰＣ−ＡＴおよびＤＯＳ／Ｖは、ＩＢＭ社の商標）を実行マシンとし、その上で、ターゲットマシンであるＰＣ−９８００シリーズ（ＰＣ−９８００は日本電気株式会社の商標）のアーキテクチャを実現するものである。図２は、ＤＯＳ／Ｖ機の概略構成を示すブロック図、図３は、そのメモリおよびＩ／Ｏマップを示す説明図である。

説明の便宜上、まず図２に従い、実行マシンであるＤＯＳ／Ｖ機の構成について説明する。このＤＯＳ／Ｖ機は、図示するように、ローカルバス２２に接続された演算処理部２０、ローカルバス２２を外部バスの一つであるＰＣＩバス３２に接続するＰＣＩブリッジ３０、ＰＣＩバス３２を介して演算処理部２０のＣＰＵ２１等によりアクセスを受けるコントローラ部４０、各種のＩ／Ｏ装置等を制御する機器が低速の外部バスであるＩＳＡバス４２に接続されたＩ／Ｏ部６０、および周辺機器であるキーボード７２，スピーカ７４，ＣＲＴ７６などから構成されている。

演算処理部２０は、中央演算処理装置としてのＣＰＵ２１（本実施例ではインテル社製Ｐｅｎｔｉｕｍ（登録商標）を使用）、キャッシュメモリ２３，そのキャッシュコントローラ２４およびメインメモリ２５から構成されている。ＰＣＩブリッジ３０は、高速のＰＣＩバス３２を制御する機能を備えたコントローラである。ＣＰＵ２１が扱うメモリ空間は、ＣＰＵ２１の内部に用意された各種レジスタ（セグメントレジスタなどのメモリマネージメント用レジスタ）により、実際の物理アドレス空間より広い論理アドレス空間に拡張されている。

コントローラ部４０は、モニタ（ＣＲＴ）７６への画像の表示を司るグラフィックスコントローラ（以下、ＶＧＡと呼ぶ）４４、接続されるＳＣＳＩ機器とのデータ転送を司るＳＣＳＩコントローラ４６、ＰＣＩバス３２と下位のＩＳＡバスとのインタフェースを司るＰＣＩ−ＩＳＡブリッジ４８から構成されている。ＶＧＡ４４は、ＣＲＴ７６に対して、６４０×４８０ドット、１６色表示が可能である。なお、表示用のフォントを記憶したキャラクタジェネレータや所定のコマンドを受け取って所定の図形を描画するグラフィックコントローラ、さらには描画画像を記憶するビデオメモリ等は、このＶＧＡ４４に実装されているが、これらの構成は周知のものなので、図２では省略した。

ＰＣＩ−ＩＳＡブリッジ４８を介して接続されたＩＳＡバス４２は、各種のＩ／Ｏ機器が接続される入出力制御用のバスであり、ＤＭＡコントローラ（以下単にＤＭＡと呼ぶ）５０、リアルタイムクロック（ＲＴＣ）５２、複合Ｉ／Ｏポート５４、サウンドＩ／Ｏ５６、キーボード７２およびマウス７３のインタフェースを司るキーボードインタフェース（以下ＫＥＹと呼ぶ）６４、優先順位を有する割り込み制御を行なう割り込みコントローラ（以下ＰＩＣと呼ぶ）６６、各種の時間カウントやビープ音を発生するタイマ６８等から構成されている。なお、ＩＳＡバス４２には、拡張ボードが実装可能なＩＳＡスロット６２が接続されている。

複合Ｉ／Ｏポート５４には、パラレル出力，シリアル出力の他、フロッピディスク装置８２やハードディスク８４を制御する信号を入出力するポートが用意されている。また、パラレル入出力には、パラレルポート８６を介してプリンタ８８が、シリアル入出力には、シリアルポート９０を介してモデム９２が、各々接続されている。また、サウンドＩ／Ｏ５６には、上述したスピーカ７４の他、マイクロフォン９６が接続可能とされている。これらの構成の他、ＤＯＳ／Ｖ機では、標準化されたＩ／Ｏチャンネルが用意されることも多いが、本実施例では図示および説明は省略する。

かかる構成を有するＤＯＳ／Ｖ機において、ＰＣ−９８００機のアーキテクチャを実現する手法について、以下説明する。まず最初に、本実施例の実行マシンであるＤＯＳ／Ｖ機のＣＰＵ２１が有するメモリ管理機能と、実行モードについて説明する。図３は、タスクが管理するアドレス空間と物理アドレスとの関係を示す説明図である。また、図４は、リアルモード、保護（プロテクト）モード、仮想８０８６モード（以下、仮想８６モードと略す）間の関係を示す説明図である。ｉ８０３８６（インテル社製）以上のＣＰＵでは、タスクが管理するアドレスを物理アドレスに自由に割り当て、タスク内では物理アドレスではなく論理アドレスで処理を行なうことができる機能が備えられている。従って、複数のタスクを異なる物理アドレスの範囲に割り付けておけば、それぞれのタスク内で同一のアドレスをアクセスしても、実際のアクセスは、異なる物理アドレスに対して行なわれるから、他のタスクには、何の影響も与えないのである。

また、このＣＰＵ２１は、リアルモード，保護モード，仮想８６モードの３つの動作モードを有する。リアルモードとは、このＣＰＵ２１を高速の８０８６として動作させるモードあり、ＭＳ−ＤＯＳ（マイクロソフト社の商標）等を立ち上げる場合には、通常このリアルモードで処理を開始する。また、保護モードは、特権レベルを設定したリング保護の機能を用いた動作モードであり、セグメント単位で、あるいは所定の命令毎に特権レベルを設定することにより、特定の処理によるハードウェアに対する直接アクセスからの保護を実現する。例えば、アプリケーションプログラムの特権レベルを最下位にしておくことで、システムとして規定されたアドレス範囲やＩ／Ｏを直接アクセスできないものとすることができる。直接のアクセスが生じた場合には、いわゆるトラップが生じて例外処理が起動され、処理を特定のタスク（カーネルと呼ばれる）に移行するものとすることができる。更に仮想８６モードは、保護モードのままで８０８６のコードを直接実行可能とするモードであり、ＣＰＵ２１は、保護モードと同様に動作するが、アプリケーションプログラムにより指定されている論理番地を８０８６と同様に解釈して実行する。このモードを利用すれば、例えば複数のＭＳ−ＤＯＳを起動することも可能である。

本実施例のＤＯＳ／Ｖ機に電源が投入されると、このＤＯＳ／Ｖ機は、ハードディスクのブートブロックを読み出し、ハードディスク上のＯＳ等を読み込み可能とする。また、ＲＯＭで提供されているＤＯＳ／Ｖ機のとしてのＢＩＯＳを主記憶上でアクセス可能な状態とする（後述する図７符号Ａ１）。ＤＯＳ／Ｖ機のメモリマップおよびＩ／Ｏマップを図５に示す。その後、本実施例における初期化手段である初期化処理ルーチンが実行される。この処理ルーチンを図６に示す。また、図６の初期化処理ルーチンの実行の様子を図７の説明図に示す。以下、図６のフローチャートと図７の説明図を参照しつつ、エミュレーション装置が初期化される様子を説明する。

図６に示した初期化処理ルーチンが起動されると、まず、エミュレーションプログラムのカーネルをハードディスク８４からロードする処理を行なう（ステップＳ１００、図７符号Ａ２）。カーネルとは、エミュレーションを行なう処理の内、例外処理が起動された際、その原因の解析を行ない、ディスパッチャと呼ばれる処理を介して実際にエミュレーションを行なう実行モジュールを呼び出す一連の手続を言う。また、ディスパッチャとは、エミュレーションを行なう処理のうち、カーネルによる分析に基づいて実際にエミュレーションを行なう実行モジュールを呼び出す一連の手続をいう。このカーネルのロードに引き続き、カーネルをその実行位置に転送し（ステップＳ１１０、図７符号Ａ３）、カーネルに処理を移行する（ステップＳ１２０）。従って、図６では一連の処理として示しているが、ステップＳ１３０以下は、カーネル自身の処理となる。

カーネルは、プロテクトモード用のいくつかのプログラムを転送し、ＣＰＵ２１の動作モードをプロテクトモードに切り換えて、ＤＯＳ／Ｖ用のメモリ空間およびＰＣ−９８００用のメモリ空間を、それぞれ上位のアドレスに確保する処理を行なう（ステップＳ１３０、図７符号Ａ４）。このメモリ空間は、仮想的なＤＯＳ／Ｖ用のタスクおよびＰＣ−９８００用のタスクに対応しており、このメモリ空間を論理的には、００００００Ｈから始まる１Ｍの主記憶として割り当てるのである。次に、カーネルと共に動作するディスパッチャ（図７符号Ａ５）、更にエミュレーションを行なう各種の実行モジュールを順次転送する処理を行なう（ステップＳ１４０、図７符号Ａ６）。この結果、先に展開された仮想ＤＯＳ／ＶのＢＩＯＳ関係のルーチンを除き、ＤＯＳ／Ｖ機のためのプログラムは、主記憶上から抹消され、代わりにエミュレーションのための実行モジュールが配置される。

ステップＳ１４０で、メモリ上に順次ロードされる実行モジュールは、所定の名称のファイルにテキストデータの形で書かれたリストに従って、ハードディスク８４から読み出される。以下、実行モジュールの配置に伴う初期化の処理について説明するが、先に実行モジュールがすべてロードされた後の全体構成について、図１を用いて説明する。カーネルＫＲ，ディスパッチャＤＰおよび各実行モジュールがロードされ初期化されると、図１に示すように、実施例のエミュレータ装置が、このＤＯＳ／Ｖ機の上に実現されることになる。このエミュレーション装置は、カーネルＫＲ、ディスパッチャＤＰ、および各種実行モジュールから構成されている。カーネルは、ＤＯＳ／Ｖ機の上に仮想的に用意されたＰＣ−９８００機と同一の環境上（仮想ＰＣ上という）で実行されるプログラムＡＰＰが特権命令などを実行した場合、例外の発生とみなして呼び出される。ディスパッチャＤＰは、カーネルＫＲにより特定された例外原因に基づいて呼び出され、この例外原因に基づいて、機能毎に用意された各実行モジュールを呼び出す。各種実行モジュールは、ディスパッチャＤＰから呼び出されて予め定められた機能のエミュレーションを行なう。

実際にエミュレートを行なう実行モジュールは、ＰＣ−９８００機のハードウェアをその機能に基づいて大まかに分割し、機能毎に用意されている。図１には、主要なモジュールのみ示した。メモリエミュレータＭＥＭは、主記憶やＥＭＳの状態をエミュレートするモジュールである。マウスエミュレータＭＵＭは、ＤＯＳ／Ｖ機のマウス７３の動きをＰＣ−９８００機のマウスとしてエミュレートするモジュールである。グラフィックエミュレータＧＥＭは、ＰＣ−９８００機のグラフィック画面をエミュレートするモジュールである。一方、テキストエミュレータＴＥＭは、文字コードにより指定された文字の画像の取得をエミュレートする文字フォントエミュレータＣＦＭと一体となって動作するモジュールであり、ＰＣ−９８００機のテキスト画面をエミュレートするものである。テキストエミュレータＴＥＭおよびグラフィックエミュレータＧＥＭによりエミュレートされ、仮想的なＰＣ−９８００機の画像が作られた後は、表示エミュレータＤＥＭにより実際のＣＲＴ７６への画像の表示がエミュレートされる。

タイマエミュレータＴＩＭは、ＤＯＳ／Ｖ機に内蔵されたタイマ６８によりＰＣ−９８００機上のタイマ関係の処理をエミュレートするモジュールである。また、キーボードエミュレータＫＥＭは、ＤＯＳ／Ｖ機のキーボード７２およびＫＥＹ６４により、ＰＣ−９８００機のキーボードからのキー入力をエミュレートするモジュールである。

更に、割り込みコントローラエミュレータＩＲＭは、ＤＯＳ／Ｖ機の割り込み機能を用いて、ＰＣ−９８００機の割り込みをエミュレートするモジュールである。この割り込みコントローラエミュレータＩＲＭは、割り込みという行為を介して多くのモジュールから呼び出される関係にある。ＤＯＳ／Ｖ機における割り込み処理の回路を図８に示す。ＰＣ−９８００機でも同様であるが、割り込み要求は、多数のデバイスからＰＩＣ６６に出されるので、これをエミュレートする実行モジュールにおいても、モジュール間で何らかのやりとりが必要となる。なお、図８では図示の都合上、インタフェース回路の一部を省略したが、専用のインタフェース回路を介して割り込み要求が出されることは当然である。例えばマウス７３からの割り込み要求は、直接出力されている訳ではなく、インタフェース回路であるＫＥＹ６４を介して出力されている。

ＤＯＳ／Ｖ機における現実のハードウェア割り込みは、特権命令の実行や書込保護が指定された範囲の書込等と共に、カーネルＫＲに処理を移す例外処理の一つとして扱われている。また、ハードウェア割り込みに起因して、あるいは各モジュール内部の処理に起因して割り込みコントローラエミュレータＩＲＭがＰＣ−９８００機の動作をエミュレートするために起こす割り込みは、仮想割り込みの発生としてカーネルＫＲを呼び出す要因とされている。割り込みコントローラエミュレータＩＲＭの呼び出しの詳細については、後述する。

これらの各種実行モジュールは、初期化の処理において、カーネルＫＲにより、ハードディスク８４から読み出され、メモリ上に配置される。各実行モジュールは、初期化の処理においてメモリ上に配置される度に、実行モジュールに予め用意した組み込み処理を一度実行する。このとき実行モジュールが行なう処理の一例を図９ないし図１１のフローチャートに示した。また、図９の処理が行なわれる様子を図１２の説明図に示した。以下、これの図面を用いて、実行モジュールの組み込み時の処理について説明する。

実行モジュール（例えば図１２実行モジュールＤＭ１）の組み込み処理に移行すると、まず、ディスパッチャＤＰが所定のメモリエリアに用意したディスパッチャテーブルＤＴを検索し（ステップＳ２００）、その空き領域にモジュール名（英数字８文字）ＴＭ１とその呼出アドレスＡ１を登録する処理を行なう（ステップＳ２１０）。なお、これらの検索および登録の処理は、実際には、図１２に示したように、カーネルＫＲおよびディスパッチャＤＰの機能を利用して行なわれる。即ち、カーネルＫＲが各実行モジュールＤＭからのサービスを受け付けるアドレスＡＡは、固定アドレスとして用意されており、各実行モジュールＤＭは、このアドレスＡＡを呼んで、モジュール名（文字列）ＴＭとその呼出アドレスＡの登録を依頼する（図１２、符号Ｂ１）。すると、カーネルＫＲは、ディスパッチャＤＰの呼出アドレスを、予めディスパッチャＤＰ自身が登録したテーブルを参照して取得し、このアドレスＡＤを利用して、ディスパッチャＤＰに登録のサービスを要求する。この要求を受けて、ディスパッチャＤＰがディスパッチャテーブルＤＴに、そのモジュールの名称（文字列）ＴＭと呼出アドレスＡとを登録するのである（図１２、符号Ｂ２）。

カーネルＫＲの固定アドレスＡＡを介してディスパッチャＤＰに各種のサービスを要求する上記手法は、実行モジュールの一つが他のモジュールを呼び出す場合や後述する直接呼出のエントリポイントＥＰを通信相手のモジュールとの間で登録し合う場合などにも用いられる。例えば、一つの実行モジュールが他の実行モジュールを呼び出す場合には、実行モジュールの呼び出しというサービスを、カーネルＫＲの固定アドレスＡＡを介してディスパッチャＤＰに依頼する。ディスパッチャＤＰは、ディスパッチャテーブルＤＴを参照して呼び出そうとするモジュールの呼び出しアドレスを容易に取得し、そのモジュールを呼び出すことができるのである（図１２、符号Ｂ３）。従って、カーネルＫＲ，ディスパッチャテーブルＤＴおよび各種実行モジュールを通じて予め固定的に管理する必要があるのは、カーネルＫＲの固定アドレスＡＡのみであり、管理が極めて容易となるという利点がある。

次に、組込の処理を行なっている実行モジュールＤＭ１にモジュール間通信を行なうとの登録がなされているか否かを判断する（ステップＳ２２０）。実行モジュールは、登録ファイルの内容に従って順次組み込まれるが、例えば第ｎ番目の実行モジュールＤＭｎが同様に起動され、自己のモジュール名ＴＭｎの登録と呼出アドレスＡｎの登録を済ませた後（図１２符号Ｂ２）、モジュール間通信が有るとの判断がなされると（ステップＳ２２０）、実行モジュールＤＭｎ内に用意されている直接呼出用のエントリポイントＥＰをパラメータとして用意する処理を行なう（ステップＳ２３０）。このエントリポイントＥＰは、モジュール間通信の対象となる実行モジュールに教える直接呼出用のアドレスであり、教えるエントリポイントがなければ０個のエントリポイントＥＰを用意し、複数個あればその数のエントリポイントＥＰを用意するのである。エミュレーションの高速性を確保しようとすると、緊密な関係を有するモジュール間では、呼出アドレスＡｎを利用したモジュール全体の呼出に代えて、そのモジュールが実現する機能の一部をなす処理そのものを直接呼び出したい場合が存在する。こうした場合には、各実行モジュールが対象となるモジュールにエントリポイントＥＰを教えておく必要がある。

エントリポイントＥＰを用意した後、次に割り込みの登録が有るか否かを判断し（ステップＳ２４０）、割り込みの登録がある場合には、登録する割り込み番号を用意する処理を行なう（ステップＳ２５０）。組み込み中の実行モジュールが割り込みを利用するものである場合には、その割り込みの番号を割り込みをエミュレートするモジュールである割り込みコントローラエミュレータＩＲＭに予め登録しておく必要があるため、その番号を用意するのである。以上の処理の後、通信対象となる実行モジュールの呼び出しを、カーネルＫＲを介してディスパッチャＤＰに依頼する（ステップＳ２６０、図１３符号Ｃ１）。この時、実行モジュールは、呼出先のモジュールをその名称（文字列）で指定し、用意した直接呼出用のエントリポイントＥＰや割り込みの登録番号等をディスパッチャＤＰにパラメータとして引き渡す。

この依頼を受けたディスパッチャＤＰは、図１０に示すディスパッチャ呼出ルーチンを実行する。ディスパッチャＤＰは、呼び出すべきモジュールの名称（文字列）を受け取っているから、ディスパッチャテーブルＤＴをこの文字列で検索し（ステップＳ３００、図１３符号Ｃ２）、呼出アドレスを取得してそのモジュールを呼び出す処理を行なう（ステップＳ３１０、図１３符号Ｃ３）。この時、ディスパッチャＤＰは、呼出元のモジュールから受け取ったパラメータを呼び出したモジュールに引き渡す。

こうしてディスパッチャＤＰから呼ばれることにより、通信対象となるべき実行モジュールが呼び出され、その実行モジュールは、図１１に示したエントリポイントを取得する処理を実行する。この処理が開始されると、まず呼び出したモジュールが何であるかの判別を行なう（ステップＳ３２０）。呼び出した実行モジュールがパラメータとして直接呼出のためのエントリポイントＥＰを用意している場合には、これを判別し（ステップＳ３３０）、直接呼出用のエントリポイントＥＰを登録する処理を行なう（ステップＳ３４０）。

次に、図１１の処理を実行するモジュールが割り込みコントローラエミュレータＩＲＭの場合には、割込の登録があるかを判別する（ステップＳ３５０）。割込番号の登録がある場合には、パラメータの一部として受け取った割込番号を登録すると共に、割込による直接呼び出しを行なう場合のエントリポイントＥＰを割り込む側のモジュールに教えるために準備する処理を行なう（ステップＳ３６０）。なお、割込番号の登録の処理を行なうモジュールは、割り込みコントローラエミュレータＩＲＭに限られるから、それ以外のモジュールで図１１の処理がなされる場合には、ステップＳ３５０，Ｓ３６０の処理は行なわれない。

割込の登録に関する処理に続いて、呼び出した側のモジュールが、割込の呼出のためのエントリポイントＥＰ以外に直接呼出の教示を行なうべきエントリポイントＥＰが存在するモジュールであるか否かの判別を行なう（ステップＳ３７０）。直接呼出のエントリポイントＥＰを呼び出した側のモジュールに教える必要があると判断された場合には、教示する直接呼出のエントリポイントＥＰを、返し値のパラメータとして用意する処理を行なう（ステップＳ３８０）。以上の処理の後、「ＲＴＮ」に抜けて本ルーチンを終了する。この結果、処理は、いったんディスパッチャＤＰを介して（図１３符号Ｃ４）、呼び出した側の実行モジュールに戻る（図１３符号Ｃ５）。この際、呼び出された側の実行モジュールが返し値として用意したパラメータが存在すれば、このパラメータは、呼び出した側の実行モジュールに渡され、呼び出した側の実行モジュールは、これをエントリポイントＥＰとして登録する。

以上の処理を組み込みを行なう最終の実行モジュールまで繰り返すことにより、初期化の処理は完了する。その後、仮想８６モードに実行モードを切り換え、ＰＣ−９８００機としてそのＯＳであるＭＳ−ＤＯＳをブートする処理を開始する。具体的には、ＭＳＤＯＳ．ＳＹＳ、ＩＯ．ＳＹＳ等のシステムファイルを読み込む処理や、ＣＯＭＭＡＮＤ．ＣＯＭを組み込む処理、更にはＣＯＮＦＩＧ．ＳＹＳに登録されているデバイスドライバを組み込む処理などを行なう。これらの処理は、通常のＭＳ−ＤＯＳの組み込み処理と同一であり、ＣＰＵは仮想８６モードに切り換えられているので、ＰＣ−９８００機がＭＳ−ＤＯＳを組み込む処理と何等相違しない。なお、ＤＯＳ／Ｖ機がそのオリジナルな状態でＭＳ−ＤＯＳを立ち上げるときも、ＭＳＤＯＳ．ＳＹＳ等同一名称のファイルを読み込むが、これらのファイルは、ＰＣ−９８００機とＤＯＳ／Ｖ機とでは、その内容が当然異なる。これらのファイルは一般にルートディレクトリに置くことが決められているが、同一名称のファイルを同じディレクトリに置くことはできない。従って、エミュレーションを開始する以前に、即ちＤＯＳ／Ｖ機として普通に使用しているときに、専用のアプリケーションプログラムを実行させ、ＰＣ−９８００機用のＭＳＤＯＳ．ＳＹＳ等のファイルの名称を、所定の名称（例えばＭＳＤＯＳ．９ＹＳ等）に変更しておくのである。なお、エミュレーションを取り止めてＤＯＳ／Ｖ機として普通に使用する場合には、エミュレーションにより動作しているプログラムにより、ルートディレクトリに置かれたこれらのファイルの名称を元に戻し、ＰＣ−９８００機用のシステムファイルの名称を変更しておく。

実行モジュールは、その組み込み時に少なくとも自己のモジュール名（文字列）ＴＭと呼出アドレスＡをディスパッチャテーブルＤＴに登録することが必要であるが、メモリを使用する実行モジュールの場合には、更に必要な実メモリをＰＣ−９８００機用に確保した仮想メモリ（９８用メモリ空間）に割り当てる処理を行なう。

以上の処理により、実行マシン（実施例ではＤＯＳ／Ｖ機）上でターゲットマシン（実施例ではＰＣ−９８００機）をエミュレートする環境が整えられた。そこで、次に図１を参照しつつ、実際にエミュレーションが行なわれる様子を大まかに説明し、更に実行モジュールがどのように処理を行なうかについて、例を挙げて詳述する。

初期化の処理が終了してＰＣ−９８００用の各種システムファイルが読み込まれ、ＭＳ−ＤＯＳが起動されると、ＣＲＴ７６には、「Ａ：」などのプロンプトが表示された状態となる。この状態では、ＭＳ−ＤＯＳが動作していることになるが、所定のアプリケーションを起動しようとして、その実行ファイル名をキーボード７２から入力する際にも、キーボードのエミュレーションが実行されるのである。即ち、図１に示した「
仮想ＰＣ上のプログラム」とは、アプリケーションプログラムのみならずＤＯＳを含めたあらゆるプログラムである。この時、ＤＯＳ／Ｖ機は、プロテクトモードで動作しており、ＣＰＵ２１に備わったリング保護機能は、特権レベル３とされている。この状態で、仮想的に用意された９８用メモリ空間にアプリケーションプログラムＡＰＰがロードされ、仮想ＰＣ上でアプリケーションプログラムが実行されている状態を取り上げてエミュレーション装置の働きについて説明する。

エミュレーションの処理が起動されるには次の４つの要因がある。
〈１〉ページフォールト（メモリが割り当てられていない領域に対するアクセス）
〈２〉一般保護例外（特権命令の実行、Ｉ／Ｏの読み書き、書込保護されたメモリに対する書込命令の実行など）
〈３〉エラー（０除算など）
〈４〉ハード割り込み
これらの要因が生じると、カーネルＫＲが起動される。この時、各レジスタの値などはすべて保存されているから、カーネルＫＲは、自己が起動された原因を調べることができる。その結果、アクセスされたアドレスやＩ／Ｏが何か、あるいは生じたハード割り込みがいかなる機能に対応しているかを判断し、ディスパッチャＤＰを呼び出す。ディスパッチャＤＰを呼び出すアドレスは、図１２に示したように、初期化の処理において登録されているから、カーネルＫＲは、この呼出アドレスＡＤによりディスパッチャＤＰを呼び出すことができる。なお、カーネルＫＲに処理が渡った以降は、特権レベルは０に設定される。

ディスパッチャＤＰは、カーネルＫＲから受け取った情報を元にして呼び出す実行モジュールを特定し、その呼出アドレスをディスパッチャテーブルＤＴから取得する。ディスパッチャＤＰは、この呼出アドレスを用いて、各実行モジュールを呼び出すのである。図１には、実行モジュールとして、既述したように、
・メモリエミュレータＭＥＭ
・マウスエミュレータＭＵＭ
・グラフィックエミュレータＧＥＭ
・テキストエミュレータＴＥＭ
・文字フォントエミュレータＣＦＭ
・表示エミュレータＤＥＭ
・タイマエミュレータＴＩＭ
・キーボードエミュレータＫＥＭ
・ハードディスクエミュレータＨＤＭ
・割り込みコントローラエミュレータＩＲＭ
を示したが、これ以外にも、プリンタやＲＳ−２３２Ｃによるシリアル通信を司るエミュレータなど、各種の実行モジュールが存在する。

ハードウェア割り込みが発生したり、アプリケーションプログラムＡＰＰが特権命令を実行したりすると、カーネルＫＲに処理が移行し、カーネルＫＲは、特権命令の中身やハードウェア割り込みの詳細を検討し、ディスパッチャＤＰを呼び出す。ディスパッチャＤＰは、エミュレートすべき内容をカーネルＫＲから受け取り、ディスパッチャテーブルＤＴを参照して必要な実行モジュールをその呼出アドレスＡｎを用いて呼び出す。呼び出された実行モジュールは、自分だけで総ての処理が実行できる場合には、そのまま実行し、他の実行モジュールの処理を必要とする場合は、初期化の処理において予め得ておいたエントリポイントＥＰを用いて、必要な実行モジュールを直接呼び出す。これをモジュール間通信と呼ぶ。

図１４は、通常の実行モジュールの呼び出しとモジュール間通信とを例示した説明図である。図１４に示した例では、実行モジュールＤＭ２，ＤＭ３，ＤＭ５の間でモジュール間通信が行なわれるものとした。図示するように、ディスパッチャＤＰから呼び出される場合には、その呼出アドレスＡ２，Ａ３，Ａ５など、モジュール全体の開始アドレスが呼ばれることになるが、モジュール間通信の場合には、初期化の処理において一方的にあるいは相互に教示・取得したエントリポイントＥＰを利用して、各実行モジュール内の処理から必要に応じて、直接他のモジュールの内部処理を呼ぶことになる。例えば、実行モジュールＤＭ５の内部処理において、実行モジュールＤＭ２の内部処理を直接実行する必要が生じた場合には、エントリポイントＥＰ２１を参照し、直接実行モジュールＤＭ２内部の処理が呼び出され、実行される（符号Ｃ２１）。ディスパッチャＤＰを介して他の実行モジュールを呼び出す手法でも、呼び出すモジュールが必要とするサービスを示すパラメータを渡すことができれば、他の実行モジュールが用意している処理を個々に利用すること自体は可能であるが、ディスパッチャＤＰに対するサービスの要求、ディスパッチャＤＰによるディスパッチャテーブルＤＴの検索、呼出アドレスＡによる呼び出しといった手続が必要になってしまう。これに較べて、モジュール間通信は、必要な処理を直接呼び出すから、極めて高速に必要な処理を実行できるという利点がある。

各実行モジュールＤＭにより、アプリケーションプログラムＡＰＰが実行しようとした処理をエミュレートした後、順次処理を復帰し、カーネルＫＲからアプリケーションプログラムＡＰＰに復帰する。なお、ハードウェア割り込みにより割り込みコントローラエミュレータＩＲＭが呼ばれた場合や、他の実行モジュールの処理から割り込みコントローラエミュレータＩＲＭが呼ばれた場合には、割り込みコントローラエミュレータＩＲＭは、ＰＣ−９８００機における割込の発生をエミュレートするため、カーネルＫＲに対して仮想割り込みを発生する。この仮想割り込みによりカーネルＫＲが呼び出され、カーネルＫＲは、この仮想割り込みを判断して必要な実行モジュールを再度呼び出したり、場合によってはアプリケーションプログラムＡＰＰに復帰する。

次に、実際にＤＯＳ／Ｖ機上で行なわれるＰＣ−９８００機の各機能のエミュレーションの一例として、キーボード７２からの入力のエミュレーションを詳しく説明する。ＤＯＳ／Ｖ機のキーボード７２およびそのインタフェースであるＫＥＹ６４の構成を図１５に示す。他方、ＰＣ−９８００機の回路は、図１６に示す通りである。両図に示したように、ＤＯＳ／Ｖ機では、１チップマイクロコンピュータがキーマトリクスを読み取って、そのデータをＫＥＹ６４側にクロックに同期した同期通信により、ＣＰＵ２１側とやり取りする構成を採っており、ＰＣ−９８００機では、キーマトリクスを１チップマイクロコンピュータで読み取って、本体側に同期通信する構成を採っている。両者の通信の仕様は、異なっている。また、両機種のキーボードは図示しないが、キーボード７２そのもののキーの数なども異なっており、更に、同じキーを押し続けた場合のキーコードの発生などのメカニズムも異なっている。

図１７，図１８は、ＤＯＳ／Ｖ機のキーボード７２からの入力をＰＣ−９８００機におけるキーボードからの入力としてエミュレートする様子を示す説明図である。図は、上方からＤＯＳ／Ｖ機のハードウェア、エミュレーションの実行部、仮想９８の各層に分けて描いてある。仮想９８とは、ＰＣ−９８００機用に仮想的に用意されたメモリ空間であって、タスク自身としては、あたかもＭＳ−ＤＯＳが用意するＰＣ−９８００機の実空間で処理を行なっているように処理を実行できる空間を意味している。但し、この時点でＣＰＵ２１はプロテクトモードで動作しているので、仮想９８においてアプリケーションプログラムＡＰＰが特権命令などを実行しようとすると、直ちに例外処理として、タスクは切り換えられ、カーネルＫＲの処理に移行するのである。

アプリケーションプログラムＡＰＰの実行中にキーボード７２のキーが操作されると、キーボード７２からのキーコードがバッファＢＦに蓄えられ（図１７符号Ｄ１）、同時にハードウェア上の割込が生じる（ＩＮＴ ０９）。この割込要求は、直ちに処理をカーネルＫＲに移行させる（符号Ｄ２）。カーネルＫＲは、既述したように、ハードウェアの割込を解析してディスパッチャＤＰに処理を渡し（符号Ｄ３）、ディスパッチャＤＰは、初期化の処理において登録された呼出アドレスを用いてキーボードエミュレータＫＥＭを呼び出す。

キーボードエミュレータＫＥＭは、バッファＢＦに保存されたキーコードを読み出し、このキーコードが、ＰＣ−９８００機のキーコードに変換可能なものか否かを判断をする。両者は完全に一対一に対応しているものではなく、特にＤＯＳ／Ｖ機では、２つ目のキーコードが与えられて初めて一意に決まるものが存在する。従って、こうしたキーコードの場合には、ＰＣ−９８００機としてのキーコードの生成は行なわず、そのままディスパッチャＤＰ，カーネルＫＲを介して、キーボード７２からの割込が生じた状態に復帰する（符号ＤＲ）。他方、ＰＣ−９８００機としてのキーコードが発生可能と判断すると、キーボードエミュレータＫＥＭは、変換したキーコードを自分が管理するバッファＤＦに記憶し（符号Ｄ５）、続いてモジュール間通信により割り込みコントローラエミュレータＩＲＭを直接呼び出す処理を行なう（符号Ｄ６）。

図９ないし図１４を用いて詳述したように、本実施例では、各実行モジュールは、初期化の処理における組み込み時に、モジュール間通信を行なう相手のエントリポイントＥＰを取得している。キーボードエミュレータＫＥＭも、割り込みコントローラエミュレータＩＲＭを直接呼び出すエントリポイントＥＰを取得しており、更に割込番号の登録も済ませている。そこで、キーボードエミュレータＫＥＭから、直接割り込みコントローラエミュレータＩＲＭを呼び出し、割込のキーボード７２からの割込の発生を、割り込みコントローラエミュレータＩＲＭに渡す。

割り込みコントローラエミュレータＩＲＭは、このモジュール間通信を受けて、割込の内容を分析し、カーネルＫＲに対して必要な仮想割込を起こす（符号Ｄ７）。カーネルＫＲはこの仮想的な割込要求を受け付け、これを解析し、アプリケーションプログラムＡＰＰがキーボード７２からのキー入力を割込処理により受け付けるものであれば、ジャンプテーブルＪＴを参照し（符号Ｄ８）、ＰＣ−９８００機がキーボード７２からの割込を受け付けたときにジャンプする先を取得して、必要な処理ルーチンに移行する（符号Ｄ９）。アプリケーションプログラムＡＰＰが、キーボード７２からの割込要求によってではなく、自分で定期的にキー入力を見に行くタイプのものであれば、処理は一旦アプリケーションプログラムＡＰＰのレベルに戻される（符号Ｄ１０）。この場合には、所定時間毎に、キーボード７２からのキーコードを読み取るルーチンが呼ばれることになる（符号Ｄ１１）。なお、この時点で、ＣＰＵ２１の特権レベルは３に戻される。

こうして仮想９８上でキーコードを読み取る処理が呼ばれた以降の処理について、図１８を参照して説明する。キーコードを読み取る処理は、ＰＣ−９８００機の所定のＩ／Ｏアドレスに割り当てられたキーデータを読み取るＩ／Ｏ命令を実行する。このＩ／Ｏ命令は、特権命令の実行に当たり、特権レベル３では例外処理としてトラップされ、処理はカーネルＫＲに移行する（図１８符号Ｅ１）。カーネルＫＲは、この例外処理の内容を解析し、ディスパッチャＤＰを介してキーボードエミュレータＫＥＭを呼び出す（符号Ｅ２）。キーボードエミュレータＫＥＭは、呼び出された際のパラメータを認識することにより、割込要求に伴う処理かＩ／Ｏに対する読み出しに伴う処理かを判別し、バッファＤＦの内容を読み取る処理を行なう（符号Ｅ３）。バッファＤＦは、先にキーボードエミュレータＫＥＭが書き込んだＰＣ−９８００機としてのキーコードを保持しているから、これを同じキーボードエミュレータＫＥＭが読み取ることは容易である。

ハードウェア割込による処理ではないので、キーボードエミュレータＫＥＭは、ディスパッチャＤＰを介してカーネルＫＲへと処理を戻し、更に例外処理を引き起こした処理まで戻って行く（符号Ｅ４）。この結果、キーボード７２からのキーデータを入力するＰＣ−９８００機上の処理がなされ、そのデータはアプリケーションプログラムＡＰＰに渡されることになる。仮想９８上に展開されたＰＣ−９８００機用のアプリケーションプログラムＡＰＰは、ＰＣ−９８００機のキーボード７２からのキー入力があった場合と同一の動作を継続することになる。即ち、実施例のエミュレーション装置は、ＰＣ−９８００機のハードウェアとその動作を完全にエミュレートするのである。

以上、キーボード７２からの入力を例に採って、本実施例のエミュレーション装置の構成と働きについて説明したが、他の実行モジュールもほぼ同様に動作する。例えば、マウス７３の動作をエミュレートするマウスエミュレータＭＵＭは、次のように構成されている。ＰＣ−９８００機のマウスは、所定のインターバルで割込を発生し、ＣＰＵに対しては原点位置からの絶対値をデータとして渡すのに対して、ＤＯＳ／Ｖ機のマウス７３は、マウス７３が動いた場合に割込を発生し、しかも前回の位置からの差分のデータ（△ｘ，△ｙ）およびマウスボタンのオン・オフの情報からなるデータを引き渡すという違いがある。そこで、これをエミュレートするマウスエミュレータＭＵＭは、マウス７３が動いた時に発生するハードウェア割込により一度呼ばれ、読み取った差分のデータ（△ｘ，△ｙ）および前回のマウスの位置から現在のマウスの絶対的な位置を演算し、これを所定のバッファに記憶しておく。加えて、マウスエミュレータＭＵＭは、予めタイマエミュレータＴＩＭに対して所定時間毎に割込を発生するように依頼しておく。タイマエミュレータＴＩＭから所定のインターバルで割り込みコントローラエミュレータＩＲＭに対して割込が生じ、この割込を受け付けた割り込みコントローラエミュレータＩＲＭは、これをＰＣ−９８００機のマウスのための割込と認識してカーネルＫＲに対して仮想割込を発生する。この仮想割込によりカーネルＫＲはＭＵＭを再度呼び出す。マウスエミュレータＭＵＭは、この呼び出しに応じて先に計算しておいたマウスの絶対的な位置をバッファから読み出し、これを返す。この結果、アプリケーションプログラムＡＰＰは、所定のインターバルでマウスからの絶対位置のデータを受け取ることができる。

以上例示したキーボードエミュレータＫＥＭやマウスエミュレータＭＵＭは、いずれはハードウェア割込を利用するものであるが、割込を利用しないモジュールでは、例外処理の発生→カーネルＫＲからディスパッチャＤＰを介した実行モジュールの呼び出し→各実行モジュールでのエミュレート（必要ならモジュール間通信）→処理後のパラメータを持ってアプリケーションプログラムＡＰＰに復帰、という手順で処理がなされることになる。

更に、実際にＤＯＳ／Ｖ機上でのハードディスク８４への読み込みを仮想ＰＣ上での読み込みとしてエミュレートする様子を詳しく説明する。ハードディスク８４は、図２に示した複合Ｉ／Ｏポート５４に接続されている。この複合Ｉ／Ｏポート５４は、各種のＩ／Ｏ機器が接続される入出力制御用バスであるＩＳＡバス４２を構成しているものの一つである。またハードディスク８４の物理的な構造を図１９に示す。ハードディスク８４の物理的な構造は、図１９に示すようなヘッド、シリンダ、セクタという単位に分かれている。このハードディスク８４をアクセスするには「シリンダＡとヘッダＢで決まるセクタＣ」といった物理アドレスか、あるいはハードディスク８４の先頭セクタから通し番号を付けて「先頭からＤ番目のセクタ」といった論理アドレスを用い、このいずれかを指定することでアクセスするセクタを決定している。ヘッド数、シリンダ数、セクタ数などの物理的な構成単位は、ハードディスクの種類によって異なっているため、論理アドレスによって読み込むセクタを決定するのであれば、ハードディスクの構成の違いを吸収することができるが、物理アドレスにより、アクセスするセクタを指定する場合には、ハードディスクの構成の違いを考慮しなければ、正しいセクタをアクセスすることはできない。これらの物理的な構成単位は、ハードディスクのシステム管理情報として、オペレーティングシステムの管理下に置かれている。

図２０は、ハードディスク８４への読み込みを仮想ＰＣにおけるハードディスクへの読み込みとしてエミュレートする様子を示す説明図である。図は、上方から仮想ＰＣ（ターゲットマシン）、エミュレーション実行部、ＤＯＳ／Ｖ機（実行マシン）のハードウェアの各層に分けて描いてある。仮想ＰＣとは、ＰＣ−９８００機用に仮想的に用意されたメモリ空間であって、タスク自身としては、あたかもＭＳ−ＤＯＳが用意するＰＣ−９８００機の実空間で処理を行なっているように処理を実行できる空間を意味している。但し、この時点でＣＰＵ２１は仮想８６モードで動作しているので、仮想ＰＣにおいてアプリケーションプログラムＡＰＰが特権命令などを実行しようとすると、直ちに例外処理として、タスクは切り換えられ、カーネルＫＲの処理に移行するのである。

アプリケーションプログラムＡＰＰの実行中に仮想ＰＣのディスク＿Ｂａｓｉｃ＿Ｉｎｐｕｔ＿Ｏｕｔｐｕｔ＿Ｓｙｓｔｅｍ（以後ＤＩＳＫ−ＢＩＯＳと呼ぶ）を利用してハードディスク８４への読み込みが行なわれると、一般保護例外が発生し、例外処理としてタスクが切り替えられてカーネルＫＲに処理が移行する。ここで、ＤＩＳＫ−ＢＩＯＳは本エミュレータによって供給されており、ＰＣ−９８００機のＢＩＯＳ−ＲＯＭを代替するよう用意されている。ＢＩＯＳを呼び出したときに、一般保護例外が発生してカーネルに処理を移行するには、いくつかの手法が考えられる。一つは、ＢＩＯＳプログラムの中で実際にＩ／Ｏにアクセスしたとき、一般保護例外が発生してカーネルに処理が移行する構成である。もう一つは、ＢＩＯＳの所定のルーチンを呼び出した時点で一般保護例外を起こしてカーネルに処理を移行する構成である。ハードウェアのレベルでエミュレーションを行なう場合（例えば上述したキーボードエミュレータＫＥＭ等）は、前者の構成を採っているが、ハードディスクのアクセスなど、実際のアクセスまでにトラックやシリンダ，セクタの指定など種々の処理を必要とする場合には、ＢＩＯＳ全体をエミュレートした方が良い場合が存在する。以下に説明するハードディスクエミュレーションでは、ＢＩＯＳが呼び出されたときに、一般保護例外を生じさせて、エミュレーションを行なっている。この場合には、ＢＩＯＳの中のハードディスクのアクセスに関する処理の先頭に「ＨＡＬＴ」などの一般保護例外を引き起こす命令を用意しておく。アプリケーションプログラムＡＰＰからハードディスクアクセスのためにＢＩＯＳがコールされると、呼び出されたＰＣ−９８００機用のＢＩＯＳの先頭がアクセスされたとき、直ちに処理はカーネルに移行し、エミュレータが起動される。カーネルＫＲは、各レジスタの値などから自己が起動された原因を調べ、アクセスされたアドレスやＩ／Ｏが何かを判断し、ディスパッチャＤＰを呼び出す。

ディスパッチャＤＰは、カーネルＫＲから受け取った情報を元にして呼び出す実行モジュールを特定し、その呼出アドレスをディスパッチャテーブルＤＴから取得する。ハードディスクへ８４へのアクセスを行なうＢＩＯＳが呼び出された場合には、ディスパッチャＤＰは、この呼出アドレスを用いて、実行モジュールであるハードディスクエミュレータＨＤＭを呼び出すのである。なお、仮想ＰＣにおけるＢＩＯＳが呼び出されたときに、これに等価なＤＯＳ／Ｖ機用のＢＩＯＳを直接呼び出さないのは、後述するように、ハードディスクのアクセスにおいては、ハードディスクの物理アドレスの変換などの処理が必要となるからである。

ハードディスクエミュレータＨＤＭは、図２１に示すように、ハードディスク８４のパーティション領域、システム領域、ＤＯＳブート領域といった各領域のデータをＤＯＳ／Ｖ機用からＰＣ−９８００機用に作成する初期化部分、ＰＣ−９８００機のＤＩＳＫ−ＢＩＯＳのパラメータから読み込むセクタの物理アドレスを論理アドレスに変換する仮想ＰＣ用ＤＩＳＫ−ＢＩＯＳ処理部、変換した仮想ＰＣ用の論理アドレスをＤＯＳ／Ｖ機用に変換するアドレス変換部、変換されたＤＯＳ／Ｖ機用のアドレスをＢＩＯＳパラメータにセットするＡＴ−ＢＩＯＳ処理部を備えたＨＤＤエミュレータ部分と、ハードディスク８４のシステム領域データ、パーティション領域データ、ＤＯＳブート領域データ及びローカルデータを備えたディスク情報ブロックとから構成されている。以下、ハードディスクエミュレータＨＤＭの処理について詳しく説明する。まず最初に、システム領域、パーティション領域、ＤＯＳブート領域のＤＯＳ／Ｖ機とＰＣ−９８００機との違いについて説明する。

図２８にＰＣ−９８００機が管理するハードディスクのシステム領域のマップを示す。図２８に示すようにＰＣ−９８００機のシステム領域は、ハードディスクの先頭セクタ（シリンダ０、ヘッド０、セクタ１）に固定されており、計５１２バイトの領域が確保されている。システム領域の先頭から３バイト目以降の内容が＃ＩＰＬ１となっており、ＰＣ−９８００機は、起動時にハードディスクのこの部分を参照する。一方、ＤＯＳ／Ｖ機のシステム領域の位置は、ＰＣ−９８００機同様ハードディスクの先頭セクタではあるが、ＰＣ−９８００機のように起動時に参照されるデータが格納されているわけではなく不定である（ＰＣ−９８００機のように３バイト目以降の内容が＃ＩＰＬ１となっている訳ではない）。よってこのようなシステム領域では、ＯＳカーネル、アプリケーションプログラム等がどこを参照すれば良いか固定的に決めることができない。したがって、そのままでは、エミュレーション装置を構成し、ＤＯＳ／Ｖ機用のハードディスク８４を仮想ＰＣ上で認識させる、ということがことができない。そこで、この実施例のエミュレーション装置では、エミュレーションを行なう際には、専用のアプリケーションを実行することにより、ＤＯＳ／Ｖ機用のシステムファイルなどの名称を変更すると共に、ＤＯＳ／Ｖ機用のハードディスク８４の先頭セクタから３バイト以降の内容を、強制的に図２８のように書き直している。なお、書き直される以前にこのセクタに置かれていた内容は、予め別の場所に退避しておき、エミュレーションを行なわない設定を変更する場合に、専用のアプリケーションプログラムを実行することにより、システムファイルの名称を元に戻すと共に、退避したデータを書き戻している。

次に図２４、２５を用いてＤＯＳ／Ｖ機のパーティションについて説明する。ＤＯＳ／Ｖ機のハードディスク８４の各ドライブは、図２５に示すように、パーティション領域をそれぞれ持っている。それぞれのパーティション領域は、図２４に示すように２つのパーティション情報を格納している。例えば図２４におけるパーティション領域の上半分のパーティション情報（パーティション１）が、図２５においてデータ領域であるドライブ＃１の開始及び最終アドレスの情報であるとすると、図２４におけるパーティション領域の下半分のパーティション情報（パーティション２）は、図２５において次のデータ領域であるドライブ＃２のパーティション情報が格納されているパーティション領域の開始及び最終アドレスの情報になっている。それぞれのドライブのこうしたパーティション領域は、図２５に示すように、ポインタにより順次リンクされている。

一方、ＰＣ−９８００機のパーティションについて図２６、２７を用いて説明する。ＰＣ−９８００機のハードディスクのマップは、図２７に示すように、先頭セクタから、システム領域、パーティション領域、ＯＳ領域、ＤＯＳブート領域、データ領域となっている。ここで重要なのはＰＣ−９８００機のパーティション領域は図２５のＤＯＳ／Ｖ機のようにパーティション領域がリンクされておらず、すべてのドライブのパーティション情報が図２７のようにシステム領域の後に格納されていることである。更にパーティション領域に格納されているそれぞれのパーティション情報は、図２６のようにシステムが登録されているパーティションかどうかを表すセレクタ、パーティションのＯＳ及びファイルシステムを表す状態、ＢＯＯＴプログラムのアドレス、開始アドレス、最終アドレス、ＯＳ＿ＩＤ名という順になっている。これに対して、ＤＯＳ／Ｖ機では、図２４に示したように、パーティション情報が、起動可能なパーティションかどうかを表すブートインジケータ、開始アドレス（開始ヘッド，開始セクタ，開始シリンダ）、パーティションのＯＳ及びファイルシステムを表すシステムインジケータ、最終アドレス（最終ヘッド，最終セクタ，最終シリンダ）、ブートセクタの相対値、パーティション内のセクタ数という順になっており、ＰＣ−９８００機とはパーティション情報の形式や内容、配置が異なっている。また各パーティションの開始アドレスがＤＯＳ／Ｖ機の場合はシリンダ０、ヘッド１、セクタ１となり、ＰＣ−９８００機の場合はシリンダ１、ヘッド０、セクタ１と異なっていたり、ＰＣ−９８００機で使用しているヘッド数、セクタ数がＤＯＳ／Ｖ機で使用しているヘッド数、セクタ数の値と一致しない場合がある。

以上のことから、仮想ＰＣ上で動作しているアプリケーションプログラムからハードディスクをアクセスする際、ＤＯＳ／Ｖ機のパーティション領域をそのまま利用するすることはできない。即ち、各々のドライブのアクセスしたいデータにアクセスできず、ＤＯＳ／Ｖ機用のハードディスク８４を仮想ＰＣ上で認識させることができない。そこでＤＯＳ／Ｖ機のパーティション領域の開始及び最終アドレスをＰＣ−９８００機用にアドレスを変換し、図２６に示すようなパーティション領域を作成する必要がある。

最後に図２９にＰＣ−９８００機のＤＯＳブート領域のマップを示す。ＤＯＳ／Ｖ機のＤＯＳブート領域も図２９とほぼ同じ構成になっている。しかし、ＰＣ−９８００機とＤＯＳ／Ｖ機とでは図２９の幾つかの項目で異なる部分があるためＤＯＳ／Ｖ機のＤＯＳブート領域の幾つかの項目を書き直す必要がある。具体的には図２９においてＤＯＳブート領域の先頭から１８Ｈバイト目のトラック当りのセクタ数や１ＡＨバイト目のヘッド数、１ＥＨ及び４０Ｈバイト目のハードディスクの先頭セクタからＤＯＳブート領域までのセクタ数、４２Ｈバイト目のＯＳ領域のサイズ数、４４Ｈバイト目の物理セクタ長、４６Ｈバイト目のデバイスコード、４７Ｈバイト目のコマンドコードである。

以上説明したように、ハードディスクエミュレータＨＤＭでは、前述したシステム領域データ、パーティション領域データ、ＤＯＳブート領域データの違いから、それぞれの領域をＤＯＳ／Ｖ機用からＰＣ−９８００機用に作成するといったハードディスク８４の初期化処理を、実行時の最初の１回のみ行なっている。以下、図２２のフローチャートを用いてハードディスク８４の初期化処理を説明する。

ハードディスクの初期化処理部（ステップＳ４００）では、まずＤＯＳ／Ｖ機のハードディスクの先頭セクタであるシステム領域を取得する（ステップＳ４１０）。システム領域の先頭から１ＢＥＨバイト目以降に格納されているパーティション情報を取得する（ステップＳ４２０）。取得したパーティション情報の開始及び最終アドレスをＰＣ−９８００用の開始及び最終アドレスに変換し（ステップＳ４３０）、図２６に示した形式でディスク情報ブロックにパーティション領域データとして格納する（ステップＳ４４０）。ＤＯＳ／Ｖ機の場合は図２５に示したように各パーティション領域がリンクされているので次のパーティション情報がないとの判断がなされるまで（ステップＳ４５０）、ステップ４１０〜ステップ４４０までの処理を繰り返す。以上のようにしてＰＣ−９８００機用のパーティション領域を作成する処理を、図２１のブロック図におけるパーティション領域データ作成部が行なっている。

最後に前述したようにシステム領域の先頭から３バイト目以降の内容に変更を加えて、ディスク情報ブロックにシステム領域データとして格納する処理を行なう（ステップＳ４６０）。以上のようにしてＰＣ−９８００機用のシステム領域を作成する処理を、図２１のブロック図におけるシステム領域データ作成部が行なっている。

図２２のフローチャートには示していないが、ＤＯＳブート領域についても前述したようにＤＯＳブート領域のトラック当たりのセクタ数、ヘッド数等に変更を加えて、ディスク情報ブロックにＤＯＳブート領域データとして格納する。以上のようにしてＰＣ−９８００機用のＤＯＳブート領域を作成する処理を、図２１のブロック図におけるＤＯＳブート領域データ作成部が行なっている。

以上のようなハードディスク８４の初期化処理を実行時の最初に行い、ＰＣ−９８００機用に変換したシステム領域、パーティション領域、ＤＯＳブート領域をデータとしてディスク情報ブロックに持つ。以後システム領域、パーティション領域、ＤＯＳブート領域に対するアクセス時には、初期化処理で作成したデータを読み込めば良く、ハードディスクへのアクセスが速くなる。

なお、システム領域データ、パーティション領域データ、ＤＯＳブート領域データをディスク情報ブロックに格納せずにシステム領域、パーティション領域、ＤＯＳブート領域に対するアクセス毎にこれを作成するという構成も可能である。この場合には、各領域データをメモリに格納する必要がないので、メモリの使用を節約することができる。しかし、システム領域、パーティション領域、ＤＯＳブート領域に対するアクセス毎にシステム領域、パーティション領域、ＤＯＳブート領域の変換および作成が行なわれるので、本実施例に比べてハードディスクへのアクセスが遅くなる。

次に、ハードディスクエミュレータＨＤＭの実際のエミュレートについてハードディスクからのデータの読み込みを例にとって説明する。まず、大まかに処理の流れを説明する。図２０に示したように、仮想ＰＣとしてのタスクで動作しているアプリケーションプログラムＡＰＰがハードディスク８４をアクセスしようとして、仮想ＰＣ上のＤＩＳＫ＿ＢＩＯＳを呼び出すと、該当するＢＩＯＳルーチンの先頭に置かれた「ＨＡＬＴ」命令が実行され、特権命令の実行であるとして、一般保護例外によるトラップが発生する。この結果、カーネルＫＲおよびディスパッチャＤＰを介して、ハードディスクエミュレータＨＤＭが呼び出される。ＤＯＳ／Ｖ機用のＤＩＳＫ＿ＢＩＯＳには、ＰＣ−９８００機用のＢＩＯＳとほぼ等価なルーチンが用意されているので、ハードディスクエミュレーションＨＤＭは、ＢＩＯＳレベルでエミュレーションを行なうものとし、後述するアドレス変換などの所定の処理の後、タスクをＤＯＳ／Ｖ機としてのタスクに切り替えて、そのＤＩＳＫ＿ＢＩＯＳを呼び出す。この結果、実際のハードディスク８４に対する処理が行なわれ、ヘッドシークやセクタリードなどの処理が行なわれ、データのやり取りを伴う処理の場合には、ＤＯＳ／Ｖ機のＤＩＳＫ＿ＢＩＯＳが管理するバッファとの間でデータの転送が行なわれる。ハードディスク８４から読み出され、バッファに書き込まれたデータは、ＤＯＳ／Ｖ機としてのタスク内に用意されたバッファに書き込まれることになる。このバッファは、ハードディスクエミュレータＨＤＭが固定的に確保している。ハードディスクエミュレータＨＤＭは、このデータを、仮想ＰＣ側のバッファに移し、その後、ディスパッチャＤＰ，カーネルＫＲを介して、仮想ＰＣ側に処理を返す。仮想ＰＣ側のＢＩＯＳコールからアプリケーションプログラムＡＰＰに処理が戻った時点では、仮想ＰＣ側のタスク内のバッファに、所望のデータが用意されていることになる。なお、仮想ＰＣ側のバッファは、仮想ＰＣのＤＯＳが予め用意するものとしても良いし、アプリケーションプログラムＡＰＰが、ＢＩＯＳコールに先立って動的に確保するものとしても良い。

実際に、上記の処理を行なおうとすると、ＰＣ−９８００機とＤＯＳ／Ｖ機では、使用できるハードディスクのヘッド数、セクタ数の違い等があるために、仮想ＰＣ上で用意したセクタの物理アドレスをそのままＤＯＳ／Ｖ機上では利用できない。そこで、実際のハードディスクへのアクセスを示す図２３に示したように、ハードディスク８４に対する読み込みの処理では、まずアドレス変換の処理を行なう。

この処理では、最初に、仮想ＰＣ上で実行しようとしたハードディスクの読み込みが物理アドレスによるものか論理アドレスによるものかを判定する（ステップ５００）。ハードディスクの読み込みが物理アドレスによるものである場合には、ＰＣ−９８００機上のハードディスク情報（ヘッド数、セクタ数、シリンダ数）を用いて論理アドレスに変換する（ステップ５１０）。具体的には読み込んだシリンダ番号にヘッド数を乗じたものに読み込んだヘッド番号を加える。これに１トラック当りのセクタ数を乗ずることで、今読み込もうとしているシリンダ番号までの総セクタ数が求められる。これに読み込んでいるセクタ番号を加えることでハードディスクの先頭セクタから数えたセクタ番号である論理アドレスを得ることができる。計算によらずとも、変換テーブルによっても容易に、物理アドレスを論理アドレスに変換することができる。以上のように仮想ＰＣにおける物理アドレスをＰＣ−９８００機用のハードディスク情報を用いて論理アドレスに変換する処理を、図２１のブロック図における仮想ＰＣ用ＤＩＳＫ−ＢＩＯＳ処理部が行なっている。ただし、仮想ＰＣ上でのハードディスクの読み込みが論理アドレスの場合には（ステップＳ５００）、上記のような処理は必要ない。

次に、変換した論理アドレスを今度はＤＯＳ／Ｖ機上のハードディスク情報（ヘッド数、セクタ数、シリンダ数）を用いてＤＯＳ／Ｖ機上のハードディスクに対応した物理アドレスに変換する（ステップ５２０）。具体的には論理アドレスを最大ヘッド数に最大セクタ番号を乗じたもので割ることで読み込んでいるシリンダ番号が得られる。この除算の余りを最大セクタ番号で割ることで、読み込もうとしているヘッド番号が得られる。更に、この除算の余りに１を加えることで、読み込もうとしているアドレスのセクタ番号が得られる。以上の演算の結果、論理アドレスをＤＯＳ／Ｖ機の物理アドレスに変換することができる。仮想ＰＣにおける論理アドレスをＤＯＳ／Ｖ機用のハードディスク情報を用いて物理アドレスに変換する以上の処理を、図２１のブロック図における仮想ＰＣ用アドレスをＡＴ用の物理アドレスへの変換部が行なっている。

次に変換した物理アドレスをＤＯＳ／Ｖ機のＤＩＳＫ−ＢＩＯＳの機能であるセクタ読み込みの入力パラメータであるセクタ数、シリンダ・セクタ番号、ヘッド番号、ドライブ番号にセットしてＤＩＳＫ−ＢＩＯＳを実行するためにＤＯＳ／Ｖ機のＤＩＳＫ−ＢＩＯＳに処理を渡す。ＤＯＳ／Ｖ機のＤＩＳＫ−ＢＩＯＳの実行は図２０のＤＯＳ／Ｖハードで行なわれるので、この時点で図２０におけるＤＯＳ／Ｖハードにタスクが切り替わる。ＤＩＳＫ−ＢＩＯＳでは入力パラメータに従ってハードディスクの指定されたセクタの内容が読み込まれ、その内容がバッファに格納される（ステップ５３０）。図２０においてＤＯＳ／Ｖハードのタスクでは必要なＢＩＯＳの処理を実行し終了すると、ハードディスクエミュレータＨＤＭの処理にタスクが切り替わる。ハードディスク８４の指定されたセクタの内容がバッファに読み込まれるとタスクが切り替わりハードディスクエミュレータＨＤＭに処理が渡されるのである。ハードディスクエミュレータＨＤＭでは読み込んだセクタに対して以下の処理を行なう。

読み込んだセクタの内容がシステム領域かあるいはパーティション情報であるか判定する（ステップ５４０）。読み込んだセクタの内容がシステム領域あるいはパーティション情報であれば、これはＤＯＳ／Ｖ機のデータであって仮想ＰＣ側が必要としているＰＣ−９８００機用のデータではないから、先程の初期化処理で作成されたＰＣ−９８００機用のシステム領域データあるいはパーティション領域データをディスク情報ブロックから読み出す（ステップ５４１）。読み込んだセクタの内容がシステム領域かあるいはパーティション情報でなければ、次にＤＯＳブート領域かどうか判定する（ステップ５５０）。読み込んだセクタの内容がＤＯＳブート領域であれば、これも仮想ＰＣ上の処理が必要としているＰＣ−９８００機用のＤＯＳブートのデータではないから、先程の初期化処理で作成されたＰＣ−９８００機用のＤＯＳブート領域データをディスク情報ブロックから読み出す（ステップ５５１）。上記いずれの領域情報でもなけれは、ハードディスク８４から読み出しておいた内容は何等変更しない。

以上の判断の後、データを、仮想ＰＣ用のメモリ空間へ書き込む（ステップ５６０）。従って、本実施例では、システム領域，パーティション領域あるいはＤＯＳブート領域に対するアクセスであれば、ディスク情報ブロックに記憶したデータにより書換えたデータを、そうでなければハードディスク８４から読み出したデータが、仮想ＰＣ用のメモリ空間に書き込まれ、仮想ＰＣ側に引き渡される。したがって、仮想ＰＣ側からは、あたかもＰＣ−９８００機のハードディスクをアクセスしているかのようにハードディスクのアクセスを実行することができる。この実施例では、システム領域などに対するアクセスであっても、必ず実際にハードディスク８４をアクセスするので、ハードディスク８４に何等かのトラブルが発生した場合でも、即座にその情報を得ることができるのである。

以上の読み込み処理が終了するとハードディスクエミュレータＨＤＭは、ディスパッチャＤＰを介してカーネルＫＲへと処理を戻し、更に例外処理を引き起こした処理まで戻っていく。この結果、仮想ＰＣ上で読み込まれたセクタに該当する内容がハードディスクエミュレータＨＤＭによってＤＯＳ／Ｖ機上のハードディスク８４から読み込まれ、仮想ＰＣ用のメモリ空間に書き込まれる。その後、仮想ＰＣ上のアプリケーションプログラムＡＰＰがこの内容を受け取り処理を行なうことになる。以上の結果、仮想ＰＣ上に展開されたＰＣー９８００機用のアプリケーションプログラムＡＰＰはＰＣ−９８００機上のハードディスクへ読み込みをあった場合と同一の動作をすることになる。すなわち、実施例のエミュレーション装置は、ＰＣ−９８００機のハードウェアとその動作を完全にエミュレートするのである。

以上のようにハードディスクエミュレータＨＤＭは、仮想ＰＣ上のタスクの実行→ＢＩＯＳコールによる例外処理の発生→カーネルＫＲからディスパッチャＤＰを介した実行モジュールの呼び出し→各実行モジュールでのＤＯＳ／Ｖ機用のタスクでのＢＩＯＳコールを含むエミュレート→処理後のパラメータを持って仮想ＰＣタスクのアプリケーションプログラムＡＰＰに復帰、という手順で処理がなされることになる。

尚、本ハードディスクエミュレータＨＤＭは、カーネルＫＲ、ディスパッチャＤＰ等からなるエミュレーションシステムの一部としての動作に加え、単独での動作も可能である。具体的には、初期化時にディスク情報ブロックに９８用ＨＤＤの情報を作成する動作は、ＳＭＩ（システム・マネジメント・インタラプト：インテルのＣＰＵに備えられた最優先割り込み）等で本ＨＤＤエミュレータを呼び出して行ない、以降のアドレス変換はハードウェアにより高速に行なうことも可能である。即ち、エミュレーションの主操作をハードウェアによって行い、一部に本エミュレーションシステムの機能を埋めこむことも有効である。

本実施例によりＤＯＳ／Ｖ機上のハードディスク８４をＰＣ−９８００機用に改めてフォーマット（初期化）することなく、ＤＯＳ／Ｖ機のハードディスク８４をその状態のまま利用すことができる。そのため、ハードディスク上の資源を共有化することが可能である。また本実施例では、ハードディスク８４の初期化処理を、ハードディスク８４に対する最初のアクセス時に行い、ＰＣ−９８００機用に変換したシステム領域、パーティション領域、ＤＯＳブート領域をデータとしてディスク情報ブロックに持つようにしている。したがって、システム領域、パーティション領域、ＤＯＳブート領域に対するアクセス時には初期化処理で作成したデータを読み込めばよく、前記領域へのアクセス毎にデータをＰＣ−９８００機用に変換する必要がないので、ハードディスクへのアクセスが速くなる。

以上説明した本実施例のエミュレーション装置によれば、実行マシン上でターゲットマシンをエミュレーションするプログラムが、カーネルＫＲ、ディスパッチャＤＰ、各実行モジュールと階層化されており、極めて見通しの良い構成となっている。従って、膨大な機能をエミュレートする膨大なプログラムを効率よく開発することができる。しかも、各実行モジュールはハードウェアの機能に近いところでモジュール化されているので、物理アドレスをハードディスクを読み書きするなどハードウェアに直接アクセスするようなアプリケーションプログラムＡＰＰであっても、エミュレーションを正しく行なうことができる。

次に、本発明の他の実施例について説明する。この実施例もハードディスクのエミュレーションに関するものである。この実施例が、上述した実施例と異なる点をまず説明する。上述した実施例では、ハードディスク８４の先頭アドレスの内容を強制的に書き直してしまうため、同一のハードディスク８４から、ＰＣ−９８００機として立ち上げるかＤＯＳ／Ｖ機として立ち上げるかを設定する際には、オペレーティングシステムがその組み込み時に必要とするファイルを共存させることができない。例えば、ＭＳ−ＤＯＳでは、その組み込み時に、「ｃｏｎｆｉｇ．ｓｙｓ」や「ｃｏｍｍａｎｄ．ｃｏｍ」など、決まった名称のファイルを必要とするが、ＰＣ−９８００機としてのＭＳ−ＤＯＳでも、ＤＯＳ／Ｖ機としてのＭＳ−ＤＯＳでも、同一の名称のファイルをルートディレクトリに必要とすることは変わりがない。この場合、アーキテクチャの異なる機種では、これらのファイルの中身は当然異なったものとなるので、共通化を図ることはできない。

そこで、上述した実施例では、エミュレーションを行なう場合には、セットアッププログラムを実行してオリジナルのファイルの拡張子を変更し、ターゲットマシンのためのファイルをデフォルトとし、逆にエミュレーションを行なわない場合には、セットアッププログラムにより両者の拡張子をそれぞれ元に戻していた。しかし、こうした手法では、ファイル名称などをユーザーが変更したりすると、セットアップを正常に行なうことが困難になってしまう。また、複数のハードディスク装置が接続されている場合、あるいは複数のパーティションが設けられている場合、これを仮想マシン上でどのように認識するかという点については、十分な対応がとられていなかった。以下に説明する実施例では、上記実施例におけるハードウェアエミュレーションを更に改良し、オペレーティングシステムが必要とするシステムファイルのファイル名称などを改変することなく、かつ複数のハードディスク装置を適正に扱うことが可能なエミュレーション装置およびその方法に関するものである。

この実施例のハードウェア構成は、上述した実施例と同様である（図１および図２参照）。この実施例では、エミュレーション装置を成立させるために、図３０に示したインストールプログラムが、エミュレーション処理に先立って実行される。このプログラムは、ＤＯＳ／Ｖ機がその正規のオペレーティングシステムの下で動作している状態で実行され、仮想ＰＣとしてのＰＣ−９８００機の環境をセットアップするプログラムである。この処理が開始されると、まずＤＯＳ／Ｖ機に接続されているハードディスク８４の空き容量などをチェックする処理を行なう（ステップＳ６００）。続いて、最大の連続する空き領域を取得する処理を行なう（ステップＳ６０２）。これは、ハードディスク８４の空き領域のうち、連続する領域を確保するためのものであり、連続した空き領域が例えば４０Ｍバイトと５０Ｍバイトあれば、５０Ｍバイトが取得される。

次に、この連続空き領域を含む情報の表示を行ない（ステップＳ６０４）、各種の設定を入力する処理を行なう（ステップＳ６０６）。ＣＲＴ７６に表示されるこの時の設定画面の一例を図３１に示す。仮想ＰＣセットアッププログラムは、仮想ＰＣ用のプログラムをインストールするドライブやそのサブディレクトリの名称、およびステップＳ６０２で取得した最大の空き領域（図３１では１０Ｍバイト）等を表示する。使用者は、この画面を見ながら、カーソルキーを操作して設定しようとする項目を選択し（反転状態となるが、図示では四角の枠で囲った）、ディレクトリ名等を設定する。なお、最大空き領域の大きさを越えない範囲であれば、仮想ＰＣのＭＳ−ＤＯＳの領域は、必要容量以上の所望な大きさに設定することができる。

所望の設定となるまで、設定処理を繰り返し、画面下の「インストールして終了」が選択されると（ステップＳ６０８）、インストールの処理が行なわれる（ステップＳ６１０）。この処理は、まず設定された連続する空き領域をＭＳ−ＤＯＳ上のファイルとして確保する処理を行なう。連続した空き領域を確保するために、ファイルアロケーションテーブル（ＦＡＴ）を直接書き換え、ＭＳ−ＤＯＳが管理しているディレクトリの情報と結びつける。空き領域を確保するために作成されるこのファイルの属性は、不可視ファイル（Ｈｉｄｄｅｎ）でリードオンリーである。更に、このファイル（以下、仮想ＰＣシステムファイルと呼ぶ）の中に、ＤＯＳのブートセクタ情報、ＦＡＴ領域、ディレクトリ領域、データ領域のディスクイメージを作成し、あたかもＰＣ−９８００機のハードディスクとしてフォーマットされたかのようにデータを書き込む。その後、このフォーマットした仮想ＰＣシステムファイルをディスクとしてアクセスするために、仮想ドライブドライバをメモリにロードし、この仮想ドライブドライバが管理する仮想ＰＣシステムファイルのルートディレクトリの領域に、ＤＯＳのサブディレクトリを作成する。

以上の処理の後、セットアッププログラムによるセットアップの内容を、所定のファイルに書き出し、その後、ＰＣ−９８００機の機能をＤＯＳ／Ｖ機上でエミュレートするのに必要な各種ファイルをハードディスク８４の予め定めたサブディレクトリに転送する。続いて、ＤＯＳ／Ｖ機用に用意されたＭＳ−ＤＯＳのシステムファイルである「ｃｏｎｆｉｇ．ｓｙｓ」というファイルの先頭に、エミュレーションを実現するデバイスドライバ（実施例では「ＮＳＥＬＥＣＴ．ＳＹＳ」）を記述する処理を行なう。従って、インストールが行なわれ後では、コンピュータが起動されると、まずＤＯＳ／Ｖ機としてのブートが行なわれてＢＩＯＳなどがロードされた後、ＤＯＳ／Ｖ機用のシステムファイルである「ｃｏｎｆｉｇ．ｓｙｓ」を参照してデバイスドライバを組み込むが、その段階で、このデバイスドライバ「ＮＳＥＬＥＣＴ．ＳＹＳ」を組み込む処理が実行されることになる。このデバイスドライバの組込の処理により、エミュレーションのための処理が開始されることになる。このデバイスドライバを組み込む処理が行なわれると、ＤＯＳ／Ｖ機用のファイル「ｃｏｎｆｉｇ．ｓｙｓ」に記述されている他のデバイスドライバは一切組み込まれないことになる。

システムファイル「ｃｏｎｆｉｇ．ｓｙｓ」を書き直したところで、インストールの処理をすべて終了として、インストール処理ルーチン（図３０）を抜けて、ＤＯＳのプロンプト状態に戻り、待機する。

ＰＣ−９８００機のエミュレーションを行ないたい場合には、以上説明したインストールを行なった後、実施例のＤＯＳ／Ｖ機をリセットないし電源断−再投入を行なう。このとき、ＤＯＳ／Ｖ機は、図３２に示した電源投入時処理ルーチンを実行する。この処理が開始されると、コンピュータは、ＤＯＳ／Ｖ機としての通常の初期化の処理（ステップＳ６２０）、ＢＩＯＳの展開の処理（ステップＳ６２２）を行なう。通常、即ちエミュレーションの機能がオンになっていなければ、コンピュータは、そのまま、システムファイル「ｃｏｎｆｉｇ．ｓｙｓ」を参照してデバイスドライバを組み込む処理（ステップＳ６２４）に進む。しかし、実際には「ｃｏｎｆｉｇ．ｓｙｓ」というシステムファイルの先頭には、エミュレーションの機能を記述したデバイスドライバ「ＮＳＥＬＥＣＴ．ＳＹＳ」を組み込むための情報が記載されているので、処理は、このデバイスドライバの組込の処理（図３２、ステップ６３０ないしステップＳ６６０）に移行する。なお、このデバイスドライバ「ＮＳＥＬＥＣＴ．ＳＹＳ」を組み込む処理の中で、他の実行ファイルが呼び出すことも可能である。実施例では、「ＮＳＴＡＲＴ．ＥＸＥ」というプログラムを呼び出して実行している。

即ち、図３２に示した処理のうち、右側の欄は、ＤＯＳ／Ｖ機のファイル「ｃｏｎｆｉｇ．ｓｙｓ」の先頭に書き込まれたデバイスドライバ「ＮＳＥＬＥＣＴ．ＳＹＳ」を組み込む処理および所定の実行ファイル「ＮＳＴＡＲＴ．ＥＸＥ」の処理として実現される。まず、エミュレーション装置を構築する処理を行なう（ステップＳ６３０）。これは、どんなアーキテクチャの機種をエミュレートするかを決定するものである。次に、エミュレーションを行なうターゲットマシンの仮想ＢＩＯＳを読み込み（ステップＳ６３２）、ターゲットマシン用に確保されたプロテクトメモリ上に展開する（図７参照）。ターゲットマシン用のこのメモリ領域は、タスクの切換により実アドレスに割り当てられる。したがって、ＤＯＳ／Ｖ機のＢＩＯＳの展開（ステップＳ６２２）とターゲットマシンの仮想ＢＩＯＳの読み込み（ステップＳ６３２）とが行なわれた後では、ＤＯＳ／Ｖ機用のＢＩＯＳは実アドレスに割り当てられ、ターゲットマシンであるＰＣ−９８００機用のＢＩＯＳはリアルモード空間に仮想的に割り当てられる。両ＢＩＯＳは、タスクの切換により、それぞれのタスクアドレス空間で実行可能となる。仮想８６モードを用いることにより、リアルモードで動作可能に作られているこれらの各ＢＩＯＳが、１Ｍバイトを越えるプロテクトモード空間でも使用可能となる。また、それぞれのＢＩＯＳによるファイルのアクセスなどに必要なバッファもそれぞれのタスク空間に用意される。

更に、この仮想ＢＩＯＳを用いて仮想システムファイルをハードディスク（ＨＤＤ）としてアクセスし（ステップＳ６３４）、エミュレーションを行なって動作するシステムとしての初期化を行なう（ステップＳ６４０）。この初期化の処理については、図３３以下のフローチャートを用いて、後述する。その後、ターゲットマシンとしてのブートを行なって（ステップＳ６５０）、ターゲットマシンとして立ち上がる（ステップＳ６６０）。ターゲットマシンとして立ち上がる場合には、第１実施例で説明したように、カーネルＫＲやディスパッチャＤＰ、各種エミュレーションモジュールなどが組み込まれることになる。これらの詳細は、第１実施例と同様なので、説明は省略する。

次に、初期化の処理（ステップＳ６４０）について説明する。初期化処理は、図３３に示すように、大きくは、仮想システムファイル情報の取得および作成（ステップＳ７００，詳細は図３８）、パーティションの並び替え（ステップＳ７２０，詳細は図３９）、仮想ハードディスクの作成（ステップＳ７４０，詳細は図４２）、アドレス調整（ステップＳ７６０）、オフセットテーブルの作成（ステップＳ７８０，詳細は図４４）から構成されている。まずこれらの処理の詳細を説明する前に、初期化の処理がなされた後の全体構成および仮想ＰＣシステムファイルの内容などについて説明する。

このハードディスクエミュレータＨＤＭは、図３４に示すように、実際にエミュレーションの処理を行なうＨＤＤエミュレータ部と、エミュレーションのための情報を記憶しているディスク情報ブロックから構成されている。ＨＤＤエミュレータ部は、図２１に拠って第１実施例で説明したＢＩＯＳ処理部などに加えて、新たに、仮想ＰＣシステムファイルの情報を作成する仮想システムファイル情報作成部、仮想的なハードディスクを構成する仮想ＨＤＤ作成部、ハードディスクのアドレス変換のためのオフセットテーブルを作成するオフセットテーブル作成部が設けられている。これらの作成部は、本実施例で、仮想的なハードディスクをファイルとして、ＤＯＳ／Ｖ機用のハードディスク８４の内部に確保しているため必要となったものである。図３４には、この仮想的なハードディスクに相当するファイルである仮想システムファイルを確保する手段を、仮想システムファイル領域確保部ＶＳＦとして、示した。この仮想システムファイル領域確保部ＶＳＦは、ハードディスク８４内の最大の連続空き領域を取得し（図３０、ステップＳ６０２）、インストールの指示を受けて（同図ステップＳ６０８）、インストールすることにより（ステップＳ６１０）、ハードディスク８４内に確保するものである。

ハードディスクエミュレータＨＤＭのディスク情報ブロックは、エミュレーションに必要な情報をハードディスクエミュレータＨＤＭが管理するプロテクトメモり上に記憶しているものであり、初期化の処理を通じて必要なデータが構成されている。ここに記憶されているデータは、ターゲットマシンとして処理を行なうために必要なデータであり、システム領域の情報、ＤＯＳのブート領域の場所に関するデータ、パーティション領域のデータ（複数のハードディスクのパーティションの並びに関するデータ）、オフセットデータ（実行マシンに実際に接続されたハードディスクと仮想ディスクとの間のアドレス変換を行なうためのデータ）、ローカルデータが記憶されている。ＰＣ−９８００機用のハードディスクとしてエミュレートされるものは、実際には、ＤＯＳ／Ｖ機用のハードディスク８４の内部にファイルとして確保された連続領域である。この領域を仮想ＰＣシステムファイルと呼ぶが、図３５に示すように、ハードディスクのイメージでフォーマットされている。この領域の先頭には、ＤＯＳブート領域までのオフセットが記録されており、そこから実際のＤＯＳのブート領域まではダミーデータが記録されている。ダミーデータを記録しているのは、後述するアドレス変換のためであり、ＤＯＳブート領域の先頭の論理アドレスが所定の条件を満たすように、ダミーデータの領域の大きさを調整している。ＤＯＳブート領域の後にＦＡＴとディレクトリの領域が設けられており、最後がデータ領域となっている。

図３５に示すように、連続領域として確保された仮想ＰＣシステムファイルは、その先頭の２バイトに、ＤＯＳブートの先頭位置までのオフセットが記録されている。また、オフセット０１ＢＦ以下に、開始ヘッド番号およびシリンダ・セクタ番号ＳＴとして、図３５に示した仮想ＰＣシステムファイル内のＤＯＳブート領域の先頭位置の情報が、オフセット０１Ｃ３以下に、終了ヘッド番号および終了シリンダ・セクタ番号ＥＤとして、ＤＯＳブート領域の終了位置の情報が、それぞれ記録されている。従って、ブート時には、このデータを用いてＤＯＳブート領域からの読み込みを開始することができる。ＤＯＳブート領域の内容を、図３６に詳細に示した。このＤＯＳブート領域には、この領域の基本的な情報が登録されており、オペレーティングシステムをブートする場合に用いられる。例えば、ブートインジケータには、このブート領域がアクティブか否かの情報が、またシステムインジケータには、このパーティションを使用しているオペレーティングシステムの種類（領域の休止／使用、ＯＳの種類、１２ビット／１６ビットセクタアクセス等のファイルシステム種類）が記録されている。ブートローダは、これらの情報を用いて、ハードディスク８４に確保された領域からデータを読み込むことでＤＯＳのブート（図３２ステップＳ６５０）を行なう。

次に、パーティションについて説明する。ＤＯＳは、接続されているハードディスク毎にドライブデータテーブルを用意しており、このデータは、所定のＢＩＯＳファンクションにより読み取ることができる。ハードディスク８４用のドライブデータテーブルの一例を、図３７に示した。図示するように、ドライブデータテーブルの先頭には、次のテーブルを示すポインタＰＮＴが置かれており、複数のハードディスクが接続されていたり、一つのハードディスクであっても複数のパーティションが設けられている場合には、その数だけの情報が、ポインタＰＮＴを介して並べられている。したがって、ＢＩＯＳのファンクションコールにより、ポインタを順次辿って行くことができ、総てのハードディスクのパーティション情報を読み取ることができる。ハードディスクエミュレータＨＤＭは、組み込み時の初期化の処理において、このドライブデータテーブルの情報を読み取り、ターゲットマシン用のパーティション情報（図２６，図２７参照）を作成し、ハードディスクエミュレータＨＤＭのディスク情報ブロック（図３４参照）のパーティション領域データに記憶する。

図３３に示した初期化の処理の詳細について、順次説明する。図３８に示したように、仮想ＰＣシステムファイル情報作成処理では、まず仮想ＰＣシステムファイルのパス名とファイル名を取得する処理を行なう（ステップＳ７０２）。これらのパス名とファイル名は、図３０に示したインストールの処理において作成される所定のデータファイルに書き込まれている。このファイルからパス名とファイル名を取得し、次に仮想ＰＣシステムファイルをアクセスし、ＤＯＳブート領域の情報を取得する処理を行なう（ステップＳ７０４）。ＤＯＳブート領域の開始アドレスＳＴ等は、オフセットのデータから求めても良いが、この実施例では直接取得可能に用意されていることは既に説明した。

更に、仮想ＰＣシステムファイルのパーティション情報（ＤＯＳ／Ｖ用）を取得する処理を行なう（ステップＳ７０６）。仮想ＰＣシステムファイルのＤＯＳブート領域には、この仮想ＰＣシステムファイル自身の情報があり、これを用いてパーティションの情報を作成することができる。但し、ここではＤＯＳ／Ｖ機のパーティション情報に合わせたフォーマットで作成する。即ち、仮想ＰＣシステムファイルに記録されているハードディスクのドライブ番号を取得し、ディスク情報ブロック（図３４参照）のオフセットテーブルデータに格納し、既述したシステムインジケータをＤＯＳブート領域から取得してディスク情報ブロックのパーティション領域データに格納する。更に、仮想ＰＣシステムファイルの開始アドレスＳＴ等もパーティション領域データに格納する。

こうして得られた仮想ＰＣシステムファイルのパーティション情報を次に仮想ＰＣ用のアドレスに変換する処理を行なう（ステップＳ７０８）。第１実施例で説明したように、ＤＯＳ／Ｖ機とＰＣ−９８００機では、ハードディスクの物理的なフォーマットの形式も異なっている。本実施例のエミュレーション装置は、ＤＯＳ／Ｖ機の上でＰＣ−９８００機の環境を実現するものなので、まずＤＯＳ／Ｖ機上でのパーティション情報を作成し、これを他のハードディスクのパーティション情報と共に、併せてターゲットマシンであるＰＣ−９８００機用のパーティション情報に変換するのである。変換したパーティション情報は、ディスク情報ブロックに格納される。

以上の処理を、仮想ＰＣシステムファイルの数だけ行ない（ステップＳ７１２）、総てのシステムファイルについて情報の取得・作成処理が完了すれば、「ＥＮＤ」に抜けて、本処理を終了する。通常、仮想ＰＣシステムファイルは、一つと考えられるが、複数のＰＣ−９８００機の環境を共存させることも可能である。こうした環境の一つとしては、例えばＰＣ−９８００機に用意されたディスクベーシックシステム等も含まれる。ディスクベーシックシステムは、ＭＳ−ＤＯＳに代えて、ＢＡＳＩＣプログラムを動作させる独自の環境が立ち上がるものである。この場合には、ファイルアクセスの単位である１セクタのバイト数もＭＳ−ＤＯＳとは異なる。したがって、ハードディスクエミュレータ内部で、一度に読み書きするバイト数を、ＢＡＳＩＣのシステムのバイト数に擬似的に合わせるエミュレーションを行なえば良い。

次に、図３９に拠ってパーティションの並び替え処理について説明する。複数のパーティションが存在する場合、ＤＯＳ／Ｖ機では、ＤＯＳが管理しているハードディスクについて、各パーティションの情報を格納したテーブルをポインタＰＮＴで繋いでいる。図４０に、この様子を例示する。ＭＳ−ＤＯＳでは、ハードディスクが複数のパーティションを持つ場合、少なくともその一つのパーティションにはシステムファイルが存在する必要がある。システムファイルが存在するパーティションを基本ＤＯＳ領域、存在しない領域を拡張ＤＯＳ領域と呼ぶ。ＤＯＳの起動時には、最初、基本ＤＯＳ領域が認識され、その後、拡張ＤＯＳ領域が認識される。従って、仮想ＰＣシステムファイルをハードディスクとして認識するハードディスクエミュレータＨＤＭでは、先頭（論理ドライブＡ：）をこの仮想ＰＣシステムファイルとすると、その後のパーティションの並びを、このＤＯＳ／Ｖ起動時の並びにするのが自然である。この様子を図４１に示した。同図（ａ）に示すように、例えば２台のハードディスク８４が接続されており、内部がそれぞれ２つにパーティションされており、更に１台目のハードディスクに仮想ＰＣシステムファイルが存在したとすると、同図（ｂ）に示したように、仮想ＰＣシステムファイル→基本ＤＯＳ領域→拡張ＤＯＳ領域の順にパーティションは配列されることになる。このように配列すれば、ＤＯＳ／Ｖ機を使用していたときのハードディスクの並び（ＤＯＳ／Ｖ機では、ハードディスクは論理ドライブＣ：から順に割り付けられる）とほぼ同一の並びとなり、ＤＯＳ／Ｖ機上で、ＰＣ−９８００機をエミュレートする使用者の違和感が小さくなる。

このようなパーティションの並び替えは、ハードディスクエミュレータＨＤＭの組み込み時に、パーティションの情報を読み取ることで容易に行なうことができる。ハードディスクにおけるパーティションの情報は、図３７に示したドライブデータデーブルを読み取ることで取得することができる。本実施例では、電源投入直後には、ＤＯＳ／Ｖ機として立ち上がり、そのＢＩＯＳを展開してから、デバイスドライバの組み込みの時点でエミュレーションに移行する。従って、タスクを切り替えてＤＯＳ／Ｖ機のＢＩＯＳのファンクションコールを使用可能とし、必要なＢＩＯＳファンクションを呼び出して、所望のデータを取得することができる。呼び出したＢＩＯＳファンクションにより得られたデータは、ＤＯＳ／Ｖ機のＢＩＯＳのタスクが管理するメモリ上に格納されるが、カーネルＫＲを介して、このデータを初期化の処理において読み取ることは容易である。ファンクションコールの一つを用いることで、ドライブデータテーブルを取得することができる。

本処理ルーチンが起動されると、図３９に示すように、ファンクションコールを利用して、まずパーティションが存在するハードディスクのドライブデータテーブルが存在するブロックを取得する（ステップＳ７２２）。次に、このドライブデータテーブルの内容から、ドライブ番号を読み取って、ディスク情報ブロックのオフセットデータテーブルに格納する（ステップＳ７２４）。次にハードディスクのパーティション情報を読み取り（ステップＳ７２６）、これを仮想ＰＣ用のパーティション情報に変換する。この変換は、パーティションの開始アドレス（シリンダ番号）をドライブデータテーブルに記録された絶対シリンダ番号から取得し、その開始アドレス（ヘッド番号：１，セクタ番号：１）を用いて、仮想ＰＣ用の開始アドレス（物理アドレス）に変換するのである。更に、ドライブデータテーブルに記録されたパーティションの総セクタ数を取得し、これを上記の開始アドレス（論理アドレス）に加算する。加算されたアドレスから、仮想ハードディスクの情報（ヘッド数、セクタ数）を用いて、ターゲットマシンであるＰＣ−９８００機の終了アドレス（物理アドレス）に変換する。

こうして変換されたアドレスとドライブデータテーブルから取得したその他の情報、例えばファイルシステムタイプなどを、ディスク情報ブロックのパーティション領域データに記憶する。その後、パーティション情報が残っている場合には（ステップＳ７３２）、テーブルの繋がりを示すポインタから次のドライブデータテーブルを検索し、同様にドライブデータテーブルの取得、パーティション情報の取得、パーティション情報の変換、パーティション情報の記憶の処理を繰り返す。

総てのパーティションについて、以上の処理が完了した場合には、仮想ＰＣシステムファイルのパーティション情報をハードディスクのパーティション情報の先頭に格納する処理を行なう（ステップＳ７３４）。この結果、図４１（ｂ）に示したように、仮想ＰＣシステムファイルを仮想的にハードディスクの一パーティションとみなして先頭に置き、ＤＯＳ／Ｖ機用のハードディスクのパーティションをその並びのままその後に続くパーティションとして並べた配列に、パーティションは並べ替えられたことになる。

次に、初期化処理（図３３）に示した仮想ハードディスク作成処理について説明する。この処理は、仮想ＰＣシステムファイルとして確保した領域を仮想ハードディスクとしてターゲットマシンに認識可能とする処理である。ここで仮想ハードディスクに関する情報としては、その最大容量が、エミュレーション装置の組み込み時に参照される情報ファイルに記録されている。最大容量の制限を加えるのは、オペレーティングシステムによっては、扱えるハードディスクの最大容量を制限しているものが存在するからである。また、仮想ハードディスクは、本実施例では、ＰＣ−９８００機をエミュレーションしていることから、１セクタ当たりのバイト数を５１２、１トラック当たりのセクタ数を１７、ヘッド数を８、最大接続台数を７としている。

図４２示した仮想ハードディスク作成処理ルーチンが起動されると、まず仮想ハードディスクの最大容量を、組み込み時に参照される情報ファイルを参照して取得する処理を行ない（ステップＳ７４２）、パーティション並び替え処理で記憶したディスク情報ブロックから仮想ＰＣ用のパーティション情報を読み出す処理を行なう（ステップＳ７４４）。このパーティション情報から、パーティションの容量を読み取り（ステップＳ７４６）、この容量が最大容量を超えているか判断する（ステップＳ７４８）。越えていない場合には、現在の仮想ハードディスクの情報に仮想ＰＣ用のパーティション情報をそのま格納する（ステップＳ７５０）。他方、パーティションの容量が、仮想ハードディスクの最大容量を超えている場合には、次の仮想ハードディスクのディスク情報に仮想ＰＣ用のパーティション情報を格納する（ステップＳ７５２）。以上の処理を、仮想ＰＣ用のパーティション情報がなくなるまで繰り返す（ステップＳ７５４）。

ここで言う仮想ハードディスク（仮想ＨＤＤ）とは、エミュレーションにより構築されるターゲットマシンから扱うことができる論理デバイスという意味である。したがって、図４１に示した例では、仮想ＰＣシステムファイルが１０Ｍパイト、基本ＤＯＳ領域〈１〉が１００Ｍパイト、基本ＤＯＳ領域〈２〉が６０Ｍバイト、拡張ＤＯＳ領域〈１〉が３０Ｍバイト、拡張ＤＯＳ領域〈２〉が１５Ｍバイト、仮想ハードディスクの最大容量が６０Ｍバイトと仮定すると、上記ステップＳ７４８ないしＳ７５２の判断および処理により、各領域は、図４３に示すように割り当てられる（なお、〈１〉〈２〉は図面においては丸付き数字を示す、以下本明細書において同じ）。まず、最初に仮想ＰＣシステムファイルが、１台目の仮想ハードディスクとして割り当てられる。次に、実際に接続されている１台目のハードディスクの基本ＤＯＳ領域が認識されるが、この領域は１００Ｍバイトあり、最大容量を超えるているので、２台目の仮想ハードディスクとして割り当てられる。更に、実際に接続されている２台目のハードディスクの基本ＤＯＳ領域が認識されるが、これは３台目の仮想ハードディスクとして割り当てられる。その次に、実際に接続されている１台目のハードディスクの拡張ＤＯＳ領域が認識され、４台目の仮想ハードディスクとして割り当てられる。最後に、実際に接続されている２台目のハードディスクの拡張ＤＯＳ領域が認識されるが、この領域を前の拡張ＤＯＳ領域に加えても最大容量を超えないので、この拡張ＤＯＳ領域は、先の領域に追加され、併せて４台目の仮想ハードディスクとして割り当てられる。

初期化処理の最後の処理はアドレスの調整（図３３ステップＳ７６０）とオフセットテーブルの作成（同ステップＳ７８０）である。図３９に示したパーティションの並び替え処理により並び替えられた各パーティションの開始アドレス（物理アドレス）は、ハードディスクの先頭から順に並んでいるとは限らない。また、パーティションの終了アドレス（物理アドレス）と次のパーティションの開始アドレス（物理アドレス）についても、ハードディスクの先頭から順に並んでいるとは限らない。そこで、各パーティションの開始アドレスがハードディスクの先頭から順に並ぶようにアドレスの調整を行ない、その後、オフセットテーブルを作成してディスク情報ブロックに格納する処理が必要となる。これらの処理を併せてオフセットテーブル作成処理と呼ぶことにし、その詳細を図４４に示した。

オフセットテーブル作成処理が開始されると、まず仮想ハードディスクの情報から仮想ＰＣ用にパーティション情報を読み出す処理を行なう（ステップＳ７８２）。次に、パーティション情報のアドレスを、ハードディスクの先頭から並ぶように変更する処理を行ない（ステップＳ７８４）、これらの処理を総てのパーティションについて実行する（ステップＳ７８６）。ここで、アドレスをハードディスクの先頭から並ぶように変更する処理は、実際には次のアドレス調整処理により実現されている。

アドレス調整処理−その１
ＤＯＳ／Ｖ機の場合、ハードディスクの先頭パーティションの開始アドレス（物理アドレス）はヘッド番号１，シリンダ番号０，セクタ番号１から始まっている。このＤＯＳ／Ｖ機での開始アドレス（物理アドレス）をターゲットマシンであるＰＣ−９８００機の物理アドレスに変換し、仮想ハードディスクの先頭パーティションの開始アドレス（物理アドレス）とする。得られたこの開始アドレス（物理アドレス）を論理アドレスに変換し、このパーティションの総セクタ数を加算する。即ち、論理アドレス上でパーティションの終了アドレスを求めるのである。この終了アドレス（論理アドレス）を仮想ハードディスクのヘッド数、セクタ数を用いて物理アドレスに変換し、そのパーティションの終了アドレス（物理アドレス）とする。次のパーティションの開始アドレスは、ヘッド番号１、セクタ番号１、シリンダ番号は一つ前のパーティションの終了アドレスのシリンダ番号Ｎに値１を加えたＮ＋１とする。

アドレス調整処理−その２
ターゲットマシンであるＰＣ−９８００機の場合、ハードディスクの最初のパーティションの開始アドレス（物理アドレス）は、ヘッド番号０、シリンダ番号１、セクタ番号０から始まっているので、この開始アドレス（物理アドレス）を仮想ハードディスクの先頭パーティションの開始アドレス（物理アドレス）とする。この開始アドレス（物理アドレス）を論理アドレスに変換し、これに総セクタ数を加算する。加算されたアドレス（論理アドレス）を仮想ハードディスクのヘッド数，セクタ数を用いて物理アドレスに変換し、これをパーティションの終了アドレス（物理アドレス）とする。次のパーティションの開始アドレスは、ヘッド番号０、セクタ番号０、シリンダ番号は一つ前のパーティションの終了アドレスのシリンダ番号Ｍに値１を加えたＭ＋１とする。

以上のアドレス変換を総てのパーティションについて行ない、更に総ての仮想ハードディスクについて行なう（ステップＳ７８８）。複数の仮想ハードディスクが接続されている場合には、各ハードディスクについては、ヘッド番号、シリンダ番号、セクタ番号は、初期値から再開される。

次に、オフセットテーブルの作成処理を行なう。まず、仮想ハードディスクの情報から、アドレス変更前と変更後の仮想ＰＣ用のパーティション情報を読み出し（ステップＳ７９０）、両アドレスの差を算出し、オフセットアドレスとして、これをディスク情報ブロックのオフセットテーブルデータに記憶する処理を行なう（ステップＳ７９２）。このオフセットアドレスを求める処理を総てのパーティションについて、更に総ての仮想ハードディスクについて繰り返す（ステップＳ７９４，７９６）。

このオフセットテーブルの作成の処理もアドレス調整と同様、詳細には、次のように行なわれる。
オフセットテーブル作成−その１
先にアドレス調整−その１でアドレス調整が行なわれた仮想ハードディスクのパーティションの開始アドレス（論理アドレス）とアドレス調整される前の仮想ハードディスクのパーティションの開始アドレス（論理アドレス）との差を求め、実際のハードディスクにおけるパーティションの開始アドレスからのオフセットＯＦＳ１として、オフセットテーブルデータに記憶する。なお、ハードディスクのドライブ番号の差については、仮想ＰＣシステムファイルの情報の取得（図３８）およびパーティションを並び替えた時点（図３９）でオフセットテーブルデータに記憶されている。

オフセットテーブル作成−その２
先にアドレス調整−その２で調整が行なわれた仮想ハードディスクのパーティションの開始アドレス（論理アドレス）とアドレス調整される前の仮想ハードデイスクのパーティションの開始アドレス（論理アドレス）との差を求め、実際のハードディスクにおけるパーティションの開始アドレスからのオフセットＯＦＳ２として、先にオフセットテーブルデータに記憶したオフセットＯＦＳ１に更に加算する（ＯＦＳ１＋ＯＦＳ２）。これが終的なオフセットＯＦＳとなる。なお、ドライブ番号についてのオフセットが既に記憶されている点は、上述の通りである。

以上のアドレス調整の様子を、仮想ＰＣシステムファイルを例にとって図４５に簡略に示した。実際のハードディスク８４を番号＃０として、その基本ＤＯＳ領域に仮想ＰＣシステムファイルを作成したとする。この仮想ＰＣシステムファイルは、仮想ＰＣ、即ちターゲットマシンでは、仮想ハードディスクとして扱われ、図４１に示したように、パーティションの先頭に配置される。そこで、番号＃１の仮想ハードディスクのオフセットテーブルには、仮想ＰＣシステムファイルの先頭から実際のハードディスク上のＤＯＳブート領域の先頭までのセクタ数が、オフセットアドレスとして記憶される。また、この仮想ＰＣシステムファイルによる仮想ハードディスクがディスク番号＃０に当たるとして、対応する番号８０Ｈが、オフセットテーブルに、同様に記憶されている。以下に説明するハードディスクへのアクセスは、このオフセットテーブルのデータを用いて行なわれることになる。

以上、本実施例におけるハードディスクエミュレータＨＤＭが組み込まれる際の処理について詳しく説明した。かかる処理により、ＤＯＳ／Ｖ機上で、ターゲットマシンとしてのＰＣ−９８００機のハードディスクアクセスをエミュレーションする準備が整ったことになる。ターゲットマシン用のシステムがブートされる仮想的なハードディスクは、ＤＯＳ／Ｖ機上では、連続した領域を有するファイルとして扱われており、これが仮想ＰＣシステムファイルとしてパーティションの情報に組み込まれ、先頭のパーティションとして、ターゲットマシンから認識およびアクセス可能となっている。また、ＤＯＳ／Ｖ機において接続されていたハードディスクおよびパーティションは、エミュレーションされたターゲットマシンであるＰＣ−９８００機から認識およびアクセス可能な仮想ハードディスクとして、ＤＯＳ／Ｖ機での並びと同じ並びとなっている。

最後に、エミュレートされたターゲットマシンであるＰＣ−９８００機からこれらのハードディスクにアクセスする場合に処理について説明する。この処理は、図４６のフローチャートに示したように、第１実施例における処理と類似の処理である（図２３参照）。ターゲットマシンにおいてハードディスクへのアクセスを行なおうとすると、そのＩ／Ｏアクセスにより処理はカーネルＫＲに移行し、ディスパッチャＤＰを介してハードディスクエミュレータＨＤＭが呼び出される。ハードディスクエミュレータＨＤＭは、図４６に示す処理を開始し、まずターゲットマシンにおけるハードディスクアクセスが、物理アドレスによるものか否かを判定する（ステップＳ８００）。物理アドレスによりアクセスの場合にはこれを論理アドレスに変換し（ステップＳ８０２）、続いてオフセットテーブルデータからオフセットアドレスとドライブ番号とを読み出す処理を行なう（ステップＳ８０４）。このオフセットアドレスをアクセスしようとした論理アドレスに加え（ステップＳ８０６）、更にドライブ番号も勘案して、ＤＯＳ／Ｖ機に実際に接続されているハードディスク８４の物理アドレスに変換する処理を行なう（ステップＳ８０８）。この物理アドレスを用いて、ＤＯＳ／Ｖ機のＢＩＯＳを呼び出し、ディスクアクセスを実行させる（ステップＳ８１０）。呼び出されるＤＯＳ／Ｖ機のＢＩＯＳは、仮想ＰＣ上で実行しようとしたＢＩＯＳと等価な機能を有するＢＩＯＳである。このＢＩＯＳは、ＣＰＵ２１のタスクをＤＯＳ／Ｖ機のＤＯＳのタスクに切り替えることにより実行される。

以下、データの読み出しの場合について説明すると、読み出したデータがシステム領域もしくはパーティション情報から読み出されたものか否かを判断し、システム領域またはパーティション情報から読み出しものであると判断された場合には、ＤＯＳ／Ｖ機のデータを読み出しても無意味であることから、仮想ＰＣ用のシステム領域またはパーティション情報を読み出して（ステップＳ８１４）、これを仮想ＰＣのメモリに書き込み処理を行なう（ステップＳ８２０）。また、変換して得られた物理アドレスによるデータの読み込みが、ＤＯＳのブート領域に当たっている場合にも（ステップＳ８１６）、そのまま読み込むのではなく、仮想ＰＣのＤＯＳブート領域の対応するデータを読み出し（ステップＳ８１８）、これを仮想ＰＣのメモリに書き込む（ステップＳ８２０）。これら以外の場合には、単なるデータであることから、ＤＯＳ／Ｖ機のＢＩＯＳの実行により得られたデータ（ステップＳ８１０）をそのまま仮想ＰＣのメモリに書き込むことになる（ステップＳ８２０）。

第一実施例で詳しく説明したように、読み出しの場合、実際にハードディスク８４からデータを読み出すのはＤＯＳ／Ｖ機のＢＩＯＳである。このＢＩＯＳの実行は、ＤＯＳ／Ｖ機のＤＯＳのタスク上で実行され、ハードディスクの該当セクタからデータが読み出され、バッファ上にロードされる。ステップＳ８２０では、このデータまたは仮想ＰＣ用のシステム領域またはパーティション情報あるいは仮想ＰＣ用のブート領域のデータを、仮想ＰＣ上のＢＩＯＳが管理しているバッファ領域に転送する。この結果、処理が、図２０に示したように、ハードディスクエミュレータＨＤＭから、仮想ＰＣ上のＢＩＯＳに戻ったとき、仮想ＰＣのタスクで実行されるＢＩＯＳは、自分が管理しているバッファ領域にハードディスクからデータを読み出したものとして、自分を呼びだしたアプリケーションプログラムに処理を戻すことになる。

以上説明した本実施例のエミュレーション装置によれば、実行マシンであるＤＯＳ／Ｖ機においてターゲットマシンであるＰＣ−９８００機のハードディスクのアクセスを、そのパーティションの違いなどを含めて完全にエミュレートすることができる。しかも、ＤＯＳ／Ｖ機のＢＩＯＳをそのまま利用し、ＤＯＳ／Ｖ機のファイルとしてターゲットマシン用のハードディスクの領域を確保する方式を採用したことから、ターゲットマシンのためのハードディスクを別に確保する必要がない。しかも、一旦実行マシンのＢＩＯＳを読み込んでから、ターゲットマシンの環境に移行し、実行マシンのＢＩＯＳおよびＤＯＳもタスクを切り替えることで実行可能であるため、ハードディスクアクセスのエミュレーションが容易になった。ＤＯＳ／Ｖ機のシステムファイルの名称などを書き換える必要がなく、システム運用の使い勝手、信頼性も向上する。

次に、本発明の第３，第４実施例について説明する。この実施例では、ＣＤ−ＲＯＭなどの周辺装置をエミュレートする構成を示す。周辺装置には、様々なものが存在するから、これをすべてエミュレーションできるように、予めエミュレータを用意することは極めて困難である。特に、ハードウェアに付属する専用のデバイスドライバを用いてアクセスするものでは、その内容をいちいち解析してエミュレータモジュールを用意することは困難である。そこで、基本構成として、図４７に示すように、ＣＰＵ２１に、実行マシンに接続された周辺機器用のデバイスドライバを実行可能に組み込む第１の組込手段ＫＫ１、実行マシン用のデバイスドライバを用いた周辺機器のアクセスに必要な第１のバッファＢＦ１、第１の組込手段ＫＫ１による組込の後で、ターゲットマシンに用意されたオペレーティングシステムを組み込むオペレーティングシステム組込手段ＫＯＳ、組み込まれたオペレーティングシステムに周辺機器用のターゲットマシンのデバイスドライバの少なくとも呼出側を実行可能に組み込む第２の組込手段ＫＫ２、ターゲットマシンのデバイスドライバを用いた周辺機器のアクセスに必要な第２のバッファＢＦ２、ターゲットマシンのデバイスドライバの呼出を取得し、実行マシンのデバイスドライバを起動して、周辺装置へのアクセスを実行させると共に、第１のバッファＢＦ１と第２のバッファＢＦ２との間でデータの転送を行なわせる転送手段ＴＲＳを、備える。

次に、これらの手段の具体的な構成について説明する。第３実施例では、図４８に示すように、周辺装置８５０をアクセスする構成において、実行マシンであるＤＯＳ／Ｖ機に用意され、その周辺装置を本来制御すべく用意されたデバイスドライバ８５２を一旦読み込んでから処理をターゲットマシンである仮想ＰＣ（ここではＰＣ−９８００機）に移行する第２実施例と同様の手法を適用する。エミュレーションにおいて実行マシンのデバイスドライバ８５２をそのまま利用するのである。ＤＯＳ／Ｖ機のデバイスドライバ８５２が組み込まれた後で、エミュレーションのための初期化の処理に移行し（図３２参照）、その後、仮想ＰＣとしてブートして、ＤＯＳを立ち上げる。この過程で、周辺装置８５０用として、オペレーティングシステムを介して呼び出される仮想のデバイスドライバ８６０を用意し、これを組み込む。

この仮想のデバイスドライバ８６０は、仮想ＰＣが、周辺装置８５０をアクセスするとき、呼び出すものであり、アプリケーションプログラムＡＰＰ側から呼び出された時、一般保護例外のトラップを起こすよう構成すれば足りる。いわば、呼出側の入り口の機能さえ用意しておけば足りるのである。仮想のデバイスドライバ８６０が呼び出されると、一般保護例外のトラップが生じ、カーネルＫＲがこれをフックしてエミュレーション装置に制御を移行する。カーネルＫＲは、ブリッジシステムＢＳを介して、メモリ上のリアル空間に呼び出される処理が実行マシンのデバイスドライバ８５２、ＢＩＯＳとなるようタスクを切り替え、実行マシン用に用意されたデバイスドライバ８５２をそのまま利用して処理を行なう。

周辺装置８５０が単純なアクチュエータなどである場合には、デバイスドライバ８５２を介して周辺装置８５０に所定の信号を出力した後、処理を、上述した流れを逆に辿って、アプリケーションプログラムＡＰＰに返せば良い。この結果、ＤＯＳ／Ｖ機側では、周辺装置８５０用のデバイスドライバをそのまま流用することができ、製品の開発、製造が極めて容易となった。したがって、エミュレーション装置の全体構成、見通しも極めて良好である。

次に、この第３実施例の構成・手法を、特にＣＤ−ＲＯＭに適用した構成を取り上げ、説明する。図４９は、周辺装置としてＣＤ−ＲＯＭ８７０を実行マシンであるＤＯＳ／Ｖ機（図２参照）に接続した場合に、仮想ＰＣ（実施例ではＰＣ−９８００機）からこれをアクセスする構成を示すブロック図である。このＣＤ−ＲＯＭ８７０用に、ＤＯＳ／Ｖ機では、専用のデバイスドライバ８７２が用意されている。このデバイスドライバ８７２は、ＤＯＳ／Ｖ機においてＤＯＳを立ち上げる過程で、ＤＯＳ／Ｖ機のＤＯＳを専用のメモリ空間に展開した後、システムファイル「ｃｏｎｆｉｇ．ｓｙｓ」の記述に従い、組み込まれる。このデバイスドライバ８７２には、ＣＤ−ＲＯＭ８７０から読み出したデータを記憶する第１バッファ８７４が必要となるが、この第１バッファ８７４は、ＤＯＳ／Ｖ機のＢＩＯＳの展開後に行なわれるエミュレーション装置の組込時（詳しくはブリッジシステムＢＳの組込時）に、ＤＯＳ／Ｖ機のＤＯＳのタスク空間の一部に固定的に確保される。ブリッジシステムＢＳが、ＤＯＳ／Ｖ機のデバイスドライバ８７２を呼び出すとき、第１バッファ８７４の位置を、デバイスドライバ８７２に教える。バッファ８７４の容量は、通常固定的に確保されるが、エミュレーション装置のオプションスイッチにより指定する構成とすることもできる。データの受け渡しのためのバッファを、デバイスドライバを呼び出す側が確保することは、周知の手法である。

ＣＤ−ＲＯＭ用のデバイスドライバ８７２など必要なデバイスドライバを組み込んだ後、図３２に示したように、エミュレータの構築が行なわれる。その構築の手法については、詳しく説明したので繰り返さないが、本実施例では、カーネルＫＲ，ディスパッチャＤＰを組み込んだ後、他のエミュレーションモジュール群と共にブリッジシステムＢＳというエミュレータが組み込まれる。このブリッジステムは、第３実施例で説明したように、仮想ＰＣのデバイスドライバと実行マシンであるＤＯＳ／Ｖ機のデバイスドライバとを繋ぐものである。その機能については、後述する。

エミュレータの構築の後、仮想ＰＣ側のＢＩＯＳを展開し、第２実施例で詳しく説明したように、ＤＯＳ／Ｖ機のハードディスク８４内に連続した領域として確保された仮想システムファイルなどをアクセスし、初期化の処理を実行し、その後、仮想システムファイルのブート領域からデータを読み出して、ターゲットマシンであるＰＣ−９８００機としてのブートを実行する。この結果、図４９に示したように、仮想ＰＣのＤＯＳが、仮想ＰＣ用のメモリ空間に展開され、更に種々のデバイスドライバが組み込まれる。こうして組み込まれるデバイスドライバの一つとして、ＣＤ−ＲＯＭのアクセスを担当する仮想デバイスドライバ８８０も組み込まれる。また、ＭＳ−ＤＯＳでは、ＣＤ−ＲＯＭをアクセスするためのデバイスドライバとＤＯＳとのインタフェースを定義したＭＳＣＤＥＸ８８２というモジュールも組み込まれる。アプリケーションプログラムＡＰＰは、このＭＳＣＤＥＸ８８２を介してＣＤ−ＲＯＭをアクセスしても良いし、直接仮想デバイスドライバ８８０をアクセスしても差し支えない。仮想デバイスドライバ８８０は、ＭＳＣＤＥＸ８８２が定める入出力を用意しているので、この入出力をアプリケーションプログラムＡＰＰからアクセスすることは容易である。なお、仮想デバイスドライバ８８０とのデータのやり取りに必要な第２バッファ８８４は、仮想デバイスドライバ８８０を呼び出す側（ここではアプリケーションプログラムＡＰＰ）が、仮想ＰＣのメモリ空間に動的に確保する。アプリケーションプログラムＡＰＰは、ＣＤ−ＲＯＭをアクセスしようとすると、メモリ空間に第２バッファ８８４を確保した後、その位置を仮想デバイスドライバ８８０に連絡する。

以上の組み込み作業やバッファの確保などを行なった後、仮想ＰＣは、アプリケーションプログラムＡＰＰを実行可能な状態となる。この状態で、アプリケーションプログラムＡＰＰからＣＤ−ＲＯＭ８７０をアクセスする場合の各部の動作について説明する。アプリケーションプログラムＡＰＰがＭＳＣＤＥＸ８８２を介して、あるいは直接にＣＤ−ＲＯＭ８７０からデータを読み出す処理を呼び出すと、仮想デバイスドライバ８８０は、この呼出を受けて、「ＨＡＬＴ」命令などの特権命令を実行する。仮想ＰＣは、プロテクトモードで動作しており、かかる特権命令の実行は、カーネルＫＲによりトラップされる。カーネルＫＲは、システムの状態をチェックしてトラップの要因を特定し、この場合には、ディスパッチャＤＰを介してブリッジシステムＢＳを呼び出す。ブリッジシステムＢＳは、変換部８９０と転送部８９２とを備える。変換部８９０は、仮想ＰＣとＤＯＳ／Ｖ機とでＣＤ−ＲＯＭのアドレスの指定の方法が異なる場合にアドレス変換を行ない、更に仮想ＰＣからの命令についてもＤＯＳ／Ｖ機のＣＤ−ＲＯＭ８７０に対する命令に変換する処理を行なう。転送部８９２は、後述する第１バッファ８７４から第２バッファ８８４へのデータ転送を制御するものである。

ブリッジシステムＢＳは、ＣＰＵ２１の実行するタスクをＤＯＳ／Ｖ機のタスクに切り替えると共に、変換されたアドレスと命令を、ＤＯＳ／Ｖ用に用意されたデバイスドライバ８７２に引き渡す。デバイスドライバ８７２は、このアドレスと命令により、ＣＤ−ＲＯＭ８７０にアクセスする。このデバイスドライバ８７２は、ＤＯＳ／Ｖ機用のＣＤ−ＲＯＭ特有のハードウェア（モータ、ヘッドの仕様等）を考慮して作られているから、ＣＤ−ＲＯＭ８７０を正しくアクセスし、必要なデータをＤＯＳ／Ｖ機のタスク内の第１バッファ８７４に格納する。これはＤＯＳ／Ｖ用デバイスドライバが自分が動作しているタスク内にバッファを持つものとして作られているからである。

以上の処理の後、ＣＤ−ＲＯＭデバイスドライバ８７２は、処理をカーネルＫＲに戻す。カーネルＫＲはタスクをエミュレータ管理下（プロテクトモード）に戻し、ブリッジシステムＢＳを呼び出す。ブリッジシステムＢＳでは、その転送部８９２が処理の戻りを判別し、第１バッファ８７４のデータを第２バッファ８８４に転送する処理を行なう。第２バッファ８８４は、仮想ＰＣのタスク内のメモリ領域である。バッファ８７４，８８４間のデータの転送は、第１バッファ８７４のデータを一旦ブリッジシステムＢＳが吸い上げ、これを第２バッファ８８４に書き出すことにより行なわれる。この後、処理は、ブリッジシステムＢＳからディスパッチャＤＰ，カーネルＫＲを介して、仮想デバイスドライバ８８０へと戻って行くが、仮想ＰＣ側が予定しているデータ量（第２バッファ８８４に用意されるべきデータ量）とＣＤ−ＲＯＭデバイスドライバ８７２が読み出して第１バッファ８７４に用意したデータ量とが異なる場合には、次のように処理が行なわれる。

仮想ＰＣが予定しているデータ量より、第１バッファ８７４に用意されるデータ量が少ない場合には、ブリッジシステムＢＳの転送部８９２は、仮想ＰＣが予定しているデータ量となるまで、ＣＤ−ＲＯＭデバイスドライバ８７２に処理を戻し、第１バッファ８７４から第２バッファ８８４へのデータ転送を繰り返す。第２バッファ８８４に必要なデータが用意されてから、ブリッジシステムＢＳは、処理をディスパッチャＤＰに戻すことになる。なお、この機能を積極的に利用して、ＤＯＳ／Ｖ機側で一回に読み込むデータ量を小さくして、第１バッファ８７４の容量を小さくすることも可能である。

他方、仮想ＰＣが予定しているデータ量より第１バッファ８７４に用意されるデータ量の方が大きい場合には、ブリッジシステムＢＳの転送部８９２は、第１バッファ８７４の一部のみ第２バッファ８８４に転送する。仮想ＰＣ側からのＣＤ−ＲＯＭ８７０に対するアクセスが連続セクタリード命令等の場合は、ブリッジシステムＢＳは、２回目以降のセクタリードに対しては、第１バッファ８７４にデータが残っている限りは、ＣＤ−ＲＯＭデバイスドライバ８７２を呼び出すことなく、直ちに転送部８９２を起動して、第１バッファ８７４の残余のデータを、第２バッファ８８４に転送する。この場合には、ＣＤ−ＲＯＭ８７０のアクセス回数を減らすことができるので、データ転送の速度を上げることができる。

処理がディスパッチャＤＰからカーネルＫＲを介して、仮想ＰＣ側で実行されているアプリケーションプログラムＡＰＰに戻ると、アプリケーションプログラムＡＰＰは、第２バッファ８８４をアクセスして所望のデータを読み取ることができる。なお、本実施例の場合、ＣＤ−ＲＯＭ８７０をアクセスするエミュレータの全体は、仮想ＰＣ上のＤＯＳとのインタフェースを司るＭＳＣＤＥＸ８８２と、ハードウェアとの接点であるＤＯＳ／Ｖ用デバイスドライバとの間にブリッジシステムを設けた構成となっている。ＭＳＣＤＥＸ８８２とＣＤ−ＲＯＭデバイスドライバ８７２とのインタフェースは共通化が図られている。この位置に仮想デバイスドライバ８８０を組み込んでいるのでＤＯＳあるいはハードウェアが変更されても仮想デバイスドライバ８８０を継続使用することが可能になっている。

以上説明した実施例では、周辺装置がＣＤ−ＲＯＭ８７０のようにデータの転送を必要とするものである場合に、各デバイスドライバが実行されるタスク内に用意されたバッファにデータを読み書きし、これをブリッジシステムＢＳにより転送しており、データ転送を伴う周辺装置のエミュレーションを極めて容易に実現することができる。

上記実施例では、ＤＯＳ／Ｖ機上でＰＣ−９８００機を実現する構成を例に挙げて説明したが、ＰＣ−９８００機上でＤＯＳ／Ｖ機を実現することも容易である。またＤＯＳ／Ｖ機はＩＢＭ−ＡＴ互換機と読み替えてもよい。更に、他のアーキテクチャに適用することも可能である。また、図１に示した実行モジュールの分け方は一例に過ぎず、モジュールを更に細分したり、併合したりすることも可能である。

本発明の一実施例であるエミュレーション装置の概略構成を示すブロック図である。 実行マシンであるＤＯＳ／Ｖ機の概略構成図である。 タスクアドレスと物理メモリとの関係を示す説明図である。 実行モードとその切り換えの関係を示す説明図である。 ＤＯＳ／Ｖ機が立ち上がった直後のメモリマップおよびＩ／Ｏマップを示す説明図である。 エミュレータ装置の初期化処理ルーチンを示すフローチャートである。 初期化の処理の様子を示す説明図である。 ＤＯＳ／Ｖ機の割込関係の回路を示すブロック図である。 実行モジュールを組み込む際の処理ルーチンを示すフローチャートである。 ディスパッチャ呼出ルーチンを示すフローチャートである。 エントリポイント取得ルーチンを示すフローチャートである。 実行モジュールの組み込み時における呼出アドレスの登録の様子を示す説明図である。 実行モジュールがその登録時に他の実行モジュールを呼び出す様子を示す説明図である。 実行モジュール間の直接呼出（モジュール間通信）の様子を示す説明図である。 ＤＯＳ／Ｖ機におけるキーボード周りの回路を示すブロック図である。 ＰＣ−９８００機におけるーボード周りの回路を示すブロック図である。 実施例のエミュレーション装置において、キーボードからの入力をエミュレートする様子を示す説明図である。 同じくキーボードからの入力のエミュレーションの後半の様子を示す説明図である。 ハードディスクの物理的構造図である。 本実施例のエミュレーション装置において、ハードディスクへの読み込みをエミュレートする様子を示す説明図である。 ハードディスクへの読み込みをエミュレートするハードディスクエミュレータの構成図である。 ハードディスクの初期化を示すフローチャートである。 ハードディスクへの読み込みを示すフローチャートである。 ＤＯＳ／Ｖ機におけるパーティション領域のマップを示す説明図である。 ＤＯＳ／Ｖ機におけるハードディスクのマップを示す説明図である。 ＰＣ−９８００機におけるパーティション領域のマップを示す説明図である。 ＰＣ−９８００機におけるハードディスクのマップを示す説明図である。 ＰＣ−９８００機におけるシステム領域のマップを示す説明図である。 ＰＣ−９８００機におけるＤＯＳブート領域のマップを示す説明図である。 エミュレーション用のシステムをインストールするための処理ルーチンを示すフローチャートである。 インストール処理おける設定画面を例示する説明図である。 エミュレーション装置における電源投入時のシーケンスを示すフローチャートである。 初期化の処理の概要を示すフローチャートである。 ハードディスクエミュレータＨＤＭの概略構成を示す説明図である。 仮想ＰＣシステムファイルの構成を例示する説明図である。 仮想ＰＣシステムファイルのＤＯＳブート領域の構成を例示する説明図である。 ドライブデータテーブルに一例を示す説明図である。 仮想ＰＣシステムファイル情報作成処理を示すフローチャートである。 パーティションの並び替え処理を示すフローチャートである。 パーティションの並びをポインタＰＮＴで参照する様子を示す説明図である。 ハードディスクの各領域を並び替える様子を示す説明図である。 仮想ハードディスクの作成処理を示すフローチャートである。 仮想ハードディスクの作成の様子を示す説明図である。 オフセットテーブル作成処理を示すフローチャートである。 オフセットデータを用いたアクセスの様子を簡略に示す説明図である。 ハードディスクのアクセスの様子を読み込み処理により示すフローチャートである。 第３，第４実施例に相当する基本構成を示す説明図である。 本発明の第３実施例として、周辺機器のアクセスをエミュレートする構成を示すブロック図である。 本発明の第４実施例として、ＣＤ−ＲＯＭ８７０のアクセスをエミュレートする構成を示すブロック図である。

符号の説明

２０…演算処理部
２１…ＣＰＵ
２２…ローカルバス
２３…キャッシュメモリ
２４…キャッシュコントローラ
２５…メインメモリ
３０…ＰＣＩブリッジ
３２…ＰＣＩバス
４０…コントローラ部
４２…ＩＳＡバス
４４…ＶＧＡ
４６…ＳＣＳＩコントローラ
４８…ＰＣＩ−ＩＳＡブリッジ
５０…ＤＭＡコントローラ
５２…リアルタイムクロック
５４…複合Ｉ／Ｏポート
５６…サウンドＩ／Ｏ
６０…Ｉ／Ｏ部
６２…拡張スロット
６４…ＫＥＹ
６６…ＰＩＣ
６８…タイマ
７２…キーボード
７３…マウス
７４…スピーカ
７６…ＣＲＴ
８２…フロッピディスク装置
８４…ハードディスク
８６…パラレルポート
８８…プリンタ
９０…シリアルポート
９２…モデム
９６…マイクロフォン
８５０…周辺装置
８５２…デバイスドライバ
８６０…デバイスドライバ
８７０…ＣＤ−ＲＯＭＲＯＭ
８７２…ＣＤ−ＲＯＭデバイスドライバ
８７４…第１バッファ
８８０…仮想デバイスドライバ
８８２…ＭＳＣＤＥＸ
８８４…第２バッファ
８９０…変換部
８９２…転送部
ＡＰＰ…アプリケーションプログラム
Ａｎ…呼出アドレス
ＢＦ１…第１のバッファ
ＢＦ２…第２のバッファ
ＢＳ…ブリッジシステム
ＣＦＭ…文字フォントエミュレータ
ＤＥＭ…表示エミュレータ
ＤＭｎ…実行モジュール
ＤＰ…ディスパッチャ
ＤＴ…ディスパッチャテーブル
ＧＥＭ…グラフィックエミュレータ
ＩＲＭ…割込コントローラエミュレータ
ＨＤＭ…ハードディスクエミュレータ
ＫＥＭ…キーボードエミュレータ
ＫＫ１…第１の組込手段
ＫＫ２…第２の組込手段
ＫＯＳ…オペレーティングシステム組込手段
ＫＲ…カーネル
ＭＥＭ…メモリエミュレータ
ＭＵＭ…マウスエミュレータ
ＴＥＭ…テキストエミュレータ
ＴＩＭ…タイマエミュレータ
ＴＲＳ…転送手段
ＶＳＦ…仮想システムファイル領域確保部

Claims (9)

1. 少なくとも演算処理部、記憶部、入出力部およびハードディスクを備えたコンピュータである実行マシン上で、所定バイト数のデータを単位とし、該単位のデータを前記ハードディスクにおいて、トラック、セクタを用いて管理するディスクシステムを用い、該ハードディスクから、前記実行マシンとは、データの入出力用の手続を定義したＢＩＯＳおよびディスクシステムを用いてデータの処理を行なう点で共通するオペレーティングシステムをロードして、前記実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
   前記実行マシンの起動時に、少なくとも二つのタスクが実行できる論理空間を前記実行マシンに確保するタスク管理手段と、
   該確保された論理空間に、前記実行マシン用に用意されたＢＩＯＳをロードし、実行可能な状態に展開する実行マシンＢＩＯＳ展開手段と、
   前記実行マシン用のＢＩＯＳが実行可能に展開された前記一つの論理空間に、該展開された実行マシン用のＢＩＯＳを呼び出す所定のファンクションコールを実現するプログラムを実行可能に読み込む実行マシン処理プログラム読込手段と、
   前記確保された他の論理空間に、前記ターゲットマシン用に用意されたＢＩＯＳをロードし、所定のファンクションコールを利用して実行可能な状態に展開するターゲットマシンＢＩＯＳ展開手段と、
   前記ターゲットマシン用のＢＩＯＳが実行可能に展開された前記他の論理空間に、該展開されたターゲットマシン用のＢＩＯＳを呼び出す該ターゲットマシンの前記ファンクションコールに対応したアプリケーションプログラムを読み込むターゲットマシンプログラム読込手段と
   該展開されたターゲットマシン用のＢＩＯＳが前記アプリケーションプログラムから前記システムコールを用いて呼び出されたとき、この呼出を取得して、該呼び出されたＢＩＯＳと等価な機能を有する前記実行マシン用のＢＩＯＳを呼び出す呼出手段と
   を備えたエミュレーション装置。
2. 請求項１記載のエミュレーション装置であって、
   前記実行マシンに接続されたハードディスクの記憶領域を検索し、該ハードディスク上に連続して存在する所定の大きさの領域を確保し、該領域を該ターゲットマシンの仮想的なハードディスクとして扱う仮想ディスク確保手段を備えたエミュレーション装置。
3. 請求項１記載のエミュレーション装置であって、
   前記ターゲットマシンプログラム読込手段によりファンクションコールに対応したプログラムの読み込みの後に、該ターゲットマシン用のオペレーティングシステム用に用意されたファイルを読み出すオペレーティングシステム読出手段と、
   該読み出したファイルに含まれるオペレーティングシステム用のプログラムを、前記他の論理空間にロードし、該オペレーティングシステム用のプログラムから前記ターゲットマシン用のＢＩＯＳおよびディスクシステムをファンクションコールを用いて呼び出し可能に関連づけることにより、、前記実行マシンに、前記ターゲットマシン用のオペレーティングシステムを構築するシステム構築手段と
   を備えたエミュレーション装置。
4. 少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
   前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込む第１の組込手段と、
   該第１の組込手段による前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込むオペレーティングシステム組込手段と、
   該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込む第２の組込手段と、
   前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させる起動手段と
   を備えたエミュレーション装置。
5. 少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション装置であって、
   前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込む第１の組込手段と、
   該実行マシン用のデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りする際に用いる第１のバッファと、
   該第１の組込手段による前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込むオペレーティングシステム組込手段と、
   該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込む第２の組込手段と、
   該ターゲットマシンのデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りするのに用いる第２のバッファと、
   前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させると共に、前記第１のバッファと前記第２のバッファとの間で、前記周辺装置との間でやり取りするデータの転送を行なわせる転送手段と
   を備えたエミュレーション装置。
6. 請求項５記載のエミュレーション装置であって、
   前記転送手段は、前記実行マシン用の前記デバイスドライバが実行される際に一度に扱う前記第１のバッファのデータ量と前記ターゲットマシン用の前記デバイスドライバが実行される際に一度に扱う前記第２のバッファのデータ量との差異に基づいて、両バッファ間で前記差異を解消する回数のデータ転送を行なう手段であるエミュレーション装置。
7. 少なくとも演算処理部、記憶部、入出力部およびハードディスクを備えたコンピュータである実行マシン上で、所定バイト数のデータを単位とし、該単位のデータを前記ハードディスクにおいて、トラック、セクタを用いて管理するディスクシステムを用い、該ハードディスクから、前記実行マシンとは、データの入出力用の手続を定義したＢＩＯＳおよびディスクシステムを用いてデータの処理を行なう点で共通するオペレーティングシステムをロードして、前記実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
   前記実行マシンの起動時に、少なくとも二つのタスクが実行できる論理空間を前記実行マシンに確保し、
   該確保された一つの論理空間に、前記実行マシン用に用意されたＢＩＯＳをロードし、実行可能な状態に展開し、
   前記実行マシン用のＢＩＯＳが実行可能に展開された前記一つの論理空間に、該展開された実行マシン用のＢＩＯＳを呼び出す所定のファンクションコールを実現するプログラムを実行可能に読み込み、
   前記確保された他の論理空間に、前記ターゲットマシン用に用意されたＢＩＯＳをロードし、所定のファンクションコールを利用して実行可能な状態に展開し、
   前記ターゲットマシン用のＢＩＯＳが実行可能に展開された前記他の論理空間に、該展開されたターゲットマシン用のＢＩＯＳを呼び出す該ターゲットマシンの前記ファンクションコールに対応したアプリケーションプログラムを読み込み、
   該展開されたターゲットマシン用のＢＩＯＳが前記アプリケーションプログラムから前記システムコールを用いて呼び出されたとき、この呼出を取得して、該呼び出されたＢＩＯＳと等価な機能を有する前記実行マシン用のＢＩＯＳを呼び出す
   エミュレーション方法。
8. 少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するにデバイスドライバを組み込んで動作する周辺装置を備えた実行マシン上で、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
   前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込み、
   該デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込み、
   該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込み、
   前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させる
   エミュレーション方法。
9. 少なくとも演算処理部、記憶部、入出力部を備えたコンピュータであり、該コンピュータに用意されたオペレーティングシステムのメモリ空間に周辺装置を利用するためのプログラムであるデバイスドライバを実行可能にロードすることで前記周辺装置を利用可能とする実行マシン上で、前記周辺装置を利用するためにオペレーティングシステムから呼び出されるデバイスドライバを利用する点では共通するオペレーティングシステムをロードして、実行マシンのアーキテクチャとは異なるアーキテクチャを備えたコンピュータであるターゲットマシン用のプログラムを実行させるエミュレーション方法であって、
   前記実行マシンに接続された前記周辺機器用のデバイスドライバを、メモリ空間にロードし、前記実行マシンの前記オペレーティングシステムから呼び出せるよう関連付けることで、該デバイスドライバを実行可能な状態に組み込み、
   該実行マシン用のデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りする際に用いる第１のバッファを用意し、
   前記デバイスドライバの組込の後で、前記ターゲットマシンに用意されたオペレーティングシステムを、前記メモリ空間にロードして、実行可能な状態に組み込み、
   該ターゲットマシン用のオペレーティングシステムに、前記周辺機器用の該ターゲットマシン上で動作可能に作られたデバイスドライバを少なくとも前記オペレーティングシステムから呼び出せるように関連付けることで、該ターゲットマシン用のデバイスドライバを呼び出す処理を実行可能に組み込み、
   該ターゲットマシンのデバイスドライバが実行される際に、該デバイスドライバが前記周辺機器との間でデータをやり取りするのに用いる第２のバッファを用意し、
   前記ターゲットマシンのデバイスドライバを呼び出す前記処理の実行を検出し、前記実行マシンのデバイスドライバを起動して、前記周辺装置へのアクセスを実行させると共に、第１のバッファと前記第２のバッファとの間で、前記周辺装置との間でやり取りするデータの転送を行なわせる
   エミュレーション方法。

Images