Building my own Sega Genesis Mini

It’s been several years since I posted Building a own custom retro console running RetroPie. That project was a lot of fun at the time, but I haven’t built another custom system since.

I just wanna play Sega Genesis

My original intent was to build something that focused on playing Sega Genesis games. The Genesis remains my favorite childhood console, and my dream was to build an emulation machine that looked like a Sega Genesis externally, but loaded with the entire library of games.

However the Raspberry Pi was still in its infancy back then, and I couldn’t bring myself to cannibalize an actual Genesis for its shell. Instead I settled on building my custom console with a generic case and (Xbox 360) controllers featuring a similar six-button layout. But that build just didn’t hold my interest for very long and I ended up digging out my original Sega Genesis, picking up one of Krikzz’s EverDrive flashcarts, and never looking back.

Fast forward to 2019, and Sega released the Sega Genesis Mini, which I happily picked up. It was my favorite of the official mini consoles, and it earned its spot on my desk at work. Despite the quick availability of hacks to add more games (and systems), I appreciated having such a tight, curated experience, even if I didn’t agree with every game choice.

Home office plans

Now it’s 2022 and that mini has mostly sat unused while I worked from home. As our offices have reopened, I’ve decided to split my time and to finally build myself a proper home office. And while I’ve kept a spot on my desk earmarked for a small “retro hardware setup”, I also have nice large TV and couch just begging for its own game system.

My first thought was to bring the Genesis Mini home, but it’s nice to have a self-contained setup at work for the days I go in. My second thought was to just pick up a Xbox Series S, giving me access to my modern digital library instead.

Then the Genesis Mini 2 was announced, so that became a contender. I looked at the game list, but unfortunately it doesn’t really excite me. However, in the process of watching various YouTubers’ opinions on the system, I stumbled upon some other projects that I’d completely missed before.

Blast 16 and the RetroFlag MEGAPi case

Blast 16 is a Raspberry Pi image designed to help you build your own Genesis mini console. Rather than just another RetroArch and Emulation Station setup, designed to host the full library of every retro console ever, Blast 16 is very Sega-oriented, and only supports the Genesis, Sega CD, 32X, Master System, and Game Gear. More than that, the beautiful, box-art-focused UI can’t handle more than a couple hundred entries without slowing down. So it’s meant to make you curate your experience, and only put on games you really want to play.

On top of that, and the real icing on the cake for me, is it’s easy to pair the Blast 16 software with the RetroFlag MEGAPi Case, which looks just like an actual Model 1 Sega Genesis. Seeing the two together in this video, my original dream was rekindled, and building my own Genesis Mini jumped to the top of my to-do list.

Getting the parts

My first concern was the age of these projects – they’d all come to market years ago, in response to the official Genesis Mini release. And if there’s one problem with these kinds of niche retro products, is that they’re often impossible to get if you didn’t buy them on day one.

Thankfully the Blast 16 website was still up and running, and I was happy to find that the MEGAPi case is still available on Amazon. I put in my order, and it’s quite lovely:

Next I gathered up two 8Bitdo M30 Bluetooth controllers (which I already had). The only thing missing was a Raspberry Pi.

I almost had a heart-attack seeing my (lack of) options. The MEGAPi case supports the Raspberry Pi 2B, 3B, or 3B+, but almost no one carries them anymore. I’d have to shell out $120 just for the low-end 2B, which is three times its original retail price of $40, and doesn’t even have Bluetooth.

Thankfully, past me had me covered. Checking my Amazon order history, I saw I’d picked up a 3B back in 2017 (who knows for what), and sure enough I there it was in my parts bin, still in the box. Bingo!

Building the hardware

Installing the Raspberry Pi into the MEGAPi case was simple and straight-forward – just plug in the two USB plugs, the single plug for the GPIO, and screw the board down:

Finally I flipped on the switch labeled “Smart Shutdown” (more on that later), closed the case and screwed it shut:

Initial software setup

With the hardware done, the next part was setting up a Micro SD card with Blast 16. I used a 16 GB card (no reason to waste anything bigger), and following the excellent instructions on the Blast 16 website, got the card imaged.

After that, I installed the card through the little lift door on the side of the MEGAPi:

After running the device once for the initial setup, and pairing the M30 controllers, it was time to install some games!

Installing games

Doing so was super easy. All you have to do is copy your ROMs (with matching box-art) onto a USB flash drive in a particular folder structure. Then if you boot the system with flash drive plugged in, Blast 16 will automatically install them onto the system. Note: if you want to remove games later, you can do so from within the Blast 16 menus.

I installed a little over a hundred games, mostly Genesis favorites, but also select few 32X, Sega CD, and Master System titles. It may not be the forever list, but it’s a great start.

Installing the safe shutdown scripts

One of the biggest gotchas with building a Pi-based anything is that the board doesn’t have a power switch. Out of the box, you’re expected to plug in the power to turn it on, and make sure to safely shutdown from within the running software to turn it off. If you don’t, and just pull the power, you risk corrupting the SD card and breaking your system.

Thankfully, the MEGAPi case wires its power switch and reset button to the Pi’s GIPO pins, and RetroFlag provides scripts you can install on your system to trigger a safe shutdown or restart when they’re used.

Update: Whoops! Apparently the base Blast 16 image already includes a working safe shutdown script that I completely missed. My version is unnecessary and installing it may give you some random error messages.

Unfortunately, RetroFlag hasn’t touched their code in a while, so the scripts have bugs and the install instructions didn’t work for me with Blast 16. I ended up forking their code and fixing the scripts myself for the Blast 16 / MEGAPi combo. I’ve written up revised instructions here, but long story short, if you want to copy my work, once you’ve gotten your Pi’s network configured, you just need to run the following from a terminal:

wget --no-check-certificate -O - "" | sudo bash

After it reboots the power switch and reset button will work as expected.

Final thoughts

I really love how well this project turned out. It looks so nice under my TV:

The UI is beautiful, and while I normally like the clean, pixel-perfect look when emulating, I’ve found I really like simulating an old CRT on this setup by setting the scaling to 4:3, turning on scan lines, and enabling the NTSC composite filter. Note: that last option meant going into RetroArch’s menus, so while that isn’t strictly necessary, I like that it’s still available.

In fact, having access to RetroArch’s menus meant I was also able to enable RetroAchievements, which was listed in Blast 16’s FAQ as unsupported. It works great, and I find adds a whole new level of fun when playing these old games.

Overall I’m thrilled to finally fulfill this old dream of mine, and while it doesn’t have literally every single game, I expect to spend plenty of hours playing my custom Sega Genesis Mini.


State of Mzinga, March 2021

Mzinga is my collection of open-source software to play the board game Hive, and I last posted about it back in November 2018.

A lot has happened since then, so this feels almost like a re-launch than anything. Essentially, Mzinga development stalled at the end of 2019. I made a variety of internal performance improvements, but the biggest changes were polishing the UI of the Viewer, including adding the ability to save and review games later, in a new review mode.

Nothing happened for Mzinga in 2020, though I did spend some time getting acquainted with .Net Core and Avalonia, an exciting cross-platform UI framework similar to WPF.

I did some smaller projects with this “new” way to write C#, and when Avalonia released their big 0.10.0 update in December 2020, I decided it was time to try porting one of my bigger apps to this new platform.

So in January of this year I ported Mzinga to .NET 5, and rewrote the Viewer in Avalonia instead of WPF. The end result has been more than worth the effort.

I got to keep 99% of my existing code, and with a just couple weekends of work, starting with Mzinga v0.10.0, the entire project is cross-platform, with releases on Windows, MacOS, and Linux.

Here’s the announcement on BoardGameGeek: Mzinga, open-source Hive, now cross-platform (Windows, MacOS, Linux)

Having the code cross-platform really opens up the opportunity for getting other developers working on their own AIs. By having the Viewer available on Mac and Linux, more developers are willing to invest in writing their own UHP engines and Hive AIs, which was the whole point of Mzinga in the first place.

I’m in conversations with several such developers- one even found a bug in Mzinga that’s been there for years! They all appreciate the level of documentation and tools I’ve provided to help give them a place to get started.

To that end, I’ve also taken some stabs at building some more engines myself. I started a UHP Sample Code repo, with simple sample engines to get people started. They only implement the base game (no expansions), have no AI, and are not optimized, but they meet the minimum requirements for an engine, and therefore are yet another starting point for developers. I’ve got versions in both C++ and C#, and I’ll probably also create versions in Python and JavaScript too.

For Mzinga itself, it’s a big, complicated codebase, and I don’t see any “easy wins” for making it faster or the AI stronger.

So on top of everything else, I’ve also started MzingaCpp, which is a brand new engine written completely in C++. Here I’m taking all that I’ve learned and focusing on making the fastest possible engine, with hopefully the strongest AI. Right now it’s got the base game and expansions up and running, and while it doesn’t have any AI yet, its move generator is already 1.5x -2x the speed of Mzinga, which is a great start.

That’s all for now! I’ve you’re interested in playing a game of Hive on your computer, give Mzinga a try. If you’re interested in developing your own Hive AI, drop me a line!



New Year, New Game Boy

One of my many hobbies is collecting and playing retro video games, especially portable / handheld systems, and especially those from Nintendo. I try to get one of every model where I can, however my rule is to only ever buy systems that I actually intend to play.

A couple years ago I bought an original Game Boy that had been modded with a backlit screen. I didn’t have an original Game Boy in my collection, and the mod itself, while inexpensive, involved a very delicate peeling apart of the original LCD and replacing specific layers – something I did not feel up to doing. So I bought a finished one off eBay.

But at the end of the day, it was just, okay.

What I hadn’t realized was that the backlight changed the color palette from pea-soup green to a gradient of blues over white. It worked, but it took a lot of the charm out of the system. Also, while the modder had replaced the original lens with a nice, scratch-resistant glass one, it didn’t sit flush with the system. The edge stuck up sloppily along one side, and it would catch my finger when I wiped it off.

I decided to accept it for what it was, but it did spend more time on the shelf than my other handhelds. When I did take it down to play, I started noticing weird splotches under the lens. I assumed it was water condensation getting inside, but it turned out to be pressure marks from the unevenly applied lens pressing against the LCD underneath. I didn’t know how to fix it, so it spent more and more time on the shelf.

Then, finally, when I took it out this past winter, it wouldn’t even turn on. The power LED lit up, but not the screen, and there was no sound. It was, for all intents and purposes, dead.

I started to think maybe it was going to just be an unfortunate shelf piece – with so many other smaller and lighter models to choose from, I didn’t really need an original to play. But the modding scene today is further along than it was a couple years ago, and the latest innovation has been a slew of drop-in replacement IPS LCDs.

I’m also a lot more proficient at repairing and restoring vintage electronics than I was a couple years ago. So I decided to take the plunge and try and rescue my poor dead Game Boy. I hit up Hand Held Legend and ordered a fancy new IPS display kit.

Since the system wouldn’t turn on I also picked up a set of replacement capacitors, and as some people complained that the IPS screen introduces some noise into the audio output, I also picked up the proscribed audio amp.

With all the parts in hand, the first step was to open the system up and remove the old backlight mod.

As you can see, the system separates into two parts – the front board with the LCD and buttons, and the back board with CPU and batteries. The new kit comes with an entirely new front board, so I set the old one aside for now and focused on the back board.

At the top was a “bivert chip” that needed to be removed. See, just adding a backlight to the original LCD produces a very washed out image – but modders figured out that if you rotated the polarizer (one of the LCD layers I mentioned before) it produced better contrast, but inverted the image. So they created a bivert chip to invert the image to start with – the result being the correct image with good contrast.

The chip was pretty easy to remove, the hard part was where a few pins from the LCD ribbon cable connector had been bent up off the board to connect to the chip. It was very finicky work to bend the pins back down and resolder them without touching the other pins.

After the chip was out I removed a set of patch wires connecting to the headphone jack. I vaguely remember the original listing for the system saying it had some kind of audio mod, but I couldn’t for the life of me figure out what they’d actually done, other than re-route some wires.

In fact, I was annoyed at the quality of the work – the soldering was weak and held on with globs of hot glue, and they’d straight up snipped some of the original wires.

Thankfully I asked around online, and a modder was kind enough to explain that it was called the “Pro Sound mod” where the audio to the headphone jack was re-routed to avoid the noise from adding the backlight. They also explained that the “IPS causes noise” issue was overblown, and that I probably should try out the existing mod before wasting time installing the new audio amp.

So I took their advice and reapplied the Pro Sound mod to my own soldering standards.

Now that that was done, I set about putting together the new IPS kit. As per their instructions, I connected everything together without permanently mounting it, and fired it up to make sure it hadn’t been damaged during shipping.

It didn’t work.

It gave me the same problem as before – power LED lit up, but no screen, no sound. Just to be sure, I re-attached the old front board, with the same results.

So, assuming the new screen and front board I’d just bought were good, then something was wrong in the other half. Assuming it was a leaked capacitor, and thankful I’d bought replacements, I took out the back board to check.

But it looked absolutely fine. I gave it a good cleaning with some isopropyl alcohol, but still no dice. So it was time for the multimeter. I started poking around the board and found no obvious shorts, and looking at some schematics online, found plenty of points where there should have been power, but registered nothing.

That’s when I learned that the little board in the bottom left wasn’t part of the audio circuitry, but the main power board. Taking a closer look, I could see where some previous battery acid leakage had escaped the battery compartment, and gotten all over the power board.

I cleaned it off and started testing, and while it looked pretty bad, the only real damage was to the trace from the input voltage (the batteries or AC adapter) to the rest of the circuit. So I patched a wire across the two pins and crossed my fingers.

Success! The original front board lit up just fine (though inverted, since the bivert chip was gone). Now that power board may not last forever, and I may need to replace it entirely in the future, but after a couple hours of cleaning and troubleshooting I was more than ready to finish this project.

The penultimate steps were to install the new front board in the front shell. This required making some minor alterations to the inside of the shell, including trimming some posts that would be in the way of the new screen, which is actually larger than what appears through the viewport.

This was also when I saw why the previous lens didn’t sit properly – the plastic lip that it attaches to was covered in uneven globs of glue. The replacement lens I’d bought already came with its own pre-applied double-sided tape, so I just took the time to sand away all of the old glue and even out the surface.

After all that prep, it was finally time to install the new board and permanently affix everything into place. The new screen is mostly held in proper alignment by a bracket, but it’s also taped to the shell forming a seal to keep out dust.

Ah, dust. With everything screwed together, the last thing to do was to install the new glass lens, which meant getting the LCD as clean as possible. After everything else, this was the most nerve-racking part of the install. I knew once the new lens was on, any bit of dust, any smudge on the LCD, would be out of reach.

I spent a long time painstakingly wiping away specks with a microfiber cloth, using cans of compressed air, and reevaluating the screen at different angles. When I was finally ready, I quickly peeled the seal off the new glass lens and applied it straight away.

Victory! I’d done it! I’d saved my poor dead Game Boy. The buzzing concerns were unwarranted – only on the highest volumes to the speakers buzz slightly, and the headphones don’t buzz at all. Everything worked perfectly, and there’s no way this is going back on my shelf any time soon.

Anyway, I hope you enjoyed this little project,


State of Mzinga, November 2018

Mzinga is my open-source AI for the board game, Hive, and I last posted about it back in February 2018.

So what’s changed in the last nine months?

From an end user standpoint, the high-level highlights are:

  • The official expansion pieces (Mosquito, Ladybug, Pillbug) are now fully supported
  • Lots of Viewer updates, including:
    • Graphical bug pieces, rather than just the text names
    • Sound effects
    • Progress bars while the AI is thinking
    • Improved layout to maximize the playing area
    • Ability to “lift” pieces that are stacked to see underneath them
    • “BoardSpace” notation (the defacto way to record Hive games)
  • The Viewer now includes an “Internal” implementation of the Mzinga Engine, in case no engine executable is available
  • Engines can now expose their options to be set by the Viewer
  • There is now a “portable” release, ie. a simple zip file for users who can’t/won’t install
  • The “updater” now only checks for updates but doesn’t offer to download and install them (security issue)

From an engine / AI standpoint, the highlights are:

  • Switched to a Principal Variation Search, ie., assume that the best move from a previous, shallow search, is the best place to when starting a deeper search
  • Pre-sort moves to try moves with the most potential to upset the game first (ie moves that affect how surrounded the queens are)
  • Switched to tapered evaluation, ie. how you should play near the start of the game can be different than how you should play near the end of the game, so evaluate the board with different metric weights as the game progresses
  • Different metrics for different game types: one general set of metric weights for all game types (all the combinations of with/without expansions pieces) just isn’t effective, so the AI now has different specialized metric weights for each game type
  • Better usage of multi-threaded searches
  • Various perf improvements

I think the biggest upgrades for users are the inclusion of the expansion pieces, the much friendlier Viewer, and the fact that it’s now portable. Technically all you need to play Hive is the single Mzinga.Viewer.exe from the portable release. You can throw it on a flash drive and play Hive on any Windows (Vista or higher) computer.

On the research front, the biggest discovery for me was of the TreeStrap self-training algorithm. I won’t go into details here, (I talk about it a little in this BoardGameGeek post), but suffice it to say that it provided a more targeted way to improve Mzinga’s AI. Rather than rely solely on my evolution-based model (which, due to the limitations of my population sizes and my “rough” implementation of genetics, produced an often homogeneous pool of AIs) TreeStrap let me force an individual AI to self-train by playing games against itself and intelligently updating its own metric weights.

It was through using TreeStrap that I created a decent AI for playing games with both the Mosquito and Ladybug expansion pieces. However, it was only in testing that AI against my existing pool of evolved AIs that I learned that it only excelled in that game type. In fact that AI did horribly in other game types, which lead me to believe that it might not be possible to create one set of weights that works in all game types. This propelled me to finally expand Mzinga to support specialized weights for each game type.

But now I have a pretty robust “pipeline” for improving Mzinga’s AI. First, I have eight special AIs, each self-training against for one particular game type. Then I push those AIs into my pool of other AIs and have them all fight each other (no more evolution, just the fighting) to evaluate their strength. Then I take the top AIs for each game type (usually, but not always, the self-trained AIs) and inject their weights into Mzinga’s Engine.

In theory, if I keep repeating that loop then Mzinga’s AI should get stronger and stronger. Also I can keep “snapshot” the AI every time I release a new version and keep it in the AI pool, so I can track that the newer AIs are objectively stronger than the older ones.

As this self-improvement loop is already starting to pan out, I’ve begun spreading the load across multiple computers. I can now have one set of computers that continuously run the self-training algorithm on the special AIs and push the results to OneDrive, while another computer regularly grabs those AIs and tests them in combat.



Introducing the RomSort utility


About a year ago I wrote a little command-line tool for sorting ROM files into alphabetical sub-directories. The main feature was it could intelligently combine the smaller sub-directories, which is useful when you’re browsing on low-resolution screens. However after I got the code working I never got around to sharing it.

So I took some time to re-package the code into a small .NET 2.0 WinForms app. It is pretty straightforward to use, and even gives you a live preview of what the end result will be before you use it. Note that filename collisions will be marked in red and it won’t let you perform the sort if there are any.

Source and binaries (under releases) @ RomSort on GitHub.