(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第１８８回］
●波形の写真から、送信されたデータを解読する
今回はいよいよ、解決篇です。
カギは前回お見せした、２３２Ｃ信号の波形の写真にありました。
写真の波形から、送信されたデータを解読してみると、以外な事実が明らかになります。
２３２Ｃは８ビットのデータをシリアルに変換して送信します。
１と０だけの羅列になりますから、最初から順に見ていくなら、送信データを読み取ることはできますが、前回の写真のように、その途中の一部だけを見ても、どこが８ビットデータの始めで、どこが終わりなのか、わからないのではないか、と言われるかもしれませんね。
ところが、読めるのです。
まるで、暗号の解読のようですけれど…。
暗号の解読といえば、はるかな昔、子供のころに、エドガー・アラン・ポーの小説「黄金虫」を読んだことを思い出しました。
もちろん、少年向きに書かれた翻訳本でしたけれど。
その中に、財宝のありかを示す、謎の暗号文が出てきます。
記号ばかりが並んだ暗号文です。
この暗号の解読がすごいのですね。子供だった私は、「この主人公はなんて頭がいいのだろう」と、感心してしまいました。
これは、英語のアルファベットをそのまま記号に置き換えたものだ、というんですね。
そして、英語でもっとも多く使われている、アルファベットは何か？またもっとも多く出てくる単語は何か？というような推理によって、見事、その暗号を解読してしまいます。
ま、もっとも、大人になった今、考えてみると、本当に、そんな推理だけで、暗号が解読できてしまうものかどうかはちょっと疑問なのですけれどね。
でも、今回の波形からの解読は、そんなにむつかしいものではありません。
しかも、ちょうど、まあ、なんとも都合のよいところをぴたりととらえた写真だったのです。
もう一度、前回の写真をお見せします。
下側（ＣＨ２）のパルス波形をよく見てみると、非常に特徴的な同じ波形の繰り返しに気がつきます。
左の方から３回、約２ｍｓｅｃのＬの部分があります。
Ｌは”０”のビットです。
ボーレートは２４００ボーです。
２４００ビット／秒と考えることができますから、１ビットの長さは１／２４００秒、約０．４ｍｓｅｃです。
すると、２ｍｓｅｃ続く”０”とは、”０００００”のように”０”のビットが５個連続していることであることがわかります。
ところで、今回送信したデータはどのようなデータであったのか、思い出してみてください。
そうです。１６進数をＡＳＣＩＩコードに置き換えたデータを送信したものでした。
その説明は［第１８１回］にあります。
下はそのときに説明した、１６進数１桁をＡＳＣＩＩコードに置き換える表です。
なお（）はＡＳＣＩＩコードの１６進数表記です。
０ ００１１００００ （３０）
１ ００１１０００１ （３１）
２ ００１１００１０ （３２）
３ ００１１００１１ （３３）
４ ００１１０１００ （３４）
５ ００１１０１０１ （３５）
６ ００１１０１１０ （３６）
７ ００１１０１１１ （３７）
８ ００１１１０００ （３８）
９ ００１１１００１ （３９）
Ａ ０１０００００１ （４１）
Ｂ ０１００００１０ （４２）
Ｃ ０１００００１１ （４３）
Ｄ ０１０００１００ （４４）
Ｅ ０１０００１０１ （４５）
Ｆ ０１０００１１０ （４６）
今回の送信データには、上の表で示された、３０〜３９、４１〜４６以外のコードは含まれていないのです。
さて、このなかで、０が５つ連続しているコードは、と捜してみると、文字Ａのコード４１（０１０００００１）が目にとまります。
しかし、残念ながら、上の写真の”０”が５つ連続しているデータは、文字Ａのコードではありません。
上の表のビット表現は、左端がｂｉｔ７で、右端がｂｉｔ０のように並んでいます。
しかしＲＳ２３２Ｃで送信するときには、この逆で、ｂｉｔ０から始まってｂｉｔ７が最後になるように送ります（下図）。
これが、文字ＡのＡＳＣＩＩコード（４１）を２３２Ｃで送信するときの波形です。
そこで、もう一度、さきほどの写真の波形を見てみることにしましょう。
０が５つ並んでいるところは一致していますが、その次の１のパルスは、図の波形ではｂｉｔ６の１ビットだけなのに、写真ではそれよりも長く、おそらく２ビット長であるように見えます。
ええー？それじゃあ、該当者なし？
そうなりますね。文字ＡのＡＳＣＩＩコード４１以外に、０が５個続くコードは存在しません。
ところが、実は、あるのです。
もう一度、上の文字ＡのＡＳＣＩＩコードを２３２Ｃで送信するときの波形の図をよく見てください。
おわかりになりましたでしょうか？
そうです。スタートビットの”０”です。
文字ＡのＡＳＣＩＩコード４１以外に、０が５つ連続するコードは存在しませんが、しかし、データの最初に必ず付け加えられるスタートビットの”０”に続けて０が４つ送られる文字コードなら、ほら、ひとつあるじゃありませんか。
文字０のＡＳＣＩＩコード３０です。００１１００００です。
もう一度、さきほどの写真の波形と比べてみましょう。
おお。今度こそ、ビンゴ、です。
これで、データの流れの中で、１つのデータのスタートビットとストップビットの位置がわかりました。
ここまでわかればあとは簡単です。
写真の波形は下図のように解読できました。
前から順に、３０、３０、Ｂ０、３２と読めます。
Ｂ０？変ですね？こんなコードは、１６進数をＡＳＣＩＩに置き換えた文字コードの中にはありません。何でしょう？
この”Ｂ０”のストップビットのところで、受信エラーがＯＮになっています（上側のＣＨ１の波形）。
送信したプログラムリストを見てみましょう。
前回に行った確認で、ＨＬレジスタは、メモリアドレス０１０Ｅを表示してエラーで停止しました。
プログラムのその部分です（プログラムリストは前回［第１８７回］にあります）。
０１０Ｃ ２１０００２
０１０Ｃに２１が入り、０１０Ｄに００が入ります。
その次の０１０Ｅに０２が入るところでエラーが発生しているようです。
１６進数の００は、ＡＳＣＩＩコードでは３０・３０になります。次の０２は同じくＡＳＣＩＩコードでは３０．３２になります。
だとすると？
上の波形から解読した、３０・３０・Ｂ０・３２は、実は３０・３０・３０・３２というデータでなければならないところだったのでは？
あ。あ。あ。
ここまで考えてきて、やっと思い出しました、のです。
そうでした。
ＰＩＣでデータを受信して、２バイトのＡＳＣＩＩコードデータを、１バイトの１６進データに変換する、というプログラム部分で、文字０〜９、Ａ〜Ｆから１６進数に変換するために、３０〜３９と４１〜４６を分離しています。
その過程で必然的に、コードが３０未満、３Ａ〜４０、４７以上のものを排除することになります。
そのようなコードは、１６進数には存在しないコードですから、受信されるはずはないのですけれど、プログラムの流れとして、もしも、そのようなコードがみつかったら、エラー表示をして停止するように作ったことを、すっかり忘れてしまっていたのです。
まさかコードエラーなど、起きるはずがない、という先入観があったため、フレーミングエラーにちがいない、と思い込んでしまったところに、今回のトラブルの原因がなかなかわからなかった、最も大きな要因がありました。
●やっぱり、目撃証言は間違っていた…
しかし、最初に当社のＢＡＳＩＣボードで受信してみたときには、エラーは発生しなかったのは、なぜ？
もう一度、ＢＡＳＩＣボードにつないで、確認をしてみました。
そうしたら…。
ＢＡＳＩＣボード「ＺＢ１１Ｖ３」のデータ受信画面です。
あれま。気がつきませんでした。文字化けしています。
中ほどよりうしろのあたりで、２１０００２になるべきところが、２１００−２になっています。
うーん。
間が悪かった、というか、これが別の文字コードだったら、文字化けに気がついたのかもしれませんが…。
もともと、ハイパーターミナルでうまく２３２Ｃ送信ができるかどうか試してみることだけが目的だったために、らしい文字列が無事表示された段階で、結果をちらりと見て、オーケー、オーケー、受信すべて、オーケー、と思ってしまったのですよね。
そこへもってきて、たまたま文字化けして表示されたのが「−」だったものですから、また先入観が働いて、見落としてしまいました。
［第１８２回］で、ファイルの中身をＭＳＤＯＳのＤＥＢＵＧコマンドで表示している画面をお見せしました。
これです。
真中に「−」があります。
ＤＥＢＵＧコマンドで、ファイルやメモリの中身を１６進数で表示するとき、図のように１行に１６バイトのデータを表示します。少し長いので、アドレス位置がわかりやすいようにというためでしょうか、行の真中を示す記号として「−」が使われます。
なまじ、こういう表示に慣れていたものですから、真中付近に「−」があっても、別に異常ともなんとも思わなかったのです。
ＢＡＳＩＣのボードは、以前から２３２Ｃの受信テストに使っていたプログラムをそのまま実行しただけで、「１６進数をＡＳＣＩＩコードに変換したデータ」を受信することを目的にしたプログラムではありませんでした。
ですから、受信したコードに相当する文字を表示するだけで、受信した文字コードそのものは、エラーではありませんから、特に異常を示す表示も何も行われなかったために、そこで発生していた「異常」にまったく気がつかなかったのです。
おお。また、思い出してしまいました。
以前にもちょいとお話をしたことがあります、エラリー・クイーンの「Ｘの悲劇」も、日常見慣れているものは、それを実際には目にしていても、異常とは感じないで、見たという記憶が残らない、という目撃証言に潜む落とし穴を利用したトリックがカギになっていましたね。
それはそうと、上でお見せしたＢＡＳＩＣボードの表示画面、えらく年代物の感じですね。
それもそのはず。
もうかれこれ１５年間、故障もせずに動いているのですよ。なかなかのものでしょう。
左側に重ねている基板は、カラーグラフィックインタフェースです。Ｎ８８ＢＡＳＩＣのカラーグラフィック機能とほぼ同じ機能を実現したボードです。３．５インチのフロッピーディスクインタフェースも実装しています。
右にのびるフラットケーブルは３．５インチのフロッピーディスクドライブにつながっています。
右上にあるＤＳＵＢコネクタがＲＳ２３２Ｃです。
これは１５年前に作った、当社のオリジナルボード「ＺＢ１１Ｖ３」です。
１５年間のほこりにまみれてかなりよごれていますけれど、まだ現役です。こわれません（これはちょいと自慢できますでしょう）。
●なんと、ハイパーターミナルにはバグがありました！
はい。これが今回あきらかになった「衝撃の事実」です。
まあ、予想もしなかった、とんでもないことに、ハイパーターミナルには、バグがあったのです！
どなたもお気づきにはならなかったのでしょうか？
Ｗｅｂで検索してみたところ、これは？というページをみつけました。
http://tss.ram.ne.jp/product/hyperterminal.htmlです。
上のリンク先ページで紹介されているバグは、まさに今回私自身が体験したバグとぴったり一致しました。
私はバグが発生する条件まではつきとめられなかったのですが、この方はしっかりとバグが発生する条件もつかんでみえました。
その条件とは、
１）新しい接続でハイパーターミナルを起動する
２）その起動直後に、同じ文字を３文字以上連続して送信する
というものです。
その例として、”ＡＡＡＡＡＢＢＢＢＢＣＣＣＣＣ”を送信すると、受信側では”ＡＡチＡチＢＢツＢツＣＣテＣテ”のように文字化けしてしまう、と紹介されています。
さらに、このバグは、切断後に通信条件を変更して再接続するか、変更しなくても現在の設定を保存して、次回その設定アイコンからハイパーターミナルを起動すると、出現しなくなる、と書かれています。
おお。まさにぴったり。その通りではありませんか。
同じ文字を連続３回送信、というところもぴったりです。
”２１０００２”と送ったところ、”２１００−２”になったのですから。
どうもこのバグには規則性があるようです。
下は一般に使われている８ビット半角英数カナの文字コード表です。
今回のエラーは、コード３０がコードＢ０に化けたものでした。その結果”０”が”−”に化けて表示されてしまいました。
この表を見ますと、文字”Ａ”（コードは４１）が化けた文字”チ”のコードはＣ１で、文字”Ｂ”（コードは４２）が化けた”ツ”のコードはＣ２、そして文字”Ｃ”（コードは４３）が化けた”テ”のコードはＣ３、であることがわかります。
いずれも、送信する、もとのコードのビット７の０が１に変化してしまっている、という明らかな規則性がみられます。
私が今回テストに使用したのは、Ｗｉｎｄｏｗｓ９８です（今だに、です。何しろ動作が軽いものですから、ＸＰなど使う気にならないのですよ）。
なんたって１０年前のＯＳだものですから、今更文句を言ったって、そりゃあ、とっくの昔に、時効成立です。
しかし、しかしです。
さきほどご紹介のあのページをお書きの方は、まあなんと、
ＷｉｎｄｏｗｓＸＰ ＳＰ３に付属のハイパーターミナルＶｅｒ５．１
で、ご確認なさった、とのことなのですよねぇ。
ふたたび、驚愕、というか、愕然。もう、お口あんぐり、です。
おやまあ、そうですか。
ＷｉｎｄｏｗｓＸＰ ＳＰ３ですか…。ハイパーターミナルＶｅｒ５．１でねぇ…。
マイクロソフトさんは、いったいどこをバージョンアップなさっていらしたのでしょうか、ねぇ。
２００９．３．２０ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る