After some initial struggles, we’re good to go!
After the fun and nostalgic experience of pulling our C64s out of storage, I wondered how someone could add new software in this day and age. It didn’t take me long to find Pi1541, which is:
a real-time, cycle exact, Commodore 1541 disk drive emulator that can run on a Raspberry Pi 3B, 3B+ or 3A+https://cbm-pi1541.firebaseapp.com/
All I needed to do was provide an RPi 3, load some stuff to an SD card, make a cable, and I would magically have an emulated 1541!
Making a cable
The process to construct the cable was straightforward after teaching myself how in the world one crimps these tiny Dupont connectors. The trick is to line up and fasten the wire with some needle-nose pliers first, then carefully insert the connector in your crimp tool so you don’t destroy the “box end” where the male connector is received.
Connecting things up
I followed the “Option A” on the Pi1541 site for wiring since I wouldn’t be including any other peripherals. An important piece of this schematic is the bi-directional logic level converter. The RPi speaks 3.3V logic while the C64 speaks 5V.
I loaded up the SD card, connected everything, fired up the C64, and plugged in the RPi. Everything worked perfectly, right? Nope.
At first the RPi didn’t boot at all – I had just a solid red light, so it was time to troubleshoot:
- Did I fry something on the Pi?
- Was the SD card bad?
- Did I load the software incorrectly to the card?
Good news: The Pi wasn’t dead. I confirmed this by booting from a spare SD card that had Raspbian loaded to it. Whew.
I then found the Pi would boot with the Pi1541 firmware, but only if the cables on the header pins were disconnected.
The culprit: The cheapo “bi-directional logic converter” I had lying around didn’t work at all like I assumed it did. Instead of supplying 3.3V and 5V to it (like it properly should), it only wants 5V. Turns out I was sending 3.3V to an output. Ouch.
Now we had a booting Pi with everything connected up, but still no disk drive:
Now we wait
After much troubleshooting I’ve come to the conclusion that I’ll just need to use a proper logic level shifter before proceeding. I’ve ordered some of these and will have to wait patiently as their expected arrival is the end of the month…
See the GitHub Repo!
Every year Clemson plays USC for their state rivalry game. I pull for Clemson and my wife pulls for USC, so we’re what you call a “House Divided”. Since this game takes place on or after Thanksgiving, it’s a great time to incorporate the LED Christmas tree and troll my spouse!
The tree works like this:
- When a team scores, it plays their fight song and lights up with their primary and secondary colors.
- The lights on the tree are distributed by the ratio of points. When it’s tied, they each get 50% of the lights. If Team A has 2/3 more points, they get 2/3 more lights in their color.
- The ring under the star at the top of the tree is the color of winning team. If they’re tied, it’s split.
- When the game is finished, the tree is the color of the team that won.
I used Golang for the software since I primarily write code in another language and want to get better at it. It makes use of various interfaces to aid in testing and abstration:
- The Fetcher interface gets the latest game state from a data source
- The Player interface plays audio at the given path
- The Illuminator interface controls a light source (in this case the LED tree)
The source code for a local data fetcher is included in this repo only. The remote fetcher I built may or may not have used an API meant for this sort of consumption. It simply fetched from a remote data source, unmarshalled a JSON data structure, and supplied what the Fetcher interface needed.
The code runs on a Raspberry Pi and communicates with the MCU via serial. An iHome IBT63 speaker is used to play audio from the Raspberry Pi. I didn’t use the Bluetooth connection and instead used the shared power and audio connector, plugging one end into the RPi’s stereo jack and the other into the USB port.
I cross-compiled from my Mac using the
rpi.sh script in the executable’s directory.
- Uploaded using PlatformIO
- Runs on a NodeMCU ESP8266
My excitement for the new Raspberry Pi 4 turned into disappointment upon learning it couldn’t handle sustained loads without some sort of extra cooling solution. After installing it in this case, I’m happy to say things are looking stable.
The Rover got its own iOS app and I implemented a neat way to control the camera servos.
A really simple project that delivers!
- An SNES-style USB controller
- A Bluetooth speaker
- The Raspberry Pi touch display
- Of course, a Raspberry Pi
The only ‘gotcha’ I came across was when sending audio to the Bluetooth speaker, the emulator I was using (snes9x, the default) got super choppy. This was resolved by adding pisnes as an emulator to EmulationStation and using it instead.