# openMSX and the case for a data-driven MSX emulator > openMSX is a C++ MSX emulator whose repository ships three build entry points, HTML manuals and a GPL licensing scheme that leaves some files under their own terms. It suits developers who want to configure and extend the machine itself, and it frustrates anyone looking for a README that answers questions in three lines. **openMSX/openMSX** — the MSX emulator that aims for perfection - Repository: https://github.com/openMSX/openMSX - Website: http://openmsx.org - Stars: 559 · Forks: 145 - Language: C++ - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/openmsx-openmsx ## What the MSX emulation target actually is openMSX describes itself as the MSX emulator that aims for perfection, and the repository topics list the machines it covers: MSX, MSX2, MSX2+ and MSX turbo R. The primary language is C++, and the default branch is master. That phrase about aiming for perfection is the project's own tagline rather than a measurement, so it is worth reading as a statement of intent: the emphasis is on modelling the machine closely, across several hardware revisions, rather than on booting a cartridge quickly. The people this suits are the ones who care about peripheral behaviour and configuration detail, such as developers trying to run software on a specific machine revision, or people who want to inspect how the emulator models a device rather than just launch a game. ## Three build entry points in one repository The top level of the repository carries a GNUmakefile, a meson.build, a meson_options.txt and a separate configure script, plus a build/ directory. Having a GNUmakefile alongside a Meson description and an autoconf-style configure script means the project supports more than one route to a binary, and each of them exists in the tree rather than being described in prose. The presence of meson_options.txt indicates that build-time choices are exposed as options rather than hard-coded. The repository also contains Contrib/, share/, src/, doc/ and .github/, which is the usual shape of a project that separates its C++ sources, its runtime data, its contributed files and its continuous integration configuration. Which of the three build systems to use is the practical first decision, and the README itself does not make that call for you. ## The README is a signpost, not a manual The README file in this repository is short by design, and it points outward instead of answering. It states that openMSX ships a set of HTML manuals describing what you need to know to install, configure and run the emulator, and that these live in the manual directory inside the doc directory, readable in a web browser. It also points to release-notes.txt in the doc directory for what changed in the current release, and to release-history.txt for highlights of earlier ones. That structure has a consequence for anyone evaluating the project quickly: the repository's front page cannot tell you which emulated peripherals exist, which machine revisions are configurable, or what the configuration file format looks like. You have to open the manuals directory to learn whether the tool fits your use case at all. ## Getting a binary, then the sources behind it The README makes one point about distribution that matters for anyone deploying this: if you received a binary release and want the sources, the project asks you to visit its home page, and the licence scheme is set up so that sources are obtainable. The canonical address appears in the README as: ```bash https://openmsx.org/ ``` The project's home page is also listed as http://openmsx.org. The build tree in the repository, with its own configure entry, is the route for people who intend to compile rather than download. Two practical consequences follow. First, there is no package manager recipe in the repository, so installation guidance has to come from the manuals rather than from a command you can copy out of the README. Second, a binary you did not build yourself comes with a source obligation attached, which is the usual and expected arrangement for software under the GPL, but it is an obligation that a redistribution policy should be checked against before the binary reaches users. ## Release cadence and what an upgrade costs The release history shows openMSX 21.0 published on 2025-09-26, preceded by 20.0 on 2024-09-22 and 19.1 on 2023-08-30. The spacing is roughly annual for the numbered versions, and the repository's last push was on 2026-10-18, so the tree is receiving commits well after the 21.0 tag. A yearly numbered release with continuous commits between tags means a user who installs once and never updates is a long way behind, and the release notes in doc/release-notes.txt are the place where behaviour changes are recorded. That file is the practical upgrade tool: it is where you look to see whether a machine revision, a peripheral or a configuration option changed under you. The cost of upgrading is therefore reading, not patching, since the project ships binaries and the source is available for the rare case where you must build. ## A licence scheme that is not uniform The README states that some source files contain a licence notice and that all other source files are licensed under the GNU Public License, with a copy in the file GPL.txt. Copyright is held by the respective authors, and the file authors.txt lists the people who made works for openMSX or contributed works to it. The practical implication is that a compliance check has two parts: the default GPL covering the bulk of the tree, and a set of per-file notices that may point elsewhere. Nothing here is legal advice, and the point is procedural rather than doctrinal. If you vendor openMSX into a product, you need to locate those individually noticed files and read them, rather than assuming the GPL answer covers everything. The repository also carries a .gitattributes file, which usually signals repository wide handling rules for line endings or binary files, and it is worth checking when you copy the tree into a build pipeline. ## Where openMSX is the wrong tool If you want a single binary to run one cartridge and nothing else, a small purpose-built emulator does less work than a full machine model with configuration layers, and this project asks for a real toolchain plus a configuration step before it will do anything. If you need a uniformly licensed source tree, the per-file notices described above add a review step that a single-licence codebase would not. If you need to know in thirty seconds whether a given peripheral or machine revision is emulated, the repository front page will not tell you, because the answer lives in the HTML manuals under doc/manual and in the source tree itself. The clearest fit remains someone who wants to configure the emulated machine, read how a release changed behaviour, and eventually look at the code that models a device. ## Conclusion openMSX is a good fit for someone who wants the MSX machine as a configurable system: a developer porting software, a researcher reading release notes for behaviour changes, or a user who wants the emulator to keep tracking the hardware rather than a frozen 1980s snapshot. It is a poor fit for a quick install on an unsupported platform, since the repository README carries no install commands and defers everything to the HTML manuals, and for a company that needs a single uniform licence across the tree, because some source files carry their own notices. Check three things before committing: whether a release near 21.0 from 2025-09-26 covers the machine and peripherals you need, whether you can meet the toolchain for the GNUmakefile, meson.build or configure path you intend to use, and whether the per-file licence notices in the source are acceptable to you, since the bulk of the tree is GPL and the rest is not necessarily so. ## FAQ ### What is openMSX and which MSX machines does it cover? openMSX is a C++ MSX emulator whose repository topics list MSX, MSX2, MSX2+ and MSX turbo R. It calls itself the MSX emulator that aims for perfection, and its default branch is master. ### How do I install openMSX? The repository README gives no install command and instead points to a set of HTML manuals that describe what you need to know to install, configure and run openMSX. Those manuals live in the manual directory inside the doc directory and are read in a web browser, and the project's home page is openmsx.org. ### What build systems does the openMSX repository support? The top level of the repository contains a GNUmakefile, a meson.build with a meson_options.txt, and a separate configure script, along with a build/ directory. The README does not state which of these to use. ### Where can I read what changed in an openMSX release? The release notes for the current release are in the file release-notes.txt in the doc directory, and highlights of previous releases are in release-history.txt. The README states the release notes of the current release can be found in that first file. ### What licence is openMSX released under? The README states that some source files contain a licence notice and that all other source files are licensed under the GNU Public License, with a copy in the file GPL.txt. Copyright is held by the respective authors, and authors.txt lists contributors. ## Sources - [Issues](https://github.com/openMSX/openMSX/issues) - [openMSX/openMSX on GitHub](https://github.com/openMSX/openMSX) - [Project website](http://openmsx.org) - [README](https://github.com/openMSX/openMSX/blob/master/README.md) - [Releases](https://github.com/openMSX/openMSX/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openmsx-openmsx