(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第２３８回］
●あれ？ブートプログラムが違ってる？
前回（［第２３７回］）、ブートプログラムのアドレスを変更しましたよ。というお話をいたしました。
毎度のことなのですけれど、一晩寝て朝になってからあらためて読みなおすと、おかしなことに気がついてしまうのですねぇ。
ほんとに困ったものです。
前回は、アドレス変更前のブートプログラムのリスト（メモリアドレス００００が開始アドレスになっています）と、開始アドレスを１０００に変更したリストを両方お見せしています。
で。
開始アドレス（ＯＲＧの部分）と受信したデータ（プログラム）を格納するアドレスをプログラムで指定している、最初のＬＸＩ Ｈの部分をちょいちょいと直しました。
と書いたのですけれど、両方のリストを見比べてみましたら、
あれま、プログラムサイズが違ってるじゃないの？これって、どういうこと？
もとのプログラムのエンドアドレスは、００１Ｂです。
それに対して変更後のプログラムのエンドアドレスは１０２１になっています。
開始アドレスを１０００にしただけですから、エンドアドレスは１０１Ｂのはず。
よくよく見てみると、もとのリストは、作成日付が、０９／０３／１０と０９／０３／１１になっています。
ところが、変更後のリストを見ると、０９／０３／１１がありません…。
どうやら、ソースを間違えてしまいました、ようです。
まっ。よくある話です…。
などと済ませられればよいのですけれど、こういうミスを納品でやってしまうと、大変です。
もう、すみません、すみません、すみまっせんっ。
って平謝りでプログラムの差し替えをすることになります。
もう、二度と過ちは繰り返しませんので、平にご容赦を…。
などと、不祥事の記者会見の定型文みたいなメールを送らなくてはいけません。
こういうことのないように、古いファイルは全部削除してしまうか、つねに上書き更新にすればよいのですけれど、そうすると、変更したらかえって異常な動作になってしまったので、もとに戻ってやり直したい、とか、気がついたら、最終ファイルまで削除してしまっていた、などという、それこそ取り返しのつかないことになったりする危険があります（事実、そういう悲しい体験もしっかりしてしまっています、です）。
ま。あれです。
えっ、と。プログラムを修正したり変更したりするときは、こういうみっともないことをしないように、お互い気をつけましょーね、というサンプルです。
過去にさかのぼって調べてみましたら、どうやら［第１８０回］でお見せしたプログラムをもとに変更作業をしてしまったようです。
この最初のブートプログラムは、その次の［第１８１回］の終りのところで、「最後のＬＯＯＰ２は冗長なので、そこのところは削除しました」と書いています。
うーん。みごとに、ぜーんぶ、きれいさっぱりと、忘れてしまいますですねー。まあ、ほんとに、我ながらあきれてしまいます。
えー。
ことのついでに、なぜ冗長なのかを説明しておきましょう（そうでもしないと、きまりが悪くて、引っ込みがつきません）。
●説明のために、もう一度ブートプログラムのリストです
ＰＩＣがＵＳＢ−ＲＳ２３２Ｃ変換回路を経て受信したデータをＰＩＣ内部で８ビット１バイトのデータにして、それをＣＰＵにパラレルで渡します。そのデータ伝送は複数の制御線を使ってハンドシェイクで行われます。
ハンドシェイクというのは、送信側と受信側が互いに相手の動作を確認しながらデータの受け渡しをする方法で、手間がかかりますがデータを落としてしまう心配がありません。
これに対して、タレ流し式といっている方法は、受信側の状態を確認することなく、送信側が適当な遅延を入れて一方的に送ってしまう方法です。受信側が十分速くないと、データを落としてしまいます。
ＰＩＣからのデータは８ビットパラレルで送られます。
ＣＰＵ側はそのデータをＩ／Ｏアドレス９４から読み込みます。
ＰＩＣはデータをセットしたことをＣＰＵに知らせるために、Ｉ／Ｏアドレス９８のｂｉｔ０のラインをＬにします。
ＣＰＵはアドレス９８のｂｉｔ０を見ていて、それがＬ（＝０）になったら、これからデータの読み込み処理をしますよ、ということをＰＩＣに伝えるために、アドレス９８のｂｉｔ０をＬ（＝０）にしてから、アドレス９４からデータを読み込み、ＨＬレジスタで示すメモリアドレスに書き込みます。
ここまでが、１００７〜１０１４までの部分です。
ここにはＰＩＣの側の動作は出てきませんが、ＰＩＣはアドレス９８のｂｉｔ０出力を監視していて、それがＬになったら、データセット信号（アドレス９８のｂｉｔ０入力）をＨに戻します。
なお、同じ９８のｂｉｔ０を入力と出力の両方で使っていますが、「つくるＣＰＵ」のＩ／Ｏ回路は、互いに独立している入力と出力回路に、同じアドレス９８を割り当てていますから、Ｉ／Ｏの外側は全く別の配線になっていて、それぞれＰＩＣの別の端子に接続されています。
そして最後に、１バイトのデータのメモリ書き込み作業が完了したことをＰＩＣに知らせるために、アドレス９８のｂｉｔ０出力をＨ（＝１）にします。
ＰＩＣは、そのＣＰＵからの信号を見ていて、アドレス９８のｂｉｔ０出力がＨになったのを確認したら、次のシリアルデータ受信〜ＣＰＵへのパラレル出力動作に入ります。
［注記］ここのところの説明に不正確なところがありました。次回（［第２３９回］）で訂正していますので、そちらもお読みください。
ＣＰＵは、ＬＯＯＰ２のところで、ＰＩＣからのデータセット信号、アドレス９８のｂｉｔ０入力がＨになるのを待ってから、次のデータ読み込みのためにＬＯＯＰに戻ります。
このようにしないと、前のデータセット信号のままなのに次のデータセット信号だと間違えて２度読みをしてしまう可能性があるからです（ここのところがウソです）。
完全なハンドシェイクです。冗長なところはないように思えます。
が、よーく、文章を読んでみると、あれえ、なんだかおかしくね？というところに気がつきます（ませんか？）。
タイミングチャートで説明しましょう。
上側の図が、ＬＯＯＰ２の部分の根拠になったタイミングチャートです。
でも、実はそうではなくて、ＰＩＣからの出力、９８（ｉｎ）ｂｉｔ０は、下側の図のタイミングで変化するのです（そうそう、読みなおしてみましたら、［第１８１回］の説明で、ちゃんと「下側の図」をお見せしていました）。
ＰＩＣは９８（ｉｎ）ｂｉｔ０をＬにしたあと、９８（ｏｕｔ）ｂｉｔ０を監視していて、それがＬになったらすぐに自分の出力、９８（ｉｎ）ｂｉｔ０もＨにしてしまいます。ＰＩＣのクロックは４ＭＨｚとわりとゆっくりしたクロックにしてありますが、それでもこの応答は速く行われ、５μｓ程度でＨになります。
ＣＰＵの側は、ＩＮ ９４、ＭＯＶ Ｍ，Ａ、ＩＮＸ Ｈ、ＭＶＩ Ａ，ＦＦ、ＯＵＴ ９８、と、これだけの命令を実行してから９８（ｉｎ）ｂｉｔ０を見に行くのですから、そのときには、もうＰＩＣからの出力は確実にＨになってしまっています。
ですから、ここのＬＯＯＰ２の部分は冗長なのです。
いや、実は、冗長どころか、ＰＩＣの側の次のデータの出力処理がもしすばやく行われたならば、かえってハングアップの危険さえ出てきます。
今回のプログラムは幸いＲＳ２３２Ｃの受信データがもとになっていますから、ＰＩＣからのデータ出力も、ＲＳ２３２Ｃの受信に同期して行われます。
もともとシリアル受信はＣＰＵのデータ処理速度に比べるときわめて低速ですから、今回の場合には、冗長ではあっても、特にハングアップの危険があるわけではありません。
でも、まあ、ムダなものをそのままにしておく必要はありませんから、ここはもう一度削除することにいたします。
２００９．６．２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る