ディスクシステムローダー・セーバー(その∞)

  • 2013/03/09(土) 23:03:23

えっと、まずこちらを見てください。



もうね。なんというか、すごすぎw
作られた方はNorixさん。VirtuaNESの開発者の方です。

続きを読む

ディスクシステムローダー(α版未満)その3

  • 2013/01/20(日) 13:14:45

なんとかデータをdumpできる感触です。

こんな感じ。
もうちょっと煮詰めたら公開したいと思っていますが、その前に目標と簡単な仕様など。

目標は
ファミコンディスクシステムを含むクイックディスク(MZ-1500とかも)をタイムカウント方式でドライブから直接dumpする。
dumpしたデータからバイナリへ変換して、各種エミュレータなどで使用できるイメージを作成する。
dumpしたデータ、もしくは独自のイメージからディスクへ書き戻すことができる。
直接ドライブ自体をエミュレートできる(HxCみたいにRAMアダプターへ直接つなげる)
エミュレートはスタンドアロンでも動作できるようにする。

#無理難題が多いw

今のところこの環境でイケるんでは?というもの
メインのデータ処理部分はAtmega644Pもしくは1284Pを予定。5Vで20MHz動作です。
#パッケージは何でもいいですが、入出力のバスやドライブの制御にピンが多くないとだめなので。今のところAtmega164Pでも大丈夫なぐらいのコードサイズですが、将来肥大化する可能性のために。
デバッグを容易とするために、ファームウェアはブートローダーから自己書き換え可能なものとして作成して、いつでも新しい機能を追加できるようにする。
PCとのデータ転送にはFTDIのFT232Hを利用し、USB2.0で。
#一から作成するのは面倒なのでUM232Hという完成している基板でやり取りしています。秋月で売ってるやつ。
#Atmegaやディスクドライブへもバスパワーから電源を供給するようにしたのでHubとかだと問題かもです。
今後いろいろと問題が起こるようなら外部電源でセルフパワーにするつもり。
PCでの制御ソフトはwindows機32ビットのXP以降、.NET4frameworkがインストール済みのもので、VisualBasic2010で作成したソフトウェアでデータのやりとり。

で、現時点での動作は続きます。

続きを読む

ディスクシステムローダー(セーバー)の準備 その2

  • 2013/01/01(火) 13:28:06

あけましておめでとうございます。
大晦日にやっていたことをちょっと報告。

で、まずはどんな信号が出ているか調べてみました。
まず、ディスクシステムのピンアサインから。

こういう感じで見たとき、昔のバッ活で書いてあったピンアサインになります。

一応、NESDevにある、「Famicom Disk System technical reference」とあわせて対応を書くと、

1 -WriteGate
2 5V
3 -MOTOR(-ScanMedia)
4 GND
5 -WriteData
6 BatterySence
7 -WritetableMedia
8 VCC Out
9 ReadData
10 -MediaSet
11 -Ready
12 -Reset(-StopMotor)
こんな感じになります。
ただ、これでは信号が扱いにくいので、RAMアダプター側からケーブルをもらってきて、



その先のピンで調べました。
#「Famicom Disk System technical reference」に後でみたら書いてあったけど。
1ピン←         →12ピン
です。
で、そのピンでの信号を調べると、
1(brown) GND RtoD
  NC  
3(orange) -WriteData RtoD
4(yellow) ReadData DtoR
5(green) -WriteGate RtoD
6(blue) -MOTOR(-ScanMedia) RtoD
7(violet) -Reset(-StopMotor) RtoD
8(grey) -WritableMedia DtoR
9(white) -Ready DtoR
10(black) -MediaSet DtoR
11(pink) BatterySence DtoR
12(cyan) 5V RtoD
こんな感じ。RtoDとかDtoRは信号方向です。(Drive、RAMアダプターって意味)


このように強引に信号を取り出して、動作を確認してみました。

続きを読む

ディスクシステムローダー(セーバー)の準備

  • 2012/12/30(日) 17:39:41

なんか、凄く昔(暑かったころ)の話をいまさらやってます。

で、どういうことをしたいかというと、ディスクシステムからのRDデータをそのままタイムカウントしてあげて、すべてのビット変化時間を記録するというもの。

前にもちょっと書きましたが、96.4KHzのクロック動作するディスクシステムなので1クロックがおおよそ10.37us程度です。
MFM変調されているので、

Clock ----____----____----____----____----____----____----____----____----____

Data ----------------________________________--------________----------------
1 1 0 0 0 1 0 1 1
C/D |C |D |C |D |C |D |C |D |C |D |C |D |C |D |C |D |C |D |
Disk ____-_______-___________-_______-___________-_______________-_______-___

上から、ベースのクロック(96.4KHz)、ビットとしてのデータ(0か1)、MFM方式のクロックウィンドウの間隔とデータウィンドウの間隔(大体です)、実際のRDからの出力の順であらわしてみました。
で、要するに、一番下のRDのビットが立ち上がったところから次の立ち上がりまでの時間を計測してそれをどんどんデータにしていく必要があります。
ベースクロックから考えると、最小で10.37us、その次に長いのが、1.5倍で15.5us程度、最長のもので20.74usになります。

で、まず考えたのが、FT245RLをUSBで接続してパラレルでデータをやり取りするもの。
これだとD2XXでBitBangで制御すれば理論的には1Mbyte/s程度のデータ入出力が可能ということでした。で、1Mbyte/sでも使用するピンはRDの入力1ピンの変化を見ていくだけ。
ですので、どっちにしても1Mbits/secの能力です。
ってことは、データの取りこぼしが無く良好に制御できたとしても、10^-6sec=1us程度の分解能しかありません。下手をすると上記の速度さえ間に合わないということに。
これではまったく速度が足りないということが判り、Windowsなどから直接データをサンプリングするのは危険だという結論になりました。

考えたのがAVRのタイマを使ってきちんと測定し、その間隔のデータをwindows機へ送信する形で設計する方向とします。

で、結局どの程度の分解能をもたせるか?ということから考えました。
ちなみに立ち上がっているビットの長さは1us程度で意味はあまりありません。
なぜならディスクはそのエッジトリガによってデータを扱うからで、エッジとしてパルスが出ていればその長さには意味がありません。
ディスクシステムからの出力は5Vですので、AVRも5Vで使用することにしました。最近の一般的なものであれば、オーバークロックも可能ですが、とりあえず定格の20Mhzで動作させます。
すると最大の分解能は1/20Msecなので、50nsecになります。
で、50nsecの分解能で上記の間隔をデータ化する、10.37us=207カウント、15.5us=310カウント、20.74us=415カウントになり、16ビットカウンタでインプットキャプチャを利用すればデータ化は問題ないと考えました。

しかし、それを実装する上でさらに問題が発生。
カウンタとしてデータは取れるのですが、1つのデータは2バイト長になってしまい、10.37usのデータが連続した場合、200Kbyte/sec程度のデータ通信速度が必要です。
USB2.0なら大丈夫ですが、問題はAVR側の方でした。
USARTとかでいいかなと思っていましたが、理論値の最高でも2Mbps程度ですので、ぎりぎりです。

で、一つの方法として、分解能を落としてみます。
50nsecでのサンプリングをやめて、プリスケーラを1/8にて400nsecでのサンプリングにします。
これだと当然すべてのカウントが256未満になりますので、1データ辺り1バイト長になりますので、半分の転送速度でOKです。
もしくはタイマーのクロック別なカウンターで生成して、もうちょっと分解能を上げ(100nsec程度)ても1バイト長になりますので、このほうがいいかなと思っています。
で、この状態でも200Kbyte/sec程度の速度が必要でした。
FT232RLでは最大460kbps程度でまったく間に合いません。

結局いろいろ探していると、FT232Hなるものが!
おおっ!まさしくこれです。
高速なFIFOとかもあるし、いろいろできそうですが、USART以外でAVRにあるインターフェースで高速なものは後はSPIインターフェースです。
これがあればUSB-SPIとして通信できますよ。
FT232H側がSPIのマスターになるので、AVR側はスレーブですが、スレーブでもマスタークロックの1/4で通信できるので、5Mbits/secつまり600Kbyte/sec程度はいけるのか?ということのようです。

こんな妄想を繰り返し、パーツを集めて今年が終わりました。
皆様良いお年を。
では〜

いまさらのファミコンディスクシステム

  • 2012/07/31(火) 09:39:40

久しぶりの更新となってしまっています。
ちょこちょこっといじっていますが、あまりうまく行っていないので、まだ公開できないことが多いですが、そのなかの一つでファミコンディスクシステムをもう一度いじっています。
#下書きばっかり溜まっていく

今更ですし、誰得なんだといえばそれまでですが、以前から一般的なFDS形式では、各ブロック毎のデータが並んでいるだけのバイナリデータで、実際のディスクに書かれているGAPなども含めた全データのベタイメージではないことがちょっと疑問でした。
#昔、どこかでいろいろGAPの事書いている人がいましたが、私は別人ですw

で、どうすればベタイメージなど全てのデータが手に入るのか?考えていましたが、結局のところ昔のPCで後年主流となった、ハードウェアデュプリケータの理屈が一番いいだろうと。
つまり、タイムカウント方式で全ビットを測定し、データにしてしまってPCで保存するのはどうかなと。

というわけで、あまりに暑いので妄想を書きますので、突っ込んでいただけると幸いです。

続きを読む