┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃		ＡＳＫ３/codeA対応　アクセサリシリーズ５		      ┃
┃			「ＤｉｃＢｕｓｈｕ」				      ┃
┃		 Copyright (C) 1998-99 by AIG-Soft			      ┃
┃		 Original      1992 by ACCESS CO.,LTD.			      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	歴史								      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

１９９８／６／２９〜７／１
	codeA.sys（ＦＤＳ氏）でアクセサリの上限を１０からもっと多くに増やして
	いただけそうな話になった。しかし、私の現在持っているアクセサリは１３しかない。
	ここは一発アクセサリを作って増やすのが良いであろう。

	ということではあるが、なかなかネタを探すのは難しい。
	いや、ネタはあるにはあるのだが、直ぐに開発に移れるものはない。
	基礎技術開発すら済んでないものがほとんどなのだ。

	そこで、安直にＸＣ ＮｅｗＫｉｔにサンプルで付いていたアクセサリを改良
	することにする。
	でも、あの中で実用化して価値がありそうなものは部首辞書位である。
	他はすでに別途作ったか、余り使わないと思う。

	ということで、そのソースを元に改良を加える。
	オリジナルの小手先改良ではおもしろくないので、大胆な改良を目標とする。
	主な変更点は次の通り（この日時点での目標ではなく、最終的な変更）。

	本体	インデックス構造を全面変更。実行時ワークエリアサイズを大幅に減らす。
			（＝常駐サイズも減るということ）
		.xタイプの常駐プログラムに変更
		キー操作の（大幅）変更
		前後候補群があるのをわかりやすくする
		前後候補群へ直ぐ移動するキーを付ける
		画数で直接ジャンプするキーを付ける
		部首の画数を常に表示する
		部首の画数による検索を可能とする
		オリジナルのバグらしき部分も修正

	辞書	第１水準漢字対応！！（見た目変換を重視したので、全て正しくはない。）
		部首名を一般的なものに変更
		（「ざとへん->こざとへん」とか「にくのぶ->にくづき」とか）
		部首名にシンボル漢字を入れてわかりやすくする
		間違えやすい画数のものを参照可能にする
		旧漢字を99画に追加（というより、他と一体になっていたのを分離）
			さらに、旧漢字を解るだけ追加
		ＷＯＲＤ ＰＯＷＥＲで確認（ＷＯＲＤ ＰＯＷＥＲの方が間違ってた^^;）

１９９８／７／２
	本体は何とか動くようになった。
	問題は辞書である。
	
	今まで私が見た数々の部首辞書の中に、ＪＩＳ第１水準をサポートしたものはなかった。
	あのＷＯＲＤ ＰＯＷＥＲですらサポートしてない。
	もちろん、もともとあるサンプルの部首辞書も第２水準のみである。
	その理由は簡単。ＪＩＳ第１水準漢字はＲＯＭ中で部首毎に並んでないから。
	第２水準は並んでる。誰も、並んでいない第１水準を並べる苦労をしなかったのであろう。
	不思議と言えば不思議だが、そんなもんかも知れない。
	（ただ、ＷＯＲＤ ＰＯＷＥＲ中の部首分類は、ＲＯＭから単純に切り出したものでは
	なさそうである。そのあたり、ＷＯＲＤ ＰＯＷＥＲ作成への力の入れ方が並ではない
	ように思える。当時のＳＨＡＲＰには・・・以下省略。）

	第２水準漢字は難しいので部首毎に並んでいるというのはいいのだが、
	第１水準だって読めない漢字はある。そういう時、いつも「部首毎になっていれば・・・」
	と思ったものだった。

	そこで、無職で時間がある「私」が苦労することにしたのである。
	（本当は就職活動で忙しいはずなのだが・・・。）

	んが、口で言うほど楽な作業ではなかった（むちゃくちゃ大変だった！！）。
	もちろんサポートプログラムを作って分類したわけだが、分類そのものは自動化
	出来ないので、人間が１つ１つ見てやるわけだし、ぱっと見でどの部首か解らない
	文字も多い。そういう時は漢和辞典で調べるしかない。それが３０５９文字もある
	のだから大変であった（ＪＩＳ第１水準の漢字数。非漢字は入れてない）。
	とにかくぱっと見で分類してるから、間違って分類している漢字もたぶん、いや絶対ある。
	一応間違いに気が付いた漢字に関しては、正解と間違いと両方で登録した。
	だって、同じ間違いをする人は必ずいるはずだ（か？）。
	よし、これを「見た目変換」と名付けよう。

	・・・あっ、ゲイツ９５のＩＭＥ９７の漢字辞典（文字コード表ではない）は
	第１水準までサポートしているぞ。くそぉ、ゲイツに先を越されるとは。これで
	日本初！！の栄誉は逃したわけか(^_^;)。変換は何な部分もあるがＩＭＥ９７、
	並の出来ではないと見た。
	ちなみに、これには頼ってまへん。全て自分の感と漢和辞典で分類しました。

	でもでも、見た目変換サポートはまだ誰もやってないだろうから、私が日本初＝世界初
	だろうな！

１９９８／７／６
	やっと第１水準の分類完了。
	勢いに乗って、第２水準も「見た目変換」サポートのため分類開始。
	こちらは４５４４字（足らず。途中飛んでるコードがあるから）。
	まあ、こちらはもともと部首別に並んでいるので、見た目部分の登録だから楽だと思う。

	本体も改良
		画数検索を付ける
		次候補群がないのに > が出ることがあるのを修正
		オリジナルの謎のバグを修正

１９９８／７／７
	就職内定！！
	これで一安心

１９９８／７／１０
	ええい、ＡＳＫのコード入力はなんでシフトＪＩＳがデフォルトとちゃうんじゃい。
	毎回切り替えるのめんどうやんけ。
	・・・ということで、ＡＳＫＡｃｃにコード入力を付けてしまう(V1.2)。
	
	やっと第２水準も分類完了。
	
	これでだいぶ漢字に詳しくなったな(^_^;)。
	成果はnan.txtを見てもらえば、単純でなかったことが解っていただけるはず。
	それにしても、漢字の難しいこと。
	これに比べれば英語なんていかに簡単なものか（大胆発言）。


１９９８／７／１１	Ｖ１.０（公開->回収）
	やっと発表。
	プログラムよりデータ作成に時間をかけたのは初めてじゃないか？

	サポートプログラム（Ksel）？
	一応それなりの出来だけど、やっぱり私が使うことを前提に作ってあるから、
	細かいところは手が抜いてあるので今回は発表しない。
	私の行った分類が気に入らない場合もあろうから、ユーザーで変更出来るように
	発表するという考えもある。まぁ、いずれにせよ、この本体への感想次第である。
	ちなみに、このプログラムの方がDicBushuよりずっ〜と大きい。

１９９８／７／１１	Ｖ１.１（公開）
	いつもの癖で発表日に改訂。
	というか、なんかむちゃくちゃでまともに動いていないことに気が付いた。
	一体いつからこんなふうになってたのだ？

	どうも、辞書の１行が特定の条件を満たした時におかしくなっていたようである。
	もちろんそれは、辞書が文字登録増加で巨大化したせいもある。
	発表直前バージョンの辞書までは動いていたので気付くのが遅れてしまった。
	同じ辞書を使うKselでは正常動作していたために、発見が遅れた。
	ただ、修正のためにファイルの読み込み方法を変えたので、遅い処理がさらに
	遅くなったかも知れない。

	・俗字直接ジャンプ機能追加
	・１１〜１９画の漢字は直接ジャンプにメインキーしか使えなかったので
	　テンキーも使えるようにする。さらにOPT.1キーも可能に。
	　これでサポートプログラム Ksel と同じキー操作になった。
	・辞書内に空行があるとそこで読み込みが止まっていたのを修正
	　（ドキュメント通りコメント扱いにする。）
	・画数ジャンプの大幅高速化

１９９８／７／１３
	感想をいただく。
	参照部首というのがわかりにくいようである。
	ということで、参照部首でCR/ENTERしたら本来の部首へ飛ぶようにする。
	このルーチンを作っている時に、「ネ示しめすへん」のサーチが出来ないことに
	気が付いたので修正。

	参照部首についてnan.txtに書いてたら、革かわへんの参照が間違ってるのを発見。
	もちろん修正。

	部首名サーチを前方一致比較にする。要するに、サーチ指定文字列部分だけでも
	一致すれば「あった」とする。今までは完全一致であった。
	この方が入力が楽だから。

	ＧＣＣの吐き出すソースを少しだけ最適化。やはりＣでの書き方に問題があるのか、
	ＧＣＣの最適化が甘すぎる。変数の型をおもいっきりこまめに設定するとか、
	グローバル変数は一旦ローカル変数にコピーしてから操作するとかしないと
	うまく最適化されないようだ。intの使いすぎも注意か。

１９９８／７／１５	Ｖ１.２
	バージョン番号を変えずにさらに変更

	毎回シーク表を作るのは無駄なので、辞書が変更されていない限り
	前の情報を使うようにして起動を高速化する。
	変更されたと判断するのは次ぎの内いずれかがあった時。
		１、ファイル作成日付が変わった
		２、ファイルサイズが変わった
		３、一度でもファイルがオープン出来なかった

	高速化されるのは良いけど、サイズがどんどん増えるのが困ったなぁ。
	やはりフルアセンブラー化する必要があるか？（でもエンバグするのが恐い。）

１９９８／７／２６	Ｖ１.３
	DicExの不具合報告から、DicBushuも辞書テキストの最後にEOFがなくてもいいようにする。

	この修正をしていて、どうにも暴走が止まらないので調べていったら、
	辞書の内容がない＝totalblocks=0の時に暴走することが解った。
	さらに、テキスト内に空行があるとそこで読み込みが止まるし、
	エラー処理が一応書いてあったのにもかかわらず、まったく動いてなかった。
	このような２重３重のバグが有ったのが、全部修正。

１９９９／１／１０
	某所からDisk-Pekinというものを入手。
	その中にＡＳＲ氏の移植したsedの中に新旧漢字変換スクリプトがあるのを発見。
	DicBushuで私が調べ上げたもの以外の多くの新旧漢字があるので足りない部分を
	そこから拝借することにした。
	氏には連絡が付けられないが、もし知っている方がいればお伝え願いたい。
	（ＰＤＳ扱いになっているので勝手に使っても良いとは思うが。）

	ということで、辞書Bushu.dicだけ更新。

１９９９／２／９
	久々に感想をもらう。
	「最初の起動が遅い」・・・やっぱりそうか。
	なんとかならんかな？

１９９９／２／２３
	いろいろな手法を考えたけど、結局辞書をあらかじめバイナリ化しておくことが
	一番ということになった。
	ということで、コンバーター作成と本体のそれへの対応を入れる
	・・・つもりだけど、最近プログラムを見てないからどこを直したらいいか解らん(^_^;)。
	しばらく時間がかかりそう。

	辞書全体をバイナリ化するのはプログラムの修正が大きいので止め。
	オフセットテーブルという物のみ外部に出すことにする。
	でも初期起動で時間がかかるのはそれだから、これで十分。
	ファイルが２本だてになるのがよろしくないかも。
	一応テキストファイルの修正をチェックしているので、
	テキストを修正した後でオフセットテーブルを作り直してない時は起動出来なくなる。

	コンバーターはＣだけでいいから簡単だけど、本体の変更が大変だなぁ．
	Ｃ→アセンブラーでやってるから。

１９９９／２／末
	本業が忙しいのと、気力が涌かないのと、腕が痛いなどの事情により
	プログラム開発がぜんぜん進まない。

１９９９／３／２
	やっぱり辞書全体をバイナリ化する。
	ファイルが２本だてになるのはよろしくない。
	ついでに他の処理も高速化されるようにバイナリ化の時点で処理する。

１９９９／３／６
	FDSさんのcodeA v0.07対応の辞書を作る。辞書回りが大幅に改良されたので
	今まで出来なかったことが出来てよろしい。変換効率も「少し」上がる。

１９９９／３／７
	ひょっとするとＳ社のゲーム機Ｓのソフトが安くなっているかも知れないと思い
	日本橋へ行って一気に４本購入。
	（結局、あまり安くはなってないのね。たぶん。）

	おもしろいゲーム		ちょっと期待はずれのゲーム
		Lunar/サクラ大戦		GRANDIA/だいな・あいらん

	期待はずれと書いたゲームもまだ最初しかやってないので、やりこめば評価が上がる
	可能性は有り。Lunarは２を先にやったけど、１もいいぞ。
	有名じゃ無くてもおもしろい物はおもしろい。ＦＦははたしてどうか？
	・・・あぁ、DicBushuの改良が一向に進まない(^_^;)。

１９９９／３／８
	コンバーターのバグがようやく採れた。

１９９９／３／９〜１０
	本体の対応は案外簡単に終わった。
	しかし、Ｃ版は動くのにアセンブラーでやると暴走する。
	「割り込みが登録されていません」とはどういうことだ？
		１、スタックの使いすぎ
		２、最適化のミス
		３、辞書読み込み時にワークを破壊
	さて原因はどれだ。

１９９９／３／１１
	謎の暴走に悩まされる。
	会社にいる間には原因が解らなかったが、帰りの電車の中で唐突に原因が解った。
	答は３に近いが、
	　４、常駐前に使っては行けないワークを使ったためにプログラムが書き換わっていた
	である。

	ということで、ワークを常駐部分に持ってくることで解決。
	さらに、ワークの移動でワード境界の問題も発生していたので修正。
	ファイルサイズは大きく増える、常駐サイズは変わらないので大丈夫。

	どうも、いつも使っているエラー表示拡張プログラム
	(TRAP14 DRIVER Ver0.11 (C)1993 ISAAK/1998 AIG-Soft)がおかしいような気がする。
	そのうちちゃんと見る必要があるか。
	どこかにエラー時の詳細を表示するものはないか？（ROM-DBで見るというのは却下。）

１９９９／３／１２
	検索を使うとうまく起動出来るのに、使わないで起動するとおかしいというバグが出る。
	辞書読み込み部分が大幅に変わった時に検索機能あたりの変更が出来てなかったためだ。
	検索有り／無しで大幅に処理を変えることで対応。

	ようやく動くようになった。
	今回は機能の追加は無し。
	まあ、起動時間が大幅に速くなっただけでも良しとしよう（本当に速いぞ）。
	速いので「辞書読み込み中」のメッセージも不要になったので外した。
	起動だけでなく、検索や部首送りも微妙に速くなったはず。
	サイズは、ファイル的には大きくなるが常駐サイズはわずかに減る。

	ＥＸ６８チェックを入れる。
	ＥＸ６８に関しては従来肯定的であったが、最近一応の環境を構築して
	いろいろと動作させてみた結果、PANIC関係がだめだったのと、ASK回りのキー再現が、
	その実際の配置も含めて納得いかなかった。
	そこで、DicBushuでは試験的にEX68チェッカーを入れ、それの上では動作しない、
	というか組み込めないようにした。
	将来EX68がより良くなるとかすれば、外す可能性はある。
	しかし、ゲイツマシンで・・・（以下削除）
	チェックの仕方は秘密（一応独自開発）。

	あれ、旧漢字が使えなくなっているぞ。
	本体のミスか、辞書コンバートのミスか？
	・・・原因は辞書コンバート中の行数カウントの部分であった。
	エラーチェック強化のために行カウント処理を変えたのが不十分であった。
	
	これで完成。

１９９９／３／１３	Ｖ２.０

１９９９／３／１７	Ｖ２.０a
	各種メッセージをDicYu7にあわせただけ。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	技術的な話	（漢字やプログラム内部に興味の無い人は飛ばそう！）    ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

	・・・漢字の話・・・

漢字のフォントだけど、正しい部首の形からすれば、正しくない形をもつものも結構ある
ことがわかった。

	区	匠

この２つ、フォント上は回りの部分の形が同じだけど、実際には

	匸	かくしがまえ
	匚	はこがまえ

というように微妙に違う。余り漢字に詳しくない人がフォントを「デザインだけから」
作った、と見た。
さらに、$e0ac=牀なんて、１６ドットフォントと２４ドットフォントで部首の形が大きく違う。
最初悩んでしまった。

また、ＪＩＳの漢字表が間違っているものまで発見。

	雙	この字、ＪＩＳでは「又のぶ」に入っているけど、実は、
		隹「ふるとり」である。

	飮	この字、ＪＩＳでは「欠あくびのへん」に入っているけど、実は、
		「飲」の旧漢字であって、「食しょくへん」である。

	飜	この字、ＪＩＳでは「羽はねのぶ」に入っているけど、実は、
		「飛とぶのぶ」である。

----------------------------------------------------------------

そうそう、使っている辞書が古いのか、漢字の形が違うのか、無い漢字もある。
わざわざこのためだけに辞書買うわけにもいかないし、感で分類した。
まあ、「見た目変換」するには問題ない。
・・・そうか、「見た目変換」にはこういう逃げ道もあったか。

どうせ見た目変換だから、今後は、実際にはない部首も設定してより牽きやすくするのも
一手かもしれないなぁ。それと部首を限定して全てそれに入れてしまうか。
これは部首辞書本体の２つ位持たせると出来るか？いずれにしても、またデータを作るのが
大変なので、先送り。
（これでも、見た目部首の登録は何度も見直している。）

あのゲイツ漢字辞典でもＪＩＳの間違いを発見するほどではなかろう。
ふっ、勝ったな V(^-^)。

	・・・プログラムの話・・・

オリジナルのプログラムは構造を単純にするためか、インデックスの取り方が
非常に豪快であった。そのため、実行時には１３.５Ｋものメモリーを必要としていた。

Ｘ６８だから大したメモリー量でないといえばそうだし、そのまま発表しても良かった
のだが、やはり８ビット時代からのプログラマーに取っては、こんなに大きな常駐サイズ
は許せなかったので、インデックス構造を大幅に見直して５Ｋにまでに減らした。
しかも、機能の大幅追加＋速度も上げて、である。

ソースレベルでもかなり注意したので、それほど読にくくななっていないだろう。
ただし、アセンブラーレベルではＧＣＣの出したコードほとんどそのままなので、
Ｃで追った方が良い。

それにしてもＧＣＣの吐き出すコードは甘い。その吐き出すコードの特性を十分知って
書くようにしないとアセンブラーで書くには及ばない。しかし、いちいちそれを考慮して
書いていては、Ｃを使う意味が半減する。困ったもんである。

とりあえず、今回追って見て解ったのは、
	１、グローバル変数を連続で操作する時は一旦ローカル変数にコピーした方が良い
	２、変数の型は正確に決めた方が良い(intを多用しない)
	３、ループ変数や配列の要素指定変数はintが良い
というところか。ワークエリアサイズがword範囲なら.wで処理してくれるとか、
そういう最適化があるとＧＣＣも良くなるのだが（ＧＣＣ２ならなっているのか？）。

	・・・ああ無情(^_^;)・・・

これはDicBushu V1.3を完成させてからずっと後にわかったこと。
ＪＩＳ規格表を見る機会があったのでとあるページを見ると・・・
がーん！！「字形索引」などがあるではないか。

	JIS X0208-1990 情報交換用漢字符号
	（ＪＩＳハンドブック 情報処理 用語・データコード編-１９９５,日本規格協会）

にそれがあった。なかなか良く区分されているぞ(T_T)。

それを使えばもっと楽に出来ただろうけど、まあ漢字の勉強にもなったからいいか。
DicBushuの辞書は完全オリジナルのもので、ＪＩＳとはまったく関係ありません。
ＪＩＳ規格のがほしい人は自分で辞書を作ってね（１漢字に２つの部首を設定できるので
ＪＩＳの分類にも対応できます。すごいぞ！）。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	部首辞書テキストについて					      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

[部首辞書テキストの構造]

部首辞書は、次の構造を持つテキストファイルをDicBuCnvでバイナリに変換したものである。

	画数,部首読み,対象漢字群[改行]

このテキストファイルのうち、旧漢字＆俗字以外は基本的にサポートツールKselで作成するので、
ユーザーが直接これを編集するのは好ましくないが、
サポートツールを発表していない現在、変更はテキスト上で行うしかない。

行の入れ換えをしてはいけない（この行順でサポートツールKselのデータが記録されているから）。
新しい画を追加する時はその画群の一番最後に入れる（参照部首の前）。

画数は１０進数字で１〜３２まで。９８画は俗字、９９画は旧漢字に使う。
（ただし、キー操作で一発画数ジャンプができるのは１〜１９と９９だけ。）
同じ画数の部首が何行有ってもよいが、同じ画数毎にまとめること。
０画は使えない。

１部首読みで１行のみ。
部首読みは先頭に代表漢字を入れて、全角文字のみで１６文字まで。
代表漢字は通常１文字だが、２文字以上でも良い。
代表漢字部分には、片仮名／漢字が使える
ただし、変換ラインに正常に表示されるのは８文字まで。

他の画の部首を参照で記述する時は、漢字の１文字目に'→'を記述すること。
	「例」3,忖りっしんべん,→４画

１行は画数、部首読み、対象漢字群および改行／セパレーターを含め1024バイトまで。
（対象漢字分にして、おおよそ４８０字まで。それ以上はエラー。）
行数は全部で２５６行以内でなければならない。
（２５６行以上はエラー。）

旧漢字は画数99で一番最後に記述し、俗字は画数98で旧漢字の前に記述すること。
この２つに関してはサポートツールKselの対象外なので追加変更はテキスト上で行うしかない。

部首名、代表漢字も変更して良いが、部首名を変更した時は、
参照部首名も変更しないと、参照がうまく出来なくなる。

空行および';'で始まる行はコメント行として無視される。
辞書ファイルの最後にEOFコード（$1a）はなくても構わないが、
改行無しでEOFが来た場合、その行は無視される。

「例」
	99,旧きゅうかんじ,隠隱発發将將潜潛[EOF] ... この行は無視される
		↓
	99,旧きゅうかんじ,隠隱発發将將潜潛      ... 行末は必ず改行にする
	[EOF]

＊＊外字について
外字は各ユーザー毎に異なるので、あらかじめ設定はしていない。
必要であれば、上記の書式に従って追加する。

詳しくは添付の部首辞書テキストファイル(Bushu.txt)を参照のこと。

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

それにしても、私の作ったアクセサリもだいぶ溜まった。
細かいものも含めると、１９。
まさかＡＳＫ３のアクセサリ上限１０を越えることがあろうとは。

その数を大幅に増やしてくれたcodeA.sys、ＦＤＳ氏に感謝。
これで、思い残すこと無く（？）アクセサリ作りに性を出せます。

	・・・

いつものことですが、キーの配置などは私の趣味です。変更出来ません(^_^;)。
（私は普段ENV3.ASKをちょっとだけ変えたものを使っています。）
どうしてもしたい人は、ソースを直して下さい。

V2.0では大幅に書き替えたのでまだどこかにバグが潜んでいるかも知れません。
何か見つけた人はご連絡を。
でも、お約束だけど、何があっても「責任取って！」はなしね。

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

さて、次回は何を作ろうか。

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

ＤｉｃＢｕｓｈｕは次の環境で作成・動作チェックされました。（敬称略）

	X68030 (25MHz/12M-Memory/FPU)
	X68000 CompactXVI-1(10,16MHz/10M-Memory)
	X68000 CompactXVI-2(10,16MHz/ 4M-Memory)
	DynaBook EZ486(i486 25MHz,/10M-Memory) ... ソース・ドキュメントの編集一部だけ
	
	Human68K	V3.02		SHARP/Hudson
	COMMAND.x	v3.00		SHARP/Hudson
	ASK68K.SYS	V3.02		SHARP/ACCESS Co.LTD.
	codeA.SYS	V0.07		FDS/SHARP/ACCESS Co.LTD.
	
	HIOCS-plus	v16.11		SHARP/Y.Nakamura/立花えり子
	TwentyOne.sys	v1.36c14+p5 	Ｅｘｔ/GORRY/立花えり子
	
	GCC		based on 1.42	F.S.F/真理子
	HAS060		v3.09+79	Y.Nakamura/M.Kamada
	HLK		v3.01+11	SALT/立花えり子
	
	ＷＳ		V0.90		Fuchi
	SuperED		v1.18		T.Nishikawa
	
	漢字分類サポートツール
	Ksel		v2.8		AIG-Soft
	XC 		v2.1 NewKit	SHARP/Hudson
	
	WPower3c.dic	V1.4		SHARP/AIG-Soft
	単漢字c.dic	-----		ｼﾞｬｽﾄｼｽﾃﾑ/AIG-Soft
	
	EX68一式	V1.06		yamama
	Compaq ARMADA1700(Pentium2-266MHz/64M-Memory) ... EX68チェック用
	しかし、クロックだけで見るならX68 10MHzの26倍速いマシンでも
	グラフィック回りを完全に再現出来ないとは。X68のグラフィック回りの
	すごさを再確認。
	
	その他多くのソフトたち。

特に、ASKはV3.02/codeAはV0.07でのみ確認しています。
ASKのV3.00,3.01では動作するかどうかは未確認です。

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

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

	XC V2.1 NewKit	拡張マニュアル,SHARP
		ＡＳＫ３アクセサリについて

	XC V2.1 NewKit	Ｃライブラリマニュアル／プログラマーズマニュアル,SHARP
	  ・・・まあ、プログラムを組むなら当然か。

	ぷにぐらま〜ずまにゅある 第五版  第四刷,立花えり子
		やはりオンラインマニュアルはいざという時に役に立ちます。

	Ｘ６８０３０ 日本語入力・辞書ユティリティー ユーザーズマニュアル,SHARP
		漢字分類について

	ＢＪ−２２０ＪＳ／ＪＣリファレンスガイド,Canon
		漢字分類について（ＪＩＳの間違いを確認するため）

	新選 漢和辞典 新版,昭和５２年,小林信明編,小学館
		部首名はこれに従って変更した部分があります
		もうこれも古い辞書なのか、ＪＩＳ漢字が載ってないものもある。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
	最近は、漢字を見ると部首を考えてしまう・・・
