ESP32 Mini Game Box Port

[Cralex]

As you may have seen on the forums, I was able to build a working firmware image! I'm building on windows 10 with ESP-IDF 4.1 based on version 1.3.3, since this is all what I had set up already.

Like you suggested, basing it off of the mrgc-g32 target worked for generating an image that the device's bootloader would allow to flash. After tweaking just a few values, I was able to build the launcher and gnuboy. The speaker, screen (with brightness controls), and buttons all work out of the box. The buttons match the vendor's firmware, so from left to right it's Start, Select, Menu, and Power. (You hold Menu/Sound on boot to access the bootloader.) If I enable the option button variable, I imagine the Option button will map itself to Power. (You have to hold down the Power button to shut the unit down, so this'll work fine.)

I'm attaching the modified target file that I used to build the firmware. (With the resolution flipped the right way around.) mrgc-g32.zip

I noticed that current retro-go has made some changes in the target file, so now I'm working on building the release version for this device to see if it'll work and if I can get wifi working. The finer details, such as battery capacity, are unfortunately beyond me.

Regarding getting a serial console going... It appears on my computer as "USB-SERIAL CH340 (COM16)" whether or not Retro-Go is running. So I tried running rg_tool.py --port=COM16 --target=mrgc-g32 run launcher while Retro-Go was booted, but it failed to connect. I can give you the exact error message once I'm done trying to build more firmware. :)

Edit: I wasn't able to finish the build of the current version. Like my earlier build, this is with the sd-card fix and panic patches applied. Same IDF. [518/673] Linking CXX static library esp-idf\newlib\libnewlib.a ninja: build stopped: subcommand failed. ninja failed with exit code 1 Traceback (most recent call last): File "C:\Users\Cralex\retro-go-new\retro-go\rg_tool.py", line 333, in <module> build_app(app, args.target, command == "profile", args.with_networking) File "C:\Users\Cralex\retro-go-new\retro-go\rg_tool.py", line 208, in build_app subprocess.run("idf.py app", shell=True, check=True, cwd=os.path.join(os.getcwd(), app)) File "C:\Users\Cralex\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 528, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command 'idf.py app' returned non-zero exit status 2.

Edit 2: Looks like the screen still needs some work. I'll add a margin and see if I can get it aligned properly. As you can see, the colors are also a bit off... Still, it's amazing to see how portable Retro-Go is and how well things work already. (Still running 1.3.3)

I thought I turned on the option button variable before my last build, but the power button still doesn't do anything in software. Since the stock firmware doesn't do anything with that button either other than power on and off, I'm wondering if they just don't have it talk to the firmware at all... Also, I don't think there's a disk LED, just power and charge indicators.

[ducalex]

Regarding serial, it's possible that they haven't wired all the signals and you'd need to manually put the device in flash mode (like holding a button while powering up). This is an issue on the mrgc-g32 too, very annoying.

But, even if you can't easily flash over serial, you should be able to at least access the log with rg_tool.py --port=COM16 monitor or using another program like CoolTerm or putty (COM16 at 115200).

[Cralex]

OK, I will try that. In the meantime, I was able to get a 4.3X IDF running and used it to successfully build the current version of Retro-Go for the device, including networking. I will try poking around with the serial connection and see if I can learn anything else.

Edit: I was able to monitor over serial just fine, and it looked very much like monitoring Retro-Go on the OdroidGo. Nothing really jumped out at me. I have the screen dimensions set up very closely to how they should be. (I can see a line or two of garbage pixels under the bottom bezel but that's it.) Here's what I'm using to build the firmware: mrgc-g32.h.zip

I think I managed to corrupt my card, so I'll need to open it up after all. (Anything I can do while it's open to help get the port done?) My unit came pre-assembled, so I don't know what sort of card was in there/if any fault lies with retro-go at all. I was doing a mass copy of 148 combined gb/gbc games into my gbc folder. It took a long time of course, but after it was done I started seeing a bunch of garbage-named files in there too and the unit was really slow trying to display it all.

[KD-MM2]

Regarding serial, it's possible that they haven't wired all the signals and you'd need to manually put the device in flash mode (like holding a button while powering up). This is an issue on the mrgc-g32 too, very annoying.

But, even if you can't easily flash over serial, you should be able to at least access the log with rg_tool.py --port=COM16 monitor or using another program like CoolTerm or putty (COM16 at 115200).

@Cralex You can use the ArduinoIDE for convenience, just select the Port, and click the button. But remember to close the Serial Monitor window before flashing or something else, or you will get "Device is busy" error.

[Cralex]

@KD-MM2 Thanks for the tip. :)

I got my device up and running again. I think I’m monitoring the wrong thing for the battery level, since it’s stuck at 100 over the serial connection. I let the battery die earlier, and the power LED flickered only moments before the unit shutdown, whereas I’m pretty sure the original firmware gives an earlier warning. If I can find the right entry in the original firmware’s source code that should tell me where to look…

Does anyone have any ideas what I can experiment with to fix the screen colors? Darker colors tend to look almost normal... It seems brownish/reddish in some places... Some grays (the title screen of Link to the Past) are indistinguishable from each other.

Overall, the screen works very well in all areas other than this. The ILI9341 driver clearly has no problem initing the screen, but I don't know enough about little displays like this to see what the problem could be.

[ducalex]

That's likely the wrong gamma curve. Maybe you can find the proper ones in the original source code, they're ili commands 0xE0 and 0xE1. Could also be the pixel format (command 0x3A) but I feel like that would be more obvious.

I'm not an expert either, it could be any other missing or incorrect init command, but that's where I'd start :) .

[Cralex]

That's likely the wrong gamma curve. Maybe you can find the proper ones in the original source code, they're ili commands 0xE0 and 0xE1. Could also be the pixel format (command 0x3A) but I feel like that would be more obvious.

I'm not an expert either, it could be any other missing or incorrect init command, but that's where I'd start :) .

GOT IT! I found the display driver in the original source code. The following gamma settings cause the proper colors to appear: {0xE0, {0xD0, 0x00, 0x05, 0x0E, 0x15, 0x0D, 0x37, 0x43, 0x47, 0x09, 0x15, 0x12, 0x16, 0x19}, 14}, {0xE1, {0xD0, 0x00, 0x05, 0x0D, 0x0C, 0x06, 0x2D, 0x44, 0x40, 0x0E, 0x1C, 0x18, 0x16, 0x19}, 14}, Guess we'll need to add a new display type for this unit after all. :) I'll look over the driver and see if anything else needs to be changed for the perfect display experience.

[Cralex]

I'm taking a break from getting the battery meter working (tried looking at a few things from the stock source, but nothing works yet) to clean up my work in preparation of making a pull request. I'd like some feedback on the button layout, though.

The upper right button, Power, does not seem to be connected to I/O at all (it's not mentioned in the stock source code either) so we have three buttons to work with for Start, Select, and Menu.

The default layout is Start, Select, and Menu. This is terrible for Retro-Go because switching tabs in the launcher is inverted compared to the OdroidGO. (I'd even get lost switching tabs when going between the devices using this layout.) It also really messes up the button mapping for the SNES emulator.

I've tried both Select, Start, Menu and Menu, Select, Start. Both layouts are workable. Neither one is perfect for SNES, but at least they're in the right order. The question is: action buttons grouped together and operated with the left hand and leaving the menu button off by itself, or action buttons under your fingertips on each hand, separated by the screen?

[ducalex]

I can't comment on what would feel best on this device, but we certainly can add more layout options in SNES if that's the only blocker :).

[Cralex]

I can't comment on what would feel best on this device, but we certainly can add more layout options in SNES if that's the only blocker :).

It would be ideal if the two buttons above A and B could be X and Y, but we aren't fortunate enough to have that option. :) Maybe I'll find some other places to ask around for opinions. (Other than the "It'll give me hand cramps!" or "I'll go blind squinting at that tiny screen! that tiny devices always get.) Point is, it CAN run Retro-GO, so I won't quit until it does. :)

[Cralex]

I'm rebasing development on the shiny new release. 😀

The build file needed to be updated in order to build properly. (See my pull request.) However, the resulting firmware does not flash.

My first thought was that the format wasn't correctly set to ESPlay, but so far I haven't found anything that would indicate that. If I find it before anyone else, I'll submit another pull request.

[ducalex]

No you're right, something went wrong when I merged the branches. It's not respecting the env.py files.

[ducalex]

It should be fixed now! I guess I'll have to re-issue the release, the format was broken for MRGC-G32 as well. Good thing I hadn't advertised it yet :).

[Cralex]

Despite the unobtanium nature of this device, someone generously offered to sell me their metal case unit when they saw that my plastic unit had a broken screen. Upon receiving it, I realized that the metal case has a taller view of the screen by ten pixels, which causes some unsightly lines of garbage when playing on a metal unit, that gets masked off on a plastic unit. I have adjusted the screen height and bottom margin to account for this, leaving a nice black bar on the bottom of the screen. Setting the bottom margin to zero, meanwhile, uses the full height of a metal unit but would crop off the bottom of a plastic unit.

For my pull request, I have a line that you uncomment to achieve the maximum screen height depending on which case you have, with the plastic case line uncommented by default as a reasonable compromise. I'd like to make it easy for any metal-case owners out there to use their whole screens, but having a separate image built based on a single variable changing would kind of bug me. But maybe it shouldn't?

[ducalex]

You're right making two builds would be annoying! It's also more confusing for the user.

I guess we could add an advanced menu to tweak things like margins at run time? There's no reason why margins couldn't be dynamic. The new advanced menu could contains other advanced things like overclocking or even LCD/SD Card frequency.

I'm not sure where's the best place to put that new menu, though. I don't want things to get even more cluttered.

[Cralex]

Yeah, it wouldn't be great to clutter things up more, especially since it's only one target (so far) that realistically needs more than one margin setting. Of the few people that I know of that have the GameBox Mini, only a handful of them have ever had a metal case unit.