Copy Link
Add to Bookmark
Report

about Dreamcast G2 bus

The original article, written by jj1odm, is available at http://jj1odm.sizious.com/

Dreamcast's profile picture
Published in 
Dreamcast
 · 16 Sep 2018
about Dreamcast G2 bus
Pin it

Introduction

The G2 bus was examined from the following doubts.
以下の疑問点から G2 バスを調べました。

1) Is byte alignment possible ?
バイトアライメントは可能か?

2) Is the long word access possible ?
ロングワードアクセスは可能か?

3) Can the access time be controlled ?
アクセスタイムはコントロールできるのか?

4) Possibility of BBA clone
BBA クローンの可能性
G2 バス上で新たに判明した信号や既に判明している信号名称を変更した部分について少し説明します。
更にこれらの解析内容をを反映させた G2 バス上のインタフェース設計例を別項で掲載します。


/MODEMCS: 5pin (modem enable: active low)
この信号は以前にも観測していましたが、他の動作とかなり違っていたので SPU 側をアクセスした時の動作だと
考えていました。結局 modem や lan adaptor [HIT-0300] の為の簡易バスモード用信号である事がわかりました。
0xa0600000 - 0xa06007ff の範囲をアクセスするとこの信号がアクティブになりシンプルバスモードになります。
(名前はモデムアダプター用チップセレクト端子という事で /MODEMCS と名付けました)


/IRQA, /IRQB: 6pin, 13pin (interrupt input: active low)
modem adapter や lan adapter [HIT-0300] に使われている割り込み信号はすでに DanPotter 氏が /IRQA (6pin)
であると解析されていたので、他の割り込み入力信号がないか以下の方法で探しました。
G2 バス上の割り込み入力信号の状態は 0xa05f6904 番地の interrupt bit map register に反映されています。
このレジスタの状態をループで表示する簡単なプログラムを走らせた状態で G2 バス上の未解明の端子に
1KΩの抵抗を介して GND に接続する方法でレジスタの値が変化する場所を探しました。
数ヶ所調べたところで BBA [HIT-0400] が使用する /IRQB (13pin) を発見する事ができました。
他にも無いか調べましたが今の所この /IRQA /IRQB の 2本だけのようです。
(ちなみに /IRQA /IRQB という名称は私が区別する為勝手に付けた名前です)

/LBE /WR: 14pin (lower byte enable output: active low / direction output)
この信号は bITmASTER 氏が dir と名づけた信号ですが、direction 情報以外に下位バイトのイネーブル信号も
兼ねている事が分かりました。(偶数か奇数番地に対するバイトアクセスをした時のこの信号の変化から分かります)
但し、0xa0600000 ベースのアドレス空間だけはバイトアクセスが禁止されているので信号の意味が変化します。
/MODEMCS がアクティブの時は簡易バスモードになり /WR ライトイネーブル信号の働きをします。

/UBE /RD: 16pin (upper byte enable output: active low)
この信号は bITmASTER 氏が /dataen と名づけた信号ですが、上位バイトのイネーブル信号である事が分かりました。
(偶数か奇数番地に対するバイトアクセスをした時のこの信号の変化から分かります)
但し、0xa0600000 ベースのアドレス空間だけはバイトアクセスが禁止されているので信号の意味が変化します。
/MODEMCS がアクティブの時は簡易バスモードになり /RD リードイネーブル信号の働きをします。

/BTA, /BTB: 22pin, 20pin (access time control / burst transfer input: active low)
この信号の説明は少し長くなります。
まず bITmASTER 氏ベースの回路を弄っている時の最初の疑問がバスのアクセス時間の長さです(1uSEC 以上もあります)。
G2 バスのスピードはもっと速いはずです。当初は 0xb4000000 ベースのアドレス空間だけが特別低速用に設定されている
と解釈しましたが BBA で使われるアドレスに変更してもバスのアクセス時間は変化しませんでした。
何処かにアクセススピードを制御する信号があると判断して BBA の動作中の信号を観察するとこの /BTA /BTB
(22pin 20pin) 信号が怪しいことが分かりました。
実験した結果この /BTA /BTB にアクノリッジパルスを返す事でバスサイクルが終了する事が分かりました。
バイトかワードアクセス時はこの /BTA /BTB 端子へ同時に同じ長さのパルスを返しますが、ロングワード時は
ワード転送2回分のバスサイクルの為少し複雑なシーケンスが必要になります。
さらに DMA 転送時はロングワードのシーケンスを繰り返すバースト転送になります。
結果的にロングワードアクセスや DMA 転送に対応するには適切に /BTA /BTB 信号をコントロールする必要があります。
ちなみに bITmASTER 氏ベースの回路で観測した 1.2uSEC のバスアクセス時間は /BTA /BTB 信号を返さない時の
G2 バス側のバスアクセスタイムアウト時間と言う事になります。
(この信号名称は bus termination と burst transfer から /BTA /BTB と命名しました)

/RESET: 46pin (reset output: active low)
電源(3.3v) の立ち上がりとこの信号の立ち上がりの時間を比較すると負論理のリセット信号である事が分かります。
(このリセット信号はシリアルポートの 9番ピンにも接続されています)

これらの解析結果から 1) - 3) の疑問は解決できました。
まだ 4) に関しては現在実験中です。

BBA 内の用途不明なレジスタが多くある事も原因の一つですが RTL8139C の為に PCI バスインターフェースが
必要である事がさらに問題を複雑にしています。(PCI バスに関してはフリー IP を利用する事も考えましたが
仕事にも役立つので勉強も兼ねて一から作っています)
仮に BBA クローンが完成しても LAN コントローラのインターフェースだけの為に FPGA が必要になるというのは
かなりオーバースペックでコスト的にも見合わないと考えています。
(セガの BBA クローンを作らせない為の G2 PCI ブリッジ IC はかなり成功していると言えるでしょう。)

追記:モデムで使われるアドレス空間のバスの挙動についてはまだ謎が残っています。
少なくともアドレス空間によってバスの動作は異なります。
これまで調べてきたバスの動作は下の 1) のアドレス空間です。

1) 0xa1001400 - use BBA (HIT-0400)
0xb4000000 - G2 ex. device area

2) 0xa0600400 - modem / lan adaptor (HIT-0300)
この空間にアクセスした時 /AEN 信号は出ません。/LBE /UBE 信号の動作も異なります。
また /BTA /BTB 信号も使われていないようです。
(発売当初からモデムは付属していたことからモデムのアドレスデコードがらみの回路を簡略化
出来るような専用のバスモードになっているのではないかと考えられます。)


追記:実験した結果やはりこの modem / lan adaptor [HIT-0300] に使われる空間は簡易バスモードになっていました。
この空間にアクセスすると /AEN は使われず /MODEMCS (5pin) が使用されます。データバスは多重化されず AD[15:8]
は 8 bit のアドレス専用バス、AD[7:0] は 8 bit のデータ専用バスになります。
この時 /UBE 信号は /RD リードイネーブル /LBE 信号は /WR ライトイネーブル の働きをします。
この空間は byte/word/long アクセスが可能ですが、ロングワード境界でアクセスする必要がありアクセスサイズに
かかわらず常に最下位バイトのみが有効になります。(8bit データバス)
この空間の範囲は狭く 0xa0600000 - 0xa06007ff の 2K バイトでした。
(ロングワード境界に配置する為 512 バイトになりますがアドレスラインが 8本なので実質 256 バイトの空間)
アクセスタイム (/MODEMCS の幅) は約 200nSEC あります。
(分かってしまえば単純なバスモードですが、この結論に達するまで随分長い時間が掛かってしまいました)

この簡易バスモードの検証に lan adaptor HIT-0300 クローンを作ってみました。
実は他の通常の G2 バスモードのアドレス空間では動作していましたが本来の 0xa0600400 ベースのアドレス空間
ではバスモードの違いから動かせずしばらく放置していました。
オリジナルの HIT-0300 では MB86967 が使われていますが、同系列の MB86964 を使用しました。
LAN コントローラ周りを一から配線するのが面倒なので MB86964 を使った PCカード (FMV-J182A) を流用しています。
(ID コードの違いと serial EEPROM インターフェースが無い部分は CPLD 側で補っています。
ちなみに MB86964 は既にディスコン、MB86967 は現状入手困難{事実上のディスコン}なのでその石が
使われている LAN カード等の製品から流用するしかないようです。)
動作検証は今のところ ip-upload 1.0.4 と KOS network sample soft のみです。

追記:MB86967 が使われている REX-R280 という LAN カードを入手したので
MB86967 版の HIT-0300 クローンも検証してみました。
(MB86967 を使用した場合リセットポートレジスタを追加するだけなので CPLD 内の回路は
非常に簡単になります。ついでに汎用ロジック IC のみを使用した回路も検証しました。)


MB86967/MB86964 10Base-T のトランスについて質問があったのでここに書いておきます。
MB86967 の場合は一般的なフィルター内臓の 20F001N 等が使えますが、MB86964 の場合フィルターは送受信ともに
LANコン側に内蔵されており、さらに送信側のトランスの巻線比が 1 対 1.4 と特殊になっています。
実際に使われているトランスを覗いて見ると受信側 10T:10T 送信側 10T:14T でトロイダルコアにまかれていました。
MB86964 の場合トランスが特殊ですがフィルター無しセンタータップ無しの簡単なトランスなので自作する事も可能です。
(ライン側のセンタータップはサージノイズ対策で高耐圧のコンデンサ(2KV/0.01u)をフレームグランドに
接続する為にありますが、工場のようなよほどの電磁気ノイズのある環境でなければ省略しても問題ありません。
ノートPC(PCカード)等有効なフレームグランドが確保できない場合も省略されている事が多いです)

追記:簡易バスモードについて、まだ疑問が残っています。
システムクロックに同期した通常の G2 バスモード(同期バスモード)では /BTA /BTB 信号によってバスの
アクセスタイムをコントロールできますが、簡易バスモード(非同期バスモード)では今のところアクセスタイムを
ハード的にコントロールする方法が見つかっていません。恐らく簡易バスモード用のウエイトコントロール端子が
G2 バスの未解明の端子の中に存在していると思われます。
(G2 バスに関係する何処かのレジスタを設定しないとウエイトコントロールが有効にならないのかもしれません)

私は本物の lan adapter HIT-0300 を所有していませんが、恐らく LAN コントローラからのバスウエイト信号は
G2 バスの何処かの端子へ接続されていると考えています。現状の HIT-0300 クローンでは LAN コントローラから
のバスウエイト信号を使用していませんが、今のところ特に問題はありません。(個人的には納得していませんが)

BBA clone その後:
これなら入るだろうと以前仕事で使って余った EPF6016AQC-208 を搭載し、パケットバッファー用に高速キャッシュメモリーを
積んで始まった BBA クローンですが、HIT-0300 クローンで中断して以来仕事が忙しくて PCI バス周りの配線が手付かずでした。

現在再開して PCI バス周りの配線 が終わり、デバッグ用に設けたコンフィグ用ポートを通してコンフィグレーションレジスタへの
読み書きが出来ています。

ここで現時点で推測する BBA 内の構造と私が考えているクローンの違いについて少し書いておきます。
私の推測ですが、BBA の場合パケットバッファー(32KBytes)へのアクセスは全て PCI バス経由でアクセスしていると考えています。
それは例のマジックコードによる RTL8139C のコンフィグレーションが終了しないとパケットバッファーのメモリ空間が現れない
という事から来ています。
(コンフィグが終了するまで PCI バスのアクセスを禁止している?もちろん RTL8139C のベースアドレスを設定しなければ
RTL8139C は見えませんが、バッファーメモリは見えても良いはずです。)

私が作ろうとしているクローンの場合、RTL8139C がバスマスターになって DMA 転送する為の PCI バスから見えるバッファー空間
と G2 バス側から見えるメモリー空間のために 2ポートメモリ構成を採っています。

この場合のメリットは、RTL8139C がパケットバッファーへバースト転送をしている間 RTL8139C へのレジスタアクセスにより
一時バースト転送は中断しますが、パケットバッファーへのアクセスは PCI バスのバスサイクルを中断することなくアクセス
することが出来ます。
デメリットは 2ポートメモリ構成の為回路が複雑になることです。
(PCI バス上でのバースト転送も 2ポートメモリに同期させる必要がある)

本当は 32bit幅のバッファーメモリーがあれば回路的にはすっきりしますが、現状は 8bit x 32768 の SRAM を 2つで 16bit 幅
で使っています。RAM ビット 32KBytes 分のメモリが確保できる FPGA という選択肢もありますが、実験としてはそちらの方が楽
ですがなるべく現実的な構成にしています。

それとは別に、相変わらず用途不明のレジスタについては謎のままです。
KOS や NetBSD のソースから読み解こうとしていますが、どうもブラックボックスへ定数を設定しているだけのように見えます。
最終的には KOS や NetBSDでは動くけど、BBA 対応の正規のソフトでは動かないかもしれません。
(希望的観測として 2ポートメモリ構成が、それら不明なレジスタを必要としない事になるのではないかと?あまい?)

現在 FPGA の 70%前後の LE 使用量でフィッティングに時間が掛かかる為、一時 2ポートメモリ構成を止めて PCIバス経由でのみ
パケットバッファーへのアクセスが出来る 構成 で 実験 しています。
PCI マスターも PCI スレーブ側もいちよう期待通り動いているようですが、RTL8139C がバスマスターになってパケットバッファー
をアクセスする辺りに問題があるのか、現状で dc-load を起動すると BBA と認識、MACアドレスも正しく 認識 され idle 状態に
なっていますが ping や dctool -r 等に反応出来ない状態。RTL8139C がバスマスターになってパケットバッファーへ盛んに
アクセスしている事はオシロで確認できますが、まだ PCI バス周りに問題があるかもしれません。

現在実装している BBA のレジスタマップ (0x010016xx 番地のレジスタは現在未実装)

 
// device map: (physical address)
// 0x01001400-0x0100140f: "GAPSPCI_BRIDGE_2" strings {read only} (16bytes)
// 0x01001410-0x01001413: 0x0c003000 ??? {read only} (4bytes}
// 0x01001418-0x0100141b: magic code register {long access only} (4bytes) {RTL8139C config sequence}
// write: 0x5a14a501 {config start} / read: bit[31:1] '0', bit[0] - config done bit
// 0x01001420-0x01001423: register ??? (4bytes) {register only}
// 0x01001424-0x01001427: register ??? (4bytes) {register only}
// 0x01001428-0x0100142b: register ??? (4bytes) {register only}
// 0x0100142c-0x0100142f: register ??? (4bytes) {register only}
// 0x01001700-0x010017ff: {PCI} RTL8139C registers (256bytes) {after config}
// *0x01001800-0x01001803: pci_ad[31:0] {read only} (4bytes) {for debug}
// *0x01001804-0x01001805: pci_cbe[3:0] {read only} (2bytes) {for debug}
// *0x01001806-0x01001807: configuration address register (2bytes) {for debug}
// *0x01001808-0x0100180b: {PCI} configuration data register (4bytes) {for debug}
// 0x01840000-0x01847fff: {PCI} packet buffer (32Kbytes)

現状の問題点:
dc-load を走らせた状態でしばらく放置すると RTL8139C がバスマスターの状態で frame:hi irdy:low で
パケットバッファーからの応答待ち状態のまま PCI バスが固まる。これは PCI スレーブ(packet buffer 側)
が fast back to back に正式に対応していなかった為、バスアービターの切り替えのタイミングによって
はバスアイドル状態のない連続バスアクセスでスレーブ側が応答できなかった。(これは修正)

現在それなりに動き出してはいますが、何回か大きなファイル送受信している内に動作がおかしくなります。
こける直接の原因は G2 バス側のバスタイムアウト 1.2uSEC にあります。
そのタイムアウトになるまえに要求された PCI バスアクセスを終わらせなければいけませんが、その為
PCI バスアービターで 2つのマスターを切り替えるタイミング(RTL8139Cではマスタレイテンシの値)
や packe buffer のスレーブ側から disconnect 要求でバスを一時開放させるタイミング等を調整して
ますが、なかなか思うようにいかないというのが現状です。

(何かまだ根本的な問題が隠れているのかもしれません。 FPGA のフィッティングに時間が掛かるのも
デバッグが進まない要因、もっと大きな FPGA 使えば良かったかな。)

BBA clone circuit について:
回路図といっても G2 bus / PCI bus / SRAM が FPGA に繋がっているだけですが、いつも
の癖でまだ全体の回路図は書いていません。(いちよう大雑把な 回路 は書きました)
(PCI バスの配線をした時は何所かで見つけた PCI コネクタ図を参考にしてました)

クロックはスキューの問題があるので G2 バスのクロック 25MHz をバッファーは使わず
ダンピング抵抗のみで FPGA と PCI バスへ分配しています。
リセットは G2 バスのリセットと FPGA の CONF_DONE 信号を CR の時定数で少し遅らせた
信号とで OR して PCI バスのリセット信号と FPGA で使うリセット信号にしています。

高速 SRAM は 3.3V 用が手持ちに無かったため 5V 用(KM688257AJ-10) を使っています。
PCI バスは 5V/3.3V 兼用のピン配置を使っているため電源には 5V を供給しています。
(I/O 電源として 3.3V もいちよう配線してあります。RTL8139C を搭載した多くの LAN
カードでは 5V 電源からレギュレータで 3.3V に落としているようです)

PCI バスでは実質パリティー回路は無くても問題無いと思いますが、自身が出すべきパリティ
の為にいちよう出力はしてますが、相手の出すパリティは未チェック、それに伴って PCI
バスの perr# serr# ピンは未使用(プルアップ抵抗のみ、RTL8139C コンフィグ時にコマンド
レジスタの parity error response / serr ビットはオフにしています)。

magic code register (0x01001418) について:
このレジスタは RTL8139C に対してコンフィグレーションを行なう為にあります。
このレジスタへ 0x5a14a501 のマジックコードを書き込むと内部でコンフィグレーションの
シーケンスが始まります。コンフィグが終了したかどうかは同じレジスタを読んで bit0
が '0' ならコンフィグ中 '1' ならコンフィグ終了です。

(きっぱり書いてますが、BBA を調べた時 KOS や NetBSD のソースコードを見て RTL8139C
に対するコンフィグレーションが何所で行なわれているかみつけられなかった為、もうこの
マジックコードレジスタへのアクセスしかないと思いました。カスタム IC 内部の動作ですが
BBA を開けて RTL8139C の frame(PCI) 端子でも観測すれば確かめられると思います。
ちなみにこのコンフィグ終了のフラグは BBA 内部で PCI バスへのアクセスを有効にするか無効に
するかを制御しているようです。恐らくコンフィグシーケンス中、他の PCI バスへのアクセスと
衝突しないようにする配慮だと考えられます。)

(追記:ハブのリンクランプの挙動から気がつきましたが、単なる PCI バスアクセスの有効無効だけではなく
マジックコードを受け付けるまで PCI バス上のリセット信号はアクティブになったままのようです。
但し BBAクローンでは汎用 PCI バスとしても使いたいので現状のパワーオンと FPGA の CONFIG_DONE だけで
PCI バスのリセット信号とします。)

私の場合はコンフィグレーション空間にある マスタレイテンシ値 / メモリベースアドレス /
コマンド のレジスタを設定しています。(ちなみにデバッグ用に使われていないと思われる
0x01001806-0x0100180b 番地にコンフィグ空間への窓口を設けてあります。)

 
A part of Fitter report under experiment.
+----------------------------------------------------------------------+
; Fitter Summary ;
+-----------------------+----------------------------------------------+
; Fitter Status ; Successful - Tue Apr 22 18:19:45 2008 ;
; Quartus II Version ; 4.1 Build 208 09/10/2004 SP 2 SJ Web Edition ;
; Revision Name ; bba_clone ;
; Top-level Entity Name ; bba_clone ;
; Family ; FLEX6000 ;
; Device ; EPF6016AQC208-3 ;
; Timing Models ; Production ;
; Total logic elements ; 928 / 1,320 ( 70 % ) ;
; Total pins ; 121 / 171 ( 70 % ) ;
+-----------------------+----------------------------------------------+
+--------------------------------------------------------------------------------------------------------------------------+
; Fitter Resource Utilization by Entity ;
+-----------------------------+-------------+---------+------+--------------+--------------+-------------+-----------------+
; Compilation Hierarchy Node ; Logic Cells ; LC Regs ; Pins ; LUT-Only LCs ; Reg-Only LCs ; LUT/Reg LCs ; Carry Chain LCs ;
+-----------------------------+-------------+---------+------+--------------+--------------+-------------+-----------------+
; |bba_clone ; 928 (557) ; 337 ; 121 ; 591 (356) ; 22 (2) ; 315 (199) ; 30 (0) ;
; |g2_bus:g2bus| ; 112 (112) ; 40 ; 0 ; 72 (72) ; 1 (1) ; 39 (39) ; 15 (15) ;
; |pci_arbitration:pciarb| ; 5 (5) ; 3 ; 0 ; 2 (2) ; 0 (0) ; 3 (3) ; 0 (0) ;
; |pci_master:pcimas| ; 83 (83) ; 47 ; 0 ; 36 (36) ; 2 (2) ; 45 (45) ; 0 (0) ;
; |pci_prity:pcipar| ; 12 (12) ; 1 ; 0 ; 11 (11) ; 0 (0) ; 1 (1) ; 0 (0) ;
; |pci_slave:pcisla| ; 159 (159) ; 45 ; 0 ; 114 (114) ; 17 (17) ; 28 (28) ; 15 (15) ;
+-----------------------------+-------------+---------+------+--------------+--------------+-------------+-----------------+

FPGA configuration:
最近コンフィグレーションROM は安くなっていますが、FLEX6000 の場合対応する ROM がワンタイムで
書き換えが出来ない為、安価な ANALOG DEVICES 社の ADuC7021 (ARM CPU) を使ったコンフィグレータ
を考えました。
(実験では ADuC7019 を使ってますが、回路図では ADuC7021 にしてあります。ADuC7021 にした理由は
シリーズで一番安価な為。7019 と7021 ではアナログピン周りのピン配置が若干違っています。)
とりあえずこんな感じ。I2C ポート以外に念の為 JTAG 端子と予備に4本の GPIO ポートを引き出してあります。
拡張子 .rbf のコンフィグレーションバイナリ-ファイルを I2CW で書き込みます。
(ADuC7021 のプログラムコードや FPGA コンフィグデータを書込む専用のプログラムにしました。fcnfw
I2C ケーブルにブートモードをコントロールする信号を追加。 i2c_cable(simple version))

FPGA configurator:
resource: circuit i2c_cable(simple version) fcnfw pic
1st step: fcnfw -x ... write configuration program (ADuc7021)
write configuration data:
altera: fcnfw filename.rbf ... .rbf LSB first format (altera)
(xilinx: fcnfw filename.bin ... .bin MSB first format (xilinx))
monitor LED: (FPGA configuration)
normal: turning off at normal termination.
error: internal error or connected error with FPGA when blinking.

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos from Google Play

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT