8ビット時代のグラフィックについて

twitterで、X1やSMC-777などのVRAMがI/Oポートの先にある設計おかしいハードだと書かれていたので「あー、今の目で見るとわからんか」と思うと同時に、それがゼンゼンおかしいどころでなく、とてもリーズナブルな設計の一つであったのだ、という話をここに書いておこうと、突然思ったので書く。
まず、当時のパソコンでとても主流だったグラフィックスを解説すると640×200。
RGB1ビットずつのデジタル8色。縦横8で割るとわかるが80×25。つまり当時のキャラクタ画面のドットに1:1対応するグラフィクスだ。
これRGB、それぞれのプレーンのサイズをKBで表すと16KB。
今から見ればカスのようなサイズだけど、アドレスバスが16ビットしかない8ビットマシンでは大問題になる。


アドレスバスが16ビットってことは、64KBが直接アクセス可能なメモリ量ってことになる。ここに16KB*3のプレーン、すなわち48KBを置くと、残りは16KBになってしまう。
なんてこったい、プログラム+システムのエリアがたったの16KBでは話にならない(実際はもっと状況は悪い)。
実はこの問題は初期の8ビットマシンでは大問題で、例えば有名なAPPLEIIなんかも、280×192の高解像度グラフィックスを使うと、48KBのメモリを搭載していても、プログラムに使えるエリアはたったの20KBほどになってしまったし、日立の和製APPLEIIと呼ばれたベーシックマスターL3もその最高解像度の640×200のグラフィクスを使うと、なんとプログラムに使えるメモリは20KBほどになってしまう体たらくだった。
これじゃあたまらない、というのでいくつか方法が考えられた。
その中でメジャーなのが「バンク切り替え」。
16KBのメモリの領域を「バンク領域」として、ポートをぶっ叩くとメインメモリにグラフィックメモリ(以下GRAM)が現れて、直接操作できるって方法だ。
で、twitterではこの88で有名なバンク方式が普通で、素直で、ポートの彼方にあるSMC-777や、X1を変態だと言っていたわけである。
そして、この考え方からしたら、グラフィックス操作専用のプロセッサを使うFM-8/FM-7方式も変態ってことになるだろうw
ところが当時のクソ遅いメモリと8ビットCPUにとっては、このバンク方式は少々ベストとは言いがたい問題がある。
まず当たり前のことながら、GRAMはモニタに表示されるメモリだ。
だから、ビデオプロセッサが常時表示のためにアクセスしている。当時の遅いビデオプロセッサはこれを表示するために多大なメモリアクセスをするわけだけど、このGRAMがメインメモリに現れるとCPUに大問題を引き起こす。
CPUのアクセスとビデオチップのアクセスが競合し、簡単にCPU側にウェイトがかかってしまうのだ。
これを避けるためにイロイロな手があるのだけど、やると基本的にはコストが跳ね上がる。つまりバンク方式にするとGRAMおよびメインメモリのアクセスに多大なペナルティを被る可能性が高い。
実際、初代PCー8801ではシャレにならない多大なペナルティがあり、とてもとても表示は遅かった。だから例えば超有名なファルコムの初期作品、瞬間描画で有名な『デーモンズリング』は、グラフィック表示を完全にオフにすることで、描画速度を稼いでいたりする。
…というか、画面をオフにして、少しでも描画速度を稼ぐのは初代88では全く当たり前な方法だった。
また、それ以外にもこのバンク方式はベストとは言いがたい理由がある。
それは一度に1プレーンしか出せず、しかもそれですら25%もメモリ領域を埋めることだ。
当たり前だけど、バンク切り替えしてるってことはそれより前に、そこには何かが置かれている。そしてバンクで切り替えるってことは、そこにはシステムの割り込みだのなんだのを置くことは出来ない。言い換えると、バンクで切り替えられるメモリ領域に置かれるものにはとても様々な制約が出てくる
実際、PC88では、GRAMの領域にはまともにモノを置けないハメになっていて、BASICとGRAMに挟まれて、プログラムを狭いメモリウィンドウに出すなんてムチャクチャなことになっている。
しかも、そのくせ、一度に1プレーンすなわち、RならRしか出すことが出来ない。だから白のドットを打ちたいなら

1)バンクを切り替えRを出し、Rを書く。
2)バンクを切り替えGを出し、Gを書く。
3)バンクを切り替えBを出し、Bを書く。

と、最低3回書き換えて、ようやく白いドットを打つことができた。もちろんオーバーヘッドも大きい。
つまり、初代PC-88で使われていたGRAMのバンク方式は、当時の技術では遅くなるうえに、メモリエリアを圧迫する方法だったわけだ。
それと比較した時、ポートの彼方にGRAMを置く方式には以下のメリットがあった。
1)メモリ領域を圧迫しない。
当たり前だけど、ポート領域に置かれてるんだから、メインメモリを圧迫しない。
2)基本的にメインメモリのアクセス速度に影響を及ぼさない。
メインメモリにいないんだから、干渉するわけがない。
3)全部のプレーンを平等における。
ポート側は16Kもあればポートの数は足りるので、48KBのグラフィック領域をフルに置いても問題がない。
もちろん弱点もあって、必ずポートに対して出力するアドレスを設定しないといけないとか、ブロック転送命令が使いにくいとか、やっぱメンドクサイところはあった。
ただ、これはバンク方式と比較して、致命的な問題とは言いがたかった。
だから8ビットコンピュータでは、GRAMがポートの彼方にあるって方式も十分に合理性はあったのだ。

LinkedIn にシェア
Pocket

7件のコメント

  • AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
    リーズナブルではあるんですが、Z80のI/Oポートのアドレスは8ビットしかない、というのが表向きの仕様だったと思います。初めて見たときは少々驚きました。

  • AGENT: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
    Z80の裏仕様
    out (C),A
    アドレスバスの上位8bitにBレジスタが出るため、実質 out (BC),Aとなるを利用した設計ですよね。
    ただし、これをやると traditionalな OUT 即値, A が使えなくなるデメリットがあり、ソフトウェア資産の後方互換性が損なわれる。

  • AGENT: w3m/0.5.3
    88/98が主流だった頃は、パックトピクセルすら変態扱いでしたよね。
    いや、懐かしい。

  • AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
    理由の 2) は間違いですよね。VRAMをメモリ空間に置いても、I/O空間に置いても、Z80のバスにぶら下がっている以上は同様に干渉が発生します。
    初代88が遅かった主要な要因は、PC-8001と同様にメインメモリからCRTCにテキスト画面用のデータを随時DMAで転送していたためにCPUの処理時間を奪われていたからで、グラフィックVRAMがバンク切り替え方式であったこととは無関係です。初代88でもテキスト画面のDMAを止めればグラフィック画面をオフにしなくとも4MHz Z80A(+メモリ1ウェイト)なりの速度が出ます。
    また、バンク切り替え方式のVRAMを搭載していて特に高速化のための仕掛けを持たない設計でも普通に速い例として、MZ-2000が挙げられます。

  • AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
    >> youkan 様
    間違い指摘ありっす。
    そいやMZ-2000はバンク形式だったんですが、速かったかというと、印象は微妙だったりします。
    確か当時、MZ-80Bから移行したのもあって、カラー版はグラフィックの負荷が大きくて(面積2倍*3プレーンの6倍だから当たり前なんですが)、相対的には低速な印象がありました。

  • AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; BTRS122080; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
    初代PASOPIAもI/Oの彼方にVRAMがあるんですが、
    8255にVRAMが繋がっていて、アドレスとかデータとか
    CS/WE/OEを手取り足取り操作してやるという、
    まごうかたなき変態アーキテクチャだったりします(を
    QC-10では、uPD7220経由でしかVRAMにアクセス
    出来ないんですが、これはむしろCPUのバスからも
    VRAMを叩ける98とかの方が変態かもしれませんね。

  • AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
    はじめまして
    紅茶羊羹さんのツイートから流れてたどり着きました。
    書かずにはいられな内容なので横槍入れさせて頂きます。
    >OUT 即値, A が使えなくなるデメリットがあり
    SMC-777はCレジスタが上位、Bレジスタが下位アドレスなのでOUT即値もブロック転送も使える16bit I/Oでした。
    レジスタスワップや桁上りが面倒で不便と言うかもしれないけど、CRTCに依存した縦8ドットごとのアドレスが既に面倒だし、
    速度重視で8bit INC/DECを多様するからデメリットよりメリットのほうが大きい。秀逸な設計。

コメントは現在停止中です。