The Vectrex was a unique console from the early 1980s. Developed by a company you’ve probably never heard of—Smith Engineering—it was put into production by General Consumer Electronics, and later sold by Milton Bradley. It was an outright commercial failure, but it’s remembered for its sharp vector display and oddball form factor.
The Vectrex was intended for tabletop use in a home environment. However, [Jeroen Domburg], also known as [Sprite_tm], decided to set about building a portable version. This wasn’t easy, but that just makes the development process a more interesting story. Thankfully for us, [Sprite_tm] was kind enough to tell the tale at the 2023 Hackaday Supercon.
Nobody likes opening up a hacking target and finding a black epoxy blob inside, but all hope is not lost. At least not if you’ve got the dedication and skills of [Jeroen Domburg] alias [Sprite_tm].
It all started when [Big Clive] ordered a chintzy Chinese musical meditation flower and found a black blob. But tantalizingly, the shiny plastic mess also included a 2 MB flash EEPROM. The questions then is: can one replace the contents with your own music? Spoiler: yes, you can! [Sprite_tm] and a team of Buddha Chip Hackers distributed across the globe got to work. (Slides here.)
[Jeroen] started off with binwalk and gets, well, not much. The data that [Big Clive] dumped had high enough entropy that it looks either random or encrypted, with the exception of a couple tiny sections. Taking a look at the data, there was some structure, though. [Jeroen] smelled shitty encryption. Now in principle, there are millions of bad encryption methods out there for every good one. But in practice, naive cryptographers tend to gravitate to a handful of bad patterns.
Bad pattern number one is XOR. Used correctly, XORing can be a force for good, but if you XOR your key with zeros, naturally, you get the key back as your ciphertext. And this data had a lot of zeros in it. That means that there were many long strings that started out the same, but they seemed to go on forever, as if they were pseudo-random. Bad crypto pattern number two is using a linear-feedback shift register for your pseudo-random numbers, because the parameter space is small enough that [Sprite_tm] could just brute-force it. At the end, he points out their third mistake — making the encryption so fun to hack on that it kept him motivated!
Decrypted, the EEPROM data was a filesystem. And the machine language turned out to be for an 8051, but there was still the issue of the code resident on the microcontroller’s ROM. So [Sprite_tm] bought one of these flowers, and started probing around the black blob itself. He wrote a dumper program that output the internal ROM’s contents over SPI. Ghidra did some good disassembling, and that let him figure out how the memory was laid out, and how the flow worked. He also discovered a “secret” ROM area in the chip’s flash, which he got by trying some random functions and looking for side effects. The first hit turned out to be a memcpy. Sweet.
Meanwhile, the Internet was still working on this device, and [Neil555] bought a flower too. But this one had a chip, rather than a blob, and IDing this part lead them to an SDK, and that has an audio suite that uses a derivative of WMA audio encoding. And that was enough to get music loaded into the flower. (Cue a short rick-rolling.) Victory!
Well, victory if all you wanted to do was hack your music onto the chip. As a last final fillip, [Sprite_tm] mashed the reverse-engineered schematic of the Buddha Flower together with [Thomas Flummer]’s very nice DIY Remoticon badge, and uploaded our very own intro theme music into the device on a badge. Bonus points? He added LEDs that blinked out the LSFR that were responsible for the “encryption”. Sick burn!
Editor’s Note: This is the last of the Remoticon 2 videos we’ve got. Thanks to all who gave presentations, to all who attended and participated in the lively Discord back channel, and to all you out there who keep the hacking flame alive. We couldn’t do it without you, and we look forward to a return to “normal” Supercon sometime soon.
In today’s episode of Diminutive Device Technology Overview, [Sprite_TM] is at it again – this time conquering the HC32L110. A few weeks ago, we have highlighted the small ARM Cortex M0+ microcontroller, which is outstanding because of its exceptionally small size. We also pointed out a few hurdles, among them – hard-to-approach SDK and documentation, and difficulties making and assembling a PCB for such a small BGA. Today, we witness how [Sprite_TM] bulldozed through all of these hurdles for all of us, and added a few pictures to our collective “outrageous soldering” galleries while at it.
First, he figured out an example layout for this MCU that’s achievable for us even on a cheapest 2-layer board from JLCPCB, keeping distances within the generic tolerance standards by snubbing out a few pins. As a result, we only lose access to four GPIOs – those will have to be kept as inputs, so that nothing burns out. However, that’s the kind of tradeoff we are okay making if it helps us keep our PCB small and lightweight for projects where these factors matter. After receiving the resulting board, he also recorded a short tutorial on soldering such packages at home with a mere hot air gun and a few bare necessities like flux and tweezers – embedded below.
It doesn’t end there, however, as he decided to work around the GPIO fanout limitation in a non-intended way. Evidently, [Sprite_TM] decided to have some fun, taking a piece of regular 0.1″ spacing protoboard and deadbugging the chip with magnet wire, much to our amusement. The resulting contraption, pictured above, worked – and this is ever something you’d like to be able to achieve yourself in times of dire need, whether you make something work or simply to be entertained by making use of a cursed mounting technique, there’s an one-hour-long livestream recording of how this magnet wire contraption came to be. And, of course, that wasn’t the last thing to be shared.
Explain a Game Boy to a child in 2021 and they’ll have little idea of how much impact that chunky grey brick had back in the day. Search for a YouTube video to demonstrate, and you might find the one we’ve put below the break. It starts with the classic Tetris on the Game Boy, then moves on to Super Mario World before treating us to Sonic the Hedgehog, and finally Doom. All seminal games of the Game Boy’s heyday, with one small problem. The last three were never Game Boy titles, and certainly wouldn’t have run on the device’s limited hardware. Most of you will by now not be surprised to find that the narrator is none other than [Sprite_tm], and his Game Boy has one of the nicest Raspberry Pi conversions we’ve ever seen.
Given his previous work we expected the cartridges to have an ESP32 on board that somehow mapped into Game Boy display memory, but in fact he’s swapped the original Nintendo motherboard with a replacement carrying an ICE40 FPGA on one side to handle the Nintendo hardware and a Pi Zero on the other to do the heavy lifting. Insert a Game Boy cartridge and it emulates the original to the point you’d never suspect it wasn’t the real thing, but insert one of the non Game Boy cartridges and it passes an identifier to the Pi which launches a script to run the appropriate Pi code. So the Mario and Sonic games are running in Pi-based emulators, and Doom is running natively on the Pi. It gives the appearance of a seamless gaming experience, wherein lies its charm.
We spend a lot of time looking at retrocomputing in the form of gaming and home computers, but it’s true to say that minicomputers are less common than hardware projects. Perhaps it’s the size, cost, or even relative rarity of the original machines, but DEC minicomputers are a bit unusual around here. [Sprite_TM] hasn’t bought us a PDP11 or a VT102 terminal, but he’s done the next best thing in the form of a miniature working VT102 that also conceals a PDE11 emulator. It runs Tetris, which was originally developed on a Russian clone of the PDP11 architecture, and the 2.1BSD operating system.
Powering it all is an ESP32 module, and the PDP11 emulator is the well-known SIMH software. Porting this to the slightly limited environment of the microcontroller required a few compromises, namely the network stack and the configuration interface. In a particularly clever move [Sprite_TM] enabled BSD networking by writing an ESP32 layer that takes network packets via SIMD directly from BSD. It includes its own DHCP client and wireless network configuration tool, allowing an ancient UNIX-derived operating system from the 1970s to connect to the 21st century Internet through an emulator with its network code stripped out.
The case is a masterwork in OpenSCAD, a complete VT102 unit in miniature with a tiny LCD screen that when printed on a resin printer is a remarkable facsimile of the real thing. It doesn’t have a keyboard counterpart, but even with a miniature Bluetooth ‘board it still looks pretty impressive. In the video below the break he boots it into 2.1BSD, and importantly since it is a server operating system, logs into it from his laptop and plays a game of Zork.
Kids of the 1990’s would call you a liar if you told them that within thirty years you’d go to a conference and be handed a Super Nintendo Entertainment System to wear around your neck. But that’s what happened with the badge Jeroen Domburg, aka [Sprite_TM], designed for the 2019 Hackaday Superconference. It’s built in the Game Boy form factor, complete with a cartridge slot, beautiful screen, and the familiar button layout. But there’s so much more here, like the HDMI port on the bottom and the ability to completely reconfigure the device by dropping a binary file onto it over USB.
Of course what makes this possible is the FPGA at the heart of the design. The story of how the badge was developed is shared in great detail during Sprite’s Supercon talk. The timeline, the hardware choices, and the oopses along the way make for a great story. But what you really don’t want to miss is how he built the machine inside of the FPGA — the collection of Verilog code known as “gateware” that brings together the System-on-a-Chip (SoC). From his delight at being able to spawn more processor cores by changing a single variable, to the fascinating SNES-inspired graphics subsystem, the inside story shared below is even more interesting than the physical device itself.
If you read Hackaday on a regular basis, there are some names you will have seen more than once. People who continually produce fascinating and inventive projects that amaze and delight us, and who always keep us coming back for more. One such hacker is [Jeroen Domburg], perhaps better known in these pages by the handle [Sprite_TM], who has never failed to delight us in this respect.
Today is a special day for [Jeroen] for it is his wedding day, and his friend [Maarten Tromp] has decided to surprise him and his wife [Mingming] with a special gift. At first sight it is simply a pair of blinky badges in the shape of a bride and groom, but closer examination reveals much more. The PCBs are studded with WS2812 addressable LEDs controlled by an ESP32 module and powered by a small LiPo battery, and the clever part lies in the software. The two badges communicate via Bluetooth, allowing them to both synchronise their flashing and flash ever faster as the couple come closer to each other.
The write-up is an interesting tale of the tribulations of designing a badge, from which we take away that buying cheap LEDs may be a false economy. A surprise was that the black-cased and white-cased versions of the LEDs had different timings, and they proved prone to failure.
We wish the happy couple all the best, thank [Sprite_TM] for all he has given us over the years, and look forward to seeing his future projects.