有关 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模擬的情況下應該可以達到全速執行游戲.
轉載于:https://www.cnblogs.com/skogkatt/archive/2007/07/04/4163247.html
總結
以上是生活随笔為你收集整理的有关 Nintendo GameCube的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ASP.NET2.0数据库入门之SQL
- 下一篇: 三层开发中容易犯的错误