標準TTLだけ(!)でCPUをつくろう!(組立てキットです!)
(ホントは74HC、CMOSなんだけど…)
[第182回]

●前回からの続きです

前回の終りに、loadプログラムを直しました。
もう一度、リストをお見せしましょう。



0007のIN命令で、PICからの情報をAレジスタに入力します。
その次の命令はRRCです。右に1ビットローティトする命令です。
Aレジスタのビット0がC(キャリー)フラグに入ります。
Aレジスタのビット0の1、0をチェックするために、ローティト命令がよく使われます。
C(キャリー)フラグが立っていたら、Aレジスタのビット0が1だということですから、まだPICには受信データが無いことを示しています。
そのときはまた0007に戻って、再びIN命令を実行します。

C(キャリー)フラグが立っていなければ、PICが受信データを出力しているという合図ですから、そのデータを読み込みます(0011のIN 94命令)。
その前に、CPUがBUSYであることをPICに知らせておくために、98にFEを出力します(出力のビット0をLにする)。

PICから受け取ったデータは、HLレジスタで示すメモリアドレス(M)に書き込みます。0013のMOV M,A命令です。
メモリアドレスを進めるために、INX H命令でHLレジスタの値を+1してから、PICにCPU READYを知らせるために、98にFFを出力します(出力のビット0をHにします)。

0007に戻って繰り返します。

前回、このプログラムはブートローダーではありません、と書きました。
ブートローダーとは、システムのプログラムを、その始めの部分だけ、まず読み込むための、簡単なロードプログラムのことです。
RAMだけしかない状態では、CPUは何もできません。
でも、たとえばいきなりTK80のモニタプログラムを、トグルスイッチを使って、パチパチやりながら、RAMに書いていくか、というと、それは余りに非能率です。疲れてしまいます。

TK80のモニタプログラムとか、あるいはもっと高級なBASICのシステムプログラムならば、ファイルネームをつけてSAVE、LOADしたり、チェックサム、とかベリファイとかといった芸の細かい処理もできます。
しかし、そういったレベルのロードプログラムも、またそれなりに大きなサイズのプログラムになってしまいますから、トグルスイッチをパチパチさせて書き込む対象ではありません。

そこで、今回のプログラムのように、ただ読み込むだけ、という簡単なプログラムを、RAMに書いて、まず実行します。
そして、その簡単なロードプログラムで、少し複雑なことができるプログラムをロードしてから、そのプログラムにジャンプして、こんどはあとからロードされたより複雑なプログラムによって、さらに大きなプログラムをロードする、といった手順で、簡単なプログラムのロードからはじまって、より複雑なプログラムの読み込みと実行をするように進める場合の、一番最初に実行されるのが、ブートローダーです。

ブートローダーは、ですから、ロードしたプログラムにジャンプする部分がなければならないのですが、今回のロードプログラムは、ひたすらロードするだけで、ロードしたプログラムにジャンプする部分がありません。ですからブートローダーではないのです。
では、こんな終りのないローダーで、使い物になるのか?といいますと、それが使えるのです。

「つくるCPU」はレジスタの状態が、いつも「丸見え」です。
プログラムをPICから受けとって、メモリに書いて行くと、HLレジスタのLED表示がカウントアップされていきます。
パソコンからプログラムを送信する段階で、そのプログラムが何バイトであるかはわかっていますから、送信が完了して、HLレジスタの表示が計算通りの表示で停止すれば、正しく受信できて、それがメモリに書き込まれていることになります。

そこで、メモリ書き込みモードにして、先頭の0000番地だけ、トグルスイッチを使って、C3に書き換えます。
C3はJMP命令のコードです。
そうしてから、リセットすれば、ロードした先頭アドレス(上のロードプログラムでは、0100)にジャンプして、そこからプログラムが実行されます。

●ブートプログラムの由来

参考までにブートプログラムの名前の由来です。
boot strap loaderというのが本来の名前です。
boot strapというのは、ブーツのクツヒモのことです。
靴のひもをつかんで、自分で自分を持ち上げる、というイメージが名前の由来です。

最初に簡単なローダーが働いて、だんだん大きなプログラムが自分自身の働きでロードされていく、という動作がそのようなイメージにつながったのでしょう(いくら力持ちでも、人間が自分で自分を持ち上げることはできませんけれど)。
WindowsのOSも、そのように、簡単なローダーからだんだんと複雑なプログラムのロードを重ねながら、ハードディスクからメモリにプログラムをロードしていきます。

●実際にプログラムをロードしてみました

AND、OR、XOR回路のテストプログラムです。



とても簡単なプログラムです。
この程度のプログラムならば、トグルスイッチをパチパチやって書いてもそれほど手間はかかりません。
そうなのですけれど、ひとつには、せっかく作った80アセンブラの動作テストと、232Cの送信テストを兼ねています。
ですから、簡単なプログラムですが、アセンブラでつくって、さきほどのロードプログラムをさきにパチパチやってメモリに書いて、実行させておいてから、パソコンから232Cで送信してみました。

●送信するためのASCIIファイル

前回書きましたように、232Cで送信するためには、バイナリコード(16進数コード)を文字に直して、ASCIIコードで送るようにします。そのためには、バイナリコードをASCIIに変換したファイルが必要です。
今回の80アセンブラのもとになった、Z80アセンブラは、純粋なバイナリファイルは作成しますが、ASCIIコードのファイルなどは、必要がなかったので、当然のことながら、作成するようにはなっていません。

そこで、また80アセンブラを追加修正して、ASCII変換ファイルも出力するようにしました。

これがバイナリコードをASCII文字に変換して出力したファイルです。


アドレス情報も改行コードもありません。
16進コードを文字に直しただけです。

じつは、こういうファイルの形式として、「インテルヘキサ」という形式があるのですが、そんな形式を採用すると、今回のような簡単なローダーでは役に立ちません。
できるだけ簡単なローダーで済ませるために、このような単純なファイル形式にしました。

●ファイルの中身をナマで見る

ところで、バイナリコードをASCII文字に変換したファイル(anatest1.htx)を、上ではメモ帳で見てみました。
しかし232Cで実際に送信されるはずのナマのコードで見たいときには、どうすればよいでしょうか?

最近は、MSDOSなどすっかり忘れられてしまったようですけれど、ファイルの中身をバイナリコードのまま、見てみたいときなどは、なんといってもMSDOSの出番です。
MSDOSのDEBUGコマンドを使います。


ついでに80アセンブラで作成される、肝心のバイナリファイル(オブジェクトファイルといいます)も、ちょいと見てみましょう。
マシン語コードだけの、メモリに書き込まれるときのそのままのイメージのファイルです。
こちらのファイル名は、anatest1.binです。
MSDOSだと、そんなファイルでも簡単に開くことができます。



上のASCIIコードのファイルとの違いがわかりますでしょうか?

説明がかなり長くなってしまいましたので、本日はこのあたりまでといたします。
次回はいよいよパソコンから232Cでファイルを送信するところの説明をいたします。
2009.3.12upload

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