Ooh, that is really great to know - thank you! I will start with that first ..

Check out boxer-plus

https://github.com/Solid7s/Boxer-Plus

Thanks, I’ll check it out

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.

The Slirp backend for the NE2000 networking driver is the big one for me.

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

> What do you want to be "interesting" about dosbox?

Quality of life improvements? Expanded (experimental) hardware support?

Same thing I'd want to be "interesting" about any emulator. Focusing on just graphics for a moment (but there are equivalent examples in other domains):

1. Running games that only ran at 10FPS on original hardware at a smooth 60+FPS, by calling the game's own rendering logic more frequently than the original hardware could "afford" to, 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 hand-crafted HiDPI / high-poly versions of those assets from an asset-pack file (as opposed to 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." Then, as with these GOG games, you're no longer just shipping a ROM "and an emulator configured to run it well"; rather, you're shipping a co-designed product: an emulator tuned to run that ROM, and a ROM tuned to run in that emulator.

---

By doing this, you technically leave the realm that MAME-like "archival preservation" emulation usually aims for, of "faithful emulation" of both a game's logic and its presentation.

However! "Faithful emulation" folks shouldn't despair. The nice thing about this technique, is that this is all done by wrapping the original ROM in an emulator + shipping runtime-applied IPS patches.

In other words, the original game ROM is still there, unmodified, under an "isolation layer"; and everything being done to modify it is done using "reversible, conservation-grade" techniques.

Which means the emulator can provide a launcher UI to turn any of those presentation "enhancement" features on-and-off. If you're the "faithful emulation" type, you can just turn them off!

(And, under this paradigm, even with the "enhanced emulation" features on, the game logic is still preserved as-is; you're only modifying the presentation. The original game engine is still running; the original instructions are still executing cycle-accurately to how they should. So the "game feel" is preserved perfectly. If you were good at the original game, you'll still be good at playing an "enhanced emulation" of the game; nothing will be "off" about it. Even input movies recorded against the un-enhanced game should replay unmodified against the enhanced game!)

Contrast this to the average "HD remaster", where the game is at the very least recompiled for a new platform (with different timing guarantees), if not entirely rewritten atop a new engine. In that process, there's no "isolation layer"; no way to guarantee a preservation of any part of the original game logic in the remastered artifact. And like George Lucas, game developers coming back to their own works 20–40 years later, just can't help but want to tweak things. So these HD remasters end up breaking "game feel" in all sorts of ways.

You could try https://github.com/dscharrer/innoextract (installable via homebrew).

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.

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 you would do in Windows 11 and spin up VM with an older version of the OS.

I keep a Windows 2000 VM with no network access around just to occasionally play Heroes of Might and Magic 3.

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.

> 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...

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).

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.