祝 60kg台！！
69.9kg
おぉぉぉ！！！
遂に、このオーダーへ！！目指せ、65kg！！だな。
さて、ここ最近は十分に時間も取れていない事もあるが、
本読んで理解に苦しむフェーズばかり。。
ハードに近い話が多いので、結構、色々調べながらで時間がかかってる。。
本の中にも色々書いてある内容に加えて、下記Web下記のページも参考に
読み進める。
まだ、いまいちよく分かっていないが、重要なのは
1. GDT/IDT（Global Descriptor Table/Interrupt Descriptor Table）
2. GDTR
3. IDTR
4. セグメントレジスタ
辺りの様だ。。
で、初めて気づいたが、このGDTってのはどうやらasmhead.nasの中にも
記載がある。。。
後、この辺りが自分としては、かなり頭がごちゃごちゃになっていたのだが、
セグメントレジスタの役割。（分かればシンプルなんだろうけど。。）
リアルモード： CS, DS, FS, ES, SSを使ってメモリアクセス
プロテクテッドモード： セグメントレジスタとGDTを使ってメモリアクセス
っていう違いがある。しかも、このプロテクテッドモードの動きがよく分からないで時間が掛かっていた。。。
まぁ、私の浅い理解は進み、当たり前の理解に徐々に近づいていってる気がする。。。
要は、セグメントレジスタが、GDT内にテーブルとして用意された各セグメントへ
のインデックスの役割をしている様で、そのテーブル内に設定されたGDT:*は64bitで
構成されており、その各ディスクリプタに対象セグメントのスタートアドレス、サイズ、
アクセス制限関係の設定等が入っているという事みたい。。。
（ここは、書く必要もないのだが、文章化する事で自分の頭を整理する理解も含まれる。。
まぁ、備忘録的な日記なんで。。）
GDT Memory
+---------+ +----------------+
Seg-reg GDT: 0 -----------> | Segment: 0 |
(index） +---------------+
| GDT: 1------------> | Segment: 1
| ‥ |
| ‥ +---------------+
| ‥
| +---------------+
+----------> GDT: n -----------> | Segment: n
+---------------+
後は、実際のプログラム上のアドレスが、このセグメント内のオフセットとして使われる事
で、アドレス変換が行われているという事らしい。。（ふむ。中々整理が難しい。。）
このGDTの先頭情報を取得する為に、GDTRにこのGDTを配置したセグメントディスクリプタテーブルの先頭アドレスとそのサイズ（リミット値）をLGDTコマンドにて48bitの形で渡す。
ここは、asmhead.nasの下にある部分を、ちょっとだけ手を加えた部分が
個人的には分かりやすかったので、参考までに載せておく。
（dsctbl.cで行われているものと同じ内容だと思うが、アセンブラの方が
より直接的で、個人的には理解するのに役立った。。）
ALIGNB 16, DB 0 ; NASMでは警告が出るので修正
GDT0:
TIMES 8 DB 0 ; NASMでは警告が出るので修正
DW 0xffff,0x0000,0x9200,0x00cf ; 読み書き可能セグメント32bit
DW 0xffff,0x0000,0x9a28,0x0047 ; 実行可能セグメント32bit（bootpack用）
DW 0
.gdt_end:
GDTR0:
DW GDT0.gdt_end - GDT0 - 1 ; 上のSegment DT のリミット値（要するにサイズ）
DD GDT0 ; ディスクリプタテーブルのアドレス
ALIGNB 16, DB 0 ; NASMでは警告が出るので修正
上記コードとは別の場所で、LDGTコマンドを実行する事でGDTRに
セグメントディスクリプタテーブルのベースアドレスとリミット値が設定され、
後は、セグメントレジスタ経由で各セグメントへアクセス可能となる。
LGDT [GDTR0] ; 暫定GDTを設定
まぁ、詳細は上にあげた参考にさせて頂いている先人様のページにある通りだが、
やはり自分の理解力の低さが悲しい。。。（時間かかり過ぎ。。）
同様に、IDTも同様の感じの様ですな。。。
一先ず、なんとなく、GDT/IDT周りのこのが理解できてきた。。。
しかし、一緒に参考にしている下記の本も参照しながらで随分助かっているのだが、
こちらはこちらで全編アセンブラで記述されているという優れもの。。。
両作者共に素晴らしいですな。
こんな私にも、OS理解へのチャンスを与えてくれる本。
本当に素晴らしいです。。。（感謝しかありません。後は、継続する自分の意思のみ）
ただ、常人ではありませんな。。。
皆様へ感謝しつつ、引き続き頑張っていこうと思う今日この頃。。
続く。。
諦めた。。。
70.5kg
前回書いた際と同じだな。
あとちょっと。。
70kg切ったらお祝いしたいな。。
（まぁ、そんなに頑張ってるわけじゃないから行かないかな。。）
さて、色々やってみたけど標準ライブラリをそのまま使うのに、
中々上手く行かなく、時間が掛かり過ぎて進まないので諦めた。
という事で、先人様のありがたいものを、そのまま使う事に決定。
（最初から素直に使っていればとも思うが、ちょっとは頑張りたくて。。）
sprintfを実装する | OS自作入門 5日目-2 【Linux】 | サラリーマンがハッカーを真剣に目指す
Makefileも合わせて、Go!!
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
gcc convHankakuTxt.c -o convHankakuTxt.bin
./convHankakuTxt.bin
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib -fno-builtin bootpack.c hankaku.c mysprintf.c
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o hankaku.o mysprintf.o
cat asmhead.bin bootpack.hrb > haribote.sys
mformat -f 1440 -C -B ipl10.bin -i haribote.img ::
mcopy -i haribote.img haribote.sys ::
qemu-system-i386 -L . -m 32 -monitor stdio -s -drive file=haribote.img,format=raw,if=floppy -boot a
QEMU 5.0.0 monitor - type 'help' for more information
(qemu)
ふむ。
久しぶりに進捗。
本にも書いてあるが、これでデバッグするのが楽になりそうだ。。
さぁ、ついにマウスじゃ！！
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
gcc convHankakuTxt.c -o convHankakuTxt
./convHankakuTxt
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib -fno-builtin bootpack.c hankaku.c mysprintf.c
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o hankaku.o mysprintf.o
cat asmhead.bin bootpack.hrb > haribote.sys
mformat -f 1440 -C -B ipl10.bin -i haribote.img ::
mcopy -i haribote.img haribote.sys ::
qemu-system-i386 -L . -m 32 -monitor stdio -s -drive file=haribote.img,format=raw,if=floppy -boot a
QEMU 5.0.0 monitor - type 'help' for more information
(qemu)
おぉぉぉ。。
マウス。。。
まだ動かないけど。。
先人の方々のお力を借りつつ本の通り進んでるだけなんで、
普通な事だけど、ちょっと嬉しい。
さぁ、いよいよ割り込み関係辺りかな。。
ここからは難易度が、更にあがっていく予感。。。
続く。。
なかなかできない。。
70.5kg.
うん。いい感じ。。
本読んでただ進めるだけなんだけど、いまいち進みが悪い。
っていうか、理解力が乏しい。。（涙）
文字列の出力関数の部分を徐々に読んで、若干個人的こんがらがっていてのを整理する事が出来た。
（自分で書いたりしてみたら、もっと大変なんだろうけど
今はコードを読んで理解できればよし。。）
次に、sprintf使う為に、ヘッダファイルを読み込んでる。。
#include <stdio.h>
まぁ、普通C言語勉強したら必ずあるやつ。
で、Go！
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib bootpack.c hankaku.c
bootpack.c:1:10: 致命的エラー: stdio.h: No such file or directory
1 | #include <stdio.h>
| ^~~~~~~~~
コンパイルを停止しました。
make[2]: *** [bootpack.hrb] Error 1
make[1]: *** [img] Error 2
make: *** [run] Error 2
あかんやん！！！（Orz...）
先人ページをみたら、ここもご自身で作ってる。
でも、何故だろう。。
標準関数を本のようにそのまま使えないのだろうか。。
また、調べるか。。
（分からなかったら、先人に従おう。。方針で！）
続く。
ノロノロと。。。
71.0kg
糖質ダイエット（without お酒（糖質オフ））と朝の散歩は続けているが、
そんな簡単に結果は出てこないよな。
でも、なんとなく糖質が恋しくなくなってきた感じがする。。
今日は体重報告だけ。。。（涙）
理解が遅い。。
71.3kg
まぁ、変わらないな。
で、いよいよFont部分なのだが、本読んでるとフォントのファイルを
コンパイルしたり、そのツールの話が書いてある。
自分の環境は、下記の先人の方の環境を使わせて頂いたものなので、
見てみると、コメントがある。
『30日でできる！OS自作入門』を macOS Catalina で実行する - Qiita
---------------上記ページから抜粋----------------
著者作成の makefont.exeの代わりに、
GDT（グローバルディスクリプタテーブル） | OS自作入門 5日目-1 【Linux】 | サラリーマンがハッカーを真剣に目指す
のページの「フォントファイルのリンクについて」を使わせて頂いた。これを convHankakuTxt.cとして作成し、これを用いて hankaku.txtを変換する。
--------------------ここまで----------------------
ありがとう先人の皆様。
Makefile内を少しだけ
----ここは先人様の通り追加------
# convHankakuTxt.c は標準ライブラリが必要なので、macOS標準のgccを使う
convHankakuTxt : convHankakuTxt.c
gcc convHankakuTxt.c -o convHankakuTxt
hankaku.c : hankaku.txt convHankakuTxt
./convHankakuTxt
--------------------------------
----------ここは自分の環境に合わせて修正----------------
bootpack.hrb : bootpack.c hrb.ld hankaku.c naskfunc.o Makefile # リンク，コンパイル
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib bootpack.c hankaku.c
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o hankaku.o
--------------------------------------------------------
（これも、ホントは分けずにできるんだろうな。。。）
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib bootpack.c hankaku.c
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o hankaku.o
cat asmhead.bin bootpack.hrb > haribote.sys
mformat -f 1440 -C -B ipl10.bin -i haribote.img ::
mcopy -i haribote.img haribote.sys ::
qemu-system-i386 -L . -m 32 -monitor stdio -s -drive file=haribote.img,format=raw,if=floppy -boot a
QEMU 5.0.0 monitor - type 'help' for more information
(qemu)
続く。
いいかげんさがねぇ。。。
70.7kg
ふむ。
油断は禁物！
という事で、怪しい場所は分かった。
要するに、asmheadでメモリに書いておいた値がおかしい為、
C言語側で使うとおかしくなる。って事。
で、恥ずかしく思いっきり間違えたものを書いてた。
（修正しておいた。）
0x0ff4: 0x0d00 （0x000d)= 3328 （14）→ ？？？（X方向の解像度で、320つまり0x0140のはず）
そう、ここ！
何故このアドレスだけ値が壊れている。。。
bootpack.cで、読めているのか？は当然、メモリの値が読めているだろうけど念の為確認。
short *tst_binfo_scrnx, *tst_binfo_scrny;
tst_binfo_scrnx = (short *) 0x1004;
tst_binfo_scrny = (short *) 0x1006;
*tst_binfo_scrnx = *binfo_scrnx;
*tst_binfo_scrny = *binfo_scrny;
(qemu) xp/100xh 0x0ff0
0000000000000ff0: 0x000a 0x0008 0x000d 0x00c8 0x0000 0x000a 0x0000 0x0000
0000000000001000: 0x0000 0x0000 0x000d 0x00c8 0x0000 0x0000 0x0000 0x0000
0000000000001010: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001020: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001030: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
あたり前だが、c言語は意図通り。
やっぱり、asmheadの中身。
なんでこのアドレスだけ。。
; MOV BYTE [VMODE],8 ; 画面モードをメモする（C言語が参照する）
MOV WORD [VMODE],8 ; 画面モードをメモする（C言語が参照する）
MOV WORD [SCRNX],320
MOV WORD [SCRNY],200
MOV DWORD [VRAM],0x000a0000
ここも、以前のデバッグ時によく分からず、色々試行錯誤している際に
残った残骸だと思うがアドレス的には問題なさそうであるが、念の為、
アクセスをBYTEもWORDも試したが問題なし。
さて、何故、0x0ff4だけ。。。
ん？？？
もしかして、以前コードの進行具合のチェッカーを入れたような。。。
MOV WORD [0x0ff4], 0x000d ; 進み具合テスト2
いた。。。。。。。😭
これかよ。。。。
という事で、チェッカーを削除（他にもない事は確認）
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib bootpack.c -o bootpack.o
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o
cat asmhead.bin bootpack.hrb > haribote.sys
mformat -f 1440 -C -B ipl10.bin -i haribote.img ::
mcopy -i haribote.img haribote.sys ::
qemu-system-i386 -L . -m 32 -monitor stdio -s -drive file=haribote.img,format=raw,if=floppy -boot a
QEMU 5.0.0 monitor - type 'help' for more information
(qemu) xp/100xh 0x0ff0
0000000000000ff0: 0x000a 0x0008 0x0140 0x00c8 0x0000 0x000a 0x0000 0x0000
0000000000001000: 0x0000 0x0000 0x0140 0x00c8 0x0000 0x0000 0x0000 0x0000
0000000000001010: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001020: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001030: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
おかえり。。。
さて、またここから始めよう。
ほんっと、進まねぇ。。
でも、ゆっくり進めば良いか。。。
ちなみに、そのまま読み進め、
まぁ、当然と言えば当然だが、ここまで二日。。（涙）
ゆっくり続けよう。。
続く。
今週も。
71.1kg
週末は少し歩いた。（ほんとに少しだけど。。）
お米も食べなかった。（毎日の２分間腹筋だけやらなかった。）
でも、これか。。
様子見じゃ。。
で、いきなりだが
$ make run
make -r img
make -r haribote.img
nasm ipl10.nas -o ipl10.bin -l ipl10.lst
nasm asmhead.nas -o asmhead.bin -l asmhead.lst
nasm -f elf32 naskfunc.nas -o naskfunc.o -l naskfunc.lst
x86_64-elf-gcc -c -g -march=i486 -m32 -nostdlib bootpack.c -o bootpack.o
x86_64-elf-ld -m elf_i386 -e HariMain -o bootpack.hrb -T hrb.ld bootpack.o naskfunc.o
cat asmhead.bin bootpack.hrb > haribote.sys
mformat -f 1440 -C -B ipl10.bin -i haribote.img ::
mcopy -i haribote.img haribote.sys ::
qemu-system-i386 -L . -m 32 -monitor stdio -s -drive file=haribote.img,format=raw,if=floppy -boot a
QEMU 5.0.0 monitor - type 'help' for more information
(qemu)
は？
もぉ。。。。
月曜の朝から、なんなの。。。
本は構造体の説明だが、それに伴い、コードが少し変更されている。
でも、それって何か難しい事してるんだっけ。。。。
bootpack.cのコードを見てみると、要するに違いはasmhead.nasでメモリ上へ
書いた情報ををC言語側から使う状態に変更している。
これが原因？？？
まさか。。。
つまり。。。。
そこに戻るのか。。。（Orz.... 一気に不安が。。。)
とりあえず、4日目の最後のものと、5日の最初のものと実行した際のasmhead.nasが
書いた情報を確認。
(qemu) xp/100xh 0x0ff0
0000000000000ff0: 0x000a 0x0008 0x000d 0x00c8 0x0000 0x000a 0x0000 0x0000
0000000000001000: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001010: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001020: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0000000000001030: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0x0ff0: 0x0a = 10 → OK.
0x0ff1: 0x00 = 0 → 多分、OK.
0x0ff2: 0x08 = 8 → OK.
0x0ff4: 0x0d00 （0x000d)= 3328 （14）→ ？？？（X方向の解像度で、320つまり0x0140のはず）
0x0ff6: 0xc800 （0x00c8）= 51200 （200）→ ？？？（Y方向の解像度で、200つまり0xc8のはず → OK）
0x0ff8: 0x000a0000 ？？？？ → OK
という事で、これが原因でしょう。
asmhead.nasを確認。
ん？？？
MOV WORD [VMODE],8 ; 画面モードをメモする（C言語が参照する）
なんだこれ。。。
これで良いのか？？
今までの格闘中に、意図せずして書き換えていたのかな。。。
時間切れ。
続く。。。
