-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
Support for 60Hz regression #729
Comments
I guess that would be a manual per-game option then? As I don't think that MISTer can know if there is monitor sync or not and thus "forced 60 hz" cannot be turned on as a fallback (eg. after x secs. without reaching sync). Probable standard usecase: "I always want un-modified gameplay speed and correct audio pitch. But game XY has a troublesome horizontal signal length for my monitor and my monitor cannot sync at all. Thus I have to turn it on in the game options for that specific game". |
A better way to do it for a CRT without the sacrifice of changing the cores clocks is just to adjust the complete display window to fit the video timing better. I've done this for many cores in the past |
See this example of how it would work for shouse I built this to play around with https://docs.google.com/spreadsheets/d/1-dsPKfnta681RCE5VyKJGzNwRFjKvYVWYVJchHFKdE4/edit?usp=sharing I think this is the location for it for the S18 core where H70 should be H83 to relax the timing for the line frequency to meet spec. E.g. 400 pixels vs 381 As per my calculations above. ** Though it wouldnt surprise me if HCNT END was what needed to change, not sure where the active window for the core is set Note: HSYNC will need to shift as well probably between :8A- A6 E.g. Something like this: .HB_START ( 9'h1ff ), |
That's the idea. The default is the original timing, and a 60Hz version can be turned on when needed. |
Documentation about reconfiguring the game PLL here |
Many systems do not output exactly 60Hz video and are troublesome for many screens (#692). Having a general fallback option to adapt the system PLL speed to produce 60Hz would fix this problem at the expense of modified gameplay speed and audio pitch.
The solution should be part of jtframe and applied to all cores automatically
The text was updated successfully, but these errors were encountered: