MS-DOS総合スレッド ２

ハードウェアスクロールでビューポート自体はレジスタに一発投げるだけで移動できたとしても、
その後一行分のテキストを書き換える作業の重さがテキストVRAMとは比べ物にならんのよ。
しかも単に表示用のVRAMに書き込めば良い訳ではなく、そこに書き込むフォントのデータを
どこかから読んできてラスタオペレーションまでかけてやらなければならない。
結局、一行書き換えるためにその数倍のメモリをCPU自身がやり繰りする羽目になる。
これが、テキストVRAMを持たない環境のコンソール表示の重さの元凶。

PC(AT)でさえ、ハードウェアスクロールを持った環境でさえ処理即が98に比肩するに至ったのは
実にPentiumの世代で、486ではywrap対応のV-TEXT環境でさえまだキツかった。

ちなみにX68kの場合は横768ドット、16ドットフォントの漢字で48文字が一行となり、
16ドットフォント48文字分のテキストVRAMは1プレーンあたり3072bytes、3KB丁度。
16色表示だとこれが4プレーン分で12288bytes、
X68kはGRCGのような複数プレーン同時アクセスの手段が無いためこれを馬鹿正直に書き込む事になる。
しかも12KBは表示用VRAMの容量に過ぎず、実際はさらにフォントを最大48文字分3072bytes
どこかから読んで来ることになるし、そのビットマップを引くにあたってShiftJISから句点コード等への
変換・テーブル参照といった処理まで全部、CPUが自前でやらなければならない。
デフォルトだとフォントはアクセスの遅いROMに載ってるから、さらに三重苦・四重苦と続くわけだ。

98の場合は、カラー・アトリビュート情報まで合わせても漢字1文字あたりわずか4バイト、
テキスト画面をスクロールさせる際はTVRAM全体の再書き換えが必要になるとはいえ、これも4KBで済む。

さらに細かく付け加えるなら、86系はバイトオーダーのアクセスにもペナルティは全く無いが、
68000では奇数バイトへのワードアクセスが基本的にできないため、奇数桁から始まる漢字の処理などは
さらに前後ワードも合わせて読み書きしなければならず、2倍・4倍とアクセスするメモリの総量が雪ダルマ式に増大する。
これをたった10MHzのMC68000で処理するのがどれだけマゾいか、って話ですわ。

で、同じ処理を例えば98の10MHzのV30でGVRAM(x68kのTVRAMに相当)に対して行ったら、
そりゃもっとマゾいわけで…フォントのビットマップパターンの読み取りからしてx68kのようには行かんしね。
だからこそTVRAMを搭載して、これが威力を発揮したというわけ。
TVRAMにコードを書くだけであとはCRTCが全部やってくれる、まあメモリもCPUも遅く・少なかった時代には必須ですな。

GVRAMに対して力技でやってTVRAMに比肩するに至るのは、上にも書いたけどPentiumの世代。
V-TEXT環境はこれはこれで快適だったけど、98のようにGVRAMをバックに壁紙として合成するのはさすがにまだ無理だった。

壁紙とテキストの合成をCPUで力技でやって概ね問題のない速度を出すにはMMX命令が最低条件で、
半透過とかまともにやりたければSSEを要求、CPUでやるのは御免だと言うならDX7世代以降のGPU持って来い…ってもうつい最近の話じゃねーかって事になる。

ハードウェア処理がどれだけCPUやメモリに対して省力化をもたらしたか、その恩恵がどれだけ大きかったか、って事ですなあ。
で、x68kのTVRAMに関して言えば、キャラクタ型TVRAMを搭載しなかった事は
当時のプロセッシングパワーとのバランス的に明らかに失策だったと。

結果、ROMで持ってるフォントをメモリに転写してウェイト処理を回避したり、ループ展開した汚いコードで少しでも速度を稼いだり、
16色表示を諦めて2プレーンや1プレーンに手抜きしたりしてまでテキスト処理を軽くしようと無駄な努力を繰り返しても、
98のTVRAMの軽さには敵わなかったと。
030環境でやっとなんとかひと息、結局CPUとメモリの速度が上がるまではどうしようもなかったって歴史がある訳ですな。
ま、その頃のPCは既に486通り越してPentiumだったりしたわけですが。