HRA's note

[1chipMSX改]

V9958調査資料～ARBITER～

VDPの中には、VRAMへアクセスするブロックが複数存在している。
VRAM として使われる DRAM は、１つ（厳密には 8bit幅で２つあるが、16bit幅の DRAM １つとして使っているので
論理的には１つと同じ）しか存在しないため、１度にアクセスできるのは１ブロックのみとなる。

グラフィック系は表示と同期している関係で、一定の間隔でアクセスしており、かつ VRAM の読み取りが
少しでも遅れると表示が乱れてしまうため、最優先のアクセス権を持っている。
スプライト系もモニタに同期している部分に関しては最優先のアクセス権を持っている。
VDP の 21MHz という動作クロックからすると、1画素あたり 4clk あるため、交互にアクセスすればアクセス競合は
発生しない。

一方、ランダムに発生する可能性があるのが、CPU による read/write リクエストと、VDP Command による read/write
リクエストである。
VDP Command は、VDP 内部のブロックであるためタイミング調整可能である。また、CPU による要求はまばらである。
従って、これら２者では、CPU の方に優先度を割り当てることでシステム的に成立している。

スプライトの処理ブロックに、「いまグラフィック系は何をしてるのかな？」という調査をさせたくない。
なぜならば、お互いに状態を知り得て、それに同期して動作するような仕組みにすると、互いの依存度が高くなり、
メンテナンスが難しい回路になってしまうためである。（ソフトウェアにおいて他オブジェクトの内部状態を公開したくないのと同じ理由だ）

したがって、確実に要求に即時応える必要のあるグラフィック系以外は、普通に REQ/ACK インターフェースを採用し、
そのインターフェースタイミングで VRAM アクセス制御を実施することにする。

V9938/V9958 には、16bit のデータバスがあり、そこに DRAM がつながっている。
MSX2 の VRAM64KB の機種は下位 8bit にだけ 64KB の DRAM が接続してあり、
VRAM128KB の機種は上位・下位のそれぞれに 64KB の DRAM が接続してある。

VRAM64KB の機種では、GRAPHIC6,7 (SCREEN7, 8) を利用できない。
容量的には、1page だけ使えても良いように見えるが、これには理由がある。

VDP は、21MHz で動作していて、水平256画素のときに1画素あたり 4clk の時間がある。
GRAPHIC6 は 4bit/画素で水平 512画素なので、1clk で 2画素分読み出せるから、4clk のうち 1clk 消費すればいい。
GRAPHIC7 は 8bit/画素で水平 256画素なので、1clk で 1画素分読み出せるから、4clk のうち 1clk 消費すればいい。
つまり、GRAPHIC6, 7 は、VRAM読み出しという観点では同じということになる。
これに、他の要素であるスプライト、CPU、VDP-Command が加わるため、最悪の場合では 4clk すべてが消費されてしまう。
しかし、このころの DRAM はクロック同期型ではないため、しっかりとタイミングをとってアクセスしなければならない。
4clk すべてで読み出さなければならないとなると、このタイミングをとるための wait を挿入できないため破綻するか、
動いても CPU や VDP-Command の応答が遅くなり、実用的な速度で運用できなくなる。
いわゆる DRAMバンド幅不足という状態に陥る。

そこで、8bit幅の DRAM を２つ並列に搭載することによって、確実に連続アクセスすることが保証されるグラフィック系で
1clkで16bit同時読みを実施することにより、DRAMバンド幅を稼いでいる。

常にそのモードで動いていれば高速でうれしいのだが、安価なシステムで VRAM を 64KB しか搭載できない場合には速度を
落として対処すべく、GRAPHIC6, 7 以外のモードでは２つの DRAMを個別にアクセスするようになっている。
残念ながら、モード切替のような機能は入っていないため、DRAM 2つ搭載している機種でも 1つのときと同じ速度で動作する。

ということで、ARBITER部分を設計してみた。

回路図とタイミング

[▲上へ]