ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第２１１回］
●ＶＦＴＳＴ１５の実行（その２）
前回はＶＦＴＳＴ１５を実行してＡＬＶ（Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）の中味を表示しました。
ＶＦＴＳＴ１５はファンクションコール１ＢＨを実行してＡＬＶの先頭アドレスを取得し、そのアドレス以降の１２８バイトの内容を１６進数表示します。
下は前回お見せしましたそのときの実行画面です。
［第１４３回］を開いて、それをバックにしてＶＦＴＳＴ１５を実行しました。
最初にカレントドライブがＡドライブのときにＶＦＴＳＴ１５を実行し、次にカレントドライブをＢドライブにして、同じようにＶＦＴＳＴ１５を実行しました。
ＡＬＶについては前回説明しましたが、そこのところをもう一度再掲します。
仮想フロッピーディスクドライブは各ドライブともサイズは２ＭＢです。
ＣＰ／Ｍはドライブをブロックという単位で管理しています。
仮想フロッピーディスクドライブは１６セクタを１ブロックにしています。
ＣＰ／Ｍの１セクタは１２８バイトです。
ですから１ブロックは２０４８バイトになります。
２ＭＢ（２０４８ＫＢ）はちょうど１Ｋ（１０２４）ブロックになります。
ＡＬＶ（アローケーションベクトル）は１ブロックを１ビットに割り当てます。
そのことからＡＬＶのバイト数は１０２４／８＝１２８バイトになります。
ＶＦＴＳＴ１５を実行した結果、ＡドライブのＡＬＶは先頭から１４バイトがＦＦになっています。
１５バイト目は８０ですから、１ブロックだけ消費されています。
全体では１４×８＋１＝１１３ブロックが使われていることになります。
このうち最初の２ブロック（№０、№１）はディレクトリ用にリザーブされています。
するとファイルとして使われているブロックは№２～№１１２になります。
で。
前回はこのあとＡドライブのディレクトリセクタの内容を表示して、セーブされているファイルのＦＣＢエリアに書かれているブロック№を確認することで、ブロックの使用状況がＡＬＶに反映されているということを説明しました。
実際にファイルデータをセーブするときはセクタ（１２８バイト）単位で行なうのですが、ＦＣＢでの管理をセクタ単位で行なおうとしますと、ＦＣＢエリアとＡＬＶが巨大なものになってしまいます。
ちなみにＣＰ／Ｍでは１セクタ１２８バイトなので、２ＭＢ（２０４８ＫＢ）の仮想ＦＤＤの場合、セクタ数は２０４８×８＝１６３８４（１ＫＢ＝１０２４＝１２８×８）になります。
この全てを管理するにはディスクディレクトリのＦＣＢエリアは少なくとも３２ＫＢ必要です。
そのほかにファイルネームのためのエリアなどが必要ですから、ディレクトリエリアは少なくとも６４ＫＢは必要です。
セクタに換算すると６４×８＝５１２セクタです。
またＡＬＶは１６３８４／８＝２０４８バイトも必要になります。
ということで。
ＣＰ／Ｍではざっくりとブロックで管理することになっています。
ＣＰ／Ｍは私が作ったシステムではありませんから、そのようになっている理由は本当のところはわかりません。
でも多分そういうことではないかと思います。
もちろんファイルのセーブ／ロードはセクタ単位できっちり行なわれます。
ただたとえ１セクタしか使わなくても、そのセクタが含まれるブロックは使用済みになってしまいます。
それがＦＣＢとＡＬＶがブロック単位で管理される、ということの意味です。
さて。
それではもう少し具体的に、その管理の実際を見てみることにします。
前回のＶＦＴＳＴ１５の実行によって、Ａドライブは先頭から１１３ブロックが使用済みであることがわかりました。
ＡＬＶは１ブロックを１ビットで示し、使用済みブロックはそのビットを１で示しますから、上でお見せした画像では、ＡＬＶの内容を１６進数で表示した結果、ＦＦＦＦ…ＦＦ８０と表示されています。
この状態は先頭のブロックから順に隙間無く消費されている状態に見えます。
それではその途中にあるファイルを削除してみたら、その結果はどのようになるのでしょうか。
それを試してみたいと思います。
最初にＤＩＲコマンドを実行して、Ａドライブのディレクトリを表示させました。
その中で、 ＴＥＳＴＤＡＴとＴＥＳＴＤＡＴ２．ＴＸＴの２ファイルをＥＲＡコマンドで消去しました。
ＴＥＳＴＤＡＴはシステム作成途中のバグで先頭にスペースが入れられてしまいました。
ＥＲＡコマンドのファイル名指定で’？’を置いているのはそのスペースを無視するためです（’？’は１文字を置き換えるためのワイルドカードです）。
消去した結果を確認するために、もう一度ＤＩＲコマンドを実行しました。
ＴＥＳＴＤＡＴとＴＥＳＴＤＡＴ２．ＴＸＴは表示されなくなりました。
そのあと、ＶＦＴＳＴ１５を実行してみました。
その結果は？
おお。
ファイルを消去する前はずっとＦＦが並んでいたのですが、今回は途中にＤ７が見えます。
Ｄ７＝１１０１０１１１です。
間を１つ置いて２つのブロックが使用済みから未使用に変わったようです。
その部分をディレクトリのＦＣＢで確認してみましょう。
前回も実行したＶＦＤＵＭＰです。
ファイル名の ＴＥＳＴＤＡＴとＴＥＳＴＤＡＴＡ．ＴＸＴの先頭にＥ５が書き込まれています。
ＦＣＢエリアの先頭にＥ５が書かれると、そのファイルが消去済みで、このＦＣＢエリアそのものも上書き使用してもよいことを示します。
ＴＥＳＴＤＡＴのブロックアローケーションエリアを見るとブロック№００５ＥＨがあります。
ＴＥＳＴＤＡＴＡ．ＴＸＴは００６０Ｈです。
５ＥＨ＝９４、６０Ｈ＝９６です。
９４／８＝１１余り６
９６／８＝１２
ですから先頭の№０からビットに当てはめて１６進数で示すと、№９４と№９６のみを０、そのほかのビットを１とすれば１１個ＦＦが続いてそのあと１のビットが６個あって、その次が０になります。
ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＦ ＦＤ ７Ｆ
↑ここのところは
１１１１１１０１ ０１１１１１１１
という感じです。
このようにＳＡＶＥやＥＲＡコマンド、ユーザープログラムによるファイルのセーブ、削除のたびにドライブ内のブロックの使用状況を常に最新のものとして記録し管理しています。
この働きこそがＤＯＳ（Ｄｉｓｋ Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）のコアなるところなのです。
ワンボードマイコンでＣＰ／Ｍを！［第２１１回］
２０１２．９．７ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る