問題タブ [real-mode]

C でブートローダーを作成するとします。グローバル変数を作成するとどうなりますか? その論理アドレスは何ですか？物理アドレスにどのように対応していますか? たとえば、文字列（グローバル）を作成した場合

セクションにs保存されているのは正しいですか？.data物理アドレスとs論理アドレスは何でしょうか? このアドレスを互いに対応させるために、追加の作業を行う必要があります。

私の OS は Linux で、コードを次のようにコンパイルします。

boot.Sいくつかのレジスタを初期化し、c コードを呼び出す場所です。

mmain-- C コードで機能します。私のリンカースクリプトは次のとおりです。

私はアセンブリが初めてで、私の仕事はファイルの名前を読み取り、このファイルから偶数行を出力することです。新しい行を見つける方法がわかりません。キャリッジリターンであるため、13と10をcmpする必要があることは理解していますが、失敗しました。どんな助けでも大歓迎です。これが私がこれまでに持っているものです：

x86 マシン用の小さなオペレーティング システムを作成しようとしていて、かなり最小限のブートローダーのコードを書き始めました。私が作成したブートローダーは非常に単純で、マスター ブート レコードの直後にあるセクターからスモール セカンド ブートローダーをロードし、そのコードにジャンプします。マスター ブート レコードのブートローダー コードは正常に動作しているようですが、第 2 段階のブートローダーにジャンプしようとすると問題が発生します。この第 2 段階のブートローダーは、成功を示す文字 (文字 S) を出力することになっているため、コードが実行されていることがわかります。問題は、画面に何も表示されないことです。そのため、第 2 段階のブートローダーが実行されていないと思われます。私が使用したコードは次のとおりです。

マスター ブート レコードのブートローダー:

第 2 段階のブートローダーのコード:

このコードは、次のコードを使用してコンパイルされ、ドライブに書き込まれました。

このコードが書き込まれたデバイスは、16 GB の USB ドライブでした。このコードの起動に使用したコンピューターは、USB からの起動をサポートしており、他のハード ドライブと同じように起動します。コードが実行されないように見える理由は何ですか?

ベース インデックス式を使用して 16 ビット リアル モードでメモリを操作しようとすると、コンパイル エラーが発生します。

でコンパイル

次のエラーが発生します。

16 ビット リアル モードでも、これは有効な構文だと思いましたか?

General Problem

I've been developing a simple bootloader and have stumbled on a problem on some environments where instructions like these don't work:

Each one of these happen to involve indirect near CALL to absolute memory offsets. I have discovered that I have issues if I use similar JMP tables. Calls and Jumps that are relative don't seem to be affected. Code like this works:

I have taken the advice presented on Stackoverflow by posters discussing the dos and don'ts of writing a bootloader. In particular I saw this Stackoverflow answer with General Bootloader Tips. The first tip was:

1. When the BIOS jumps to your code you can't rely on CS,DS,ES,SS,SP registers having valid or expected values. They should be set up appropriately when your bootloader starts. You can only be guaranteed that your bootloader will be loaded and run from physical address 0x07c00 and that the boot drive number is loaded into the DL register.

Taking all the advice, I didn't rely on CS, I set up a stack, and set DS to be appropriate for the ORG (Origin offset) I used. I have created a Minimal Complete Verifiable example that demonstrates the problem. I built this using NASM, but it doesn't seem to be a problem specific to NASM.

Minimal Example

The code to test is as follows:

I build both an ISO image and a 1.44MB floppy image for test purposes. I'm using a Debian Jessie environment but most Linux distros would be similar:

I end up with a floppy disk image called floppy.img and an ISO image called myos.iso.

Expectations vs Actual Results

Under most conditions this code works, but in a number of environments it doesn't. When it works it simply prints this on the display:

BMMME

I print out B using a typical CALL with relative offset it seems to work fine. In some environments when I run the code I just get:

B

And then it appears to just stop doing anything. It seems to print out the B properly but then something unexpected happens.

Environments that seem to work:

• QEMU booted with floppy and ISO
• VirtualBox booted with floppy and ISO
• VMWare 9 booted with floppy and ISO
• DosBox booted with floppy
• Officially packaged Bochs(2.6) on Debian Jessie using floppy image
• Bochs 2.6.6(built from source control) on Debian Jessie using floppy image and ISO image
• AST Premmia SMP P90 system from mid 90s using floppy and ISO

Environments that don't work as expected:

• Officially packaged Bochs(2.6) on Debian Jessie using ISO image
• 486DX based system with AMI BIOS from the early 90s using floppy image. CDs won't boot on this system so the CD couldn't be tested.

What I find interesting is that Bochs (version 2.6) doesn't work as expected on Debian Jessie using an ISO. When I boot from the floppy with the same version it works as expected.

In all cases the ISO and the floppy image seemed to load and start running since in ALL cases it was at least able to print out B on the display.

My Questions

• When it fails, why does it only print out a B and nothing more?
• Why do some environments work and others fail?
• Is this a bug in my code or the hardware/BIOS?
• How can I fix it so that I can still use near indirect Jump and Call tables to absolute memory offsets? I am aware I can avoid these instructions altogether and that seems to solve my problem, but I'd like to be able to understand how and if I can use them properly in a bootloader.