16日目（マルチタスクの続き）
mtask.cの大改造。
（bootpack.cもウィンドウが増えるところが大改造）
haribot13aはbootpack.hの/* mtask.c */（構造体を追加）以下を修正。
本書には記載がないが、CD-ROMのデータだとその後、
extern struct TIMER *mt_timer;
void mt_init(void);
void mt_taskswitch(void);
を
extern struct TIMER *task_timer;
struct TASK *task_init(struct MEMMAN *memman);
struct TASK *task_alloc(void);
void task_run(struct TASK *task);
void task_switch(void);
にしている。
mt_timerをtask_timerに置き換えたためだが、自分にはそこまで読み取れなかった。
void HariMain(void)の前も追記に注意。
void task_b_main(struct SHEET *sht_back);
と、struct TSS32の項目と、次の
void task_b_main(struct SHEET *sht_back);
を削除。
timer.cも修正が必要なのを忘れない。具体的な修正が本書に記載されてないので、エラーで気づいた。
mt_timerをtask_timer、mt_taskswichをtask_swichにする。
最初で苦労したら、harib1３b以降は問題ないと思う。
だいたい記載されている通りになっている。
bootpack.cとbootpack.hの改造はセットでチェックが必要なのはいつもの通り。
あとはタイプミスとの戦い。
ウィンドウを増やすところは自分のポカミスが多くてもう無理だったので、最後はコピペに頼った。
それとtimer3など、消す必要があるところと、環境によってはカウンタ表示を%dにするのを忘れずに。
改造した後はカウントが目に見えて早くなっているのがわかる。
数え続けてしまうときは数字を通り越して記号になるしスピードも早すぎるので、正確に数字は書けない。
（一時的に止めるように改造できればいいんだけど、自分には無理）
最近のPCを使っていると処理が早すぎるので、おそらくスピードの測定はあまり意味がないんじゃないかと思う。
ここまで来ると、自分の環境ではマウスでウィンドウを動かしてもストレスがない。
進めていく上で必要な場合のみ、対応していくことにする。
疑問のまとめ（途中）
本書を読んでそういうものとして次に進んだけど、やっぱり納得できなくてもう一度調べ直したもの。
引用箇所を自分用にわかりやすくまとめています。
徐々に増やしていく予定。
●全体
言語を基準にした目次
http://hrb.osask.jp/wiki/?prog_index
前に出てきた命令なんかを忘れたときに見返すとやりやすい。
●2日目
ADD CX, 0x1234 は 81 C1 34 12 という４バイトの命令だが、
ADD AX, 0x1234 は 05 34 12 という３バイトの命令。
機械語に直してみると本当にそうなってる。
1234が34 12になってしまうのと同じように、そういうものらしい。
nasmでコンパイルしてみるとわかる。
http://road-of-os.blogspot.com/2007/10/2makefile1.htmlを参照
●4日目
（http://hrb.osask.jp/wiki/のq_aから抜粋）
＜問い＞
write_mem8という関数をアセンブラで作っていますが、MOV ECX,[ESP+4] MOV AL,[ESP+8]というところが分かりません。
なぜ[ESP+4]にアドレスが入っていることが分かったのでしょうか?
そしてなぜ、[ESP+8]にデータが入っていることが分かったのでしょうか?
また、p.70に「C言語でwrite_mem8が使われると・・・そして、その時に指定された数字はメモリにメモしてありまして、それぞれ
1番目のもの:[ESP+4]
2番目のもの:[ESP+8]
3番目のもの:[ESP+12]
4番目のもの:[ESP+16]
とありますが、コレは
1番目にVRAMのアドレス、
2番目に15、
3番目にまたVRAMのアドレス、
4番目に15ということでしょうか?
そして値が4増えていっているのは32ビットモードだからでしょうか?
＜回答＞
簡潔に言えば、なぜ分かったのかというと、tolset内のコンパイラは自分で（＝著者自身が）作ったコンパイラだからです。
自分で作った以上、メモリのどこに格納されるような機械語になるかは当然分かっていたわけです
（まあ他の人が作ったコンパイラもたいていは同じですが）
そして[ESP+4]と[ESP+8]についてはそのとおりですが、今回のwrite_mem8には3番目や4番目の数値はないので、[ESP+12]や[ESP+16]に書かれている値がどんなものかはわかりません。
値が4ずつ増えるのは、そうなるようにコンパイラを作ってしまったからというだけの理由で、32bitモードかどうかは直接は関係ありません
●12～13日目
割り込みハンドラ、FIFOバッファって何だっけ？
FIFOの基本的な説明は6日目に戻って読む。
（ファイルの分割についても6日目、結構重要な日）
さらに詳細は7日目。
FIFOについては以下の説明が詳しく、わかりやすい。
http://bttb.s1.valueserver.jp/wordpress/blog/2018/01/01/makeos-7-2/
FIFOバッファそのものの詳細は以下。
（30日本を読んでる方なのでわかりやすい）
http://uchan.hateblo.jp/entry/2019/05/03/220443
●15日目
「*8」の正体
現在動いているタスクの GDT番号ｘ8倍（←ここがインテルの仕様）
http://osjisaku30.g.hatena.ne.jp/bluespear/20060812
https://yuyubu.hatenablog.com/entry/2018/06/07/30%E6%97%A5OS%E8%87%AA%E4%BD%9C%E6%9C%AC16%E6%97%A5%E7%9B%AE
selはGDTの番号のこと
https://kobapan.hatenadiary.org/entry/20090518/1242644719
15日目（おまけ：実機での起動）
USBメモリでブートする実機での起動がどうしてもできず諦めかけていたが、なんとか見つけた。
以下を参照して、ipl10.asmにそのままコピペした。
とても丁寧に解説されていてとてもありがたい。感謝です。
しかし内容は、自分の頭では理解できなかった…そもそもipl10.asmの存在をすっかり忘れていた。
また改めてこの辺りの章を読み直したい。
さっそく自分の環境で別フォルダ（tolset/haribote_jikki）を作成し、そこに現在Haribote OSを作成しているファイルを全部コピーし、ipl10.asmだけは中身を上記の内容にコピペする。
これでいつも通りにimgファイルを作成。
ddコマンドでUSBメモリに書き込む。
ずっとここで引っかかっていたのに気付いていなかった。
USBメモリに書き込みの際の場所が違ってたのと、あとはbsの値とsyncを入れるのが正解だったらしい。
起動可能なUSBメモリを作成できたコマンドは以下の通り。
$ sudo dd bs=4M if=haribote.img of=/dev/sdb && sync
自分のPCのBIOSをレガシーモードにして、USBメモリから起動すればHaribote OSが起動する。
ちなみにUSBメモリの内容をQEMUで起動するときは、
$ sudo qemu-system-x86_64 -m 1024 -hda /dev/sdb
で起動できた。
実機での起動はいろいろ試した結果なので、正直どうしてこれが良かったのかが不明。
なぜimgファイルの書き込み先を、USBメモリのパーティションでなく本体そのものを指定しなければいけなかったのか、syncを付けたのが何故正解だったのか、とか。
（他の起動ディスク作成の時はそんなことはなかった気がする）
それにもしかするとUSBメモリ本体の相性もあるのかと、いくつか別のものを使ってみたりもした。
フォーマットの方法もいじってみた。
だが結局、USBメモリ自体には罪はなかったようだ。
書き換えたipl10.nas自体は全く問題ないので、あとは使うPCに合った方法を模索するしかなさそうだ。
とにかく、これで今後は実機での確認もできるようになる。かなり楽しくなってきた。
今回参照させて頂いたサイト:
https://qiita.com/machine_engineer/items/9b0c74f59aba9c0a2ed1
https://yohgami.hateblo.jp/entry/20171210/1512888735
https://freepc.jp/bootusb
