Mini vMac

迷你vMac 是一款開源的，免費的，跨平台的圖形化軟件，用C實現，並由偏移設計，用作蘋果公司創建的Macintosh Plus計算機系統的仿真器，運行在Linux，BSD，Microsoft Windows和Mac OS X操作系統上。

要在GNU / Linux系統上使用Mini vMac應用程序，請確保您下載與計算機硬件架構相對應的二進制包，將存檔保存在計算機上的某個位置，將其解壓縮並雙擊可執行文件

應用程序將打開，通知您無法找到Macintosh Plus系統的ROM映像。這意味著您還必須獲取一個vMac.ROM文件（更多詳細信息可以在項目主頁上找到），並將其放在與Mini vMac可執行文件相同的文件夾中。

這個軟件實際上是vMac應用程序的一個分拆，多年來還沒有更新。為了方便起見，它作為前面提到的操作系統的預先構建的二進制包進行分發，支持64位（x86_64）和32位（x86）指令集架構。

新版本：

• 今天的Mini vMac 3.5.8更新了穩定版本以解決PowerPC OS X上的問題，並且還修復了影響變更服務的問題。除了PowerPC OS X（'mach'）和x86-32 OS X（'imch'）以外的平台上，Mini vMac 3.5.8應與Mini vMac 3.5.7相同，但版本字符串和修改日期除外。 / LI>
• 據報導，“Mini vMac 3.5.7不會在PPC G3系統上運行”。事實證明，GCC標誌“-mmacosx-version-min”應該為所有編譯的文件指定，而不僅僅是依賴平台的代碼。它影響到像所需的CPU這樣的東西。對於x86-64 OS X，發生這種變化對Mini vMac沒有影響，x86-32 OS X有一些效果，最大的影響是PowerPC。

3.3.3中的新功能：

• 默認編譯中的新功能：
• 更多操作系統由Mini vMac官方支持：
• x86-32上的FreeBSD（在構建系統中使用“-t fbsd”）
• x86-64上的FreeBSD（“-t fb64”）
• x86-32上的OpenBSD（“-t obsd”）
• x86-64上的OpenBSD（“-t ob64”）
• x86-32上的NetBSD（“-t nbsd”）
• x86-64上的NetBSD（“-t nb64”）
• x86-32上的蜻蜓BSD（“-t dbsd”）
• x86-64上的蜻蜓BSD（“-t db64”）
• OpenIndiana on x86-32（“-t oind”）
• OpenIndiana on x86-64（“-t oi64”）
• Linux on ARM（“-t larm”）
• Linux on SPARC（“-t lspr”）
• Minix 3.2（“-t minx”）
• 這些端口適應與Linux端口相同的X Window代碼，並且應具有相同的功能，除了一些當前不是聲音。由於缺少彙編語言調整，x86-64版本的速度更慢，如果x86-32版本可以工作，則不應該使用x86-64版本。
• X版本現在可以使用開放聲音系統（OSS）API播放聲音。 （通常在每個操作系統上使用兼容的實現，而不是官方的OSS本身）。默認情況下，FreeBSD和NetBSD啟用了聲音。聲音編譯沒有問題（使用“-sound 1”）在蜻蜓BSD和OpenIndiana，但我還沒有能夠測試這些。在蜻蜓BSD上獲得聲音似乎需要一些手動設置。 OpenIndiana在VMware Fusion中似乎沒有任何聲音。聲音也在OpenBSD上編譯沒有問題，但它不起作用 - 設置所需的採樣率失敗。 Minix似乎還沒有支持聲音。還可以在Linux上使用OSS API，使用新的“-snd-api”構建系統選項。
• 現在，X版本將嘗試查看包含ROM映像的應用程序的文件夾，如Macintosh和Windows版本。 （也適用於disk1.dsk等文件）如果無法確定應用程序目錄，則使用當前目錄。這適用於Linux，FreeBSD，NetBSD，Dragonfly BSD和OpenIndiana，但不支持OpenBSD和Minix。
• X版本現在有一個新的命令行選項“-d [directory_path]”，其中使用[directory_path]而不是應用程序目錄來查找ROM映像，以及disk1.dsk等文件
• X版本現在有一個新的命令行選項“-n [app_name]”，其中使用[app_name]而不是Mini vMac窗口的標題的應用程序名稱。
• X版本現在支持像Macintosh和Windows版本一樣的中央ROM文件夾。如果“〜/ .gryphel / mnvm_rom”存在，Mini vMac將會看到ROM映像。如果不存在，它將在應用程序目錄中查看。 （而且-r命令行選項將覆蓋兩者。）
• 更改行為默認編譯：

將仿真屏幕繪製到實際畫面更為有效。當顏色深度為4位或更少時，不是轉換每個像素，所以有一個256個條目的表，用於一次轉換一個字節。更為小心的只是轉換矩形框內的像素，而不是整個屏幕
• Linux版本動態加載ALSA庫以播放聲音，因此即使沒有安裝ALSA，Mini vMac仍然可以運行，沒有聲音。 （這種技術在SDL中被看到）所以默認情況下，Linux版本現在編譯有聲音，與Mac和Windows版本相匹配。
• 在Linux版本中，當使用ALSA播放聲音時，不再調用snd_pcm_delay。播放樣本之前的延遲並不真正相關。 Mini vMac需要知道什麼是緩衝區的時間。因此，Mini vMac現在看緩衝區大小減去緩衝區中的可用空間，這可能更有用，以防止緩衝區欠載，同時最小化延遲。
• X版本現在使用諮詢鎖定拒絕打開，以便寫入由另一個Mini vMac副本打開的磁盤映像。以前，X版本的Mini vMac可能打開已經打開的磁盤映像，可能會破壞映像。如果Mini vMac只能打開一個只讀的磁盤映像，例如由於用戶已鎖定該文件，則不會使用該建議鎖，並且Mini vMac的多個副本可以使用。
• X版本現在嘗試使用應用程序名稱來設置其窗口的標題，如Macintosh和Windows版本。 （如果無法確定應用程序名稱，則會像以前一樣使用“Mini vMac”。）這與應用程序目錄同時發現，並且是為相同的操作系統實現的。
• 現在，在查找disk1.dsk等文件之前，將掃描命令行參數。這對於新的“-d”是必要的。選項工作，並且具有副作用，如果在命令行上指定了磁盤映像，它們將被首先打開。如果命令行上有圖像，那麼Mini vMac現在就不用去尋找disk1.dsk了。
• “-l” （或Windows上的“/ l”）命令行選項被刪除。 “速度z”應該使用構建系統的選項。命令行選項來自構建系統之前，決定有利於構建運行時間選項。
• 錯誤修正在默認編譯：
• Windows版本現在將數字鍵盤上的Enter鍵映射到Macintosh Enter鍵。現在可以將該鍵與主鍵盤上的Enter鍵區分開，並將其映射到Macintosh Return鍵。以前沒有辦法鍵入Macintosh Enter鍵。感謝“Alex”指出這個問題。
• 在Windows版本中，在全屏模式下，檢查鍵下拉事件是否是自動重新鍵是不正確的。所以潛在的鑰匙可能會被忽略，當他們不應該是。我已經取消了支票，因為不清楚如何正確執行（使用“低級別鍵盤掛鉤”）時。這不會影響Macintosh仿真，因為對冗餘事件進行了額外的檢查。它可以影響控制模式，例如按住Control-M時。
• Windows版本現在響應WM_QUERYENDSESSION消息，因此如果您嘗試使用Mini vMac運行（帶有已安裝的磁盤映像）關閉計算機，則Mini vMac將抱怨並停止關閉。
• 在Linux版本中，使用ALSA播放聲音，在將任何聲音樣本放入ALSA緩衝區之前，調用snd_pcm_start。這可能會在開始時引起口吃，或根據一份報告，可以防止聲音工作。 Mini vMac現在等待它的私人緩衝區已滿，然後傳輸到ALSA緩衝區，然後開始播放聲音。
• 當為ARM編譯Linux版本時，它包含一個檢查，snd_pcm_avail_update的結果是否合理，如果不是調用snd_pcm_status_get_avail。這對Raspberry Pi的Raspbian似乎是一個錯誤。

仿真時鐘沒有被正確初始化，並且在第一個“第二”之後是正確的。中斷。
• 如果模擬屏幕太大，無法放在實際屏幕上（當自動滾屏可用時），如果已更改的仿真屏幕區域與仿真屏幕的可見區域不相交，則無效矩形為用於繪圖。我發現這個時候嘗試了Vector Linux 7，似乎有一些額外的調試檢查。
• 在不太可能的情況下，在全屏模式下，自動滾屏可能無法滾動顯示右下角或最後一列像素的最後一行像素。
• 如果主機不足以使Mini vMac以1x速度運行，那麼Mini vMac將無法順利運行，定期暫停幾秒鐘。這種情況的測試是不正確的，一個字節的計數器會溢出。 （盡可能小的這樣的計數器使得更容易檢測到這樣的錯誤。）
• 在X Window版本的Mini vMac中，當使用Mini vMac擴展在主機系統上創建文件時，例如使用ExportFl，則不會執行保存對話框。以前，這個文件只能在應用程序目錄中被創建，並帶有請求的名稱。這不安全，最糟糕的是它允許在Mini vMac中運行的程序來替換Mini vMac應用程序。因此，現在，文件將被創建在名為“輸出”的文件夾中在包含應用程序的目錄中。如果不存在，將創建該文件夾。
• 在Microsoft Windows版本中，如果在超過路徑合法的命令行上將磁盤鏡像的路徑傳遞給Mini vMac，則會產生緩衝區溢出。
• Windows CE版本遭受了點腐敗。它現在可以編譯，至少在Windows Mobile版本5.0的Microsoft Device Emulator上工作。我不知道它是否適用於真正的硬件。有人在乎嗎？ （Windows Mobile已停止，並被Windows Phone取代。）此端口開始乾擾維護主要的Windows版本，並且選擇是完全刪除它或使其可維護。
• 新功能未在默認編譯：

新的構建系統選項“-lt”使Mike Fort的LocalTalk模擬。目前有一些限制。它僅適用於OS X.它需要運行命令“sudo chmod ugo + rw / dev / bpf *”允許Mini vMac（和其他人）訪問所有網絡流量。 “-1t”默認情況下，Mini vMac可以在後台運行，因為如果沒有運行Mini vMac，則無法成為正確的LocalTalk節點。而您需要在選擇器中手動打開AppleTalk - 我可以將PRAM標誌設置為使用AppleTalk啟動但不能正常工作。
• 新的構建系統選項“-lang pol”選擇Przemyslaw Buczkowski的用戶界面的波蘭語翻譯。
• X版本最初支持顏色（適用於Mac II仿真）。迄今為止，X版本僅支持24位“TrueColor”，並且對格式有其他一些限制。我懷疑除了TrueColor之外的任何東西都在現代機器上使用，所以可能不支持其他選項。可以使用其他深度，如15,16和32位，如果我可以找到一種方式來測試它們，可能應該支持它。

一個新的構建系統選項“-mf”允許從默認值2更改放大倍率。例如，“-mf 3”將放大倍率設置為3.選項“-mf 1”禁用放大（刪除Control-M命令）。放大係數必須是整數。
• 更改行為不在默認編譯：
• Mac II仿真的默認顏色深度為“-depth 3”而不是“-depth 0”。
• 對於Macintosh II仿真，AutoSlow默認情況下已禁用“-as 0”。 AutoSlow可能需要進一步調整才能與Mac II仿真一起使用。
• 在X版本中，現在檢查fwrite和fread在磁盤映像上的結果是否有錯誤，這會阻止最近Ubuntu中的編譯器警告。
• 錯誤修正不在默認編譯：
• 修正了“AP”報告的DIVS.L指令中的錯誤。 （在Mac II仿真中使用的A 68020指令。）
• 修正了由“AP”報告的BFFFO指令，該指令已經完全中斷了。 （另一個68020指令用於Mac II仿真。）
• 寄存器上的位域操作現在使用旋轉而不是移位。所選擇的位可以是非連續的，如“AP”所指出的，並由文檔證實。 （位操作字段已添加到68020中。）
• 現在，對存儲器進行位字段操作，只能根據需要操作盡可能多的字節。以前，它總是以5個字節運行，如“AP”所指出的，如果在內存映射設備上運行，則可能會產生不良影響。
• “MoveP.L，Dn”指令混合了移動和掩蔽的順序，因此被完全破壞，如“AP”所報告的。
• 在Macintosh II仿真中允許額外大量視頻RAM的黑客無法正常工作，因為用於CPU仿真中的地址空間轉換的陣列未分配足夠大。現在，構建系統選擇分配大小。 （這個問題是1024x768，數百萬種顏色）。更詳細的說明：當計算機處於24位模式時，每個NuBus卡只能獲得1M的地址空間。而Mac II似乎通常採用24位模式。當需要更多的視頻RAM用於所請求的編譯時間選項時，Mini vMac將使用相鄰NuBus插槽的地址空間。
• 修正了“-min-extn”在Linux版本中構建選項。
• 構建系統：
• 添加了構建系統選項“-api cco”將Apple的Cocoa API用於OS X，而不是不推薦使用的Carbon API。但是Mini vMac的可可端口尚未被認為已經準備好正式支持，因此仍然使用Carbon版本。
• 添加了構建系統選項“-api sdl”使用Simple DirectMedia Layer 1.2 API。這被添加為Cocoa端口的墊腳石 - 通過將SDL的源代碼與Mini vMac的SDL端口的源代碼相結合，然後刪除所有不需要的內容，然後大量清理，直到最初的本機可可港口湧現。然而，SDL端口可以按原樣用於連接到SDL支持的其他平台。但這不是（尚未）正式支持。
• 添加了構建系統選項“-t mx64”適用於x86-64上的Apple X11實現。 （以前支持x86-32和PowerPC。）
• 添加了構建系統選項“-t cygw”對於Cygwin / X for Microsoft Windows。 Cygwin也可用於編譯具有“-t wx86 -e cyg”的常規Microsoft Windows版本。

添加構建系統選項“-t irix”對於IR Graphics，Silicon Graphics，Inc.，感謝John Perkins。
• MinGW可用於使用構建系統選項“-t wx86 -e mgw”編譯Mini vMac。由於Bloodshed Dev-C ++基於MinGW，“-t wx86 -e dvc -cl”以前會提供類似的結果。
• 在構建Linux版本時，更改鏈接命令的順序。事實證明，有一個常規的順序，如何指定庫，我不知道，因為我沒有遇到一個鏈接器，直到Ubuntu 11.10。
• 構建系統現在應該可以在其他仿真器（如SheepShaver）中正常工作。匿名報告說，構建系統會使模擬器崩潰。對於構建系統是否在Mini vMac中運行（以便生成的歸檔可能導出到主機）的測試不夠好。
• 構建系統現在可以抑制使用Microsoft Visual C ++編譯Macintosh II仿真時生成的警告消息，感謝William Grana的報告。