MicroPython Is This Summer’s Hottest Title For The SNES, Thanks To Claude Fable

July 11, 2026 by Tyler August 8 Comments

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.

To Build More Believable Bots, Simulate The Neurochemistry

July 11, 2026 by Donald Papp 7 Comments

Giving machines the ability to communicate nonverbally has real value, and [Drew Smith] clearly thinks your robot deserves better than an emoji. He shared a very interesting approach with his project Kindalive.

Kindalive is a simulated dot-matrix robot face that responds believably to input text, modeling and expressing both short-term and long-term moods. It’s pure Python and modular enough to invite using it elsewhere, but that’s not the really interesting part.

What sets [Drew]’s project apart is the way he models eight key neurochemicals (including dopamine and cortisol) as the foundation from which to derive emotional states. That’s an approach we certainly haven’t seen before.

Conventional sentiment analysis uses a large language model (LLM) to apply discrete labels to communication, but Kindalive doesn’t do that. It even goes so far as to model the decay and interplay between its simulated neurochemicals to derive emotional states on the fly. It’s more fluid and organic, and reflects both short-term and long-term mood changes.

Physical representation of the emotional mix is done by altering twelve key facial movements (brow raise, lip corner pull, mouth open, and others of that nature) known as the Facial Action Coding System (FACS). These twelve elements combine to express emotion nonverbally with facial expressions. It’s what drives the simulated dot-matrix robot face seen in the image above, and could easily be used to drive a real LED matrix, or servos on an animatronic face.

Much of communication is nonverbal. Humans even weigh nonverbal higher when there’s a mismatch between the content of verbal and nonverbal communication. So, there’s clear value in having robots able to express themselves as such.

Importantly, a realistic and human-like face is entirely unnecessary — something every Star Wars fan already knows. Cartoon eyes and basic sounds are enough to make robots easier to relate to and work with, even if blinking is also important but hard to get just right.

When Changing Scale Isn’t Just More Of The Same

July 11, 2026 by Elliot Williams 20 Comments

[Jenny] and I were talking about [Bitluni]’s experiment in scale, where he will take 65,536 cheap microcontrollers, network them all together, and give each one an RGB pixel. From there, antics will surely ensue. Right now, he’s only got 8,192 of them up and running, and already the novel problems and opportunities are rearing their heads.

We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.

Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.

On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.

So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.

A clay vase sits in the center of a circular table, with an extruder in contact with the top surface. The extruder has a tube containing clay on the right side, with a motor mounted above an auger over the main nozzle.

Clay Extruder Enables Printable Pottery

July 11, 2026 by Aaron Beckendorf 33 Comments

Ceramic 3D printers, despite using the same fundamental mechanism as standard FDM printers, are much harder to find. Part of this comes down to the material properties of fired ceramics versus thermoplastics, but they’re also significantly harder to build; for example, in his ceramic printer build, [Joshua Bird] had to deal with severe material shrinkage, collapsing bridges, and the surprisingly abrasive effects of clay.

The centerpiece of the printer is the clay extruder: an air compressor pushes clay along a tube into the extruder, which uses an auger to squeeze the clay through the nozzle, while a gap at the top lets trapped air escape. The extruder has enough control for successful retractions, but rheology remained a challenge: the clay needed to be soft enough to flow through the nozzle, but stiff enough to form bridges without collapsing. [Joshua] thus pressurized the clay as much as possible, making it possible to use stiffer clay mixtures. The extruder’s greatest challenge was longevity: [Joshua] tried many 3D-printed plastic augers, but the clay abraded them all much too quickly, often in under an hour of use; a 3D-printed stainless steel extruder solved this.

Printing in ceramic isn’t a simple process: for each part, [Joshua] had to mix the clay, load it into the tube, clean the extruder, actually print the object, let it dry, fire it, apply glaze, and fire it again. The clay’s shrinkage during drying and firing destroyed many prints, but [Joshua] was nevertheless able to print a double-walled cup, a decorative climbing-themed cup, and even a chain-mail mesh.

The 3D printer’s motion system is a polar design, an adaptation of his earlier non-planar 3D printer, which might eventually make it easier to print overhangs. We’ve previously seen a similar auger-based clay extruder, an approach reminiscent of direct-granule FDM printing.

A Look Inside A 1997 BBC Ceefax Generator

July 11, 2026 by Maya Posch 21 Comments

Ceefax was the BBC’s broadcast teletext service that ran until 2012, providing text and rudimentary graphics that were broadcast invisibly with the TV signal. In order to get this teletext data merged into the analog TV signal, special equipment was needed, of which [Nathan Dane] has a 1997-era unit on his bench to take a gander at.

Interestingly, until this time the Ceefax signal had been generated centrally in London, meaning that regional TV broadcasts might have Ceefax issues on occasion due to retransmission glitches. This makes this Ceefax Inserter system so much more interesting, as it was one of the early examples of what these regional stations would end up installing in their racks.

At their core these units are regular PCs, running MS-DOS 6.22 on a 486-class CPU and all the typical bits and bobs that go with a PC. The speculation here is that these are essentially rebranded industrial PCs, which would make a lot of sense. As for how [Nathan] got his hands on these units, it required a deal with the company scrapping them, preventing him from showing details of the software configuration.

Following a booting demonstration, we get the teardown of a typical 1990s rackmount PC, revealing a rather interesting backplane with the mainboard being one of the cards on it. Of these, two ISA cards provide the special Ceefax sauce as well as a timing signal in the form of a PDC card featuring a Lattice CPLD or FPGA that VCRs could use to automatically start recording.

The Ceefax main event comes in the form of the inSERT Teletext Encoder card. This is pretty much its own computer system, featuring a TI TMS34010 CPU and its own RAM as well as IO. Compared to modern takes on teletext generators, this card appears to directly mix the analog signals, without any kind of conversion.

Although teletext systems have been largely shutdown now at this point due to the transition to digital TV broadcasting, there’s still a lot to be said for having such a service available for basic news and information.

Continue reading “A Look Inside A 1997 BBC Ceefax Generator” →

Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture

July 10, 2026 by Maya Posch 5 Comments

After previously fixing an overly bright picture from a Voodoo graphics card with a simple resistor on one of the RAMDAC’s pins to correct its faulty internal Vref, [Bits und Bolts] got called out for not taking component drift into account. Thus in an update video he shows how instead to use an adjustable AMS1117 voltage regulator to hopefully prevent either the original issue or something new and exciting from cropping up later.

The basic idea here is to use the external voltage reference (Vref) pin for this ICS5342 RAMDAC and supply it with a constant 1.235V. If unused – as on this Orchid-branded Voodoo card – it is connected via an 0.1 microFarad capacitor to ground. This fortunately means that the pin is routed to easily accessible pads that make this modification relatively straightforward.

Basically this is where the AMS1117-ADJ chip comes into the picture, as a widely available adjustable LDO option, even if the 0.8A current rating is very much overkill for this application. With the supplied voltage the lowest voltage this LDO can output is around 1.25V, which is within the 1.10 – 1.35 V range of the datasheet.

Of course, with the PCB never having had a provision for this part, much of the rest of the video is about planning out where to place and route the components. After that tedious work and testing that nothing explodes, the new voltage is used for the RAMDAC’s Vref pin, fixing the brightness issue.

While one could argue that this RAMDAC is likely simply defective and already beginning to break down inside, this should at least give it a bit longer on what seems to be a little used card anyway.

Continue reading “Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture” →

Reject Modernity, Return To 80s, Learn C.

July 10, 2026 by Tyler August 88 Comments

We’re not exactly sure how old [SnailMail] is, but he’s probably a member of Generation Alpha considering that to our wizened eyes the lad looks only slightly older than a fetus– which makes it all the more impressive that he’s written his own text editor, from scratch, in C– on a 386. See, [SnailMail] tried to learn the modern way, with IDEs that have code completion and AI integration, but his thoughts couldn’t gel in the modern environment. So he went online and bought an old IBM-compatible complete with monochrome amber monitor, and a whole 4MB of RAM. Big spender that he is, [SnailMail] upgraded that to 8MB.

Rather than fall victim to the siren song of Wolfenstien 3D or SimCity, he set out to learn to code: C, specifically, since that language bridges four decades between [SnailMail] and his new PC. Even more specifically, he got ahold of disks for Borland Turbo C and Turbo C++, which brings back memories for some of us. Of course the lad also had to learn how to use a DOS PC at the same time, but a teen in the 80s with a fresh box would have climbed the same steep learning curve. Some of you probably remember doing so yourselves. Just like you–or the hypothetical teen in the 80s–[SnailMail] did it not by googling or begging Claude for answers, but by digging into books. Many books.

After all the reading, he started with a text editor, something we remember being a pretty big project not given to first year students. Video evidence suggests he pulled it off. He describes how his solution works from about 8:00 in the video, so you greybeards in the audience can judge his work for yourself.

If you’re a member of Gen Alpha reading this and looking to learn to program, we cannot recommend this technique highly enough– [SnailMail] is going to have a better understanding of the underlying logic of computer science than a lot of CS grads being frocked today. Especially when you consider he ends by promising to learn assembly, something we heartily endorse.

Continue reading “Reject Modernity, Return To 80s, Learn C.” →