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!

Many of us are very heavy computer users, and two items that can affect our comfort and, by extension, our health are the keyboard and the mouse. We’ve covered many ergonomic and customisable keyboards over the years, but we are not sure we’ve covered a fully adjustable mouse until now. Here’s [Charlie Pyott] with their second take on an adjustable mouse, the open source, statial-b.

[Charlie] goes into an extensive discussion of the design process in the video after the break, which is a fascinating glimpse into the methods used by a professional industrial designer. The statial concept breaks the contact surfaces of the mouse into fixed and moveable sections. The moveable sections are attached to the mouse core via a pair of ball joints connected with extendible arms, allowing the surfaces to be adjusted for both position and orientation. The design process starts with 3D scanning their ‘workhorse mouse,’ a Razer Deathadder Elite. This creates a reference volume within which the statial body should fit in its minimal configuration.

The design has a fixed central core, with each button (including the central scroller) separately adjustable. The side panel with a pair of thumb buttons is also moveable. Creating a model in Rhino 3D working with the grasshopper visual programming environment [Charlies] explored the surface constraints for the base, claw, finger and vertical grip styles common among mouse users. This model was then fed into Fusion 360 for the detailed design. After completing the design, it was passed back into Rhino 3D to add lattice effects to the panel. This helps reduce weight and lets the internal LEDs shine through. The design is intended for resin printing, so you could go wild with the visuals by missing custom resins if you were so inclined.

For the electronics, [Charlie] based the design around an Arduino Pro Micro, taking input from a PWM3389 laser direction sensor module. These are soldered to a simple base PCB, which also houses PH series connectors for the moveable switches to hook into. Check out the GitHub project page for all the files and an excellent build guide! As mentioned earlier, we don’t see many custom mouse hacks, but here’s a nice DIY gaming mouse to look into. If desk space is tight, perhaps a DIY trackball is in order? And while thinking about input devices, what about a neat DIY PCB-coil 3D mouse?

Thanks to [Keith] for the tip!

It’s not news that Leonardo DaVinci was somewhat ahead of his time, and over the centuries many of the creations in his sketchbooks have been created and proved quite functional. The guys from the YouTube channel How To Make Everything have been looking at one such sketch, a screw thread-cutting machine. At first glance, it seems a little flawed. Threads are hard to make by hand, and you can see that this thread-cutting machine needs two identical threads operating as a reference to make it work. However, as the guys demonstrate, you can create threads by hand using simple methods.

Starting with an offset blade mounted on a block with a hole through it, a dowel can be scribed with a starter thread. This can then be worked by hand to cut enough of a groove for the application. They demonstrated that the machine was viable using nothing but wood for construction. A metal blade was mounted, and some preload force was applied to it with a spring. The dowel to be cut was loaded, and the machine ran back and forth enough times to create a very nice-looking screw thread. And once you’ve made two identical threaded dowels, you can use them to upgrade the machine or even build a second. Once you have a repeatable way to make such threads, all kinds of applications become more accessible. Need a bench vice? No problem now!

Whilst the demonstration doesn’t precisely follow the plans laid out by the master inventor, they aren’t all that clear on the cutting tool after all, it’s nice to see people still wanting to build his ideas, and we’ll certainly be following along.

If you like these “from scratch” builds, you’ll like this other one. Leonardo’s work wasn’t just about machines; he was also very interested in science. Here’s a recreation of his demonstration of gravity as a form of acceleration.

Thanks to [Keith] for the tip!

Have you wanted to get into GPU programming with CUDA but found the usual textbooks and guides a bit too intense? Well, help is at hand in the form of a series of increasingly difficult programming ‘puzzles’ created by [Sasha Rush]. The first part of the simplification is to utilise the excellent NUMBA python JIT compiler to allow easy-to-understand code to be deployed as GPU machine code. Working on these puzzles is even easier if you use this linked Google Colab as your programming environment, launching you straight into a Jupyter notebook with the puzzles laid out. You can use your own GPU if you have one, but that’s not detailed.

The puzzles start, assuming you know nothing at all about GPU programming, which is totally the case for some of us! What’s really nice is the way the result of the program operation is displayed, showing graphically how data are read and written to the input and output arrays you’re working with. Each essential concept for CUDA programming is identified one at a time with a real programming example, making it a breeze to follow along. Just make sure you don’t watch the video below all the way through the first time, as in it [Sasha] explains all the solutions!

Confused about why you’d want to do this? Then perhaps check out our guide to CUDA first. We know what you’re thinking: how do we use non-nVIDIA hardware? Well, there’s SCALE for that! Finally, once you understand CUDA, why not have a play with WebGPU?

Lisp is one of those programming languages that seems to keep taunting us for not learning it properly. It is still used for teaching functional languages today. [Adam McDaniel] has an obvious fondness for this fifty-year-old language and has used it in several projects, including their own shell, Dune.

Dune is a shell designed for powerful scripting. Think of it as an unholy combination of bash and Lisp.

Dune is designed to be highly customisable, allowing you to create a super-optimised workstation for your admin and programming tasks. [Adam] describes the front end for Dune as having turned up the cosiness dial to eleven, and we can see that. A cosy home is personalised, and Dune lets you customise everything.

Dune is a useable functional programming environment with a reasonably complete standard library to back it up, which should simplify some of the more complicated sysadmin tasks. [Adam] says the language also supports a few metaprogramming concepts, such as a quote operator, operator overloading, and macro programming. It’s difficult to describe much more about what you can do with Dune, as it’s a general-purpose programming language wrapped in a shell. The possibilities are endless, and [Adam] is looking forward to seeing what you lot out there do with his project!

The shell can be personalised by editing the prelude file, which allows you to overload functions for the prompt text, the incomplete prompt text (so you can implement intelligent completion options), and a function that deals with the formatting of the command response text. [Adam] gives us his personal prelude file, which defines many helper functions displaying useful things such as the current weather, a calendar, and an ASCII art cat. You never know when that might come in handy. This file is written in Lisp, so we reckon that’s where many people will start as they come up the Lisp (re)learning curve before embarking on more involved automation. Dune was written in Rust, so you need that infrastructure to install it with Cargo.

As we said earlier, Lisp is not a new language. We found a hack for porting a Lisp interpreter to any old language and also running Lisp bare metal on a Lisp machine. Finally, [Al] takes a look at some alternative shells.

Should you be able to brick a keyboard just by writing a driver to flash the lights on it? We don’t think so either. [TheNotary] got quite the shock when embarking on a seemingly straightforward project to learn C++ on the x86-64 architecture with Windows and sent it straight to Silicon Heaven with only a few seemingly innocent USB packets.

The project was a custom driver for the XVX S-K80 mechanical keyboard, aiming to flash LED patterns across the key LEDs and perhaps send custom images to the integrated LCD. When doing this sort of work, the first thing you need is the documentation of the communications protocols. Obviously, this was not an option with a closed-source project, so the next best thing is to spy on the existing Windows drivers and see how they worked. Using Wireshark to monitor the USB traffic whilst twiddling with the colour settings, it was clear that communications were purely over HID messages, simplifying subsequent analysis. Next, they used x32dbg (now x64dbg, but whatever) to attach to the existing driver process and trap a few interesting Windows system calls. After reading around the Windows API, a few candidate functions were identified and trapped. This gave them enough information to begin writing code to reproduce this behaviour. Then things got a bit odd.

There apparently was a lot of extra protocol baggage when performing simple tasks such as lighting an LED. They shortened the sequence to reduce the overhead and noticed an additional byte that they theorized must encode the number of packets to expect in case only a subset of the LEDs were being programmed. Setting this to 0x01 and sending LED code for single keys appeared to work and was much faster but seemed unreliable. After a short experiment with this mystery value, [TheNotary] reverted the code to send all the packets for the full LED set as before, forgetting to correct this mystery value from the 0xFF it was programmed to during the experiment. They were surprised that all the LEDs and LCD were switched off. They were then horrified when the keyboard never powered up again. This value appeared to have triggered an obscure firmware bug and bricked it—a sad end to what would have been a fun little learning project.

Keyboard hacks are so plentiful it’s hard to decide where to start. How about upgrading the keyboard of your trusty ZX81? Here’s a lovely, minimal mechanical keyboard powered by a Pi Pico, and finally while we’re thinking about drivers bricking your stuff, who can forget FTDI gate? We may never forgive that one.

Header image: Martin Vorel, CC BY-SA 4.0.

We’ve covered a scanning laser project by Ben Make’s Everything last year, and now he’s back with a significant update. [Ben]’s latest project now offers a higher resolution and RGB lasers. A couple of previous versions of the device used the same concept of a rotating segmented mirror synchronised to a pulsed laser diode to create scanlines. When projected onto a suitable surface, the distorted, pixelated characters looked quite funky, but there was clearly room for improvement.

The previous device used slightly inclined mirrors to deflect the beam into scanlines, with one mirror per scanline limiting the vertical resolution. To improve resolution, the mirrors were replaced with identically aligned mirrors of the type used in laser printers for horizontal scanning. An off-the-shelf laser galvo was used for vertical scanning, allowing faster scanning due to its small deflection angle. This setup is quicker than then usual vector galvo application, as the smaller movements require less time to complete. Once the resolution improvement was in hand, the controller upgrade to a Teensy 4 gave more processing bandwidth than the previous Arduino and a consequent massive improvement in image clarity.

Finally, monochrome displays don’t look anywhere near as good as an RGB setup. [Ben] utilised a dedicated RGB laser setup since he had trouble sourcing the appropriate dichroic mirrors to match available lasers. This used four lasers (with two red ones) and the correct dichroic mirrors to combine each laser source into a single beam path, which was then sent to the galvo. [Ben] tried to find a DAC solution fast enough to drive the lasers for a proper colour-mixing input but ended up shelving that idea for now and sticking with direct on-off control. This resulted in a palette of just seven colours, but that’s still a lot better than monochrome.

The project’s execution is excellent, and care was taken to make it operate outdoors with a battery. Even with appropriate safety measures, you don’t really want to play with high-intensity lasers around the house!

Here’s the previous version we covered, a neat DIY laser galvo using steppers, and a much older but very cool RGB vector projector.

Thanks to [Chan] for the tip!

[Ken] from the YouTube channel What’s Ken Making is back with another MiSTer video detailing the TapTo project and its integration into MiSTer. MiSTer, as some may recall, is a set of FPGA images and a supporting ecosystem for the Terasic DE10-Nano FPGA board, which hosts the very capable Altera Cyclone V FPGA.

The concept behind TapTo is to use NFC cards, stickers, and other such objects to launch games and particular key sequences. This allows an NFC card to be programmed with the required FPGA core and game image. The TapTo service runs on the MiSTer, waiting for NFC events and launching the appropriate actions when it reads a card. [Ken] demonstrates many such usage scenarios, from launching games quickly and easily with a physical ‘game card’ to adding arcade credits and even activating cheat codes.

As [Ken] points out, this opens some exciting possibilities concerning physical interactivity and would be a real bonus for people less able-bodied to access these gaming systems. It was fun to see how the Nintendo Amiibo figures and some neat integration projects like the dummy floppy disk drive could be used.

TapTo is a software project primarily for the MiSTer system, but ports are underway for Windows, the MiSTex, and there’s a working Commodore 64 game loader using the TeensyROM, which supports TapTo. For more information, check out the TapTo project GitHub page.

We’ve covered the MiSTer a few times before, but boy, do we have a lot of NFC hacks. Here’s an NFC ring and a DIY NFC tag, just for starters.

Thanks to [Stephen Walters] for the tip!

It seems like only yesterday we covered a project using QR codes to archive data on paper (OK, it was last Thursday), so here’s another way to do it, this time with a dedicated codec using the full page. Optar or OPTical ARchiver is a project capable of squeezing a whopping 200 Kb of data onto a single A4 sheet of paper, with writing and reading achieved with a standard laser printer and a scanner. It’s a bit harder than you might think to get that much data on the page, given that even a 600 DPI printer can’t reliably place every dot each time. Additionally, paper is rarely uniform at the microscopic scale, so Optar utilizes a forward error-correcting coding scheme to cater for a little irregularity in both printing and scanning.

The error-correcting scheme selected was an Extended Golay code (24, 12, 8),  which, interestingly, was also used for image transmission by the NASA Voyager 1 and 2 missions. In information theory terms, this scheme has a minimum Hamming Distance of 8, giving detection of up to seven bit errors. This Golay code implementation is capable of correcting three-bit errors in each 24-bit block, with 12 bits available for payload. That’s what the numbers in those brackets mean.

Another interesting problem is paper stretch during printing. A laser printer works by feeding the paper around rollers, some of which are heated. As a printer wears or gets dirty, the friction coefficient along the rollers can vary, leading to twisting and stretching of the paper during the printing process. Water absorbed by the paper can also lead to distortion. To compensate for these effects, Optar regularly inserts calibration targets throughout the bit image, which are used to locally resynchronize the decoding process as the image is processed. This is roughly similar to how the alignment patterns work within larger QR codes. Finally, similar to the position detection targets (those square bits) in QR codes, Optar uses a two-pixel-wide border around the bit image. The border is used to align to the corners well enough to locate the rows of bits to be decoded.

In the distant past of last week, we covered a similar project that uses QR codes. This got us thinking about how QR codes work, and even if encoding capacity can be increased using more colors than just black and white?

Thanks to [Petr] for the tip!

For many of us of a particular vintage, the internet blossomed in the ’90s with the invention of the Web and just a few years of development. Back then, we had the convenience of expression on the WWW and the backup of mature services such as IRC for all that other stuff we used to get up to. Some of us still hang out there. Then something happened. Something terrible. Big-commerce took over, and it ballooned into this enormously complex mess with people tracking you every few seconds and constantly trying to bombard you with marketing messages. Enough now. Many people have had enough and have come together to create the Tildeverse, a minimalist community-driven internet experience.

Tilde, literally ‘ ~ ‘, is your home on the internet. You can work on your ideas on a shared server or run your own. Tilde emphasises the retro aesthetic by being minimal and text-orientated. Those unfamiliar with a command line may start getting uncomfortable, but don’t worry—help is at hand. The number of activities is too many to list, but there are a few projects, such as a collaborative Sci-Fi story, a radio station, and even a private VoIP server. Gamers are catered for as long as you like Minecraft, but we think that’s how it should go.

The Tildeverse also supports Gopher and the new Gemini protocol,  giving some people a few more options with which to tinker. The usual method to gain access is to first sign up on a server, then SSH into it; you’re then taken to your little piece of the internet, ready to start your minimalist journey into the Tildeverse.

A couple of videos after the break go into much more detail about the whys and hows of the Tildeverse and are worth a chunk of your time.

We’ve talked about the ‘small web’ before. Here’s our guide to Gemini.

Thanks to [Andrew] for the tip!

We don’t get enough electrochemistry hacks on these pages, so here’s [Markus Bindhammer] of YouTube/Marb’s lab fame to give us a fix with their hand-built general-purpose electrochemistry device.

The basic structure is made from plyboard cut to size on a table saw and glued’n’screwed together. The top and front are constructed from an aluminium sheet bent to shape with a hand-bender. A laser-printed front panel finishes the aesthetic nicely, contrasting with the shiny aluminium. The electrode holders are part of off-the-shelf chemistry components, with the electrical contacts hand-made from components usually used for constructing stair handrails. Inside, a 500 RPM 12 V DC geared motor is mounted, driving a couple of small magnets. A PWM motor speed controller provides power. This allows a magnetic stirrer to be added for relevant applications. Power for the electrochemical cell is courtesy of a Zk-5KX buck-boost power supply with a range of 0 – 36 V at up to 5 A  with both CV and CC modes. A third electrode holder is also provided as a reference electrode for voltammetry applications. A simple and effective build, we reckon!

Over the years, we’ve seen a few electrochemical hacks, like this DIY electroplating pen, a DIY electrochemical machining rig, and finally, a little something about 3D printing metal electrochemically.

A few years back NVIDIA created a dedicated cryptocurrency mining GPU, the CMP 170HX. This was a heavily restricted version of its flagship A100 datacenter accelerator, using the same GA100 chip. It was intended for accelerating Ethash, the Etherium proof-of-work algorithm, and nothing else. [niconiconi] bought one to use for accelerating PCB electromagnetic simulations and put a lot of effort into repairing the card, converting it to water-cooling, and figuring out how best to use this nobbled GPU.

Typically, the GA100 silicon sits in the center of the mighty A100 GPU card and would be found in a server rack, cooled by forced air. This was not an option at home, so an off-the-shelf water-cooling block was wedged in. During this process, [niconconi] found that the board wouldn’t power on, so they went on a deep dive into the power supply tree with the help of a leaked A100 schematic. The repair and modifications can be found in the appendix, right down to the end of the article. It is a long read to get there.

NVIDIA has a history of deliberately restricting silicon in consumers’ hands to justify the hefty price tags of its offerings to big businesses, and this board is no different. The plan was to restrict the peak performance of the board to only applications with the same compute requirements as Ethash, specifically memory-intensive algorithms. The FP64 performance was severely limited, but instructions were not removed. This meant the code would run really badly, considering what the GPU is capable of.

The memory was limited to 8 GB, despite some A100 cards hosting a whopping 80 GB. The strategy was to use fuses to limit the crucial instructions, particularly the FP32 FMA and MAD instructions, which are used for multiply-add operations and are crucial for general computing applications. Finally, the PCIe bus was nobbled to run only as a Gen 1 interface with a single lane. They reduced the lane count by removing the coupling capacitors on the PCB, which meant they could just be added later, but it’s still only a slow interface.

[niconconi] went into great detail benchmarking the instruction types, keeping their EM simulation application in mind. After a few tweaks to make it work, they determined it was a good purchase. This article is worth reading for all those hardcore GPU nerds!

If you need a primer on GPU mining, we’ve got you covered. Once you’ve understood proof-of-work crypto, perhaps take a look at Chia?

Thanks to [gnif] for the tip!

IO user [monte] was pointed towards an 1898 display patent issued to a [George Mason] and liked the look of the ‘creepy’ font it defined. The layout used no less than 21 discrete segments to display the complete roman alphabet and numerals, which is definitely not possible with the mere seven segments we are all familiar with. [monte] then did the decent thing and created a demonstration digit using modern parts.

For the implementation, [monte] created a simple PCB by hand (with an obvious mistake) and 3D-printed an enclosure and diffuser to match. After a little debugging, a better PCB was ordered from one of the usual overseas factories. There isn’t a schematic yet, but they mention using a CH32V003 Risc-V micro, which can be seen sitting on the rear of the PCB.

Maximum flexibility is ensured by storing every glyph as a 32-bit integer, with each LED corresponding to a single bit. It’s interesting to note the display incorporates serifs, which are definitely optional, although you could display sans-serif style glyphs if you wanted to. There is now a bit of a job to work out how to map character codes to glyph codes, but you can have a go at that yourself here. It’s still early doors on this project, but it has some real potential for a unique-looking display.

We love displays—every kind. Here’s a layout reminiscent of a VFD digit but done purely mechanically. And if you must limit yourself to seven digits, what about this unique thing?

There’s something magical about volumetric displays. They really need to be perceived in person, and no amount of static or video photography will ever do them justice. [AncientJames] has built a few, and we’re reporting on his progress, mostly because he got it to run a playable port of DOOM.

As we’ve seen before, DOOM is very much a 3D game viewed on a 2D display using all manner of clever tricks and optimizations. The background visual gives a 3D effect, but the game’s sprites are definitely very solidly in 2D land. As we’ll see, that wasn’t good enough for [James].

The basic concept relies on a pair of 128 x 64 LED display matrix modules sitting atop a rotating platform. The 3D printed platform holds the displays vertically, with the LEDs lined up with the diameter, meaning the electronics hang off the back, creating some imbalance.

Lead, in the form of the type used for traditional window leading, was used as a counterbalance. A Raspberry Pi 4 with a modified version of this LED driver HAT is rotating with the displays. The Pi and both displays are fed power from individual Mini560 buck modules, taking their input from a 12 V 100 W Mean-Well power supply via a car alternator slip ring setup. (Part numbers ABH6004S and ASL9009  for those interested.) Finally, to synchronise the setup, a simple IR photo interrupter signals the Pi via an interrupt.

The base contains a DC motor driving the platform with a 224:20 reduction ratio using a GT2 timing belt to help reduce noise. [James] reports that running at 700 RPM was the limit for the current version, giving an acceptable update frame rate. Too high, and the vibration and chassis flex was excessive. The base does little else other than house that power supply and support a 400 mm acrylic garden light dome. We wouldn’t want to run this without such protection, which might not even be enough.

There are quite a few details to consider in such a build. One is the need to reduce the angle of perception of the LED display using a 3D printed slat-type collimator in front of each unit. You only want to perceive the LEDs head-on, or the POV effect is ruined. However, most of the details are in the software.

To that end, [James] took the entire game logic of the ‘Doom Generic’ port, removing the code that renders the 3D parts of the scene. The 2D menus and in-game panels are rendered by projecting the image onto a cylinder. That was easy. [James] took a minimalist path for the room scenes, as fully solid walls looked too busy. The viewport automatically zooms into any ongoing battles, so monsters zoom into focus if nearby, but objects behind closed doors and too far around corners are discarded. No spoiler alerts! The models were lifted from Chello’s Voxel Doom mod, giving a fitting 3D upgrade to gameplay. This is an ongoing project, so we’ll keep track and report back!

We’ve reported on a few volumetric displays over the years, like this tiny one based on an OLED display. Even a volumetric CCTV system. But they can’t run DOOM. Speaking of which, here’s what it looks like ray-traced.

Thanks to [Keith] for the tip!

[Mike] from Leaded Solder has a soft spot for old computers, and a chance encounter with a friend sent them deep down the deep hole that is the world of 80s and 90s-era Japanese home computers.  Many people playing with these machines have all kinds of issues to deal with, such as rotting cartridges, failing components, and just dirt and mank in critical places. [Mike] decided that working on an MSX-standard custom programmable cartridge would be sensible, but then got stuck on how the MSX cartridge mapping works.

You may recall that the MSX platform is not a single computer but a standard to which many (mainly Japanese) manufacturers designed their products. This disconnected the software writers from the hardware makers and is essentially a mirror of the IBM-PC clone scene.

The MSX is based around the Z80, which has a 16-bit address bus, restricting it to 64K of ROM or RAM. The MSX has two cartridge slots, an ‘internal’ slot for the BIOS and RAM and a fourth for ‘misc’ use. Each of these is mapped internally into the physical address space. The cartridge slots have 64K of addressable space mapped into the Z80 physical space.

If this was not complicated enough, many MSX games and applications exceeded this restriction and added a layer of mapping inside the cartridge using bank switching. A register in the cartridge could change the upper bits of the address allowing ROMs larger than 64K.

[Mike] wanted to replicate the method Konami used for their games. Their first target was The Maze of Galious, which requires a 128K ROM. Their scheme requires additional hardware to map each of the four 16K slots in the cartridge interface to four of the eight 16K slots of the ROM chip. The game selects which bits of the ROM it needs as the game progresses. The implementation uses an old 74LS670, which can still be bought from old stock as a 4×4 bit register file and a two-way dip selector switch. This allowed [Mike] to fit four games into a single SST39SF040 4MBit parallel flash chip. After a few false starts with the details of address bit selection, they were rewarded by Galious booting up without any additional work needed. If you own an MSX-compatible machine and want to build one for yourself, the full KiCAD project is available on the project GitHub page.

The MSX isn’t a well-known platform in the West, and MSX hacks are a rarity here, but in the spirit of retro, here’s a hack to add support for a retro gamepad to the MSX. Also, if you can’t find a period MSX, you can always build one.

Neon lamps are fun to play with. These old-school indicators were once heavily utilized in many types of equipment for indication purposes but now seem largely relegated to mains voltage indication duties. Here’s a fun video by [Ashish Derhgaen], discussing the photoelectric effect of neon lamps with some simple demonstrations.

[Ashish] demonstrates the well-known photoelectric effect by triggering a sub-biased neon lamp with visible light from an LED. Neon bulbs work on the principle of voltage-induced ionization, creating a visible glowing plasma. If the applied voltage is high enough, around 60 to 80 V, electrons get knocked off the neutral neon atoms. The now free electrons, roaming around highly energized, will eventually come across a neon ion (missing an electron) and recombine to make it neutral again.

The results are a lower total energy state, and the difference in energy is resolved by the emission of a photon of light, which, in the case of neon, is a dull reddish-orange. Nothing unusual there. However, nothing will happen if the applied voltage bias is just below this device-specific threshold. There’s not enough energy to strip electrons.

Apply an external light source, and this threshold can be exceeded. The photons from the LED are just energetic enough to strip a small number of electrons from the surface of the electrodes, and this causes a cascade, or avalanche effect, lighting up the plasma and turning on the neon lamp. Take away the external light source, and it dies down and goes dark.

The video also shows an interesting effect due to the wavelength of applied light. The photon energy needed to release an electron depends on the atom it strikes. Neon bulbs have all manner of electrode materials. [Ashish] shows that a particular neon lamp can be excited to emit a specific wavelength corresponding to a certain energy level. With some materials science work, this can then be used to ascertain what the electrode material is. Finally, the video shows some simple astable and relaxation oscillators initiated by light, making us wonder if one neon bulb could activate some neighboring bulbs and create a neat wave propagation effect for some electrode material and bias levels? You can see in the video that when the spectrum thrown from the prism is passed over the bulb, it illuminates in the orange section. So this could work. If you know, then do let us know with some examples.

Neon light hacks are plentiful around here. Neon lamps have many other uses beyond indication, even detecting sound. Of course, they look nice, but driving them is a hassle. Why not just fake the look with modern tech?

[GloriousCow] has started working on a series of investigations into the various historical floppy disk copy protection schemes used in the early days of the IBM PC and is here with the first of these results, specifically Formaster’s Copy-Lock.

The game in question is King’s Quest by Sierra Entertainment, which used a ‘booter disk’ with the Copy-Lock protection scheme. Instead of having to boot DOS separately, you could just insert this disk and the game would launch automatically. Early copy protections often used simple methods, like adding sectors with non-standard sizes or tampering with sector CRC values to create disk errors. Copy-Lock employed several such tricks together, making it challenging for standard floppy disk hardware to replicate. In the case of Copy-Lock, Sector 1 on track 6 was intentionally written as only 256 bytes, with a 256-byte blank section to fill the gap. Additionally, the CRC was also altered to add another layer of protection.

When attempting to read the disk, the PC BIOS interrupt routine assumes it’s looking for a standard 512-byte sector, so when a “read sector” command is issued to locate the sector, it never finds it. To detect a dodgy copy, the game bypasses the BIOS and talks directly to the floppy disk controller using some custom code. The first part of the code uses the standard INT 13h routine to seek to track 6, sector 1, where it expects a fail since there is no valid sector there. Next, the floppy controller sends the “read track” command to perform a raw dump of all 512 bytes at this address and looks for a magic number, 0xF7, sitting in the final byte. That empty second half of the short sector is indeed not empty and is the check the game makes to determine if it was written with the Copy-Lock capable hardware. That last point is pertinent; you can’t create this disk structure with a standard IBM PC floppy disk controller; you need specialised hardware that can write different-sized sectors and incorrect CRCs, and that costs money to acquire.

We recently covered the copy protection scheme used for Dungeon Master on the Atari ST and the Amiga. If you’re thinking less about how a floppy got cracked and copied and more about how to preserve these digital relics, check this out!

Battery management is a tedious but necessary problem that becomes more of a hassle with lithium-ion technology. As we’re all very aware, such batteries need a bit of care to be utilized safely, and as such, a huge plethora of ICs are available to perform the relevant duties. Hackaday.IO user [Erik] clearly spent some time dropping down the same old set of ICs to manage a battery in their applications, so they created a drop-in castellated PCB to manage all this.

The little board, measuring just a smidge over 22 x 16mm, packs a fair amount of capability, with an ATTiny1616 to make it customisable. The Injoinic tech IP2312, which is intended to be supplied from USB sources, takes care of charging with a programmable current set by a resistor, as is typical. The battery output is switched by a beefy MOSFET, with the output first passing through a measurement resistor and being sensed by an INA219 bidirectional current monitor. This might be useful for monitoring charging via the microcontroller. An APX803 low-voltage lockout/supervisor IC enables an LD56100 LDO to ensure no load is supplied to the battery below the low-voltage threshold. This is important! This provides a 3.3V rail to all the other ICs on the board, which is always on when the battery voltage is high enough. Utilising interrupts in the ATTiny firmware means the controller remains mostly asleep, consuming as little power as possible and preserving battery standby time. Temperature measurement is courtesy of the TMP102 with a ADS1015 quad channel 12-bit delta-sigma ADC also wedged in for some auxiliary sensing. These additional analog channels are not actually used by the module but are presented on the IOs. These could be very handy for detecting external inputs relevant to battery management with some custom Arduino-compatible firmware.

Implementation-wise, [Erik] provides PCB footprint details for both Eagle and KiCAD and an example application circuit detailing hookup and programming. So long as you ensure the UDPI pin in connected to a UART as shown in the application circuit, developing and uploading custom application code should be simple. Check out the project GitHub for more details.

Topics of power management and batteries are plentiful. Here’s a nice, hackable power meter for starters. Here’s an interesting story about extracting perfectly useable LiPo cells from perfectly useless disposable vapes and, finally, a possible method for mitigating electrode damage due to constant current charging.

3D printing is all well and good for making low numbers of units, so long as they’re small enough to print in a reasonable time, but what if you want to go really big? Does a 35-hour print time sound like a fun time? Would it even make it that long? [Nathan] from Nathan Build Robots didn’t fancy the wait, so they embarked on a project to build a huge parallel 3D printer with four independent print heads. Well, kind of.

The premise seems obvious at first glance: More print heads mean more plastic is laid down per unit of time. As long as you can maximise the nozzle diameter and machine speed, it should theoretically be possible to speed things up massively. But it doesn’t work like that. The custom machine they constructed utilises a polar coordinate system, with a rotating bed (the ‘theta’ axis) and four radial axis gantries arranged at 90 degrees to each other. Each gantry has its own independent extruder, so multilateral printing is also an upfront option. [Nathan] laments that the problem with constructing such a beast is not so much the mechanical aspects but the limitations in the current firmwares out in the wild. There are also more complex considerations at the slicing level, so getting the machine to operate as desired is quite a large programming task! Right now, this means that each radial axis must operate in lock-step, meaning objects to be printed must be rotationally symmetric of order four. Another option is to print four copies of a much smaller object in parallel, which has its use cases, but that’s not their end goal. [Nathan] says he was going for a record-breaking 20kg print. However, multiple issues with alignment over height and bed adhesion, not to mention keeping the extruders fed with fresh filament, scuppered this first attempt.

There are some large hurdles regarding alignment. The four corner verticals can be out of alignment with each other in all sorts of ways, causing the radial axis to shift as the Z axis moves. We suspect that’s just one glaring problem, and other more subtle issues are waiting in the wings to cause problems in the future, but we’ll keep an eye on this and see where it goes!

We covered a few projects turning up the 3D printing knobs lately. Here’s a big printer, for big prints. Our thoughts about speed printing and, lastly, a fascinating machine mod that optimises colour swapping by having automated hot end swapping.