復活！ＣＰ／Ｍ ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第１２８回］
●ファンクションコール０Ａ（コンソールバッファ入力）
ＣＰ／Ｍ２．２で［ＢＳ］の機能が正しく働くようになりましたので、あらためてその動作を確認してみましたところ、同じコード０８Ｈでもキー入力コードと画面表示コードとでは、その動作が異なっていることがわかりました、というところまでが前回のお話でした。
ＣＰ／Ｍでキー入力というのはコンソール入力になります。
ＢＩＯＳのコンソール入力ルーチンは、ただキー入力コードを取得するだけですが、ファンクションコール０１のコンソール入力は、キー入力コードを取得すると同時に、それをエコー表示するため、コンソール出力も行ないます。
このときに行なうエコーとしてのコンソール出力では、０８Ｈは［ＢＳ］の動作をします。
しかしファンクションコール０２のコンソール出力では、０８Ｈは［←］の動作をします。
そこのところを使い分けるように、ＣＰ／Ｍ互換ＤＯＳのプログラムを直さなければなりません。
なかなかに面倒なことです。
面倒ではありますが、そんな程度のことでめげてしまうような私ではありません。
なんとか直してしまいましたよ。
さてそこで。
そのように直したＣＰ／Ｍ互換ＤＯＳプログラムが、ＣＰ／Ｍ２．２と同じ動作をするかどうかを検証していたのでありますが。
まてよ。
コンソール入力は、他にもあったのでは？
おお、そうでした。
ファンクションコール０Ａ（コンソールバッファ入力）もコンソール入力です。
こちらのほうでは［ＢＳ］はどのように働くのでありましょうか？
そこに気が付いて、確認してみましたところ。
そこにはなんと。
まさかの複雑な仕組みがあったのでありました。
いえ。
「まさか」といいますのは、まあ、言葉のあやでありまして、ファンクションコール０Ａにつきましては、それが複雑な仕組みらしいということは、おおよそはわかっておりました。
しかし、そんな面倒な仕組みは要らんだろうよ、ということで無視してしまうつもりだったのですよねえ。
はじめは。
ですけれど。
そこはそれ、持ち前の性格といいますか。
考えておりますうちに、そういう複雑なものだからこそ、なおさら自分の手で作ってしまいたい、という悪魔の誘惑につい乗ってしまうのでありますね。
かくして、いつも泥沼でもがくことになってしまいます。
よくよく落ち着いて考えてみましたら、そもそも［ＢＳ］の主たる活躍場所はファンクションコール０１（コンソール入力）やファンクションコール０２（コンソール出力）ではなくて、このファンクションコール０Ａ（コンソールバッファ入力）であるように思えてきました。
［ＢＳ］はどういう時に使われるかといいますと、それはもちろんキー入力で誤入力をしてしまった場合にそれを訂正する時、ということになりますでしょう。
ではキー入力をする時、というのはどういう時かといいますと、ただ１文字だけの入力、という場合もありますけれど、ほとんどはある文字数を入力して、最後に［Ｅｎｔｅｒ］キーを押して入力を確定する、という使い方をしている時である、と言えますでしょう。
つまりそういうプログラムを書く時は、ふつうはファンクションコール０１（コンソールから１文字を入力）ではなくて、ファンクションコール０Ａ（コンソールバッファ入力）を使うことになると思います。
すると、その場合の［ＢＳ］キーの入力は、画面にエコー表示された文字を１文字消去すると同時に、コンソール入力バッファに入力されている文字コードも消去する、という動作になります。
勿論、そこまでは想定内だったのですよね。
ところが。
さらに詳細を調べていきましたら、コンソールバッファ入力の想像を超える複雑な仕組みが明らかになってきました。
あ。ここでひとつご注意を。
以下の説明は、あくまでＣＰ／Ｍのファンクションコール０Ａにおける動作についての説明です。
一般的なキー入力時でもそのような動作をする、ということではありません。
以上。念の為。
さて。
コンソールバッファ入力の複雑な仕組みのひとつは、［Ｃｔｒｌ］キー入力時のエコー表示に関わるものです。
ここで［Ｃｔｒｌ］キー入力といいますのは、［Ｃｔｒｌ］キーと同時にアルファベットキーを押す、という入力のことです。
［Ｃｔｒｌ］＋［Ｈ］はコード０８Ｈで、これは［ＢＳ］キーを入力したのと同じ動作になります。
また［Ｃｔｒｌ］＋［Ｊ］は０ＡＨ、［Ｃｔｒｌ］＋［Ｍ］は０ＤＨで、それぞれＬＦ、ＣＲコードの入力と同じ動作になります。
しかしたとえば［Ｃｔｒｌ］＋［Ｋ］は０ＢＨですが、ＣＰ／Ｍではこのコードには特別の機能は与えられていません。
そのような［Ｃｔｒｌ］コードの入力があった場合には、エコーとして、 ＾Ｋ のように ＾ に続けてアルファベットを表示します。
しかしコンソールバッファには０ＢＨの１文字コードが入力されるだけです。
するとエコー表示される画面上のカーソルアドレスとコンソール入力バッファのポインタには１文字分のずれが生じます。
何を言っているか、おわかりになりますでしょうか。
これは面倒なことなのですよ。
たとえば［Ａ］、［Ｂ］、［Ｃ］、［Ｃｔｒｌ］＋［Ｋ］、［Ｄ］と入力したとしますと、画面には、
ＡＢＣ＾ＫＤ
と表示されますが、コンソールバッファには
４１・４２・４３・０Ｂ・４４のように入力されます。
それではここで［ＢＳ］を２回入力するとどうなるでしょうか？
コンソールバッファは２文字消されますから、
４１・４２・４３
の３文字が入力されていることになります。
このとき表示画面はどうなるかと言いますと、
ＡＢＣ＾
ではなくて、この場合には＾も含めて３文字が消去され、
ＡＢＣ
になります。
確かにつじつまが合いますけれど。
［Ｃｔｒｌ］入力をするたびに画面のカーソル位置カウンタとコンソールバッファの入力文字カウンタの値はどんどん相違していきます。
でも［ＢＳ］はそこのところをちゃんと間違い無く処理しなくてはなりません。
どうやっているのでしょうかねえ。
でも、こんなもんじゃないのです。
もっとすごいのはＴＡＢの扱いです。
ＴＡＢのキーコードは０９Ｈですが、このコードは画面表示コードとしては働きません。
それがＴＡＢとして働くのは、システム（ＯＳ）の働きによるのです。
ＣＰ／Ｍでは０、８、１６、２４、…というように８字ごとに固定したＴＡＢが設定されています（先頭が０カラムです）。
この数を１６進数で示しますと、００Ｈ、０８Ｈ、１０Ｈ、１８Ｈ、２０Ｈ…になります。
今キーボードから、
［１］［２］［３］［ＴＡＢ］［４］［ＴＡＢ］［５］ ……①
と入力したとします。
このときコンソールバッファには、
３１・３２・３３・０９・３４・０９・３５ ……②
というようにコードが入ります。
では、このときコンソール出力には、エコーとしてどのようなコードが出力されるかといいますと、
３１・３２・３３・２０・２０・２０・２０・２０・３４・２０・２０・２０・２０・２０・２０・２０・３５ ……③
というようにコードが送られます。
その結果、画面には
１２３□□□□□４□□□□□□□５＿ ……④
と表示されます（□は１文字分の空白です。また＿はカーソルの表示です）。
なんと、［ＴＡＢ］入力のたびに、現在のカーソル位置から次のＴＡＢ位置までの文字数を計算して、そこまでに必要な空白の個数を算出して、コンソール出力を行なっているのです。
しかも、それはコンソールバッファの現在の入力文字カウンタをもとに計算されるのではなくて、あくまで画面表示の現在のカーソルポイントをもとに計算されているのです。
これがＴＡＢの仕組みです。
その仕組みがどれほど複雑であるか、想像できますでしょうか？
たとえばさきほどの①～④の例は、説明を簡単にするために、入力開始時にカーソルポイントが画面の左端にあるものと仮定して説明をしています。
でもいつもそうであるとは限りません。
もしも、
ＩＮ：＿
と表示されたあとにファンクションコール０Ａがコールされたとすると、そのときに①と同じ入力を行なった場合、②～④はどのように変化するでしょうか？
この場合でも②は同じです。
つまりコンソールバッファへの入力は画面のカーソル位置（カーソルポインタの値）からは独立しています。
それでありながら、ＴＡＢ入力に対するエコーはカーソル位置に依存しているのです。
ですからさきほどは③だったものが、
３１・３２・３３・２０・２０・３４・２０・２０・２０・２０・２０・２０・２０・３５ ……③’
になります。
このようにカーソル位置から、必要な空白の数を計算しているのです。
その結果、画面には、
ＩＮ：１２３□□４□□□□□□□５＿ ……④’
と表示されます。
この④’をさきほどの④と重ねて表示してみますと、
１２３□□□□□４□□□□□□□５＿ ……④ ＩＮ：１２３□□４□□□□□□□５＿ ……④’ |
１２３□□□□□４＿ ……⑤ ＩＮ：１２３□□４＿ ……⑤’ |
１２３□□□□□４□□□□□□□５＿ ……④ ＩＮ：１２３□□４□□□□□□□５＿ ……④’ |
１２３□□□□□４＿ ……⑤ ＩＮ：１２３□□４＿ ……⑤’ |