People enjoy retrocomputing for a wide variety of reasons – sometimes it’s about having a computer you could fully learn, or nostalgia for chips that played a part in your childhood. There’s definitely some credit to give for the fuzzy feeling you get booting up a computer you built out of chips. Old technology does deteriorate fast, however, and RAM chip failures are especially frustrating. What if you got a few hundred DRAM chips to go through? Here’s a DRAM chip tester by [Andreas]/[tops4u] – optimized for scanning speed, useful for computers like the ZX Spectrum or Oric, and built around an ATMega328P, which you surely still have in one of your drawers.

The tester is aimed at DIP16/18/20 and ZIP style DRAM chips – [Andreas] claims support for 4164, 41256, 6416, 6464, 514256, and 44100 series RAM chips. The tester is extremely easy to operate, cheap to build, ruthlessly optimized for testing speed, sports a low footprint, and is fully open-source. If you’re ever stuck with a heap of RAM chips you want to quickly test one by one, putting together one of these testers is definitely the path to take, instead of trying to boot up your well-aged machine with a bunch of chips that’d take a while to test or, at worst, could even fry it.

[Andreas] includes KiCad PCB and Arduino source files, all under GPL. They also provide adapter PCBs for chips like the 4116. What’s more, there are PCB files to build this tester in full DIP, in case that’s more your style! It’s far from the first chip tester in the scene, of course, there are quite a few to go around, including some seriously featureful units that even work in-circuit. Not only will they save you from chips that failed, but they’ll also alert you to fake chips that are oh so easy to accidentally buy online!

USB PD is a fun protocol to explore, but it can be a bit complex to fully implement. It makes sense we’re seeing new stacks pop up all the time, and today’s stack is a cool one as far as code reusability goes. [Vitaly] over on Hackaday.io brings us pdsink – a C++ based PD stack with no platform dependencies, and fully-featured sink capabilities.

This stack can do SPR (5/9/15/20V) just like you’d expect, but it also does PPS without breaking a sweat – perfect for your Lithium Ion battery charging or any other current-limited shenanigans. What’s more, it can do EPR (28V and up) – for all your high-power needs. For reference, the SPR/PPS/EPR combination is all you could need from a PD stack intended for fully taking advantage of any USB-PD charger’s capabilities. The stack is currently tailored to the classic FUSB302, but [Vitaly] says it wouldn’t be hard to add support for a PD PHY chip of your choice.

It’s nice to have a choice in how you want your PD interactions to go – we’ve covered a few stacks before, and each of them has strong and weak sides. Now, if you have the CPU bandwidth, you could go seriously low-tech and talk PD with just a few resistors, transistors, and GPIOs! Need to debug a particular USB-C edge case? Don’t forget a logger.

Now, Rock 5 ITX+ is no x86 board, sporting an ARM Rockship RK3588 on its ITX form-factor PCB, but reading this blog post’s headline might as well give you the impression. [Venn] from the [interfacinglinux.com] blog tells us about their journey bringing up UEFI on this board, thanks to the [EDK2-RK3588] project. Why? UEFI is genuinely nice for things like OS switching or system reconfiguration on the fly, and in many aspects, having a system management/configuration interface for your SBC sure beats the “flash microSD card and pray” traditional approach.

In theory, a UEFI binary runs like any other firmware. In theory. For [Venn], the journey wasn’t as smooth, which made it very well worth documenting. There’s maybe not a mountain, but at least a small hill of caveats: having to use a specific HDMI port to see the configuration output, somehow having to flash it onto SPI flash chip specifically (and managing to do that through Gnome file manager of all things), requiring a new enough kernel for GPU hardware acceleration… Yet, it works, it really does.

Worth it? From the looks of it, absolutely. One thing [Venn] points out is, the RK3588 is getting a lot of its features upstreamed, so it’s aiming to become a healthy chip for many a Linux goal. From the blog post comments, we’ve also learned that there’s a RPi UEFI port, even if for a specific CPU revision of the Model 5B, it’s still a nifty thing to know. Want to learn more about UEFI? You can start here or here, and if you want a fun hands-on example, you could very well start by running DOOM.

Connected devices are ubiquitous in our era of wireless chips heavily relying on streaming data to someone else’s servers. This sentence might already start to sound dodgy, and it doesn’t get better when you think about today’s smart glasses, like the ones built by Meta (aka Facebook).

[sh4d0wm45k] doesn’t shy away from fighting fire with fire, and shows you how to build a wireless device detecting Meta’s smart glasses – or any other company’s Bluetooth devices, really, as long as you can match them by the beginning of the Bluetooth MAC address.

[sh4d0wm45k]’s device is a mini light-up sign saying “GLASSHOLE”, that turns bright white as soon as a pair of Meta glasses is detected in the vicinity. Under the hood, a commonly found ESP32 devboard suffices for the task, coupled to two lines of white LEDs on a custom PCB. The code is super simple, sifting through packets flying through the air, and lets you easily contribute with your own OUIs (Organizationally Unique Identifier, first three bytes of a MAC address). It wouldn’t be hard to add such a feature to any device of your own with Arduino code under its hood, or to rewrite it to fit a platform of your choice.

We’ve been talking about smart glasses ever since Google Glass, but recently, with Meta’s offerings, the smart glasses debate has reignited. Due to inherent anti-social aspects of the technology, we can see what’d motivate one to build such a hack. Perhaps, the next thing we’ll see is some sort of spoofed packets shutting off the glasses, making them temporarily inoperable in your presence in a similar way we’ve seen with spamming proximity pairing packets onto iPhones.