-
Notifications
You must be signed in to change notification settings - Fork 5
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
Big visual regression between 5.1 and 5.0 on "double density" demo #164
Comments
Since i forgot to mention it : The issue occures whether we are on HDMI or VGA. Also not all the picture is corrupted, juste the logo and It seems related to a timing issue with VSP+Line crunching. Also added the .prg since it's a single file demo. |
WOW @paich64 - It is amazing how thoroughly you tested this to make it easier for us to find the root cause. Thank you for that!! There is one thing which might be the culprit - and it was the culprit for another demo, too: The fact that we have the GEOS RTC always ON, which means we "do things" with the tape port which leads to "Old Men in Used Cars" not working (#135) and which leads to TRAP16/TRAP17 incompatibilities (#133). Do you by chance keep the binaries of Alpha versions that I have sent to you in past? If so, do you still have the binary of V5.1A16 (Alpha 16): It is basically the same as V5.1 release but it has the GEOS RTC switched OFF. I have a strong suspicion that this visual glitch will not happen with V5.1A16... |
It's good to have you, because Yes you are 100% right ! I just grabbed V5.1A16 from issue 133 and tested "double density" demo on both R3A & R6 : The issue does not happen anymore ! I guess you can link this issue to issue 133 and consider it as "fixed" :) |
Thank you @paich64 . Let's keep this issue open, so that we are not forgetting to test it again in future and as soon as we implement issue #120 "Advanced C64 Compatibility Settings", then users will be able to toggle the RTC clock. Given, that already two demos fail when the GEOS RTC clock is ON by default and given that also the compatibility test (TRAP16/TRAP17) fail, I tend to DEACTIVATE the GEOS RTC clock in future releases and users who want to use it in GEOS will need to ACTIVATE it using the advanced menu that will be done in issue #120 . Reminder to self and to @Kugelblitz360: We must not forget to document in c64.mega65.org how users will be able to use the Real Time Clock (RTC) in future then. Today it "just works" if you install the right driver, but in future, one needs to activate the feature. |
I have been reported that the demo called "Double Density" has a massive visual glitch on v5.1 R6
And indeed, the big scrolling logo is completely corrupted :
V5.0 :

https://www.youtube.com/watch?v=bZawKtRrQx4
V5.1

https://www.youtube.com/watch?v=rVUFP2bw2T8
C64_20221007.rbf Release 20221007 => No issue
C64_20221124.rbf Release 20221124 => No issue
C64_20230224.rbf Release 20230224 => No issue
C64_20230517.rbf Release 20230517 => No issue
C64_20231208.rbf Release 20231208 => No issue
C64_20240110.rbf Release 20240110 => No issue
C64_20240418.rbf Release 20240418 => No issue
I have checked all the unstable mister builds which have been produced over this period and could not find any issue with any of them :
C64_unstable_20231214_132a8c.rbf <== this where Mister issue 160 (and associated issues) investigation started => No issue
C64_unstable_20231216_15c0e3.rbf => No issue
C64_unstable_20231218_20eef0.rbf => No issue
C64_unstable_20231218_215425.rbf => No issue
C64_unstable_20231220_18bcb7.rbf => No issue
C64_unstable_20231221_188a41.rbf => No issue
C64_unstable_20231221_1723c1.rbf => No issue
C64_unstable_20231223_084f46.rbf => No issue
C64_unstable_20231223_1682a5.rbf <== this where Mister issue 160 (and associated issues) investigation ended => No issue
C64_unstable_20240101_188e63.rbf => No issue
C64_unstable_20240102_223f9c.rbf => No issue
C64_unstable_20240103_141291.rbf => No issue
C64_unstable_20240106_1200bf.rbf => No issue
C64_unstable_20240127_131e40.rbf => No issue
C64_unstable_20240224_16b6d7.rbf => No issue
C64_unstable_20240225_12a798.rbf => No issue
Currently my only assumption is that we possibly missed something when porting the modifications to the C64 core.
I know we did not port completly the CMOS/HMOS option, but i have tested them in the Mister core and they do not seem to produce the issue.
Could we have a chat to discuss about this issue ?
Demo file : https://csdb.dk/release/?id=2681
The text was updated successfully, but these errors were encountered: