2019-09-10 23:41 — asano
カテゴリー:
前回に引き続きメモリ基板についてです。今回はDPSRAM構成になった理由を書いてみたいと思います。
これまでに検討した方式には次のようなものがあります。
- SRAM only
一番最初に考えたのはSRAMのみを使うものです。256kbit(32k×8bit)SRAMを2つ使えば多くの8ビットCPUのメモリ空間を満たすことが可能です。これをROMエミュレータと同様に切り替えて使います。ターゲットと同時にアクセスすることはできませんので、アクセスするときはターゲットCPUをリセットしておきます。ターゲットとして特定のCPUを想定しないのでZ80のBUSRQやWAITのような信号を使ってアービタを実装するわけにはいきません。起動させるだけならこれでも構いませんが、何らかのモニタを動作させようとすると最低限コンソールが必要です。
- SRAM + UART
上記構成に何らかのUARTを追加します。簡単ですがいくつかの問題があります。- UARTなどのペリフェラルのRD,WRのタイミングはSRAMのそれより制約が多いのが一般的です。
- ターゲットにI/O空間が無い場合アドレスデコーダが必要になります。CPUによってメモリマップの制約が異なるのでデコードアドレスを切り替える仕組みが必要です。
- 6502のように意図しないメモリアクセスがおこる場合も要注意です。
- SRAM + ハンドシェイクポート
ポートを汎用ロジックで構成すれば制御信号のタイミング問題・意図しないアクセスは対応可能です。
ハンドシェイクポートの回路の配線量が増えるのと制御マイコン側のソフトウェアで対応が必要になります。 - SRAM + FIFO
上記ハンドシェイクポートをIDT7200のようなFIFOで置き換えて配線量を減らそうとした案です。 - SRAM + DPSRAM
汎用SRAMでそれなりのRAM容量を確保しつつ、共有メモリ経由でコンソールなどのI/O機能を確保します。 - DPSRAM only
RAM容量をあきらめて全メモリをDPSRAMでまかなうものです。アドレスデコーダが不要になるので非常にシンプルな構成になります。コストを度外視すれば容量を増やすことはできます。
1.の場合、コンソール他すべてのI/OはCPUボード側に必要になります。とにかくいろいろなCPUを動かしてみるという目的から、CPUボードは多数製作することになると思うのでこれはできれば避けたいところです。
2.~5.は複数のデバイスを使うことになるので何らかのアドレスデコーダが必要になります。アドレスデコーダをメモリボード側に持てばCPUボードが多少簡単になりますが、CPUにあわせてメモリマップを切り替えなくてはなりません。
3.~6.では制御マイコンでCPUボードからのリクエストに応じてコンソールの機能を実装する必要があります。ストレージ機能も提供すればCP/MなどのOSを動かすこともできます。
ながらくRAM容量を諦めきれずに迷い続けていたのですが...
割り切って6.を選んだとたん、一気に計画が現実になりました。あまり「nice to have」に拘らないほうがよいですね。
基本的に古いCPUが多いので4kBもあれば十分なことが多いと思います。一応簡単な改造で5.にも対応できるようにしましたし、CPUボードにRAMを搭載することもできます。
拡張予定については次回にまわそうと思います。
Add new comment