[心得] NES的開發timing雜談

看板Emulator (模擬器)作者erspicu (.)時間4小時前 (2026/03/10 01:04)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串1/1

比較偏給對軟硬體模擬開發等議題有關的人分享 "https://github.com/100thCoin/TriCNES 這專案評價如何?" TriCNES 是個很有意思但也頗具爭議的專案。讓我從幾個面向整理一下：專案本質 TriCNES 是由 Chris "100th_Coin" Siebert 用 C# 寫的 NES 模擬器，全名叫做「 Coin's Contrabulous Cartswapulator」，專注於測試驅動的精確度。它最初是為了實驗一個叫做「Intercycle Cartridge Swapping」的理論 — 在每個 CPU cycle 之間更換卡帶來執行自訂程式碼。這個概念本身非常瘋狂且富有創意。精確度成績亮眼，但有脈絡作者同時開發了 AccuracyCoin 測試 ROM，而 TriCNES 在自己的測試中拿到滿分。不過這正是爭議所在。社群的主要質疑有人提出應該謹慎看待這些結果，指出 TriCNES 雖然號稱追求「speedrun 精確度」，但它甚至無法正確輸出音訊。此外，也有人批評說「我的模擬器在我自己開發的測試 ROM 上最精確」這件事本身就不是一個經過充分審計的精確度主張。從功能面來看限制也很明顯：它只能正確執行 NTSC 卡帶，而且只支援少數幾個 mapper （0、1、2、3、4、7、9、69）。更有人指出，TriCNES 目前甚至不接受手把輸入，只能用 TAS 檔案回放，所以作為一般使用者來說根本無法「玩」遊戲。測試 ROM 本身的爭議 AccuracyCoin 的測試是針對特定的 NES 硬體版本（RP2A03G CPU 和 RP2C02G PPU）設計的，在不同版本的實機上也可能會失敗，目前看來只有一種 NES 版本能跑出滿分。但也有不可否認的貢獻作者花了 8 個月專注在模擬器精確度上，並坦承說它不完美，但認為跟 Bizhawk 相當 — 有些測試 TriCNES 過但 Bizhawk 沒過，反之亦然。而且 AccuracyCoin 測試 ROM 確實推動了整個 NES 模擬生態的進步，MiSTer 的開發者 Kitrinx 就是用它來改進 NES core 的精確度。總結來說，TriCNES 與其說是一個「最精確的 NES 模擬器」，不如說是一個極度特化的研究工具 — 它在 CPU cycle 層級的時序行為上下了很深的功夫，但犧牲了音訊、 mapper 廣度、和一般遊玩功能。它的價值更多在於它推動了精確度測試的標準化，以及「intercycle cart swapping」這個瘋狂概念的驗證。 "所以針對任天堂不同型號的cpu ppu,實際硬體行為也不同相同?" 沒錯，這是一個非常實際的問題，而且答案是肯定的 — 不同版本的 CPU 和 PPU 在硬體行為上確實存在差異。 CPU（2A03）方面，已知的版本包括無字母版（最早期）、E、F、G、H 等。最早期的無字母版 RP2A03（用在所有 VS. System 大型電玩基板上）完全沒有實作「短週期噪音」（ short period noise）模式，設定對應的 bit 完全沒有效果。這就是一個具體的功能差異。另一個有趣的差異是 Pin 30 的行為：在 RP2A03G 上拉高這個腳位會啟用額外的音訊硬體診斷暫存器（$4018-$401A），但在 RP2A07（PAL 版）和 RP2A03E 上，拉高同一個腳位反而會透過停用內部 6502 的 /RDY 輸入來讓 CPU 停止執行。同樣的引腳，不同版本做完全不同的事。 PPU（2C02）方面差異更多。不同版本在開機時螢幕顏色就不一樣 — 2A03E/2C02E 組合通常顯示紫色或棕色，而較新的版本則總是灰色。此外還有 RP2C03、RP2C04、 RP2C05 等變體，這些主要用在大型電玩基板如 PlayChoice-10 和 VS. System 上，它們輸出原生 RGB 而非 composite，而且色盤也不同，有些遊戲看起來會有明顯差異。 PAL 版本的差異更是根本性的。PAL 版的 RP2A07 和 NTSC 版相比，輸入時脈分頻器不同（除以 16 而非除以 12）、各種計時器查表值（噪音、DPCM、frame timer）都不同。 PAL 版的 RP2C07 和 NTSC 版 PPU 相比，差異包括時脈分頻器、每幀掃描線數量及相關時序細節、產生的視訊訊號、sprite RAM 刷新邏輯，以及改進的 I/O 暫存器同步。還有一個值得一提的層面：CPU 開機和重置時的初始狀態（暫存器和 RAM 內容）也不能被視為確定的。 NESdev不同主機可能開機後 RAM 的內容就不一樣，很多商業和自製遊戲的 bug 就是因為錯誤地依賴了初始系統狀態。這就是為什麼前面提到 AccuracyCoin 測試 ROM 會註明它是針對 RP2A03G + RP2C02G 設計的 — 因為「精確」這件事的前提是：你到底要精確模擬「哪一台」NES？不同版本的實機本身行為就不完全一致，所以模擬器和 FPGA 核心必須選定一個特定版本作為目標。大多數模擬器和 MiSTer 都以最常見的 G 版為基準。 "也就是說真實遊戲主機跑ac test,可能會因為cpu ppu的型號差異,導致分數比122更低?" 對，這是完全確定的事實，而且不只是「可能」，是「必然」。從前面的資料就能拼出完整的圖像。AccuracyCoin 明確說明它是針對 RP2A03G CPU 和 RP2C02G PPU 設計的，不同版本的硬體上某些測試可能會失敗。 GitHub而實際測試顯示目前只有一種 NES 版本能在這個測試中拿到滿分。具體來看幾個已知的例子：一台真實的 AV Famicom 只拿到 121/125，而且它失敗的項目跟 MiSTer 失敗的不一樣。 MiSTer FPGA這就代表真實硬體本身就不是「標準答案」。再想想前面談過的版本差異。早期無字母版的 RP2A03 連 short period noise 都沒實作，這種主機跑 APU 相關的測試一定會掛。RP2C02E-0 及更早的版本 OAMDATA 和調色盤 RAM 不可讀，如果測試項目涉及這些讀取行為也會失敗。PAL 的 RP2A07/RP2C07 就更不用說了，時脈分頻、掃描線數量、frame timer 全部不同，拿去跑 AccuracyCoin 大概會慘不忍睹。所以實際情況是這樣的階層關係：特定的 RP2A03G + RP2C02G 組合 → 接近滿分（但即使同型號，個體差異也可能導致少數測試結果不同） AV Famicom（通常搭載較晚期的 H 版）→ 121 左右早期 Famicom（E 版或更早）→ 預期會更低最早期無字母版（VS. System 大型電玩用）→ 可能明顯更低 PAL 主機 → 根本不適用這個測試山寨機 → 結果不可預測有人甚至指出了一個有趣的矛盾：通過所有測試意味著你完美模擬了 revision G 的行為，但這反而代表你「無法」正確執行某些依賴其他版本行為的 Famicom 遊戲。 MiSTer FPGA 所以你的 122 分不只是比某些真實主機更高，從某個角度來說，它可能比大多數現存的真實 NES/Famicom 主機都更「標準」— 因為你的模擬器是以理想化的 G 版規格為目標，而真實硬體則受限於它出廠時裝了哪個版本的晶片。 "目前最新測試ac test是136分.實際上我拿136分也不一定代表100%準確,只是代表符合了某種特定機型的特性?" 沒錯，你的理解完全正確。 136/136 滿分只代表一件事：你的模擬器在這 136 個測試項目上的行為，與作者手上那台特定的 RP2A03G + RP2C02G 主機一致。它不等於「100% 精確」，原因有好幾層：第一，測試覆蓋率永遠是有限的。NESdev Wiki 上對此有很精闢的區分 — 「相容性」是指模擬器對已知程式產生相同輸出，而「精確度」是指對任意未知程式也能產生相同輸出。精確度無法被直接測量，要在數學上證明模擬器等價於真實硬體，本質上是不可判定問題。 NESdev136 個測試只是從無限可能的硬體行為中挑出的 136 個切面，NES 內部還有大量未被測試到的交互行為。第二，同型號晶片之間也有個體差異。半導體製程本身就存在微小的變異，同樣標記為 RP2C02G-0 的兩顆 PPU，在極端邊界條件下的行為可能不完全一致。開機時 RAM 的初始值就是最明顯的例子 — 有些主機開機後 RAM 內容可能是一致的，但其他主機可能不是， NESdev這種差異在晶片層級是不可控的。第三，測試本身可能有盲區或偏見。AccuracyCoin 的作者同時也是 TriCNES 的作者，有人質疑這構成了「用自己的測試驗證自己的模擬器」的循環論證。測試項目的選擇必然反映了作者對「什麼行為重要」的判斷，而不是硬體行為的完整描述。還有其他測試 ROM 套件（如 blargg 的各種測試、Mesen 的測試等）可能會測出 AccuracyCoin 沒覆蓋到的問題。第四，「準確」到哪個層級？目前的測試大多關注 cycle 層級的行為，但真實硬體還有 sub-cycle 的類比特性 — 電壓的上升/下降時間、匯流排上的電容效應、晶片之間的信號傳播延遲等。Visual 2A03/2C02 專案已經做到了電晶體層級的模擬，但即使如此也不可能完美複製物理晶片的每一個電氣特性。所以比較健康的看法是：AccuracyCoin 是一把很好的尺，但它量的是「與 G 版硬體在這些特定行為上的吻合度」，而不是「絕對精確度」。136/136 代表你的模擬器在目前已知的、被認為重要的行為上表現優秀，但沒有任何有限的測試能證明「100% 精確」— 這在邏輯上就做不到。 ps.目前衝到132/136,但其實是沒啥意義的,不過就虛無的爽感而已實際上看完這AI說法一度想暫停,但反正是ai燒TOKEN不是燒我的腦.... 所以最後我用AccuracyCoin自己開發的模擬器(似乎完美通過自己的測驗XD)來參考, 它的code真的是非常非常的硬體底層低階描述,所以code的量很大, 說是參考,更直接是說看它的sources是怎樣描述硬體規格和行為, 實際上比較厲害的不是做軟體的,反來是有辦法逆向挖出硬體特性的人, 我只是拿做好功課的答案去想辦法把正確結果湊出來而已. (可能是爭議偏高,AccuracyCoin作者自己本人寫的模擬器反來非常低調, 搞到根本不太能用...) 感覺應該是可以衝到136滿分,接下來會慢慢轉移到周邊功能.效能之類的, 再後續是希望用一些教學分享.還有把核心弄更友善,以後不管有人沒有人用aprnes, 哪天有人有興趣可以用核心組件套自己的介面去用,簡單來說library化. AprNes一直都偏向於技術研究.驗證.教育用途性質的專案, 興趣使然下班無聊玩的東西 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 182.233.248.16 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Emulator/M.1773075863.A.257.html ※ 編輯: erspicu (182.233.248.16 臺灣), 03/10/2026 01:08:02 ※ 編輯: erspicu (182.233.248.16 臺灣), 03/10/2026 01:11:09