ライト時のデータバス衝突

FM-8もFM-7も、オプションのZ80カード上のデータバスバッファには、双方向バッファ74LS245を使用しています。245ではDIRにより方向制御を行いますが、6809の場合方向制御は$\text{R/}\overline{\text{W}}$信号であり、ノーマリリードです。ノーマリリードとは、ライト時以外は常にリード方向、すなわち周辺からCPU方向にバスバッファの方向を向ける制御方式です。Z80にも似たような信号であるライト時を示す$\overline{\text{WR}}$があるため、FM-8のZ80カードではこれをデータバスバッファのDIRに接続していました。

ところが、図267.1を見るとわかるように、$\overline{\text{WR}}$はストローブ信号であり、データバスバッファの方向制御に使用すると、

• T1のクロックの立下りからT2のクロックの立下りまで(1クロックのデータセットアップタイム)
• T3のクロックの立下りから立上がりまでの間(0.5クロックのデータホールドタイム)

の2つの期間において、CPUはデータを出力しているにも関わらず、バッファはリード方向となっています。すなわち、Z80と245の間でバスが衝突します。

図267.1 メモリリードライトサイクルの波形

通常、Z80システムではデータバスバッファのDIRには$\overline{\text{RD}}$を用います。すなわち、Z80はノーマリライトバスアーキテクチャです。

バス衝突の解消

まず、データバスバッファのDIRに$\overline{\text{RD}}$を用いれば、CPUとバスバッファの間のバス衝突は解消できます。FM-7のZ80カードではこの方式をとりました。

次に問題になるのがシステムバスのRWBです。データバスバッファ方向制御が$\text{R/}\overline{\text{W}}$であることから、同じ信号をシステムバスに出力するのが最も容易ですが、一方、これはノーマリライトのバスアーキテクチャであることを意味します。従って、システムバスアーキテクチャの変更にはリスクがあるため、無理やりノーマリリードの信号を作り出しています。

まずM18.4によりリフレッシュでないメモリ要求信号(!RFSH & MREQ)を作成します。

図267.2 M18周りの回路

これはリードとライトの両方でアサートされるため、次の図のように$\overline{\text{RD}}$信号で打ち消し、ライト信号を取り出します(M19.8)。これは同時変化の信号の論理を取っているため、M5のDFFを用いてクロックで叩きます。これが基本的に$\text{R/}\overline{\text{W}}$となります。

図267.3 M5周りの回路 バッファの方向制御に関して、CPUバスバッファ、システムバスバッファの両方ともにアナログ遅延を入れ後縁を伸ばしていますが、これはデータホールドタイムの保証目的だったと思います。バス容量によるホールドタイムを考えれば不要かもしれません。

バス衝突の確認

上記のとおり、バスの方向制御を作成しましたが、残るのはデータバスバッファ(ノーマリライト)と周辺(ノーマリリード)の間でのバスアーキテクチャの食い違いであり、この間でのバス衝突です。以下ではこれを確認します。バッファの衝突の可能性があるのは、

• 周辺バッファはリード方向
• データバスバッファはライト方向

であるから、下図において、M5.5($\text{R/}\overline{\text{W}}$)=Hのときです。さらにEB=Hの時に周辺からデータが出力されます。一方、データバスバッファは$\overline{\text{RD}}$=Hの際に周辺方向になるため、これらをANDすれば、リードサイクルのEBの後縁及び、ライトサイクルのEBの後縁のみであり、DCパスは無いことが確認できました。

図267.4 メモリリードライトサイクルの波形

---

前のブログ 次のブログ