找街機,上2233街機網 | 經典街機游戲平臺

手機版

您的位置:首頁 > 街機攻略 > MAME模擬器架構、編譯及配置分析

MAME模擬器架構、編譯及配置分析

 作者:羽逸之光  時間:2020-04-21 19:58:47

MAME模擬器架構、編譯及配置分析:

[摘要] 眾所周知,M.A.M.E是目前世界上支持驅動最多、模擬精確程度最高、開發團隊實力最強及影響力最為廣泛的通用街機模擬器。本文以Mame 0.105b為例,嘗試從編譯配置和源碼結構角度出發,簡要分析和描述了Mame的軟件架構,并且詳細論述了Mame的配置、編譯及裁剪過程。作為一篇啟蒙性質的文章,本文主要面向希望深入了解Mame的模擬新手,以及對Mame源碼感興趣、且具備一定技術水平的模擬老手。
1. Mame源碼結構

Mame 0.105b源代碼目錄樹結構如下:  
makefile是一種用于自動編譯的特殊腳本,里面記錄了所有源碼的編譯步驟、規則及相互依賴關系,多用于跨平臺的命令行編譯場合。它可以類比于我們熟悉的Windows中VC++的"工程文件",但是與IDE自動生成的工程文件不同,makefile腳本一般由開發者手工編寫。為簡潔起見,在Mame的makefile中定義了大量模板規則(pattern rule),同時,其整套編譯腳本也從功能性的角度被劃分為如下6個文件: 
其中,后5個mak腳本用來生成相應的功能模塊,而作為主控腳本./makefile則負責調用(include)上述的5個mak腳本,實現5個功能模塊的鏈接并生成最終的mame.exe文件。

2. Mame軟件架構

2.1 總體架構
早期Mame的軟件架構變動得非常頻繁,只有Nicola SalmoriaAaron Giles等少數幾個教父級核心開發者才能把握其細節。隨著Mame的逐步成熟及其支持驅動數量的日趨龐大,Mame Team已經充分意識到了架構穩定的重要性,并終于在2005年的上半年宣布Mame的結構基本定型,這同時也說明:從源碼分析角度一窺其堂奧的機會終于成熟了。鑒于0.106u2版之后的Mame引入了全新的顯示系統,該系統目前仍在測試中,因此在這里我們將主要以較新的0.105穩定版作為具體分析實例。
根據Mame的源碼及makefile編譯結構,我們可得出其目前的總體架構圖如上。如圖所示,整個Mame架構可劃分為核心層和OSD層共2個層次;其中的核心層又引用了驅動、CPU核心及聲音芯片核心等3個模塊,它們都是平臺無關的;而針對Windows的OSD層則為核心層集中提供了面向操作系統的具體實現接口,所有的Win32 API和DirectX實際調用均由OSD層來實現。可以看出,通過替換OSD層,可以很方便地將Mame移植到不同的操作系統中,并使用不同的底層多媒體控制機制,如MacOS-Linux/SDL等,但是反過來,這種具備良好移植性的分層結構恰恰也是導致Mame模擬效率低下的主要原因之一,對移植性的追求使得Mame不可能100%的充分利用平臺相關的硬件加速能力。[NextPage]
2.2 誰需要關注Mame架構和源碼?
作為一個在模擬界擁有絕對領導地位的龐大項目,參與Mame開發的人員自然形形色色,而各自期望了解Mame的目的也是多種多樣的。從其軟件結構上可以看得出來,關注Mame架構及源碼的人主要包括核心框架開發者、模擬技術研究者和驅動開發者3類(當然,現實中并不一定劃分得那么絕對,如NicolaAaronHaze等大牛往往身兼數職):核心開發者主要負責Mame核心層及高層軟件框架的研制工作;模擬技術研究者主要關注CPU及聲音芯片等核心部件的模擬實現,出于為CPU等模擬部件提供標準復用接口的目的,他們對Mame架構也必須有所了解;而游戲驅動開發者做的工作則主要是利用Mame已有的流程、框架以及模擬部件,接合自己對真實主機運行細節的理解來實現具體的游戲驅動,如虛擬主機定義、定制視頻/音頻硬件模擬等;很顯然,Mame核心框架和已有的核心部件是驅動開發的基礎,它們是可共用的,它們讓驅動開發者們能夠集中精力解決被模擬主機所特有的細節問題,而不必去考慮如何重復實現那些模擬器通用的處理流程和部件——就好比Windows程序員們使用MFC一樣(突然發覺這個比喻很貼切: CPU等核心部件可類比MFC標準類、Mame框架就好像MFC Framework、而游戲驅動則就是那使用了MFC消息映射等框架機制及類庫的用戶代碼部分);由于Mame支持的游戲驅動數量極其龐大,驅動開發者的數量無疑也是最龐大的,同時他們往往也是早期Mame架構頻繁變動的最大受害者,值得慶幸的是,他們并沒有放棄Mame,Mame也沒有放棄他們——目前Mame的結構終于定型了,而且0.106u2版本后所引入的顯示系統新變動也主要集中在Mame核心層和部分OSD接口,對驅動模塊及CPU、聲音芯片模塊的影響并不大,主要是一些顯示相關配置方式上的改進,驅動開發者們終于可以安心了。
除上述3類直接參與的開發者之外,圈子里還存在著不少專用模擬器開發者對Mame的源碼感興趣(盡管他們不一定參與了Mame的研制),這是因為他們能夠從Mame源碼中獲取到寶貴的主機信息;事實上,Mame的參考文獻價值遠遠超越了它為給普通玩家所帶來的游戲樂趣,這也正是Mame Team為什么會如此"孤高而又傲慢地"追求模擬精確性的根本原因。在真正模擬器開發者的眼中,Mame并不僅僅等同于一個慢吞吞的模擬器,它更像是一本百科全書,而關于Mame的框架常識則是這本Bible的目錄和索引。另一方面,也有不少熱愛DIY、期望精簡Mame的驅動并在自己的機器上對其進行優化編譯的模擬愛好者對閱讀Mame源碼感興趣,如果你正好是其中一員,那么你將非常幸運:這篇文章幾乎就是為你寫的;當然,你也會發現這篇文章的內容并不僅限于此。
不管怎樣,我希望此文的讀者能夠首先明確自己的理想和目標——這將是你征服Mame懸崖般陡峭的學習曲線的唯一希望所在。Okay,扯遠了,下面讓我們回到技術話題上來:具體看看Mame架構中各個組成部分所實現的功能。
2.3 OSD平臺依賴層
Mame源碼中僅自帶了針對Windows的OSD層代碼,其全部位于src/windows目錄中。考察其中的windows.mak可以發現,該OSD層代碼分為針對Win32和針對DirectX兩個部分,前者包括Windows相關的MinGW_GCC/Link編譯選項、Win32窗體及其UI顯示代碼、內存分配調試代碼(接管標準C運行庫中的內存分配函數,以便于檢測內存泄漏)、虛擬機調試窗口代碼和Win32資源文件編譯等;后者則包括DInput、DSound、DDraw等DirectX函數調用接口的編譯。說得簡單點,就是一半代碼負責Win32系統調用及窗口管理,而另一半負責DirectX媒體訪問控制。
2.4 Mame核心層
核心層是完全與平臺無關的,在src/core.mak中詳細給出了核心層的編譯選項及過程。作為Mame的最高層框架,核心層定義了一系列與平臺實現無關的抽象數據結構及其處理流程,如抽象位圖、抽象色板和抽象音頻流等,其具體表述及功能的實現均依賴于OSD底層;所有高層抽象結構在具體執行過程中均將被映射成為OSD層中的對應實體,如DDraw里面的Off-Screen Surface、DSound中的SecondaryBuffer等;而針對位圖、音頻等抽象實體的實際操作則均通過調用底層OSD層接口來間接完成。同時,核心層還為所有的CPU核心、聲音芯片和游戲驅動(Romset、虛擬機器、內存映射、I/O映射、虛擬視頻硬件和虛擬音頻硬件等)定義了統一的數據及操作/回調接口,可以說,核心層構成了Mame最重要的宏觀架構,同時也是分析Mame代碼的最佳入手點。
2.5 CPU核心及聲音芯片
考察src/cpu/cpu.mak和src/sound/sound.mak可以發現,在Mame的配置中,其按照不同類型、不同廠家的規則對CPU模擬核心和聲音芯片進行了分組,這使得我們可以很方便地從mak文件中抽取出生成任一特定CPU核心或聲音芯片的編譯步驟。在CPU核心編譯過程中,以68000核心的編譯過程最為復雜(用到了重編譯代碼生成器技術,生成m68k核心的步驟與利用lex/yacc生成編譯器類似),而在聲音芯片代碼中則Yamaha家族的較繁瑣點。
CPU核心與聲音芯片模塊均是可以跨平臺的,因此,其99%的代碼均使用C語言編寫,只有極少部分采用了匯編(現在你應該知道Mame模擬效率低下的另一個理由了),同時考慮到不同匯編語法的復雜性,代碼中很少采用C語言的嵌入式匯編,而是將匯編部分單獨分離出來,額外地組織成相應的asm文件(采用Intel語法),使用可跨平臺的Nasm進行編譯。
完全理解CPU核心、聲音芯片模擬的代碼需要具備扎實的編譯器研發技能和較為全面的數字/模擬信號處理及電路常識,這些過于專業的要求顯然令人望而生畏。但不必緊張,對于絕大多數的人而言,僅需知道如何通過Mame核心層提供的標準接口使用這些核心部件便足夠了,至于如何實現它們就交給牛人們去操心吧。
2.6 游戲驅動部分
2.6.1 Mame驅動概述
游戲驅動是Mame中較為關鍵的一個組成部分,其代碼是與平臺無關的,多采用C語言編寫。游戲驅動包括了Mame中某個游戲正常模擬運行所需的一切信息,下面我簡要羅列一下這些信息,希望能給各位好奇的讀者們一個"華麗的"的第一印象: 
Hmmm…我知道在你看過了上述信息之后的感受一定很復雜… Mame驅動相關的信息是非常細致而又龐大的,我相信你已經體會到了;但這里我想強調的是: 這些信息實際上并不像你想象的那么混亂,其實它們之間的聯系非常緊密。仔細看看上面的那個表,我們可以將其驅動信息劃分成CPU、Romset、I/O與輸入設備、視頻設備和音頻設備等5類,其中,CPU部分包括了正確模擬CPU運行行為所需的全部信息,如內存映射、I/O端口映射和中斷管理等;而Romset代表著游戲的程序正文和數據;輸入設備告訴我們這個游戲用的是搖桿、光電槍還是跟蹤球,音、視頻設備的作用不用多說了吧?不難發現上述分類跟我們所了解的基板硬件結構是一一對應的,事實上,街機作為一種游戲專用的嵌入式系統,恰恰也就是由上述5個部分構成。
另一方面,我們還可以發現,在Mame驅動體系中,存在著"游戲驅動"(DRIVER)和"虛擬機"(MACHINE)的邏輯層次劃分:為降低研發成本,不少游戲使用了相同的基板,因此其硬件配置是基本一致的,比方說Neo.Geo MVS系列和CPS1/2系列,既然如此,它們完全可以重用同一份"虛擬機"驅動定義;但是,在實際模擬它們的時候,還需考慮每個游戲自身的具體情況,比如MVS中存在著的Rom加密現象——某些較新的游戲roms加載后需要解密,而多數早期游戲則不需要,為了讓這些新游戲能夠正常運行,我們有必要在Mame驅動架構中為它們添加一些額外的驅動信息及其驅動行為。簡而言之,"虛擬機"定義記錄的是多個游戲可共用的驅動信息及操作,而"游戲驅動"定義則記錄的是某一游戲所特有的驅動信息及行為,這實際上是一種對象繼承關系的體現。(熟悉OOP的朋友將很快會發現,在Mame的C源碼中大量采用了宏定義來模仿C++的面向對象特征,甚至是多態性實現,這令源碼分析難度進一步提高了,但與此同時它也帶來了相對簡潔、方便的架構設計及編碼,前提是你要能看得懂——這幾句話是寫給技術水平較高的讀者看的)
只要有足夠的耐心,我們可以在Mame驅動源碼中找到關于某個特定游戲的任一上述信息,而知道在何處找到這些信息則是我們應當關注的重點。從源碼結構角度來說,一般而言,一個游戲的完整驅動主要包括驅動注冊、驅動定義及實現、定制視頻硬件、定制音頻硬件和周邊器件等5個代碼模塊,它們分別對應著src/mamedriv.c、src/drivers/$(zip_name).c、src/vidhrdw/$(zip_name).c、src/sndhrdw/$(zip_name).c和src/machine中的某些文件,這里的$(zip_name)指的是游戲Romset的zip名,如ddragon、ddragon2等。其中,除了前二者之外,其他3部分是可選的,因為前面已經說過了:某些模塊和信息是可以多個游戲共用的。在這些代碼模塊中包含了所有的驅動信息,因此,為Mame添加一個新游戲驅動的過程通常包括了添加或修改上述一系列文件的過程。為了提高可讀性,這些不同的代碼模塊通常使用相同的文件名,即$(zip_name)(如雙截龍Double Dragon,其主Romset名為ddragon,則其驅動模塊文件名均為ddragon.c),但分別存放在src/drivers、src/vidhrdw、src/sndhrdw和src/machine等4個不同的子目錄中。
在這5個驅動文件中,src/mamedriv.c作為一個全局共用模塊,負責實現所有游戲驅動在Mame框架中的注冊,所謂驅動注冊就是讓Mame知道自己支持模擬哪些游戲,以便提供相應的命令行及驅動載入接口,如果驅動不注冊的話,即使它已被編入了Mame中,用戶也無法啟動其模擬過程;位于src/drivers中的文件則給出了被模擬游戲的虛擬硬件定義,如Romset、內存映射、I/O映射、使用的CPU/聲音芯片和視頻布局等絕大多數驅動信息;位于src/vidhrdw中的文件封裝了該游戲所定制的視頻模擬例程,相當于實現了該游戲所需要的虛擬視頻硬件,多數游戲都有對應的視頻硬件模擬實現,當然,如果新游戲使用的視頻硬件和另一個已有游戲是完全一樣的,它完全可以重用已有游戲的對應文件;與vidhrdw類似的,位于src/sndhrdw中的文件封裝了游戲所定制采用的音頻模擬函數,相當于實現該游戲所需要的虛擬音頻硬件,如離散音頻系統等,定制專用音頻硬件的情況大多存在于早期游戲中,它遠不及定制視頻硬件那么普遍,為達到成本、效果及靈活性的折衷,后期游戲多采用音頻解碼/控制CPU配合標準聲音芯片的集成方式,因此很多游戲并不存在對應的sndhrdw實現;最后,在src/machine中則保存了游戲模擬所需的其他周邊硬件的虛擬實現,如NVRAMEEPROM、記憶卡和實時時鐘等,它們在多數游戲基板中使用得非常普遍,我們可以將src/machine這一目錄中的文件看成由多個游戲驅動所共享的"周邊硬件"代碼庫。[NextPage]
2.6.2 驅動文件查找范例
位于src/目錄下的mame.mak配置文件是與驅動編譯直接相關的,其內部結構組織得非常具有啟發性,無形中為我們提供了非常多的"隱含"信息,使得我們能夠非常方便地找到某特定游戲所對應的驅動代碼文件。下面我專門給出一個Step by Step實例:查找ddragon和ddragon2(雙截龍1、2代)兩個游戲所對應的驅動文件。

  • 首先獲取Mame支持的所有游戲的詳細信息,命令行下,運行"mame -listxml | xml2info > mame.lst",得到mame.lst,里面存放了所有游戲的詳細驅動信息,包括游戲名、Romset、對應驅動文件、所使用的CPU和聲音芯片及其DIP信息
  • 用編輯器打開mame.lst,查找字符串"ddragon"和"ddragon2",發現兩者的sourcefile字段均為ddragon.c,這說明ddragon和ddragon2的驅動均為同一文件:src/drivers/ddragon.c
  • 仔細看看這兩個游戲的其他信息,在chip字段中發現ddragon的CPU為HD6309和HD63701,聲音芯片為YM2151和MSM5205,而ddragon2的CPU則為HD6309和Z80,聲音芯片為YM2151和OKI6295(不用恐懼,幾乎90%以上的街機都是多CPU架構)
  • 再來,打開src/mame.mak文件,根據src/drivers驅動文件名ddragon.c查找對應obj的字符串"ddragon.o",發現了如下信息:
$(OBJ)/technos.a: \
$(OBJ)/drivers/battlane.o $(OBJ)/vidhrdw/battlane.o \
$(OBJ)/drivers/blockout.o $(OBJ)/vidhrdw/blockout.o \
$(OBJ)/drivers/bogeyman.o $(OBJ)/vidhrdw/bogeyman.o \
$(OBJ)/drivers/chinagat.o \
$(OBJ)/drivers/ddragon.o $(OBJ)/vidhrdw/ddragon.o \
$(OBJ)/drivers/ddragon3.o $(OBJ)/vidhrdw/ddragon3.o \
$(OBJ)/drivers/dogfgt.o $(OBJ)/vidhrdw/dogfgt.o \
$(OBJ)/drivers/matmania.o $(OBJ)/machine/maniach.o $(OBJ)/vidhrdw/matmania.o \
$(OBJ)/drivers/mystston.o $(OBJ)/vidhrdw/mystston.o \
$(OBJ)/drivers/renegade.o $(OBJ)/vidhrdw/renegade.o \
......

  • 上述信息中的"technos.a"字樣告訴我們,在編譯Mame時,MinGW GCC將會把所有Technos公司出品的街機驅動編譯所得的obj統統打包到同一個.a包中,用于link;另一方面,請特別注意其中每一行的分行方式,這是因為——這里的每一行都給出了與src/drivers/中的驅動代碼所對應的其他驅動模塊,例如,對于ddragon/ddragon2的驅動文件src/drivers/ddragon.c,它所對應的其他驅動模塊為src/vidhrdw/中的ddragon.c文件,而matmania驅動則對應著兩個其他驅動模塊,src/machine/maniach.c和src/vidhrdw/ matmania.c。mame.mak中給出的這些信息對于Mame的裁剪編譯是非常有價值的,這將在下文中進一步提到
  • 最后說說如何查找ddragon/ddragon2所涉及的src/machine中的周邊設備驅動文件,有兩種做法,一種是干脆不去找,直接將src/machine中的所有文件均編譯/打包成shared.a(請參見mame.mak中關于shared.a的編譯過程定義一節),統統鏈接進最終的可執行文件,但是這將導致編譯所得執行文件長度的膨脹;另一種做法是打開src/drivers/ddragon.c,簡要查看一下其引用的頭文件,這里,我們在ddragon.c中并沒有發現任何src/machine頭文件的引用,因此這兩個游戲均未顯式使用src/machine中特殊的周邊硬件
  • 綜上,我們可以得出結論了:ddragon和ddragon2所對應的驅動文件主要包括src/drivers/ddragon.c、src/vidhrdw/ddragon.c;此外,為驅動這兩個游戲,還必須包括3個CPU核心:HD6309、HD63701和Z80,以及3個聲音芯片模擬核心:YM2151、MSM5205、OKI6295
3. 編譯及配置
Mame的編譯過程相對簡單。以Mame 0.105b為例,其在Win32下的標準編譯環境主要包括:編譯器MinGW 5.0、DirectX 8庫及頭文件(for MinGW)、匯編器Nasm 0.98.39(for Win32)。詳細編譯步驟如下:
  • 下載Mame 0.105b的源碼mame0105s.exe
  • 下載mingw-mame-20060210.exedx80_mgw.zipnasm-0.98.39-win32.zip
  • 將Mame 0.105b源碼解壓縮到c:\mame105
  • 解壓mingw-mame-20060210.exe到c:\mingw,并將dx80_mgw.zip直接解壓至c:\mingw
  • 將nasm-0.98.39-win32.zip解壓至c:\mingw\bin中
  • 設置Windows環境變量,在PATH中添入c:\mingw\bin
  • 將c:\mingw\bin\mingw32_make.exe改名為make.exe,至此,編譯環境配置完畢
  • 用編輯器打開c:\mame105\makefile,配置其中的編譯選項
  • 命令行下,在c:\mame105目錄中運行make,開始正式編譯
整個Mame編譯過程包括Maketree、工具庫編譯、模擬器編譯、可執行工具生成4個步驟。Maketree用來創建存放臨時obj的目錄樹,工具庫編譯主要包括expat庫(用于解析XML)和zlib庫(用于直接zip壓縮/解壓縮)2部分工作,而可執行工具生成則包括romcmp、chdman和xml2info等3個工具軟件的編譯工作,它們的具體功能請參考Mame隨機文檔。
如第8步所述,我們可以通過修改makefile中的配置選項來指導make的編譯行為,下面給出了幾個常用編譯選項的說明: 
也可以使用VC7/VC8對Mame進行編譯,使用微軟的IDE調試起來非常方便,但其缺點則在于編譯配置不夠靈活,不便裁剪,不及makefile好用,詳細步驟請參考VCMame.net。VC8下的試驗表明:在最大可能優化的場合下,VC編譯的Release版本較GCC在速度方面僅有一定程度的提高,并不十分顯著,但是在縮短可執行文件長度方面的效果卻非常驚人:VC的編譯尺寸一般只有GCC版本的一半。[NextPage]

4. 裁剪編譯及范例

在粗略了解了Mame的軟件架構、源碼結構及其編譯配置之后,我們便可以對其進行裁剪和定制編譯了。通過精簡不必要的CPU核心、聲音芯片模塊及游戲驅動,而僅保留若干個我們需要的游戲驅動,可以令Mame文件長度更小、運行時占用的內存資源更少。同時,對Mame進行裁剪編譯還有一個重要目的:它有助于我們深入了解Mame本身的源碼結構,從而為添加全新驅動提供堅實的實踐基礎。
對Mame編譯過程的裁剪工作主要集中在對mame.mak內部編譯配置的修改。如上文所述,在src/mame.mak中保存了全部編譯相關的驅動配置,同時,通過查看mame.mak內容我們還可以發現,其內部定義的$(CPUS)和$(SOUND)兩個make腳本變量將直接影響src/cpu/cpu.mak和src/sound/sound.mak的編譯行為,決定著某一特定的CPU核心及聲音芯片是否被編譯,因此,僅需修改mame.mak文件即可完成全部的裁剪工作。事實上,在Mame 0.105b源碼中已經為我們提供了一個專供裁剪編譯配置參考的簡化版mame.mak模板——src/tiny.mak。我們可以通過重定義或修改./makefile中的TARGET腳本變量來指定make編譯時使用mame.mak還是tiny.mak。
下面仍以兩個ddragon為例,舉個實際例子來說明裁剪配置的全過程,編譯一份ddragon/ddragon2專用的Mame:

  • 動手之前,我們假定你已經獲得了一份完整編譯的Mame 0.105b可執行文件(mame.exe)
  • 根據2.6.2節中范例的分析,ddragon和ddragon2所對應的驅動文件包括src/drivers/ddragon.c、src/vidhrdw/ddragon.c;所需CPU核心包括HD6309、HD63701和Z80,聲音芯片核心包括YM2151、MSM5205、OKI6295
  • 用編輯器打開src/tiny.mak文件,初步修改如下:
# 這里兩個宏定義只用在tiny.c中,用于驅動注冊,照葫蘆畫瓢即可。是的是的,如果需要支持100個游戲,那么你就得在這里手工寫100個"driver_xxx",這確實很煩;其實tiny.c實際上就是mamedriv.c的簡化版,因此你也可以直接用后者來進行編譯,但需要修改mamedriv.c和編譯腳本,限于篇幅,我就不多寫了
# 友情提示: 注意mamedriv.c中采用的一些C語言慣用技巧——重復宏定義和遞歸宏展開
COREDEFS += -DTINY_NAME="driver_ddragon,driver_ddragon2"
COREDEFS += -DTINY_POINTER="&driver_ddragon,&driver_ddragon2"


# CPU配置,將所有用到的CPU都添加進$(CPUS)中
CPUS += Z80
CPUS += HD6309
CPUS += HD63701


# 聲音芯片配置,將所有用到的聲音芯片都添加進$(SOUNDS)中
SOUNDS += YM2151
SOUNDS += OKIM6295
SOUNDS += MSM5205


# 驅動文件配置,這里應把我們當前所發現的所有驅動文件及相關的驅動模塊全部添入
DRVLIBS = $(OBJ)/vidhrdw/ddragon.o $(OBJ)/drivers/ddragon.o

# tiny.o絕不可刪除,因為src/tiny.c中包括了驅動注冊的相關代碼,事實上tiny.c就是src/mamedriv.c的精簡版
# 如果不想使用作弊功能,可以將cheat.o刪除
COREOBJS += $(OBJ)/tiny.o $(OBJ)/cheat.o

  • 命令行下,在c:\mame105目錄中運行"make TARGET=tiny clean"
  • 同一目錄的命令行下,再次運行"make TARGET=tiny",開始正式編譯
  • 你將會很郁悶地發現編譯中途出錯,提示缺少M6800和M6803 CPU核心相關的obj文件...不會吧?!沒有用到M680x系列的CPU啊??
  • 查閱一下src/cpu/cpu.mak中M680x系列CPU核心的編譯配置,你會很驚訝地發現HD63701與M680x居然使用的是同一份代碼...
  • 沒啥好說的,直接將M6800/M6803添加至$(CPUS)完事,但記住不能刪除HD63701,因為它將作為一個標志被記錄在游戲相關的驅動注冊信息中,用于Mame啟動時配置驗證;再次修改的tiny.mak內容如下:
COREDEFS += -DTINY_NAME="driver_ddragon,driver_ddragon2"
COREDEFS += -DTINY_POINTER="&driver_ddragon,&driver_ddragon2"

# 注意這里不能將HD63701刪除,否則將在第12步驗證時發現ddragon的CPU配置為空,導致Mame無法啟動,提示"ddragon uses non-present CPU"
CPUS += Z80
CPUS += HD6309
CPUS += HD63701
CPUS += M6800 #新添加的!!
CPUS += M6803 #新添加的!!


SOUNDS += YM2151
SOUNDS += OKIM6295
SOUNDS += MSM5205

DRVLIBS = $(OBJ)/vidhrdw/ddragon.o $(OBJ)/drivers/ddragon.o

COREOBJS += $(OBJ)/tiny.o $(OBJ)/cheat.o

  • 你一定會問,如何確保寫入tiny.mak中CPU核心和聲音芯片的宏標識符(如OKIM6295等)是正確的?這很容易,根據6309、63701、6800、2151、6295等特征字串在mame.mak或者是cpu.mak、sound.mak中查找確認一下即可
  • OK,再次"make TARGET=tiny",編譯成功,并最終獲得一個名為tiny.exe的裁剪版可執行程序(1.8MB),不妨將其和完整編譯的mame.exe(40MB)比比哪個大? 呵呵
  • 下面來驗證一下編譯結果,首先運行"tiny -listfull"打印游戲列表,確認一下是否僅支持ddragon和ddragon2兩個游戲
  • 然后再次運行"tiny -listxml",打印ddragon/ddragon2的全部驅動信息,仔細檢查一下ddragon和ddragon2的CPU核心與聲音芯片配置是否與我們需要的相符,注意,驅動信息中的任一個CPU、聲音芯片字段均不能為空,否則說明驅動添加失敗,Mame將提示"xxx uses non-present CPU/Sound chips",導致無法啟動
  • 如果上述兩步檢查均通過,那么恭喜你,趕緊輸入"tiny ddragon"或"tiny ddragon2"開打吧!對了,記得別忘了將ddragon.zipddragon2.zip這兩個roms文件放在c:\mame105\roms里面哦....
5. 我們能夠做點什么?
好了,終于可以收尾了。如果你能堅持看到這里,那么你一定不僅僅只是一名模擬器的玩家,而更有可能是一位真正關注模擬界發展、并有志為其作出貢獻的技術人員(這也是為什么我要寫這么長的目的....^^)那么最后說點大家都感興趣的話題吧,深入了解并熟悉Mame源碼之后,我們能夠做點什么。街機中國轉載
如果你還只是個剛接觸Mame源碼的新手,但具備相當的意志和實力,那么你可以幫Mame做做驅動方面的優化工作,因為正如你在上文所看到的,Mame確實不是很關注效率的問題,無論架構還是實現,Mame Team的Guru們心里想得更多的是如何精確精確再精確、前進前進再前進,而通常不傾向于理會fans們的種種要求,如果你是真心憐憫那幫啥都不懂卻成天抱怨這個速度太慢那個效果不好的可憐fans,你完全可以拋開Mame已有的架構,僅將Mame源碼當作一個無價的資料庫,全靠一己之力來實現一套全新的、與平臺綁定的優化模擬架構,就像曾經寫過Final Burn的David、開發Kawaks的Mr. K和星云大師Elsemi一樣,很多牛人都是這么一路走過來的,這是讓自己逐漸成熟起來并最終走向創新的必由之路,同時也能幫助你在圈子里面迅速地贏得超強人氣,獲得僅次于Mame Team的專用模擬器開發者所擁有的名譽和尊重;或者你也可以考慮考慮為Mame中的眾多游戲添加狀態保存功能、做做測試并提交驅動補丁,這些都是很受Mame開發者歡迎的非常有意義的事情,盡管不夠酷。或許你已經是個Guru了,那么很抱歉....也許這篇啟蒙性質的文章對你而言并沒有太多價值,也許你更情愿不受打攪地完成更多該做的事情,比方說加入Mame Team、讓Capcom CPS3保護加密去見鬼、編寫200%高效模擬且支持動態重編譯的64/128bit CPU核心、為Sammy AtomisWaveSega Lindbergh提交夢幻般的完美驅動、把Mame當作VMWare并為其添加一個可以啟動Linux的驅動等等... 總之,奇跡僅限于實力和想象力。
不管怎么說,我希望能夠通過這篇長文來激發目前國內對Mame更深層次的技術思考,盡管它本身非常粗淺。如果你看過此文之后發現自己對待Mame的態度變得比以前更為嚴肅,我將非常欣慰,因為我達到了我的目的。

最新游戲

更多

Copyright?2010-2019 game2233. All rights reserved | game2233.com | 2233街機網

湘ICP備19024003號

[email protected]

qq分分彩官方开奖 天津体彩十一选五走势图定牛 国际开户自助领取彩金 股票指数期权交易 七星彩开奖结果查询 浙江体彩飞鱼开奖结果 靠谱的投资理财平台 广西11选5开奖彩图版 急速赛车10 青海快三投注网址 配资炒股介绍 排列7开奖结果查询 彩吧论坛福彩3d预测总汇 期货理财平台 山西11选5开奖规则 快乐彩12稳赚技巧 内蒙古十一选五任五遗漏