ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第８３回］
●ＢＩＯＳの変更
前回からの続きです。
変更箇所は大きく分けて２つになります。
１つはデイスクドライブに関する定義をしているところです。
もう１つはディスクドライブをアクセスしているＢＩＯＳルーチンの変更です。
まず最初にディスクドライブの定義部分を変更します。
現行のＣＰ／Ｍソースプログラムは、［第７６回］で作成したＣＰＭ２２Ｊ．ＴＸＴです。
それをもとにして、ＣＰＭ２２Ｋ．ＴＸＴを作ります。
●ディスクドライブの定義部分の追加と変更
１）ＣＳＶ、ＡＬＶの追加と変更
ディスクサイズの変更とＢドライブの追加にともない、ＣＳＶ（チェックサムベクタ）とＡＬＶ（アローケーションベクタ）を追加および変更します。
下左が変更前（ＣＰＭ２２Ｊ．ＴＸＴ）で下右が変更後（ＣＰＭ２２Ｋ．ＴＸＴ）です。
変更前の
CSV00 EQU 0B880H
ALV00 EQU 0B888H
を、下のように追加、変更します。
CSV00 EQU 0B880H
ALV00 EQU 0B884H
CSV01 EQU 0B886H
ALV01 EQU 0B88AH
ＣＳＶ０１、ＡＬＶ０１はＢドライブのために追加しました。
ＣＳＶ、ＡＬＶについては［第３３回］で説明をしていますので、そちらを参照願います。
今回の変更により、ディレクトリは４セクタ、ブロック数は１２になりました。
２）ディスクパラメータの追加と変更
ディスクパラメータの追加と変更を行ないます。
下左が変更前で下右が変更後です。
まずはｄｒｉｖｅ Ｎｏ．１を追加します。
ｄｒｉｖｅ Ｎｏ．０の記述の下に、以下のようにｄｒｉｖｅ Ｎｏ．１の記述を追加します。
;drive No.1(b drive)
DEFW 0
DEFW 0
DEFW 0
DEFW 0
DEFW DIRBF
DEFW DPTOP
DEFW CSV01
DEFW ALV01
最後のＣＳＶ０１とＡＬＶ０１だけが、ｄｒｉｖｅ Ｎｏ．０と異なっていることに注意してください。
次にディスクパラメータを変更します。
ディスクサイズ、ディレクトリサイズを小さくしたための変更です。
変更するのは次の３箇所です。
DEFW 23
DEFW 31
DEFW 0C0H
を、下のように変更します。
DEFW 11
DEFW 15
DEFW 80H
最初の数値は、ブロック数が２４－１から半分の１２－１になったことによる変更です。
２番目の数値はディレクトリサイズが８セクタから４セクタになったことで、ＦＣＢ数４×８－１＝３１から４×４－１＝１５に変更になります。
最後の数値は、ディレクトリが２ブロックから１ブロックになったため、ディスク先頭からの位置が、ビットマップで１１００００００（Ｃ０Ｈ）から１０００００００（８０Ｈ）に変更になります。
各パラメータの意味と数値の根拠については［第１２回］と［第１３回］で説明をしていますので、そちらも参照してください。
●ＢＩＯＳルーチンの変更
Ｂドライブの追加によってＢＩＯＳルーチンも変更が必要になります。
●Ｂドライブの先頭アドレスを定義する
ＢドライブのＲＡＭ上での先頭アドレスを追加します。
DISKTOP EQU 8800H
の下に、次の行を追加します。
DISKTOP2 EQU 0A000H
●リブートルーチンの変更（Ｃレジスタをクリア）
ファンクションコール０Ｅのテストを進めていくなかで見えてきたことがあります。
カレントドライブ（カレントディスク）がどのように決められるのか、というあたりにちょいと疑問があったのですが、おそらくその解明に関係していると思われる動作です。
本来のＣＰ／Ｍでは、リブートしたとき、カレントドライブはＡドライブになります。
この場合ＡドライブにはＣＰ／Ｍシステムディスクが装着されている必要があります。
そしてそのシステムディスクからＣＰ／Ｍシステムプログラムの一部がメモリに再ロードされます。
しかし、今作業中のＣＰ／Ｍ仮システムでは、ＡドライブにはＣＰ／Ｍシステムはありません。
ＺＢ３ＢＡＳＩＣシステムにエントリしたときに、必要ならばＷｉｎｄｏｗｓのハードディスクから、ＣＰ／Ｍシステムプログラムをロードしてから、ＢＩＯＳのエントリルーチン（リブートルーチン）にジャンプします（この仕組みは将来は変わるかも知れません）。
そのため、リブートしてもＡドライブをセレクトすることは意識していませんでした。
でもいつもＣＰ／Ｍを起動すると、最初にＡドライブが選択されていました。
今回、Ｂドライブを追加したことによって、そのテストをしていくなかで、ＣＰ／Ｍ起動時にＡドライブが選択されていたのは「たまたま」そうなっていたに過ぎない、ということがわかりました。
こういうところがプログラミングの恐いところです。
「たまたま」動いてしまうことがよくあるのですよねえ。
それでデバッグ完了、のつもりになって納入すると、ユーザーのところにいってから、信じられないような、有り得ない誤動作が発生して悩んでしまう、などということがおこります。
今回もＢドライブを追加してからテストをしましたら、
むむむ。おかしいではないか？
という事態が発生してしまいました。
ある条件でリブートすると、Ａドライブが選択されません。
でもＣＰ／Ｍ起動時のＢＩＯＳのリブートルーチンは全く同じように実行されています。
あらためてＣＰ／Ｍのエントリ部分のソースプログラムを調べてみて、納得いたしました。
ＣＰ／Ｍはエントリ時にＣレジスタの値をチェックしていたのです。
Ｃレジスタの上位４ビットにはユーザー識別Ｎｏ．があって、下位４ビットがカレントドライブ№になっているようです。
現行のＢＩＯＳのリブートエントリールーチンを確認しましたら、Ｃレジスタは全くさわっておりませんでした。
ＺＢ３ＢＡＳＩＣからＣＰ／Ｍにジャンプするときに、ＺＢ３ＢＡＳＩＣのコマンド処理ルーチンの中でＣレジスタがクリアされていたようです。
Ｃレジスタの値が００のときにＡドライブが選択され、０１のときにＢドライブが選択されます（以下同様にして、０２ならＣドライブ、０３ならＤドライブ…が選択されます）。
［注記］Ｃレジスタの上位４ビットはユーザー№ですが、ユーザーによる使い分けは考えないことにしますから、それは０にしておきます。
そこで、ＢＩＯＳリブートルーチンに、Ｃレジスタクリアを追加します。
ＪＰ ＣＢＡＳＥ の前に、
ＬＤ Ｃ，Ａ
を追加します。
●ＨＯＭＥルーチンの変更
ホームポジションへのスキップルーチンもＡドライブだけに対して行なっていたところを、Ｂドライブに対しても行なうように変更します。
ＣＰＭ２２Ｊ．ＴＸＴ（上図左側）の以下の部分を
