“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
把 Mac OS X 移植到任天堂 Wii：一次硬核系统底层之旅
本文讲述了一位开发者如何将 Mac OS X 10.0 Cheetah 移植到任天堂 Wii 游戏机上的完整过程，涵盖硬件兼容性分析、引导加载程序编写、内核修补与驱动开发等底层技术细节。
缘起：不可能的挑战
2021 年，Reddit 上有人断言将 Mac OS X 移植到 Wii 上“发生的概率为零”。正是这句话点燃了作者 Bryan Keller 的斗志。他决定用实际成果证明，所谓的不可能只是尚未有人尝试。
本文是作者对自己这一壮举的技术复盘，面向的是对操作系统底层机制感兴趣的开发者，即使你不是系统专家，也能从中学到大量关于硬件引导、内核加载、设备驱动的知识。
可行性调研：硬件兼容性
移植的第一步是评估 Wii 的硬件是否与 Mac OS X 兼容。
处理器：本是同根生
Wii 采用的是 PowerPC 750CL 处理器，它是 PowerPC 750CXe 的演进版本，而后者正是早期 G3 iBook 和部分 G3 iMac 所使用的 CPU。这一近亲关系让作者对 CPU 层面充满信心——指令集架构完全一致，不存在根本性障碍。
内存：奇特但够用
Wii 的内存配置颇为另类，总计 88 MB，分为两部分：
- 24 MB 1T-SRAM（MEM1）
- 64 MB 更慢的 GDDR3 SDRAM（MEM2）
Mac OS X Cheetah 官方要求 128 MB 内存，但实际可以更低。作者先用 QEMU 模拟器以 64 MB 内存启动 Cheetah 验证可行性，确认没有问题后才进入下一步。
外围设备：待征服的山头
需要驱动的硬件还包括：
- USB Gecko 串口调试输出
- SD 卡（用于启动内核后的文件系统）
- 中断控制器
- 位于内存中的帧缓冲器视频输出
- Wii 的 USB 端口（用于鼠标和键盘）
评估后作者认为，Wii 的硬件与 Mac OS X 没有根本性的不可调和之处，值得继续推进。
软件栈理解：开放核心与封闭外壳
Mac OS X 的架构非常独特：
- 开源核心：Darwin（包括 XNU 内核和 IOKit 驱动模型）
- 闭源组件：Quartz、Dock、Finder、系统应用和框架
理论上，只要能修改开源部分让 Darwin 跑起来，闭源部分就能无缝运行。这让移植路径清晰了很多。
Mac 的启动流程
PowerPC Mac 的启动分为两个关键阶段：
- Open Firmware：硬件检测、设备树构建、I/O 函数、从文件系统加载 BootX
- BootX：Mac OS X 的引导加载器，负责读取设备树、解码并加载 XNU 内核、将控制权交给内核
关键洞察：XNU 一旦运行，就不再依赖 BootX 或 Open Firmware 了。这意味着引导加载器的复杂度只需要撑到内核启动即可。
Wii 的自制软件生态
得益于 Wii 早已被“越狱”，任何人都可以通过 Homebrew Channel 和 BootMii 运行具有全部硬件访问权限的自制代码，这为移植提供了必备的跳板。
方案抉择：破而后立
作者评估了三条路线：
- 移植 Open Firmware，运行未修改的 BootX：复杂且多余，因为 Mac OS X 运行时并不依赖这两者。
- 移植并修改 BootX：仍然引入很多 Wii 用不到的硬件配置逻辑。
- 编写自定义引导加载程序：只做最简化的初始化，直接加载内核。
最终选择了第三条，参考 Wii Linux 项目的经验，从零编写引导加载器。其核心职责包括：
- 初始化 Wii 硬件
- 从 SD 卡加载内核
- 构建设备树和启动参数
- 将控制权传给内核
一旦内核运行，引导加载器就完全退场，后续焦点转向内核修补和驱动编写。
实现引导加载器：从骨架到内核加载
作者基于 ppcskel（一个 Wii 低级示例代码库）开始开发。这个骨架提供了系统初始状态设置、SD 卡文件读取、帧缓冲文本绘制、USB Gecko 调试日志等基础功能。
解析 Mach-O 内核文件
XNU 内核以 Mach-O 格式存储，它由一连串的 Load Command 描述，告知加载器将文件的各个段放入内存的具体位置。例如，某个命令可能指示“从文件偏移 0x2cf000 读取数据，放到内存地址 0x2e0000”。
处理完所有 Load Command 后，内存布局如下：
0x00000000: 异常向量表
0x00011000: __TEXT 段
0x002e0000: __DATA 段
0x00367000: __KLD 段
0x00395000: __LINKEDIT 段
0x00434000: __SYMTAB 段
0x004d3000: __HEADER 段
内核文件同时指定了入口地址。引导加载器只需跳转到该地址即可。
调用内核的瞬间
代码上，作者直接通过函数指针调用内核入口：
c
((void ()())kernel_entry_point)(boot_args_address, MAC_OS_X_SIGNATURE);
执行后，屏幕变黑，串口调试日志停止——这意味着内核已经开始运行，但也意味着引导加载器的调试通道失效了。
黑暗中摸索：LED 调试大法
XNU 内核启动时，第一段代码是 PowerPC 汇编的 _start 例程。它会重新配置硬件，覆盖 Wii 特有的初始化，并禁用引导加载器的串口和视频功能。普通调试手段全部失效。
作者想出了一个精巧的“土办法”：直接二进制修补内核，将特定位置的指令替换为控制 Wii 前面板 LED 的指令。如果 LED 在跳转后亮起，就说明内核至少执行到了那个位置。
在 PowerPC 汇编中，点亮 LED 只需向特定内存地址写入值：
assembly
lis r5, 0xd80 0；加载高位地址（原文此处有截断，但原意如此）
这种方法虽然粗糙，却在不依赖传统调试设施的情况下，为引导过程提供了宝贵的可见性。
后续工作展望（原文截断部分）
原文在 LED 调试部分后中断，但根据项目完整脉络，可以推断作者继续进行了：
- 内核修补：针对 Wii 的硬件特点调整 XNU 的启动代码，例如绕过对 Open Firmware 的依赖、修正内存映射等
- 驱动开发：为中断控制器、帧缓冲器、USB 等设备编写 IOKit 驱动
- 反复迭代，每次用 LED 作为“进度条”，逐步推近引导流程
最终，Mac OS X 10.0 Cheetah 成功在 Wii 上原生启动，并显示桌面环境。
总结与启示
这再次证明了一个朴素而深刻的常识：看似不可能的移植，背后是扎实的硬件认知、软件栈的深刻理解，以及无数个“未知的未知”被逐个击破的耐心。
这个项目也展示了开源软件的力量——Darwin 和 XNU 的开源部分使得移植成为可能，而 Wii 的自制社区提供的基础设施则为探索铺平了道路。
如果你想亲自动手体验，可以参考 wiiMac 引导加载器仓库中的指南。
原文链接：https://bryankeller.github.io/2026/04/08/porting-mac-os-x-nintendo-wii.html