-
Notifications
You must be signed in to change notification settings - Fork 4
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
Compatibility issues due to the 0.25% system slowdown #2
Comments
Current status: There is a menu item called "HDMI: Flicker-free". If you switch it off, then the system runs at 100% and for example above-mentioned Input 64 Issue 1/1985 works like a charm. We leave this issue open, because the root-cause of this behavior is completely in the dark. "Theoretically" no software should ever notice, that it runs on a slightly slower machine... |
fixes #2 It is important that also in the HDMI-Flicker-Free-mode we are using the vanilla clock speed given by CORE_CLK_SPEED_PAL (or CORE_CLK_SPEED_NTSC) and not a speed-adjusted version of this speed. Reason: Otherwise the drift-compensation in generate_drive_ce will compensate for the slower clock speed and ensure an exact 32 MHz frequency even though the system has been slowed down by the HDMI-Flicker-Free. This leads to a different frequency ratio C64 vs 1541 and therefore to incompatibilities such as the one described in the above-mentioned GitHub Issue.
Commit 313c468 fixes this issue. We decided it is too "dangerous" to go into Release 4 at this time, since we would need to do a lot of regression testing, including all the demos. If you need this fix before Release 5, here is an experimental, unreleased core that fixes the issue. It is based on "Release Candidate 2 for Release 4": |
… 'fix-issue-2' into develop fixes #2 It is important that also in the HDMI-Flicker-Free-mode we are using the vanilla clock speed given by CORE_CLK_SPEED_PAL (or CORE_CLK_SPEED_NTSC) and not a speed-adjusted version of this speed. Reason: Otherwise the drift-compensation in generate_drive_ce will compensate for the slower clock speed and ensure an exact 32 MHz frequency even though the system has been slowed down by the HDMI-Flicker-Free. This leads to a different frequency ratio C64 vs 1541 and therefore to incompatibilities such as the one described in the above-mentioned GitHub Issue.
Joystick port #2 button did not work any more
Joystick port #2 button did not work any more Merge commit '494a4f571a9fd6fb4b7e68010db7660098b48416' into dev-M2M-upgrade
As described above: We consider this issue as fixed. But the fix will not be released before Version 5 of the core. So we leave the issue open so that people who run into the issue can download this Alpha version of Version 5 that fixes the issue. |
"Wizard of Wor" cartridge ia working and "Silicon Syborgs" (game #2) from "Super Games" is working.
Fixed with V5 |
When running in HDMI flicker-fix mode, we are slowing the whole system (not only the CPU, but everything including the whole C64 system (CIA, SID, VIC, ...) and the C1541) down by 0.25%, so we are only running at 99.75% of the official speed. This leads to a great silky smooth scrolling experience on HDMI, but also leads to some software not working.
The tapemag / diskmap Input 64 Issue 1/1985 is known to have this problem: It works fine without the HDMI flicker-fix but it does not work with the HDMI flicker-fix: iput0185.d64.zip
The text was updated successfully, but these errors were encountered: