Restoring A Soviet ES-4001 Mainframe Control Panel

October 22, 2026 by Maya Posch 19 Comments

Recently the [Chornobyl Family] got their hands on an ES-4001 control panel for a 1970s-era Soviet mainframe, with the intention to restore it to full working order. Not just because they’re really into cool old Soviet technology, but also because of the connection that this control panel holds to the Chernobyl nuclear accident that was so instrumental to the area in modern times.

The Duga-1 computer room with what's left of the ES-1060 mainframe. (Credit: Chornobyl Family, YouTube) — The Duga-1 computer room with what’s left of the ES-1060 mainframe. (Credit: Chornobyl Family, YouTube)

During the 1970s the USSR felt that it could not be left behind in the race to create better digital computers. This led them to not only create a few original designs, but also effectively clone the IBM System/360 and System/370. This resulted in the ES EVM-series of mainframes, with an ES-1060 finding itself installed at the Duga-1 early warning radar system near what is now the Chornobyl nuclear power plant in Ukraine.

Although the radar arrays are the most well-known feature of the Duga-1, below it is the computer center where the ES-1060 was installed. It was never put into service following the ChNPP Unit-4 accident — all that remains of a once pinnacle of Soviet engineering are the picked-over carcass of the mainframe and its control panel.

The control panel in question was obtained was from the early 1980s, serving a more gentle service life in a datacenter and looks to be in a mostly good condition. That said, there was still enough to be done to make it work and undo the damage of its violent removal from the mainframe. Along the way we also learn how the system was used and how the control panel works.

Although similar in some ways to the System/370, it’s still very different, and with only about 300 of these mainframes produced, it’s worth saving whatever elements still remain today, along with the surviving documentation.

Continue reading “Restoring A Soviet ES-4001 Mainframe Control Panel” →

Using A Waffle To Check The Health Of Your Wii U’s NAND Flash

October 13, 2026 by Maya Posch 14 Comments

Game consoles tend to have a weak spot or two that will take certain units out sooner than they would due to normal parts aging. In the case of the Wii U it’s the eMMC storage IC with the console’s firmware and any user data that likes to keel over, with the SK Hynix variant reportedly developing faulty cells much sooner than the Samsung and Toshiba chips. If you want to check the health of these eMMC ICs in your Wii U, you can do so easily now with the Wafel Installer project by [zer00p].

This doesn’t take much more than navigating to the wafel.xyz URL on the Wii U to launch the installer on any (unmodified) Wii U, or alternatively starting it from an SD card if you’re running a homebrew-enabled console. This can also install the Stroopwafel CFW, ISFSax and the Aroma homebrew environment, but the NAND testing option in the installer’s menu is what you want to select if you’re not into homebrew or have already cracked open the console for said sweet homebrew action.

All of this is covered in this video by [FunkyScott47], whose Wii U’s Samsung-branded eMMC is fortunately still all fine, but it shows off the variety of tests available. Unless the eMMC is already quite cooked this should take only a minute or two, so it’s pretty good for ease of mind.

With the heavily waffle, syrup and stroopwafel-coded naming scheme for these tools we can not be held responsible for a sudden case of the munchies, of course.

Continue reading “Using A Waffle To Check The Health Of Your Wii U’s NAND Flash” →

Open Firmware Fixes Dead Onkyo AV Receivers

October 13, 2026 by Tom Nardi 3 Comments

If you’ve been reading Hackaday for any length of time, you’ll know we love seeing hackers replacing the stock firmware on their devices with open source alternatives. Usually this is done because the open firmware offers more features, or lifts some arbitrary limitation. But if you find yourself installing OSIRIS on an Onkyo AV receiver such as the TX-NR717, it’s probably because you’re trying to bring the thing back to life.

As developer [Jokūbas] explains, certain Onkyo receivers that use the Texas Instruments D830 are known to suffer from a very specific failure — the device will power on and appear functional, but no audio will come through. When this happens, it’s either because the D830 itself has failed or the 64 MiB NAND flash chip that holds the firmware it runs is cooked. Unfortunately, replacing either component is a bit more difficult than you might expect.

Everything passes through the Texas Instruments D830. If it goes, you’ve got a problem.

If you swap the D830 with a pin-compatible chip that’s easier to find and less prone to failure, the stock firmware won’t boot. If you try to replace the NAND, you’ll find that the original software is only capable of addressing 512-byte pages, while the flash you’ll find on the market today uses 2 KiB or 4 KiB pages. In both cases, it’s OSIRIS to the rescue.

The open firmware not only supports D830 compatible chips such as the OMAP-L137, but it’s able to address modern NAND flash, making the replacement of either or both component far more practical. With fresh hardware and the new firmware installed, your Onkyo receiver should spring back to life. That said, OSIRIS isn’t feature complete yet, and truthfully the items listed as untested or not implemented on the feature list currently outnumber the entries for what actually does work. But at least it’s a start.

Of course, not all the burned out parts on your Onkyo receiver require a firmware flash to replace. Sometimes a misbehaving unit just needs to have a few of its passive components replaced.

Repairing A Couple Of Very Expensive Registered DDR5 RAM Sticks

October 7, 2026 by Maya Posch 43 Comments

It’s definitely a sign of the times when repair shops get handed sticks of registered ECC DDR5 RAM by businesses to try and fix, rather than just tossing the defective ones and slotting in a fresh bunch. This is how [northwestrepair] ended up with two of these ECC RDIMMs, with a current market valuation of a rather nice budget car.

The 128 GB stick was first on the bench, with the fault being that it would fail DDR5 training on boot. This suggests that one or more of the DRAM BGA packages had developed a cracked solder joint, which is something that you could conceivably fix with more diagnosing and testing for a single IC reballing.

In this case doing a reflow cycle was enough to bring the RAM back to life, with the DDR5 training now passing without issues in a test system.

For the 256 GB stick things wouldn’t be so easy, as it seemed completely dead. This suggested a dead PMIC, as this is the component on DDR5 RAM responsible for ensuring that the DRAM ICs even power on. The SPD ROM was another option, so that got swapped first, which does require reprogramming the RDIMM. For this the earlier SPD dump image was reflashed, but swapping this chip made no difference.

After some additional reflowing of a few suspect ICs, still nothing happened. Following this a lot of reballing and other troubleshooting steps followed, only for the problem to be one shorted MLCC and a broken PMIC, potentially caused by whoever dropped said RDIMM onto the server room floor.

Cracked MLCCs do appear to be a very common cause of failures, as they’re often used as filter capacitors, same as for this RDIMM. Checking for shorts across a number of such MLCCs can be a good way to shorten a diagnostic cycle. Since this RDIMM was dropped, reballing every IC probably was still a good move as this may have cracked some solder balls.

Continue reading “Repairing A Couple Of Very Expensive Registered DDR5 RAM Sticks” →

A Headset Fit For A Hackaday Writer

October 6, 2026 by Jenny List 22 Comments

I started writing this from a commuter train passing at speed through the outskirts of London, and my headset had just broken. The flexible joint that attaches one earpiece to the headband has snapped, leaving the earpiece dangling on its cable. This is annoying on its own, but what is annoying me enough to write about it is that this isn’t the first time. This is only the latest in a succession of headsets I’ve taken on the road with me has broken, not because of rough treatment, but simply due to flimsy or bad design. What on earth can I do about this?

Failure Built-In

The earpiece of an EPOS headset, detached from its band. — Failure inevitable: the whole headset relied on a tiny piece of plastic in the centre.

The most recent three have been a JVC whose rotating joint allowing the earpiece to lie at a slight angle with my ear has failed, a quite expensive Logitech whose ear sponges failed closely followed by its USB cable, and now an EPOS whose ball joint has failed.

I repaired the JVC and got a bit more life out of it and I’ll have a go at repairing this EPOS, but that’s hardly the point. I’m paying not inconsequential money and I’m getting good sound quality and electronics, but I’m not getting anywhere near the mechanical quality I need. I could buy a set of tough DJ headphones such as the Sennheiser HD25, but they don’t come with a microphone, they’re not a headset.

So if I can’t buy a decent headset without spending military grade money on one from an F16 fighter, what can I do to make my own? I’m an engineer, damnit!

At its most basic, a headset is a springy band that goes over the head, with an earpiece at its end. But a human head is not a cube with vertical parallel sides, it’s a complex shape and every one is different. So those earpieces have to have some “give” in them in order to fit comfortably against the ear. In the simplest case this is achieved by giving the earpiece a soft surround that moulds itself to the ear, but most headsets incorporate some articulation. The earpiece must rotate a little around a vertical line parallel with the ear, and also with a horizontal line at right angles to the axis of the ear. The EPOS managed both axes by means of a ball joint, while the JVC had a stirrup with pins to achieve the horizontal motion, and a circular joint — the part which broke — for the vertical. In both case the weak point was a thin part of the plastic moulding which broke, on the EPOS a short stalk for the ball in the ball joint, and in the JVC a similar stalk for the circular joint. Any design I come up with must avoid this type of weak point, and spread the load of an earpiece over considerably more material than my broken headset. Continue reading “A Headset Fit For A Hackaday Writer” →

Tearing Down A Heavy Oscilloscope

October 4, 2026 by Al Williams 13 Comments

When [Thomas] showed his 1960s-era Tektronix 545A oscilloscope in a recent video, it made us both nostalgic and happy. Nostalgic because we miss the days when our oscilloscopes were “mainframes” that could take plug-in modules. Happy because we noticed the two handles on top to manage hauling the almost 70 pounds of tubes, transformers, and glass around if you didn’t have the requisite cart.

Not only did old scopes have plugins so you could reconfigure them, but there were also handy plugins and racks that could power them so you could build different test setups easily. This scope was an early version of that idea, but it only accepted a vertical section plugin. The mainframe part of the scope has 75 tubes, and the plugin, a type D, has six tubes, too. The power consumption was about 500 watts!

Continue reading “Tearing Down A Heavy Oscilloscope” →

The Game Boy Test Lab Provides A Cartridge-Sized Diagnostic Lab

October 2, 2026 by Maya Posch 10 Comments

Most of the time when you see a repair video of a Game Boy it’ll be demonstrated with a cartridge inserted and booting up into the game, but does this actually mean that the system is truely fully functional? There can still be more intermittent faults, dodgy buttons, or even something like a defective link port — all of which can be much harder to detect than firing up a copy of Tetris. This is where the GB Test Lab cartridge by [Marcel Pflug] of the Game Boy Museum comes into play.

With the freely available ROM put on an EverDrive or similar flash cartridge, you can test a whole range of functions of the original Game Boy (DMG-01), most of them autonomously and some with some user input.

This is similar to the test cartridge that Nintendo themselves used in the form of the DMG-AGING-01, which validated the basic functionality of the handheld. Since then a myriad of test cartridges have been created by the homebrew community, but not all try to test quite literally everything possible. In the case of the GB Test Lab this includes the typical like CPU, RAM, interrupts, etc., but also key bounce time, intermittent connectivity and playing a game of Pong between two GBs connected by link cable as well as using the GB Printer.

Results are saved per GB and persisted if the flash cartridge has battery backup or similar. Overall it seems quite comprehensive and something that’s worth giving a shot if you’re the kind of person who owns one or more GBs. Perhaps the neatest part of this ROM is that it also contains a built-in reference for all the components and other useful details, including how to interpret results and symptoms.