２０１２．３．７
前へ
次へ
ホームページトップへ戻る

復活！ＣＰ／Ｍ　ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！

［第５３回］

●ファイル名が表示されないわけ

前回からの続きです。
ＣＯＰＹプログラムを作って実行してみたのですが、プログラムは正常に終了したはずなのに、ＤＩＲコマンドを実行してみると、ＣＯＰＹ先のファイル名が表示されませんでした。
ＺＢ３ＢＡＳＩＣに戻ってＤＭコマンドでＲＡＭディスクのディレクトリエリアを表示させてみますと、ＣＯＰＹプログラムによって新しく作成されたｔｅｓｔｄａｔａ．ｔｘｔはちゃんと登録されています。
それなのに、どうしてＤＩＲコマンドでは表示されないのでしょうか？

ＤＭコマンドによって表示されたＲＡＭディスクのディレクトリエリアのダンプリストを眺めていましたら、あることに気がつきました。
というところで、前回は終わりました。

おそらく。
前回をお読みになって、「そこじゃないのかなあ」、と思われた方も多いのでは、と思います。
下は前回お見せしたＲＡＭディスクのディレクトリエリアのダンプリストです。
今回はその一部だけを、再掲いたします。



アドレス８９４０Ｈ～８９５ＦＨがＴＥＳＴＤＡＴＡ．ＴＸＴのＦＣＢです（水色で囲った部分）。
アドレス８９４ＣＨの値がＢ８になっています。
そのほかのファイルの同じ位置を見ますと、全て００です。
ＣＯＰＹ元のファイルＦＴＥＳＴ４－１．ＴＸＴのＦＣＢはアドレス８８Ｃ０Ｈ～８８ＤＦＨです（緑色で囲った部分）が、その同じ位置（アドレス８８ＣＣＨ）はやはり００になっています。

ＦＣＢのこの位置は、［第５１回］のＣＰ／Ｍシステムエリアの説明では、「ディレクトリ拡張№」に相当しているようです。
ディスクディレクトリのファイル毎のＦＣＢ（ファイルコントロールブロック）は、上のダンプリストにありますように、３２バイトのサイズです。
その１７バイト目からの１６バイト（アローケーションエリア）に、そのファイルのデータが格納されているブロック№が書き込まれます。
たとえばＴＥＳＴＤＡＴＡ．ＴＸＴのデータ部はブロック№０Ｄおよびブロック№０Ｅに置かれていることが、上のダンプリストからわかります。

この仮ＣＰ／ＭシステムのＲＡＭディスクでは、１ブロック＝４セクタです（［第１２回］）。
ですからＲＡＭディスクの先頭から４セクタ（１セクタは１２８バイト）ごとに区切って、そこに№００、０１、０２…と番号をつけていったときの、№０Ｄと№０Ｅに、ＴＥＳＴＤＡＴＡ．ＴＸＴのデータが書き込まれているということになります。
ＴＥＳＴＤＡＴＡ．ＴＸＴのサイズはＦＴＥＳＴ４－１．ＴＸＴと同じですから７０７バイトです（［第４９回］）。
１ブロック＝４セクタ＝１２８×４＝５１２バイトですから、２ブロックに書き込まれます。

しかし、その計算でいくと、ＦＣＢのアローケーションエリアは１６バイトですから、５１２×１６＝８１９２バイトを超えるファイルは扱えなくなってしまいます。
そこで、ＣＰ／Ｍシステムではそのような場合には、もう１つ同じファイル名のＦＣＢを作成して、そのアローケーションエリアに続きのブロック№を記入できるようにしてあります。
すると同じファイル名のＦＣＢが複数存在することになりますから、それぞれを区別するために、今回注目しましたディレクトリ拡張№が使われます。

ということになりますと。
このディレクトリ拡張№エリアは通常はおそらく００ということになりますでしょうし、もしそこが００以外であれば、同一ファイル名のセカンド以降のＦＣＢであるということになりますから、ＤＩＲコマンドでは二重に表示されないようになっていると思われます。

おお。
どうやら、ここが００でないことが、ＤＩＲコマンドで表示されなかった原因のようです。

●表示されなかった原因を取り除きました

そこで、ＣＭコマンドで８９４ＣＨの値をＢ８から００に変更してみました。

>cm 894c
894C B8-00
894D 00-
>jp d233

a>dir
A: FILLE5   COM : FTEST1   COM : FTEST2   COM : DM       COM
A: TEST     COM : FTEST4   COM : FTEST4-1 TXT : FTEST4-2 COM
A: FTEST4-3 COM : COPY     COM : TESTDATA TXT

ここ（８９４ＣＨ）はＲＡＭディスクのディレクトリエリアです。
ＲＡＭディスクだからこそ、こんな器用なことができるので、普通のフロッピーディスクなどではこんなことはできません。
こういうことが簡単にできてしまうというところに、今回の仮ＣＰ／Ｍシステムの強みがあります。

そのように変更してから、
ＪＰ　Ｄ２３３［Ｅｎｔｅｒ］
でＣＰ／Ｍに戻り、もう一度あらためてＤＩＲコマンドを実行しました。

おお。
ＴＥＳＴＤＡＴＡ．ＴＸＴが表示されるようになりました。

●コピー先のファイルを表示させてみました

ＣＯＰＹプログラムによって作成されたＴＥＳＴＤＡＴＡ．ＴＸＴを、［第４６回］で作ったＴＹＰＥプログラム（ｆｔｅｓｔ４．ｃｏｍ）で表示してみました。

a>ftest4 testdata.txt
; BDOS TEST4 TYPE
;2012/2/28
;
        ORG $8100
        FCALL=$8005
        FCB=$805C
        RECNO=$807C
        DMA=$8080
;
        LD C,0F;open
        LD DE,FCB
        CALL FCALL
        INC A;if FFH?
        JP Z,ERR
        XOR A
        LD (RECNO),A
;
LOOP1:  LD C,14;read
        LD DE,FCB
        CALL FCALL
        OR A
        RET NZ;read end
;
        LD HL,DMA
LOOP2:LD E,(HL)
        LD C,02
        PUSH HL
        CALL FCALL
        POP HL
        INC L
        JP NZ,LOOP2
        JP LOOP1
;
ERR:LD DE,ERRMSG
        LD C,09
        CALL FCALL
        RET
ERRMSG:"can'"
        "t op"
        "en"
        DB 0D
        DB 0A
        DB 24;$
;

a>

もとのファイル（ＦＴＥＳＴ４－１．ＴＸＴ）と同じ内容のようです。
本当は２つのファイルが同一であるかどうかを比較するプログラムを作って、それで比較してみるとよいですが…。
むむ。
あとで作ってみることにいたしましょう。

さて。
これで一件落着としたいところなのですが、そうはいきませんでしょう。
そもそもＣＯＰＹプログラムで、コピー先のプログラムのＦＣＢエリアのディレクトリ拡張№に００がセットされなかったことが、今回の問題の原因だったわけですから、それを直しておく必要があります。

一番ダイレクトな方法は、プログラムでその位置に００を書き込むようにすればよいのですが…。

●システムによってＦＣＢにファイル名がどのように書き込まれるか？

ＣＰ／ＭシステムによってＣＰ／ＭシステムのＦＣＢエリア（８０５ＣＨ～８０７ＦＨ。本来は００５ＣＨ～００７ＦＨ）にファイル名がインプットされる段階で、このディレクトリ拡張№も００がセットされているのではないだろうか？
という疑問が出てきました。

もとのプログラムでは、ファイルネーム部として、８０６ＣＨ～の１２バイトをＦＣＢＷＫ（８０３ＢＨ～）にコピーするようにしていたのですが、もしもそういうことならば、その後のアドレスのデータも含めてコピーする、という考えもあり、だと思います。

それでは。
ＣＰ／Ｍシステムがそのようになっているかどうかはどうすれば確認できるか、ということでありますが。
ＣＰ／Ｍソースリストを解析してみればわかることなのですけれど。
もっと簡単な方法があります。

少し説明が長くなってしまいましたので、この続きは次回にすることにいたします。

ワンボードマイコンでＣＰ／Ｍを！［第５３回］
２０１２．３．７ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る