ちょっと変化がありました。

実機Aは相変わらずなんですが、実機Bで初めて「ぶっ！」っと音が出ました。

・・・実はオイラはこれまでシークやリセットは搭載していなかったんです。
もしかしてこれかなぁと思い、シークを搭載してみたら変化が。

読み取りコマンド前にシークやリセットを挟み込んでさらに実験・・・

むむむ・・・
実機Aではあいかわらずだが、実機Bではリザルトが0x40、つまりコマンドの
異常終了になるようになった。
これははたして進歩だろうか・・・orz・・・

整理する。

オイラが書いたコード

qemu: リザルトは0x00
実機A(ダイナブックGT475）:0x80
実機B(自作機・Celelon700）:0xc0
VMWareイメージFD:0x00
VMWare実FD:0x00

コマンド間違い

意図的にコマンドを間違える。S(セクタ）をありえない数値（99）にしてみる

qemu: 0x40
実機A(ダイナブックGT475）:0x80
実機B(自作機・Celelon700）:0xc0
VMWareイメージFD:回復不能なエラーで落ちた
VMWare実FD:回復不能なエラーで落ちた

コマンド中抜き

意図的にコマンドのひとつを抜く。じゃ、02の送信を抜く

qemu: 0x00
実機A(ダイナブックGT475）:0x80
実機B(自作機・Celelon700）:0xc0
VMWareイメージFD:0xc0
VMWare実FD:0xc0

コマンド中抜き2

意図的にコマンドを抜く。02、さらに12も抜いてみるく

qemu: 0x00
実機A(ダイナブックGT475）:0x80
実機B(自作機・Celelon700）:0xc0
VMWareイメージFD:0x00
VMWare実FD:0x00

DMAを開けない

DMAを開ける関数を無効化

qemu: 0xc0
実機A(ダイナブックGT475）:0x80
実機B(自作機・Celelon700）:0xc0
VMWareイメージFD:回復不能なエラーで落ちた
VMWare実FD:回復不能なエラーで落ちた

DMAを開け、コマンドを送信しない

DMAを開ける関数を無効化

qemu: 0x00
実機A(ダイナブックGT475）:0x00
実機B(自作機・Celelon700）:0x00
VMWareイメージFD:回復不能なエラーで落ちた
VMWare実FD:回復不能なエラーで落ちた

DMAも開けず、コマンドも送信しない

DMAを開ける関数を無効化し、リードコマンドも送信しない

qemu: 0x00
実機A(ダイナブックGT475）:0x00
実機B(自作機・Celelon700）:0x00
VMWareイメージFD:回復不能なエラーで落ちた
VMWare実FD:回復不能なエラーで落ちた

分析してみる・・・（ノД｀）・・・

• エミュはかなりアテにならない
  
• リザルトは機種により違いが出てしまうようだ
  
• DMAの開け閉めそのものはリザルトには影響しない
  
• コマンドを送信しなければ0x00なので、リザルトがこれ以外になる（エラー系）のはやはりコマンドになにか問題があると予測される
  

新たな疑問。
この実験では実機の場合、なにも送信しなければ0x00である。
・・・っということは、0x08なり0x0cなりになるのはどの時点か？

実機A:[0x03f4待ち] [E6] [H<<2] [C] [H] [S] [02] [12] [01] [FF] 

       00           c0    80  ・・・・・・・・・・・・ 



実機A:[0x03f4待ち] [E6] [H<<2] [C] [H] [S] [02] [12] [01] [FF] 

       00           c0  ・・・・・・・

はあぁ〜。
土日は忙しかったので今日はお休み〜

実機で問題が出る所は特定できた。コマンドが間違っているというエラーが帰ってきている。

・・・でもこれ、ほんとうにコマンドだけの話かな？

いくつかワザと間違っている状況を作ってリザルトコードを検証してみよう・・・

DMAを開けないで実行

うーむ・・・。エミュだと0xC0(AT互換機では発生しないエラー）が帰ってきた。
実機だと、同じコードでも0x80（コマンドが間違っているエラー）のまんまだなぁ。

コマンドが足りない

コマンドが足りない（わざと一個送らない）状態だと・・・
最後の0xFFを送らない状態だと、
あれえぇ？　エミュでは正常終了？
実機では0x80だなぁ？？？？

これはどういうことなんだろう？？？

うはぁ！　VMWareでイメージで実行すると0xC0？
実FDだと同じくかぁ・・・

じゃ、真ん中当たりのコマンド（じゃあ02）の送信をしないでやると・・・

エミュでは0x00、
実機では0x80、
VMWareイメージだと0xC0、
VMWare実FDだと0xC0。

うむむむむ〜？？

ダメダだめだ！　ちょっと整理・・・

むむむ〜！！

原因はわかった。（いやわかっていないのだが）
読み込みコマンド（[E6] [H<<2] [C] [H] [S] [02] [12] [01] [FF]）を
発行した後、なぜかINTが帰ってこないのだ・・・

どういうわけなんだろう？　コマンドに問題が？　それとも？？？

うーん。リザルトを取ってみようかな。

・・・・・・え”　0x80　??　「 コマンドそのものが間違っている」場合の
エラーじゃない？これ？？？？

おっかしいぃなぁぁぁぁぁ。エミュでは問題ないはずなのに。
見直しても問題点はみつからない。なんじゃろう？？　これ？？

朝っぱらから古いFDを引っ張り出して実験〜！

結果は・・・orz・・・

うーん。オイラの現在もマシン（ペン4）だとそもそも追加したタスク（時計とテストタスク）が動かない。

古いノート（486）では動いているけど、FDアクセスコマンドを発行すると
リセットがかかっちゃう。

　　うええぇぇぇん！　問題だ〜
‾‾‾‾‾‾‾‾‾∨‾‾‾‾‾‾‾‾‾‾‾
　　　　　　　　　 　Λ＿Λ
　　　　　　　　　　（ ´Д⊂ヽ
　　　　　　　　　⊂　　　　ノ
　　　　　　　　　　 人　 Ｙ
　　　　　　　　　　し （＿）



・・・・しばし実験・・・・
まず、タスクが動かない問題は解決しますた！！ヽ（ ´Д`）ノ
ここ。バージョン6のパッチを当て込むことで動作OKです。

で、問題のFDD。
486だと相変わらずリセットしちゃう。
ペン4だと、リセットは起こらない。また、モーターの回転＆ストップもうまくいっている模様。
しかし、セクターを読んでくれないようです。
さーて。どこが悪いんだろう。検証コードを埋め込んで特定しないとなぁ。

・・・・あ”　いっけねぇ！　もう仕事じゃん！
いってきま〜〜〜〜す！！

やっとこさモーター制御のコードが書けた！！！

・・・さーて！　ほいだば、いよいよ実機でチャレンジかな？？

あ”　・・・もう健康なフロッピーがないんだった・・・orz

よーし！　パパ、明日はダイソーだぞ〜？？？

どうも構造体のやり取りがうまくいかないと思ったら大ポカしてた！

構造体を渡して、渡した先でも内容をいじったりする場合はアドレスとして渡し、ポインタで受け取るのね・・・

間違った例

    struct KOUZOU kouzou1;



    kouzou1.aaa = 1;

    kouzou1.bbb = 2;



    testkansuu(kouzou1);





void testkansuu(struct KOUZOU kouz)

{

    int s[40];

    sprintf(s,"構造体のメンバーaaa=%02d",kouz.aaa);    ←もらうことはできる。

                                                         ちゃんと「１」が表示される



    kouz.bbb = 123;                                    ←戻っても、bbbの値は変化しない。

                                                         つまりリードオンリー状態!?

    return;

}

たぶん？正しい例

    struct KOUZOU kouzou1;



    kouzou1.aaa = 1;

    kouzou1.bbb = 2;



    testkansuu(&kouzou1);





void testkansuu(struct KOUZOU *kouz)

{

    int s[40];

    sprintf(s,"構造体のメンバーaaa=%02d",kouz->aaa);    ←もらうことももちろんできる。

                                                          ちゃんと「１」が表示される



    kouz->bbb = 123;                                    ←戻ると、ちゃんと

                                                          bbbの値は123になっている。

    return;

}

うーむ・・・
連続してセクタを読めるようになったからこそだけど、
モーター始動時の待ちを厳密に管理しないと・・・

（現在はどこかヘタ打ってるらしくて、セクタごとに待ちが入る）

キタ━━━ヽ(ヽ(゜ヽ(゜∀ヽ(゜∀゜ヽ(゜∀゜)ノ゜∀゜)ノ∀゜)ノ゜)ノ)ノ━━━!!!!

セクターリードを関数化してコールし、連続してroot領域を読み込めました！

ファイル名取得などは30日本からパクって実装したら、つる〜っと読めてしまった！

前回と同じ動作を

	    int CC = 0;

	    int HH = 0;

	    int SS = 1;



	    int err1;

	    char ssbuf[512];



	    err1 = read_sector(CC,HH,SS,ssbuf,fdtime1);



	    //読み込んだのはセクター0なのでBPE解析！

	    bpe_read(fdbpe,ssbuf);

こんなことして単独関数にできた！
これを使っていよいよFAT読み込み＆解析開始！！

・・・ん？　まてよ？？
ディスク情報はかならずセクタ0なんだし、これをそのまんま論理セクタ対応にしちゃおうかな？？？