ワンチップマイコン使用のＧ３ＲＵＨ互換モデム

ＲＳＶ９６解説書・改訂版

１９９３．０８．２０　ＪＳ１ＲＳＶ／吉田功

Ｇ３ＲＵＨモデムの簡略化から始まった、このプロジェクトですが、皆様のご協力を得て、なんとか復調率も十分に実用的なレベルまで来ましたし、プログラムも安定してきました。

ＲＳＶ９６ではプログラムが命なのですがＣＱ誌（1993年3〜5月号）の記事ではプログラムの具体的な解説は不向きと思われ割合されましたが、今回は具体的なプログラムを揚げ解説していきます。ちなみに、紹介したソースは解説を分かりやすくするために若干変更されています。単純に繋ぎ合わせても動作はしませんのであしからず。

■ 「８０Ｃ３１」というＣＰＵ

今回使用した、８０Ｃ３１は、インテル社の８０５１シリーズの１チップマイコンです。このシリーズの特徴は、ＣＰＵ内部に、ＲＯＭが４Ｋバイト（８０Ｃ３１には無い）、ＲＡＭが１２８バイト、パラレル入出力が最大８ビット×４組、非同期用シリアル入出力、タイマ、カウンタ、等が入っています。

８０５１シリーズは、内部にＲＯＭを持つ８７５１と、ＲＯＭが無い８０３１が有ります。ＲＯＭを持つ８７５１ですと外付けＲＯＭ回路が無用になるので大変コンパクトに仕上ります。反面、ＣＰＵの値段も高く（秋葉原で４０００−１００００円）、ＲＯＭの焼き込みも安価なＲＯＭライタでは出来ずに手が出し難くなっています。また、８０３１は、外付けＲＯＭが必要になり少々回路が複雑になりますが、ＣＰＵの値段も安く（１０００円未満）、ＲＯＭには通常の物が使えて開発がしやすいのが長所です。

今回は、回路は少々複雑になりますが、安くて開発のしやすい８０Ｃ３１（８０３１のＣ−ＭＯＳ版）を使いました。現時点では、回路的にもプログラム的にも安定してきたので、今後は８７Ｃ５１を使用して超小型の９６００ｂｐｓモデムを作れればと、考えています。

別に、この８０Ｃ３１で無くとも、ポピュラーなＺ８０等の汎用ＣＰＵでもモデムは作れそうですが、ＲＯＭ、ＲＡＭ、Ｉ／Ｏポートを外付けしなくてはならず回路規模がＴＮＣ本体のように少々複雑になってしまいます。また、８０５１シリーズは１チップＣＰＵの中では高速な部類に入ります。９６００ｂｐｓの信号を処理するためには、かなり高速なＣＰＵでないと耐えられません。Ｚ８０に例えると８〜１０ＭＨｚのクロックに匹敵するほどです。

■ ＲＳＶ９６回路（ハードウエア）解説

ブロック図ＲＳＶ９６では、Ｇ３ＲＵＨモデムのアナログ部分を除く全てをＣＰＵで処理させています。動作原理は基本的にＧ３ＲＵＨモデムと同様ですから、Ｇ３ＲＵＨモデムと同様の性能が得られる事になります。参考迄にＲＳＶ９６のハードウエアのブロック図（図１）を書いておきました。

●受信部のしくみ

受信部分はアナログ（ＬＰＦ）部分以外の全てはＣＰＵがやってしまいます。Ｇ３ＲＵＨモデムでは、ＰＬＬや、逆スクランブル回路が有りましたが、これらの仕事は全てＣＰＵ内部で行われています。

アナログ（ＬＰＦ）部分は、Ｇ３ＲＵＨモデムと全く同等の回路構成・定数設定にしてあります。Ｇ３ＲＵＨモデムとの比較の為にわざと同じ回路にしてみました。

ＲＳＶ９６では、プログラムの都合でモデムのクロックをＣＰＵ内部で生成します。その為に、９６００ｂｐｓ専用（ＣＰＵのクロックが１２ＭＨｚの場合）となっています。ＴＮＣから与えている９６００×１６（Ｈｚ）のクロックは見ていません。

●送信部のしくみ

送信される波形はアナログです。使用したＣＰＵに（８０Ｃ３１）にはＤＡＣ（デジタル→アナログ・コンバータ）が内蔵されていませんので外付けする必要がありました。それ以外は受信同様に極めてシンプルな構成になっています。

送信の場合は受信と違って、ＴＮＣ（ＳＩＯのＴＸＤＡ）から出力される信号の位相をモデム側で把握しておかないと、うまく送信されませんので、ＴＮＣから出力されるクロック（９６００×１６Ｈｚ）もモデム用ＣＰＵへ入力する必要があります。そのかわり、このクロックを可変することでモデムのボーレートを変化させる事も可能になります。ただし、ＣＰＵの速度的な問題で８０Ｃ３１（１２ＭＨｚ）では９６００ｂｐｓが限界です。

８０Ｃ３１のＩ／Ｏポートは、オープンドレイン＋内部プルアップ抵抗で出来ています。この為にＩ／Ｏポートから電流を流すと電圧降下が起きるので、Ｒ−２Ｒ等の抵抗型のＤＡＣを直接付けると出力の保証がされません。そこで、７４ＨＣ５４１というバッファー用のＩＣが付いています。

送信用のＬＰＦも受信同様の理由で、Ｇ３ＲＵＨモデムと同じ回路を使いました。

■　ＲＳＶ９６プログラムについて

フローチャートさて、肝心のソフトウエア部分の解説です。解説の都合上ソースリストからの抜粋ですが、Ｇ３ＲＵＨモデムを完全に理解していて、８０５１のアセンブラをマスターしていれば、これだけでも何をしているか理解出来ると思いますし、自力で完動するソースリストを作成する事も可能でしょう。解説用にプログラムが何をしているか簡単なフローチャート（図２）にまとめてみました。

●受信部のしくみ

Ｇ３ＲＵＨモデムの信号を受信するための要は、受信信号に含まれたクロックを取出す事です。Ｇ３ＲＵＨモデムではハードウエアによりＰＬＬで高分解能（０．４μ秒）を得ていましたが、そのままプログラム化するには速度的に難しい物がありますので、独自に考えて作りました。

※「クロック検出」部分の解説

モデムが持つクロックと、受信した信号が持つクロックとの位相が、遅れているか、進んでいるかを調べる部分です。１ビット（１０４μ秒）をウインドウ１と、ウインドウ２に時間的に分けて、２つのウインドウの間に、受信した信号のクロックの変化点が来るように、モデムのクロックの位相を変化（１ビット分の時間を変化させる）させます。

タイムチャートタイムチャートを書くと（図３）のような感じになります。ウインドウの間に受信した信号が変化（Ｌ→Ｈ、Ｈ→Ｌ）の有無で、次の「位相調節」を調節しています。

ウインドウ１で変化が有った場合は、内部クロックが、受信信号に対して短すぎるわけで、逆にウインドウ２で変化が有った場合は、長すぎるわけです。両方のウインドウに変化が無い場合もありうるので、この時は現在の位相を保持します。

スクランブル処理部分などのクロック検出用ウインドウの無い部分では、信号に変化が有っても検出されません。Ｇ３ＲＵＨモデムでは終止信号変化を見ていますので、動作としては違う物です。メリットとしては「ノイズに強くなる」のですが、反面「信号を補足しにくくなる場合がある」という欠点ももっています。使用した結果でも、復調率がＧ３ＲＵＨモデムを越える場合と、悪くなる場合があるようで一長一短です。

;*** WINDOW - 1 ウインド１の中でデータに変化が有ったか？
        mov     R4,P3        受信データ保存 (Bit.2)
        call    wait         待機 27uS
        mov     a,P3         受信データ取得 (Bit.2)
        xrl     a,R4         直前に取得したデータと保存したデータを比較
        anl     a,#100b      有効なデータは(Bit.2)だけにする
        mov     R5,a         変化が有ったかどうか保存する

;*** WINDOW - 2 ウインド２の中でデータに変化が有ったか？
        mov     R4,P3        受信データ保存 (Bit.2)
        call    wait         待機 27uS
        mov     a,P3         受信データ取得 (Bit.2)
        xrl     a,R4         直前に取得したデータと保存したデータを比較
        anl     a,#100b      有効なデータは(Bit.2)だけにする
        mov     R6,a         変化が有ったかどうか保存する


※「位相調節」部分の解説

９６００ｂｐｓでは、１ビットあたり１０４μ秒の周期でデータが伝送されます。ただ、この時間（位相）はモデムの個体差で微妙に違うので、受信している信号に合わせなくてはなりません。

「クロック検出」で得られた情報を元に、実際にモデムのクロックを一時的に変化させて位相を調整します。時間（位相）調整は、ハードウエア・タイマを使わずソフトウエアでタイマを使い、微妙な時間可変をしてみましたが、８０Ｃ３１（１２メガ）の場合は最短命令が１μ秒なので、その分解能はＧ３ＲＵＨモデムに比べて２．５倍粗くなります。

ソフトウエア・タイマを使った為に、ハードウエアでのボーレートの変更が出来ません。また、ＣＰＵのクロック（１２ＭＨｚ）に依存してしまうので、これの誤差が±１％を越えると復調率に影響してしまいます。

        mov     a,R5    ウインド１の変化状況
        jz      WAIT1   変化無し
        mov     a,R6    ウインド２の変化状況
        jnz     WAIT2   変化あり WIN1=1 WIN2=1
        sjmp    WAIT3   変化無し WIN1=1 WIN2=0

WAIT1   mov     a,R6    ウインド２の変化状況
        jz      WAIT2   変化無し WIN1=0 WIN2=0
        sjmp    WAIT4   変化有り WIN1=0 WIN2=1
WAIT2   sjmp    WAIT5   時間調整用のダミー

WAIT4   nop             位相（時間）の調整はｎｏｐ(１μ秒)
WAIT5   nop             の実行でやっている
WAIT3   nop

※位相調整の詳細

ウインド１ ウインド２ 時間調整 備考
変化無し 変化無し 0 クロック情報が得られないので変化させない
変化無し 変化有り +1 ループの時間を延ばして位相調整
変化有り 変化無し -1 ループの時間を縮めて位相調整
変化有り 変化有り 0 有り得ないので変化無し

※「逆スクランブル」部分の解説

Ｇ３ＲＵＨモデムには、送出信号のスペクトラムを拡散させて、エラーレートを減らすために「スクランブル（暗号化）」が掛かっています。

受信した信号のスクランブルを外すのもプログラムで行っています。プログラム的には実行時間を極力減らすために技巧を凝らした物になっていますが、それでも「位相調節」と合わせて４０μ秒程度も掛かっています。また、ビット演算が可能な８０Ｃ３１ですが、ビット間でのＥＸＯＲが出来ない為に８ビットレジスタを使っています。

        mov     a,RXSR2 #2のBit3のEXORを取る
        swap    a       処理の都合でBit3→Bit7へ移動
        xrl     a,RXDAT 入力データとEXOR
        xrl     a,RXSR3 #3とEXOR
        mov     c,ACC.7 Bit7だけ抜き取る
        cpl     c       反転
        mov     P3.1,c  データ出力

        mov     a,RXDAT 入力データ取得
        rlc     a       入力データをC(CarryFlag)へ移す
        mov     a,RXSR1 #1の内容を取得
        rlc     a       シフトする
        mov     RXSR1,a #1の内容を保存
        mov     a,RXSR2 #2の内容を取得
        mov     RXSR3,a #3はBit7だけ有効
        rlc     a       シフトする
        mov     RXSR2,a #2の内容を保存

        mov     c,P3.2    受信データ取得
        mov     RXDAT.7,a 受信データをBit7に保存


●送信部のしくみ

Ｇ３ＲＵＨモデムの送信部分も極めて簡単な構造になっています。これは、Ｇ３ＲＵＨモデムの最大の特徴でもある、ＲＯＭを使ったＦ．Ｉ．Ｒ．フィルタを使っているためです。これをプログラム化する場合も、Ｇ３ＲＵＨ（James Miller氏）が設計したＲＯＭデータを使う事で極めてシンプルなプログラムになっています。

プログラムは、「波形出力関連」と「データ処理関連」のプログラムが同時に別々に動いています。普段は別々に動かして、必要な時のみ双方の処理のタイミングを合わせることで、処理時間の短縮を計っています。

※「送信クロック」部分の解説

ＴＮＣから出してくる送信信号と間違い無く同期させるため、ＴＮＣから出るクロック（９６００×１６Ｈｚ）を取込んでいます。そのクロックをＣＰＵ内部のタイマ機能（ハードウエア）により１／４に分周して、波形出力用割込み信号として使っています。

※「波形出力」部分の解説

Ｇ３ＲＵＨモデムのＲＯＭには、Ｇ３ＲＵＨモデムが出す波形のデータが入っています。このデータは１ビットにつき４パターン用意されていますので、１ビット（１０４μ秒）に４つの波形パターンを出力しなくてはなりません。この波形出力に「送信クロック」の部分で得られた割込み信号を使って処理させています。

ＴＮＣから得たクロック（９６００×１６Ｈｚ）を１／４に分周すると、わずか２６μ秒となり、この間に波形をＲＯＭから取出し、ＣＰＵ外部に出力するのはなかなか大変です。送信部分は全体的に時間との戦いになり、良く考えてプログラムしても９６００ｂｐｓが限度となってしまいました。また、送信しながら受信出来ない（半二重動作）になってしまった理由も此処にあります。

TXout                   波形出力割り込み毎に実行される
        movx    a,@DPTR 波形データの読みだし
        mov     P1,a    波形データ出力
        inc     DPH     次の波形のデータ・アドレスの用意
        reti


※「スクランブル」部分の解説

データ処理は、波形出力関連のプログラムとは別に動いています。ただし、データをＴＮＣから取込む時に、「送信クロック」の割込み信号と同期させています。

スクランブルのプログラムは、受信用の「逆スクランブル」と似たような構成になっています。送信部の為の高速プログラミングの為に、受信部の「逆スクランブル」も結果的に早くなったというのが実状です。

        mov     c,P3.0  送信データ入力
loop    mov     a,DPH
        cjne    a,WAVEH,loop TNCのCLOCKと同期を取る
        mov     TXDAT.3,c    入力データをBit3に保存
        mov     a,TXSR2      #2のBit3のEXORを取る
        xrl     a,TXSR3      #3とEXOR
        xrl     a,TXDAT      入力データとEXOR
        mov     c,ACC.3      Bit3だけ取り出しC.Flagへ移す
        mov     a,TXSR1      #1取得
        rlc     a            シフトする
        mov     TXSR1,a      #1保存
        mov     a,TXSR2      #2取得
        rlc     a            シフトする
        mov     TXSR2,a      #2保存
        mov     TXSR3.3,c    C.Flagを#3へ保存 Bit3のみ使用


※「ＲＯＭアドレス計算」部分の解説

「波形出力」の為にＦ．Ｉ．Ｒ．のデータ格納アドレスの計算をします。このアドレス計算が極めて高速に行えるように、データを本来の順番と変更してあります。

        mov     DPL,TXSR1 #1の内容でROMの下位決定
        mov     DPH,R1    ROMの上位は波形で変更可能


送信波形のパターンは、８ＫバイトのＲＯＭを使用した関係で７種類しか入りません。波形の選択は、ＣＰＵに余っている入力ポートが無いために、ＤＡＣ部分のパラレルポートと共用して、電源入力時（リセット時）だけＤＩＰスイッチを確認するように出来ています。

■ 最後に（1997年8月記述）

以上、８０Ｃ３１を使ったＲＳＶ９６の解説でした。図はＣＱ誌からの取り込みです(^^；)　１９９３年のハムフェアーで配布する予定だった資料ですが、動作解説には余り興味を持たれなかったようなので、配布しないままで終わりました(^^;)　今回のＮｅｋｏ２で使ったＰＩＣの場合もほぼ同様の処理を行っています。リクエストが有りましたらＰＩＣ版を執筆しますのでご連絡ください。（でも、内容変わらないかも？）

HOME