Running DOOM On…a TrueType Font?

April 10, 2026 by Julian Scheffers 38 Comments

Over the years, DOOM has been ported to many things; think of any arbitrary device and chances are it can run the classic shooter. But what about something more esoteric like [Artem]’s DOOM in a TrueType font?

Okay, it’s not technically a port of DOOM, but it’s still very cool. TrueType actually has a bytecode used for hints to the render and, while not made for this, it’s just complete enough for this demo to run. Either to increase the over-engineering, or just to make it all a bit easier, [Artem] makes a simple DSL and a matching compiler written in Python.

All of this allows the byte code intended to implement serifs run arbitrary code, in this case, ray casting the walls for a DOOM demo. The final bytecode is 6,580 in size and, assuming your font renderer implements this, is very playable.

While this project’s implementation of the game is a bit abstract, the version of DOOM that you can run over DNS is the real deal.

A stick of DDR4 in DIMM format held by some alligator clips

Dodging A 60-Year-Old Design Flaw In Your RAM

April 8, 2026 by Julian Scheffers 41 Comments

Modern computers use dynamic RAM, a technology that allows very compact bits in return for having to refresh for about 400 nanoseconds every 3-4 microseconds. But what if you couldn’t afford even such a tiny holdup? [LaurieWired] goes into excruciating detail about how to avoid this delay.

But first, why do we care? It once again comes down to high-frequency trading; a couple nanoseconds of latency can be the difference between winning or losing a buy order. You likely miss all the caches and need to fetch data from the remote land of main memory. And if you get unlucky, you’ll be waiting on that price for a precious 400+ nanoseconds! [Laurie] explains all the problems faced in trying to avoid this penalty; you try to get a copy of the data on two independent refresh timers. That’s easier said than done; not only does the operating system hide the physical addresses from you, but the memory controllers themselves also scramble the addresses to the underlying RAM!

For the real computer architecture nerds, there’s a lot more to it, and [Laurie] goes over it in meticulous detail in the video after the break.
Continue reading “Dodging A 60-Year-Old Design Flaw In Your RAM” →

A prototype VLIW computer made by Multiflow

A History On The “Impossible” VLIW Computing

April 7, 2026 by Julian Scheffers 14 Comments

A computer does one thing at a time, even if it feels like it’s doing multiple things at once. In reality, it’s just switching between tasks very quickly. But a VLIW (Very Long Instruction Word) computer is different. Today, [Asianometry] tells us about VLIW computing and its history.

Processors have multiple functional units; for example, you might have separate units each for addition, multiplication and division. But because it runs one instruction at a time, these units tend to spend a large amount of time idle. VLIW aims to address this inefficiency by reinventing what an instruction means. Instead of telling the whole processor what to do, a VLIW instruction tells each functional unit what to do at once. Sounds good, right? Well, that was the easy part.

The hard part? How to compile a program for a VLIW computer, that can actually make use of all the functional units at once; after all, the efficiency promise is that the higher activity makes up for larger instruction words to fetch. That is the compiler’s job; VLIW compilers try to reschedule the operations in the program to convert sequential code into more parallel operations then compiled into the titular very long instruction words.

[Asianometry] goes into detail about this, the history, and more in the video after the break.
Continue reading “A History On The “Impossible” VLIW Computing” →

A mechanical keyboard, transformed to look like a retro laptop with an ipad for a screen

Modular Mechanical Keyboard Transformed Into A Compact Workstation

April 6, 2026 by Julian Scheffers 1 Comment

3D printing is a staple of the hacker community. From decorative items to rugged functional parts, almost anything you can think of, can be printed. [anurag.id] shows us some classic 3D printing hacks by converting his keyboard into a compact workstation.

Like any hacker project, the initial idea is small: he decides the knob on his mechanical keyboard is boring, so he designs some alternatives. First, one “retro style” knob. Then, like any good project, the scope creep begins. He makes another knob, and another… by the end he has 6 different designs! But don’t worry, the scope can get even bigger. He decides his ipad needs a good stand on his desk–and what better place to put it than on the keyboard? Now it’s starting to look like a real little workstation. Finally, as a finishing touch, he adds some magnetically-attached wrist rests for a compact, ergonomic workstation.

Video after the break.
Continue reading “Modular Mechanical Keyboard Transformed Into A Compact Workstation” →

A jar of pine cones that appears to glow like the embers of a fire

Simulating A Glowing Fireplace With An RP2040

April 3, 2026 by Julian Scheffers 11 Comments

Today, fireplaces, their cozy glow once a household staple, are mostly a thing of the past. In fact, a decent amount of old fireplaces are completely blocked up! [David Capper] brings back the atmosphere without the actual flames, with his RP2040-based fireplace glow simulator.

It’s not just a string of LEDs with some PWM brightness control, either. No, [David] goes into detail about the black body radiation that gives these fires their colors. He then uses the theory of black-body radiation to determine the colors that the LEDs glow to simulate the colors of a real fire.

But the colors alone don’t make for a good simulated fire, so [David] adds the heat equation. It starts with a grid wherein each cell has a temperature. Over time, cells are randomly selected to have heat added to them (increasing the cell’s temperature), then he applies the heat equation to diffuse and decay the heat within the grid for a nice simulated crackling fire. Add in a custom PCB and a nice little 3D-printed case and you’re ready for a cozy hacker time.

WheatForce: Learning From CPU Architecture Mistakes

April 1, 2026 by Julian Scheffers 21 Comments

Nothing ever made is truly perfect and indeed, CPU architectures like x86, RISC-V, ARM, and PowerPC all have their own upsides and downsides. Today, I aim to make an architecture that learns from all these mistakes and improves architecture design for everyone.

I’ve consulted with many people opinionated on the matter, both from a software perspective, and from a hardware perspective. I have taken all their feedback in mind while creating this initial draft of the WheatForce architecture (PDF). It is inspired by pieces from many architectures: segmentation inspired by x86, hash table-like paging from PowerPC, dynamic endianness control from RISC-V and PowerPC, and more. Let’s look into each feature in a little bit more detail. Continue reading “WheatForce: Learning From CPU Architecture Mistakes” →

A hex dump of the first iteration of the small ELF file

How Small Can A Linux Executable Be?

March 31, 2026 by Julian Scheffers 39 Comments

With ever increasing sizes of various programs (video games being notorious for this), the question of size optimization comes up more and more often. [Nathan Otterness] shows us how it’s done by minifying a Linux “Hello, World!” program to the extreme.

A naive attempt at a minimal hello world in C might land you somewhere about 12-15Kb, but [Nathan] can do much better. He starts by writing everything in assembly, using Linux system calls. This initial version without optimization is 383 bytes. The first major thing to go is the section headers; they are not needed to actually run the program. Now he’s down to 173 bytes. And this is without any shenanigans!

A hexdump of the final ELF file, significantly smaller than the original — The final tiny ELF file

The first shenanigans are extreme code size optimizations: by selecting instructions carefully (and in a way a C compiler never would), he shaves another 16 bytes off. But the real shenanigans begin when he starts looking for spaces in the ELF header that he can clobber while the program is still accepted by Linux: now he can move his already tiny x86_64 code into these “vacant” spaces in the ELF and program headers for a final tiny ELF file weighing in at just 120 bytes.

P.S.: We know it is possible to make this smaller, but leave this as an exercise to the viewer.