|
■とりあえず受信 まだ不安定要素はあるが、とりあえず受信できるようになった。 PC側のターミナルソフトからキーインすると、MSXに表示される。 1バイト受信してはBASICに渡すだけの最小限の機能だけなので、あまり早い処理はできない。手入力であれば追随できるが、ファイル送信では、1文字毎に50ミリ秒程度の遅延を入れる必要がある。1文字当たり0.05秒かかるので1秒間に20文字、160bps程度の転送速度か。 100 '================ 110 'SERI_RB.BAS 120 '================ 130 SAVE "SERI_RB.BAS" 140 CLEAR 200,&HBFFF:BLOAD"SERI_RB.OBJ" 150 DEFINT A-Z:DEFUSR=&HC000:A$="" 160 D=USR(0):D$=CHR$(PEEK(&HC003)) 170 IF D$=CHR$(13) THEN PRINT A$:END 180 A$=A$+D$ 190 GOTO 160 ■処理手順 (1) 入力線がHIGHになっているか確認。HIGHでなければ、HIGHになるまで待つ。 (2) LOWになるのを待つ。 (3) ちょっと待って、1ビット目を取り込む。 (4) (3)を計8回繰り返して1バイトのデータを得る。 厄介だったのは、(3)の「ちょっと待って」の部分である。少し処理を変えるたびにウエイトループの定数を変更しないといけない。結局、ステート数計算は断念し、試行錯誤で定数を決めた。 ■問題点 速度については、むやみに高速化を求めるよりも、MSXらしく十分遅く処理することで対処したい。とはいえ、現状ではカセットテープからの読み込みより遅いような気がする。これを酔狂と、いつまで笑ってられることやら。 精度については、MSXどうしの通信であれば送受信とも柔軟に対応できるので、なんとかなるさ、と考えている。PCからの受信は、まだちと厳しいなあ。 残る問題として、受信の際、なぜか漢字が文字化けする。送信ではANKモードで文字化けし、受信では漢字モードで文字化けするっていうのは、なんだかなあ。通信方法が単純ななだけに、タイミング以外に原因の見当がつかないのが困るっぽい。 ■まとめ まだ不完全ではあるものの、MSXどうしの通信に進みたい。実装に当たっては、2本に分かれている送受信プログラムの一本化も考えたい、と考えているところである。 |
全体表示
-
詳細
コメント(0)
|
MSXの受信側プログラムを書いているところだが、予想どおり難航中。 ステート数を数えたりしているが、なかなかうまくタイミングが取れない。 イライラしているところに、イライラするCMに出くわしたので、八つ当たり気味に紹介しておく。 サッポロビール「オフの贅沢」。 見慣れない店のまえで男が足を止める。入ってみると女将が飲み物メニューを差し出す。 「ふつう」 と 「贅沢」。 男が「ふつう」と答えると、女将は「あら、意外」。「じゃ、贅沢」と答えると、「単純」。 ムカッ。「どないせえっちゅうんじゃっ! ワシは帰る!」と、自分なら席を蹴るところである。 サッポロビールは何を考えてこんなCMを作ったのか? とき前後して、サッポロビールの社長が傷害容疑告訴で書類送付されるという「事件」が起きた。 酔っ払った社長が「感謝の意を表すため」、お店の女性のほおを両手ではさむように叩いたとされている。 同社は「手で挟んだ、という認識」としているが、たとえ本当に感謝の意を表すためとはいえ、人前で女性の顔に手を触れるなんてことを普通、するかい? というわけで、サッポロビールは「普通じゃない」というオチがついてしまった次第である。 なもんで、受信側プログラムがうまくいかない今日この頃である。 |
|
http://art17.photozou.jp/pub/378/247378/photo/29483151_org.v1258647991.gif
■実体配線図 MSXの汎用入出力ポートの8ピンは、起動時LOWである。一方、RS232Cぽい通信では、無信号時はHIGHで、スタートビットのLOWにより通信が開始される。 8ピンの状態を無信号時HIGHに反転するため、74LS14を加えている。74LS04でもいいと思うが、波形がしゃきっとするような気がする。伝送が遅延するというウワサは気にしない。 ■送信波形 9600bpsにおける1bitの信号幅は約104μ秒。一方、MSXの1ステートは0.294μ秒。 従って、1bitの信号幅で処理できるステート数は、 104μ秒 ÷ 0.2794μ秒 ≒ 373 により、約373ステート分となる。 例えば「NOP」は本来4ステートのところ、MSXではマシンサイクル1回に付き1ステートのウエイトが入るので、計5ステートとなる。 373 ÷ 5 ≒ 75 により、9600bpsにおける1bitの信号幅は、NOPを約75回実行した長さに相当する。 以上をもとに、アセンブラソースのステート数を数えようと思ったが、面倒になってきた。 というわけで、スタートビットの立下りからストップビットの立上りまでの計算上の時間(938μ秒)と同じような波形になるよう、ウエイトループを調整した。 どうせ信号幅の許容誤差3〜5%のおおらかな通信仕様であり、結果オーライである。 ■奇妙な現象 ところで、奇妙な現象に気づいた。 普段からSONYのHBI-J1を用いて漢字モードを常用しているのだが、試みにANKモードで試してみると、なぜか文字化けが増加する。 機械語プログラムでは、割り込み禁止してPSGを直接操作しているので影響ないはずである。 BASICプログラムでも大したことしていないので、影響が出るとは思えない。 今後の原因究明が待たれる。待っていて解決するのか知らんが。 ■今後の展開 ひとつはPCとの連携。もうひとつはMSXどうしの連携。いずれも、MSX側の受信環境を整える必要がある。 受信は送信に比べ、難易度が格段に高くなる。 また、turboRへの対応も必要かなと思うが、一時的にZ80モードにすればええのんとちゃう? と気乗り薄である。 |
|
■BASICプログラム
前回に書いたとおり、送信したい文字列はUSR関数の引数として渡す。 MSXの場合、文字列は255文字までという制限に留意すべきである。 今回は、「引数として文字列をUSR関数に渡す」という仕様にしたため、このような制限がある。これにこだわらなければ、アセンブラソースを書き換えて、16ビット長のデータも扱えるはずである。 今回のテストしたプログラムは次のとおり。 100 '================ 110 ' SERI.BAS 120 ' SERIAL OUT TEST 130 '================ 140 'SAVE "SERI.BAS" 150 CLEAR 200,&HBFFF:BLOAD"SERIBAS.OBJ" 160 DEFUSR=&HC000:LF$=CHR$(10):CR$=CHR$(13) 170 FOR I=32 TO 126 180 D$=CHR$(I):D$=USR(D$) 190 NEXT 200 D$=USR(CR$):D$=USR(LF$) ">http://art19.photozou.jp/pub/378/247378/photo/29294606.jpg MSXは、SONYのHB-F900を使用。写真右下の赤い小さなブレッドボードがインターフェース。 MSX本体に載っている左側画面はMSXのモニタ。右側がSA-1Fパソコン。文字コード32〜126の文字を表示している。ターミナルソフトは「Tera Term PRO」。MSX風に青地に白文字にしてみた。 http://art19.photozou.jp/pub/378/247378/photo/29275986_org.v1258227281.gif パソコン側で受信しているさまをGIFアニメにしてみた。少〜し実際よりも早目に表示されている。 マシン語部分の転送速度は9600bpsであるが、BASICの部分で時間がかかっている。1文字ずつ送信しているためであって、送信データをまとめてバッファに格納し一気に送信すれば9600bpsの実力が発揮できるはずである。 受信側のパソコンの処理能力に余裕があるのでフロー制御なしでも大丈夫であるが、パソコンからMSXに送信する場合は、データの取りこぼしが予想される。 MSXの受信プログラムも書こうと思っているが、たいてい受信側のほうが面倒なんだなあ。 |
|
以前から考えていたものの、なかなか着手せずにいた、MSXによるシリアル通信に着手。 ■1 仕様 (1) ベースはBASIC やっつけ仕事に柔軟に対応できるBASICをベースとする。当然、USR関数による引数渡し。 CLEAR 200,&HBFFF:DEFUSR=&HC000 A$="ABC":DUMMY$=USR(A$) てな調子である。 (2) RS232Cっぽい仕様 転送速度は9600bps固定。スタートビット1、データビット8、パリティなし、ストップビット1。フロー制御なし。 なぜ9600bps固定かというと、転送タイミングを機械語命令数に依存しているため。 今どきの機器は9600bpsでも十分こなせるはず。 PC/AT互換機のシリアルポートに似ていることもあり、例によって汎用入出力ポートを使用。 (3) RS232Cぽくない仕様 12Vレベル変換は行わず、TTLレベルのまんまとする。 今どきの機器は、内部では5Vとか3.3Vで処理しているくせに、シリアルポート部分だけは12Vに上げたり下げたりしている。んな面倒なことはしない。 ■2 ソフトウエア ざっと仕様を書いたところで、アセンブラソースを書き始める。いつものとおり、ASM.COM用である。 動作の概略は次のとおり。 (1) USR関数の変数型チェック。文字列でなければリターン。 (2) 文字列の長さをチェック。ゼロならリターン。 (3) 文字列の長さがゼロになるまで、信号を送出する。 ※ここまでは、「MSX2テクニカル・ハンドブック」と、ほぼ同じ。PSGレジスタ#15のデータ保存を紛れ込ませている程度の改変。 (4) まず8ピンを下げて、ストップビットの送出。 (5) LSBから順番に8ピンを上げ下げ。 (6) 最後に8ピンを上げて、ストップビットを送出。 ※「上げ下げ」とソースコードが逆ではないかと思っている人がいるかもしれないが、その点は後述。 (7)サブルールーチンは、PSGレジスタ#15のデータセーブ。8ピンの上げ下げ。ウエイトループ。 ※NOP命令を繰り返しているが、DJNZで結構時間を喰ってしまい、大味なウエイトループになっている。もうちょびっとウエイトがほしいので、ループ外にもNOPを足している。 ■3 ハードウエア (1) 主な部品 ・Dサブ9ピンコネクタ(メス):金属部分を外して、ポートに接続しやすくした。 ・74LS14:MSXの起動時点では8ピンはLOWであることに後から気が付いて、論理を反転するために入れたもの。このため、上述のソフトウエアの論理をもう一度反転するさせた。考えてみれば、サブルーチンの中で反転しておけば読みやすかったかもしれない。CPLなんて命令も入っていて、まるで「反対の反対なのだ!」状態である。 ・USBシリアル変換アダプタ:ここではFT232RLを使ったsparkfunの製品を使用。 (2) 結線 ・MSXの5VとGNDを74LS14に結線。 ・MSXの8ピンを74LS14の1ピンに結線。 ・74LS14の2ピンをアダプタのRXに、GNDをGNDに結線。 ・パスコンとかプルダウンは適宜。 ■まとめ さて、どうなることやら。続きはコマーシャルのあとで。 http://art19.photozou.jp/pub/378/247378/photo/29273001.jpg 赤くてかわいいブレッドボード。これがインターフェース。 74LS14とsparkfunのFTDI Basic Breakout(5V)が載っている。後者は秋月のUSB-シリアル変換モジュールも使えるはず。 |



