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

Last Updated on 2014年7月8日 by kabekin

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

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

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

転送ツールが無いので、普通のコピーコマンドを使い データ転送&ファイル書込みを行いました。
DSC01458
クロス環境で編集したclock_rtcモジュールのソースを転送すると、必ず同じ場所でOS-9側が#244エラーを出してコピー停止になります。

転送速度は現状のS1用OS-9では一番高速な2400bpsです。
(Oh!FM誌掲載の拡張コピーコマンドcpyでも全く同じ結果になりますので、copyコマンドの問題ではなさそう)
B16からの送信条件はこんな感じで、送信ウェイト設定は8*0.5秒で約4秒とライトビジー対策はOKと思われます。
DSC01477
条件を変えながら転送してみるとボーレートが遅いほど#244エラーが発生しやすくなる傾向があり、ちょっと予想外です。

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

転送時にエラーが発生してしまう部分はこちらで、 特段おかしなコードではないと思います。
DSC01473
*
*RTC Write Routine 
*
のコメント3行目のアスタリスクを送ると100%の再現性で#244エラーが発生し、コピー停止^^;;;
100%の再現性なので何か原因があるはずです。

何度やっても同じなので、最近趣味用に入手したラインモニタを使って、何かヒントはないかモニタしてみました。
DSC01470
エラーが発生している部分をモニタすると、
こんな感じで、特におかしなコードは送ってなさそうです・・・・^^

AE5131B  ch1:RS-232C        DATA&STATE  JIS8      BLK 00001/00002 D_LN 0288/0305
TDuls△a  ,  p  c              CR  *  CR  *△RTC  △  W  r  i
RD          △  p  u  ls△a,pc  CR  *  CR          *  △  R  T  C
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TDt  e  △  R  o  u  t  i  n  e          CR*    CR  tmwrite△
RD  △  W  r  i  t  e  △  R  o  utine    CR*  CR
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TDequ△*CR△sta△adataCR△lda△#$3eCR△sta△bcntCR△
RD
RTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CTS 1111111111111111111111111111111111111111111111111111111111111111111111111111
CD  0000000000000000000000000000000000000000000000000000000000000000000000000000
DTR 1111111111111111111111111111111111111111111111111111111111111111111111111111
DSR 0000000000000000000000000000000000000000000000000000000000000000000000000000
CI  1111111111111111111111111111111111111111111111111111111111111111111111111111
TI  1111111111111111111111111111111111111111111111111111111111111111111111111111

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

  ToverC20:51:36.902CR                T.004C20:51:36.912*T.010C20:51:36.9
*                      C20:51:36.908CR
22△RTC                △  W  r  i  t  e  △  R  o  u  t  i  n  e
          C20:51:36.936*  △  R  T  C  △  W  r  i  t  e  △  R  o
          ToverC20:51:40.713CR*                T.726                ToverC
utine                        C20:51:40.718CR      C20:51:41.444*
20:51:44.440CR                T.004C20:51:44.450tT.010C20:51:44.459mwri
              C20:51:44.446CR

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

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

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

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

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

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

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

2件のコメント

  1. 通信中割り込み禁止にしているために、バックグラウンドの何かのモジュールが一定間隔の処理をできなくて例外を返しているとかかなあ。
    WindowsのTeraTermなら、1文字毎や1行毎にウェイトやキープを入れられるため、何とかなるかも。

    1. >enakaさま
      コメントありがとうございます
      モニタした感じでは、電文には問題が見当たらないので、やはりターミナルの相性に何かありそうです。
      次回WindowsのTeraTermで試してみます。
      モニタしたところハードフローの信号には全く変化が無いのでUSB変換のシリアルポートでもOKそうな感じがしています^^

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください