先日１０日から，ホストのモデムを２４００ＭＮＰ５に変更した．モデムの設定は，端末速度固定モードで９６００ＢＰＳとした．こうしておけば，今までのように接続される速度（３００，１２００，２４００など）に応じてホスト側の通信速度を切り替える必要がない．フロー制御は，ＭＮＰ接続の有無に係わらずＲＳ／ＣＳフローを併用，通常はＸＯＮ／ＸＯＦＦとＲＳ／ＣＳが動作する．ＸＭＯＤＥＭ転送時は，ＲＳ／ＣＳフローのみとする．アクセスするモデムを端末速度固定モードの９６００ＢＰＳを始めとして，３００ＢＰＳまで接続テストしたがどれもうまくいった．各速度毎にＭＮＰを設定，非設定にして試すもすべて良好．回線がつながらないというような事態は一度も無し．ＭＮＰと相性の悪いといわれるＸＭＯＤＥＭもテストするが一応問題なく転送できた．
アクセス中にホスト側のモデムの信号ランプを見ているとなかなか面白い．ＲＳやＣＳランプがフロー制御のために点消灯する．ＣＳランプが消灯するとそれに合わせたかのようにＳＤのランプが消灯する．（当り前か．）ホストに向けて無手順ファイルアップロードを行うと一時的にＲＳランプが消灯し，合わせてＲＤランプが消灯する．これでホスト側からのフローオフが有効に働いているのが分かる．
実のところ，以前にホストのプログラムをＱＢで書き直した時に，いずれはＭＮＰを使用するだろうとＭＮＰ対応可能なようにＲＳ／ＣＳフロー制御をプログラミングしておいたのだが，それの動作や効果を試すのはこれが初めてである．
さて，これで通信速度が早くなったと一安心したいのだが，テスト中に，やはりホスト側の不具合というか処理の遅さが目に付きだした．何点かそれを列挙してみる．
- ＸＭＯＤＥＭ（ＣＲＣ−１Ｋ）のＣＲＣ計算が遅い．
これは，以前からも気が付いていたのだが，１ブロック（１０２４バイト）を転送し，受信ＯＫのＡＣＫを受けてから次のブロックの転送を始めるまでに２〜３秒間ちょっと間が空くことで分かる．原因はＣＲＣの計算である．
ＱＢはＢＡＳＩＣであるがゆえにというのが正しいのかどうか知らないがビットシフトや符号なし整数の演算命令がない．このため効率よくＣＲＣ計算させるプログラムが書けない．どうしても時間がかかるのである．１０２４バイトともなるとその遅さが顕著に現れる．１２８バイトなら処理時間が目につくという程ではない．これでは，何のための高速転送か分からない．
- ホストの実効処理速度は２４００が限界．
ＭＮＰ５（圧縮あり）で，ホスト，端末とも９６００の端末速度固定モードでモデムを使うならば，実効速度３０００〜最高（運がよければ）４８００で通信可能というのがＭＮＰモデムの売り文句なのだが，この効果を活かすためには，ホスト，端末とも計算機処理が９６００に追従出来ての事である．ホストの内部処理が遅ければだめだ（端末側の通信ソフトは問題なかろう）．
回線ポートの送信速度を早くしたところで，ポートに出力するデータを９６００の速度で準備できないのでは意味がない．受信の場合は，たびたびフローストップを掛けてしまう．１２００非ＭＮＰで接続した時，モデムは９６００ＢＰＳ（実効速度は必ずしも９６００ではない）でホストからくるデータを回線に出し切れず，データ転送途中でＣＳをオフにしてフローストップしてくるのが，モデムのＣＳランプで分かる．２４００非ＭＮＰで接続した時，同様にＣＳランプが途中で消灯するならば，ホストは実効速度２４００以上でデータ送信している事になる．ところがである，ボードのアーテイクルを連続読みだししてもＣＳランプが消灯しない．つまり，９６００ＢＰＳでモデムに接続していても，流しているデータの速度は２４００程度であるということだ．
さて，この原因だが一つにはＣＰＵの処理速度が挙げられる．ホストはＰＣ−９８０１Ｍ２だが，このマシンは８ＭＨｚの８０８６である．このＣＰＵは今や骨董品に近い存在だ．ＶＭやラップトップのＬＶ２１，ＬＶ２２などに使用されているＣＰＵＶ３０よりもまだ遅い．これらの機種の遅さは定評だが，それよりもまだ遅いのだから困ったものだ．ちなみに１２ＭＨｚの８０２８６で動くＲＸ２１を使ってホストを試験的に動かすと４８００ＢＰＳは充分出るようだ。２４時間無人で動くホスト（そしてホストだけにしか使えない，このマシンを他の事に使うことができない）にはあまり高価なマシンを使うわけにもいかずいたしかたの無いところ。
二つ目の原因としては，ホストのプラグラムに問題がある．ＱＢに備わっている通信回線制御にはＲＳ／ＣＳのフロー制御はない．また，ｘｏｎ／ｘｏｆｆ制御で回線オープンするとバイナリモードが通らないのはもちろんの事，ＣＴＲＬ＋Ｚの変換やタブ変換など勝手な事をやらかしてくれる．プラグラム上でフロー制御を管理したいと思えばこれら全てをプログラムしてやる必要がある．また，ＡＴＬＡＳでは，画面制御のエスケープシーケンスを送信したり，しなかったりの制御を行っている（アーティクルの中のＥＳＣシーケンス部分のカットも行う）．処理中にＥＳＣがきたかどうか，ｘｏn／ｘｏｆｆは受信したかどうか，ＲＳをオフするタイミングかどうか，受信したＢＳキーは漢字の後かどうかなどをうまくやろうと思えば，一文字送受信する度にいろんな処理モジュールをくぐらせる必要がある．そしてこれらをＱＢでプログラムしているのである．これでは，とうてい高速処理は望めない．さらに悪い事にコンパイルしてみてもＱＢのシステムランタイムルーチンが裏でタイマー処理などの複雑な割り込み処理を常に行っている．いわゆる荷が重いというやつである．アセンブラかＣで書き直さない限り改善が望めない状況である．
- ＥＳＣキーの聞くタイミングがずれる．
これは，１２００で接続した時に起きるのだが，モデムのデータバッファリングの作用により，ホストがＥＳＣを受け付けるタイミングと端末でＥＳＣを押すタイミングがずれてしまう事に起因する．別の現象として，ログオフした時に，ログオフメッセージが完全に表示されないうちに回線が切断されてしまうという不具合もある．ホストの方は，ログオフメッセージをモデムに向けて完全に送信してから切断処理しているのだが，この時点で，メッセージはモデムにバッファされただけで回線上には掃きだし切れていない，このようなタイミングでホストがＥＲオフ（切断処理）するものだからモデムは無情にもバッファ内のデータを掃き出さないうちに回線を切断してしまう．モデムのバッファリングを活用したがゆえの副作用がでたわけだ．
最近のＣは，アセンブラを併用せずとも割り込みが記述できるようになった．ＣＰＵ速度の遅いＭ２ではあるが，Ｃでプログラムし，ＱＢの管理から離れれば今よりは高速処理が期待できるのではないかと思い，Ｃによるプログラムの書き直しに着手した．この連休では通信回線制御の部分を書き上げた．ＸＭＯＤＥＭのモジュールもＣで書き直した．ＱＢはもともと構造化言語になっているので書き直しは割と楽である．そのままＣの文法に変換していけば事足りる．とはいうものの先は長い，やはり個人の能力の限界を感じてしまう．ホストプログラムには，プログラミングの課題が豊富に存在する（回線制御，ファイル管理，エディタ，検索処理などなど）．一つ一つ解決しなければならないが，それもまた楽しである．