ザビタン開発日記
2009 | 01
2008 | 01 | 02 | 06 | 12
2007 | 10 | 11 | 12
11月 05 (月曜日) 2007
23:05
FDアクセス:自前の待ちを置くべきか?
 
くっそーーー!
どーしても「待ち」をシステム側で設けられないよーー!(´・ω・`)

どうしたもんかなぁ。
アプリであるdir2.nas側で、自分で待たせるようにしないとダメかなぁ・・・

なんとなくスマートな方法じゃない気がする。
ファンクションコールはシンプルならシンプルなほどプログラミング時に
楽ができるはずだし・・・


------------ 一時間後 ----------------------------
ヽ(`Д´)ノ のわあぁぁぁぁ!!!
アカンわ。そもそもオイラのノーミソは食品添加物100%で減塩なのに5年持つ粗悪品じゃい!

dir2.nas側でループして待つ仕様に暫定だ!

(うっちゃんスマソ。せっかくアイディアもらったけどオイラじゃここらへんが落としどころらしいっす) (^^;


 
●uchan@Guest -- 11/05 23:13
的はずれだったらすみませんが、思いついた事を書きます。APIが親タスクのFIFOにデータ(コマンド)を送信する前にあるフラグを立てておいて、FDタスクがそのコマンドを実行し終えたらすぐにフラグをクリアするようにしておく。そして、API内(else if (edx == 0x4E) {} 内の forループ)でそのフラグをチェックしておいて、クリアされたらreturnする。……どうでしょうか。
●hideyosi -- 11/05 23:52
うっちゃんのアイディアを参考に搭載・・・・アカンです〜。この(else if (edx == 0x4E) {} 内にwhileやforループを設けると、他のタスクまで固まってしまうようです。(つまりFDタスクも停止してしまうので作業が完了しないのです) orz

30日を過ぎたBlogにはコメントできません。
21:16
FIFO間通信完了!しかし・・・!?
 
よーし! OK。
FIFO間(タスク間?)通信、とりあえず成功したぞ!
あとはコマンドの仕様を決めて実装すれば、FDタスクを制御できる!!

・・・っと思ったんだけど、問題点が・・・
それは「待ち」なんですよねぇ・・・


  1. INTで割り込みを起こしてAPIを呼ぶ。
  2. APIは親タスクのFIFOにデータを送信する。
  3. 親タスク内のループで判断し、番号がFD命令用ならFDタスクのFIFOに発信!
  4. FDタスクはFIFOにデータが来るとそれを読み、命令だったらFDにアクセス・・・

さあここ!
4でFDが動く。ほんのわずかだが時間がかかる。
しかし、1では既に指令を出し終わっている。つまり、次のプログラムが
書いてあったらそっちの実行を始めてしまう・・・
1の時点を、FDタスクが完了したと返事をするまで待っていてもらう。
返事がきたら続きの動作をする。

・・・これ、どうしたらいいかなぁ・・・・

こんなことをしてみた・・・

else if (edx == 0x4E) {
char *search_f_name;
char *fbuf;

int i,i2;

search_f_name = (cons, (char *) eax + ds_base);
fbuf = (cons, (char *) ebx + ds_base);

i = 0;

fifo32_put(MainFifo,3200);

fbuf[i] = 0x00;

// reg[7] = 0;

for (;;){}

}

console.c内でFIFOのデータを判断する部分。ここに無限ループを置く
当然これなら、「dir2」でエンターした後固まってくれる。

つまり、その下のreturnが実行されない限り、戻らずに停止してくれるようだぞ!??

じゃ、このfor内で、返事が返ってくるまでループしていればいいのかな????
(このループ内でFIFOを監視してゲットするとか・・・)
 
30日を過ぎたBlogにはコメントできません。

Referer  (5)
15:35
バグ発見!?
 
ただえま〜 (仕事終わった!)

いやいや〜。
ぜんぜん気が付かなかった。Ver.0.00からこっち、ずーっとコンソールでフォントの表示がおかしかったのね・・・
(今見ると、スクリーンショットでも出てる。漢字だけ表示されない!)
原因がわからなくて泣きべそかいてたんだけど、たぶんこれでは?を発見。

これは表示されてないんじゃなくて、日本語フォントが壊されているらしいんだ・・・
で、原因と思しきもの。・・・・リーナのJPGでした!\(^o^)/
しかしなぜこのファイルを追加するとおかしくなるんだ???
と、原因を考えていたんだけど、ようやっと判明。

「JPGファイルをへんな位置にはさみこんじゃったから」

だったのです〜(^^; Makefileはこうしていました。


copy from:pictdata/fujisan.jpg to:@: \
copy from:pictdata/night.bmp to:@: \
copy from:pictdata/lina1.jpg to:@: \
copy from:nihongo/nihongo.fnt to:@: \
imgout:haribote.img
               :

これをこうすると


copy from:pictdata/fujisan.jpg to:@: \
copy from:pictdata/night.bmp to:@: \
copy from:nihongo/nihongo.fnt to:@: \
copy from:pictdata/lina1.jpg to:@: \
imgout:haribote.img
               :

スクリーンは正常に表示を始めますが、今度はgviewでリーナの
画像が表示されなくなります。

・・・これはどういうことかと???

はりぼての現状では、起動時にメモリにファイル全てを読み込み、
それをシステムから使っています。(一種のRAMディスクのよーな!)

でね?

この時、ファイルを全て判断してぜーんぶ読み込んでいるわけでは
ないわけ。
asmhead.nas内でやってるんだけど、はりぼてが完成した時点の全サイズを計算して、
「まぁ、こっからここまで、とりあえず読んでおけばまぁいいだろう!」
というプログラムになっている。これには理由があって、起動時に
全部やってたら起動が遅くてしょうがなくなってしまうから。
(実機のFDで1.44MB全部読もうとするとけっこう時間かかるでしょ?)
いままではなんとかなってたけど、本体やらコマンドやらが増えてきて、
とうとう境界線を越えちゃったわけなんです・・・  orz
そんなわけで、しばらくはヲタ絵をはずすことにしまする。

・・・でもこれ、すっげーーー悩んだんですよ〜? (^^;

なにしろ、bootpac.cに一行命令を増やすだけで発生したり直ったり・・・

原因を特定するためにソースもあちこち弄り回してしまったのでもう
ぐっちゃぐちゃだ〜〜〜〜!!!  (泣

一個前のバージョンからやりなおします・・・  orz


ついでに。
night.bmpを残しておく。そしてNIHONGO.FNTのすぐ下においておく。
こうしておけば、またいつかプログラムが大きくなって似たような
問題が起こった場合でも、この画像を表示することで確認が取れるから。

リビジョン68
 
●uchan@Guest -- 11/05 18:30
せっかくFDC使えるようになったのにリーナたんのJPGをはずしちゃうの?
●hideyosi -- 11/05 20:09
そなんですよ〜。今しばらくは。(^^; FDC使えるとはいえ、まーだちょこっとセクタ読める程度なので。もうすぐ・・・もーーすぐでっせ!!

30日を過ぎたBlogにはコメントできません。

Referer  (1)
(1) 

PopnupBlog V3 Denali created by Bluemoon inc.