OpenComputers II: Linux and CP/M running on emulated hardware inside Minecraft

Two architectures, one Linux and one CP/M

OpenComputers II is a Minecraft mod adding virtual computers to the game, and the hardware choices are specific rather than generic.

The computers run a virtual machine emulating a 64-bit RISC-V architecture capable of booting Linux, or an 8-bit Z80 architecture running CP/M 2.2. So there are two genuinely different machines in the same block, one a 64-bit Linux-capable system and one an 8-bit system on a DOS-like operating system from the era of the original IBM PC.

That pairing is the interesting design choice. A Z80 running CP/M is a machine you can genuinely understand, and a RISC-V running Linux is a machine that is actually useful, so the mod can serve two different player motivations with one set of concepts. The README calls the project a spiritual successor to OpenComputers, and says that while many implementation details have changed quite dramatically, the concepts of customizable hardware, persistence and sandboxing are still at the core of it.

The primary language is Java, the loaders are Fabric and NeoForge, and the homepage is the CurseForge mod page. The current release is 1.21.1/0.10.0, tagged on 2026-10-20, following 0.9.1 and 0.9.0 earlier in October, and the default branch is 1.21.1, so the project tracks the Minecraft version it targets.

The licence situation is worth noting because it is unusual for a mod. The repository records a custom licence that GitHub cannot classify, and the contributing section says that by contributing you accept that the code is licensed under the MIT license, with LICENSE and LICENSE-JCODEC files at the root. A separate file for a code generator library is a sensible thing to see, since it is the part of the tree that is not the mod itself.

The device API is the extension point, and it comes in two levels

The architecture of the mod is best understood through the two APIs it exposes, because that is how a mod author adds a device.

The high level Lua API, HLAPI, is provided to communicate with various devices in the game world, and it enables adding virtual devices using a simple, Java-friendly API without having to implement actual kernel drivers. That last clause is the whole point of the design. A device in the game is normally something that needs a driver in the emulated OS, and requiring every device author to write one in Linux or CP/M assembly would make the extension surface almost unusable.

The mid level API, MLAPI, serves the same purpose on the Z80 but at an assembly level. So the same device concept has two bindings, one for each machine, and the high level one is the one most mod authors will use.

The API types are documented in the Javadoc, the manual is published as a site, and the same manual is also available as an in-game item, which is a nice touch for a mod whose whole subject is computing.

The developer documentation in the repository follows the same split. The docs directory holds a high level overview of things like the device API for mods and the data pack extension points, the examples directory holds minimal mods using the device API, and the API Javadoc documents the mod's API types.

The examples directory is worth a look for anyone evaluating, because the naming shows the intended extension scenarios. There are block-entity examples for both loaders, a card example for NeoForge, and third-party-block examples for both loaders. A card is the item-based device form factor, and the third-party-block examples exist so that another mod's block can be exposed as a device, which is the extension point that matters most for interoperability.

Five design guidelines explain most of the technical choices

The contributing section carries the author's rough design guidelines, and they are the clearest statement of intent in the project.

Immersion comes first. The mod should avoid breaking the fourth wall. In-game documentation reads in context, devices do not expose game internals like absolute coordinates, and physical interaction with the world should make sense, so a bus interface should not be able to just move items around in an adjacent chest. Block and item ids are given as an example of the kind of exception that exists.

Realism is the second. Computers are emulating real hardware, and to some degree knowledge should transfer from and to the real world. Going deeper is encouraged, so building and using custom firmware or a custom OS should be possible without mod or datapack modifications.

Flat progression is the third, and it is a deliberate constraint. At least for now the focus is on horizontal rather than vertical progression. No complex tech tree of tiered hardware, and no explicit block or item being strictly better than another, since it should always be a tradeoff. Capability usually drives up power consumption rather than crafting costs or complexity, and specific focused devices are preferred so players make active decisions when composing things.

Sandboxing is the fourth, and it is the one that matters for a server. The mod should be safe to put on a server with untrusted players. That means permission checks so devices cannot be used to grief directly, for example robots breaking things, and no server resource denial-of-service or resource exhaustion attacks: memory use limits, disk use limits, controlled network traffic and stable tick times, with throttling as the fallback. Indirectly griefing other players by exhausting sandbox resources is out of scope for now, with the example of one player spamming computers so others cannot start theirs.

Maintainability is the fifth. The codebase should avoid extremely complex systems beyond the one core one, virtualization, and features should be compartmentalised and tested, with game tests being easy to add. Features must not need host configuration or dependencies, which the author says was the whole point of writing an emulator in Java. And prefer good defaults over config values, because in the predecessor the config surface exploded to infinity, making it incredibly hard to test.

Two loaders, a Gradle build and a game test suite

The engineering side of the repository is what you would expect from a mod of this size, and a few details are worth knowing before you try to build it.

The build is Gradle with Kotlin DSL, so build.gradle.kts and settings.gradle.kts at the root, with a buildSrc/ directory for custom build logic and a gradle/ directory with the wrapper. The loader-specific code is split into fabric/ and neoforge/ directories, with common/ holding the shared parts, and the gradle.properties file at the root carries the shared version and dependency configuration.

There is a gametest/ directory at the top level, and the README badges point at a separate test-report workflow labelled game tests, distinct from the build workflow. That matches the maintainability guideline about testing being easy to add, and it is the mechanism by which the sandboxing rules get exercised rather than merely documented.

The assets/ directory holds the mod's resources, the tools/ directory holds build tooling, and there is a pmd.xml for static analysis, along with an .editorconfig and .gitattributes for formatting.

The examples are structured the same way as the main build, with one directory per example and per loader, so a new example is a self contained Gradle module rather than a file you add to a shared project. The examples directory has its own README.

One point of care for a contributor: when adding a new block or item, document it both on the device and in the in-game manual, and preferably add game tests for it. The guideline exists because a device with no documentation and no test is exactly the kind of thing that breaks the immersion the project is trying to protect.

The build badge points at a workflow named build and the test badge at one named test-report, and the CI workflow files live in .github/workflows.

Where OpenComputers II is the wrong tool

The first wrong-tool case is a server that has not been reviewed for sandboxing. The guidelines say the mod should be safe to put on a server with untrusted players, and they spell out the threat model: devices that grief directly, memory and disk exhaustion, uncontrolled network traffic and tick time instability. That is a list of things to test on your own deployment, and the mitigation mentioned for uncertain cases is throttling. A server operator who installs the mod without reading that section is relying on the author's judgement rather than their own.

The second case is a player on a Minecraft version the mod does not support. The default branch is 1.21.1 and the latest release targets that version, so a player on a different release needs a different build, and a server on a different version needs its own build for every mod on it. The dual loader support, Fabric and NeoForge, doubles that surface rather than reducing it.

The third case is a mod author who wants a device that must reach into the emulated operating system. The design deliberately avoids that. The high level Lua API exists so that you do not have to implement actual kernel drivers, and a device that needs to intercept things like a real interrupt or a specific memory-mapped region is outside what the API offers. The two level split is a convenience, and the price is that the device model is constrained to what the host can mediate.

The fourth case is anyone expecting the original OpenComputers. This is a spiritual successor with many changed implementation details, and the concepts of customizable hardware, persistence and sandboxing are what carried over rather than the code or the recipes.

What you get in exchange is a machine you can actually boot. The RISC-V side can run Linux, which means a player can do real work inside the game rather than push buttons on a fictional device, and the Z80 side gives the CP/M experience with a much lower barrier to entry. The flat progression design also means the interesting decisions are in how you compose devices rather than which tier you have unlocked.

Editorial conclusion

OpenComputers II suits a Minecraft player who wants to program real machines inside the game rather than solve a tech tree, and a mod author who wants to add a device without writing a kernel driver. It does not suit a server operator without a sandboxing review, because the design guidelines explicitly target untrusted players and the mod needs both loaders and the host to be kept current. Before installing, read the sandboxing section of the contributing guidelines, check the CurseForge and Modrinth pages for the loader combination you need, and note that the current release targets Minecraft 1.21.1, so a different game version means a different build of the mod.

Frequently asked questions

Official sources

1. fnuecke/oc2 on GitHub
2. Issues
3. Project website
4. README
5. Releases