Mini vMac

軟件截圖:
Mini vMac
軟件詳細信息:
版本: 3.5.8 更新
上傳日期: 2 Oct 17
開發: Paul C. Pratt
許可: 免費
人氣: 44

Rating: 5.0/5 (Total Votes: 1)

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


作為蘋果設計的最早的Macintosh機器之一,Macintosh Plus僅運行舊的Mac軟件,當然這些軟件在最近的Macintosh電腦上無法使用。因此,Mini vMac軟件有助於保存歷史記錄。它被設計為盡可能易於使用,便攜和簡單。


迷你vMac入門

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

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

獲得Macintosh Plus ROM映像後,您必須關閉程序並重新打開。如果ROM文件有效,系統將自動啟動並允許您像使用任何其他虛擬化操作系統一樣使用它。


運行在所有主流操作系統上

這個軟件實際上是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的報告。

截圖

mini-vmac-220691_1_220691.gif
mini-vmac-220691_2_220691.gif

顯影劑的其他軟件 Paul C. Pratt

Mini vMac
Mini vMac

4 May 20

意見 Mini vMac

評論沒有發現
添加評論
打開圖片!