20日目〜。

ひさしぶりのソース整理の後は、いよいよAPIだ！

・・・ふむ・・・
APIはいわば関数の塊だよね。これをアプリからコールする。
そのためにはコールするための場所がわからないといけない。
また、レジスタ内に保持したパラメータ（この場合は文字コード）
はCとの関数のやりとりで壊れてしまうので、スタックに積むと。

コールする場所だけどその場所を記憶しておくところを作る。
（0x0fec）。なぜこんなことをしないといけないのか。
関数consの場所はプログラムを書き換えたりするとすぐにコロコロ
動いてしまう。なので、コンパイルして実行したときに初めて
consの実際の場所が確定できるわけね。
なので、実行時に実際のconsのアドレスを調査して、それを0x0fecに書き込んでおくというわけ。


P403の_asm_cons_putchar関数はなにをやっているかというと、

1. hlt.nas(アセンブラ）が_asm_cons_putcharをコールする。
   　　
   （アセンブラ同士なので、この時点ではレジスタは壊れない）



2. _asm_cons_putcharはアセンブラなので、hlt.nasのレジスタを保持しているが、次に呼び出すcons_putcharはC言語で書かれている関数なので、レジスタが壊れてしまう。なので、現在の必要なレジスタの値（文字コード）をスタックに退避させる。



3. さらに、consの値もスタックに積む



4. ここで初めて、_cons_putcharをコールして制御を渡す。
5. 
   
   
6. _cons_putcharは実際の動作を行うが、Cで書かれたこの関数はレジスタを壊す。しかし、ちゃんとスタックにデータが詰まれているのでパラメータを受け取れる。
7. 
   
   
8. 関数なので、処理を終えると戻ってくる。



9. 戻ってきたら、最初にスタックに積んでおいたデータはもういらないし、邪魔である。スタックを元に戻すため、積んだデータを壊す。



10. ADD ESP,12 がその処理。スタックポインタの位置を示すESPに単純に12を加算することで、POPを3回やったのと同じことになる。

・・・と、しかしこの完璧な構想にはエラーが・・・(^^;

これはもう、すぐにピンとくるよね。そう。セグメントが違うじゃんということ！！

P405
予想通り〜。
そんなわけでCALLとRETをfar対応にすればOK〜。

P407
わははは！　まだコールする場所を手作業でやっているため
こんなことが起こるんですねぇ〜。

いずれこれも自動化されるはず！

19日目〜。

なんだかエライペースで進んでますなぁ　(^^;
まあオイラの場合、一回読んでるので。
その時ちゃんと理解できたものはもう、ただの復習なので早いのです！

・・・うーん。こまった。特にわからないところも
ないしなぁ・・・

そんなわけで19日目終了〜

18日目〜。

わはは！　カーソル点滅おもしろ〜い！

スクロールもエンターキー対応もおもしろ〜い！

コマンド搭載＆追加もおもしろーーーーーーい！

おっとぉ！
P371。いよいよdirコマンド！

これこれ！
構造体をポインタで定義して、そこにアドレスを当て込んじゃって
しまえば、メモリの規則正しい配列はそのまま構造体の要素と
して読めちゃうっていうテクニック！

しびれる〜！


さーて。そんなわけで18日目終了〜

（・・・やべー・・・はやく改造してーー！）

17日目〜。

むっずかしいタスク管理。完全に解らなかったのがちょっと
くやしいが今度はコンソールだ！。サクサク進めるはずだぞー！？

・・・いきなりまたタスクですか・・・　orz

ん？　あれ？

でも、これならわかるぞ？　番兵でしょ？
P337
うん！大ジョブ大ジョブ！　これなら解る解る！
（　　あーよかった・・・(^^;　　）

P338
さてさて！
いよいよコンソール作り〜！　こういうのはなんか楽しいな♪

P344
あーん。なるほどねぇ。ここでTASK構造体にFIFOが入るのかぁ。

P345
&fifoを&task->fifoに書き換えると・・・なるほどなるほど。もっともです。

P347
うーん。なつかしいなぁ。これ見るたび、かつてhideyOSiを
作ってた時のこと思い出すです。（いやそりゃ、ぜんぜん
レベルが違いますが・・・(^^;　　）

P352
コラムに書いてあることをウチでも実験・・・・
あっれ〜？？？　ウチのはちょっとちがうぞ？？

QWER UIOP
ASDFGHJKL:"|
BN?

ウチのキーボード+WindowsXPだと、両Shift押しだとこれしか
入力できないようだ・・・。こういうのはなんの仕様なんだろう？
キーボード？　それともマザーボードかなんかかな？？？


さてさて〜。
タスク管理と違ってツルツル進むぞ！　←逆恨み

そんなわけで、17日目終了〜

P324
タスクに優先順位かぁ。なるほど確かにこれは必要な仕組みですね。
そのために、TASK構造体にプライオリティーという変数を追加と。

P326
ふむふむ。タスクが2個以上ないとスイッチしないと。なるほどなるほど。

P327
なるほどぉ〜。タスクを走らせる時に優先順位をこういうふうに
指定すれば近い値が出ますなぁ。たしかに。

P328
・・・さ〜て！　ここからが課題。
っと言うのは、以前はどうもここがわからなかったからなんです。

おっとっと！
さっそく！。やることがなくなるとスリープすると。
えっと。これどういう仕組みだったっけ？。チョット復習。

あー！ここ、ここ！　P316だ。
なるほど。やることがなくなった場合はtaskctl->tasks[]内から
削除されると。これは要するに、順番待ちの名簿から名前を
削除されるのと同じことだね。スリープというとなにか特殊な
感じがするけど、ようは名簿から外れたので呼び出し（タスク切り替え）
が起こらず、結果なにもしないタスクということになるわけか。

P329
・・・むむむ・・・これがどうもわからんなぁ。
マウスと音楽。共に大事なんだけど、その大事なのがぶつかって
しまったら。まあそれはよくわかるんだけど、たとえばプライオリティーを
もっと細かく（たとえば100段階とか）にするってんじゃダメなのかなぁ・・・

タスクにレベルを設ける。で、上のレベルが空にならない限り、下のレベルのタスクにはやってこないと。
うーむ！。でも、例えば音楽再生みたいにずーっと処理されるようなタスクが
二個あったら、下のタスクには永遠に切り替わらない？？？

あ”っーーーー！　ちょっと違うなぁ。

これは逆の考え方のほうがいいのかな。つまり、いままでの
優先順位だけだとタスクは全て切り替わる。順位はあるが
必ず切り替わると。
音楽再生のように忙しいタスクが出現した場合はいくつかの
タスクが下のレベルに追い出され、終わるまでは切り替わらない。
そういう考え方なのかな？？


うーーーん・・・・
P331のtask_switchsub()がどうもわからないなぁ・・・

・・・こりゃちょっとダメかもしれん・・・
さすがに「3巡目」ってのはないけど、ここはちょっと棚上げ。

以上、2巡目もまた惨敗だが先に進むことを優先し、不本意ながら16日目終了・・・orz