Open paich64 opened 1 week ago
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. double density.m.zip
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 (https://github.com/MJoergen/C64MEGA65/issues/135) and which leads to TRAP16/TRAP17 incompatibilities (https://github.com/MJoergen/C64MEGA65/issues/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...
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" :) Well done @sy2002, you rock :)
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 https://github.com/MJoergen/C64MEGA65/issues/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 https://github.com/MJoergen/C64MEGA65/issues/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
1) Since this demo is not part of our "Marathon demo" bench I tested it on V5.1 (R3A & R6) as well as on V5.0 (R3A).
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
2) I have of course checked if the issue has ever existed on the Mister official c64 core releases :
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
3) Since the modifications we have brought in V5.1 are coming from many changes which have been grabbed from Mister modifications which occured in the context of the following Mister issue : https://github.com/MiSTer-devel/C64_MiSTer/issues/160
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