-
Notifications
You must be signed in to change notification settings - Fork 65
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
Comments
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. |
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. |
I recall encountering this and concluding it was a quirk of the console and not the OSSC. |
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. |
That's actually very nifty! |
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:
This is 256x240:
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?
The text was updated successfully, but these errors were encountered: