中国DOS联盟

Gemini 解答

---

核心技术原理：DOS 下的 USB 存储驱动架构

在 2000 年代中期（USB 闪存盘普及、Windows XP 流行初期），老旧主板的 BIOS 普遍不支持 USB-HDD 或 USB-ZIP 模式直接引导系统，且实模式 DOS 本身没有内置 USB 协议栈。为了在 DOS 下访问 USB 大容量存储设备（Mass Storage Class, MSC），当时业界普遍采用的是“主控驱动 + ASPI 抽象层 + 块设备驱动”的分层架构：

1. 主机控制器驱动层（ASPI 转换层）： 例如松下（Panasonic）开发的 USBASPI.SYS。其作用是探测并接管主板上的 USB 主机控制器（UHCI / OHCI / EHCI），将 USB MSC 设备的通信协议封装并模拟成标准的 ASPI（Advanced SCSI Programming Interface，高级 SCSI 编程接口）。
2. 块设备转换层： 例如 Novac 的 Di1000dd.SYS 或 Iomega 的 ASPIDISK.SYS。它们本身并不直接操作 USB 硬件，而是向上挂接 DOS 的块设备链（分配盘符），向下调用 ASPI 接口发送 SCSI 读写命令。

对帖子中“驱动方案”的技术勘误

原帖作者认为“加入 duse.exe 才能驱动 USB 2.0 优盘”并自称“发明/国内领先”，这是典型的因试凑配置巧合生效而产生的技术误解。

1. DUSE.EXE 与 USBASPI.SYS 的功能冲突与冗余

• DUSE 的真实身份：DUSE.EXE 是 Cypress Semiconductor（赛普拉斯）为其 USB 控制芯片开发的 DOS 驱动，后来被广泛用作通用 DOS USB 存储驱动。DUSE 本身是一个全功能独立驱动，它自身就包含了 USB 控制器探测、枚举、大容量存储协议支持以及向 DOS 注册驱动器盘符的全部功能。
• 冲突与覆写：在 CONFIG.SYS 中同时加载 DUSE.EXE 和 USBASPI.SYS + Di1000dd.SYS 在架构上是冗余且互相冲突的。当 DUSE.EXE 优先加载时，它可能已经完成了总线复位、设备枚举与供电握手。在某些老旧主板（仅支持 USB 1.1 的 UHCI/OHCI）上，由于特定 USB 2.0 闪存盘控制器芯片的握手超时时间较短或对总线复位时序敏感，USBASPI.SYS 裸加载时可能枚举超时失败；而 DUSE.EXE 率先执行的总线初始化碰巧为后续驱动“铺平了道路”，或者实际上盘符就是由 DUSE.EXE 本身分配的，作者误以为是三者配合的结果。

2. USBASPI.SYS 对 USB 2.0 (EHCI) 的原生支持

USBASPI.SYS 2.0x 系列（松下驱动）本身就原生支持 EHCI（USB 2.0 高速控制器），无需任何其他前置驱动。作者起初失败的原因在于参数缺失与硬件环境限制：

• 主板限制：作者明确提到其主板“只支持 USB 1.1”。如果主板南桥本身只有 UHCI/OHCI 控制器，硬件上最高物理速度只能达到 Full-Speed（12 Mbps，理论约 1.5 MB/s）。USB 2.0 设备插入后会降速回落到 1.1 模式运行，此时强制使用针对 EHCI 的配置不会产生高速效果。
• 参数控制：USBASPI.SYS 提供了细致的开关参数：
  • /e：仅启用 EHCI（USB 2.0）；
  • /o：启用 OHCI（多见于 ALi、SiS、VIA 及 nForce 早期芯片组）；
  • /u：启用 UHCI（常见于 Intel、VIA 芯片组）；
  • /v：显示详细调试信息。 如果在 USB 1.1 主板上未指定正确的主机控制器类型，或在存在 EHCI 的主板上未加参数导致驱动默认回退到 companion 控制器（UHCI/OHCI），都会导致识别失败或速度降至 1.1。

标准的有效配置仅需两行（无需 DUSE）：

device=USBASPI.SYS /v /w
device=Di1000dd.SYS

注：/w 参数用于提示用户插入驱动设备并等待，避免在系统引导过快时因 USB 设备枚举未完成而跳过盘符分配。

历史环境与兼容性局限（结合后续跟帖）

1. 传输速率问题（第 4 楼 Michael 的疑问）： 在纯 DOS 实模式下，即使主板与外设均支持 USB 2.0 高速（EHCI，480 Mbps），实际读写速度通常也远低于 Windows 环境下的 20~30 MB/s。这是由于 DOS 运行在 16 位实模式，所有磁盘 I/O 均依赖 CPU 轮询或软中断进行扇区搬移，受限于实模式寻址机制、频繁的实模式/保护模式切换开销、缺少高效率的 DMA 缓冲队列管理，通常读取速率很难超过 3~5 MB/s。
2. nForce 2 芯片组兼容性问题（第 3 楼 aleng18 的提及）： 帖子中提及“nf2 芯片组试验失败”，这确实反映了当时的历史事实。NVIDIA nForce2 芯片组（MCP2/MCP2-T 南桥）的 USB 控制器实现存在较为严重的硬件/微码层面的非标行为与时序缺陷。在 Windows 环境下尚可通过特定补丁与专用驱动修正，而在缺乏动态容错机制的 DOS 实模式驱动（无论是松下的 USBASPI.SYS 还是 Cypress 的 DUSE）下，极易在控制器复位阶段发生硬件锁死或直接超时返回失败。
3. 卡死在 ID 0 = HD ... #1 : ??? 现象（第 15 楼 liangqi 的反馈）： 此现象表明 USBASPI.SYS 已经成功枚举到了设备并建立了 ASPI 节点（认出了 SZHX SKYMEDI 控制器），但在后续 Di1000dd.SYS 发送 SCSI READ CAPACITY 或读取 MBR 引导扇区时出现错误。Skymedi（天擎）作为当时极为廉价的主控方案，其固件对标准 SCSI/ATAPI 指令集的仿真存在大量非标截断问题，无法正确响应 Di1000dd.SYS 严格的柱面/磁头/扇区（CHS）几何参数查询，导致设备驱动死循环或挂起。

附件

dos下驱动usb2u盘.rar (73.33 KiB, 下载附件所需积分 1 点, 下载次数: 5446)