(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第１８２回］
●前回からの続きです
前回の終りに、ｌｏａｄプログラムを直しました。
もう一度、リストをお見せしましょう。
０００７のＩＮ命令で、ＰＩＣからの情報をＡレジスタに入力します。
その次の命令はＲＲＣです。右に１ビットローティトする命令です。
Ａレジスタのビット０がＣ（キャリー）フラグに入ります。
Ａレジスタのビット０の１、０をチェックするために、ローティト命令がよく使われます。
Ｃ（キャリー）フラグが立っていたら、Ａレジスタのビット０が１だということですから、まだＰＩＣには受信データが無いことを示しています。
そのときはまた０００７に戻って、再びＩＮ命令を実行します。
Ｃ（キャリー）フラグが立っていなければ、ＰＩＣが受信データを出力しているという合図ですから、そのデータを読み込みます（００１１のＩＮ ９４命令）。
その前に、ＣＰＵがＢＵＳＹであることをＰＩＣに知らせておくために、９８にＦＥを出力します（出力のビット０をＬにする）。
ＰＩＣから受け取ったデータは、ＨＬレジスタで示すメモリアドレス（Ｍ）に書き込みます。００１３のＭＯＶ Ｍ，Ａ命令です。
メモリアドレスを進めるために、ＩＮＸ Ｈ命令でＨＬレジスタの値を＋１してから、ＰＩＣにＣＰＵ ＲＥＡＤＹを知らせるために、９８にＦＦを出力します（出力のビット０をＨにします）。
０００７に戻って繰り返します。
前回、このプログラムはブートローダーではありません、と書きました。
ブートローダーとは、システムのプログラムを、その始めの部分だけ、まず読み込むための、簡単なロードプログラムのことです。
ＲＡＭだけしかない状態では、ＣＰＵは何もできません。
でも、たとえばいきなりＴＫ８０のモニタプログラムを、トグルスイッチを使って、パチパチやりながら、ＲＡＭに書いていくか、というと、それは余りに非能率です。疲れてしまいます。
ＴＫ８０のモニタプログラムとか、あるいはもっと高級なＢＡＳＩＣのシステムプログラムならば、ファイルネームをつけてＳＡＶＥ、ＬＯＡＤしたり、チェックサム、とかベリファイとかといった芸の細かい処理もできます。
しかし、そういったレベルのロードプログラムも、またそれなりに大きなサイズのプログラムになってしまいますから、トグルスイッチをパチパチさせて書き込む対象ではありません。
そこで、今回のプログラムのように、ただ読み込むだけ、という簡単なプログラムを、ＲＡＭに書いて、まず実行します。
そして、その簡単なロードプログラムで、少し複雑なことができるプログラムをロードしてから、そのプログラムにジャンプして、こんどはあとからロードされたより複雑なプログラムによって、さらに大きなプログラムをロードする、といった手順で、簡単なプログラムのロードからはじまって、より複雑なプログラムの読み込みと実行をするように進める場合の、一番最初に実行されるのが、ブートローダーです。
ブートローダーは、ですから、ロードしたプログラムにジャンプする部分がなければならないのですが、今回のロードプログラムは、ひたすらロードするだけで、ロードしたプログラムにジャンプする部分がありません。ですからブートローダーではないのです。
では、こんな終りのないローダーで、使い物になるのか？といいますと、それが使えるのです。
「つくるＣＰＵ」はレジスタの状態が、いつも「丸見え」です。
プログラムをＰＩＣから受けとって、メモリに書いて行くと、ＨＬレジスタのＬＥＤ表示がカウントアップされていきます。
パソコンからプログラムを送信する段階で、そのプログラムが何バイトであるかはわかっていますから、送信が完了して、ＨＬレジスタの表示が計算通りの表示で停止すれば、正しく受信できて、それがメモリに書き込まれていることになります。
そこで、メモリ書き込みモードにして、先頭の００００番地だけ、トグルスイッチを使って、Ｃ３に書き換えます。
Ｃ３はＪＭＰ命令のコードです。
そうしてから、リセットすれば、ロードした先頭アドレス（上のロードプログラムでは、０１００）にジャンプして、そこからプログラムが実行されます。
●ブートプログラムの由来
参考までにブートプログラムの名前の由来です。
ｂｏｏｔ ｓｔｒａｐ ｌｏａｄｅｒというのが本来の名前です。
ｂｏｏｔ ｓｔｒａｐというのは、ブーツのクツヒモのことです。
靴のひもをつかんで、自分で自分を持ち上げる、というイメージが名前の由来です。
最初に簡単なローダーが働いて、だんだん大きなプログラムが自分自身の働きでロードされていく、という動作がそのようなイメージにつながったのでしょう（いくら力持ちでも、人間が自分で自分を持ち上げることはできませんけれど）。
ＷｉｎｄｏｗｓのＯＳも、そのように、簡単なローダーからだんだんと複雑なプログラムのロードを重ねながら、ハードディスクからメモリにプログラムをロードしていきます。
●実際にプログラムをロードしてみました
ＡＮＤ、ＯＲ、ＸＯＲ回路のテストプログラムです。
とても簡単なプログラムです。
この程度のプログラムならば、トグルスイッチをパチパチやって書いてもそれほど手間はかかりません。
そうなのですけれど、ひとつには、せっかく作った８０アセンブラの動作テストと、２３２Ｃの送信テストを兼ねています。
ですから、簡単なプログラムですが、アセンブラでつくって、さきほどのロードプログラムをさきにパチパチやってメモリに書いて、実行させておいてから、パソコンから２３２Ｃで送信してみました。
●送信するためのＡＳＣＩＩファイル
前回書きましたように、２３２Ｃで送信するためには、バイナリコード（１６進数コード）を文字に直して、ＡＳＣＩＩコードで送るようにします。そのためには、バイナリコードをＡＳＣＩＩに変換したファイルが必要です。
今回の８０アセンブラのもとになった、Ｚ８０アセンブラは、純粋なバイナリファイルは作成しますが、ＡＳＣＩＩコードのファイルなどは、必要がなかったので、当然のことながら、作成するようにはなっていません。
そこで、また８０アセンブラを追加修正して、ＡＳＣＩＩ変換ファイルも出力するようにしました。
これがバイナリコードをＡＳＣＩＩ文字に変換して出力したファイルです。
アドレス情報も改行コードもありません。
１６進コードを文字に直しただけです。
じつは、こういうファイルの形式として、「インテルヘキサ」という形式があるのですが、そんな形式を採用すると、今回のような簡単なローダーでは役に立ちません。
できるだけ簡単なローダーで済ませるために、このような単純なファイル形式にしました。
●ファイルの中身をナマで見る
ところで、バイナリコードをＡＳＣＩＩ文字に変換したファイル（ａｎａｔｅｓｔ１．ｈｔｘ）を、上ではメモ帳で見てみました。
しかし２３２Ｃで実際に送信されるはずのナマのコードで見たいときには、どうすればよいでしょうか？
最近は、ＭＳＤＯＳなどすっかり忘れられてしまったようですけれど、ファイルの中身をバイナリコードのまま、見てみたいときなどは、なんといってもＭＳＤＯＳの出番です。
ＭＳＤＯＳのＤＥＢＵＧコマンドを使います。
