retro-go
retro-go copied to clipboard
What's the status of the Retro ESP32 target?
I know that the account behind its stock firmware occasionally contributes, but it doesn't seem like anyone's building firmware images for it. I ask because there's definitely a number of these out in the wild (they were in stock as recent as November at https://www.tindie.com/products/handheld-gaming/retro-esp32/ ) and it would be nice to support them if the target is mature enough.
I can't test any builds for it unfortunately since I sold mine a long time ago. Part of that was because my casemodding skills left something to be desired, but another reason was that its stock firmware felt clunky to me.
I don't have a Retro-ESP32 either and I prefer to only release builds that I can personally test and troubleshoot when needed. But I can see the value in making such builds at least available. So I would be in favour of a separate page listing automatically-generated builds for unsupported targets.
I don't really know what the best option would be to accomplish that. A github action? A second/mirror github project? Something else entirely?
All you need is on github. I got some pcbs from china and built a few. Firmware compiles OK now and works well. There isnt much case modding required either. Just need to file down the sd card slot and print or make a battery holder cart.
I don't have a Retro-ESP32 either and I prefer to only release builds that I can personally test and troubleshoot when needed. But I can see the value in making such builds at least available. So I would be in favour of a separate page listing automatically-generated builds for unsupported targets.
I don't really know what the best option would be to accomplish that. A github action? A second/mirror github project? Something else entirely?
I got some spare HASL pcbs i think.. if you need one let me know and i see what i can do
If I'm not mistaken, the Github Actions thing that automates builds typically requires the person downloading files to be logged into github, right? This would prevent the new updater function from working, unless it's just disabled for nightly builds. I guess I was thinking 32teeth might maintain some binaries since they seemed to be leading the charge for the Retro ESP32 target, but nothing of that sort has happened and even the stock firmware hasn't been updated since 2021.
I've been hosting pre-releace builds of each major release for the GameBox Mini on my fork, with the update downloader configured to match. I could start doing this for the Retro ESP32 as well. I don't know of any community fir the device, but hopefully there's someone out there that could provide feedback if anything needs fixing...
I don't think the updater not working on unsupported targets is a very big deal but I agree it should at least work easily on forks of retro-go.
First thing to fix would be to not have the github repo hardcoded in updater.c. I'm not sure if we should try to be clever and detect it from git remotes or if it should be manually defined somewhere else? But where? rg_config.py? retro-go/config.h? elsewhere?
I fixed the DOWNLOAD_LOCATION for the retro-esp32 (untested, but their README says /odroid/firmware). Feel free to submit a PR or tell me the correct path for the gamebox mini as well!
If I'm not mistaken, the Github Actions thing that automates builds typically requires the person downloading files to be logged into github, right?
Yes. Accessing artifacts is probably possible with an API key but I really don't want to deal with that. For example setting up my local build system to use that semi-secret key isn't so bad but then those automated artifacts wouldn't be able to update themselves because they'd be missing the key.
But pre-releases are probably accessible so we could setup an action in a way that it creates/updates a daily or weekly pre-release. It could contain all targets too. Feel free to look into that, I'm not familiar enough with github actions to quickly set that up.
Yeah, pre-release assets are 100% accessible using the Retro-Go updater as it stands (tested with the GBM binaries) so that would work if wherever firmware files are kept are distinguished from full releases in that way. I agree that /odroid/firmware looks like the correct location for the Retro-ESP32, since that's mentioned both on github and their tindie documentation. As for the GameBox Mini, the path to firmware files is /espmini/firmware
I don't know anything about automating builds on github with actions, but if I happen to find out before you I'll share my findings. :)
Starting with next release I'll be building and uploading for all targets we have (even if they're not fully working). Though I still only test and support ODROID-GO and MRGC GBC.
Not sure if I'll bundle them with the regular release files or create pre-releases alongside yet, but they should hopefully be also visible through the updater.
To sum up: The status is unclear, but for the past couple versions I've been providing a .fw that should work on the Retro-ESP32 device.
If it doesn't, or for any other Retro-ESP32 issue, feel free to re-open or create a new issue!