中国DOS联盟

Gemini 解答

---

技术背景与定位

SDLPal 是基于开源 SDL 库对《仙剑奇侠传》（DOS / Win95 版）游戏引擎的逆向工程重实现。传统的 SDLPal 普遍面向现代操作系统，而该项目通过 DJGPP（GCC 的 32 位 x86 DOS 移植版）将 SDLPal 重新移植回 DOS 环境。

这一移植依赖了近年 SDL3 上游合并的 DOS 后端、DPMI 保护模式扩展、以及 SBEmu / VSBHDA 等现代声卡虚拟化中间件，使得基于现代跨平台代码架构的游戏引擎能够在实机 DOS 和纯软渲染环境下运行。

---

核心技术要点与机制解析

1. 内存模型与 DPMI 突破

• 突破 640KB 常规内存限制：DOS 原版《仙剑奇侠传》使用 DOS 扩展器（如 DOS/4GW 等）突破常规内存，而 SDLPal DOS 版基于 DJGPP 编译，运行于 32 位 DPMI（DOS Protected Mode Interface，通常依托 CWSDPMI）保护模式下，享有扁平寻址空间（Flat 4GB Address Space）。
• 常规内存（Low Memory）占用机制：保护模式程序本身占用扩展内存，但声卡 DMA 缓冲区、中断服务例程（ISR）入口跳板以及部分 BIOS/VBE 接口调用必须位于首兆（1MB）以下的常规内存中。文中提到实机仅剩 100KB 常规内存仍可运行，是因为 DJGPP 将大部分堆栈和代码段搬移到了扩展内存，只在常规内存池分配极少量的 DOS 传输缓冲区（Transfer Buffer）。

2. 多线程与音频模型差异

• SDL 的多线程音频模型：标准 SDL 音频驱动依赖 OS 级抢占式线程（如 pthread）定期调用音频回调填充缓冲区。
• DOS 环境的实现机制：
  • 硬件中断（ISR）直驱：DOS 原版引擎通过挂载 PIT 8253/8254 定时器中断（INT 08h 或 INT 1Ch）周期性向 OPL 芯片端口写入寄存器数据。
  • SDL3 协程模拟：DOS 下原生不存在内核态抢占式多线程。SDL3 的 DOS 后端使用用户态协程（通过切换栈指针与寄存器上下文，如 setjmp/longjmp 或 ucontext 原理）实现协作式“假多线程”，在主循环空闲或主动 yield 时切出执行音频渲染与事件轮询。
• 关于多核（SMP）的讨论（跟帖）：
  • DOS 本质运行在实模式或单核 DPMI 保护模式，BIOS/ACPI 启动 AP（Application Processor）核需要发送 INIT-SIPI IPI（处理器间中断）并在保护模式/长模式下初始化多核调度器。
  • 回复中提到的 smp.vxd 是针对 Windows 9x 的 VxD（虚拟设备驱动），利用 Ring 0 特权级唤醒次核并接管硬件调度；而在纯 DOS/DPMI 环境下，缺乏内核态抢占式调度器和内存屏障管理，直接运行真正的多核 pthread 仍存在巨大的架构壁垒。

3. 硬件音频与现代声卡映射（CMI8738）

• 传统 ISA 声卡：标准 Sound Blaster / AdLib 将 OPL 芯片直接映射在固定的 ISA I/O 端口（通常为 0x388 - 0x38B，SB 为 0x220 等）。
• PCI 声卡直接访问：CMI8738 等 PCI 声卡在 PCI 配置空间中被分配了一段 Base Address Register（BAR）。CMI8738 芯片内部集成了兼容 OPL3 的 FM 核心，其硬件规格书定义了在 PCI I/O 空间基地址偏移 +0x50 处映射该 FM 寄存器。因此在 DPMI 拥有 in/out 端口 I/O 特权级（IOPL=3）的前提下，程序无需装载专有 DOS 驱动，只需读取 PCI 配置空间查出基地址即可直接向硬件端口写 OPL 数据。
• 虚拟化方案：SBEmu / VSBHDA 利用 CPU 的 VT-x 硬件虚拟化或 Trap（捕捉）I/O 端口访问，把针对 0x220、0x388 的旧 ISA 端口访问动态重定向至现代 HD Audio 或 AC97 PCI 设备，使免驱动硬件模拟成为可能。

4. 视频渲染与模式处理

• VGA 模式（Mode 13h）：320x200 256色（8-bit 调色板）。针对 Win95 版 16-bit / 24-bit 的 AVI 动画，必须在运行时进行色彩空间转换，通过离线生成 LUT（查找表）和抖动算法降采样映射到 256 色 VGA 调色板中。
• VESA 模式（VBE）：高分辨率（如 1080P）依赖 VBE 2.0+ 线性帧缓冲区（LFB，Linear Frame Buffer）。高分辨率下帧率骤降属于必然现象：纯软渲染器在向显存 PCI/AGP/PCIe 总线逐像素写入（memcpy）时，受到未经硬件加速的总线 I/O 写入带宽和 CPU 单核算力限制。

---

技术结论与使用限制

1. 环境依赖：该二进制为 32 位 DPMI 程序，需搭配 386 以上处理器，最低内存建议 16MB 以上（若包含视频解码堆栈建议更高）。
2. UEFI 启动限制：纯 UEFI 环境去除了传统 BIOS 中断（INT 10h、INT 13h 等）与 CSM（兼容支持模块），DOS 系统及依赖实模式/BIOS 调用的 DPMI 扩展器无法直接引导。CSM 包装层（如 CSMWrap）仍处于实验阶段，兼容性较低。
3. 性能调优：在低配置实机或未开启硬件加速的虚拟机中，应强制锁定 DOSForceMode13h 并使用 REALOPL 硬件直通或轻量级软合成器（如 DBINT），避免使用高开销的 NukedOPL 或高分辨率 VESA 软渲染。

Gemini 解答

---

该回复讨论了在 DOS / 早期 Windows 环境下实现“真多核抢占式多线程（SMP Preemptive Multithreading）”的可能性。以下从 x86 体系结构、操作系统模型及相关开源项目的底层原理进行技术解读：

1. 核心概念澄清：抢占式单核多线程 vs. 多核并发 (SMP)

原帖及跟帖中混淆了两个不同的层次：

• 单核抢占式多线程（Preemptive Multitasking / Multithreading）： DOS 本身是单任务实模式系统，但只要进入保护模式（如通过 DPMI 或自定义 Extender），程序完全可以利用硬件定时器中断（如 8254 PIT 的 IRQ0）定期触发上下文切换（保存/恢复寄存器、切换堆栈指针 ESP 和页表），从而在单核上实现抢占式多任务。DJGPP 早期就有基于时钟中断的抢占式线程库（如 GNU Pth 的部分移植），并非只能做协程式（Cooperative）切换。
• 多核对称多处理（SMP, Symmetric Multiprocessing）： 指同时调度多个物理 CPU 核心（或线程）并行执行指令。这不仅需要多任务调度器，还必须具备初始化次级核心（Application Processors, APs）、维护缓存一致性（Cache Coherency）、跨核中断（IPI）以及多核内存同步原语（如原子锁、自旋锁）的能力。

---

2. 对帖子中提及项目的原理解析

smp.vxd 与 Windows 9x 的多核机制

• 技术背景：Windows 9x（95/98/Me）的内核（VMM32/Kernel32）基于单处理器（UP）设计，未实现 SMP 调度，整个操作系统与驱动运行在单核上，其 16 位和 32 位混合架构大量依赖非重入的 Win16Lock（Big Caret Lock）。
• smp.vxd 的实现原理：
  1. 该驱动（VxD 运行在 Ring 0）绕过了 Windows 9x 自身的任务调度器。
  2. 它直接通过 ACPI / MPS（MultiProcessor Specification）表检测系统的多核拓扑。
  3. 通过主处理器（BSP, Bootstrap Processor）向 APIC（高级可编程中断控制器）发送 INIT-SIPI-SIPI（Startup IPI）序列，将处于停机（HALT）状态的次级核心唤醒，并使其进入 32 位保护模式。
  4. 为 AP 核心建立独立的特权级栈与页表，并在 Ring 0 维护一个独立的私有任务调度器。
• 局限性：次级核心不能调用 Windows 9x 的任何系统 API（无论是 Ring 3 的 Win32 API 还是 Ring 0 的 VMM/VXD 服务），因为这些 API 是非线程安全的。次级核心仅能作为“纯算力工人”，处理无系统调用的纯内存计算密集型任务（例如 Mesa 软渲染器 llvmpipe、视频解码等）。

pthread9x

它是配合 smp.vxd 开发的用户态运行时库。它将标准 POSIX 线程（pthread）API 映射到 smp.vxd 暴露的 Ring 0 调度接口上。由于次级核心无法直接响应 Win32 线程消息，该库的线程实质上是脱离 Windows 系统调度的外部并行计算线程。

SBEmu 的 VDPMI 桥接 VxD 设想

• SBEmu 的机制：SBEmu 是一个用于纯 DOS 环境的 Sound Blaster 模拟器，利用 QEMM/JEMMEX 等 EMM386 内存管理器的 Ring 0 / Virtual 8086 (V86) 权限，通过捕获 I/O 端口访问（如 0x220）来重定向现代 PCI/HD Audio 硬件。
• VDPMI 与 VxD 兼容性： VxD（Virtual Device Driver）是专为 Windows 3.x/9x 的 VMM（Virtual Machine Manager）设计的驱动格式，高度依赖 VMM 导出的底层服务（如 Get_Cur_VM_Handle、中断虚拟化链等）。 纯 DOS 环境下的 DPMI 宿主（Host）通常只提供 Ring 3 到 Ring 0 的中断切换、选择子分配与内存映射（如 INT 31h），并不具备 VMM32 的驱动加载和运行时基础设施。在没有实现完整 VMM 仿真层的前提下，直接在 DOS/DPMI 中加载并执行任意 .vxd 文件在工程上存在显著断层；但如果仅参考 smp.vxd 中唤醒 APIC 与 SIPI 初始化的裸机硬件代码，直接在 DOS DPMI 扩展器中实现多核引导，则是完全可行的。

---

3. DOS 下实现真多核多线程的工程现实

要在 DOS（DJGPP 运行环境）下实现真正的多核多线程，不需要依赖 Windows 9x 的 VxD，其标准技术路径为：

1. 硬件初始化（Ring 0）： DOS Extender（或加载的 TSR 驱动）从实模式或通过 DPMI 取得 Ring 0 权限，解析 ACPI MADT（Multiple APIC Description Table）或 MP-Table 获取 CPU 核心信息。
2. 唤醒次核： 利用 Local APIC 发送 SIPI 消息，加载实模式引导代码（Trampoline Code），将次核切换至保护模式/分页模式，加载与主核共享或映射一致的 CR3（页目录）。
3. 调度与约束：
   • DOS 本身（INT 21h）及 BIOS（INT 10h, INT 13h 等）是**完全不可重入（Non-Reentrant）**的。
   • 所有次核严禁调用任何 DOS/BIOS 中断。所有 I/O、文件读写、音频 DMA 交互必须交由主核（BSP）在中断上下文中代理执行。
   • 次核只运行无 OS 依赖的纯算法代码，线程间通信仅依赖共享内存及基于原子操作指令（如 x86 的 LOCK CMPXCHG、PAUSE）实现的 Spinlock 或 Lock-free 队列。

Gemini 解答

---

本帖讨论的核心是 DOS / 早期 Windows 环境下实现多核（SMP）与真正多线程（Preemptive / Multi-core Threading）的可行性与实现路径。楼上提到的讨论存在一些技术概念的混淆与工程可行性的偏差，以下做系统性解读与澄清：

1. DOS 与 x86 多核唤醒（AP Bring-up）的技术事实

在 x86/x64 架构下，无论操作系统是什么，多核唤醒的底层硬件机制是完全一致且标准化的（依据 Intel MultiProcessor Specification 或 ACPI 规范）：

• 系统启动时，固件（BIOS/UEFI）仅将一个核心作为 BSP（Bootstrap Processor） 引导进入实模式或保护模式，其余核心作为 AP（Application Processor） 处于挂起（Wait-for-SIPI）状态。
• 唤醒 AP 不需要传统意义上依赖 OS 内核特性的“多核驱动”，而是需要一段运行在 Ring 0（实模式或特权模式）的代码向本地高级可编程中断控制器（Local APIC）发送 INIT-SIPI-SIPI（Startup IPI） 中断序列，指定 AP 的入口实模式向量地址（0x000VV000）。
• 一旦 AP 被唤醒，开发者可以将其直接切换到保护模式或长模式，并为其分配独立的栈（ESP）、页表（CR3）与中断描述符表（IDT）。

因此，第 6 楼指出“根本没有多核驱动，可以直接 bringup 第二个核心”在底层硬件层面上是完全成立的。在 DOS 环境（特别是 32 位 DPMI / DOS 扩展器环境）下，完全可以直接通过内存映射 I/O（MMIO）访问 Local APIC 来唤醒并控制其他从属 CPU 核心（Asymmetric Multiprocessing，AMP 模式）。

2. DOS 下利用多核的真正瓶颈：不是 Bring-up，而是系统资源竞争

唤醒 AP 并不难，难点在于如何在多核环境下调度与共享系统资源：

• DOS 的非可重入性（Non-reentrancy）：MS-DOS 本身是一个单任务、单线程且非可重入的系统。内部有大量的全局静态状态（如 InDOS 标志、SDA - 交换数据区、当前目录结构等）。多个核心若同时触发 INT 21h 进行文件 I/O 或内存分配，会导致严重的系统状态破坏或死锁。
• BIOS 与中断架构限制：传统的 PIC（8259A）与 BIOS 中断例程同样不可重入。如果要实现真正的 SMP，必须建立一套核间通信机制（IPI）或任务队列，将所有涉及 BIOS/DOS 调用的 I/O 请求串行化（Marshal）派发回 BSP（Core 0）执行，而让 AP 仅负责纯粹的计算任务（如软渲染、音效解码、矩阵变换）。
• DPMI 规范的缺失：现有的 DPMI 0.9/1.0 规范以及常见的 DOS 扩展器（如 CWSDPMI、DOS/4GW、PMODE/W）均只针对单 CPU 设计，无法感知和管理多核上下文切换。

3. 关于 smp.vxd 与 vdpmi 的技术分析与纠偏

5 楼提到的两个项目及桥接设想存在概念理解上的偏差：

• smp.vxd 的本质： Windows 9x 的 VMM32（虚拟机管理器）内核虽然在调度层是单处理器架构，但其运行在 32 位 Ring 0。smp.vxd 是一个运行在 Ring 0 的虚拟设备驱动程序，它利用 Local APIC 唤醒了其他核心，并在这些核心上运行轻量级的从属调度器（Worker 线程池），用于协助主核心进行并行计算（如软光栅渲染）。它并不是让 Windows 9x 获得了类似 Windows NT 的完整 SMP 内核能力，而是在单核 OS 内部开辟了一个非对称计算协处理器环境。
• pthread9x 的定位： 它是在 Win32 用户态封装了调用 smp.vxd 核心接口的 POSIX 线程 API 库，依赖 Win32 运行环境与 VXD 接口。
• DOS 下桥接 VXD 的不切实际性： 5 楼提及“VDPMI 开源后桥接 VXD 来支持多核”在工程上不可行。VXD（Virtual Device Driver）是专为 Windows 3.x/9x 的 32 位保护模式虚拟机管理器（VMM）设计的驱动架构，其高度依赖 VMM 提供的服务（如 Get_Cur_VM_Handle、Hook_V86_Int_Chain、VXD 服务表与 Ring 0 消息通信）。在纯 DOS / DPMI 环境下，模拟完整的 VMM32 运行时来跑 VXD 属于过度设计；如果要在 DOS 下用多核，直接在 DPMI 扩展器或 Ring 0 载入器中通过 APIC SIPI 唤醒从核并编写裸机计算循环，在技术实现上要简单且干净得多。

4. 虚拟化与静态分区（Hypervisor Partitioning）

第 6 楼提到的“使用 ACRN 等静态分区 Hypervisor”是现代嵌入式和工业领域常用的方案：

• 原理：利用 CPU 的硬件虚拟化技术（Intel VT-x / AMD-V），由底层 Type-1 Hypervisor（如 ACRN、Jailhouse 或轻量级 VMM）对物理 CPU 核心与物理内存进行硬隔离分区。
• 实现：Core 0 分配给 DOS（运行在受限的 VM 容器或非根模式下，处理原本的显示与 DOS 系统调用），Core 1..N 分配给裸机计算程序、FreeRTOS 或 Linux；核心之间通过共享物理内存（Shared Memory Ring Buffer）和虚拟中断进行无锁通信（Lock-free IPC）。
• 结论：这种方案不仅技术上完全可行，而且是目前在不需要重写 DOS 体系的前提下，让 DOS 程序安全利用现代多核 CPU 算力最稳定、最标准的技术路径。