2026-03-26 07:00:13
In the maker world, it’s the Arduino and ESP32 lines that get the lion’s share of attention. However, you can do fantastic things with PIC chips, too, if you put the dev time in—it’s just perhaps less likely another maker has done so before you. A great example is this VGA output project from [grecotron].
A PIC18F47K42 is perhaps not the first part you would reach for to pursue any sort of video-based project. However, with the right techniques, you can get the 8-bit microcontroller pumping out the pixels surprisingly well. [grecotron] was able to get the chip outputting to a VGA monitor at a resolution of 360 x 480 with up to 16 colors. It took some careful coding to ensure the chip could reliably meet the timing requirements for the standard and to get HSYNC, VSYNC, and the color signals all dancing in harmony. Aiding in this regard was that the chip was clocked with a 14.3182 MHz crystal to make it easy to divide down from all the internal timers as needed. Supporting hardware is light, too—primarily consisting of a VGA connector, a couple of multiplexers, and resistor ladder DACs for the color signals. Files are on Github for those interested in deeper detail on the work.
VGA output is possible to implement on all kinds of microcontrollers—and even a bunch of raw logic if you know what you’re doing. If you’re pursuing your own video output wizardry, be sure to let us know on the tipsline.
2026-03-26 04:00:07
Digital clock projects have been with us since the 1970s, when affordable LEDs and integrated circuits became available. In 2026 most of them use a microcontroller, but for the AliExpress fans there’s one that goes straight back to the ’70s with a pile of logic chips. You can make it on the supplied PCBs, but that wasn’t for [ALTco]. Instead, he made the circuit in free form, using six metres of brass wire.
The construction is anchored together by a set of busbars that carry sockets for a set of seven-segment and driver modules. The circuit is typical for the day, with a crystal oscillator and divider chain feeding the counters for the displays. There are a few clever tricks that older engineers might recognize in order to reduce the chip count. In this case that’s negated by an extra set of circuitry allowing the time to be set from a rotary encoder.
We’re impressed by the intricacy of the device, made bit by bit without a plan, it as some wires what thread their way between others. It’s a truly beautiful piece, and it reminds us of our circuit sculpture contest back in 2020.
2026-03-26 02:30:41
This week Jonathan chats with Milo Schwartz about Pangolin, the Open Source tunneling solution. Why do we need something other than Wireguard, and how does Pangolin fix IoT and IT problems? And most importantly, how do you run your own self-hosted Pangolin install? Watch to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
Direct Download in DRM-free MP3.
If you’d rather read along, here’s the transcript for this week’s episode.
Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
2026-03-26 01:00:44
Digital Convergence Corporation is hardly a household name, and there’s a good reason for that. However, it raised about $185 million in investments around the year 2000 from companies such as Coca-Cola, Radio Shack, GE, E. W. Scripps, and the media giant Belo Corporation. So what did all these companies want, and why didn’t it catch on? If you are old enough, you might remember the :CueCat, but you probably thought it was Radio Shack’s disaster. They were simply investors.
The :CueCat was a barcode scanner that, usually, plugged into a PC’s keyboard port (in those days, that was normally a PS/2 port). A special cable, often called a wedge, was like a Y-cable, allowing you to use your keyboard and the scanner on the same port. The scanner looked like a cat, of course.
However, the :CueCat was not just a generic barcode scanner. It was made to only scan “cues” which were to appear in catalogs, newspapers, and other publications. The idea was that you’d see something in an ad or a catalog, rush to your computer to scan the barcode, and be transported to the retailer’s website to learn more and complete the purchase.
The software could also listen using your sound card for special audio codes that would play on radio or TV commercials and then automatically pop up the associated webpage. So, a piece of software that was reading your keyboard, listening to your room audio at all times, and could inject keystrokes into your computer. What could go wrong?
You might think this was some tiny startup that died with a whimper, but Radio Shack, Forbes, Wired, and several major newspapers were onboard. The :CueCat cost about $6.50 to produce, but most people never bought one. Radio Shack, Forbes, and Wired were giving them away.
The problem is, even free was too high a price for most people. To use the device, you had to register and complete a long survey full of invasive questions. Then the software showed you an ad bar. Digital Convergence had your demographic info, your surfing habits, and knew what you were scanning.
Even then, the scanner solved a non-problem. If you saw something in a Radio Shack catalog, for example, it was probably not so hard to go to their website and search for it by title or stock number. Especially if you were sitting in front of your computer. If you weren’t… well, then, the :CueCat didn’t help you in that case, anyway.
It is easy to look back on this and think, “What a bad idea?” But Digital Convergence and its investors were in a full-blown media blitz. The video below shows a contemporary demo of the technology.
If you still aren’t sold, look at how happy the woman in the Radio Shack commercial is that she didn’t have to manually search the web for her next phone purchase.
Problem solved, right? Want to buy that new ham radio? Scan the code, and you don’t have to type “Alinco” into a search box! Even the table of contents in the 2002 RadioShack catalog was festooned with barcodes.
The RadioShack catalog might have been an exception, though. A 2001 issue of Forbes magazine showed sparing use of the barcodes and no obvious ones linking to big advertisers. You would think the advertisers would have been a prime target, even if you had to make deals to get them onboard.
Naturally, hacks immediately appeared. Drives from [Pierre-Philippe Coupard] and [Michael Rothwell] allowed you to use the :CueCat without the invasive software or registration. You could even scan normal barcodes like UPC codes. Radio Shack and others wound up simply giving away $6.50 barcode scanners.
While people were already prickly about the amount of information gathered and the tracking, hackers found a report file on a public server that revealed personal info about 140,000 users — a huge number for the year 2000.
With hackers attacking both the hardware and the company’s website, Digital Convergence had to act. They changed their license, claiming that you didn’t own the scanner and forbidding reverse engineering. There were no real lawsuits, but there were threats and, as you might imagine, that just made things worse.
By 2001, there were a very few USB-native :CueCats distributed. But the bad publicity and the lack of usefulness took its toll. By mid-year, most of the 225 employees at Digital Convergence had been let go. Later in the year, the investors decided to stop using the tech entirely.
By 2005, you could buy the now-surplus devices for $0.30 each, as long as you agreed to take 500,000 or more of them. You can still find them on the used market if you look. Open source software is still around that can make them do useful things, but honestly, unless you’re hacking it into a custom hardware setup, your phone is a better barcode scanner.
You can still find some of the contemporary teardowns of the :CueCat online. There were, apparently, several revisions of the hardware, but at least one version had a cheap CPU, a serial EEPROM, an 8 KB static RAM, and a handful of small parts. For a free device, the insides looked pretty good.
Of course, now we have QR codes. But these are somewhat more private, work with the ubiquitous cell phone, and even then haven’t caught on in the way Digital Convergence had planned.
Was it a good idea? That’s debatable. But giant privacy grabs usually go poorly. Granted, in 2000, that might not have been as obvious as it is today. But it still doesn’t keep companies from finding it out all over again.
Featured image: The :CueCat. Photo by [Jerry Whiting]
2026-03-25 23:30:30
Tech has a problem, an e-waste problem. Google is a common offender when it comes to this, creating a product just to end support a couple of years later. Thankfully, there are some lasting capabilities left in their defunct Stadia controllers. After hearing about these capabilities, [Bringus Studios] managed to turn this future e-waste into something new: a Bluetooth adapter for game controllers.
To give some credit to Google, once they announced the Stadia program was winding down, they released an updated firmware that let you use the controller as a generic Bluetooth gamepad. But there was also a rather unusual feature added — if another controller is connected to it via USB, its output will be passed along over Bluetooth as if it was coming from the Stadia controller itself.
This would allow you to wirelessly connect an Xbox 360 or PlayStation 3 controller to your computer, for example. But while a neat trick, having the two controllers plugged into each other is a bit awkward. So [Bringus Studios] decided to take the Stadia controller apart and turn it into a dedicated Bluetooth interface.
Unfortunately, a fair amount of Dremel work was required to fully disassemble the device. Additional PCB modifications allowed for tricking the main board into default joystick positions and removing some button boards. Slap a 3D printed box around the Frankenstein’d hardware and you’ll be able to add Bluetooth capability to a wide array of USB controllers.
While the end result can’t be used with every single controller, it still gives a unique use case for a defunct product. If you have some spare time, maybe check out the e-waste graveyard, where you too can turn abandoned products into something new.
2026-03-25 22:00:58
The Linux world is currently seeing an explosion in new users, thanks in large part to Microsoft turning its Windows operating system into the most intrusive piece of spyware in modern computing. For those who value privacy and security, Linux has long been the safe haven where there’s reasonable certainty that the operating system itself isn’t harvesting user data or otherwise snooping where it shouldn’t be. Yet even after solving the OS problem, a deeper issue remains: the hardware itself. Since around 2008, virtually every Intel and AMD processor has included coprocessors running closed-source code known as the Intel Management Engine (IME) or AMD Platform Security Processor (PSP).
These components operate entirely outside the user’s and operating system’s control. They are given privileged access to memory, storage, and networking and can retain that access even when the CPU is not running, creating systemic vulnerabilities that cannot be fully mitigated by software alone. One practical approach to minimizing exposure to opaque management subsystems like the IME or PSP is to use platforms that do not use x86 hardware in the first place. Perhaps surprisingly, the ARM-based Apple M1 and M2 computers offer a compelling option, providing a more constrained and clearly defined trust model for Linux users who prioritize privacy and security.
Before getting into why Apple Silicon can be appealing for those with this concern, we first need to address the elephant in the room: Apple’s proprietary, closed-source operating system. Luckily, the Asahi Linux project has done most of the heavy lifting for those with certain Apple Silicon machines who want to go more open-source. In fact, Asahi is one of the easiest Linux installs to perform today even when compared to beginner-friendly distributions like Mint or Fedora, provided you are using fully supported M1 or M2 machines rather than attempting an install on newer, less-supported models. The installer runs as a script within macOS, eliminating the need to image a USB stick. Once the script is executed, the user simply follows the prompts, restarts the computer, and boots into the new Linux environment. Privacy-conscious users may also want to take a few optional steps, such as verifying the Asahi checksum and encrypting the installation with LUKS but these steps are not too challenging for experienced users.
Changing the operating system on modern computers is the easy part, though. The hard part is determining exactly how much trust should be placed in the underlying hardware and firmware of any given system, and then deciding what to do to make improvements. This is where Apple Silicon starts to make a compelling case compared to modern x86 machines. Rather than consolidating a wide range of low-level functionality into a highly privileged black box like the IME or PSP, Apple splits these responsibilities more narrowly, with components like the Secure Enclave focusing on specific security functions instead of being given broad system access.
Like many modern systems, Apple computers include a dedicated security coprocessor alongside the main CPU, known as the Secure Enclave Processor (SEP). It runs a minimal, hardened operating system called sepOS and is isolated from the rest of the system. Its primary roles include securely storing encryption keys, handling sensitive authentication data, and performing cryptographic operations. This separation helps ensure that even if the main operating system is compromised, secrets managed by the SEP remain protected.
To boot an Apple Silicon computer, a “chain of trust” is followed in a series of steps, each of which verifies the previous step. This is outlined in more detail in Apple’s documentation, but starts with an immutable boot ROM embedded in the system-on-chip during manufacturing. It first verifies early boot stages, including the low-level bootloader and iBoot, which in turn authenticate and verify the operating system kernel and system image before completing the boot process. If any of these verification steps fail, the system halts booting to prevent unauthorized or compromised code from executing.
Perhaps obvious at this point is that Apple doesn’t sign Asahi Linux images. But rather than allowing unrestricted execution like many PCs, or fully locking down the device like a smartphone, Apple’s approach takes a middle way. They rely on another critical piece of “security hardware” required to authorize that third-party OS: a human user. The Asahi Linux documentation discusses this in depth, but Apple’s secure boot system allows the owner of the computer to explicitly authorize additional operating systems by creating a custom boot policy within the user-approved trust chain. In practice, this means that the integrity of the boot process is still enforced, but the user ultimately decides what is trusted. If a boot component is modified outside of this trust chain, the system will refuse to execute it. In contrast to this system, where secure boot is enforced by default and only relaxed through explicit user action, x86 systems can treat these protections as optional. A motivated x86 user can achieve a comparable level of security, but they must assemble and maintain it themselves, as well as figure it out in the first place.
The limited scope of Apple’s Secure Enclave gives it a much smaller attack surface compared to something like the Intel Management Engine. As mentioned before, the IME combines a wider range of functionality, including features designed for low-level remote system management. This broader scope increases its complexity and, by extension, its attack surface which has led to several high-profile vulnerabilities. Apple’s Secure Enclave, by contrast, is designed with a much narrower focus. That’s not to say it’s a perfect, invulnerable system since it’s also a closed-source black box, but its limited responsibilities inherently reduce that attack surface.
It’s also worth mentioning that there are a few other options for those who insist on x86 hardware or who refuse to trust Apple even in the most minimal amount, but who still consider the IME and its equivalents as unacceptable security risks. Some hardware manufacturers like NovaCustom and even Dell have given users the option of disabling the IME (although this doesn’t remove it entirely), and some eight and ninth generation Intel machines can have their management engines partially disabled by the user as well. In fact these are the computers that my own servers are based on for this reason alone. Going even further, it is possible to get a 2018-era Thinkpad to run the open-source libreboot firmware. However, libreboot installations can become extremely cumbersome, and even then you’ll be left with a computer that lacks the performance-per-watt and GPU capabilities of even the lowest-tier M1 machines. In my opinion, this compromise of placing a kernel of trust in Apple is the lesser evil for most people in most situations, at least until libreboot is able to support more modern machines and/or until the libreboot installation process is able to be streamlined.
I’ll also note here that Apple is far from a perfect company. Their walled garden approach is inherently anti-consumer, and they’ve rightly taken some criticism for inflating hardware costs, deliberately making their computers difficult to repair, enforcing arbitrary divisions between different classes of products to encourage users to buy more devices, and maintaining a monopolistic and increasingly toxic app store.
But buying an M1 or M2 machine on the used market won’t directly give Apple any money, and beyond running the Asahi installer script doesn’t require interacting with any Apple software or their ecosystem in any way, beyond the initial installation. I’ve argued in the past that older Apple computers make excellent Linux machines for these reasons as well, and since the M1 and M2 machines eliminate the IME risk of these older computers they’re an even better proposition, even without considering the massive performance gains possible.
Ultimately, though, the best choice of hardware depends on one’s threat model and priorities. If the goal is to minimize exposure to IME/PSP-level risks while retaining semi-modern performance, an M1/M2 Mac with Asahi Linux is one of the best options available today. But if fully open hardware is non-negotiable, you’ll need to accept older or less powerful machines… for now.
