ＬＩＮＥ：と１０の間、ＶａｌｕとＦｏｒｍａｔの間、ＳｙｎｔａとＦｏｒｍａｔの間、それから％１と？１との間の行、そして？１の次（最下行）におかしな表示があります。
ブラウザによって、ただの「・」が表示されたり、見慣れない文字（というよりマーク、記号）が表示されたりします。
Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒやＯｐｅｒａではただの「・」ですが、Ｆｉｒｅｆｏｘではおかしなマーク（？）が表示されます。
泥沼からやっと抜け出せて、今は落ち着いて考える余裕が出てきました。
そこで、本日になりましてから、そのあたりを追求してみることにいたしました。
このおかしな表示なのですが、それでは一体ここにはどのような文字コードがあるのでしょうか？
そういう場合に役に立ちますのが、ＭＳＤＯＳのＤＥＢＵＧコマンドです。
ところが、ずっと以前に書いたことなのですが、Ｗｉｎｄｏｗｓ７（６４ｂｉｔ）では、この便利なＤＥＢＵＧコマンドが使えません（パソコンをつくろう［第１２回］）。
なんですか、６４ｂｉｔでも仮想ＸＰモードとやらが使える、上のバージョンですと出来るらしいのでありますが。
余談になりますが、上記の記事を書きましたところ、ある方からメールをいただきました。
「Ｗｉｎｄｏｗｓ７の６４ｂｉｔ版でもｘ８６アプリケーションが動くツールを作りましたから、よろしかったら使ってみてください」というメールでした（パソコンをつくろう［第１６回］）。
Ｍｉｃｒｏｓｏｆｔとは関係ない（と思います）方でもそういうツールを作ることが出来るといいますのに、これはいかにもＭｉｃｒｏｓｏｆｔ様の手抜きじゃあありませんかねえ。
本題に戻ります。
エラーメッセージの部分だけをコピーして、ＴＸＴファイルにして、それをＤＥＢＵＧコマンドで開きました。
下の画面はＷｉｎｄｏｗｓ９８ＳＥでの画面です。
Ｗｉｎｄｏｗｓ７（３２ｂｉｔ）でもＤＥＢＵＧコマンドは使えますけれど、こういうものはやっぱりＷｉｎｄｏｗｓ９８あたりが一番使い易いです。
ですので、いつまでたってもＷｉｎｄｏｗｓ９８は手放せません。
水色で囲ったところが、おかしな文字表示の部分です。
Ａ０、Ｅ５、Ｆ８、８Ａになっています。
確かにこれはＡＳＣＩＩじゃありません。
むむ。
これは、Ｆ８０のバグか。
とも思ったのですが。
んなことは、ありませんでしょう。
おお。
ひらめきました。
ＣＰ／Ｍ２．２では、文字コードは７ビットしか使わなかったはず。
つまり最上位のビット７は常に０であるはずです。
ところが、このコードはどれも、ビット７が１です。
ひょっとすると、文字列の終わりを示すのに＄（２４Ｈ）ではなくて、最終文字の文字コードのビット７を１にする、というテクニックだったのでは。
それではということで、Ａ０、Ｅ５、Ｆ８、８Ａのビット７を０にしてみますと。
２０、６５、７８、０Ａになりました！
そういうことか！
文字列の終わりを＄（２４Ｈ）にした場合、
ＣＰ ２４
ＪＰ Ｚ，ｘｘｘｘ
でチェックすることになりますが、ビット７＝１のチェックなら
ＯＲ Ａ
ＪＰ Ｍ，ｘｘｘｘ
ですから、１バイト少なくて済みます。
文字列そのものも余分な＄が不要になりますから、そこでも１バイト少なくて済みます。
当時の１バイトは貴重だったのですよねえ。
そういうことならば。
ＢＤＯＳのファンクションコールで、文字コードをＢＩＯＳに送るところで、強制的にビット７＝０にしてしまえばよい、ということになります。
さっそくそのように直してしまいました。
ところで。
肝心のエラーメッセージが出された理由なのですが。
それも今ではどういうことだったかわかっております（実にみっともない、お恥ずかしい理由でありました）。
わかっておりますから、［第１６８回］でお見せしましたように、ちゃんとコンパイルして、それからＬ８０．ＣＯＭでリンクして、そのあと作成されたＨＥＬＬＯ．ＣＯＭを実行するところまでできているのです。
もちろんエラーメッセージが出された理由がわかっておりますから、エラーを再現することだってできてしまいます。
下は７ビットコードのみを出力するように修正した、ＣＰ／Ｍ互換ＤＯＳで、わざと同じエラーを表示させてみたところです。
おかしな表示が消えて、代わりに本来の文字が表示されました。
ワンボードマイコンでＣＰ／Ｍを！［第１７０回］
２０１２．７．１２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る