KimJorgensen / KungFuFlash

Cartridge for the Commodore 64 that packs a punch
zlib License
396 stars 60 forks source link

Sparkling screen #94

Closed Gabeki17 closed 1 year ago

Gabeki17 commented 3 years ago

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

KimJorgensen commented 3 years ago

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.

Gabeki17 commented 3 years ago

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 am not afraid of coding if that is the only way.

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 It is ok on one of my 250407 And we could say, perfect on another 250407.

Gabeki17 commented 3 years ago

Hello Again,

I have checked a few version where you have changed the timing. But still not compatible with 2/3 of my C64.

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? I will fix it for myselsf. I hope I can adjust it to my devices. :)

Is this the right plce to look at? https://github.com/KimJorgensen/KungFuFlash/commit/652f082b001117c37a57cf49c4e714a20a19b63f

This one was made using v1.07_PAL: https://www.youtube.com/watch?v=-2Nqv516g4c

And this one was made using 1.23_PAL: https://www.youtube.com/watch?v=DV2QIz4ht6A

Gabeki17 commented 2 years ago

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. If you can help me with that I could try to solve my own issue, and when it works I can simply give you the information about.

I know there are many C64 behaving a litlle different.

Thank you in advance!

With regards, Gábor

zitev commented 2 years ago

@Gabeki17 hi, i think you can adjust the CT1 capacitor near the optimal frequency with help of KFF diagnostic mode.

KimJorgensen commented 2 years ago

Yes, I meant adjusting the frequency of the C64 not changing the firmware

Gabeki17 commented 2 years ago

CT1

Got it! Will try tomorrow! :)

Still I am interested on compiling. I have some experience with microcontrolers like esp8266. Also coded a lot. Mostly in Arduino IDE But this chip I have never....

With regaerds, Gábor

Gabeki17 commented 2 years ago

Yes, I meant adjusting the frequency of the C64 not changing the firmware

I did this. Even replaced ct1 with a new one. Now it is tooned to exactly to 985248 Hz, but still.... Sparkling hard.

:(

KimJorgensen commented 2 years ago

At least the frequency is now ruled out as being the issue. Did you try Jupiter Lander V2 from the Multimax relase?

Gabeki17 commented 2 years ago

At least the frequency is now ruled out as being the issue. Did you try Jupiter Lander V2 from the Multimax relase?

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. (I have tried a different VIC-II. Was the same....)

To be honest, I am lost.... :(

zitev commented 2 years ago

@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!

Gabeki17 commented 2 years ago

@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, Gábor

zitev commented 2 years ago

@Gabeki17 @KimJorgensen

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, Gábor

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.

Gabeki17 commented 2 years ago

@Gabeki17 @KimJorgensen

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, Gábor

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, Gábor

zitev commented 2 years ago

@Gabeki17 @KimJorgensen

Thx!

May I ask what version you are using on your KFF?

With regards, Gábor Of course, the latest version (v1.30) is up and it seems to be the most stable so far.

KimJorgensen commented 2 years ago

@Gabeki17 and @zitev Could you try firmware v1.37 to see if that has fixed this issue?

zitev commented 2 years ago

@KimJorgensen @Gabeki17

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).)

KimJorgensen commented 2 years ago

@zitev Did you also test with 1.37?

zitev commented 2 years ago

@KimJorgensen yes, i tried it with v1.37.

KimJorgensen commented 2 years ago

@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 :(

zitev commented 2 years ago

@KimJorgensen yes i say so too - but the Pharaoh's Curse has been healed since v1.36 .. :)

Gabeki17 commented 2 years ago

Hi,

Just read the latest duscussion here.

Thx! :)

Will test it tomorrow! (all my family is sleaping now.)

With regards, Gábor

zitev commented 2 years ago

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

Gabeki17 commented 2 years ago

@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 :(

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, Gábor

Gabeki17 commented 2 years ago

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

Hi Zitev,

What have you changed exacly?

Sorry, When starting soldiering a 64 I am starting thinking binary. :)

Regards, Gábor

zitev commented 2 years ago

@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.

rittwage-zz commented 2 years ago

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

medzes commented 2 years ago

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.

markky10 commented 2 years ago

im having the exact same ultimax mode issue randomly on 2 differents 250407 boards, it appear mostly when i use a replacement kernal adapter and a kff but it seem to be way worst when i use a keelog psu (4.7vdc and 11.5ac) sometime i get same issue even with the original radar rat race cartridge , when i use a gal pla the sparkling effects is allmost gone but not totally (i still see a few line on the left side of the screen), i guess changing the (6.2v) zener diode could be the solution but i only see a 2.7v (cr1) and a 7.5v (cr2) in the service manual, can you please tell me wich one i need to replace. rrr

zitev commented 2 years ago

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)...

shelterx commented 1 year ago

C64C, PAL, PCB NO. 252311 REV. A I see white sparkles/pixels in the border of Giana sisters on the title screen (PRG version of the game). There's no white pixels when playing the actual game.

Not sure if it's KFF related.

KimJorgensen commented 1 year ago

@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

shelterx commented 1 year ago

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. It could of course be my C64 that makes those dots, it's a stock C64C with nothing replaced (yet) and I'm using a Keelog PSU.

rittwage-zz commented 1 year ago

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.

shelterx commented 1 year ago

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!

KimJorgensen commented 1 year ago

The original issue was fixed by firmware v1.44 where it is possible to adjust the timing (see #146) so I'll close this. Please feel free to create a new issue if you still have problems with v1.44