Abusing SQL To Play DOOM

Most laypeople who encounter SQL think of it purely as a tool for managing large datasets. While that is certainly what it was designed for, SQL is still a programming language at its core. It includes many of the features found in general-purpose languages like C or Python, and although it wasn’t built for general-purpose work, it can handle a surprising range of tasks that programmers might not expect to use it for. To demonstrate its capabilities, and perhaps to show off their skills with SQL, a group at CedarDB ported the original DOOM to this language.

The project stores the WAD data (essentially everything except the engine) in a series of tables, which was fairly straightforward compared to the rest of the project. Where it gets more complicated is managing the timing that ties the game to 35 fps, and of course rendering the images. Their rendering process takes up 1300 lines of SQL across 89 common table expressions (CTEs) which is certainly advanced for this language. The rest of the project is another 4000 lines of SQL, with a bit of Python to handle the keyboard inputs, timing, and display of the generated bitmap.

Perhaps counterintuitively, DOOM might be the perfect game to run on SQL. It was built in an era before dedicated graphics cards and isn’t truly 3D, meaning that the programmers had to do a lot of tricks to get it to look as if it is 3D. This results in a lot of data transformations uniquely suited to SQL. It’s almost like DOOM‘s original renderer was built by someone with extensive SQL knowledge in the first place. For those looking to try this out, the source code for the project is available on a GitHub page, and for some other unique implementations of DOOM there’s also this version built in regular expressions and this one in Microsoft Word.

The Low-Level Waste Dumps In The Atlantic Have Become Ecosystems

Dumping of the barrels into the Atlantic. (Credit: Greenpeace, Pierre Gleizes)
Dumping of the barrels into the Atlantic. (Credit: Greenpeace, Pierre Gleizes)

Recently French and international researchers took a look at the state of the thousands of barrels of radioactive waste that were dumped into the Atlantic Ocean between 1950 and 1990, trying to ascertain the state of this waste and its effect on the ecosystem.

Although a lot of fuss is made of the spent uranium fuel and high-level waste produced by light water reactors and fuel reprocessing facilities, the overwhelming majority of nuclear waste is low- and intermediate-level waste (LLW and ILW) churned out by hospitals, laboratories and various industries.

Due to the sheer volume of this waste over the decades creative ways have been sought to dispose of it, which include burying in landfills and incinerating.

For a while tossing such waste into the ocean was also deemed to be an excellent destination for LLW and ILW, with the latter especially encapsulated in bitumen or cement. This was the poured into the barrels that many people have come to associate with nuclear waste in general. Since the approximately 200,000 tons of such barrels and similar were tossed into the Atlantic Ocean decades ago the question was where they ended up and their state.

The Radiocean mission site lists the objectives, including the mapping of the sites and identifying the elements of the ecosystems in addition to any radioisotope levels and their effect on said ecosystems. As it turns out, although the barrels have definitely degraded and their contents are slowly collapsing, the local ecosystems seem to have adapted well, treating the dump sites more as convenient shelters rather than a hazard. Some more photos can be found on the Bluesky account of [Javier Escartin].

None of this should come as a surprise if you are aware of just how much radioactive material is already dissolved naturally in the oceans, with much more uranium present in seawater than can be mined on-shore. Although the introduction of isotopes that are not part of the normal thorium and uranium decay chains into the ocean is of course undesirable, it’s good to know that this rather haphazard treatment of LLW and ILW has apparently just resulted in some Atlantic Ocean floor critters ending up with an interesting reef.

Reviving The PoE++ Feature On A Ubiquiti Switch

Recently [The Parallel Port] was asked to take a look at repairing the PoE++ feature on a Ubiquiti switch that otherwise worked fine. This is a pretty nice 24-port rackmounted switch with 2.5 Gbit-capable RJ-45 ports and two 10 Gbit SFP+ ports, so by itself it’s pretty useful, but having the 400 Watt PoE feature just go AWOL still stings, especially if you bought it new for $800.

With power applied the switch starts up as normal, including its 1.3″ touch screen that provides direct port information as well as a fancy screensaver cum QR code for the AR feature.

After logging into the switch’s BusyBox console it showed that all ports reported bad for the PwrGood status, and there were PoE power status request errors in the log, but this could be just the consequence of something else. Using a PoE splitter it was confirmed that the PoE functionality was indeed dead.

After disassembly and some testing with a multimeter and thermal camera, a short and related hot spot on the PCB that the PoE power board connects to was identified, with the short persisting after removing this PCB from the switch. Since the switch had suffered a bit of an electrical event the TVS diode was checked, but it turned out to be fine.

Next to it, marked as fuses, were protective thyristor surge protection devices (Trisil), functioning as a crowbar device. These aren’t supposed to be shorted to ground until a surge event occurs, but these were indeed both shorted when measured directly. Clearly they had taken the brunt of the electrical event and sacrificed themselves in the process.

One replacement later of these devices the switch now happily reports a good PoE status and even was able to power a DC fan via the PoE splitter. Even if it wasn’t a particularly hard fix, this is definitely one of those cases where knowing how the protective circuit works can save a lot of time in diagnosing and fixing a fault.

Continue reading “Reviving The PoE++ Feature On A Ubiquiti Switch” →

Pi Pico Recreates The Heathkit Pocket Packet

Packet radio is a particularly fun part of the ham radio hobby. Once upon a time, you might have squirted data about the airwaves using something like the Heathkit HK-21 Pocket Packet. Heathkit stopped being a going concern some time ago, but [btech] has now recreated the device with modern hardware.

[btech] has called the project the Pocket Pico, and like the hardware that inspired it, it acts as a terminal node controller for amateur packet radio. It literally runs the same firmware as the real HK-21. It achieves this by using the Raspberry Pi Pico to run a Z80 processor emulator that can run the same code, while also using the microcontroller to do the work of modulating and demodulating Bell 202 audio tones at 1200 baud to avoid the need for a dedicated modem chip.

Thanks to running the same firmware as the HK-21, you can use the Pocket Pico with lots of old packet radio software. It’s fully capable of doing APRS as well as AX.25 Level 2, and has a built in Personal Bulletin Board System for other stations to leave messages.

If you’re looking to get into packet radio, you might just find this project to be useful. Alternatively, you might like taking a look at some other projects we’ve featured in this space, like the capable OpenModem project. Video after the break.

Continue reading “Pi Pico Recreates The Heathkit Pocket Packet” →

Investigating A Rare Burnout 3 Beta Disc

These days, it’s pretty easy to buy old retail console games just by hunting online auction sites. It’s much rarer to come across a disc holding a beta version that was only ever intended for internal us, and yet, that’s precisely what landed in [MattKC’s] hands—a copy of the Beta 3 release of Burnout 3 for the original Xbox. He thus set about the task of investigating the differences to the retail release and preserving the beta for the future.

The first task involved figuring out how to read the disc. Retail Xbox games show up as a DVD Video disc if you put them into a PC, which can complicate reading them. However, being a burnt beta disc for use in an Xbox devkit, this one was a little different. It was easy enough to read and dump with a regular DVD drive and some common tools for ripping Xbox ISOs.

From there, it was a matter of comparing the dumped disc to the retail PAL release. There wasn’t a lot of differences to find—with [MattKC] noting that the beta was dated just six days before the official retail release. Mostly, this beta had just a few localization differences in non-English languages compared to the final release. Still, [MattKC] nonetheless was able to preserve this curio for the future, and it now lives on the Internet Archive for future generations to enjoy. Perhaps the diehard Burnout 3 fans will one day decide that PAL Beta 3 is the ultimate version of the game.

It’s always interesting to get a look behind the scenes of big-time game development. We’ve taken a look at console devkits before, too—hardware that is never intended for the public to see.

Continue reading “Investigating A Rare Burnout 3 Beta Disc” →

Hackaday Podcast Episode 388: RAM-Swapping On Raspberry Pi, Raindrops On Radar, And A Fine Mesh

This week, Hackaday Editors Elliot Williams and Al Williams had a lot to talk about. From advice for a young hacker to using a laser to break into a microcontroller, there was plenty to cover from the week in Hackaday.

From the “Point/Counter Point” department, there were dueling posts about how big a deal it is for Raspberry Pi to lock out RAM chip swapping. Ever want to do interactive debugging in MicroPython? For intellectual exercise, there’s the physics of raindrops becoming a radar antenna. If you are a history buff, there was even news about World War I codebreaking.

For the can’t-miss articles, the big news was the issues with LoRa mesh communities possibly clashing with the FCC rules and how to make your computer take dictation.

Check out the links if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download an MP3 created with ultra premium ones and zeros.

Continue reading “Hackaday Podcast Episode 388: RAM-Swapping On Raspberry Pi, Raindrops On Radar, And A Fine Mesh” →

Did The BBC And Sir Clive Get It Right Twenty Years Ago?

Predictions of the future are often laughable when reviewed in the years for which they are made. For example, here in 2026 we neither live on the Moon, nor have flying cars. But sometimes they come closer to the reality than others, and in that the BBC Archive have an interesting offering. It’s a Newsnight feature from 2006 looking at the future of artificial intelligence, and since its main interviewee is none other than Sir Clive Sinclair, it’s worth a second look.

Watching the video it’s a shock to be reminded that 2006 was twenty years ago, as in so many ways it’s close enough to touch. Back then we had laptops with Windows or Linux, we had the Web, and HDTV, as we do today. But as we sat in our Ford Focus family car it would be on a Nokia that we rang home; while technically a smartphone it was nothing like the Apple and Android devices that would take the world by storm in the following years. Sir Clive is positive about the development of AI as he saw it then, seeing it as providing knowledge based services such as education or healthcare from your computer. The following interviewee from British Telecom perhaps puts his finger on the pulse the most, predicting a path “Over the next few years” that seems pretty familiar to us a couple of decades later.

So for once this is a future prediction that doesn’t seem too outlandish. Aside from Sir Clive’s appearance it’s packed with retro technology goodies, so it’s well worth a watch below.

Continue reading “Did The BBC And Sir Clive Get It Right Twenty Years Ago?” →