# 86Box roms: the firmware image repository behind the 86Box emulator > The 86Box ROM repository holds the machine firmware images the emulator needs, one directory per device category, from floppy and hard disk images to SCSI, sound, video, printer, network, real time clock, memory card, and the machine definitions themselves. It is a data repository rather than a code project, and its contribution process is governed by a rule that the emulator has to accept the code first. **86Box/roms** — ROMs for the 86Box emulator. For development versions of 86Box, the recommended way to use this repository is to clone it instead of downloading the tagged releases. - Repository: https://github.com/86Box/roms - Stars: 753 · Forks: 152 - Language: Unknown - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/86box-roms ## A data repository, and what it is for This repository contains all the ROMs needed by the 86Box emulator, and it is the companion data repository for the emulator project rather than part of the emulator source tree. That distinction matters if you are deciding where to look. The emulator itself lives in its own repository, and this one holds the images the emulator loads: the firmware that a real machine of that type would have had in its BIOS, its video card, its disk controller, its sound card, and so on. Without a ROM set, 86Box is a program with nothing to run. The repository is not archived and the last push was on 2026-10-20, so the set is being maintained continuously. The releases are named after the emulator version they accompany, with a 7.0 prerelease from 2026-10-14, a 6.0 set from 2026-05-30, and a 6.0 beta from 2026-05-18. The language is recorded as unknown, which is what you would expect for a repository of binaries, and the licence is one GitHub cannot classify automatically, with a LICENSE file in the root that is the authoritative text. The top level of the repository is a directory per device category, and the list is a compact description of what 86Box emulates. There is a floppy directory, a hard disk directory, a machines directory, a memory card directory, a network directory, a printer directory, a real time clock directory, a SCSI directory, a sound directory, and a video directory. The machines directory is the interesting one, because a machine definition and the firmware it needs are usually two separate things. The definitions say how the machine is wired together, and the ROMs say what its components think they are. ## Clone it, do not download a tag, if you are on a development build The repository description contains the practical instruction, and it is conditional on which build of the emulator you are running. For development versions of 86Box, the recommended way to use this repository is to clone it instead of downloading the tagged releases. That is a small sentence with a reason behind it. A tagged release of the ROM set corresponds to a tagged release of the emulator, so a user on a stable build wants the matching tag. A user on a development build wants the current state of the data, because the development branch of the emulator is regularly learning about new devices and new ROM revisions, and a tag from May is missing whatever landed since. The repository README says the same thing in a slightly different way, and adds a caveat that is worth reading carefully if you are debugging a machine that will not appear. Some ROMs in the repository may be for dev-branched machines and devices, meaning that they will not do anything on regular release builds. If you are confused why some device does not appear despite the ROM being present in the set, check that you are using an appropriate build of 86Box before reporting issues. So the failure mode is a specific one. A ROM is present in the data, the emulator is a stable build, and the device does not show up. The cause is not a missing file, it is a version mismatch between the data and the binary, and the README asks you to rule that out before filing an issue. That is a considerate instruction, because the alternative is a queue of reports that are really one question about which branch you cloned. ## The contribution rule: the emulator has to want it first The contributing section contains one rule that determines the whole workflow, and it applies to removals as well as additions. Before new ROMs can be accepted in this repository, the code that uses the ROMs needs to be in the upstream 86Box repository. Once you have made an 86Box pull request, you open a pull request here. And this applies to removals as well, in inverse. The order is deliberate. The ROM repository is a data set, and a data set that contains images for a device the emulator cannot boot is not just useless, it is a source of confusion and of wasted debugging time. By requiring the emulator support to land first, every image in the set corresponds to something the emulator can actually run. The timing rule is the second half of it. Your ROM will not be merged to master until the code is in 86Box master. However, if the development is happening in an upstream 86Box branch, a corresponding branch can be created here until the feature is ready for master. So a contributor is expected to work in two repositories at once, with the emulator change landing first, and the ROM change following it into master. The branch escape hatch exists for the case where the emulator work is itself still in flight, and it is the reason a contributor does not have to wait for a release cycle before contributing an image. For anyone reading the repository rather than contributing to it, this process explains something about the data set itself. A device that exists in the emulator is very likely to have its ROM here, and a device that is present in the ROM set but not in your emulator build is a version question rather than a data question. ## Commit guidelines, which are unusually specific The commit guidelines section is short and prescriptive, and it reads like the result of having merged a lot of large binary uploads without any information in them. The first rule is not to use vague commit messages, and the examples are the point. An acceptable message names the exact machine, such as adding the ROM for a particular board model or removing the ROM for another one. An unacceptable message is one that says the files were added via upload, or that it is a romset update, or that it deletes a ROM. The second rule is to separate additions and removals into different commits, which is the convention that makes a large binary change reviewable at all, since a diff of a commit that only removes one ROM is comprehensible and a diff of a commit that removes one ROM and adds nine is not. The third is about the subject line length, which should not be longer than fifty characters. If you are having trouble fitting what you did in the subject, consider splitting your changes into multiple commits. And if you genuinely need to give a lot of background information and splitting is not appropriate, write it in the description. The closing line is the one that makes the guidelines work. If you make no effort to follow these guidelines, your contribution will not be merged until you correct the highlighted issues. And the last sentence is an invitation to ask for help if you have made a mistake and do not know how to correct it. That combination, a strict rule and an offer of help, is the right way to write it. A repository of binaries is only usable if a human can tell what changed in a commit, and the fifty character limit with the escape to the description is a workable compromise between the reviewer's need for a one line summary and the contributor's need to explain a large change. ## The device categories, and what they tell you about the emulator The directory list is worth reading as a map of the project, because each one is a place where the emulator has to be right about real hardware. The floppy and hard disk directories hold the storage images, which for a period machine means the actual geometry and the file system of the original media rather than a modern disk image format, and getting that wrong is the difference between a machine that boots and one that does not. The video directory covers the graphics cards, and it is the one where the variety is highest, because a period machine might have had a fixed screen, a standard card, or something exotic, and each of those needs its own firmware image and its own emulation. The sound directory covers audio hardware, which is the same problem in another dimension, since there were several sound standards and the choice affects what the operating system thinks it is driving. The SCSI and network directories cover the two subsystems that are hardest to emulate convincingly, because both are about the behaviour of a bus rather than about a chip, and both are the places where a user is most likely to notice that something is not right. The printer, real time clock, and memory card directories cover the peripherals, and the real time clock one is quietly important, because a machine with the wrong clock will fail in ways that look like unrelated bugs, with certificate validation failures and file timestamps in the wrong decade. And the machines directory is where the definitions live, which is the part that connects all of the above, because a machine definition is the statement of which firmware belongs to which device in which configuration. The consequence for a user is simple. When a device does not work in 86Box, the question is almost always which of these directories the missing piece is in, and the answer determines whether you are looking for a firmware image or for the emulation code that uses it. ## Conclusion The 86Box ROM repository fits an emulator user who wants a machine that is not in their current set, or a developer working on a new device who needs the images to test against. It does not fit a user on a development build who wants to stay on a tagged set, because the recommendation for development builds is to clone the repository instead of downloading a release, and it does not fit a contributor who has not already landed the emulator code. Verify first that the ROM set you want is present, that you are on a 86Box build that includes the corresponding support, and that your contribution follows the two part process, upstream code first and the ROM second, since a ROM pull request on its own will sit unmerged. ## FAQ ### What is the 86Box ROM repository? It holds all the ROMs needed by the 86Box emulator, as the companion data repository for the emulator project. The top level is organised by device category, with directories for floppy, hard disk, machines, memory card, network, printer, real time clock, SCSI, sound, and video. ### How do I get the ROM set for a development build of 86Box? Clone the repository rather than downloading the tagged releases. The tagged ROM sets correspond to tagged emulator releases, so a development build needs the current state of the data to include whatever the development branch has learned since. ### Why does a device not appear in 86Box even though its ROM is present? Because some ROMs in the repository are for dev-branched machines and devices and do nothing on regular release builds. The README asks you to check that you are using an appropriate build of 86Box before reporting the issue. ### What is the rule for contributing a ROM to the 86Box repository? The code that uses the ROM has to be in the upstream 86Box repository first, and only then do you open a pull request here. The same applies to removals in reverse, and the ROM will not be merged to master until the emulator code is in 86Box master, although a corresponding branch can be created while the feature is still in flight. ### What commit message style does the 86Box ROM repository expect? No vague messages. An acceptable message names the exact machine being added or removed, additions and removals go in separate commits, and the subject line should not be longer than fifty characters, with longer background moved to the description. The README says contributions that ignore the guidelines will not be merged until they are corrected. ## Sources - [86Box/roms on GitHub](https://github.com/86Box/roms) - [Issues](https://github.com/86Box/roms/issues) - [README](https://github.com/86Box/roms/blob/master/README.md) - [Releases](https://github.com/86Box/roms/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/86box-roms