超ミニマルなファイル システムを作成するために 2k バイトが与えられたので、FAT16 を取り除いたバージョンを作成することを考えました。
私の唯一の問題は、ボリュームに FAT を保存する方法を理解することです。ブロックごとに 2 バイトを使用するとします。したがって、1024 ブロックになります。1024 行のテーブルが必要で、各行にファイルの次のブロックを保存します。
このブロックのそれぞれが他の 1023 ブロックをアドレス指定できるため、このテーブルが 2k スペース全体を使用しない理由がわかりません。このテーブルをハード ドライブに保存し、1024 ブロックを使用して 1024 行のテーブルを書き込むのではなく、数バイトのみを使用する方法がわかりません。
フラットなファイルシステムを実装することが許可されており、作業するスペースが非常に小さい場合、FAT16 のような階層的なファイルシステムではなく、 Apple DOS 3.3 ファイルシステムのようなものを検討します。FAT16 の前身であるフラット ファイルシステムであるFAT12でさえ、目的に対して非常に複雑です。
Apple DOS 3.3 命名法を使用するために、2 kiB ボリュームを 256 バイトの「トラック」と 16 バイトの「セクター」に分割することをお勧めします。独自の実装で好きな名前を付けてください。ここで設計段階で同じ用語を再利用すると、概念をマッピングするのに役立ちます。
DOS ブート イメージは必要ありません。また、ディスク ドライブ ヘッドの移動のシーク時間を気にする必要もないため、トラック 0 ～ 2 を脇に置いて VTOC トラックをディスクの中央に配置する代わりに、 、トラック 0 に VTOC を配置しましょう。空きセクタ ビットマップ、最初のカタログ セクタの位置などを含む VTOC。
トラック 0 全体を VTOC 用に予約すると、16 バイトのセクターのうち 112 が残ります。これらはビットマップ用にわずか 14 バイトにまとめられます。これは、このためにトラック 0 全体が本当に必要ないことを示唆しています。
代わりに、トラック 0 の最初の 2 つのセクターを取っておき、空きセクター ビットマップにトラック 0 を含めます。これにより、最初の 2 つのセクターが常に「使用済み」としてマップされるため、ある程度の冗長性が生じますが、特殊なケースがなくなったため、実装がより簡単になります。
Apple DOS 3.3 の VTOC の概念を、ボリューム ラベル セクター (VLS) とボリューム フリー セクター ビットマップ (VFSB) の 2 つの部分に分けてみましょう。
VLS をトラック 0 セクター 0 に配置します。
VLS の最初の 2 ～ 4 バイトをマジック ナンバーとして取っておき、このボリューム ファイルがファイル システムに属していることを識別します。これがないと、ボリューム ファイルの唯一の識別特性は、サイズが 2 kiB であることです。つまり、同じサイズの無害なファイルを破棄するようにコードが誘導される可能性があります。それよりも、データ破壊に対するより多くの保険が必要です。
VLS もこのボリュームに名前を付ける必要があります。Apple DOS 3.3 はボリューム番号を使用していましたが、代わりに ASCII 名に数バイトを使用したい場合があります。
VLS は、最初のカタログ セクターを指す必要もあります。これには少なくとも 2 バイトが必要です。128 のトラックがあるため、少なくとも 7 ビットが必要です。トラックとセクターの 2 バイトを使用しましょう。これは、デザインの選択の核心に入る場所です。256 トラックを定義することで、4 kiB ボリューム サイズへの移行を検討できるようになりました。あるいは、この時点で 16 バイトのセクターでは小さすぎると判断し、後で 4 kiB を超えることができるようにセクターを増やします。ただし、今のところ 16 バイト セクタに固執しましょう。
VFSB に必要なセクターは 1 つだけです: 2 kiB ボリューム ÷ セクターあたり 16 バイト = 128 セクター ÷ バイトあたり 8 ビット = 16 バイト。しかし、上記の考えを念頭に置いて、VL に続く VFSB セクターの数のために VLS に 1 バイトを確保して、より大きなボリュームを可能にすることを検討するかもしれません。
Apple DOS 3.3 カタログ セクタのアイデアは、この新しいファイル システムにほぼそのまま反映されるはずです。ただし、1 セクタあたり 16 バイトしか使用できないため、1 セクタあたり 7 ファイルを記述することはできません。次のカタログ セクタへのポインタには 2 バイトが必要で、14 バイトが残ります。各ファイルには、削除済み、読み取り専用などのフラグ用のバイトが必要です。つまり、カタログ セクターごとに 1 つのファイルに対して 13 バイトのファイル名を使用するか、カタログ セクターごとに 2 つのファイルに対して 6 バイトのファイル名を 2 つ使用することができます。1 文字のファイル名を 7 つ指定できますが、それでは不十分です。3 文字のファイル名のアイデアに従うと、ファイルごとのフラグ バイトを考慮すると、カタログ セクタごとに 3 つのファイルになり、定義する余分な 2 バイトが残ります。ただし、セクターごとに1つまたは2つのファイルを使用します。
それはあなたが必要とするものです。残りは実装と拡張です。
拡張に関するもう 1 つのアイデア: これをブータブル ディスク メディアとして使用するにはどうすればよいでしょうか。そのようなものは通常、ブートローダーを必要とするので、VLS および VFSB セクターを 1 つ下に移動して、トラック 0 セクター 0 をブートイメージ用に残しておく必要がありますか? または、VLS に、代わりにブート イメージを含むファイルを記述する最初のカタログ セクタへのポインタが含まれている可能性があります。