The Latest

This is a handheld game system that looks somewhat like a looks like a Game Boy Advance SP, though unlike the RG35xx SP it doesn’t copy the hinge design or finishes. More of an homage than an imitation. Unlike the RG35xx SP, it’s the same size as a GBA SP, and although the size difference is small on paper, it makes a big difference in feel.

The buttons are much nicer than the Anbernic device. They have a similar shallow travel and clicky operation, but a much lighter feel. This is a lot closer to the original GBA, and I wish the RG35xx SP had these buttons. The machine is less powerful though, and you can really tell.

Stock OS

So far there isn’t much for custom firmware (CFW), though maybe that’s coming over time. For now there’s the stock OS and MinUI as working options.

Emulator Setup

Emulators on the stock OS are configured by creating a folder in the Emu folder in the root of the SD card, writing a small configuration file in JSON that names the system, links to images for the UI, and calls a launch script. It’s probably easiest to copy an existing emulator configuration and build from that, which I tested by creating an Atari 2600 emulator config.

The launch script is a simple shell script that sets environment variables and launches the desired emulator. For Retroarch, which is what most systems use, it’s easy to copy another launch script and then just change the core it’s pointing to.

This can also be used to change cores for a given system. The config file makes it seem like you can have multiple launch scripts and choose between them, but I don’t see how you can actually do that in the system UI.

Retroarch Configuration

The stock configuration of Retroarch is a bit of a mess. I’m getting close to the point of nuking the whole config and building it from new to catch all the little shit and have a clean setup, because there is a bunch of unexpected weirdness and overrides that need to be fixed.

But I worry if I do this it may mess with the UI integration such as with save states, so I’ve not tried to nuke it. I have made some significant changes though.

Video Settings

Must turn off threaded video or things stutter like mad. It supposedly “runs faster” but you can really see it in some side scrolling games. Scrolling must be smooth. This makes things not be smooth.

Save Location

I don’t like the saves being buried in Retroarch/.retroarch/saves so I edited the config to point to a Saves folder in the root of the SD card. I also updated settings so that save files are organized by content directory, so instead of all save files being in the same folder, they are organized into Saves by game directory, so all the subdirectories in the Emu, Roms, and Saves folders align. Makes it much easier to find, back up, and organize, and avoid collisions for games that have the same filename but are for different systems (such as Tetris.nes and Tetris.gb, if you chose to name them that way).

BIOS Directory

Like the rest of the pirated software the system comes loaded up with most of the BIOS files it needs in Retroarch/.retroarch/system. I am considering changing this to a root level BIOS folder so it’s more exposed to the end user. Then again, if it has all the files it needs maybe that does not really matter, because I won’t be messing with it. It’s not like new BIOS files get released all the time for these old systems.

Overlays

After a whole bunch of trying things on various handhelds I’ve settled on using overlays for these little 640×480 screens for CRT and LCD effects instead of shaders. There is a set of excellent ones built for this use case called Perfect Overlays and it’s almost ideal. For a bigger screen like the Steam Deck I would still go with a shader for the effects, but for these little displays and low powered chips this actually looks better and runs better too. Choose the overlay that works best for your system, set opacity to 100% then set a content directory override to apply it to all games for that system (some cores are shared between different systems, but we organize the ROMs by system, hence content directory override).

Shaders

The system is barely powerful enough for shaders, I think the gpu, if you can call it that, is shitty. Doesn’t even support vulkan that I can tell. The system came with a shader called “perfect” that seems to even out pixels for non-integer scaling. Unfortunately the system doesn’t appear powerful enough to use this with many cores.

Another option is the Sharp Shimmerless shader which needs to be installed. This is fairly lightweight but still can be too much for several cores including SNES. It smooths out hard edges while remaining sharp, and can fix some weirdness with scaling, though it isn’t perfect. And unfortunately the system isn’t powerful enough to apply this on all cores.

Choosing Cores by System

As noted above, selecting cores appears to be straightforward by directly editing the launch script for consoles. I’ve been doing some testing on different available cores and caveats. This is still a work in progress.

NES/Famicom

The system default is FCEUemm. In limited testing so far, this core with the CRT overlay and the Sharp Shimmerless shader works well.

Super NES/SFC

The system default is snes9x_2005. This is an older, less accurate core, but is also faster. The sound is borked though. A spin jump on Super Mario World makes this obvious. It appears fast enough to run with the Sharp Shimmerless shader on all games I’ve tried to date.

An alternative is snes9x_2005_plus which has a better audio system but remains fairly fast. Also appears fast enough to run with the shader. I have noted that this has some weirdness in rendering in Yoshi’s Island though.

More accurate but slightly slower is snes9x_2010. This may be the best choice, but I’ve found it stutters with the shaders on. Might be best to run without the shader but with this core, for most games. One option that seems to work on the whole is to run this core without shaders and then enable bilinear filtering and the normal2x video filter. The first makes things blurry, which solves for some of the hard edge issues, and the second pixel doubles things so the blur is much less than baseline. The combination means a slightly soft image, but not so much as default, and performance appears good.

The mainline snes9x core is more accurate than these but doesn’t appear fast enough to run well on this underpowered system. BSNES cores are unavailable though I might see if I can download or compile them to test out.

Game Boy Advance

The system default is mGBA, and this is a core I use myself quite a bit. But I’ve experienced notable performance issues with this, such as massive stuttering on the opening scene of Final Fantasy IV. I’ve switched this to the gbSP core, which appears to fix the performance issues. Use of the Sharp Shimmerless shader appears to still be running full speed without glitching so far.

Although not a perfect copy of the look of an actual GBA or GBA SP, I suggest not using color correction. Most games I’ve tried don’t seem to have over-revved their colors to compensate for the screen hardware the way they did for the Game Boy Color.

Game Boy/Game Boy Color

The system default is gambatte. This appears to be running fine. I set the Game Boy configuration to use the Game Boy Pocket overlay from the Perfect Overlays collection, and dropped the GBP palette file into the Retroarch system folder. I could switch this to DMG but honestly I think the Pocket is a better choice.

Game Boy Color is simple. Make sure to enable color correction so games aren’t so insanely saturated.

One note on crashing Pokemon games: make sure the system real time clock is set to a real time, not some random date in 2017. If that doesn’t work, delete the rtc files in the Saves folder.

Sega Genesis/Megadrive and Master System

The default core is picodrive. In limited testing this appears to be running well.

Sony Playstation

The only available core appears to be pcsx_rearmed. I’m getting some slight stuttering in Xenogears and it doesn’t appear powerful enough to run with shaders on. I’ll mess around a bit more but this has very limited testing so far.

One thing that is needed is to disable “Enhanced Resolution” in the core options. The screen is tiny, and the performance hit seems noticeable.

Apps/Ports

The Miyoo Flip OS has some support for Linux ports but doesn’t appear to directly support PortMaster, at least not in standard form, even though there is a PortMaster folder on the device. However, the device shipped with a number of pirated indie games. Not great and not something I plan to leave on the device (they’re all deleted from my testing card), but possibly very useful for figuring out how to enable specific games using some of the Portmaster assets and game files. And I do own a few of the games they pirated so their examples might be useful. More testing pending.

Adding a New App

Adding a new app to the list is easy, create a folder (avoid spaces I think) and then create a config.json file with just a few lines in it, such as this one I created for Cave Story:

{
    "label":"Cave Story",
    "icon":"cavestory-80.png",j
    "launch":"CaveStory.sh",
    "description":"Cave Story"
}

That will add it to the list using the icon specified, title, and description on the App list. I’m not sure how it chooses to sort things in the list though. It seems almost random.

I don’t know what icon formats are OK, but png images appear supported, including transparency. For the App list keep the images small, 80×80 or less. The Cave Story image wouldn’t appear until I shrunk it down to 80×80.

Cave Story

For my first try adding my own App to the menu I went with Cave Story. This runs as a Retroarch core so I started by copying one of the normal retroarch game launchers. I had to download nxengine_libretro from a GitHub repository that had cores compiled for the RK3566 chipset in the device. At least since they are using a common chipset I can avoid cross compiling myself.

As simple as launching this should have been this took forever to troubleshoot. I was having issues with working directories, where to run things from, and more, and debugging on a system without a terminal is very hard. Eventually I added a bunch of manual logging to the launcher script and that led to what I was missing.

In the end, I put all the Cave Story PC files in the App folder, put nxengine_libretro.so in the /Retroarch/.retroarch/cores folder, and came up with the following script that actually works:

#!/bin/sh
echo $0 $* # probably not needed, was in example copied
progdir=(`pwd $0`) # set script directory to a variable

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$progdir # probably not needed

RA_DIR=/mnt/sdcard/RetroArch # Set retroarch base directory and enter it
cd $RA_DIR/

# Launch Retroarch with the nxengine core and path to the main Cave Story program
HOME=$RA_DIR/ $RA_DIR/ra64.miyoo -v -L $RA_DIR/.retroarch/cores/nxengine_libretro.so "$progdir/Doukutsu.exe"

I don’t love it, the Retroarch folder is hard coded, the progdir variable ends up as something weird (but working), and there are probably useless lines in there. But the game runs. Considering how long this took me to get working I’ll take the win.

MinUI

This has many fewer options. Limited initial testing shows it works fine. Although MinUI is simpler on purpose and designed to be straightforward, I have found that a little tweaking and adjustment can improve the experience. Although it is much simpler than the stock OS and gives up a few things as a result, it may be a better experience overall.

Also, I learned that installing it requires actually installing it; it doesn’t just run from the SD card, it does something to the internal memory to allow it to boot. This doesn’t appear to affect the ability to run the stock OS though, but it does mean you can’t install MinUI on one Flip and expect to be able to just slot the card into another. You have to prepare a new card (or re-prepare the old) and install it on the new console.

Software and Optional Extensions

MinUI can be downloaded from it’s Github page. I recommend getting both the base release and the extras. Since the UI only shows systems you have ROMs for there doesn’t appear to be any harm having extra items that you don’t use.

I also recommend getting Ry’s Custom MinUI paks for Miyoo Flip as it has some useful additions.

Follow the instructions to install. For the Miyoo Flip that pretty much means just copying the files to an SD card. I had success with a blank FAT32 formatted card and just copying all the files from the base and extras install along with Ry’s paks over to the new card before inserting it into the right SD card slot. There are a bunch of folders in the MinUI release for other systems, but these don’t appear to affect anything negatively.

On first boot with this prepared card the software will take a while to install, then reboot and boot into the MinUI interface. You can then add your BIOS and ROM files to the appropriate folders following the documentation included with the software downloads.

Optional Emulator Cores

The MinUI extras pak includes the mednafen-supafaust and mgba libretro cores for the SNES and GBA. I would probably stick with the base cores (snes9x_2005_plus and gpsp) for most games, but for particular games you can try the other cores by moving the game files from the base ROM folders to the optional core folders (SUPA and MGBA) and they’ll boot with that. Since the base ROM folder starts with the system folder they’ll appear in a single list.

Change Boot Logo

MinUI includes a tool to change the boot logo found in the Tools folder. It defaults to changing it to the MinUI logo, but I created a simple 640×480 windows bitmap file with my own logo on a black background and it flashed this just fine. After running the tool it will be renamed to Bootlogo.pak.disabled and no longer show up on the list, but you can rename it and change the bitmap file and do it again, or uninstall it if needed.

Adding Systems

Since MinUI is still based on Retroarch and libretro, other systems can be added by creating custom Pak files if you have a libretro core compiled for the system, such as from GitHub repository that had cores compiled for the RK3566 chipset. Not all systems will work though, as not all features are supported in the version of Retroarch included with MinUI. For example, the Atari 2600 Stella core fails to launch as this version of Retroarch doesn’t support XRGB8888 color.

The MinUI documentation has more details.

Example System, Atari 7800

The ProSystem libretro core does run, so let’s show an example of setting it up on MinUI.

In the Emus/my355 folder on the SD Card, add a new folder for the new emulator with a .pak extension. I used A7800.pak for this example. In that folder drop the prosystem_libretro.so core file and copy an existing launch.sh file from another emulator that uses a custom core such as SUPA.pak into it to use as a starting point. From that example change the reference to the emulator core and review the rest to make sure it makes sense.

#!/bin/sh

# Atari 7800 ProSystem launch script

EMU_EXE=prosystem # used in the script below to call the libretro core file
CORES_PATH=$(dirname "$0") # needed so that the script looks in the current folder rather than the system cores folder

###############################

EMU_TAG=$(basename "$(dirname "$0")" .pak)
ROM="$1"
mkdir -p "$BIOS_PATH/$EMU_TAG"
mkdir -p "$SAVES_PATH/$EMU_TAG"
HOME="$USERDATA_PATH"
cd "$HOME"
minarch.elf "$CORES_PATH/${EMU_EXE}_libretro.so" "$ROM" > "$LOGS_PATH/$EMU_TAG.txt" 2>&1

In the Roms folder add a new folder for the new core, with the displayed name first and the emulator pak folder name in parentheses, such as Atari 7800 (A7800) and place your ROMs in that folder. At this point it should show up in the main UI and work, and will create the other folders for saves and BIOS as needed. If your new core does need a BIOS file, add it to the Bios folders based on the paths above.

Cave Story

Because Cave Story runs as a libretro core and is compatible with the cut down version of Retroarch, it is possible to get this to run. Old versions of MinUI from 2022 had this as an option as Native Games, but it doesn’t appear to be included any more. I used some of the old code as a guide, with the same core file as in the Cave Story discussion for the stock OS above.

Using the old code as a basis, I created a new folder on the SD card called Emus/my355/SH.pak. In this folder I created a launch file launch.sh based on the older MinUI code:

#!/bin/sh

# for Native Games or Ports

EMU_TAG=$(basename "$(dirname "$0")" .pak)
mkdir -p "$SAVES_PATH/$EMU_TAG"
"$1" &> "$LOGS_PATH/$EMU_TAG.txt"

Then in the Roms folder I created a new folder called Native Games (SH), and a Cave Story game inside that. Into that folder I include a text file called Cave Story.m3u which only contains launch.sh. This is basically a playlist that links the Rom folder to what file to run, similar to how MinUI handles multi-disc playstation games. I also copied the Cave Story windows game distribution including Doukutsu.exe and the related data folder into that folder.

I then dropped in the nxengine_libretro.so core as noted in the stock OS discussion.

Then we need the launch.sh file to actually run the game. Based on the older example, here is the resulting file that works on the January 2025 release of MinUI:

#!/bin/sh

DIR="$(dirname "$0")"
HOME="$USERDATA_PATH"

cd "$DIR"
if [ -f Doukutsu.exe ] && [ -d data ]; then
    cd "$HOME"
    minarch.elf "$DIR/nxengine_libretro.so" "$DIR/Doukutsu.exe"
else
    show "okay.png"
    say "Missing exe and data folder!"$'\n\n'"Please see readme.txt"$'\n'"in the Cave Story folder"$'\n'"on your SD card."$'\n'
    confirm only
fi