実験中パート２
Windows95でフォーマットした16bitＦＡＴのＺＩＰディスクを
ＭＳＸ−ＤＯＳ２でREAD/WRITEする実験をしています。
１２月３０日
わぁ今年が終わっちゃう。年を越さないように、これでFAT16パッチ第一段階を終了します。
リードは多分問題ないのではと思いますが、ＺＩＰの全ての領域で試したわけではありません。
セクタ番号のbit16が変化する位置にあるファイルとか、サブディレクトリがディスクの後方で、
ファイルがディスクの前方にある物とか、問題になりそうなケースだけ試しました。
ライトに関してはコピーなら大丈夫みたいです。これも完璧に試したわけではないです。
普通にファイルを作成するなら、ディスクの位置やディレクトリに関係なく出来るようす。
NGLOADやTRLOADでＺＩＰにセーブした場合、エラーになることがあります。
２８日版のパッチは、リードするセクタがBUFFERに読み込んであるかどうか調べるルーチンで、
手抜きしたので010001hセクタと000001hセクタの区別がつきません。危ないので直しました。
ものすごく危ないですね。
FAT16が使えるのはＳＴだけです。カーネルにはいろいろなバージョンがあるようで、
ＳＴのふたつのバージョンに対応しています。
LUNAと一緒に使えますが、ＣＤエクステンションと一緒に使えないので、そのあたりを何とか
したいです。それから、気になることがひとつ。パッチをあてたSHEMでファイルを指定して
起動すると、セクタ番号のbit16-23が無視されるようなのですが、どうしてなのでしょう。
FAT16パッチ（ＳＴ用）MEGA-SCSI only
１２月２８日
ごめんなさい。下のパッチ、あちこち間違えています。これだからプログラム組みたくないのよね。
ディスクキャッシュを使いたいという要望が届いたので、直すついでに常駐アドレスをちょっと
変更してLUNAと一緒に使えるようにしました。
ディスクキャッシュってあまり使ったことがないし、家にあるのは随分前のバージョンかも
知れません。常駐アドレスは3FB0h〜3FFFhですか？変わってない？キャッシュのお陰で
アクセスが速くなりました。ＺＩＰってＦＤＤみたいに遅いです。
ＭＭを使えるようにしたいです。解析しようかな。
１２月２６日
MEGA-SCSIの拡張入出力の使い方、わかりました。16bitＦＡＴの読み出しを考えて作った機能
ですか？3554hにパッチあてて、拡張入出力が使えるようにしました。
ＦＤＤ以外はメディアＩＤがなくてもＤＩＲ出来るのですね。
ＤＯＳ２カーネルも良くできてますが、MEGA-SCSIは凄いですね。私にはまだまだ理解できません。
３２Ｍｂ以降のルートディレクトリにファイルを作れない問題はまだ解決できてないし、
やっぱり年を越しちゃいますね。
それから、また違う種類のカーネルが見つかりました。
スペインからの報告ですが、ＧＴでUnknown kernelのエラーになるそうです。
ＳＴとＧＴではカーネルが違うのですか？ どなたかＧＴのカーネルを送っていただけませんか。
１２月２３日
論理ブロック数をFFFFFFhに変えてFFFDh〜10004hセクタをリードすると、あっさり読めるじゃ
ないですか。な〜んだ、これなら簡単。でも、こうすると・・・・
この先がわかりません。ＣレジスタにメディアＩＤの代わりにセクタ番号のbit22〜16を入れて、
普通に35E2hをコールすればいいのでしょうか。それともMEGA-SCSIの4010hを直接コールする？
3554hのメディアＩＤをＣレジスタに入れるところ書き換えて、セクタ番号を入れていますが、
こうするとディレクトリが取れなくなってしまうのです。メディアＩＤがないからね。
もうちょっと、という所で先に進めません。
１２月２２日
この実験を始めてから半年近くになりますが、ようやく第１段階終了かなという所まで来ました。
ディレクトリ問題（サブディレクトリからルートディレクトリに戻れない、ディスクの空き容量
計算が出来ない）は解決方法がわかりました。
あとは３２Ｍｂ以降のルートディレクトリへのセーブ、ＣＯＭファイルはＭＭから実行しないと
"Wrong version of MSX-DOS"のエラーが出るので、ＭＭで正常にファイル表示が出来るといいな
とか、まだまだすることがありましたね。
今日は気になっていたけど、大変そうだから見ないようにしていた部分に手を着けましたが、
案の定見なければ良かったという感じです。
25ADhからのセクタREAD/WRITEルーチンで、セクタ番号にREAD/WRITEしたセクタ数を足している
ところがあるのです。FFFFhセクタの次はどうなるのかなって。
この実験、ディスクのFFFFh〜10000hセクタにファイルをセーブしなければいけないので、
それが面倒でした。ＭＳＸで3F95hクラスタまでＦＡＴにFFhを書き込んで、それからWindows95で
ファイルをセーブしました。ファイルは3F96h〜3FA5hクラスタにあります。
SHEMでファイルをリードすると3F99hクラスタが読めません。3F99hクラスタはFFFDhセクタ〜
10000hセクタです。試しに3F99hクラスタを600hバイトと200hバイトに分けてリードしてみま
したが、始めの600バイトはFFFDhセクタ〜FFFFhセクタなので正常に読めました。
後の200hバイトはクラスタ番号が3F99hのままなので読めませんでした。
ファイルのREAD/WRITEはクラスタ単位？なので、クラスタの途中でセクタが終わってしまうと
駄目なのですね。
ＣＤエクステンションみたいに論理ブロック数をFFFFFFhにするとどうなるのだろう。
似非職人工房さんに聞いてみないと、分からないですね。
ディスクを読む前にクラスタ番号のチェックをして、セクタの終わりだったらFFFFhまでを
ファイルリード、そのクラスタの残りはセクターリードして、転送アドレスやファイルリードの
ポインタを書き換える。なんか面倒ですね。
ファイルアクセスルーチンってファンクション26h,27h,48h,49hと共通なので、どっちを使って
いるのか分からないし、ＦＩＢのアドレスを調べるのも・・・・ＦＩＢはBBF2hに書いてあるかな。
年内には終わらない。
１２月１８日
DOS2カーネルはいくつか種類があるようで、ウチのはTYPE Bというものです。
なのでここに出てくるアドレスは全てTYPE B用です。
2B7Eh, 2EB6hのバッファ関連ルーチンを見ていたら、パッチのあてかたが分かりました。
どこにあてたのでしょう。セクタ番号の16-23bitが問題だったわけですね。
でもＦＡＴとルートディレクトリは必ず最上位８bitが０になるので除外します。
そうすると問題はサブディレクトリとデータのあるセクタです。
それでバッファにセクタ番号を書き込むときにそれらを見分けて、サブディレクトリと
データのときはセクタ番号の最上位８bitをBUFFER+8に書き込みます。
そうすればFLUSH(2D23h)の時に完全なセクタ番号が得られると言うわけです。
このパッチをあてて、TRLOADでゲームをＺＩＰのサブディレクトリにセーブしました。
932Chクラスタにバッチリセーブ出来てました。ロードもＯＫ。ところが、ルートディレクトリに
セーブ出来ません。なぜ簡単なルートディレクトリにセーブ出来ないのでしょう。
う〜ん、完成は遠いですね。
そのうち解析結果をアップします。
１２月１４日
ディスクライトの実験をしました。
クラスタ総数計算にパッチあてて、COMMAND2.COMパッチ版（ずっとこれを使ってますけど、
大丈夫みたいです）を使ってＤＩＲを取ると・・・ディスクの空き容量計算に時間がかかりすぎ。
クラスタが多すぎるから？
2/3くらい埋まっているディスクにファイルを作成すると、ＭＳＸがハングしました。
どこで止まるのか・・・ページ３を他のセグメントにしてから実験してみよう。
スタックが残っていれば分かるかも知れないから。
FAT16-4は直しましたので、今度こそディスクの後ろの方が読めます。
１２月１３日
最近、ボケているのかも知れない。ＺＩＰの後ろの方に作ったサブディレクトリが
読めなかったのは、BIT 7,D を潰すのを忘れていたからでした。
３ヶ所潰してあっさり解決しました。それにしても物忘れが・・・
解析結果もきちんと残しておかないと、時間の無駄ですね。
若い人が受け継いでくれるといいのだけど。
１２月１２日
実験用のＺＩＰディスクを作りなおしました。
WIN95にＭＳＸのHDDを繋ぎたかったのに、どういう訳か出来ませんでした。
以前は出来たのに・・・・って、WINのHDDを飛ばす前でした。
何か必要なファイルがあったのでしょうか。
HDDが繋がらないので、ＣＤからＺＩＰにコピーすることにしました。
思いっきり後ろのクラスタ（BE6Fh）にサブディレクトリ\ROMを作って、ディスクの真ん中
あたりのファイルを大量に消してから、ROMに大量のファイルをコピーしました。
変な作り方ですね。
FAT16-4を起動して、TRLOAD F:\ROM\TWIN-BEE.ROM 実行するとFile not foundになります。
何か変です。SHEMから\ROM\TWIN-BEE.ROMをリードすると読めるんですよね、１回だけ。
どうして１回だけなのでしょう。
サブディレクトリ\ROMはBE6Fhクラスタ（2FB55hセクタ）、TWIN-BEE.ROMは91A2hクラスタ
（24821hセクタ）にあります。BBB4hにはファイルのセクタ番号、BBE2hにはサブディレクトリの
セクタ番号がそれぞれ16bitだけ入っています。
そしてバッファにもサブディレクトリのセクタ番号が16bitだけ。
２回目からファイルが読めないのはどうしてなのでしょう。
１１時を過ぎたので寝ます。
１２月１１日
私の頭は夜１１時になると、自動的にお休みモードになってしまうようです。
昨日は１１時過ぎにホームページの更新をしましたが間違いが多くて、２回目の訂正をした
ところです。
１２月１０日
クラスタ総数問題は原因がわかりました。DOS2カーネルの3311hあたり、ブートセクタからDPBに
値を書き込んでいます。そこにもパッチをあてて、COMMAND2.COMパッチ版を使うとディスクの
空き容量計算が正常に出来ました。
これで３２Ｍまでのリード／ライトが出来ます。それ以降はリードのみです。
それにしても３２Ｍ以降のライトは難しいです。バッファのセクタ番号を保存するスペースが
16bit分しかないし、BB80h〜BBFFhでセクタ番号を保存するところが２ヶ所(BBB4hとBBE2h)。
セクタ番号のbit16-23をどうしたらいいのやら。
バッファの+8hって空いてるのかな。空いていればセクタ番号の上位bitを入れてしまうとか。
１２月１日
ＦＡＴに書き込むルーチンを見直すと、こんな所に間違いが・・・。
という訳で早速なおしました。ＺＩＰへのファイル書き込みが出来ます。
ただし、ディスクの空き容量計算が正常に出来ないので、書き込みは３２Ｍまでのアクセスに
なります。
NSLOADとTRLOADでＺＩＰからロード、ＺＩＰにゲームのセーブをしてみましたが、
セーブ／ロード共に正常でした。
ディスクの空きクラスタが３２Ｍ以降にあるディスクの場合、たぶんDISK FULLになると
思うのですが、確かめていないので実験される方は注意して下さい。
ＭＳＸで書き込んだ後、Windows95で読めるのかな。試してない。
１１月２７日
クラスタ総数の計算について情報をいただきました。
早速 COMMAND2.COM のDIRルーチンと MEGA-SCSI の4016hルーチンにパッチをあてました。
DIRコマンドを使ってみると、空き容量計算が間違っています。どうして。
DPBを見るとクラスタ総数が 3FF0h になっています。BFF0hにしたはずなのに。
どうもクラスタ総数の bit15,14 がリセットされてしまうようです。
フラグにでも使っているのでしょうか。
モニタでメモリ上のDPBとワーク内のDPBを書き換えれば、空き容量計算は正常に出来ます。
と言ってもクラスタ総数が BFF0h といい加減な数値なので、正しくないですね。
１００Ｍｂって 100 * 1024 * 1024 ですか？ 違う？
数字が大きくなると分からなくなってしまう。
１１月２４日
パッチのあてかたを変えたので、見落としがなければクラスタ番号の上位bit問題は解決したかも。
ＦＣＢを使ったファイルの書き込みは、ＺＩＰ以外のドライブでは問題なしです。
WIN95フォーマットのＺＩＰにＭＳＸで書き込むのは、なんか問題ありそうで、
その前に問題ありすぎて私には出来ないです。
FAT16パッチのNEW VERSIONです。
NSLOAD、NGLOAD、TRLOADでＺＩＰのＲＯＭファイルをロード、ＨＤＤにゲームのパラメータを
セーブなんてことが出来ます。
ファイルセーブ用のドライブにＺＩＰを指定するとエラーになるので、間違えても大丈夫かな。
もしかしたらＺＩＰのディレクトリにはしっかりとファイル名が書かれてしまうかも知れませんが。
それからＭＭからの操作も出来ます。時々、サブディレクトリに行ったときに画面表示が乱れます。
表示出来ないサブディレクトリもあります。これってクラスタ番号のせいかも知れませんね。
セクターバッファ問題かも。
ＤＯＳ２って良くできてますね。
サブルーチンに行くときのレジスタの値が決まっているじゃないですか。
IY=BB80h、 IX=ＦＣＢ又はＦＩＢのアドレス、 HL=ＤＰＢのアドレスとか。
Ｚ＝０で戻ったらエラーとか。
下の空きクラスタが探せない理由がわかりました。原因はＤＰＢのクラスタ総数＋１です。
ＺＩＰのクラスタ総数＋１は3F98hになってしまうので、ファイルの書き込みでＦＡＴが
3F00hクラスタまでワークに読まれていたのでした。だから'DISK FULL'なのですね。
ということは動作は正常？
クラスタ総数の計算って、いつどこでするのですか？ MEGA-SCSIの論理ブロック数を
変えても変化なし。もしかして、ディスクのブートセクターの情報から求めている？
１１月１５日
実験が進んでいろいろと分かってきたら、#26,#27はクラスタ番号の問題で使えない気がしました。
FCBを使ったファイルの書き込みでは、FCB+1Dhの上位4bitをフラグに使っているようなので、
クラスタ番号問題でファイルのクローズが出来ません。
FIBを使えばＺＩＰ以外のドライブではファイルが書けます。
9000hクラスタあたりまで使っているＺＩＰに、FIBでファイル書き込みを試してみました。
結果は空きクラスタが見つけられずエラーになりました。
ページ２のワークを見るとＦＡＴは3F00hクラスタまでしかリード出来ていません。
ＦＡＴが大きすぎて読めないのでしょうか。カーネルを見ると空きクラスタサーチにはループ回数が
ないし、クラスタ番号が0000hかFF00hを見つけるまでループするはずなのですが。
１１月６日
ファイルハンドルのオープンで、FIB+31hに変な値が書き込まれる原因がわかりました。
MEGA-SCSIファンクションコールを使うときに、裏レジスタを保存していなかったからでした。
ファイルハンドルは使えるようになったのですが、DIRを取ったときのディスクの空き容量計算は
駄目です。
あと、クラスタ番号のbit15が１になると、ルートディレクトリと判断されてしまいます。
お願いだから bit 7,d だけで判定しないで。
このあたりのパッチが大変かも知れない。
あっ、最大の難関を忘れていました。DISK BUFFER。
１１月２日
ちょっと行き詰まっているので、ファイルハンドルの仕組みを調べてみようかな。と言うことで、
パート２になりました。
今までのパッチではかろうじてファンクション#27が使えましたが、#48では駄目でした。
#48のファイルハンドルの読み出しを使っても、ディスクリードルーチンは#27と一緒なので、
理論的には読めないはずはないのです。
ファイルハンドルのオープンは正常終了なのですが、どういう訳かデータセグメント内のFIB+31hに
変な値が書き込まれてしまいます。ここはオープン時にAレジスタにセットした値が書き込まれます。
パッチをあてるとなぜか最初のファイルオープンのときだけ、違う値が書かれてしまうようです。
ひとつでもオープンしているファイルがあれば、正常値になるのですが。不思議。
う〜ん。どうなっているのだろう。
FAT16パッチ開発日記に戻る
トップページに戻る