ROMレスシステム

| 9 Comments | No TrackBacks

西田さんからのコメントがあったので、ROMレスシステムについて考えてみました。

基本的な考えは、

  • SRAMをROM領域(0x4000-0x7fff)に確保しておく
    (実際には32kB分のSRAMを0x4000-0xbfffに配置してRAM拡張を兼ねる)
  • 起動時にSRAMにブートアップ用のプログラムを転送し、そこから起動する

以前、私もAVRのプログラム領域、またはSDカード内にブートアップ用の(Z80の)プログラムを入れておいて、そこから起動することも考えてはいたのですが、直接AVRからZ80に読むにはタイミングが間に合わないのでそれ以上考えていませんでした。

しかし、西田さんのアイデアのように、いったんSRAMに転送してしまえば問題はなさそうです。

ブートアッププログラムはAVRに焼きこんでもいいのですが、SDカードに入れておけば、カードの差し替えで起動方法を変えられるのでさらに便利そうです。

なんかSDカードからのブートアップなんて格好いいかも? :-)

課題は次のとおりです。

  • デコードおよび調停が複雑になる
    メモリ系のピン(MREQ, RAS, EXCAS等)のデコードが必要なほか、アドレスの上位も扱う必要があります。
    また、SRAMに書き込んでいるときには本体からの読み書きを停止する必要があります。 いよいよCPLDの出番ですかね。
  • PC-6001が起動してROMからブートアップするタイミングまでにSRAMへの書き込みが間に合わない可能性がある。 特にSDカードを使った場合。
    これは、電源を入れてブートアップを読み込んだ後、手動で本体をリセットすればいいのですが、格好悪いですね。
  • 28ピン系のAVRでは入出力が厳しい。
    仮に可能な限りI/Oを共用をしたとしても、28ピン系のAVRで使えるI/Oは23本です(リセット含む)。 データ線に8本、アドレス線(ROMの16kB分, 14本)、制御線(ブートアップ中であることを示す, 1本)を出したとすると23本。 う~んぎりぎり。 この場合SDカードからの読み込みはI/O不足でできません。 時間分割すれば不可能ではないでしょうが、なんか不毛かも。 SDカードから読み込みたければ、素直に40ピン系のAVRを使ったほうがいいでしょうね。

というわけで、けっこう変えなきゃいけません。 これまでの設計はなるべくシンプルにしてきましたが、実際BIOSが必要であることを考えると(BelugaやPC-6006のカートリッジと同時使用する場合を除き)、メモリの扱いも必要なんですね。

とりあえずシンプル版?とROMレス版、2本立てで考えを進めてみようかと思います。


No TrackBacks

TrackBack URL: http://www.markn.org/cgi-bin/mt/mt-tb.cgi/819

9 Comments

なるほど、思いつきで言ってしまいましたが、なかなか大変そうですね。
いきなり沢山トラブルを抱えるのも嫌なので、まずは今のままの回路で行ってみます?

ブートアップ用の SRAM のアドレス発生を、もう一つの ATTINY2313 かなんかでやらすということも
考えられますが(汎用ロジックのトライステート+バイナリカウンタより安いし、遅くても良い)
まあ、まずはシンプルな方が良さそうです。

いま XILINX プログラミング用の SVF フォーマットを勉強しています。
USB のライターを作るためです。(別に難しいものではない)。
これができたら、CPLD を使う事を考えましょうか。

ATmega162のような外部SRAMインタフェースを持っているマイコンはどうでしょうか?
拡張スロット側からリセットがかけられるなら、AVR側が起動してから転送を終えるまで本体側をリセットしっぱなしにしておき、終わったら外部SRAM I/F を無効にして入力ピンに設定しておく…という方法でバッファを削減できそうです。
バスを奪っている最中にリフレッシュサイクルを挟まなくていいの? という気はしますが…。

>外部SRAMインタフェースを持っているマイコン
なるほど、それは良いアイデアですね。
だた、(TTL版の) 基板も結構大変なことになってるので、CPLD + ATmega162 + SRAM という構成ですかね。
拡張スロットから P6 本体をリセットすることは出来ないんです。
あくまでも P6 本体からのリセット信号なので。
電池を内蔵して、まず転送がおわってから、本体に差し込むのかなぁ。。。

>拡張スロットから P6 本体をリセットすることは出来ない
あらら、そうなんですか…。
そうすると
・本体からのリセットに反応してバスリクエストをかけ、SRAMのセットアップが終わるまで本体に止まっていてもらう
・本体とは並列にSRAMセットアップを行う。本体からSRAMにアクセスしに来たときにまだセットアップ中なら、終わるまで本体にウェイトをかけっぱなしにして待ってもらう
みたいな方法をとらなければいけないかもしれませんね。後者だと本体から来る信号はHi-Zにならないので、トライステートバッファの削減はできませんが…。

あらららら…。それは厳しいですね…。
ということは、ちゃんとしたバス調停機構を拡張スロット側に置かないといけないんですね。しかも本体側優先で。これは大変だ…。

本体側がアクセスに来る前にシグネチャを書いて、ついでにエントリポイントに'RST 00h'を書いておいて、AVRがSRAMを準備し終わるまで本体側にぐるぐる回っててもらうくらいしかないですかねえ。

エントリポイントからフェッチしに来た本体に対して適当に遅い1バイト命令(ADD HL,HLとか)を返し続けて、本体をアドレスカウンタとして使いつつSRAMを充填する…という変態実装もできなくはないですが(^^;

Leave a comment