(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５８９回］
●犯人はＤＭＡでした
前回はＮＤ８０ＺⅢで、［＊（Ｉ／Ｏ）］［ＳＩ］（１６進キーの３）を使って、ＲＳ２３２Ｃ受信のテストをしようとしたところ、ほとんど受信できずにハングアップしてしまいます、ということを書きました。
Ｚ８０ＢＡＳＩＣで、ＲＥＡＤ ＃１命令を使ったテストプログラムを実行させてみますと、全く問題無く、正しく受信できます。
Ｚ８０ＢＡＳＩＣでも、ＮＤ８０ＺⅢの［＊（Ｉ／Ｏ）］［ＳＩ］でも、同じことをやっているはずなのですが、なぜかＮＤ８０ＺⅢのモニタプログラムでのＲＳ２３２Ｃ受信だとハングアップしてしまいます。
どうにも原因がわかりませんでしたから、カメレオンＵＳＢ＋ロジアナで信号の動きをチェックしてみました。
カメレオンＵＳＢ＋ロジアナは［第３７４回］でご紹介いたしました。
すると、怪しいところがみつかりました。
前回の最後にお見せした波形です。
２３２Ｃセレクト信号がアクティブ（Ｌ）になって、ＰＩＣ１８Ｆ１４Ｋ５０に、２３２Ｃ受信データの送出を要求しています。
送信側はまだ送信を開始していませんから、ＰＩＣ１８Ｆ１４Ｋ５０は受信バッファエンプティを返します。
ＲＢ４（ＰＩＣＳＴＢ）が約１５μｓｅｃの間ＬになってからＨに戻っています。これが受信バッファエンプティのときの応答です。
ところが奇妙なことに、このＰＩＣＳＴＢがＬになっている期間の、Ｚ８０ＣＰＵのＩＯＲＱとＲＤとＤ５がＨになっていて、まるで無信号のように見えます。
そしてその後で、２３２Ｃセレクト信号がＬになりっぱなしになっています。
そしてそして、ＩＯＲＱとＲＤが繰り返しアクティブになって、まるで無限ループになっているかのように見えます。
なんでもない、正常なときの波形と比べていただければ、その違いは一目瞭然です。
前回、この怪しげな、間延びした波形をご覧になって、あるいはお気づきになられた方もいらっしゃるかと思います。
そうなのです。
犯人は、７セグメントＬＥＤのダイナミック表示を行うためのＤＭＡだったのです。
ＮＤ８０ＺⅢは（ＴＫ８０も同じ）、７セグメントＬＥＤをダイナミック点灯させるために、ＬＥＤ表示回路がＣＰＵの動作を一時的にほんのわずかな期間、停止させて、その間にメモリから表示データを読み出してＬＥＤに表示させています。
それがＤＭＡ（ｄｙｎａｍｉｃ ｍｅｍｏｒｙ ａｃｃｅｓｓ）です。
ＮＤ８０ＺⅢはこのための信号をタイマーＩＣの５５５で作り出して、それをＺ８０ＣＰＵのＢＵＳＲＱに入れています。
約１ｍｓｅｃに１回、１０～２０μｓｅｃのパルスがＢＵＳＲＱに入れられます。
Ｚ８０ＣＰＵはＢＵＳＲＱが入力されると、その間は命令の実行を中断して、メモリアクセスやＩ／Ｏアクセスに必要な信号や、データバス、アドレスバスをハイインピーダンスにして、ＢＵＳＡＫ信号をアクティブにします。
その間はＣＰＵ以外の回路が、メモリやＩ／ＯをＣＰＵの動作とは関係無くアクセスすることができます。
ＩＯＲＱはともかくＲＤはメモリアクセスにも使う信号ですから、そのＲＤが１０μｓｅｃ以上もの間、Ｈになりっぱなしということは、ちょっと考えられません。
たとえ暴走したとしても、ＣＰＵクロック６ＭＨｚに見合う間隔でＲＤはアクティブになるはずです。
とすると、犯人は、ＤＭＡ以外にはない、ということになります。
ＤＭＡは、ＢＵＳＡＫ信号がアクティブである期間に実行されます。
そこで、ＢＵＳＡＫを加えて、もう一度カメレオンＵＳＢ＋ロジアナで観測してみました。
おお。
まさにぴったり。
ビンゴです。
こういうことだったのです。
Ｚ８０ＣＰＵは、ＰＩＣ１８Ｆ１４Ｋ５０にＲＳ２３２Ｃ受信データを要求するために、２３２Ｃセレクト信号をアクティブにして、ＰＩＣ１８Ｆ１４Ｋ５０からの応答（ＰＩＣＳＴＢの立下り）を待ちます。
１０７５μｓの少し前のところで、ＩＯＲＱとＲＤがアクティブになっています。
ＰＩＣＳＴＢをチェックするためのＩＮ命令の実行です。
ここではまだＰＩＣＳＴＢはＨのままです。
その直後に、ＤＭＡが実行されました。
ＢＵＳＡＫがアクティブ（Ｌ）の間は、ＩＮ命令は実行されません（プログラムの実行はそこで一時停止しています）。
ＢＵＳＡＫがＨになると、プログラムの実行が再開され、再びＰＩＣＳＴＢのチェックのためにＩＮ命令が実行されます。
１０９０μｓを過ぎたところで、ＩＯＲＱとＲＤがアクティブになっています。
ところがちょうどその直前に、ＰＩＣＳＴＢ信号はＨになってしまっています。
ＰＩＣ１８Ｆ１４Ｋ５０は約束した通りに、１５μｓｅｃの間、ＳＴＢ信号をアクティブにして、バッファエンプティを出力したのですが、Ｚ８０ＣＰＵ側では、ちょうどその間、ＤＭＡのためにいわば瞬間的に目をつぶってしまって、そのＰＩＣＳＴＢ信号を見逃してしまったのです。
Ｚ８０ＣＰＵの側では、２３２Ｃセレクト信号をアクティブにしましたから、ＰＩＣ１８Ｆ１４Ｋ５０からのＳＴＢ信号をずっと待ち続けています。
ではＰＩＣ１８Ｆ１４Ｋ５０の方は何をしているのか、といいますと、これがまた悲しいことに、ＳＴＢ信号を出力し終えましたから、Ｚ８０ＣＰＵ側からの２３２Ｃセレクト信号がＨになるはず、ということで、これまたずっとそれを待ち続けているのです。
実はここのところは、以前はちゃんと動作していたはず、でした。
以前は、ＰＩＣ１８Ｆ１４Ｋ５０はＳＴＢをＨにすると、２３２Ｃセレクト信号がＨになることを確認することなくリターンしていました。
そのため、今回のように２３２Ｃセレクト信号がアクティブのままになっていると、ＰＩＣ１８Ｆ１４Ｋ５０は次のサイクルでふたたびＳＴＢをアクティブにします。
そこで、今度はＺ８０ＣＰＵ側もその信号をキャッチすることができていたのです。
しかし、その処理の甘さのせいで、Ｚ８０ＢＡＳＩＣの受信プログラムで、ときどきデータを落としてしまうという現象が発生しました。
そこで、ＰＩＣ１８Ｆ１４Ｋ５０のプログラムを修正して、ＳＴＢをＨにしたあと、２３２Ｃセレクト信号がＨになるまで待ってからリターンするように変更しました（［第５８３回］）。
今回は、その修正がかえってアダとなってしまいました。
しかし、それにしても、よくぞここまで見事にすっぽりはまってくれたものです。
狙ったってこうまで見事に当るものじゃありません。
それなのに、毎回必ずと言っていいくらいハングアップしたのですから、これを魔物の仕業と言わずして、なんと言いましょうぞ。
それはともかくとして、これにはまいりました。
ここまできて、土壇場でこんなことになってしまうとは。
実は、Ｚ８０ＢＡＳＩＣはエントリすると、ＮＤ８０ＺⅢのＬＥＤ表示のためのＤＭＡを禁止してしまうのです。
Ｚ８０ＢＡＳＩＣでは、表示にはＷｉｎｄｏｗｓパソコンのディスプレイを使いますから、もう７セグメントＬＥＤの表示は不要なのです。
それにＢＡＳＩＣインタプリタは実行に時間がかかりますから、ＤＭＡによって無駄な時間が消費されるのは避けたかったという理由からでもあります。
そのために、Ｚ８０ＢＡＳＩＣの２３２Ｃ受信プログラムはハングアップしなかったのです。
いっそ、ＮＤ８０Ｚモニタでも、２３２Ｃ受信のときは、ＤＭＡを禁止してＬＥＤ表示をブランクにしてしまいましょうか？
あるいは、ＰＩＣＳＴＢ信号をもっと長い時間アクティブにして、その間にＤＭＡが発生しても大丈夫なようにする、というテもあります。
いや、いや。
ＤＭＡを禁止する、というのはともかくとして、ＰＩＣＳＴＢを長くする、というのは面白くありません。
それに５５５の発振はＲＣですから、ある程度のバラつきは避けられません。
うむ。やっぱり、それは、やりたくありません。
もともと、ここのところは、余り賢くないなあ、と思っていました。
こういうことが明らかになってしまいますと、これはもう、なんとか別の方法にすることを考えなくてはいけません。
しかしＰＩＣ１８Ｆ１４Ｋ５０の端子は全部使い切ってしまっていますから、別の信号線を使って受信バッファエンプティを知らせる、ということができないのですよねえ。
バッファエンプティを知らせるために、ＳＴＢパルスを利用する、というのは、まあ、ぶっちゃけて言いますと、苦肉の策、だったのです。
信号線が無い？
うう。
待てよ。
なんとかなるのかも…。
昔の人はいいことを言いました。
頭は生きているうちに使え、って。
ま。もっとも、そのうち生きていても使えなくなる日がやってくるかも…。とほほ。
回路図を眺めていましたら、
おお。
ひらめきましたよ、なんとかなりそうな方法を。
本日は時間がなくなってしまいました。この続きは次回にさせていただきます。
２０１０．８．２２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る