Auto sync mode selection

[gruntbuggly]

In order to play a game in 480p mode on the Playstation 2, for example OutRun 2006, I have to do the following:

1. Start OSSC in 480i mode (#1 on the remote for RGBS)
2. Start the game, then instruct it to switch to 480p
3. On the OSSC, switch to 480p (#4 on the remote for RGsB)
4. In the game, press a button before the time runs out to confirm that it’s working

It would be nice if the OSSC could eliminate the need for step 3 by switching automatically when it sees the RGsB signal on the SCART input. It doesn’t affect gameplay and so it doesn’t need to be quick like switching between 240p and 480i, so anything under 3 seconds should be good.

[BuckoA51]

I don’t think this is possible to auto detect. As an alternative you could use an extron interface or similar to convert sync on green to RGBS.

[gruntbuggly]

With 480i content (RGBS #1), the OSSC says “NO SYNC” when it’s in RGsB (#4) or YPbPr (#7). Then with 480p content (RGsB #4), the OSSC says “NO SYNC” when it’s in RGBS (#1) mode, but in YPbPr (#7) mode it shows an image but with the wrong colors. I think this is the issue that is impossible to auto detect: how would it choose between RGsB or YPbPr?

But if I could tell the OSSC to exclude YPbPr (#7) from auto sync mode selection, then conceptually it seems like it should be able to switch automatically between RGBS (#1) and RGsB (#4) modes, unless there are underlying technical issues.

[marqs]

It’d be possible to automatically cycle inputs e.g. after 1 sec of sync inactivity. However, the list of cyclable inputs would need to be user-defineable, so that each one of the 9 inputs/modes can be included/excluded separately so that e.g. RGsB and YPbPr don’t get mixed as mentioned. In the end, I’m not sure if the end result would be that helpful taking into account the configuration effort required from user, but I’ll put this into consideration nevertheless. For PS2, the best way to remove this annoyance is to mod it to output RGBs regardless whether it is in HD mode or not.

[gruntbuggly]

For PS2, the best way to remove this annoyance is to mod it to output RGBs regardless whether it is in HD mode or not.

I’ve ordered the retrogamingcables.co.uk SCART cable with csync for PS1/PS2/PS3 and will report back with the results in a few weeks.

[gruntbuggly]

So the SCART cable wired for CSYNC using a built in sync separator circuit had no effect compared to the sync-on-luma cable. The OSSC still needs to be in RGBS mode when the PS2 outputs 480i and RGsB mode when it outputs 480p.

[marqs]

The console itself needs to be modded for that.

[nmalinoski]

I know this thread is nearly a year old, but I’d like to see this as well. If at least some level of automatic mode detection can be implemented, it opens the door to automatic input switching. Please forgive me if I’m off-base with any of this.

Assuming that the OSSC can determine whether or not it has a valid sync given a sync type, I think a good starting point would be to set a per-input default for muxed sync, then start checking[1] the H-sync/C-sync, V-sync (AV3 only), and G/Y lines on the current input for sync signals[2]. In order of priority: if sync on H-sync and V-sync, assume RGBHV (AV3 only); if sync only on H-sync/C-sync, assume RGBS; and, if sync on G/Y, assume RGsB/YPbPr[3].
[1] Triggered by holding Button 0 for 1-2 seconds?
[2] Select between RGsB or YPbPr; system defaults could be YPbPr for AV2, RGsB for AV1 and AV3. (YPbPr over SCART and HD15 are less common, yes?)
[3] Perhaps tapping Button 0 when using auto-detect could toggle between RGsB and YPbPr? Remote could still manually set mode if needed.

Getting into automatic input switching, if the OSSC doesn’t find a sync signal after a timeout period (1 second?), it could start sequentially checking each input until it finds something.

Sure, it’s not elegant; but it’d be something until a better solution comes along.

As for trying to autodetect YPbPr or RGsB, would it be possible to check for quirks in the voltages? I’m not quite sure which standards are in use, and I’m probably reading this PDF incorrectly, but it looks like if the B/Pb or R/Pr voltages center on +350mV during the sync tip (or go negative during color data), the signal is probably YPbPr.

[arebokert]

I would also like some kind of feature solving this issue as the sync will switch between menus and gameplay when 480p or 1080i is selected on the ps2. This makes you required to switch back and forth between 4 and 1 on the remote several times when playing.

It would also be interesting to mod the PS2 to always output RGBs as mentioned but I don’t know how to go about it and I couldn’t find anything when googling.

[Harrumph]

Citrus3000psi has made a well documented guide, see also this shmups thread for some discussion.

[arebokert]

Thank you for the links! It says some video modes will not work though. If I understand correctly this will make the PS2 output RGBs in all video modes? Or will it make 480i stop working for example?

[SirRockALot]

I’ve been thinking about switching my PS2 from YPbPr component to SCART RGB, but came to the conclusion that it’s probably not very practical without some sort of auto detection from the OSSC or a CSYNC mod on the console. FMCB boots up in 480i, then 480p from OPL, then into GT4’s 480i, activate high-res mode, switches to 480p/1080i, back to 480i for the menus, then 480p/1080i in-game. I’d be wearing out the remote to just get into a single race.

[paulb_nl]

I have done some work implementing auto input switching on the OSSC. Currently I have added these settings:

Autodetect input -> Off, Current input, All inputs.
Auto AV(1-3) Y/Gs -> RGsB, YPbPr

When there is no sync it switches input very quickly every 0.2 seconds and there are 6 different inputs if you consider RGsB/YPbPr the same input so it cycles through all inputs every 1.2 seconds. With the Auto AV* Y/Gs settings you can select if it switches to RGsB or YPbPr for AV1-3 separately.

When set to Current input it stays on the same physical input so for example it switches between AV1 RGBS, AV1 RGsB only.

I think this should take care of all the various auto switching needs.

[nmalinoski]

I have done some work implementing auto input switching on the OSSC.

Huzzah! Thank you for working on this; I look forward to testing it.

When there is no sync it switches input very quickly every 0.2 seconds and there are 6 different inputs if you consider RGsB/YPbPr the same input so it cycles through all inputs every 1.2 seconds.

So, when you’re on a given input and the OSSC loses sync (such as during a mode change), and you’ve got ‘Autodetect input’ set to ‘All inputs’, the auto input switching starts scanning all inputs for a signal? So if I have two consoles connected, and one of them does a mode change, it will switch to the other console? If so, how much more complicated would it be to start with the ‘Current input’ behavior and fall back to the ‘All inputs’ after 1 or 2 seconds?

Also, how complicated would it be possible to hijack Button 0 functionality when Autodetect Input is enabled, so that pressing it triggers a kind of seek-next functionality? (Not unlike how modern radios can automatically seek to the next station with a decent signal.)

[SirRockALot]

That’s really cool, one less button press when starting to game with a component/VGA console and it actually makes sync-on-green an attractive option. I figured development on the OSSC was more or less done at this point, but it’s cool to get a few more small little gifts like these! 😉

[Author]

Posts