Inkbox Software revives Zaxxon from the UEFI firmware

There are projects that make you raise an eyebrow and think: wow, this is something different. Inkbox Software has paid homage to the old school Bringing back a classic isometric arcade game and making it boot directly from the PC firmware, without an operating system in between. Their reinterpretation of Zaxxon (1982) is more than just a curiosity: it's programmed entirely in x86-64 assembly language and released as open source under the GPLv3 license.

The most striking thing is not just the result, but the journey. The philosophy of the project is “back to metal”: leave behind the operating system layers, take advantage of the hardware Without intermediaries, they demonstrate that it's still possible to build a polished gaming experience where we usually only see diagnostic tools. And yes, there's an explanatory video with a long and entertaining technical overview that details how it all came about and what obstacles were encountered along the way.

UEFI as a starting point: why this experiment matters

Most playful experiments on UEFI They remain as demos, technical toys, or payloads that are loaded "within" the firmware environment. Here, however, the approach is different: the machine boots up and the first thing you see is the game, without going through an operating system or an intermediate menu. That detail makes all the difference in terms of complexity and user experience.

UEFI is the modern replacement for the old BIOS And, although it has services for entry/exit, timing and video, It is not designed to offer a sophisticated gaming experienceThis forces its authors to compensate for shortcomings with low-level engineering: from how to read controls in real time to how to draw at full speed without tearing or annoying latency.

The value of the proposal is twofold. On the one hand, demonstrates that firmware can offer more than just utilities configuration and testing. On the other hand, it serves as a practical lesson on current PC architecture, timings, and the design of minimalist graphics engines that do not depend on "luxury" libraries.

Inkbox sums it up with a powerful idea: they were tired of the operating system setting the pace and the limits. Their response was to program in assembly language, without an operating system, to get the most out of the hardware as is.It's not an anti-anything manifesto; it's a declaration of creative freedom, with the added incentive that anyone can examine the code and fork it thanks to its open license.

What is Space Game for x64 and what does it aim to achieve?

The project has a simple and descriptive name: Space Game for x64 is a Zaxxon recreation for the x86_64 platform packaged as a UEFI image. There are no emulators involved, nor a "traditional" port that depends on SDL, DirectX, or similar: it's a BOOTX64.EFI binary that loads as if it were the boot system.

This means that, once you prepare it on a disk with an EFI partition, The PC boots up and gets straight to actionThere is no desktop, no background services, no window managers or complex drivers: only the firmware, the binary and your hardware responding precisely to what the assembler asks of it.

True to the spirit of the original, The recreation preserves the isometric aesthetic and that eight-bit arcade feel. To achieve this, they've built a kind of engine that mimics a classic PPU (Picture Processing Unit), the kind that turned limitations into visual style. It's a technical nod that also facilitates a very controlled rendering pipeline.

In its public repository you will find the source code and instructions for compiling, linking and running the game on real hardware. The set is released under GPLv3so that it can be studied, modified and redistributed under the terms of a license well known in the free software community.

Technical challenges: input, timing, and offline video

Anyone who has tinkered with UEFI knows that its keyboard, clock, and graphics support is utilitarian, not "gamer". The first major obstacle was the entranceThe standard UEFI keyboard introduces an internal delay that feels clunky and imprecise for gaming. This lag disrupts the immediacy that arcades demand, so Inkbox sought another route: mouse/joystick input for a more responsive and fluid experience.

The second challenge was timing. Without an operating system that provides high-resolution programmersWith well-chewed monotonic timers and pampered thread planners, we need to invent stable mechanisms for measure latency...to align the frames and maintain the consistency of the game engine. The project video focuses on this point in detail, because nailing the timing is half the battle in gameplay.

On the graphics front, the solution involves a renderer that replicates the behavior of a retro PPU. It starts with a base buffer with low resolution (256×256)This is sufficient for the old-school console aesthetic, and from there the final image is scaled and composited. The result is crisp and uniform, with the aesthetic consistency one expects from a remake that respects the original visual identity.

Having overcome those obstacles, The final demonstration looks as smooth as silk: 128 FPSFluid animations and responsive touch controls. There is, however, one deliberate omission: no sound is implemented for now. A solid visual and gameplay experience is preferable to spreading itself too thin in the first iteration.

How to build it: compilation and linking tools

The code is written in 64-bit assembler and relies on Microsoft tools for assembly and linking. Microsoft Macro Assembler (MASM) in x64 mode is used for assembly.The linking process is handled by the Microsoft Visual C++ Linker (MSVC Linker). There's no magic involved: these are well-known tools within the ecosystem. Windows that produce a UEFI-compatible binary.

The result of the compilation is a standard UEFI executable: BOOTX64.EFIThat file is the one that should be placed in the path of Boot expected by the firmware: EFI/BOOT/, within the EFI system partition (ESP) of a disk with a GPT partition table. If you are coming from LinuxWhether you're using macOS or a modern Windows system, this structure will sound familiar.

The setup is straightforward with just a couple of requirements. Go into the firmware settings and disable Secure Boot To avoid signature locks, select the disk where you copied BOOTX64.EFI as the boot device. If everything is in place, the machine will immediately launch the game without any additional loading screens.

For those who like to experiment with different devices, there is a clear advantage: UEFI is a widely supported standard on x86_64 machinesAs long as your hardware is 64-bit and your firmware implements UEFI, you should be able to try the remake without too much trouble. It always helps to verify that the firmware allows you to disable Secure Boot.

Hardware scaling, debugging, and other options

Beyond the basics, the project adds a very interesting idea in terms of performance: a “hardware scaling” mode It leverages the other application processors (the system cores) to quickly convert the game buffer to a 1024x1024 target. It's a small tour de force of parallelization within the UEFI environment: the game draws at 256x256, and the final resolution is multiplied without penalizing the frame rate.

If you prefer simplicity or your equipment is modest, you can disable that scaling. In that case, the program dumps the 256x256 buffer onto the screen as is.Maintaining a more pixel-perfect look while reducing the computational load. Depending on your preferences, you can prioritize visual purity or extra sharpness.

For those curious to see "the guts", there are toggles designed for development. There is an option to display the hitboxes (the collision boxes) which only makes sense if hardware scaling is active, since the overlay is clearer and more manageable at higher resolutions.

A diagnostic overlay can also be activated. Debug mode dumps information into the consoleThis includes details of the control input and the render engine's column count. If you're adjusting timings, latencies, or device read accuracy, this data is invaluable for understanding what's happening in each frame.

Performance and gaming experience

What best defines this experiment is how he feels in charge. Smooth gameplay at 128 FPS And the seamless response creates a very arcade-like feel: everything happens at the exact moment, without the system overthinking. This immediacy is the result of meticulous control over the pipeline: fewer layers, less uncertainty.

Even without sound, it's a fully enjoyable game. The emphasis is on gameplay and visual clarityWith a palette, sprites, and scrolling that evoke the eight-bit era without resorting to modern filters or unnecessary post-processing. If you come for the nostalgia, you'll stay for the performance.

The issue of the entrance deserves a separate round of applause. Avoid the UEFI “standard” keyboard —due to its built-in delay— and opting for mouse/joystick not only avoids a problem, but reinforces the arcade identity of the remake. This is noticeable in the precision when adjusting trajectories and in how well the game tolerates quick corrections.

On current multicore systems, the scaling mode makes 1024x1024 display instantaneous. Distribute scaling work among cores It allows you to maintain a 128 FPS frame rate without breaking a sweat, while in simple mode the "raw" 256×256 aesthetic offers that uncompromising retro texture.

Compatibility and availability

One of the strengths of this proposal is its scope. The binary is designed to run on any x86_64 machine with UEFI, which covers a very broad spectrum of desktop PCs and portable contemporary. No specific model or brand is needed; it is enough to meet the standard and allow the EFI to start without hindrance.

If you want to tinker, the door is open. The “Space Game for x64” repository on GitHub includes code, documentation, and resources so you can compile and build your own image. Anyone already comfortable with MASM and the MSVC linker will feel right at home; and those who aren't have a perfect excuse to learn.

Licensing it under GPLv3 is not a minor detail. That choice ensures that knowledge returns to the communityAnd any derivative will maintain that same openness. For educational projects or reverse engineering labs, it's a treasure: you can read, modify, compare, and measure without proprietary restrictions.

The story behind it: motivation and lessons learned

Why get involved in such a mess? The author's motivation is as technical as it is philosophical.: to remove the operating system's constraints, to rediscover the programming At the heart of the matter, and recapturing the arcade essence of "what you see is what you get." This spirit translates into understated and effective design choices.

The video that accompanies the project is a bonus. It's not a trailer, it's a masterclass It's about how to deal with the real limitations of the firmware and how to turn them into a compelling gaming experience. Anyone who has struggled with timers, latency, and device polling will appreciate the level of detail.

There is learning everywhere: from the choice of input devices to the drawing pipeline and scaling. Replicate the behavior of a retro PPU It's not just nostalgia; it's a pragmatic decision that limits the problem, avoids external dependencies, and gives coherence to the final aesthetic.

This approach, by the way, results in a code that can be read and studied. Programming in x86-64 assembler is not common todayAnd even less so with this level of playful ambition. Precisely for this reason, the educational value of the project is enormous for anyone who truly wants to understand what the hardware does in each instruction.

Practical details for trying it on your computer

If you're curious, here's the basic route: You compile with MASM in 64 bits, you link with MSVC and you get the BOOTX64.EFI binary. You copy that file to the EFI (ESP) partition of a disk with a GPT table, respecting the path EFI/BOOT/, and prepare your firmware to boot from that device with Secure Boot disabled.

Some firmwares add their own "personality", so take note. You may need to force the boot order Or select the disk manually from a quick boot menu. Once the manufacturer's UEFI logo appears and the boot process starts, if the path is correct, you'll go directly into the game.

For performance adjustments, there's no mystery. Enable hardware scaling if you want 1024x1024 With maximum clarity and plenty of cores, disable it if you're looking for a clean 256x256 image. If you're debugging, show the hitboxes and the diagnostics panel: you'll see the recorded input and the column count the engine is handling in real time.

As a safety note: Disabling Secure Boot is a requirement for this binary.Remember to revert this change if you prefer, once you're finished playing. It's not an unusual step in home UEFI projects, but it's good to keep in mind if you work on production teams.

Beyond the game: impact and possibilities

Focusing solely on the retro nod would be unfair. This work opens a conversation about what can be done in UEFI With engineering discipline and clear objectives. Today it's a classic arcade game; tomorrow it could be an advanced graphics utility, a hardware testing environment, or interactive experiences that don't depend on installing anything on a disk.

For the educational scene, the appeal is immediate. A well-commented assembler repositoryThe document, which covers input, timing, graphics, and light parallelization within UEFI, is an exceptional learning resource. It's hard to imagine a more illuminating lab for understanding modern PC architecture without the operating system layers.

In the maker and retro community, the ripple effect is also clear. To regain full control of the pipeline It's captivating. It recaptures the DIY spirit of the '80s and brings it into a modern, standardized environment. Many will be inspired to experiment with their own mini UEFI engine based on these principles.

And for those who just want to play for a while, the proposal more than delivers. It's fast, it's clean, and it's amazing. Boot up your PC and land straight into a revamped classic without ever seeing a desktop. If you're looking for a distraction-free arcade session, it's hard to ask for more.

One idea that pervades the entire project is that of autonomy. When you control every instruction, you control the experience.You're not dependent on OS updates, task schedulers, or drivers. There are costs—no sound for now, no comfort layers—but in return you get a delightful technical toy and a manifesto of creative independence.

Among the small technical gems, the alternative input management to the clunky UEFI keyboard and the use of application processors for scaling stand out. That detail of "light" parallelization within the firmware It's a reminder that the standard offers more leeway than we usually exploit on a daily basis.

If you enjoy delving into source code and commits, you'll have a great time reviewing the project's organization, the clarity of the routines, and how edge cases are resolved. The decision to share under GPLv3 He assures that nobody keeps their ace up their sleeve: what is learned here circulates and grows with the contributions of others.

In the end, it's more than just a simple port, It's a statement of intent wrapped in pixels.It revives a way of programming and playing —without anesthesia or harnesses— that still has charm in 2025. And it does so with respect for the original and a technical execution to match, starting where no one expects to see a game: the firmware itself.

Related article:

Differences between remaster, remake, reboot, demake, and port in video games

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.