Skip to content

Beginner, Requesting help in porting to ESP32 WROOM #179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KrishnaAswin opened this issue Jan 18, 2025 · 7 comments
Open

Beginner, Requesting help in porting to ESP32 WROOM #179

KrishnaAswin opened this issue Jan 18, 2025 · 7 comments

Comments

@KrishnaAswin
Copy link

Hi,

I am trying to port the project to an ESP32 WROOM (4 MB flash, 520 KB SRAM). The hardware components I plan to use are:

  • TFT ILI9341 (2.8") display with an SD card reader
  • Tactile buttons for controls
  • 5V power source
  • No audio functionality planned

I have already set up the environment as per BUILDING.md, cloned the repository, and verified the environment by creating a .img file for the esp32s3-devkit. The next step, as I understand it, is to modify the configuration and other files. I have a few questions:

  • Is it possible to port this project to the ESP32 WROOM?
  • If it is possible, where should I start?
  • What changes do I need to make?
  • I am planning to follow the Odroid-Go schematics with minor modifications. Am I on the right track?

I am a beginner, so any advice, recommendations, or instructions would be greatly appreciated.
(Forgot to mention: I am new to GitHub and unsure if the Issues section is the right place to ask for help. I apologize if this violates any community guidelines.)

Thank you!

@rapha-tech
Copy link
Contributor

rapha-tech commented Jan 18, 2025

Hi,
I have personnaly made my own retro-go compatible "console" so here are some advices I can tell you

1°) I think it should be easier to directly go with the ESP32 wrover or ESP32-S3 with at least 2MB of PSRAM. I don't think it would be possible to adapt the firmware to only use 520KB of RAM or it would probably be very uncompatible and very very difficult.
2°) Odroid-go schematic is a very nice start ! I personnaly copied some parts of it ;)
3°) For the screen I would recommend you to go with an "ST7789" IPS screen, TFT ILI9341 visual quality isn't the best and if you can find an 2.8" IPS with ST7789 it would be compatible with retro-go since some people already wrote some code for it !

Anyway, good luck for your port !

@KrishnaAswin
Copy link
Author

Hi, I have personnaly made my own retro-go compatible "console" so here are some advices I can tell you

1°) I think it should be easier to directly go with the ESP32 wrover or ESP32-S3 with at least 2MB of PSRAM. I don't think it would be possible to adapt the firmware to only use 520KB of RAM or it would probably be very uncompatible and very very difficult. 2°) Odroid-go schematic is a very nice start ! I personnaly copied some parts of it ;) 3°) For the screen I would recommend you to go with an "ST7789" IPS screen, TFT ILI9341 visual quality isn't the best and if you can find an 2.8" IPS with ST7789 it would be compatible with retro-go since some people already wrote some code for it !

Anyway, good luck for your port !

Thanks @raphatex ,
But my goal is to make this work with the parts that I already have.

@rapha-tech
Copy link
Contributor

rapha-tech commented Jan 19, 2025

Alright, so here are some recomendations to at least get it to boot:

  • start from odroid-go target and modify the pinout to correspond to yours
  • then do a build of the launcher
  • then go cd into your launcher folder
  • type the command "idf.py menuconfig"
  • on this menu find the flash size and modify it from 16mb to 4mb
  • also find the settings for the external ram and disable it
  • now exit with escape and save (y)
  • you fill find a new sdkconfig file in your launcher folder, copy it to the target folder (odroid-go)
  • delete the build folder inside the launcher folder
  • and you can build retro-go again ! (Don't forget to cd back into retro-go
  • you can't put all the apps on 4mb so for example you can drop Genesis or msx

@KrishnaAswin
Copy link
Author

@raphatex, thank you for the detailed instructions!

I have a couple of additional questions:

  • Would removing the audio from the firmware help make the build lighter?
  • Are there any other modifications you’d recommend to optimize the system for my hardware constraints?

I do have a few more questions in mind, but I think it’s best to address them after I’ve implemented your suggestions. I’ll follow up with an update soon. Once again, Thank you for all the recommendations!

@rapha-tech
Copy link
Contributor

rapha-tech commented Jan 19, 2025

Yes of course disabling audio can free up some space but more importantly ram !
You can also disable networking at build time I think

@ducalex
Copy link
Owner

ducalex commented Jan 26, 2025

I think rapha-tech gave you good advice, you should ignore fmsx, gwenesis, prboom (delete them in rg_config.py) because they simply will never work without PSRAM anyway.

Here's a few additional ideas of where you can reduce memory usage:

branch

Use the dev branch, I have made changes over the past year that allow retro-go to work better in a low memory environment and that isn't in master yet.

retro-core double buffering

Most emulators in retro-go use double buffering but each framebuffer is big (50-150KB) and you can't possibly fit two in internal memory and still have enough memory for the rest. The best way to get rid of double buffering is a bit beyond my comment and will vary by app, but one thing you could try to get started is to allocate a single buffer and alias it.

For example in main_nes.c you will find:

    updates[0] = rg_surface_create(NES_SCREEN_PITCH, NES_SCREEN_HEIGHT, RG_PIXEL_PAL565_BE, MEM_FAST);
    updates[1] = rg_surface_create(NES_SCREEN_PITCH, NES_SCREEN_HEIGHT, RG_PIXEL_PAL565_BE, MEM_FAST);
    currentUpdate = updates[0];

and you could replace it with:

    updates[0] = rg_surface_create(NES_SCREEN_PITCH, NES_SCREEN_HEIGHT, RG_PIXEL_PAL565_BE, MEM_FAST);
    updates[1] = updates[0];
    currentUpdate = updates[0];

(you will find similar lines in all emulators)

retro-core static memory

Each emulator that is part of retro-core "wastes" 1-10KB even when it's not in use, because of static allocations. I suggest you get rid of all emulators that you don't (or can't) run on your setup. Simplest way to remove an emulator is to comment its two lines (the if (strcmp) ... xxx_main()) in retro-core/main/main.c.

launcher framebuffer

The launcher uses a big framebuffer (150KB) to draw itself but it can technically work without one, it will just be very flickery. I haven't tested it recently, but I think it can be as simple as commenting this line in launcher/main/gui.c:

gui.surface = rg_surface_create(gui.width, gui.height, RG_PIXEL_565_LE, MEM_SLOW);

networking

Building with --no-networking is a good idea, the wifi stack does waste a lot of memory even if you don't connect it. This will only help the launcher, though.

sound

Disabling sound is a bit complicated because most emulators are tightly coupled to their sound emulation, and also retro-go uses sound hardware to synchronize emulation speed. The most you'll save if you entirely get rid of sound (emulation and playback) is about 10-12KB. In my opinion there are easier changes to do before that.

@KrishnaAswin
Copy link
Author

Thanks @ducalex ,
I will try that and return with an update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants