Snow: a hardware-level Macintosh emulator with a debugger built in

Hardware emulation, not ROM patching, is the whole design decision

Snow emulates classic, Motorola 68k-based Macintosh computers, and the stated aim is to emulate the Macintosh on a hardware-level as much as possible, as opposed to emulators that patch the ROM or intercept system calls.

That distinction determines what the debugger can show you. If the emulator intercepts system calls, the code above the call boundary is a reconstruction, and the interesting part of a Macintosh bug is usually below it. Emulating the hardware means the emulated machine executes the same instructions the real one would and reacts to the same bus cycles, so a fault in a driver is a fault in the emulated machine rather than a discrepancy in a shim.

The project features a graphical user interface to operate and debug the emulated machine, which is unusual for an emulator of this class. Most emulators of this kind expose a debugger in a text console or through a separate tool. Here the debugger is part of the application, next to the screen.

The implementation is Rust, and the workspace layout shows a deliberate split. The default member is frontend_egui, and the other members are core for the emulation itself, floppy for the disk controller side, nat for the userland NAT, and testrunner. The GUI is egui based, and the frontend directory is named frontend_egui.

For downloads and more information the project points at snowemu.com, and there is a limited online demo at demo.snowemu.com. The README is otherwise a compact capability list, with the reference details moved to docs, including BUILDING.md for the build instructions and PACKING.md for packaging.

The release history is recent and steady: v1.5.0 on 2026-07-06, v1.4.1 on 2026-04-20 and v1.3.1 on 2026-02-27, and the last push to the repository was on 2026-10-20.

The model list stops at the compact Macs and the early II series

The supported machines are listed explicitly, and the list is worth reading because an emulator's model list is its compatibility list.

Covered are the Macintosh 128K, 512K and 512Ke, the Macintosh Plus, the Macintosh SE in both non-FDHD and FDHD flavours, the Macintosh Classic, the Macintosh Portable and the PowerBook 100, the Macintosh II in both non-FDHD and FDHD flavours, and the Macintosh IIx, IIcx and SE/30.

That is the compact Mac line plus the first generation of II machines. The PowerBook 100 is listed, which is the PowerBook that was really a Portable with a keyboard attached. There is no 68040, so the Quadra and Centris line is out of scope, and there is no PowerPC, so the later Macs are out of scope too.

The hardware list underneath is more detailed. The CPUs are the Motorola 68000, 68020 and 68030. The coprocessors are the 68881 and 68882 FPUs and the 68851 PMMU. Storage is the IWM and SWIM floppy controllers, GCR 400K and 800K drives with up to 3 drives on the SE, a GCR or MFM 1.44MB SuperDrive, SCSI hard disk drives with up to 7 of them, and a SCSI CD-ROM drive with CD audio support. Input is the original Macintosh and ADB keyboard and mouse. Audio output is PWM-based on the compact Macs and ASC on the newer models. Graphics cover the Macintosh Display Card 8-24 with various monitor types on NuBus machines, and networking includes the DaynaPORT SCSI/Link Ethernet adapter.

The four FDHD and non-FDHD pairings exist because the two variants of the SE and the II differ in their disk controller and their video, so supporting one does not give you the other.

Floppy images, including flux level dumps

The floppy support is where this emulator goes beyond the usual tool, and the format list is the clearest evidence of a hardware-level approach.

Sector-based formats come first: Apple DiskCopy 4.2, and Apple Disk Archive and Retrieval Tool, DART, both sector-based. Then the flux-level formats appear, which is the significant part. Applesauce A2R 2.x and 3.x are flux. Applesauce MOOF is supported in both bitstream and flux flavours, and Snow can also save floppies in that format. PCE Flux Image, PFI, is flux, and PCE Raw Image, PRI, is bitstream. Raw images are sector-based.

And then the catch-all: any format supported by Fluxfox, the library by Daniel Balsom, which is also credited in the acknowledgements and is the same author's project. The extent of that support is described as Mac 1.44MB or PC formats.

The distinction matters if you have a real disk. A sector-based image is a snapshot of what the drive read, and it will boot a copy-protected or otherwise timing-sensitive program incorrectly, because the drive itself was part of the behaviour. A flux image is a recording of the actual magnetic transitions on the disk, at the level the hardware sees them, and an emulator that reproduces the drive's timing can boot the original. Since Snow emulates the IWM and SWIM controllers rather than reading a decoded image, flux images have somewhere to be played back into.

The CD-ROM side is narrower, with ISO, Toast and CUE/BIN supported. Hard drives are raw device images only, which is a simple format and also the one that assumes you already have the contents of the disk image you want.

The debugger is the reason to try it

The debugging feature list is longer than any other section of the README, and that says something about the project's priorities.

Breakpoints come in five kinds: execution, bus access, system trap, exception and interrupt level. A bus access breakpoint on a 68k machine is the direct analogue of a hardware watchpoint, and combined with the watchpoints, which support editing, it lets you catch a device that reads the wrong register at the wrong time.

The stepping controls are the familiar set: single step, step over and step out. Around them sit views. There is a disassembly view, a register view with editing, a memory viewer with editing, an instruction history view with export functionality, a system trap history viewer, and a peripheral debug view. A terminal for the serial ports is also included, which is how you talk to a device that has no screen.

Instruction history with export is worth singling out, because it turns the debugger into a tool for producing a bug report or a reversing note rather than only for interactive inspection. If you are trying to work out what a piece of 68k software does to the hardware, being able to pull the trace out and look at it offline is the difference between a curiosity and a workflow.

The system trap history viewer fits the same pattern. System traps were the Macintosh mechanism for communicating between an application and the system, and a device driver, a disk cache extension or a network stack all talk through them. Watching the trap history is how you see which extension is doing something you did not expect.

The whole feature set is exposed through the graphical interface rather than a separate console, which is the other reason the list is long: a terminal debugger with this many views would be painful, while a side panel with a graph of the 68k is not.

Networking bridges, licensing and the credits that matter

The networking features are about connecting the emulated machine to the outside world, and they are practical rather than decorative.

There are TCP and PTY bridges for the serial ports, which is how you get a modern terminal program to talk to the emulated Mac, and LocalTalk over UDP, so a LocalTalk network of emulated Macs can talk to each other over a real network. Ethernet can be linked to userland NAT and HTTPS stripping, and to tap interfaces on Linux only.

The HTTPS stripping is worth a note. It lets a real browser talk to a server running inside the emulated Mac over a plain HTTP connection, so you can test a web stack of the period without dealing with certificates the emulator would have no way to trust.

The licence is MIT, with a LICENSE file at the repository root. That matters here more than for most projects, because an emulator is the kind of software people want to modify and redistribute, and the MIT terms allow it without the copyleft obligations that would attach to a GPL emulator.

The acknowledgements are unusually specific and tell you where the accuracy comes from. The project thanks raddad772 for a 68000 JSON test suite, Daniel Balsom for the mascot art and the Fluxfox library, Andrew Yaros for the application icon, and the Emudev and Applesauce communities. The Musashi project by Karl Stenerud and MAME have been used as a reference for poorly documented components, which is the standard practice in emulator development and a good sign about how the hardware was reconstructed. The BlueSCSI Toolbox protocol and software is used in and distributed with Snow with the permission of Eric Helgeson.

The build configuration shows a project that takes its own tooling seriously. Clippy nursery lints are denied with a list of specific allows, several lints are explicitly denied including large_enum_variant, large_types_passed_by_value and needless_pass_by_value, and the test profile is compiled at opt-level 3 with debug info on. The egui dependency is patched to a fork to fix menu bar hover behaviour, which is a small but telling detail about the level of polish.

Editorial conclusion

Snow suits someone who wants to run or repair classic Macintosh software, and it suits a developer who wants to understand how a 68k Macintosh actually worked, since the hardware-level approach means the debugger shows real bus activity rather than a shimmed API. It does not suit you if you need a modern emulator with a large compatibility list, since the model list is fixed at the compact Mac line and the early II series. Before you try it, read the BUILDING.md instructions in the docs directory, and note that the build patches egui from a fork to fix menu bar hover behaviour, so building offline or with a different toolchain will not be straightforward.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. twvd/snow on GitHub