メッセージデータの形式が決まれば、次は実際の処理の流れです。スクロールは、1ドット単位で行われます。そのため、画面下部で文字を描いているのが見えるのは、あまりエレガントとは言えません。また、スクロール中は、その追加文字列の表示を壊すわけにもいかずで、意外と複雑な構造が要求されます。さらに、全画面コピーだと処理速度が足りずにたらつきます。2画面切り替えのようなハードの支援がない場合は、コピーの速度はできる限り高速に行う必要があります。今回は、そのような処理の実装に必要な構造を解説していきます。

メッセージデータの解説はこちらを参照してください。



  • 処理全体の流れとメモリ構成
スクロールアップは大きく2つの処理に分解できます。まずは画面に表示されている文字を1ドット上にずらす処理です。ハードウェアスクロールの機能がないマシンの場合は、これが案外重いです。そして、上にずらした後の最下行に、新しい文字列の1ラインをコピーする処理が必要です。つまり「スクロール」と描画バッファからの「新しいラインコピー」のセットで初めてエンドロールアップの処理が出来るのです。下記にイメージを掲載します。
※ 数値は参考なので、実際の値と異なる可能性があります。
メモリ構成
スクロールは文字の範囲だけをずらす対象に限定します。そのため、各行にコピー開始の左側の座標と、コピーの長さを情報として格納して、その情報を確認しながらコピーしてきます。PC-8001mk2 の場合ですと、横幅80バイトで縦の解像度が200ラインですので、1ラインに2バイトとして、テーブルワークが 400バイト必要となります。改行だけのラインではコピーが不要ですから、それを早い段階で確認するために、テーブルの格納順は、コピーサイズと左側座標としています。コピーサイズが 0 ならそのラインは改行なので、何もせず次のラインに処理を移せば終わるためです。

新しいラインコピーは、少し面倒です。画面のスクロールアップが終わったら、行バッファに文字列を描き直す処理系とした場合、1行毎に処理が集中してカクつきます。スクロールにおいてはたらつきとカクつきは、極力避けるべき見苦しい挙動なのです。これを避けるために、表示用の行バッファと、次のために事前に文字列描画は行う編集バッファの2つを用意します。所謂ダブルバッファです。

描画バッファから実画面の最下位ラインに、1ラインずつコピーしながら、編集バッファにその次のメッセージデータを描画しています。描画バッファから全てのデータを実画面にコピーし尽くしたら、描画バッファと編集バッファを入れ替えて、また描画バッファの先頭から実画面に1ラインずつコピーしながら、編集バッファをクリアして次のメッセージを作成するという流れを文字列の終了まで繰り返しています。
※ 絶対美味しい!
続いては、新しい行の描画です。
文字表示処理そのものではなくて、処理分散についての解説がメインとなります。