Stella: a multi-platform Atari 2600 VCS emulator you can build from source

An emulator of one console, kept alive for three decades

Stella is a multi-platform Atari 2600 VCS emulator, and the README puts the audience plainly: it lets you play your favourite Atari 2600 games on your PC. The primary language of the repository is C, while the Makefile compiles the tree as C++ with a C++23 standard, so in practice this is a C++ project with a C heritage. That combination is not unusual for emulators, where the console side is a hardware contract described in a manual and the host side is ordinary application code, but it does mean the codebase is read as C++ even though much of the surrounding text speaks of C. The project is licensed GPL-2.0, carries a copyright line in the Makefile covering 1995 through 2026, and has kept a website at stella-emu.github.io that the README points to for checking whether you have the latest release. For an engineer, the interesting part is not the game library. It is that a working emulator for a 1977 console has been maintained continuously for close to thirty years, which is a rare long-term maintenance record in emulator code.

configure writes config.mak, and the Makefile is only half the story

The build is a two step arrangement that is worth understanding before you touch a flag. The top level tree contains a configure script along with config.guess and config.sub, and the Makefile includes a file called config.mak whose comment says it loads the make rules generated by configure. So the flow is: configure probes the system and writes config.mak, then the Makefile pulls those rules in and compiles. Because the rules live in a generated file that is not checked into the tree, editing the Makefile alone will not change a setting that configure already decided, which is a common source of confusion. The defaults are visible in the Makefile itself, and they are conservative. The compile flag is -DSDL_SUPPORT, so SDL support is on by default, and the linker flag is -pthread. The variables for sources, libraries and modules are declared empty at the top and filled in by the generated rules. There is also a separate set of test compile flags, CFLAGS_TEST and CXXFLAGS_TEST, which means the test suite is compiled with its own switches and can diverge from the main build.

macOS Gatekeeper blocks the app before you see a single frame

The README has a dedicated section on macOS installation, and the reason is specific rather than general. When you download Stella on macOS, Gatekeeper may refuse to open the app with a message saying that Stella cannot be opened because Apple cannot verify it is free from malware. There are two documented workarounds. The first is a right click, or control click, on Stella.app, then choosing Open from the context menu and confirming Open in the dialog, which only has to be done once. The second is a terminal command that strips the quarantine attribute from the downloaded bundle:

xattr -dr com.apple.quarantine /path/to/Stella.app

Replace the placeholder path with the real location of the app bundle and macOS will stop applying the quarantine flag to it. Either route is a one time action per copy, and the README is clear that once the app has been opened this way it starts normally afterwards. This is the kind of friction that decides whether a user tries a project twice, which is why the README keeps the instructions short and puts them at the top of the install story rather than in a troubleshooting appendix.

The issue tracker is shared, the support responsibility is not

Reporting problems is where this project draws a line that surprises people, and it is stated at the top of the README. You are asked to check the list of known issues first, which lives in the issue tracker, before opening a new one. The sharper part is the exclusion: the Stella Team asks that issues regarding platforms other than PC and RetroN 77, with Libretro given as the example, are not reported there, because the team is not responsible for those forks and cannot help with them. That means the upstream tracker is not a general Atari 2600 emulator support desk. It covers the platforms the project maintains itself. For a team evaluating the project, this tells you something about the shape of the work: upstream takes the mainline, and variants such as the Libretro core are maintained elsewhere, so a bug in a fork may never reach the people who wrote the original code. Search the existing list before filing, and expect that issue triage covers the maintained platforms only.

The tree carries a manual, a changelog and a Debian packaging directory

Beyond the source, the top level layout tells you how the project is organised and where the answers live. The src directory holds the implementation, test holds the test suite, and docs contains the Stella Users Manual that the README points to as the place to find the documentation. Copyright.txt and License.txt carry the licensing text, Changes.txt is the change log, and Todo.txt plus Announce.txt track planned and announced work. There is a debian directory, so the project is packaged for Debian, and a .gitlab-ci.yml at the top level, which shows that continuous integration is driven from GitLab even though the source is hosted on GitHub. The .vscode directory points at editor tooling, and the presence of CLAUDE.md shows the project ships guidance for AI coding assistants alongside its own conventions. For someone evaluating the project, the manual in docs is the artifact that matters most, because option names and behaviour in an emulator are scattered across a lot of keyboard shortcuts and menu screens.

GPL-2.0 with a warranty disclaimer, and releases that lag the commits

The licensing picture is simple and has consequences. The repository is classified as GPL-2.0, and the Makefile header points readers at the file License.txt for information on usage and redistribution of the source, and for a DISCLAIMER OF ALL WARRANTIES. The copyright line names Bradford W. Mott, Stephen Anthony and the Stella Team, covering 1995 to 2026. If you intend to redistribute Stella, or to fold parts of it into another product, the GPL obligations attach to the distribution itself, and that is a question for your own legal review rather than something this article can answer. On releases, the picture is different from the commit activity. The listed releases are 7.0 from 2024-10-05, 6.7.1 from 2024-01-15 and 6.7 from 2022-06-13, while the last push was on 2026-10-19. Work continues between tagged versions, and the README asks users who want the newest build to check the website rather than assuming a release tag is current.

Editorial conclusion

Stella is a good fit for developers who want to read a long lived emulator codebase, patch a platform, or run the console's games on a machine the original hardware no longer supports, and the build system is conventional enough to pick up in an afternoon. It is the wrong choice if you need a maintained console emulator that covers hardware beyond the 2600, or if you need commercial redistribution terms, since the project is GPL-2.0 and the source itself states it is provided with a disclaimer of all warranties. Before adopting it, build from the source tree with the configure script and the generated config.mak, read the Stella Users Manual in the docs subdirectory for the option set, and check the issue tracker for the known issue list so you do not file a problem that is already tracked.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. stella-emu/stella on GitHub