以任天堂的ROM檔來說目前最主流最主流使用的header格式稱為 INES header,標頭共16Bytes大小,緊接著後面連貫的是RPG-ROM與CHR-ROM實際內容,理論上搞定INES header就可以,但實際上這格式內容卻有些新舊衝突的問題要謹慎處理,這東西是由社群和領導制定者產生的東西.
ines header最大的公約數是開頭一定是 'N' 'E' 'S' \0x1a 這四個字元(檔案內容byte 0~3),接著是一個byte的RPG-ROM count (byte 4) , 接著是一個byte的CHR-ROM count (byte 5) , 以及擁有mapper與rom重要屬性flag的 byte 6 與 byte 7 , 接著 byte 8 ~15 是實作上比較沒那麼重要的資訊,輔助性質的一些東西,隨著 ines版本或是各dumper者習慣而有資訊多寡不同,簡單來說如果你找相關介紹資訊,會發現byte 8~15 的定義有些差異 , 通常舊的ines header byte 8~15內容都為 0x00,新版的 nes 2.0 ines header延伸規範則會有新的屬性.
撇開新版的ines 延伸規格 nes 2.0不談 , 就算是舊版只討論 byte 0 ~ 7 的內容,也還是會有些衝突問題會導致mapper解讀錯誤,最主要是早期某些rom 對 mapper的解讀定義是不會理會到 byte 7這邊,從 byte 7 ~ byte 15 會填入 DiskDude! 這幾個ASII code , 如果你拿到這種rom用新的正確規範去解讀,就會踩到地雷,從mapper 0 變成 mapper 64.
Early ROM processing tools were not aware of Flags 7 because the earliest emulators ignored it. For example, one tool put 0x44 (ASCII for 'D', the first character of "DiskDude!") here. This confuses newer emulators, which combine the nibbles from Flags 6 and Flags 7 to form an incorrect mapper number. NES 2.0 redefines the unused bits to always equal binary 10, which happens not to match any of the patterns used by these ROM processing tools:
簡單來說需要有一個判斷方式去對這種特立做解讀mapper上的修正.
流程大概是
1.如果 byte 7 低4bits 為 0 , 進行標準ines規範maper解讀,
mapper = (byte)(((byte6 & 0xf0) >> 4) | (byte7 & 0xf0));
2.如果 byte 7 低 4bit 不為 0 ,且 byte 7 bit3為1 & byte 7 bit2為 0 ,認定此為遵守nes 2.0延伸規範的header定譯內容.
3.如果 byte 7 低 4bit 不為 0 , 且byte 7的 "bit3與bit2"不為 "1與0" , 則是早期非標準的版本.
mapper = (byte6 & 0xf0) >> 4;
以上.....社群零散發展起來的東西其實就會有這樣的狀況,就算組織單位也常常會有規範衝突的問題,但又是別種層面的狀況.
其實ines的規範標準並不是說很方便完整,也有新的規範方式出現,不過並不普及,模擬器多數實作也不一定會支援,如果我是當初的制定者,我大概會給mapper一個完整的byte,而屬性控制則獨立一個byte分開來放置,不需要把mapper硬切高低 4bits 放置到兩個 byte 跟 屬性控制bits混雜,有可能最早時候沒考慮到 mapper的數量會超過於 4bit範圍這問題.
其實ines的規範標準並不是說很方便完整,也有新的規範方式出現,不過並不普及,模擬器多數實作也不一定會支援,如果我是當初的制定者,我大概會給mapper一個完整的byte,而屬性控制則獨立一個byte分開來放置,不需要把mapper硬切高低 4bits 放置到兩個 byte 跟 屬性控制bits混雜,有可能最早時候沒考慮到 mapper的數量會超過於 4bit範圍這問題.
