Most of us are familiar with virtual machines (VMs) as a way to test out various operating systems, reliably deploy servers and other software, or protect against potentially malicious software. But virtual machines aren’t limited to running full server or desktop operating systems. This tiny VM is capable of deploying software on less powerful systems like the Raspberry Pi or AVR microcontrollers, and it is exceptionally fast as well.
The virtual machine is built from scratch, including the RISC processor with only 61 opcodes, a 64 bit core, and runs code written in his own programming language called “Brackets” or in assembly. It’s designed to be modular, so only those things needed for a given application are loaded into the VM. With these design criteria it turns out to be up to seven times as fast as comparably small VMs like NanoVM. The project’s creator, [koder77], has even used its direct mouse readout and joystick functionality to control a Raspberry Pi 3D camera robot.
For anyone looking to add an efficient VM to a small computing environment, [koder77] has made the project open-source on his GitHub page. This also includes all of the modules he has created so far which greatly expand the project’s capabilities. For some further reading on exceedingly tiny virtual machines, we featured this project way back in 2012 which allows users to run Java on similar hardware.
[Stanislaw Pusep] has gifted us with the Pianolizer project – an easy-to-use toolkit for music exploration and visualization, an audio spectrum analyzer helping you turn sounds into piano notes. You can run his toolkit on a variety of different devices, from Raspberry Pi and PCs, to any browser-equipped device including smartphones, and use its note output however your heart desires. To show off his toolkit in action, he set it up on a Raspberry Pi, with Python code taking the note data and sending color information to the LED strip, displaying the notes in real time as he plays them on a MIDI keyboard! He also created a browser version that you can use with a microphone input or an audio file of your choosing, so you only need to open a webpage to play with this toolkit’s capabilities.
He took time to make sure you can build your projects with this toolkit’s help, providing usage instructions with command-line and Python examples, and even shared all the code used in the making of the demonstration video. Thanks to everything that he’s shared, now you can add piano note recognition to any project of yours! Pianolizer is a self-contained library implemented in JavaScript and C++ (which in turn compiles into WebAssembly), and the examples show how it can be used from Python or some other language.
[Stanislaw] also documented the principles behind the code, explaining how the note recognition does its magic in simple terms, yet giving many insights. We are used to Fast Fourier Transform (FFT) being our go-to approach for spectral analysis, aka, recognizing different frequencies in a stream of data. However, a general-purpose FFT algorithm is not as good for musical notes, since intervals between note frequencies become wider as frequency increases, and you need to do more work to distinguish the notes. In this toolkit, he used a Sliding Discrete Fourier Transform (SDFT) algorithm, and explains to us how he derived the parameters for it from musical note frequencies. In the end of the documentation, he also gives you a lot of useful references if you would like to explore this topic further!
It’s one of those things that certainly sounds simple enough: take a picture of a receipt, run it through optical character recognition (OCR), and send the resulting information to whatever expense-tracking website or software you wish. There are companies that offer such a service, so it can’t be too difficult to replicate on your own…right?
That’s what [Marcel Robitaille] thought when he set out to create his homebrew “Receipt Ingestion” system, anyway. But in reality it took so much time to troubleshoot and implement that he says it would have been faster to just enter in all his receipts by hand. We’re happy he stuck with it though, otherwise you wouldn’t be reading about it on Hackaday, and we wouldn’t be able to learn anything from the detailed account he’s provided.
It only took an evening to hack together a rough demo, and the initial results were very promising. The code could detect the edges of the receipt, rotate the captured image appropriately, and then pull out the critical information such as date, total amount, business name, etc. He was then able to decipher the API for Splitwise, an online service for splitting bills, by capturing the data sent by his browser while adding a new bill. With this information, writing up some Python code to push his captured data into the service was trivial. So far, so good.
Using a QR code as reference point.
But like so many horror films that begin with a happy family starting a new life in a beautiful home, there was a monster lurking in the shadows. It’s one thing to capture data from perfectly clean and flat receipts, but quite another to get any useful info out of one that spent half the day crumpled up in your back pocket. The promising proof of concept that worked a treat under controlled conditions failed completely in the real-world, with [Marcel] reporting that only 1 in 5 receipts he tried to scan actually went through.
In the end, [Marcel] realized that the best way to handle the unreliable condition of the receipts was to focus on a different object in the image. He came up with a QR code marker that he could put on the table with the receipt to be scanned, which his software can use as a known point of reference. This greatly improves the reliability of the image rotation and transformation, which in turn makes the OCR more reliable. It also makes it much easier to tell which images need to be scanned — if there’s no QR code found, the software just skips that shot and keeps looking.
The unique challenges of digitizing large amounts of printed content using OCR makes for some fascinating problem solving, and we’re glad [Marcel] shared this particular story with us. While there’s still some edge cases that need chasing down, he’s using the software on a nearly daily basis, and has posted it up on GitHub for anyone who might wish to build on his efforts.
We’re huge fans of taking retro games and adding new graphics features to them, so you had to know that when [Sultim Tsyrendashiev] released his ray-traced Doom engine, we would have to cover it. Now this does break with tradition — instead of running Doom on every conceivable platform, this version requires an AMD or Nvidia ray tracing capable card. On the other hand, the spirit of Doom is certainly alive, as ray-traced Doom has already been demonstrated on the Steam Deck. Check out the video below for a demo, and come back after the break for more info.
The most exciting part of this graphical feat may be the RayTracedGL1 library that “simplifies the process of porting applications with fixed-function pipeline to real-time path tracing.” Besides Doom, there’s also been demos made of Serious Sam and Half-Life 1. There’s even experimental Linux support! We managed to compile and test it on our system, running a 6700 XT and Fedora 35 with bleeding edge Mesa. There are a few visual glitches to work out, but it’s an outstanding project so far. The only complaint we have is that it’s based on prboom, not the still-maintained GZDoom, though with enough attention who knows where the project will go. If this leaves you hungry for more, check out more retro-upgrades, or Doom on more devices.
There was a time when “real” engineering workstations ran Linux Unix. Apollo and Sun were big names and Sun’s version was Solaris. Solaris has been an iffy proposition since Oracle acquired Sun, but Oracle announced last month that you can download and use Solaris 11.4 CBE free for non-production use.
Do you care? If you ever wanted to run “real” Unix this is an option although, honestly, so is Free BSD and it probably has better community support. On the other hand, since you can virtualize a machine to spin up, it might be worth a little time to install it.
On the other hand, if you have an old SPARC machine — this could be big news. We aren’t sure how far back the hardware this will support will go, but this could be just what you need to breathe new life into that eBay pizza box from Sun you’ve had in the basement. Of course, if you have an FPGA SPARC system, this might be interesting too, but we have no idea how much other stuff you need to implement to be able to benefit from Solaris.
Will you install Solaris? If so, tell us why. We are sure we won’t have to prompt you to tell us why not. In 2017, we thought we’d seen the end of Solaris, but apparently not. Maybe this will help those folks still on Solaris 9.
The first PCBs we built involved a draftsman laying out large pieces of tape. The finished artwork would be photographically reduced to produce the board. This solved a few problems. It was easier to work on the large pieces and any errors were reduced by the scale amount. Boards from this era have a distinct appearance because the tracks are generally curved. But when computer-aided drafting took over, the early packages couldn’t deal with wavy lines making all sorts of angles. So traces started appearing at very common angles like 45 degrees or 90 degrees only. If you use KiCAD, though, there’s no reason to have rectilinear traces. Now there is a plugin to help make your boards appear like old-fashioned circuit boards.
The video by [mitxela] below talks about how we got here and debunks some common myths about PCB design. The plugin produces rounded corners and teardrop-shaped pads. There’s also a second post on the topic with more details. The effect isn’t just ornamental. There are some reasons graceful traces might be better than sharp angles.
[Görg Pflug] wrote in with his really nice graphics library. It’s got multiple layers, two text consoles, greyscale, internal halftoning, and sprites. It can pull off a number of classic graphics tricks and demos. Oh yeah, and did we mention it runs on a freaking ATtiny85 and an I2C OLED screen?!
This is an amazing piece of work — if you’d asked us if this was possible, we would have probably said “no”. And now it’s yours to use in your own projects. The GitHub repo is full of demos showing off everything from switching between multiple layers, extremely rapid text scrolls, animations, boing balls, and even a Wolfenstein-style raycaster. On an ATtiny85.
There’s a demo video, embedded below, that shows it all off, but honestly you have to think about what’s going to to be suitably wowed. The first demo just seems to have a graphic wave over static text, for instance. No big deal? It’s blending the greyscale layers together and dithering them out to black and white for the OLED in real time! On an ATtiny85.
While the library is written in straight C++, there are even a couple examples of how you’d integrate this with Arduino’s Wire library if you so wished. We don’t know about you, but this makes us want to whip together an ATtiny85 and SSD1306 OLED demo board just to start playing around. This isn’t just an amazing hack, but it would also be a useful way to add graphics and a nice console to any project you’re working on.
Did we mention it’s all done on an ATtiny85? Over I2C? Kudos!
