PAL red/green color moire, not in NTSC

Disk drives, Monitors, SuperCPU etc.
rmzalbar
Member
Member
Posts: 54
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar » Thu Jan 30, 2020 7:01 am

It's a 250407, with the clock generator built from 74-series parts. Solder joints are all good - I built it carefully - and have manhandled it enough while testing to know it's not flex or pressure sensitive.

I used my digital o-scope to count the clock - but it's hard to get a solid count, depending on window size and trigger jitter. I zoomed out as far as I could and had it average over time to get a stable reading. This is possibly not as good as a true FC would give me, so I'm a little bit suspicious.



banman
Member
Member
Posts: 76
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman » Thu Jan 30, 2020 12:35 pm

Hi rmzalbar,


Hmmmm.... I think I remember that board....

I remember trying to count the clock on pin 1 of the 6510 on a very old oscilloscope and it to would fluctuate between an upper and lower number.
When I hooked up a dedicated frequency counter in parallel it would give me a reading right in the middle of the 2 oscilloscope readings.



This is a bog standard PAL setup too by the way....may help you get your bearings right....

Apologies for the rubbish video quality...



So I would hazard a guess maybe just get a good stable upper and lower value and do an average of the two.

On your 250407 board have you done a running continuity check to see if the NTSC J1 jumper disengages and the PAL J2 line engages completely?
From what I understand is that the C64 will appear to be working even with the NTSC jumper on with a PAL VIC II chip in the socket.
It messes with the timing slightly so the C64 looks like it is working .

Maybe try to load a game that has a complex loader and see if that works ok.

Alternatively see if you can temporarily hard wire the PAL jumper with a bodge wire and keep the NTSC line open all while having the NTSC chip out from the circuit.

That might put focus on just the VIC II chip, onboard crystal oscillator and your NTSC RF modulator.....

rmzalbar
Member
Member
Posts: 54
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar » Thu Jan 30, 2020 9:22 pm

With regards to the jumper - the C64 is working and is PAL-aware: peek(678) contains 1 in this mode. Loading GEOS and timing its RTC shows it to be 12 seconds fast (as it should be with a 60hz AC frequency in PAL mode.) Games and loaders all work fine.

I took my measurement as you had, by trying to center between the upper and lower limits, and ultimately using the "sample average" feature of the o-scope to get a stable value. I can't imagine this could be significantly incorrect.

What I do notice is that the red/green bar pattern frequency is spaced exactly the width of the characters on the screen - 8 pixels? - the AEC frequency? There is a Lumafix integrated onto the board, but adjusting it only affects the luma AEC bars, it does absolutely nothing to the red/green bars.

banman
Member
Member
Posts: 76
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman » Fri Jan 31, 2020 5:53 am

Hi rmzalbar,


I just noticed this....
rmzalbar wrote:
Thu Jan 30, 2020 9:22 pm
With regards to the jumper - the C64 is working and is PAL-aware: peek(678) contains 1 in this mode. Loading GEOS and timing its RTC shows it to be 12 seconds fast (as it should be with a 60hz AC frequency in PAL mode.) Games and loaders all work fine.

Is that a typo regarding the PAL frequency. It's just we have 50hz 230v in Australia.

All the PAL TVs here are 50hz. If you look at the screen shot in this discussion earlier the PC LCD monitor runs at 50hz.
Maybe try adjusting your PC LCD monitor clock to 50hz and see if there is a difference...

What upper and lower frequencies are you obtaining on pin 1 of your 6510?

I snagged this from a web site......
MOS Technology 6510/8500 @ 1.023 MHz (NTSC version) @ 0.985 MHz (PAL version)

If all is good in those areas and you can categorically rule out incorrectly wired NTSC and PAL jumper settings it seems that the focus is now on the PAL VIC II chip or maybe the NTSC RF modulator.

Can you temporarily de solder the RF modulator to see if that makes a difference?


What happens when you play a PAL game? Do the bars remain there?

When your 2nd C64 arrives from Europe you can temporarily switch out some parts to test against.

banman
Member
Member
Posts: 76
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman » Fri Jan 31, 2020 6:43 am

Hi rmzalbar,

I should elaborate on what said earlier, apologies.... :oops:


While a program is being loaded from tape on the C64, the screen remains blank, to avoid memory reads issued by the video chip blocking the time-sensitive code on the CPU.

Try loading a tape game to see if you get any anomalies......

User avatar
eslapion
Member
Member
Posts: 897
Joined: Mon Jul 20, 2015 10:11 am
Location: Canada
Contact:

Re: PAL red/green color moire, not in NTSC

Post by eslapion » Fri Jan 31, 2020 7:10 am

rmzalbar wrote:
Thu Jan 30, 2020 9:22 pm
What I do notice is that the red/green bar pattern frequency is spaced exactly the width of the characters on the screen - 8 pixels? - the AEC frequency? There is a Lumafix integrated onto the board, but adjusting it only affects the luma AEC bars, it does absolutely nothing to the red/green bars.
It seems to me the people who designed this NTSC/PAL switcher board did a huge mistake. The dot clock and color clock should always be perfectly in sync at a ration of 4/9 for PAL and 4/7 for NTSC.

It seems they are not in sync when you're using PAL. That's the cause of your red/green bars.

You can't simply use a cheap passive crystal to generate frequencies, they must be tuned using a variable capacitor and they didn't do that last critical part. That's why TOLB and LumaTOLB use an active oscillator. It's more expensive but it's simpler to use and it's perfectly accurate with no required tuning.
Wealth, like happiness, is never attained directly. It comes as a by-product of providing a useful service. -Harland D. Sanders

banman
Member
Member
Posts: 76
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman » Fri Jan 31, 2020 1:32 pm

Hi eslapion,


I missed that detail entirely...... :o

I need to go back and do more oscilloscope readings on the board as you suggested in another thread.

I was sloppy and didn't do my homework :oops:


https://dustlayer.com/c64-architecture/ ... your-clock


They actually discuss the fine adjustment of the factory trimmer capacitor in this thread and I didn't twig on to it.......


PostPosted: Fri Oct 17, 2014 9:12 pm Post subject: Reply with quote
Do you have a frequency counter oscilloscope ?

You amiga need to adjust the trimmer capacitor to fine tune the crystal frequency.

Ps, Please start a new thread for the fault when you get to it.



Thanks for your valued input...... :)

rmzalbar, maybe politely contact your supplier and report your issue.

They may have a simple fix for you they can mail out to you.

I am certain that the manufacturers of this equipment would want to maintain a very high level of customer satisfaction by remedying any faults/ concerns related to this item you purchased in good faith.

It wouldn't look good for them regarding future trading..

Please let us know how you get on.........

rmzalbar
Member
Member
Posts: 54
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar » Sat Feb 01, 2020 9:28 am

eslapion wrote:
Fri Jan 31, 2020 7:10 am
rmzalbar wrote:
Thu Jan 30, 2020 9:22 pm
What I do notice is that the red/green bar pattern frequency is spaced exactly the width of the characters on the screen - 8 pixels? - the AEC frequency? There is a Lumafix integrated onto the board, but adjusting it only affects the luma AEC bars, it does absolutely nothing to the red/green bars.
It seems to me the people who designed this NTSC/PAL switcher board did a huge mistake. The dot clock and color clock should always be perfectly in sync at a ration of 4/9 for PAL and 4/7 for NTSC.

It seems they are not in sync when you're using PAL. That's the cause of your red/green bars.

You can't simply use a cheap passive crystal to generate frequencies, they must be tuned using a variable capacitor and they didn't do that last critical part. That's why TOLB and LumaTOLB use an active oscillator. It's more expensive but it's simpler to use and it's perfectly accurate with no required tuning.
Hmm. Well.. the C64 does have a variable capacitor and a passive crystal in the discrete clock circuit to begin with, and the tunable capacitor is still in-circuit. The board itself just routes the crystal line through one or the other crystal.

I did use my oscilloscope to tune the C64's color clock capacitor as close as possible - of course, it's under the board, so I had to do several iterations of tuning, I could not do this live and watch the effect. However, the dot clock seems to be generated by the same chip, so what needs to be done to tune them relative to each other?

rmzalbar
Member
Member
Posts: 54
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar » Sat Feb 01, 2020 9:47 am

banman wrote:
Fri Jan 31, 2020 5:53 am
Hi rmzalbar,


I just noticed this....
rmzalbar wrote:
Thu Jan 30, 2020 9:22 pm
With regards to the jumper - the C64 is working and is PAL-aware: peek(678) contains 1 in this mode. Loading GEOS and timing its RTC shows it to be 12 seconds fast (as it should be with a 60hz AC frequency in PAL mode.) Games and loaders all work fine.

Is that a typo regarding the PAL frequency. It's just we have 50hz 230v in Australia.

All the PAL TVs here are 50hz. If you look at the screen shot in this discussion earlier the PC LCD monitor runs at 50hz.
Maybe try adjusting your PC LCD monitor clock to 50hz and see if there is a difference...

What upper and lower frequencies are you obtaining on pin 1 of your 6510?

I snagged this from a web site......
MOS Technology 6510/8500 @ 1.023 MHz (NTSC version) @ 0.985 MHz (PAL version)

If all is good in those areas and you can categorically rule out incorrectly wired NTSC and PAL jumper settings it seems that the focus is now on the PAL VIC II chip or maybe the NTSC RF modulator.

Can you temporarily de solder the RF modulator to see if that makes a difference?


What happens when you play a PAL game? Do the bars remain there?

When your 2nd C64 arrives from Europe you can temporarily switch out some parts to test against.
Yes - the situation is that I have a few displays capable of handling PAL and NTSC; they switch between 50hz and 60hz depending on the video signal they receive, rather than the mains frequency. As I am in the USA, the C64 is receiving 60hz frequency on its 9VAC power input. This does not prevent a PAL C64 from operating at the correct speed, as it uses a DC-powered clock generator for everything, with one exception: The RTC (real-time clock) built into the CIA chips use the mains frequency as a timing reference, by reading a square wave triggered off the the 9VAC input. This is not of much consequence because nearly nobody uses the RTC for anything. GEOS does, to show you the time; and of course this will run too fast if the C64 is in PAL mode but running off 60hz mains. A few games might use the clock for event timing, but I can't think of any; Beach Head apparently won't advance past the title screen if you don't have RTC running at all (some people feed 12VDC in place of 9VAC because it's easier to find a power supply to do that.) Nearly everyone uses the much more useful jiffy counter because it has finer resolution and is synced to vblank.

Removing the RF modulator entirely is not really testable, as it's needed for color generation; a simpler substitute circuit can be used which removes RF but sharpens the video output. I think eslapion has hit it on the head however with a mismatch in phase between dot and color clock. Now to determine what to do next.

The color bars are visible in games, more or less visible depending on the colors used and how much fine detail there is. I notice it, but it doesn't dominate.

User avatar
eslapion
Member
Member
Posts: 897
Joined: Mon Jul 20, 2015 10:11 am
Location: Canada
Contact:

Re: PAL red/green color moire, not in NTSC

Post by eslapion » Sat Feb 01, 2020 4:18 pm

rmzalbar wrote:
Sat Feb 01, 2020 9:28 am
I did use my oscilloscope to tune the C64's color clock capacitor as close as possible - of course, it's under the board, so I had to do several iterations of tuning, I could not do this live and watch the effect. However, the dot clock seems to be generated by the same chip, so what needs to be done to tune them relative to each other?
You're saying total nonsense here. When you use the VIC-II2, the C64's capacitor and crystal is UNUSED. This board doesn't know what type of C64 board it's going to be installed on so it carries both frequencies since you have both types of 656X. They are clearly marked 'NTSC crystal' and 'PAL Crystal'.

On PAL systems, the dot clock is 4/9 of the color clock and on NTSC systems, the dot clock is 4/7 of the color clock. The VIC-II2 board takes care of the conversion depending on the system/video chip you selected.

The VIC-II2 has it's own 14.31818MHz crystal and it's own 17.7344 MHz crystal. You could completely cut off the crystal that's on the C64 board and everything would still work.

You can check for these frequencies on pin 21 of the 656X. Sidenote: You're going to fry the 6567R8 if you don't put an adequate heat sink on it.
Removing the RF modulator entirely is not really testable, as it's needed for color generation; a simpler substitute circuit can be used which removes RF but sharpens the video output.
That happens to be false. You can tap the chroma directly on the VIC-II. As a matter of fact, it's too strong for S-Video and has to be reduced in intensity with a voltage divider. Two simple resistors can do it.
I think eslapion has hit it on the head however with a mismatch in phase between dot and color clock. Now to determine what to do next.
I NEVER said anything like that!!

If the color clock is wrong, everything else is derived from it* so everything else will be wrong too. It only needs an error of less than 0.1% for the colors to go wrong. Correctly tuned crystal usually have an error of about 50ppm or less, that's 0.0003%.

* On PAL C64, that's phiColor=17.7344 MHz, phiDot=(4/9) x phiColor=7.882MHz, phi0=(1/8) x phiDot=0.98525MHz
Wealth, like happiness, is never attained directly. It comes as a by-product of providing a useful service. -Harland D. Sanders

Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 2 guests