はじめに
前回は、MOディスク・ドライブが復活し、そこからプレインストールのMS-DOS 5.0A-HとWindows 3.1を書き戻すことができたところまで作業を進めることができました。
今回は各種バックアップから過去のMS-DOS環境を取り戻してみたいと思います。
関連記事
- 旧世代のPC-9800シリーズを復活させる私的プロジェクト 第4回
MOディスク・ドライブにバックアップしたMS-DOSおよびWindows 3.1を新たなストレージに書き戻してみたり、既存のSCSI HDDにインストール済みのWindows 95やWindows NT 4.0 Workstationの起動を試みたりしてみます。 - 旧世代のPC-9800シリーズを復活させる私的プロジェクト 第3回
手持ちのUltra 2 Wide SCSIのHDDを使用することをあきらめ、コンパクト・フラッシュを使用してみました。 - 旧世代のPC-9800シリーズを復活させる私的プロジェクト 第2回
PC-9821Xt/C10Wをチェックしたところ、HDDのSCSI ID-0のものが動作していないことが確認でき、代替HDDとしてSCA-80コネクター採用のUltra 2 Wide SCSI HDDを代替ストレージとしてしようとしましたが…。 - 旧世代のPC-9800シリーズを復活させる私的プロジェクト 第1回
手持ちのPC-9800シリーズ各種が動作するかどうかのチェックを行いました。
最新のバックアップを探す
初期環境のバックアップ以外にもいろいろな手段でバックアップを作っていました。例えば、先日発掘したCD-Rメディアへのバックアップもそのうちの1つです。
さらに、前回MOディスク・ドライブが復活したことで、開発環境を1998年当時※1にバックアップしたものも見つかりました。
両者のバックアップを比較したところ、後者の方が新しいことがわかりました。しかし、最新ではないことが判明しています。というのも、一部の公開済みツールのソースのバージョンが古いことが判明しているからです。
1998年～1999年のどこかあたりで、自宅にファイル・サーバーを作成しており、この中にせっせと自作プログラムやデータなどを保存していました。それがおそらく最新だと思われます。
というわけで、開発環境はMOディスクから、自作プログラムとデータはファイル・サーバーから書き戻して復活させることにします。
まず、開発環境ですが、当時はプレインストールのMS-DOS 5.0A-Hではなく、MS-DOS 6.20を使用していました。これを書き戻す必要があります。MOディスクはバックアップ目的で作成したことからブート可能ではありません。はたしてMS-DOS 5.0A-Hから起動して書き戻すことができるのか、と、やや不安に思いながら該当MOディスクをカレント・ディレクトリーに設定したのちに、MS-DOS 5.0A-HのSYS.EXEコマンドを使用してシステムの転送を試みたところ、あっさりと終了しました。
続いてその他のMS-DOS関連ファイルと開発環境、その他ファイルを含めてMOディスクから新ストレージにMS-DOS 5.0A-HのXCOPY.EXEコマンドで書き戻します。※2今回はファイルが多いのでやや時間がかかりましたが、無事コピーが完了しました。そしてCOMMAND.COMがMS-DOS 6.20のものに上書きされているためロードに失敗し、エラーが表示されました。※3
これでいったんリセット・ボタンを押して再起動してみます。新しいMS-DOSがこれで起動するだろうか、と、若干不安に思いながらHDDメニューから起動してみると、問題なく起動し、懐かしいブート・メッセージが流れて行き、環境設定がなされました。
何が懐かしいって…。30行BIOSと90桁BIOSなどが返ってきました 🙂 ほかにも、高速リブートのHSB※4とか、ファイラーのSuperView※5とか、テキスト・エディター兼MS-DOS拡張環境のVZ Editor※6とか、メモリー・マネージャーのVEM486※7とかとか。書ききれないほどのソフトウェアが返ってきたのです。何もかもが本当に懐かしいです。
この環境に自作プログラムとデータを書き戻すのですが、直接Windows 95やWindows NT 4.0 WorkstationからMS-DOSのパーティションへ書き込むのはいろいろな意味で危険なので、まずはWindows 95を起動して、Windows 95によってMS-DOSからも読めるWindows 95のパーティションにコピーを行い、再起動してMS-DOS 6.20に切り替えてからMS-DOSのパーティション内にコピーを行いました。
なぜこのような遠回りをするか、ですが、それは長いファイル名（Long File Name）にあります。Windows 95と統合されたMS-DOS 7.0より前のMS-DOSではこの長いファイル名に対応していません。読み出し互換性はありますが、削除やリネームには対応していませんし、一部のMS-DOS用ユーティリティの動作や表示の障害の原因にもなります。そんなわけで、MS-DOS用のパーティションにLong File Nameを持ち込まないために、いったんWindows 95のパーティションにコピーし、そこからMS-DOSのコマンドでコピーをしたわけです。
これで、当面困ることがない程度に整備されたMS-DOS環境が戻ってきました。
30行BIOS/90桁BIOS
私がPC-9800シリーズについて書く時点で避けて通れないのが30行BIOSと90桁BIOS関連に関する言及かと思います。というわけで、この新たな環境でもさっそくテストをしてみました。
環境
| 項目 | 内容 |
|---|---|
| 本体 | NEC PC-9821Xt/C10W 起動時に Grphキーと2キーを押した31kHzモード、GGDCは5.0MHz設定。 |
| ディスプレイ | アイ・オー・データ機器 LCD-AD191SEB |
| 30行BIOS | Ver 1.41 標準版 |
| 90桁BIOS | Ver 0.01 マルチスキャン・モードを使用。 |
検証
以前、三菱電機のRD17GII※8では、80桁×31行を拡張状態の標準として使用していました。まずはこのままの設定でモードを切り替えたところ、ディスプレイは720×480モードとして認識して追従しました。若干調整をしてみたのですが、31行目が表示できないことがわかりました：
いろいろと調整していて判断したのですが、この「720×480」というのはディスプレイが該当するアナログ接続のディスプレイ信号を内部のバッファにデジタル・データとして展開する際の解像度を示しているようです。したがって、31行という表示は496ドットとなってしまい、480ドットを超えた1行分が表示できないのではないかと思われます。
というわけで、まずは行数を素直に30行に設定しました：
これによってファンクションキーの表示がされるようになりました。
続いて桁数です。90桁は正しく表示できたので、どこまでいけるか、ということで2桁ずつ※9増やしていったところ、思いのほかディスプレイは周波数変動に追従し、私自身がリミッターとして設定している100桁に到達しました。設定を詰めればもっと多くの桁数での表示も可能であると思われますが、以下の理由からそれは断念しました：
- ディスプレイの認識解像度が720×480のため、90桁を超えた段階で水平方向の解像度が1ドット以下になって滲み始めており、100桁ではかなり滲んでいること（さらに桁数を増やせば滲みがよりひどくなるのは明らか）。
- このディスプレイは基本的に表示を画面いっぱいに引き延ばして表示するため、当初よりブラウン管ディスプレイ時代と比較してドットが縦長となっているが、桁数を増やすことでさらにドットの縦長が進むこと。
つまり、100桁×30行が実用上の限界であろうと判断したわけです。ただ、もっと素直に90桁×30桁表示がいいような気もします。これは今後様子を見ながら決めていきたいと思います。
しかし、このディスプレイの内部解像度は30行BIOSと90桁BIOSの名前につけた行×桁と一致する解像度なのが面白いところです。※10
実動写真
80桁×25行（640ドット×400ライン）の標準状態での表示したディスプレイの写真を以下に示します：
30行BIOSと90桁BIOSを使用して100桁×30行（800ドット×480ライン）を表示したディスプレイの写真を以下に示します：
補足1 – ディスプレイ信号について
前述の状況分析に関連してディスプレイの信号に関する補足をしたいと思います。
ディスプレイの信号※11は、水平同期信号と垂直同期信号を元に位置決めが行われます。水平同期信号は1ラインごとに出力され、この信号の後に次のラインの信号出力が行われます。垂直同期信号は1画面ごとに出力され、この信号の後に次の画面の信号出力が行われます。
このように、1ラインおよび1画面については信号で明確に分けられています。これに対して1ライン中の1ドットについては明確なタイミングが取られていません（1ラインの出力が終わるまでの間にどれだけアナログ信号の振幅があるかは明確ではありません）。これは、ブラウン管型のディスプレイを駆動することを前提とした信号であるためにこのようになっています。
しかし、現在のディスプレイはアナログ入力であったとしても内部はデジタルで処理が行われます。このため、アナログ信号は内部に取り込む際にデジタル化（デジタイズ）します。このタイミングは、デジタイズの際に決まっている必要があるため、信号のタイミングによって適応するドット数を割り出す必要があり、これは一般的に想定するドット数をあらかじめ決めることが多いようです。これが細かければ細かいほど微妙な信号の変化を再現しやすくなりますが、処理する情報量は増大し、これがコストに響くことになります。また、本来であれば1画面に含まれるライン数は実測値で割り出すことができますが、こちらもある程度の典型値を持っていることが多いようです。
このような前提に基づいて考えると、今回使用したディスプレイLCD-AD191SEBは、この2つの値、つまり横のドット数、縦のライン数の想定値として720ドット×480ラインを採用していると想定できるわけです。※12このサイズでデジタイズした画像を1280ドット×1024ドットの物理的な液晶ディスプレイに射影しているわけです。
このような仕組みであるため、横の「ドット数」と縦の「ライン数」は別の概念となるため、本稿では横は「ドット」、縦は「ライン」という単位を表現に使用しています。
補足2 – PC-9800シリーズの解像度について
一般に、PC-9800シリーズの解像度は640ドット×400ラインと言われていますが、実はこれは一定の条件下を除いて正しくありません。正確には641ドット×400ラインです。640ドット×400ラインになるのは液晶/プラズマ・ディスプレイモードが設定されているケースとプログラムが同等のモードを設定している場合に限られます。
なぜ1ドット増えるのかというと、テキストとグラフィックが1ドットずれているからです。テキストはグラフィックよりも1ドット左に表示されます。このため、表示領域の総ドット数が1増えるのです。
今回のようにディスプレイのデジタイズ解像度※13を意識する必要がある場合には、このような状態になっていることを知るのはとても大事なことです。
ちなみに、最大表示色数もグラフィックスの4096色中16色＋テキストのデジタル8色の合計24色がより正確です。
Windows 95
MS-DOS側の環境を整備したことにより、Windows 95側の環境も本来の環境を取り戻しました。というのも、MS-DOS用の各種ユーティリティを使用してWindows 95用の初期化をCONFIG.SYSとAUTOEXEC.BATで行ったうえでWindows 95が起動するように設定していたためです。
行っている設定は以下の通りです：
- HSBの組み込み
- 各種環境変数の設定
- MOディスク・ドライブの設定変更（スリープ・タイマーの変更とライト・キャッシュの有効化）
- 音源ボード（PC-9801-86ボード）の初期設定※14
- PC-9821Xt/C10W内蔵WSS音源の初期設定※15
このうち音源ボードと内蔵WSS音源の初期設定を行っているのがポイントです。さらにWindows 95のINFファイルの記述変更なども行っていて、Windows 95上において音源ボードと内蔵WSS音源を両立させています。この両立している状態でのデバイス・マネージャーの表示を以下に示します：※16
このように「Mate-X PCM」と「PC-9801-86 または互換」が共存しています。Windows 95では1つのサンプリング・データの再生で音源を独占する仕様のため、現在のように1つの音源に複数のアプリケーションから同時に音を出すことができません。このため通常は1音のみが再生可能なのですが、このように2つの音源を両立させると2音まで同時に音を出すことができます。また、WindowsにおいてはWSS音源の方が良いパフォーマンスを発揮するので、優先する音源として同音源を設定しておくと、より快適になるというメリットもあります。
これを見ていて気づいのですが、他にアイ・オー・データ機器のRSA-98をCバスに接続しているのですが表示されていません。どうもWindows 95側にはドライバーを入れていないようです。Windows NT 4.0 Workstation側には入っているのですが…。
まとめ
今後の課題としては、PC-9821Xt/C10Wのフロッピー・ディスク・ドライブ（FDD）の修復が残っています。前回までテストをしていなかったCD-ROMドライブ（SCSI ID-6）については、Windows 95のデバイスを入れ替える際に、Windows 95のCD-ROMを入れてみたところ、正常に動作しました。ただ、CDキャディが必要なタイプのドライブで、このCDキャディの予備がないのがやや不安に思えます。
今回の作業によって、MS-DOS上における開発をある程度再開できるところまで環境整備ができました。ただし、30行BIOSで使用している「TSRdrv」※17のソース・コードが今回のファイルの中には存在していないことが明らかとなりました。
ここにないとなると、この前の開発環境、すなわちPC-9801ES2を使用していた時の開発環境に存在している可能性が高そうです。第1回の調査でPC-9801ES2は電源が入らない状態であることが判明しているため、対応策を検討する必要があります。さらに、開発環境が入っていたHDDがはたして読めるのかどうか、という問題もあるなど、考慮しなければならないことが多くあります。
余談
今回は前回あまりきれいにデジタル・カメラで撮影できなかった反省を入れて、ディスプレイを撮影する際の照明と距離および設定などについて改良をしてみました。前回や前々回と比較して割とよく取れていると思うのですが、いかがでしょうか？ なお、今回ディスプレイのフレームを写真に入れているのは実際の画像であることを強調するためです。
- 執筆時点で、今から約16年前…ですよ…。ちなみに1998年の9月15日から10月末くらいの間のどこかで作成したバックアップだと思われます。
- 実行したコマンドは
XCOPY /S /E C:\ A:\です。 - MS-DOSのコマンド・ラインを処理する
COMMAND.COMは、外部コマンドを実行する際に自身が使用する大部分のメモリ領域を「フリー領域」として申告します。再びコマンド・ラインに戻る際に、自分自身の「フリー領域」として申告した部分が破壊されているかどうかをチェックし、破壊されていればディスクなどから読み直して実行するようになっています。これによって不要なディスクからの読み取りを減らし動作速度を上げることと、有効にメモリを活用することの両立を実現しています。 - 森河 正男さん（Masaoさん）による「HSB for PC-9801 – High Speed Boot プログラム」
- 鵜川さん（Ukaさん）によるソフトウェア。30行BIOSと90桁BIOSに完全対応しています。
- c.mosさんによるテキストエディター。かつて存在したビレッジセンターより市販されていました。
- 荻野 晃史さん（K.Oginoさん）による「VEM486 – Virtual XMS/EMS/VCPI Memory Server」
- ダイヤモンドトロン採用の17インチ・ディスプレイ。標準価格198,000円、秋葉原の実売で99,800円ほどでした。
- 90桁BIOSのマルチスキャン・モードでは、GGDCクロックが2.5MHzの際には4桁単位、同5.0MHzの際には2桁単位で桁数を指定できます。
- 30行×16ドット＝480ライン、90桁×8ドット＝720ドット、すなわち720×480となり、一致するわけです（実際には1ドットずれるわけですが…）。
- ここでは特にアナログ信号に限定し、細かいタイミング（水平・垂直の各フロント・ポーチやバック・ポーチなど）については省いています。
- 表示上ならびに使用上も同じ値が書かれていることもこれを裏付けています。
- こういうケースでは同じresolutionでも分解能の方が適切かもしれませんが、ここでは他で解像度と記述しているのでそれに合わせることにしました。
- Takehiro UEDAさんによる「SIC（PC-9821 Sound & ID Controler）」を使用
- 見やすいようにスクロールして表示する部分をつなぎ合わせて1枚の画像にしています。
- 30行BIOSの原作者であるluciferさんによる開発ライブラリー