┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃		ＦＡＴ３２ツールシリーズ				      ┃
┃		 Copyright (C) 2000-2002 by AIG-Soft			      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	歴史								      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

２０００／０８ごろ
	某所にてＦＡＴ３２上のファイルを読む出す必要が出てきた。
	と言うことで開発。
	
	本当はデバイスドライバー化したかったが、そこまでの技術・時間共にないのと、
	本来の目的（秘密）のためにはそれは不要なので、やめにした。
	読み書き両方したいが、書き込みは当面不要なので読みだし専用にした。
	
	と言うことで、仕様を絞って開発開始。
	ＦＡＴ３２に関する資料は以前から集めていたので、ここでは特に収集せず。
	ＦＡＴという機構に付いてはＸＣプログラマーズマニュアルによる。

２０００／０９／０３
	ドリームキャストを買ってしまう。
	やりたいゲームはもちろんサクラ対戦・・・ではなくグランディア２。
	しばらく開発は遅れる・・・かも知れない。

２０００／０９／１２
	基本関数群とりあえず完成

２０００／０９／１３
	基本関数を使って従来から有るツールをＦＡＴ３２対応させる。

２０００／０９／１４
	第１版完成

２０００／０９／１７
	グランディア２　１回目終了。
	感動。
	お勧めゲームに入れておこう。

２０００／０９／２０
	第１版発表

２０００／０９／２１
	やはりロングファイル名を表示したいので調査＆改良開始。
	意外にも簡単に出来上がる。
	一番の課題はロングファイル名がUnicodeという文字コードで記述されている
	ことだが、ここはGORRY氏のVTwentyOneのソースを使わせてもらうことで解決。

２０００／０９／２４
	第２版発表

２０００／０９／２７
	立花えり子氏のFATCHKと言うツールがあることを知る。
	良さげなので早速ＦＡＴ３２対応版を作る。
	但し、プログラムは完全オリジナルなので、同氏のツールとは使い方は違う。

２０００／１０／０３
	ロングファイル名での指定も可能にした。
	読み出したロングファイル名と比較可能にしただけだが、ワイルドカード比較処理は
	完全に差し替えである。
	
	ファイル名に２バイト文字を使った時、２バイト目が'\'になると誤動作
	するのを発見、修正。

２０００／１０／０４近辺
	ファイル削除を開発開始する。
	ファイル削除はディレクトリエントリの削除とＦＡＴリンクの削除の２つから成る。
	基本的にはファイル／ディレクトリ／ボリュームで共通である。

	ファイル削除はロングファイル名対応版しか考えない。
	ＶＦＡＴも削除しなければならないと言うことである。

２０００／１０／０８
	グランディア２　３回目開始。
	今回はスペシャルステージ最後まで攻略と、魔法・スキル・必殺技を
	全員・全部ＭＡＸ化をめざす。

２０００／１０／１０〜１３
	ファイル削除開発続行。
	書き込みがあるだけに慎重になる。
	なかなかうまく動かなかったが、原因は引き数の渡し方の間違いであった。
	Ｃの出す警告を安易に無視してはいけない。

２０００／１０／１５
	グランディア２　３回目終了。
	初めて、本編で全滅無しで終了出来た（スペシャルステージでは不覚を取ったが）。
	レベルが５０を越えると急に楽になってくる（戦闘に面白味がなくなる、という説もある）。

２０００／１０／１６
	関数レベルでファイル削除を完成。
	
	ファイル削除の前にファイル属性変更も必要なのでその関数も作る。
	簡単なので２時間で完成。

２０００／１０／１８
	プログラムとしてファイル削除を完成(ADEL32)。
	早速発表しようと思ったが、満開ネットが休止中なので先送り。

	ついでなのでファイル属性変更も作成(ATTRIB32)。

２０００／１０／１９
	ファイル名長に関する設定が間違っていたので全プログラム修正。

	実は、ほとんどのプログラムがまともに動かないことが判明。
	原因調査開始。
	
	１、ロングファイル名用バッファーを取りすぎてスタック不足になっていた

２０００／１０／２０
	まだ動かないプログラムがある。
	
	２、ロングファイル名系関数とショーとファイル名系関数が混在していた
	３、一部内部関数の持つバッファーがロングファイル名長に対応してなかった
	４、原因不明だが、ハングアップする場所が解ったものは処理方法を変えて
	　　原因関数を取り除くことで対処。かえって処理が簡略化され速くなったはず。
	５、FAT16版からあったバグ
		acopy32のルートディレクトリからサブディレクトリ/ALL2コピーが出来ないなど
	まだacopy32は途中で止まる。

	某所に貸しているX68000CompactXVIで、どうもSRAM設定値が消えるようである。
	バックアップ電池が劣化しているらしい。
	ちょうど満開製作所で出物があったので買ったが、これがまた物違いで配送されてきた。
	(CompactXVIはPanasonicのVL1220で、送られてきたのはSANYOのCR2450。
	前者はリチウム２次電池＝充電可能で、後者はリチウム１次＝充電不可。
	よって置き換え不可。）
	どうするべ、作業出来ないぞ。

２０００／１０／２３
	だいぶ良くなってきたが、それでもまだacopy32が途中で止まる。

	fs32		ファイルが見つからない
	attrib32	カレントディレクトリ変更がおかしい
	adel32		カレントディレクトリ削除がおかしい

	LUN付き指定時にドライブ名が化けるバグを修正（ライブラリの問題）。

２０００／１０／２４
	acopy32のバグ追跡
	デバッグルーチンを入れまくってやっと解析。
	
	６、パス名長がHumanの許すそれを越えていた
	
	ファイル名の規定を変えて対応。
	
	しかしそこを直してもまだ暴走する。
	どうもメモリーを食いつぶしている。こういう時はスタックが怪しいので
	-fstack-checkを入れて追ってみる。やっぱり。
	
	７、ディレクトリが深くなった時にスタック不足になっていた
	
	ワークエリアをスタックではなくmalloc()で取るように変更。

	と言うことで、やっと完成。

２０００／１０／２５
	読み込みキャッシュを入れることで、心持ち高速化。
		files32/fs32/adel32/attrib32/acopy32
	連続記録されてない／深いディレクトリがあるという状況でないと
	余り効果が出ないんだけど。

２０００／１０／２６
	スペース入りファイル名には何かと問題が多いので、オプション化した。
	（TWentyOne +Sでも使えないツールは多い。）
		acopy32

２０００／１０／２７
	スペース入りファイルの処理に問題が合ったので修正。
	１８バイトを越えるファイル名の処理に問題が合ったので修正。

	第３版発表・・・と思ったけど、満開ネットが復活しないので先送り。

２０００／１１／０２
	acopyのファイル名長さの判定がおかしかったので修正。
	TwentyOneを常駐したからといって２１文字使えるとは限らないのね。
	２１じゃなくて１８＋３。

２０００／１１／０７
	やっと満開ネットが再開したので発表。

	アップ後に眺めていると、.hisに誤字、２つの.hlpに間違いを発見。
	致命的な問題ではないので当面公表しない。

２０００／１１／０９
	うちの環境を追記。
	ドキュメントの各所をいろいろと修正・変更。

２０００／１１／１０
	ドライブがエラーを返してきた時のリトライ方法を
	単純な時間待ちからセンスキーを用いたものに変更。
	これにより、的確と言うかＳＣＳＩ規格に乗っ取った処理になった。

２０００／１２／０４
	FORMAT32がようやく動くようになった。
	しかし、これでフォーマットしたディスクにアクセスすると従来のツールが
	バスエラーを起こす。何故？

２０００／１２／０５
	問題は１クラスタのサイズにあった。
	従来は１クラスタ４Ｋまでしか対応してなかったが、FORMAT32は
	DVD-RAMに対しては１クラスタ８Ｋをデフォルトとしていたためである。
	４Ｋではいくら何でも小さいので１６Ｋまで拡大した。
	これより大きい場合もエラーにすることで、バスエラーは出さないようにする。

	うぉっ、どうもディレクトリの内容が表示されないところがあるぞ。
	途中で切れている。
	ファイルエントリのデータをダンプして「新事実」が発覚。
	ファイルエントリって、１クラスタ全部使うんじゃ無くて、
	途中までで次のクラスタへ移ることがあるのね。
	（８Ｋクラスタの場合、４Ｋで終わっていた。）
	ということで、修正（ライブラリのみ。しかもわずか）。

２０００／１２／１１
	そうか、ＦＡＴ３２＋ロングファイル名でファイル作成が出来れば、
	Ｘ６８のファイル名そのままでWindows機に持っていけるようになるから、
	ＣＤ−ＲＯＭにも元のファイル名のまま記録出来るようになる＝
	CD-ROMでまともにＸ６８データの保存が出来ると言うことか。
	（Julietモードを使えば。）
	これは良いかも知れない。がんばらんと。

２０００／１２／１５
	Format32の細部チェック。
	ルートディレクトリの位置を変更するとWindowsでエラーになる。
	よって、このオプションは削除。
	他は軒並み大丈夫。

２０００／１２／１８
	ＦＡＴを１つにした時は大丈夫。しかし３つにするとおかしい。
	そういう構造にWindowsが対応していないかどうかの判定以前の問題で、
	フォーマットそのものが書き込めていない。
	どうも書き込みキャッシュの挙動がおかしい。
	しかしデバッグ用にprintf()を入れたら動く。速度の問題か。
	
	何かエラー発生時のチェックが甘すぎるので、format32にエラーチェックを
	徹底的に入れる。

	しかしある時から急にエラーが出なくなった。
	全く解らない。ＳＣＳＩバスの安定度の問題かも知れない。
	とりあえず再現しなくなったのでほっておくことにする。
	公開後にまたレポートがあれば再度調査しよう。

	でもやっぱりWindowsは３つ以上のＦＡＴを許さないようなので１／２に制限する。

	/L(L)時にはフォーマット中にセクター番号を表示するようにする。
	これで動いているかどうかが解って、気分的に安心。
	
	オプションのインダイレクト指定を出来るようにしようかとも思ったが、
	設定出来る項目も減ったのでやめることにした（実現は難しくない。
	ライブラリがあるから）。

２００２／２／２８
	パーティションを切った大容量ドライブに対してFILES32を実行すると何故か
	全く表示されないで終了するので解析していったら、いくつかのバグがあることを発見。
	・大容量ＨＤＤ（何Ｇ以上かは突き詰めてない）のＦＡＴ３２で表示されない
	・暴走することがある
	修正はライブラリのみだが、全てのプログラムが対象になるのでリンクし直し。
	
	また、format32はフォーマットそのものの理解に間違いが合ったので修正。
	・表示される名称を変更
		BOOT -> BPB
	・オプション名を変更
		/SECBOOT     -> /SECBPB
		/SECBOOTCOPY -> /SECBPBCOPY
		/BOOT2FAT1   -> /BPB2FAY1
	このため、これでフォーマットしたディスクは旧版のツール群ではアクセス
	出来なくなるがしかたなしとしよう。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	少しだけ技術的な話						      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

これらのツールは基本的には、Ｘ６８上のＦＡＴ１６／１２のディスク・ファイル用に
作られたツールに対し、ＦＡＴ３２用関数を差し替えるだけで作成している。
その関数の開発には時間がかかったが、差し替え（移植）は２日ほどで出来ている
（デバッグを除き）。

それだけ従来のＣ標準関数と互換性を考えて作っているのだが、
諸般の事情から現在はそれを公開出来ない。
いずれ問題が無くなったら公開することもあろう。
説明書などは書き上がっているのだが。

現在の関数群には以下の制約がある。

・ファイル削除/属性変更を除き読み出しのみである
・ファイルアクセスはバイナリーモードのみである（テキストモードはない）

将来やりたいこと（開発順）
　１、リネーム
	１−１、ディレクトリエントリ削除（完了）
　	１−２、ディレクトリエントリ新規作成（ロングファイル名が解析出来ず中断）
	１−３、ＦＡＴリンク作成
　	１−４、ディレクトリ移動
　２、ファイル書き込み
	２−１、ＦＡＴリンク延長
	２−２、データ書き込み
　３、フォーマットパーティション対応

しかし、十分な時間は当面取れそうにないのでそんなに直ぐには出来ないだろう。
２００２年中には何とかしたいが。

ロングファイル名(VFAT)はFAT32用のものではない。
Windows95登場時からあり、FAT16やFAT12でも使える。
構造は複雑ではないが、リネーム関係が面倒ではある。
ディレクトリ領域を使うので、従来「ルートディレクトリには何ファイルまで入る」
という数があったが、これより少ないファイルしか記録出来なくなる。
８＋３以内のファイル名でも以下のような文字を使うとロングファイル名が出来てしまうので
要注意である。
	全角文字が含まれる（８＋３バイト以下でも）
	半角スペースなど８＋３ファイル名で使えない文字が含まれる
	英小文字が含まれる

	・・・

何故専用関数が必要なのかも書いておこう。

・通常のブロックデバイスとして実装すると、Human内蔵のFATシステムの管理化に入るため
　FAT32は絶対に実現出来ない。そのため、ファイルアクセスを完全にデバイスドライバ側に
　渡すリモートドライブ型にする必要がある。
・SUSIEはリモートドライブ型デバイスドライブの例であるが、残念ながらCD-ROM
　アクセス部分のみであり、その他ディスクはやはりHumanに任せているのでFATの
　差し替えは出来ない。
・そのようなわけで、完全に一からドライバーを書く必要が出てきたが、
　いきなりデバイスドライバー型にするにはサポートすべきことが多すぎて手に負えない。
　そこでＣのライブラリ型にした。ＯＳレベルでのサポートではないため制限は多いが、
　読み込みに関してだけ言えば、ユーザープログラムを作るには十分である。

結局、これを元にSUSIE等に組み入れて欲しいとひそかに願っているわけである。
（いや、Humanそのものの改良か。）
それをやってみると言う人には、ソースの公開をするかも知れない（実績評価の上）。

余談。
・ＦＡＴ３２は、ルートディレクトリもサブディレクトリと同じ構成なので、そういう意味では
　特別処理がないので解りやすい。
・FAT32には高速アクセス用のFSINFOという領域があるが、ここは全く参照しない。
　将来作るであろうフォーマッターでもそこは構築しない。面倒だからである。
　これがないとアクセス速度が微妙に落ちるらしいが、「Windowsマシンは遅ければハード交換」が
　原則なので（誤解？）気にしない。書き込みがない現状では全く関係ない。

さらに「こねこね場外編」。
・DVD-RAM 2.6Gと言えば松下／日立／東芝がドライブを作っている。松下と日立は自社販売で
　東芝のはメルコからのＯＥＭ販売のみである。
　私は仕事がら全てのドライブを全部Ｘ６８につないでみたが、一番性能が良いのは
　松下である（２.６Ｇ／４.７Ｇとも）。ドライブが持っているキャッシュの挙動がすばらしい。
　日立は遅いが問題とは言えない。しかし東芝は全く使い物にならない（すでに撤退した模様）。
　Windows上のドライバーにかなりの処理をまかせているのか、X68で使うと普通の読み書きすら
　まともに出来ない。買ってはいけない（棄てました）。
	SUSIE+DVDSUBでつながります
		松下2.6G/4.7Gドライブ
		日立2.6G
	全く使い物になりません
		メルコ（東芝）2.6G
　ちなみにメルコも現在は松下ドライブを使っているようなので問題無いだろう。
　（きっとクレームがたくさん来たんだろうなぁ。）

・最近はＨＤＤで２０Ｇを越える物も多いが、これらもおおよそＸ６８につながる。
　SUSIEは不要だが、GOVERHDは必須である。
　また、Human68Kは１ドライブ２Ｇまで、１装置全体で１６Ｇ領域までしかアクセス
　出来ないので、それ以上の部分は無駄になる。
　（正確には、先頭から１６Ｇ以内の領域にパーティションの先頭がくれば大丈夫。）
　従って、１パーティション２０００Ｍ（２Ｇではない）で切ると、９ドライブ
　＝１８０００Ｍまでは使える。
　
　そういえば、ＩＤＥのＨＤＤには１３７Ｇと言う壁があって、それ以上は
　いろいろと細工しないとWindows上でも正常認識されない（WindowsXPではレジストリを
　いじれば行けると聞いたが）。
　そういうＩＤＥドライブに対して現在有るＳＣＳＩ−ＩＤＥ変換ボードを使ってＳＣＳＩ化しても、
　やはり１３７Ｇ近辺までしか使えないことになる。
　そういうドライブに対応した変換ボードの登場は、もう少し先になるだろう。
　（これに関しては実はいろいろと知っているが書けないのが残念。^_^;）

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	うちの環境							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

現在、うちでは以下のような環境でWindows->X68のデータやりとりをしています。

X68030Compact
TwoSCSI+内蔵SCSI<---------------DVD-RAM2
       | ID=7			Panasonic
       |			LF-D100
       |			2.6G
       |			ID=5
       |
       +Mach2p<-->DVD-RAM1<---->MO<------------>HDD1<----------->HDD2
       	 ID=15	Panasonic	NEC		メルコ		 自作
		LF-D200相当	PC-OD302			 SCS-IDE変換ボード
		4.7G		230M		20G		 120G
		ID=12		ID=11		ID=8		 ID=9

HDD2はFAT32環境です。これを外してWindows機にSCSIに接続して書き込み、
また上記のように接続して読み出す、と言った感じです。

このＰＣ２台、従来はＦＤによるデータやりとりをしていたのですが面倒で、
特に大きなファイルのやりとりがファイル分割→結合が必要でいやになってました。
ＦＡＴ３２ツールが出来てからはわりと楽にデータやりとりが出来てます。

やはり、Ｘ６８を主にしてWindowsをサブにこき使うのが良い環境です。
それぞれのマシンに得手不得てはありますから、その特徴を活かして組み合わせるのが一番です。
何が何でもＸ６８だけと言うのは、もはや苦労以外の何物でもないと思うし、
Windowsだけとか言うのも私にとっては創造的でなくていやです。

現在のＨｕｍａｎ６８ＫはＦＡＴ１６なので１ドライブ２Ｇまで、
１ドライブ内では全体で１８Ｇ未満までしかアクセス出来ませんが
（だから２０Ｇ／３０Ｇドライブも全部を使えない）、
ＦＡＴ３２での書き込みが可能になれば、その全体を使えるようになって、
記憶容量が飛躍的に向上します。
ただ、その夢が実現されるまでにはまだだいぶ時間がかかりそうですが。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	あとがき							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

かなり複雑なので、まだまだどこかにバグが潜んでいるかも知れません。
間違い無くあります（自信を持ってどうする^^;）。
実害がないものは解ってるけど直してないものもあります（m(__)m）。

致命的バグを見つけた人はご連絡を。
でも、お約束だけど、何があっても「責任取って！」はなしね。

	「フリーソフトは使う側の責任で。」

あらかじめ言っておきますが、ＵＤＦを読めるツールを作る可能性は、
現時点ではまったくありません。要求しないように。
（英語のドキュメントしかないので、読めない。）

	・・・心苦しい話ではありますが・・・

開発に結構費用がかかっているので、気に入った方は
何がしかの寄付をして頂けるとありがたいのですが。
ＣＤ等が買える券とか図書券もいいかもしれません。
（ビール券はいりません。呑みませんので。^_^;）

もちろん強制はしません。感想だけでも十分励みにはなります。

御意志の有る方は、まずはメイルをお願いします。
この他に「こんなもんどう？」と言うのもお待ちしてます。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	作成環境							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

ＦＡＴ３２ツール群は次の環境で作成・動作チェックされました（敬称略）。

	X68030 Compact(25MHz/12M)		SHARP
	X68000 CompactXVI(16MHz/12Mor8M-Memory)	SHARP
	＋mach2p				満開製作所
	（メモリーボードが不調で時々認識しなくなる。求むメモリーボード。）

	X68000初代(10MHz/12M-Memory)		SHARP

	ARMADA1700 (P2-200MHz/64M-Memory)	Compaq
	＋CBSCII(UltraSCSIカード)		I/O DATA
	
	Human68K	V3.02		SHARP/Hudson
	COMMAND.x	v3.00		SHARP/Hudson
	
	HIOCS-plus	V16.13		SHARP/Y.Nakamura/立花えり子
	TwentyOne.sys	v1.36c14+p9 	Ｅｘｔ/GORRY/立花えり子
	
	TWOSCSI.X	V0.55		TNB製作所
	SCSITAI.SYS	V0.47		TNB製作所
	DVDSUB.X	V0.02		TNB製作所
	
	GCC		v1.36(?)	F.S.F/真理子
	HAS060		v3.09+87	Y.Nakamura/M.Kamada
	HLK evolution	v3.01+14	SALT/立花えり子
	
	ＷＳ		V0.90		Fuchi
	SuperED		v1.18＋		T.Nishikawa/AIG-Soft
	EDR-plus	v2.0.1		mipro

	FILES.X/FS.X/FMOVE.X
	/DUMP0.X/TYPE2.X/TREE2.X
	/ADEL.X				AIG-Soft
	ATTRIB.X			SHARP/Hudson
	FIM.X		V1.03A+t3+1	GORRY/ひで(TNB製作所)

	Windows関係は特にツールは使ってないので省略(^_^;)

	その他多くのソフトとハードたち。

各ソフトの開発者に感謝致します。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	参考文献							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

	VTwentyOneのソース,GORRY
		Unicode->SHIFT-JIS変換テーブル＆プログラムは
		ほぼそのまま使わせてもらってます。感謝。
		ただし、テーブルをプログラム内部に入れると大きくなりすぎるので
		外部に出しました。

	Windows95 OSR2の秘密,ナツメ社,吉野敏也
		結構参考になりますが、
		ロングファイル名辺り等の記述には間違い（というか解析不足）もあります。
		（それと気づけるには相当調べなきゃいけないけど。）
		ＶＦＡＴの処理はこれを参考に作ったので、VTwentyOneは全く見てません。

	Interface 2001/7号,ＣＱ出版
		良い記事なのですが、パーティション周りの記載がはしょられているのが残念。
		著者の名前の中に、昔Oh!Xで見たことの有るような名前があるのは気の性？

	Windows95に隠されたファイルとフォルダの秘密,ナツメ社,吉野敏也
	続Windows95に隠されたＤＯＳの秘密,ナツメ社,吉野敏也
	Windows98に隠されたＤＯＳの秘密,ナツメ社,吉野敏也
	MS-DOSエンサイクロペディア１,ASC出版

	ＭＳＤＮの情報,Microsoft
		ほとんど英語の上に、やっぱり情報が足りないのが難点。
		相対セクターなんか、絶対セクターなんかどっちや！！とか。

	XC V2.1 NewKit	Ｃライブラリマニュアル２／プログラマーズマニュアル,SHARP
	ぷにぐらま〜ずまにゅある 第六版  第五刷,立花えり子

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
