Electronics Projects: 'Originals'

This page has 'original' electronics projects I'm working on: none of them are actually completed, and there's no guarantee they will be. I'm really trying to, though!

Picogirl - RP2040 Gameboy DMG Emulator

An overhead photo of the Picogirl emulator breadboard setup. The main breadboad section consists of three smaller breadboards joined together in a rectangle, with the screen attached to the 'fourth' space in the upper right corner. The upper left corner contains the Pico (actually a WaveShare Pico-derivative) and some external flash. The bottom left corner has the debug OLED display and the connection to the gamepad, while the bottom right corner has the audio 'mixer', amplifier, and speaker. As well as the main display screen, the upper right corner also has a mount for the frame counter 7-seg display. To the right of the breadboard assembly is the gamepad, which is silver-grey with blue light blue buttons. It is connected via a couple of ribbon cables, and has red and yellow debug LEDs.
Overview of the current Picogirl breadboard setup.

A Gameboy emulator that runs on RP2040 (Raspberry Pi Pico) is nothing new, and this is very much an amateur attempt: if you're looking for a ready-to-go Gameboy emulator that runs well on the Pico, I would suggest deltabeard's excellent Peanut-GB, which I have looked at many times when I'm stuck on how to implement something. However, I wanted to write a Gameboy emulator with some limited constraints and interfacing with low-level hardware, so I'm having a go at it! This is Picogirl, an emulator for the original Gameboy DMG that runs on RP2040.

An animated gif of the Picogirl display screen showing the Kirby's Dreamland title screen, which has kirbys marching along the bottom and flying around the logo. The actual display area is truncated at the top and bottom due to the resolution of the screen, and needs to be scrolled up and down to view the entire image.
The title screen of Kirby's Dreamland, showing the auxilary up/down screen scroll.
An animated gif of the Picogirl display screen showing gameplay of Kirby's Dreamland. Kirby walks along the first area of the first stage, 'Green Greens', fighting enemies and jumping around, before reaching the warp star at the end and flying away.
More Kirby's Dreamland gameplay. By the standards of the website, the size of this gif is decadent.
An animated gif of the Picogirl display screen showing Kirby fighting the first boss of Kirby's Dreamland, Whispy Woods. Kirby dodges gusts of wind and spits out apples at the boss. The frame counter is visible in the upper left, hovering around 50 frames per second.
I like to call this a 'PAL Gameboy' because it runs at ~50fps...

The overall structure of emulator/supporting hardware isn't too complex: the first RP2040 core handles CPU and PPU (Picture Processing Unit) emulation (using a cycle timing approach to keep everything in sync), while the second core just handles writing to the display over SPI. Input is provided via a keyswitch matrix (which is how the Gameboy's CPU is expecting to interpret input anyway) wired to the GPIO pins. APU (Audio Processing Unit) emulation is currently a bit hacky, for reasons I'll get into later, but this is mostly handled by the PWM blocks and sent out through a very very simple mixer into an off-the-shelf Adafruit amp.

At the moment, games have to be baked directly into the binary with a #include header file (yes, I'm writing this in C++) - game loading is on the to-do list, but it'll have to be copied to the QSPI flash onboard the microcontroller for speed. There's also some indicator LEDs on the 'gamepad', a 4-digit 7-segment display connected over I2C as a framerate counter, and a little OLED connected over I2C to print debug information (which is absolutely indispensable).

A photo of the Picogirl gamepad's PCB, which is green and contains a lot of empty space. The buttons are standard 6x6mm through-hole switches which are designed to be covered by more ergonomic 3D-printed button caps. There are LEDs and resistors in the upper left corner, the switch matrix diodes in the centre, and headers to connect the ribbon cables at the centre of the top edge. There are several labels on the silkscreen, as well as the text 'girls are now playing' near the top (referencing the 'girls are now praying' text seen on the loading screens of several Touhou games).
The populated PCB of Picogirl's test gamepad.

The gamepad was something I designed after I was actually getting games running and playing them to test the emulator: the original setup just had tiny buttons in the centre of a breadboard with diodes stretched between them, which was absolutely miserable to use as input. The design isn't complicated: it basically just puts the eight Gameboy buttons in a nice form factor on a single board, wires them up to the diodes, and puts the row/column pins on a header to connect to the rest of the Picogirl breadboard.

It also includes a 'debug header' which has ground, three direct-to-ground buttons, and a couple of LEDs. These 'aux buttons' can be programmed to do a bunch of things, but the main use for two of them is to scroll the screen up and down, since the most reasonable screen I could find is only 160x128 (vs. the Gameboy's actual 160x144 resolution). I'm planning to switch to a higher res screen at some point, but most of the other panels are either way smaller or larger in physical size, and would all require sizeable borders around the actual screen render area.

A top-down photo of an earlier PCB setup for Picogirl. The main differences are an actual Raspberry Pi Pico H board, several status LEDs in the bottom right corner, and a bunch of tiny switches and diodes in the bottom left corner instead of a proper gamepad.
An earlier version of the Picogirl setup, showing the barely-connected audio and a miserable control setup in the bottom left.

Audio emulation is currently... very hacky. The first three channels work by reading the values in the register and just turning on a PWM block at the correct frequency (although channel 1 does respect the frequency/period sweep, changing the PWM frequency accordingly). This means no volume adjustment, since that would require the Pico to micromanage the PWM blocks to generate a tone at the correct frequency, and it also means that channel 3 doesn't actually play any unique waveforms: the wave data registers are ignored entirely. Channel 4, being white noise, is bit-banged using a couple of pre-generated arrays of random bits (depending on what LFSR length is selected). It does work pretty well and music is extremely recognizable (not to mention that using the PWM blocks means the frequencies are independent of how fast the emulator's running), but it's pretty shoddy and I want to improve it. Bit-banging the white noise channel is also a significant performance hit.

The current best bet I have is writing an APU implementation using the PIO (Programmable Input/Output) blocks of RP2040, which should remove the burden from the main CPU entirely and allow for more accuracy. I don't have very many instructions to work with, though. For channel 4 specifically, I've put together a hardware LFSR that the Pico can drive for fast and very accurate white noise generation: more on that in the next section.

LFSR (Linear Feedback Shift Register)

An annotated picture of the linear feedback shift register breadboard setup, with different parts labelled. There's two 8-bit shift registers for a total of 16 bits, the chip containing the XNOR gates for feedback, a bank of inverters to delay the shift signal in order to use it for latching, several LEDs showing the value of each bit in the shift register, an amplifier and speaker, a potentiometer for frequency control, and a Raspberry Pi Pico to read the potentiometer and set the output clock frequency.
Overview of the LFSR setup, with annotations.

LFSRs have lots of theory behind them and many applications, which you can read about on their Wikipedia page. The basic idea is that by using the outputs of a shift register and some logic gates, you can use the current state of the shift register to feedback into the input. This will create a sequence that isn't actually random, but will result in a very long pseudorandom chain that doesn't require any 'computation' to generate (all the Pico is doing here is reading the potentiometer and generating and clock signal).

What I care about, however, is using them to make fucked up noises. You can't hear this one because I can't upload audio, but it sounds pretty neat. You can look at the pretty lights flashing though.

An animated gif of the LFSR breadboard setup scrolling through various frequencies, which is visible via the per-bit LEDs showing bits scrolling through the shift registers. The LEDs go from clearly flashing in sequence, to only slight flickering being visible and then just appearing to be on steadily at the higher frequencies.
When the lights look like they're on steadily, the frequency is very high.

Picosynth (not the PICO-8 tool by Johan Peitz I should really think of another name)

A photo of a breadboard setup, consisting of two larger white breadboards attached together along their long edges and then four tiny breadboards in various colors attached at the bottom. The top white breadboard only contains the Pi Pico and a small OLED display, while the bottom one has several buttons and diodes to form a switch matrix. From left to right, the tiny breadboards are: a yellow one containing the audio mixer, amplifier, and speaker; a red one which is empty; a green one containing some small LEDs and resistors; and a blue one containing some additional buttons and trim potentiometers. There is also a seperate board with a slide potentiometer to the right of the setup.
Overview of the previous Picosynth setup.

Picosynth is meant to be an all-in-one Pi Pico-based synthesizer - again, that's not anything new, but I wanted to try making one myself so I am. The original concept was to use the main CPU cores to bit-bang wave data with high frequency PWM controlling the 'volume', but much like in Picogirl, that's just too much work for the CPU to dedicate itself to (once more than a couple of tones are playing, the pitch starts to fall as the Pico can't keep up anymore). I still want to do it and will probably end up using a similar solution to the PIO APU I'm planning for Picogirl (in fact, I'm probably going to convert my LFSR prototype into a general PIO synthesizer testbed), but for now it's on the backburner.

A photo of the previously-described breadboard setup, this time centered and zoomed in on the switch matrix. Jumper wires cover the actual buttons, making them quite difficult to press.
A closeup of the atrocious 'keyboard'.
A photo of an earlier implementation of the 'audio mixer', simply consisting of four input channels connected to a single output via some resistors. The current setup is also this, but is laid out slightly neater.
This is what an audio mixer is, right?.

Slimetime - Hybrid Virtual Slime Mold Pet

A photo of a breadboard with a rack components attached to the long edge. The breadboard itself is in the background and out of focus, with a Raspberry Pi Pico, a couple of DIP form factor chips, and a piezo buzzer on it. The rack of components in the foreground has a small OLED display, a small LCD display, a rotary encoder, and a rotary potentiometer.
Current state of the prototype.

So this is a project that's extremely extremely early on, to the point where I don't really have much to write about it. The basic idea is that it's a virtual pet, like a Tamagotchi, but instead of taking care of the pet via the software on the device you take care of an actual slime mold growing in a little removable channel. Since the slime mold can conduct electricity, keeping it healthy enables games and features on the virtual pet device. I'd been thinking of making a virtual pet for awhile, and this solves several issues I was having with the concept: having the pet be a real slime mold reduces the amount of attention it needs (a Tamagotchi needs to be watched basically constantly for 'good care'), adds a real incentive to continue to provide care after the novelty wears off, and sidesteps a lot of the ideological problems that pop up with a Tamagotchi around gender, eating habits & body weight, etc.

The project is inspired and based on the work by Jasmine Lu and Pedro Lopes in their work Integrating Living Organisms in Devices to Implement Care-based Interactions, which explicitly mentions virtual pets as a touchstone and asks the participants of the study about them. It's really good and you should read it (there's an open access copy available here, last I checked). However, I have to come clean: I only found out about it because a certain extract gained traction on Tumblr, and it gained traction because... well I'll just quote it here.

While she was sick, P5's partner helped take care of her as well as helped to take care of her device. P5 recounts, "I was taking care of the slime and feeding it oats and stuff, my partner was also feeding me oatmeal because I was sick and so she was like you're my little slime and I was like yeah, I am (...) then she started calling me her slime because I mean me and the slime, like, we were eating the same stuff, (...) we were both being fed and watered".

Thank you to participant P5 and her partner for their contribution to the dissemination of research.

An animated gif showing a 1-bit, black-and-light-blue OLED display. The left half has a rendering of Kagerou Imaizumi from Touhou Project, as she appears in 'Alternative Facts in Eastern Utopia'. The right half has a 2x2 square of different patterns. On top of both of these, a rendition of Momiji Inubashiri's sprite from the tenth Touhou game, 'Mountain of Faith', travels from left to right across the screen, bobbing up and down as she goes.
Momiji is going on a journey.

The first thing I did was getting a good rendering baseline for the little OLED display I'm using: since I eventually want this to be a virtual pet with little sprites and games and a decent UI, having a way to draw sprites with 'transparency' in arbitrary locations on the screen is actually pretty important (and something the example SSD1306 driver I've been adapting couldn't do "out of the box"). Eventually I want to expand this into a general rendering layer that can plug into different types of displays (an OLED isn't really a good display technology for something that's going to be on all the time), but for now this is extremely good enough.

A photo of the back of a couple of the component mounts, showing the rotary potentiometer and encoder screwed into their mounts.
This mounting system actually turned out really really well.

While resistance measurement and op-amp shenanigans were next, along the way I added this little modular rack system to put components on. It was originally just intended for stuff that couldn't go on a breadboard, like the potentiometer and encoder, but I also expanded it to stuff like displays that are perfectly breadboard-able but take up way more room than their number of pins.