有关 Nintendo GameCube
毫无疑问, Nintendo GameCube 在市场上失败了.
毫无疑问, Nintendo GameCube 在技术上成功了.
也许有人怀疑这第二句, 这就是我写这篇文章的原因.
从硬件上来讲, NGC十分的标准, 简洁, 高效.
NGC硬件组成:
大体上, NGC以Art-X Flipper为中心, 北桥连接CPU, 南桥连接24MB 1T-SRAM, 东桥连接Audio DSP, Audio DSP另外连接16MB缓存.
事实上Audio DSP是集成在Flipper中的, PCB上看不到.从这种角度上看, 似乎很像pc.
深入Art-X Flipper, 这块PCB上最大的芯片, 集成了内存控制器, GPU, Audio DSP. 注意, CPU和GPU都直接连接到内存控制器. 在NGC架构中, 没有显存和内存的区别, 24MB 1T-SRAM 同时存放代码, 贴图, 顶点乃至FrameBuffer等等数据. 这24MB 1T-SRAM用得很出彩. CPU可以很方便的对GPU处理过的数据再次进行处理.
1T-SRAM 具体原理就不介绍了, 它最大的特点就是与DRAM相比, 没有随机访问的延迟, 不像DRAM那样需要等待几个时钟周期才会读取到需要的数据.
NGC GPU有个特殊的设计, 就是嵌入式的2MB 1T-SRAM, 这个缓冲区被用作GPU内部的超高速缓冲, 保存有z-buffer之类的数据, 渲染中间过程的临时数据放在这里, 可以不用抢主存的带宽. 注意, 这个设计显然被ATI发扬光大了, XBOX360 GPU中也有这么个玩意, 只不过容量大了不少.
从软件上讲, NGC编程易于掌握.
NGC CPU Gekko是一块IBM PowerPC 750 + Paired Single多媒体扩展指令集, 可以使用工业标准的c/c++, 同时汇编语言也易于掌握.
NGC GPU 从概念上类似于OpenGL, 可以设置大量的状态, CPU通过专用FiFo向其发送渲染命令, 即可完成渲染.
NGC Memory map非常的清晰:
0x00000000 - 0x017FFFFF 物理内存
0x80000000 - 0x817FFFFF cached 逻辑内存
0xC0000000 - 0xC17FFFFF not cached 逻辑内存
0xCC000000 - 0xCC00FFFF 硬件寄存器
0xE0000000 - 0xE0003FFF L2 cache
0xFFF00000 - +1MB IPL(BIOS BOOT ROM)
由于设备全部共享24MB主存, 所以主存被映射到三个地址区域, 为不同的目的服务, 例如程序代码使用cache映射地址.
所有设备的硬件寄存器都依次映射到寄存器地址区域, 详细的分布也是很有规律的.
至于L2 cache为什么也会映射到全局地址空间, 这个并没有文档介绍, 个人估计是为硬件调试器使用的.
NGC模拟器
NGC模拟器自当年Dolphin横空出世之后, 对广大玩家而言, 就没有什么突破性的进展了, 其实质变源于量变, NGC模拟并不是停滞不前, 只是量还积累的不够.
CPU: Gekko使用的PowerPC指令集, 由于RISC的缘故, 并且OPCODE似乎是6bits, 所以解释模拟的话, 目前似乎都是采用查表的方法, 效率还是蛮高的. gcemu采用了动态编译的实现, 效率已经非常令人满意了. Dolphin x64更是利用了x64的64位优势, 不过由于尚未正式发布, 所以其性能无法实际考察.
GPU: Art-X这个显示芯片, 由于似乎和OpenGL有那么一腿, 所以开源的实现无一例外都使用了OpenGL, 其中gcemu采用了OpenGL 2.0规范, 实现了动态生成shader的算法, 所以已经实现的部分, 速度非常得快.
AudioDSP: 很多模拟器作者已经表态, 这是NGC中最难以模拟的部分, 主要是资料的稀少, 基本上都是靠反向工程获取的数据.
由目前我所掌握的源代码来看, 优化的余地还很大, 至少还没有多线程的模拟器实现, 如果CPU和GPU能够多线程并行模拟, 以目前主流配置, 至少在不考虑DSP模拟的情况下应该可以达到全速执行游戏.