ＤＯＳを作ろう
昔のＯＳはＤＯＳ、つまりディスク・オペレーティング・システムと言われていた。
これはその多くの機能がディスクのアクセス関連だったからだ。
現在のＯＳはディスク関連以外に多くの機能を持つが、今回そこまでは作らない。
本当にファイルアクセスが最低限できればいい程度のＯＳにする予定だ。
「ファイルアクセスに必要なのはシーケンシャルアクセスとランダムアクセス。そしてディレクトリエントリとＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）の管理だ」
今回ランダムアクセスの機能は入れない予定だ。
とりあえずファイルをシーケンシャルに読み書きできれば、最小セットとしては十分なはずだ。
ランダムアクセスが必要になってくるのは仮想記憶とかもっと複雑な処理が必要になってからだ。
どうしても必要ならＢＩＯＳを直接アクセスすればいいしね。
最初に決めるのはディレクトリエントリとＦＡＴの仕様だ。
昔のＰＣはメモリーが少なく名前をファイル名八文字＋拡張子三文字のように制限していた。
その名残が今のＷｉｎｄｏｗｓにもあってファイル名に変な制限があったりする。
またＦＡＴもメモリ節約のためにＦＡＴ１２やらＦＡＴ１６やらＦＡＴ３２やら機械の進歩に合わせて泥縄式に対応してきた歴史がある。
最初に作られたものがデファクトスタンダードになりやすいので、できれば慎重に決めたいが。
「ＨＤＤ領域は十分あるから初めから柔軟性のあるシステムにしても構わないんだが、データが増えると速度がより遅くなるからなー」
ここでも速度の制限がシステムの制限となりそうだ。
構造を単純に、データを少なくすれば少なくするほど早くなる。
すでに快適とは言えない状態になっているので、ここでの速度低下は避けたい。
「本格的な規格は商用コンピュータを発売する時でいいか」
どうせ研究用は自分と数人の研究者しか使わないのだ。
協力者と話し合ってどこまでやるか改めて研究すればいいだろう。
ということで昔のＭＳ－ＤＯＳと同じ八文字＋三文字のファイル名でディレクトリエントリは決定。
ＦＡＴはどうしたものかな。
現在のＨＤＤもどきの容量は五〇メガバイト。
１セクタ四〇九六バイトだから、一二五〇〇セクタほどが管理できればいい。
セクタをいくつかまとめてクラスタとして管理すれば更に少なくてすむわけだが、クラスタを大きくすると無駄が多くなる。
まあ、そのうちメガ単位が誤差の範囲になるだろうから、あまり気にする必要もないが。
「気にしなければならないのは、速度の方だね」
基本、ディスクアクセスは一セクタ単位で行う。
１バイトのデータでも１セクタ分読み込むわけだから、無駄な時間が発生する。
やろうと思えば１ビット単位でもできるが、どうせガイドビットやエラー訂正用ビットも読まないといけないのだ。
必要な１ビットだけ読んでも意味はない。
昔は（今も？）ＨＤＤは五一二バイトがセクタサイズの基本で、これをいくつかまとめたクラスタなるものでＦＡＴを管理していた。
そう考えると、今の１セクタ四〇九六バイトは大きすぎるかもしれない。
速度面からすれば１セクタ二五六バイト程度でもいいか。
どうせクラスタでまとめるのであれば、セクタサイズが小さいほうが調整しやすい。
ＨＤＤの多くが五一二バイト１セクタだったのは、容量と管理サイズのバランスを考えた結果なのだろう。
ＨＤＤは円盤を高速回転させデータを読み書きする。
その位置決めのためにセクタの前後にＧａｐというものが必要になる。もうすぐデータですよと示すマークだ。
１トラックにたくさんのセクタを書き込もうとすると、このＧａｐが増えて、使える容量が減ってしまう。
かといって大きくしすぎると、セクタ数が少なくなるので１ファイル１バイトとかのファイルがたくさんあると無駄が多くなる。
精霊コンピュータにはこのＧａｐなるものがないから、セクタを小さくしても問題は少ない。
チェックサムが少し増えるくらいか。
必要ならクラスタサイズを大きくすればいいわけだし。
クラスタサイズ×ＦＡＴの管理個数がＨＤＤの最大容量となるから、ここのバランスをどう取るかが重要になる。
クラスタサイズを大きく取れば、ファイルの最低容量がクラスタサイズとなり、１バイトのファイルでも三二キロバイト使用することになったりする。
逆にＦＡＴの管理個数を大きくしクラスタサイズを小さくすれば、ファイル一個あたりの無駄は少なくなるが、ＦＡＴの管理領域が大きくなってしまう。
自分としてはクラスタサイズを小さくしてＦＡＴサイズを大きくしたほうがいいと思っている。
将来小さなファイルとか大量に増えることが予想される。
ブラウザのキャッシュとか、なんかよくわからないアプリのデータとか、気がつくと何万ファイルもフォルダに入っている。
それが数バイト程度しかないファイルだと、ＨＤＤ全体容量の数分の一しか使わないうちにいっぱいになってしまうということがあり得る。
現在のところ管理に必要な個数は一二五〇〇個程度だから、ＦＡＴは一六ビットでも十分足りる。
セクタサイズを二五六バイトとかにすれば、三二ビット必要だが、五〇メガバイト程度なら、三二ビットにしても管理領域がそんなに増えるわけでもない。
今回は容量より速度をとってセクタサイズやクラスタサイズを最小限にして、無駄な読み書きを減らしたほうがいいかもしれない。
将来的にはＮＴＦＳとか高機能なファイルシステムにしたいが、今は諦めざるを得ない。
ＤＯＳがあるだけでもコンピュータの歴史を数世代飛び越えたようなものなのだからこれで満足しておこう。
「やりたいことは多いが、やれないことが多いな」
それもこれもこの先を知っているからの贅沢なのだが。
さて、シーケンシャルリードライトをどうやって作っていくか。
現在のＯＳだとファイルハンドルなどを介してデータのやり取りを行うのが一般的だ。
ファイルハンドルとは、ファイルをオープンしたときに渡される管理ＩＤのことで、ＭＳ－ＤＯＳだと内部で管理する管理番号になっていたはずだ。
ファイルアクセスというのは通常、ファイル名とアクセスモードを渡しファイルをオープンして成功するとファイルハンドルが返ってくる。
次はそれを渡してやることにより、ファイルにアクセスできる仕組みだ。
ディレクトリエントリへのポインタだとかファイルの読み書き位置などの細かな情報はこのファイルハンドルに紐づけられた管理領域に書き込まれる。
そのためユーザープログラムは細かいことを気にしなくてもファイルアクセスできるようになっている。
ユーザープログラムはファイルをオープンして読み書きしクローズするだけでいい。
今回はデータやシーケンスの一気読みと一気書きの機能のみ入れる予定だ。
もっと高度となるとテキストモードとバイナリモードがあったり、テキストモードなら一行ずつ読み込めたり一バイトずつ読み込めたりといった機能があるが、今回は組込まない。
本当に必要最低限の機能にすることで開発期間の短縮と動作速度の向上を図る。
「機能が単純だと開発もサクサク進むな」
未だに紙上コーディングなのだから開発ステップが少ないのはいいことだ。
自分の魔導書を手に入れ、好きに起動実験ができるようになったから、全部を紙上で行っていたことに比べれば雲泥の差だ。
「あー、早くエディタを開発したい」
しかし楽になればなったで、さらなる希望が出てくるものだ。
せっかくキーボード入力が可能になったのだから、シーケンスもキーボードから入力して画面上で修正したい。
そうすればいちいち下書きを消去魔法で消して書き直すということしなくてすむ。
最近のＨＤＤは容量を増やすために１セクタ４０９６バイトにしてＧａｐを減らているものがあります。
しかし、１セクタ４０９６バイトに対応していない環境もあり、擬似的に５１２バイトにしているものが多いようです。
この場合１セクタを書き換えるために４０９６バイト読み込み、その中の一部を書き換えて再び４０９６バイト書き込むというＲｅａｄ Ｍｏｄｉｆｙ Ｗｒｉｔｅという手法が使われます。
そのため単純に細かいファイルを読み書きすると、当然パフォーマンスは落ちます。
そこでキャッシュメモリにデータを保存しておいて４０９６バイトになったら書き込む等いろいろ工夫しているようです。
他にもできるだけ回転待ちを減らすように読み書きの順番を変えたりとか、地道な調整が行われているようで、同じ回転速度、容量、プラッタ数でもこの辺の調整次第で性能は結構変わってきます。
また、使用メーカーや用途によって、様々な調整がされているようで、例えば書き込みが少なく読み込みが大多数な環境では、リードキャッシュのみライトキャッシュ無効とかの設定がされている場合があります。
なので、組み込まれているＨＤＤを換装した場合、同じメーカー品でも思ったほどパフォーマンスが出ない場合がありますので気をつけましょう。
