A New Golden Age Of Browser Games

October 17, 2025 by Bryan Cockfield 17 Comments

Arguably, the golden age of browser gaming occurred in the 00s mostly revolving around Adobe Flash. This was an era with high creativity and a low barrier of entry, and also decentralized from gatekeeping app stores. Sadly, these times have passed us by as the security concerns around Flash led to its discontinuation and most casual gamers have migrated to the app store for their fix. But that doesn’t stop some from continuing to bring gaming to the browser, even if those games were never intended for it in the first place like this browser port of Celeste.

Celeste is an indie platformer where the player climbs a mysterious mountain while confronting her inner struggles. Originally meant for consoles and PC, a group of friends including [velzie], [bomberfish], and [Toshit] aka [r58Playz] took this as a challenge especially after seeing someone else’s half finished web port of this game. Most of the build revolves around WebAssembly (wasm) and around “cursed” .NET runtime hacks which also allow the port to run the community-made Everest mod loader. It uses a multithreaded and JIT compiling version of mono-wasm backported from .NET 10 to .NET 9 to maximize performance. The team actually first started by porting Terraria to the browser, and then moved on to this Celeste port from there.

The port of Celeste can be played here, and their port of Terraria is also available, although may not support a ton of Hackaday traffic so some patience is advised. There are also GitHub repositories for Celeste and Terraria as well. With impressive ports of relatively modern games moving into the browser, perhaps we’re entering a new golden age of browser gaming; we’ve also seen things like Minecraft implemented in only HTML and CSS lately as well.

Factorio Running On Mobile

October 15, 2025 by Bryan Cockfield 27 Comments

As a video game, DOOM has achieved cult status not just for its legendary gameplay and milestone developments but also because it’s the piece of software that’s likely been ported to the most number of platforms. Almost everything with a processor can run the 1993 shooter, but as it ages, this becomes less of a challenge. More modern games are starting to move into this position, and Factorio may be taking a leading position. [Point Substantial] has gotten this game to run on a mobile phone.

The minimum system requirements for Factorio are enough to make this a challenge, especially compared to vintage title like DOOM. For Linux systems a dual-core processor and 8 GB of memory are needed, as well as something with at least 1 GB of VRAM. [Point_Substantial]’s Xiaomi Mi 9T almost meets these official minimum requirements, with the notable exception of RAM. This problem was solved by adding 6 GB of swap space to make up for the difference.

The real key to getting this running is that this phone doesn’t run Android, it runs the Linux-only postmarketOS. Since it’s a full-fledged Linux distribution rather than Android, it can run any software any other Linux computer can, including Steam. And it can also easily handle inputs for periphreals including a Switch Pro controller, which is important because this game doesn’t have touch inputs programmed natively.

The other tool that [Point_Substantial] needed was box86/box64, a translation layer to run x86 code on ARM. But with all the pieces in place it’s quite possible to run plenty of games semi-natively on a system like this. In fact, we’d argue it’s a shame that more phones don’t have support for Linux distributions like postmarketOS based on the latest news about Android.

Thanks to [Keith] for the tip!

Macintosh System 7 Ported To X86 With LLM Help

September 29, 2025 by Lewin Day 50 Comments

You can use large language models for all sorts of things these days, from writing terrible college papers to bungling legal cases. Or, you can employ them to more interesting ends, such as porting Macintosh System 7 to the x86 architecture, like [Kelsi Davis] did.

When Apple created the Macintosh lineup in the 1980s, it based the computer around Motorola’s 68K CPU architecture. These 16-bit/32-bit CPUs were plenty capable for the time, but the platform ultimately didn’t have the same expansive future as Intel’s illustrious x86 architecture that underpinned rival IBM-compatible machines.

[Kelsi Davis] decided to port the Macintosh System 7 OS to run on native x86 hardware, which would be challenging enough with full access to the source code. However, she instead performed this task by analyzing and reverse engineering the System 7 binaries with the aid of Ghidra and a large language model. Soon enough, she had the classic System 7 desktop running on QEMU with a fully-functional Finder and the GUI working as expected. [Kelsi] credits the LLM with helping her achieve this feat in just three days, versus what she would expect to be a multi-year effort if working unassisted.

Files are on GitHub for the curious. We love a good port around these parts; we particularly enjoyed these efforts to recreate Portal on the N64. If you’re doing your own advanced tinkering with Macintosh software from yesteryear, don’t hesitate to let us know.

Another Doom Port To The Atari ST

May 29, 2025 by Lewin Day 7 Comments

Last week, we examined a Doom port for the venerable Atari ST. As is so often the way with this thing, one netted another, and [Steve] wrote in to inform us about a different version under the name DOOM8088ST.

The port is so named because it’s based on Doom8088, which was originally written for DOS machines running Intel 8088 or 286 CPUs. Both ports are the work of [FrenkelS], and aims to bring the Doom experience into the far more resource constrained environment of the Atari ST. There is only very limited sound, no saving, and it only supports Doom 1 Episode 1. Still, it’s quite recognizable as Doom!

Doom8088ST is tunable to various levels of performance, depending on what you’re running it on. Low mode (30 x 128) is suitable for stock Atari ST machines running at 8 MHz. It’s described as having “excellent” framerate and is very playable. If you’ve got an upgraded ST or Mega STe, you can try Medium (60 x 128), which has greatly improved visuals but is a lot heavier to run.

Files are on Github for those interested to run or tinker with the code. Don’t forget to check out the other port we featured last week, either, in the form of STDOOM. Video after the break.

Continue reading “Another Doom Port To The Atari ST” →

Command And Conquer Ported To The Pi Pico 2

April 6, 2025 by Tom Nardi 9 Comments

A couple of months back, Electronic Arts did something uncharacteristically benevolent and released several of the old Command and Conquer games under the GPLv3. Logically, we knew that opened the doors up to the games being ported to new operating systems and architectures, but we admit that it was still a little surprising to see Command and Conquer: Red Alert running on the Raspberry Pi Pico 2.

[Charlie Birks] documented the process of getting the 1996 game up and running on the microcontroller in a series of Mastodon posts spanning a few days in March. Seeing the incremental progress made each day makes for interesting reading, as he moves from the game just barely starting up to being able to complete missions and eventually even get multiplayer going between two Picos.

As [Charlie] clarifies, he’s technically using the Pimoroni Pico Plus 2 W, which takes the RP2350B from the official Pico 2, adds 8 MB of PSRAM, and bumps the onboard flash to 16 MB. The upgraded specs and an SD card are required to get the game running, as content that would have originally been held in RAM on the computer must instead be pulled from flash.

For an even more streamlined experience, he eventually slaps the Pico Plus 2 W into the Pimoroni Pico VGA Demo Base — which provided not only an integrated SD card slot, but (as the name implies) VGA output.

It’s still early days, but [Charlie] has been pushing all of his code changes into his fork of Red Alert on GitHub for anyone who wants to play along at home. If you get his fork compiled and running on your own Pico, we’d love to hear about it in the comments.

Smallest USB Device… So Far

January 20, 2025 by Bryan Cockfield 37 Comments

For better or worse it seems to be human nature to compete with one another, as individuals or teams, rather than experience contentedness while moving to the woods and admiring nature Thoreau-style. On the plus side, competition often results in benefits for all of us, driving down costs for everything from agriculture to medical care to technology. Although perhaps a niche area of competition, the realm of “smallest USB device” seems to have a new champion: this PCB built by [Emma] that’s barely larger than the USB connector pads themselves.

With one side hosting the pads to make contact with a standard USB type-A connector, the other side’s real estate is taken up by a tiny STM32 microcontroller, four phototransistors that can arm or disarm the microcontroller, and a tiny voltage regulator that drops the 5V provided by the USB port to the 3.3V the STM32 needs to operate. This is an impressive amount of computing power for less than three millimeters of vertical space, and can operate as a HID device with a wide variety of possible use cases.

Perhaps the most obvious thing to do with a device like this would be to build a more stealthy version of this handy tool to manage micromanagers, but there are certainly other tasks that a tiny HID can be put to use towards. And, as far as the smallest USB device competition goes, we’d also note that USB-A is not the smallest connector available and, therefore, the competition still has some potential if someone can figure out how to do something similar with an even smaller USB connector.

Thanks to [JohnU] for the tip!

You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t

January 20, 2025 by Lewin Day 23 Comments

DOOM used to primarily run on x86 PCs. It later got ported to a bunch of consoles with middling success, and then everything under the sun, from random embedded systems to PDFs. Now, thanks to [Wojciech Graj], you can even play it in Microsoft Word.

To run DOOM inside Microsoft Word, you must enable VBA macros, and ignore security warnings, to boot. You’ll need a modern version of Word, and it will only work on Windows on an x64 CPU. As you might imagine, too, the *.DOCM file is not exactly lightweight. It comes in at 6.6 MB, no surprise given it contains an entire FPS. It carries inside it a library called doomgeneric_docm.dll and the whole doom1.wad data file. Once the file is opened, a macro then extracts all the game data and executes it.

If you think that Microsoft Word doesn’t really have a way of displaying live game graphics, you’d be correct. Instead, that DLL is creating a bitmap image of the game state for every frame, which is then displayed inside Word itself. It uses the GetAsyncKeyState function to grab inputs from the arrow keys, number keys, and CTRL and space so the player can move around. It certainly sounds convoluted, but it actually runs pretty smoothly given all the fuss.

While this obviously works, you shouldn’t get in the habit of executing random code in your word processor. It’s just not proper, you see, like elbows on the dinner table! And, you know. It’s insecure. So don’t do that.

Continue reading “You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t” →