Snow – Emulator für klassische Macintosh-Computer

 (snowemu.com)
3 Punkte von GN⁺ 2025-06-28 | 1 Kommentare | Auf WhatsApp teilen
  • Snow bildet klassische Macintosh-Computer auf Basis des Motorola 680x0 hardwarenah nach und macht alte Mac-Umgebungen auf modernen Systemen nutzbar
  • Statt ROM-Patches oder dem Abfangen von Systemaufrufen zielt es auf Emulation auf Hardware-Ebene ab und bietet zugleich eine grafische UI sowie Debugging-Funktionen
  • Unterstützt mehrere klassische Mac-Modelle vom Macintosh 128K bis zum SE/30, sodass sich die frühe Mac-Familie breit ausprobieren lässt
  • Ein in Rust geschriebenes Open-Source-Projekt unter MIT-Lizenz; eine eingeschränkte Online-Demo und Installationsdokumentation sind verfügbar
  • Stabile Releases gibt es auf GitHub; aktuelle Development-Builds sind weniger getestet, stehen aber für Windows, macOS und Linux bereit

Hardware-nahe Emulation klassischer Macs

  • Snow ist ein Projekt zur Emulation klassischer Macintosh-Computer auf Basis des Motorola 680x0
  • Es bietet eine grafische Benutzeroberfläche zur Bedienung der emulierten Maschine sowie umfangreiche Debugging-Funktionen
  • Ziel ist es, den Macintosh möglichst auf Hardware-Ebene zu emulieren, statt ROMs zu patchen oder Systemaufrufe abzufangen
  • Derzeit unterstützte Modelle:
    • Macintosh 128K/512K/512Ke
    • Macintosh Plus
    • Macintosh SE, non-FDHD und FDHD
    • Macintosh Classic
    • Macintosh II, non-FDHD und FDHD
    • Macintosh IIx, IIcx, SE/30

Veröffentlichung und Möglichkeiten zum Ausprobieren

  • Die Implementierungssprache ist Rust; der Code ist auf GitHub als Open Source verfügbar
  • Die Lizenz ist die MIT license
  • Es gibt eine eingeschränkte Online-Demo, in der jedoch nur die emulierte Maschine ohne die UI oder andere Funktionen der vollständigen Software genutzt werden kann
  • Installation und weitere Informationen finden sich in der Online-Dokumentation

Releases und Support-Kanäle

  • Stabile Releases werden paketiert, wenn bestimmte Meilensteine erreicht sind
  • Stabile Releases sind über GitHub releases erhältlich
  • Aktuelle Development-Builds (bleeding edge) werden im Zuge der Emulator-Entwicklung automatisch erzeugt und können neuere Funktionen enthalten, sind aber weniger getestet
  • Verfügbare aktuelle Development-Builds:
    • Windows 10 oder neuer x86 64-bit
    • Windows 10 oder neuer ARM64
    • macOS 11.7 Big Sur oder neuer Universal
    • Linux Ubuntu 24.04 x86 64-bit
    • Linux Ubuntu 24.04 ARM64
  • Bug Reports und Verbesserungsvorschläge werden über GitHub issues entgegengenommen
  • Support und Austausch sind im Kanal #snow auf dem The Opcode Collective Discord möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-28
Kommentare auf Hacker News

  • Wer den Hintergrund verstehen will, warum ein portabler und einfach zu bedienender Hardware-Level-Emulator für klassische Macs so wichtig ist, sollte diesen Artikel von 2020 lesen: https://invisibleup.com/articles/30/
    Für Spielkonsolen gibt es seit Langem Emulatoren wie Nestopia, bsnes, Dolphin und Duckstation; auf dem PC haben Virtualisierungslösungen wie VMWare und VirtualBox die meisten Anforderungen abgedeckt, und in jüngerer Zeit kamen auch Emulatoren mit hoher Genauigkeit wie 86Box und MartyPC hinzu.
    Für den C64 gab es VICE, für den Amiga WinUAE und auch für den Apple II hochwertige Emulatoren wie KEGS und AppleWin, aber beim Mac blieb es im Großen und Ganzen bei High-Level- und Näherungs-Emulatoren wie Basilisk II.

    • Es gibt auch Executor, auch wenn dessen Kompatibilität deutlich schlechter ist als bei den anderen: https://en.wikipedia.org/wiki/Executor_(software)
      Man kann sogar die Macintosh-Version von Solitaire im Browser laufen lassen, indem der Browser MS-DOS emuliert und darauf Executor/DOS ausführt: https://archive.org/details/executor
      Neben Executor/DOS lief eine unveröffentlichte Version auf Sun-3-Workstations, und Executor/NEXTSTEP lief auf NeXT-Maschinen; es unterstützte sowohl 680x0-basierte Geräte als auch x86-PCs, auf denen NEXTSTEP laufen konnte.
      Da Executor keinerlei geistiges Eigentum von Apple verwendete, hatte es die geringste Kompatibilität; die Ersatzimplementierungen für ROM und Systemsoftware waren Clean-Room-Implementierungen, die weder Apple-ROMs noch Systemdateien disassemblierten.
      Es gibt zwar einen Linux-Port, aber er dürfte schwer zu bauen sein. Der Grund ist, dass die synthetische CPU auf gcc-spezifische Erweiterungen angewiesen war, um auf dem 80386 die maximale Leistung herauszuholen.
      Ich kenne mich mit Executor ziemlich gut aus, weil ich die frühen Versionen geschrieben habe. Die wirklich beeindruckenden Teile wie der synthetische 68k-Emulator oder das Farb-Subsystem wurden allerdings von Programmierern gebaut, die mir weit überlegen waren.
    • Der Artikel ist objektiv richtig, aber ich habe selten gesehen, dass die mühsame Arbeit, die Leute kostenlos geleistet haben, auf so bizarre Weise herabgewürdigt wird.
    • Man kann es vielleicht nicht unbedingt „benutzerfreundlich“ nennen, aber MAME emuliert den Macintosh und den Apple II auf Hardware-Ebene.
      Es ist genauer als KEGS oder AppleWin und deckt mehr Peripherie ab, ist dafür aber weniger benutzerfreundlich.
    • Ich konnte den Macintosh-II-FDHD-Emulator zwar booten, aber obwohl das Snow-Handbuch sagt, dass der Mac-II-FDHD-Emulator zwei SuperDrives bereitstellt, bietet das Emulator-Menü unter https://docs.snowemu.com/manual/media/floppies nur das Laden von 400K/800K-Disketten an.
      Vielleicht deshalb wurden bisher alle Disketten-Images, die ich eingelegt habe, sofort wieder ausgeworfen, auch eine 800K-System-7.1.1-Diskette, die mit dem Mac II kompatibel sein soll.
      Snow hat großes Potenzial und ich respektiere die investierte Arbeit, aber ehrlich gesagt wirkt die Mac-Emulationslandschaft bisher nicht wesentlich anders als früher. Mehrere Emulatoren bieten eine unebene Produktmatrix aus emulierter Hardware und unterstützten Funktionen, erfordern viele Schritte sowie Vorwissen über alte Mac-Interna und wirken wie etwas, das vor allem für die Zukunft viel verspricht.
    • Nicht vergessen sollte man, dass auch MAME in gewissem Umfang 68k-Macintosh unterstützt.
      https://wiki.mamedev.org/index.php/Driver:Mac_68K

  • Wegen der Genauigkeit wird es die mächtigen Funktionen von BasiliskII vermutlich nicht geben. BasiliskII patcht OS/ROM, um ultrahohe Auflösungen und eine nahezu nahtlose Integration mit dem Host-Dateisystem und -Netzwerk hinzuzufügen.
    Schade ist, dass Basilisk trotz – oder wegen – seiner ungenauen, aber leistungsfähigen Funktionen ziemlich instabil ist. Wenn es richtig funktioniert, ist die Nutzung wirklich angenehm.

    • Ein genauer Emulator und eine saubere Codebasis sind ein guter Ausgangspunkt, um Patches oder Abkürzungen daraufzusetzen.
      Ich habe mir Basilisks Patch-Code angesehen; er war nicht so kompliziert, und in Basilisks internem Code, Executor, MACE usw. gibt es auch mehrere Neuimplementierungen von Teilen der Toolbox.
      Für eine Portierung wäre etwas Arbeit nötig, aber insgesamt dürfte es eher auf eine direkte Übersetzung des Codes plus testgetriebene Ergänzungen hinauslaufen.

  • Wie findet man ROMs? Ich habe über Google ein paar von gefundenen Websites heruntergeladen, aber der Emulator sagt immer „Unknown or unsupported ROM file“. Wo bekommt man eine verwendbare ROM-Datei?

  • Ein beträchtlicher Teil meiner frühen Arbeiten direkt nach dem College liegt auf einem Stapel Mac-formatierter Bernoulli-Disketten.
    Zum Ausführen der Software braucht man einen ADB-Dongle, also ist echte Hardware nötig. Ich frage mich, ob es ADB-USB-Adapter gibt, die sich in einen Emulator mappen lassen.

    • Alle ADB-USB-Adapter, die ich kenne, unterstützen nur Maus und Tastatur, und ihre interne Firmware mappt sie auf USB HID.
      Für Raw-Passthrough in einen Emulator müsste man vermutlich Custom-Firmware schreiben. Wahrscheinlich wäre es einfacher, die Software zu cracken.
    • Wenn du die Daten noch nicht gesichert hast, könnten sie bereits weg sein.
      Falls die Daten wertvoll sind, solltest du sie prüfen, bevor es zu spät ist.
    • Wer eine funktionierende Bernoulli-Box hat, besitzt wahrscheinlich auch einen passenden alten Mac dazu.
    • Das hier könnte vielleicht funktionieren: https://www.bigmessowires.com/usb-wombat/

  • Ich habe es mit leicht erhältlichen Standard-Installationsdisketten für Mac OS 7.1 und einem Mac-Plus-ROM geladen, aber die Diskette wird aus Drive 0 ausgeworfen.
    Da Mini vMac funktioniert, scheint hier noch Verbesserungsbedarf zu bestehen.

  • Es überrascht mich, dass die HD20-Unterstützung für SE, II usw. als „nicht zutreffend“ angezeigt wird. Soweit ich weiß, haben alle Modelle in der Liste außer dem II im ROM Unterstützung zum Booten von HD20.
    Ich nutze auch auf einem echten Mac SE einen HD20-Emulator.
    Das ist eine der bequemsten Methoden, Disk-Images beliebiger Größe sowohl in Mac-Emulatoren als auch in echte Floppy-Emulatoren zu übernehmen.

  • Da es sich um einen in Rust neu implementierten 68K-Emulator handelt, gibt es keine gemeinsamen Teile mit bekannten CPU-Cores in C wie Musashi oder UAE-Code.

  • Braucht der Mac, ähnlich wie die Lisa, eine zyklusgenaue Emulation der Hardware? Ich habe lisaem ausprobiert und auch mit Qemu experimentiert, aber Lisa OS trifft Annahmen über das Hardware-Timing, die Qemu nicht erfüllen kann.

    • Die frühen Macs nutzten den IWM, im Grunde eine auf einen Chip reduzierte Version von Wozniaks Disk-II-Controller von 1977.
      Dieselbe Technik mit zyklusgenauem Code wie beim Apple II wurde auch auf dem Mac verwendet.
      Das ist auch der Grund, warum der Cursor beim Schreiben auf Disk gelegentlich stehen bleibt. Der Mac hat zwar einen 60-Hz-Interrupt-Timer, der auch den Cursor verfolgt, aber während Schreibvorgängen muss er abgeschaltet werden.
      In einem Text von Andy Hertzfeld auf Folklore.org wird das nebenbei erwähnt:

      Woz's disk technology required that the software feed it new data every 32 microseconds exactly. If we were even a single microsecond early or late, it would cause a glitch in the data and ruin it. In order to write the routines, I needed to know how fast the Macintosh executed each instruction. The manual gave the number of clocks for each instruction, but I wasn't sure how long it took to fetch from memory. So of course, I asked Burrell what the timings were, but I was surprised at his response.
      "I don't know. The Mac is synchronous, just like the Apple II, so each instruction has the same timing, every time you execute it, so you will be able to write disk routines that have exact timing. I don't know what it is, so we'll just measure it. Why don't you write your routine and we'll measure it with the logic analyzer."
      -- https://www.folklore.org/Nybbles.html
      Wenn ich das sehe, dürften die ungewöhnlichen Disk-Techniken des Apple II wie spiralförmige Spuren, Sektoren unterschiedlicher Größe und verschiedene Nibblization-Verfahren theoretisch auch auf dem Mac möglich gewesen sein. Ich frage mich, ob sie tatsächlich für Kopierschutz eingesetzt wurden.

  • Es fühlt sich wirklich wie echte Hardware an, und die Arbeit ist hervorragend. Könnte man das auch für Atari-ST-Emulation verwenden?

    • Ist Hatari nicht bereits hervorragend? https://github.com/hatari/hatari
      Es gibt auch Clock Signal (CLK). Es beschreibt sich als „ein Emulator für Acorn Electron und Archimedes, Amstrad CPC, Apple II/II+/IIe und frühe Macintosh, Atari 2600 und ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 und Amiga, MSX 1/2, Oric 1/Atmos, frühe PC-Kompatible, Sega Master System, Sinclair ZX80/81 und ZX Spectrum, der Latenz hasst“: https://github.com/TomHarte/CLK