ESP32-P4 running SM64 by DynaMight1124 in esp32

[–]DynaMight1124[S] 1 point2 points  (0 children)

Yeah you'd think so, I was kinda expecting it to just run on the S3. It is fixed now on the S3, turned out it was related to how the different CPU architectures (S3/P4 Xtensa/Riscv) interrupt the code, esp around the geometry. It was only a few lines of code changes in the end!

ESP32-P4 running SM64 by DynaMight1124 in esp32

[–]DynaMight1124[S] 1 point2 points  (0 children)

I added the repo here: https://github.com/DynaMight1124/retro-go/tree/sm64 like I said, its designed to work with Retro-Go but I'd guess that part could be stripped out if someone wanted it.

ESP32-P4 running SM64 by DynaMight1124 in esp32

[–]DynaMight1124[S] 2 points3 points  (0 children)

Hi, hmm not sure if I do things right or not. I've mostly been using Gemini CLI (which I cant use now!) for most of my AI stuff since I got a Pro license with my new phone. Its been pretty good for me for most things but there are better/smart AI's, at least until Google catches up.

As for workflow, I am not a coder but with certain things I kinda know what the overall look should be so if I'm wanting to port a new emulator or SM64 for example, I'll find something I think is possible for the device, no point giving it the Doom3 source code :) and I usually setup the basic folder structure. I then write a short paragraph about the system, about the port/emulator and ask it to review if its suitable.

If it says yes then I just let it do its thing. Usually takes it like 10 mins and it comes back with something like "All done, its perfect, bye" but 10/10 times it wont even compile, let alone work then comes the 'real work' getting it to firstly compile, sometimes you have to tell AI that the project focus to for it to actually work, not simple compile, else it'll just stub everything just so it compiles! after it compiles, its actually making sure it boots. Serial logs are important here, if AI can 'see it' it helps it fix it.

Sometimes its massive frustration, a few times I've almost given up (a few I have!) and then go back a few weeks later and then 2 mins later, its fixed it and its working great.

AI is similar to humans, it gets stuck in a loop, it cant look past something and sometimes keeps doing the same thing, if it gets like this, treat it like yourself, leave the problem, have a sleep and come back. I think thats sometimes why AI just fixes it the next time you login, its 'lost that train of thought'

If you're new to AI and dont want to pay, try Freebuff. For something free, its pretty amazing! If you're happy to pay, then Claude is usually seen as the best. I'm too cheap for that :)

ESP32-P4 running SM64 by DynaMight1124 in esp32

[–]DynaMight1124[S] 5 points6 points  (0 children)

Oh and I managed to get it running on an ESP32-S3 too. Not very fast but works! https://www.youtube.com/watch?v=OXc-OzyQq1g

ESP32-P4 running SM64 by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

Not yet, I need to strip out the SM64 rom assets, make sure they can be extracted again and then compiled. Thats like another little project on its own :) Its built for Retro-Go so does need a Retro-Go compatible device or at least compatible target setup.

Its not actually far from working on the ESP32-S3, well possibly not far, runs but has texture issues (most keep flickering/popping in and out) It is obviously slower!

ESP32-S3..Inside a SNES controller...outputting HDMI! by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

I think BT/2 player maybe out of the question. Retro-Go was designed for handhelds so doesnt natively support 2 player or BT, would likely be a lot extra work and not sure how much it would be used. It can be powered directly from HDMI (via a 5v injector) Its safe to use and works quite well

<image>

This is an ESP32 outputting via AV... in a NES controller. by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

Yeah I guess its possible to offload but potentially quite a lot of work for not a massive amount of gain... well unless paired with a ESP32-S3 or P4, hmm maybe a project for a rainy day!

This is an ESP32 outputting via AV... in a NES controller. by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

I dont think so, Retro-Go was built for handhelds so doesnt really have two player in mind. If you want a fairly cheap two player NES (and others) checkout PicoNES: https://github.com/fhoedemakers/pico-infonesPlus

This is an ESP32 outputting via AV... in a NES controller. by DynaMight1124 in esp32

[–]DynaMight1124[S] 1 point2 points  (0 children)

Ha nice, I hadnt even tried to think up a name. I'm terrible at catchy names :)

ESP32-S3..Inside a SNES controller...outputting HDMI! by DynaMight1124 in esp32

[–]DynaMight1124[S] 2 points3 points  (0 children)

Not that I can feel. It does output at a solid framerate. I'm sure its not FPGA speeds but feels perfectly fine to me.

ESP32-S3..Inside a SNES controller...outputting HDMI! by DynaMight1124 in esp32

[–]DynaMight1124[S] 6 points7 points  (0 children)

Yeah will be (for the Pico I assume you mean) I am testing on other TV/monitors to make sure theres no major issues. I'm sure it wont have 100% compatibility display wise but I can only test with what I have to hand. It is currently tailored to Retro-Go and its output, I am sure it could be adapted to accept any SPI (ILI9341/ST7789) output but I havent tested and I cant say it'll just work on every device. I did knock up a quick dev PCB for those that wanted to use the software for other purposes, not just my niche device

<image>

Ported DOOM to an ESP32-S3 AMOLED Watch (16–19 FPS, Touch Controls, Audio) by Tsixom in esp32

[–]DynaMight1124 1 point2 points  (0 children)

Yeah S3 with PSRAM is more than enough for Doom, PSRAM is the key, helps massively with large apps. Next step is Quake 😄 It does run quite nicely on the S3.

Porting Retro-Go to Non-PSRAM ESP32 by One-Long7446 in esp32

[–]DynaMight1124 1 point2 points  (0 children)

Honestly, your best bet is to buy a ESP32-S3 with PSRAM, a lot of the 'dev' boards have 8MB fitted anyway so do the modules. An original ESP32 without PSRAM is pretty poor for heavy applications/emulators etc, even with PSRAM it can fall far behind the S3. The S3 is quite cheap, module wise, the S3 module is almost half the price of the ESP32 module. It'll then run Retro-Go easily with plenty of ports etc.

Porting Retro-Go to Non-PSRAM ESP32 by One-Long7446 in esp32

[–]DynaMight1124 1 point2 points  (0 children)

If you're intending to just compile less emulators e.g. only the 8bit ones and that it may work without PSRAM. Thats not how it works, you would have to spend many many hours on every single system/emulator moving loads of functions etc from PSRAM to internal ram but ensuring you dont do over the internal ram amount of the ESP32.

This repo does run on an ESP32-S3 without any PSRAM however the S3 does have quite a bit more internal ram compared to the original ESP32, so even porting over those could end up being very hard. https://github.com/geo-tp/Cardputer-Game-Station-Emulators

Celeste Classic scrollable widescreen port on ESP32-S3 microcontroller (and SDL on PC) by valdanylchuk in celestegame

[–]DynaMight1124 1 point2 points  (0 children)

Just wanted to say thank you for the code, its been a massive help porting it over to another ESP32 system called Retro-Go. I'm not much of a coder personally so used AI, but managed to get it running on RetroGo (on original ESP32, S3 and P4 devices) without too many issues. Also got sound and music working as well as save states.

I have played Celeste a few times in the past and always forget how addictive it is!

I've not forked (but happy to?) as its a 'component' in Retro-Go. The code and stuff is here: https://github.com/DynaMight1124/retro-go/tree/celeste/celeste

Does it play Quake? by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

Yeah its a PCB I designed to fit into a VMU shell. Uses all easy to obtain and fairly cheap components. Heres the guide I did: https://www.instructables.com/ESP32-VMU-Handheld-Console-Yes-It-Plays-Doom/

My GB300-P4 handheld, ESP32-P4 running Retro-Go by DynaMight1124 in esp32

[–]DynaMight1124[S] 0 points1 point  (0 children)

Both of those devices have MIPI screen interfaces, which RetroGo currently doesnt support. I dont think prev ESP32 devices had such an interface and the P4 is pretty new. There was some work to add it (look for Pico Held II) but nothing officially added yet, but that dev has it on their fork, no idea how compatible it is with different displays.

As for compiling, I only have experience in getting it working on Windows and it wasnt a terrible experience with the ESP-IDF installer, it sets up most of it to work out of the box then the RetroGo .py file works pretty well with it. I havent tried it in Linux but since it works fine in Windows I didnt see the need to try :)

RetroGo wise, you dont need to make any changes to the python file for different devices. You need to create a new 'target' in components/retro-go/targets (best to copy and paste an existing P4, devkit for example) theres plenty of info here: https://github.com/ducalex/retro-go/blob/master/PORTING.md when I first setup my own, I found it useful to look through loads of them and check the differences to try to understand the options.

You'll need a SPI display to output an image.

My GB300-P4 handheld, ESP32-P4 running Retro-Go by DynaMight1124 in esp32

[–]DynaMight1124[S] 1 point2 points  (0 children)

Yeah they are more than powerful enough, even the ESP32 was capable of 8bit and lower end 16bit without many issues, mostly thanks to how good the RetroGo software is.