问题标签 [real-mode]

我需要在实模式下拦截 CR0 编辑并在 CPU 进入保护模式之前执行我的代码。是否有可能，如果是，我该怎么做？

我想在不使用任何库的情况下显示寄存器 al 的值，我该怎么办？我应该使用哪个中断？我正在使用汇编语言（masm）并且我的程序处于实模式。

例如在保护模式下，我们使用 Irvine32 库：

我正在尝试学习汇编并编写引导加载程序。以下代码将软盘驱动器的内容加载到内存并跳转到它（从地址 0x1000 开始加载）。这段代码应该在屏幕上打印“X”，但由于某种原因它打印了一个空格。有人可以告诉我有什么问题吗？

假设我在 C 上编写引导加载程序。当我创建一些全局变量时会发生什么？它的逻辑地址是什么？它与物理地址如何对应？例如，如果我创建了一些字符串（全局）

我对s存储在.data部分中是否正确？什么是物理地址，s什么是逻辑地址？我们是否应该做一些额外的工作来使这些地址相互对应。

我的操作系统是 Linux，我像这样编译我的代码：

boot.S就是我初始化一些寄存器并调用 c 代码的地方：

mmain-- C 代码中的函数。我的链接器脚本是：

我是汇编新手，我的任务是读取文件名并打印该文件中的偶数行。我不知道如何找到新的线路。我知道我必须 cmp 13 和 10 因为那是回车，但我没有成功。任何帮助将不胜感激。这是我到目前为止所拥有的：

我正在尝试为 x86 机器创建一个小型操作系统，并开始为一个相当小的引导加载程序编写代码。我创建的引导加载程序非常简单，它从直接位于主引导记录之后的扇区加载一个小的第二个引导加载程序并跳转到该代码。主引导记录中的引导加载程序代码似乎运行良好，当它尝试跳转到第二阶段引导加载程序时出现问题。这个第二阶段的引导加载程序应该输出一个表示成功的字母（字母 S），所以我可以知道代码正在执行。问题是屏幕上什么都没有出现，所以我怀疑第二阶段引导加载程序从未执行过。我使用的代码如下：

主引导记录中的引导加载程序：

第二阶段引导加载程序的代码：

此代码是使用以下代码编译并写入驱动器的：

写入此代码的设备是 16GB USB 驱动器。我用来启动此代码的计算机支持从 USB 启动并像任何其他硬盘驱动器一样启动它们。代码似乎没有执行的原因是什么？

尝试使用基索引表达式在 16 位实模式下操作内存会导致编译错误：

编译

产生以下错误：

我认为这是有效的语法，即使在 16 位实模式下？

在 QEMU 中诊断引导加载程序代码？

我正在尝试创建一个最小的“引导加载程序代码”，打印字符“A”然后停止。

为此，我编写了以下 C++ 程序

首先，我在未注释内联程序集的情况下运行代码。在调试器中，我派生了操作码，并确定操作码与我的源代码中的操作码匹配。接下来，我运行带有注释的内联程序集的代码，然后生成了一个 img 文件。我使用二进制编辑器查看内容并确保它看起来像我想要的那样。最后，我运行了 qemu-system-i386.exe -fda disk.img，我希望引导加载程序显示一个大写的“A”，但实际上什么也没显示。

现在我有两个问题：

1.) 我的代码有什么问题？2.) 我该如何诊断？

我正在为教育目的编写一个小内核，并且正在考虑一种在实模式下设置堆栈的好方法。我从这里读到：http ://wiki.osdev.org/Memory_Map_%28x86%29 地址0x07E00到0x7FFFF保证可以免费使用。

因此，如果我将堆栈段设置为0x0900，这将使堆栈的范围从0x0900 << 4到0x0900 << 4 + 0xFFFF即0x09000到0x18FFF这意味着我将获得一个安全的0x10000字节的堆栈空间，对吧？

而且我可以将我的堆栈指针设置为 0，它也会在下一次推送时“下溢”到 0xFFFE？分割让我有点困惑。

这是代码的相关部分的外观：

一般问题

我一直在开发一个简单的引导加载程序，并在某些环境中偶然发现了一个问题，这些指令不起作用：

其中每一个碰巧都涉及到绝对内存偏移的间接近调用。我发现如果我使用类似的JMP表会出现问题。相对的调用和跳转似乎没有受到影响。像这样的代码有效：

我已经通过讨论编写引导加载程序的注意事项的海报接受了 Stackoverflow 上提出的建议。特别是，我看到了这个Stackoverflow的答案与General Bootloader Tips。第一个提示是：

1. 当 BIOS 跳转到您的代码时，您不能依赖具有有效或预期值的CS、DS、ES、SS、SP寄存器。当您的引导加载程序启动时，它们应该被适当地设置。您只能保证您的引导加载程序将从物理地址 0x07c00 加载和运行，并且引导驱动器编号已加载到DL寄存器中。

接受所有建议，我不依赖CS，我设置了一个堆栈，并将DS设置为适合我使用的ORG（原点偏移）。我创建了一个 Minimal Complete Verifiable 示例来演示该问题。我使用NASM构建了它，但这似乎不是NASM特有的问题。

最小的例子

测试代码如下：

出于测试目的，我构建了一个ISO映像和一个 1.44MB 软盘映像。我使用的是 Debian Jessie 环境，但大多数 Linux 发行版都类似：

我最终得到了一个名为 的软盘映像和floppy.img一个名为myos.iso.

期望与实际结果

在大多数情况下，此代码有效，但在许多环境中则无效。当它工作时，它只是在显示器上打印：

BMMME

B我使用具有相对偏移量的典型CALL打印出来，它似乎工作正常。在某些环境中，当我运行代码时，我会得到：

乙

然后它似乎只是停止做任何事情。它似乎B正确打印出来，但随后发生了一些意想不到的事情。

似乎工作的环境：

• QEMU用软盘和 ISO 启动
• VirtualBox用软盘和 ISO 启动
• VMWare 9用软盘和 ISO 启动
• DosBox用软盘启动
• 使用软盘映像在 Debian Jessie 上正式打包的Bochs (2.6)
• Debian Jessie 上使用软盘映像和ISO的 Bochs 2.6.6（从源代码控制构建）映像
• 90 年代中期使用软盘和ISO的 AST Premmia SMP P90 系统

无法按预期工作的环境：

• 使用ISO映像在 Debian Jessie 上正式打包的Bochs (2.6)
• 基于 486DX 的系统，带有 90 年代初的 AMI BIOS，使用软盘映像。CD 无法在此系统上启动，因此无法测试该 CD。

我发现有趣的是Bochs （2.6 版）在使用ISO的 Debian Jessie 上无法正常工作。当我从具有相同版本的软盘启动时，它按预期工作。

在所有情况下，ISO和软盘映像似乎都已加载并开始运行，因为在所有情况下，它至少能够B在显示器上打印出来。

我的问题

• 当它失败时，为什么它只打印出 aB而仅此而已？
• 为什么有些环境有效而有些环境失败？
• 这是我的代码或硬件/BIOS 中的错误吗？
• 如何修复它以便我仍然可以使用近乎间接的跳转和调用表来获得绝对内存偏移量？我知道我可以完全避免这些说明，这似乎解决了我的问题，但我希望能够了解如何以及是否可以在引导加载程序中正确使用它们。