Commodore 64C problem

[penny-bit]

Hi, I've just bought your cartridge from TFW8b and I've inserted it into my Commodore 64C and I had many problems: freeze, glitch, not showing the menu etc. then I've inserted it into the good old Commodore 64 and it worked perfectly fine. Here the specs of the motherboards:

• C64 Assy 250407 Rev A
• C64C Assy 250469 Schematic 252311 Rev A

My questions are:

• Do you know if there is a known issue with this type of C64C/motherboard?
• If yes, Is there any workaround to make it work?
• If no, and the problem is the C64C can you tell me, if you know, what could be the cause of this?

Thank you a lot for your work it's really great!

[zitev]

I compared the measurement of the KFF's diagnostic tool with a digital scope, there is a 30Hz difference between the two measurements (the scope measures 985.248kHz, the KFF measures 985218Hz.) I know this is not a significant discrepancy, I would just like to know what this discrepancy may be, and which result should be considered relevant for KFF?!

[KimJorgensen]

@zitev Didn't I answer that question already? The accuracy is down to the precision of the clock circuit on the Kung Fu Flash board and that hasn't been calibrated to provide a super accurate frequency. The digital scope would of course also have a certain frequency counter accuracy that depends on the model you are using.

[zitev]

@Kim Sorry, if your post escaped my attention, I won't follow the developments exactly. So, if I understand correctly, then the oscilloscope is considered authoritative because of its accuracy, even if the card's clock shows otherwise..

[KimJorgensen]

@zitev Yes, if you use an oscilloscope with a decent frequency counter accuracy. In your case the deviation is so small that I don't think that it could cause any problems.

[michielboland]

Managed to probe the reset line. It appears to have some spikes/ringing immediately after power is applied - don't know if this is relevant. After the spike the reset is low for about 248ms then remains high. I notice that the noise on the reset line looks slightly different, depending on whether the machine is in a bad state or not.

OK:

BAD:

[KimJorgensen]

@michielboland I'm not sure what would generate that noise on the reset line or if that is normal, but the voltage levels look OK for TTL logic. Did you also measure the +5V rail and clock signal when the reset goes high? Sorry, I should have been more specific when asking for measurements during power-up, but I was curious to see if the power and clock are stable when the 6510 processor starts executing.

[zitev]

@Kim Unfortunately, there are now plenty of precarious, unstable machines in operation, in which KFF can also produce strange operations. Could there be a possible workaround for this problem if KFF checked for stable operation for a few clock cycles at startup and continued booting when CPU operation was already stable? Sorry if you ask stupidity ...

[KimJorgensen]

@zitev KFF is already checking for a stable clock before releasing the reset line. Maybe that detection isn't good enough or maybe the fault has nothing to do with the clock at all. At this point it is all pure guesswork.

[michielboland]

Probed RST (1 yellow) +5V (2 cyan) PHI0 (CPU pin 1) (3 magenta) So it looks like 5V and clock are stable when RST goes high. [edit] captured over longer time period:

[KimJorgensen]

@mwedmark thanks. And this was a failed startup attempt that was captured?

[michielboland]

These two happened to be ok. Captures look the same for failed startups. Here is a capture I managed to make of some noise that appears when power is initially applied (i.e. before there is a clock) (this time the machine failed to boot)

[KimJorgensen]

@michielboland This is interesting. I could see why something like this would get detected as a clock signal

[michielboland]

The excessive ringing on phi0 may also be due to bad probing. (Last time I used one of those tiny probe tips with a very short ground lead I shorted something and burnt out a coil.)

[KimJorgensen]

@mwedmark Here is a test firmware where KFF requires the clock to be stable for much longer. If there is ringing on the clock signal like the capture then it should not be detected as a valid clock. Please let me know if it makes any difference.

KungFuFlash_vTST2.zip

[michielboland]

The PAL upd file in the TST2.zip appears to be the same as in the TST1.zip

[KimJorgensen]

@mwedmark OK, not that either :( but thanks for testing

[michielboland]

I think you are @-in the wrong person :) I was trying to point out that the KungFuFlash_vTST1_PAL.upd .image in the KungFuFlash_vTST2.zip file appears to be the same as the one in the first zip file (with the reset line change) - so I think I'm just testing the same firmware and not the one with the improved clock detection. So there may be hope yet. :)

[KimJorgensen]

@michielboland Whoops. You are right, wrong person and wrong image in zip file. Sorry for that. I'll get the zip file updated...

[KimJorgensen]

@michielboland Here is a new zip file, hopefully with the correct files this time :)

KungFuFlash_vTST2.zip

[michielboland]

No improvement I'm afraid. I have observed some different failure modes, FWIW. Sometimes the machine will start up fine. Other times the machine crashes instantly. Sometimes the R/W line shows 3 W pulses in succession almost right after the reset line goes high which would mean the CPU is executing a BRK (0) instruction very early on after powerup (?). Another failure mode is that the machine will run fine for what appears to be some milliseconds but would then lock up anyway.

I'm using the following image for testing test5.zip source below

; Ultimax

* = $e000

nmi_handler
  rti
rst_handler
  ldx #0
  ldy #8
loop
  .rept 62
  sty $d020
  stx $d020
  .endr
  bit 0
  nop
  jmp loop

* = $fffa

  .word nmi_handler
  .word rst_handler
  .word 0

[KimJorgensen]

@michielboland Note that 3 write pulses in succession could also be a IRQ or a NMI. Don't you need to initialize the hardware (VIC-II, CIAs) when running in Ultimax mode?

[michielboland]

I think interrupts are disabled when the 6502 / 6510 starts, so you might get an IRQ from somewhere but then this is ignored by the CPU until the interrupt bit is cleared. Not sure about NMI but these are edge triggered, so also highly unlikely.

[michielboland]

Problem appears to be fixed in 1.32. I couldn't reproduce a hang with about 10 poweroff/powerons; when I revert to previous firmware it will hang randomly.

[KimJorgensen]

@michielboland Great that it works :) I guess the code optimization must have changed the timing, but it would have been nice to know where the problem was so I do not make it worse again by mistake

[michielboland]

Firmware v1.31 : boot fails intermittently v1.32 : boot ok (tried about 20 times) Hope that narrows it down a bit.

[TzOk83]

I have similar problems (garbage on a screen) when trying to enter KFF Menu out of a Dead Test or a Diagnostic Cartridge. Other cartridges seem to work fine. I have PAL C64C machine, and KFF v1.34.

[lordoftears]

The 1.39 firmware update fixed my garbage screen issue when pressing the menu button. I also noticed that the diagnostics frequency is more stable now on that computer.

[michielboland]

I'm still having issues with my C64C v1.43 firmware.

.crt files load but then the menu button may or may not work .prg files may or may not load (display stuck in light blue border/dark blue background with no graphics)

I suspect this could have something to do with the phase of the dot clock relative to the 1Mhz clock. There are basically four phases this clock can be in (this is due to the wonky 8701 chip.) From experiments, it appears the KFF works 100% in two phases and is 100% broken in the other two phases.

Some scope measurements: yellow = phi0 (probed at VIC-II pin 16) cyan = color clock (probed at VIC-II pin 20) magenta = dot clock (probed at expansion port 6)

GOOD

BAD

GOOD

BAD

Hopefully this can give a bit more insight.

[KimJorgensen]

@michielboland Very interesting. KFF does not use the dot clock but only phi2 so do you have any ideas to why this phase shift would cause any problems? Does the phase shift cause the duty cycle of phi0 or phi2 to change? KFF is only using the falling edge of phi2 to calculate the bus timing

[TzOk83]

I can confirm these issues on my PAL C64C. I was convinced, that it is something wrong with mu KFF, but I made a second KFF unit, and it is the same. Not sure if it has anything to do, but my C64C is DC only powered, so ACIAs do not function fully correct (no 50 Hz clock), yet in normal operation it doesn't matter, as the only visible symptom is TOD not working.

I can provide measurements if you want, just tell what signals you are interested in.

[michielboland]

In theory the phi0 duty cycle should be independent of the dot clock phase, since the time between the 1st and the 5th falling edge of he dot clock is always the same. I think RAS is clocked in the VIC-II by the dot clock internally, so that could maybe also be related. I'll try to do some more measurements.

[michielboland]

Could not find a difference in phi0 duty cycle as expected. Some timings: these are time in nanosecond between falling edges of two signals

                        01 (good)  02 (bad)   03 (good)   04 (bad)
dot - phi0              43         43         43          43
phi0 - dot              78         89         77          92
phi0 - ras             179        190        179         194
 dot - ras (computed)  101        101        102         102
phi0 - cas             264        261        260         263

So from the falling edge to the dot clock to the next falling edge of phi0 it is always 43 ns, and from the next falling edge of the dot clock to the falling edge of ras the time also appears to be constant.

Also I noticed that if the KFF is in a bad state the C64 has the 'grey dot' issue (using the test program above) and if it is in a good state there are no grey dots.

[KimJorgensen]

@michielboland OK, thanks for the update

[KimJorgensen]

A new release has been created with some performance optimizations and a tool for adjusting timing, if needed. Let me know if this solves your stability issues

[michielboland]

With phi2 offset to 0 the menu would always work but the cartridge would not start if the dot clock was in the 'bad' phase. Both cartridge and menu work if I set phi2 offset to 2.

[KimJorgensen]

Please let me know if anybody still have stability problems with their C64C and firmware v1.44, that cannot be fixed by adjusting the phi2 offset. Otherwise I'll close this issue

[lordoftears]

Hey Kim, I am currently out of home for work, I will be back before the weekend and I'll try that. Thank you

Emanuele

---

From: Kim Jørgensen @.> Sent: Wednesday, November 9, 2022 5:09:34 PM To: KimJorgensen/KungFuFlash @.> Cc: lordoftears @.>; Mention @.> Subject: Re: [KimJorgensen/KungFuFlash] Commodore 64C problem (#89)

Please let me know if anybody still have stability problems with their C64C and firmware v1.44, that cannot be fixed by adjusting the phi2 offset. Otherwise I'll close this issue

— Reply to this email directly, view it on GitHubhttps://github.com/KimJorgensen/KungFuFlash/issues/89#issuecomment-1308993335, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVZOLQBQCSIEYAAJMPRYW23WHPED5ANCNFSM42V3IMDQ. You are receiving this because you were mentioned.Message ID: @.***>

[mwedmark]

I have reports of 250469 motherboard crashing with: "Mayhem in Monsterland" and "Creatures" but maybe this is connected to known problems for some C64 that cannot run those games? Anyone else seen this? Source: https://csdb.dk/forums/?roomid=11&topicid=6711&firstpost=12

[KimJorgensen]

@mwedmark It seems that both these games can trigger the VSP bug, see https://kodiak64.com/blog/future-of-VSP-scrolling You can try running the bug fixed version of the game and see if that helps

[mwedmark]

Thanks for the feedback! I deem this to not be a Kung Fu Flash issue, so nothing from me.

[lordoftears]

Please let me know if anybody still have stability problems with their C64C and firmware v1.44, that cannot be fixed by adjusting the phi2 offset. Otherwise I'll close this issue

The clock is stable on my computer, and also the menu issue I had before disappeared some updates ago.