■ASK光通信プロトコル
このプロトコルはPIシリーズの赤外線通信に必要なものです。
MIシリーズの場合はマイクロソフト赤外線通信ドライバが対応している赤外線インタフェースを利用する場合にはプロトコルを意識する必要はありません。
オプションポート１５の通信は比較的単純で、ターミナルや通信ソフトでも通信できるのですが、ASK光通信にはプロトコル（通信制御手順）というものが存在します。
このプロトコルを正しく解釈して、プログラムに反映させないと正常な通信はできません。
現在、光通信に関する公式情報はソフトバンク刊：ザウルスSUPER TOOLS のＣＤＲＯＭに収録されている、過去に「ザウル出現Mark2 添付FD」収録されていたデータが存在します。（技術評論社：「ざべ(The BASIC) 」１９９５年７月号にも光通信解説記事もあります。）
通信タイミング関係はこちらの内容を参考にしています。
ただし、上記文書には欠落があり、そのままの情報を利用しても転送が正常にできない場合があります。
通信に使うシリアルポートの設定
9600,O,8,1 (9600BPS、奇数パリティ、データ８、ストップ１ビット）
調歩同期、半二重通信
フロー制御は「なし」でよいパリティが奇数である点が曲者でOSによっては設定できない場合があります。
光通信は半二重通信です。
制御コードを交換することで、送信側、受信側を切り替えます。
下の例では、送信側をパソコン、受信側をザウルスとした場合の例です。
逆の場合もありますが、そのときはこのプロトコルを逆に適用して下さい。
■通常のデータブロック
| 方向 PC->ZAU |
内容 | 意 味 |
| → | ENQ | ザウルスが受信できる状態か確認 |
| ← | SYN | ザウルスは受信可能である |
| → | ヘッダ | データブロックを送るためのヘッダ |
| ブロック番号 | 0001〜FFFFhまでインクリメント | |
| 01 04 FE | 定数 | |
| データ長 | 0〜512(200h)まで | |
| データ本体 | この部分はテキストデータ | |
| チェックサム | データ本体部分のチェックサム | |
| ← | ACK | 正常受信できたことを示す |
通常のブロックは上記を１単位としてデータが終わるまで繰り返されます。
ENQ,SYNなどのコントロールコードや、ヘッダ部分にはプリアンプル・コードがつきますので、こちらをご参照の上、実際のデータパターンをご理解下さい。コントロールコードの送受信タイミング等は後述します。
■最終データブロック
| 方向 | 内容 | 意 味 |
| → | ENQ | ザウルスが受信できる状態か確認 |
| ← | SYN | ザウルスは受信可能である |
| → | DH | データブロックを送るためのヘッダ |
| ブロック番号 | 最終ブロックはFFFFh（固定） | |
| 01 04 FE | 定数 | |
| データ長 | 0〜512(200h)まで | |
| データ本体 | この部分はテキストデータ | |
| EOF | (1Ah)データの最後を表す | |
| チェックサム | データ本体+EOFのチェックサム | |
| ← | ACK | 正常受信できたことを示す |
最終ブロックに関しては、ブロック番号がFFFFh（２番目のブロックが最後だとしても、FFFFh）になることと、データ本体の最後にEOFが付加されることが、通常ブロックとの違いです。
EOF を埋め込むタイミングですが、本来はザウルスのデータを受信した時にEOF を付加してファイルに保存するべきですが、配布されているデータ中にはEOFが含まれない場合がありますので、転送前にファイルをチェックして最後にEOFを追加するようにした方が良いと思います。
これは、データ長が５１２バイトの時、特殊処理が必要になりますが、プログラミングの際EOFがファイル中に付加されていないことが前提になると余分な処理をする必要が生じプログラムの手間と、処理速度の低下を招くためです。（特殊処理は後述）
通信開始時のシンクロ
- 相手機器が通信可能になっているかをサンプリングする(ENQの送信）
- ENQを送信して500ms以内にSYN レスポンスが返らない場合は再度ENQ を送信する
- SYNが返らない場合、ENQ送信の繰り返しは６分間続く
- SYN が返ってきたら、実際のデータを送信する
データブロックの構成
| 内容 | 実データ | バイト数 | 意味 |
| 光通信データヘッダ(DH) | 00 00 00 00 00 96 81 10 | 8 | 定数扱いで良い |
| ブロック番号 | 01 00 | 2 | ブロック番号は1から順次カウントアップされる 下位-上位バイトの並び |
| デバイスコード他 | 01 40 FE | 3 | 01 制御コード 40 デバイスコード FE ？？？？？？？ （定数扱いで良い） |
| データ長 | 02 00 | 2 | 実際のデータブロックの長さ 00 00 〜 02 00 |
| データ本体 | テキストファイルをバイナリ イメージで転送 |
0〜512 | ファイル内容をそのまま送信 |
| チェックサム | XX XX | 2 | データ本体部の単純加算チェックサムの 下位２バイト |
ENQ （ザウルスが受信できる状態か確認）を送った時の応答
| 正常応答 | SYN | ザウルスは受信可能である |
| 異常応答 | CAN | ザウルス側で通信中止 |
| その他 | 信異常が発生したとして処理 （無データも含む） |
異常応答時の処理
通信キャンセルの場合は通信処理を終了する
その他の場合は最初のデータブロック転送時には６分間、２番目以降のデータブロックの場合は１０秒間、500ms間隔でSYNを送信し、応答が返るのを待つ
応答が返らなければ、通信異常が発生したものとして通信処理を終了する
データブロックを１ブロック送信後の応答
| 正常応答 | ACK | ザウルス側は正常に受信完了 |
| 異常応答 | NACK | 通信異常の原因がチェックサムであることを示す リトライ処理を行う |
| その他 | 信異常が発生したとしてリトライ処理 （無データも含む） |
異常応答時の処理
- リトライ処理を行う
- ENQの送信から始め、エラーが発生したブロックを再度送信する
- ※リトライの回数
２回（最初のデータ転送を併せて３回）行い、それでも転送不可能なときは、通信を中断する。
経験者からのアドバイス
転送タイミングに関しては、ms単位で指定があるものの通常の処理を行う限りシビアになることはありませんが、ENQ-SYN に関しては最優先処理が必要です。
実際にZauBASE のプログラムを組む際には、ENQ-SYN 500ms の部分のみインターバルタイマを利用してチェックを行っています。
| 通信状態 | 通信タイミング、リトライ、中断条件 | |
| シンクロ時 | →ENQ ←SYN |
ENQ 送信後、受信側が500ms 以内にSYN
を返さない場合は、ENQ を再送しSYN
が返るまで初期リンク時６分間、通常時１０秒間ENQ
再送を繰り返す。 受信側はENQ 待ち状態になり、初期リンク６分間、通常時１０秒以内にENQ が送られてこない場合通信中断となる。 |
| データ転送時 | ←SYN →DH |
SYN が戻った後、送信側が200ms 以内に DH以降のデータを送る必要がある。 受信側は、SYN 送信後、400mS 以内にDH 以降のデータを受信できない場合はリトライ処理に入る |
| 正常受信確認時 | →DATA ←ACK |
受信側はデータブロックの最後の１バイトを受信後、400ms
以内にACKを送信する必要がある。 送信側はACK が送られてくるのを１秒待ち、ACK がこない場合はリトライ処理をする。 データブロックを転送するときは、送信側は４秒以内に全てのデータを転送する必要がある。（9600BPS なら十分この制限をクリアできる） 受信側は最初の１バイト受信後、５秒間データブロックを受信し続けるが、５秒以内にデータブロックの最後まで受信できないときはリトライ処理する。 |
データの最後に EOF(1Ah) を付加することを忘れないようにして下さい。
シャープの純正インタフェースを利用した場合、光通信エコー（送信したデータがそのまま、受信データとなる）がありますので、それを考慮したプログラムが必要になります。
また、ノートＰＣ等に内蔵されているIrDA-ASK互換インタフェース、PCMCIAカードタイプのインタフェースについては、CS（ハードウェアフロー）を有効にすると、ハングアップするものがあります。
原因は良くわからないのですが、CSを無効にすると正常に通信できます。
シリアルポートのフロー制御については、テキストデータの通常通信時のみXon,Xoffを指定し、それ以外はNon で大丈夫です。
参考文献：ソフトバンク株式会社 ZAURUS Super Tools PIRICA編 付録CD-ROM