Raspberry Pi Composite (3.5mm) output broken

[jayare5]

There was a PR that was expected to fix it here but it didn't seem to work:

https://github.com/libretro/Lakka-LibreELEC/pull/1273

@dmrlawson, I tested both Pi3 and Pi4 (with enable_tvout=1) and they don't work. However, I know they're outputting something because the TV detects the signal, but it's black. Using sdtv_mode=16 actually works, and gives a 240p signal, so I know the Pi4 has enable_tvout working, but it's all black.

Thanks!!

[kFYatek]

I've pushed my dirty PoC to my fork of the repo: it's tagged as 480p-poc, the commit is 8c4fc3c. It's based on the current state of that raspberrypi/linux#4406 PR.

It is intended to give you a clear "fake 480p" picture with sdtv_mode=16/sdtv_mode=18. ***NOTE: It intentionally breaks all other modes, including HDMI***, so proceed with caution.

the games we play with this are already basically line doubled (games are 240p, integer scaled to 480p, and then line halved again on the TV) so it shouldn't be a difference there!

The reason why I was a bit skeptical is that, if an emulator displays the doubled lines at, say, y=0 and y=1, and then y=2 and y=3 and so on, there will indeed be no difference. But if instead it displays those doubled lines at y=1 and y=2, then y=3 and y=4 and so on - they will be all blurred instead. I don't know if any emulator could align the image like that, it's just a possible corner case that I thought of.

The lines being averaged sounds like it might even produce a nicer image whenever higher quality assets are shown (like in RetroArch menus).

This is probably true, though.

Additional note: with hardware scaling, it could also be possible to scale the image up, i.e. set something like 352x240 as the display mode, so that the aspect ratio is more or less correct, but there is no downscaling. I don't know if that would be interesting for you, just noting.

[HiassofT]

There's no need to hack up the driver, DRM/KMS already supports scaling and you can set up framebuffers with different size than the CRTC output resolution if you want.

This gives you full control over what's happening in the output pipeline, automatic up- or down-scaling may not always be what you want (eg you might prefer to render to a 360x240 framebuffer and let DRM output that at 720x240).

Kodi uses that to up-scale the GUI to 4k on RPi4 and other SBCs (the GPU isn't powerful enough for smooth 4k GLES, so the GUI plane is limited to 1920x1080) and to scale videos to screen output size (eg playing 4k or SD content on a HD monitor).

[kFYatek]

@HiassofT That's true - but the real question is whether RetroArch and other emulators support doing that.

If not, it might be actually easier to add implicit scaling to the driver instead of patching all the userland software, especially considering that it's how the firmware modes worked since forever...

[HiassofT]

While it might be easier short term to carry over the old workaround it would be a lot better to implement that properly (if retroarch etc don't support it yet).

DRM will tell you the exact output resolution and should also report the picture aspect ratio which you can then use to calculate the output pixel aspect ratio and set up a proper scaling pipeline for emulator output so the picture won't be squashed or stretched.

While the usual PC/TV monitor modes nowadays have square pixels, that isn't true for PAL/NTSC modes (which could even be anamorphic 16:9) and even less true for 1980-era game consoles and home computers.

So to properly display emulator output on old and new monitors using correct aspect ratios a scaling pipeline has already to be set up and adding another step that involves lossy downscaling and is always happening in the background doesn't really help to get accurate output.

[jayare5]

@kFYatek

the games we play with this are already basically line doubled (games are 240p, integer scaled to 480p, and then line halved again on the TV) so it shouldn't be a difference there!

The reason why I was a bit skeptical is that, if an emulator displays the doubled lines at, say, y=0 and y=1, and then y=2 and y=3 and so on, there will indeed be no difference. But if instead it displays those doubled lines at y=1 and y=2, then y=3 and y=4 and so on - they will be all blurred instead. I don't know if any emulator could align the image like that, it's just a possible corner case that I thought of.

Ah, I can tell you that this is the least of my worries :P RetroArch is full of video configs, moving the image 1 pixel up or down to make it align with the sharp line is the easiest thing to do! And it saves that location value so games always boot properly scaled / placed.

Additional note: with hardware scaling, it could also be possible to scale the image up, i.e. set something like 352x240 as the display mode, so that the aspect ratio is more or less correct, but there is no downscaling. I don't know if that would be interesting for you, just noting.

That's good to know! But in reality i've found the downscaled approach to be more ideal because horizontal scaling needs to be higher res to stretch horizontally without noticing blurred pixels too much, like stretching 256 to around 640 or more.

It is intended to give you a clear "fake 480p" picture with sdtv_mode=16/sdtv_mode=18. NOTE: It intentionally breaks all other modes, including HDMI, so proceed with caution.

When you say break, does that mean that using HDMI could harm a TV? Or does it just simply mean I can use it and it will look like a weird 480p resolution?

Also, is there no way to ignore any of those sdtv commands like sdtv_mode=16 / sdtv_mode=18 (and maybe others) if HDMI is detected? Luckily I mainly use a CRT and rarely switch between it and HDMI, but I can put up with having to change the config.txt if I need to switch to HDMI for the time being.

@HiassofT

There's no need to hack up the driver, DRM/KMS already supports scaling and you can set up framebuffers with different size than the CRTC output resolution if you want.

Does this mean that HDMI does not have to be broken if using SDTV commands?

[kFYatek]

When you say break, does that mean that using HDMI could harm a TV? Or does it just simply mean I can use it and it will look like a weird 480p resolution?

No, it won't break a TV. By broken, I mean that all other modes will probably display a squashed image on only the upper half of the screen, or (less likely) some other form of distorted output. The signal itself should be reasonably formatted - just with garbage contents.

Besides, I don't think breaking an HDMI TV is that easy ;)

Also, is there no way to ignore any of those sdtv commands like sdtv_mode=16 / sdtv_mode=18 (and maybe others) if HDMI is detected? Luckily I mainly use a CRT and rarely switch between it and HDMI, but I can put up with having to change the config.txt if I need to switch to HDMI for the time being.

I'm fairly sure that this is the case right now, with any "normal" kernel (i.e. not that PoC of mine I linked), at least with full-KMS. What problems do you encounter exactly?

[jayare5]

When I use fkms, I've noticed frame tearing sometimes. Does not happen when I don't use fkms. I assume this could mean using fkms is not really recommended in the long term, I do not know what other problems may arise.

I've found some other issues as now i've been playing more since we're talking about it:

Latency is a bit hard to measure, but I find that RetroArch's low latency options don't seem to have much satisfying results when using fkms. Something always feels laggy, whereas with kms I feel like this is the low latency I expect. It could be just me though.

[jayare5]

@kFYatek So I was able to build an image (with the help of @dmrlawson, thanks a ton!!!!) And I've finally tested the 240p stuff :D It is perfect! I actually looked for those differences you mentioned where if it's 1 pixel off vertically, it would blur, it behaved like that so that is confirmation I tested your patch. And yes that "side effect" is absolutely fine, having line averaging is great, it does make the menu look a little better just like how I thought too! It does not affect the way games look at all, so this is good with me! I accept this as the new 240p behavior!

[ToKe79]

@kFYatek thank you for your work! I have added the PoC patch into our tree (we patch the kernel at build time of the OS). I have also updated the original patch for the PR.

@jayare5 thank you for the test! Next nightly build should now work as expected. Please, be so kind and confirm - I will bump this thread once the nightly build with the below commit is available.

https://github.com/libretro/Lakka-LibreELEC/commit/2f3e7f98e72b1a688f6e3e2045477ace3573b079

[kFYatek]

@jayare5 @ToKe79 I'm glad that it works for you! However, I just want to remind you that the 240p patch is just a PoC and not intended for anything beyond initial testing whether it produces an acceptable output. Using it for regular builds is not a good idea - it will break video output in all other cases.

I plan on evolving this idea further so that proper mode switching (480i vs. 240p vs. "fake 480p") is possible - probably this week. I will offer that patch to the official repo, but, like @HiassofT said, this whole idea is a hack, so I'm not sure whether anybody would be willing to merge it there - but even if it's not merged into mainline, that upcoming patch will be much more appropriate for incorporating into projects like here instead of the existing PoC.

[jayare5]

@ToKe79 Wait, I thought it was meant for testing purposes only. When testing it, only 240p on a CRT worked properly. Using HDMI was broken.

Sorry that I did not comment about that, as I thought it was intentional for that patch alone to be meant for testing only. (Although, I built using the entire fork of Linux instead of just the patch)

[ToKe79]

Okay, I will revert the patch for 240p then - thank you for noticing me.

[jayare5]

That is a relief! :)

That being said, the future is really looking bright :D Can't wait for the evolved patch!

[kFYatek]

@jayare5 @ToKe79 Check out the composite-scaling branch on my fork: https://github.com/kFYatek/linux/tree/composite-scaling

I have not tested it too thoroughly - didn't check on Pi4, and didn't check HDMI - but it should be what you're looking for. You can switch between 480i, 240p and 480-scaled-to-240p (the same for 576i, 288p and 576-scaled-to-288p for PAL mode). If sdtv_mode=16 is set in config.txt, the default mode will be 480-scaled-to-240p - so overall, this should be as close to the firmware behaviour as possible.

It also adds support for horizontal scaling, so you can try dialing in modes such as 852x480 (the horizontal resolution needs to be a multiple of 4) for 16:9 aspect correction.

Note that when setting non-standard modes, you should set the pixel clock as if it was actually changed, and as if 480p was real 480p - so 27 MHz for that "fake 480p" mode, 16.364 MHz for 16:9 480i (assuming 40:33 PAR) etc.

Like I said, I didn't test it with Pi4 or HDMI yet - will probably do it tomorrow or something - but in theory it shouldn't break anything.

I will post it as a PR to https://github.com/raspberrypi/linux after some more testing, but like I said - I don't have my hopes high for the idea to actually be accepted there.

[jayare5]

Truly appreciate all your work!!!! Thanks so much.

I will be testing each mode for sure this time! (I think the only mode that was usable when I tested was 480-scaled-to-240p)

Btw, what needs to happen for these to be accepted in the raspberrypi/linux?

[ToKe79]

I tested the patches on RPi400 and HDMI works. @jayare5 were you able to test the CRT output? If you need an image for test, you can grab next nightly build, which will include these patches. If it works, we will include the patches in the next release.

@kFYatek thank you for your work!

[jayare5]

@ToKe79 I tested the nightly builds, and it all seems perfect!!

I have a Pi3B+ and a Pi4. Both can now do 240p on a CRT and proper HDMI when editing the configs accordingly! There are no glitches or issues as far as I could test on either board / config. I can live live this now, unless there are plans in the future for both modes to work without having to edit the config?

Here are some notes just to make sure. • On a Pi3, all I have to do is:

In cmdline.txt (after 'quiet ' with space included): video=Composite-1:720x480@60ie

With this alone it will be 240p, and commenting that part out will work with HDMI.

---

• On a Pi4, I have to do the following:

In cmdline.txt (after 'quiet ' with space included): video=Composite-1:720x480@60ie

In config.txt enable_tvout=1 dtoverlay=vc4-kms-v3d-pi4,composite=1

(That second line is also in distroconfig.txt, but that file can be ignored apparently and only manage the config.txt for convenience)

Commenting out the part added to cmdline.txt will make it work with HDMI.

[ToKe79]

Thanks @jayare5 - we will create wiki page with your recommended additions to cmdline / config.txt.

[ToKe79]

https://github.com/libretro/Lakka-LibreELEC/wiki/Raspberry-Pi#composite-output

[jayare5]

Looks like very clear instructions to me! :D Glad to see official support

[jayare5]

@ToKe79

Hey so I just found something out now that I've been really testing. video=Composite-1:720x480@60ie this line here, where it ends in ie, the i causes it to go interlaced mode every time the RetroArch "window" is absent. Meaning that between loading games, it will go interlaced for a sec and then progressive again. If I just remove the i, and leave it ending as @60e, it will never switch so it's probably better for the TVs.

@kFYatek

Question, is there a chance that the downscale may be done with the method that isn't line averaging? After testing it more, I found something about the RetroArch menu that doesn't look good with it. I didn't get to test this in particular before, but if the menu is configured to use a pixel art font or icons, it reveals that a lot of menu elements in RetroArch were not made to align with this, so there are things 1 pixel off and will look blurry, and other things will look normal. Everything used to align properly when there was no line averaging :( Sorry for this late discovery... unless someone was willing to move certain things in the RetroArch menu just by 1 pixel so it's fully compatible with this :D

[kFYatek]

@jayare5

Question, is there a chance that the downscale may be done with the method that isn't line averaging?

I'm certain this is technically possible, but TBH I have no idea how to configure the GPU scaler to do that. I tried messing with the vc4_get_scaling_mode() function or overriding its output, but no setting other than VC4_SCALING_TPZ works for downscaling, which is what we're doing here. Looking at the various scaler registers, nothing really rings a bell as to what I could change there, so... sorry. I can't help you further with that.

[burabure]

@jayare5 Thank you so much for all your work on this. I got my lakka pi working over composite with my PVM-8040 thanks to you.

I also noticed that audio over composite/jack doesn't work by default, so I had to set audio_device = "default:CARD=Headphones" on /storage/.config/retroarch/retroarch.cfg

PS: Might want to add this to the wiki/docs also @ToKe79

[jayare5]

@kFYatek @ToKe79 Hi again, I just updated to the latest version of Lakka on both Raspberry Pi 3 and 4, they don't output 240p anymore with the same configs that would have given me 240p just 2 months ago. Has anything changed or broken? It outputs only 480i. Thanks!!

[Ntemis]

Should be fixed soon

[jayare5]

It works now!

[jayare5]

@burabure @eugene-s-nesdev

Hey, I have news, check this out if you're still interested in this! We've made a Lakka branch specifically made for the Composite output of Raspberry Pi, with updated RetroArch + cores!

https://lakka.tv/articles/2024/05/02/rpi-composite/

[eugene-s-nesdev]

Thank you! I will try it soon

[eugene-s-nesdev]

I want to thank you for this build, it's awesome. I've just tested it on RPI3, it looks very nice.

BTW, i have some questions: I still have lakka-2.2.2, and i've configured it for PAL CRT progressive (SDTV_MODE=18) My config: config_for_lakka2.2.2-PAL-CRT.zip

The new 4.x build have complete different configuration schemes, no more config.txt override lines, etc. I've set it to PAL as described here: https://www.lakka.tv/articles/2024/05/02/rpi-composite/ But the xmb/rgui/games have strong flickering on CRT@50Hz, like it work in interlaced (non-progressive) mode.

Which is the most correct way to set progressive (240p/256p) to your build?

Another question: Can anyone compile lastest https://github.com/libretro/Genesis-Plus-GX for RPI2 (lakka 2.2.2) and RPI3 (current 4.x build) targets? Recent lastest-master have a "Force VDP" core option, which is very important for me. I've tested it on x86-64 and it works perfect, but i cannot test on RPI3 due to libretro-buildbots are outdated: https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/ https://buildbot.libretro.com/nightly/linux/armhf/latest/

[jayare5]

@eugene-s-nesdev

If you edit cmdline.txt, Is there no difference between these?

video=Composite-1:720x576@50e

video=Composite-1:720x576@50ie

[jayare5]

@eugene-s-nesdev

Actually, try this. Make a copy of your retroarch.cfg Replace the value of video_refresh_rate into "50.099998" and try loading that file in RetroArch. Thanks!

[eugene-s-nesdev]

Strange thing. I tried almost all your fixes with no luck:

There is no difference between these:

video=Composite-1:720x576@50e
or
video=Composite-1:720x576@50ie

in cmdline.txt

Also i tried to edit "./config/retroarch/retroarch.cfg" for set "50.099998" in the video refresh rate. When no luck, i've edit retroarch-overrides.txt too, for set "50.099998" instead of "50.000000" - it doesn't help too.

GUI and games still have a small shake/jitter, like it using interlaced mode. If you're want, i can upload lakka 2.2.2, which doesn't have this issue, so you can check it on your end too.

[jayare5]

@eugene-s-nesdev

Im sorry to hear!

1. Make sure cmdline.txt has the line ending in "e" and not "ie" again after that test.
2. Editing retroarch-overrides.txt will only work the first time you boot after flashing and before resizing process! You're supposed to edit the actual retroarch.cfg. But you need to make a copy so that you can edit it or else RetroArch will not let you save changes, make the edit to the copy, and then load it from RetroArch.

We will fix this for an update, Im very sorry! The problem is when we tested this the first time, it worked with progressive signal, but didn't realize it could have been interlaced too. But if you fix it like that, it should work :)

[eugene-s-nesdev]

Lakka 2.2.2 + CRTPI 3.0/3.1 + necessary configs for PAL, enjoy for testing: https://drive.google.com/drive/folders/1HioNAhU5vcYOGwtGRlOkBPnOYA4Tq_qN

[jayare5]

Lakka 2.2.2 + CRTPI 3.0/3.1 + necessary configs for PAL, enjoy for testing: https://drive.google.com/drive/folders/1HioNAhU5vcYOGwtGRlOkBPnOYA4Tq_qN

Hah, I got it to work! Yup, it does give me the same result as what I can get from the new build! Please try these instructions from my last post.

[ToKe79]

@eugene-s-nesdev : just to be clear - editing retroarch.cfg while RetroArch is running is worthless - RetroArch (unless configured not to save settings on exit) will overwrite your changes. Therefore either stop RetroArch before editing (systemctl stop retroarch) or use a copy of current config as @jayare5 wrote.

[eugene-s-nesdev]

@jayare5, did you tried new build on RPI3b+, or you using another RPI device? Yes, i got it to work without flickering now, using 50.099998 referesh rate and video=Composite-1:720x576@50e at the same time. It works very good. Image is clear without flickering now, thank you. Note for this build (in the case of NES) you're need to set horizontal/vertical overscan to 0 in the all NES core options for getting clear pixels.

[eugene-s-nesdev]

I've re-flashed it from scratch to RPI3B+ using lastest instructions:

cmdline.txt:
change video=Composite-1:720x480@60e to video=Composite-1:720x576@50e
remove vc4.tv_norm=NTSC-J

retroarch-overrides.txt: (after flashing the image and before the first boot)
add a new line with text video_refresh_rate = "50.099998"

and didn't touch any other settings. It works correct, i can confirm it.

important note: Still need to edit "./config/retroarch/retroarch.cfg" for set "50.099998" in the video refresh rate, otherwise it will switch to 50.000000 automatically after loading any game causing flickering.

[ToKe79]

Unfortunately I can currently test only on HDTV composite input, not real CRT (both are broken), so can't tell if it is really switching back to 576i or not, but the menu looks blocky, as "288p". With 576i it was looking much smoother, mostly the menu icons (speaking of xmb). And there were shimmering artefacts in 576i. Also the HDTV might be doing some post-processing, so it is really hard to tell. But thank you for your tests!

@jayare5: maybe we could add video_refresh_rate = "50.099998" to all core overrides?

[ToKe79]

@eugene-s-nesdev I might have a solution but you will not like it.

First of all you must enable Show save game overrides (Settings - User Interface - Menu Item Visibility - Quick Menu - Show 'Save Game Overrides' - ON.

Then load your PAL game, open quick menu.

Go back to Settings - Video - Output - Vertical Refresh Rate - change it - just push left or right once to change it by a 1/1000.

Go back to quick menu, go to Overrides - Save Game Overrides.

You can close the game.

Edit the override file - it will be in

• ssh: /storage/.config/retroarch/config/<core>/<game>.cfg
• network share: \\lakka\Configfiles\retroarch\config\<core>\<game>.cfg

Correct the refresh rate to 50.099998.

Try to load the game again.

While I was testing this I observed following: 1) RetroArch displays refresh rate up to 3 decimal places, so upon start it showed 50.100 Hz (rounded value from config) 2) After I ran a PAL game and checked refresh rate again, it was still 50.100 Hz 3) kmsprint -m shows this output:

Connector 1 (50) Composite-1 (connected)
   0 720x576@50.08     27.000 720/20/64/60/?     576/4/6/38/?       50 (50.08) P|D
   1 720x576i@50.00    13.500 720/20/64/60/?     576/4/6/39/?       50 (50.00) U|D
   2 720x288@50.08     13.500 720/20/64/60/?     288/2/3/19/?       50 (50.08) D

This means that if the requested refresh rate is closer to 50.0 Hz, maybe then the interlaced mode gets selected. Maybe the cores request exactly 50 Hz, therefore the interlaced mode is selected. Hopefully the game override will fix this switching.

If you do not want to do this per game, then you can place all PAL roms in one folder (maybe subfolders per system) and add overrides based on content folder. The steps would be the same as above, but you would have to do this for at least one game of that folder and should work for each game in that folder. And instead of Save Game Overrides you will select Save Content Directory Overrides and the name will be <folder>.cfg (instead of <game>.cfg), where the folder would be the name of the "deepest" folder, i.e. for path /storage/roms/PAL/SegaMD it will be SegaMD.cfg.

But we are still iooking into other ways how to avoid using the interlaced mode. If you have any ideas, we are open to hear from everybody.

[eugene-s-nesdev]

Personally i prefer to keep all settings hardcoded, and don't let the cores to change frequency/resolution. You can use 2 separate builds (2 microSD-Cards) for NTSC and PAL, like CRTPI-RCA project has.

Anyway, current build works stable for me, and it doesn't change the frequency. For now i can run almost all NES-library in forced PAL mode (using Dendy-timing for NTSC ROMs and PAL-timing for PAL ROMs).

Recent GenesisPlusGX core has "VDP mode" option, which can run almost all gen/smd games (doesn't matter NTSC or PAL ROMs) in forced PAL-mode too, without region-lock. I'm waiting when it will compiled for RPI3-target.

What's happened to libretro-buildbot for armhf/armv7-neon-hf? It was updated in 2020 last time.

[ToKe79]

@eugene-s-nesdev I understand, we all have different preferences. From all my tests I made with NES and SEGA roms, running a rom for PAL region ("50 Hz") kept the refresh rate at 50.080, that means the progressive mode (interlaced mode gets selected when the refresh rate drops below 50.040 Hz).

We have released an update and also updated the instructions for PAL here https://lakka.tv/articles/2024/05/02/rpi-composite/#pal-users

As next step we will check at every boot what parameters are in the cmdline and based on that we will update retroarch.cfg with compatible settings, so one SD card can be used on both - NTSC and PAL - CRT TVs just by editing cmdline.txt.

We have also updated all cores in the images, including GenesisPlusGX, to the latest commits in their respective repository.

To your other questions: I don't think we would be able to provide updated cores for any 2.x or 3.x release - because of limitations of our build environment. What we can try to do is to add support for RPi2 to the composite branch. Would you be interested to help with the development and testing?

Regarding the buildbot - this question I cannot answer. Maybe there were some issues with cross-compiling? Not sure, just guessing.

[eugene-s-nesdev]

We have also updated all cores in the images, including GenesisPlusGX, to the latest commits in their respective repository.

It's very nice, i will test it right now. Thank you.

To your other questions: I don't think we would be able to provide updated cores for any 2.x or 3.x release - because of limitations of our build environment. What we can try to do is to add support for RPi2 to the composite branch. Would you be interested to help with the development and testing?

Yes, i'm very inerested. I'm 100% remember that last stable 2.x release that has perfect-working composite was 2.2.2, and since 2.3x it was broken. The 3.x-branch also have some composite problems. I don't tested it deeply, and still using 2.2.2 on my RPI3B+. So, it will be nice if i can get fresh cores (i.e. genesisplusgx with "force VDP" option) for it. As i know, 2.2.2 was compiled for RPI2-target, so i can update cores manually, if they will be avaliable for RPI2.

Regarding the hardware for testing: i have two RPI3B+ devices, that's all. So i can't test anything on a real RPI2/4/5 hardware.

[ToKe79]

In that case - you don't need RPi2 build, as in 2.x and 3.x branches, RPi2 image was meant for both - RPi2 and RPi3. Now we have dedicated image for RPi3. Give it a try and if you find anything not working for you, we will try to fix it.

and maybe to take this discussion to more suitable platform - you can join us on discord - check lakka.tv website - there is an invite link to libretro discord server in the footer.

and just to clarify - I was under impression you are using RPi2 2.x build on RPi2 device, hence I suggested adding support for RPi2 in the composite branch :-)

[eugene-s-nesdev]

Yes, thank you, i will join to discord-channel soon. I've re-flashed new image now and it works very good. BTW, fresh genplusgx-core (f9f16d7) https://github.com/ekeeke/Genesis-Plus-GX/commits/master/ still don't have "force VDP" option yet, but it will be merged soon from here: https://github.com/libretro/Genesis-Plus-GX/commits/master/

[jayare5]

@eugene-s-nesdev That is awesome news for PAL!! 😄 Thanks for testing. I hope you can finally move on to this newer build, as I too had been using an old build for years.

[ToKe79]

yes, we are using the upstream repository, hopefully the feature you need from the libretro fork will be merged soon in upstream.

[eugene-s-nesdev]

Thank you. I'm testing new build right now, and i'm very happy to see anything works like a charm. For my taste the best NES settings for this build on CRT PAL TV are: to set all NES core options to 4:3 and no overscan.

[eugene-s-nesdev]

hunterk has compiled lastest gpgx core for current RPI3-target (thanks discord!) I'm glad to test it on real CRT. It works prefectly: https://github.com/hunterk/libretro_builds/releases/download/Linux_aarch64/genesis_plus_gx_libretro.so.zip

If you're want to run any Genesis/Megadrive game in forced PAL mode, without region-lockups, try these settings: [core options] -> [system] ->

• system hardware = "auto" (this is default value)
• system region = "auto" (this is default value)
• force VDP mode = "50Hz"

[gouchi]

What's happened to libretro-buildbot for armhf/armv7-neon-hf? It was updated in 2020 last time.

Arm platforms has not been yet added to the new CI/CD but there have been an attempt for aarch64.

If needed also armv7-hf-neon.