c0pperdragon
commented
3 years ago Using this pin to send out the pixel clock was a very desperate hack from the very start. It is actually used during the FPGA configuration and is a bidirectional open-drain pin. So it is possible to mess things up when driving this pin in the wrong time. If I understand the doc correctly it is even possible to re-initate configuration later by driving the pin low for a specified minimum time. That it consistently works on my setup is probably just a lucky coincidence. The pin should be externally driven high by the R24 pull-up until the FPGA pulls it low to signal configuration completion (also my clock output seems to not cause problems just by itself) Maybe the input circuitry to your VIC draws just too much current to overcome this 10k pull-up and this messes up everthing. You could try to just use a stronger pull-up instead? Maybe 4k7 alreads does the trick...
IanSB
I've had a strange stability issue with my board.
It was working OK yesterday but I started up my C64 today and it was completely dead (power cycled many times) I'm using the clock from the FPGA and I checked that output and it was missing. I also checked the 3.3v regulators and the crystal oscillator on the FPGA board which were all OK as well as the C64 power rails. I then tried reprogramming the FPGA and it failed multiple times during programming with "Operation Failed" (The C64 was powered up OK)
I reverted to the normal C64 clock and the C64 booted up OK. I then tried reprogramming the FPGA and this time it worked and everything is behaving itself at the moment.
One thing that occurred to me is that if the R24 clock out of the FPGA changes frequency with PAL or NTSC would that get into a stability issue as that clock is partly being used to determine if the VIC is PAL or NTSC? That doesn't explain the inability to program the FPGA though unless the RGBtoHDMI palette detection is screwing up the JTAG interface in this failure mode.
This happened previously about a week ago. At that time I was using a 100R resistor in series with the R24 clock so I removed it and had the R24 clock line directly connected and things worked OK again so I thought it was a faulty connection but it looks like that might have just been coincidence and there is another underlying issue.
I'm running with the normal C64 clock for the time being to see if the problem re-occurs.
Not sure if this is a fault with my board or an issue with the FPGA design. Any ideas?
EDIT: Just had a failure using the normal C64 clock so I have now reverted to v2.7 which was before the continuous PAL/NTSC switching to see if it happens with that version.