Where does the name ‘Snow’ come from?
Apple machines released from 1984 to 1990 had an iconic design with horizontal and vertical lines, originating from the Snow White design language, developed by Hartmut Esslinger’s company named Frog Design. The emulator was named after this iconic design language.
What are the base design choices for this emulator?
Snow strives to be as close and accurate to the original Macintosh hardware as possible. Some other emulators emulate certain hardware (particularly the disk drives) by patching and/or hooking into the Macintosh ROM. While this allows for certain improvements to make life easier, such as mounting floppies of arbitrary size, it does not allow these emulators to e.g. run copy-protected applications from uneditted floppy images.
For Snow, the aim is to have whatever worked on a real-life Mac to also work identically in the emulator, bugs included, to provide an authentic and accurate experience.
What other Macintosh emulators are out there?
The emulators I know of that emulate the same models as Snow are:
Where do I find a Macintosh ROM file?
The ROMs are still the intellectual property of Apple and therefore I cannot distribute them or help you obtain them.
Snow will verify the integrity of ROM files that it loads and auto-detect the Macintosh model the ROM belongs to so the surrounding hardware is configured accordingly.
Sector/bitstream/flux images? What is the difference?
Flux images are the closest to how the information was actually stored on the original floppy disk that was imaged: they literally store the magnetic flux transitions that were observed by the imaging device at the time the media was imaged. Because flux images usually store more than one rotation, flux images also contain observations that may differ from rotation to rotation, because of the electrical and mechanical characteristics of the floppy drive. Some copy protection schemes make use of these characteristics to detect whether a disk is original or not. Because a flux image captures these, a copy protected image will be able to run in an emulator. On the down side, this also means that a flux image will contain any defects that were present in the on the original media. Because of the level of accuracy, a flux image file is usually quite large compared to the actual amount of logical data stored inside it.
Bitstream images contain a binary representation of the magnetic flux transitions as they were interpreted by the drive and drive controller at the time of imaging. Usually, the imager tooling will also have done some analysis and error correction of the data. They still contain the complete, encoded physical bits of one revolution of every track on the disk, including any data or noise between the sectors.
Sector-based images contain only the logical data stored on the disk. Any GCR/MFM encoding and noise/data present between the sectors is lost. Because it is only the logical data, sector-based image files are also the smallest. However, copy protection that looks for transitions that differ per track revolution, noise between sectors, sectors with deliberately incorrect metadata, etc will detect the disk as non-original.
There is no image format better or worse than another, it really depends on the level of accuracy required to satisfy the software and/or copy protection present on the disk.
Some image formats are able to store tracks with varying degrees of accuracy. For example, MOOF images are able to store flux accurate as well as bitstream tracks. A track relevant for copy protection can then be marked as requiring flux accuracy, where other tracks can remain at bitstream accuracy.
What are the caveats of loading raw flux images in an emulator?
Raw flux images, such as A2R, are not ment to be used in emulators directly. This is because they contain an image of a media in ‘unresolved flux’: basically the exact thing the drive saw for a number of revolutions at the time of imaging, including errors and all.
This also means that the track data contained in the image is not exactly one track revolution long. For example, Applesauce usually images 1.25 to 2.25 revolutions. A more extreme example are Kryoflux images, which contain 5 revolutions by default but depending on the quality of the disk and the settings used while imaging may contain 25 or more revolutions.
An emulator will repeat this entire set of revolutions, of which some may contain errors and are not perfectly stitched together. In theory, this should work fine, because there are error correction and retry mechanisms in place. In practice, load times may be longer and some software/copy protections may not be as forgiving.
In practice, most A2R or other raw flux images should work fine in Snow. However, it is good to keep the above in mind if you run into problems.
If you want to use an A2R disk image in Snow and you notice things aren’t working very well, you may want to try converting the image to MOOF using Applesauce first. In Applesauce you can select which tracks you want to have flux accuracy (e.g. for copy protection), which it will then resolve (stitch together as one revolution, apply error correction, etc) and store in the MOOF image as a resolved flux track.
MFM DOS disks in raw flux format will be loaded by Fluxfox, which will resolve the raw flux on load. Fluxfox does not (yet) support Macintosh GCR.