さてさて。
ここ数日プログラミングとかしないでこのサイトのメンテをしておりました。
ビミョ〜〜〜な部分でかなり苦労したんですがわかりますかねぇ？　(^^;

ま、それはちょっと置いておいて・・・

本当ならdir2コマンドのパターンマッチ部分のチューンナップすべき
なんだけど・・・飽きたぁ！！！！！！！
やっぱ、ファイル読み込みとかしたいじゃん！
そんなわけで、実機FDのテキストファイルを読んで表示するtype2コマンドに
着手〜！（はたしてうまくいくか！？？）


別談
うっちゃんが例によってオイラのタココードを検証してくれた。（ありがたや〜）

超オバカなミスをしていたようでする。

・・・やっぱ、丸写しするにしても、よく読まないとダメだよね・・・

（とはいえ、これで動いてるんだからすごい！いやはやなんとも・・）

できた━━━━━━(゜∀゜)━━━━━━ !!!!!

とりあえず、「dir2」だけだと全ファイルが表示。
で、「dir2 m」とかすると、頭文字がmのファイルだけを表示！

まずはそんなところでしょうか。

リリース！　リリース！

（うっちゃんにスゲーみっともないこと指摘してもらったので今度は慎重に・・・(^^;　　）

昨日、思わずうまくいってしまって「わーい！　わーい！」ってな
もんで、勢いでリリースしましたが、これ、そりゃあひどいもんですよ？　（＾＾

なにしろそこいらじゅうが「とりあえず」なもんで・・・

そんなわけで、dir2コマンドをヘコヘコとチューンナップ中なんですが・・

やっぱアセンブラはむずかしーーー！

でもそのおかげで、本体にどんな機能や関数が必要か
（どんなAPIがあればアセンブラでも楽できるか）
がだんだん。だんだんわかってきました。

とりあえず、全部のファイルがちゃんと表示されることと、せめて
頭文字くらいは選別表示ができるように。そんなこと考えながら
イジっております〜

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

やった！　いけたっぽいぞ！！！！
dir2コマンド（実機FDをdir）　うごいたーーーーーーー！

リリース！　リリーーーーースウゥゥゥ！！！！

くっそーーー！
どーしても「待ち」をシステム側で設けられないよーー！(´・ω・｀)

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

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


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

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

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

よーし！　OK。
FIFO間（タスク間？）通信、とりあえず成功したぞ！
あとはコマンドの仕様を決めて実装すれば、FDタスクを制御できる！！

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

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

さあここ！
４でFDが動く。ほんのわずかだが時間がかかる。
しかし、１では既に指令を出し終わっている。つまり、次のプログラムが
書いてあったらそっちの実行を始めてしまう・・・
１の時点を、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を監視してゲットするとか・・・）

ただえま〜　（仕事終わった！）

いやいや〜。
ぜんぜん気が付かなかった。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のすぐ下においておく。
こうしておけば、またいつかプログラムが大きくなって似たような
問題が起こった場合でも、この画像を表示することで確認が取れるから。

まず、子タスク？であるコンソールタスクから親タスク？のfifoに
データをプットしてみる実験ね。

・・・うーーーん。いい方法ないかなぁ・・・
わからん・・・

しょうがないので、コンソールタスク内でポインタ宣言をして、
マインのfifoのアドレスを当て込むことにしてみよう・・・

・・・あか〜ん・・・　どーもうまくまとまらん・・・・

やむをえないなぁ。素人のオイラでもさすがにちょっとイヤな感じだけど、
暫定的にグローバル変数でしばらくお茶を濁そう・・

FDへのアクセスは、専用のタスクで行っている。
この独立したタスクに命令を出すには・・・・・
なるほど！　FIFOへの発信ね！！

オイラがいまいじってるconsole.cはコンソールタスクだよね。ここから
別のタスクに送信ってできるのかな？？　ちょっと実験・・・

	  fifo32_put(&testtask->fifo,1024);

・・・こんなことしてみた・・・　　ダメ〜　(^^;
console.c内はコンソールタスクで動いてる。このタスクは、testtaskなんていう
タスクは知らないんだよねぇ。（上位のtask_aは知ってるんだが）

・・・どうしたもんだろう？
たとえば。task_a内にタスクの一覧表（詰め所？）みたいなのを作って、
その詰め所のアドレスを全タスクが共有する。FIFOに送りたいものは
その詰め所が配送を行うなんてのはどうだろう？？？

・・・うーん。発想そのものはきっと悪くないと思うけど、この段階で
そんなことするとちょっと仰々しいなぁ。（オイラの技術も追いつかないだろうし）
・・・親タスクのFIFOに送信して、親タスク内でif判断して振り分けるってのはどーーーだろ！！！


・・・よし・・・
この方法でいろいろとやってみるか・・・

あ”それと、ついで。各追加タスク（時計バーとFDタスク）が、今はぜーーんぶbootpac.c内なんだよなぁ。これはちょっとまずいでそ？
ファイル分けを先にやっておくか・・・

でけた〜

まずはとりあえずは大雑把に。
最初の文字がmのファイルを探してくる。

_HariMain:



		MOV		EDX,0x4E	;機能番号

		MOV		EAX,filename

		MOV		EBX,fbuf

		INT		0x40	;コール！



;この後、fbufにはmで始まるファイル名が書かれるはず・・・





	;もらった文字列を表示してみる	

		MOV		EDX,2

		MOV		EBX,fbuf

		INT		0x40	;コール！



		MOV		EDX,4	;アプリを終了

		INT		0x40





[SECTION .data]



filename:

		DB	"m*.*",0



fbuf:

		RESB	512 * 14

console.c側もとりあえずは大雑把に・・・

	else if (edx == 0x4E) {

	  char *search_f_name;

	  char *fbuf;



	  int i,i2;



	  search_f_name = eax;

	  fbuf = ebx;



	  i = 0;

	  while ( search_f_name[i] != 0 )

	    {

	      fbuf[i] = search_f_name[i];

	      i++;

	    }



	  for ( i2 = 0; i2 <= 3; i2++)

	    {

	      fbuf[i] = 'A';

	      i++;

	    }



	  for ( i2 = 0; i2 <= 5; i2++)

	    {

	      fbuf[i] = 'B';

	      i++;

	    }



	  fbuf[i] = 0x00;



	  reg[7] = 0;



	}

これで、コンソールには「m*.*AAABBB」と表示されるはずです。

・・・・あれれれ？　うまくいかないなぁ・・・・・・

さては！！！！

こういうのは大抵セグメントなんですよねぇ。ええと・・・どこに書いてあったかな・・・

・・・あったあった！。P422のあたりから。
コンソール側で実行されたアプリであるdir2。セグメントが違う。
dir2にとっての0x1000番地と、コンソールタスクにとっての0x1000番地は別の場所なんだよねぇ。

なので、

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

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

こんなことしてやると、補正できるわけ。

とりあえずコンパイル＆実行。うまくいったーーー！！！　(^^

これでレジスタを通して番地のやり取りもできるようになったぞ！。
それじゃいよいよ、実際にFDを読んでその情報を返すようにコードを書こ・・・

は！！！！

うわーーーーーー！　そうだよ！　FDアクセスは専用のタスク内でしか
動かないはずなんだよ！　FD用タスクに命令を出したり情報をもらったり・・・・
そこいらへんがぜんぜんできてないじゃんかーーーー！