HP200LX日本語化キット 開発秘話

第5回
DOS環境とシステムマネージャ環境の融合

TEXT:寺崎和久
前回登場したfontmanとyadcによって、DOSの日本語環境も現在の姿に近づきつつあった。しかし、DOSとシステムマネージャの日本語環境はまったく別のアプローチで実現されていたため、まだ両者を共存させるのは困難だった。今回は、DOSとシステムマネージャの日本語環境が歩み寄り、ひとつの環境に融合されていった過程を紹介しよう。

■100LX用のEMSドライバがついに登場

 当時、DOSとシステムマネージャの日本語化ソフトは、似たような機能を持つものでも別のプログラムとして作られていた(たとえば、表示を行なうyadcとkdisp 100、入力を行なうWXII+とFEP100など)。yadcとkdisp100が改良され、両者を同時に組み込むことは問題なくなっていたが、メモリ不足は深刻だった。とくに、WXII+などの日本語FEPの常駐量は大きく、それを組み込んだままではシステムマネージャ上で十分な空きメモリが残らなかった。そこで当時のユーザーは、ADDDEV/ DELDEVというユーティリティを使って、DOS上ではFEPを組み込み、システムマネージャを起動する前にFEPを取りはずすという工夫をしていた。

 FEPの常駐量が大きいのは、100LXでEMSメモリが使えないことも影響していた。EMSメモリとは、DOSの640KBのコンベンショナルメモリを補うために考えられた拡張メモリの規格である。EMS用のメモリ、EMSドライバ、EMSに対応したアプリケーションを組み合わせて使うと、DOS上でも640KBを超えるメモリが利用できる。当時のFEPは、コンベンショナルメモリの常駐量を減らすためにEMSメモリを使うのが常識となっていたのだ。たとえば、WXII+はEMSがなければコンベンショナルメモリを126KBも使ってしまうが、EMSがあれば21KBですむようになる。

 EMSメモリの仕組みは、ページフレームという名の16〜64KBの大きさの「窓」を用意し、その窓を通して広大な拡張メモリにアクセスするというものだ。窓の位置は固定だが、窓からみえるメモリはアプリケーションが好きなように切り換えられるため、使える拡張メモリの量はほとんど無制限に大きくできる。EMSメモリを使うためには、このようなメモリウィンドウの仕組みを備えた「ハードウェアEMSボード」をつけるか、i386以上のCPUの機能を利用してプロテクトメモリをEMSに見せかけることになる(このようにソフトウェアの処理でハードウェアEMSボードの機能を実現したものを「仮想EMS」という)。

 しかし、100LXのCPUは80186相当なので仮想EMSは逆立ちしても実現できないし、ハードウェアEMSボードを差すこともできない。そこで、ひろ.氏が考えたのは、ページフレームはコンベンショナルメモリ内に置いて、拡張メモリに見立てたファイルの内容を逐次ページフレームとの間でコピーするという手だ。ファイルをメモリの代わりに使う手法はexfontやfontmanですでに実現されており、そこそこの速度で動くという確証があった。EFM100の次のネタを探していたひろ.氏はすぐに作りはじめ、EMM100 Version 0.10としてFYHPフォーラムで発表した。

 EMM100 Version 0.10を公開してすぐに、ひろ.氏のもとにkdisp100のかづひ氏から1通のメールが届いた。そこには、100LXはハードウェアEMS相当の機能をはじめから備えており、Cドライブの内容をメモリウィンドウを介して読み書きできるという驚くべき情報が書かれていた(リスト)。リストでは省略しているが、メールにはかづひ氏独自の解析結果も書かれており、100LXのメモリウィンドウを操作するには十分な情報であった。

 ひろ.氏はさっそくこの情報を取り入れ、Cドライブに置いたEMS用のファイルをメモリウィンドウから高速にアクセスするようにEMM100を改良した。これでEMSメモリのアクセス速度が向上し、FEPをEMSに組み込んでもそこそこ満足できる速度で動くようになった。ただし、ページフレームはまだEMM100の常駐部に置かれていたため、速度は改善されても常駐量は減らなかった。

 しかし、これはEMM100の改良の過程にすぎなかった。かづひ氏のメールには、100LXのハードウェアはメモリウィンドウの機能を備えており、そこをEMSのページフレームとして使える可能性があることを示唆していた。問題は、100LXのシステムとEMM100の間で、メモリウィンドウの奪い合いが起こることである。メモリウィンドウは100LXが標準でROMに搭載しているアプリケーションを実行するためにも使われており、EMM100が勝手にメモリウィンドウをいじるとアプリケーションが正常に動作しなくなってしまうのだ。

 ひろ.氏はこの問題をある程度解決した時点で、EMM100 Version 0.30を公開した。このバージョンではページフレームをコンベンショナルメモリの外に追い出すことに成功し、EMSメモリのアクセス速度も劇的に向上した。ついに、100LXでは実現不可能と思われていた本もののEMSが利用できるようになったのである。Version 0.30では内蔵アプリケーションとDOSプロンプトを往復したときの動作に問題があったが、その後のVersion 1.00では完全に解決された。

 当時、DOSとシステムマネージャの日本語化ソフトは、似たような機能を持つものでも別のプログラムとして作られていた(たとえば、表示を行なうyadcとkdisp 100、入力を行なうWXII+とFEP100など)。yadcとkdisp100が改良され、両者を同時に組み込むことは問題なくなっていたが、メモリ不足は深刻だった。とくに、WXII+などの日本語FEPの常駐量は大きく、それを組み込んだままではシステムマネージャ上で十分な空きメモリが残らなかった。そこで当時のユーザーは、ADDDEV/ DELDEVというユーティリティを使って、DOS上ではFEPを組み込み、システムマネージャを起動する前にFEPを取りはずすという工夫をしていた。

 FEPの常駐量が大きいのは、100LXでEMSメモリが使えないことも影響していた。EMSメモリとは、DOSの640KBのコンベンショナルメモリを補うために考えられた拡張メモリの規格である。EMS用のメモリ、EMSドライバ、EMSに対応したアプリケーションを組み合わせて使うと、DOS上でも640KBを超えるメモリが利用できる。当時のFEPは、コンベンショナルメモリの常駐量を減らすためにEMSメモリを使うのが常識となっていたのだ。たとえば、WXII+はEMSがなければコンベンショナルメモリを126KBも使ってしまうが、EMSがあれば21KBですむようになる。

 EMSメモリの仕組みは、ページフレームという名の16〜64KBの大きさの「窓」を用意し、その窓を通して広大な拡張メモリにアクセスするというものだ。窓の位置は固定だが、窓からみえるメモリはアプリケーションが好きなように切り換えられるため、使える拡張メモリの量はほとんど無制限に大きくできる。EMSメモリを使うためには、このようなメモリウィンドウの仕組みを備えた「ハードウェアEMSボード」をつけるか、i386以上のCPUの機能を利用してプロテクトメモリをEMSに見せかけることになる(このようにソフトウェアの処理でハードウェアEMSボードの機能を実現したものを「仮想EMS」という)。

 しかし、100LXのCPUは80186相当なので仮想EMSは逆立ちしても実現できないし、ハードウェアEMSボードを差すこともできない。そこで、ひろ.氏が考えたのは、ページフレームはコンベンショナルメモリ内に置いて、拡張メモリに見立てたファイルの内容を逐次ページフレームとの間でコピーするという手だ。ファイルをメモリの代わりに使う手法はexfontやfontmanですでに実現されており、そこそこの速度で動くという確証があった。EFM100の次のネタを探していたひろ.氏はすぐに作りはじめ、EMM100 Version 0.10としてFYHPフォーラムで発表した。

 EMM100 Version 0.10を公開してすぐに、ひろ.氏のもとにkdisp100のかづひ氏から1通のメールが届いた。そこには、100LXはハードウェアEMS相当の機能をはじめから備えており、Cドライブの内容をメモリウィンドウを介して読み書きできるという驚くべき情報が書かれていた(リスト)。リストでは省略しているが、メールにはかづひ氏独自の解析結果も書かれており、100LXのメモリウィンドウを操作するには十分な情報であった。

かづひ氏がひろ.氏に送ったメールの一部

(……前略……)

 それで、私もあれから色々と試したのですが、実は! 私は1つすっごい思い違いをしていたのでした。 それは、C:のRamは、以前実験した時には 直接Ramとして書き換えたら、次回の Power-ON 時に「C:が壊れてまっせー」 メッセージが出て、強制イニシャライズがかかったんですよ。 それで、ずーっとそう思ってたんですけど、最近実験したら、どうもそうはならない。 つまり、「C:のRamは、直接書き換えてもいい!」という結論なんです! これこそ私達が求めていたもの! でしょでしょ?

 それと、実はHP100LXには、LIM−EMS相当のハードウェアは|最初から載っています。 それも、メモリウィンドゥは、16K*8, 64K*1 も持っています。 しかし、普段は SystemManager がガッチリ管理していて、勝手に触れません。 でも、自分が使う時だけレジスタ値を変えて、使った後はすぐに戻すようにすれば大丈夫なので、今のようにメインメモリに物理ページを割り当てておいて、そこに Memory to Memory のコピーをするような形でなら利用は可能です。

(……後略……)

 ひろ.氏はさっそくこの情報を取り入れ、Cドライブに置いたEMS用のファイルをメモリウィンドウから高速にアクセスするようにEMM100を改良した。これでEMSメモリのアクセス速度が向上し、FEPをEMSに組み込んでもそこそこ満足できる速度で動くようになった。ただし、ページフレームはまだEMM100の常駐部に置かれていたため、速度は改善されても常駐量は減らなかった。

 しかし、これはEMM100の改良の過程にすぎなかった。かづひ氏のメールには、100LXのハードウェアはメモリウィンドウの機能を備えており、そこをEMSのページフレームとして使える可能性があることを示唆していた。問題は、100LXのシステムとEMM100の間で、メモリウィンドウの奪い合いが起こることである。メモリウィンドウは100LXが標準でROMに搭載しているアプリケーションを実行するためにも使われており、EMM100が勝手にメモリウィンドウをいじるとアプリケーションが正常に動作しなくなってしまうのだ。

 ひろ.氏はこの問題をある程度解決した時点で、EMM100 Version 0.30を公開した。このバージョンではページフレームをコンベンショナルメモリの外に追い出すことに成功し、EMSメモリのアクセス速度も劇的に向上した。ついに、100LXでは実現不可能と思われていた本もののEMSが利用できるようになったのである。Version 0.30では内蔵アプリケーションとDOSプロンプトを往復したときの動作に問題があったが、その後のVersion 1.00では完全に解決された。


[TOP] [NEXT]
トップへ 次ページ

無断転載を禁じます