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
Sparkling screen #94
Comments
Hi Gabeki17, Ultimax cartridges are supported, but it is probably the KFF that can't meet the timing requirements of the VIC-II on your specific C64. If you could try this with another C64 I would expect a different result. |
Thx! Can the timing be tuned somehow to make it compatible with my 64? I have checked all I have by your recommendation. It looks like out of my 3 C64, only one is not having this issue. Also this issue is geting stronger when the 64 gets warm. The worst is on my Assy 250425 |
Hello Again, I have checked a few version where you have changed the timing. So going from older versions to latest, for sure it have improoved, but for me, no luck... :( Can you help me how to compile the code and where is the timing section in the code? Is this the right plce to look at? https://github.com/KimJorgensen/KungFuFlash/commit/652f082b001117c37a57cf49c4e714a20a19b63f This one was made using v1.07_PAL: And this one was made using 1.23_PAL: |
Thx!, It also effects other games, like Prince of Persia. (Actually I bought KFF because of. :( ) I would try to tune it, but can't compile the code. I know there are many C64 behaving a litlle different. Thank you in advance! With regards, |
@Gabeki17 hi, i think you can adjust the CT1 capacitor near the optimal frequency with help of KFF diagnostic mode. |
Yes, I meant adjusting the frequency of the C64 not changing the firmware |
Got it! Will try tomorrow! :) Still I am interested on compiling. With regaerds, |
I did this. Even replaced ct1 with a new one. :( |
At least the frequency is now ruled out as being the issue. |
Not yet. This version should also be fine. Looks like if directly accessing the ram from cartridge I have this issue. (guessing, really) Also, if the C64 cold, no issue. Might be is some kind of overheating issue. To be honest, I am lost.... :( |
@Gabeki17 @KimJorgensen I would just add that with Jupiter Lander I also had some very strange operating phenomena, it was practically unplayable (the music as it started, nicely faded, sprite collision bugs, screen structure fell apart, etc.) and this I also saw sparkling effects. Then I haven’t looked at it in a long time, since then a lot has happened with servicing the machine and KFF has had many firmware upgrades, and with the current v1.30x firmware, the same Jupiter Lander CRT version is now working flawlessly! |
Ohhhh! Tell me the secret! :) Did you try to leave it running for 1-2 hours? What is your assy version if I may ask? Also VIC-II revision I am interested for! :) Thank you very much for sharing this! With regards, |
As I wrote, I'm not sure what improved it, but I wouldn't think it was a hardware bug, I'd rather have think on KFF's firmware status at the time and how Jupiter Lander is operating differently than usual. |
Thx! May I ask what version you are using on your KFF? With regards, |
|
I seem to have been wrong. The Sparkling screen is completely independent of the firmware. I noticed this on one of my machines, loading the CRT version of Jupiter Lander and then turning the machine on / off, the error occurs, or the machine starts up completely error-free. Under the new firmware, Pharaoh's Curse now runs flawlessly (for pre-v1.36 firmware, the game's music speeded up and the game couldn't be started).) |
@zitev Did you also test with 1.37? |
@KimJorgensen yes, i tried it with v1.37. |
@zitev OK, if you got a sparkling screen with firmware versions 1.35, 1.36 and 1.37, then my fix in 1.37 obviously did not work :( |
@KimJorgensen yes i say so too - but the Pharaoh's Curse has been healed since v1.36 .. :) |
Hi, Just read the latest duscussion here. Thx! :) Will test it tomorrow! (all my family is sleaping now.) With regards, |
Hi @Gabeki17, Meanwhile for me past the sparkling screen phenomenon. I modified several things on the pcb (I soldered the CIAs and 4066s and put them in an IC socket, among other things). But I suspect it seems to have improved since I replaced a shorted zenner diode (6.2V) that was responsible for the datasette power supply. Since I didn't test the datasette for a long time, the error didn't appear for a long time. If the datasette port doesn't work for you, suspect this zenner diode! Using diagnostic cartridge with harness did not detect this error! Üdv, zitev |
Thx for testing! For me, still sparkling hard when warmed up. When the C64 was off for a while and cold, there is no sparkling. Regards, |
Hi Zitev, What have you changed exacly? Sorry, When starting soldiering a 64 I am starting thinking binary. :) Regards, |
@Gabeki17 there’s really nothing else that can cause this to go away (except maybe zenner’s fault). I haven't been able to reproduce this since, I have no other hints yet, I think the phenomenon is completely gone. |
Just an FYI, this problem is caused (or at least affected) by the PLA. If I have original 82S100 PLA in my C64 (250425 board), I get sparkles in Jupiter Lander. If I use a modern CPLD-based PLA, it works fine. Firmware 1.41 |
I've had similar sparkling or unstability issues, where it may work better on cold C64s or instead on warm C64s, as well as stability differences using a PLA replacement. For the Jupiter Landing video, I would guess either the address output of the VIC-II is slightly slower for that specific C64 PCB or the PLA ROML/ROMH is slightly slower. The ARM code then captures the VIC address or ROML/ROMH control slightly too early. Fixing unrelated issues like the zener diode or capacitors on the C64 PCB likely make the 5V supply more stable, and a more stable power supply will slightly improve all signal timings on the PCB. A PLA replacement should be around 10-15ns faster than an 82S100 typically. (according to skoe's PLA dissected document). That is 2 to 3 ARM cycles difference. In my experience, it is quite easy to get ARM timing differences of 1 or 2 cycles, just by recompiling the firmware with a different GCC sub-version or by changing something unrelated anywhere in the firmware code. It does like the specific place in the ARM code where this happens, has a tweak to read the VIC address early to support C128 CRT reads from ARM flash, which is always slow (7 ARM cycles). Wihtout changing the timing for anything else, and not changing anything for C128, it might be enough to re-read the VIC address at the start of crt_normal.c crt_early_vic_handler.c. Such changes have to be tested well on several machines though. |
Hello @markky10, yes, this was typically the case for me, and the cause is most likely a power failure! I looked it up, unfortunately I misremembered when I memorized the data of the zenner diode, it is not a 6.2V, but a 6.8V zenner, and I replaced it on pcb 250469 (according to the service manual, it is CR1). There can be another related error phenomenon: if the supply voltage is lower than specified (I use a power supply in which I replaced the 5V DC part one by one with a +24V-/+5V mini module)... |
C64C, PAL, PCB NO. 252311 REV. A Not sure if it's KFF related. |
@shelterx I wouldn't expect KFF to affect PRG games, but if you have another way to load the PRG on your C64 you should be able to test that |
EDIT: I tried the same game in VICE and you know what, it's exactly the same behavior, so it's not related to the KFF nor my C64C. I don't have any other way to load Giana Sisters other from the KFF right now. I just got started using the C64 and KFF was one of the first things I bought because it's a very nice piece of hardware and it was available. |
What you are describing there in Giana is the "grey dots" bug in the CMOS 85xx VIC-II chip. As you found, it's unrelated to the KFF. |
Wow, never heard of this particular bug before. Thanks for the clarification! |
The original issue was fixed by firmware v1.44 where it is possible to adjust the timing (see #146) so I'll close this. |
Hi,
I am a little confused.
This CRT image runs, but causing picture issues.
https://www.youtube.com/watch?v=ixoqpP0xUW4
If I run it as a prg, no issue.
cartconv -f Jupiter.crt
CRT Version: 1.0
Name: Jupiter Lander
Hardware ID: 0 (Generic Cartridge)
Mode: exrom: 1 game: 0 (ultimax)
offset sig type bank start size chunklen
$000040 CHIP ROM #000 $e000 $2000 $2010
total banks: 1 size: $002000
The text was updated successfully, but these errors were encountered: