Gamecube-ファイルシステムデバイス





こんにちは、ハブロフスク市民! 最後のトピックでは、チームと私が任天堂Wiiで Xenoblade Chroniclesのようなゲームをどのようにロムハッキングしたかについて説明しました。 あまり単純ではないが興味深いトピックである、 任天堂のGameCubeファイルシステムストレージデバイスについてお話ししたいと思います。 たまたまこのコンソールに夢中になり、小さいながらも技術面について話す機会を逃すことができませんでした。 遅らせないで、始めましょう!



はじめに



トピックのタイトルが明確であるため、 ニンテンドーゲームキューブファイルシステムの配置方法、より正確にはディスクファイルシステムの配置方法について説明します。 Nintendo GameCubeで使用されるこれらすべてのディスクについて話しましょう。 ガレージで家を出て、 デロリアンに座ってゼロの始まりに行くようにお願いします。 2001年の構内では、 Sony PlayStation 2が1年間ゲーム機市場を支配し、 任天堂のGameCubeが登場しました 。 より強力な詰め物、より多くの可能性がありますが、なぜ売上がPlayStation 2ほど高くないのですか? 任天堂とその海賊版対策ポリシーと、コンソールでストレージメディアとして使用することに決めたモンスター-miniDVDドライブ自体に、「ありがとう!」と叫びます。 彼はどんな人だったのか、そしてなぜ彼はそのような潜在的なコンソールを破壊することができたのか、あなたは尋ねる? 答えは、DVDディスクの半分のサイズでしたが、問題は1.5 GBの小さなサイズでした( PlayStation 2の DVDの4.7 GBに比べて)。 これは純粋に私の個人的な意見ですが、このドライブの販売を台無しにしたのはこのドライブでした。 これについて多くのことを話すことができますが、それでもメイントピックに戻ります。 はい、 任天堂GameCubeのために独自の1.5GBディスクを発明しましたが、これは大規模なゲームには十分ではありませんでした。 さまざまな圧縮アルゴリズムを使用して、ゲームをディスクに収まるように何らかの形で短縮する必要がありました。 さて、悲しいことはもう十分です。メイントピックに戻りましょう。



技術コンポーネント



前述したように、ディスクの容量は1.5GBでした。 このようなボリュームでは、慣れているISO9660またはその修正をすべて使用することは明らかに不利でした。 任天堂は別の方法で行った-彼らはファイルシステムを記述するための技術を開発し、その基礎はFST(FileStringTable)ブロックでした。 このブロックはコンパクトで、ファイルに関するすべての必要な情報を保存します。これについては後で詳しく説明しますが、これについては後で詳しく説明します。



ゲーム画像全体を6つのブロックに分割できます。



  1. 基本情報(boot.bin)
  2. 基本情報への追加(bi2.bin)
  3. Apploader(apploader.img)
  4. FileStringTable(fst.bin)
  5. DOL(main.dol)
  6. マスタデータ


各ブロックを個別に検討することを提案します。 たとえば、 バイオハザードコードベロニカX (GCDP08)のヨーロッパ版の最初のディスクが使用されました。



基本情報、boot.binブロック







このブロックはファイルの先頭にあり、どの種類のディスクで、次に何をするかを特定できる情報が含まれています。 0x440バイトの固定サイズがあります。 バイトがあり、その値はまだ明確ではありませんが、それらには触れません。より重要なことだけを説明します。



class gcmBoot { public uint gameCode; public ushort makerCode; public byte diskID; public byte version; //seek to 0x1C public uint DVDMagicWord; //0xC2339F3D public string gameName; //seek to 0x420 public uint offsetMainDol; public uint offsetFST; public uint sizeFST; }
      
      





上記のコードからわかるように、このブロックにはディスクコード、その番号(ゲームに複数のディスクが含まれる場合に使用)、ゲームの名前、DOLブロックへのポインター、FSTブロックへのポインターとサイズが含まれます。 このブロックには他のデータがありますが、それらはデバッグモードに使用されます。デバッグモードは、市民モードではまったく使用されません。



基本情報への追加、ブロックbi2.bin



このブロックは、最後のブロックと同様に固定サイズですが、今回はそのサイズは0x2000バイトであり、boot.bin(0x440)の後に厳密に開始します。 私はそれについて何も言うことはありません、それはデバッグモードの情報が含まれています。



Apploader







このブロックは、その名前が示すとおり、イメージのロード、FSTの解析、モジュールの初期化、DOLファイルの起動を担当します。 彼についても、bi2.binについても何も話すことがないので、先に進みましょう。



FileStringTable、fst.binブロック







最も興味深いのは、このブロックに画像内のすべてのファイルのマークアップが含まれていることです。ファイルとフォルダーの名前、それらのオフセットとサイズです。 アドレスgcmBoot> offsetFSTで始まり、サイズはgcmBoot> sizeFSTです。



その構造は次のとおりです。



 class gcmFST { public byte flags; // 0: File; 1: Dir; public uint offsetName;//Real size 3 byte //if flags = 0 public uint fileOffset; public uint fileSize; //if flags = 1 public uint dirParent; public uint dirNext; }
      
      





私はそれを簡単に説明しようとします:



1バイトは、ファイルまたはフォルダーに関する情報があるかどうかを判別するために使用されます。 残りの3バイトは、ファイルまたはフォルダーの名前を持つ行へのポインター用です(ポインターは、FSTブロックの先頭ではなく、files \ foldersの名前を持つブロックの先頭から始まります)。



最初のバイトが0(ファイル)の場合、次の8バイトは次のことを意味します。



  1. 4バイト-イメージ内のファイルへのポインター
  2. 4バイト-ファイルサイズ


最初のバイトが1(フォルダー)の場合、次の8バイトは次のことを意味します。



  1. 4バイト-このフォルダーが置かれているフォルダーの番号
  2. 4バイト-このフォルダー内のアイテムが終了するアイテムの番号


ファイルを使用すると、すべてがシンプルで理解しやすくなりますが、フォルダーを使用すると、それほどではありません。 しかし、私はあなたにすべてを説明するためにここにいます。 たとえば、フォルダーはディスクのルートにあり、habrという名前を持ち、dirParentは0(ディスクのルートにあるため)ですが、dirNextの値は6です。フォルダー自体はFSTブロックの3つの要素にあるため、後続の要素はすべて最大6ですアイテムはhabrフォルダー、つまりアイテム4と5にあります。



私が言い忘れた最も重要なことは、0ブロック(つまり最初のブロック)はディスクのルートへのリンクであり、ブロックには要素の名前を持つ名前はありませんが、ポインタはあります。 考慮する必要があるだけで、それ以上のことはありません。



ご覧のように、同様の構造のおかげで、サイズが非常に小さくなっています(ISO9660とその修正版と比較した場合)。



ドル







sayingにもあるように、ゲームの核心です。 Windows -EXE、およびGameCube -DOLの両方。 メインの実行可能ファイルでブロックします。 もちろん、別の実行可能ファイルが使用され、メインのゲームファイルと一緒に保存されたゲームもありましたが、多くの場合、そのような倒錯した人はいませんでした、神に感謝します。



さて、彼について何がわかりますか? セクションに分割された単純な実行可能ファイル:



  1. 7つのTEXTセクション(コード)
  2. 11個のDATAセクション(データ)


マスタデータ



そして最後のブロックは、その本質を名前で伝えます。 このブロックはファイルの最後に移動し、2048バイトで整列されたすべてのファイルを含みます。 スペースを節約するために、これらのファイルを2048バイトではなく4バイトに揃えることができるという伝説があります。 そして、エミュレータ上でも非常に正確に動作します。 しかし、この方法でレーザーを殺すことは間違いなくあなたにとって難しいことではありません。



おわりに



このトピックでは、 任天堂がどのようにしてみんなを地獄に送ったのかを発見し、シンプルでありながら興味深いコンパクトなファイルシステムを開発しました。 もちろん、ファイルストレージ機能があるため、家庭用PCでの使用には適していません。 このファイルシステムには、File \ Dir以外のフラグは保存されません。ファイルの作成時間、各セクターのEDC \ ECCなど、ISO9660で利用可能な情報は保存されません。 しかし、彼女はここでは必要ありません。 任天堂は、このようなコンパクトなファイルシステムを設計して、ゲームデータ用のスペースを増やしました。 結局、ゲームシステムのディスクに、ファイルの作成などにかかった時間を保存する必要があるのはなぜですか?

ご清聴ありがとうございました。



All Articles