Although once little more than an academic endeavor, the RISC-V architecture is slowly supplanting applications that would have normally gone to ARM. Even a few microcontrollers have chips running this open-source instruction set now, and we expect it to grow in the future since it doesn’t require the licensing of an ARM or x86 chip. [M_Jagadeesh97] is getting ahead of the curve with this retro gaming system built on a custom-designed RISC-V system.
Most of us, presumably including [M_Jagadeesh97], don’t have access to chip fabrication tools, but what we can get is any of various FPGAs. This RISC-V CPU is built on a Terasic DE0-Nano board with 32 MB of RAM available to it, and boots to a launcher with 32 games available. There are a few limitations with this low-power system which was largely solved by limiting the display to 64×32, which lets it maintain the same aspect ratio as the original DOOM as well as the same aspect ratio for many of the older games, while still maintaining 45 FPS.
The project writeup goes deep into the design of a system like this, from the bare metal, the CPU design, the timing of the video signals, and how to implement a Wolfenstein-like raycaster. After adding a small display it looks to be fairly portable as well and is an excellent demonstration of how powerful inexpensive boards like this FPGA can be with the proper amount of effort.
Although the term ‘quantum battery’ is a bit of a vague term, the cell that [Kieran Hymas] et al. demonstrate in a recent paper does seem to suggest that it uses quantum effects to charge faster than would otherwise be possible, with this rate increasing faster than its volume, meaning at a superextensive rate.
The general idea behind a quantum battery is that these somehow use a quantum effect to store and release energy faster than would be possible using classical physics. First proposed in 2013, the initial Dicke model saw its theoretical quantum advantage shot down by 2020, leading to the search for alternative models.
We have previously seen claims of a quantum advantage in batteries based on the Sachdev-Ye-Kitaev model, such as by [Davide Rossini] et al., but this new paper may be the first prototype cell demonstrating a reproducible effect.
In the here demonstrated cell a microcavity is created with strong light-matter coupling, allowing for both energy storage and discharging, with the illuminated particles super-absorbing the light with what the researchers claim to be due to these particles cooperating using a quantum mechanism. Effectively scaling up the cell would thus scale up the charge- and discharge rate faster than in a conventional chemical cell.
Whether this demonstration can be replicated and expanded upon remains to be seen, naturally. The stored energy in this experiment was very small and the storage time only very brief, so for now it serves primarily as an interesting experimental result for researchers to dig through.
Although not technically the first virtual pet, the Tamagotchi handhelds certainly popularized the idea and made it a worldwide phenomenon. In the late 90s it was hard to go out in public and not see them dangling from backpacks and belt loops. They turned out to be more than a passing fad, too. There have been Tamagotchis in various forms since then, and one of the latest, the Tamagotchi Paradise, is uniquely hackable thanks to this custom UART interface.
The build starts with a simple and inexpensive CH340G UART adapter with a built-in USB interface. A custom 3D printed enclosure is used to house the adapter and also help to expose the interface to the Tamagotchi. This is done by wiring three pins to nickel strips, which are threaded through slits in the case and looped back around to create a pogo-style adapter for the Tamagotchi’s custom dock. Normally this would be used to link to other Tamagotchis, but in this case the USB-to-UART adapter mimics it, allowing for all kinds of in-game shenanigans. The project’s creator [Squalius] shows it off by connecting it directly to a browser tool in Google Chrome.
Not only that, but this can also be used to modify the software running on the handheld entirely, with the video showing demos playing not only Super Mario but also DOOM (of course). This isn’t too surprising given that these games are built with modern 32-bit ARM microcontrollers. For the 90s purists, though, it probably won’t surprise anyone to know that these devices have been the subject of various hacks almost since they came out.
Although e-paper displays are famous for being low-power and lasting essentially forever if not damaged physically, the recent push to drive even cheaper e-paper displays at a framerate like 30 FPS for a decent monochrome gaming experience does raise a few questions. The first being what this does to the power usage of these displays, and the second whether this will wear out the display in short order. To investigate this, [Bo Made It] set up a few experiments.
Subject of this test was a Waveshare ESP32-S3-ePaper board, which had previously been demonstrated running a Game Boy emulator at 30 FPS. With this software running, the board consumed on average about 115 mA, which would run down the device’s 400 mAh battery in about 3.5 hours. From here key was to isolate the power consumption of the display itself, with the system minus the display updates consuming about 90 mA.
Running the frame calculations for the greyscale mode without rendering to the screen pushed that up to 107.6 mA, with even in the 30 FPS greyscale mode the display thus only consuming about 7.4 mA, which is vanishingly small. Clearly the low-power claims of e-paper remain intact even at higher framerates.
As for lifespan, one datasheet gives the typical lifespan as one million updates. This would translate to about 9.3 hours at 30 FPS, though that assumes a full display refresh. Since a smart driver only updates changed pixels, obviously this will be longer, but the question is how much longer, and what will degradation look like?
After running 2.16 million frames of a custom endurance test featuring repeating patterns, some ghosting was apparent, but repeated refreshing made this go away again. This means that so far no permanent damage has been detected within the no doubt conservative limit provided by e-paper manufacturers.
It should be noted that Waveshare itself also recommends against running such high-FPS applications on their device, meaning that this is definitely one big longevity experiment. If actual damage occurs, this means that obviously this won’t be covered under any warranty.
The project started as an attempt to produce a set of C64 keycaps for an Ajazz 75% keyboard layout, but [Levente] kept pushing until it developed into a universal set. The keys have C64 legends, plain legends, or blank, and work for ANSI boards from 60% to full size. There are a few ways they can be printed. — you can do two-color printing with an FDM machine, or you can print the caps alone and fill the legends with paint, either in FDM or resin.
As a part of this work, [Levente] had to obviously create the glyphs to print upon all the keycaps. He thus decided to release that as the C64 keyboard font, in fact. It’s available in TTF and OTF formats, and you can preview the font in your browser, if so desired. It includes the function key labels, the 63 PETSCII graphic font legends, and various symbols, punctuation, and selected accented letters, too.
We’ve seen lots of vintage C64 parts recreated from scratch. It’s been at the point for a while where you can build a new machine with what’s available off the shelf. They said Amiga would never die, but it’s the earlier Commodore that really lives on today…
Upcycling smartphones makes a lot of sense, especially since they contain so many components that remain useful long after their desirability as a smartphone has faded. In the case of [Mountain DS Lab], they opted to use an 8-year old Xiaomi Mi 8 phone to add long-range FPV video link and remote control functionality to an RC plane, using the phone’s LTE cellular connectivity.
The smartphone was bought used for $23, with the default Xiaomi ROM overwritten by LineageOS to get a more lightweight and up to date Android installation on it. From the video it’s clear that this phone has seen better days, with the glass back cracked and a few ugly lines running across the display. Fortunately all that is needed is the motherboard itself.
One gotcha here is that the OS checks for the display on boot and will time-out if it’s not present, potentially halting the process entirely. The workaround requires disabling the display in the device tree, which is done by modifying the boot.img file as explained in the video. Next a custom bracket for the motherboard was printed so that it could be fitted inside the target airplane.
To communicate with the avionics, a USB-to-UART adapter PCB was created with a CH340 IC on it. This was then connected together for an initial test, with the extended front camera being used as the FPV camera for the custom Android application. Using the controller via the remote LTE link worked with the flight controller, so next the airplane was assembled for initial testing.
From this point it’s all pretty standard RC airplane assembly and testing, just with the typical RF-based control and FPV link replaced with the LTE link. Unfortunately flying drones isn’t permitted in the immediate area where the creator lives, so only some taxiing was tried prior to its maiden flight at a local airstrip that will be featured in an upcoming video.
Naturally, this isn’t the first time that someone has tried this type of remote control, with the ongoing Russo-Ukraine war being a prime example of LTE-based remote control of drones. Although we do not advocate wiping out a third of a nation’s strategic bomber fleet with upcycled smartphones, ultimately this is the same technology and a good way to create an RC drone that can last more than the few kilometers eked out from a 2.4 GHz link or so. Just be prepared for the LTE link to add a few milliseconds of latency.
Many of the image formats we’re familiar with have been around for decades. We all know JPEG and PNG like the back of our hands, and GIF even had a bit of a resurgence when tiny annoying looping animations became cool again on social media. There has been a growth in newer formats, though, like WEBP, and AVIF, with various platforms and software companies adopting them for greater efficiency, performance, and image quality.
Amongst the new crop of formats vying for relevance is JPEG XL. It was touted as a format that improved on what JPEG could do in the lossy compression space, while also adding on a lossless mode. There were grand hopes that it would become a universal replacement for all existing raster formats on the Web. A major problem was that Google was seemingly against it, only to backflip—with the format now slated to hit the big time with renewed backing from the search giant. So what’s going on?
Got You JPEG’d
The JPEG XL codec architecture. Credit: Jon Sneyers, CC BY SA 4.0
The JPEG XL standard is modern, but by no means brand new. It was initially released on 13 October 2021, having been developed by a consortium of the Joint Photographic Experts Group, Google, and Cloudinary. It was deveoped from earlier work from Jon Sneyers on the Free Universal Image Format (FUIF), and work from Google on the PIK format.
It was decided the resulting format would use the *.jxl file extension. The spec defined a format with a wide range of features well beyond what classic JPEG ever offered. It has lossless compression, including for the alpha channel, but also lossy compression available in different modes to suit both photographic and synthetic imagery.
It remains fast to decode—almost as fast as JPEG and much quicker than HEIC with x265. A key future proofing feature is that it can also handle 32-bit sample precision, and images with over a billion pixels per side—that’s a terapixel, if you’re playing along at home.
The JPEG XL logo, which pretty much solely exists for people who need an image for their article about JPEG-XL. Credit: Joint Photographic Experts Group
A wide range of major tech companies have backed the standard in the years since it dropped, from Meta, to Adobe, Intel, and Flickr. While it might seem like Google was fully onboard from the get-go, having literally been involved in development of the standard, the history is more complicated, as reported by TT Lab.
Chromium implemented a libjxl-based decoder all the way back in 2021, which seemed to signal JPEG-XL support would soon be a thing in Chrome and other products besides. However, soon enough, there was a change in direction. In late 2022, it was slated for removal, with a notice that ecosystem support wasn’t great enough to justify continued efforts to bring JPEG-XL into the fold.
In Chrome 110, there was no trace left—JPEG-XL was not going to be a part of things. And yet, in the years that followed, debate raged on the Chrome issue tracker as to whether the nascent format would earn its inclusion. Elsewhere, JPEG-XL was struggling to find a footing. Apple rolled it into Safari in 2023, while Mozilla continued to hedge, noting that including another C++ image decoder was undesirable for reasons around memory safety.
A screenshot of an Android media app displaying a *.jxl image. Credit: Syced, CC0
New movement happened in November 2025, when Rick Byers, Area Tech Lead on Google Chrome, noted that the landscape had shifted. He posted that in light of JPEG-XL support being added to things like the PDF format and Safari, amidst other signals of support in the wider ecosystem, that the development team would be open to “integrate a performant and memory-safe JPEG XL decoder in Chromium.”
With Chrome having over 65% of the browser market, this would be a game changer for the format and likely see its adoption skyrocket across the web. It just needed to actually be implemented. However, Byers was careful to note that the inclusion of the new format would be contingent on a commitment to long-term maintenance of the decoder.
Things moved fast, and when Chrome 145 dropped in February this year, JPEG-XL was on the docket. This was thanks to the development of the jxl-rs decoder, which was implemented in Rust. This was an intentional decision for security reasons, with Google relying on the Rule of 2 to keep its browser safe. However, the new decoder was not activated by default. It would take another half a year or so before the new format would become a mainstream part of Chrome, rather than being hidden behind an experimental flag or anything like that. As of Chrome 155, though, JPEG-XL will be fully supported in the browser.
Don’t expect to see a ton of *.jxl files out on the wider web immediately. However, with the new format offering 30-50% better compression than JPEG, it will be appealing to just about any content provider looking to slimline data budgets and improve page loading times. When the performance gains start boosting traffic to a degree that makes up for the loss of users from older non-compliant browsers, expect to see things changing more quickly.
What does it mean for you, the end user? Probably little more than some minor headaches. You’ll struggle here and there when you download a *.jxl and try and load it into older software that doesn’t support it. You might get a device that shoots pictures in JPEG-XL and then find you can’t upload them to an older website with an out-of-date image submission form.
It’s the same problem we’ve all dealt with as HEIC, AVIF, and WEBP have started bouncing around the web, and we’ll have to weather it again. At least, at the end of the day, we’ll have slightly prettier images that take up a little less space. It’ll all be worth it, to be sure.
What [Jan] has built is a 100% browser-based emulator for an Intel 80486DX2-66 PC. Obviously, it’s not just a CPU that’s being emulated here—[Jan] has gone so far as to throw in the motherboard and ISA/VLB adapter card emulation necessary to make this a real and functioning computer that runs inside a solitary browser tab.
It’s all written in ES6 JavaScript. It will happily run SeaBIOS, VGA BIOS, FreeDOS 1.3, and a whole bunch of classic games, like Wolfenstein 3D, Duke Nukem, and DOOM. There’s even a control panel where you can configure the PC how you like, from storage to expansion cards and all the rest.
Once upon a time an emulator was an application you had to download and run, hoping all the while that your new machine had enough grunt to emulate the classic hardware of your desires. These days, we have endless piles of CPU cycles to throw at everything and you can do it all within a browser. Or even on a tiny microcontroller, if you feel like it!
There are plenty of “robot” projects out there that are really just a small remote control platform of some sort. We often like to think of robots of having some sort of autonomy though. [Luca Fagioli] demonstrates a great example of this with his explorer robot that uses Simultaneous Localization and Mapping (SLAM) to navigate its environment.
The robot is a built on a small plastic chassis, with one gear motor per drive wheel. Running the show is an Arduino Uno R4 Wi-Fi, paired with the Sensor Shield 5.0 and an L298N motor driver board. There’s also an HC-SR04 ultrasonic sensor module onboard, mounted atop an SG-90 servo motor so it can be panned around. The ultrasonic sensor determines the range between the robot and surrounding walls, and a map is constructed at the same time as the robot is localizing itself within it. There are also infrared sensors on the bottom of the robot for detecting tape marks on the floor for checkpointing purposes.
Having watched some fun videos on repurposed satellite dishes on YouTube, [Melan] wanted to get in on the action, managed to source an Intellian i4 — a dish built for marine use — and set about hacking it.
[Melan] first needed to convince the antenna that it was still on a boat by using an RP2040 microcontroller and an RS-422 module to send NMEA sentences. This was necessary to tell the i4 the “heading” of the “boat”, even though [Melan] was really using the rig stationary on land. From there, a simple email to the company itself sufficed to get the Intellian software running on the antenna.
But could it be controlled without the software?. Sniff the communications between the software and the Antenna Control Unit, and decompile the code. This done, it was relatively straightforward to put together a protocol description and figure out how to command the antenna where to point simply by issuing commands for azimuth and elevation.
Airborne micro particles can be a significant health hazard in a workshop, and thus it’s important to maintain a high standard of ventilation. But monitoring their concentration is also important, and thus there exists a range of sensors to help keep you safe. [WeSpeakEnglish] has taken this idea to the MAX, with a PM2.5 sensor that drives a very large wall mounted display. You’ll never be uncertain what the level is now!
The standout feature of this thing is a huge addressable LED seven segment display PCB, upon the back of which sits a tiny Seeed Studio Xiao board to which the particle sensor is hooked up. The software displays the particle count, and handily changes the colour as the number creeps upwards. Meanwhile should you wish to log the readings, the USB exposes a serial port upon which they are placed.
We can see this is a useful project for anywhere that is likely to have a high particle count, but it’s worth noting also that a large 7-segment display with an ESP32 board attached could have plenty of other uses. Meanwhile this is a nicely finished air quality monitor, but it’s certainly not the first we’ve seen.
If we care to cast an eye over the history of ubiquitous personal computing as we know it today, we might immediately point at the original IBM PC. After all, for most of us our machines share backward compatibility in some form through multiple generations back to that original box from 1981.
But if we look at the things we use today and take for granted, from laser printers to graphics cards to the routers which power most of the Internet, they’re not from IBM at all. At the recent Vintage Computing Festival Berlin, [Michael Engel] delivered a talk naming a surprising progenitor for much of that technology, none other than Sun Microsystems.
It all starts with [Andy Bechtolsheim], famously Sun’s co-founder, when at the end of the 1970s he was a postgraduate at Stanford University. Working on the Stanford University Network — SUN — project he designed a computer to be used as a workstation on the network. The processor of choice then was Motorola’s 68000, but it lacked the MMU that would be required to run UNIX. His design had an MMU implemented externally to the 68000, with a bank of SRAM serving as the page table. This design would form the CPU board of the first Sun workstation.
The story might end there, were it not that many other companies had the same requirement, and Sun could supply them a CPU board. Silicon Graphics, the distant ancestral progenitor of your GPU, was one of them, so the first SGI workstation also had the same CPU as the first Sun. It appeared in the early Imagen laser printers too, as well as commercial AppleTalk to Ethernet bridges. Perhaps the biggest surprise is that because the original Stanford board had also been used as a router, the software for that became part of Cisco’s first product.
The video is below the break, and it’s a fascinating watch.
The humble credit card reader — most of us have used hundreds, perhaps even thousands of them over the years. But even for folks like us, it’s not the sort of device we give a lot of thought to. It’s just a keypad, a display, and a magnetic stripe reader. How interesting could it possibly be?
That may be true in some cases, but at least for the 1990s-era TRANZ 330, there’s a bit more to the story than that. As [CharlesD] explains, these particular readers are essentially complete Z80 computers just waiting to do something more exciting than processing PINs. In the case of this particular unit, the addition of a GPS module and some new code has turned it into an interactive guide to the solar system.
Thanks to the UV erasable ROMs used in the TRANZ 330, loading new code on the device is easy enough. With a bit of educated poking around, [CharlesD] was able to map out what did what. Working from the basics of getting the display and keypad working, he moved onto the serial interface, which in turn let him communicate with a modern GPS module and era-appropriate thermal printer. From there it was just a matter of getting the math implemented to compute the azimuth and elevation of a given planet, and he had an offline map of the solar system for use with his telescope.
This is one of those projects which is awesome enough on its own merits, but it’s particularly exciting to see just how easy it is to repurpose one of these card readers, especially since [CharlesD] was kind enough to share his source code. If you end up picking one of these up and getting something running on it, be sure to let us know.
Many readers will be familiar with Douglas Englebart’s 1968 so-called “Mother of All Demos”, in which he described many of the devices and technologies we would be using two or three decades later. Among these was a primitive computer mouse, but while famous it was by no means the earliest pointing device. At the recent Vintage Computer Festival Berlin, [Dmitriy Kostiuk] delivered a fascinating lecture of the history of the pointing device.
It’s a long video that we’ve placed below, and it’s an exhaustive examination of the topic from the earliest examples to the 1990s when mice became commoditized. It’s a surprise to find that the first pointing device was a trackball built for a 1950s Canadian warship, with a surprisingly modern-looking optical encoder. Englebart’s 1966 wooden block with its pair of wheels and potentiometers had a less-well-known and much more stylish competitor in the same year from Telefunken.
We visit the various design iterations as the form of what we’d call a mouse today took shape. It’s unexpected to find that those Sun mice with the spotty mouse pad weren’t from Sun at all, they were from Mouse Systems. The first mice from Microsoft and Apple make an appearance, as do some awful designs for 8-bit computrs. Remembering those in particular perhaps it’s as well we didn’t have the cash to buy such a disappointing product for ourselves.
The video is long, but interesting. Give it a watch.
Header image, Douglas Englebart’s prototype, Michael Hicks, CC BY 2.0.
Bridges! We kind of expect them to just be there and do their job, ad infinitum. They are built into the landscape, and we often take them and the routes they open up for granted.
The reality, as any civil engineer will tell you, is that bridges are living, breathing things that require endless maintenance and monitoring to keep them safe, standing, and functional. A great example of this is found in the US Department of Transportation, and its publicly accessible register of bridge health reports.
Stay Standing
The thing about bridges is that we rely on them. They serve as vital transport links in our communities, ferrying people to and from work and school, and acting as the very arteries of commerce as trucks and trains haul goods to and fro. When a bridge crossing has to close, either for maintenance or at end of life, this link is severed, often with serious economic and logistical impacts. For that reason, we tend to like to keep our bridges in service as long as possible. The result, of course, is that if pursuing this goal means that proper maintenance and repairs aren’t seen to, there is a risk of collapse—which often comes with worse consequences. Loss of life is common when bridges fail, and replacing a collapsed bridge is often much harder and more time consuming than handling things properly ahead of time.
In the United States, it’s a well known fact that the bridges are getting old. The average bridge is 44 years old, which is bumping up against the 50-year service limit many were originally built for. Being an average number, it’s indicative that many bridges are exceeding that figure significantly. Obviously, a bridge’s age isn’t a perfect proxy for its condition, but closer examinations indicate there’s definitely a problem. A 2024 report from the American Road & Transportation Builders Association noted that 36 percent of US bridges are in need of repair or replacement, a total of 221,800 spans. 42,067 spans were considered to be in “poor” condition, which in their total see 168.5 million motorists crossing them every day. It’s a particularly sobering figure as it highlights the size of the disaster possible if these structures are to fail.
InfoBridge quickly lets you sort through data by all kinds of different factors. If you’re looking for the worst bridges in town, it’s easy to flick through CAT10 – BRIDGE CONDITION to see which bridges as listed as Good, Fair, or Poor. Bridges are rated on the condition of their deck, superstructure, and substructure, and the lowest scoring section influences which bin the bridge lands in, as per federal code—specifically, 23 CFR 490 Subpart D. Credit: InfoBridge screenshot
You can drill down into the data yourself if you desire. Within the Department of Transport, the Federal Highway Administration maintains LTBP InfoBridge, a database of information on bridges all across the country. It was developed by the Long Term Bridge Performance program, because the goal of the project is to understand how these structures hold up and perform over the decades. The database is publicly accessible, and serves as a portal for all the available data and statistics on how US bridges are doing. It hopes to enable everyone from state and federal authorities, to university students, faculty, and other researchers, to dive into bridge data and visualize and understand it better.
Data available is from a wide number of sources, including the National Bridge Inventory and National Bridge Element datasets, as well as climatic data collected from NASA’s MERRA-2 database. There’s also construction and design data sourced by the LTBP program, along with non-destructive evaluations that have been carried out. Data from various other special projects is available too, such as from Federal Highway Administration projects investigating timber bridges, steel weathering, and the use of ultra-high performance concrete structures.
Just glancing at the Vincent Thomas bridge won’t tell you how the structure is doing. Credit: The Port of Authority, CC BY-SA 3.0
If you have a particular bridge of interest, it’s easy to get a quick break down of how it’s doing. For example, you might like to know about the Vincent Thomas Bridge, in Los Angeles, California: National Bridge Inventory number 53 1471. It links San Pedro with Terminal Island, and is a suspension bridge with a total length of 6,060 feet and a longest span of 1,500 feet. Built in 1963, we can see from the data alone that it’s now showing its age.
The bridge condition is listed as “Poor,” and if we dive deeper into the National Bridge Elements data, we can see why. The health indexes of the deck, substructure, and superstructure have all been trending down in recent years as the bridge’s age has increased, with a particular drop off from 2019 or so. In particular, the steel cables and girders on the bridge have been showing their age, and the concrete columns supporting the bridge have been similarly degrading. The deck, too, is in need of repair, with the California Department of Transport recently dedicating some $706 million to replace it ahead of the 2028 Olympic Games.
However, InfoBridge will let you drill down into detailed reports on the bridge conditions, down to a level which indicates which parts of the bridge are most in need of maintenance, repair, or replacement. Credit: Screenshot, InfoBridge
InfoBridge also offers condition forecasts for many bridges across the country. For example, the 24th Street Bridge over Rio Linda Creek is currently listed as being in “Good” condition. Current forecasts show that the deck and superstructure is expected to be in much poorer shape somewhere between 2035 and 2055, while the substructure is expected to hang on in good shape for a bit longer.
The Long Term Bridge Performance Program has developed a variety of models—base, survival, and machine-learning—to predict bridge condition over time. The aim is to guide maintenance efforts over time and allow for better planning. Credit: InfoBridge, screenshot
You might think that you’d have to query a government department and delve deep into some dusty records room to learn about the condition of your local bridges. Instead, thanks to the efforts of diligent civil servants, you can instead access all the rich inspection data you like from the comfort of your own web browser. It’s not just good for citizen oversight, either. It aids local authorities and bridge owners in making the right decisions, by putting the necessary data right at their fingertips.
It also creates a certain level of accountability—having the data available means there’s little room for anyone to make excuses that they were unaware of a bridge’s condition prior to something going wrong. Ultimately, it’s just one arm of a project that hopes to take US bridges safely long into the future.
Recently [shraiwi] decided to have a bit of good nerdy fun and implement the FAST machine vision algorithm on an ESP32-S3 using its SIMD ISA. This involves using the assembly instructions for the ISA, making for an exciting opportunity to become familiar with this part of this Xtensa Lx7-based twin-core MCU.
The Features from Accelerated Segment Test (FAST) algorithm is a corner detection method that can determine with reasonable accuracy and in real-time whether a given input frame contains said corners which thus may correspond to objects and other characteristics worthy of note. This is essential for machine vision, with machine learning able to bump up its recognition accuracy even more.
Implementing this algorithm on the ESP32-S3 proved to be a bit of a challenge due to somewhat limited SIMD ISA. Missing instructions included things like comparisons between unsigned byte values, and there is no support for direct misaligned reads.
All of these required some creative coding to work around, but in the end the ESP32-S3 running at 240 MHz was able to process a VGA stream in real-time at 30 FPS. This means about a 2x speed-up over a naive implementation using only non-SIMD instructions.
We’re big fans of pushing hardware into situations it wasn’t designed for here at Hackaday, but sometimes you’ve got to appreciate a nicely designed gadget doing more or less exactly what it was intended for — especially when it’s courtesy of code that’s freely available for you to run and hack on however you like.
That’s precisely what [mircemk] has done with their “Universal Timer” project. The 2.1 inch CrowPanel “Rotary Display” at the heart of the build combines an ESP32-S3 with a 480×480 round touch screen display and a rotary encoder.
The all-in-one device — clearly meant to be reminiscent of the Nest thermostat and similar commercial offerings — is technically all you need, but in this case it’s been joined by a PCF8574 I2C I/O expander which in turn is used to drive a buzzer that provides a bit of audio feedback at the end of the countdown.
With the code [mircemk] has provided flashed onto the board, the rotary encoder ring built into the housing makes for an exceptionally intuitive input for setting the desired time. It’s a bit like a high-tech version of the classic kitchen timer, as shown in the video below, you simply twist the ring and the graphics on the display rotate accordingly. Unlike grandma’s clockwork timer of old however, this one can change color as it nears zero, which makes it easier to estimate how much time remains from across the room.
As the popularity of smartwatches has brought the cost of these circular displays down, we’ve started to see some very slick projects utilizing them. The various efforts to turn them into desktop “radar” displays for nearby flights are a particular favorite.
In the open source world we are used to software being compiled from source for our particular distro, so while in a few cases an ancient release may still be in use, it’s just going to run on the latest distro version. But in the Windows world it’s rare for software to come with the source, so you’re left with a binary that will only run if your Windows version has the right APIs for it. Since the more recent versions of Windows dropped 16-bit support a while back, that means there must be a hard date set on the earliest Windows GUI application that can still run today. [Enlyth] decided to investigate.
Given that the earliest API supported in WIndows 11 is the 32-bit version, the hunt led straight to either the first Windows NT release and ancestor of Windows 11, or the Win32s extension for WIndows 3.1. Thus a 1993 Win32S version of Freecell runs happily, but that want’s the end of the trail. Somewhere in the pre-release builds of Windows NT 3.1 would be the requisite binary, but there’s a snag. Early Windows NT 3.1 APIs were incompatible with later ones. This led through a lot of crashing binaries to a November 1992 version of the CD player app, that ran because it called a DLL which happens to still be present. The need for another DLL to emulate a CD drive speaks volumes about the progress of the PC world, back then they were the last word in storage but who’s got one now?
That’s the earliest official binary to run, but the story’s not quite over. Windows 11 may not have a VDM to run 16-bit apps, but there’s a WINE VDM for that. Behold, Reversi from Windows 1.01 in November 1985, in Windows 11. Your ancient software may yet be saved.
There are some devices which achieve electronic immortality, it’s likely that you have used a few of them yourself. The 555 timer of course, or the 741 op-amp. [ElectronicsNotes] is here with another candidate that might not have been on your mind as you read the previous sentences, and it’s a transistor. The 2N3055 is an NPN power transistor, no, THE NPN power transistor, that has found its way into an astounding array of devices over the last six decades or more.
For such a ubiquitous device one might imagine that there’s not much new to know, but the video delivers on that front. Here as well as probably for you the 3055 has always been an epitaxial device whose quirks you likely know well, but originally it was something different. It used the hometaxial construction process on its launch in the early 1960s, but in the mid 1970s it was replaced by a version with the same capabilities but using the epitaxial process. The consequent higher Ft required modifications to circuits using the device to stop unwanted oscillation.
Where this is being written there are several 2N3055s, in the by now rather old office audio amplifier, in a bench power supply, and probably elsewhere too. It’s been superseded in many ways and its TO3 case now feels antiquated, but it will probably never entirely go away. Meanwhile if you’d like to read about another iconic 1960s device that never went away, we have you covered.
Header: a really early example. Eule4404, CC BY-SA 4.0
Recently [Rod Burlamaqui] released the arc-rebar project on GitHub, enabling Intel GPUs to work significantly more efficiently if the system’s mainboard does not support resizable BAR. It does require a Debian or Ubuntu installation and of course a supported Intel GPU.
Although the resizable base address register (ReBAR) feature has been part of the PCIe specification for a while, its use was quite limited until Intel released its Arc series of graphic cards. These use this feature to map much more of the GPU’s video RAM (VRAM) into the PC’s address space than the standard 256 MB, assuming that the system is capable of decoding addresses above 4 GB, i.e. allow for 64-bit BARs.
For GPU manufacturers like AMD and Nvidia this wasn’t so much of an issue as their GPU designs developed in a world where ReBAR didn’t exist, while Intel’s new GPU generations were designed with ReBAR as a core feature, which naturally cripples performance if the mainboard does not have it enabled during PCIe bus enumeration.
This initramfs-based fix runs before the GPU driver loads and performs the requisite BAR configuration. In testing with an Intel Arc B580 GPU on a 2015-era Intel Xeon mainboard the difference between the default and the fixed bandwidth was a bump from a pitiful 15 GB/s to a respectable 392 GB/s, showing how this one fix can breathe new life into older systems.
Login
Running the frame calculations for the greyscale mode without rendering to the screen pushed that up to 107.6 mA, with even in the 30 FPS greyscale mode the display thus only consuming about 7.4 mA, which is vanishingly small. Clearly the low-power claims of e-paper remain intact even at higher framerates.
The smartphone was bought used for $23, with the default Xiaomi ROM overwritten by 
