TRON仕様では、 データの交換媒体であるフロッピーディスクの標準形式を規定している。 これは、基本的にアプリケーションプログラム、 およびアプリケーションデータの交換用フロッピーディスクに対してのみ適用されるが、 マシンに依存したシステムフロッピーディスク等の場合も同一形式であることが望ましい。
フロッピーディスクのセクタは 物理ブロックとも呼び、 物理的なアクセスの単位となる。 また、論理的なアクセス/アドレシングの単位を 論理ブロックと呼び、 連続した n 個の物理ブロック(セクタ)から構成される。 論理ブロックの大きさは標準フ ロッピーディスクでは 1024 バイトとする。
単にブロックといった場合は論理ブロックを示し、 論理ブロック単位のアドレスをブロックアドレスと呼ぶ。
最大論理ブロック数、 最大ファイル参照カウントの制限を緩和した拡張形式がある。 拡張形式も基本的には標準形式と同一である。 拡張形式に関しては、標準形式と異なる部分のみ記述する。
標準フロッピーディスクは以下に示す全体の構成を持つ。
システムブロック はファイルシステム全体の情報を保持するブロックであり、 以下に示す構成を持つ。
システムヘッダは、128 バイトから構成され、以下の構成を持つ。 この部分はファイルシステムの生成時に作成され、 以後、"*" を付けたデータ以外は変更されない。
各データの内容を以下に示す。 各データは上位バイトが先(若いアドレス)にくるビッグエンディアン形式である。
標準形式の場合 | 0x42FE |
拡張形式の場合 | 0x52FE |
標準形式の場合 | 0x6400 |
拡張形式の場合 | 0x6401 |
SFIDT | = (最大ファイル数×ファイルIDテーブルの1エントリバイト数) / 論理ブロックのバイト数 |
= (NFMAX×4)/1024 |
SFNMT | = (最大ファイル数×ファイル短縮名テーブルの1エントリバイト数) / 論理ブロックのバイト数 |
= (NFMAX×4)/1024 |
標準形式の場合 | |
NBMP | ≧ 論理ブロックの総数/8 |
≧ NLB/8 | |
拡張形式の場合 | |
NBMP | ≧ 論理ブロックの総数/32 |
≧ NLB/32 |
0x0021
となる。
0(レベル0) | アクセス管理は行なわない。 |
1(レベル1) | アクセス管理を部分的に行なう。 |
2(レベル2) | アクセス管理を完全に行なう。 |
ビットマップは論理ブロックの管理に使用され、 使用ブロックビットマップと不良ブロックビットマップの2つがある。
1 つの論理ブロックが1つのビットに一対一対応し、 使用ブロックビットマップでは、"0" で未使用、 "1" で使用中または不良を示し、 不良ブロックビットマップでは、 "0" で正常、"1" で不良を示す。 不良ブロックに対応する使用ブロックビットマップ上のビットは、 必ず "1" に設定される。
ファイルIDテーブルは、 そのファイルシステム内に存在するファイルの開始ブロックアドレス (3バイト) とファイルの参照カウント (1バイト) をファイル ID 順に並べたテーブルであり、 システムヘッダ内にある最大ファイル数分のエントリから構成される。
ファイルの参照カウントは、 そのファイルを参照している同一ファイルシステム内の固定リンク数を示す。 参照カウント0は、 どこからも参照されておらずファイルが削除可能であることを示す。
標準形式では、最大ファイル参照カウントは 255 となる。 拡張形式では、ファイル参照カウントが 255 以上になった場合は、 ファイルIDテーブルのファイル参照カウント値を 255 とし、 実際の参照カウント値 ( 255 以上 ) をファイルヘッダへ記録する。
標準フロッピーでは、 最大ファイル数は NFMAX であり、 ファイル ID テーブル全体は (NFMAX×4) バイトから構成される。
ID に対応する 4 バイトのエントリが0の場合は、 未使用エントリを意味する。
ファイル短縮名テーブルは、 そのファイルシステム内に存在するファイルのファイル名を短縮化 (ハッシュ化) した4バイトの値をファイル ID 順に並べたテーブルであり、 システムヘッダ内にある最大ファイル数分のエントリから構成される。
標準フロッピーでは、 最大ファイル数は NFMAX であり、 ファイル短縮名テーブル全体は (NFMAX×4) バイトから構成される。
40 バイトのファイル名全体は各ファイルのヘッダ部分に入るが、 このテーブルはファイル名によるファイルの検索を高速に行なうために使用される。
ファイル短縮名は以下の方法により生成される。
短縮名 = 0; for (i = 0; i < 10; i++) { 短縮名 = 短縮名 ^ NAME[i]; 短縮名 を右に1ビット回転シフトする。 }
ファイル領域にはそのファイルシステム内のすべてのファイルが入り、 その先頭にはルートファイルが必ず存在する。 ルートファイルはファイルシステムの生成時(フォーマット時) に自動的に生成されるファイルで以下の特徴を持つ。
1 つのファイルは、順序付けられたレコード列から構成され、 1 つのレコードは可変長のバイト列から構成される。 1 つのファイルは、ヘッダブロック、データブロック、インデックスブロック、 および間接ブロックから構成され、 その構成はインデックスレベルと呼ぶ値により異なる。 インデックスレベルはレコードインデックスの多重度を示す値で、 レコードの数に応じて動的に変化する。 インデックスレベルが 0 , 1 , 2 の場合のファイルの構成を以下に示す。
なお、リンクファイルはヘッダブロックからのみ構成される。
ファイルのヘッダブロックは、以下に示す構成となる。
ファイルヘッダは 192 バイトで構成され、 ファイルの各種の管理情報が保持されている。 以下にファイルヘッダの内容を示す。
各データの内容を以下に示す。 各データは上位バイトが先(若いアドレス)にくる ビッグエンディアン形式である。
0x54726f6e
の固定パターン
TTTT xxxx BAPO xRWE
T : ファイルタイプ | 0 リンクファイル |
1 通常ファイル | |
2〜 予約 | |
P : 削除不可属性 | |
O : 変更(書込)不可属性 | |
A : アプリケーション属性1 | |
B : アプリケーション属性2 | |
RWE : ファイル所有者のアクセスモード | |
x : 予約 (0) |
0x82dde96b
の固定パターン
リンクファイルの場合は、 ファイルヘッダに続くフラグメントテーブルの部分に以下に示す 90 バイト対象ファイルの所在を示すファイル所在データが入る。 各データは上位バイトが先 (若いアドレス) にくるビッグエンディアン形式である。
フラグメントテーブルは、 レコードの削除/サイズ縮小等によって発生した 1 つの論理ブロック内の断片的な空き領域 (フラグメント) を登録するテーブルであり、 レコードの追加 / サイズ拡張で新たな領域が必要となった場合参照されるテーブルである。
このテーブルには現在そのファイルに対して割り当てられている論理ブロック中の空き領域 (フラグメント) が最大 32 個まで登録される。 フラグメントが 32 個以上となった場合は、もっともサイズの小さいフラグメントはテーブルから取り除かれる。
レコードの削除 / サイズ縮小等が行なわれていない場合でも、 通常は、最後に書き込んだブロックの残り領域が 1 つのフラグメントとして登録されることになる。
フラグメントテーブルは以下に示す構成をとり、 各エントリは 6 バイトから構成される。 未使用エントリは、フラグメントサイズ = 0 で示される。 エントリは、必ずサイズの大きい順に並び、 途中に未使用エントリが入ることはない。 即ちフラグメントサイズ = 0 のエントリがあった場合は、 それ以後のエントリはないものと見なされる。
リンクファイルの場合は、 フラグメントテーブルの代わりにファイル所在データが入る。
レコードインデックスは各レコードの管理情報を保持している 16 バイトのインデックスである。 インデックスレベル = 0 の場合は、 ヘッダブロックに最大 40 個のレコードインデックスが入り、 インデックスレベル < 0 の場合は、 インデックスブロックに入る。
1つのレコードが複数の論理ブロックにまたがる場合は、 通常のレコードインデックスの直後に接続インデックスと呼ぶ論理ブロックの割り当て情報を示すインデックスエントリが続く。 この接続インデックスは内部的なものであり、 レコードの数としてはカウントされない。
以下に各レコードインデックスの構成を示す。
各データの内容を以下に示す。 各データは上位バイトが先 ( 若いアドレス ) にくるビッグエンディアン形式である。
100T TTTT
T:レコードタイプ | 0 リンクレコード |
1〜 その他のレコード |
割り当てられている論理ブロック | |
連続カウント 1 | X |
連続カウント 2 | X, X+1 |
連続カウント n | X, X+1, ... X+n-1 |
レコードインデックスの形式は、先頭の2バイトの値により決められる。
第1バイト | 第2バイト | |
接続インデックス | ≠0 | any |
通常インデックス | =0 | ≠0 |
リンクインデックス | =0 | =0x80 |
未使用インデックス | =0 | =0 |
間接インデックスは、インデックスレベル >0 の場合に使用され、 レコードインデックスを含む論理ブロックを示す以下の 8 バイトのエントリである ( 1 論理ブロックに 128 個、ヘッダブロック内は 80 個)。
最初の 4 バイトのデータは、 間接インデックスで示される間接ブロックまたはインデックスブロックが含む有効なレコード数 (接続インデックス、 未使用インデックスを除いたレコードインデックスの数) を示す。 これは、 レコードの位置によるシークを行なう場合に使用される。
論理ブロックアドレス = 0 の間接インデックスは未使用エントリと見なされ、 未使用インデックスは、 論理ブロック内の任意の位置に存在してよい。 なお、 間接ブロック中で使用されていない部分は、 すべて未使用エントリで埋められていなければいけない。
レコードインデックスの最大数はインデックスレベルの値により以下のようになる。
インデックスレベル | 最大レコードインデックス | |
0 | 40 | |
1 | 5120 | (64×80) |
2 | 655360 | (64×128×80) |
レコードインデックスとデータブロックとの対応の例を以下に示す。
レコードインデックスは、 ヘッダブロックまたはインデックスブロックの中で、 レコード順に並べられているが途中 ( 最初、最後も含む ) に任意個の未使用インデックスが入っていてもよい。 ただし、 接続インデックスは、 通常インデックスの直後から隙間無く連続して入っていなくてはいけない。 接続インデックスが複数の論理ブロックにまたがる場合でも、 論理ブロックの切れ目(最後、最初)に未使用エントリが入ってはいけない。
なお、 インデックスブロック中で使用されていない部分は、 すべて未使用インデックスで埋められていなければいけない。
インデックスレベル = 1 で、以下の状態の場合を考える。
間接インデックス | インデックスブロック | |
53個 | → | A:64個のエントリ(内、接続インデックス11) |
42個 | → | B:50個のエントリ(内、接続インデックス 8) |
20個 | → | C:20個のエントリ(内、接続インデックス 0) |
未使用 |
この例で、 110番目のレコードをアクセスしたい場合は、 110-53-42=15から、 インデックスブロックCの15番目のレコードインデックスを使用することになる。
また、10番目のレコードの直前にレコードを追加した場合は、 インデックスレコードAを2つに分割 ( 通常は2等分 ) しインデックスブロックA' と A''を生成して、 間接インデックスに登録することになる。 レコードの追加後の状態は以下に示す通りとなる。
間接インデックス | インデックスブロック | |
26個 | → | A' :33個のエントリ(内、接続インデックス7) |
28個 | → | A'':32個のエントリ(内、接続インデックス4) |
42個 | → | B :50個のエントリ(内、接続インデックス8) |
20個 | → | C :20個のエントリ(内、接続インデックス0) |
未使用 |
データブロックにはレコードの実際のデータが、 レコードインデックスで示されたブロック、 オフセットに入るが、 1つの論理ブロック内のフラグメントを管理するために、 1つの論理ブロック内のレコードとレコードの境界には空き領域を示す 2 つの区切りコードを格納する必要がある。
区切りコードは空き領域のサイズをバイト数で示した2バイトのコードであり、 空き領域の先頭と最後にそれぞれ入る。 レコードとレコードの間が隙間無く詰まっている場合は値 0 の区切りコードが連続して2つ入ることになる。 論理ブロックの先頭、および最後の区切りレコードは省略される。
以下に1つの論理ブロック内の区切りコードを示す。 図で、→はレコードインデックス内のオフセットを意味し、 ⇒はフラグメントテーブル内のオフセットを示す。 いずれの場合も区切りコードの直後の位置を示す。
1 つの論理ブロック内の隣接する空き領域は常にマージされ 1 つの空き領域にまとめられるため、 2 つ以上の空き領域が連続して存在することはない。
レコードの生成、追加、削除、サイズ変更、再配置等の操作では、 区切りコードを正しく設定し直す必要があり、 その結果、論理ブロック全体が空き領域となった場合はそのブロックを解放することになる。
TRON 標準フロッピーディスク形式では、 異なるプロセッサ間を含めたフロッピーディスクの交換を完全に保証するために 8 ビット以上のビット長を持つデータのバイトオーダーは、 上位バイトが先にくるビッグエンディアン形式に統一している。
しかしながら、 この形式はリトルエンディアン形式の CPU 上で動作する BTRON では負担となる場合もあるため、 これを救済するために、 リトルエンディアンのデータ形式を持つフロッピーディスク形式を、 準標準フロッピーディスク形式として規定する。
準標準フロッピーディスク形式は、 TRON 標準フロッピーディスク形式に対して以下に示す変更 / 制限を行なったものである。
システムヘッダの TRON ディスク ID、 およびディスク形式 ID のバイトオーダーにより、 TRON 標準フロッピーディスク形式か、 準標準フロッピーディスク形式かの識別が行なわれる。 すなわち、BTRON標準の場合は、0x42, 0xFE, 0x64, 0x00 であり準標準の場合は、0xFE, 0x42, 0x00, 0x64 となる。
準標準フロッピーディスク形式に基づいたシステムは、 以下の点を遵守しなくてはいけない。
本仕様書の中で、 ビッグエンディアン形式によって記述された図は、 準標準フロッーディスクにおいては、 M(Most Significant Bit) と L(Least Significant Bit)の表記が逆になる。 ここではそのすべてを掲げないが、 その一例として、 準標準フロッピーディスク形式によるレコードインデックスの構成を示す。
また、システムブロックにおけるビットマップ構成は、以下のようになる。
TRON標準フロッピーディスク形式の仕様に基づいて実現された フロッピーディスクのいくつかの例をあげる。