ThroatyMumbo/WinCE64

源码：https://github.com/ThroatyMumbo/WinCE64

Nintendo 64 上的 Windows CE 2.11

在真实的 Nintendo 64 上运行原版微软 Windows CE 2.11。一个自定义的 HAL 将未修改的 nk.lib 内核搭载到 VR4300 上，启动 CE 2.11 的 GWES 桌面和 shell，将 EverDrive-64 X7 的 SD 卡挂载到 \SDCard，把 N64 手柄当作鼠标使用，通过标准 CE wave 栈在 N64 AI 硬件上播放声音，并直接从 SD 卡运行第三方的 CE 2.11 EXE 程序。

这是一个爱好性质的逆向工程项目：微软从未官方为 N64 移植过 CE 2.11。未修改的 nk.lib 之下的所有组件（HAL、OAL、显示驱动、FSD、键盘/鼠标 PDD、wave PDD、RDP 加速的 GDI 填充、ed64-X7 驱动）都属于本仓库。

在 https://www.youtube.com/watch?v=eGS9su_inBY 中有介绍

状态

可在真实 N64 + EverDrive-64 X7 上完全启动。目前已实现的功能：

• 桌面、任务栏、文件浏览器；窗口拖拽、关闭按钮（X）、模态对话框
• N64 手柄驱动一个可见光标；A = 左键点击，B = 右键点击
• 通过 FatFS 在 X7 卡带 SD 上挂载 \SDCard\*
• 通过 sndPlaySoundW / waveOutOpen → N64 AI 播放 wave 音频
• 可从 SD 卡启动第三方的 CE 2.11 EXE 程序（例如 BeziersCE）
• RDP 加速的 3D 演示（cube3d.exe），直接通过 RDP 对平面着色三角形进行光栅化

架构

架构

未修改的 nk.lib 是主干：它负责 PSL 分发、调度和 TLB。围绕它，标准的 CE 2.11 用户态模块（coredll.dll、gwes.exe、filesys.exe、device.exe、shell.exe）从 ROM 镜像中原样加载。自定义的部分有：

• HAL / OAL（bsp/hal/）—— 启动、异常向量、MIPS 初始化、定时器、USB 调试、两个 LE 模式 RDRAM 半字异常解决方法。
• 显示驱动（bsp/drivers/display/）—— VI 帧缓冲 + RDP 填充加速 + 软件光标合成器，填补了 CE 2.11 在非覆盖硬件上由 CURSOR.LIB / MCURSOR.LIB 分离留下的空白。
• 鼠标 / 键盘 PDD（bsp/drivers/kbdmouse/）—— SI Joybus 轮询，解码 N64 手柄和官方 N64 鼠标。
• SD 文件系统（bsp/drivers/sdfsd/）—— 基于 FatFS 的 FSD，注册到 \SDCard 下。用基于 PI-DMA 的 EverDrive-X7 驱动（edx_x7.c）替换了 libdragon 的 libcart，以避开在真实硬件上模拟器中不可见的卡带总线读写后读取异常。
• Wave PDD（bsp/drivers/wavedev/）—— 轮询模式的 AI 驱动，位于标准 waveapi.dll 之下。采用轮询而非中断，因为在真实硬件上 MI_INTR_MASK_AI 会阻塞 SysAD 总线。
• commctrl.dll（bsp/drivers/commctrl/）—— 一个很小的 DllMain，CE 2.11 的 commctrl.lib 忘了打包它，因此旋转控件（msctls_updown32 类）才能被注册。
• Shell（bsp/shell/）—— Win9x 风格的桌面、任务栏、文件浏览器。
• RDP 3D 库（bsp/lib/rdp3d/）—— 为用户 EXE 提供的最小三角形光栅器；由 bsp/apps/cube3d/ 使用。

关于漫长的调试历史（缓存异常、TLB 遍历、GWES 启动、CE 端 wave 栈的奇特之处等），详见每个驱动中的源码注释。

你需要准备什么

本仓库特意不包含任何微软或任天堂专有的内容。你需要自行获取外部代码树，并将它们放置在与本目录同级的位置（或使用符号链接）：

主机端的工具：

• Wine —— SDK 的 CLMIPS.EXE / LINK.EXE / RC.EXE / ROMIMAGE.EXE 都在 Wine 下运行。已在 Linux 上测试。
• Python 3 以及 Pillow
• libdragon 工具链中的 mips64-elf-gcc（用于引导 ROM）
• libftdi1（如果想通过 USB 上传到真实的 X7）—— 构建 diag/ed64_upload 时需要。

构建

将 wince211_sdk/ 和 libdragon/ 放置在此目录旁边之后：

bash bsp/build.sh

该脚本会编译 HAL 和所有驱动 DLL，在 Wine 下运行 LINK.EXE 和 ROMIMAGE.EXE 生成 bsp/build/nk.bin（原版 CE ROM 镜像），然后链接到 bootloader/Makefile，将其包装在一个 libdragon IPL3 引导加载程序中。输出：bootloader/n64ce.z64（约 3.5 MB，可直接由 X7 加载）。

典型的干净构建在现代硬件上大约需要 30 秒；主要耗时来自 Wine 的冷启动，构建脚本通过在整个运行过程中保持一个 wineserver 存活来分摊这个开销。

运行

在真实 N64 + EverDrive-64 X7 上

只需构建一次 USB 上传工具：

cd diag && make ed64_upload

然后上传并启动：

diag/ed64_upload bootloader/n64ce.z64       # 写入并启动
diag/ed64_upload --listen bootloader/n64ce.z64   # 同时流式传输 USB 调试信息

--listen 会在上传后保持 FTDI 句柄打开，从而不会丢失任何调试输出。

模拟器

早期开发使用了 Ares，并对其打了一个小补丁以处理 LE 模式 RDRAM 半字异常。但这逐渐导致该项目变成了一个“改进 Ares”的项目，而非仅在真实硬件上测试。让它在 Ares 上工作是另一个更深的兔子洞，我无意去解决。尚未在其他模拟器上测试。

仓库结构

bsp/             N64 BSP：HAL、OAL、驱动、shell、应用程序、ROM 镜像
  hal/             在标准 nk.lib 之上的自定义 HAL
  drivers/         显示、键盘/鼠标、sdfsd（FatFS）、wavedev、commctrl
  lib/rdp3d/       用户应用程序使用的三角形光栅器
  apps/            cube3d、paint、notez（链接到 ROM 中）
  shell/           桌面、任务栏、文件浏览器、图标
  build.sh         完整的构建脚本
  ce.bib           ROMIMAGE 构建信息文件（内存映射 + 模块列表）

bootloader/      libdragon IPL3 引导加载程序，用于从卡带加载 nk.bin
diag/            裸机诊断 ROM（LE 模式异常测试、音频测试、USB 上传器、ed64 重启）
docs/            架构图、硬件调试笔记、N64 怪异之处

（外部，不在本仓库中）
libdragon/          → DragonMinded/libdragon 的克隆
wince211_sdk/       → 来自 MS Embedded Toolkit 的 CE 2.11 SDK
ed64-x-pub/         → krikzz/ed64-x-pub（参考，不用于构建）

常见问题

为什么？

好问题！这个想法来自于 IBM Workpad Z50，它使用了与 N64 非常相似的 MIPS CPU（VR4121 vs N64 的 VR4300）。实际上在 N64 上运行 Windows 并没有实际意义，所以这更像是一个编程挑战。

我在哪里可以拿到预构建的 ROM 镜像？

拿不到——没有这样的镜像，我也不会发布。用 bash bsp/build.sh 自行构建。生成的 n64ce.z64 链接了微软的 CE 2.11 二进制文件（nk.exe、coredll.dll、gwes.exe、filesys.exe、ddi.dll 的 MGDI / GPE 库等），它们来自 SDK 的静态库；发布一个完整的 ROM 意味着重新分发这些文件，而我没有这样做的许可。本仓库中我自己的源文件采用 MIT 许可——但构建的输出文件不是，将来也不会。

我可以直接购买一份 SDK 吗？

不能，已经大约 20 年没有卖了。微软 Windows CE 2.11 Platform Builder（包含在 Microsoft Embedded Toolkit for Visual C++ 6.0 中）最后一次销售是在 21 世纪初，并在 2004–2005 年左右悄然退役。微软从未重新发布、开源或在下载网站上替换它。它最初附带的使用许可是按开发者许可的开发许可证：你可以用它构建嵌入式软件，并将生成的二进制文件随嵌入式设备一起发布，但不能自行重新发布 SDK 或其静态库。该工具包的 ISO 归档版本在网上流传；找到它们就靠你自己了。

它能在模拟器中运行吗？

也许吧？参见上面的“运行 → 模拟器”说明。真实硬件是测试平台；我不会维护模拟器路径。

我可以运行自己的 CE 2.11 MIPS EXE 程序吗？

可以。将它们放到 SD 卡上，然后从文件浏览器启动。BeziersCE（https://github.com/ThroatyMumbo/BeziersCE）已确认可以端到端运行，包括它的 commctrl 旋转对话框。需要 CE 在 N64 上未公开的硬件功能（网络栈、真实键盘、GAPI 等）的应用程序将会失败。

为什么图标看起来很奇怪？

有两个原因：

• CE 2.11 SDK 不包含任何图标（除了一些零星的 EXE 图标）
• 由于法律原因，我无法将经典的 Win9x 图标添加到本仓库中。

你可以轻松地将 bsp/shell/icons 下难看的图标替换成更真实的图标，应该就能正常工作。

这里面有多少是自定义的？

很多。CE 2.11 SDK / Platform Builder 提供了内核（nk.lib）、coredll.dll、gwes.exe、filesys.exe、device.exe、通用控件、MGDI / GPE 显示抽象层以及 Win32 API 表面。但它不附带桌面 shell——没有 Explorer、没有任务栏、没有开始菜单、没有桌面窗口、没有文件浏览器。OEM 被期望在纯 GWES 窗口管理 API 之上构建自己的 shell。微软确实销售过带有预构建 shell 的 H/PC Pro 设备，但参考 shell 源码直到 CE 3.0+ 才出现在 Platform Builder 中（IESAMPLE / EXPLORER 示例）。对于 2.11，你得靠自己。

因此，bsp/shell/——Win9x 风格的桌面、带时钟和开始按钮的任务栏、通过 FindFirstFileW 遍历 \SDCard\ 的文件浏览器、带可工作 commctrl 旋转控件的模态对话框——全部是根据标准 CE 2.11 GWES API 编写的原创代码。GWES 之下的所有组件也是如此：CE 2.11 提供了接口，并期望 OEM 编写底层的设备特定驱动，因此 HAL/OAL、显示驱动、键盘/鼠标 PDD、SD FSD、wave PDD、RDP 填充代码、ed64-X7 卡带驱动以及 commctrl 的 DllMain 都是为 N64 目标自定义的。

许可

MIT 许可，详见 LICENSE。MIT 的范围仅限于本仓库中的源文件。微软 Windows CE 2.11 SDK / Platform Builder 二进制文件（构建过程会链接它们）带有自己的许可；你必须合法地获取它们。