訳注 　この文書はFDSLOADR.TXTの日本語参考訳です。 　吸い出しに必要な部分のみ先行して訳しています。 　原文書は英語のため、NES→ファミコン、FDS→ディスクシステムといった 　読み替えが必要になります。 　文書中のPCは、AT互換機(DOS/V機)の英語モードを指しています。 　一部の日本語DOS環境では、us命令で英語モードに切り替えられます。 　訳に関する質問のみ、あさひ (asahi@momo.chan.ne.jp)まで。 　それ以外の内容に関する質問などは、原文を読んだ上で原文作者へ。 　参考資料部分は各文書をもとにあさひがまとめたものなので、 　疑問点などがあれば各文書を独自に参照してください。 ------------------------------------------------------------------------ 参考資料：FDS吸い出し用配線図 ・ディスクドライブ用(原文書の"Small signal wiring chart"部 DDU〜FDSに対応) 　(A)ディスクドライブ背面12ピン 　(B)パラレルポート D-Sub25ピン 　(A) (B) その他 　 1 ---- 14 : A→B ￣WRITE GATE 　 2 ------------ +5V : Vcc(+5V) 　 3 ---- 1 : A→B ￣SCAN MEDIA 　 4 ---18〜25--- GND : GND(共通接続) 　 5 ---- 2 : A→B DATA 　 6 ---- 11 : A←B MOTOR ON/BATTERY GOOD 　 7 ---- 12 : A←B ￣WRITABLE DATA 8 : この端子は使用しない 　 9 ---- 10 : A←B DATA 10 ---- 13 : A←B ￣MEDIA SET 11 ---- 15 : A←B ￣READY 12 ---- 17 : A→B ￣STOP MOTOR 　(A)は特殊な端子。ケーブル作成の詳細やピン番号は、 　本文あるいはバックアップ活用テクニックvol.5〜6を参照。 　ディスクドライブ駆動用の電源は乾電池あるいはACアダプタで供給されるが 　ドライブに付随する電子回路のVccはRAMアダプタ側から供給される。 　このため2/4番ピンから+5Vを供給する必要あり。 ・ツインファミコン用(端子入手が比較的容易) 　(C)ツインファミコン背面拡張端子Cに接続 1列12ピン 　(D)既存ケーブルを介してツインファミコン背面拡張端子D(2列)に接続 1列12ピン※ 　(E)パラレルポート D-Sub25ピン 　(C) (D) (E) 1 ---- 13 : D←E ￣MEDIA SET 2 ---- 17 : D→E ￣STOP MOTOR 3 ---- 15 : D←E ￣READY 　 4 ---- 10 : D←E DATA 　 5 ---- 12 : D←E ￣WRITABLE DATA 　 6 ---- 2 : D→E DATA 　 7 ---- 1 : D→E ￣SCAN MEDIA 　 8 ---- 14 : D→E ￣WRITE GATE 　 9 ---- 9 ---18〜25 : GND(共通接続) 　10 ---- 10 : Vcc(+5V) 　 11 ---- 11 : D←E MOTOR ON/BATTERY GOOD 12 : この端子は使用しない 　(C)(D)を接続する拡張端子C・拡張端子Dは背面に隠れている。 　黒いカバーを外すと見え、端子間は既にケーブルで接続されている。 　このケーブル部分がRAMアダプタ〜ディスクドライブ間に相当。 　(D)のピン番号は、バックアップ活用テクニックvol.5を参照して 　ディスクドライブ用のピン番号を変換したもの。 　ツインファミコンではここの12ピンがディスクドライブ背面端子に対応する。 　実際の端子のピン番号はハウジングに記載あり。 　上記の(C)〜(D)結線はGNDの統一と+5V供給のため。 　ツインファミコンではここから電子回路の電源となる+5Vが取れる。 　※2つの拡張端子間は既にケーブルで接続されているので、これのC側を外す。 　　外したところの本体側端子を(C)、ケーブル側端子を(D)として用いる。 　　旧 : 拡張端子D■ [2列端子]----[1列端子] ■拡張端子C 　　新 : 拡張端子D■ [2列端子]----[1列端子] (D) --+-- (C) ■拡張端子C 　　 | 　　 (E) 　　このように既存ケーブルを使うことで一般的な端子を使用できる。 　　http://www.jst-mfg.com/ProductGuideJ/SM.html 日本圧着端子製造(JST) 　　同じ手法はバックアップ活用テクニックvol.6でも行われている。 　　ハウジングは(C)がSMR-12V、(D)がSMP-12Vと思われる。 　　電子部品店によってはこれに対応するコンタクトと電線を圧着させた状態で 　　販売しているものもあり、これを使うとさらに製作が容易。 ・パラレルポート端子をアンフェノール36ピンにする場合 　下記の対応に従って変換する。19〜30と18〜25はGND。 　36 : 1 2 10 11 12 13 14 32 36 19〜30 　25 : 1 2 10 11 12 13 14 15 17 18〜25 ------------------------------------------------------------------------ 参考資料：*.FDSファイル形式 　1つのファイルに2面以上のディスクデータを保存できる。 　ファイルサイズは、16+65500×面の数 である。 　ファイルの先頭16バイトはヘッダとなり、 その後は65500バイトごとに各面のデータが格納される。 　ヘッダ形式は、 　struct { 　 unsigned char sign[4]; // 46h 44h 53h 1Ah ('F' 'D' 'S' ^Z) 　 unsigned char disks; // 1枚片面なら01h 1枚両面なら02h 2枚組なら04h 　 unsigned char dummy[11]; // 11バイト全て00h 　} 　FDSLOADRのために空の*.FDSファイルを作るならば、 1枚片面 … 65516バイト 先頭5バイトは46h 44h 53h 1Ah 01h 1枚両面 … 131016バイト 先頭5バイトは46h 44h 53h 1Ah 02h 2枚両面 … 262016バイト 先頭5バイトは46h 44h 53h 1Ah 04h のファイルを作成し、6バイト目以降は全て00hとしておく。 ------------------------------------------------------------------------ 参考資料：FDSLOADRを使った吸い出し方 (1)ケーブルを接続し、PCやディスクドライブの電源を入れる(電源接続)。 (2)ディスクドライブにディスクカードを入れる。(特にドライブは反応しないはず) (3)"FDSLOADR 1.FDS"のように、有効な*.FDSファイルを指定して起動 (4)自動的にFDSファイルの第1面部分にディスクカードの内容が吸い出される 　　※ディスクドライブモードのREADになっていることを確認。 　　　そうでない場合はケーブルの配線などに失敗している可能性がある。 　　※遅いコンピュータの場合は右上のベンチマーク結果に注意。 ＊(5)〜(8)は両面ゲームを1枚両面用*.FDSファイルに吸い出す場合。 ＊片面ゲームの吸い出しの場合は(9)へ飛ぶ。 (5)ディスクを取り出す。 (6)キーボードの'2'を押し、強調表示されたバーが変わったのを確認する。 (7)先ほどはA面を入れただろうが、今度はB面を入れる。 (8)自動的にFDSファイルの第2面部分にディスクカード(B面)の内容が吸い出される。 (9)F4キーを押す。1.FDSに吸い出した内容が保存され、DOSに戻る。 (10)ディスクを取り出し、ディスクドライブの電源を切る。 　　※FDSファイルをバイナリエディタで開くと、 　　　各面に「*NINTENDO-HVC*」などの文字列が存在するはず。 ------------------------------------------------------------------------ FDS Loader 説明書 (二訂版) 　プロジェクトの考え方、調査、構造、開発と文書作成はもっぱらBrad Taylor (big_time_software@hotmail.com)による。他のNES/FC/FDS関連の作品や情報はhttp://nesdev.parodius.comに置かれている。 　原文書のスペルの間違いはChristopher Cox (c.cox@sasktel.net)が訂正している。 　このプロジェクトの開発につながる全ての情報は、"FDSTECH.TXT"文書とその中でふれた文書からもたらされたものである。 　注意：この文書はテキストモードの文字を使っている。この文書を見るのに「メモ帳」のよおうなWindowsプログラムを使っているなら、全ASCIIキャラを表示する"terminal"スタイルの書体を使うことで正しく表示が整えられる。 免責 ---- 　このプロジェクトは「あるがまま」で提供される。この製品の作成や実行はあなた自身のリスクである。これは、この製品に欠陥があることを暗示してはおらず、それがあなたに直接的あるいは間接的に引き起こす何らかの損害に、私(Brad Taylor)は責任を追わないことをただ意味している。 目次 ---- 改訂履歴 なぜこのプロジェクトを行ったのか プログラム・ソフトウェアの説明 プロジェクトの物理的な構築 ソフトウェアの改良点(前版に比べて) ソフトウェアの互換性 プログラムが動かないかもしれない理由 既知の問題 ディスクのプログラム変更の問題 ピン配列図 配線図 ソフトウェアの利用 +--------+ |改訂履歴| +--------+ 改訂 日付 追加・注釈 ~~~~ ~~~~ ~~~~~~~~~~ 2.0 02/11/14 -以前のタイミング問題を問わず性格に動作するための、FDSLOADRのデータアップロード命令の大幅な書き直し -FDSLOADRソフトウェアの変更に対応したこの文書の修正 1.1 02/10/18 -"software comp./known bugs"を2節に分割 -「ディスクのプログラム変更の問題」節 1.02 02/ 5/ 7 -スペル訂正 1.01 02/ 5/ 2 -配線図の注釈($) -改訂履歴 1.00 02/ 4/29 -一般公開 +--------------------------------+ |なぜこのプロジェクトを行ったのか| +--------------------------------+ 　このプロジェクトを開始した理由は、1994年からFDSを所有していて、すばらしいゲーム(特にすばらしい音を鳴らすゲーム)をそれで遊んだからである。現在、1987年に作られたディスクの一部はとても古くなり、ますます機能しなくなってきた。さらに、私がそんなに賢くなかった間にディスクドライブで行った実験は、ドライブを決して完全ではない状態にした。(これに加えて、それらのFDSディスクドライブのベルトがどのようにしてすり減っていくかについてネット上の豊富な記事を見てきた。)言うまでもなく、ディスクドライブやゲームはいつか動かなくなる。 　RAMアダプタ(私のものは無傷である)とともに故障できるものなどない、といえばじゅうぶんだろう。だから、ディスクドライブの代わりのパソコンとFDSのRAMアダプタのインタフェース、というプロジェクトの構成を考えた。PCは制御(エミュレーション)ソフトウェアを介して、ハードディスクからRAMアダプタにFDSゲームをアップロードする。これによって、扱いにくい(そしてたいてい信頼性に欠ける)FDS保存システム(言い換えるとその独自の2.5インチディスク)を無視しながら、FDSのRAMアダプタというハードウェアを使うことができる(ゲームを遊ぶのに本物のNESを使える)。RAMアダプタを持つNES開発者へのボーナスとして、このプロジェクトは、PC上の独自のNES用プログラム(*.FDS形式)のコーディングを可能にし、実際のNES上でそれを実行するためにアップロードするのも容易になる。 　このプロジェクトは、ディスクドライブの動作や、シリアル通信に使われるデータ通信方式、ディスク上にデータが保存される低レベル方式の解析調査で(01年8月に)始まった。これに一ヶ月半ほど費やし、その大半はディスクドライブとPCのインタフェースのために必要となる電子的な課題、そして取り込んだデータを理解する助けとなるための書き込みソフトウェアであった。 　次の段階は、ディスク上のファイルのデータの完全性を維持するのに使われるCRCアルゴリズムの解読であった。私の知っているCRCチェックの存在に触れたFDS技術文書でさえ、その計算や生成の詳細がないままであったので、これを完全にするのはとても難しい課題であった。ほとんどのFDS文書は、RAMアダプタのエミュレーションを含む完璧なFDSエミュレータの開発(これにCRC構造の実装は必要ない)に適合しているので、これは理解できる。 　それにもかかわらず、CRCアルゴリズムなしには、このプロジェクトはまだ夢物語である。CRCを調査し、ほとんどソフトウェア実装の説明がない文書の意味を理解するのに半月を費やした。ディスクシステムのCRCの値に関して解決しなければならなかった最大の謎は2点あった。ビットオーダーと使われている多項式である。まず、ディスクに記録されたものと適合するCRCに到達するために、(実際のFDSディスクを部分的に読んで得られた)テストデータのそのイメージの組み合わせすべてを試してみた。当時、友人が私に言ったのは、CRCの計算においてディスクに保存されたCRC値を含めれば、データがCRCと一致するとき0がもたらされることである。それが、私がアルゴリズムや使われる多項式を解読したときである。実際には、使われていた多項式は非常に一般的な16ビットであった。 　このことの後、FDSのディスクドライブユニットをエミュレーションするプロジェクトをまとめる試みを行う準備ができた。 　(01年10月に)私が書いた最初のソフトウェアは、RAMアダプタとPCの間のデータ転送のために外部ハードウェア(手持ちのあったデジタル電子回路)を頼る必要があった。このハードウェアはFIFO(エミュレーションソフトウェアの出したデータのバーストをバッファリングするため)と並直列変換(主に8ビットのシフトレジスタとXORゲートであり、データをRAMアダプタ本来のシリアル通信プロトコルに変換するため)からなっていた。最終的には、外部ハードウェアを利用していることによってプロジェクトが、私が最終的にプロジェクトを終えるために必要とする理由である、何らかの一般公開には異例のものとなることから、プロジェクトへの関心を失った(このプロジェクトの恩恵を誰にでも、電子工学のバックグラウンドを持つ人以外にも受けてもらいたかった)。そのうえ、RAMアダプタがディスクに書き込み(保存)したいときに送ったデータを処理する準備がこれまではなかった。データ保存能力でさえ、より多くのハードウェアを必要とし、プロジェクトの目標と衝突した。 　02年1月、私はこのプロジェクトを修正し、いったん使っていたハードウェアをどのようにソフトウェアがエミュレートするかについて詳細に調べ始めた。最大の問題は、一定の速度(96.4kHz±10%)でシリアルデータをRAMアダプタに送ることであった。 　最初に考えたのは、毎秒192800割り込み(このときシリアルデータ信号の更新とRAMアダプタへの転送を行う)を放つためにPCのプログラマブルなインターバルタイマ(PIT)を使うことであったが、すぐにこの非現実的な解決法は信頼性のある結果をもたらさないと気が付いた。 　プログラムの次の試みは、何らかのポートが書き込まれたときの固有遅延の利用であった。その外部利用性がRAMアダプタとの接続を容易にでき、そしてISAバスのPIOタイミングは長年にわたって確立されてきた業界標準であり、従ってそのアクセス速度は新旧のコンピュータにわたって同じであると多かれ少なかれ保証されていたので、パラレルポートのレジスタが主な標的であった。このポートへの"OUT"1回の間には私の必要とする遅延全部が生成されないので、連続した数回の"OUT"ということになる。これが、前述の問題に立ち向かう確かで実用的な方法であることが分かった(更新された関連する続報については「ソフトウェアの改良点」節を参照)。 　最後の段階は、ディスクへの書き込みのときにRAMアダプタの出したシリアルデータの解釈のサポートであった。これは、ソフトウェアだけで実装するのが間違いなく難しいことであった。 　結局、RAMアダプタの出した書き込みデータはパルスからなっていることが分かった。これは、どのようにデータがFDSのディスクに保存されるかと違いがなかったが、PIOの観点からは、(RAMアダプタの生成した)パルス周波数が読み込み周波数(CPUがパラレルポートのレジスタから読み込んだもの)と同期していない場合は、パルスの進行状況が確実には読むことができないし、それはもちろん同期していなかった。 　これを乗り越えるために、"write data"信号をプリンタポートのIRQ7の線と結ぶことに決め、従ってパルスが出されるたびに割り込みが生成された。ソフトウェアの行うことは、パルスの期間を決めるのに使われる、割り込みの間の経過時間を把握することであり、そして最終的にはパルスの適切なビット解釈であった。 　"write data"信号をIRQ線へ結ぶことは、1秒に最大で96400回の割り込みを意味したが、「もし」他の割り込みすべてを無効にしたならば、どうやらPICは、ビット解釈の目的にじゅうぶんなこの割り込み周波数を正確に扱うことができるらしい。 　とうとう、96.4kHz(最大)の割り込み感覚の間の経過時間を把握する方法が実装された。 　まず、CPUの与える最高速度でカウントアップをできるだろうCPUレジスタをカウンタとして使うことに決めた。割り込みが起こったとき、カウントが読まれ、その数に基づいて適切なビットが解釈され、カウンタは割り込みルーチンが終了したときに0にリセットされる。 　この案の持っていた主な注意事項は、(カウンタは割り込みのないときのみ動作するので)アキュムレータのカウントが割り込みのオーバーヘッドに気を配っていないことである。この場合、たった1回のポート書き込みしか必要にならないので、割り込みオーバーヘッドは無視できる。これはPITすなわちレガシーISAハードウェアデバイスへのもの(パルス割り込みの間に利用できる時間の約18%を費やす)である。最終的に、あらかじめ計算するオーバーヘッドは、冒頭における何らかの性能測定を意味し、私の考えでは目前の課題に対しては少し度を超えている(し、それでも100%の正確さを保証しないオーバーヘッド計算しかもたらされない)。 　結局のところ、経過時間を把握するのに最適なすばらしいx86命令であるRDTSC(読み出しタイムスタンプのカウント)に偶然でくわした。この命令は、クロックサイクル毎にインクリメントされるCPU内部の継続的なカウンタ、現在の64ビットカウント値を返す。この命令の利用を決めるときの唯一の問題は、これがPentium移行のCPUでのみ実装されていることであった。最終的に、Pentiumシステムがすでにじゅうぶん長く(10年間)あちこちに存在しているのを見て、この命令と付きあうことを決めた。 　RDTSCは、割り込みの間の経過時間を把握するのに最も正確な方法を確保するが、PCシステムを越えて広く変化するパルスのCPUカウント範囲に、非常に大きい注意を持つ。他のシステムの場合のプログラムの互換性よりは、適切にデータを読み込むことに対してこのプログラムに懸念を持っていたので、とりあえずそれに我慢した。 　RAMアダプタによって出されたデータの取得に非の打ち所がないうちに、FDSディスクドライブユニットとの追加インタフェースに関する対応をプログラムに含ませることを決めたにもかかわらず、本物のFDSディスクからのデータ読み込みは私のプログラムではあまりうまく解釈できなかった。 　ディスクの内容はときどき正確に読み込めたが、他のときはパルス1つが誤解釈されたところでダウンロードされたデータに奇妙な点があったのかもしれない、これがディスク上のファイルの中のそれ以降のデータ全てが不正確に変換される原因だったのだろう。 　これが起こる理由は、FDSディスクドライブのディスク回転速度あるいはRPMが一定ではないためであった。実際、ディスクが走査されているとき、RPMは想定していた変化の外側となる±15%に至るまで変化している。これは主として何点かで他よりもディスクの摩擦が大きくなることによる。この「ドリフト」のため、プログラムは1を0として、あるいはその逆に考えるのだろう、なぜなら単に、プログラムのパルス解釈は定数に基づいていてそれゆえにパルス間の経過時間に範囲を期待するからである。 　従ってあなたは、どのようにしてRAMアダプタがこのドリフトに対処するのかについて尋ねるだろう。RAMアダプタは、前のパルスが送られた周波数に基づいて、ディスクドライブからのデータ読み込みを解釈する転送速度を動的に調節できる。例えば、RAMアダプタが0を解釈するためには、前に受け取ったパルスから15〜24単位の経過時間範囲が期待され、1には25〜34単位の範囲とする。パルスが22単位の経過時間で来た。RAMアダプタはこれを0と解釈し、ただし"0"の定義を17〜26に、"1"を27〜36単位時間に変更する(実際には、範囲は適切な因数が加えられ、そして差を単純に加減するわけではない、しかしこれは私の単純な説明を越える)。この動的な調整におけるRAMアダプタの柔軟性は制限付きであることに注意(言い換えると、大量の転送速度ドリフトを許容することはできない。このことが、なぜ必ずFDSディスクがそのうち動作を止めるかを説明するだろう)。 　プログラムが転送速度の変化を伴うデータを解釈できるようにするため、同様の方法が私のプログラムに実装されなければならなかった。けれども、0や1に対する経過時間単位範囲について、何らかの初期値に頼る必要がないように、現在のデータ送信速度を自動的に検出できるように実装しなければならなかった。これは、プログラムが他の何よりも最初に入手する最初のデータが"GAP"データであると知ることによって、可能になった。このデータが完全に0から成っていると知ることで、GAPの期間内で最初の経過時間の値を得た後、最初の範囲の定義が計算できる。そして、計算はデータを得る過程の全体にわたって続けられ、いくらかの転送速度ドリフトが補償できることが約束される。もちろん、この構造の実装とともに、CPUクロック速度がデータ解釈に関してプログラムにとって重要ではなくなる。 　だがしかし、前述のアルゴリズムの実装とともにやってきたのは、ちょっとした成功であった。ときどきデータの取得は完全になったが、他のときにはそうではなかった。いくらかの調査の後、パルスがプリンタポートのIRQピンに送られたとき、CPUの応答時間がときどき遅れていることに気づいた。この遅延(96.4kHz割り込み間隔ではおよそ10%の回数で起こる)は、先送りされない普通のパルスの経過時間と比較されたとき、小さなスパイクに形を変える。このアルゴリズムは直前のパルスのみに基づいてパルス範囲の計算を行うので、これらの「スパイク」が動作中のアルゴリズムを台無しにしていた。修正は、最近読み込まれた16パルスかそこらの期間を記録するバッファを整備することであり、ゆえに範囲の計算はバッファ内に保存されたパルスの期間の平均に基づくことができる。そしてこのふるまいによって、範囲の計算が以前に述べた「スパイク」にほとんど鈍感になり、それでもデータを取得できる速度が長時間にわたって変化することは可能になっている。 　このようにして、ここであなたがこれを手にしている。今見ているものは、調査の2ヶ月間、そしてソフトウェアの開発と文書化の4ヶ月強である。これは、これまで私の行ってきたNES関連の最大のプロジェクトである(おそらくNESのサウンドチャネルの解析調査と文書化が2番目だろう)。私が望むのは、私がしてきたのと同じようにこの経過を読んで楽しむことであり、もちろん最後には私の取り組んできたプロジェクトを楽しんでもらいたい。 +------------------------------+ |プログラム・ソフトウェアの説明| +------------------------------+ 　この文書が説明するソフトウェアは2つの用途を持っていて、その両方がNintendo Famicom Disk Systemハードウェア(RAMアダプタとディスクドライブユニット)の利用を必要とする。 　利用者はコマンドパラメータによって、ソフトウェアに読み込む*.FDSファイル(FDSディスクゲームイメージ)を指定する。それからパラレルポートを用いて、何のFDSハードウェアがパラレルポートに接続されているか次第で、ソフトウェアはRAMアダプタあるいはディスクドライブユニットのどちらかと通信を行うことができる。 　RAMアダプタが使われたとき、ソフトウェアは完璧なFamicom Disk Systemディスクドライブのエミュレータとして作動する。読み込まれたFDSディスクゲームイメージが提供するデータは、RAMアダプタの判断で送受信されることができる。RAMアダプタによって修正されたディスクデータは、オプションとして当初に指定された*.FDSファイルに保存することができる。 　ディスクドライブユニットが使われたとき、ソフトウェアはドライブ中のディスクの内容を読み込みあるいはプログラムの変更をすることができる。ソフトウェアは、実行される操作(ドライブ中のディスクの読み込みあるいはプログラムの変更)を制御する。この場合、プログラムの実行に先だって指定された*.FDSファイルは、ディスクイメージの内容の情報源あるいは行き先のいずれかとして扱われる。 +--------------------------+ |プロジェクトの物理的な構築| +--------------------------+ 　このプロジェクトを機能させるのに、外部の電子回路は必要ない。パラレルポートからFDSハードウェアまで直接の電気接続のみが行われる(これらの接続は「配線図」節でお知らせする)。けれども、いくらかの電子工学の技能がこのプロジェクトを終わらせるためにあなたの役割として必要になるだろう。必要となる少数の配線の作成に関して、初心者レベルのはんだ付け・配線の経験をもつものなら誰でも、この役割が難しいとは考えないはずだ。しかしあなたは、このプロジェクトで使われる様々なコネクタを作成・調達する責任を伴っていて、いくらかの問題解決、工夫、あるいはひょっとするとさらに難しい決心を必要とするかもしれない。このプロジェクトのハードウェア関連のどれを完成させることに関しても、この文書には写真あるいはステップバイステップ方式の案内が提供されていない、しかし願わくは、図、配線図、提案で充分であろう。このプロジェクトを完成させるのに必要となる物理的な道具は、以下のものである： - FDSハードウェア(RAMアダプタ・ディスクドライブ)。 - はんだごて・はんだ(ほとんどたぶん、接続を固く結合したいだろうから)。 - 25ピンでオスのDコネクタ。コンピュータのプリンタ・パラレルポートに差し込むため(旧式のコンピュータで使われていた25ピンタイプのシリアルポートコネクタはこの部分のよい調達源になる)。 - 金属線(PCとFDSハードウェアの接続のため)。どんなタイプのものでも非常によく使われるが、私の推奨する2種類のケーブルは、シールド付きのものとリボンケーブルである。無線に関連した電子回路では、リボンが容易に使われる(そしておそらく、ほとんどのコンピュータケーブルがリボンであるので、より利用しやすい)のに対して、シールドは少数派のインタフェースである。あなたが適切だと判断した長さの線を使ってもらいたい。必要とする線(導線)の数を決めるには、「配線図」の節を参照。 - RAMアダプタあるいはディスクドライブユニットに差し込むためのインタフェースコネクタ。RAMアダプタのコネクタは何らかのカードエッジなインタフェースを必要とするので、ピンへのアクセスを得るためには、両面の銅被覆回路ボード(PCB)を差し込んで使うのをおすすめする。銅被覆ボードはコネクタまでの途中ずっとに適合するのにじゅうぶん長く、そしてはんだの詰め物のための空間となるのにじゅうぶん突き出している(しかし一般にPCB一片は非常に小さい)。またそのボードは、コネクタのピンの短絡を防ぐために、片面ごとに5つ、それに向けて線を引かれた等距離の絶縁部を持っている必要があるだろう(これを行うにはユーティリティナイフを使うか、持っているならば他の手段によって)。ディスクドライブユニットのピンへのアクセスを得るための唯一の解法は、RAMアダプタ自身のケーブルを使うことであろう。これは、RAMアダプタを分解してケーブルを抜くことによって、傷つけることなく行うことが可能である。 - オプションとしてオス型の4ピン電源コネクタ、PCの電源ケーブルのひとつに接続するため。ディスクドライブユニットは(そのグランドピンに関して)5ボルトの直流入力を必要とする。この電源は通常RAMアダプタから提供される。けれども、それがない状態では、電源はPCから提供する必要がある。これは、もしパラレルポートがいくらかの電源出力を提供するのならばたいへんなことではないだろうに。従って、この電源はPCの電源ケーブルの一つから取る必要がある。 +----------------------------------+ |ソフトウェアの改良点(前版に比べて)| +----------------------------------+ 　FDSLOADRで当初動作していたデータアップロードの方法(「なぜこのプロジェクトを行ったのか」節の第8〜10段落を参照)の理由で、ポート378hの正確なタイミング(±10%許容)が、ソフトウェアがFDSハードウェアと適切に動作するためには重大であった。デスクトップPCで私はポート378のタイミングをベンチマークし、タイミングは非常に一定している(あるいは少なくともタイミングが許容範囲の点に調節できる)と思われた。だから、プロジェクトのこの特徴は問題にならないだろうし、ポート378のベンチマーク(SPDETECT.COM)を世間に提供し、念のため互換性問題は存在している(おおよそ起こらないと予想していたと)と仮定した。 　けれども、02年4月後半のFDSLOADR一般公開の後、プロジェクトのトラブルシューティングに関するかなりの電子メールを受け取った。具体的に言うと、取り上げられ続けた話題は、SPDETECTにこのプロジェクトの実行へ青信号を与えてもらう問題を抱えた人々にかかわっていた。タイミング問題は(私の知っていたように)ラップトップ型のPCで起こると思っていた。一般的な日本のPCもまた、私のソフトウェアでタイミング問題を発生させる条件となっていた。 　そこで、FDSLOADRソフトウェアに長いこと延び延びになっていた更新を行うことを決めた。最初のプログラムの基にしていた、ポート378hへの二重の16ビット書き込みは、1/(96400×2)時間基準の生成にはもはや使われない。この公開の時点では、(必要となる)単独の8ビットのポート書き込みのみが行われる。慎重に計時されたCPUループが、時間の違いを作り上げるためにポート書き込みの中間に導入されている。これらのCPUループは、FDSLOADRがその実行時ごとに行うベンチマークに基づく繰り返しカウントを持っている。ベンチマークは迅速(2分の1秒)なので、別に気づかれることなく行われるだろう。 　最終的にこの変更は今度こそ、内部タイミングが動的に生成される(このための規定は存在する。詳細は次の節2つを参照)ので、出ている大変多くのどんなPCシステムでもFDSLOADRは動作するという一種の補償になるはずである。けれども、これらのソフトウェアアーキテクチャの改良は、FDSLOADRの最高の進化を意味する。FDSLOADRはソフトウェアエミュレーションによるシリアル通信の一里塚に相当し、そしてFDSLOADRがその最終版でも動作しないのなら、あなたのPCでは外部ハードウェア以外にはそれを可能にするものは存在しない。 +--------------------+ |ソフトウェアの互換性| +--------------------+ - 当該のプログラムは、DOSターゲットのx86マシンコードのバイナリイメージコマンドファイル(*.COM)で格納されている。それゆえ、COMファイルをサポートしないOSではこのプログラムは動作しない。このソフトウェアは386命令を利用しているので、必然的に386より前のコンピュータでは動作しないだろう。 - FDSLOADRをDOS上で単独に実行することを強く推奨する。Windows内でも動作するだろうが、起動時にベンチマークを行うため、Windowsがそのときシステムリソースを占有するよう決めたならば、ベンチマークの結果が汚れてしまう。この期間中にプログラムの優先度を重要と(Windowsに)指し示す方法は(私の知る限り)存在しない。また、ベンチマーク結果がWindowsによって汚されたならば、データアップロードの完全性は直接影響を受けるだろう(これは悪いことである、特にディスクのプログラムの変更をしようとしているならば)。 - アップロードは正確なCPU内部に基づく時間遅延ループに頼る。簡単に言えば、あなたのシステムが速いほどよいということである。それ故に、CPU速度が低いほど、より多くのソフトウェアオーバーヘッドがポート書き込みタイミングに影響する(プログラムの送る一連のビット列の正確さを危うくする)。要約すると、ボトムエンドなシステム(20MHz動作の386など)で動作させようとすれば、すばらしい結果は期待してはならない。数段落で述べられるだろう理由については、機能上ソフトウェア全体の色彩を利用するためには、おそらく少なくとも第5世代x86プロセッサのPCでこのソフトウェアを動作させるべきである。 - Windows(9x)内でのアップロード処理の間は、他の全ての処理が(マウスを含めて)停止する。通常の動作はアップロードが終了してから再開するだろう。これは、データ転送の間に割り込みが無効化される結果である。これは避けることができない、なぜならバックグラウンドでの割り込みの発生はいつでもデータ転送の処理を停止させることができ、これはデータの正確で信頼性のある転送を満足しなくなるからである。 - ダウンロードはWindows(9x)内では動作しない。プログラムがRAMアダプタやディスクドライブからデータをダウンロードしようとすると、(Windowsは無傷で残るはずだが)プログラムは中断するだろう。ソフトウェアは、ダウンロードがWindows内で動作するように調節されているのだが、見たところではWindowsがDOSソフトウェアからパラレルポートIRQをブロックする(あるいは、ただ私が何か正しいことをしていないのか)。 - ダウンロードには、"RDTSC"CPU命令(オペコード0F 31)の実装が必要になる、これは公式にはPentiumプロセッサで導入されている(一部の後期486CPUもこの命令に対応している可能性がある)。この命令に関して対応のないCPUでダウンロードを動作させるためには、その機能をあなた自身でエミュレートさせる必要がある。私の知る限りでは、この課題に利用できる最良の(そして唯一の)ハードウェアはPIT(プログラム可能なインターバルタイマ)であり、これは継続的なカウンタとなるためにプログラムできる。この課題のためにPITを使うのを避けた大きな理由は、その基本カウント周波数が1.19MHzより低めであるからである。経過時間カウントの周波数が低いほど、得られたデータが危うい可能性がある(けれどもおそらく間違いなくこのカウント周波数はじゅうぶんである)。第2の理由は、PITがレガシーISAハードウェアであり、これは極めて低速なI/Oアクセスを意味する。これら両方を計算に入れると、わずかに除算や乗算を利用するデータ取得アルゴリズムとともに、このエミュレーションの実装について少し疑いを抱いている理由を見られるだろうし、486以下のクラスのCPUでまあまあ動作することを期待している。 - このプログラムは、Fan Wenの16バイトヘッダの*.FDSファイルフォーマットのみに対応している。これはまた、プログラムが1つのディスクから取得できるデータの絶対的な最大量が65500バイトであるということも意味している。一般的に、公式のFDSディスクはおよそ57KBのデータを持っているが、カートリッジ方式のゲームの海賊版コピーのディスクは64KB以上のデータを持っている。このようなディスク(65500バイト以上のデータのディスク)を読み込もうとした結果は不確定である。 +------------------------------------+ |プログラムが動かないかもしれない理由| +------------------------------------+ 　このプログラムは、画面の右上隅に(ネズミ色で)あなたのシステムのポート378h速度の測定結果を(Hz単位で)表示する。信頼性のあるアップロードには、このポートの速度が少なくとも192800Hz(この数字は基本的なFDS転送周波数の2倍に由来している)であることが必須である。もし測定結果がそれ以下で、しかし10%未満の差ならば、ポート速度の値は緑がかった青で(そしてたぶん点滅して)表示される。FDSLOADRはこの状況下でもまだ動作するだろう、しかしおすすめできない。もしFDSLOADRが最低基準のより10%以上低いポート速度を計測したなら、プログラムは無条件に終了する(同時にエラーメッセージを出す)。もしこの問題が出たならば、あなたのコンピュータのBIOS(通常はその中の"chipset features"メニュー)にあるパラメータを加減することで、コンピュータのポート378hの動作速度を増加させることができるかもしれない。これを行うには、2つの方法がある。"(8-bit) I/O recovery time"を最小値にする、あるいはPCI:ISA clock ratioを下げる(BIOSがサポートしているなら)、である。これでも歯が立たなければ、FDSLOADRを試すためには他のPCが必要になるだろう。 　プログラムがディスクドライブユニットからデータをダウンロード(取得)する途中に問題をかかえたなら、読もうとしているディスクが痛んでいるのかもしれない。どうしてこれが修正可能かもしれないかを見るには、"DISKFIX.TXT"を読んでもらいたい。また、周知の動作問題のもとでのディスクの読み込みに関しては、より高速なPCを使うと一般に、正確なディスクデータを読み込むことができるだろう。この全ての後でもディスクのデータを読む問題を抱えているのなら、たぶんそれに保存されたデータが破損していて、それは正確に再生することができないということになる。 　もしソフトウェアとFDSハードウェアの間にはっきりと何の通信もないのなら、パラレルポートがBIOSで有効になっているか、ポート番号は378hベースか、IRQは7か、そして配線の接続を二重に確かめてもらいたい。 　最後に、世界中の多くの人々がこのプロジェクトを首尾良く組み立てたので、このプロジェクトは、試みられ、試され、正しいと判断されている。 +----------+ |既知の問題| +----------+ 　このプログラムはキーボードからの(BIOSを経由するかわりに)直接の生データを取り扱っているので、どうもFDS転送の途中にキーが打たれたとき(特に"jamming"のとき)に問題がときどき起こるらしい。この問題は、プログラムが終了するときに下がったキーのうち一つ(すなわちシフト)がロックされるようである。"exit"とタイプしてから影響の出ていたキーを押すことで、この問題が修正されることが分かっている。FDSLOADRの実行中に、激しい(しかしまれな)場合だと、この問題によってキーボード全てがロックされ、キーボードが無効になる。もしそうなら、唯一の解決方法は再起動である。 +------------------------------+ |ディスクのプログラム変更の問題| +------------------------------+ 　(吸い出しには関係ないのでひとまず省略) +----------+ |ピン配列図| +----------+ __________________________________________________ ＼ 13 12 11 10 9 8 7 6 5 4 3 2 1 ／ 　＼ ／ 　　＼ 25 24 23 22 21 20 19 18 17 16 15 14 ／ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　PCの25ピンパラレルポートコネクタの正面図である。ここで注意すべきこととして、パラレルポートの中には実際に穴にピン番号を記入しているものもあるので、念入りに見てもらいたい。 ■■ 　■■■■■■■■■■■■ 　■ 1 3 5 7 9 B ■ 　■ ■ 　■ 2 4 6 8 A C ■ 　■■■■■■■■■■■■ 　RAMアダプタの、ディスクドライブユニットに接続する12ピンの配列の正面図である。ここで注意すべきこととして、ディスクドライブのコネクタピンはこの図と比べて水平に反転しているだろう。 +------+ |配線図| +------+ 　この節は、このプロジェクトを動作させるための、FDSハードウェアとパラレルポートコネクタの間に必要となる電気的な接続を説明する。ここで注意することは、RAMアダプタとディスクドライブユニットは一緒には使えなく、あるときにはその片方のみがパラレルポートと物理的に配線をつなげるということである。 電源信号の配線方法 ------------------ 　パラレルポートのピン番号18〜25はグランド(接地)である。コンピュータのグランド(これらのピン経由で、あるいは他の方法で)とFDSピン番号4の間を接続することが絶対に必要である。グランドのような電源信号を伝えるためには、1本以上の配線を使うのが、絶対に必要ではないかもしれない。しかし弱電信号の線を使う場合には数本を独占的な電源信号用として専念させることを推奨する。これは特にリボンケーブルを使うときには重要である。例えば、パラレルポートのグラントピン8本全てを使い、リボンケーブルの相互に排他的な線を割り当てるべきだろう。また、線に信号を割り当てるときには、リボンケーブル内で電源信号と弱電信号との間を交互に並ばせるよう試みるべきである(すなわち、リボンケーブルの偶数番目の線を電源に、奇数番目の線を弱電に)。 弱電信号の配線図 ---------------- 　下の図は、RAMアダプタとディスクドライブユニットの線の間の一般的な12のピン配列の全て(これらは"FDS"フィールド)と、パラレルポートにおける最終の電気的な行き先("RAM"や"DDU"フィールド)を記載している。"RAM"フィールドに記載されたピン配列は、RAMアダプタをパラレルポートコネクタに接続するときのみ使われ、"DDU"も同様にディスクドライブユニットを接続するときのみ使われる。 　「信号名/解説」フィールドの前に付いているものは"(R)"か"(D)"(これらは信号の源を示し、(R)がRAMアダプタ、(D)がディスクドライブ)であり、前に"-"が付いているものは(省略時である、H(1)が動作中の信号状態なものとは対照的に)L(0)が動作中の信号状態であることを示す。このフィールドで提供される情報は参考のためでしかないことに注意。そうでなければ無視することができる。 　空白のままになっているフィールドは意図的なもので、「当てはまらない」状態(言い換えると、無視できる)を示す。 RAM DDU FDS 信号名/解説 --- --- --- ----------------------- 12 14 1 (R) -write * 2 (R) VCC (+5VDC) 13 1 3 (R) -scan media 15$ 4 (R) VEE (ground) 10 2 5 (R) data 16 11 6 (D) motor on/battery good 14 12 7 (D) -writeable media 8 (D) motor power 2 10 9 (D) data 1 13 A (D) -media set 17 15 B (D) -ready 11 17 C (R) -stop motor $:このピンはパラレルポートの入力である。FDSのピン#4をここに接続することは、(上で述べたように)FDSハードウェアとPCの間に必要なグランド接続状態を満たさない。それゆえ、この接続は「電源信号の配線方法」で述べたものに加えてのものとなる。入力ピンの役割についての詳細は、「ソフトウェアの利用」節の第2段落を参照。 *:ディスクドライブのこのピンは電源入力である。(グランドに対して)+5ボルトの直流をこの入力に提供する必要がある。この電圧は、計算機の中から赤/黒/黄のケーブルを介して利用できる。赤い線が直流+5V(FDSのピン#2に接続)を伝えていて、黒い線がグランド(FDSのピン#4)である。ディスクドライブを動作させるにはさらに、電池あるいはドライブの直流入力を介してその独自の電源条件を満たす必要がある。 +------------------+ |ソフトウェアの利用| +------------------+ 　プログラムのコマンドパラメータとして、FWNESフォーマット(16バイトヘッダ)の有効な*.FDSファイル(ドライブやパスも指定されるだろう)を指定する(これがアップロードしたいデータあるいはダウンロードしたデータの格納先となる)。何ら問題(*.FDSファイルが無効、メモリ確保失敗など)に出くわさなければ、テキストベースの画面モードでプログラムが始動する。両方の動作モードで共通して見えるのは、現在の動作モードを示すテキスト、プログラムのホットキー、それとディスクファイルの転送の進行状況を示すバーである。 　このプログラムの始動したときの動作モードは、どちらのFDSハードウェアがパラレルポートコネクタに接続されているかに依存する(動作モードの名前は、現在接続されているFDSハードウェアと同じである)。しかし厳密には、そこにあるFDSハードウェアを検出あるいは認証する方法がないため、プログラムの始動時におけるパラレルポートのピン#15の状態がモードを決定する。 　指定された*.FDSファイルに存在するディスクゲームごとに対応するディスクファイル転送バー1つがあり、それぞれのバーはディスク上に見つかったファイルごとに四角形1つを持つだろう(特定のディスク面にファイルが存在しないのなら、進捗バーは目に見えないだろうが、存在はしている)。明るく表示(強調表示)されたバーは、現在選択されているディスク面を示す。キーボードの'1'〜'9'(テンキーは除外)によって、現在のディスク面を任意に選択できる(しかし('1'で始まる)キー一つのみが各面に対して機能する)。データ転送が始まれば、現在明るくなっている転送バーは強調解除される。そのとき徐々に読み書きされたファイルがバーの中で強調表示される。アップロード(送信)されたデータは緑の印が付けられ、ダウンロード(取得)されたデータは赤の印が付けられる。 　プログラムで使われる、他の共通するキーは。プログラムの終了キーである'Esc'と'F4'である。F4は、メモリに保存されたデータに変更が加えられていた(これはファイル転送進捗バーに赤く示され、このキーがそれらの保存のために押される必要がある)場合、もとの*.FDSファイルを更新する。 エラー ------ 　ファイルのダウンロードの間に起こったエラーは、使用中のファイル転送進捗バーに印で示される。見えるだろうエラーは2種類ある。 　第一はCRCエラーであり、紫の'X'で示される。CRCの一致しないファイルは、データ転送の中断の原因とはならないだろう。これは、先へ出たCRC不一致ファイルはそれ自身の破損を意味するとは限らないからである。機能するか疑わしいディスクを何度も読むことで、複数の走査に散乱している正確に得られたファイルにょって、ディスクのファイルを全て正確に取得できるかもしれない。これを行う最良の方法は、ディスク面の数を8くらいにした*.FDSファイルを生成して、単純にそのディスクを8回読み、それぞれの繰り返しにおいて(数字キーを介して)プログラムで使用する仮想ディスクの番号を漸次増やすことである。もちろん最後には、利用者は自分で有効なデータを再組み立てしなければならないだろう(これにはFDS形式のディスクデータ構造のレイアウトに関する知識が必要になる、GorohやNoriのFDS文書が利用できるだろう)。 　第二は無効なファイルタイプのエラーである。FDSディスク内のそれぞれのファイルはファイルタイプバイトを持っていて、当該ファイルのサイズを最終的に決定する。有効な所定のファイルタイプは4種類(1〜4)存在する。それら以外の値は、ダウンロードの処理の即時中止を引き起こす。黄色(ときどき灰色)の部分は、不成功であるファイルタイプを進捗バー上で示している(全ASCII文字の図が出くわしたファイルタイプを表示しているのだが、0〜9のみが数字で表示される。)。タイプ#4のファイルのサイズを決定するには、直前のファイルのデータ取得が完全に正確である必要がある。これは、CRCエラーの起こったファイルが存在するときに、タイプ#4のファイルがダウンロードをなぜ中断させるのかの理由となる。無効なファイルタイプに出くわした時点で、取得されたディスクデータは常に切り捨てられる。 RAMアダプタモード ----------------- 　(吸い出しには関係ないのでひとまず省略) ディスクドライブモード ---------------------- 　プログラムがディスクドライブモードで動作するとき、見えるだろうものは、現在のデータ転送方式("READ"(緑)か"REPROGRAM"(赤)のいずれか)のみである。 　READはディスクドライブからのデータのダウンロードを行い、その結果、メモリ上に保存された現在の*.FDSディスクイメージの内容は上書きされる(これはプログラム始動時の既定モードである。)。このモードを選択するには、'Alt'キーを押す。含まれるディスク面の数を特製した「空白の」*.FDSディスクイメージを準備するためには、有効な.FDSファイルヘッダ(16バイト)を生成する必要がある。存在していなければならない唯一のフィールドは、FDS文字列、*.FDSファイルにダウンロードしたいFDSゲームイメージの数(これをこのプログラムが変更することはないし、できない)である。プログラムの終了前にもとの*.FDSファイルへダウンロードされたディスクイメージを保存するにはF4キーの投下が必要なことに注意。 　REPROGRAMは、データ(メモリに読み込むよう指定された*.FDSファイル)をディスクドライブにアップロードし、その結果、ドライブ内の現在のディスク面の内容は上書きされる。このモードを選択するには、右側の'Shift'キーを押す。このソフトウェアは、書き込みプロテクトされたディスクのプログラム変更のリクエストを無視するだろう(注：プログラム変更の試みは効果が望み薄かもしれない。「ディスクのプログラム変更の問題」を参照)。 　ドライブにディスクが入れられたときにのみ、転送が発生する(プログラムが開始されたときにドライブにディスクが存在するならばそのときにも起こる)。一度の走査がいったん行われると、ディスクドライブは停止し、次にディスクが(再び)入れられるまで活動しなくなる。'Space'バーの投下によってこれが覆され、現在選択されている転送モードでのデータ転送を引き起こす。もし、転送が起こると思われるときにディスクドライブユニットの赤ライトが点灯しないならば、ディスクドライブの電池が切れていることを意味する。この状況のとき、プログラムは現在使用されているファイル転送バーを強調解除するだろう。 EOF