ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第４３８回］
●ＴＵＲＢＯ ＰＡＳＣＡＬ（２）
前回からの続きです。
ファイルの読み書きをするのにＣＰ／ＭではＤＭＡバッファというものを使います。
フロッピーディスクのアクセスは制御が複雑なので、専用のＬＳＩを使いました。
一般にＦＤＣ（フロッピーディスクコントローラ）と呼ばれていました。
ＣＰＵとＦＤＣとの間のデータのやりとりは、フロッピーディスクのアクセスには時間がかかるため、通常のＩ／Ｏアクセスを使うとＣＰＵの処理能力ががくんと落ちてしまいます。
そこでＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）方式で行なうことが一般的でした。
ＣＰ／ＭはフロッピーディスクをベースにしたＯＳなので、ファイルの読み書きは、そのＤＭＡバッファを経由して行ないます。
デフォルトのＤＭＡバッファは００８０Ｈ～００ＦＦＨの１２８バイトですが、メモリ上の空いているところならばどこにでもＤＭＡバッファを置くことができます。
ＤＭＡバッファのアドレスを設定するときはファンクション１ＡＨをコールします。
ところでファイルの読み書きをするときには、データを置くためのＤＭＡバッファとは別に、ディスクのディレクトリエリアを読み込んでファイル名をサーチしたり、新規にファイル名を登録するという作業が必要になります。
それをデータ用のＤＭＡバッファを使って行なうと、ディレクトリを読み込んだときにデータを破壊してしまいます。
それを避けるためＣＰ／ＭではＤＭＡバッファとは別にＤＩＲバッファを用意して、ディレクトリを読み書きするときはそのＤＩＲバッファを経由する、というシステムになっています。
それではデータ用のＤＭＡバッファとディレクトリ用のＤＩＲバッファとは完全に別物か、といいますとちょいと悩ましいことに、最初のファイル名サーチ（ファンクション１１Ｈ）や次のファイル名サーチ（ファンクション１２Ｈ）ではＤＭＡバッファにディレクトリが読み込まれてしまうのです。
それじゃあ困るではないの？
んでも、これはまあファイル名サーチの結果、それをどのように利用するかを考えてみますと、そのようにせざるを得ない事情も見えてきますので、仕方がないことなのであります。
そういう仕様になっている以上、ユーザーはそのときデータを破壊されてしまわないように、ＤＭＡバッファアドレスを適宜変更してバッティングするのを避けるようにすることが求められます。
実は、そのあたりの仕様をふまえてＺＢ３ＤＯＳ（ＣＰ／Ｍ互換ＤＯＳ）を作り上げていく過程で、どうせディレクトリを格納するのにもＤＭＡバッファが使われるのなら、工夫すればＤＩＲバッファを使わなくてもＤＭＡバッファだけでもできるのではないか、というとんでもないことを思いついて、それを実施してしまっておりました。
全然なしというわけにはいきませんので、バッティングするときだけは、バッファのバッファにバックアップするという面倒なプログラムを書いてしまいました。
それはそれで問題なく機能しておりましたが、そこで起きてしまいましたのが、今回のＴＵＲＢＯ ＰＡＳＣＡＬのトラブルです。
おかしいじゃないの？
ファイルサーチをすれば、ＤＭＡバッファが破壊されるのは当たり前で、そんなところにジャンプテーブルを置くなんて、ＴＵＲＢＯ ＰＡＳＣＡＬの開発者は何を考えているのだ？
ま、そこを使ってはならぬということはありませんから、そのようにするのは自由でありますが、それなら少なくともファイルＯＰＥＮよりも前にＤＭＡバッファを別のところに設定しているはず、と思ったのでありますが。
といいますのも、デフォルトではＤＭＡバッファはシステムによって必ず００８０Ｈに置かれてしまいますから、今回のように００８０Ｈ～のエリアをＤＭＡバッファ以外の目的に使うということでありましたら、ファイルにアクセスするよりも前にＤＭＡバッファを別のアドレスに指定しておかなくてはならないというのがものの道理です。
しかし、しかし。
ブレークポイントを設定してＴＵＲＢＯ ＰＡＳＣＡＬの動きを起動時から追跡してみましたところ、なんとＤＭＡバッファのアドレス変更がまったく行なわれないままファイルＯＰＥＮが実行されてしまいました。
ファイルＯＰＥＮ（ファンクション０Ｆ）ではファイル名サーチがコールされています。
そのため、ファイルＯＰＥＮによってＤＭＡバッファに置かれていたジャンプテーブルが破壊されて、暴走してしまうという結果になったのでありますが。
Ｈ様のメールによりますと、ＣＰ／Ｍエミュレータですかシミュレータでありますか、そちらで実行してみると、暴走などしない、とのことなのですね。
んな、ばかな。
こういう場合。
ばかなのは決まって私でありまして。
よーく調べてみましたら、どうやらＣＰ／Ｍでは、ＤＭＡバッファにディレクトリが書き込まれるのはファイル名サーチ（ファンクション１１Ｈ）と次のファイル名サーチ（ファンクション１２Ｈ）だけで、ファイルＯＰＥＮ（ファンクション０Ｆ、ファンクション１６Ｈ）やファイルＣＬＯＳＥ（ファンクション１０Ｈ）ではＤＭＡバッファは変化しない、ということがわかりました。
もっとよくＣＰ／Ｍのソースプログラムリストを読んでみましたら、ファイル名サーチ（ファンクション１１Ｈ）と次のファイル名サーチ（ファンクション１２Ｈ）のときに限って、わざわざＤＩＲバッファからＤＭＡバッファへのコピーが行なわれていることがわかりました。
むむむむ。
そーいうことだったのか。
そこで。
ＺＢＤＯＳプログラムを大幅に変更して、ＤＩＲＢＦとＤＭＡＢＦを分離しました。
これは、しかし相当に大幅なプログラム変更だったため、この後も尾を引くことになるのでありますが、それは後日のお話です。
ともあれ、そのように変更しました結果、ＴＵＲＢＯ ＰＡＳＣＡＬが正常に動作するようになりました。
あ。
その説明の前に。
●またＥＳＣシーケンスを追加しました
前回のＴＵＲＢＯ ＰＡＳＣＡＬの起動画面をご覧になってお気付きになられたかも知れません。
画面をよく見ますと ［０ｍ とか ［１ｍ とかという文字が表示されています。
また新たなエスケープシーケンスです。
調べてみましたら、ＥＳＣ［１ｍ は太字指定でＥＳＣ［０ｍは文字修飾をもとに戻すエスケープシーケンスでした。
この仲間にはそのほかに以下のものがありました。
ＥＳＣ［４ｍ 下線付き
ＥＳＣ［５ｍ 点滅
ＥＳＣ［７ｍ 白黒反転
しかしＥＳＣ［０ｍ以外はちょっと無理ですから、ＥＳＣ［１ｍ～ＥＳＣ［７ｍはいずれも文字の色指定を白にしました。
明るい白ですので、太字のように見える効果があります。
こんな感じになりました。
この太字（実は明るい白）は、ＴＵＲＢＯ ＰＡＳＣＡＬを使うと指定され、その後もずっと指定されたままになります。
ＺＢ３［Ｅｎｔｅｒ］でＣＰ／Ｍモードを終了してＺＢ３ＢＡＳＩＣに戻ると、通常の表示に戻ります。
ＴＵＲＢＯ ＰＡＳＣＡＬのエスケープシーケンスにはまだ続きがあるのですが、本日は時間がなくなってしまいましたので、この続きは次回にすることにいたします。
ワンボードマイコンでＣＰ／Ｍを！［第４３８回］
２０１３．７．１２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る