[HN Gopher] Snow - Classic Macintosh emulator
___________________________________________________________________
Snow - Classic Macintosh emulator
GitHub repo: https://github.com/twvd/snow, Announcement from
creator: https://www.emaculation.com/forum/viewtopic.php?t=12509,
Originally-submitted source with further details:
https://oldbytes.space/@smallsco/114747196289375530
Author : ColinWright
Score : 274 points
Date : 2025-06-26 09:08 UTC (1 days ago)
(HTM) web link (snowemu.com)
(TXT) w3m dump (snowemu.com)
| the_other wrote:
| Off-topic...
|
| I wish Apple would bring back the white menubar background and
| the coloured logo.
|
| The white menubar makes the whole computer easier to use in a
| small but constant way. The coloured apple icon would suggest
| they no longer have their heads stuck up their assess and might
| bring back "fun" rather than "showing off" to their design
| process. And then maybe, maybe... with that "suggestion"
| symbolised in the UI, we can hope they might bring back the more
| rigorous user-centric design process they used to be famous for.
| xenonite wrote:
| What about setting a white background, which yields a white
| menubar?
|
| A color logo might be added with an overlay app - or you
| reminisce a black&white screen.
| trinix912 wrote:
| So are we supposed to make custom backgrounds with a 30px
| white bar on top instead of expecting this to be an option in
| the settings like in every other sanely customizable OS?
| raihansaputra wrote:
| seconding the overlay app, i forgot the name but there was an
| app that can configure the appearance of the menubar. maybe
| it's my menubar icon organizer? Not dozer or bartender, but
| can't recall right now
| egypturnash wrote:
| Ice organizes menubar icons and can alter the bar's
| appearance.
| thm wrote:
| https://www.macrumors.com/2025/06/23/macos-tahoe-beta-2-menu...
| SkyeCA wrote:
| Are they really changing the UI up again? I am actually so
| done at this point. The endless UI churn drives me absolutely
| mad, but I suppose when there's nothing left to do, making it
| look different is easy.
|
| I suppose a built in volume mixer is still too much to ask
| for though.
| jamwil wrote:
| Do you harbour an honest expectation that computer UIs will
| look the same in 2035 as they do in 2025? That would prove
| to be a silly thing to hope for if you were to backtest it.
|
| It's not churn its change, and it's inevitable. No sense
| getting worked up over it.
| coldpie wrote:
| Sure, why not? My desktop environment hasn't
| significantly changed since I first set it up in 2007.
| The screenshots here[1] span more than 20 years (XFCE 4.0
| was released in 2003) and, aside from different user-
| selected theming choices, look substantially similar
| across that whole time.
|
| [1] https://xfce.org/about/screenshots
| jamwil wrote:
| I like XFCE but you can't cherry pick a niche DE that is
| designed for minimalism and extrapolate that to computer
| UIs writ large, which was the subject of my comment.
| Gnome, KDE, Windows, macOS... all evolve regularly.
| hadlock wrote:
| Linux desktop hasn't changed appreciably since the advent
| of Windows 2000, perhaps even NT4. That's 1996 or 29
| years ago. XP changed the color of the start button and
| rounded the edges, and Windows 8 had a purple theme but
| it's been a remarkably consistent design. I think the
| only reason Microsoft has made any changes to the start
| bar is so that the marketing department had something
| visually different to show consumers, since it's such a
| central part of the GUI. KDE and XFCE are so similar I
| often forget which one to install on a new computer.
|
| The only improvement I've seen has been for mac they have
| the command+space launcher which is functionally like the
| win+type the app you want. Graphical file browsers
| haven't changed since the original Mac and/or Win 3.1.
| Mac has never had a good tree view IMO but they do have a
| version of it.
|
| The only reason UIs would change at this point is to keep
| UI/UX folks employed and busy, and give the marketing
| department something new to talk about.
| jamwil wrote:
| If your definition of "appreciably" allows for such
| variation then I would say this current refresh also
| hasn't changed appreciably.
| the_other wrote:
| Nice, thanks. I'll use that when I upgrade.
|
| But I'm not going to upgrade whilst the back/next buttons are
| floating 3m above the window as suggested in that screen
| shot.
| celsius1414 wrote:
| Turning "Reduce Transparency" on in Accessibility > Display
| will solidify the menubar in both light and dark modes.
|
| I go through phases with transparency off or on.
| the_other wrote:
| Same.
|
| Sometimes I enjoy the translucent menus. They make the
| machine look "glossy" and expensive. But they're definitely
| harder to read than opaque flat ones.
|
| With "reduce transparency" on, it's better, but the menubar
| still isn't white. It's a textured light grey that's closer
| to the look of an unfocused app window than the solid,
| dependable, flat thing I wish it still was.
| thristian wrote:
| For some context about why a portable, user-friendly, hardware-
| level emulator for classic Mac systems is such a big deal, see
| this blog post from 2020: https://invisibleup.com/articles/30/
|
| For game consoles, we've had emulators like Nestopia and bsnes
| and Dolphin and Duckstation for years.
|
| For PCs, virtualisation systems like VMWare and VirtualBox have
| covered most people's needs, and recently there's been high-
| fidelity emulators like 86Box and MartyPC.
|
| The C64 has VICE, the Amiga has WinUAE, even the Apple II has had
| high-quality emulators like KEGS and AppleWin, but the Mac has
| mostly been limited to high-level and approximate emulators like
| Basilisk II.
| xdfgh1112 wrote:
| That article is objectively true but .. I've never seen such a
| grotesque dismissal of the hard work people have done for free.
| tom_ wrote:
| For the amount of time and effort that went into that
| article, the author could surely have fixed at least one of
| the things they complain about! And they don't seem to
| understand the C #include mechanism _at all_ , so should we
| even pay attention to their technical criticisms in the first
| place?!
| ndiddy wrote:
| I don't know if you read the whole article. The author did
| make a Mini vMac fork to clean up the build system and
| code, she linked it at the end.
| https://github.com/InvisibleUp/uvmac .
| tom_ wrote:
| Ha. I was starting to find the article a bit tiring and
| the moment my eyes landed on the Conclusion heading I
| stopped right there. You shouldn't trust my criticisms
| either.
| tclancy wrote:
| Wait, but that last sentence makes you a reliable
| narrator now. I am lost.
| projektfu wrote:
| Oh, thank goodness. Hacking Mini vMac was a chore and I
| didn't have the energy to do something like this.
| nxobject wrote:
| My 2c: having played around with the codebase recently
| (to add C++ to the codebase), I did find Cursor helpful
| in figuring out how to work with the bespoke build
| system.
| InvisibleUp wrote:
| I feel like that's a bit harsh, but I'll admit that it is
| needlessly inflammatory. I wasn't in the best state mentally
| when I wrote that. (I do sometimes worry that I'm responsible
| for the disappearance of Paul C. Pratt...) At some point I
| need to either rewrite it to be less hostile or just yank it
| entirely.
| troad wrote:
| I stopped reading when we got to sarcastic hate-compiling.
| That whole part could be a thoughtful and compassionate
| discussion of the state of Mac emulators, and would be much
| more persuasive if it were, and instead it reads like a
| blog-length dunk tweet.
|
| > I feel like that's a bit harsh, but I'll admit that it is
| needlessly inflammatory.
|
| You're asking for a courtesy here that you failed to extend
| to others.
|
| When you write a hit piece on someone's hobby volunteer
| code, and then you get called out for being unduly mean, I
| don't think you get to complain people are being harsh to
| _you_. You chose to devote hours of your time to
| dismantling something someone put years of effort in,
| entirely as a fun hobby. (Antique Mac emulation is
| certainly not the highway to riches.) You say
| 'inflammatory', like the issue here is that you're slightly
| heated and passionate. No, the issue here is that the piece
| boils down to bullying other people because their fun hobby
| projects don't meet your esoteric standards ('no Github
| releases!').
|
| > I wasn't in the best state mentally when I wrote that. (I
| do sometimes worry that I'm responsible for the
| disappearance of Paul C. Pratt...)
|
| Nothing about your mental state gives you licence to bully
| others. Their emotional states are no less important than
| yours.
| InvisibleUp wrote:
| To clarify, at the time I was aiming for the tone of
| Tantacrul's popular and well-received videos about poor
| software UX. (In particular, the MuseScore video is a
| good comparison; that was also an open source passion
| project.) Light-hearted ribbing / frustration venting
| mixed with genuine compassion toward the project's
| creator and his remarkable effort. Clearly I wildly
| missed the mark there. I'll try my best to avoid things
| like this happening again in the future.
| InvisibleUp wrote:
| Update: Now that I'm off work, I've removed the big rant
| about mini vMac's code and sanded off the snark from the
| rest. I should have done this years ago, and I never should
| have added that in the first place.
| nmdeadhead wrote:
| In compatibility, it's _MUCH_ worse than all the others, but
| there 's also Executor:
| https://en.wikipedia.org/wiki/Executor_(software) which you can
| use to run a Macintosh version of solitaire in your browser by
| having the browser emulate MS-DOS which then runs Executor/DOS:
| https://archive.org/details/executor
|
| In addition to Executor/DOS, a non-released version ran on the
| Sun 3 workstations (they too had 680x0 processors) and
| Executor/NEXTSTEP ran on NeXT machines, both the 680x0 based
| ones and the x86 powered PCs that could run NEXTSTEP.
|
| Executor was the least compatible because it used no
| intellectual property from Apple. The ROMs and system software
| substitutes were all written in a clean room--no disassembly of
| the Apple ROMs or System file.
|
| Although Executor ostensibly has a Linux port, it's probably
| hard to build (I haven't tried in a couple decades) in part
| because to squeeze the maximum performance out of a 80386
| processor, the synthetic CPU relied on gcc-specific extensions.
|
| I know a fair amount about Executor, because I wrote the
| initial version of it, although all the super impressive parts
| (e.g., the synthetic 68k emulator and the color subsystem) were
| written by better programmers than I am.
| homarp wrote:
| https://github.com/autc04/executor is a more recent fork of
| executor (but based on the issues, it does build on recent
| OS)
| homarp wrote:
| typo: does NOT build on recent OS
| mattl wrote:
| When I was starting out in the 90s, Executor was one of those
| very cool pieces of software I would love to play around
| with.
| joshmarinacci wrote:
| Thank you so much for Executor. I used to run it on my 486
| Linux box, over an X11 SSH tunnel to the Sun workstation I
| used in the computer labs for work on campus. I balanced my
| checkbook and wrote essays in emulated Excel and Word (with
| rough compatibility with the Windows versions). It was so
| cool to be able to mix and match systems that way.
| dlevine wrote:
| I had a licensed copy of Executor back in the mid-90s. It was
| the coolest thing ever. Thanks for being one of my
| inspirations to go into software development.
| ksherlock wrote:
| It might not count as "user-friendly" but MAME does hardware-
| level emulation of the Macintosh and Apple II (more accurate
| and more peripherals but less user friendly than KEGS and
| AppleWin).
| Palomides wrote:
| there's definitely room to improve user friendliness of mac
| emulation (minivmac's compile time config is so infuriating),
| but I think it's a bit unfair to compare to most of those
| emulators
|
| vmware and virtualbox were backed by billion dollar corps
|
| the 16 bit machines are much simpler than macs
|
| game consoles had highly homogenous well documented hardware,
| and sold in much greater numbers (snes alone sold more than all
| macs from 1987 to 1995) so there's a larger community to draw
| devs and users from. writing a nes emulator is almost a weekend
| project now, it's so documented.
| trollbridge wrote:
| It should be pointed out that VMware started as a tiny,
| scrappy company mostly focused on selling workstation seats
| for you to run Windows on your Linux computer (which I did
| back circa 1999, so I could use Linux on my desktop), and
| VirtualBox started out from InnoTek, a tiny company which was
| essentially making software to emulate Windows on OS/2, and
| then later did a contract with Connectix to run OS/2 on
| Windows (or other hosts) using Virtual PC.
|
| Connectix got bought by Windows, and InnoTek got bought by
| Sun, which is now Oracle. Connectix themselves started as a
| scrappy outfit making it possible to run DOS/Win95 on a Mac.
|
| The core emulation was pretty much done and stable and
| optimised before the billion-dollar corps bought them out.
| Palomides wrote:
| vmware apparently had 20 employees in year one, I don't
| think a single person has ever worked full time on a mac
| emulator (other than Apple's internal ones, of course)
|
| even a "tiny, scrappy company" has massive manpower
| compared to 99.999% of open source projects
| anthk wrote:
| You forgot miniVMAC, 68k. Qemu does MacPPC fine.
| snvzz wrote:
| Note that while this was true about software, there is also
| hardware (FPGA HDL), such as the MacPlus-miSTer core[0].
|
| 0. https://github.com/MiSTer-devel/MacPlus_MiSTer
| 0points wrote:
| Not to be forgotten: MAME supports the 68k macintoshes to some
| extent
|
| https://wiki.mamedev.org/index.php/Driver:Mac_68K
| leoc wrote:
| I managed to get the Macintosh II FDHD emulator to boot, but
| the emulator menu only invites me to load 400K/800K floppies
| despite the Snow manual claiming that the Mac II FDHD emulator
| provides two SuperDrives
| https://docs.snowemu.com/manual/media/floppies . Maybe that has
| something to do with why the system has immediately ejected
| every floppy image I've given it so far, including 800K System
| 7.1.1 disks which are supposedly Mac II compatible. I'm sure
| that Snow has a great deal of promise and I salute the hard
| work, but to be honest, so far the overall landscape of Mac
| emulation seems much the same as before, with _n_ emulators
| offering a jagged product matrix of emulated hardware and
| supported features; lots of hoop-jumping and necessary, assumed
| prior knowledge of old Mac plumbing; and promises for the
| future.
| jakedata wrote:
| Much of my early post-college work is stored across a stack of
| Mac formatted Bernoulli disks. The software requires an ADB
| dongle to run, so physical hardware is required. I wonder if any
| of those ADB to USB adapters could be mapped into the emulator?
| ChrisRR wrote:
| If you've not backed it up already that data might be gone. If
| it's valuable to you then I'd recommend finding out sooner than
| later
| jakedata wrote:
| Good advice of course. It is not valuable, and it is not my
| product - I merely worked on it. The real value was guiding
| me _away_ from a career as a programmer (and the friends we
| made along the way).
| kalleboo wrote:
| All of the ADB to USB adapters I know of only support mice and
| keyboards and have internal firmware that maps to USB HID.
| You'd have to write a custom firmware to make a raw pass
| through to an emulator...
|
| It would probably be easier to crack the software!
| mrpippy wrote:
| The Griffin iMate was the most popular ADB-USB adapter from
| the time, and probably supports non-input devices (it
| would've been the only option at the time to make those
| dongles work).
| kalleboo wrote:
| Ah yeah, the ones that were sold at the time would work if
| you passed through USB to an emulator that supported USB
| hardware, or reverse-engineered their proprietary protocol.
| I was only thinking of the modern options when I wrote my
| comment.
| brirec wrote:
| You can get used Griffin iMates on eBay from time to
| time, but you'll want to solder in a new coin cell
| battery.
| longtimelistnr wrote:
| I have a large collection of vintage Mac's and peripherals,
| with the largest quantity being the Apple Keyboard II [1].
| Archive forums all suggest the Belkin ADB Adapter [2] but
| that has long since been retired. I would like to make my
| own, i know instructions exist for a raw passthrough.
|
| [1]https://en.wikipedia.org/wiki/File:Apple_Keyboard_II.jpg
|
| [2]https://www.cnet.com/tech/computing/hack-your-old-macs-
| adb-k...
| mewse-hn wrote:
| I made a adb-to-usb adapter for my AEK2 using a teensy 2.0
| and a cut up s-video cable. The TMK and QMK firmware have
| this functionality, but I used this firmware because it's
| much smaller and not a "kitchen sink" keyboard firmware:
|
| https://github.com/gblargg/adb-usb
|
| Unfortunately it's US-ANSI only so my pile of 4 french
| canadian AEK2s don't work very well with it.
| mmmlinux wrote:
| Anyone who has a working Bernoulli box probably has a matching
| old mac to go with it.
| jakedata wrote:
| Several, yes ;-)
| thehigherlife wrote:
| maybe this would work? https://www.bigmessowires.com/usb-
| wombat/
| jakedata wrote:
| It turns out there has been some discussion on emulating or
| passing through ADB hardware keys but nothing conclusive
| seems to have come of it.
| DrNosferatu wrote:
| Any Flatpak, Snap or Scoop editions?
| mdavid626 wrote:
| Little help - how can I find ROM-s? I tried to download some
| using sites found in Google, but the emulator always says
| "Unknown or unsupported ROM file". How can I find usable roms?
| reaperducer wrote:
| _Little help - how can I find ROM-s? I tried to download some
| using sites found in Google, but the emulator always says
| "Unknown or unsupported ROM file". How can I find usable roms?_
|
| These seem to work:
|
| https://archive.org/details/mac_rom_archive_-_as_of_8-19-201...
| mdavid626 wrote:
| Very nice, thank you.
|
| I try to run some of them, e.g. Macintosh Plus. It does
| accept the ROM, but it just shows a flashing floppy disk icon
| and doesn't do anything else. How could this be fixed?
| duskwuff wrote:
| The icon is telling you that you need a disk to boot from.
|
| https://www.gryphel.com/c/minivmac/start.html has some
| links.
| wsc981 wrote:
| The Mac Plus didn't have an internal hard drive. So you
| need to start the OS from a floppy.
|
| My father used an external hard drive with his Mac Plus,
| back in the day.
| numpad0 wrote:
| Macintosh ROMs aren't OS, they're like BIOS images. The OS
| were supplied in forms of either CD for data + minimum OS
| on floppy, or a 40-ish box of floppies.
|
| Apps on Macintosh were supplied as disk images often
| compressed in hqx formats. You'll need PC Exchange and
| StuffIt Expander - think of those as equivalents of a file
| extension renaming tool, and 7-zip.
|
| Installation of apps was often accomplished by dragging and
| dropping the application icon from installer image to
| Applications folder, although some did came with Windows-
| like installer apps.
|
| Unmounting disks and installer images was done by moving
| disk icons to Trash(recycle bin). It's the most intuitive
| and straightforward feature of classic MacOS, followed by
| "Shut down" menu being under "Special".
| longtimelistnr wrote:
| https://macintoshgarden.org/ has always been the gold standard
| source for me!
| CTOSian wrote:
| I usually use https://www.macintoshrepository.org , the
| garden lack some proper organisation
| RachelF wrote:
| It's a bit crazy that Apple still prosecutes people who put
| these old ROMs online.
| ChrisRR wrote:
| I'm not sure why OP links to this site, but the actual project is
| here
|
| https://snowemu.com/
|
| https://github.com/twvd/snow
| ColinWright wrote:
| Personally I find an announcement like the one linked more
| helpful and useful to create a context, rather than linking
| directly to the project.
|
| Links to the actual project are in the submitted post, so you
| can get an overview before then being directed to the project
| itself.
|
| As always YMMV, indeed, YMWV, but I like seeing the
| announcement giving the context rather than a bare pointer to
| the project.
| ColinWright wrote:
| ... and while I appreciate the rationale behind it, I'm
| always saddened when a carefully chosen link that suits the
| way I think, giving and overview and a context with links to
| the projects, is then over-written by the direct link to the
| project that _doesn 't_ give a sense of why it's interesting
| or relevant.
|
| But as the Man in Black says in The Princess Bride: "Get used
| to disappointment".
| tomhow wrote:
| We can have our cake and eat it.
|
| The guidelines are clear that the original/canonical source
| is what we want on HN:
|
| _Please submit the original source. If a post reports on
| something found on another site, submit the latter._
|
| But you're welcome to post a comment with links to other
| sources that give the extra information and context, and we
| can pin it to the top of the thread, or do what I've done
| here and put them in the top text.
| ColinWright wrote:
| We won't agree on this.
|
| I understand the rationale, and as someone who moderates
| other communities I can totally understand why this is
| administered as a blanket policy. Having said that, it
| does sometimes result in what I think of as sub-optimal
| situations where information is unnecessarily lost or
| obscured.
|
| In particular, adding a link to the original post, as you
| have done here, is likely to be of minimal value. People
| will click on the headline link, wonder what it's about
| or why it's "news", and close the window. On the other
| hand, clicking through first to the post means people
| will see the context, then those who are interested will
| click through to the project site(s). I've done this
| analysis in other contexts and found that the decision
| tree for engagement and user-information is in favour of
| linking to the post, not the project.
|
| But as I say, I understand your position, and in the end,
| it's not my forum, not my community, and not my choice.
| tomhow wrote:
| I think you're implying that we're more rigid and/or
| self-defeating about this than we are.
|
| We always want the source that contains the greatest
| amount of information about the topic. As I wrote in the
| other reply in this subthread, the heuristic is whether a
| source contains "significant new information" vs an
| alternative.
|
| That means, as explained in that reply, an article about
| the findings of an academic study is better than the
| academic paper, if it contains significant new
| information that isn't easily found from the paper itself
| (particularly if the article contains quotes from
| interviews with the researchers). A project creator's
| blog post about a new project or release is better than a
| link to the project's GitHub page.
|
| We generally prefer not to link to a third-party's social
| media post about a project, on the basis that it's light
| on significant new information and takes
| traffic/attention away from the primary source or another
| in-depth article about it. (It's different if it's a 3rd-
| party's detailed blog post about a project, which
| includes their own experiences using the project and
| comparing it with other projects in the same category.
| But then it's more of a review, than a report about the
| project itself.) Another problem with submitting a 3rd-
| party post about a project is that it then becomes a
| topic of debate in the comments, why one source was
| chosen over another, which happened here.
|
| In a case like this, the information that was in that
| social media post could easily have been quoted in a
| comment in the thread, that we could have pinned.
|
| Given that the author of the project posted an
| announcement in a discussion forum, there could be a case
| for making that the HN source, given that it contains the
| other relevant links and some additional commentary,
| though in this case it's a bit light on detail. But it
| makes all the difference that the source we link to is by
| the author of the project.
|
| In the case of this submission, the story has been on the
| front page for 12 hours already, including some time at
| #1, and is still going strong, so I don't think anything
| has been lost.
|
| You're always welcome to make a case for why a particular
| source is the one that contains the most "significant new
| information" and is thus the one that should be the HN
| source.
| joshAg wrote:
| so just to confirm, this HN submission [ 1] should have
| linked to this pdf of the paper [2] and put the article
| [3] that is the current link for the post as a comment?
| [1]: https://news.ycombinator.com/item?id=44381297
| [2]: https://arxiv.org/pdf/2506.19244 [3]:
| https://www.quantamagazine.org/a-new-pyramid-like-shape-
| always-lands-the-same-side-up-20250625/
| tomhow wrote:
| The question we always ask is whether a source contains
| "significant new information".
|
| In the case you cited, the Quanta Magazine article is a
| report about the study's findings that is readable and
| understandable to lay people, and includes backstory and
| quotes from interviews with the researchers and also
| images.
|
| I.e., there's plenty of information in the article that
| isn't in the paper. So we'll always go with that kind of
| article, over the paper itself, particularly in the case
| of Quanta Magazine which is a high-quality publication.
|
| In other cases an article is "blog spam" - I.e., it just
| rewords a study without adding any new information, and
| in those cases we'll link directly to the study, or to a
| better article if someone suggests it.
|
| Anyone is always welcome to suggest a source that is the
| most informative about a topic and we'll happily update
| the link to that.
| wk_end wrote:
| I suppose - owing to its accuracy - that this doesn't have some
| of BasiliskII's killer features: it patches the OS/ROMs to add
| support for super-high resolutions and (mostly) seamless
| integration with the host's file system and network.
|
| It's a shame that Basilisk - possibly owing to its inaccurate but
| killer features - is as janky as it is, because it's really
| remarkably pleasant to use when it works.
| hedgehog wrote:
| An accurate emulator with clean codebase is a good starting
| point onto which to add patches/shortcuts. I've looked through
| the Basilisk patching code, it's not really complicated, and
| there are a handful of partial Toolbox reimplementations
| including the bits in Basilisk, Executor (author is in the
| comments here), MACE, etc. It would be some work to port but
| mostly direct translation of the code & adding test
| infrastructure.
| duskwuff wrote:
| As an aside, I _really_ wish MACE would open-source their
| work. They 've made some impressive progress, but I worry
| that work's going to go to waste if it stays closed.
| hedgehog wrote:
| Aha, I got MACE and Advanced Mac Substitute (AMS) mixed up.
| AMS looks less complete but has source available.
|
| https://www.v68k.org/advanced-mac-substitute/
| nxobject wrote:
| One way to add devices that doesn't require ROM or software
| modification, but _does_ require modifying the emulator:
| create a virtual memory-mapped device off 68K bus, and write
| a driver/CDEV to drive it. The SE and Macintosh II had
| blessed but different expansion options, after all.
|
| For earlier models, there are unused apertures in model
| memory maps that are at least 2KB large, but they do differ
| between models.
| ColinWright wrote:
| The original submission was to a post that explains why this is
| news, and not just a random project:
|
| _A brand new 68k Mac emulator quietly dropped last night!!_
|
| _"Snow" can emulate the Mac 128k, 512k, Plus, SE, Classic, and
| II. It supports reading disks from bitstream and flux-floppy
| images, and offers full execution control and debugging features
| for the emulated CPU. Written using Rust, it doesn 't do any ROM
| patching or system call interception, instead aiming for accurate
| hardware-level emulation._
|
| * Download link (Mac, Windows, Linux): https://snowemu.com
|
| * Documentation link: https://docs.snowemu.com
|
| * Source link: https://github.com/twvd/snow
|
| * Release announcement:
| https://www.emaculation.com/forum/viewtopic.php?t=12509
|
| -- https://oldbytes.space/@smallsco/114747196289375530
|
| I understand why links get re-written, but I think the context is
| relevant and can help the random reader who is unfamiliar with
| the project.
| trollbridge wrote:
| Was this inspired by MartyPC?
| GloriousCow wrote:
| Funny you mention that, I'm actually friends with twvd and we
| share a discord server and trade UI ideas as we both use the
| same GUI toolkit. Snow actually uses the disk image library I
| built for MartyPC.
|
| Inspired is a strong word. I didn't invent the concept of an
| accurate emulator, although I'm certainly a fan of his
| approach.
| Rochus wrote:
| Does the Mac - like the Lisa - also require cycle accurate
| emulation of the hardware? I spent some time with lisaem and made
| experiments with Qemu, but the Lisa OS makes assumptions about
| hardware timing which cannot be met by the latter.
| retrac wrote:
| The early Macs used the IWM, which is basically Wozniak's 1977
| Disk II controller reduced to one chip. The same trick with
| cycle-exact code, that was used in the Apple II, is also used
| in the Mac.
|
| It's why the cursor stops moving sporadically when writing to a
| disk. The Mac has a 60 Hz interrupt timer that also tracks the
| cursor. It needs to be switched off when writing.
|
| There's a story on Folklore.org by Andy Hertzfeld that mentions
| it in passing:
|
| > 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
|
| This reminds me that all of the unusual Apple II disk stuff
| like spiral tracks and different-sized sectors and different
| nibbilization schemes were also, at least theoretically,
| possible on the Mac. I wonder if they were ever used for copy
| protection?
| flomo wrote:
| Early Mac games did have disk-based copy protection, and yes
| there was a cracking scene. A lot of these games did not run
| on later Macs, so this was largely forgotten.
| Someone wrote:
| The original Mac floppy also was constant linear velocity
| (https://en.wikipedia.org/wiki/Constant_linear_velocity),
| with rotation speed being under software control.
|
| http://www.mac.linux-m68k.org/devel/plushw.php:
|
| _"The Macintosh disk interface uses a design similar to
| that used on the Apple II and Apple III computers,
| employing the Apple custom IWM chip. Another custom chip
| called the Analog Signal Generator (ASG) reads the disk
| speed buffer in RAM and generates voltages that control the
| disk speed. Together with the VIA, the IWM and the ASG
| generate all the signals necessary to read, write, format,
| and eject the 3 1 /2-inch disks used by the Macintosh."_
| chiffre01 wrote:
| I tried loading this with the standard Mac OS 7.1 install disks
| readily available, with a Mac plus rom. Drive 0: disk ejected?
| Mini vMac seems to work. I guess it needs some work still.
| car wrote:
| Feels so real, great work.
|
| Any chance this could be made to emulate an Atari ST?
| msephton wrote:
| Hatari is already excellent? https://github.com/hatari/hatari
|
| And there's also Clock Signal (CLK) "A latency-hating emulator
| of: the Acorn Electron and Archimedes, Amstrad CPC, Apple
| II/II+/IIe and early Macintosh, Atari 2600 and ST,
| ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga,
| MSX 1/2, Oric 1/Atmos, early PC compatibles, Sega Master
| System, Sinclair ZX80/81 and ZX Spectrum."
| https://github.com/TomHarte/CLK
| nxobject wrote:
| I'm surprised HD20 support is listed as "not applicable" for SE,
| II, etc: I think all models listed except for II have HD20 boot
| support in ROM. I use an HD20 emulator with my physical Mac SE.
|
| It's one of the most convenient ways to get arbitrary-sized disk
| images both into emulators -- both Mac emulators and physical
| floppy emulators.
| cemyazar3131 wrote:
| Pls play my game
| darqis wrote:
| Obligatory You know nothing Jon Snow quote
| gbraad wrote:
| It is a reimplemented 68K emulator in Rust, so shares nothing
| from Musashi or UAEs code (wellknown cpu cores in C).
___________________________________________________________________
(page generated 2025-06-27 23:01 UTC)