Feature Request: "Super Resolution" input support

[cg-alves]

A lot of projects have recently been appearing with the aim of using low powered devices (like Raspberry Pi) to emulate systems and display them on CRTs via RGB or Y/Pb/Pr. These devices usually use the GPIO pins and custom timings to display a sort of "Super Resolution" (1920x240, 1792x239, etc.) which circumvents a lot of the inherent limitations of the SoCs present in these devices. While these have no problem displaying on a CRT and even the very cheap "SCART to HDMI" devices, the OSSC doesn't appear to like the signal, presently (audio works, but no sync/video).

The main use for such a feature (given that most of these devices natively output HDMI), would be for the purposes of streaming/capturing the video output while simultaneously playing on a CRT (e.g. Pi video goes into SCART Buffer, goes to both CRT for playing and OSSC for capturing).

The specific timings used vary a little on a device by device and system by system basis, but since most of the timings are listed on CRTPi and RGB-Pi's github pages, it should hopefully not be too much trouble to figure out what they're doing exactly.

[marqs85]

I doubt the timings are the issue here - horizontal resolution doesn't really matter as it just ends up as analog signal which gets sampled. The problem more likely is in the way sync is generated (H/V or composite sync, odd/even indicator usage, irregularities etc.), I'll need to check more details and see if there are oscilloscope captures of the signals.

[cg-alves]

Thanks for looking into this! I'm fairly certain that the RGB Pi uses csync (the dev claims as much, anyway), and Mike Chi's RetroTink Ultimate did too. He open-sourced the design, which might provide some insight as to how these hats generate their sync signals. I don't have an oscilloscope to read my RGB Pi, but I'm willing to donate you one if necessary.

[Trun0Jay]

While these have no problem displaying on a CRT and even the very cheap "SCART to HDMI" devices

Could you show me which SCART to HDMI devices do recognise a Pi running super resolutions? I'd like to get one in the meantime.

[cg-alves]

While these have no problem displaying on a CRT and even the very cheap "SCART to HDMI" devices

Could you show me which SCART to HDMI devices do recognise a Pi running super resolutions? I'd like to get one in the meantime.

The black metal box ones seem to be a little better than the others, and that's what I'm using. Here's a couple of shots of mine.

[marqs85]

Haven't had a chance to look into these issue yet, but I have a few questions:

1. Does OSSC indicate "NO SYNC" with these 240p modes, or that there is just no picture on display?
2. Does OSSC recognize any mode (480i, 480p etc.) generated via Pi GPIO?

[cg-alves]

Haven't had a chance to look into these issue yet, but I have a few questions:

1. Does OSSC indicate "NO SYNC" with these 240p modes, or that there is just no picture on display?

2. Does OSSC recognize any mode (480i, 480p etc.) generated via Pi GPIO?

1. It displays "NO SYNC" even with lots of tweaking in the Sync options. Occasionally audio would cut in for a split second, but 99.9% of the time there's just nothing.

2. My previous SCART buffer died, so I can't really test anything outside of the standard (presumably 240p) mode for the menu. I ordered a new one, so I'll be sure to update the issue when it comes in.

[cg-alves]

After some thorough testing with the new SCART buffer, I can confirm that none of the modes are recognized by the OSSC.

[marqs85]

Ok, maybe the title should be changed accordingly as it seems the issue is not related to Super resolutions.

Do you have more details on the sync combiner circuit RGB Pi uses? Maybe you could open the connector and take a photo. Also, have you tested it directly without the scart buffer?

[cg-alves]

Not sure what to rename it to, to be honest. It seems related to how the Pi is being hacked to generate the signal. I opened the connector, but there doesn't seem to be much going on there.

Yes, I tried it without the buffer, but the result is the same. It's the one from js-technology, so it shouldn't make a difference to the signal.

[marqs85]

Could you take a closer photo of the chip shown in first picture, or at least write its markings here? I've now built a fenlogic vga666 adapter and will test it in near future. The only relevant difference is sync generation as RGB Pi uses composite sync, most likely combined using the said chip.

[marqs85]

I've now tested vga666 module hooked to AV3 RGBHV with the modelines below:

# 320x240 (jittery)
#hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1
# 1920x240 (unstable)
#hdmi_timings 1920 1 50 250 250 240 1 6 10 6 0 0 0 60 0 38690000 1
# SNES (jittery)
#hdmi_timings 1920 1 160 200 286 224 1 9 8 21 0 0 0 60 0 40410000 1
# VGA 60Hz (ok)
#hdmi_timings 1280 1 32 192 96 480 0 10 2 33 0 0 0 60 0 50350000 1

The signal quality isn't very good for some reason, but I'm getting sync nevertheless. The problem seems to be related to the sync combiner then.

[Sircrab]

I'm also facing this issue, trying right now with a Recalbox and an RGBPi. I'll test the timings described above once I have the time and report back.

[optimusuk]

Any update, findings on this?

[marqs85]

Has anyone tested this with v1.xx firmware revisions? I'd still need to know details of tha cable (sync path) to have any ideas on what could be wrong since vga666 adapter worked OK in my setup. I can only guess sync level is not optimal which could be mitigated by OSSC's Analog sync Vth option.