I like DOSBox pure, because that allows you to put the full games into a single zip file and so you then essentially have the equivalent of per-game file on consoles.
Same thing I'd want to be "interesting" about any emulator. Focusing on just graphics (but there are equivalent examples in other domains):
1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, but without breaking game logic (i.e. by forcibly decoupling the game's physics ticks from its presentation ticks);
2. Using out-of-viewport but in-{tile/frame}buffer data to expand the viewport to fill my screen (which can be very janky under some rendering paradigms, due to offscreen parts of tile/frame buffers being dynamically partial-updated with a loading seam; but which can work very well under other rendering paradigms, like the SNES's mode 7 where the tilemap was usually just fully populated once at mode-switch time);
3. Making games that used vector-graphics for at least part of their display, and soft- or hard-rasterized those vector graphics into the native low-resolution framebuffer, instead rasterize those graphics at my display's native resolution;
4. having the emulator recognize particular bitmap assets (tiles, sprites, 3D meshes/textures) the game is telling it to render, and swap these out for hang-crafted HiDPI / high-poly versions of those assets (rather than relying on the caprices of a DLSS-like upscaling model.)
Mind you, to have features like this work well, they often leave the realm of "interpreting the control-register pokes from the game differently", and enter the realm of "the game being patched to take advantage of the capabilities of the emulator." Where, as with these GOG games, you're no longer shipping a ROM "and an emulator to run it"; rather, you're shipping a co-designed product: an emulator, and a ROM that's been tuned for that emulator.
At this point, you're technically leaving the realm of "faithful emulation" of both game logic and presentation, and entering the realm of "faithful game-logic emulation but runtime-synthesized HD remaster of presentation-logic emulation." Which is how a decent chunk of people prefer to play old games.
Last time i checked (and DOSBox hasn't made an official release since then) the vanilla DOSBox isn't able to run the game i made for an MS-DOS game jam a few years ago[0] because it doesn't implement RDTSC properly (that the game uses for timing). All currently developed DOSBox forks work properly.
Also the forks add some additional niceties, e.g. DOSBox Staging has some very nice CRT filters that basically make games look almost like the real thing (i have some actual CRTs to compare). DOSBox-X has a GUI to setup options while the emulator is running which is very convenient.
I have to admit, I've tried using Heroic Launcher both on macOS and on a Steam Deck and in both cases the experience has been rather frustrating. Maybe I was just unlucky, but any game I tried was broken in a way or another, or stopped working with no clear explanation (weird segfaults at start) just a few days later.
I've tried GOG DOS Games, GOG Windows Games, Steam Games under Proton, nothing was particularly usable.
Got the very same games working under Faugus Launcher and Dosbox-X. The UX is a bit worse but my games run without any issues, and I've stuck with those since then.
x86 gaming and running x86 Linux software are the exceptions.
> Starting with macOS 28, Rosetta 2 will be largely discontinued. Apple says that after that point, it “will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”
What they say is "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks" which sounds like OS X games. But even if it is all-inclusive "retro" games, that means the 1,000s of contemporary games runnable via Crossover through Steam for Windows are being shut out.
They relented under pressure to continue allowing Linux virtual machines, so hopefully they continue to revisit this decision.
This would be very bad for Wine too. I think Wine has some answer to this, since Wine does run on Android, but I think it won’t make the current easy path that is just brew install wine and be done.
I get why Apple wants to remove it but it genuinely sucks. I can't imagine it costs them a lot to put it into maintenance mode and just support 20 years of macOS games and apps going forward. They want developers to fully move to ARM but older titles or software whose developers have moved on/passed will be lost to the sands of time.
If they choose to discontinue it, it would be nice to have them opensource it so that the community could have a go at maintaining it tbh. Surely that's better than letting it rot (both rosetta and the old software that it runs).
That would be ideal, but given Apple's general hostility towards Open Source, it sounds extremely unlikely. I wonder what it would take to re-implement it. If it's "just software," I suppose there is a chance, not that I'm volunteering :)
Apple really isn't as hostile towards OSS as people think. With that being said, the reason to discontinue Rosetta 2 is to push developers to upgrade their software. Allowing others to continue using Rosetta 2 by way of 3rd party maintainers works against that goal :(
Rosetta 2 is software, but there are design decisions made for the M-series chips that are specifically made to improve the ability of Rosetta to work in a performant way. The main one I'm aware of is the x86-TSO memory-ordering mode - most ARM chips don't support this, but the M-series have it so that Rosetta can toggle it on for x86 emulation.
I'm not sure what the total cost of these are, but it's not zero.
There's another big one, 4K page support. The MMU can be told to set up a virtual address space with smaller, x86-compatible 4096-byte memory pages instead of the default 16384-byte pages.
Dosbox has its emulator to run DOS, but afaik dosbox binary that starts up dosbox on Mac uses Rosetta on M-series Macs, and without Rosetta it simply won’t start and emulate DOS.
My favourite project to run these old games was Boxer (1). Based on dosbox, it creates a runnable self contained disk (app) for each game or set of games / software. It is pretty neat, but I am not sure if it has been maintained recently.
I do the opposite and put all games together, with DOS BAT-files to launch the games. I boot up my virtual dream DOS machine by just starting DOSBox-X and then I launch the games the way they are meant to be launched, from the DOS COMMAND.COM command-line. And as I mentioned in another comment, all of that is in one big DOS git repo.
Nice thing with DOSBox-X is there is a built-in command to set config parameters, so for games that require special settings or to slow down etc that can be set up from its launcher BAT file. All games share the same dosbox config file with default settings.
I've hoped for years someone would pickup the source and get it going again, it's essentially abandonware right now, no changes in nine years. The website is like a time machine back to the peak skeuomorphic mac app era. It still has the nicest UX of any of the DosBox variants I've tried. In this era of agentic rewrites, modernizing this app is probably the cheapest it has ever been too...
This is awesome, and I can't wait to have the time to set this up and install my GOG library .. but one thing has been bugging me for a long time about my GOG library, and that is: local multiplayer network gaming was awesome then.
So .. is there going to be any chance of getting multiplayer networking setup for some of the GOG's? Has anyone accomplished this in the DOXBox-*'en .app'o-sphere yet?
I never had any issues using WINE to install GOG games, but maybe running WINE on a Mac is not as easy now as it was back when I did that on a x86 Mac?
I always run the GOG installer in WINE and then copy the game into my git repo for DOS stuff, make sure the game works, git commit it, and then I know it will always just work and I will not have to think about that again (plus I can version manage all settings and save-games for all the games and also sync between my different machines without relying on any cloud service).
Hmm i guess this would require figuring out how to extract game data from an .exe installer GOG distributes. I guess AI would figure it out in like 3 minutes ;) I’ll check later.
>install DOSBox for Mac
Mind you there are countless DOSBox forks out there and the vanilla original one is probably the least interesting one.
Nowadays the three most popular one would be DOSBox-X, DOSBox Pure, and DOSBox Staging
https://dosbox-x.com/ https://github.com/joncampbell123/dosbox-x
https://schelling.itch.io/dosbox-pure https://github.com/schellingb/dosbox-pure-unleashed/
https://www.dosbox-staging.org/ https://github.com/dosbox-staging/dosbox-staging
I like DOSBox pure, because that allows you to put the full games into a single zip file and so you then essentially have the equivalent of per-game file on consoles.
> there are DOSBox forks, most popular one would be DOSBox-X
Straight from the article:
> there are actively developed alternatives like DOSBox-X
> Mind you there are countless DOSBox forks out there and the vanilla original one is probably the least interesting one.
What do you want to be "interesting" about dosbox?
Same thing I'd want to be "interesting" about any emulator. Focusing on just graphics (but there are equivalent examples in other domains):
1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, but without breaking game logic (i.e. by forcibly decoupling the game's physics ticks from its presentation ticks);
2. Using out-of-viewport but in-{tile/frame}buffer data to expand the viewport to fill my screen (which can be very janky under some rendering paradigms, due to offscreen parts of tile/frame buffers being dynamically partial-updated with a loading seam; but which can work very well under other rendering paradigms, like the SNES's mode 7 where the tilemap was usually just fully populated once at mode-switch time);
3. Making games that used vector-graphics for at least part of their display, and soft- or hard-rasterized those vector graphics into the native low-resolution framebuffer, instead rasterize those graphics at my display's native resolution;
4. having the emulator recognize particular bitmap assets (tiles, sprites, 3D meshes/textures) the game is telling it to render, and swap these out for hang-crafted HiDPI / high-poly versions of those assets (rather than relying on the caprices of a DLSS-like upscaling model.)
Mind you, to have features like this work well, they often leave the realm of "interpreting the control-register pokes from the game differently", and enter the realm of "the game being patched to take advantage of the capabilities of the emulator." Where, as with these GOG games, you're no longer shipping a ROM "and an emulator to run it"; rather, you're shipping a co-designed product: an emulator, and a ROM that's been tuned for that emulator.
At this point, you're technically leaving the realm of "faithful emulation" of both game logic and presentation, and entering the realm of "faithful game-logic emulation but runtime-synthesized HD remaster of presentation-logic emulation." Which is how a decent chunk of people prefer to play old games.
Last time i checked (and DOSBox hasn't made an official release since then) the vanilla DOSBox isn't able to run the game i made for an MS-DOS game jam a few years ago[0] because it doesn't implement RDTSC properly (that the game uses for timing). All currently developed DOSBox forks work properly.
Also the forks add some additional niceties, e.g. DOSBox Staging has some very nice CRT filters that basically make games look almost like the real thing (i have some actual CRTs to compare). DOSBox-X has a GUI to setup options while the emulator is running which is very convenient.
[0] https://bad-sector.itch.io/post-apocalyptic-petra
Read what the others offer
GUI config, load games from zip and image files, controller support, save states, various sound, graphics, and network enhancements etc.
There is more to this than simply being a DOS emulator.
> What do you want to be "interesting" about dosbox?
Quality of life improvements? Expanded (experimental) hardware support?
The Slirp backend for the NE2000 networking driver is the big one for me.
This seems like a good place to mention boxer for macos. Sadly discontinued in 2016
https://boxerapp.com/
which was then continued via boxer-plus which adds apple silicon support
https://github.com/Solid7s/Boxer-Plus
edit: I think it has apple silicon support. I am getting mized messages when I look it up.
Heroic Launcher makes it even simpler, also for non-DOS Windows games (both very old and newer) - https://heroicgameslauncher.com/
I have to admit, I've tried using Heroic Launcher both on macOS and on a Steam Deck and in both cases the experience has been rather frustrating. Maybe I was just unlucky, but any game I tried was broken in a way or another, or stopped working with no clear explanation (weird segfaults at start) just a few days later.
I've tried GOG DOS Games, GOG Windows Games, Steam Games under Proton, nothing was particularly usable.
Got the very same games working under Faugus Launcher and Dosbox-X. The UX is a bit worse but my games run without any issues, and I've stuck with those since then.
But I wonder if Heroic can install HoMM2 on a Mac if no Mac binary is available on GOG.
Heroic Launcher is awesome on the Steam Deck
This is why Rosetta 2's looming retirement sucks.
x86 gaming and running x86 Linux software are the exceptions.
> Starting with macOS 28, Rosetta 2 will be largely discontinued. Apple says that after that point, it “will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”
https://9to5mac.com/2026/02/16/macos-26-4-will-notify-users-...
It's the Mac native x86 software that hasn't been updated in most of a decade that would be affected.
> Retro gaming
What they say is "we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks" which sounds like OS X games. But even if it is all-inclusive "retro" games, that means the 1,000s of contemporary games runnable via Crossover through Steam for Windows are being shut out.
They relented under pressure to continue allowing Linux virtual machines, so hopefully they continue to revisit this decision.
https://developer.apple.com/documentation/apple-silicon/abou...
That's an "I'll believe it when I see it working on my machine" matter.
As my sibling post says, it's more likely to work only for some older mac os native games.
Is there an actual reason for it, apart from Apple hurrying devs along?
For the consumer, the benefits of backwards compatibility are obvious, but it’s sad that companies don’t see it as a selling point.
Well, we wouldn’t want anyone using their perfectly functional copy of Photoshop CS6 would we…
The Apple Silicon dev kit shipped in 2019 and the cutoff date is 2028, so it's a pretty mild form of hurry.
If you want to continue to run older software, do what Windows 11's compatibility layer does and spin up VM with an older version of the OS.
This would be very bad for Wine too. I think Wine has some answer to this, since Wine does run on Android, but I think it won’t make the current easy path that is just brew install wine and be done.
Enjoy paying for your yearly Adobe subscription as your shrink wrap software won’t work.
I get why Apple wants to remove it but it genuinely sucks. I can't imagine it costs them a lot to put it into maintenance mode and just support 20 years of macOS games and apps going forward. They want developers to fully move to ARM but older titles or software whose developers have moved on/passed will be lost to the sands of time.
If they choose to discontinue it, it would be nice to have them opensource it so that the community could have a go at maintaining it tbh. Surely that's better than letting it rot (both rosetta and the old software that it runs).
That would be ideal, but given Apple's general hostility towards Open Source, it sounds extremely unlikely. I wonder what it would take to re-implement it. If it's "just software," I suppose there is a chance, not that I'm volunteering :)
Apple really isn't as hostile towards OSS as people think. With that being said, the reason to discontinue Rosetta 2 is to push developers to upgrade their software. Allowing others to continue using Rosetta 2 by way of 3rd party maintainers works against that goal :(
I imagine that the area it takes up on the chip is non-trivial and so it'd cost them a ton to continue to have it.
I thought Rosetta 2 was a purely software layer
Rosetta 2 is software, but there are design decisions made for the M-series chips that are specifically made to improve the ability of Rosetta to work in a performant way. The main one I'm aware of is the x86-TSO memory-ordering mode - most ARM chips don't support this, but the M-series have it so that Rosetta can toggle it on for x86 emulation.
I'm not sure what the total cost of these are, but it's not zero.
There's another big one, 4K page support. The MMU can be told to set up a virtual address space with smaller, x86-compatible 4096-byte memory pages instead of the default 16384-byte pages.
Those are still needed for the Rosetta use-cases that are sticking around (old games, Linux binaries)
It’s software.
I thought dosbox had its own x86 emulation layer so it should work fine on any arch?
Dosbox has its emulator to run DOS, but afaik dosbox binary that starts up dosbox on Mac uses Rosetta on M-series Macs, and without Rosetta it simply won’t start and emulate DOS.
My favourite project to run these old games was Boxer (1). Based on dosbox, it creates a runnable self contained disk (app) for each game or set of games / software. It is pretty neat, but I am not sure if it has been maintained recently.
1 boxerapp.com
its back https://github.com/Solid7s/Boxer-Plus
I do the opposite and put all games together, with DOS BAT-files to launch the games. I boot up my virtual dream DOS machine by just starting DOSBox-X and then I launch the games the way they are meant to be launched, from the DOS COMMAND.COM command-line. And as I mentioned in another comment, all of that is in one big DOS git repo.
Nice thing with DOSBox-X is there is a built-in command to set config parameters, so for games that require special settings or to slow down etc that can be set up from its launcher BAT file. All games share the same dosbox config file with default settings.
Thanks, I’ll check it out
Boxer was wonderful in its day, I think it also became the basis of the official GOG Mac DOS game releases for a while too:
> https://www.gog.com/forum/general_archive/mac_dos_game_editi...
I've hoped for years someone would pickup the source and get it going again, it's essentially abandonware right now, no changes in nine years. The website is like a time machine back to the peak skeuomorphic mac app era. It still has the nicest UX of any of the DosBox variants I've tried. In this era of agentic rewrites, modernizing this app is probably the cheapest it has ever been too...
> http://boxerapp.com/
> https://github.com/alinebee/Boxer
Check out boxer-plus
https://github.com/Solid7s/Boxer-Plus
This is awesome, and I can't wait to have the time to set this up and install my GOG library .. but one thing has been bugging me for a long time about my GOG library, and that is: local multiplayer network gaming was awesome then.
So .. is there going to be any chance of getting multiplayer networking setup for some of the GOG's? Has anyone accomplished this in the DOXBox-*'en .app'o-sphere yet?
Dosbox-X has network support via NE2000 drivers.
Ooh, that is really great to know - thank you! I will start with that first ..
Is it really necessary to first install and copy from a Windows machine?
I never had any issues using WINE to install GOG games, but maybe running WINE on a Mac is not as easy now as it was back when I did that on a x86 Mac?
I always run the GOG installer in WINE and then copy the game into my git repo for DOS stuff, make sure the game works, git commit it, and then I know it will always just work and I will not have to think about that again (plus I can version manage all settings and save-games for all the games and also sync between my different machines without relying on any cloud service).
Hmm i guess this would require figuring out how to extract game data from an .exe installer GOG distributes. I guess AI would figure it out in like 3 minutes ;) I’ll check later.
You could try https://github.com/dscharrer/innoextract (installable via homebrew).
That, or just run it with wine.