Issue with ESPlay micro

[monsieurPiGG]

retro-go (mrgc-g32 last version) installs and launch in ESPlay micro but display remains white.
We can argue it installs since retro-go folder are created in the sd card.
ESPlay should be a clone of odroid-go.
Here are the specs :
ESP32 WROVER, Dual-core processor with Integrated 16MB Flash + 8MB PSRAM
Integrated WIFI and Bluetooth 4 BLE
2,4" ILI9341 TFT Panel
Micro SD slot connected to SDMMC Host in 1 Line Mode for saving GPIO pin
Integrated I2S DAC via UDA1334A
Is it a known issu with other odroid go clones ? Is there a workaround ? Thanks !

[Cralex]

I noticed that there's an esplay target, but for some reason it's not included in the main releases. (Maybe it's not done?) I don't have an esplay micro of my own, but maybe this firmware I built will work for you.
retro-go-1.35.1-esplay-s3.zip

[monsieurPiGG]

Thanks ! Unfortunately it doesn't flash, There is an header mismatch error and erase error.

[monsieurPiGG]

Edit : the .img flash but it's stuck with a white screen, as for mrgc-g32 release...
Indeed, I can see an esplay target in rg_tool.py...

[ducalex]

Esplay micro isn't supported. No reason it couldn't be, but someone will have to write the target file :) . The mrgc target is a good starting point, from what I can tell it's already a close match in terms of hardware and pinout. Maybe borrowing the lcd init sequence from the esplay micro's code would be enough, I don't know.

[Cralex]

Drat, ok. There are multiple units that use the ESPlay name, and I was having trouble figuring out which one we have a target for.

@monsieurPiGG Is this the unit you have? I was thinking about possibly picking up one at some point.

[monsieurPiGG]

@Cralex, yes, this is the unit I have !
I'll try to figure it out. I'm new to esp32 programming but I want to learn !
Thanks !

[Cralex]

@monsieurPiGG Do you have a build environment set up? If I have time, maybe I can look at the source code for one of your device's firmwares and see if there are any clues there to get your screen working.

[monsieurPiGG]

Hi ! Sorry for the delay !
@Cralex, not yet but it's my first step for sure !

[Cralex]

I have an ESPlay Micro V2 on order. Time permitting, I'll be able to attempt building and testing Retro-Go ports for it once it finally arrives. 🚀

Edit: Looking for firmware source code for the device to reference the screen's init code. It's hard to tell what's for the original ESPlay Micro vs the V2 (if there's even a difference) until I have one in hand. It'll be nice once we have a Retro-Go port up and running... Make it easier to, ah, avoid potentially copyrighted content while just looking for firmware.

[monsieurPiGG]

Sorry I didn't,t have time to try something...
That's sound good ! I guess display init sequence is the same for both v1 and v2. I had a v2 running the same firmware...

[Cralex]

That is an important clue, though. I noticed, of the multiple firmwares available for the ESPlay Micro, none of it is labeled V1 or V2. If they are in fact all capable of running the same firmware, that gives us a lot of working code to base a Retro-Go port off of and I might be justified in naming the target just ESPlay Micro.

@ducalex I noticed that it's possible to specify shoulder buttons in Retro-Go targets. Since this device actually has some, are the emulators set up to take advantage of them?

Edit: My unit arrived today. The buttons are clicky (So clicky! It burns my ears!) and all the acrylic parts and screen had protective coverings that required disassembly to remove. The board designer flipped A and B compared to how they're normally on Nintendo consoles. Perhaps worst of all, my screen came crooked and was mounted with some really sticky adhesive foam.

But enough complaining. This thing needs Retro-Go and I can't work on porting it if I break the screen while trying to straighten it. (ง'̀-'́)ง I found a couple possible screen init codes to try in the OG firmware source code to get me started.

[Cralex]

Sorry to bug, @ducalex , but I'm having some trouble building a compatible firmware file that doesn't do the "header mismatch error" thing. Also, the firmware files from https://github.com/pebri86/esplay-micro-firmware-collections don't seem to work either. I'm attaching some firmware that came on the device's card. Could you possibly check it to see what format we should aim for? Thanks.

firmware.zip

Edit: Seems like a firmware format that Retro-Go hasn't used yet. I tried placing both the ODG and the G32 firmware files in there as a sanity check to make sure I wasn't compiling my WIP firmware wrong, but both firmware files give the header mismatch error.

[ducalex]

@ducalex I noticed that it's possible to specify shoulder buttons in Retro-Go targets. Since this device actually has some, are the emulators set up to take advantage of them?

Currently no but rg_input supports them in most drivers I think, so it's only needed to be added on the emulator side. Feel free to send a PR or just tell me what mapping should be added where :).

I'm attaching some firmware that came on the device's card. Could you possibly check it to see what format we should aim for? Thanks.

Those .fw files seem to match the esplay format:

• 22 bytes magic "ESPLAY_FIRMWARE_V00_01"
• 40 bytes name "Retro-Emulation"
• 8256 bytes icon
• data
• crc32

I don't see anything obvious as to why those are accepted as valid and the ones produced by retro-go (in esplay mode) are not...

[monsieurPiGG]

Perhaps worst of all, my screen came crooked and was mounted with some really sticky adhesive foam.

Indeed. You can lift the screen up with a thin blade. I've added a strong double sided tape, the one used for carpets.
Overall, if you want something that feel stronger and have access to a 3D printer, I've designed this tiny case for v2 esplay micro board : https://www.thingiverse.com/thing:5592683

That's strange that the mrgc-g32 retro go .fw doesn't have the header mismatch error and seems to install since retro go folders are created in sd card.

[Cralex]

@monsieurPiGG That's a cute case! I don't have access to a 3D printer but I might have to order one made at some point.

Regarding Retro-Go folders, you mentioned that you tried flashing the .img file that I uploaded before and that succeeded, but there was nothing on the screen, right? I am guessing that Retro-Go was able to boot at that time (just without the proper screen configuration) and that's when the folders were created.

I'll keep trying and see if I come up with anything. This device is unusual among the other ESP32 handhelds I've used in that it displays an animated splash screen before starting the installed firmware or boot loader. No idea how that works or if it matters. I'll probably try to flash it over USB or something and see if I can at least get it running.

[monsieurPiGG]

you mentioned that you tried flashing the .img file that I uploaded before and that succeeded, but there was nothing on the screen, right?

I meant the mrgc-g32 release of retro go. This one seems to launch, but with a display issue. Unfortunately, the .fw and the .img files you provided earlier gave the header mismatch error.

[Cralex]

Progress, but ugh, it was a bear getting here.

(I'm partly writing this so I don't forget how on earth I got here.) Since I can't get it to accept .fw files, I tried flashing the .img file I compiled instead using esptool. It kept failing to connect and giving me a Invalid head of packet (0x45) error, so I went over to where the base firmware is (https://github.com/pebri86/esplay-base-firmware/issues) to flash that, just to see if I could. Same problem. I was about to give up when I tried pressing the little reset button on the back of the board while it was trying to connect. Finally, I have some means of testing Retro-Go and also restoring the stock bootloader when needed. The screen works, but it's rotated wrong and inverted(?!) but I know what to poke with to fix that. Just need to take a break first...

Edit: Since I actually know very little about how esp32 works under the hood, what defines whether or not a .fw needs to be in ESPlay format or not, the hardware or the bootloader, @ducalex ? If for some reason, I am never able to figure out how to load Retro-Go in .fw format in the stock bootloader, would porting and flashing your Odroid Multi-Firmware bootloader neutralize the format problem? Since I know how to flash the stock bootloader now, I am willing to experiment if it comes to that.

Edit2: I took another look at the aforementioned firmware collections github and you can clearly see that the Esplay Micro's main emulation firmware was updated to support the V2 hardware. Sure enough, it matches what came on the card and explains why most of the older firmware doesn't work with it. I found the commit where the firmware was updated here. Perhaps the key lies in the mkrelease_retro-esp32.sh file.

[monsieurPiGG]

@Cralex it's amazing ! You're almost there !

[ducalex]

Edit: Since I actually know very little about how esp32 works under the hood, what defines whether or not a .fw needs to be in ESPlay format or not, the hardware or the bootloader, @ducalex ?

It is the flashing utility that resides in the factory partition (the app that starts when you power up holding a specific button). It's called odroid-go-firmware on the ODROID GO.

If for some reason, I am never able to figure out how to load Retro-Go in .fw format in the stock bootloader, would porting and flashing your Odroid Multi-Firmware bootloader neutralize the format problem?

Yes it would, but surely finding the .fw format would be easier!

The .fw format can be known from two sources:

• The source of their odroid-go-firmware's version/fork (I don't know which came first...)
• The source of their mkfw tool (I couldn't locate it, but it's called in the .sh file you showed)

Alternatively if someone can provide me a .fw that IS recognized by the firmware and a .fw that ISN'T but SHOULD BE recognized, I might be able to find the issue. It has to be something minor!

---

I can't explain why your device rejects the mrgc-g32 builds I published, but have you double checked that your own builds are indeed in the esplay format? Maybe your target isn't configured correctly and retro-go makes the .fw in the odroid-go format?

[Cralex]

I'm very nearly done with the screen. It fills the display properly and everything looks great, but everything is still flipped across the y-axis. (So, right-side up but mirrored.) I tried changing the value of #define RG_SCREEN_ROTATE but it doesn't seem to change anything. I have no idea what I'm missing. Mind taking a look? My screen driver is here and the reference I used to write it from the stock fw is here. And here's the current state of the target: esplay-micro.zip

I looked at the resulting firmware in a hex editor and it definitely showing as an esplay firmware. Might looking at the various emulator firmware versions for the Esplay Micro line help? The "update 2.0" version is an exact match for the one on the card and is valid, while the "new release" one is for the V1 and is not valid. (Other changes were made as well, I'm sure.)

Still do do: verify sound works, finish mapping buttons, make sure networking works... Also flashing the .img never seems to allow me to actually launch an emulator. That's not normal, right? I'm only building with retro-core and launcher for now. Haven't checked for serial output yet.

[ducalex]

I'm very nearly done with the screen. It fills the display properly and everything looks great, but everything is still flipped across the y-axis. (So, right-side up but mirrored.)

Take a look at the 0x36 command/register, it controls scanning direction. It's called "Memory Access Control" in the datasheet.

Can't really help with your other questions but I imagine obtaining debug output would be a good place to start :).

[monsieurPiGG]

I don't know if it could help, but I've ever use ILI9341 display with rasp pi. In raspbian (config.txt), display_lcd_rotate can take that arguments :

• 1 for 90 degrees clockwise
• 2 for 180 degrees clockwise
• 0x10000 for horizontal flip
• 0x20000 for vertical flip

[monsieurPiGG]

Take a look at the 0x36 command/register, it controls scanning direction. It's called "Memory Access Control" in the datasheet.

Can this be helpful ?
Bodmer/TFT_eSPI#544

[Cralex]

Thanks @ducalex for pointing me in the right direction, and @monsieurPiGG for the legwork. We have a fully functional screen, ready to be merged. 😁

Edit: Probably gonna call it a night. I tinkered around a little now that I have a legible display. Here's where I'm at.

• Networking: Seems to work fine. I was able to create an AP and transfer a file over. Need to test client mode. (Had problems, see last bullet point.)
• Buttons: Most of the main buttons work with the target file that I based off of the g32 except for Menu, L, and R. They seem to be connected a different way from the rest. Need to figure out how they're connected and how to express it properly in the target file. Edit: Additional buttons are connected via a PCF8574 I2C GPIO, but I don't know how to address them yet. I found what appears to be a list of the buttons as GPIO, but trying to map them that way caused the function I was trying to map (Menu button) to be called when I pressed up and down.
• Fw format: I flashed the stock bootloader again and, just for fun, tried flashing the g32 firmware. Still didn't work, but I got more that just the header match error. When I tried flashing it anyway, I got checksum mismatch error (it was gone so fast that I had to film in slow motion to read it) and partition count error, which is where the bootloader hangs.
• Launching emulators: As stated above, the launcher restarts when I try to start an emulator. I got serial output, but didn't see anything that looked like "something's wrong, so I'll just restart the launcher". (Having trouble copying it out of what I was using to monitor it, or else I'd post the output.) But, I'm starting to wonder if my sd card is faulty and might even be causing the problem. I noticed a lot of retro-go creating directories in the serial output that should've been there already, and it doesn't always reliably appear in a computer or the unit itself. I imagine retro-go wouldn't know what to do if the files it just created aren't there when it goes to read them... I'll try with a known good card and see if anything changes. After sleep. Retro-Go didn't like the janky card the unit came with. Now that it's not losing the files it creates, the thing boots games now.

[nod3011]

Thanks @ducalex for pointing me in the right direction, and @monsieurPiGG for the legwork. We have a fully functional screen, ready to be merged. 😁

Edit: Probably gonna call it a night. I tinkered around a little now that I have a legible display. Here's where I'm at.

• Networking: Seems to work fine. I was able to create an AP and transfer a file over. Need to test client mode. (Had problems, see last bullet point.)
• Buttons: Most of the main buttons work with the target file that I based off of the g32 except for Menu, L, and R. They seem to be connected a different way from the rest. Need to figure out how they're connected and how to express it properly in the target file. Edit: Additional buttons are connected via a PCF8574 I2C GPIO, but I don't know how to address them yet. I found what appears to be a list of the buttons as GPIO, but trying to map them that way caused the function I was trying to map (Menu button) to be called when I pressed up and down.
• Fw format: I flashed the stock bootloader again and, just for fun, tried flashing the g32 firmware. Still didn't work, but I got more that just the header match error. When I tried flashing it anyway, I got checksum mismatch error (it was gone so fast that I had to film in slow motion to read it) and partition count error, which is where the bootloader hangs.
• Launching emulators: As stated above, the launcher restarts when I try to start an emulator. I got serial output, but didn't see anything that looked like "something's wrong, so I'll just restart the launcher". (Having trouble copying it out of what I was using to monitor it, or else I'd post the output.) But, I'm starting to wonder if my sd card is faulty and might even be causing the problem. I noticed a lot of retro-go creating directories in the serial output that should've been there already, and it doesn't always reliably appear in a computer or the unit itself. I imagine retro-go wouldn't know what to do if the files it just created aren't there when it goes to read them... I'll try with a known good card and see if anything changes. After sleep. Retro-Go didn't like the janky card the unit came with. Now that it's not losing the files it creates, the thing boots games now.

This look great.

[ducalex]

Fw format: I flashed the stock bootloader again and, just for fun, tried flashing the g32 firmware. Still didn't work, but I got more that just the header match error. When I tried flashing it anyway, I got checksum mismatch error (it was gone so fast that I had to film in slow motion to read it) and partition count error, which is where the bootloader hangs.

That's progress at least!

I built a .fw with our mkfw.py and their mkfw.c[1] then compared the result and they were identical. So I'm tempted to say our .fw format is fine. An SD Card issue (driver or card) perhaps?

1. https://github.com/pebri86/esplay-base-firmware/tree/master/tools/mkfw

[monsieurPiGG]

An SD Card issue (driver or card) perhaps?

Since it has problems launching emulators from roms stored in the supplied sd card, I'm also tempted to point the sd card.
@Cralex does it flash .fw from bootloader since you've changed your sd ?

[Cralex]

An SD Card issue (driver or card) perhaps?

does it flash .fw from bootloader since you've changed your sd ?

Well, I thought I'd tried flashing from the bootloader after I switched cards, or maybe I just did a backup of what was already on the card without checking the validity of my build. I flashed the bootloader and copied over a fresh build of retro-go... It works. Icon appears, it flashes, it boots. Oy! Sorry all for the wild goose chase. In addition to simply working, I also tested the headphone audio (can people solder a speaker to this?), the wifi again, and the battery. Battery needs more tweaking, but everything else works fine.

I'm taking another look at the buttons. I'm using the I2C driver, and I noticed that past a certain point the buttons start to repeat themselves without hitting Menu, L, and R. I'm going to keep trying and see if maybe the new buttons can be mapped by passing by the first repeats. I'll post my results when I have them.
Edit: Yeah, for (1<<X), if I go too high then retro-go just gets stuck in recovery mode. Open to suggestions... I'll probably clean up my target file and submit a pull request soon as a work-in-progress.

Oh yeah, I'll bet all those other esplay micro firmwares will work fine now that I'm copying them to a good card. 🙃

[Cralex]

Okay, now that the self-inflicted flashing problem is solved, I see no reason not to put out an alpha release for ESPlay Micro owners to test out. See usage and installation notes in the link. I also made a pull request with all the necessary files to build the firmware in case anyone wants to help me work on it.

[nod3011]

Okay, now that the self-inflicted flashing problem is solved, I see no reason not to put out an alpha release for ESPlay Micro owners to test out. See usage and installation notes in the link. I also made a pull request with all the necessary files to build the firmware in case anyone wants to help me work on it.

I've try this alpha version. look like the [select] button and [menu] button is the same. This might need some fix.

[monsieurPiGG]

Amazing !

Point 3 in the release :

Turn your unit off and back on again. This should get you access to the bootloader.

It's not necessary. Just hold menu while booting and the device boots the boot loader.

look like the [select] button and [menu] button is the same. This might need some fix.

@nod3011, it's normal and intended by @Cralex in order to make it playable.

can people solder a speaker to this?

I have a speaker soldered to it and it works. Sound glitches with snes but I guess it's a known issue.

It's amazing ! I'm impressed by the snes performance, still not 100% speed but good enough to play some games (with patience !).

[Cralex]

After a nice long rest, I'm back to look at the buttons, this time with moderately more research. There's a diagram of the unit's component connections here. Note the PCF8574 GPIO extender chip that appears to be used to wire some of the buttons. There's a little guide on how to use the thing here.

As little experience as I have with ESP32, I have even less with Arduino. But it seems as though someone wanting to use this with Arduino would need to add some libraries. Does it look like Retro-Go would need to do this as well? I glanced over the stock firmware and it doesn't seem as though they do. There also seems to be a section in the guide that hints that the addresses for the added pins should start at 0x20, but I don't know how to apply the knowledge. This is all rather above my head, but I really want to improve the port for this device.

[ducalex]

In retro-go you can use rg_i2c_* functions to talk to the chip. The equivalent to what they do here would be rg_i2c_read_byte.

So essentially in rg_input_init you'd need to call rg_i2c_init(); and then in gamepad_read you'd do uint8_t buttons = rg_i2c_read_byte(0x20, -1);.

[Cralex]

I've been working for a few hours on the button mapping and could use a break and/or another set of (human) eyes.
Here's what I added to rg_input.c:
Under static inline uint32_t gamepad_read(void)

#elif RG_GAMEPAD_DRIVER == 7  // ESPlay Micro V2
    uint8_t buttons = rg_i2c_read_byte(0x20, -1);
        for (size_t i = 0; i < keymap_size; ++i)
    {
        if (buttons & (1 << i))
            state |= keymap[i].key;

Under void rg_input_init(void)

#elif RG_GAMEPAD_DRIVER == 7 // ESPlay Micro V2
    const char *driver = "I2C_BYTE";
    rg_i2c_init();

It builds, but always boots to Recovery Mode regardless of how I've set the button mapping, so either I'm not expressing the buttons correctly or my additions to rg_input.c are inherently buggy. I eventually stumbled on a repo containing some simple tests for the unit here, including a helpful button test for reference. The repo mentions that only the L, R and MENU keys are directly connected to the IO pins, while the other keys are connected through the PCF8574.

But yeah, need sleep. I'll think on this more tomorrow.

[ducalex]

I think it should look more like:

    uint8_t buttons = rg_i2c_read_byte(0x20, -1);
        for (size_t i = 0; i < keymap_size; ++i)
    {
        if ((buttons & keymap[i].src) == keymap[i].src)
            state |= keymap[i].key;

RG_GAMEPAD_MAP is a table where each entry has:

• .src: This is the bitmask that represents the button in hardware
• .key: The retro-go key to which this bit maps

But maybe you should ignore the map until you get things working, it can get a bit confusing. Another reason to ignore RG_GAMEPAD_MAP for now is that it isn't super flexible, it can't express two sources of inputs (gpio+i2c extender) nicely. We'll have to fix that...

Anyway just to get things working you could just do something like that:

    uint8_t buttons = rg_i2c_read_byte(0x20, -1);
    if (buttons & (1 << 0)) 
        state |= RG_KEY_UP;
    if (buttons & (1 << 1)) 
        state |= RG_KEY_DOWN;
    if (!gpio_get_level(MENU GPIO))
        state |= RG_KEY_MENU;
    if (!gpio_get_level(L GPIO))
        state |= RG_KEY_L;

[Takiiiiiiii]

Not exactly sure why, but this doesn't seem to work with ESPLAY Micro V1 (along with other boards based on it). Have any of you been able to get it to work on a V1 board?

V1 - ESP32 WROVER, Dual-core processor with Integrated 4MB Flash + 4MB PSRAM
V2 - ESP32 WROVER, Dual-core processor with Integrated 16MB Flash + 8MB PSRAM

The two V1 boards that I have just loop:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57

Solved by reflashing the bootloader with JP1 connected to ground.

This is what the end of the log shows toward the end of the V1.40 flashing process:

Writing (4) - 0x0de000
Writing (4) - 0x0df000
Writing (4) - 0x0e0000
Writing (4) - 0x0e1000
Writing (4) - 0x0e2000
OK: [4] Length=0x0e2df0
write_partition_table: startTableEntry=4, startFlashAddress=0x050000
Booting application.
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

The last four lines loop.

@ducalex It might be worth renaming the release to V2 unless someone with a V1 confirms it works.

[ducalex]

I don't have any of those devices so we'll wait for @Cralex to see if he knows what's going on before I make any naming or code changes.

But that sounds like maybe retro-go doesn't fit in the flash and, for whatever reason, the firmware/bootloader tries to flash it anyway? Based on that log, it would end at 0x410000 (1.40 is 3.75MB). Which is likely past the 4MB flash.

We have several options to make retro-go smaller:

• Disable networking: maybe 400KB saved
• Remove SNES: 512KB saved
• Remove Genesis: 960KB saved

We could also instruct users to flash a (non-reduced) .img version instead. But it's perhaps less convenient.

Let me know what you all think is the best route to take and I'll see how I can integrate those needs in my next release.

[Takiiiiiiii]

Darn. I might swap out my Wrover module for an 8MB one. I was looking forward to testing those two systems. Losing networking isn't a huge issue.

[Cralex]

Yeah, I also don't have a V1 board, and I'm guessing (I don't know off the top of my head. Maybe the MRGC GameBox Mini?) that all the ports I've been working on so far have had enough flash storage to install a full build of Retro-Go using the bootloader's flashing feature.

Renaming the port to specify a V2 target is certainly one option, although I'm curious to know how well it runs Retro-Go. Were you able to flash a Retro-Go .img on your V1 directly, without using the bootloader? Like Ducalex said, building it without some of the extra components (networking, SNES, Genesis) should hopefully result in an image small enough to flash from the bootloader.

I am rather spoiled by the networking features, but I can compile a copy without it if you would like to test it out.

[ducalex]

Darn. I might swap out my Wrover module for an 8MB one. I was looking forward to testing those two systems. Losing networking isn't a huge issue.

If I'm being honest you're not missing much, neither is running very well.

Attached build is as small as I could pack things, can you test it to confirm it's just a size issue? Nothing was cut, I've just moved snes9x to retro-core.

retro-go_1.41-dirty_esplay-micro.zip

If it still doesn't work for other reasons then I'm ok with making it clear retro-go is v2 only!

[Takiiiiiiii]

Darn. I might swap out my Wrover module for an 8MB one. I was looking forward to testing those two systems. Losing networking isn't a huge issue.

If I'm being honest you're not missing much, neither is running very well.

Attached build is as small as I could pack things, can you test it to confirm it's just a size issue? Nothing was cut, I've just moved snes9x to retro-core.

retro-go_1.41-dirty_esplay-micro.zip

If it still doesn't work for other reasons then I'm ok with making it clear retro-go is v2 only!

I'll try and update you with the results. The strange thing is this person was able to get retro-go working on a 4MB V1 derivative based on their serial output: #91 (comment)

edit
That v1.41 dirty build flashes and works!

To other users, be aware that this may not work for V1 derivative boards. The one that I have cannot boot this dirty build, but a real ESPLAY Micro can.

rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:8900
load:0x40080000,len:7392
entry 0x4008039c
I (31) boot: ESP-IDF v3.1-odroid-1-g08f2c8f26 2nd stage bootloader
I (31) boot: compile time 11:33:25
I (31) boot: Enabling RNG early entropy source...
I (37) qio_mode: Enabling default flash chip QIO
I (42) boot: SPI Speed      : 80MHz
I (46) boot: SPI Mode       : QIO
I (50) boot: SPI Flash Size : 16MB
I (55) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (73) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (80) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (88) boot:  3 firmware         factory app      00 00 00010000 00040000
I (95) boot:  4 launcher         OTA app          00 10 00050000 000e0000
I (103) boot:  5 retro-core       OTA app          00 11 00130000 000e0000
I (110) boot:  6 prboom-go        OTA app          00 12 00210000 000c0000
I (118) boot:  7 gwenesis         OTA app          00 13 002d0000 000f0000
I (126) boot: End of partition table
I (130) esp_image: segment 0: paddr=0x00050020 vaddr=0x3f400020 size=0x2bc00 (179200) map
I (186) esp_image: segment 1: paddr=0x0007bc28 vaddr=0x3ffb0000 size=0x03794 ( 14228) load
I (190) esp_image: segment 2: paddr=0x0007f3c4 vaddr=0x40080000 size=0x00c54 (  3156) load
I (194) esp_image: segment 3: paddr=0x00080020 vaddr=0x400d0020 size=0x9a418 (631832) map
I (368) esp_image: segment 4: paddr=0x0011a440 vaddr=0x40080c54 size=0x10c1c ( 68636) load
I (390) esp_image: segment 5: paddr=0x0012b064 vaddr=0x50000000 size=0x00010 (    16) load
I (401) boot: Loaded app from partition at offset 0x50000
I (401) boot: Disabling RNG early entropy source...
E (414) spi_flash: Detected size(4096k) smaller than the size in the binary image header(16384k). Probe failed.

assert failed: 0x400d311a

Backtrace:0x40081662:0x3ffe3bc0 0x4008b249:0x3ffe3be0 0x40090736:0x3ffe3c00 0x400d311a:0x3ffe3c40 0x40081239:0x3ffe3c70 0x40078d99:0x3ffe3ca0 |<-CORRUPTED

Stock ESPLAY Firmware

rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:8900
load:0x40080000,len:7392
entry 0x4008039c
I (31) boot: ESP-IDF v3.1-odroid-1-g08f2c8f26 2nd stage bootloader
I (31) boot: compile time 11:33:25
I (31) boot: Enabling RNG early entropy source...
I (37) qio_mode: Enabling default flash chip QIO
I (42) boot: SPI Speed      : 80MHz
I (46) boot: SPI Mode       : QIO
I (50) boot: SPI Flash Size : 16MB
I (55) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (73) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (80) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (88) boot:  3 firmware         factory app      00 00 00010000 00040000
I (95) boot:  4 retro-esp32      OTA app          00 10 00050000 00100000
I (103) boot:  5 esplay-nofrendo  OTA app          00 11 00150000 000a0000
I (110) boot:  6 esplay-gnuboy    OTA app          00 12 001f0000 000a0000
I (118) boot:  7 esplay-smsplusgx OTA app          00 13 00290000 00140000
I (126) boot: End of partition table
I (130) esp_image: segment 0: paddr=0x00050020 vaddr=0x3f400020 size=0x1e294 (12                                 3540) map
I (171) esp_image: segment 1: paddr=0x0006e2bc vaddr=0x3ffb0000 size=0x01d54 (                                   7508) load
I (174) esp_image: segment 2: paddr=0x00070018 vaddr=0x400d0018 size=0x33adc (21                                 1676) map
I (234) esp_image: segment 3: paddr=0x000a3afc vaddr=0x3ffb1d54 size=0x07788 ( 3                                 0600) load
I (243) esp_image: segment 4: paddr=0x000ab28c vaddr=0x40080000 size=0x00400 (                                   1024) load
I (244) esp_image: segment 5: paddr=0x000ab694 vaddr=0x40080400 size=0x11f30 ( 7                                 3520) load
I (288) boot: Loaded app from partition at offset 0x50000
I (288) boot: Disabling RNG early entropy source...
I (289) spiram: Found 64MBit SPI RAM device
I (293) spiram: SPI RAM mode: flash 80m sram 40m
I (298) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (306) cpu_start: Pro cpu up.
I (309) cpu_start: Application information:
I (314) cpu_start: Project name:     retro-esp32
I (319) cpu_start: App version:      1.1-esplay-micro-15-g23762c4-di
I (326) cpu_start: Compile time:     Oct 28 2019 09:19:44
I (333) cpu_start: ELF file SHA256:  f82dddf1da9ed71f...
I (338) cpu_start: ESP-IDF:          v3.3-beta3-131-g8decc05ee-dirty
I (346) cpu_start: Starting app cpu, entry point is 0x40081520
I (337) cpu_start: App cpu up.

[Takiiiiiiii]

Were you able to flash a Retro-Go .img on your V1 directly, without using the bootloader?

I am unsure of how to do this. Do you use Flash_Download_Tool/esptool?

[ducalex]

To other users, be aware that this may not work for V1 derivative boards. The one that I have cannot boot this dirty build, but a real ESPLAY Micro can.

I'm not sure this is a retro-go issue (at least based on the logs you provided). In the first log, boot fails because the bootloader expected to find a 16MB flash chip but found a 4MB instead.

This is likely because the bootloader/firmware was configured for 16MB flash at build time, and you didn't override that during flashing.

If flashed correctly, this line:

I (50) boot: SPI Flash Size : 16MB

should become:

I (50) boot: SPI Flash Size : 4MB

I think for esptool you just have to use --flash_size 4MB. In the gui tool there's a size selector and also a checkbox to uncheck I think.

Just to be clear: This could still be a retro-go issue because clearly the same bootloader works when a different .fw is flashed? Retro-Go is configured for 16MB flash but I'm almost sure that the flash size info isn't preserved in the .fw format, so I'm not sure what's going on.