Gamecube - file system device

Hi, habrovchane! In the last topic, I told you how we and the team produced (and continue to produce) the rhomming of a game like Xenoblade Chronicles on the Nintendo Wii . I would like to talk about a less simple but interesting topic - the storage system of the file system in the Nintendo GameCube . It just so happened that I fell in love with this console and could not miss the chance to talk about its technical side, albeit small. We will not delay, let's start!

Introduction

As is clear from the title of the topic, the discussion will focus on how the Nintendo GameCube file system works , or more precisely, how the disk file system works. Let's talk about what all of these drives were used on the Nintendo GameCube . I ask you to leave the house in the garage, sit in DeLorean and go to the beginning of zero. In the courtyard of 2001, the Sony PlayStation 2 has been dominating the gaming console market for a year now and it is Nintendo GameCube . More powerful stuffing, more potential, but why sales are not as high as those of the PlayStation 2 ? Let us shout “Thank you!” To Nintendo and their policies from piracy and the monster that they decided to use in their console as a carrier of information - the miniDVD disk itself. What he was and why he was able to destroy such a potential console, you ask? And I will answer, he was half the size of a DVD, but the problem was a small amount of 1.5 GB (as opposed to 4.7 GB for a DVD on a PlayStation 2 ). This is purely my personal opinion, but it was this disk that ruined the sales of this console. We can talk a lot about this, but still we will return to the main topic. Yes, Nintendo invented for the GameCube its own 1.5GB disk, which was absolutely not enough for large games, which is why they were divided into several disks (hello 90th). I had to use a bunch of different compression algorithms, somehow reduce the game, so that they climbed onto the disk. Okay, enough about the sad, it's time to return to the main topic.

Technical component

As I said above, the disk had a volume of 1.5 GB. With such a volume, it was obviously unprofitable to use the established ISO9660 or its modification. Nintendo went the other way - they developed their file system description technology, the basis of which was the FST (FileStringTable) block. This unit is compact and stores all the necessary information about the files, I will tell you more about it, but more on that later.
')
The whole game image can be divided into 6 blocks:

1. Basic Information (boot.bin)
2. Supplement to basic information (bi2.bin)
3. Apploader (apploader.img)
4. FileStringTable (fst.bin)
5. DOL (main.dol)
6. Basic data

I propose to consider each block separately. For example, the first disc of the European version of Resident Evil Code Veronica X (GCDP08) was used.

Basic information block boot.bin

This block is located at the very beginning of the file and contains information that allows you to identify what kind of disk it is and what to do with it next. It has a fixed size of 0x440 bytes. There are bytes, the values ​​of which are still not clear to me, but we will not touch them, I will tell only what is more important:

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; } 

As can be seen from the code above, this block contains the disc code, its number (used when the game contains several discs), the name of the game, the pointer to the DOL block, the pointer and the size to the FST block. There are other data in this block, but they are used for the debug mode, which is not used in civil mode at all.

Supplement to basic information, block bi2.bin

This block, like the last one, has a fixed size, though this time its size is 0x2000 bytes, and it begins strictly after boot.bin (0x440). I have nothing to say about him, it contains information for debug mode.

Apploader

This block, as the name implies, is responsible for loading the image, parsing the FST, initializing the modules, running the DOL file. I don’t have anything to tell about it, as well as about bi2.bin, so go ahead.

FileStringTable, fst.bin block

So we got to the most interesting, this block contains the markup of all the files in the image: the names of files and folders, their offset and size. It starts with the address gcmBoot> offsetFST and has the size gcmBoot> sizeFST.

Its structure is as follows:

 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; } 

I will try to clarify easier:

1 byte is used to determine whether the file or folder information is being sent. The 3 remaining bytes are intended for a pointer to a line with the name of a file or folder (the pointer starts from the beginning of the block with the names of the files \ folders, and not from the beginning of the FST block).

If the first byte is 0 (file), then the next 8 bytes means:

1. 4 bytes - a pointer to the file in the image
2. 4 bytes - file size

If the first byte is 1 (folder), then the next 8 bytes means:

1. 4 bytes - the folder number in which this folder is located
2. 4 bytes - the number of the element on which the elements in this folder end

With files, everything is simple and clear, but not with folders. But, I'm here to explain everything to you. For example, the folder is in the root of the disk, has the name habr, dirParent is 0 (because at the root of the disk), but dirNext has the value 6. The folder itself is 3 elements in the FST block, therefore, all subsequent elements are exactly 6 the item will be in the habr folder, that is, item 4 and 5.

The most important thing I forgot to say, so the 0 block (that is, the first one) is a link to the disk root, it does not have a name in the block with the names of the elements, although it does have a pointer. It just needs to be considered and nothing more.

As you can see, thanks to this structure, it has a very small size (when compared with ISO9660 and its modifications).

Dol

As they say, the heart of the game. Like Windows - EXE, and GameCube - DOL. Block with the main executable file. Of course, there were games where a different executable file was used, stored with the main game files, but, more often, no one was perverted like that, thank God.

Well, can you talk about it? A simple executable file divided into sections:

1. Seven TEXT sections (code)
2. Eleven DATA sections (data)

Basic data

And the last block, which tells its essence by name. This block goes to the end of the file and contains all files aligned to 2048 bytes. There is a legend that to save space, you can align these files not by 2,048 bytes, but by 4 bytes. And it will even work, on the emulator so accurately. But to kill the laser in this way you just will not be difficult.

Conclusion

In this topic, I tried to reveal how Nintendo sent everyone far away and developed a simple, but still interesting and compact file system. Of course, it is not suitable for use on home PCs because of its file storage features. This file system does not store any flags except for File \ Dir, does not store the file creation time, EDC \ ECC of each sector, etc., which is contained in ISO9660. But she is not needed here. Nintendo has developed such a compact file system to provide more space for game data. After all, why should a disk with a gaming system keep the time of file creation, etc.?
Thanks for attention.