ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第１３２回］
●昔の端末のＣＲとＬＦ
前回と前々回、ＬＦについて書きましたところ、ＣＰ／Ｍマイコンシステムの開発をご依頼いただいておりますＹ様から、昔の端末のＣＲとＬＦについての情報をメールしていただきました。
Ｙ様は昔のミニコン、パソコン及び当時の業界の事情に通じていらっしゃって、ときどきお寄せいただくメールはとても参考になります。
せっかくの情報を私ひとりがいただくだけでは勿体無いので、Ｙ様からご承諾をいただき、ときどき機会をみつけて、皆様にもご披露させていただきたいと思っております。
以下、今回Ｙ様からいただきました、昔のミニコン端末のＣＲとＬＦについてのメールをそのまま転載させていただきます。
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
メカの塊であるテレックスを端末に利用した時代、つまりテレタイプ社のASR３３や、互換性があるTTY端末を利用していた時代は、「復帰」と「改行」は個々に文字どおりの動作をしていました。
「復帰」コードを送ると、「キャリッジ」つまり「印字ヘッド」が「ギィーガチャン！」と音を出して左端に移動しました。
「改行」コードを送ると、「印字ヘッド」の位置はそのままで、「ゴムローラー」が「カクン」と音を出して１行分ロールペーパーを送りました。
送信順番は、必ず、「復帰」が先で「改行」が後でした。
これは、「復帰」の実行には印字ヘッドを動かすので時間がかかるためです。
「復帰」コードだけを送り、その後に文字コードを送ると同じ行に文字の重ね打ちができました。
この重ね打ちのテクニックを利用してプリンタ用紙に微妙な濃淡で「モナリザ」などの精巧な文字絵をプリントしていました。（１９７５年当時一般の方に大受けでした）
このようにメカのテレタイプ（TTY）を利用していいた時代は、「復帰」と「改行」は個々に機能していました。
テレタイプのキーボードにも、「復帰」と「改行」は個別のキーが有りました。
１９７５年頃からテレタイプに替わり、ビデオ端末や、ドットマトリックス印字ヘッドを持った新型の端末が出現しました。
これらの端末の内部制御には８０８０やZ８０を利用していてユーザー設定でエスケープシーケンスなどが定義可能でした。
この時期の端末には、「改行」コードの動作として、意味どおりの「改行」だけと、「改行」コード単独で「復帰」と「改行」の二種類の動作を同時に行うという選択設定が出来たようなおぼろげな記憶があります。
ホストから「改行」が送られて来るというのは、同じ場所で一行下へカーソルを移動するのではなく、一行下で、なおかつ、次の行の先頭にカーソルを移動するという意味と解釈した方が合理的という考えと思われます。
ビデオ端末では「印字ヘッド」を移動する時間は不用なので、１文字分の時間稼ぎを行う必要が無くなったのも関係していると思います。
１９７５年頃から主流になったビデオ端末は、エスケープシーケンスでカーソルを上下左右に自由に動かすことが出来たので、印字ヘッドの位置を「復帰」と「改行」で制御する必要がなくなりました。
文字を画面表示する場合は、「改行」コード単独で「復帰」と「改行」の二種類の動作を行い、カーソル移動にはエスケープシーケンスで行うという方法が採用されたと記憶しています。
このようなビデオ端末は、「復帰」と「改行」の両方を送信してくるホストにも対応できるように「復帰改行モード切替」機能があり、「改行」コード単独で「復帰」と「改行」を行う機能を止めて、「復帰」と「改行」は個別に画面上で動作するように切り替えることができたと思います。
このような「改行」コード単独で「復帰」と「改行」する機能はUNIX系で採用されたようです。
テレタイプ端末を標準コンソールとして利用されたCP／M系は、「復帰」と「改行」は個別に機能するようになっていたと思います。
「復帰改行モード切替」が適切に設定されていない状態でホストからの通信を受信するとビデオ端末の画面表示がメチャクチャになった記憶があります。
はるか昔の記憶なのでアヤフヤな部分が多いですが、記事を拝見して「復帰改行モード切替」機能という設定がビデオ端末側にあったということを思い出したのでご連絡いたしました。
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
Ｙ様。
いつもながら貴重な情報をお寄せいただき有難うございました。
そうですよね。
私も確かその昔の端末で、ヘッドが行の途中で止まったまま、紙送りがズズズズ…というように働いていたような記憶があります。
いずれにしましても遠い昔のお話です。
ちなみに今回いただいたメールにあります、エスケープシーケンスも今では過去のものになってしまいました。
Ｗｉｎｄｏｗｓ７のコマンドプロンプトではエスケープシーケンスは使えません。
●テレタイプの印字速度
Ｙ様から追加のメールが届きました。
テレタイプの印字速度についての追伸です。
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
テレタイプ時代の印字速度は今の方には想像を絶する遅さですので追加説明を送ります。
「復帰」と「改行」の時代から「改行」だけの時代に移行したのは、テレタイプ端末からビデオ端末に進化した頃だと思います。
「復帰」と「改行」の時代というのは、通信速度１１０bpsのテレタイプの時代です。
テレタイプを利用したことが無い方には想像を絶する時代です。
「復帰」と「改行」を含めて１秒間に１０文字しか出力できない表示（印字）装置です。
つまり「復帰」と「改行」を含めて１分間に６００文字しか印字できませんでした。
しかも、印字中は物凄い騒音と振動です。
このテレタイプの横で眠れるのは凄腕プログラマーの証でした。
マイコンには、今の様な画面などはありませんから、アセンブラリストを見るためには印字するしかなく、印字には５分から１０分ぐらいかかりました。
紙テープへのメモリダンプには２０～３０分位かかりました。
スタートレックゲームや、チェスゲームをするときは、１手進める毎に３０秒間位「ガシャガシャガシャ・・・・ギーガチャン」印字していました。
テレタイプ社のキーボードと印字装置が付いたテレタイプ端末の説明がWikiにあります。
http://ja.wikipedia.org/wiki/ASR-33
プリンターの後ろにある横長のロール紙（大きなトイレットパーパーのようなもの）をゴムローラーに巻きこんで印字します。
テレタイプの「改行」とは、ゴムローラーを回して、このロール紙を１行分送る操作です。
ビデオ端末での「改行」は、カーソルが一段下の行に移動しますが、テレタイプでは、印字する紙が１行上に送られるだけで印字ヘッドが下に下がるわけではありませんでした。
この辺のところは現状のPCから入門した方には想像できない部分だと思います。
ビデオ端末は、テレタイプと同じく文字しか表示できませんでしたが、初期のビデオ端末に４８００ｂｐｓの通信速度、つまり１秒間に約５００文字程度の文字が画面いっぱいに一気に表示されたときは驚異的でした。
表示速度が、１秒間に１０文字から、１秒間に５００文字に激変しました。
しかもビデオ端末には、蒸気機関車のような騒音と振動もありません。
それまで、リストを取る間は、珈琲ブレークだったプログラミングの効率が一気に向上しました。
１９７７年頃の初期のビデオ端末 ADM－３ キットは８４０ドル 完成品は１０８０ドル 日本のマイコンショップで３５万円位でしたが、当時としては低価格でした。
http://www.old-computers.com/history/detail.asp?n=32&t=3
１９７８年発売 DEC社のベストセラー ビデオ端末 VT－１００ 復帰改行モード切替機能あり
http://ja.wikipedia.org/wiki/VT100
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
Ｙ様。
追加情報をお送りいただき有難うございました。
今後ともよろしくお願いいたします。
●ファンクションコール０Ａのバッファサイズ
［第１３０回］で、ＣＰ／Ｍ互換ＤＯＳのファンクションコール０Ａを、ＣＰ／Ｍ２．２のファンクションコール０Ａと同じ動作をするように、プログラムを大幅に書き直してしまいました、と書きました。
まるっと１日以上を費やしてしまいました。
そして書き直したあとのＣＰ／Ｍ互換ＤＯＳでファンクションコール０Ａのテストプログラムを実際に実行して、ＣＰ／Ｍ２．２と同じ動作をしているところの画面をお見せしました。
これで、やれやれ一件落着。
と思ったのでありますが。
まだ続きがありました。
前回までの説明でファンクションコール０Ａをテストするために使ったＦＴＳＴ９．ＣＯＭは、［第６４回］で作ったものです。
それでその［第６４回］を念の為にということで、読み直していましたら、あれま、だめじゃないの、ということに気が付いてしまいました。
実はテストだということでＦＴＳＴ９．ＣＯＭのファンクションコール０Ａでは、コンソールバッファのサイズを２０文字にしておりました。
しかし、そこのところを読みましたら、バッファの最大サイズは
あ。
たった今気が付きました。
ここは誤記でありました。
正しくは２５５バイトです。
むむ。
［第６４回］も訂正しておかなくては（そのように訂正いたしました）。
これはまた、どえりゃあことです。
今まで私はなんとなく、コンソールバッファの最大サイズは画面の１行と同じ８０バイトだと思い込んでおりました。
それだと入力時のエコーとも一致していて都合が良いと考えたからでもあります。
いや。
大体その考えがそもそも間違っていたのです。
そういうことではないでしょう。
おそらく聡明なる読者におかれましてはすでにお気づきのことと思います。
たとえばＴＡＢ。
ＴＡＢを使いますと、コンソールバッファには１バイトのタブコード０９Ｈだけが入りますが、画面にはカーソル位置によって最大８個の空白が出力されます。
もしもＴＡＢばかりを入力したとしますと、８０×８＝６４０バイトの空白が表示されますから、それだけでも８行表示されることになります。
しかも。
それが最大８０バイトではなくて、最大２５５バイトだったとしますと。
あかん。
もお。
また、やり直しだあ。
一瞬、目の前が真っ白になりました。
ここは一番落ち着いて、気を取り直して。
とにかく、まずは熱いコーヒーなどを入れまして。
うーん。
落ち着いてよく考えてみますと。
たとえバッファが２５５バイトではなかったとしても（上に書きましたようにバッファサイズが８０バイトだったとしても）、エコー表示した結果は１行では表示できなくて、２行以上にわたって表示されてしまうことも大いに考えられます。
ましてバッファが最大２５５バイトにもなるということになりますと、エコー表示が複数行になってしまうというのは必然です。
オリジナルのＣＰ／Ｍ２．２では、それはそのようになっているだろうということは、確かめてみるまでもありません。
そして。
エコー表示をするだけならば、８０字を超えて表示を続ければ勝手に改行が行なわれて、その下の行に表示が続けられますから、そこは別に問題ではありません。
バッファのサイズが最大８０バイトだとして書いていたプログラムを、最大２５５バイトまで扱えるように書き直すだけで済みます（当然バッファに割り当てるメモリもそれだけのサイズを確保しなければなりませんが）。
しかし。
エコー表示が２行以上になってしまった場合、そこでの［ＢＳ］はどのように働くのでしょうか？
８０字以上を入力した（もしくはＴＡＢ、Ｃｔｒｌ入力などを多用した）結果、エコー表示が２行以上になってしまい、カーソルの表示が最初に入力を開始した行の下の行に移ってしまっている場合に、そこで［ＢＳ］を入力し続けたらどうなるか？という疑問です。
［ＢＳ］を入力し続ければ、当然カーソルはその行の左端に到達します。
そこでもさらに［ＢＳ］を入力したら？
カーソルが上の行に戻る？
いえ。
それはありません。
スクリーンエディタでもない限り、カーソルを上の行に戻すことはできません。
ＣＰ／Ｍ２．２では、そのような機能は想定していません。
するとどうなるか？
ＣＰ／Ｍ２．２でその動作を確認してみました。
カーソルがその行の左端に到達したあとも［ＢＳ］を入力した場合、カーソルの表示は左端にとどまったままになります。
しかし実はバッファの中では［ＢＳ］が実行され続けるのです。
つまりそこからは「目に見えない」状態になってしまいます。
ああ。
それで。
やっと［Ｃｔｒｌ］＋［Ｒ］の機能が納得できました（違っているかも知れませんが）。
そのような状態（バッファの中味が画面に正しく反映されなくなった状態）になったときには、そこで［Ｃｔｒｌ］＋［Ｒ］を入力すると、現在のバッファの内容が正しく再表示されます。
なるほど。
そういう動作なら、理屈に合っていますし、無理はありません。
しかし。
そのように［ＢＳ］を操作した結果、画面上ではカーソルが左端に張り付いたままの状態になって、それでいてバッファの中味だけが［ＢＳ］によって削除されていく、などという動作は、どのようにプログラムしたらよいのでしょうか。
しばらく。
はたと考え込んでおりましたが。
むうう。
よくはわからんが。
どうも、このままでいけるのではあるまいか。
つまり。
バッファのサイズを、当初の８０バイトから２５５バイトに変更することと、ＴＡＢが画面の右端から先に進まないようにしていたところを、次の行に移ってＴＡＢ表示を続けられるように変更することは必要だけれども、上で説明した［ＢＳ］の動作はそのままのプログラムでも、してくれるのではないだろうか。
という気がしてきました。
そう思ったら、あれこれ考えていないで、まずは試してみるのが一番でありましょう。
結果は、ビンゴ、でありました。
下はそのときの画像です。
ＮＤ８０ＺⅢ上で、現在作成中のＣＰ／Ｍ互換ＤＯＳを起動して、そこでＦＴＳＴ９．ＣＯＭを実行して、入力を行なっています。
ＦＴＳＴ９．ＣＯＭは［第６４回］で作った、ファンクションコール０Ａをテストするためのプログラムですが、バッファサイズを当初２０バイトにしていたところだけ、２５５バイト（ＦＦＨ）に変更しました。
画面一杯に文字が表示されていて、このままではなにがなんだかよくわからないと思います。
順番に説明をいたします。
最初に連続してキー入力を続けていきました。
入力した文字数をあとからでも数えやすいように、１２３４５６７８９０ａ１２３４５６７８９０ｂ…というように入力していきました。
…ｗ１２まで入力したところでバッファが一杯になり、そこで入力が打ち切られて下にバッファの中味が表示されました。
その下にはバッファの先頭の２３バイト分の内容が１６進数で表示されています。
１２３４５６７８９０ａで１１バイトです。それがａ…ｗまでですから、１１×２３＝２５３バイトです。
そこに最後の’１２’の２バイトを加えるとちょうど２５５バイトになります。
おお。
計算は合っていますね。
ここまではＯＫです。
その次は、下のように入力しました。
１２３［ＴＡＢ］４［ＴＡＢ］５［ＴＡＢ］６［ＴＡＢ］７［ＴＡＢ］８［ＴＡＢ］９［ＴＡＢ］ａ［ＴＡＢ］ｂ［ＴＡＢ］ｃ［ＴＡＢ］ｄｅｆｇ［ＴＡＢ］ｈ［ＴＡＢ］ｉ［ＴＡＢ］ｊ［Ｃｔｒｌ］＋［Ｒ］
上から１０行目と１１行目です。
最後に［Ｃｔｒｌ］＋［Ｒ］を入力しましたから、そこに＃が表示されたあと、改行が行なわれ、入力された通りにその下に再表示されました。
１２行目と１３行目です。
そこでも、もう一度［Ｃｔｒｌ］＋［Ｒ］を入力しました。
そこに＃が表示されて、その下に入力バッファの内容が再度表示されました。
１４行目と１５行目です。
ここでは［ＢＳ］を入力し続けました。
カーソルが左端になっても、さらに何回か［ＢＳ］を入力しました。
そのあと［Ｃｔｒｌ］＋［Ｒ］を入力しました。
下（１６行目）に、バッファの内容が再表示されました。
バッファに入っているデータが少なくなっていることがわかります。
そのあと［Ｅｎｔｅｒ］を入力しました。
その下にバッファの中味が文字で表示されたあと、１６進数でダンプ表示されました。
ダンプリストの左端がバッファのサイズです。
最大値のＦＦ（２５５）になっています。
その次の数値が、現在バッファにある文字数です。
［ＢＳ］を入力し続けて、カーソルが画面の左端に来てしまうと、画面上ではそこからは変化しませんが、バッファの中味は［ＢＳ］の入力に応じて、削除が進むことがわかります。
次は［Ｃｔｒｌ］キーの入力を試してみました。
ちょっと説明が長くなってしまいましたので、上の画面の、その部分から下をもう一度お見せすることにいたします。
次のように入力しました。
［ＴＡＢ］ａ［ＴＡＢ］ｂ［ＴＡＢ］ｃ［ＴＡＢ］ｄ［ＴＡＢ］ｅ［ＴＡＢ］ｆ［ＴＡＢ］ｇ［ＴＡＢ］ｈ１２３４５６７８９０［Ｃｔｒｌ］＋［Ｚ］［Ｃｔｒｌ］＋［Ｇ］１２３４５６７８９［Ｃｔｒｌ］＋［Ｚ］［Ｃｔｒｌ］＋［Ｇ］［Ｃｔｒｌ］＋［Ｒ］
最後に［Ｃｔｒｌ］＋［Ｒ］を入力しましたから、そこに＃が表示されて改行が行なわれ、下に入力した通りに再表示が行なわれました。
そこでも［Ｃｔｒｌ］＋［Ｒ］を入力しましたので、さらにその下に同じものが再表示されました。
下から３行目と２行目です。
今度は再表示された２行目（画面下から２行目）で、カーソルが画面の左端に行くところまで［ＢＳ］を入力しました。
そしてそこでさらに［ＢＳ］を２回実行してから［Ｃｔｒｌ］＋［Ｒ］を入力しました。
その結果画面左端に＃が表示されています。
［Ｃｔｒｌ］＋［Ｒ］を入力しましたから、改行後にコンソールバッファの内容が再表示されましたが、そこでは１行目の行末に再表示されていた’＾Ｇ１’が、最後に入力した２回の［ＢＳ］によって削除されたため、表示されなくなったことがわかります。
おお。
［ＢＳ］の連続入力によって、画面上のカーソルが画面左端にとどまったあとも、コンソールバッファの中味は削除され続けています。
成功です。
これで。
やっと、ファンクションコール０Ａは完了です。
ワンボードマイコンでＣＰ／Ｍを！［第１３２回］
２０１２．５．２７ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る