Snow – Emulator für klassische Macintosh-Modelle

 (snowemu.com)
3 Punkte von GN⁺ 2025-06-28 | 1 Kommentare | Auf WhatsApp teilen
  • Snow ist ein Open-Source-Emulator, der das Hardware-Verhalten von Motorola-680x0-basierten Macintosh-Systemen so realitätsnah wie möglich nachbildet
  • Er bietet eine grafische Benutzeroberfläche (GUI) sowie leistungsstarke Debugging-Funktionen
  • Anders als bestehende Emulatoren setzt er auf einen Ansatz, der ROM-Patches oder das Abfangen von System-Calls minimiert
  • Unterstützt die Modelle Macintosh 128K/512K/Plus/SE/Classic/II
  • Entwickelt auf Rust-Basis und für verschiedene Betriebssysteme build- und downloadbar

Projektüberblick

  • Snow ist ein Emulator, der klassische Macintosh-Computer (680x0-Familie) softwareseitig nachbildet
  • Nutzer können ihn über eine grafische Oberfläche bedienen, ähnlich wie einen echten Mac
  • Dank umfangreicher Debugging-Funktionen eignet er sich gut für Entwicklung und Analyse

Funktionsweise und Merkmale

  • Snow zielt auf eine möglichst vollständige Emulation auf Hardware-Ebene (Low Level) ab
    • Anstatt wie üblich das ROM zu patchen oder System-Calls zu umgehen, verhält er sich dadurch wie echte Hardware
  • Offiziell unterstützte Modelle:
    • Macintosh 128K
    • Macintosh 512K
    • Macintosh Plus
    • Macintosh SE
    • Macintosh Classic
    • Macintosh II
  • Implementiert in Rust, mit Fokus auf Effizienz und Sicherheit
  • Als Open Source unter der MIT-Lizenz veröffentlicht

Testen und Dokumentation

  • Es gibt eine eingeschränkte Demo-Version, die im Webbrowser ausgeführt werden kann
    • Sie bietet allerdings nicht alle Funktionen der vollständigen Software, insbesondere nicht die GUI
  • Detaillierte Informationen zu Installation und Nutzung finden sich in der Online-Dokumentation

Download-Hinweise

  • Derzeit wird automatisch nur die neueste Entwicklungsversion (bleeding edge build) bereitgestellt
    • Windows 10 oder neuer (x86 64-Bit)
    • macOS 11.7 (Big Sur) oder neuer (Universal)
    • Linux (Ubuntu 24.04, x86 64-Bit und ARM64)
  • Für die jeweiligen Betriebssysteme werden sofort herunterladbare Build-Dateien verteilt

Kontakt und Mitwirkung

  • Über das GitHub-Repository können Issues gemeldet und Beiträge eingereicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-28
Hacker-News-Kommentare

  • Zum Kontext, warum ein portabler und benutzerfreundlicher Hardware-Level-Emulator für klassische Mac-Systeme bedeutsam geworden ist, siehe auch diesen Blogbeitrag von 2020: https://invisibleup.com/articles/30/ Für Spielkonsolen gibt es schon lange hervorragende Emulatoren wie Nestopia, bsnes, Dolphin und Duckstation, während bei PCs Virtualisierungssysteme wie VMWare und VirtualBox den verbreiteten Bedarf abgedeckt haben und in jüngerer Zeit hochpräzise Emulatoren wie 86Box und MartyPC hinzugekommen sind. Für den Commodore 64 gibt es VICE, für den Amiga WinUAE und für den Apple II hochwertige Emulatoren wie KEGS und AppleWin, aber auf der Mac-Seite gab es meiner Ansicht nach vor allem Emulatoren wie Basilisk II, die eher auf hohem Abstraktionsniveau arbeiten und das System nur grob ähnlich nachbilden.

    • In Bezug auf die Kompatibilität zwar deutlich eingeschränkt, aber es gab auch die Alternative Executor: https://en.wikipedia.org/wiki/Executor_(software) Es gibt eine Demo, in der ein Browser MS-DOS emuliert und darauf mit Executor/DOS ein Solitaire-Spiel für den Macintosh ausführt: https://archive.org/details/executor Neben Executor/DOS gab es auch eine nicht öffentliche Version für Sun-3-Workstations mit 680x0-Prozessor sowie Executor/NEXTSTEP für die NEXTSTEP-Umgebung. Es wird darauf hingewiesen, dass Executor die geringste Kompatibilität hatte, weil keinerlei geistiges Eigentum von Apple verwendet wurde; sowohl der ROM-Ersatz als auch der Ersatz für die Systemsoftware wurden komplett im Clean-Room-Verfahren neu geschrieben. Ältere Versionen von Executor verwendeten gcc-spezifische Erweiterungen, sodass ein Build unter heutigem Linux schwierig oder unmöglich sein könnte. Ich habe selbst eine frühe Version des Executor-Projekts entwickelt, während der performante 68k-Emulator und das Farbsystem von deutlich besseren Programmierern geschrieben wurden.

    • Der Inhalt des Artikels stimmt zwar, aber ich stimme zu, dass er die Bemühungen der freien Community etwas zu stark herabsetzt.

    • Es wird betont, dass MAME Macintosh und Apple II ebenfalls auf Hardware-Ebene emuliert; genauer als KEGS und AppleWin und mit breiterer Peripherieunterstützung, aber weniger benutzerfreundlich.

    • Ich habe versucht, den Macintosh II FDHD-Emulator zu starten, aber im Menü erschien nur die Meldung, man solle 400K/800K-Disketten laden. Im Snow-Handbuch steht jedoch ausdrücklich, dass zwei SuperDrives unterstützt werden: https://docs.snowemu.com/manual/media/floppies Vielleicht deshalb hat er bisher jedes Diskettenabbild sofort wieder ausgeworfen, das ich eingelegt habe, und selbst eine 800K-System-7.1.1-Diskette für ein Mac-II-kompatibles System wurde nicht erkannt. Ich denke, Snow hat viel Potenzial und ich zolle der Arbeit Respekt, aber die Mac-Emulationsszene ist weiterhin ein Zustand, in dem verschiedene Emulatoren jeweils sehr uneinheitlich Hardware und Funktionen unterstützen, allerlei Tricks und Vorwissen über die interne Architektur alter Macs weiterhin nötig sind und alles noch ziemlich nach zukunftsorientierten Versprechen klingt.

    • Hinweis darauf, dass MAME auch 68k-basierte Macintoshes in gewissem Umfang unterstützt: https://wiki.mamedev.org/index.php/Driver:Mac_68K

  • Wegen der Genauigkeit des Emulators fehlen ihm vermutlich einige der entscheidenden Funktionen von BasiliskII. BasiliskII bietet durch Patches an OS und ROM Unterstützung für extrem hohe Auflösungen sowie eine weitgehend nahtlose Integration mit dem Host-Dateisystem und Netzwerk. Das mag vielleicht unsauber oder ungenau sein, aber auch wenn die Benutzererfahrung nicht diese besondere Reinheit hat, ist die Bedienung, wenn es funktioniert, wirklich sehr angenehm.

    • Wenn ein Emulator präzise ist und zugleich eine saubere Codebasis hat, scheint es leicht zu sein, solche Patches oder Funktionen zusätzlich aufzusetzen. Als ich mir den Patch-Code von Basilisk direkt angesehen habe, war er tatsächlich nicht kompliziert, und es gibt Beispiele für partielle Toolbox-Neuimplementierungen wie Executor (dessen Autor in diesem Thread auftaucht) und MACE. Für ein Port wäre es zwar einiges an Umfang, aber es wirkt so, als würde es genügen, den ursprünglichen Code fast unverändert zu übernehmen und eine Test-Infrastruktur hinzuzufügen.

  • Ich brauche Rat, wie man an ROM-Dateien für Macs kommt. Ich habe mehrere von einer bei Google gefundenen Website heruntergeladen, aber der Emulator meldet immer nur „Unbekannte oder nicht unterstützte ROM-Datei“. Gibt es Tipps, wie man brauchbare ROMs findet?

  • Arbeiten aus meiner frühen Zeit nach dem Uni-Abschluss sind auf Mac-formatierten Bernoulli-Disketten gespeichert. Um die Software auszuführen, ist zwingend ein ADB-Dongle nötig, daher frage ich mich, ob physische Hardware unvermeidlich ist. Konkret: Gibt es ADB-USB-Adapter, die sich so zuordnen lassen, dass ein Emulator sie nutzen kann?

    • Die mir bekannten ADB-USB-Adapter unterstützen bislang nur Maus und Tastatur, und ihre interne Firmware lässt sich nur auf USB HID abbilden. Für vollständiges Passthrough wäre benutzerdefinierte Firmware nötig; möglicherweise wäre es einfacher, gleich den Kopierschutz dieser Software zu knacken.

    • Falls du noch kein Backup gemacht hast, besteht ein Risiko für Datenverlust; wenn dir die Daten wichtig sind, solltest du sie möglichst bald prüfen.

    • Wer ein funktionierendes Bernoulli-Laufwerk hat, besitzt oft auch gleich die passende alte Mac-Hardware dazu.

    • Vielleicht hilft dieses Produkt: https://www.bigmessowires.com/usb-wombat/

  • Es wird hervorgehoben, dass der in Rust neu implementierte 68K-Emulator keinerlei weithin bekannten C-basierten CPU-Code wie Musashi oder UAE verwendet.

  • Ich habe mit allgemein leicht verfügbaren Mac-OS-7.1-Installationsdisketten und einer Mac-Plus-ROM-Datei versucht zu booten, aber Laufwerk 0 wirft die Diskette immer wieder aus. Mini vMac funktioniert, aber hier scheint noch Verbesserungsbedarf zu bestehen.

  • Ich finde es merkwürdig, dass bei Mac SE oder II und ähnlichen Modellen die HD20-Unterstützung als „nicht zutreffend“ markiert ist. Alle Modelle außer dem II unterstützen HD20-Booting bereits im ROM. Ich nutze selbst einen HD20-Emulator an einem Mac SE und halte das für eine sehr gute Methode, verschiedene Formen von Disk-Images sowohl auf dem Mac als auch mit einem Floppy-Emulator einfach einzusetzen.

  • Ich frage mich, ob der Macintosh wie die Lisa „cycle accuracy“ auf Hardware-Ebene braucht. Bei der Lisa setzt das OS Hardware-Timing voraus, was Emulatoren wie Qemu nicht erfüllen.

    • Frühe Macs verwendeten den IWM (einen Chip, der den Disk-II-Controller integriert), und wie beim Apple II wurde dort Code eingesetzt, der auf Zyklusgenauigkeit angewiesen ist. Dass die Cursorbewegung plötzlich stoppt, liegt daran, dass der 60-Hz-Interrupt-Timer während des Schreibens auf Diskette abgeschaltet werden muss. Andy Hertzfeld erwähnte diese Anekdote auf Folklore.org: https://www.folklore.org/Nybbles.html Die ungewöhnlichen Disk-Kopierschutztechniken des Apple II (spiralförmige Tracks, Sektoren verschiedener Größe, unterschiedliche Nibbilization-Verfahren) wären theoretisch auch auf dem Mac möglich; ich frage mich, ob es dafür reale Beispiele gab.

  • Mein persönlicher Eindruck ist, dass die Umsetzung wirklich sehr authentisch wirkt. Gibt es Hoffnung, dass auch Atari-ST-Emulation möglich wird?

    • Es gibt bereits das sehr hochwertige Atari-ST-Emulatorprojekt Hatari: https://github.com/hatari/hatari Außerdem deckt der auf geringe Latenz ausgelegte Emulator Clock Signal (CLK) eine breite Palette klassischer Systeme ab, darunter Acorn, Amstrad, Apple II/II+/IIe, Atari ST und 2600: https://github.com/TomHarte/CLK