Author: Julian Scheffers

54 Articles

Python Comes To The Arduino Uno Q

April 15, 2026 by 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 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 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 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 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 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 12 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.