オイラのスットコドッコイな落とし穴で思わぬ回り道をしてしまったが
うっちゃんのおかげでやっとすこし戻ってこれた・・・

さて！
そうなると、再びお勉強の本筋に！
そう。現時点でイマイチ理解ができていない、「割り込み状態取得」である！

えーーーっと・・・・例のここに書いてあるこれかなぁ・・・

• SEEK系のコマンドの実行が完了すると、割り込みでCPUに知らせてくる。CPUはExecution-Phaseでないときに割り込みを受け取ったら、速やかにSENSE INT STATUSで応じなければならない。これでST0をチェックして、状態遷移割り込みなのか、それともSEEK系の終了割り込みなのかを判断する。
  
• 結局、SEEK系のコマンドは、SEEK終了を知らせる割り込みにCPUがSENSE INT STATUSで応じてST0とPCNをリードしおわった時点で、コマンドの実行が完了する（＝やっとこのドライブ対して次のコマンドが発行可能になる）。
  

・・・よくわからないなぁ・・・
こういうことなのかな？？？

• 割り込みには二種類ある。
  
• 状態遷移割り込みとSEEK系終了割り込み
  
• 割り込みが来た場合、その時点ではこの両者は区別できない
  
• なので、割り込むが来たらすぐに[08]コマンドを発行してST0やCを読む必要がある
  
• 帰ってきた[08]のリザルトにより、どっちの割り込みか判断できる
  
• それがSEEK系終了の割り込みだったら一仕事終了。リザルトを受け取る作業に入る
  
• ・・・では、状態遷移割り込みだったら？？
  

そもそも、状態遷移割り込みとはどういう状況下で発生するのだろう？？？

たとえばだが、ヘッドを10シリンダにシークしたいとする。

　　　　　いろいろチェック（ステータスとかそういうの）

　　　　　　　　　　　　　↓

　　　　　　10Cにシークしろ！と命令（コマンド発行）

　　　　　　　　　　　　　↓

　　　　　　命令を受け取ったFDCは動作開始（時間がかかる）

　　　　　　　　　　　　　↓

　　　　FDC曰く、「できたよーー！」とお返事。（これがIRQ6の割り込み）

　　　　　　　　　　　　　↓

　　　　　待ってたホイ！SEEKが終わったことが解った！

　　　　　　　　　　　　　↓

　　　　リザルトを取得し、本当にできてるかどうかチェック！

　　　　　　　　　　　　　↓

　　　　　OKOK!　大丈夫みたいね。じゃ、次の指令をば・・・

この流れの中で、状態遷移割り込みという、SEEK終了ではない割り込みが来る！？？
いったいなぜ？　なんのために？？


・・・な〜んて書いて、ちょっと一休みしてたら再び勇者うっちゃんが！！　（＾＾

なるほどぉ！つまりこういうことなのかな？

• 状態遷移割り込みとは本来はディスクの抜き差しを検出して発生する割り込みである
  
• 割り込みは仕組み的にパラメータを持たせることができない。とにかく、「発生したぞ！」とだけ知らせることしかできない
  
• そのため、割り込みが発生したらそれがSEEK終了なのかディスク抜き差しなのかを判断しなければいけない
  
• そのため、FDC側では割り込みを発生させると同時に、「これはxxx割り込みだよ！」ということをレジスタに書き留めておくという動作をする。
  
• ゆえに、プログラム側では割り込みが発生したら、仮にどっちの割り込みかを知りたくなくても「読み出す」という作業をしなくてはならない。（一連の動作のひとつとして組み込まれている手順？）
  
• しかし、ディスクが動作（SEEK）している最中にディスクの抜き差しなど、普通発生するだろうか？
  
• おそらく、「複数ドライブ対応ゆえ」なのだろう。
  
• いまでこそ、AT互換機のFDは一基が当然だが、このFDCは能力として4台のドライブまで対応できる設計である。また、別にAT互換機用というものではない汎用的なものだ。
  
• ディスクが複数台搭載されているような機械なら、当然A:ドライブで読み込みをしている最中にB:ドライブを抜くなどということは普通に発生が予想されるのだから。
  
• ・・・しかし、現実問題として、うっちゃんが示してくれたページを読む限りでは、どうもこの便利な割り込みはAT互換機上では殺されているようである。
  
• ・・・っということは、少なくともATでは、事実上状態遷移割り込みは発生しない・ありえないという理解でいいのだろうか？
  
• ありえないが、とにかくこのFDCでは割り込みの後、[08]を発行してリザルトを2個取得しなくてはいけない。この手続きそのものまで殺されているわけではないという理解でいいのだろうか？
  

ニョニョニョ〜〜〜！！
うっちゃんが須原歯科ヒントを！！

え！？　まってまって？　じゃ、いままでのwhileでひっかかるのもこれ？
その後のwhileも？　じゃ、whileをみんなこのパターンにしてみると？？？

・・・
・・・・・・
・・・・・・・・・
キタ━━━━━━(゜∀゜)━━━━━━ !!!!!

いや〜・・・
我ながらこんなことも知らんで「OS作成」してるとは・・・

うっちゃんスマソ。ほんと感謝。わざわざURLまで。勉強しまする。

え”えぇぇぇぇぇ！？？

なんかヘンだよ？　おかしいよ？
こんどはこんなことしてみたんだけど

	    //	    while ( io_in8(0x03f4) & 0x10 != 0 ) {}

	    char aa;

	    	    for (;;)

	    	      {

			aa = io_in8(0x03f4);

	    		if ( aa & 0x10 == 0 )

	    		  {break;}

			else

			  {

		sprintf(s, "aa=%08x,%08x",aa,aa & 0x10);

		putfonts8_asc_sht(sheet,8*20,16*2,COL8_008484,COL8_FFFFFF,s,20);



			  }

	    	      }

このforを抜け出せない！？
値はちゃんと、「aa=FFFFFF81,00000000」って出てるのに・・・０なのに・・・
ヽ（ `Д´）ノ

例の「ひっかかり」の場所。
逆に場所が特定できているんだから、その時のステータスレジスタ(0x03f4）
の値がなにで、どういう状態なのかがこれで読み取れるかもしれない。

	    //割り込み状態取得

	    char aa;

	    aa = io_in8(0x03f4);

	    while(aa & 0x10 != 0x00 )　　//←このwhileから抜け出せない

	      {

		aa = io_in8(0x03f4);

		sprintf(s, "aa=%08x",aa);

		putfonts8_asc_sht(sheet,8*20,16*2,COL8_008484,COL8_FFFFFF,s,11);

	      }

こんなことして値を表示させてみたら「0x81」と表示された・・・

さて。0x81ってのはどういう状態なんだろう？。オベンキョしたことを踏まえて・・・

0x81すなわち10000001b。むむむうぅぅ？？？

• ドライブ#0動作中
  
• ドライブ#1非動作中
  
• ドライブ#2非動作中
  
• ドライブ#3非動作中
  
• FDCはIdle-Phaseである
  
• DMAモード？
  
• データレジスタの書き込み待ちモード
  
• データレジスタは準備完了だ！ドンと来い！
  

なるほどなるほど・・・・・って、え”

& 0x10　==　0　の待ちなんだから、bit4だけが0ならとりあえずは
ここは通過できるはず。なんで？　なんで通過しないの！？？

大マヌケをこいてしまったが、な〜に！いつものことさ！　　orz

●コマンド発行前待ち
io_in8(0x03f4) & 0x11 の値が0になるのを待ちます
0x11すなわち00010001bによる摘出。bit0とbit4摘出ね。
・ドライブ#0が非動作中（bit0)
・FDCがidle-Phaseである(bit4)

ふむ！納得！　理屈どおりだよね？
（・・・でも、bit6やbit7は関係ないのかな？？？）

●コマンド[08]発行前待ち
io_in8(0x03f4) & 0x10 の値が0になるのを待ちます
0x10すなわち00010000bによる摘出。bit4のみかぁ・・・
・FDCがidle-Phaseである(bit4)

ん？っていうことは、仮にドライブ#0が動作中であってもいい。
もしくはどっちでもいいということかな？？？

●個々のコマンド送信前待ち
io_in8(0x03f4) & 0xc0 が 0x80 になるのを待つ
0xc0すなわち11000000bによる摘出。bit7とbit6ね。
さらにこれらが0x80なんだから10000000b。bit7が1で、かつ、bit6が0だと。
・データレジスタの準備ができている。いつでも来い！(bit7)
・書き込み待ちの状態(bit6)

・・・なっるほどぉ・・・。bit7やbit6はさっきは無視されたんじゃ
なくて、個別に別々に検査されるわけね。

●個々のリザルトの受信待ち
io_in8(0x03f4) & 0xc0 が 0xc0 になるのを待つ
0xc0すなわち11000000bによる摘出。bit7とbit6ね。
さらにこれらが0xc0なんだから11000000b。bit7、bit6共に1でいてほしいと。
・データレジスタの準備ができている。いつでも来い！(bit7)
・読まれ待ちの状態(bit6)

おおおおお！！　なるほど！　なんか理屈通りだ！　よく解る!

・・・あれ？　でも、ちょっと疑問があるなぁ。
リザルト受信を開始する前のチェックというか・・・「コマンド発行前待ち」みたいなチェックってないのかなぁ？？？

たとえばだけど、
●リザルト発行前待ち
io_in8(0x03f4) & 0x11 の値が0x10になるのを待ちます
0x11すなわち00010001bによる摘出。bit0とbit4摘出ね。
・ドライブ#0が非動作中（bit0)　・・・これはいらないかな？
・FDCがidle-Phase以外(Result-Phase）である(bit4)　

とか・・・・

うーむ。どうもわからない。
ここで新しくいろいろと勉強してみたんだけど、いつものところに
まず io_in8(0x03f4) & 0x11 の値が0になるのを待ちます
とある。0x11すなわち00010001bでのAND演算。bit3とbit7の摘出となる。
しかし、資料によるとbit3はドライブ#3の動作状況を示すようだ。
bit0(ドライブ#0）ならまだわかるのだが・・・
また逆に、bit4が検査されていない理由がよくわからない。なんか
これは検査すべき部分のような気がしてならない。

他のものはどうだろうか・・・

●コマンド[08]発行時
io_in8(0x03f4) & 0x10 ==0を待つ。
これはええと・・・
やはりbit3だなぁ。

●コマンド送信待ち
io_in8(0x03f4) & 0xc0 が 0x80 になるのを待つ
bit0とbit1を摘出。その結果が0x80すなわち10000000bであってほしいと。
ドライブ#0が動作中で、かつドライブ#1は非動作中という状態を待っている・・・えぇ？

●リザルト受信前
io_in8(0x03f4) & 0xc0 が 0xc0 になるのを待つ
同じくbit0とbit1の摘出。0xc0すなわち11000000b待ち。
ドライブ#0とドライブ#1両方の動作状態を待つ・・・

・・・おっかしい！　どう考えてもこれはおかしい！！

なにかオイラのほうで勘違いや読み違いしてる可能性が濃厚だ！
もう一回復習してみよう・・・

さっそくわかりました！／(^o^)＼

bit0とかbit7とかの捕らえ方が、オイラ左右逆でした！

  間違い　　　　　　　　　　　　　　　　　正解　　

bit0,bit1,bit2,bit2・・・bit7　　　　bit7,bit6・・・bit2,bit1,bit0

全部やりなおし！