Maybe if I share videos of half-finished projects it’ll motivate me to finish them!
Category: Projects
Categories
64×64 LED Matrix + Doom
From the weekend hacks department: I now have DOOM running on my 64×64 matrix!
- A Raspberry Pi 2B drives the 64×64 3mm pitch LED matrix via the Matrix Bonnet.
- I’m using SDL2 to handle scaling the original resolution of 320×200 down to 64×40 as well as the game ticks, user input, and sound.
- It was mainly an exercise in Makefiles and linking C libraries – the hard parts were done in the libraries. 🙌 Generic Doom / Rpi RGB LED Matrix
- The matrix is covered with an acrylic panel that smooths out the LEDs and makes it pleasant to look at.
- The flickering effect isn’t seen in real life, it’s just how the camera captured it.
GitHub repo: https://github.com/twstokes/doom-matrix
Categories
OpenBSD + iMac G4
Fun fact: You can put the latest version of OpenBSD on a PPC 32-bit processor like the G4. Fun to dual boot with Mac OS 9 if you want a modern, secure computer!
Some notes
The OpenBSD docs are really good and thorough. Open Firmware needs some tweaking if you want to boot directly into OpenBSD, so this is what I did after booting into it with command+option+o+f:
setenv auto-boot? True
setenv boot-device hd:,ofwboot
reset-allI failed to get a USB install working
Initially I didn’t want to mess with the internal drive of the iMac since I had both Mac OS 9 and Mac OS X installed, so I tried to install to a USB drive. Although the installation succeeded (albeit extremely slowly due to USB 1.1), the boot into the system failed due to the following error:
panic: rootfilesystem has size 0
Looking at the trace of the kernel boot process it was evident why: Even though we installed the OS to sd0 (the mounted USB device), the kernel kept trying to mount wd0 which is the internal IDE drive.
I tried what I knew:
- Tweaking the
boot-devicevariable in Open Firmware - Using a different USB slot
- Booting into the recovery kernel (
bsd.rd) and mounting the USB to see if I could tweakfstab
Supposedly if we get to the boot prompt we can pass a -a flag for the root device (docs), but I couldn’t figure out how to get there.
Ultimately I decided to install OpenBSD to the main internal drive for now. If I get a hankering for Mac OS 9 I still have the trusty Power Mac G4.
The best setup will eventually be a dual or triple-boot. Trying to make the super-slow USB drive work is probably a terrible idea unless we plan to run it in a ramdisk mode the entire time.
The graphics driver kinda works
As you can see from the glxgears output above graphics are not accelerated. I’ve mostly played with the machine over SSH in a headless state so this hasn’t bothered me too much. I did glance at dmesg and saw that the expected driver, nv, was loaded and detected the card so I’m not totally sure what’s happening. I’m having flashbacks of when I used to spend hours tweaking xorg.conf and that may be on the horizon again.
If just running the console we still want the screen to sleep and I found I needed to make a couple tweaks for that to work.
First I needed to shut down X Windows:
rcctl stop xenodm
Then I needed to disable output activity from waking the screen:
display.outact=off
After that the screen would shut off after however many milliseconds were set for display.screen_off.
Copying over /etc/examples/wsconsctl.conf to /etc/ is a great starter config.
Oh yeah, it runs DOOM
(Very poorly, presumably until the graphics driver is tweaked)
Running Chocolate Doom was painful. Even the setup utility had a good second or so input lag!
I first want to acknowledge that I did the thing that I try to never do: I showed off a snazzy project, left some hints here and there of how it worked, said I would follow up with full details… and never did. That’s lame.
I’ve had multiple people reach out for more info and I’m glad they did, since that’s pushed me to finally get some repos public and this belated follow-up written. Apologies!
To jump straight to it, I’ve published these two repos:
Hardware
Let’s first go over the hardware involved. The most important piece, of course, is the Alfa-Zeta XY5.
In my case, the 14×28 board was made up of two 7×28 panels connected together via RJ-11.
The panels are pricey, but they can be thought of as “hardware easy-mode”. Alfa-Zeta has done the hard job building the controller that drives the hardware and all we have to do is supply power and an RS-485 signal that abides by their protocol.
If you purchase a panel from them there are two important documents to request:
- The main manual that describes the specs, features, and things like the DIP switch settings.
- The protocol for sending commands to the controllers (which is really simple).
These can easily found by searching around, but if you own a panel the company should supply them. Most of the protocol can be deduced by looking at open source code.
Components
- Alfa-Zeta XY5 – 14×28 Flip Dot display
- NodeMCU ESP8266 – MCU
- 3.3v RS-485 to TTL – Allows the MCU to communicate over RS-485
- ALITOVE AC 100-240V to DC 24V 5A Power Supply – Required to power the panels
- BINZET DC 12V 24V to 5V 5A – Optional, used to step down power to the MCU so we have one power source
The 24V -> 5V converter isn’t necessary if you supply power to the MCU independently, say through a USB power adapter.
Connection overview
- 24V DC goes to both panels
- 24V DC goes to the step-down converter, 5V DC goes to the 5V input of the NodeMCU
- NodeMCU is wired to the RS-485 to TTL converter
VCC -> 3.3vGnd -> GndDE -> 3.3v pulled high because we're always transmittingRE -> 3.3v pulled high because we're always transmittingDI -> TX[x] x being 0 or higher depending on boardRO -> RX[x] most boards only have the main serial IO, but boards like the Mega have multiple
- RS-485 -> Only one panel controller – not both
An Arduino Mega is driving the board in this photo.
Software
The MCU
See https://github.com/twstokes/flipdots for the code that runs on the MCU.
At the moment there isn’t much to it – you can either compile the firmware to run in a mode that writes data from UDP packets to the board, or you can draw “locally” using Adafruit GFX methods.
See the README in the repo above for more details.
iOS / iPadOS / macOS
See https://github.com/twstokes/flipdots-ios for the code that runs on these devices.
Semi-interestingly I utilized Adafruit GFX again, this time via swift-gfx-wrapper to draw to the board over UDP. It’s hacky and experimental, but that’s part of the fun.
See the README in the repo above for more details.
The Power Mac G4 didn’t get the “windtunnel” nickname for nothing – its power supply is quite loud. Thankfully with the help of an adapter, a standard ATX (or SFX) power supply can replace it. I love putting “modern” power supplies into my retro machines to get less noise and clean power.
I went with a Corsair SF600 from my previously built Mini-ITX machine and it’s worked really well due to its small form factor. Although it’s rigged in place with two wire ties it’s not going anywhere. 😀
Resources:
From the seasonal hacks department, here’s my toy app to make it snow on macOS. ❄️
https://github.com/twstokes/snowflakes
How it works:
When the app is told to make it snow it adds full-screen non-interactive windows on each display and inside those windows adds a SpriteKit view with a scene inside that contains emitters.
That’s basically it!
Thanks to Whisper and this awesome port, the tree is responding to spoken words. 🗣🎄
Since the tree itself only has a low-powered MCU, we need another machine to act as a listener.
The architecture is:
- A machine in my office runs the Whisper model and listens for words.
- If certain keywords are found it finds a corresponding command to run (e.g. do a theater chase sequence in a green color).
- It sends that command to the tree over the network.
For now I’m running it from iOS and macOS, so I wrote the current implementation in Swift. The code is currently still in “hack” status, but working well!
Now it’s time to test it when talking to coworkers at Automattic.
Something I should’ve done long ago – enabling OTA (Over The Air) firmware updates so I don’t have to disassemble the project box and move the tree every time I want to change its code.
To add a touch of UX, the pixels represent the upload progress. 😎
I’m finally taking the time to make the NeoPixel Christmas tree smarter this year.
My current plan is to:
- Connect it wirelessly to the network (it has an ESP8266, after all)
- Run a UDP server on it
- Respond to various commands
- Write a client that sends UDP packets to it
It’s fun to design UX for limited hardware. In this case, the tree starts with an orange pattern that rotates until a WiFi connection is successful. If it fails the tree will go red, otherwise the tree briefly goes green to let the end user know all is well before starting its first sequence.
Nifty! 🎄
Categories
Domo Arigato
If the objective was to make the robot less creepy, I’ve failed miserably.