Itanium: The Great X86 Replacement That Never Was

April 21, 2026 by Julian Scheffers 29 Comments

Itanium was once meant to be the next step in computing, to compete with the likes of IBM, Sun and DEC, but also for Intel to have an architecture that couldn’t be taken from it, as the PC was from IBM by its clones. Today, however, Itanium is a relic of the past. [Asianometry] tells us the story of Itanium.

By the ’90s, servers were an established market dominated by RISC architectures and Unix-like operating systems. Intel wanted to compete in this market, due in part to worries of losing control over x86. So, when Hewlett Packard came to Intel in late ’93, Intel eventually agreed to collaborate on a new project in EPIC (Explicitly Parallel Instruction Computing).
Continue reading “Itanium: The Great X86 Replacement That Never Was” →

How One Line Of TF2 Code Ruined This Simple Feature

April 18, 2026 by Julian Scheffers 11 Comments

Ever encountered a minor annoying bug in a video game? How about one dating back to 2018? Usually, you have no hope of fixing it, but this time is different. [Joey Cheerio] shows the first-time programmer approach to (with great difficulty) fixing a bouncy ball prop turning invisible when shot in Team Fortress 2.

It starts with a band-aid solution that hides the problem: just turn off jiggle physics! While that works, it also affects many other models in the game, and doesn’t tackle the root cause. Time to investigate. Because this ball often goes overlooked, [Joey Cheerio] didn’t even realize that it was supposed to have jiggle physics, accidentally removing it. Turns out, after scouring the internet for old footage, it’s supposed to jiggle after all.

Back to square one, [Joey Cheerio] infers that the jiggle bone accidentally removed was related to the problem, eventually figuring out that the specific type of jiggle bone used (is_boing) caused the issue. Time to dig in the code. Tracking down the problem is no small feat for someone who’s never programmed before, even with the help of LLMs, but eventually, at 4 in the morning, a breakthrough! The ball no longer turned invisible but retained the intended jiggle.

At the limits of his knowledge on the subject, [Joey Cheerio] posts his partial progress so far to GitHub, where [ficool2] tracks down the real problem and turns this second band-aid into a proper fix. [Joey Cheerio] finishes up by explaining the math of what exactly went wrong.

Continue reading “How One Line Of TF2 Code Ruined This Simple Feature” →

FRED Comes To Hobby Operating Systems (and Linux)

April 17, 2026 by Julian Scheffers 13 Comments

Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.

Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.

Part of the startup log of EvalynOS — The kernel confirming that FRED has been detected and enabled

To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.

[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.

Pentium II die shot. Martijn Boer, Public domain.

FPGA Powers DIY USB Scope And Signal Generator

April 16, 2026 by Julian Scheffers 8 Comments

Oscilloscopes and to lesser extent signals generators are useful tools for analyzing, testing and diagnosing circuits but we often take for granted how they work. Luckily, [FromConceptToCircuit] is here to show us how they’re made.

[FromConceptToCircuit] starts by selecting the hardware to use: an Artix-7-based FPGA and an FT2232 USB-serial converter. RS245 in synchronous FIFO mode is selected for its high bandwidth of about 400 Mbps. Then, they show how to wire it all up to your FPGA of choice. Now it’s time for the implementation; they go over how the FT2232 interfaces with the FPGA, going through the Verilog code step-by-step to show how the FPGA makes use of the link, building up from the basic transmission logic all the way up to a simple framed protocol with CRC8-based error detection. With all that, the FPGA can now send captured samples to the PC over USB.

Now it’s PC-side time! [FromConceptToCircuit] first explains the physical pipeline through which the samples reach the PC: FPGA captures, transmits over RS245, FT2232 interfaces that with USB and finally, the software talks with the FT2232 over USB to get the data back out. The software starts by configuring the FT2232 into RS245 mode, sets buffer sizes, the whole deal. With everything set up, [FromConceptToCircuit] explains how to use the FT2232 driver’s API for non-blocking communication.

As a bonus, [FromConceptToCircuit] adds a signal generator feature to the oscilloscope using an I2C DAC chip. They start by explaining what exactly the DAC does and follow up with how it’ll be integrated into the existing system. Then it’s time to explain how to implement the I2C protocol bit-for-bit. Finally combine everything together for one final demo that shows a sine wave on the DAC’s output.

Python Comes To The Arduino Uno Q

April 15, 2026 by Julian Scheffers 14 Comments

MicroPython is a well-known and easy-to-use way to program microcontrollers in Python. If you’re using an Arduino Uno Q, though, you’re stuck without it. [Natasha] saves the day by bringing us a a subset reimplementation of machine for the Arduino Uno Q.

In the past, microcontrollers were primarily programmed in C, but since MicroPython’s popularity increased over the years, it has become more and more common for introductory microcontroller programming to be in Python. Python, of course, is generally considered more beginner-friendly than C. [Natasha] presumably wanted to teach this way using an Uno Q, but the usual MicroPython APIs weren’t available. And so, in true hacker fashion, they simply made their own library to implement the most important bits of the familiar API. It currently implements a subset of the machine module: Pin, PWM, ADC, I2C, SPI and UART. While not complete, this certainly has potential to make the Uno Q easier to use for those familir with MicroPython.

It looks like osu!, but it's actually Trombone Champ

Implementing A Rhythm Game Entirely In A GPU Shader

April 10, 2026 by Julian Scheffers 21 Comments

Most rhythm games have a community creating custom charts, and Trombone Champ is no exception. What is exceptional, however, [CraftedCart]’s osu! played in a Trombone Champ chart.

It all started as a challenge to make the most unserious chart possible. Among some other ideas, [CraftedCart] eventually decides to make an osu! chart but play it in Trombone Champ. Okay, not a problem, let’s just–oh, you can’t run arbitrary code without a making a mod. So instead, they decided to use shaders on the GPU. There are, of course, all sorts of problems with such an idea. Being stuck in the fixed render pipeline of a game, you can’t just add any resources to your shader you want. This leads to using textures as memory, both the game state and the osu! chart are actually textures. Another interesting one is getting user input into the shader. [CraftedCart] solves that by connecting the position of the game object the background is rendered to to the cursor; then, the shader reads the world to local transform matrix to determine the mouse position. Finally, the graphics the player ends up seeing are rendered using ray marching.

Video after the break.
Continue reading “Implementing A Rhythm Game Entirely In A GPU Shader” →

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.