Felipe Nonato

Building a Custom GBA Handheld with Raspberry Pi Zero 2W

2026-05-13T00:00:00+09:00

Custom GBA Handheld

2026-05-13

Status: In progress — display, audio, and input working. Final assembly underway.

I really like handheld stuff! Me and my wife are always in the same ambient doing our stuff. Be it work or our hobbies. You have no idea how many monsters were hunted in monster hunter rise in my OLED switch in its handheld mode! Althought I really like my switch and still want to buy myself a steamdeck, I think they're both too big to carry around. Another thing is that I wanted a device that not only could fit in my pocket but also could run my and other pico8 games that I like! I never had a Game Boy Advance, so I thought, hey, why not?! I do like electronics, and buying one ready felt less interesting than building one. I could unite both of my interests: GameDev and Electronics!

The challenge: fitting a raspberry pi, a 2.8inch display, GPIO input handling, an audio amplifier inside a shell designed for 2001 hardware without the original PCB, without a kit, just components wired together! Oh yes, there's also the battery! This is my progress so far:

System

Component	Part
Computer	Raspberry Pi Zero 2 W
OS	RetroPie
Display (Driver)	ST7789 2.8" SPI TFT (fbcp-ili9341)
Input	GPIOnext (GPIO buttons)
Audio	PAM8302A amplifier
Shell	Original GBA case (modified)
Battery	2000mAh Li-Po
Battery Charger	Mini 18650 TP4056 Lithium Battery Charger
DC-DC Converter	Boost Power Supply Module (winova)

Display

The first display I tried was an ILI9341. It worked! I got RetroPie running on it and was able to play Celeste on PICO-8. But the screen cracked while I was trying to adapt it do the GBA shell since it didn't fit cleanly inside even with physical modifications to the case. I replaced it with a ST7789 2.8" TFT, which fit the shell window much better.

Both displays use the same driver: fbcp-ili9341. Setting it up requires compiling from source with the correct GPIO pin mappings for the specific wiring. The BCM pin numbering used by the driver doesn't match the physical pin numbers on the header, which caused some initial confusion. One issue I hit: after compilation the display was showing inverted colors. Looking at the driver's documentation, this is a known quirk for certain panels and is handled by a compile flag. My final cmake command was:

cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DSPI_BUS_CLOCK_DIVISOR=8 -DDISPLAY_INVERT_COLORS=ON -DSTATISTICS=0 ..

Another thing I had to deal is due to how the display fit inside the shell I had to invert its image inside raspberry's boot config. This line inside the archive solved it:

display_rotate=2

Input

Input is handled via GPIOnext, which maps GPIO pins to gamepad buttons and exposes them as a standard input device to RetroPie. The GBA shell uses original-style button PCBs: D-pad on the left, A/B on the right, L/R on top which I wired directly to the GPIO header through a breadboard during prototyping. I also tested a Pro Controller connected via bluetooth. It worked without additional configuration, just a bit of try and error to pair. GPIOnext handles the native GPIO buttons for the final build.

Audio

Audio is handled by a PAM8302A amplifier, which takes the Pi's PWM audio output and drives a small speaker (The original GBA one, it's not THAT good). On the Raspberry Pi Zero 2W, audio output through GPIO requires enabling the pwm and setting the right pin! The PAM8302A is compact enough to fit inside the GBA shell alongside the other components.

Assembly

The GBA shell required physical modification to fit the hardware pieces. The original PCB mount points and battery compartment don't accommodate the Pi Zero 2W or the display PCB, so I removed material from the inside of the shell with hand tools to make room. The display window also needed adjustment to align with the ST7789 panel. The button PCBs from a GBA replacement kit connect to the GPIO header. Left side handles the D-pad, right side handles A,B, Start and Select. L and R are wired as separate tactile switches.

What is running?

With display, input, and audio working, the system runs:

RetroPie — the main OS and emulation frontend
PICO-8 — integrated as a RetroPie system; plays all PICO-8 cartridges
Steam Link — tested and working via command line; frontend integration still in progress

What's next?

Re-test sound system before soldering cabes
Final soldering — moving everything from breadboard to permanent connections
Fitting the Pi, amplifier, and speaker inside the shell with the battery
Power management: The power button must schedules the pi to turn off and not just disconnect the battery as this might corrupt the SD card with the OS.
- Two button solution: One to turn the pi off and a hidden one that disconnects the pi
Steam Link frontend integration so it launches from the RetroPie menu

Blog Post Title #1

2025-09-06T00:00:00+09:00

Blog Post Title #1

2025-09-06

Bloop!Jump is my first attempt into gamedev! It is a simple platformer where the goal is simple: Get to the top! I tried to make it a little bit difficult so...sorry if it was too much. (Or sorry if it was not at all lol!) But I decided to blog this game as a story for future self! And for you too, reader.

There are a ton, seriously, absolutely A TON of tutorials on how to make games and how to use engines out there. I actually bought a course in Udemy once and did some games in unity during the course, but after I finished, I felt like I learned absolutely nothing. I would come back to unity and everything would look alien to me! That made me abandon it for a while. The pandemic didn't help and some stuff happening at home made me forget about it. To be fair...following tutorials step by step is a thing that never worked for me, at least not when I wanted to learn something that I wanted to apply by myself later.

Fast forward, I'm in Japan doing a Master's in CS (something that I always wanted, maybe I can talk about this in another post!) and specially motivated to do stuff I always wanted to do! Like learn how to gamedev, how to write interesting stories for games, study in-depth graph theory...and so I started to play a bit with Pico8. My adviser told me about it. It looked like a fun engine to play and learn. It wasn't that difficult and I saw lots of fun stuff made with it. So I practiced a bit in Tiny Code Christmas. It was pretty fun! :D

Fast forward more months! I was going through some rough times with anxiety on having to write an phD proposal and doing my master's research. I was checking mastodon during a procrastination session and noticed LOWRESJAM) Perfect! It was, honestly, the thing that put my mind at ease a little bit! I was doing my stuff and working on the game alternatively. It was some real good cleansing thing to me. And...I had fun!

I totally had 193956398493 ideas to put in this game. I would talk to my wife about the puzzles and story and meanings I wanted to put into the game... only then to remind myself that I should just get something ready. Something done. It was my first game after all. It didn't need to perfect. Hell! It didn't need to be good! It just needed to be.

All that considered, I did it! I got a lot of feedback from people in the jam and lots of evaluations! I was just happy that people took their time to play this simple thingy. I got top #101 overall. My first though was... "damn! so close to top100! " But then I just laughed it out. I had fun doing it, fixing it and actually playing it. I still have plans to update it with one or more levels and add some stuff I got feedback on. You can check the game on my itch: Bloop!Jump!

Welp! Too long for an intro post, but I kinda wanted to separate this one from the "devlog-like" thing I wanted to do later. So yea, next post I intent to talk about the ideas, the challenges the game presented to me and how I solved them!

See you in the next one! :D (Yes, the title was intentional!)

Mario Maker 2 and Open-Endedness

2025-04-15T00:00:00+09:00

Mario Maker 2 and Open-Endedness

2025-04-15

I recently (finally!) bought my copy of Mario Maker 2 (MM2)! I've been having fun playing "One-Screen-Puzzle" levels and am still taking my time with the infamous troll levels. I'm an avid watcher of CarlSagan42, a person who plays lots of very difficult Mario levels, Celeste levels, and...MM2 troll levels! Since I'm really fond of open-endedness evolution research, I've been thinking a lot about drawing a connection between this concept and the world of games. Watching so many of Carl's videos playing troll levels got me really impressed with what you can MAKE in MM2! It's as if...it's open-ended!

It's difficult for me to give a definition of open-endedness. You could read a lot of papers and each would give its own definition of it. It's hard to pin down a single, exact definition. But for the sake of simplicity, let's call open-endedness the capacity that a system has to constantly produce noticeable and relevant novelty. Noticeable and relevant being extremely relative here. Relative because it's really difficult to determine when something that happened, say in a simulation, is unique...to us. For the computer, it's probably pretty easy: Have you ever heard about the 10,000 Bowls of Oatmeal problem? We could generate millions of levels, but if they all feel the same to the player... is there anything new in them?

"So your algorithm may generate 18,446,744,073,709,551,616 planets. They may each be subtly different, but as they player is exploring them rapidly, will they be perceived as different? I like to call this problem the 10,000 Bowls of Oatmeal problem. I can easily generate 10,000 bowls of plain oatmeal, with each oat being in a different position and different orientation, and mathematically speaking they will all be completely unique. But the user will likely just see a lot of oatmeal. Perceptual uniqueness is the real metric, and it’s darn tough."

Dr.Kate Compton talks about procedural content generation and the 10.000 oatmeal problem (and other things) here.

Games are a good platform to study open-endedness because they often offer us a limited system to act upon - and a system that we already understand. Especially when we talking about an existing game. In a sense, it would be easier for us to spot different bowls of oatmeal when looking at bowls of various Mario levels, than when we look at a simulation that we just built ourselves. A game like Mario has its system done and closed, with strict rules to what is possible. That is: its levels, mechanics, possible actions Mario can take, consequences of these actions, and even a goal (I'm thinking of a platformers here. Yes. Mario.). But we don't have to limit ourselves to these "closed games". We also have Dwarf Fortress and Caves of QUD with infinite possibilities of outcomes, which represent what I'm talking about even more! And these don't even have a flag you need to get in the end! But I want to focus on how Mario could be used to study open-endedness.

So, when looking at a Mario level, what actually makes it different from another one? We could talk about the art of it. A block is blue instead of red. They're in the same place, serve the same function, but have a different skin. Maybe the change was big enough that could give someone a whole different "feeling" to the level. We could also say the same about music! But what about gameplay? Oh, the potential is infinite! Although one could argue that there are limited tools in the game to be used, and the game is simple and closed (Wait, I heard this somewhere). How we use the tools and put them to work together is what makes MM2 a great case of study for open-endedness. Like having emergent behavior in a system with simple rules.

I think that people do this - and they do this a ton in the Mario Maker community! I mean, they use the same oat but somehow create different oatmeal bowls. Give the tools to the player so they can build their own levels gave rise to crazy cool creations that maybe one would find impossible. Like I wrote in the beginning, I really like [One-Screen-Puzzle] levels. They use the existing tools of the game to create these puzzles that to solve, you need to figure out in which order (and sometimes when exactly) you should use a tool and/or take advantage of their interaction so you can reach the final goal. And yes. The tools are numerous, but even so, are limited (you don't need to use all of them either). And their interactions are already described by the game system. Yet, I played a ton of different levels that although some of them used the same gimmick, they felt totally different for me. Those bowls were absolutely different.

The code of this one is W1Y-1LC-XLG. I played all puzzle level from this creator! Good ones! Puzzle levels can be bit frustrating sometimes. When you get the order wrong you have to start the level again. Good thing it's small. I'll show you something worse in a second.

The idea to explore this existing limitation as a motor to understand how variability is built in a system (I know I read a paper on this! I'll look for it and update!) is pretty cool too. Like I said in another draft of mine , we could have a huge number of different rules and possibilities for a Mario. But is the outcome of this relevant at all to us? Or, how long it'd take for a relevant behavior to appear? (considering we're evolving them) When you look into a Mario simple platformers, you have limitations to what the player can do. This pushes the player to think: "How can I solve this problem with the tools I have?". Or to us as we watch evolution like: "How are the entities going to solve this problem with the tools I gave?" The goal could be as "simple" as surviving! Coincidentally, surviving is the main goal of the next type of level we're going to talk about.

Now in MM2 there's a subcommunity of trolls. But not those kind of troll you thought of, these are good ones (Actually, that also depends on your point of view...). The point is, the level makers in this community are often doing their best to trick you into thinking the correct way is jumping to the other side, only for you to the discover that there's a hidden block (they call it kaizo block) right in your jump trajectory. Now Mario hit that block, lost all his momentum and fell into the abyss.

Classic.

There are tons of similar techniques (or should I say traps) documented by the community. (This GIF is from here) We could see all these as patterns that used the system to output an outcome, in this case, kill the player. But there's a bit more to it that turns this kind of thing a bit more difficult to replicate and amazing to think about. A lot of patterns are born from the creator predicting the path the player is going to take, or creating a perfect "bait" for the player, only to reveal the pit (or any other way Mario could be killed. Sorry Mario...). In order to create these baits, or these unexpected behaviors from the game, the creators go out of their way to try things out so they discover how to take advantage of the game system to create these "monstrosities". They evolve these patterns where the fitness is how this pattern fits to the idea the maker is trying to convey at said time. Tick the player? Surprise the player? Make the player rush? Just be cruel because they can? It varies. We'd let the computer chose and see what we get.

Sometimes bugs are used in these levels - and Nintendo is pretty quick in putting down the level that have them - but when I say "unexpected" I want to say that sometimes the player dies because something behaves differently due to some specific interaction: A mechanism off-screen turned a conveyor belt on and Mario was pushed to the pit again. How would you expect that?! Back to the beginning! The mechanisms that are often off-screen are the grinding the gears of these Fortrolls (Fortress+Trolls. I am not sorry.). And these are what the endless interactions and ways to kill Mario that we get. But ok, we don't need to be so mordbid, these mechanisms are also used to create cool challenging levels or simply showcases of the mechanism itself.

The question stays: How can we measure the novelty of these games simulations? How the interaction between entities influence the system outcome? How these influence the entities behavior? How these describe how much open-ended this system really is? These questions could totally be done for an Alife simulation. Games are also a great place to study computational creativity, and how each player's perception affects what is perceived as new, or not. You often only play these troll levels once. The second time, you know everything needed to be done in order to finish the level, so nothing might sound new to you.

Mario Maker 2 is going to be 6 years old later this year (2025) and we still get to play lots of different levels and actually experience different sensations and feelings with them. Troll levels are still showing how different interactions can be used to deliver a good gameplay experience (ok, this is totally debatable). But point is, this game is basically an open-ended canvas for diabolic (and angelic ones too) players to explore its systems and come up with different contraptions born out of the interactions of smaller parts. It's an open-ended system full of emergent behavior and creativity! Its Alife with plumbers and piranha plants.

Mito-san: The mitochondrion

2025-03-26T00:00:00+09:00

Mito-san: The mitochondrion

2025-03-26

This is pretty cool. Every little square that forms that square is moving on its own. Right now, they are moving randomly and I did put them in that starting position. I wanted to see what I'm looking for, or at least one of the things that I'm looking for.

It is pretty cool! The whole idea of putting an energy source that has collision and can be moved around was to see if this sort of organization can be built. It's not really the same thing, but it reminds me of the mitochondrion and how it sources the organism with energy (sorry, not a biologist I'm probably simplifying things a ton). Not only that, but how one of the theories of their origin is that mito-san (English is difficult, and I'm being respectful!) was a single cell organism that developed a endosymbiotic relationship with another cell. Mito-san produces something good for the big one, and they live happily ever after.

So there's a stretch. Mito-san in the video is a floppy disk that gathers energy and gives it to the squares that enter in its area. I didn't have plants for evolving Mito-san, but who knows? I have to finish things with square-guys first.

Also, if you read the last blog post you may have noticed that food aren't particles anymore. I did this way because I was a bit afraid of dealing with a lot of collisions. But it's something that I may come back later.

Right now, I want to make the squares share their energy when they are attached: Everybody dies if energy is down! Then, implement self-replication. Then build a simple probability table that will determine to which direction they move. I'm heavily tending to implement a delay that will make them keep a chosen direction for some steps, but not sure yet. Still thinking about the last post too.

Not related, but I also have being thinking on making a troll-game in pico8 just like the troll levels I often see in MarioMaker2... I know, random right? I'd let you know my progress. Until next time!

Rules rules?

2025-03-21T00:00:00+09:00

Rules rules?

2025-03-21

Post by @djuniou@sigmoid.social

View on Mastodon

Sorry for the flashbang. I tried putting a spoiler thing so that the video would only appear when you clicked on it, but after a while I just wanted to play Monster Hunter Rise again. I promise next time I'll trie to put the video itself. But hey. Say hi in fedi!

Yes! The floppy disks are spiting data. That's what these little robots eat. They need it to stay alive! Every time we have less than five bots on the screen, one of the spawners spawns a new one.

These bots have eight "tact sensors" around them. These are basically collision areas. They use these to decide which direction they go. Right now they are cowards! That is, they go in the opposite direction of where they were touched! Even food scares them.

I have been thinking on what rules I should create to control these little guys. The goal is to get relevant variability in their behavior. But what I mean by that? Well. I could put a ton of sensors and rules using their input, but...at some point wouldn't the output behavior look a lot like random? Or even if they had a pattern to it, would we be able to extract meaningful information when we consider the inputs? Or even if they eventually create something interpretable...would it take too long? Or if the rules are too simple. Wouldn't they all look the same?

I'm doing this thinking on evolving something like multicellularity. I'll add a way for these guys to be able to attach themselves. Maybe we can see specialization arise: Some bots focused on moving left, others on moving up to create unique movement patterns...

Is there a defined trade-off to where we have "good" or "relevant" emergent behavior? Maybe I should be clearer with what is "good" or "relevant". I think for now, behavior that allowed a long life should be enough.

Oh well. Should think more about this. I'll be updating the rules with some simpler stuff and also change the food a bit. See you next time!

Week 1 - Procrastination

2024-01-15T00:00:00+09:00

Week 1 - Procrastination

2024-01-15

" I should go back to writing my thesis. " 'Should' being a key word here. Feeling the comfortable heated air coming from laboratory's central heater made starting anything serious almost impossible. It was cold outside and getting cozy in such times made my body and mind adjust to...being cozy. My normal course of action would be to grab the switch and spend the next hours playing it. However, even with these huge forces pushing against me, I tried to focus.

" Ok. Preparing the environment. " First, put the switch away from the table. " If I need to stand up I won't play it. " Second, open youtube and look for a gray noise sound. Risky move. A lot of distractions came up on the screen but one of them was conveniently placed. " ADHD relief music for studying...I'll try this today. " Convenient. Third, open the note-taking app with all the bibliography PDFs. I scratch my head reading the titles, looking for something that I really don't know what it is until my eyes glance at the folders in the app. " Scripts... " I made that folder after I decided on one of this year's resolutions: Write one short story every week. I unconsciously click to open a new note in said folder. " Title... "

Update from 24-March-2025: Nope. No stories were written every week. F