ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第８９回］
●カレントディスクの仕組み
ファンクションコール０Ｅをテストした結果として得た結論は、［第８６回］に書きましたように、
「ユーザープログラムの中で実行された、ファンクションコール０Ｅによるカレントドライブの変更は、そのプログラムの中だけ有効で、プログラムが終了するとキャンセルされて、プログラム実行前のカレントドライブに戻る」
というものでした。
それはテストによって確認したことですから確かなことなのですけれど、しかしまだ疑問が残ります。
カレントドライブ№は当然メモリ上のどこかに保存されているはずです。
しかし、それがユーザープログラム中で変更されても、プログラムが終了すると、「もとの状態に戻ってしまう」、というところが気になります。
おそらく、カレントドライブの記憶場所が複数あって、ユーザープログラム内で使われるもの以外に、システムによって保存されているものが別に存在しているのではないか、と推測されます。
そのあたりが、どうなっているのか、解析してみることにいたします。
●ファンクションコール０Ｅルーチン
下はファンクションコール０Ｅの処理プログラム部分です。
ファンクション０Ｅがコールされると、ＳＥＴＤＳＫ（アドレスＤ０４５Ｈ）が実行されます。
ＳＥＴＤＳＫでは、Ｅレジスタの値を１バイトの記憶場所ＡＣＴＩＶＥ（アドレスＣ７４２Ｈ）に書き込んでいます。
どうやらＡＣＴＩＶＥがユーザープログラムでのカレントドライブの保存場所のようです。
Ｅレジスタの値がすでにＡＣＴＩＶＥに入っていたとき（つまりＥレジスタで指定したドライブ№が現在のカレントドライブであったとき）はそのままリターンします。
それ以外のときは、ＬＯＧＩＮＤＲＶにジャンプします。
ＬＯＧＩＮＤＬＶはＳＥＴＤＳＫの上にあります（アドレスＤ０２１Ｈ）。
ＬＯＧＩＮＤＲＶでは、ＡＣＴＩＶＥに入れたドライブ№を、実際にＢＩＯＳコールして選択する（アドレスＤ０２ＤＨのＣＡＬＬ ＳＥＬＥＣＴ）とともに、ログインベクタを更新します。
ログインベクタについては、後日説明をいたします。
下はＳＥＬＥＣＴ（アドレスＣ７５９Ｈ）のエントリ部分です。
ＡＣＴＩＶＥから値をＣレジスタに入れて、ＢＩＯＳのＳＥＬＤＳＫをコールしています。
やはりＡＣＴＩＶＥに入れた値をもとにして、ドライブが選択されているようです。
そうすると、このＡＣＴＩＶＥの値が、ユーザープログラムが終了してシステムに戻ってきたときに、ユーザープログラムを実行する前の値に戻される、のではないかと思われます。
果たしてそうなのか、どうなのか。
ユーザプログラムにエントリするときと、ユーザープログラムからシステムにリターンしてきたときに、何が行なわれるのかを、確かめてみることにいたします。
こちらが、まさにその部分です。
アドレスＣ３５ＣＨのＣＡＬＬ ＴＢＡＳＥで、８１００Ｈ（本来は０１００Ｈ）にロードされたユーザープログラム（トランジェントプログラム）をコールしています。
そして、ユーザープログラムからリターンしてくると、その次のアドレスＣ３５ＦＨから後の処理が行なわれます。
ＣＡＬＬ ＴＢＡＳＥの直前にＣＡＬＬ ＳＥＴＣＤＲＶがあります。
’ｒｅｓｅｔ ｃｕｒｒｅｎｔ ｄｒｉｖｅ’というコメントがついています。
ここでカレントドライブに関する何かが行なわれているようです。
そしてユーザープログラムからリターンしてきた後に実行される部分には、ＣＡＬＬ ＭＯＶＣＤとＣＡＬＬ ＤＳＫＳＥＬがあります。
ここでもカレントドライブに関する何かが行なわれているようです。
下はＳＥＴＣＤＲＶとＭＯＶＥＣＤルーチンです。
ＳＥＴＣＤＲＶ（ｓｅｔ ｃｕｒｒｅｎｔ ｄｒｉｖｅの略だと思われます）では、１バイトの記憶場所ＣＤＲＩＶＥ（アドレスＣ３ＥＦＨ）の値の上位４ビットをユーザーコードにした上でＴＤＲＩＶＥ（アドレス８００４Ｈ。本来は０００４Ｈ）に入れています。
ここでまた新たな記憶場所ＣＤＲＩＶＥ（ｃｕｒｒｅｎｔ ｄｒｉｖｅの略か）とＴＤＲＩＶＥ（ｔｒａｎｓｉｅｎｔ ｄｒｉｖｅの略か）が登場しました。
ユーザープログラムから戻ってきたあとで実行されるＭＯＶＥＣＤ（ｍｏｖｅ ｃｕｒｒｅｎｔ ｄｒｉｖｅか）でも、ＣＤＲＩＶＥからＴＤＲＩＶＥに値が移されています。ここではユーザーコードは加えられません。
あれ？
ＡＣＴＩＶＥは出てきませんねぇ？
ＭＯＶＥＣＤの後ではＤＳＫＳＥＬが実行されています。
それではＤＳＫＳＥＬは？
ということで、サーチしてみましたら。
ファンクションコール０Ｅでした。
Ａレジスタの値をＥレジスタに入れて、Ｃレジスタに１４（０ＥＨ）を入れて、システムをコールしています。
Ａレジスタには、ＭＯＶＥＣＤでＣＤＲＩＶＥの値が入れられています。
ファンクションコール０Ｅは、ページトップでお見せしておりますリストのアドレスＤ０４５Ｈのルーチンです。
これで、ユーザープログラムの終了後にＣＤＲＩＶＥからＡＣＴＩＶＥに値がコピーされることがはっきりしました。
しかしいぜんとしてはっきりしていないことがあります。
ユーザープログラム開始前のＡＣＴＩＶＥには、いつ、何が入れられるのか？ということと、ＣＤＲＩＶＥには、いつ、何がいれられるのか？ということです。
’ＣＤＲＩＶＥ’で検索をかけてみました。
ここはＣＣＰ（Ｃｏｎｓｏｌｅ Ｃｏｍｍａｎｄ Ｐｒｏｃｅｓｓｏｒ）のエントリ部分です。
ここでＣレジスタの値がＣＤＲＩＶＥに入れられています（このＣレジスタにつきましては［第８３回］で説明をしています）。
そして、その後ＤＳＫＳＥＬをコールしています。
おお。
ＤＳＫＳＥＬではありませんか。
ＤＳＫＳＥＬはさきほど説明をいたしました。
ファンクションコール０Ｅです。
これでやっとつながりました。
ＣＡＬＬ ＤＳＫＳＥＬ
のすぐ上で
ＬＤ （ＣＤＲＩＶＥ），Ａ
が実行されていますから、
ここで（ＣＣＰのエントリ直後に）、ＣＤＲＩＶＥとＡＣＴＩＶＥにＣレジスタから同じ値が入れられています。
実はこのほかにもＣＤＲＩＶＥに値が入れられているところがあります。
ここは、上のリストのすぐ下、続きの部分です。
なんだかややこしいことをやっているようですが、ＣＣＰにエントリして、ａ＞またはｂ＞などと表示して、コマンド入力を受け付けている部分です。
ＧＥＴＤＳＫをコールしたあと、Ａレジスタの値をＣＤＲＩＶＥに入れています。
それでは、ＧＥＴＤＳＫは？
といいますと。
こちらがＧＥＴＤＳＫです。
これは、ファンクションコール２５（１９Ｈ）です。
ファンクションコール１９Ｈはログインディスク（カレントディスク）のナンバーを取得するファンクションです。
ファンクションコール１９Ｈの処理ルーチンはこちらです。
ここでは、ＡＣＴＩＶＥからＡレジスタに値を入れています。
むむ。
そういうことになりますと。
ここまでの検討の過程では、ＣＤＲＩＶＥがもとになっていて、そこからＡＤＲＩＶＥに値が移されるという仮定を立てていたのですが、必ずしもそういうことではなくて、逆にＡＣＴＩＶＥからＣＤＲＩＶＥへのコピーも行なわれるようです。
このあたりの考え方は、ちょっと不統一な気がしますが、そのようにしているのには何か意味があるのかも知れません。
ＣＤＲＩＶＥに値が入れられているところはもう1箇所ありました。
ＵＮＫＮＯＷＮというルーチンの中にあります。
このＵＮＫＮＯＷＮとは何ぞや？
ということになりますが、それを説明しようとしますと、またあちこち行ったり来たりしなければなりません。
とにかく滅多矢鱈あちこち複雑に入り組んでいます。
もう少しすっきり整理できなかったものか、と思います。
ま。自分のことを棚に上げておいて他人を批判することはできません。
えてして大きなプログラムはそういうことになりがちです。
他人が見ると、どこがどうなっているのか、さっぱりわからないなどということになります（自分が見てもわからなかったりして）。
そういうことですので、ここに至る検索の過程は省略することにいたしまして、ここは結果のみを申し上げますと、ＵＮＫＮＯＷＮというのは、コンソール入力されたユーザーコマンドを解析するルーチンです。
ＵＮＫＮＯＷＮつまり未知のコマンドです。
ここに来る前の段階で、コンソール入力された文字列がチェックされていて、先頭にＡ～Ｚ（ａ～ｚはＡ～Ｚに変換されています）の１文字＋’：’があると、そのＡ～Ｚの文字コード（４１Ｈ～５ＡＨ）を０１Ｈ～１ＡＨに変換した値がＣＨＧＤＲＶに入れられます。
そのあとに続く文字列が無い（つまり○：のみが入力された）場合には、ＣＨＧＤＲＶの値－１がドライブ№としてＣＤＲＩＶＥに入れられます。
おお。
ここはたとえば、
ａ＞ｂ：
というように入力したときの処理のようです。
そしてこの後でも、上で説明しましたＭＯＶＥＣＤとＤＳＫＳＥＬがコールされています。
以上をまとめてみますと、つぎのようになるかと思います。
１）ＣＤＲＩＶＥがカレントドライブ№を保持している
２）ＣＣＰにエントリした時にはＣレジスタの値がＣＤＲＩＶＥに入れられる。
３）アルファベット＋’：’のみを入力してカレントドライブを変更したときは、新しいドライブ№がＣＤＲＩＶＥに入れられる
４）ファンクションコール０ＥはＡＣＴＩＶＥを書き換える
５）上記２）および３）では同時にファンクションコール０Ｅが実行されて、ＡＣＴＩＶＥにも同じドライブ№が入れられる
６）ユーザプログラム終了後はファンクションコール０Ｅが実行され、そこでＣＤＲＩＶＥの値がＡＣＴＩＶＥにコピーされる
７）ＴＤＲＩＶＥ（アドレス８００４Ｈ。本来は０００４Ｈ）にはユーザー№＋ＣＤＲＩＶＥが反映される
８）おそらくファイル操作時のカレントディスクとしてはＡＣＴＩＶＥが参照される（ＧＥＴＤＳＫ参照）
１）については、逆にＡＣＴＩＶＥからＣＤＲＩＶＥにコピーが行なわれているところもありますので、ちょっと疑問も残りますが、大筋では上のような結論でよいか、と思います。
いやあ。
人様がお書きになったプログラムを解析するのは、本当に疲れます。
ワンボードマイコンでＣＰ／Ｍを！［第８９回］
２０１２．４．１２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る