2012.5.27
前へ
次へ
ホームページトップへ戻る

復活!CP/M ワンボードマイコンでCP/Mを!
CP/MがTK−80互換のワンボードマイコンの上で復活します
ND80ZVとMYCPU80の上でCP/Mが走ります

[第132回]


●昔の端末のCRとLF

前回と前々回、LFについて書きましたところ、CP/Mマイコンシステムの開発をご依頼いただいておりますY様から、昔の端末のCRとLFについての情報をメールしていただきました。
Y様は昔のミニコン、パソコン及び当時の業界の事情に通じていらっしゃって、ときどきお寄せいただくメールはとても参考になります。
せっかくの情報を私ひとりがいただくだけでは勿体無いので、Y様からご承諾をいただき、ときどき機会をみつけて、皆様にもご披露させていただきたいと思っております。

以下、今回Y様からいただきました、昔のミニコン端末のCRとLFについてのメールをそのまま転載させていただきます。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

メカの塊であるテレックスを端末に利用した時代、つまりテレタイプ社のASR33や、互換性があるTTY端末を利用していた時代は、「復帰」と「改行」は個々に文字どおりの動作をしていました。

「復帰」コードを送ると、「キャリッジ」つまり「印字ヘッド」が「ギィーガチャン!」と音を出して左端に移動しました。

「改行」コードを送ると、「印字ヘッド」の位置はそのままで、「ゴムローラー」が「カクン」と音を出して1行分ロールペーパーを送りました。

送信順番は、必ず、「復帰」が先で「改行」が後でした。

これは、「復帰」の実行には印字ヘッドを動かすので時間がかかるためです。

「復帰」コードだけを送り、その後に文字コードを送ると同じ行に文字の重ね打ちができました。

この重ね打ちのテクニックを利用してプリンタ用紙に微妙な濃淡で「モナリザ」などの精巧な文字絵をプリントしていました。(1975年当時一般の方に大受けでした)

このようにメカのテレタイプ(TTY)を利用していいた時代は、「復帰」と「改行」は個々に機能していました。

テレタイプのキーボードにも、「復帰」と「改行」は個別のキーが有りました。

1975年頃からテレタイプに替わり、ビデオ端末や、ドットマトリックス印字ヘッドを持った新型の端末が出現しました。

これらの端末の内部制御には8080やZ80を利用していてユーザー設定でエスケープシーケンスなどが定義可能でした。

この時期の端末には、「改行」コードの動作として、意味どおりの「改行」だけと、「改行」コード単独で「復帰」と「改行」の二種類の動作を同時に行うという選択設定が出来たようなおぼろげな記憶があります。

ホストから「改行」が送られて来るというのは、同じ場所で一行下へカーソルを移動するのではなく、一行下で、なおかつ、次の行の先頭にカーソルを移動するという意味と解釈した方が合理的という考えと思われます。

ビデオ端末では「印字ヘッド」を移動する時間は不用なので、1文字分の時間稼ぎを行う必要が無くなったのも関係していると思います。

1975年頃から主流になったビデオ端末は、エスケープシーケンスでカーソルを上下左右に自由に動かすことが出来たので、印字ヘッドの位置を「復帰」と「改行」で制御する必要がなくなりました。

文字を画面表示する場合は、「改行」コード単独で「復帰」と「改行」の二種類の動作を行い、カーソル移動にはエスケープシーケンスで行うという方法が採用されたと記憶しています。

このようなビデオ端末は、「復帰」と「改行」の両方を送信してくるホストにも対応できるように「復帰改行モード切替」機能があり、「改行」コード単独で「復帰」と「改行」を行う機能を止めて、「復帰」と「改行」は個別に画面上で動作するように切り替えることができたと思います。

このような「改行」コード単独で「復帰」と「改行」する機能はUNIX系で採用されたようです。

テレタイプ端末を標準コンソールとして利用されたCP/M系は、「復帰」と「改行」は個別に機能するようになっていたと思います。

「復帰改行モード切替」が適切に設定されていない状態でホストからの通信を受信するとビデオ端末の画面表示がメチャクチャになった記憶があります。

はるか昔の記憶なのでアヤフヤな部分が多いですが、記事を拝見して「復帰改行モード切替」機能という設定がビデオ端末側にあったということを思い出したのでご連絡いたしました。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

Y様。
いつもながら貴重な情報をお寄せいただき有難うございました。
そうですよね。
私も確かその昔の端末で、ヘッドが行の途中で止まったまま、紙送りがズズズズ…というように働いていたような記憶があります。
いずれにしましても遠い昔のお話です。
ちなみに今回いただいたメールにあります、エスケープシーケンスも今では過去のものになってしまいました。
Windows7のコマンドプロンプトではエスケープシーケンスは使えません。

●テレタイプの印字速度

Y様から追加のメールが届きました。
テレタイプの印字速度についての追伸です。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

テレタイプ時代の印字速度は今の方には想像を絶する遅さですので追加説明を送ります。

「復帰」と「改行」の時代から「改行」だけの時代に移行したのは、テレタイプ端末からビデオ端末に進化した頃だと思います。

「復帰」と「改行」の時代というのは、通信速度110bpsのテレタイプの時代です。

テレタイプを利用したことが無い方には想像を絶する時代です。

「復帰」と「改行」を含めて1秒間に10文字しか出力できない表示(印字)装置です。

つまり「復帰」と「改行」を含めて1分間に600文字しか印字できませんでした。

しかも、印字中は物凄い騒音と振動です。

このテレタイプの横で眠れるのは凄腕プログラマーの証でした。

マイコンには、今の様な画面などはありませんから、アセンブラリストを見るためには印字するしかなく、印字には5分から10分ぐらいかかりました。

紙テープへのメモリダンプには20〜30分位かかりました。

スタートレックゲームや、チェスゲームをするときは、1手進める毎に30秒間位「ガシャガシャガシャ・・・・ギーガチャン」印字していました。

テレタイプ社のキーボードと印字装置が付いたテレタイプ端末の説明がWikiにあります。
http://ja.wikipedia.org/wiki/ASR-33

プリンターの後ろにある横長のロール紙(大きなトイレットパーパーのようなもの)をゴムローラーに巻きこんで印字します。

テレタイプの「改行」とは、ゴムローラーを回して、このロール紙を1行分送る操作です。

ビデオ端末での「改行」は、カーソルが一段下の行に移動しますが、テレタイプでは、印字する紙が1行上に送られるだけで印字ヘッドが下に下がるわけではありませんでした。

この辺のところは現状のPCから入門した方には想像できない部分だと思います。

ビデオ端末は、テレタイプと同じく文字しか表示できませんでしたが、初期のビデオ端末に4800bpsの通信速度、つまり1秒間に約500文字程度の文字が画面いっぱいに一気に表示されたときは驚異的でした。

表示速度が、1秒間に10文字から、1秒間に500文字に激変しました。

しかもビデオ端末には、蒸気機関車のような騒音と振動もありません。

それまで、リストを取る間は、珈琲ブレークだったプログラミングの効率が一気に向上しました。

1977年頃の初期のビデオ端末 ADM−3  キットは840ドル 完成品は1080ドル 日本のマイコンショップで35万円位でしたが、当時としては低価格でした。
http://www.old-computers.com/history/detail.asp?n=32&t=3

1978年発売 DEC社のベストセラー ビデオ端末 VT−100  復帰改行モード切替機能あり
http://ja.wikipedia.org/wiki/VT100

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

Y様。
追加情報をお送りいただき有難うございました。
今後ともよろしくお願いいたします。

●ファンクションコール0Aのバッファサイズ

[第130回]で、CP/M互換DOSのファンクションコール0Aを、CP/M2.2のファンクションコール0Aと同じ動作をするように、プログラムを大幅に書き直してしまいました、と書きました。
まるっと1日以上を費やしてしまいました。
そして書き直したあとのCP/M互換DOSでファンクションコール0Aのテストプログラムを実際に実行して、CP/M2.2と同じ動作をしているところの画面をお見せしました。

これで、やれやれ一件落着。
と思ったのでありますが。

まだ続きがありました。
前回までの説明でファンクションコール0Aをテストするために使ったFTST9.COMは、[第64回]で作ったものです。
それでその[第64回]を念の為にということで、読み直していましたら、あれま、だめじゃないの、ということに気が付いてしまいました。

実はテストだということでFTST9.COMのファンクションコール0Aでは、コンソールバッファのサイズを20文字にしておりました。
しかし、そこのところを読みましたら、バッファの最大サイズは256バイトだと書いてあります。
あ。
たった今気が付きました。
ここは誤記でありました。
正しくは255バイトです。
むむ。
[第64回]も訂正しておかなくては(そのように訂正いたしました)。

これはまた、どえりゃあことです。
今まで私はなんとなく、コンソールバッファの最大サイズは画面の1行と同じ80バイトだと思い込んでおりました。
それだと入力時のエコーとも一致していて都合が良いと考えたからでもあります。

いや。
大体その考えがそもそも間違っていたのです。
そういうことではないでしょう。
おそらく聡明なる読者におかれましてはすでにお気づきのことと思います。

たとえばTAB。
TABを使いますと、コンソールバッファには1バイトのタブコード09Hだけが入りますが、画面にはカーソル位置によって最大8個の空白が出力されます。
もしもTABばかりを入力したとしますと、80×8=640バイトの空白が表示されますから、それだけでも8行表示されることになります。

しかも。
それが最大80バイトではなくて、最大255バイトだったとしますと。
あかん。
もお。
また、やり直しだあ。

一瞬、目の前が真っ白になりました。

ここは一番落ち着いて、気を取り直して。
とにかく、まずは熱いコーヒーなどを入れまして。

うーん。
落ち着いてよく考えてみますと。
たとえバッファが255バイトではなかったとしても(上に書きましたようにバッファサイズが80バイトだったとしても)、エコー表示した結果は1行では表示できなくて、2行以上にわたって表示されてしまうことも大いに考えられます。
ましてバッファが最大255バイトにもなるということになりますと、エコー表示が複数行になってしまうというのは必然です。
オリジナルのCP/M2.2では、それはそのようになっているだろうということは、確かめてみるまでもありません。

そして。
エコー表示をするだけならば、80字を超えて表示を続ければ勝手に改行が行なわれて、その下の行に表示が続けられますから、そこは別に問題ではありません。
バッファのサイズが最大80バイトだとして書いていたプログラムを、最大255バイトまで扱えるように書き直すだけで済みます(当然バッファに割り当てるメモリもそれだけのサイズを確保しなければなりませんが)。

しかし。
エコー表示が2行以上になってしまった場合、そこでの[BS]はどのように働くのでしょうか?
80字以上を入力した(もしくはTAB、Ctrl入力などを多用した)結果、エコー表示が2行以上になってしまい、カーソルの表示が最初に入力を開始した行の下の行に移ってしまっている場合に、そこで[BS]を入力し続けたらどうなるか?という疑問です。

[BS]を入力し続ければ、当然カーソルはその行の左端に到達します。
そこでもさらに[BS]を入力したら?
カーソルが上の行に戻る?
いえ。
それはありません。
スクリーンエディタでもない限り、カーソルを上の行に戻すことはできません。
CP/M2.2では、そのような機能は想定していません。
するとどうなるか?

CP/M2.2でその動作を確認してみました。
カーソルがその行の左端に到達したあとも[BS]を入力した場合、カーソルの表示は左端にとどまったままになります。
しかし実はバッファの中では[BS]が実行され続けるのです。
つまりそこからは「目に見えない」状態になってしまいます。

ああ。
それで。
やっと[Ctrl]+[R]の機能が納得できました(違っているかも知れませんが)。
そのような状態(バッファの中味が画面に正しく反映されなくなった状態)になったときには、そこで[Ctrl]+[R]を入力すると、現在のバッファの内容が正しく再表示されます。

なるほど。
そういう動作なら、理屈に合っていますし、無理はありません。
しかし。
そのように[BS]を操作した結果、画面上ではカーソルが左端に張り付いたままの状態になって、それでいてバッファの中味だけが[BS]によって削除されていく、などという動作は、どのようにプログラムしたらよいのでしょうか。

しばらく。
はたと考え込んでおりましたが。

むうう。
よくはわからんが。
どうも、このままでいけるのではあるまいか。

つまり。
バッファのサイズを、当初の80バイトから255バイトに変更することと、TABが画面の右端から先に進まないようにしていたところを、次の行に移ってTAB表示を続けられるように変更することは必要だけれども、上で説明した[BS]の動作はそのままのプログラムでも、してくれるのではないだろうか。
という気がしてきました。

そう思ったら、あれこれ考えていないで、まずは試してみるのが一番でありましょう。

結果は、ビンゴ、でありました。
下はそのときの画像です。
ND80ZV上で、現在作成中のCP/M互換DOSを起動して、そこでFTST9.COMを実行して、入力を行なっています。
FTST9.COMは[第64回]で作った、ファンクションコール0Aをテストするためのプログラムですが、バッファサイズを当初20バイトにしていたところだけ、255バイト(FFH)に変更しました。



画面一杯に文字が表示されていて、このままではなにがなんだかよくわからないと思います。
順番に説明をいたします。

最初に連続してキー入力を続けていきました。
入力した文字数をあとからでも数えやすいように、1234567890a1234567890b…というように入力していきました。
…w12まで入力したところでバッファが一杯になり、そこで入力が打ち切られて下にバッファの中味が表示されました。

その下にはバッファの先頭の23バイト分の内容が16進数で表示されています。
1234567890aで11バイトです。それがa…wまでですから、11×23=253バイトです。
そこに最後の’12’の2バイトを加えるとちょうど255バイトになります。
おお。
計算は合っていますね。
ここまではOKです。

その次は、下のように入力しました。
123[TAB]4[TAB]5[TAB]6[TAB]7[TAB]8[TAB]9[TAB]a[TAB]b[TAB]c[TAB]defg[TAB]h[TAB]i[TAB]j[Ctrl]+[R]
上から10行目と11行目です。

最後に[Ctrl]+[R]を入力しましたから、そこに#が表示されたあと、改行が行なわれ、入力された通りにその下に再表示されました。
12行目と13行目です。

そこでも、もう一度[Ctrl]+[R]を入力しました。
そこに#が表示されて、その下に入力バッファの内容が再度表示されました。
14行目と15行目です。
ここでは[BS]を入力し続けました。
カーソルが左端になっても、さらに何回か[BS]を入力しました。
そのあと[Ctrl]+[R]を入力しました。
下(16行目)に、バッファの内容が再表示されました。
バッファに入っているデータが少なくなっていることがわかります。

そのあと[Enter]を入力しました。
その下にバッファの中味が文字で表示されたあと、16進数でダンプ表示されました。
ダンプリストの左端がバッファのサイズです。
最大値のFF(255)になっています。
その次の数値が、現在バッファにある文字数です。
[BS]を入力し続けて、カーソルが画面の左端に来てしまうと、画面上ではそこからは変化しませんが、バッファの中味は[BS]の入力に応じて、削除が進むことがわかります。

次は[Ctrl]キーの入力を試してみました。
ちょっと説明が長くなってしまいましたので、上の画面の、その部分から下をもう一度お見せすることにいたします。



次のように入力しました。
[TAB]a[TAB]b[TAB]c[TAB]d[TAB]e[TAB]f[TAB]g[TAB]h1234567890[Ctrl]+[Z][Ctrl]+[G]123456789[Ctrl]+[Z][Ctrl]+[G][Ctrl]+[R]

最後に[Ctrl]+[R]を入力しましたから、そこに#が表示されて改行が行なわれ、下に入力した通りに再表示が行なわれました。
そこでも[Ctrl]+[R]を入力しましたので、さらにその下に同じものが再表示されました。
下から3行目と2行目です。

今度は再表示された2行目(画面下から2行目)で、カーソルが画面の左端に行くところまで[BS]を入力しました。
そしてそこでさらに[BS]を2回実行してから[Ctrl]+[R]を入力しました。
その結果画面左端に#が表示されています。

[Ctrl]+[R]を入力しましたから、改行後にコンソールバッファの内容が再表示されましたが、そこでは1行目の行末に再表示されていた’^G1’が、最後に入力した2回の[BS]によって削除されたため、表示されなくなったことがわかります。

おお。
[BS]の連続入力によって、画面上のカーソルが画面左端にとどまったあとも、コンソールバッファの中味は削除され続けています。
成功です。
これで。
やっと、ファンクションコール0Aは完了です。

ワンボードマイコンでCP/Mを![第132回]
2012.5.27upload

前へ
次へ
ホームページトップへ戻る