Snow - Émulateur de Macintosh classique

 (snowemu.com)
3 points par GN⁺ 2025-06-28 | 1 commentaires | Partager sur WhatsApp
  • Snow reproduit de façon fidèle au matériel les Macintosh classiques basés sur Motorola 680x0, afin de permettre d’utiliser d’anciens environnements Mac sur des systèmes modernes
  • Il vise une émulation au niveau matériel plutôt que des correctifs de ROM ou l’interception des appels système, et fournit à la fois une interface graphique et des fonctions de débogage
  • Il prend en charge plusieurs modèles de Mac classiques, du Macintosh 128K au SE/30, ce qui permet d’expérimenter largement avec les premiers modèles de Mac
  • Il s’agit d’un projet open source sous licence MIT écrit en Rust, avec une démo en ligne limitée et une documentation d’installation disponibles
  • Les versions stables peuvent être téléchargées sur GitHub, tandis que les derniers builds de développement, moins testés, sont proposés pour Windows, macOS et Linux

Émulation de Mac classique proche du matériel

  • Snow est un projet d’émulation d’ordinateurs Macintosh classiques basés sur Motorola 680x0
  • Il fournit une interface utilisateur graphique pour manipuler les machines émulées ainsi que de vastes fonctionnalités de débogage
  • Son objectif est d’émuler le Macintosh autant que possible au niveau matériel, plutôt que par des correctifs de ROM ou l’interception des appels système
  • Modèles actuellement pris en charge :
    • Macintosh 128K/512K/512Ke
    • Macintosh Plus
    • Macintosh SE, non-FDHD et FDHD
    • Macintosh Classic
    • Macintosh II, non-FDHD et FDHD
    • Macintosh IIx, IIcx, SE/30

Modalités de publication et parcours d’essai

  • Le langage d’implémentation est Rust, et le projet est publié en open source sur GitHub
  • La licence est la licence MIT
  • Une démo en ligne limitée est proposée, mais elle permet uniquement d’utiliser la machine émulée, sans l’interface utilisateur complète du logiciel ni les autres fonctionnalités
  • L’installation et des informations complémentaires sont disponibles dans la documentation en ligne

Versions et canaux de support

  • Les versions stables sont empaquetées lorsqu’un certain jalon est atteint
  • Les versions stables peuvent être téléchargées depuis les GitHub releases
  • Les derniers builds de développement (bleeding edge) sont générés automatiquement au fil de l’avancement du développement de l’émulateur ; ils peuvent inclure des fonctionnalités plus récentes, mais sont moins testés
  • Derniers builds de développement proposés :
    • Windows 10 ou version ultérieure x86 64-bit
    • Windows 10 ou version ultérieure ARM64
    • macOS 11.7 Big Sur ou version ultérieure Universal
    • Linux Ubuntu 24.04 x86 64-bit
    • Linux Ubuntu 24.04 ARM64
  • Les signalements de bugs et demandes d’amélioration sont reçus via les GitHub issues
  • Le support et les échanges sont possibles sur le canal #snow du Discord The Opcode Collective

À lire aussi

1 commentaires

 
GN⁺ 2025-06-28
Avis sur Hacker News

  • Pour comprendre pourquoi un émulateur portable et facile à utiliser, au niveau matériel, pour Mac classiques est important, on peut lire cet article de 2020 : https://invisibleup.com/articles/30/
    Les consoles de jeux disposent depuis longtemps d’émulateurs comme Nestopia, bsnes, Dolphin ou Duckstation ; côté PC, la virtualisation comme VMWare et VirtualBox a couvert la plupart des besoins, et plus récemment des émulateurs à haute fidélité comme 86Box et MartyPC sont apparus.
    Le C64 avait VICE, l’Amiga avait WinUAE, l’Apple II avait aussi des émulateurs de qualité comme KEGS et AppleWin, mais le Mac est resté en grande partie cantonné à des émulateurs de haut niveau et approximatifs comme Basilisk II.

    • Il y a aussi Executor, même si sa compatibilité est bien inférieure à celle des autres : https://en.wikipedia.org/wiki/Executor_(software)
      On peut même faire émuler MS-DOS par le navigateur, puis exécuter Executor/DOS dessus pour lancer la version Macintosh de Solitaire dans le navigateur : https://archive.org/details/executor
      En plus d’Executor/DOS, une version non publiée tournait sur des stations de travail Sun 3, et Executor/NEXTSTEP fonctionnait sur des machines NeXT ; il prenait en charge à la fois les appareils 680x0 et les PC x86 capables de faire tourner NEXTSTEP.
      Comme Executor n’utilisait aucune propriété intellectuelle d’Apple, sa compatibilité était la plus faible ; ses remplacements de ROM et de logiciels système étaient des implémentations en salle blanche, sans désassemblage des ROM Apple ni des fichiers System.
      Il existe bien un port Linux, mais il risque d’être difficile à compiler. Le CPU synthétique s’appuyait sur des extensions propres à gcc pour tirer le maximum de performances du 80386.
      Je connais assez bien Executor, car j’ai écrit ses premières versions. Cela dit, les parties vraiment impressionnantes, comme l’émulateur 68k synthétique ou le sous-système couleur, ont été réalisées par des programmeurs bien meilleurs que moi.
    • Cet article est objectivement juste, mais c’est la première fois que je vois le travail acharné que des gens ont fait gratuitement être dénigré d’une manière aussi étrange.
    • On ne peut peut-être pas vraiment le qualifier de « convivial », mais MAME émule le Macintosh et l’Apple II au niveau matériel.
      Il est plus précis que KEGS ou AppleWin et gère davantage de périphériques, mais il est moins convivial.
    • J’ai bien réussi à démarrer l’émulateur Macintosh II FDHD, mais même si le manuel de Snow indique que l’émulateur Mac II FDHD fournit deux SuperDrive, le menu de l’émulateur https://docs.snowemu.com/manual/media/floppies ne propose de charger que des disquettes 400K/800K.
      C’est peut-être pour cela que toutes les images de disquettes que j’ai essayées jusqu’ici ont été immédiatement éjectées, y compris une disquette System 7.1.1 en 800K censée être compatible avec le Mac II.
      Snow a beaucoup de potentiel et je respecte le travail investi, mais honnêtement, le paysage actuel de l’émulation Mac ne me semble pas très différent d’avant. Plusieurs émulateurs proposent une matrice produit irrégulière de matériels émulés et de fonctionnalités prises en charge, nécessitent de nombreuses manipulations et des connaissances préalables de l’ancienne architecture interne des Mac, tout en promettant surtout des progrès futurs.
    • Il ne faut pas oublier que MAME prend aussi en charge, dans une certaine mesure, les Macintosh 68k.
      https://wiki.mamedev.org/index.php/Driver:Mac_68K

  • Pour des raisons de précision, il n’aura probablement pas les fonctionnalités puissantes de BasiliskII. BasiliskII patche l’OS/la ROM pour ajouter une très haute résolution et une intégration presque transparente avec le système de fichiers et le réseau de l’hôte.
    C’est dommage que Basilisk soit assez instable, sans doute à cause de ses fonctionnalités puissantes mais imprécises. Quand il fonctionne correctement, il est vraiment agréable à utiliser.

    • Un émulateur précis avec une base de code propre est un bon point de départ pour ajouter des patchs ou des raccourcis.
      J’ai examiné le code de patch de Basilisk et il n’était pas si complexe ; on trouve aussi plusieurs réimplémentations partielles de Toolbox dans le code interne de Basilisk, Executor, MACE, etc.
      Le portage demanderait un peu de travail, mais cela ressemblerait globalement davantage à une traduction directe du code et à l’ajout d’une base de tests.

  • Comment trouver une ROM ? J’en ai téléchargé quelques-unes depuis des sites trouvés via Google, mais l’émulateur affiche toujours « Unknown or unsupported ROM file ». Où peut-on obtenir un fichier ROM utilisable ?

  • Une bonne partie de mes premiers travaux juste après l’université est stockée sur un tas de disques Bernoulli au format Mac.
    Le logiciel nécessite un dongle ADB pour s’exécuter, donc il faut du vrai matériel. Je me demande s’il existe un adaptateur ADB-USB qui pourrait être mappé vers l’émulateur.

    • Tous les adaptateurs ADB-USB que je connais ne prennent en charge que la souris et le clavier, et leur firmware interne les mappe en USB HID.
      Pour faire du passthrough brut vers l’émulateur, il faudrait probablement écrire un firmware personnalisé. Il serait peut-être plus simple de cracker le logiciel.
    • Si tu ne les as pas encore sauvegardées, ces données ont peut-être déjà disparu.
      Si ce sont des données précieuses, mieux vaut vérifier avant qu’il ne soit trop tard.
    • Quelqu’un qui possède un boîtier Bernoulli en état de marche a probablement aussi un vieux Mac adapté avec.
    • Ceci pourrait peut-être marcher : https://www.bigmessowires.com/usb-wombat/

  • J’ai essayé de le charger avec des disquettes d’installation standard de Mac OS 7.1 faciles à trouver et une ROM de Mac Plus, mais le disque est éjecté du Drive 0.
    Comme Mini vMac fonctionne, il semble qu’il y ait encore des améliorations nécessaires.

  • Il est surprenant que la prise en charge du HD20 soit indiquée comme « sans objet » pour les SE, II, etc. À ma connaissance, tous les modèles de la liste, sauf le II, disposent dans leur ROM de la prise en charge du démarrage sur HD20.
    J’utilise d’ailleurs un émulateur HD20 sur un vrai Mac SE.
    C’est l’un des moyens les plus pratiques de transférer des images disque de taille arbitraire à la fois vers des émulateurs Mac et vers de vrais émulateurs de disquettes.

  • Comme il s’agit d’un émulateur 68K réimplémenté en Rust, il ne partage rien avec des cœurs CPU bien connus écrits en C comme Musashi ou le code d’UAE.

  • Le Mac a-t-il besoin, comme le Lisa, d’une émulation cycle-exacte du matériel ? J’ai essayé lisaem et aussi expérimenté avec Qemu, mais Lisa OS fait sur les timings matériels des hypothèses que Qemu ne peut pas satisfaire.

    • Les premiers Mac utilisaient l’IWM, qui est essentiellement le contrôleur Disk II de Wozniak de 1977 réduit à une seule puce.
      Les mêmes techniques de code cycle-exact que sur l’Apple II étaient utilisées sur Mac.
      C’est aussi pour cela que le curseur se fige parfois pendant l’écriture sur disque. Le Mac dispose d’un timer d’interruption à 60 Hz qui suit aussi le curseur, mais il faut le désactiver pendant les écritures.
      Cela apparaît aussi en passant dans un article d’Andy Hertzfeld sur Folklore.org :

      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
      Cela me fait penser que les techniques de disques atypiques de l’Apple II — pistes en spirale, secteurs de tailles différentes, diverses méthodes de nibblisation — auraient en théorie aussi été possibles sur Mac. Je me demande si elles ont réellement été utilisées pour la protection contre la copie.

  • Le rendu est vraiment proche d’une vraie machine, et le travail est excellent. Est-ce qu’on pourrait l’utiliser aussi pour l’émulation Atari ST ?

    • Hatari n’est-il pas déjà excellent ? https://github.com/hatari/hatari
      Il y a aussi Clock Signal (CLK). Il se décrit comme un « émulateur allergique à la latence pour Acorn Electron et Archimedes, Amstrad CPC, Apple II/II+/IIe et les premiers Macintosh, Atari 2600 et ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 et Amiga, MSX 1/2, Oric 1/Atmos, les premiers compatibles PC, Sega Master System, Sinclair ZX80/81 et ZX Spectrum » : https://github.com/TomHarte/CLK