Like the rest of us, 8-bit hardware is not getting any newer, and failed ROMs are just a fact of life. Of course you can’t call up Commadore corporation for replacement parts anymore, so something is needed. [Peirs Rocks] wasn’t satisfied with the existing options, so he came up with the Software Defined Retro ROM to serve as a drop-in replacement for 2364, 2332, and 2316 ROM chips.

Physically, the Software Defined Retro ROM is a PCB that matches the footprint of the original ROM chip, and holds an STM32F4 family microcontroller with a number of extra pins facing upwards. Some of those pins are for programming, so you can flash the board in-situ without removing it from the system using a Pi Pico. The others pins are jumpers for image selection or chip configuration. Depending which STM32 you use, you can have upto 16 ROM images on the board, at whatever chip select behaviour you require. The ROM’s chip select lines could be configured at the factory to answer to HIGH or LOW, and this board can handle either with a jumper swap.

The documentation on the GitHub is very well done, for which we applaud [Piers]. Instructions and demos are also available in the video embedded below. We could certainly see this hack becoming popular in the retrocomputer community, especially as everything ages and memories continue to, uh, y’know. What were we talking about, again?

Oh, right, ROMs. You might think an mask ROM would last a very long time, but it’s been a very long time since some of these were made. Best to dump them while you still can. If the chip is really far gone electrically, you might try decoding a photograph of the die.

Sometimes a write-up of a piece of retrocomputing hardware goes way beyond the hardware itself and into the industry that spawned it, and thus it is with [OldVCR]’s resurrection of a Blasto arcade board from 1978. It charts the history of Gremlin Industries, a largely forgotten American pioneer in the world of arcade games, and though it’s a long read it’s well worth it.

The board itself uses an Intel 8080, and is fairly typical of microcomputer systems from the late 1970s. Wiring it up requires a bit of detective work, particularly around triggering the 8080’s reset, but eventually it’s up and playing with a pair of Atari joysticks. The 8080 is a CPU we rarely see here.

The history of the company is fascinating, well researched, and entertaining. What started as an electronics business moved into wall games, early coin-op electronic games, and thence into the arcade segment with an 8080 based system that’s the precursor of the one here. They even released a rather impressive computer system based on the same hardware, but since it was built into a full-sized desk it didn’t sell well. For those of us new to Gremlin Industries the surprise comes at the end, they were bought by Sega and became that company’s American operation. In that sense they never went away, as their successor is very much still with us. Meanwhile if you have an interest in the 8080, we have been there for you.

If you’re a regular GitHub user you’ll be familiar with the website’s graphical calendar display of activity as a grid. For some of you it will show a hive of activity, while for others it will be a bit spotty. If you’re proud of your graph though, you’ll want to show it off to the world, and that’s where [HarryHighPants]’ Git Contributions E-Ink Display comes in. It’s a small desktop appliance with a persistent display, that shows the current version of your GitHub graph.

At its heart is an all-in-one board with the display and an ESP32 on the back, with a small Li-Po cell. It’s all put in a smart 3D printed case. The software is the real trick, with a handy web interface from which you can configure your GitHub details.

It’s a simple enough project, but it joins a growing collection which use an ESP32 as a static information display. The chip is capable of more though, as shown by this much more configurable device.

It’s always clock time at Hackaday, and this time we have an interesting hack of a clock by [danjovic]– the CIS4, a Cistercian digital clock.

The Cistertians, in case you weren’t paying close attention to European holy orders during the 13th to 15th centuries were the group of monks you’d most likely have found us in. They were the hackers of the middle ages, establishing monestaries across western Europe that were chock full of hacks– including their own numeral system. Cistercian numerals were much more efficient (in spaces and penstrokes) than the Roman numerals they replaced, and even the “Arabic” numerals that replaced them. A single glyph could record anything from 1 to 9,999. (The Europeans hadn’t yet cottoned on to zero.)

Depending how you wanted to count time, a single glyph could be used; it looks like [danjovic] is using the thousands and hundreds portions of the glyph for hours and the tens and ones for minutes. This is all accomplished with a 4×4 neopixel matrix, run by an Attiny85 Digispark with a DS3231 RTC module keeping time. A slight simplification is required to reduce the glyphs to 4×4, but we don’t think the monks would mind. For those of us who don’t wear tonsures, an easy read mode scrolls the time in Arabic numerals. (Which still aren’t super easy,with only 4×4 LEDs to display them. See the demo video embedded below and try and guess the time.)

One nice quality of life feature is an LDR for ambient light detection, to automatically adjust the neopixels’ brightness. The hackiest part, which we thought was really clever, is the enclosure: it’s a cheap LED ceiling light. This provides a diffuser, housing and mounting hardware with decent design for no effort. A 3D-printed mask sits between the diffuser and the LEDs and doubles as a PCB holder. All very elegant.

[danjovic] did include a buzzer in the design, but does say if its been programed to sound off for matins, nones and vespers. In any case, at least it’s easier to read than his binary-coded-octal clock that we featured a few years back. This isn’t our first look at this number system,so evidently people can read them with practice.

Have you made or seen a cool clock? Send us a tip. We always have time for clocks.

Gaming on a Nintendo DS can bring back great memories of long car trips from the past. But looking back, we remember wishing to play more than the DS could ever hope to handle. [fami] looks into the SuperCard DSTWO in her recent video, a solution to our past sorrows.

Able to play anything from the very games designed for the DS to emulated PS1 games, the DSTWO is more than capable of surpassing the abilities of the DS itself. More impressively, all games are run directly from the cartridge itself rather than on the DS’s hardware. While this emulated console within a handheld is impressive, it is far from simple to get running.

The DSTWO runs with an Ingenic JZ4732 as the CPU, completely different from any native architecture of the DS. Pair this with the unhelpful SDK made for the cartridge, and the aging hardware is held together by the community development behind any improvements. This is aided by the CPU similarities of another widely modded game console, the Dingoo A320.

When not having a fit, and after going through hours of troubleshooting, you might find the DSTWO running a game of SimCity 2000 or even Spyro the Dragon inside a DS. Even with the difficulties of use, the fact that these games run at all is impressive. If you want to try the DSTWO emulation yourself, check out the forums.

This is far from the only example of extreme care going into emulation. Here at Hackaday, we have covered similarly impressive projects such as this completely DIY handheld made for any retro game emulation you throw at it.

Thanks to DjBiohazard for the tip!

EFI from cables is something every ham loves to hate. What if you modulated, that, though, using an ordinary cable as an antenna? If you used something ubiquitous like a video cable, you might have a very interesting exploit– which is exactly what [Xieyang Sun] and their colleagues have done with TEMPEST-LoRa, a technique to encode LoRa packets into video files.

The concept is pretty simple: a specially-constructed video file contains information to be broadcast via LoRa– the graphics card and the video cable serve as the Tx, and the Rx is any LoRa module. Either VGA or HDMI cables can be used, though the images to create the LoRa signal are obviously going to differ in each case. The only restriction is that the display resolution must be 1080×1920@60Hz, and the video has to play fullscreen. Fullscreen video might make this technique easy to spot if used in an exploit, but on the other hand, the display does not have to be turned on at the time of transmission. If employed by blackhats, one imagines syncing this to power management so the video plays whenever the screen blanks. 

According to the pre-print, a maximum transmission distance of 81.7m was achieved, and at 21.6 kbps. That’s not blazing fast, sure, but transmission out of a totally air-gapped machine even at dialup speeds is impressive. Code is on the GitHub under an MIT license, though [Xieyang Sun] and the team are white hats, so they point out that it’s provided for academic use. There is a demo video, but as it is on bilbili we don’t have an easy way to embed it. The work has been accepted to the ACM Conference on Computer and Communications Security (2025), so if you’re at the event in Taiwan be sure to check it out. 

We’ve seen similar hacks before, like this one that uses an ethernet cable as an antenna. Getting away from RF, others have used fan noise, or even the once-ubiquitous HDD light. (And here we thought casemakers were just cheaping out when they left those off– no, it’s security!)

Thanks to [Xieyang Sun] for the tip! We’ll be checking the tips line for word from you, just as soon as we finish wrapping ferrites around all our cables.

[Ryan] of [Fat Lip Collective] has been on a streak of using 3D printing for his car mod projects. From spark plug adapters to exhaust pipes to dash panels, his CAD skills and additive manufacturing tech have played a number of roles in his process.

Most recently, [Ryan] has embarked on a mission to equip an ’80s-era Toyota KE70 Corolla with a turbo engine. The main question there being how to fit the engine back into the car once he’s inserted a salvaged turbo into the exhaust line.

There is a non-trivial amount of stuff that needs to be packed in with the rest of the engine and finding a working configuration that doesn’t get in the way of anything else requires some trial and error. Furthermore, the alignment of the many twisting and turning pieces of schedule 40 pipe that will direct gasses where they need to go needs to be pretty precise.

Juggling all of this would be tedious, time consuming, and error prone if it were not for [Ryan’s] mighty 3D printer. He printed a set of the different elbows and reducers modeled on the schedule 40 pipe that he would likely be using. He added degree markers for easy reference later and flat sections at the ends of each piece so they could be bolted to each other. With this kit of parts in hand, he was able to mock up different arrangements, re-configuring them as he considered the position of other nearby components.

The project is still ongoing. but we’re looking forward to seeing [Ryan] roaring around in his souped-up Corolla soon. In the meantime you can go deeper on ways of adding turbo to vehicles from the ’90s, the innovation of the Mercedes Formula 1 split turbo engine, and see the evolution of a 3D-printed pulsejet turbocharger.

Thanks to [Ryan Ralph] (not the same Ryan) for tipping us off.

These days ‘AI’ is everywhere, including in software development. Coming hot on the heels of approaches like eXtreme Programming and Pair Programming, there’s now a new kind of pair programming in town in the form of an LLM that’s been digesting millions of lines of code. Purportedly designed to help developers program faster and more efficiently, these ‘AI programming assistants’ have primarily led to heated debate and some interesting studies.

In the case of [Jj], their undiluted feelings towards programming assistants like GitHub Copilot burn as brightly as the fire of a thousand Suns, and not a happy kind of fire.

Whether it’s Copilot or ChatGPT or some other chatbot that may or may not be integrated into your IDE, the frustration with what often feels like StackOverflow-powered-autocomplete is something that many of us can likely sympathize with. Although [Jj] lists a few positives of using an LLM trained on codebases and documentation, their overall view is that using Copilot degrades a programmer, mostly because of how it takes critical thinking skills out of the loop.

Regardless of whether you agree with [Jj] or not, the research so far on using LLMs with software development and other tasks strongly suggests that they’re not a net positive for one’s mental faculties. It’s also important to note that at the end of the day it’s still you, the fleshy bag of mostly salty water, who has to justify the code during code review and when something catches on fire in production. Your ‘copilot’ meanwhile gets off easy.

Here’s a clever hack. Simple, elegant, and eminently cost-effective: using an SMD capacitor to hold your flash media in place!

This is a hack that can pretty much be summed up with just the image at the top of the page — a carefully placed SMD capacitor soldered to a routed tab makes for an extremely cost effective locking mechanism for the nearby SD card slot. There’s just enough flexibility to easily move the capacitor when its time to insert or eject your media.

It’s worth noting that the capacitor in this example doesn’t even appear to be electrically connected to anything. But there’s also no reason you couldn’t position one of the capacitors in your existing bill of materials (BOM). This form of mechanical support will be much cheaper than special purpose clips or mounts. Not a big deal for low-volume projects, but if you’re going high-volume this is definitely something to keep in mind.

If you’re just getting started with SMD capacitors then one of the first things to learn is how to solder them. Also, if you’re hoping to salvage them then try to look for newer equipment which is more likely to have SMD components than through-hole. If you’re planning to use your capacitors for… “capacitance” (how quaint), you can start by learning the basics. And if you want to know everything you can learn about the history of capacitors, too.

Thanks to [JohnU] for writing in to let us know about this one. Have your own natty hacks? Let us know on the tipsline!

You could use a little pocket-sized Pez dispenser if you’re a humble, reserved person. Or, you could follow the example of [Backhaul Studios], and build a dangerously powerful blaster that shoots Pez fast enough to shatter them into pieces. Just don’t aim it at your own mouth.

As the video explains, Pez is really the perfect candy for this application. It’s compact, hard, and already designed to be dispensed via a magazine. It’s thus not a big stretch to set it up to be fired out of a pistol-like blaster. The build is of the flywheel type, where a pair of counter-rotating wheels fling the candy out at great speed. The wheels themselves are spun up to high speed with a pair of small brushless motors, running off hobby speed controllers and lithium-ion batteries. A simple trigger mechanism dispenses the rectangular candies into the wheel mechanism, sending them flying out of the blaster at will. It’s all 3D-printed, designed specifically for the purpose of high-speed candy delivery.

The video goes into great detail on the design, from the development of the TPU treads on the flywheels and other details that helped improve the effectiveness of the design. The final build shoots Pez fast enough that they practically detonate upon hitting a surface.

We’ve featured some innovative work in this space from [Backhaul Studios] before—the condiment cannon was really quite something. Video after the break.

So-called artificial intelligence (AI) is all the rage right now between your grandma asking ChatGPT how to code in Python or influencers making videos without having to hire extras, but one growing concern is where the power is going to come from for the data centers. The MIT Technology Review team did a deep dive on what the current situation is and whether AI is going to kill us all (with carbon emissions).

Probably of most interest to you, dear hacker, is how they came up with their numbers. With no agreed upon methods and different companies doing different types of processing there were a number of assumptions baked into their estimates. Given the lack of information for closed-source models, Open Source models were used as the benchmark for energy usage and extrapolated for the industry as a whole. Unsurprisingly, larger models have a larger energy usage footprint.

While data center power usage remained roughly the same from 2005 to 2017 as increases in efficiency offset the increase in online services, data centers doubled their energy consumption by 2023 from those earlier numbers. The power running into those data centers is 48% more carbon intensive than the US average already, and expected to rise as new data centers push for increased fossil fuel usage, like Meta in Louisiana or the X data center found to be using methane generators in violation of the Clean Air Act.

Technology Review did find “researchers estimate that if data centers cut their electricity use by roughly half for just a few hours during the year, it will allow utilities to handle some additional 76 gigawatts of new demand.” This would mean either reallocating requests to servers in other geographic regions or just slowing down responses for the 80-90 hours a year when the grid is at its highest loads.

If you’re interested in just where a lot of the US-based data centers are, check out this map from NREL. Still not sure how these LLMs even work? Here’s an explainer for you.

Mjolnir, also known as Thor’s hammer, is a discerning thing, at least if you believe the modern Marvel canon. [alemanjir] decided to build a semi-functional replica that makes judgement calls of its own, though they’re perhaps a little less thought-out than the storied hammer of legend.

The build consists of a 3D-printed hammer prop, inside of which is a Raspberry Pi Pico microcontroller running the show. It’s hooked up to a MPR121 touch sensor that detects when someone grips the handle of the hammer. At this point, the Pico makes a pseudorandom “worthiness check” as to whether the holder is righteous enough to wield the hammer. If they are pure of heart, it unlocks a magnet which frees the hammer from whatever metallic surface it might be stuck to. [alemanjir] also included a little additional functionality, with the hammer playing various sounds when swung thanks to a speaker and a ADXL345 accelerometer secreted inside.

One wonders whether the electromagnet inside is strong enough to hold out against an unworthy person lifting it from the ground. While it’s perhaps not as powerful or as decisive as the mythical object, it’s nonetheless a fun learning project that likely taught [alemanja] some useful basics of embedded development.

We’ve featured some terrifying takes of the Mjolnir prop before, too, like this shockingly high voltage version. Video after the break.

Modern fertilizer manufacturing uses the Haber-Bosch and Ostwald processes to fix aerial nitrogen as ammonia, then oxidize the ammonia to nitric acid. Having already created a Haber-Bosch reactor for ammonia production, [Markus Bindhammer] took the obvious next step and created an Ostwald reactor to make nitric acid.

[Markus]’s first step was to build a sturdy frame for his apparatus, since most inexpensive lab stands are light and tip over easily – not a good trait in the best of times, but particularly undesirable when working with nitrogen dioxide and nitric acid. Instead, [Markus] built a frame out of aluminium extrusion, T-nuts, threaded rods, pipe clamps, and a few cut pieces of aluminium.

Once the frame was built, [Markus] mounted a section of quartz glass tubing above a gas burner intended for camping, and connected the output of the quartz tube to a gas washing bottle. The high-temperature resistant quartz tube held a mixture of alumina and platinum wool (as we’ve seen him use before), which acted as a catalyst for the oxidation of ammonia. The input to the tube was connected to a container of ammonia solution, and the output of the gas washing bottle fed into a solution of universal pH indicator. A vacuum ejector pulled a mixture of air and ammonia vapors through the whole system, and a copper wool flashback arrestor kept that mixture from having explosive side reactions.

After [Markus] started up the ejector and lit the burner, it still took a few hours of experimentation to get the conditions right. The issue seems to be that even with catalysis, ammonia won’t oxidize to nitrogen oxides at too low a temperature, and nitrogen oxides break down to nitrogen and oxygen at too high a temperature. Eventually, though, he managed to get the flow rate right and was rewarded with the tell-tale brown fumes of nitrogen dioxide in the gas washing bottle. The universal indicator also turned red, further confirming that he had made nitric acid.

Thanks to the platinum catalyst, this reactor does have the advantage of not relying on high voltages to make nitric acid. Of course, you’ll still need get ammonia somehow.

If you’re a solo musician, you probably have lots of gear you’d like to control, but you don’t have enough hands. You can enlist your feet, but your gear might not have foot-suitable interfaces as standard. For situations like these, [Nerd Musician] created the OpenMIDIStomper.

The concept is simple enough—the hardy Hammond enclosure contains a bunch of foot switches and ports for external expression pedals. These are all read by an Arduino Pro Micro, which is responsible for turning these inputs into distinct MIDI outputs to control outboard gear or software. It handles this via MIDI over USB. The MIDI commands sent for each button can be configured via a webpage. Once you’ve defined all the messages you want to send, you can export your configuration from the webpage by cutting and pasting it into the Arduino IDE and flashing it to the device itself.

We’ve featured some great MIDI controllers over the years, like this impressive parts bin build.

Great Scott! If my calculations are correct, when this baby hits 88 miles per hour, you’re gonna see some serious shit. — Doc Brown

On this day, forty years ago, July 3rd, 1985 the movie Back to the Future was released. While not as fundamental as Hackers or realistic as Sneakers, this movie worked its way into our pantheon. We thought it would be appropriate to commemorate this element of hacker culture on this day, its forty year anniversary.

If you just never got around to watching it, or if it has been a few decades since you did, then you might not recall that the movie is set in two periods. It opens in 1985 and then goes back to 1955. Most of the movie is set in 1955 with Marty trying to get back to 1985 — “back to the future”. The movie celebrates the advanced technology and fashions of 1985 and is all about how silly the technology and fashions of 1955 are as compared with the advancements of 1985. But now it’s the far future, the year 2025, and we thought we might take a look at some of the technology that was enchanting in 1985 but that turned out to be obsolete in “the future”, forty years on.

As the opening credits roll there are a bunch of different ticking clocks, signaling the time motif. But they are all analog clocks, some with pendulums, and not an LED or 7-segment display in sight. The only “digital” clock is a split-flap. The signaling of the time motif by clocks is done throughout the film, from the control panel in Doc’s DeLorean time-machine to the stopped clock on the town hall. Of course these days clocks have gotten much better and now they can even set themselves.

The JVC hand-held video camera recorded to VHS tape. The competing format to VHS at the time was known as Betamax which was developed by Sony. You will of course still find hand-held video cameras today but these days they are far more capable such as with 8K video cameras and you probably have one as a feature of your smartphone anyway. The tape-based VHS and Betamax media has been made obsolete mostly by flash media.

The old Cathode Ray Tube (CRT) television gave way to flat-screen LCD displays and nowadays transparent OLED is state of the art. There were two competing video standards back in 1985 being NTSC which was used in North America, Japan, parts of South America, and so on; and PAL which was used in Europe, Australia, parts of Asia, and Africa.

These old standards didn’t accommodate more than 30 frames-per-second, NTSC was 29.97 Hz and PAL was 25 Hz; and long before “widescreen” 16:9 aspect ratios were released in the 90s they had resolutions of up to 720 × 480 for NTSC and 720 × 576 for PAL. That’s “up to”, there were versions with resolutions worse than this. Of course this is a long way from the 4K@60Hz you have become accustomed to! Also there were no remote controls for these old beasts, you had to get up out of your chair to adjust the volume or change the channel, oh the indignity of it all!

When Marty McFly rocks out, he plugs his guitar into a vacuum tube amplifier, a piece of gear that has proven to have surprisingly long legs. You would think that it would now be an anachronism, replaced by transistor technology, but many guitarists still think that analog vacuum tube technology has a superior and warmer distortion sound. Powering the amp is another dinosaur that survived. The Variac controller shown is an autotransformer that is still made and used, although in 1985 the Variac trademark was owned by General Radio but is now owned by ISE, Inc.

The Cathode-Ray Oscilloscope (CRO) on the table there is completely obsolete, but it remains customary for a hacker to get nostalgic and buy one on eBay. The analog Voltage-Ohm-Milliamp (VOM) meter is maybe only half obsolete, and as with the CRO, a nostalgic hacker will still have one. Everyone else has a Digital Multi-Meter (DMM) which can do everything a VOM could do, and much more.

The old reel-to-reel magnetic tape recorder and player gave way to miniature flash storage in the end. And also a bunch of other media formats in the interim, ranging from floppy-disks to hard-drives. Reel-to-reel magnetic tech had a number of drawbacks, not least was that rewinding and fast-forwarding to find the track you were looking for was a real hassle. (Should we say a reel hassle?) Also the signal would get weaker and more distorted the more copies were made, this was known as generation loss and isn’t relevant to digital media.

The pulse-dial telephone gave way first to DTMF-based phones and then ultimately to cellphones and Voice over IP. People who are too young to have seen or used a rotary-dial phone won’t know how slow and annoying they were to use. To key in a number you had to rotate the dial in proportion to the number you wanted to enter, one for one, two for two, up to nine for nine and ten for zero; so if you had larger numbers in the phone number you were keying in you would have to wait for the dial to count back, which was tedious and boring. It is certainly not for practicality reasons that hackers keep trying to bring them back.

Like the pulse-dial and DTMF-based landline telephones the cordless telephone also gave way to cellphones and VoIP, but the old cordless telephones get a special mention because they were totally insecure. The radio signals they used were easily sniffed by anyone who knew how to operate a radio. To patch this technical vulnerability, the FCC made listening to particular frequencies illegal, and manufacturers cut out the cellphone and wireless phone bands from their scanners.

And to wrap-up let’s give a special mention to the push-button Seeburg vinyl jukebox. These were commonplace back in the day and every good bar had a coin-operated one. These days you’re unlikely to find a jukebox at the bar, it is perhaps more likely that one of the bar staff is streaming music to the bar’s Bluetooth speakers from their smartphone.

Thanks for coming with us on this brief journey back to 1985, it was fun to take some time to look at some of the things that have changed, and to pay our respects to this icon of hacker culture on its fortieth birthday. Don’t forget to sound-off in the comments regarding where you have seen references to the movie!

Some time last year, a weird thing happened in the hackerspace where this is being written. The Internet was up, and was blisteringly fast as always, but only a few websites worked. What was up? Fortunately with more than one high-end networking specialist on hand it was quickly established that we had a problem with our gateway’s handling of IPv4 addresses, and normal service was restored. But what happens if you’re not a hackerspace with access to the dodgy piece of infrastructure and you’re left with only IPv6? [James McMurray] had this happen, and has written up how he fixed it.

His answer came in using a Wireguard tunnel to his VPS, and NAT mapping the IPv4 space into a section of IPv6 space. The write-up goes into extensive detail on the process should you need to follow his example, but for us there’s perhaps more interest in why here in 2025, the loss of IPv4 is still something that comes with the loss of half the Internet. As of this writing, that even includes Hackaday itself. If we had the magic means to talk to ourselves from a couple of decades ago our younger selves would probably be shocked by this.

Perhaps the answer lies in the inescapable conclusion that IPv6 answers an address space problem of concern to many in technical spaces, it neither solves anything of concern to most internet users, nor is worth the switch for so much infrastructure when mitigations such as NAT make the IPv4 address space problem less of a problem. Will we ever entirely lose IP4? We’d appreciate your views in the comments. For readers anxious for more it’s something we looked at last year.

Like many of us of a certain vintage, [Dillan Stock] at The Stock Pot is nostalgic for VHS tapes. It’s not so much the fuzzy picture or the tracking issues we miss, but the physical experience the physical medium brought to movie night. To recreate that magic, [Dillan] made a Modern VHS with NFC and ESPHome.

NFC tags are contained in handsomely designed 3D printed cartridges. You can tell [Dillan] put quite a bit of thought into the industrial design of these: there’s something delightfully Atari-like about them, but they have the correct aspect ratio to hold a miniaturized movie poster as a label. They’re designed to print in two pieces (no plastic wasted on supports) and snap together without glue. The printed reader is equally well thought out, with print-in-place springs for that all important analog clunk.

Electronically, the reader is almost as simple as the cartridge: it holds the NFC reader board and an ESP32. This is very similar to NFC-based audio players we’ve featured before, but it differs in the programming. Here, the ESP32 does nothing related directly to playing media: it is simply programmed to forward the NFC tag id to ESPHome. Based on that tag ID, ESPHome can turn on the TV, cue the appropriate media from a Plex server (or elsewhere), or do… well, literally anything. It’s ESPHome; if you wanted to make this and have a cartridge to start your coffee maker, you could.

If this tickles your nostalgia bone, [Dillan] has links to all the code, 3D files and even the label templates on his site. If you’re not sold yet, check out the video below and you might just change your mind. We’ve seen hacks from The Stock Pot before, everything from a rebuilt lamp to an elegant downspout and a universal remote.

[juskim] wanted to build a tiny mouse, but it couldn’t just be any mouse. It had to be a high-tech gaming mouse that could compete with the best on raw performance. The results are impressive, even if the final build is perhaps less than ideal for pro-level gameplay.

The build riffs on an earlier build from [juskim] that used little more than a PCB and a 3D-printed housing to make a barebones skeleton mouse. However, this one ups the sophistication level. At the heart of the build is the nRF54L15 microcontroller, which is paired with a PAW3395 mouse sensor which is commonly used in high-end gaming mice. It offers resolution up to 26K DPI for accurate tracking, speeds up to 650 ips, and 8 kHz sampling rates. Long story short, if you want fine twitch control, this is the sensor you’re looking for. The sensor and microcontroller are laced together on a custom PCB with a couple of buttons, a battery, and a charging circuit, and installed in a barebones 3D-printed housing to make the final build as small as possible.

The only real thing letting the design down is the mouse’s key feature—the size. There’s very little body to grab on to and it’s hard to imagine being able to play most fast-paced games at a high level with such a tiny device. Nevertheless, the specs are hardcore and capable, even if the enclosure isn’t.

[juskim] loves building tiny peripherals; we’ve featured his fine work before, too. Video after the break.

Selecting a random sample from a set is simple. But what about selecting a fair random sample from a set of unknown or indeterminate size? That’s where reservoir sampling comes in, and [Sam Rose] has a beautifully-illustrated, interactive guide to how reservoir sampling works. As far as methods go, it’s as elegant as it is simple, and particularly suited to fairly sampling dynamic datasets like sipping from a firehose of log events.

While reservoir sampling is simple in principle it’s not entirely intuitive to everyone. That’s what makes [Sam]’s interactive essay so helpful; he first articulates the problem before presenting the solution in a way that makes it almost self-evident.

[Sam] uses an imaginary deck of cards to illustrate the problem. If one is being dealt cards one at a time from a deck of unknown size (there could be ten cards, or a million), how can one choose a single card in a way that gives each an equal chance of having been selected? Without collecting them all first?

In a nutshell, the solution is to make a decision every time a new card arrives: hold onto the current card, or replace it with the new one. Each new card is given a 1/n chance of becoming held, where n is the number of cards we’ve seen so far. That’s all it takes. No matter when the dealer stops dealing, each card that has been seen will have had an equal chance of ending up the one selected.

There are a few variations which [Sam] also covers, and practical ways of applying it to log collection, so check it out for yourself.

If [Sam]’s knack for illustrating concepts in an interactive way is your jam, we have one more to point out. Our own Al Williams wrote a piece on Turing machines; the original “universal machine” being a theoretical device with a read/write head and infinite paper tape. A wonderful companion to that article is [Sam]’s piece illustrating exactly how such a Turing machines would work in an interactive way.