[Leaded Solder] took on an interesting challenge. The BBC, apparently, produced a game console known as the BBC Bridge Companion that connected to your TV and helped you learn to play Bridge back in 1985. At £200, we doubt many were sold new, but there were nine ROM cartridges available, presumably at an additional cost. [Leaded Solder] doesn’t care about playing bridge, but decided to teach the computer itself to play Tetris.
Inside is what you might expect for 1985. A Z80 and TI video chip, although naturally enough, it is the PAL variant. With 16K of VRAM the machine would have been very capable for its day. Unlike some game systems, the Bridge Companion runs its own code before launching what’s on the ROM cartridge. That required a few evenings of reverse engineering to figure out the correct header. Meanwhile, the surplus real hardware needed a quick repair on its cartridge slot before he could test it with real metal.
There were more hurdles, including adapting the PAL output for a composite monitor. Don’t miss the second part of the series for more technical details, and we’ll be interested in following the posts to their conclusion later this month.
Oddly enough, we think this is the first time the BBC Bridge Companion has made an appearance on Hackaday. However, we’ve had no shortage of card shufflers.
If you’re water cooling a PC, it’s generally accepted that you need some interface between the coolant and the chips — a water block of copper or aluminum that carries the heat-removing fluid. What if you just…didn’t? That’s what [TrashBench] asked with his direct water cooling experiment. Instead of integrated pump or copper water block, he just epoxied a 3D printed pipe fitting onto his bare GPU and CPU.
The results are interesting: while the directly-cooled GPU outperforms the professional system by a decent margin, the same technique fails when applied to the CPU. It also leaks and nearly ruins his hardware, but those are the risks you take when doing mad science, and it’s nothing more epoxy can’t fix. In any case, the fact that directly exposing chips to liquid can cool them down isn’t exactly a revelation. People have been dunking computers in oil for years, but the fact that he sees such a difference between CPU and GPU is quite interesting. [TrashBench] has his own theory in the video, but what do you think is going on here?
Sandboxing a Linux process usually means spending a lot of effort deciding what it isn’t allowed to see. You might put it in a mount namespace, bind-mount a few directories into place, hide some others, add a chroot, and generally construct a carefully restricted version of the filesystem. But a new Linux kernel feature is about to change all of that. Instead of carefully hiding most of the filesystem, why not just take the filesystem away?
That’s essentially the idea behind FailFS, a tiny pseudo-filesystem expected to land in Linux 7.3. As the name suggests, it doesn’t do very much. In fact, that’s the point: every operation that reaches FailFS returns EOPNOTSUPP, meaning “operation not supported.”
The interesting bit is what happens when a process uses FailFS as its root or current working directory. At that point, normal pathname lookup essentially ceases to work. Absolute paths fail. Absolute symbolic links fail. Relative paths using the normal current-directory mechanism fail. If the application tries to open /etc/passwd, there simply isn’t a useful /etc to find.
Some of the cotton candy options by the machine. The Chinese text reads ‘flower type’.
Having a fully automated cotton candy vending machine in your possession is a great thing, but not if you do not have full access to its software. With [Block’s Retro Repairs] getting ghosted by the manufacturer on regaining account access to the machine he bought used for $300, there was little left but to try and break into the system.
We previously covered the journey in getting the vending machine back into a state where it’d actually reliably produce cotton candy again, a process which is quite tedious and temperamental. After a lot of fiddling with sensors and temperature settings this was fixed, but still left the issue that as a vending machine it should allow the owner to set prices and such. Sadly this could only be done remotely via a special account, which access to had been left with the previous owner.
Despite the very custom exterior, the vending machine runs what is effectively an Android system, consisting of an industrial computer board wired into a lot of stepper drivers and other control boards. To the extreme delight of everyone involved, it was possible to access the Ct Terminal application with adb and its product database on the device’s storage. Unfortunately writing back a changed database file didn’t change anything in the UI, so for a few months the project languished.
After nearly bricking the system and ending up factory resetting the control software including temperatures, it actually improved the performance of the machine and produced cotton candy, so that was one win. Ultimately the solution was to modify the original app, but a combination of weak coding skills and the app being in Chinese led him to use free LLM coding chatbots to assist here.
This resulted in a custom settings menu being added with the ability to modify pricing, no need for online access any more and a very nice cotton candy vending machine for the private arcade where presumably friends and family can enjoy cheap or even free cotton candy. Finally having the machine sealed against ant intrusion was also a major improvement.
When the Chernobyl Nuclear Power Plant’s #4 reactor experienced an extreme criticality event on that infamous day in 1986, the resulting steam explosion and lack of any kind of containment building meant that parts of the core were scattered throughout the site. In an extensive update to the original 2023 video, the [Chornobyl Family] covers the mad scramble to design robots to perform on-the-ground measurements, and ultimately remove all this debris for safe disposal.
The TR-1A, an early debris removal robot. (Source: Chornobyl Family, YouTube)
This essentially took the form of a hackathon, involving teams from all over the USSR and allied nations, creating the most diverse range of robots that 1980s Soviet technology and later Western technology could muster.
Many of these robots didn’t perform very well, or at all, mostly due to the bypassing of any kind of testing before deployment. Especially at the beginning of the clean-up the robots were being pushed into the high-radiation zones as soon as they were finished, with not only mechanical issues being a problem, but also with e.g. inaccurate radiation measurements by the RR-1 robot, that overstated measurements by more than a factor of ten. Meanwhile the RR-2 and RR-3 were too top-heavy and after deployment by helicopter simply tipped over. Eventually manual measurements proved to be faster and safer.
Early debris removal robots like the TR-1A were rather simplistic, with successive generations of robots over the next weeks and months improving on it. The use of a combustion engine instead of batteries provided to be a boon, as combustion engines are far less affected by radiation.
The BAER Beloyarets used an airport cart as the basis, with its electronics relying on vacuum tube technology and relays, with an internal combustion engine. This proved to be one of the most reliable designs and it’s been largely preserved on display in the Chornobyl Exclusion Zone, with many others of these robots also being on display around the nuclear plant or in the city of Chornobyl.
Overall an absolutely dizzying number of robotic designs were invented on the spot, adapted from existing designs or repurposed for operation in a high-radiation zone. Eventually bulldozer designs like the STR-1 helped to push radioactive debris off the roofs into containers, massively reducing the radioactive contamination of the area.
The fact that following #4’s RUD the other three RBMK units were able to keep operating safely without risks to its operators, and with the zone now safe for tourists, is a real testament to the success of the worst hackathon imaginable. Many of the lessons learned are relevant today, including during the decommissioning of Fukushima Daiichi’s melted-down cores.
This week’s Hackaday podcast is a European affair again, as Elliot Williams is joined by Jenny List on a summer evening to review the week. And we have a feast of hacks for your delectation.
As the title above says, one of the stand-out hacks this week was a set of airless mountain bike tyres 3D printed in glorious fluorescent TPU. They look as though they shouldn’t work but in fact they showed real promise, and we discuss the process behind their design. Then we take a look at a hybrid of a UV printer and an SLA 3D printer, capable of making high-resolution and robust 3D prints. The prospect of new Amigas intrigues us for a while, then carbon-fibre fabric in 3D prints.
Finally we’re in awe of the tech behind the Las Vegas Sphere, and we’re there for some radio at the Danish BornHack hacker camp. Follow that one up and you’ll find a bonus, an unofficial extra Hackaday podcast.
All the usual links are below, but before you head on down to have a listen, don’t forget we’ve got a mailbag for the podcast and we’d love to hear from you!
Given that the no doubt totally sustainable build-out of data centers has sent both solid state and magnetic hard drive prices soaring, though, [WNY Over The Air] decided to take a look back at optical disks — specifically the high-density BDXL disks — and see how they do hosting the music library for his Plex server, among other things.
Price wise, well, it’s going to vary depending where you are in the world and exactly when you look. But Blu-ray pricing is looking competitive to hard drives again, and that even goes for the long-lasting, archival-quality “M-disks” that are supposed to last 1000 years in ideal conditions. Of course if you’re playing with LLM Agents, having your precious data on a Write Once Read Many medium like Blu-ray also has the advantage of keeping the agent from wiping it out, which [WNY] takes pains to point out.
That might be obvious, but what’s less obvious is that once the disk has had its metadata queued by his media-streaming Plex server the M-disk is plenty fast enough for streaming music with no noticeable lag. That load time does happen every time you load in a fresh disk, but how often would you be swapping out 100 GB of songs? Even with lossless formats like FLAC, that’s a few thousand tracks. If you’ve already got a Blu-ray drive and are hard up for storage, it might make sense right now to move your music to an optical disk while waiting for drive pries to normalize.
The window where this makes financial sense might not last long, and we’ll be back to wondering where to store our data. All we can say is that’s probably not going to be audio tape, as cool as a reel-to-reel would look in the server room.
