Skip to content
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

320 / 256 width positions don't match #65

Open
filevans opened this issue Jul 15, 2020 · 5 comments
Open

320 / 256 width positions don't match #65

filevans opened this issue Jul 15, 2020 · 5 comments

Comments

@filevans
Copy link

filevans commented Jul 15, 2020

Hello

On a CRT if you adjust your horizontal position in the service menu, all the resolutions match. But on the OSSC it doesn't match, i centralised the position for 256x240 games but then 320x240 is quite a lot out of position. The mega drive uses both of those resolutions for different games for example, and the OSSC uses one setting for all 240p resolutions no matter what width.

This is 320x240:

15948116272958482482931815044954

This is 256x240:

15948117256066761189666728704905

You can see 256x240 is centralised (I've turned the brightness up a lot so you can see where the screen ends)
But 320x240 isn't centralised. I have only adjusted the back porch slightly and not the h. samplerate

Yet on CRT, these 2 resolutions will match better and be centralised, so there seems to be something off in the way it handles the different widths?

@marqs85
Copy link
Owner

marqs85 commented Aug 10, 2020

It might be that the modes have different hsync width which may affect the position on a CRT while OSSC only uses leading sync edge as reference like many digitizers. Need to check sync width on a scope to verify the hypothesis.

@marqs85
Copy link
Owner

marqs85 commented Aug 11, 2020

The sync in 256col mode is slightly shorter according to a measurement. If backporch has identical length in both modes, delay from leading sync edge to picture border is higher in 320col mode which explains shift to the right.

@Firebrandx
Copy link

I recall encountering this and concluding it was a quirk of the console and not the OSSC.

@marqs85
Copy link
Owner

marqs85 commented Jul 27, 2021

The upside with different hsync length is that it's possible to reliably detect which mode MD is outputting (unless the signal goes through a sync conditioner etc.). On OSSC Pro it should be possible to add "MD Auto" sampling preset which would select automatically between existing "MD 256col" and "MD 320col" presets.

@Firebrandx
Copy link

That's actually very nifty!

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