Minecraft on a 1960s UNIVAC: What It Takes to Run the JVM on Hardware That Predates Unix

There is a category of retrocomputing project that exists purely to answer the question “can it?” without any pretense that the answer will be useful. Running a Minecraft server on a 1960s UNIVAC computer falls squarely into that category, and the writeup by Farlow is the kind of deep technical archaeology that makes it worth understanding in detail, not just appreciating from a distance.

The interesting part is not that Minecraft ran. The interesting part is what had to be true about computing history, emulation design, and the Java Virtual Machine for it to be possible at all.

What a UNIVAC Actually Was

UNIVAC is a family, not a single machine. The original UNIVAC I, delivered to the US Census Bureau in 1951, was a vacuum-tube behemoth that weighed around 13 tons and consumed roughly 125 kilowatts. By the mid-1960s the line had evolved considerably: the UNIVAC 1107 and its successors used transistors rather than tubes, ran at clock speeds measured in fractions of a megahertz, and addressed 36-bit words rather than bytes.

That 36-bit word size is the first thing that makes running modern software on real UNIVAC hardware strange. Most contemporary computing assumes an 8-bit byte as the fundamental addressable unit. The UNIVAC 1100 series addressed 36-bit words, with each word holding six 6-bit characters under the FIELDATA encoding system. A byte, in the modern sense, does not exist natively. Code that assumes char is 8 bits, or that a pointer fits in 32 bits, or that memory is laid out in a particular way runs into immediate obstacles.

The UNIVAC 1108, introduced in 1965, pushed the architecture further: pipelined execution units, a memory cycle time around 750 nanoseconds, and support for up to 262,144 words of core memory. Core memory. The kind where each bit is stored as the magnetic orientation of a tiny ferrite ring threaded on wires by hand. The kind that holds its state when power is cut, and that generates a detectable pulse when read. To run anything modern on this hardware, you are running it on a machine whose memory subsystem predates the invention of the DRAM chip.

The Emulation Layer

No one is running a JVM natively on a UNIVAC 1108. The word size alone makes that impractical: the JVM specification assumes a 32-bit or 64-bit host, and its bytecode is defined in terms of 8-bit bytes. You cannot simply compile a JVM for a 36-bit one’s-complement word machine without fundamental rethinking of the memory model.

What projects in this space typically do is layer an emulator. The UNIVAC hardware runs software written for its native architecture, and a software emulator running on that hardware presents a virtual environment closer to what modern code expects. This is not so different from what Hercules does for IBM mainframes, or what SIMH does for a wide range of vintage architectures including several UNIVAC models. SIMH, in particular, includes a reasonably complete simulation of the UNIVAC 1100 series that handles the 36-bit word, the one’s-complement integer arithmetic, and the Exec operating system’s I/O model.

But running an emulator on an emulator, or running an emulator on real hardware that is itself already being simulated through cycle-accurate timing adjustments and interface adapters, means understanding exactly which layer each piece of software inhabits.

The more credible path for running something like Minecraft on 1960s hardware directly is to treat the vintage machine as physical infrastructure and run the actual workload through a chain that looks roughly like this:

1. Real UNIVAC hardware, maintained and operational, running its native OS
2. A network interface that bridges the vintage hardware to a modern IP stack, since UNIVAC networking predates TCP/IP by decades
3. A modern computing environment that the UNIVAC can delegate work to, or that runs in a virtual machine the UNIVAC’s OS manages

That last step is the telling one. When a project like this says “running Minecraft on a UNIVAC,” the honest answer often involves the UNIVAC doing something real, such as bootstrapping, scheduling, or providing an interface, while the JVM workload runs somewhere it can actually execute. The value of the project is in what the UNIVAC contributes, not in pretending it natively executes Java bytecode.

Why the JVM Makes This Particularly Interesting

Java’s “write once, run anywhere” promise is about abstracting over ISA differences. The JVM presents a uniform environment regardless of whether the underlying processor is x86, ARM, RISC-V, or something else. That portability, in principle, extends to any architecture with a working JVM implementation.

GCJ (GNU Compiler for Java) and Excelsior JET tried ahead-of-time compilation of Java to native code. Avian is a lightweight JVM implementation written in C++ that can compile down to a small footprint for embedded targets. GraalVM Native Image does AOT compilation today. The question for vintage hardware is whether any of these can target an architecture old enough to predate the C standard.

The UNIVAC 1100 series has a GCC backend maintained through the UNISYS simulator community, though it is not in the mainline GCC tree and its completeness for modern C++ is limited. A Minecraft server, specifically the vanilla server JAR that Mojang distributes, pulls in a substantial dependency tree including Netty for networking, a logging framework, and the game logic itself. The resulting JVM heap under normal operation sits somewhere between 512 MB and 2 GB depending on world size and player count. A real UNIVAC 1108 with a maximum of 262,144 36-bit words has about 1.1 MB of addressable core memory. That gap is not bridgeable by clever coding.

The interesting framing, then, is that running Minecraft “on” a UNIVAC is an exercise in what you can make a vintage machine orchestrate, not what you can make it execute directly. The UNIVAC becomes the interface point, the console, the historical artifact that the workload passes through, and that reframing is itself technically interesting.

Networking Across Six Decades

UNIVAC machines of the 1960s communicated through their own protocols. The UNIVAC 1100 series used a DCA (Data Communications Adapter) for serial connections. There was no Ethernet, no IP stack, no concept of a socket in the Berkeley sense. Interfacing a machine like this to a modern network requires custom hardware, typically an embedded system or a small single-board computer that speaks the UNIVAC’s peripheral bus on one side and standard Ethernet on the other.

Projects like this one for connecting PDP-11s to Ethernet give a sense of what that work involves: custom FPGA or microcontroller firmware that implements the vintage machine’s bus protocol and bridges it to a PHY. For UNIVAC, the adapter would need to handle the timing and signal levels of 1960s-era peripherals. This is not trivial hardware work.

Once the network bridge exists, the UNIVAC can make TCP connections, receive packets, and interact with the outside world in ways its designers never imagined. A Minecraft client connecting to a server address could, in principle, be routed to an IP served by an adapter physically plugged into a 1960s UNIVAC chassis.

What the Retrocomputing Community Has Built

The broader context here matters. UNIVAC machines are not the most popular retrocomputing platform, but they have an active preservation community. The Computer History Museum holds examples of early UNIVAC hardware. The Charles Babbage Institute at the University of Minnesota maintains archival records. SIMH’s UNIVAC 1100 simulation is detailed enough to run actual historical software, including the EXEC-8 operating system.

The TUHS (The Unix Heritage Society) mailing list and related communities have done similar archaeology for other architectures, recovering source code and documentation that would otherwise be lost.

Running something as recognizably modern as Minecraft on this hardware is a form of living archaeology. It demonstrates that the machine works, that the community around it has the skills to interface it with the modern world, and that the gap between 1965 and 2024 is not, in practice, absolute. The workload is beside the point. A Minecraft server is a convenient target because it is a well-understood, self-contained Java application with a defined network protocol. It could just as easily be a web server, a database, or any other bounded service.

The Technical Argument Worth Making

There is a version of this project that is genuinely instructive beyond the novelty. When you force modern software to interface with vintage hardware, you learn things about the assumptions embedded in contemporary software stacks that are otherwise invisible.

Consider byte ordering. The UNIVAC 1100 series is big-endian in word layout, but the concept of byte endianness barely applies when your words are 36 bits. Java’s DataInputStream and DataOutputStream assume network byte order, which is big-endian 16-bit and 32-bit values. The Minecraft protocol, documented at wiki.vg, uses big-endian multi-byte integers throughout, which means it is actually more natural for a UNIVAC than for an x86 machine.

Consider alignment. The UNIVAC requires word-aligned memory access. Unaligned reads generate traps. Modern x86 CPUs handle unaligned access in hardware; ARM CPUs used to trap on it and still carry the flag for strict alignment mode. Code that takes alignment for granted, including most JVM implementations, needs explicit handling when targeting architectures that enforce it.

Consider the I/O model. The UNIVAC 1100’s I/O system is based on I/O channels, a concept that IBM also used in its System/360 and that survives in modern IBM Z mainframes. An I/O channel is essentially a small processor dedicated to managing device communication, freeing the main CPU from polling loops. Minecraft’s Netty-based networking layer sits far above that abstraction, but tracing the I/O path from a player’s packet all the way down to core memory on a UNIVAC chassis is an exercise in understanding every layer of the stack.

The Part That Is Just Fun

None of the above analysis should obscure what this actually is: someone kept a 60-year-old computer running, connected it to the internet, and made it serve Minecraft to players. That is an achievement in hardware preservation, in mechanical and electrical engineering, and in the kind of stubborn refusal to accept that old things should stop working.

The machines that first ran payroll for US government agencies, that processed census data in the 1950s, that ran military logistics software during the Cold War, are not museum pieces behind glass. Some of them still work. Some of them can do new things. That continuity matters, not for any practical reason, but because understanding where computing came from makes it easier to see what is contingent and what is fundamental about where it is now.

The word size changes. The memory technology changes. The programming model changes. The fact that you can put a packet on a wire and have a program somewhere respond is the same idea it was when ARPANET first demonstrated it in 1969, four years after the UNIVAC 1108 shipped. Some things travel well across sixty years.