嵌入式固件【免费下载链接】Apollo-11Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.项目地址https://gitcode.com/GitHub_Trending/ap/Apollo-11点击查看免费下载本指南面向所有希望为 Apollo-11 仓库贡献代码的开发者核心主题是阿波罗 11 号制导计算机AGC汇编源码的转录校对规范。仓库中的Comanche055/指令模块代号 Colossus 2A与Luminary099/登月模块代号 Luminary 1A全部源码均由志愿者从纸质打印输出printouts手动数字化而来因此本指南详细定义了以扫描件为唯一基准的逐字校对流程从编辑器选型、格式化规范到注释排版错误、空格密度与空行规则读完即可上手完成一次合格的转录差异审查并知道如何提交一份与扫描件完全一致的 Pull Request。本文内容以 Translations/CONTRIBUTING.id.md印尼语贡献指南及其英文原版 CONTRIBUTING.md 为主体并结合仓库内真实 AGC 源文件展开佐证。背景一份必须以扫描件为准的开源代码Apollo-11 仓库的定位非常明确——它是阿波罗 11 号制导计算机原始源码的存档库而不是一份被润色过的现代代码。正如 README.md 所述仓库内容由 Virtual AGC 社区与 MIT 博物馆合作数字化而成目标是保存 Comanche 055 与 Luminary 099 的原始转录文本并欢迎任何针对转录与原始扫描件之间差异的 Pull Request。正因为源码来自手动数字化转录过程中不可避免地混入了两类问题原始扫描件本身就有的错误——当年的 NASA 工程师在纸质注释中写下的拼写错误数字化过程中新引入的错误——人工转录、OCR 或排版环节产生的偏差。因此贡献指南的核心原则只有一条仓库中的转录代码必须被修改使其与下列官方扫描打印输出完全一致Comanche指令模块 AGC扫描打印输出Luminary登月模块 AGC扫描打印输出此外社区还提供了便捷的在线工具用于浏览两份扫描件可在仓库 README.md 的 Attribution 一节找到 ibiblio 镜像入口。在开始校对之前请先把对应页面的扫描件调出来逐行对照。如何在仓库中定位要校对的模块仓库目录结构即模块边界Comanche055/指令模块CM的 AGC 程序装配版本Assemble revision 055 of AGC program Comanche by NASA1969 年 4 月 1 日Luminary099/登月模块LM的 AGC 程序装配版本Assemble revision 001 of AGC program LMY99 by NASA1969 年 7 月 14 日。每个.agc文件头部都带有标准的转录元信息。以 Comanche055/P11.agc 为例其文件头第 1~35 行记录了 Copyright、Filename、Purpose、AssembleryaYUL、Contact、Mod history并注明Assemble revision 055 of AGC program Comanche by NASA与Page 533字样。这类页号信息正是你比对扫描件时定位页码的依据——PDF 扫描件的每一页通常都标有对应页码。工欲善其事为你的编辑器安装 AGC 语法高亮AGC 汇编语言是 1960 年代的产物现代代码编辑器默认都不认识它。好消息是 GitHub 本身内置了对 AGC 汇编语言的语法支持在线浏览 .agc 文件时已可高亮但本地编辑器需要额外安装语言扩展。贡献指南列出了以下支持 AGC 语法高亮的编辑器及其扩展编辑器说明Atom† 支持自动格式化CodeBlocks—Eclipse—Kate—ProgrammersNotepad—Sublime Text 3† 支持自动格式化TextPad—Vim—Visual Studio Code† 支持自动格式化jEdit—† 标记表示该扩展额外支持自动格式化即保存文件时能自动套用下文所述的格式化规范。这些扩展分别由社区成员维护可在各编辑器的插件市场或 Virtual AGC 项目的Contributed/SyntaxHighlight目录中找到Virtual AGC 是编译 AGC 源码的参考实现详见 README.md 的 Compiling 一节。装上语法高亮后CS、TC、IMODES33这类 AGC 助记符与标签会被正确着色校对时对代码结构的识别效率会明显提升。格式化规范三个必须遵守的硬性要求在动手校对之前先确保你的编辑器 / 扩展已启用正确的格式化设置贡献指南给出的格式要求非常明确使用 TAB 进行缩进不要用空格缩进TAB 宽度为 8 个字符去除行尾的空格或 TABtrim trailing whitespace。其中TAB 宽度为 8与 AGC 源码的物理排版历史直接相关1960 年代的宽行打印机以 8 列为一个制表位源代码的缩进层次、标签列、操作码列与操作数列都依赖这一固定列宽。即使现代编辑器默认 TAB 宽度是 4校对 AGC 文件时也必须改为 8否则列对齐关系会被破坏无法与扫描件的排版对应。提示贡献指南注明GitHub 平台本身以及上表中带 † 的三个扩展会自动帮你应用正确的格式化但手动编辑时仍需自查。校对要点一注释必须与扫描件逐字精确匹配这是整个校对工作的最高优先级规则转录代码中的注释必须与扫描打印输出完全一致用原文档的措辞即MUSTmatch the scansexactly。之所以要精确而不是纠正是因为当年开发者写下的注释本身就包含错误而这些错误同样属于历史的一部分。校对者需要处理两类典型的排版错误Typographic Errors数字化把原本正确的拼写改错了→ 必须改回扫描件的原文数字化好心修正了扫描件里的原始错误→ 必须还原成错误版本。原文档给出一个极具代表性的例子如果数字化注释中是SPACECRAFT而扫描件上印的是SPAECRAFT漏了字母C那么转录代码必须被纠正为SPAECRAFT。同理如果某个单词在数字化文本中拼错了、但扫描件拼写正确则必须修正转录文本。这个规则在仓库源码中有真实对应。以 Comanche055/CONTRACT_AND_APPROVALS.agc 第 38 行为例转录注释为# * PROJECT 55-23870, SPONSORED BY THE MANNED SPACECRAFT *该文件同时保留了大量值得对照的细节例如第 57 行 COLOSSUS PROJECT MANGERMANGER系MANAGER之误——这类注释中的原始笔误正是贡献指南要求保留的对象。校对者的任务不是把MANGER改成MANAGER而是确保它与扫描件印刷内容逐字符一致。校对要点二注释中的空格密度约定注释内任意两个字符之间的空格数量也应尽量与扫描件一致。贡献指南参考了社区讨论原文档引用了 PR #316 的评审讨论归纳出如下默认约定场景空格数量新单词之间1 个空格新句子之间2 个空格缩进位置3 个空格需要注意的是这只是一条通用经验法则并非所有扫描页面都严格遵循。规则本身强调如果扫描件某页实际只印了 1 个空格而不是 2 个就照扫描件用 1 个空格——扫描件永远优先于约定。以中英文贡献指南中都给出的格式化示例为参照把散乱空格整理为统一密度的过程大致如下单词间单空格、句号后双空格、续行缩进三空格。这一规则的意义在于空格密度在扫描件上承载了句读信息转录时保持密度即保持原件的可读性结构。校对要点三换行与空行规则R0000 列的特殊地位AGC 打印输出在每一页左侧带有行号列其中R开头的行号如R0819出现在第 1 列。贡献指南对换行给出两条硬性规则规则 1带R0000的换行必须与扫描件完全一致。当一行的第 1 列出现R0000形式的行号时该行与上一行之间的换行关系是打印排版刻意为之必须原样保留。规则 2不含R0000的连续空行最多 1~2 行。若两个非空行之间夹着超过 2 个连续空行则删除多余的空行带R0000的行不计入这个1~2 行的限额——也就是说R0000行之间的空行可以不受此限。原文档给出了一个非常直观的对照示例。假设扫描件对应的原始排版如下含 3 个连续空行与错位行号R0819 SUBROUTINE TO SKIP... R0820 0821 LAMPTEST CS IMODES33则转录代码应整理为最多保留 2 个空行且行号需对齐R0819 SUBROUTINE TO SKIP... R0820 0820 LAMPTEST CS IMODES33注意第二个示例中行号从0821修正为0820——因为删除了一个多余空行后后续代码行号整体前移必须同步校正以保持与扫描件逐行对应。空行密度背后的排版机制为什么会有1 个空行 / 2 个空行这种密度限制贡献指南解释了原始打印机制在源图片中这些空行是由第 8 列上一个未打印的数字控制的——数字2强制双倍行距即 1 个空行数字3强制三倍行距即 2 个空行数值4~8在打印规范中被定义过但从未被实际使用。换言之扫描件上的空行密度是打印列控制符的可视化结果转录时必须忠实地把它还原为最多连续 2 个空行的形式多余的空行一律删掉。提交 PR 之前的最后检查贡献指南在结尾给出了唯一且必须遵守的验收标准在你提交 Pull Request 之前请确保你的所有改动与原始扫描打印输出保持一致。结合仓库 CONTRIBUTING.md 与 README.md 的流程一次完整的贡献可以总结为以下步骤选对模块根据改动所在文件判断属于Comanche055/还是Luminary099/并定位对应的扫描打印输出页码范围每个 .agc 文件头部的 Pages 注释即为页码索引如 Comanche055/P11.agc 头部的Pages: 533-550配置编辑器安装对应的 AGC 语法扩展设置 TAB 宽度为 8、开启去除行尾空白逐行比对优先核对注释拼写、空格密度再核对换行与空行规则R0000 行、空行上限自查格式化确认没有行尾空格、缩进使用 TAB提交 PR在 PR 描述中说明发现的差异与依据的扫描件页码方便维护者复核。整个仓库的贡献文档均以多种语言维护除本文依据的 Translations/CONTRIBUTING.id.md 外还包括 Translations/CONTRIBUTING.zh_cn.md 等二十余种语言版本且 CONTRIBUTING.md 与各翻译版之间通过语言导航互相索引。若发现任一语言版本的贡献指南与英文原版存在差异同样欢迎通过 PR 修正。结语对现代开发者而言为一份 1969 年的汇编源码做校对是一件反直觉的工作我们要的不是修正错误而是还原历史。阿波罗 11 号 AGC 源码之所以被以逐字一致的精度保存是因为它不仅是可编译的代码更是一件需要被原样保留的工程史料。掌握了注释精确匹配、空格密度约定、R0000 换行规则与空行上限这四把标尺你就可以放心地打开任一.agc文件与扫描件展开一次严谨、可追溯的差异审查。赞分享嵌入式固件【免费下载链接】Apollo-11Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.项目地址https://gitcode.com/GitHub_Trending/ap/Apollo-11点击查看免费下载相关推荐Apollo-11 仓库 AGC 汇编源码的转录校对与贡献规范让扫描件与代码逐字符一致Apollo 11 仓库 AGC 汇编源码的转录校对与贡献规范让扫描件与代码逐字符一致 本指南基于 Apollo 11 仓库官方贡献文档整理系统讲解 Com嵌入式固件OpenUSD 场景描述数据类型完全指南Sdf 值类型、角色语义类型与字典元数据OpenUSD 场景描述数据类型完全指南Sdf 值类型、角色语义类型与字典元数据 在 OpenUSD 中Prim 上的每个属性值都必须落在 SdfScen嵌入式固件OpenReel Video 音频效果全解均衡器、压缩器、混响、延迟与失真完整使用指南OpenReel Video 音频效果全解均衡器、压缩器、混响、延迟与失真完整使用指南 OpenReel Video 是一款 100% 基于浏览器的开源视频编嵌入式固件上一篇Zotero Style 完整上手指南30分钟搭起文献阅读进度可视化工作台下一篇魔兽争霸3优化指南5分钟解锁144Hz高帧率与宽屏体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考