ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第３７９回］
●ＣＯＰＹコマンド作成中のトラブル
このところＣＯＰＹコマンドの機能拡充のための作業に取り組んでいます。
とんでもないバグの伏兵のために半日、１日を費やしてしまうことなどがあって、なかなかに大変です。
今回はそのお話を少々。
ＣＰ／Ｍ互換ＤＯＳはＣＰ／Ｍ２．２（５８ＫＢ版）の互換ソフトとして開発をしてきました。
ＣＰ／ＭはＣＣＰ、ＤＯＳ、ＢＩＯＳの３つのプログラムによって構成されていて、その開始アドレスが決まっています。
５８ＫＢ版の場合、ＣＣＰのアドレスはＣＣ００になっているようですので、それより前にシステムプログラムを置くわけにはいきません。
ＣＣＰとＢＩＯＳにはさまれる形になっておりますＤＯＳもどうやらその居場所は決まっているようで、Ｄ４００からになっているようです。
実際にはファンクションコールのアドレスの関係で、メインになるプログラムの先頭アドレスはＤ４０６からになります。
ＢＩＯＳのアドレスはＥ２００からのようです。
このように３つのプログラムを配置するとなりますと、機能拡張をするにもメモリアドレスの壁が出てきます。
ＣＰ／Ｍの場合、ＰＩＰコマンドはトランジェントコマンドでした。
トランジェントプログラムというのは、一般にユーザーに開放されている０１００からのアドレスにロードされて実行されるプログラムのことで、トランジェントコマンドはシステムプログラムとして最初からメモリに常駐しているのではなくて、必要に応じてシステムディスクからトランジェントエリアにロードされて実行されるコマンドです。
ＣＰ／Ｍ互換ＤＯＳではＰＩＰに代わるものとしてＣＯＰＹコマンドを用意しているのですが、それはトランジェントコマンドではなくて、最初からシステムに常駐しているビルトインコマンドです。
これには理由がありまして、まあ、卵が先か鶏が先かという悩ましい問題なのです。
ＣＰ／Ｍ互換ＤＯＳではプロッピーディスクの代わりにＷｉｎｄｏｗｓパソコンのハードディスク内に仮想フロッピーディスクドライブというものを作ってそれにアクセスします。
最初にＣＰ／Ｍ互換ＤＯＳを立ち上げたときには、仮想ＦＤＤは空っぽです。
［２０１３．４．２６追記］
ＣＰ／Ｍ互換ＤＯＳをインストールして、そのあと最初に起動したときに、という意味です。
毎回起動したときに空ということではありません。
ＣＰ／Ｍ互換ＤＯＳを起動して、そこでＡ～Ｄの仮想ＦＤＤにプログラムファイル、データファイルをセーブしたあとは、次にＣＰ／Ｍを起動したときには、その仮想ＦＤＤは空ではありません。
前にセーブした状態はそのまま維持されています。［追記ここまで］
システムはＺＢ３ＢＡＳＩＣ上の ／ＣＰＭコマンド によってＮＤ８０ＺⅢ（ＮＤ８０Ｚ３．５）のＲＡＭにロードされたのち起動します。
つまりシステムディスクなるものが存在しないのです。
Ａ～Ｄの仮想ＦＤＤをシステムディスクのように使うことは自由ですが、しかし、とにかく最初はそこは空ですから、まずそこにプログラムを入れてからでないと、トランジェントコマンドとして使うこともできません。
そこでＷｉｎｄｏｗｓのフォルダから仮想ＦＤＤにプログラムをコピーする機能として、ＣＯＰＹコマンドにＣＯＰＹ Ｚという機能を付加しました。
当然、そのコピーコマンドは仮想ＦＤＤが空のときにも使えなくてはなりませんから、最初からシステムに常駐していなくてはいけないのです。
すると。
そのＣＯＰＹの機能を拡張するということになりますと、今度はさきほど書きましたように、メモリアドレスの壁が制約になってきてしまいます。
仕方がありませんから、最初はＣＣＰに入れておりましたＣＯＰＹプログラムを切り離して、それをＢＩＯＳの後方に置くという改造に着手いたしました。
しかしＢＩＯＳの後方は、ＺＢ３ＢＡＳＩＣのシステムワークが使っているところですから、気をつけないととんでもないトラブルになる可能性が出てきます。
狭いところでのやりくりはなかなかに大変です。
これまで割りといい加減に使っておりましたＣＰ／Ｍ互換ＤＯＳのためのワークエリアも整理したり移動したりと、派生的な作業に結構時間を取られてしまいました。
で。
ＣＯＰＹコマンドをそのようにお引越ししまして、やっとなんとか試運転にかかりましたところ。
？？？？？？
おかしいのでありますね。
実に奇妙な、摩訶不思議なエラーに直面してしまいました。
プログラムを何回見直してもそんなおかしな結果にはならないはずなのですが。
結局、その意外な原因をやっと突き止めるまでにたっぷりと貴重な半日余りを費やしてしまいました。
とにかくＣＯＰＹの動作があまりにおかしい、どうにも納得がいきません。
で、ブレークポイントを設定しながら少しずつプログラムを進めてデバッグをしていきましたところ、ある時点までくると、変数の値がプログラムの通りになっていないところがでてきました。
異常な動作の原因はその変数の値によるものであることがわかりました。
しかし、なぜそれがプログラムの通りになってくれないのか？
その値を設定する前後を詳しく調べてみましたところ、なんと、プログラムが一箇所書き換わっているじゃありませんか！
具体的には、アドレスＥＡ００が６２でなければならないところがＥ２に化けてしまっています。
すわメモリ異常か？
そんなわけはないのですよね。
何回か試して確認しましたところ、ＣＰ／Ｍ互換ＤＯＳをロードしたときには、その場所（アドレスＥＡ００）はちゃんと正しい値になっています。
ところが／ＣＰＭコマンドでＣＰ／Ｍ互換ＤＯＳを起動した直後にブレークして確かめてみますと、Ｅ２に化けてしまっています。
どういうわけかＣＰ／Ｍ互換ＤＯＳの初期動作のどこかでＥＡ００にＥ２を書き込んでしまっているようです。
しかし、プログラムを何回確認してみましても、ＥＡ００などというアドレスは全く出てきません。
そこで。
またしても、ブレークポイントを設定してＣＰ／Ｍ互換ＤＯＳを少しずつ進めつつ、アドレスＥＡ００の値を確認するという退屈な作業を続けました。
その結果、ＡＬＶ（アローケーションベクタ）の設定中にＥＡ００が変化するということがわかりました。
むむむ。
なぜこんなところで？
ＣＰ／Ｍはディスクの使用状況のマップ（それがＡＬＶです）をディスク上にではなくて、ＲＡＭ上に展開します。
ＭＳＤＯＳでＦＡＴと言っている情報エリアです。
ＣＰ／Ｍではセクタをまとめてブロックという単位で管理します。
仮想ＦＤＤの場合１ブロックは１６セクタで、ディスク全体は１０２４ブロックで構成されます（［第２１９回］参照）。
ディスクの割り当てはブロック単位で行なわれますが、どこのブロックが使用済みかということを常に管理していなければなりません。
ＣＰ／Ｍではディスクドライブの１ブロックをメモリの１ビットに割り当てて１０２４／８＝１２８バイトをＡＬＶエリアとして管理します。
ＭＳＤＯＳでＦＡＴとよんでいる同様のエリアはディスク上に置かれますが、ＣＰ／Ｍではそれはメモリ上に置かれます。
メモリですから電源を切ったら消えてしまいます。
それじゃディスクの情報も消えてしまうではないか、ということなのですが、そこでＣＰ／Ｍでは新たにディスクドライブにディスクがセットされるたびに、ディスクのディレクトリエリアを全部サーチして、使用状況を読み取って、その情報をもとにメモリ上にＡＬＶエリアを再構築するのです。
このためディスクを交換したり装着したりするたびにその作業に時間が費やされることになります。
その方式の是非はさておき、本題のトラブルの結末です。
実は、それよりも前にＣＯＰＹプログラムを変更する過程で何回かテストを行なって、そのたびに仮想ＦＤＤの中身も書き換わっていました。
最初のうちはバグだらけですから、仮想ＦＤＤの中身もそれなりにメチャクチャに壊されてしまったところがでてきていましたが、まあ、テストだからいいか、ということで、構わずそのままテストを続けておりました。
ちっともよくはなかったのでした。
テストの過程でバグのために、ディレクトリのＦＣＢ（３２バイトずつに区切られたファイルコントロールブロック）の中のブロックアドレスが書かれているエリアが破壊されていて、ありえない値になってしまっていたのでした。
本来はディスク全体で１０２４ブロックしかありませかんから、あるプログラムが書き込まれているブロックのナンバーとしては００００～０３ＦＦの間の値になります。
そこに２０００というとんでもない値が書き込まれてしまっていました。
ＡドライブのＡＬＶエリアはアドレスＥ６００～Ｅ６７Ｆに置かれています。
ブロックナンバー２０００（１６進数です）をそこに割り当てようとしますと、１ビットが１ブロックですから２０００Ｈ／８を計算して４００、それをＥ６００に加算しますと。
おお、ＥＡ００になりました。
つまり、本来ならばありえない２０００Ｈなどというブロックナンバーが使用済みであるとしまして、本来のＡＬＶエリアを大きく逸脱したＥＡ００にその情報が書き込まれてしまったのでした。
いやはや、おかげでたっぷりと半日以上を浪費してしまいましたが、しかし、ものは考えようで、たまたまＣＯＰＹプログラムを移動して、そしてたまたま今回のトラブルに遭遇したために、ＡＬＶエリアが作成されるときに、ディスクの情報が破壊されていたりすると、思わぬ場所が書き換わってしまうというプログラムの「脆弱性」が明らかになったわけでありまして、これがもし全くそのことに気がつかないままユーザー様に配布してしまったあとで、そういう事態が発生したりしますと、それこそ原因追及のために思いっきり悩んだことでありましょう（あなおそろしや）。
さっそく、ＡＬＶエリアを作成するときにその範囲をチェックするようにプログラムを修正しました。
と同時にディスクディレクトリのどこに異常があるかを表示できるようにしました。
前回お見せしましたＣＰ／Ｍ互換ＤＯＳ起動時の各ディスクドライブの表示の後ろに表示されている．．．．がその表示です。
．（ドット）のひとつが１６セクタあるディレクトリの各１セクタを示しています。
その機能を検証するために、わざとＡドライブのディレクトリの一部を書き換えてみました。
下の画面でディレクトリのブロックエリアに２２２１Ｈ、２４２３Ｈという異常な値を書き込んでいます。
普通はこういうことはできません。
ＺＢ３ＢＡＳＩＣのマシン語デバッグ機能を利用しています。
ＤＩＲコマンドで表示させても、その異常はわかりません。
一度ＺＢ３コマンドでＣＰ／Ｍ互換ＤＯＳを終了したあと、もう一度ＣＰ／Ｍ互換ＤＯＳを起動しました（デバック機能を利用中ですから／ＣＰＭではなくてＪＰ命令でＢＩＯＳにエントリしています）。
ｄｒｉｖｅ Ａの表示で前から２番目に ！ が表示されています。
ディレクトリの２番目のセクタに異常があることを示しています。
このことはＶＦＤＵＭＰで確認することができます（ＶＦＤＵＭＰはＣＰ／Ｍ互換ＤＯＳに同梱予定のソフトウェアです）。
表示されたセクタの一番下の行が書き換わっています。
いやあ。
なかなかに。
骨が折れる作業です。
ワンボードマイコンでＣＰ／Ｍを！［第３７９回］
２０１３．４．２５ｕｐｌｏａｄ
２０１３．４．２６追記
前へ
次へ
ホームページトップへ戻る