Walking around the alley at Hackaday Supercon 2024, we noticed an interesting project was getting quite a bit of attention, so we got nearer for a close-up. The ‘Circuit Graver’ by [Zach Fredin] is an unconventional PCB milling machine, utilizing many 3D printed parts, the familiar bed-slinger style Cartesian bot layout and a unique cutting head. The cutting tool, which started life as a tungsten carbide lathe tool, is held on a rotary (‘R’) axis but can also move vertically via a flexure-loaded carriage driven by a 13 kg servo motor.

The stocky flexure took a lot of iteration, as the build logs will show. Despite a wild goose chase attempting to measure the cutting force, a complete machine solution was found by simply making everything stiff enough to prevent the tool from chattering across the surface of the FR4 blank. Controlling and maintaining the rake angle was a critical parameter here. [Zach] actually took an additional step, which we likely wouldn’t have thought of, to have some copper blanks pre-fabricated to the required size and finished with an ENIG coating. It’s definitely a smart move!

To allow the production of PCB-class feature sizes compatible with a traditional PCB router, the cutting tool was sharpened to a much smaller point than would be used in a lathe using a stone. This reduced the point size sufficiently to allow feature sizes down to 4 mils, or at least that’s what initial characterization implied was viable.  As you can see from the build logs, [Zach] has achieved a repeatable enough process to allow building a simple circuit using an SMT 74HC595 and some 0402 LEDs to create an SAO for this year’s Supercon badge. Neat stuff!

We see a fair few PCB mills, some 3D printed, and some not. Here’s a nice one that fits in that former category. Milling PCBs is quite a good solution for the rapid prototyping of electronics. Here’s a guide about that.

[David Bryant] clearly has an awareness of the impact of an excess concentration of CO₂ in the local environment and has designed an SAO board to add a CO₂ traffic light indicator to one of the spare slots on the official Hackaday Supercon 2024 badge.

The part used is the Sensirion SCD40 ‘true’ CO2 sensor, sitting atop an Adafruit rider board. [David] got a leg up on development by creating a simple SAO breakout board, which could have either the male and female connectors fitted, as required. Next, he successfully guessed that the badge would be based around the RP2040 running MicroPython and hooked up an Adafruit Feather RP2040 board to get started on some software to drive the thing. This made hooking up to the official badge an easy job. Since the SAO has only two GPIOs, [David] needed to decode these to drive the three LEDs. There are a few ways to avoid this, but he wanted to relive his earlier EE college years and do it the direct way using a pair of 74HC00 quad NAND gate chips.

We’ve seen a few CO₂ monitors over the years. This sleek little unit is based around the Seeeduino XIAO module and uses an LED ring as an indicator. Proper CO₂ monitors can be a little pricey, and there are fakes out there. Finally, CO₂ is not the only household pollutant; check out this project.

As we all know, when developing software for any platform or simply hacking a bit of code to probe how something works, the ability to deploy code rapidly is a huge help. [Martin Donlon], aka [wickerwaka], is well known in retro gaming and arcade hardware reverse engineering circles and had the usual issues figuring out how an arcade CPU board worked while developing a MiSTer core. Some interesting ASICs needed quite a bit of poking, and changing the contents of socketed ERPOMs is a labour-intensive process. The solution was PicoROM, a nicely designed ROM emulator in a handy DIP-32 form factor.

As the title suggests, PicoROM is based on the Raspberry Pi RP2040. It emulates an 8-bit ROM up to 2MBits in size with speeds up to 100ns. Since it uses the RP2040, USB connectivity is simple, enabling rapid uploading of new images to one (or more) PicoROMs in mere seconds. A vertically orientated USB-C connector allows multiple PicoROMs to be cabled to the host without interfering with neighbouring hardware. The firmware running on core 1 passes data from the internal 264K SRAM, using the PIO block as a bus interface to the target. A neat firmware feature is the addition of a mechanism to use a ROM region as a bidirectional control channel, which the software running on the target can use to communicate back to the host computer. This allows remote triggering of actions and the reporting of responses. Responses which may not be physically observable externally. [Martin] is using this feature extensively to help probe the functionality of some special function chips on the target boards, which is still a slow process but helped massively by reducing that critical software iteration time. The PCB was designed with KiCAD. The project files for which can be found here.

This isn’t the first time we’ve seen the RP2040 used for ROM emulation; here’s a pile of wires that does the same job. It just isn’t as pretty. Of course, if you really must use EPROMs, then you could give this sweet programmer a look over.

[David Shadoff] has a clear soft spot for the NEC console systems and has been collecting many tools and data about them. When developing with these old systems, having a way to upload code quickly is a real bonus, hence the creation of the PC-FX Dev Cart. Based on the Raspberry Pi RP2040, the custom cartridge PCB has everything needed to run software uploadable via a USB-C connection.

While the PC-FX is a CDROM-based system, it does sport a so-called FX-BMP or backup memory port cartridge slot, which games can use to save state and perform other special functions. Under certain circumstances, the PC-FX can be instructed to boot from this memory space, and this cartridge project is intended to enable this. Having a quick way to upload and execute code is very useful when exploring how these old systems work, developing new applications, or improving the accuracy of system emulators. The original FX-BMP cartridge has little more inside than a supercapacitor-backed SRAM and a custom interfacing IC, and of course, it would be quite a hassle to use this to develop custom code.

The RP2040 isn’t really being too tasked in this application, with one core dedicated to emulating a 128K x 8 SRAM, handling the PC-FX bus interface, and the other doing duty on the USB side. At the top of the PCB are a pair of 74LVC16T245 16-bit level shifter ICs, which need to be translated from the 5 Volt console voltage domain into the 3.3 Volts at which the microcontroller operates. Power for the board is taken from the USB, not the console, enabling code to be uploaded before powering up the target. This way, the power budget of the console isn’t compromised, and the cartridge can be initialized before powering up and booting.

[David] Needed to overclock the RP2040 to 240 MHz, way beyond the specification limit of 133 MHz, because despite the PIO block being fast enough to emulate the required interface timing, the latency passing data between the PIO and the CPU core was too large, hence the need for GPIO-based solution. The project was created in KiCAD; the design files can be found here, and only one mistake has been found so far!

[David] is also heavily involved with documenting and collecting all the PC-FX resources available in the wild. These can be found in this GitHub repo. It doesn’t look like we’ve covered the PC-FX before, but we have seen a few hacks about its older sibling, the PC Engine and the closely related TurboGrafx-16. Here’s a simple PC engine-to-TurboGrafx converter board for starters. If you lack the genuine hardware, do not despair; here is an FPGA-based emulator.

A decade ago, [Jouke Waleson] bought a Dutch ‘model 1950’ PTT (The Dutch Postal Service) rotary-dial telephone of presumably 1950s vintage manufactured by a company called Standard Electric, and decided it would be neat to hack it to function as a Bluetooth hands-free device. Looking at the reverse, however, it is stamped “10.65” on the bottom, so maybe it was made as recently as 1965, but whatever, it’s still pretty old-tech now.

The plan was to utilise ESP32 hardware with the Espressif HFP stack to do all the Bluetooth heavy lifting. [Jouke] did find out the hard way that this is not a commonly-trodden path in hackerland, and working examples and documentation were sparse, but the fine folks from Espressif were on hand via GitHub to give him the help he needed. After ripping into the unit, it was surprisingly stuffed inside there. Obviously, all the switching, even the indication, was purely electromechanical, which should be no surprise. [Jouke] identified all the necessary major components, adding wires and interfacing components as required, but was a bit stumped at the function of one funky-looking component that we reckon must be a multi-tap audio transformer, oddly finished in baby pink! After renovating some interesting cross-shaped mechanical indicators and wiring up some driving transistors, it was time to get on to the audio interface.

Initially, [Joike] planned to use an INMP441 I²S digital microphone module, but this was incompatible with the standard ESP32 HFP client (used for Bluetooth hands-free support), so [Jouke] pivoted and used a WM8782-based ADC board for audio input. This also allowed the existing microphone to be used simply by biasing

it to 5 Volts and hooking it straight up to the ADC board via a coupling capacitor. This was a happy outcome, as the modern digital microphone would have sounded very different to the original equipment! On the speaker side, a PCM5102 I²S audio DAC module was pressed into service. The ringer/buzzer needed seven volts, so adding a boost converter board was also necessary. It’s a minor annoyance for powering a single device, but this is a one-off hack, so it’s no big deal. Finally, the backplate was modified to add a USB-C module and a power switch so it could be power-cycled, giving access to the ESP32 boot loader and enabling firmware updates without opening the case.

The outfit’s brains are courtesy of a LilyGo T-Koala board, a basic breakout board based around the older ESP32-WROVER module. This was necessary as the newer ESP32 chips drop Bluetooth classic support and, with it, support for handling the Bluetooth hands-free protocol. We were particularly ticked by the project tagline, “Bakelite to the future”, and that lifting the phone when not answering an incoming call connects you to Google Assistant or Siri! Nice work! For a look over the source code for the project, check out the GitHub page.

This is not the first modernisation of a classic telephone, and we hope it won’t be the last. Here’s an older GSM-based hack. If all this talk of rotary phones and tethered handsets confuses you, here’s our guide to this older telephone system. Telephones weren’t the only old-school home appliances constructed from Bakelite—far from it. It was also used to make many radios.

Unless you spend all your time lounging on the sofa, you probably own at least one pair of shoes. But have you ever thought to make your own to improve some aspect of your life? YouTube channel Answer in Progress set out to do precisely that, but it didn’t quite work out.

When you (well, other people) get into running, it’s tempting to believe a lot of the shoe company hype and just drop hundreds of dollars on the latest ‘super shoe’ and hope that will help you break your target time. But do you actually need to buy into all this, or can you make something yourself? The project aimed to get the 5k time down significantly, at any cost, but primarily by cheating with technology. The team set out to look at the design process, given that there is indeed a fair amount of science to shoe design. Firstly, after a quick run, the main issues with some existing shoes were identified, specifically that there are a lot of pain points; feet hurt from all the impacts, and knees take a real pounding, too. That meant they needed to increase the sole cushioning. They felt that too much energy was wasted with the shoes not promoting forward motion as much as possible; feet tended to bounce upwards so that a rocker sole shape would help. Finally, laces and other upper sole features cause distraction and some comfort issues, so those can be deleted.

The plan was to make a ‘sock’ shoe style, with an upper in one piece and stretchy enough to slip on without laces. The process started by wrapping the foot in cling film and then a few layers of duct tape to fix the shape. This was split down the top to extract the foot, open out the pattern, and transfer it to some nylon fabric. The outer profile was transferred and cut out with simple hand tools in a fashion that would allow the shape to be reconstructed as it was glued to a sole. It sounds simple, but it’s pretty fiddly work.

The latest running shoes use specialised rubber materials for the midsole. The solid foam wedge between the outer rubber and the inner sole cushions the foot. Those materials are only a few per cent ‘better’ than much more accessible foams that can be 3D printed. After sculpting a sole shape by hand using Blender, a friend 3D printed it. After that, the upper part was glued and ready for a test run. Which didn’t last long. It turned out that the lack of a stable heel counter (the bit around the back) that helps lock the heel in place meant the foot was too loose in the shoe, causing potential issues such as an ankle roll. That would be not good.  A follow-up session with a sports-focused chiropodist demonstrated that all this was rather pointless before the fundamental issues of strength and fitness were addressed. So, whilst it was fun to see an attempt to beat the big boys at their own game, it sure isn’t easy to pull it off, especially if you can’t get off the sofa.

The invention of flexible 3D printing filaments spurred the development of a wide range of 3D-printed footwear, like these low-poly beauties. While we’re 3D printing shoes, we also need some lace locks. Finally, with winter approaching for us Northerners, perhaps it’s time to run off a pair of 3D-printed strap-on cleats.

Thanks to [fluffy] for the tip!

BIQU has released a new line of low-temperature build plates that look to be the next step in 3D printing’s iteration—or so YouTuber Printing Perspective thinks after reviewing one. The Cryogrip Pro is designed for the Bambu X1, P1, and A1 series of printers but could easily be adapted for other magnetic-bed machines.

The idea of the new material is to reduce the need for high bed temperatures, keeping enclosure temperatures low. As some enclosed printer owners may know, trying to print PLA and even PETG with the door closed can be troublesome due to how slowly these materials cool. Too high an ambient temperature can wreak havoc with this cooling process, even leading to nozzle-clogging.

The new build plate purports to enable low, even ambient bed temperatures, still with maximum adhesion. Two versions are available, with the ‘frostbite’ version intended for only PLA and PETG but having the best adhesion properties.  A more general-purpose version, the ‘glacier’ sacrifices a little bed adhesion but gains the ability to handle a much wider range of materials.

An initial test with a decent-sized print showed that the bed adhesion was excellent, but after removing the print, it still looked warped. The theory was that it was due to how consistently the magnetic build plate was attached to the printer bed plate, which was now the limiting factor. Switching to a different printer seemed to ‘fix’ that issue, but that was really only needed to continue the build plate review.

They demonstrated a common issue with high-grip build plates: what happens when you try to remove the print. Obviously, magnetic build plates are designed to be removed and flexed to pop off the print, and this one is no different. The extreme adhesion, even at ambient temperature, does mean it’s even more essential to flex that plate, and thin prints will be troublesome. We guess that if these plates allow the door to be kept closed, then there are quite a few advantages, namely lower operating noise and improved filtration to keep those nasty nanoparticles in check. And low bed temperatures mean lower energy consumption, which is got to be a good thing. Don’t underestimate how much power that beefy bed heater needs!

Ever wondered what mini QR-code-like tags are on the high-end build plates? We’ve got the answer. And now that you’ve got a pile of different build plates, how do you store them and keep them clean? With this neat gadget!

[Sebastian Mihai] is a prolific programmer and hacker with a particular focus on retrocomputing and period games, and this latest hack, adding new gameplay elements to Capcom’s Street Fighter II – Champion Edition, is another great one. [Sebastian] was careful to resist changing the game physics, as that’s part of what makes this game ‘feel’ the way it does, but added some fun extra elements, such as the ability to catch birds, lob barrels at the other player, and dodge fire. The title screen was updated for each of the different versions, so there is no doubt about which was being played. This work was based on their previous hacks to Knights of the Round. Since both games shared the same Capcom CPS-1 hardware, the existing 68000 toolchain could be reused, reducing the overhead for this new series of hacks.

Obviously, without access to the game’s source code, the hacks (all seven of them!) were made by binary modification, first learning about how the original program stores aspects of the game and hacking in a little hand-grafted assembly here and there to sneak in the extra elements without interfering too much with the original code operation. [Sebastian] stripped out some title screen effects to speed boot time and removed some in-game graphics, such as the score and the ‘insert coin’ images, to free up some graphical tiles to reuse for the new elements. [Sebastian] first needed to understand the game code, which meant disassembly and hand annotation of the entire binary, which was done using the MAME debugger. As the linked article demonstrates, saying this is a big task is somewhat of an understatement.

A simple approach was taken to the mods consisting of three types of binary patches. The first, or ‘short circuit’, are simple NOPs inserted to disable subroutine calls or RTS to force an early return in a subroutine. The second type is a blob of code residing in some unused ROM space and storing state in a spare section of RAM. This is where the main parts of the new code reside. Finally, hooks are injected into the code at key locations, which jump into the binary blob where modified behaviour is required. This can do any needed initialisation before returning to the main game logic. Making significant changes to the game would be very hard without any spare space in the system, but we guess you could do it by stripping out other game elements, but [Sebastian] didn’t need to go there. If you’re into retro gaming and particularly modding, then going deeper into [Sebastian]’s homepage will reveal an astonishing number of projects and hacks.

Sometimes, our fond memories of games of old are skewed a little over the years, and the gameplay wasn’t that great in reality. So, what can we do? How about a little Redux, Zelda II style? If you’re really down the rabbit hole of retro hardware, then dealing with all those pesky EPROM chips is getting more difficult these days. To help with that, here’s a modern take on the necessary hardware.

[Chris Borge] has spent the last few years creating some interesting 3D printed tools and recently has updated their 3D printable lathe design to make a few improvements. The idea was to 3D print the outer casing of the lathe in two parts, adding structural parts where needed to bolt on motors and tool holders, and then fill the whole thing with concrete for strength and rigidity.

The printed base is initially held together with two lengths of studding, and a pile of bolts are passed through from below, mating with t-nuts on the top. 2020 extrusion is used for the motor mount. The headstock is held on with four thread rods inserted into coupling nuts in the base. The headstock unit is assembled separately, but similarly; 3D printed outer shell and long lengths of studding and bolts to hold it together. Decent-sized tapered roller bearings make an appearance, as some areas of a machine tool really cannot be skrimped. [Chris] explains that the headstock is separate because this part is most likely to fail, so it is removable, allowing it to be replaced.

Once together, the whole assembly is filled with runny concrete and set aside to cure. Before fully curing, the top surfaces are scraped flat to remove excess concrete so the top covers will fit. A belt-driven motor is fitted, with associated control electronics, and then it’s time to talk tooling. The first tool shown is a simple T-shaped rest, used with a hand tool known as a ‘graver.’  This is more likely to be used on a wood lathe, but we reckon you could about get away with it if you’re really careful with aluminium or perhaps brass. An adjustable rest was made using a few simple pieces (in steel!) and held in a short length of 2020 extrusion in a manner that makes it adjustable, albeit not shown in this video. Finally, a reasonable torture test is demonstrated, comprising a rough-cut aluminium disk screwed to a threaded carrier. This was tidied up to make it nice and round and clean up its surfaces. The lathe survived, only melting the 3D printed motor pulley, which, as they say, should not have been a 3D printed part when metal parts are so easy to acquire! If you want to build one for yourself, then everything you need is here, but like with projects of this type, more development is still needed to overcome a few shortcomings. Check out [Chris]’s channel for many more interesting ideas!

We’ve seen a few of [Chris]’s other 3D-printed tools, like this neat fractal vice for odd-shaped objects. We like tiny tool hacks; after all, when you’re making small things, you don’t need full-sized tools.

Thanks to [CJay] for the tip!

[Sebastian Lederer] has created Tridora: an unusual stack-based CPU core intended for FPGA deployment, co-developed with its own Pascal compiler. The 32-bit word machine is unusual in that it has not one but three stacks, 16-bit instruction words, and a limited ISA, more like those of the 8-bit world. No multiply or divide instructions will be found in this CPU.

The design consists of about 500 lines of Verilog targeting the Digilent Arty-A7 FPGA board, which is based around the Xilinx Artix-7 FPGA line. [Sebastian] plans to support the Nexys A7 board, which boasts a larger FPGA array but has less RAM onboard. The CPU clocks in at 83 MHz with four clock cycles per instruction, so over 20 MIPS, which is not so shabby for a homebrew design. Wrapped around that core are a few simple peripherals, such as the all-important UART, an SD card controller and a VGA display driver. On the software side, the Pascal implementation is created from scratch with quite a few restrictions, but it can compile itself, so that’s a milestone achieved. [Sebastian] also says there is a rudimentary operating system, but at the moment, it’s a little more than a loader that’s bundled with the program image.

The Tridora Gitlab project hosts the Verilog source, an emulator (written in Golang, not Pascal) and a suite of example applications. We see quite a few custom CPUs, often using older or less popular programming languages. Here’s an FPGA-based Forth machine to get you started. Implementing programming languages from scratch is also a surprisingly common hack. Check out this from-scratch compiler for the Pretty Laughable Programming language.

[Jeremy Weatherford] clearly has a knack for explaining projects well enough for easy reproduction but goes way further than most and has created a four-part YouTube series detailing every step from project inception to the final assembly, covering all aspects of 3D modelling and PCB design for a custom MacroPad design. Many tools are introduced along the way, all of which help reduce complexity and, by extension, the scope for errors. As every beginner hacker knows, early successes breed confidence and make for better and more ambitious projects.

Part 1 covers the project motivation and scope and introduces a keyboard layout editor tool. This tool allows one to take a layout idea and generate a JSON file, which is then used to drive keyboard tools. XYZ to produce a usable KiCAD project. The tool only generates a PCB project and an associated netlist file. No schematic is created; you don’t need one for a simple layout.

Part 2 is a walkthrough of the design process in KiCAD, culminating in ordering the PCB from JLCPCB and assembling the surface-mount parts. This particular design uses a controller based on the Sea-Picro RP2040 module, but there are many options if you have other preferences. [Jeremy] shows what’s possible with the selected suppliers, but you need not follow this step precisely if you have other ideas or want to use someone local.

Part 3 covers exporting the mechanical aspects of the PCB out of KiCAD and into a 3D CAD program, specifically OnShape. [Jeremy] covers some crucial details, such as how to read the mechanical drawing of the keys to work out where to place the top plate. It’s very easy to plough straight in at this stage and make a design which cannot be assembled! The plan is to use a simple laser-cut box with a bottom plate with mounting holes lining up with those on the PCB. A Top plate is created by taking the outline of the PCB and adding a little margin. An array of rectangular cutouts are designed for the keys to protrude, lining up perfectly with where the keys would be when mounted on the PCB below.  The sides of the case are formed from laser-cut sections that lock into each other and the laser-cut base—using the laser joint feature-script addon tool from the OnShape community channel. A second feature script addon is used to auto-layout the laser-cut components onto a single sheet. A CAM application called Kiri Moto is used to export for laser cutting and is available on the OnShape store.

Part 4 concerns the firmware. The QMK WSL build is compiled on Windows using WSL, minimizing the barrier to entry for intrepid hackers who are likely to start out with Windows-based hardware. The QMK layout is configured as an ortho_4x4, but [Jeremy] calmly and clearly explains how the other layouts are used and how they align with the earlier design choices. Finally, the VIAL keyboard layout editor is shown to be used for testing the finished macropad, and how it is used for programming those delicious macros we want to emit into the world.

Macropads are very individual things, and you really need to be pushing the limits of productivity to need one, let alone build a custom device. Here’s one for those who get stuck in MS Teams calls a lot. If you’re into video editing, that’s a valid use case. Video editing macropads have existed for decades, but have they been made out of wood?

We’ve seen a few retro products using core rope memory, such as telephone autodiallers. Obviously, we’ve covered the Apollo program computers, but we don’t think we’ve seen a complete and functional DIY computer using core rope memory for program storage until now. [P-lab] presents their take on the technology using it to store the program for a Z80-based microprocessor demoboard, built entirely through-hole on a large chunk of veroboard.

For the uninitiated, core rope memory is a simple form of ROM where each core represents a bit in the data word. Each wire represents a single program location. Passing a wire through the core sets the corresponding bit to a logic 1, else 0. These wires are excited with an AC waveform, which is coupled to the cores that host a wire, passing along the signal to a pickup coil. This forms an array of rudimentary transformers. All that is needed is a rectifier/detector to create a stable logic signal to feed onto the data bus.

For this to work as a ROM with the Z80, the address bus is decoded to 16 individual lines using a CMOS 4515 4-16 decoder. These lines each drive a 2n2222 NPN transistor, pulling one end of the associated address wire to ground. The other ends of all address wires are tied to a common AC-coupled oscillator based around our good friend, the 555 timer. A simple rectifier is formed for each core sense circuit with a BAT85 Schottky diode and a 1 nF capacitor, which passes the sense signal along to a CMOS 4508 dual 4-bit latch. The output of which is passed back to the Z80 data bus via some multiplexing logic. Other than some indicator LEDs on the data bus, the only other IO or indication on this board are a couple of 7-segment displays. Obviously, the ROM is limited to a meagre 16 bytes of storage, making a meaningful demo rather limited. Luckily, it’s possible to code a Fibonacci sequence generator in that space, including driving the output latch to update the display. We wonder now what else could be made to fit in such a restricted code?

We covered DIY core rope memories before, like here and here; they’re not news to us. Compare and contrast a DIY magnetic core memory. Less efficient at this scale? We think so, too.

thanks to [Giuseppe] and [Survival Hacking] for the tip!

We’re suckers for good-looking old-school calculators, so this interesting numerical equation-solving calculator by [Peter Balch] caught our attention. Based around the ESP32-WROOM-32 module and an LCD, the build is quite straightforward from an electronics point of view, with the main work being on the software side of things.

A custom keyboard was constructed on Veroboard using a handful of tactile switches arranged in a charlieplexing array to minimize the number of IO pins consumed. For the display, an off-the-shelf 240×320 ILI9341-based module hooked up by SPI was used. A single lithium cell was used for the power supply, connected to a USB

charger module, but you could just as easily substitute a 3 x AA battery box. The case was designed in DesignSpark mechanical and 3D printed. It’s unclear what keyboard version they settled on; there are options for one with keycaps and one without. Regardless, a 3D-printed frame sits atop the keyboard circuit, with the graphics printed on photo paper and a protective coversheet on top.

The most interesting part of this project is the software and [Peter]’s extensive explanation of the pros and cons of the various numerical-solving algorithms. “Solve,” as they call the project, uses five methods to solve single-variable equations and Newton-Raphson for simultaneous equations. The exact method depends on the types of functions used in the equations and whether they are continuous.

Additionally, the calculator software supports looping constructs, allowing the generation of results tables and multivariable graph plotting. All in all, it could be a helpful desktop addition for someone needing a dedicated solver. Check out the project GitHub page for more details of the construction and software and to start building your own.

The subject of calculators is very personal, especially for engineers and scientists. Here’s our word on maybe the last physical scientific calculator. Of course, we’ve covered so many DIY calculator builds that we’ve lost count. Here’s a great example. Finally, who needs electronics when you can do it mechanically? Batteries not included.

Embedded programming is a tricky task that looks straightforward to the uninitiated, but those with a few decades of experience know differently. Getting what you want to work predictably or even fit into the target can be challenging. When you get to a certain level of complexity, breaking code down into multiple tasks can become necessary, and then most of us will reach for a real-time operating system (RTOS), and the real fun begins. [Aleksei Tertychnyi] clearly understands such issues but instead came up with an alternative they call ANTIRTOS.

The idea behind the project is not to use an RTOS at all but to manage tasks deterministically by utilizing multiple queues of function pointers. The work results in an ultra-lightweight task management library targeting embedded platforms, whether Arduino-based or otherwise. It’s pure C++, so it generally doesn’t matter. The emphasis is on rapid interrupt response, which is, we know, critical to a good embedded design. Implemented as a single header file that is less than 350 lines long, it is not hard to understand (provided you know C++ templates!) and easy to extend to add needed features as they arise. A small code base also makes debugging easier. A vital point of the project is the management of delay routines. Instead of a plain delay(), you write a custom version that executes your short execution task queue, so no time is wasted. Of course, you have to plan how the tasks are grouped and scheduled and all the data flow issues, but that’s all the stuff you’d be doing anyway.

The GitHub project page has some clear examples and is the place to grab that header file to try it yourself. When you really need an RTOS, you have a lot of choices, mostly costing money, but here’s our guide to two popular open source projects: FreeRTOS and ChibiOS. Sometimes, an RTOS isn’t enough, so we design our own full OS from scratch — sort of.

The 3D printing process is cool, but it’s also really annoying at times. Specifically, when you want to get a part printed, and no matter how you orientate things, what adhesion aids you use or what slicer settings you tweak, it just won’t print right. [David Malawey] has been thinking a little about the problem of the edges of wide prints tending to curl upwards, and we believe they may be on to something.

Obviously, we’re talking about the lowest common denominator of 3D printing, FDM, here. Other 3D printing technologies have their gotchas. Anyway, when printing a wide object, edge curling or warping is a known annoyance. Many people will just try it and hope for the best. When a print’s extreme ends start peeling away from the heat bed, causing the print to collide with the head, they often get ripped off the bed and unceremoniously ejected onto the carpet. Our first thought will be, “Oh, bed adhesion again”, followed by checking the usual suspects: bed temperature, cleanliness and surface preparation. Next, we might add a brim or some sacrificial ‘bunny ears’ to keep those pesky edges nailed down. Sometimes this works, but sometimes not. It can be frustrating. [David] explains in the YouTube short how the contraction of each layer of materials is compounded by its length, and these stresses accumulate as the print layers build. A simple demonstration shows how a stack of stressed sections will want to curl at the ends and roll up inwards.

This mechanism would certainly go some way to explain the way these long prints behave and why our mitigation attempts are sometimes in vain. The long and short of it is to fix the issue at the design stage, to minimize those contraction forces, and reduce the likelihood of edge curling.

Does this sound familiar? We thought we remembered this, too, from years ago. Anyway, the demonstration was good and highlighted the issue well.

Thanks to [Keith] for the tip!

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

For those who have not dealt with the automotive side of electronics before, it comes as somewhat of a shock when you find out just how much extra you have to think about and how tough the testing and acceptance standards are. One particular test requirement is known as the “load dump” test. [Tim Williams] needed to build a device (first article of three) to apply such test conditions and wanted to do it as an exercise using scrap and spares. Following is a proper demonstration of follow-through from an analytical look at the testing specs to some interesting hand construction.

The load dump test simulates the effect of a spinning automotive alternator in a sudden no-load scenario, such as a loose battery terminal. The sudden reduction in load (since the battery no longer takes charging current) coupled with the inductance of the alternator windings causes a sudden huge voltage spike. The automotive standard ISO 7637-2:2011 dictates how this pulse should be designed and what load the testing device must drive.

The first article covers the required pulse shape and two possible driving techniques. It then dives deep into a case study of the Linear Tech DC1950A load dump tester, which is a tricky circuit to understand, so [Tim] breaks it down into a spice model based around a virtual transistor driving an RC network to emulate the pulse shape and power characteristics and help pin down the specs of the parts needed. The second article deals with analysing and designing a hysteric controller based around a simple current regulator, which controls the current through a power inductor. Roughly speaking, this circuit operates a bit like a buck converter with a catch diode circulating current in a tank LC circuit. A sense resistor in the output path is used to feedback a voltage, which is then used to control the driving pulses to the power MOSFET stage. [Tim] does a good job modeling and explaining some of the details that need to be considered with such a circuit.

The third and final article turns what’s been learnt so far into a practical design that can be built, with many extra parts added and explained to make this work in reality. It was nice to see ICs being mostly rejected in favour of a discrete design using transistors and other parts at hand—you can see the individual circuit elements if you know what you’re looking for. That said, the venerable 555 timer is in there, doing one of the things it does best: being a trigger timer.  The physical construction is done Manhattan-style on a couple of board layers, with some hilariously outsized parts bolted on just because. There’s much to learn from this project, although it will be a tough read for any newcomer to electronics.

While we’re considering building our own instruments, here’s an active load build. EMC testing is one of those areas that can really cause problems. Here’s our guide. We don’t see enough discrete components used in projects these days. Here’s a discrete transistor CPU to admire.

We always thought the older console games looked way better back in the day on old CRTs than now on a modern digital display. [Stephen Walters] thinks so too, and goes into extensive detail in a lengthy YouTube video about the pros and cons of CRT vs digital, which was totally worth an hour of our time. But are CRTs necessary for retro gaming?

The story starts with [Stephen] trying to score a decent CRT from the usual avenue and failing to find anything worth looking at. The first taste of a CRT display came for free. Left looking lonely at the roadside, [Stephen] spotted it whilst driving home. This was a tiny 13″ Sanyo DS13320, which, when tested, looked disappointing, with a blurry image and missing edges. Later, they acquired a few more displays: a Pansonic PV-C2060, an Emerson EWF2004A and a splendid-looking Sony KV24FS120. Some were inadequate in various ways, lacking stereo sound and component input options.

A large video section discusses the reasons for the early TV standards. US displays (and many others using NTSC) were designed for 525 scan lines, of which 480 were generally visible. These displays were interlaced, drawing alternating fields of odd and even line numbers, and early TV programs and NTSC DVDs were formatted in this fashion. Early gaming consoles such as the NES and SNES, however, were intended for 240p (‘p’ for progressive) content, which means they do not interlace and send out a blank line every other scan line.  [Stephen] goes into extensive detail about how 240p content was never intended to be viewed on a modern, sharp display but was intended to be filtered by the analogue nature of the CRT, or at least its less-than-ideal connectivity. Specific titles even used dithering to create the illusion of smooth gradients, which honestly look terrible on a pixel-sharp digital display. We know the differences in signal bandwidth and distortion of the various analog connection standards affect the visuals. Though RGB and component video may be the top two standards for quality, games were likely intended to be viewed via the cheaper and more common composite cable route.

One debatable point is the effect of modern digital image processing on display lag. Modern TVs may have analog inputs, but these are sampled into the digital domain before being filtered and upscaled to fit the screen. This takes some time to process. We reckon that with games needing pixel-perfect timing reflexes, this could affect gameplay. It is also a perfect excuse to bust out some old games, you know, for science.

It’s an interesting discussion with newer tech that perhaps has a detrimental effect on the gameplay experience. Emulators such as Retroarch have some excellent video shader plugins that can accurately render some of these effects, so even if you can’t find a physical CRT that works, you can still at least experience the joy that these things once brought.

We touched on this subject a couple of months back with a somewhat opposite opinion, but all this stuff is subjective anyway. Want to know what makes CRTs tick? Then, take them to bits with a hammer. And did we mention how light guns are no longer just for CRTs?

YouTuber [MechPanda] has recreated a DIY STM hack we covered about ten years ago, updating it to be primarily 3D-printed, using modern electronics, making it much more accessible to many folks. This simple STM setup utilises a piezoelectric actuator constructed by deliberately cutting a piezo speaker into four quadrants. With individual drive wires attached to the four quadrants. They (re)discovered that piezoelectric ceramic materials are not big fans of soldering heat. Still, in the absence of ultrasonic welding equipment, they did manage to get some wires to take to the surface using low-temperature solder paste.

They glued a makeshift probe holder on the rear side of the speaker actuator, which was intended to take a super sharp needle-like piece of tungsten wire. Putting the wire in tension and cutting at a sharp angle makes it possible with many attempts to get some usable points. Usable, in this instance, means sharp down the atomic level. The sample platform, actuator mount and all the connecting parts are 3D-printed with PA-CF. This is necessary to achieve enough mechanical stability with normal room temperature fluctuations. Three precision screws are used to level the two platforms in a typical kinematic mount structure, which looks like the only hard-to-source component. A geared stepper motor attached to the probe platform is set up to allow the probe to be carefully advanced towards the sample surface.

The next issue concerns vibration damping of the whole assembly. This was achieved with a simple hanging sprung platform, damped using an aluminium plate and magnets mounted underneath—a simple and effective eddy-current damper setup. For the electronics, a Teensy 4.1 runs the show, driving the four quadrants via a brace of AD5761 serial DACs and a few summing amplifiers. Three DACs generate the X, Y and Z signals, which are sent to the quadrants as Z+/-X and Z+/-Y, and the fourth DAC generates a sample bias signal. The tunnelling current picked up by the probe tip is first sent to a preamplifier constructed using a very high gain transconductance (current-to-voltage) amplifier. However, the part used was not identified. The whole assembly is electrically shielded with metallic tape, including the cable running down the main analog board, which hosts an LTC2326 ADC that can handle the bipolar differential signal being fed to it. The software was programmed using the Arduino stack for ease of use. The reason for the high-speed micro is the need to control the scanning signals based on the measured tunnelling current to form a control loop. We didn’t dig into precisely how that works! As can be seen from the video, they managed to get some quite decent images of the surface of a freshly peeled HOPG (graphite) lab specimen, so the setup works, and the noise sources are under control.

To read along, check out the project GitHub page, but more importantly, the original project by [Dan Berard.]

Thanks to [rolmie] for the tip!