The classic SP0256-AL2 speech chip has featured a few times on these pages, and if you’ve not seen the actual part before, you almost certainly have heard the resulting audio output. The latest Python library from prolific retrocomputing enthusiast [Nick Bild] brings the joy of the old chip to the Raspberry Pi platform, with an added extra trick; support for the venerable AY-3-8910 sound generator as well.
The SP0256-AL2 chip generates vaguely recognisable speech using the allophone system. Allophones are kind of like small chunks of speech audio which when reproduced sequentially, result in intelligible phonemes that form the basis of speech. The chip requires an external device to feed it the allophones at a regular rate, which is the job of his Gi-Pi library.
This speech synthesis technology is based on Linear-predictive coding, which is used to implement a human vocal tract model. This is the same coding method utilized by the first generation of GSM digital mobile phones, implementing a system known as Full-Rate. Both an LPC encoder and an LPC decoder are present on the handset. The LPC encoder takes audio in from the user, breaks it into the tiny constituent parts of speech, and then simply sends a code representing the audio block, but not the actual audio. Obviously there are a few more parameters sent as well to adjust the model at the receiving side. The actual decoding side is therefore not all that dissimilar to what the AY-3-8910 and related devices are doing, except you the user have to create the list of audio blocks up-front and feed the chip at the rate it demands.
People keep warning that Skynet and the great robot uprising is not that far away, what with all this recent AI and machine-learning malarky getting all the attention lately. But we think going straight for a terminator robot army is not a very smart approach, not least due to a lack of subtlety. We think that it’s a much better bet to take over the world one home appliance at a time, and this AI Powered coffee maker might just well be part of that master plan.
[Mark Smith] has taken a standard semi-auto espresso maker and jazzed it up a bit, with a sweet bar graph nixie tube the only obvious addition, at least from the front of the unit. Inside, a Raspberry Pi Zero sits atop his own nixie tube hat and associated power supply. The whole assembly is dropped into a 3D printed case and lives snuggled up to the water pump.
The Pi is running a web application written with the excellent Flask framework, and also an additional control application written in python. This allows the user to connect to the machine via Ethernet and see its status. The smarts are in the form of a simple self-grading machine learning algorithm, that takes a time series as an input (in this case when you take your shots of espresso) and after a few weeks of data, is able to make a reasonable prediction as to when you might want it in the future. It then automatically heats up in time for you to use the machine, when you usually do, then cools back down to save energy. No more pointless wandering around to see if the machine is hot enough yet – as you can just check the web page and see from the comfort of your desk.
But that’s not all [Mark] has done. He also improved the temperature control of the water boiler, and added an interlock that prevents the machine from producing a shot until the water temperature is just so. Water level is indicated by the glorious bar graph nixie tube, which also serves a few other user indication duties when appropriate. All in all a pretty sweet build, but we do add a word of caution: If your toaster starts making an unreasonable number of offers of toasted teacakes, give it a wide berth.
For those who like to muck around in boats, there’s enough to worry about without wondering if you’re going to run aground. And there’s really no way to know that other than to work from charts that show you exactly what lies beneath. But what does one do for places where no such charts exist? Easy — make your own homebrew water depth logger.
Thankfully, gone are the days when an able seaman would manually deploy the sounding line and call out the depth to the bottom. [Neumi]’s sounding rig uses an off-the-shelf sonar depth sounder, one with NMEA, or National Marine Electronic Association, output. Combined with a GPS module and an Arduino with an SD card, the rig can keep track not only of how much water is below it, but exactly where the measurement point is. The whole thing is rigged up to an inflatable dinghy which lets it slowly ply the confines of a small marina, working in and out of the nooks and crannies. A bit of Python and matplotlib stitches that data together into a bathymetric map of the harbor, with pretty fine detail. The chart also takes the tides into account, as the water level varies quite a bit over the four hours it takes to gather all the data. See it in action in the video after the hop.
There’s something cool about revealing the mysteries of the deep, even if they’re not that deep. Want to go a little deeper? We’ve seen that before too.
The idea of having software translation programs around to do things like emulate a Super Nintendo on your $3000 gaming computer or, more practically, run x86 software on a new M1 Mac, seems pretty modern since it is so prevalent in the computer world today. The idea of using software like this is in fact much older and easily traces back into the 80s during the era of Commodore and Atari personal computers. Their hardware was actually not too dissimilar, and with a little bit of patience and know-how it’s possible to compile the Commodore 64 kernel on an Atari, with some limitations.
This project comes to us from [unbibium] and was inspired by a recent video he saw where the original Apple computer was emulated on Commodore 64. He took it in a different direction for this build though. The first step was to reformat the C64 code so it would compile on the Atari, which was largely accomplished with a Python script and some manual tweaking. From there he started working on making sure the ROMs would actually run. The memory setups of these two machines are remarkably similar which made this slightly easier, but he needed a few workarounds for a few speed bumps. Finally the cursor and HMIs were configured, and once a few other things were straightened out he has a working system running C64 software on an 8-bit Atari.
Unsurprisingly, there are a few things that aren’t working. There’s no IO besides the keyboard and mouse, and saving and loading programs is not yet possible. However, [unbibium] has made all of his code available on his GitHub page if anyone wants to expand on his work and may also improve upon this project in future builds. If you’re looking for a much easier point-of-entry for emulating Commodore software in the modern era, though, there is a project available to run a C64 from a Raspberry Pi.
Hackers love the warm glow of a vacuum fluorescent display (VFD), and there’s no shortage of dead consumer electronics from which they can be pulled to keep our collective parts bins nicely stocked. Unfortunately, figuring out how to actually drive these salvaged modules can be tricky. But thanks to the efforts of [Lauri Pirttiaho], we now have a wealth of information about a VFD-equipped front panel used in several models of Topfield personal video recorders.
The board in question is powered by a Hynix HMS99C52S microcontroller and includes five buttons, a small four character 14-segment display, a larger eight character field, and an array of media-playback related icons. There’s also a real-time clock module onboard, as well as an IR receiver. [Lauri] tells us this same board is used in at least a half-dozen Topfield models, which should make it relatively easy to track one down.
After determining what goes where in the 6-pin connector that links the module with the recorder, a bit of poking with a logic analyzer revealed that they communicate over UART. With the commands decoded, [Lauri] was able to write a simple Python tool that lets you drive the front panel with nothing more exotic than a USB-to-serial adapter. Though keep in mind, you’ll need to provide 17 VDC on the appropriate pin of the connector to fire up the VFD.
What’s that? You don’t need the whole front panel, and just want to pull the VFD itself off the board? Not a problem. Our man [Lauri] was kind enough to document how data is passed from the Hynix microcontroller to the display itself; critical information should you want to liberate the screen from its PVR trappings.
Especially over the last year and a half, most of us have gotten the feeling that there’s precious little distinction between our computers and ourselves. We seem welded together, inseparable even, attached as we are day and night to our machines as work life and home life blend into one gray, featureless landscape where time passes unmarked except by the accumulation of food wrappers and drink cans around our work areas. Or maybe it just seems that way.
Regardless, there actually is a fine line between machine and operator, and in most instances it’s that electromechanical accessory that we all love to hate: the keyboard. If you buy off the shelf, it’s never quite right — too clicky, not clicky enough, wrong spacing, bad ergonomics, or just plain ugly design. The only real way around these limitations is to join the DIY keyboard crowd and roll your own, specifically customized to your fingers and your needs — at least until you realize that it’s not quite perfect, and need to modify it again.
Hitting this moving target is often as much a software problem as it is a hardware issue, but as is increasingly the case these days, Python is ready to help. To go into depth on how Python can be leveraged for the custom keyboard builder, our good friends at Adafruit, including Limor “Ladyada” Fried, Phillip Torrone, Dan Halbert, Kattni Rembor, and Scott Shawcroft will stop by the Hack Chat. We suspect they’ll have some cool stuff to show off, in addition to sharing their tips and tricks for making DIY keyboards just right. If you’re building custom keebs, or even if you’re just “keyboard curious”, you won’t want to miss this one.
No, despite what it might look like, this isn’t some early Halloween project. The creepy creation before you is actually a tongue-in-cheek “robot” created by the prolific [Nick Bild], a topical statement about companies asking their remote workers to come back into the office now that COVID-19 restrictions are being lifted. Why commute every day when this ultra realistic avatar can sit in for you?
OK, so maybe it’s not the most impressive humanoid creation to ever grace the pages of Hackaday. But if you’re looking to spin up a simple telepresence system, you could do worse than browsing through the Python source code [Nick] has provided. Using a Raspberry Pi 4, a webcam, and a microphone, his client-server architecture combines everything the bot sees and hears into a simple page that can be remotely accessed with a web browser.
Naturally this work from home (WFH) bot wouldn’t be much good if it was just a one-way street, so [Nick] has also added a loudspeaker that replays whatever he says on the client side. To prevent a feedback loop, his software includes a function that toggles which direction the audio stream goes in by passing the appropriate commands to the bot over SSH; a neat trick to keep in mind for your own, less nightmarish, creations.