え〜。
そんなわけで、ようやっと2巡目終了。
途中忙しくてなかなか進まなかったけどやっと終わりますた〜。

まだまだわからないところも多いんだけど、とりあえずいつまでも
ってわけにもいかないので、思い切ってこれで、このはりぼて日記
は終了っつーことにしまする〜。

実はここ数日、ちょっと急いでいたのには理由があります。

そう！この日記をはじめたのが去年の11月。いくら2巡してるとはいえ、
やっぱり一年を超えたくなかったんですよ〜。
幸いちょこっと時間が出来たので、これ幸いとスパートをかけた
という次第です。
（間に合った〜。よかった〜）

以降はずいぶん間が空いちゃったThe-BBLの開発をしながら
勉強していくっつーことで。
（友の会でも一番出遅れてるもんねぇ。（汗々・・・）

そんなわけで、以降は新日記、ザビタン開発日記にて。

ではでは〜

30日目〜

いよぉっしゃあぁぁぁぁ！！！

ラストだ〜！

・・・とはいえ、既に一回読んでるオイラには、最終日は
取り立ててなんもないのだ〜。

（一応コードは一通り目を通し直したよ!　(゜∀゜)


ほ〜た〜るの〜ひ〜か〜あり〜♪


30日目終了〜！！！

29日目〜。

チクソーくやしいなぁ。
バグわからんかった。で、答えあわせ。

・・・あーー！　あーあーあー！　ここかぁぁ！！
なるほど！　リフレッシュをしていないからかぁ！
（より正確には文字幅が増えた分の範囲をリフレッシュしていない。
文字の幅は常に8だと考えてリフレッシュを置いていたのでその
範囲のリフレッシュが置き去りにされている）
なるほどぉ！　ウィンドゥを動かすと直るってのは、sheet_slideか
なんかが全体をリフレッシュしてくれるからなのね！？

P629
えーと。圧縮に関しては・・・
「ふむふむなるほど」に留めるとしましょう　（汗


P637
標準関数の整備かぁ。
いずれこれを参考にしていろいろと揃えたいっすよね？

P643
うーむ？
ここでも同じ現象がおきてるよね。
「よってこのバグはリフレッシュ関係だ！」ってのがある程度
パターンになっているのが面白い。こういうのはもう、経験
だよね。

P644
インベーダー。
これの検証や勉強は今はしないんだけど、ここで注目。
それなりにややこしいこのゲームの動作。そのソースが
たったこれだけってのがすごいよね。
あの頃のゲーム達はきっとアセンブラとかでROMに焼きながら
作ってたんだろうなぁ。どんな感じだったんだろうなんて
想像してしまう。


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

わーーーー！　ラス前だーー！

28日目２〜。

おまたせしました！いよいよ日本語表示だ！

P613
えーっとえっと・・・・
ちょっと込み入ってるけどむずかしくはないな。そして例の構造体に当て込むテクニックね。

P617
これたしか、前回も思ったんだよね。
「え？　こんなに簡単でいいの？？」
って。

P622
・・・いや、ほんとにこんなに簡単でいいの？？　(^^;

P627
うお！！
バグだぁ！
うーん。このバグはおもしろい？よね？
半分しか文字がでない。（全て右側）
ウィンドウを動かすと直る・・・

ちょっと考えてみよう。

うーむ。全てが右側欠けになるわけじゃない。EUCという、
そもそも半角の文字はちゃんと表示しているなぁ。
全角文字だと判断して表示している部分をチェックしてみる・・・

ここかな？P619のputfontの辺り。

・・・ダメだなぁ。おかしい所、特にないなぁ。

putfont8そのものがおかしいのかな？
いや、そらならEUC部分も変になるのでは？？？

順を追ってみてみよう。

1. この以上はchklang.cにて起こる
   
2. chklang.cで文字を表示するにはapi_putstr0を使っている
   
3. api_putstr0は_api_putstr0(P457）を呼び出す
   
4. _api_putstr0は機能番号2を使い、INTしている。
   
5. これにより、hrb_apiに制御が渡り、cons_putstr0が呼び出される（P422あたり？）
   
6. cons_putstr0は内部で文字数分だけcons_putcharを呼び出しているだけ。（P416）
   
7. cons_putchar（P398）。普通の文字の表示のためにputfonts8_asc_shtをコールしている
   
8. putfonts8_asc_shtは内部でputfonts8_ascをコールしている（P250）
   
9. putfonts8_ascは内部でputfonts8をコールしている（P106）
   
10. putfonts8でようやくvramに書き込んでいる（P102)
    

・・・ダメだこりゃ・・・
下から順にソースを追ってみたんだけどわからないや・・・・

半分欠けてしまう原因って・・・・

28日目〜

P594
なになに？　alloca？
んーーーっと・・・・
1000までは　　char flag[MAX], s[8]　では、
charだから1バイト。それが配列として宣言されるから1000バイト。
1000バイトは1KB弱かぁ。だからOKと。
で、これが10000になっちゃうとええと・・・9.7KB。たしかに4KBを超えてるなぁ。

ちなみにちょっと実験。ほんとに4KBが境目かどうかやってみました。
えっと、4KBってことは1024*4だから、4096bだよね。MAXを4095にして実行！

うほぉ！　とまったぞ？？？　おっかしいなぁ・・・

3500はOK・・・
3900もOK・・・
4000だとおかしくなるけど、なんかちょっと違うぞ？？
3950はOK・・・
3960もOK・・・
3970もOK・・・
3980もOK・・・
3990からおかしいな。
3985もダメ。
3984・・・おぉぉ！　OKじゃん！！

ふーむ・・・つーことは、3984が実質限界ということかぁ・・・
配列は0からスタートするから個数としては3985。3985バイト・・・

これはなんの数値だろう？？
あ”　そうか！　同じく配列タイプがもう一個あるな。[8]だから
9個。足し算すると3994。3994バイト・・・。
スタックの限界値は4KBすなわち4096バイト。102バイト足りないけど、これはなにに使われてるんだろう？？？

まあいいや。とにかく、ほぼ4KBを境におかしくなるのは間違いないようだなぁ・・・

で！！　

とにかくCコンパイラがこの仕様というわけか。（ここまでは理解）
ほんでもって、_allocaがなくてもいいようにmallocでメモリを確保しておいて、それをflagに当て込むと・・・。これも理解。
（つか、おもしろいね。このテクニック・・・（＾＾　　）

で、_allocaを搭載すると。


ところで、スタックに領域を確保するのにESPの引き算って、これ、意味解る？
スタックは積まれていくことを思い出すと理解できるよね？（＾＾



P601
さていよいよファイルAPIだ！！

おぉぉっと！　予想に反してなんかこれ簡単だぞ！？？


P609
コマンドラインの取得ね。・・・うーん。そんなに言うほどややこしくないと思うぞ？

P580
にょにょ〜！
まーたKタンの大好きなダイエットかよおぉぉ・・・・(
笑

と思っていたらそうじゃない！
ライブラリとはなにかの解説じゃないですか！これは有用ですよ！？

整理してみると・・・

1. アプリのサイズがやたらデケー！　なんで？
   
2. APIとして容易されている関数の全てがアプリに入ってしまっているから。
   
3. まてよ！　このアプリでは○○○は使うが△△△は使わないじゃん！　△△△までは内蔵しなくていいだろ！
   
4. だってしょうがないじゃん。全てのAPI関数が一個の.objに内蔵されてるんだもん。これをリンクすりゃ、そりゃ全部はいっちゃうだろうが。
   
5. よしわかった！　じゃ、全部の関数を一個一個の.objに割っちまえ。それならいるものだけがリンクできるだろ！
   
6. いいアイディアだ！そうしよう！
   
7. あらこんなにスッキリ！！！！！
   
8. ・・・問題発生だ・・・関数が増えて.objが増えてくるととても把握できん！！！！
   
9. おっと？　.objが粉々な場合、把握なんかしないで全部書いておけばいいと？　それならリンク時に、実際に使ったのだけリンクしてくれると？　便利〜！！！　じゃあ黙って全部書いておこう！
   
10. *.objが多すぎるよぉ〜。なくしたりしたらもうワケワカンネ！
    
11. LZHとかみたいに、一個にまとめられね？
    
12. そんなわけで誕生！　ライブラリ！！！
    

なんか一見すると最初の全部入りobjに戻ってしまったようにも
見えますがそうじゃないんですよね。ライブラリ＆.hファイルに
よって、ようは9番をフルオートでやってくれるようになったと
いう認識ですな。


まあ、理屈的に考えればリンカが賢くなって、使っていない部分は
自動でひっこぬいてくれるようになればライブラリなんていらない？
と言えなくもないかもしれませんが、それはまた別の話というかね。


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

P577

えーっと、まず、GDTをもう一回復習。

GDTはメモリ内の設けられた特別な意味を持つ領域。
（メモリのどこにするかは原則自由。GDTRというレジスタに番地を
設定すればそれでいい。）

たとえばGDTRに、0x10000を設定したとする。すると以降、CPUはここから
8,191までの範囲をGDTとして扱うようになる。
GDTは表。一個（一行？）に各要素があり、次の行へ移る。
（とりあえず1行は8バイト。64ビットある。これ刻みに行が移る）

┌────┬────┬───┬────┬─────┬───┐

│アドレス│GDT番号 │大きさ│開始番地│　　属性　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0x10000 │　0   　│　　　│　　　　│　　　　　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0x10008 │　1   　│　　　│　　　　│　　　　　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0x10010 │　2   　│　　　│　　　　│　　　　　│　　　│

├────┼────┼───┼────┼─────┼───┤

│　　　　│　　  　│　　　│　　　　│　　　　　│　　　│

　　：　　　　　：　　　：　　　　：　　　　：　　　　：

├────┼────┼───┼────┼─────┼───┤

│0x1FFF0 │　8190　│　　　│　　　　│　　　　　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0x1FFF8 │　8191　│　　　│　　　　│　　　　　│　　　│

└────┴────┴───┴────┴─────┴───┘

これに対して普通にGDTを一個設置したい場合は各項目に書式に
したがってデーアを当て込めばいい。たとえば、
・あるセグメントを0x80000〜0x90000(64kb）として作りたい
・このセグメントはアプリが使う（コード）
・とりあえず0、1はOSで使われているようなので、2番とする。

こうしたい場合、

├────┼────┼───┼────┼─────┼───┤

│0x10010 │　2   　│64kb　│0x80000 │アプリ用C │　　　│

├────┼────┼───┼────┼─────┼───┤

こう設定すればいい。
これでメモリ0x80000〜0x90000がアプリ用のセグメントとして管理
されるようになる。アクセスする場合はセグメント2番として行う。

IDTというのがある。IDTは割り込みが来た時にどの番地にジャンプ
するのかを、同じようにメモリの一部にずらーっと書いてある。
どこからどこまでがIDTなのか？という設定も、同じくレジスタ
に書き込めばいい。IDTLレジスタにIDTのスタート地点としたい
番地を設置してOK。

さてここで問題が生じる。
マルチタスクでは他に、TSSという設定一覧表が必要になる。
TSSはレジスタの退避エリア＆タスクの設定が書かれた表である。
この流れで行けば、CPUのどこかにTSSLなんてレジスタがありそう
だがこれはない。
TSSはGDTで設置する。つまり、どこか適当な番号のセグメントを
設置して、そこはメモリとかではなくTSSなんだという属性を
与える。例えば、

・メモリ0xA0000を、あるタスクのTSSとして設置したい。
・TSSはどこにでも設置できるが大きさが決まっている（それ以上いらない）

なんて場合は、

├────┼────┼───┼────┼─────┼───┤

│0x10018 │　3   　│104b　│0xA0000 │TSS用　　 │　　　│

├────┼────┼───┼────┼─────┼───┤

こうしてあげれば0xA0000〜0xA0103までがTSSになる。

・・・はっはぁ・・・・

こうやって整理してみたら、ちょっとわかってきたぞ？？

TSSはGDTのように専用のレジスタを使ってポンと設定できない。
変則的だがGDT内に、「俺はTSSだー！」と設定するわけ。
同じような考え方でLDTを作るわけ。
LDTはGDTとそっくりな構造だけど、「どこからどこまでがLDTか？」
という設定をレジスタではなくGDTセグメントにて設定するわけ。

たとえばLDTを0xB0000に設置したいとする。流れからすると、LDTLなんて
レジスタがCPUにありそうだが違う。TSSと同じく、どこか適当な
GDTに設置する。（空いているところでいいようだ。）
具体的には

├────┼────┼───┼────┼─────┼───┤

│0x10020 │　4   　│15b 　│0xB0000 │LDT用　　 │　　　│

├────┼────┼───┼────┼─────┼───┤

これで0xB0000から始まる、GDTとそっくりな表が形成される。
大きさを表すパラメータ。（今回は15bとしている）これは最大値(64KB)は決まっているがいくつでも構わない。GDT
の場合は開始番地をレジスタに設置した瞬間、自動的に最大値まで
が確保されるが、LDTは必要な分だけでよい。今回は２個しか
必要じゃないのでこれでいい

この作業を行った後には、

┌────┬────┬───┬────┬─────┬───┐

│アドレス│LDT番号 │大きさ│開始番地│　　属性　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0xB0000 │　0   　│　　　│　　　　│　　　　　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0xB0008 │　1   　│　　　│　　　　│　　　　　│　　　│

└────┴────┴───┴────┴─────┴───┘

こんな感じでLDTが作られる。
仮にこのLDTで0xC0000から始まる64KBのセグメントを二つ作るとしよう。

┌────┬────┬───┬────┬─────┬───┐

│アドレス│LDT番号 │大きさ│開始番地│　　属性　│　　　│

├────┼────┼───┼────┼─────┼───┤

│0xB0000 │　0   　│64KB　│0xC0000 │アプリ用C │　　　│

├────┼────┼───┼────┼─────┼───┤

│0xB0008 │　1   　│64KB　│0xD0000 │アプリ用D │　　　│

└────┴────┴───┴────┴─────┴───┘

こうなる。

さて！！！！！！！！！！！！

このLDTで定義されているセグメント(0xC0000〜）を使えるのは
誰か？　誰でも使えるのか？？　いやそれでは困る。

そこで、各タスクを管理しているTSSに、このLDTを使ってもいいと
設定をする。このLDTを作っているのはGDTの4番である。
TSS内のldtrに4番と指定を入れると、このLDT(で定義されているセグメントのメモリエリア）(0xC0000〜0xDFFFF）は
このTSSからしかアクセスできなくなる。
（ちょっち言い方が変かな？　ldtrを4番と指定されているTSSからしかアクセスできなくなるが正しいかな






こういうことかあぁぁぁぁ！！！！！！！！！！！

27日目〜

・・・だめだ。わからんかった・・・orz

P569
うっわあぁぁぁ！
なんじゃこれは！？？　これはさすがにオイラレベルじゃわからん
よなぁ〜。（こういうことってあるんですねぇ。一番やっかいな
バグのパターンのような気がします。）

P574
黒川合再登場！
（なんだか邪悪さが増してませんか？？（笑　）

超余談ですが昔NHKでびっくりかという小学生向けの
教育番組をやっていました。（知ってる人いるかな？）
これ、けっこう斬新な手法で面白かったんですよ。理科の疑問を
普通に放送するんじゃなく、わざと一度、おねぇさんがミスを
おかすんですよ。するとそこにメチャモンというイジワルな
電子妖精？が現れて、おねぇさんのミスや誤認識にツッコミを
入れ、チャカして帰ってゆく。おねぇさんはそれがくやしくて
もう一度調査再開！というパターン。
これでおもしろかったのは、おねぇさんの間違いです。決して
おねぇさんがアホなので間違うのではないということ。間違った
認識をしてしまうことにも「なるほど」と思えるような配慮が
なされていました。この手法だと、最後には正しい答えが出て
きますが、「よくある誤解や間違いはなぜ起こるのか？」という
ことも同時に教えてくれるんですよねぇ。
そういう意味ではこの本の手法とも通じるところがあるなぁと、今ふと思ったと。
・・・いや、この時々登場する黒川合がどんな顔だろうと考えていたら、メチャモンの顔を思い出したと。ただそれだけであるんす・・・。


P576
・・・なっるほどなぁ。
「OSが使うメモリ」には手を出せないけど、「アプリが使うメモリ」には
「アプリが書き込める」から、当然よそのアプリのデータを壊せると・・・。
これはどうやってガードするんだろう？
たとえば、2005セグメント（アプリ1のデータ）は、1005セグメント（アプリ1のコード）から
しかアクセスできないとか、そういうスイッチがあるのかな？？

P576
むむむ？　LDTとな？？？

あ”っーーーーーー！！！
思い出したぞこれ！？
たしかこれ、1巡目でわからなかったところじゃなかったっけ！？？
クソ！　こんどこそ！！！
そんなわけで、ちょっと戻ってチャンと整理してみよう！

26日目〜

GUIのチューニングですね。
確かにforとかって簡単に書けるんでついなんにも考えずに
使っちゃうんですけど、入れ子にするとすぐに数万回になって
しまう。こういうチューニングは重要です。


メモメモ！
xxx & ~3　　というのは、3のビット反転の意味。



うーん・・・4の倍数かぁ。
これはすごく良くわかるんだけど、生意気ながらなんとなく
好みじゃないなぁ。なんかもうすこしうまい方法ないかな・・・。

座標や幅が適当でも同じくらいの効果を上げる方法、ないかな〜？
↑自分で改造する時用のメモですよん。


P553
コンソールの閉じ方。
うん。特に難しいことはないんだけど、なんつーか、いつのまにか
凄く「理屈」が通るようになってますよね？
まずアレして、次にこれし、最後にそれをする。で、閉じるときは
これを逆にしていけばいいと。
あったりまえかもですが、このアタリマエができるようになるまで
ってのは大変でしたよねぇ。
プログラミングにかぎらず、
「あたりまえはすごいことなのだ」
ということを忘れずに日々をすごそうと思う今日この頃・・・(^^

P562
むむむむ？？？？？
最初、このncstの使いどころがよくわからんかったのだが。
あれかな？　Linuxとかで使う、　vi &　とかと同じことかな？

・・・しかもなんだがバグが出ているぞ？(^^;

また明日〜らしいが、ちょっとコードを読んで考えてみよう。

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

25日目〜

うーむ・・・
あの部分はちょっとパズルを解いてる場合ではないので
はずかしながら「ま、そういうことらしい」でお茶を濁します(^^;
（いずれ検証＆整理できたらいいなぁ）

P527
コンソールの複数化ですな。
・・・あっれえぇ？？？？？
P528のソース。ソースの意味はもちろん解るんだけど、そもそも
なんで最初から構造体に内臓しなかったんだっけ？
ちゃんと理由があったよね確か？？

え〜っと・・・どこだったっけ・・・

あったあった。P403〜P404。この時は、

• アプリケーションがAPIをコールしたい。
  
• アセンブラであるasm_cons_putcharをコールする
  
• コールされたasm_cons_putcharはレジスタに与えられたパラメータをPUSHしてスタックに積み、cons_putcharをコールする
  

・・・あれれ〜？　やっぱよくわからないなぁ。
あれかな？初期の頃はややこしくなるので、あえてメモリに書き込む
というベタな方法を取っただけなのかな？？
まあいいや。とりあえずこの新しい方法のほうがなんかピンと
くるし疑問もないわけだし。

P530
なーるほど。どのアプリを起動しても1003と1004を自分のタスクの
セグメントとして初期化しちゃんだもん。そりゃ暴走するよね？
なので各アプリがおのおの自分が使うセグメントをちゃんと
独立して初期化するようにすると。納得納得！

P532
ふむふむ。これも納得納得！

P536
なっるほどなぁ。これも確かに言われてみればまったくその
通りですよね。
単純ではありますが、なんというか、こういうマルチタスク
（並行処理）だからこそ、初期化などの順番をしっかりOS側で
管理しないといけないんですねぇ。

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