日立 MB-S1 SASI-HDD接続作戦 その4 (ソース転送で躓く)

S1のSASI-HDD接続作戦のその後です。

MS-DOS上のクロス環境でclock_rtcモジュールのソース入力&修正を行い、クロスアセンブラでエラーゼロまで持って行ったのでS1実機にソースファイルを転送したところでハマってしまいました。

転送元はB16LX上で動作しているMITERM。
転送先はS1/30の/T1ポート(標準ACIA)です。

転送ツールが無いので、普通のコピーコマンドを使い データ転送&ファイル書込みを行いました。

クロス環境で編集したclock_rtcモジュールのソースを転送すると、必ず同じ場所でOS-9側が#244エラーを出してコピー停止になります。

転送速度は現状のS1用OS-9では一番高速な2400bpsです。
(Oh!FM誌掲載の拡張コピーコマンドcpyでも全く同じ結果になりますので、copyコマンドの問題ではなさそう)
B16からの送信条件はこんな感じで、送信ウェイト設定は8*0.5秒で約4秒とライトビジー対策はOKと思われます。

条件を変えながら転送してみるとボーレートが遅いほど#244エラーが発生しやすくなる傾向があり、ちょっと予想外です。

送信ウェイトは12*0.5秒の約6秒にしても全く改善されないので、ライトビジーの問題ではなさそうです。

転送時にエラーが発生してしまう部分はこちらで、 特段おかしなコードではないと思います。

*
*RTC Write Routine 
*
のコメント3行目のアスタリスクを送ると100%の再現性で#244エラーが発生し、コピー停止^^;;;
100%の再現性なので何か原因があるはずです。

何度やっても同じなので、最近趣味用に入手したラインモニタを使って、何かヒントはないかモニタしてみました。

エラーが発生している部分をモニタすると、
こんな感じで、特におかしなコードは送ってなさそうです・・・・^^

AE5131B  ch1:RS-232C        DATA&STATE  JIS8      BLK 00001/00002 D_LN 0288/0305
ＴＤｕｌｓ△ａ  ，  ｐ  ｃ              CR  ＊  CR  ＊△ＲＴＣ  △  Ｗ  ｒ  ｉ
ＲＤ          △  ｐ  ｕ  ｌｓ△ａ，ｐｃ  CR  ＊  CR          ＊  △  Ｒ  Ｔ  Ｃ
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111
ＴＤｔ  ｅ  △  Ｒ  ｏ  ｕ  ｔ  ｉ  ｎ  ｅ          CR＊    CR  ｔｍｗｒｉｔｅ△
ＲＤ  △  Ｗ  ｒ  ｉ  ｔ  ｅ  △  Ｒ  ｏ  ｕｔｉｎｅ    CR＊  CR
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111
ＴＤｅｑｕ△＊CR△ｓｔａ△ａｄａｔａCR△ｌｄａ△＃＄３ｅCR△ｓｔａ△ｂｃｎｔCR△
ＲＤ
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111

そうなると、やはりバッファがオーバーしているのかもしれないと、画面を切替てモニタすると
こちらを見ても該当部分は特に何もなさそうです。

  ＴoverＣ20:51:36.902CR                Ｔ.004Ｃ20:51:36.912＊Ｔ.010Ｃ20:51:36.9
＊                      Ｃ20:51:36.908CR
22△ＲＴＣ                △  Ｗ  ｒ  ｉ  ｔ  ｅ  △  Ｒ  ｏ  ｕ  ｔ  ｉ  ｎ  ｅ
          Ｃ20:51:36.936＊  △  Ｒ  Ｔ  Ｃ  △  Ｗ  ｒ  ｉ  ｔ  ｅ  △  Ｒ  ｏ
          ＴoverＣ20:51:40.713CR＊                Ｔ.726                ＴoverＣ
ｕｔｉｎｅ                        Ｃ20:51:40.718CR      Ｃ20:51:41.444＊
20:51:44.440CR                Ｔ.004Ｃ20:51:44.450ｔＴ.010Ｃ20:51:44.459ｍｗｒｉ
              Ｃ20:51:44.446CR

アイドルタイムをチェックするとT.726と#244エラーになったタイミングではアイドルタイムが大き目のようです。

そうなると送信側のB16&MITERMの問題かと思いますが、他に適当なターミナルが無いので物置に探しに行く必要がありそう・・・・
(アイドル時間はストップビットを検出してからスタートビットを検出するまでの時間らしいのですが、連続して電文を送っている場合でも非同期通信の場合ではアイドル時間が長くても特に問題ない気もします^^;;;

問題の個所を少し変更すると送信できるので、何かの組合せでエラーが発生する状況になってしまうようです。
正常に送れる電文に変更すれば送れるのですが原因は追究したいです。
結局、原因はよく分からないのですが、送信側のターミナルを変えてみると状況が変わるような気がします。

Windowsで専用のターミナルを作るといろいろ便利そうですが、専用ターミナルではなく汎用ターミナルで運用できる方がメリットが多いと思うので汎用ターミナルで安定して流し込めるように整備したいところ・・・

OS-9ニュースに掲載されていた情報によるとデータ転送で#244になってしまう原因として
「シリアルチップ廻りのハード的な問題」と「ドライバの受信バッファオーバフロー」が考えられるとありました。

受信バッファのオーバフローの原因としてFDへのライトビジーを考え送信側で巨大なウェイトを入れていますが、ライトビジー以外で受信バッファに気を使わなければいけない状況があるとすると難しそうです^^;;;

何だかよく分かりませんが、もうしばらく弄ってみます(^^)