ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第１３５回］
●ファンクションコール１０Ｈ（ファイルクローズ）、１３Ｈ（ファイル削除）、１５Ｈ（シーケンシャルライト）、１６Ｈ（新規ファイル作成）
今回は表記のファンクションコールを一度にテストします。
テストプログラムＦＴＳＴ５ＣＰＹは［第５１回］で作成しました。
ファイルコピープログラムです。
ＦＴＳＴ５ＣＰＹは［第５２回］で実行しましたが、そこでバグがみつかったため、［第５４回］で修正をしました。
そのあと再度実行をしています。
ファイルクローズ～新規ファイル作成までの機能は、ＣＣＰ（Ｃｏｎｓｏｌｅ Ｃｏｍｍａｎｄ Ｐｒｏｃｅｓｓｏｒ）のＥＲＡコマンドやＳＡＶＥコマンドとしてすでに検証済みなので、今回のテストは楽勝ものだったはずなのですが。
またまた見事にこけてしまいました（なかなかにつらいものです）。
下はテスト中の画面です。
ファンクションコール１３Ｈ（ファイル削除）の機能を試すために、ＣＯＰＹ後のファイル名を登録済みにしておく作業を先に行なっています。
ＲＥＮ ＬＦＴＥＳＴ．ＣＰＰ ＴＥＳＴＤＡＴ２．ＴＸＴ
です。
どうでもいいファイルをそのように名前変更しました。
［第５２回］でしたのと同じように、ＦＴＳＴ５ＣＯＰＹ．ＢＩＮをロードしてから互換ＤＯＳを起動して、ＣＯＰＹ．ＣＯＭというファイル名で仮ＲＡＭディスクにセーブしました。
セーブする前にＲＥＮを実行していますが、誤操作を避けるためには、セーブコマンドを実行後にすべきところです。
慣れてきますとこういうイレギュラーな操作を平気でするようになりますが、よくないことです。
そのあと
ＣＯＰＹ ＦＴＥＳＴ４－１．ＴＸＴ ＴＥＳＴＤＡＴ２．ＴＸＴ
を実行して、エラーも出ずに無事終了しました。
めでたし、めでたし、でありました。
念の為に、軽い気持ちで、ディレクトリの中味も見ておきますかねぇ、ということで、一旦ＣＰ／Ｍ互換ＤＯＳを終了してＺＢ３ＢＡＳＩＣに戻ってＤＭコマンドでディレクトリエリアを表示させてみました。
そうしましたら！
えっ？
まさかのハプニングです。
画面なかほど、ＴＥＳＴＤＡＴ２．ＴＸＴのブロックアローケーションエリア（ファイル名の次の行）が、空っぽ？？？
ＣＯＰＹ元のＦＴＥＳＴ４－１．ＴＸＴのそこには、ちゃんと０８、０９の２ブロックが登録されておりますのに、ＣＯＰＹ先のＴＥＳＴＤＡＴ２．ＴＸＴは００のみで何も登録されていません。
うわあ、えりゃあこっちゃあ。
どこかにとんでもないバグがあるう…。
かくして、ため息をつきながら、デバッグ作業を開始したのでありました。
ブレークポイントを設定してデバッグを開始したときの様子です。
しばらく地道にデバッグを続けておりました。
デバッグというのは本当に骨の折れるしんどい作業です。
うむむ。
おかしいなあ。
どこも、悪くないなあ。
あっ…。
なんだ、これは？
やっと気が付きました。
なんとディスクが満杯だったのでした。
もう何回も説明をしております通り、本来はＷｉｎｄｏｗｓパソコンのハードディスク上に設けるつもりのＲＡＭディスクなのですが、今のところテストに都合がよいように、ＮＤ８０ＺⅢのＲＡＭに小さな仮のＲＡＭディスクを設けて、そこでテストを続けております。
わずか３２ＫＢしかないＲＡＭに、ＣＰ／Ｍ互換ＤＯＳをインストールして、さらにトランジェントエリアも設けた上で、余ったところをＲＡＭディスクとして利用するわけですから、ムリムリの状態です。
アドレス８８００Ｈ～Ｂ７ＦＦＨの１２ＫＢをさらに２分割して、Ａドライブ６ＫＢ、Ｂドライブ６ＫＢとして使っています。
ディスク容量がたったそれだけしかありませんから、すぐにディスクが一杯になってしまいます。
でも、テストを行なうにはこれが一番都合がよいので、このようにして使っているのです。
さて。
その構成での１ブロックは４セクタ０．５ＫＢです。
Ａドライブは６ＫＢなので、６／０．５＝１２ブロックしか使うことができません。
ブロックナンバーで言いますと、０～Ｂまでで１２ブロックです。
さきほどのディレクトリエリアのダンプをよく見てみますと。
最後にセーブしたＣＯＰＹ．ＣＯＭがブロックＢを使ってしまっています。
もっともＣＯＰＹ．ＣＯＭの実行時に作成されるコピー先ファイルのＴＥＳＴＤＡＴ２．ＴＸＴはすでにセーブ済みのファイルで、それを削除してからそのエリアを再利用しますから、もしもコピー元のファイルサイズが１ブロックだけだったとすれば、かろうじてディスク容量ぎりぎりで済んだはずなのでありますが。
上の画像にありますように、コピー元のＦＴＥＳＴ４－１．ＴＸＴは０８、０９の２ブロックを使っています。
当然コピー先のＴＥＳＴＤＡＴ２．ＴＸＴも２ブロックになりますから、そうするとディスク容量が足りません。
しかし。
それならエラーになったはず。
何のエラーも表示されなかったということは、それはそれで問題です。
そこで今度は、なぜディスクフルのエラーが表示されなかったのか？
ということを追求いたしました。
だんだん焦点が定まってきて、ついに解決に至ります。
ディスクフルエラーは、ＣＯＰＹプログラム（ＦＴＳＴ５ＣＰＹ）の中でチェックしていたはずでした。
最終的なＦＴＳＴ５ＣＰＹのプログラムリストは［第５４回］にあります。
そこでは何箇所かでディスクフルをチェックしています。
その中で、今回のトラブルの原因は、ファンクションコール１５Ｈ（シーケンシャルライト）のエラーチェックにあることがわかりました。
ソースプログラムのその部分です。
