【问题标题】:How can I read and store video memory in 8086 using C?如何使用 C 在 8086 中读取和存储视频内存?
【发布时间】:2021-07-04 16:38:23
【问题描述】:

我正在为我的家庭作业编写一个微型操作系统,我想保留 shell 上显示的内容(因为当我使用 shell 打开另一个应用程序时,屏幕将被它的新内容覆盖,我想恢复shell 就像返回后调用应用程序之前一样)。

我想用C语言来完成它,但我不知道如何正确使用指针来处理它。我的想法是把显存中的所有数据都读取出来,保存在一个数据结构中,然后通过重写到显存中来恢复,但是我尝试了很多方法,都不管用。

我试着写这样的函数:

void storeContents()
{
    uint16_t * ptr =0xB800;
    int cnt = 0;
    while(cnt < 80 * 25)
    {
        store[cnt++] = * (ptr++);
    }
}

我不知道这个函数是否正确,但是当我使用Bochs调试时,我发现进入这个函数时,它卡在这个循环中,我确定指针一定有问题(但是不知道是什么意思,找不到叫哪个中断)

(0) [0x0000000fe9e6] f000:e9e6 (unk. ctxt): push ax ; 50
<bochs:26> s
Next at t=439640331
(0) [0x0000000fe9e7] f000:e9e7 (unk. ctxt): call .-22398 (0x000f926c) ; e882a8
<bochs:27> s
Next at t=439640332
(0) [0x0000000f926c] f000:926c (unk. ctxt): mov al, 0x20 ; b020
<bochs:28> s
Next at t=439640333
(0) [0x0000000f926e] f000:926e (unk. ctxt): out 0x20, al ; e620
<bochs:29> s
Next at t=439640334
(0) [0x0000000f9270] f000:9270 (unk. ctxt): ret ; c3
<bochs:30> s
Next at t=439640335
(0) [0x0000000fe9ea] f000:e9ea (unk. ctxt): pop ax ; 58
<bochs:31> s
Next at t=439640336
(0) [0x0000000fe9eb] f000:e9eb (unk. ctxt): iret ; cf

你能帮我吗?谢谢! (顺便说一句,我使用的是显卡的文本模式,我的操作系统上还没有文件系统。操作系统目前处于实模式)

【问题讨论】:

  • 只要有一个指针 point 指向显存。 The OSDev wiki 有一些很好的例子。
  • 是什么阻止您跟踪发送到显示器的数据?
  • 您的问题中现在有两个不同的问题。请一题一题。请采纳 SOtour,阅读How to Ask,以及this question checklist
  • 您是否正在以实模式运行从 32 位 C 编译器 (gcc) 生成的代码?您是否将 -m16 与 GCC 或类似的东西一起使用?
  • 只是一个观察。将 0x20 发送到端口 0x20 本身表明此代码正在发送 EOI(中断结束),并且代码出现的方式很可能是从 0x00 到 0x07(包括)的中断。此范围内最常见的 2 个中断是计时器 (0x00) 和键盘 (0x01)。 0xf000 段是 BIOS,因此您希望在 BIOS 中调试外部中断处理程序。

标签: gcc nasm x86-16 osdev real-mode


【解决方案1】:

在 8086(和 8088)上,内存访问是使用两个寄存器完成的,一个 16 位段寄存器和一个 16 位偏移值/寄存器。实际地址是通过获取段寄存器,将其向左移动 4(乘以 16)并添加偏移量来计算的。所以如果你用DS作为段寄存器,AX作为偏移寄存器,那么真正的内存地址就是(DS * 16) + AX

8086 提供了 4 个寄存器来保存内存访问的段值:DS(数据段)、SS(堆栈段)、CS(代码段)和 ES(额外段)。使用哪一个取决于操作码。指令获取总是相对于CS

请注意,段可以重叠,因此不同的段/偏移组合可以引用相同的内存。例如[aaaa:0000][aaa9:0010][aaa8:0020][aaa7:0030]都引用了地址0xaaaa0

8086 的地址总线是 20 位的,所以如果地址计算溢出,它就会回绕。所以[ffff:0010] 将是一种混淆的写作方式 [0000:0000]。 80286 增加了更宽的地址总线,并且在 8086 模式下运行时不会溢出,因此为了使 IBM PC-AT 与原始 PC 保持兼容,IBM 决定实现一些怪异,涉及称为 A20 门的键盘控制器芯片。 (但这已经离题了。)

所以如果你想访问从0xB8000 开始的内存块,你可以设置 DS(或其他一些段寄存器)到0xB800,并使用适当的偏移量访问您的数据。

自然地用 C 编程你不必直接弄乱寄存器,但你还是要了解 8086 的分段内存模型。

通常,8086 的 C 编译器允许您使用 3 种不同的寻址模式编译代码:

  1. 小内存模型 - 这里所有数据和代码都在同一个段中 (DS = SS = CS = ES)。指针是 16 位的,包含段中的偏移量。代码和数据的大小总共可能只有 64k。

  2. 大内存模型 - 类似于“小内存模型”,但一段用于数据,一段用于代码 (DS = SS = ES != CS)。指针仍然是 16 位。代码和数据的大小分别最大为 64k。

  3. 超大内存模型 - 指针是 32 位的,同时保存内存地址的段和偏移部分。指针运算仅通过修改指针的偏移部分来完成。所以即使程序可以访问整个 1Mb 的地址空间,c 中的原生数据对象(包括结构和数组)也只能是最大 64k,而且只有当它们以 16 字节对齐开始时。

如果 IRC,原始 PC 上的视频内存从 0xb8000 开始。那将是段0xb800。为了能够访问它,我们必须使用“巨大的内存模型”(32 位指针)进行编译。在文本模式下,字符存储为两个字节,一个用于属性,一个用于字符代码。

将所有这些放在一起,并假设视频控制器已设置为 80x25 字母数字模式,我们可以像这样在屏幕上写入:

struct char_cell
{
   unsigned char attribute;
   unsigned char char_code;
};

/*
   How to handle pointers is compiler dependent, but we assume here that 
   the segment value is stored in the high 16 bits. So memory address
   0xb8000 or [b800:0000] can be written as 0xb8000000
 */
#define video_buffer ((struct char_cell *)0xb8000000ul) 

void put_char(int line, int column, int ch)
{
   video_buffer[line * 80 + column].char_code = ch;
}

int get_char(int line, int column, int ch)
{
   return video_buffer[line * 80 + column].char_code;
}

/*
   Saving/restoring buffer doesn't handle saving/restoring cursor position.
   This must be done separately.
 */ 
void save_video_buffer(struct char_cell buffer[80 * 25])
{
   memcpy(save_buffer, video_buffer, sizeof(*buffer) * 80 * 25); 
}

void restore_video_buffer(struct char_cell buffer[80 * 25])
{
   memcpy(video_buffer, save_buffer, sizeof(*buffer) * 80 * 25); 
}

很久没做MS-DOS编程了,可能细节有点不对。

【讨论】:

  • 非常感谢您的耐心解答和优雅的解决方案,给了我很多启发。但是由于memcpy仍然涉及指针操作,这会导致我在调试时遇到同样的问题。我想我需要单独问这个问题。
  • 您在这里的想法似乎适用于具有 FAR PTR 概念的 DOS C 编译器(Turbo-C、Watcom C/C++ 等)。尽管有一个实验性的 ia16-gcc 仍然存在问题,但它被标记为 GCC 并没有这样的概念。 CGA/EGA/VGA 文本 显存位于 0xb800:0x0000
  • 你弄错了内存模型。你所谓的small实际上是tiny。你的large 实际上是small。有个好overview of the models on Wikipedia
  • @ecm,感谢指正,MS-DOS是很久以前的事了,每个小细节都记不太清了。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-08-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-09-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多