ＣＲＴ/VGAIF+KEYIF+SDCARDIFボードの製作
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
ＷｉｎｄｏｗｓパソコンにＵＳＢ接続して使う現行方式はそれなりに便利ではありますが、ときとしてＷｉｎｄｏｗｓ
のしがらみから開放されて、小さいながらも独立した一個のパソコンとして機能したいと思うこともあります。
昔はそれが普通のことだったのですが、安価なＣＲＴディスプレイが生産中止となって久しい今日ではそれ
は叶わぬことと諦めていたのですが…。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
［総合第４５回］
●ＲＳ２３２Ｃのテスト（ＲＥＡＤ＃、ＷＲＩＴＥ＃）
ＲＳ２３２Ｃ通信はＵＳＢ経由ではありませんがＵＳＢインターフェースに使っているＰＩＣ１８Ｆ１４Ｋ５０の機能を利用しているため、プログラムとしてはＷｉｎｄｏｗｓパソコンに対してキーボード入力を要求したり画面表示データを送ったりするのと同じような処理をすることになります。
独立型ではキーボード入力、画面表示などをＰＩＣ１８Ｆ１４Ｋ５０を介さないで、キーボードインターフェース、ＣＲＴ/VGAインターフェースに対して行ないます。
しかし２３２Ｃ通信についてはＵＳＢ接続型と同じようにＰＩＣ１８Ｆ１４Ｋ５０を通じて行ないます。
そこのところがうまく交通整理できているかどうかをテストしました。
テストはＺＢ３ＢＡＳＩＣの２３２Ｃ送信、受信プログラムを使って行ないました。
こちらはＮＤ８０Ｚ３．５独立型セットです。
ＮＤ８０Ｚ３．５は試作基板をまだ大切に使っています。
組立キットのＬＳＩを出荷前にテストするために、テストソケットを使っています。
こちらは２３２Ｃ通信の相手側です。
こちらはＮＤ８０ＺⅢをＵＳＢ接続型で使います。
ＮＤ８０Ｚ３．５とＮＤ８０ＺⅢは９ピンのクロスケーブルで接続しています。
どちらもＺＢ３ＢＡＳＩＣプログラムを使います。
ＮＤ８０ＺⅢは最初に受信して次に送信の順で、ＮＤ８０Ｚ３．５は逆に最初に送信して次に受信の順で行ないます。
受信側を先に実行します。
こちらはＮＤ８０Ｚ３．５（独立型）の画面です。
テスト中なのでＲＡＭにロードしたシステムを起動しています。
７ＦＦＦの値を書き換えることができましたからシステムがＲＡＭ上で動いていることが確認できました。
ＳＤカードの２３２Ｃテストプログラムをロードしました。
先に送信してから次に受信するプログラムです。
ＮＤ８０ＺⅢのプログラムとは順序が逆になっています。
先にＮＤ８０ＺⅢのほうをＲＵＮさせてから、こちらのプログラムを実行しました。
送信と受信が正しく行なわれました。
ＮＤ８０ＺⅢのほうも正しく実行されました。
これで独立型ＺＢ３ＢＡＳＩＣの２３２Ｃ送信命令（ＷＲＩＴＥ＃）、受信命令（ＲＥＡＤ＃）が正しく実行されることが確認できました。
でもついでですので、こんどは双方のプログラムを入れ替えて、逆の順序でテストをしてみました。
さきほどＮＤ８０ＺⅢが実行したのと同じプログラムをＮＤ８０Ｚ３．５（独立型）にロードしました。
今度はＮＤ８０Ｚ３．５（独立型）を先にＲＵＮしました。
ＮＤ８０ＺⅢにはさきほどＮＤ８０Ｚ３．５が実行したプログラムをロードしました。
先にＮＤ８０Ｚ３．５のほうをＲＵＮしてから、ＮＤ８０ＺⅢをＲＵＮさせました。
送信、受信が正しく行なわれました。
こちらはＮＤ８０Ｚ３．５（独立型）の画面です。
こちらも正しく実行されました。
●ＲＳ２３２Ｃのテスト（ＩＮＰＵＴ＄）
ＺＢ３ＢＡＳＩＣのＩＮＰＵＴ＄には２つの機能があります。
１つは前回説明しましたように、指定した文字数の文字をキーボードから入力する機能です。
もう１つはキーボードの代わりにＲＳ２３２Ｃ回線から受信する機能です。
後者の場合はＩＮＰＵＴ＄の第２パラメータとして＃１をつけます。
テストプログラムをロードしてＲＵＮしました。
ＮＤ８０ＺⅢは送信側です。
先ほどのテストプログラムを利用します。
送信を完了したらそのままプログラムを終了するように、ＳＴＯＰ文を追加しました。
ＮＤ８０ＺⅢ側の送信プログラムを実行しました。
送信が完了してブレイクしました。
ＮＤ８０Ｚ３．５の側は？
受信の途中で停止しているようです。
なぜでしょう？
もう一度ＮＤ８０ＺⅢ側のプログラムを実行しました。
やっぱり同じです。
４文字受信したところで止まってしまいます。
どうやらそれから後ろのデータは落ちてしまうようです。
さては？
思い当たるところがありましたので、［Ｃｔｒｌ］＋［Ｂ］でブレイクしました。
ＣＬＳ（Ｃｌｅａｒ Ｓｃｒｅｅｎ）コマンドで画面クリアします。
画面クリアしてからもう一度ＲＵＮしました。
ＮＤ８０ＺⅢの送信プログラムをもう一度実行しました。
今度は正しく受信できました。
ＲＳ２３２Ｃ受信はＰＩＣ１８Ｆ１４Ｋ５０を使って行なっていますが、ＰＩＣ１８Ｆ１４Ｋ５０はそのほかにＵＳＢ通信も行なうため、２３２Ｃ受信に多くの資源は割けません。
独立型ではＵＳＢ通信は使いませんが同じＰＩＣ１８Ｆ１４Ｋ５０をそのまま使いますから２３２Ｃについては同じです。
ＣＰＵ側が受信データの引き取りに遅れると受信したデータを落としてしまいます。
上の例では、ＣＰＵ側は画面の最下行で受信データの表示を行なうため、１文字受信ごとに画面全体を上に１行分スクロールしています。
毎回１画面２０００文字の移動を行なわなければならないため、その時間が原因で受信データが落ちてしまいました。
再テストでは画面をクリアしてスクロールしない状態で受信したのでデータを落とさずに受信することができました。
十分な受信バッファを用意して、時間がかかる処理をしている間でもデータを受信するようにできるとよいのですけれど、いろいろな制約の中でこういう機能になっていることをご理解ください。
ＣＲＴ／ＶＧＡＩＦ＋ＫＥＹＩＦ＋ＳＤＣＡＲＤＩＦボードの製作［総合第４５回］
２０１７．４．１１ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る