[Linus] playing his instrument

The Qweremin Is A QWERTY Theremin With A C-64 Heart

While we have nothing against other 1980s 8-bit machines, the Commodore 64 has always been something special. A case in point: another new instrument using the C-64 and its beloved SID chip. Not just new to retrocomputing, either, but new entirely. [Linus Åkesson] has invented the QWERTY Theremin, and there’s a Commodore at its core.

If this project sounds vaguely familiar, it’s because it’s based off of the C-64 Theremin [Linus] built a couple of years back. According to [Linus], there were a few issues with the instrument. A real thereminist told him there were issues with the volume response; his own experience taught him that theremins are very, very hard to play for the uninitiated.

This model fixes both problems: first, the volume circuit now includes a pair of digital-analog-converters (DACs) connected to the Commodore’s user port, allowing smooth and responsive volume control.In this case the DAC is being used solely for volume control: SID provides the analog reference voltage, while the 12-bit digital input served as volume control. That proved noisy, however, thanks to the DC bias voltage of the audio output being scaled by the DAC even when the SID was silent. A second DAC was the answer, providing a signal to cancel out the scaled bias voltage. That in and of itself is a clever hack.

The biggest change is that this instrument no longer plays like a theremin. Pitch has been taken out of the 555-based antenna circuit entirely; while vertical distance from the spoon-antenna still controls volume as in a regular theremin and the last version, the horizontal distance from the second antenna (still a clamp) now controls vibrato. Pitch is now controlled by the QWERTY keyboard. That’s a much easier arrangement for [Linus] — this isn’t his first chiptune QWERTY instrument, after all.

Continue reading “The Qweremin Is A QWERTY Theremin With A C-64 Heart”

No Die? No Problem: RealDice.org Has You Covered

Have you ever been out and about and needed to make a check against INT, WIS or CON but not had a die handy? Sure, you could use an app on your phone, but who knows what pseudorandom nonsense that’s getting up to. [Lazy Hovercraft] has got the solution with his new site RealDice.org, which, well, rolls real dice.

Well, one die, anyway. The webpage presents a button to roll a single twenty-sided die, or “Dee-Twenty” as the cool kids are calling it these days. The rolling is provided by a unit purchased from Amazon that spins the die inside a plastic bubble, similar to this unit we covered back in 2020.  (Alas for fans of the venerable game Trouble, it does not pop.) The die spinner’s button has been replaced by a relay, which is triggered from the server whenever a user hits the “roll” button.

You currently have to look at the camera feed with your own eyes to learn what number was rolled, but [Lazy Hovercraft] assures us that titanic effort will be automated once he trains up the CVE database. To that end you are encouraged to help build the dataset by punching in what number is shown on the die.

This is a fun little hack to get some physical randomness, and would be great for the sort of chatroom tabletop gaming that’s so common these days. It may also become the new way we select the What’s That Sound? winners on the Hackaday Podcast.

Before sitting down for a game session, you might want to make sure you’re all using fair dice. No matter how fair the dice, its hard to beat quantum phenomena for random noise.

Animatronic Eyes Are Watching You

If you haven’t been following [Will Cogley]’s animatronic adventures on YouTube, you’re missing out. He’s got a good thing going, and the latest step is an adorable robot that tracks you with its own eyes.

Yes, the cameras are embedded inside the animatronic eyes.That was a lot easier than expected; rather than the redesign he was afraid of [Will] was able to route the camera cable through his existing animatronic mechanism, and only needed to hollow out the eyeball. The tiny camera’s aperture sits nigh-undetectable within the pupil.

On the software side, face tracking is provided by MediaPipe. It’s currently running on a laptop, but the plan is to embed a Raspberry Pi inside the robot at a later date. MediaPipe tracks any visible face and calculates the X and Y offset to direct the servos. With a dead zone at the center of the image and a little smoothing, the eye motion becomes uncannily natural. [Will] doesn’t say how he’s got it set up to handle more than one face; likely it will just stick with the first object identified.

Eyes aren’t much by themselves, so [Will] goes further by creating a little robot. The adorable head sits on a 3D-printed tapered roller bearing atop a very simple body. Another printed mechanism allows for pivot, and both axes are servo-controlled, bringing the total number of motors up to six. Tracking prefers eye motion, and the head pivots to follow to try and create a naturalistic motion. Judge for yourself how well it works in the video below. (Jump to 7:15 for the finished product.)

We’ve featured [Will]’s animatronic anatomy adventures before– everything from beating hearts, and full-motion bionic hands, to an earlier, camera-less iteration of the eyes in this project.

Don’t forget if you ever find yourself wading into the Uncanny Valley that you can tip us off to make sure everyone can share in the discomfort.

Continue reading “Animatronic Eyes Are Watching You”

Screenshot of AVRpascal

Pascal? On My Arduino? It’s More Likely Than You Think

The Arduino ecosystem is an amazing learning tool, but even those of us who love it admit that even the simplified C Arduino uses isn’t the ideal teaching language. Those of us who remember learning Pascal as our first “real” programming language in schools (first aside from BASIC, at least) might look fondly on the AVRPascal project by [Andrzej Karwowski].

[Andrzej] is using FreePascal’s compiler tools, and AVRdude to pipe compiled code onto the micro-controller. Those tools are built into his AVRPascal code editor to create a Pascal-based alternative to the Arduino IDE for programming AVR-based microcontrollers. The latest version, 3.3, even includes a serial port monitor compatible with the Arduino boards.

This guy, but with Pascal. What’s not to love?

The Arduino comparisons don’t stop there: [Andrzej] also maintains UnoLib, a Pascal library for the Arduino Uno and compatible boards with some of the functionality you’d expect from Arduino libraries: easy access to I/O (digital and analog ports) timers, serial communication, and even extras like i2c, LCD and sensor libraries.

He’s distributing the AVRPascal editor as freeware, but it is not open source. It’s too bad, because Pascal is a great choice for microcontrollers: compiled, it isn’t much slower than C, but it can be as easy to write as Python. Micropython shows there’s a big market for “easy” embedded programming; Pascal could help fill it in a more performant way. Is the one-man license holding this project back, or is it just that people don’t use Pascal much these days?

While AVR programming is mostly done in C, this is hardly the first time we’ve seen alternatives. While some have delved into the frightening mysteries of assembly, others have risen to higher abstraction to run LISP or even good old fashioned BASIC. Pascal seems like a good middle road, if you want to go off the beaten path away from C.

Via reddit.

A preproduction U1 sitting on a workbench

A Tool-changing 3D Printer For The Masses

Modern multi-material printers certainly have their advantages, but all that purging has a way to add up to oodles of waste. Tool-changing printers offer a way to do multi-material prints without the purge waste, but at the cost of complexity. Plastic’s cheap, though, so the logic has been that you could never save enough on materials cost to make up for the added capital cost of a tool-changer — that is, until now.

Currently active on Kickstarter, the Snapmaker U1 promises to change that equation. [Albert] got his hands on a pre-production prototype for a review on 247Printing, and what we see looks promising.

The printer features the ubiquitous 235 mm x 235 mm bed size — pretty much the standard for a printer these days, but quite a lot smaller than the bed of what’s arguably the machine’s closest competition, the tool-changing Prusa XL. On the other hand, at under one thousand US dollars, it’s one quarter the price of Prusa’s top of the line offering. Compared to the XL, it’s faster in every operation, from heating the bed and nozzle to actual printing and even head swapping. That said, as you’d expect from Prusa, the XL comes dialed-in for perfect prints in a way that Snapmaker doesn’t manage — particularly for TPU. You’re also limited to four tool heads, compared to the five supported by the Prusa XL.

The U1 is also faster in multi-material than its price-equivalent competitors from Bambu Lab, up to two to three times shorter print times, depending on the print. It’s worth noting that the actual print speed is comparable, but the Snapmaker takes the lead when you factor in all the time wasted purging and changing filaments.

The assisted spool loading on the sides of the machine uses RFID tags to automatically track the colour and material of Snapmaker filament. That feature seems to take a certain inspiration from the Bambu Labs Mini-AMS, but it is an area [Albert] identifies as needing particular attention from Snapmaker. In the beta configuration he got his hands on, it only loads filament about 50% of the time. One can only imagine the final production models will do better than that!

In spite of that, [Albert] says he’s backing the Kickstarter. Given Snapmaker is an established company — we featured an earlier Snapmaker CNC/Printer/Laser combo machine back in 2021— that’s less of a risk than it could be.

Continue reading “A Tool-changing 3D Printer For The Masses”

Battery Repair By Reverse Engineering

Ryobi is not exactly the Cadillac of cordless tools, but one still has certain expectations when buying a product. For most of us “don’t randomly stop working” is on the list. Ryobi 18-volt battery packs don’t always meet that expectation, but fortunately for the rest of us [Badar Jahangir Kayani] took matters into his own hands and reverse-engineered the pack to find all the common faults– and how to fix them.

[Badar]’s work was specifically on the Ryobi PBP005 18-volt battery packs. He’s reproduced the schematic for them and given a fairly comprehensive troubleshooting guide on his blog. The most common issue (65%) with the large number of batteries he tested had nothing to do with the cells or the circuit, but was the result of some sort of firmware lock.

It isn’t totally clear what caused the firmware to lock the batteries in these cases. We agree with [Badar] that it is probably some kind of glitch in a safety routine. Regardless, if you have one of these batteries that won’t charge and exhibits the characteristic flash pattern (flashing once, then again four times when pushing the battery test button), [Badar] has the fix for you. He actually has the written up the fix for a few flash patterns, but the firmware lockout is the one that needed the most work.

[Badar] took the time to find the J-tag pins hidden on the board, and flash the firmware from the NXP micro-controller that runs the show. Having done that, some snooping and comparison between bricked and working batteries found a single byte difference at a specific hex address. Writing the byte to zero, and refreshing the firmware results in batteries as good as new. At least as good as they were before the firmware lock-down kicked in, anyway.

He also discusses how to deal with unbalanced packs, dead diodes, and more. Thanks to the magic of buying a lot of dead packs on e-Bay, [Badar] was able to tally up the various failure modes; the firmware lockout discussed above was by far the majority of them, at 65%. [Badar]’s work is both comprehensive and impressive, and his blog is worth checking out even if you don’t use the green brand’s batteries. We’ve also embedded his video below if you’d rather watch than read and/or want to help out [Badar] get pennies from YouTube monetization. We really do have to give kudos for providing such a good write up along with the video.

This isn’t the first attempt we’ve seen at tearing into Ryobi batteries. When they’re working, the cheap packs are an excellent source of power for everything from CPap machines to electric bicycles.

Thanks to [Badar] for the tip.

Continue reading “Battery Repair By Reverse Engineering”

The camera, lens off to show the 1" sensor.

There’s Nothing Mini About This Mini Hasselblad-Style Camera’s Sensor

When someone hacks together a digital camera with a Raspberry Pi, the limiting factor for serious photography is usually the sensor. No offense to the fine folks at the foundation, but even the “HQ” camera, while very good, isn’t quite professional grade. That’s why when photographer [Malcolm Wilson] put together this “Mini Hasselblad” style camera, he hacked in a 1″ sensor.

The sensor in question came in the form of a OneInchEye V2, from [Will Whang] on Tindie. The OneInch Eye is a great project in its own right: it takes a Sony IMX283 one-inch CMOS image sensor, and packages it with an IMU and thermal sensor on a board that hooks up to the 4-lane MIPI interface on the Raspberry Pi CM4 and Pi 5.

Sensor in hand, [Malcolm] needed but to figure out power and view-finding. Power is provided by a Geekworm X1200 battery hat. That’s the nice thing about the Pi ecosystem: with so many modules, it’s like LEGO for makers. The viewfinder, too, uses 4″ HDMI screen sold for Pi use, and he’s combined it with a Mamiya C220 TLR viewfinder to give that look-down-and-shoot effect that gives the project the “Mini Hasselblad” moniker.

These are a few images [Malcom] took with the camera. We’re no pros, but at least at this resolution they look good.
The steel-PLA case doesn’t hurt in that regard either, with the styling somewhat reminiscent of vintage film cameras. The “steel” isn’t just a colour in this case, and the metal actually makes the PLA conductive, which our photographer friend learned the hard way. Who hasn’t fried components on a surface they didn’t realize was conductive, though? We bet the added weight of the steel in the PLA makes this camera much nicer to hold than it would be in plain plastic, at least.

The OneInchEye module came set up for C-mount lenses, and [Malcolm] stuck with that, using some Fujinon TV lenses he already had on hand. [Malcolm] has released STL files of his build under a Creative Commons NonCommercial license, but he’s holding the code back for subscribers to his Substack.

This isn’t the first Pi-based camera we’ve seen from [Malcolm], and there’ve been quite a few others on these pages over the years. There was even a Hackaday version, to test out the “official” module [Malcolm] eschewed.