Author: Tyler August

619 Articles

Digital Upgrade Brings Medium Format Camera Into The 21st Century

September 22, 2026 by 12 Comments

Large format cameras can produce amazing shots, but are a bit too bulky to be practical. Medium format is a different story, as [Wenting] demonstrates with his Sitina B220M — an open-source digital back for the Mamiya Super 23 camera using a full-frame Kodak CCD.

“Digital back” just means he’s replacing the rear of an existing film camera in order to put a sensor where said film used to live. The sensor is a 22 Megapixel Kodak KAF-22000CE, which measures in at a very respectable 38.8 mm by 50 mm. That’s only a touch smaller than the rolls of 120 the camera was designed for, whose large dimension was 56 mm. How much was exposed at a time was determined by the back you put on the camera, but would never have been below 41.5 mm. Again, the CCD is pretty close.

With Mamiya covering the optics, [Wenting] could focus on the digital end. He’s got a Xilinx Zynq 7010 running the show, making use of both that SoC’s Cortex-A9 cores and its built-in FPGA. There’s some decent info on how that works in the build video embedded below, if you don’t want to dig into the code at the GitLab repository above. The photos look great, and start at 8:25.

[Wenting] has been around the bush with FPGAs before. Not least in his e-ink monitor project, but also with the last iteration of his mirror-less digital camera. This version is perhaps less ambitious, being merely a digital back and not the whole enchilada, but it solves some design issues he had on the “camera” part while he focuses on the “digital” for now.

Continue reading “Digital Upgrade Brings Medium Format Camera Into The 21st Century” →

Reverse Engineering A Sony Car Stereo LCD

September 20, 2026 by 8 Comments

For his own reasons, [Jose Luis Monteiro] (aka [emsyscode]) decided he needed to drive the LCD on a Sony CDX-A250 car stereo’s front panel using an Arduino. There’s probably a sweet project in the works, or perhaps he just wanted to see if it could be done. Either way, more power to [Jose], because he totally pulled it off and put the results up on GitHub for all to enjoy. There’s also a project video showing how he did the reverse-engineering, which you can see below.

The driver for this diminutive LCD is a chip obviously labeled LC75826W, and that’s what the Arduino ends up talking to. Thankfully, there was a datasheet available for that part, which gave [Jose] a great starting point for figuring out how to use it. While [Jose] is working with the LC75826W driver, he’s quite explicit in his GitHub repo that this repository is not a driver library for that chip. The code only targets the specific LCD on the CDX-A250 head unit. Still, if you’ve got a different oddball LCD that uses this driver, [Jose]’s code is a great place to start, and since it’s under an MIT license, you can fork to your heart’s content.

Kudos to Sony for not obfuscating the part or using a chip-on-board black blob — you can reverse-engineer an LCD driven by one of those, but it’s a lot more work. If you’re wondering how and why those black blobs come to be, we’ve got you covered.

Continue reading “Reverse Engineering A Sony Car Stereo LCD” →

The guts of the server, with lots of sticks of DDR3, and not a single GPU in sight.

No GPU, No Problem: Flagship LLMs On A GPU-less Teenaged Server

September 20, 2026 by 25 Comments

There are lots of reasons to run LLMs locally, from privacy concerns to just wanting to futz about with the technology, but if you want to run the big models, the standard logic is that you need big money for lots and lots of VRAM. [MattMo] is calling that into question with his recent video — embedded below, naturally — in which he gets GLM 5.3 Flash, Qwen 3.8 Flash and Qwen 3.8 27B all running on a 14-year-old server without a single GPU.

The secret, if you can call it that, is that they aren’t running very fast: four tokens per second was about the max. Those four tokens are excreted from the twin Xeon processors of the vintage Dell PowerEdge R720 server, with the models living in its 348 GB of DDR3 system memory. That’s enough even for the largest flagship models, but as you can see by the speed, things are a bit bottlenecked by having only 20 threads available between the two processors. Said processors are also old enough to lack certain instructions that might have helped speed things up. Still, [MattMo] argues in the video that this is more than just a dancing bear: there are workloads where batch-processing at 4tps might make sense, and there are people who already have servers of this class laying around in their homelabs. The intersection of that Venn diagram is probably pretty lonely, but if that’s you — hey! [MattMo] says it’ll work, so give it a shot.

If you had to buy the hardware, well, it’s also quite reasonable on the second-hand market, with [MattMo] estimating about $600 given prevailing prices. He also points out that the newer models may still get some optimization to improve speeds, but don’t expect real-time conversations with Hal 9000.  Still, in terms of local LLMs, it certainly beats the pants off toy models running via Llama on the PSP or the C64.

Continue reading “No GPU, No Problem: Flagship LLMs On A GPU-less Teenaged Server” →

Laser Your Way Into Debug Mode On The RP2350

September 19, 2026 by 24 Comments

The RP2350 is actually a pretty secure chip, all things considered. It has secure boot, ARMv8’s TrustZone to split secure and non-secure execution, and you can permanently disable debug — the Pi Foundation even included glitch detection, meaning the traditional ‘zap the chip until it obeys’ technique is blocked. That’s why the [Ledger Donjon] security team went full Bond Villain and strapped everyone’s favourite fruit-flavoured microcontroller to a table with a slowly-approaching laser beam.

Continue reading “Laser Your Way Into Debug Mode On The RP2350” →

Coreboot Hikes The Bay Trail To DRAM Initialization

September 19, 2026 by 18 Comments

This article is written on an open-source operating system, but not an open-source machine — the BIOS isn’t open-source, and even if it were supported by the coreboot project (formerly LinuxBIOS), there would still be a whole host of binary blobs required to get it to boot. On one vintage architecture, there’s one less blob, as coreboot can now initialize DRAM on Intel Bay Trail SOCs, as [Mate Kukri] presented in a talk at the recent Open Source Firmware Conference.

Bay Trail isn’t exactly cutting-edge hardware, to be sure — the SoCs are over a decade old at this point, and were only used in low-performance mobile applications like Chromebooks. On the other hand, coreboot has been on Chromebooks for at least as long. Getting DRAM set up is difficult because, well, you don’t have any memory to work with until you do. Traditionally, the way you did that was to call on one of the many proprietary ‘binary blobs’ provided with next to no documentation by the manufacturer. Reverse engineering that requires some serious bus-sluthing, which was done in software with the SerialICE debugger and the Unicorn Engine CPU emulator. The talk focused on that technique and how it might be applied more widely, rather than getting into the weeds of how to do DRAM init on one obsolete SOC. At some point the whole thing should be archived on the OFSC website so those of us not lucky enough to attend in person can hear what [Mate] — and all the other speakers — had to say.

Continue reading “Coreboot Hikes The Bay Trail To DRAM Initialization” →

Printing A Clock Fit For A Pope

September 17, 2026 by 12 Comments

When it comes to clockwork, there is a spectrum — some people love the ticking, and some people hate it, while most fall into the broad middle of indifference. Once upon a time, Pope Alexander VII fell into the “hate it” category, and commissioned a silent timepiece from [Fratelli Campani] in 1656. Three hundred seventy years later, [Many Vices] sought out to re-create the mechanism in extruded plastic thanks to the efforts of watchmaker [Carlo G. Croce], who documented his brass recreation in this PDF file and his own videos.

While the archaeology of recreating the mechanism from old photos is interesting, the mechanism itself is the real showpiece. The secret, as you might be able to tell from the photographs, is an eccentric crank escapement that provides continuous movement rather than the traditional anchor escapement whose periodic movements creates the distinctive ‘tick’ and ‘tock’. [Many] tests both in his video so you can hear the difference and see how much power is wasted with the crank escapement, which doesn’t keep going very long.

We wonder if carefully tuning the flywheel he’s using to match the frequency of the swinging pendulum would help a little there. Likewise, his linear-rail-based spring pendulum modification — though it does look awesome and we’d love a train-themed clock using it — doesn’t come close to providing the runtime of traditional clockwork. That’s probably why the anchor escapement persisted for centuries, even if some people and Popes couldn’t stand the tick-tock.

We’ve featured a lot of different 3D printed clocks, from wholly mechanical to electromechanical digital units to even ones based on D20s , so it’s hard to believe that not much more than a decade back, printing a mechanical clock was considered a challenge. Time marches on whether we can hear it or not.

Continue reading “Printing A Clock Fit For A Pope” →

CircuitPython Goes Turbo With Precompiled Functions

September 14, 2026 by 19 Comments

It would not be at all original to declare that Python is the new BASIC. Like BASIC, it has been the first programming language for a whole generation of coders, and its main advantage is that it’s quick and easy to write in. Like BASIC it is an interpreted language, and thus rather slow to execute.

Thus while CircuitPython can be very useful for beginners and quick projects, it hits the limitations of the hardware far sooner than it needs to — unless you can pre-compile critical parts of the code, which you now can, thanks to CircuitPython Turbo by [Mikey Sklar] with some help from Anthropic’s Claude LLM.

Now if that sounds a lot like MicroPython’s ‘Viper’ and machine-code compiler, that’s because it is. CircuitPython is a fork of MicroPython with some handy extras on Adafruit boards, but Viper wasn’t one of them until now. Before the Turbo version, CircuitPython only ran in interpreted mode.

Like MicroPython, using CircuitPython Turbo you can flag sections to run as ‘native’, where instructions are compiled but values stay as python objects, which gets you about a 3X speedup. A little more rewriting to declare your variables and pointers and you can use ‘viper’ mode, which can — depending on what you’re up to — result in a 20x to 70x speedup. In Adafruit’s documentation, they demonstrate a Metro RP2040 calculating the Mandelbrot set 3x faster in Native and 19.7 times faster with Viper than normal Python bytecode.

The one thing that we miss from BASIC that CircuitPython Turbo doesn’t give is inline assembly– though interestingly enough, that is in the upstream MicroPython implementation, so perhaps its day will come here too. Not every job is suited to the use of Python on microcontrollers, but we’ve seen it used for everything from e-bikes to a Winamp-inspired music player.