行スクロールは愛の力で乗り越えろ
ＤＯＳはディレクトリ周りとＦＡＴの管理が面倒くさかったが、まあ、なんとか動くようになった。
セクタサイズも結局信頼と実績の五一二バイトに変更し、それに伴いＦＡＴサイズも調整した。
「次はコマンドプロンプトか」
昔はＤＯＳ窓ともいったが、ようはコマンドベースの入出力インターフェイスのことだ。
普通コマンドプロンプトには内部コマンドと外部コマンドというのがある。
内部コマンドはその名のとおり、コマンドプロンプト内に組込まれている基本コマンドで、外部コマンドは別ファイルになっている実行アプリだ。
「内部コマンドはｄｉｒとｒｅｎａｍｅとｃｏｐｙ、ｄｅｌｌくらいでいいか？」
今の所、ディレクトリはルートしか無い。
サブディレクトリが無いからディレクトリ関係のコマンドはｄｉｒ以外必要ない。
ファイル一覧を見てコピーして名前を変えて削除する機能があればとりあえずなんとかなるだろう。
「ディレクトリを見れるようにする場合、画面表示をもっと拡張しないとだめか」
現在のＢＩＯＳはキャラクタＲＡＭに書かれたデータと対応する文字を表示する機能しかない。
ディレクトリの一覧を表示するとなれば、文字列を改行したり下まで達したらスクロールしたりしなければならない。
ここらへんはＯＳの仕事だ。
「とすると、ＯＳの強化が先か？」
文字列表示はともかく、画面スクロールは速度的にどうなんだ？
現在全画面書き換えは二秒かかる。
つまり画面スクロールさせようとすれば二秒以上かかることになる。
「一行スクロールさせるたびに二秒とかありえないから」
インベーダーが二秒毎に落ちてきたら恐怖だけど、スクロールが二秒毎だと驚愕しか覚えない。
ちなみにインベーダーとは昔流行ったスペースインベーダーというゲームのことである。
最近の良い子は知らないかもしれないので追記しておく。
って、誰に言ってるんだよ、僕は。
「現在二五行表示だから、五〇ファイルとかあったら、二五行もスクロールする。表示完了するのに一分近いのか」
一分近くディレクトリ表示を見守る自分を想像する。
「わびしい」
わびさびの境地に陥りそうだ。
「どうしたものか……」
今の所、画面スクロールは現実的でない。
「やはり行数を減らすか」
減らせばその分スクロールは早くなる。
半分にすれば一秒だし。
「って、一秒でも遅い。たかがか二五行で三〇秒近く待たされるわけだし、行が半分になる分スクロールする行が増える。結局時短になっていない。……詰んだ」
詰みが多すぎだ。
高速化が実現すれば解決する問題ではあるが、こんな性能では前段階で躓いてしまう。
「スクロールさせるのではなく表示開始位置をずらすのはどうだ？」
スクロールさせる時キャラクタＲＡＭを一行分上の行にコピーしていくのではなく、一行下を一番上の行として表示すれば、外部的にはスクロールして見えるはずだ。
そしてデータを一番上の行に書き込めばそこが一番下になる。
僕も八ビットマシンのスクロールが遅かったから、ＣＲＴＣをいじって表示開始位置をずらして擬似的スクロールを実現したことがあった。
だが、精霊コンピュータではその手は使えない。
いや、できなくはないが早くはならないのだ。
「ＣＲＴＣの場合ＲＡＭの読み込み開始位置を指定するレジスタの数字をいじってやれば、あとはＣＲＴＣが勝手にやってくれるんだけどね」
ＣＲＴＣとはＣＰＵとは別に働く専用チップのことだ。
こいつがＲＡＭに書かれたデータをＣＰＵに関係なしに読み込んで勝手に表示する。
ＣＰＵと別の装置だからＣＰＵの動作には影響を及ぼさない。
しかし精霊コンピュータは画面の表示がＣＰＵ頼りだから、書き換えるにはＣＰＵの動作が必要で、高速化にはつながらないということだ。
もし同じような仕組みにするとしたら魔石がもう一つ必要になるであろう。
まあ、中にはＣＰＵに影響を与えるＣＲＴＣもあったみたいだが。
今は高速なＲＡＭを使ったり、デュアルポートＲＡＭを使ったりしているが、ここで手抜きなのかコストの問題か、低速のシングルポートＲＡＭを使って、ＣＰＵとＣＲＴＣとでメモリを共有していたマシンがあった。
ポートが一本しか無くアクセス速度も遅いからＣＰＵとＣＲＴＣで同時に読み込みに行くとどちらかが待たされる。
ＣＲＴＣが待たされると画面が乱れる。当然であろう。画面はリフレッシュレートに従い六〇分の一秒とかでの書き直しが必要だから、これを待たせると画面更新がスキップされるわけだからその分が表示されない。
その結果画面にノイズが走るのだ。
かといってＣＰＵを待たせると、処理速度が極端に遅くなる。
ＣＲＴＣは絶えずメモリアクセスしてるものだから、ＣＰＵがメモリを使える時間は極端に少ない。
せっかくＣＲＴＣがＣＰＵと独立して動いているのに変に同期をとっているものだから、画面表示がクソ遅いマシンがあったのだ。
もちろんそんなに遅いのではアクション系ゲームには使えない。
後にＣＲＴＣをいじってＣＲＴＣ待ちをしない方法が考案され、ノイズまみれながらもアクション系のゲームができるようしてしまったやつもいた。
プログラマの愛というか執念を感じる。
「そうか、僕には愛が足りなかった」
目が覚める思いである。
昔の人は（僕もだけど）諦めなかった。
愛と執念で様々な困難を乗り越えてきた。
ＭＺ－７００に不可能はないという言葉に感動を覚えたものだ。
僕も同じＭＺ使いとして負けてなるものかと奮起した記憶がある。
「神は乗り越えられる試練しか与えない、らしいからな。これだって乗り越えられるはずだ」
異世界の神もそうなのか知らないが。
僕はこれまでの経験からなにか使えるものがないかと考える。
候補としては全画面を一行ずつ上の行にコピーするのではなく、変更がある文字だけコピーする方法である。
ゲームのマップなどをスクロールする方法として昔はよく使われていたもので、変更箇所だけを書き換えることで、書き換えるデータを少なくし速度を稼ぐ手法だ。
ディレクトリ表示であればファイル名一二文字、データバイト数が数桁、日付と時間で二〇桁もあれば済む。
画面の半分くらいはブランクなのだから、書き換えが必要なデータは半分になる。
画面の書き換えはキャラクタコードを変換してキャラクタフォントテーブルの位置を計算し光魔法で指定位置に投影するいう処理をおこなっている。
掛け算シーケンスとかも実行するから、結構多くのステップ数を要する。
コードを比較するだけなら大した負荷にはならないはずだから、処理時間は半分以下になるはずだ。
それでも三〇秒近い。もしかしたら二〇秒位まで縮められるかもしれない。
それでも遅い。
「……これが僕の限界か？ いや、まだ行けるはずだ。愛があれば不可能はない！」
僕は考えに考える。
全画面スクロールは論外。部分スクロールも、結局書き換え範囲が大きければ全画面スクロールと変わらなくなる。
一番早いのは書き換えを行わない方法であるが、さっき却下した表示位置をずらす方法は本当にだめだろうか？
キャラクタ表示で一番ステップ数を要しているのはキャラクターコードからフォントテーブルの位置を計算するところだ。
今回これは省略できるから、表示位置を指し示す変数だけいじればいい。
これなら全部の処理を再処理するよりずいぶん早くなるはずだ。
ステップ数から考えて五分の一くらい、一〇秒ちょいで二五行のスクロールが終わりそうだ。
「まだ遅いがこれで妥協するか」
スクロールさせる方法としてはこれが最速のようだ。
「スクロールさせるだと。……僕は馬鹿だ」
ディレクトリはとりあえず一覧が見られればいいんだから、スクロールなんかいらなかった。
昔、汎用機のコンソール画面にはログを表示するための専用画面がついていた。
この端末は新しいログを検知すると、一行下に表示し最新行にアンダーラインを引く。そして一番下まで行くと、最上行に表示しそこにアンダーラインを引く。
つまり最新行がわかれば、スクロールさせる必要はない。
そうでなくとも一ページ分表示したら一度止めて、なにかキーを押したらもう一ページ分表示とかしてもいい。
必要ならページアップなりページダウンなりで、一ページずつ表示させればいいのだ。
行スクロールで二秒は耐えられないがページスクロールで二秒なら耐えられる。
「愛の勝利だ」
ログ表示端末風画面表示ルーチンを完成させた。
「ＭＺ－７００に不可能はない」の言葉については検索すればいくつか出てくるかと思います。
今ではＰＣの性能を上げればある程度なんとかなりますが、昔は遅いＣＰＵ、少ないメモリ、しょぼいグラフィックで何とかする他ありませんでしたから、ＭＺ－７００のみならず、他機種でもすごいゲームを作るスーパープログラマが多数いました。
今では開発規模も大きくなり、チーム開発となったため、一人のプログラマが注目されることも少なくなりましたが、それでもまだ、個人で始めて有名になられる方もおり、自分もまだまだ愛が足りないと思う今日このごろ。
