「PC」カテゴリーアーカイブ

Hyfaxのこと-こんにちはTTS

x86リアルモードでモニターを作ろうシリーズです。
まずshell機能を独立させるかMonitorに取り込むかという問題ですが、shellとして独立させることにしました。そのうえ常駐します。このため、Monitorとほぼ同様のメモリに展開されます。アプリケーションとは完全独立です。
shellはTiny Thin Shell、小さい最低限のシェルということでTSSという名称にしました。

TTS本体

TTSはline_input(1行入力)を行います。
次にパースしたトップの文字列をファイル名とみなしてMonitorに実行依頼をします。
大枠で言うとこれだけです。

split処理

パース処理についてもちょっと触れておきますね。パースとか言ってますけど、内容はsplitです。入力された文字列を空白を区切り文字として複数の文字列に分解するアレです。データ構造はこんな感じ。

先頭にアドレス配列があり、アイテム数を持っていてこれで管理します。
splitのコードはこちら。

83形式編集処理

最後は83形式に変換する関数です。
『APP.BIN』の形式を『APP BIN』の11文字にします。

主要な関数は以上になります。
これらをうまく組み込んでTTSは成り立っています。

実行結果図

実行結果はこんな感じになります。

所感

セグメントが辛かったです。かつてセグメントが面倒臭いとか、厄介だとかいろいろ話は聞いていたのですが、思っていたより10倍も面倒くさかったなぁ。
特に文字列が複数セグメントに設置されているような場合、セグメント合わせに多大な時間がかかることがわかりました。

元日そうそう丸一日セグメントと格闘してしまいました。

はい、今日はここまでです。お読みくださりありがとうございました。

このソースはgithubで公開しています。よろしければどうぞ。
https://github.com/CbWB-Inc/software/tree/main/laboratory/lab02/hyfax-03-hello-tts

《2026/01/02 06:12:12》

Hyfaxのこと―Shellへの遠い道(2)

x86リアルモードでMonitorプログラムを作ってみようの、第何回目だっけ?
よくわからなくなってますが、始めます。

一応ね、shellからコマンドを実行するところまで作ってみたんですよ。KBからファイル名を入力すると、そのファイルを実行するっていう感じで。shellの対話環境の基礎的な部分です。でもね、なんか気に入らないという。
実行結果はこんな感じです。

コマンドを打ち込むと内部コマンドならそれを実行(ただし現状では内部コマンドないので処理なし)、違うならファイルを検索して見つけたらロードして遷移です。

ただ記事を書く気にどうしてもなれなかったんですね。もやもやしてて。
構造はこんな感じでした。

①のファイルの実行は仕方ないです。Boot1からMonitorを呼ぶ経路は一つしかないし、クリティカルパスなので外せない。でもね②と③が気に入りません。
まったく同じ機能、ファイルを探して、見つけたら読み込んで、そこに遷移するってのが2か所にある。もやもやもや。

で、結局役割分担を間違えているんじゃないかと思ったわけです。こうなる方がいいんじゃないかと。

shellはコマンドを受け取って最低限の動作をする。ファイルの検索、ロード、遷移はMonitorに任せる。内部コマンドの時だけ自分で実行する。
きれいじゃないですか?

というわけで作り直しです。一応作ってしまったものはもったいないので、懺悔と供養のために公開しちゃいます。
https://github.com/CbWB-Inc/software/tree/main/laboratory/lab02/hyfax-02-hello-tts-X

作る前にきっちり設計しようね!

というお話でした。

《2026/01/01 3:23:12》

Hyfaxのこと―Shellへの遠い道

MONITORが動くようになりAPP実行から終了までできるようになりました。でもそれだけです。まだ入力とかもほとんどできません。プログラム名の入力→実行とか出来るようにしたいな~……。

というわけで、まずはshellを目指すのでした。これがないとHyfax君と会話できないし♪
shellといっても超簡易版です。最初ですんで何かキーを押したら反応が返ってくる、それくらいのやつ。

なにはともあれechoの実装

echoから作ります。shellに組み込む前に動作確認ですね。せっかくAPPが動くようになったんで、APP内で作って動作チェックして、それからshellとして取り込みましょう。
ドライバのソースはこれ。

本体がこちら。

実行結果

ちゃんと返ってきてます。これで勝ち確ですよね。アプリ名を入力して、前回作ったapploadに渡せば実行できる流れです。とはいえ今はappに居る関係上、このまま実行するとアドレスが被るんで動かないんでしょうけれども。動かすにはもう少し調整が必要です。(今回はやりません。)

履歴機能とか

コマンド(らしきもの)が入力できるようになると、欲しくなってくるのが履歴機能です。command historyですね。以前打ち込んだ内容を↑キーとか↓キーで表示してくれるやつです。プログラミングの練習がてら上下カーソルキーで文字列を変更するプログラムも書いてみましょう。

実行確認用ドライバのソースはこれ。

本体のソースはこれです。

実行結果はこちら。

上下キーでone、two、three、fourが切り替わります。

そして1行入力へ

echoとhistoryが形になりました。次にこれを悪魔合体させて1行入力を作りましょう。
例によって確認用ドライバのソースはこれ。

本体のソースはこちら。

上下キーで履歴の内容を表示、文字入力可能でエンターキーで確定して戻ります。
戻ったらバッファの内容を表示して文字数、バッファをクリアしています。
実行結果はこちら。

履歴を切り替えてバッファに反映、文字入力をバッファに反映、履歴と文字入力を共にバッファに反映、それぞれできています。
追加機能として,tabキーで現在の履歴を即時反映させます。直前のコマンド表示させるのに上下キーで上って降りてなんてしたくないですから。

(tabが素通しで文字化けしたんで機能を得割り振ったなんてことはないですよ?
本当のところは、どう、なのかですか?
禁則事項です♪)

shellへの遠い道

これで文字列を入力することができるようになります。受け取った文字列をコマンドとして実行したり処理を振り分けたりできるようになるということですね。

現状ではまだ本体に組み込みません。MONIOTRにshell機能を持たせるか、shellとして独立したapp扱いするか決めかねているからです。それによってメモリ配置も考え直す必要があります。今後の宿題ですね。

今回はここまでです。お付き合いありがとうございましたm(_ _)m

この連載の成果物はgithubに公開しています。よろしければどうぞ。
https://github.com/CbWB-Inc/software/tree/main/laboratory/lab02/hyfax-01-long-road-to-shell

《2025/12/28 15:34:41》

Hyfaxのこと(8)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の8回目です。boot0→boot1→monitorとやってきて、monitorに機能を実装しました。今回はmonitorからappをロードし実行する部分です。

アプリのロードと起動

実はアプリのロードと起動って、実を言うともう完成してるって言ってもいいんですよね。そもそも既にあるboot1の機能は

①『MONITOR BIN』をルートディレクトリから探す
②見つかった『MONITOR BIN』をメモリに読み込む
③読み込んだメモリに制御を移す

という処理をやっているわけです。んじゃmonitorは何をするのかというと

①『APP BIN』をルートディレクトリから探す
②見つかった『APP BIN』をメモリに読み込む
③読み込んだメモリに制御を移す

何のことはない、ファイル名が違うだけなんです。(厳密に言うと、読み込むメモリの位置も違うんですが。)そこだけこちょこちょっと変えれば完成してしまうのですね。
ただ、boot1をまるっとコピーして必要な部分だけ修正するのは楽なんですが、例によって「ほとんど同じコードがあちこちに存在する」というのがね。背筋がぞわぞわしてくるので関数化してしまいます。
該当部分をloadapp.asmにくくりだして修正を加えます。
axにファイル名、es:bxに読み込むエリアのセグメントとオフセットを指定します。

こうするとboot1.asmがどうなるかというと、こうなります。すっかすかです。

monitor.asmにもloadappを呼び出す部分を追加します。

実行結果はこちら。

monitorからのHello、appからのHello、Monitor内・App内で実行したSyscallの結果が確認できます。

終わりに

8回にわたり続けてきました『Hyfaxのこと』もこれで一区切りです。この後は文字入力を可能にして、簡易シェルを作成し、複数アプリを実行してもよし、マルチタスクに挑戦してもよし。ロングモードに移行してもよしです。望むままの世界が開けています。

さて、名残は尽きないものの、皆様の開発ライフに幸が多からんことを祈りつつ、この辺で終わりにしたいと思います。
お付き合いありがとうございました。

この連載の成果物はgithubに公開しています。よろしければどうぞ。
https://github.com/CbWB-Inc/software/tree/main/laboratory/lab02/hyfax_base

《2025/12/21 1:08:21》

Hyfaxのこと(7)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の7回目です。前回まででboot0、boot1を経てmonitorを起動するところまでできました。やっとmonitor本体のお話ができます。
今回はmonitorにSysCallを導入したいと思います。Linuxでも使われている仕組みで、「直接BIOSを呼ばない」ための約束事です。なんかかっこいいですよねw

本格的に機能として実装しようとすると多岐にわたるのですが、今回は最低限、すぐに使うものだけを実装しようと思います。

HyfaxのSysCall

実装にはint 0x80割り込みを使います。定番だそうなのでそれに乗っかった感じです。
into 0x80を実行するとソフトウェア割り込みが発生し、事前に登録されたハンドラに制御が移り、実行後に戻る形ですね。

HyfaxのSysCall ABI

ABI(Application Binary Interface)はバイナリ同士が守る約束事です。APIがソースコード上の約束事(関数名、引数、型など)であるように、ABIは実行時の約束事(どのレジスタに何を入れるか、どこに戻り値が来るか)になります。

今回は5つの機能を実装します。

AH機能引数戻り補足
20hwriteDS:SIなし文字列出力
22hgetkeyなしAL一文字入力
23hputcharALなし一文字出力
24hnewlineなしなし改行
26hrebootなし戻らない再起動

実装

はい。実装です。こんな感じにしてみました。

実行結果はこんな感じになります。

なんだかそれらしくなってきましたね♪

さて、今日はここまでです。やっと終わりが見てうれしい限りです。

《2025/12/19 3:01:43》

Hyfaxのこと(6)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の6回目です。今回は予告通りFATクラスタチェーンの追跡を取り込みたいと思います。

クラスタチェーン

FATはクラスタという単位で管理されています。クラスタは標準で4セクタ=0x800Byte=2048Byteになります。ここで、

  • もしすべてのファイルサイズが2014Byte未満だったら
    この場合は管理が簡単で、ディレクトリ管理領域にあるファイル名と開始LBAだけあれば内容にアクセスできます。
  • もしファイルが1回書いたら消せないとしたら
    この場合もファイル名と開始LBAがあればファイルにアクセスできます。

ところがわたしたちのやりたいことは、ファイルのサイズが自由に変えられて、削除追加ができることなんですね。例えば2048ByteのファイルAとB、4096ByteのファイルCがあったとします。ファイルA、Bと追加した後ファイルAを削除し、ファイルCを追加すると木のことを考えてみます。

ファイルAとファイルBを空きディスクに追加します。

すると感じになります。

次にファイルAを削除するとこう。

ここにファイルCを追加すると、空きエリアをできるだけ少なくするように(言い換えると効率的にディスクを使うために)ファイルCを分割して格納することになります。

結果としてディスクにはこのように格納されることになります。

このように異なるサイズのファイルを削除追加できるようにすると、場合によってファイルが分割され泣き別れになって格納されることになるわけです。このような場合、ファイルの先頭とサイズだけわかっていても全体を扱うことができません。ファイルが分割されたときに、その先がどこにあるかを記録しておく必要があります。これがFATです。FATでは特定のクラスタがどのクラスタにつながっているかが記録されています。開始クラスタから終端クラスタまでの単方向リストです。
あまりいい例ではないのですが、何度か見たディスクイメージのダンプを覗いてみます。

ディレクトリ領域は0x110800から始まります。最初のエントリはボリュームラベルです。『MONITOR BIN』のエントリは0x110820から始まり、開始クラスタが0x0002(エンジ色の部分)サイズが0x000008c5Byte(水色の部分)だとわかります。0x08c5=2245なので1クラスタを少し超えています。
次にFAT1を見ます。FATは2バイト=1エントリで、ゼロオリジンなので0x0002クラスタに対応する箇所は0x100804(エンジ色の部分)になります。そして1クラスタに入りきらないので次の空きクラスタに行くのですが、この例では隣が開いていたみたいでクラスタ0x0003に続いています。クラスタ0x0003ですべて格納できますのでクラスタ0x0003に続きはなく0xffff(EOF)で終了しています。
『MONITOR BIN」の次のファイルは『APP BIN』なのですが、同様に0x0004クラスタと0x0005クラスタの2クラスタ使用して格納されていることがわかります。

このような構造になっているのですが、使い方はそれほど複雑ではなく、ファイルの内容を読みに行くときにクラスタが終端ならばそこで終了、先があるなら先を読む。これを終端になるまで繰り返す。
言葉にしてしまえばこれだけなんです。

実装

コードにするとこんな感じになります。
前回のfind_dir_ent:から先を修正したものになります。

ね?めんどくさいでしょ?

さてキリがいいところで今日はここまでです。実行結果は前回、前々回と変わらないので載せません。でも『結果が同じことを確認する』ことができるだけで、言い換えれば『ゴールが明確になる』だけで、かなり気持ち的に楽になります。

次回は『MONITOR BIN』に機能を追加しようかなとか思ってますが、どうなるかわかりません。未来のわたしに聞いてください♪

Hyfaxのこと(5)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の5回目です。前回ではBOOT1.BINが起動するところまでを作成し確認しました。今回はBOOT1.BINにディレクトリ検索機能とFATチェーン追跡機能を追加してBOOT1.BINを完成させたいのですが、果たしてうまく事が運ぶかどうか。不安でいっぱいです。

BOOT1.BINの機能

BOOT1.BINはVBRに置かれ、MBRにあるboot0.binからメモリに読み込まれ実行されます。そしてFAT16ファイルシステム内にあるMONITOR.BINを検索して読み込み、さらにこれを実行します。MBRは完全固定で、VBRは半分ほど固定でディスク内に配置されるので、読み込む際に考慮する点は多くなく、というかとても少なく、ある意味LBA固定で作成することもできます。MONITOR.BINもLBAを固定で済ますこともできないわけじゃないです。というか、前回それをやりました。が、ご存じのようにファイル内にはいくつもファイルを置くことができますし、並び順も固定ではありません。なのでFAT16ファイルシステムを使うのであれば(言い換えれば使うときに便利にするためには)、手順を踏まなければいけません。

ファイルシステムを使うからどこにMONITOR.BINを置いてもいいかというと、そうはいきません。ブートプログラムはサイズ制限が厳しいのでMONITOR.BINはルートディレクトリに置くことになります。BOOT1.BINはルートディレクトリ管理領域からMONITOR.BINの開始クラスタ番号とサイズを読み取り、メモリに読み込んで実行することになります。

ディスクイメージダンプ

ここでもう一度ディスクイメージのダンプを見てみます。

ルートディレクトリの管理領域は0x110800Byteから始まります。数字の羅列でなにがなにやらなんですが、その右側にあるASCII表示を見ると、『MONITOR BIN』『APP BIN』『APP1 BIN』……とどこかで見たような名前があります。そうファイル名です。ディレクトリエントリは1エントリ=32Byteでファイル名、属性、開始クラスタ番号、サイズ等を持っています。最大エントリ数であるROOT_ENT_CNT(0x0200)個並んでいる中から、お目当てのファイル名を探し出して開始クラスタ番号、サイズを取り出し使用するわけです。
ディレクトリエントリの構造はこんな感じ。この例だと『MONITOR BIN』の開始クラスタは0x0002、サイズは0x000008c5ですね。(注:リトルエンディアン)あ、FAT16前提なので上位クラスタ番号は使いません。

実装

前々回DIR_START_LBA、DATA_START_LBA、ROOT_ENT_CNTを保存しました。
①DIR_START_LBAから32Byteずつ取り出し
②先頭の11文字を照合して
③目当てのファイルだったら
④下位クラスタ番号とサイズを取り出し
⑤クラスタ番号からLBA値を算出し
⑥DATA_START_LBAから始まってその値にあたる部分からファイルサイズだけ読み込む

という実装になります。うむぅ。FATのクラスタチェーンの話は次回ですね。今回は連続して置かれているだろうことを信じてサイズをそのまま使いましょう。(今回の例ではクラスタが連続していないということはあり得ないんですけどね。)
検索処理をコードにするとこんな感じになります。
前回のコードのFILEのLBAを算出する部分とファイルサイズ・セクタ変換する部分をまるっと置き換えると動くはずです。

これを見て『なんをしてるかわかんな~い』と思ったあなた。悲観する必要はありません。書いたわたしが今そう思ってます。書いた時点では理解していても時間がたつと忘れます。ホント。コメント大事です。きっぱり。

実行結果

一応実行結果もあげておきますね。

まぁ、前回と変わらないんですけどねw
とはいえゴールが明確に示され、達成がはっきりわかるのはいいことです。うんうん。

さて、今回はここまでにします。次回こそラスボス感のある掛け算七の段こと、FATクラスタチェーンの追跡を実装しようと思います。
お疲れさまでした。

《2025/12/14 17:35:29》

Hyfaxのこと(4)

x86リアルモードでモニタプログラムを作ろうの第4回目です。今回はブート処理の2段階目、VBRからの起動になります。
前回、boot1.asmで使用するであろう数値群をあらかじめ用意したので、モニタプログラムを起動することだけなら簡単にできます。ちょっと重複しますが確認しておきますね。

①MBRからVBRのLBAを取り出して読み込み遷移する。
②BPBから必要な数値を得る。
③FAT開始位置を得る。
④DIR領域開始位置を得る
⑤DIR領域からファイルの開始LBAとサイズを得る。
⑥サイズとFATを比べながらファイルを読み込む
⑦ファイルに遷移する。

ざっくり言うとこういう流れになります。①②はboot0.asmでやってますので、boot1.asmは③~⑦をやることになります。盛りだくさんですね。
FATを利用して、となるとこうなるのですが、このシリーズではファイル位置は固定ですので(作り方がいつでも一緒なので同じ位置に作られる)単にモニタプログラムを起動するだけなら、モニタの開始位置とサイズがあれば実現できます。モニタが複数クラスタにまたがったとしても、連続領域に配置されることは確定なので、FATによるクラスタチェーンも追う必要はなかったりします。
要するに突き詰めれば⑤だけあればいいことになります。
モニタプログラムは『MONITOR .BIN』という名前なので、ダンプして調べてみるとこんな感じ。

VBR領域の後、FAT1、FAT2の領域があって、その後ろにDIR領域があります。『MONITOR .BIN』はDIR領域の2番目のエントリにあって、開始クラスタは0x0002、サイズは0x000008c5となっています。(注:リトルエンディアン)
開始クラスタが2番目ということはセクタ数は0セクタ(先頭2クラスタは予約)。データ開始LBAの最初に『MONITOR BIN』ですね。
データ開始LBAは前回保存したものがあるのでそれを使うとLBAは0x08a4、バイト数で0x114800になります。
これらを踏まえてboot1.asmのプロトタイプとmonitor.asmのスタブを作ってみます。

boot1.binプロトタイプ

boot1.asmプロトタイプです。前回保存した各種数値を取り出して使えるようにしつつ、LBA0x8a4にある『MONITOR .BIN』をサイズ0x08c5Byte(5セクタ)で読込、遷移させます。

こんな感じ。

monitor.asmスタブ

monitor.asmのスタブは遷移されたことがわかるだけでいいので、メッセージを出すだけにします。こんな感じでしょうか。

実行結果

実行するとこんな感じになります。

Hello from Monitorが表示されてますね。正しく読み込まれて遷移されたことがわかります。これで一つのゴールが明確になりました。monitorを読み込んで遷移する。このゴールを崩さないように、ディレクトリエントリの検索、fatチェーンの追跡を行うことになります。

さて、そろそろいい時間なので、今日はここまでです。お疲れさまでした。
細切れにして情報量少なくなってごめんなさいです。
でもね、この程度でも書くのとってもしんどいんですよ?
ともあれ、また次回お会いしましょう。

《2025/12/14 4:59:42》

Hyfaxのこと(3)

前回boot0.asmを作ったわけですが、次のboot1.asmを作るにあたって用意しておくと多少楽になって整理がしやすい数値群があります。今回はboot0.asm側であらかじめそういった数値を用意しておこうと思います。

用意するのは
BOOT_DRIVE
VBR_START_LBA
ROOT_ENT_CNT
FAT_START_LBA
DIR_START_LBA
CLUS_SIZ
DATA_START_LBA
です。

それぞれ少し説明しますね。

BOOT_DRIVE

Bootされたドライブの値です。boot0.asm実行時にdlレジスタに渡されてきます。boot0.asmでしか拾えない値なので、保存して使いまわします。

VBR_START_LBA

文字通りVBRが開始されるLBAです。これはMBRのパーテションテーブルの中にしかないので、これまた保存して使いまわします。

ROOT_ENT_CNT

ルートディレクトリの中にいくつエントリが入るかを示します。FAT16ではROOTディレクトリがサイズ固定なので、この数値を見て最大値を算出します。BPBと呼ばれる領域に設定されています。

FAT_START_LBA

文字通りFATが解されるLBAです。計算で出します。VBR開始後、リザーブされた領域を挟んで、そのあとからFATが始まります。

FAT_START_LBA = VBR_START_LBA + BPB_FAT16.RsvdSecCnt

となります。
余談ですが、MBRはMAX512Byte、パーテションテーブルを除くと446Byte「しか」取れません。必達です。ですがVBRの方はVBRの開始からFATの開始までの領域を使うことができます。VBR_START_LBA + BPB_FAT16.RsvdSecCnt分だけ余裕があるわけです。

DIR_START_LBA

ディレクトリ領域が開始されるLBAです。FATの後に位置し、計算で出します。FATは2個あるので、FAT開始LBAのあと、FAT領域を2つ分追加した後がこの値になります。

DIR_START_LBA = FAT_START_LBA + BPB_FAT16.FATSz16 * BPB_FAT16.NumFATs

CLUS_SIZ

クラスタの総バイト数です。標準では4セクタ=1クラスタ、512Byte=1セクタなので0x800Byteになるはずです。

CLUS_SIZ = BPB_FAT16.SecPerClus * BPB_FAT16.BytesPerSec

DATA_START_LBA

DIR_START_LBAにディレクトリエントリの分の領域を要した後がデータ開始LBAになります。

DATA_START_LBA = ROOT_ENT_CNT * 32 / BPB_FAT16.BytesPerSec

boot0.asmの修正

boot0.asmにデータ保存用のコードを入れていきます。主処理の間にチマチマ出てきてうっとうしいし見通しが悪くなるんですが、まぁ、しかたがないですね。で、修正したソースがこれ。

あと、定義ファイルも使用しています。これですね。

これでboot1.asmを作成する準備ができました。

次回こそはboot1.asmを公開したいと思います。

《2025/12/12 22:00:47》

Hyfaxのこと(2)

このテーマを進めるにあたって、どうしようかいろいろ考えたのですが、まずはディスクイメージを作るところから始めることにしました。
QEMUでの実行ではプログラムを指定というよりディスクイメージを指定しするので、これがないと何もできません。今回はFAT16の32MByteのハードディスクイメージを作成します。

作り方はこれ。

ddでファイルのガワを作って、パーティションテーブル作って、ブート可能にして、フォーマットしてます。
まんまですねw

プログラムの方なんですが、オレオレOSというかオレオレ環境なので、どんな構成でも構わないっちゃ構わないんですが、FAT16を選択してしまった以上、決まったお作法があります。

Fat構造だとまず最初にMBR(Master Boot Record)から512Byte 読み込んで実行します。そこでパーティションテーブルを確認して、最初にブート可能なパーティションのVBR(Volume Boot Record)の位置を取り出して、そこを読み込みます。
VBRでは実行するプログラムをファイルシステムから探して読み込みます。

というような、ちょっと面倒くさいお作法になります。
都合上、MBRに置くプログラムをboot0.bin、VBRに置くプログラムをboot1.bin、ファイルシステムから読み込むプログラムをmonitor.binとしています。
アイキャッチの図の通りです。

今回はboot0.binを作りたいと思います。
これは結構楽なんですよね。なにせMBRに置いておけばあとは勝手に読み込まれて実行されるので。
まずは「とにかく動けばいいや」というコードを書いてみます。実はVBRの位置は0x800セクタ、VBRの大きさはMAX4セクタとわかっているので、パラメータを揃えて実行するだけです。
こんな感じ?

確認用に読み込んだ内容の先頭16バイトを表示しています。実行結果はこんな感じ。

ディスクイメージをダンプするとこんな感じ。

セクタ0x800、バイトで0x100000の先頭はeb 3c 90。正しく実行されてますね。

さて、骨格ができたところで肉付けを。というかパーテションテーブルをきちんと見るように修正します。パーティションテーブル、4エントリをなめて当たりを探す処理を追加です。
一気に行っちゃいます。

事項結果は前と変わらないので省略。
最後にboot0.binをディスクイメージに書き込む例を挙げて終わりにします。
パーティションテーブルより前の446バイトを書き込んでいます。

お疲れさまでした。(主にわたしが疲れてるという……)

《2025/12/3 223:41:32》