■パソコンリンクの機能
ザウルスの内部にはデータを格納するメモリエリア、ファームウェアに類する物を格納するメモリエリア、ICカード上のメモリエリアなどがあり、それぞれ固有のドライブ番号が割り当てられています。
それぞれのドライブには機能データやアドインなどのデータファイルが格納されています。
パソコンリンクはドライブとファイル名の組み合わせによりザウルス関連ファイルの全てを送受信する機能を持っています。
通常通信の場合はザウルス側のメニューでオプションポート15通信で選択できる物しか送受信できず、ザウルスネット通信記録やアドイン、設定ファイルといったものは送受信できません。
パソコンリンクを使えばドライブ上のファイルリストの取得により設定ファイル等の隠されたファイル名まで把握することができます。
また、オプションポート15の通常通信はノンパリティ、Xフローという冗長性の無いものですが、パソコンリンクはブロック単位の転送で各ブロックにはチェックサムが付けられチェックサム比較によるエラーチェック、エラー発生時のリトライまで定義されておりそのシーケンスに従えば通信エラーによる中断を極力回避することができます。
■パソコンリンクの危険性
パソコンリンク・プロトコルはザウルス内の全てのファイルを操作できる強力なもので、使い方を誤ると内部ファイルを破壊する可能性と、ゴミファイルを内部に残す可能性がありますので、通信プログラムを実際に組まれてテストする際は事前にザウルスのデータを全てバックアップする等の自衛策を取って下さい。
なお、これまでZauBASE の転送試験で無茶してますが、ザウルス本体機能そのものに損傷を与えたことはないので(全初期化すれば元に戻るということです)神経質になる必要はないと思いますが(^_^;
■パソコンリンク・プロトコルの基本要素
パソコンリンクはコマンド(CFV,CFF,CFD,CFU,CFC,CLE)リクエスト(RFV,RFF,RFD,RFU,RFC)アンサー(AFV,AFF,AFU,AEX,DOK,ANG)という3つの要素から成り立ちます。
コマンドを送りザウルスの応答準備を指示し、リクエストでザウルス内のドライブとファイル名を指定します。
そして、実行結果はアンサーとして返されます。
■パソコンリンクでできる操作
コマンド | レスポンス | リクエスト | アンサー | |
ファイルの確認 | CFV | DOK(ANG) | RFV+ファイル名 | AFV(ANG) |
ファイル情報取得 | CFF | DOK(ANG) | RFF+ファイル名 | AFF+ファイル情報 |
ダウンロード | CFD | DOK(ANG) | RFD+ファイル名 | AEX(ANG) |
アップロード | CFU | DOK(ANG) | RFU+ファイル名 | AFU+ファイル内容 |
削除 | CFC | DOK(ANG) | CFC+ファイル名 | AEX(ANG) |
パソコンリンク解除 | CLE | DOK(ANG) |
■アドイン・ダウンロードのための手順
ここではアドインをザウルスに転送する際の手順を例にパソコンリンクプロトコルを解説します。
- ザウルスにアドイン機能があるかの確認
- 機種確認(PI4500識別)
- ザウルス内に同じ名前のアドインが登録されていないか?
- アドインファイル名の転送
- アドイン本体の転送 (複数のファイルがあるときは4−5を繰り返します)
- パソコンリンクの解除
完全なモニタリストはこちらをご参照下さい。
■CFV コマンド送信(RFV リクエストが使えるか確認)
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 03 00 | データ長(0003hバイト) |
→ | 43 46 56 | CFV(コマンド) |
→ | DF 00 | チェックサム |
■通信確認のための制御コード交換
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■CFV に対するアンサー
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 03 00 | データ長 |
← | 44 4F 4B | 文字列"DOK" |
← | DE 00 | チェックサム |
◆正常時の応答は"DOK"
◆異常時の応答に関しては後述
■通信確認のための制御コード交換
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
■RFV リクエスト(ファイルの存在確認)<アドイン機能搭載機種か?>
このRFV で、NIFADR.BOX(NIFTY
接続先)ファイルが存在するかをチェックします。
存在するなら、この機種はPI4500以降(アドイン搭載機種)となります。
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 14 00 | データ長 |
→ | 52 46 56 0A 00 00 53 31 3A 4E 49 46 41 44 52 2E 42 4F 58 00 | RFV S1:NIFADR.BOX |
→ | 81 04 | チェックサム |
◆RFV におけるファイル名のフォーマット
"RFV" | 0A 00 00 | "S1:" | "NIFADR.BOX" | 00 |
要求データバイト | ドライブ名 | ファイル名 | 定数 |
■通信確認
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■RFV に対するアンサー
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 0D 00 | データ長 |
← | 41 46 56 FF 00 10 02 3F 00 00 11 00 00 | AFV |
← | 3E 02 | チェックサム |
◆正常応答 "AFV" (そのファイルは存在する =
アドイン機能あり)
◆それ続く10バイトはRFVコマンドで指定した要求データバイト数
■通信確認
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
■CFF コマンド送信 (RFFリクエストが使えるか)
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 03 00 | データ長 |
→ | 43 46 46 | CFF |
→ | CF 00 | チェックサム |
■通信確認
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■CFF に対する応答 "DOK" は正常応答
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 03 00 | データ長 |
← | 44 4F 4B | 文字列"DOK" |
← | DE 00 | チェックサム |
■通信確認
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
■RFF (ファイル情報取得) <PI4500識別>
このRFF で、"S7:"という内部ドライブ(本体Bに該当)にNIFADR.BOX(NIFTY接続先)ファイルが存在するかをチェックしましす。
存在するなら、この機種はPI5000以降となります。
もし存在しないなら、この機種はPI4500で、その場合は転送できるアドインサイズのチェックが必要になります。
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 11 00 | データ長 |
→ | 52 46 46 53 37 3A 4E 49 46 41 44 52 2E 42 4F 58 00 | "RFFS7:NIFADR.BOX" |
→ | 6D 04 | チェックサム |
◆RFF におけるファイル名のフォーマット
"RFF" | "S7:" | "NIFADR.BOX" | 00 |
ドライブ名 | ファイル名 | 定数 |
■通信確認
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■AFF (ファイル情報応答) <S7:にNIFADR.BOXに関する情報があればPI5000以上>
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 2C 00 | データ長 |
← | 41 46 46 4E 49 46 41 44 52 20 20 20 42 4F 58 | AFFNIFADR BOX |
← | 20 20 20 20 36 38 32 38 20 20 20 20 20 | 6828 |
← | 39 35 2D 31 30 2D 33 31 20 31 33 3A 33 32 | 95-10-31 13:32 |
← | 0D 0A | CR + LF |
← | 89 08 | チェックサム |
◆AFF におけるファイル名フォーマット
AFF | xxxxxxxx | S | xxx | S | 9999999 | SSSSS | YY-MM-DD | S | HH:MM | CR+LF |
ファイル名本体 | 拡張子 | サイズ | 日付 | 時間 | ||||||
C(3) | C(8) | C(1) | C(3) | C(1) | N(7) | C(5) | C(8) | C(1) | C(5) | C(2) |
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■同一名アドインのチェック
CFF-DOKレスポンス
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 03 00 | データ長 |
→ | 43 46 46 | CFF |
→ | CF 00 | チェックサム |
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 03 00 | データ長 |
← | 44 4F 4B | 文字列"DOK" |
← | DE 00 | チェックサム |
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
◆ZTEST2.BAS というアドインがザウルス内に存在するか?
純正のダウンローダでは、プログラムというよりは、データ保護を目的として上書きを禁止しているようです。(同名のアドインを削除しないと転送できません)
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 11 00 | データ長 |
→ | 52 46 46 53 31 3A 5A 54 45 53 54 32 2E 42 41 53 00 | "RFFS1:ZTEST2.BAS" |
→ | 6C 04 | チェックサム |
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■存在しない場合の応答 "ANG" (存在する場合は"DOK" が返るので、上書きを防止するなら転送を中止する)
← | 18 | <CAN> |
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 06 00 | データ長 |
← | 41 4E 47 53 30 32 | "ANG" + "S02" |
← | 8B 01 | チェックサム |
◆<CAN>応答時の特殊制御コード交換
なぜか、通常のACK-ENT-ACK-ENQではなく、変な応答が返ってきます。
← | 04 | <ENT> |
← | 05 | <ENQ> |
→ | 05 | <ENQ> |
→ | 06 | <ACK> |
→ | 06 | <ACK> |
プログラム組むときは応答を適切に行うか、<CAN>応答時は ACK-ENT-ACK-ENQではなくて、ENT:ENQ-ENQ:ACK:ACKで応答するようにすれば良いはずです。
いろいろなケースでモニタしてみましたが、必ず<CAN>応答はこうなります。
◆正しいかもしれない応答
以下のように考えると
どのデータに対しての応答か | |||
← | 18 | <CAN> | |
→ | 05 | <ENQ> | <CAN>に対してその原因を送信するように指示するENQ |
← | ANGブロック | ||
→ | 06 | <ACK> | |
← | 04 | <ENT> | |
→ | 06 | <ACK> | |
← | 05 | <ENQ> |
<CAN>応答の時は「みなし」で ENQ を送ってくるようです。
■ファイルのダウンロード(パソコンからザウルスへ)
やっとここから、アドインダウンロードの本編です。
CFF-DOKレスポンス
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 03 00 | データ長 |
→ | 43 46 44 | CFD |
→ | CD 00 | チェックサム |
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
← | 01 | <SOH> |
← | 01 FE | データブロック番号 |
← | 03 00 | データ長 |
← | 44 4F 4B | 文字列"DOK" |
← | DE 00 | チェックサム |
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
■RFD (ダウンロードリクエスト)
→ | 01 | <SOH> |
→ | 01 FE | データブロック番号 |
→ | 11 00 | データ長 |
→ | 52 46 44 53 31 3A 5A 54 45 53 54 32 2E 42 41 53 00 | "RFDS1:ZTEST2.BAS" |
→ | 6A 04 | チェックサム |
◆RFD におけるファイル名のフォーマットは RFVと同じ
RFD の場合は、まず、ファイル名を送信し、次に実際のデータ部分を転送します。
◆連続してデータブロックを送信する場合の応答
← | 06 | <ACK>(正常受信) |
連続してデータを送る場合、<ACK> に対しては<ENT> ではなく、<SOH> を返すことでデータが継続していることを通知します。
→ | 01 | <SOH> |
→ | 02 FD | ブロック番号に注目 |
→ | 2D 00 | データ長 |
→ | 52 46 44 FF 00 00 00 34 00 00 4B | "RFD" + データ |
→ | 00 00 00 00 00 00 00 00 00 00 0D 00 01 13 3A 27 | |
→ | 1E 10 41 42 43 44 45 46 47 61 62 63 64 65 66 67 | |
→ | 0D FF | |
→ | AE 08 | チェックサム |
← | 06 | <ACK>(正常受信) |
→ | 04 | <ENT>(送信完了) |
← | 06 | <ACK>(正常受信) |
→ | 05 | <ENQ>(送信要求) |
■AEX (ダウンロード正常終了応答)
ファイルが正しくザウルスに格納された場合"AEX"を返します。
← | 01 | |
← | 01 FE | |
← | 03 00 | |
← | 41 45 58 | "AEX" |
← | DE 00 |
→ | 06 | <ACK>(正常受信) |
← | 04 | <ENT>(送信完了) |
→ | 06 | <ACK>(正常受信) |
← | 05 | <ENQ>(送信要求) |
■次のファイル送信(同じパターンで送信)
"CFD" | |
←ACK →ENT ←ACK →ENQ | |
←SOH "DOK" | |
→ACK ←ENT →ACK ←ENQ | |
→SOH "01 FE" + "RFDS1:ZTEST2.BAI" | ZTEST2.BAIというファイルを送信 |
←ACK | |
→SOH "02 FD" + "データブロック1" | |
←ACK | |
→SOH "03 FC" + "データブロック2" | |
←ACK →ENT ←ACK →ENQ | |
←SOH "AEX" | ファイル受信を完了した場合"AEX"を返す |
→ACK ←ENT →ACK ←ENQ | |
→SOH "CLE" | パソコンリンク解除 "CLE" |
←ACK →ENT ←ACK →ENQ | |
←SOH "DOK" | |
→ACK ←ENT →ACK ←ENQ |
これで、アドインのダウンロード完了、ザウルス側はザウルスリンクが解除されます。
■お約束のご注意
この解析は私が独自に行ったもので、内容についての保証はありません。
また、メーカー等に問い合わせることはしないようにお願いしますm(_
_)m