When we started preparing for the game jam (2 months ahead) I had the idea to use a fantasy console, such as Pico-8, and then run it on a small computer with a display and some buttons attached.
So I ordered a Raspberry Pi Zero with a display hat. The plan was to install Linux on it, run the Pico-8 console on startup and show the game on the tiny 128x128 px display. Pico-8 only supports 128x128 px resolution, so that shouldn’t be a problem. Oh, how wrong I was…
While waiting for the components, I made a simple demo game for the Pico-8. It was just a ball bouncing off walls and a paddle controlled by the player.
Once it arrived, and after a few days messing around with various display drivers and programs, learning about some new Linux concepts and internals, I got the display and buttons working. Few approaches that I tried:
- Use fbcp, which supports the display directly, although not with the latest Raspberry Pi video driver.
- Use fbtft driver, which creates a second Linux framebuffer, but I couldn’t get Pico-8 to render the game to the framebuffer directly.
- Use fbtft, start an X server and run the game, which works, but has additional overhead.
When I finally ran the demo game, it worked — the ball was bouncing, the player could control it using the buttons on the “console”. But the frame-rate was terrible, and since the Zero is not exactly a powerful computer, there was little hope of improving it.
So I tried a different approach. Instead of using a full-blown computer to run a fantasy console that artificially imposes limitations of older and less powerful hardware, let’s use that hardware directly. I won’t gain any extra computing power (in terms of processor frequency and memory size), but at least I’ll be fully in control and any bad performance will be caused by my incompetence.
After some research into modern open-source handheld consoles, I found an amazing project from the neighbouring Czechia.
Picopad is pretty much a Raspberry Pi Pico with a display, speaker, battery and some buttons on a convenient PCB. And it has its own C SDK, with loads of demo games to take inspiration from! I still had several weeks before the game jam starts, enough time to brush off my C knowledge and also learn how to work with microcontrollers, right?
It comes as a kit that needs to be soldered, but conveniently, it is sold by the wonderful Pajenicko.cz e-shop, which also sells everything you need for soldering. I ordered the kit, a soldering iron, solder and some accessories.
Putting the Picopad together was easier than I expected, although I was terrified the whole time I was soldering it. Surprisingly, it worked the first time I turned it on—display, buttons, sound, everything.
After playing around with the built-in demo games I set out implement my demo game on the Picopad. After studying the Picopad SDK I decided to official Pico SDK instead. The main reason is that the build system for Picopad SDK was (at the time) designed for Windows systems, as a bunch of Makefiles and cmd batch files. The official Pico SDK uses CMake and works very well on both Linux and Windows.
Combined with the fact that the Picopad SDK does not have many users (yet) and the documentation is not very comprehensive, I was afraid of running into issues that could slow us down during the game jam.
Plus, it would be good exercise to find out how the SDK implements things such as graphics and audio. I took inspiration from the SDK and improved some parts, but that’s material for next posts.
Looking back, I think Picopad was the right choice for the project. Raspberry Pi Pico was powerful enough to drive the display at around 30 FPS, although with some caveats. We were able to use the Picopad PCB and design our own case for it, that matched the game aesthetic.
It has everything you might need for a handheld console game, and it can be easily extended. There is a SD card reader if you need more storage, external connector for custom hardware, and there is a version that uses Raspberry Pico W with Bluetooth and Wi-Fi chips.