z80 , 8008 , 8086 , 6502

純心得文.

GameBoy用的z80特殊修改版(簡化掉一些功能.修改掉一些功能) , 以前實作過 , 所以還算熟 , 定址模式不會很複雜 , 反來是同期的 6502 定址模式多不少,相對複雜 , 但有趣的是後來才知道 z80原來就是 Intel 8008 的相容實作 ,然而在8086這顆Intel 16Bit版本的cpu卻反來充滿了 6502 的一些影子在 ,  不知道這中間是有啥商業合作關係或是設計關係在 , 總之8086有著模仿的影子 , 但模仿對象相似對象卻不是自己上代 8008 ,反來是 相異產品 6502 ,滿有趣的.

目前正在邊學邊實作8086電腦,看到那堆定址模式給我的直覺聯想到的是6502,定址模式複雜沒關係,反正做啥就做啥,一板一眼的應該是還好,但PC模擬器周邊裝置的模擬反來複雜些,目前正在慢慢理解如何實作軟碟機.硬碟.光碟和一些裝置IO這塊,總之東看西看,慢慢來.,..期待有機會完成一個基礎的8086 PC.

目前大概的心得是,PC模擬器似乎不用考慮到如同遊戲機嚴謹的timing問題,顯示的部分也簡單很多,理論上應該會比遊戲機的模擬容易一點,但相對的PC的裝置周邊這塊又是遊戲模擬器所沒有的部分,反來需要比較多功夫.

模擬器兩方向發展議題

過去多數模擬器採用的是直譯式的運作方式,直到現在還是一樣,但俗著近年來很多技術從實驗階段到發展成熟到普遍應用,像是最有名的JIT或是LLVM之類的工具或是概念,也影響到模擬器的實作方式,網路上開始零星(數量還不多)出現一些採用非直譯方式的模擬器,下面就是一個例子

http://andrewkelley.me/post/jamulator.html

多數是採取8bit的遊戲主機為範本,讓異質的機械碼編譯成x86原生碼.

wii模擬器Dolphin中,也看得到模擬模式中有類似含意的選項.

這是非常有趣的嘗試,不過因為技術層次比較高,多數人會先採取將較為簡單的機械碼做轉換,所以才通常是會8bit遊戲主機的模擬器來學習,但實際上如果以實用性來說,CPU 模擬的運算在古早主機中負擔比例其實很低,反來是GPU等等部分模擬代價較高,通常會這樣做多數可能是基於研究或是學習立場,並沒有真的帶來很多好處.

不過如果是近年來的進階機種,cpu模擬耗用運算可能就不低了,這時候這種效能比直譯佳的運作模式,就帶來很多好處.

這種東西其實有很多進階討論的空間,而且不單單能在遊戲模擬器上發揮,試想著ARM與X86透過編譯步驟的方式,就能快速擁有雙邊硬體的相容性,這是多夢幻的"未來"....


跟上面這種往高階領域剛好相反的模擬方式(上面是軟體發展的進步),是由於近年來硬體效能快速發展下產生的,那就是往更低的領域發展,電晶體準確層次的模擬器,也就是說它的模擬基礎是從電路邏輯層開始,這種設計方式反來耗用更高的運算資源,不過有著其他方式無法取代的優點,像是絕對準確的tinimg特性.保證原汁原味的功能等等,目前也已經開始有零星實作出現,但通常是技術宣示性質,執行效能還得做不少改善,才能到實用的地步.

想像一下如果真的是在未來,電腦主機效能強大到無法想像的地步,模擬一台主機所要做的是把遊戲主機拆解,邏輯晶片打開,拍張照,把線路layout匯出描述,接著就可以跑了,也是一件很夢幻的事情...誰知道那天何時到來?  就像是當初誰也想不到現金一台手機的效能,就打死過去一整台桌機一樣.

目前是受限效能,因為邏輯電路是平行的運作方式一層一層下去,從這層次去模擬代價是相當多倍的運算資源,不過讓我發想的倒是這種運作方式在平行運算的超級電腦上似乎還ok,又或者是近年來利用顯卡異構計算的平行處理運算資源輔助?  這似乎也是一個方向.

相關參考
http://www.mobile01.com/topicdetail.php?f=514&t=1799027
http://blog.visual6502.org/2014/10/atari-2600-simulation.html
http://psxdev.ru/news
http://hackaday.com/2014/12/18/counting-transistors-in-the-playstation/
http://sourceforge.net/projects/dice/

ideal很多,不代表我有辦法在現在去做一些想法驗證,多數還是看看資訊.整理資訊而已.

8086tiny 相當有趣的 8086 PC 模擬器專案

Intel 8086介紹
http://www.mynikko.com/CPU/8086.html

專案網址 8086tiny
https://github.com/adriancable/8086tiny

別人再次延伸功能與修改版本 8086tiny plus
http://jaybertsoftware.weebly.com/8086-tiny-plus.html

原本對PC模擬器比較沒興趣,但就剛好看到這別人的專案,短短的不到800行code,完整實作8086電腦PC,完成度跑遊戲 WIN3.0 都不是問題,真的是滿神奇的.

回想起以前用ET3跟PE2.DOS的歲月....雖然它是以8086為對象,8086跟現在電腦相比少了非常多非常多功能,但是卻是80x86系列的開山始祖(比8086更早前的Intel處理器差異比較大,一般大家是把8086定義成為x86的開端),某種意義上算是一個簡化的雛型實作,16bit的暫存器.最大1MB記憶體定址.只有真實模式雖然陽春但跑跑一些早期的東西也不是問題了.

大體上看了一下專案的內容,作者真的把8086指令集K的很透徹,所以大幅減少CPU這塊處理的程式碼,另外文字模式直接借用現成環境 console 輸出,也是少了很大一部分,因此這款模擬器會在進入到繪圖模式時另外跳出SDL視窗.....雖然很怪異,但也因為簡化.簡單,讓人可以很快地了解整台電腦的基礎運作,也方便做最簡易的實作.

比起遊戲主機,似乎PC的模擬器並不用做cycle時序性處理的問題,有的也只有怕現在電腦太快,所以有在一些環節加上delay,調整速度,但並沒有一個很精確的速度模擬.

滿有趣的東西....

這種做法是一種方式,大概略知一二 ,dosbox 或是 bosch 都是這樣 , 但進階的像是QEMU dynamic binary translation 模擬方式,或是更快的  virtualization 技術層次又更高,效率又更好了,只是實作門檻想必然更高.

PS.補充一個CANON EOS相機的移植版
http://www.magiclantern.fm/forum/index.php?topic=14853

C# 效能校調優化感想

總是會好奇C#效率表現的最高點為何,特別像是video filter處理那塊的效率,因此做一些code的調整,零零星星的大原則處理完畢後,接著是一些比較偏向於編譯器那塊細節的部分,這麼說也不太正確,因為我還沒摸到編譯器內部處理本身,除非自己玩opensource,而是指修改一些code的寫法,盡量讓編譯器產生比較有效率的code....多數都是用stopwatch實際測試看看,平平兩種寫法,在運算吃重時候就是會有差異,但往往會覺得...奇怪? 並不是自己觀念中預料的方式會比較好,有時候自以為簡化運算或是優化,結果反來會有反效果,又x86.x64模式的不同 . .net framework版本不同 . 一般模是執行或debug模是執行 . 是否有開啟優化處理 ,都會有些不太一樣 , 於是整個優化的修改過程比較像是try error , 反正stopwatch數據哪個好就用那種方式去寫,有一種被黑盒子遮蔽住的感覺,特別像是 .net 或是 java 這種會產生中介碼的技術,除了如何產生中介碼本身是一個變數環節外,之後JIT階段如何執行又是一個變數,因此形成一種讓人難以捉摸的感覺,你不知道你的CODE會被編譯器編譯出怎樣的中介碼,然後你也不知道這些中介碼會如何被 JIT 詮釋..

因此得到的結論是,如果真的要掌握和控制,追到中介碼反組譯是不夠的,連 JIT 產生怎樣的Native Code都要下去看看,才知道到底怎麼回事.....

目前是沒摸到這塊,也許以後興致來了再看看吧.

不過想起來很妙,人類傾向將底層的技術包裝起來變成越高階抽象方便的工具 ( ASM -> C -> C++ -> C# ) , 但用了方便的高階工具後又因為想掌握細節和自由,所以從高階抽象的那一層鑽研回底層低階的那塊 .