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

［第４３１回］


●ＭＳ−ＣＯＢＯＬ（３）

前回からの続きです。
ＣＰ／ＭではファイルのＯＰＥＮやファイルのＲＥＡＤ／ＷＲＩＴＥなどのファイル操作の場合にＦＣＢ（Ｆｉｌｅ　Ｃｏｎｔｒｏｌ　Ｂｌｏｃｋ）という３２〜３６バイトのエリアをＲＡＭ上に設けて、そこにファイル名情報などを書き込んで、それをディスクアクセスの際のファイルサーチに利用します。
ＦＣＢエリアはメモリ上で３６バイト以上連続して空いているところならばどこでも指定できます。
下はデフォルトのＦＣＢエリアとして使われるアドレス００５ＣＨ〜をＦＣＢエリアとしたときの、ＦＣＢの内容を示したものです。

００５Ｃ　１バイト　ディスクドライブ�ａ@カレントディスクは００、Ａドライブは０１、Ｂドライブは０２というように指定する。
００５Ｄ〜００５４　８バイト　ファイル名。８文字に満たない場合には後ろの余ったところは２０Ｈ（スペース）で埋める。
００６５〜００６７　３バイト　拡張子。３文字に満たない場合には後ろの余ったところは２０Ｈ（スペース）で埋める。
００６８　１バイト　エクステント（拡張�ａj通常はここには００を置く。
００６９〜００６Ａ　２バイト　システムが使用することになっているが何に使われるか不明。通常は００を置く。
００６Ｂ　１バイト　記録レコード数
００６Ｃ〜００７Ｂ　１６バイト　ファイルアローケーションマップ　データブロックのブロック�ｂｪ記録される。
００７Ｃ　１バイト　シーケンシャルＲＥＡＤ／ＷＲＩＴＥのとき、次にアクセスするレコード�ｂ�置く。
００７Ｄ〜００７Ｆ　３バイト　ランダムアクセスのときに、次にアクセスするレコード�ｂ�置く。

以上のうち、ファイルオープンで指定する必要があるのは００５Ｃ〜００６８の１３バイトです。
前回はつい「ルール違反」などと書いてしまいましたが、実のところどういうルールなのかいまひとつわかっていないところがあります。
どうやらほぼ確実なのはファイル名の比較、検索には００６９の１バイトは使われていないらしいということです。
しかし００６Ａはファイル名の比較、検索には使われるらしいということで（今となってはその根拠もちょっとあいまいなのですが）、ここはファイル名比較の場合にチェックしていました。
通常ドライブに新規ファイルとしてセーブされるときには、この位置の２バイトは００が書き込まれます。
ですので、ファイルオープンするためにＦＣＢを作成する場合には、たいていはここは００をいれます。
と、私は思い込んでいました。

しかし。
考えてみればドライブ名〜エクステントまでの１３バイトさえあれば、ファイルＯＰＥＮには十分だとも言えます。
確かに。
でも、今までテストをしてきたプログラムでは、その後ろの２バイトも００にするというＦＣＢになっていたのです。
ですので、てっきりそういうものだと思ってファイル名比較のルーチンを書いていました。
もうおわかりかと思います。なぜファイルＯＰＥＮでこけてしまったか？

もう一度前回お見せしましたログファイルのＦＣＢのメモリダンプ部分をお見せします。　

-d5130 5130 C8 3E FF B7 C9 01 00 4C 3A 00 00 CC 52 00 52 55 .>.....L:...R.RU 5140 4E 43 4F 42 20 20 43 4F 4D 00 48 E4 15 75 39 31 NCOB COM.H..u91 5150 75 57 31 61 01 00 36 00 4F A2 30 66 D3 3E 3E 00 uW1a..6.O.0f.>>. 5160 5D 3A 38 51 FE 41 DA 6E 51 D6 40 32 3D 51 11 00 ]:8Q.A.nQ.@2=Q.. 5170 01 0E 1A CD 05 00 11 3D 51 0E 0F CD 05 00 3C CA .......=Q.....<. 5180 A9 51 AF 32 5D 51 21 00 01 EB D5 0E 1A CD 05 00 .Q.2]Q!......... 5190 11 3D 51 0E 14 CD 05 00 D1 B7 C0 21 80 00 19 3A .=Q........!...: 51A0 37 51 BC DA B4 51 C3 89 51 11 BA 51 0E 09 CD 05 7Q...Q..Q..Q.... 51B0 00 C3 00 00 11 D8 51 C3 AC 51 2A 2A 20 43 4F 42 ......Q..Q** COB 51C0 4F 4C 20 45 78 65 63 75 74 6F 72 20 6E 6F 74 20 OL Executor not 51D0 66 6F 75 6E 64 0D 0A 24 2A 2A 20 43 4F 42 4F 4C found..$** COBOL 51E0 20 45 78 65 63 75 74 6F 72 20 74 6F 6F 20 6C 61 Executor too la

ここでは５１３ＤからがＦＣＢです。
前から１３バイト目のエクステントは００になっていますがその後ろの２バイトは００ではありません。
こういうところはきちんと００にしておいてほしいなあ。
ですけれど。
まあ、上でも書きましたようにこの２バイトが実際に何に使われるのか、あるいは使われないのかはっきりしないところもありますから、とりあえずこの２バイトはファイル名検索からは外すことにしてプログラムを書き換えました。
そうしましたら。

おお！
ＳＱＵＡＲＯ．ＣＯＭが実行できるようになりましたよ。

ＳＱＵＡＲＯ．ＣＯＭは平方根の計算プログラムなのだそうです。
へえっ?
ＣＯＢＯＬは事務処理用だとばかり思っていたのですけれど…。
そうか。
事務処理でも平方根を使う場合もあるわけか（本当に使うか？）。

うむむ。
ちゃんとルート５は「富士山麓オーム鳴く」になっていますね。
ＣＯＢＯＬも大したもんじゃありませんか。

あれっ？
ルート２は、「一夜一夜にひとみごろ」じゃありませんでしたっけ？

ほらあ。
そうでしょう。

’３’が落ちてますよ。
でも、まあ、事務計算ですからいいか（って、よくないでしょう）。

うむむ。
なんだろうなって気になっていたのですけれど。
ＫＥＹ　ＩＮ　”Ａ”　ＡＳ　９（７）Ｖ９（１１）
の意味が分かりましたよ。
多分、数値の入力フォーマットが９９９９９９９．９９９９９９９９９９９ということなのじゃないでしょうか？

試してみました。

おや。
どうやら９（７）Ｖ９（１１）ではなくて９（７）Ｖ９（９）の間違いのようですねえ。
しかもその範囲でも大きい数は苦手なようです。

うむむ。
ＣＯＢＯＬは大きい桁の数値の演算を正確に扱えるというのがウリだったはずですけれど…（ＦＯＲＴＲＡＮは近似値計算）。
ま、しかしルート９９９９９９９．９９９９９９９９９がここまで計算できれば大したもんじゃありませんか。
なんたって８ビットＣＰＵなんですから。

ちなみに正確な計算ではこうなります。


●ＤＤＴの入手先

ＤＤＴ（Ｄｉｎａｍｉｃ　Ｄｅｂｕｇｇｉｎｇ　Ｔｏｏｌ）の入手先です。
こちらのサイト（http://www.retroarchive.org/cpm/os/os.htm）のＤＲＩＰＡＫ．ＺＩＰをダウンロードして解凍するとフォルダがいっぱい現れます。
そのうちのＣＰＭ＿２−２フォルダの中のＵＴＩＬＳＲＣフォルダを開くとＣＰＭ２．２用ユーティリティフォルダがいっぱいできています。
すごい。お宝の山です。
そこのＤＤＴフォルダを開くとＤＤＴ．Ｃ８０があります。
これがＤＤＴ．ＣＯＭです。
Ｚドライブ（Ｚフォルダ）にコピーしてから、拡張子をＣ８０→ＣＯＭに変更します。
ＲＥＮ　ＤＤＴ．Ｃ８０　ＤＤＴ．ＣＯＭ　です。

こんな感じです。

Z>ren ddt.c80 ddt.com rename z\DDT.C80 DDT.COM done Z>ddt DDT VERS 2.2 -l0100 0100 LXI B,0FBC 0103 JMP 013D 0106 MOV B,E 0107 MOV C,A 0108 MOV D,B 0109 MOV E,C 010A MOV D,D 010B MOV C,C 010C MOV B,A 010D MOV C,B 010E MOV D,H -

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

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