PAL red/green color moire, not in NTSC

Disk drives, Monitors, SuperCPU etc.
banman
Member
Member
Posts: 419
Joined: Sat Jun 15, 2019 12:21 am
Contact:

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

Post by banman »

Hi rmzalbar,

I was just looking at my ...407 board and taking a few readings.

I noticed if I set my scope to just look at 1 square wave instead of say looking at multiple waves on a screen the oscilloscope is able to make much more accurate frequency readings. It still fluctuates however it is greatly improved over taking in multiple waves.

Here is what I observed.....
IMG_20200206_160017.jpg
IMG_20200206_155724.jpg
IMG_20200206_155815.jpg

Apologies for the pictures being on their side. I can't seem to rotate them.

To hazard a hypothesis I would say the scope tries to average the multiple waves rather than the single wave.
I will go further (I could be wrong here) the fluctuations I see on just the single wave are actual variations on the C64's wave forming circuitry.

A suggestion you may be able to get greatly improved readings on your oscilloscope as I have if it is set to look at only 1 wave. Adjust your timebase/ sweep dial till you only see one full wave.

I noticed that in an earlier post you showed a picture of your oscilloscope's screen with lots of waves on the display. You mentioned that you were having issues with wide fluctuating readings.

It might be helpful to you, just a thought......




The pictures are from my setup. The numbers I am reading might give you a ball park figure.


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

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

Post by eslapion »

banman wrote: Thu Feb 06, 2020 6:34 am To hazard a hypothesis I would say the scope tries to average the multiple waves rather than the single wave.
Not quite. But it's difficult to explain, long and tedious.
I will go further (I could be wrong here) the fluctuations I see on just the single wave are actual variations on the C64's wave forming circuitry.
Yes. That's why using TOLB with an active oscillator which is extremely stable does improve image quality.
A suggestion you may be able to get greatly improved readings on your oscilloscope as I have if it is set to look at only 1 wave. Adjust your timebase/ sweep dial till you only see one full wave.
Yes. However, I have to add that your setup with this little 'pickup' probe and long yellow wire adds parasitic inductance so your scope gets a poor quality signal with lots of ringing.

Also, I see you have the CPU clock on your scope. Why don't you try the more challenging color clock which is on pin 21 of the VIC-II.
I noticed that in an earlier post you showed a picture of your oscilloscope's screen with lots of waves on the display. You mentioned that you were having issues with wide fluctuating readings.
Yes. Older/cheaper scope can only trigger on one channel so you'll get junk if you display signals with 2 different frequencies.

The TOLB captures I did 2 years ago with my TDS-3014B requires trigger conditions for 2 channels since I'm displaying 2 channels with 2 completely different frequencies. See: http://sleepingelephant.com/ipw-web/bul ... 9&start=13

You can see the TDS-3014B doesn't have a trigger frequency counter in the lower right corner like the TDS-1002. So this older cheaper scope has an invaluable feature the bigger guy doesn't have.
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: 419
Joined: Sat Jun 15, 2019 12:21 am
Contact:

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

Post by banman »

Hi eslapion,
eslapion wrote: Thu Feb 06, 2020 7:45 am Yes. However, I have to add that your setup with this little 'pickup' probe and long yellow wire adds parasitic inductance so your scope gets a poor quality signal with lots of ringing.

Also, I see you have the CPU clock on your scope. Why don't you try the more challenging color clock which is on pin 21 of the VIC-II.

Absolutely, my setup is very much the train wreck! :)

I will get back and tidy it up and have a better look on the oscilloscope...

You are right that is the PAL frequency for the 6510 CPU in my posted images.

I think in those shots I am taking readings off pin 9 of u29. It looks like a nice square wave. It was stable (as can be) too.

I am thinking does this circuitry take the analogue crystal oscillator waveform and reshape it to a square wave so it's easier for the other parts of the computer to recognise and use?


I will take up the challenge of looking at pin 21 on the VIC II chip. :D

I was wondering I am getting a wave very similar to your channel 1 oscilloscope pictures that you put a link to in your above post.

I took my reading from u31 pin 10. I think it's just the PAL crystal oscillator waveform. It is not a very sinusoidal looking wave in that it has a few plateau like features. I am not sure how to interpret them.
I would have imagined that they would be a nice sine wave shape to it. Maybe (probably) I'm doing it wrong.

So the 'TOLB' will actively maintain a square wave at the appropriate PAL or NTSC clock frequencies with better life span than the original Commodore factory monolithic chip (MOS 8701)?

WIll it work in the new Commodore Reloaded board?

How does the power consumption rate?

I am assuming that this is only suitable for later model C64 boards that have the 1 chip timing solution.

Can it be modified to fit all the C64 boards?
User avatar
eslapion
Active Member
Active Member
Posts: 1215
Joined: Mon Jul 20, 2015 10:11 am
Location: Canada
Contact:

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

Post by eslapion »

banman wrote: Thu Feb 06, 2020 9:38 am You are right that is the PAL frequency for the 6510 CPU in my posted images.

I think in those shots I am taking readings off pin 9 of u29. It looks like a nice square wave. It was stable (as can be) too.

I am thinking does this circuitry take the analogue crystal oscillator waveform and reshape it to a square wave so it's easier for the other parts of the computer to recognise and use?
U29 only is present on earlier C64 boards which use an antiquated and complex way to derive all other frequencies it uses from the crystal. I couldn't say.

I took my reading from u31 pin 10. I think it's just the PAL crystal oscillator waveform. It is not a very sinusoidal looking wave in that it has a few plateau like features. I am not sure how to interpret them.
I would have imagined that they would be a nice sine wave shape to it. Maybe (probably) I'm doing it wrong.
This is a higher frequency signal and should be close to a square wave. If you tap there, the ground connection must be on the same chip (pin 8). Use an oscilloscope probe 10X only and nothing to 'extend' it.
So the 'TOLB' will actively maintain a square wave at the appropriate PAL or NTSC clock frequencies with better life span than the original Commodore factory monolithic chip (MOS 8701)?
Lifespan, I couldn't say since most C64 boards are more than 35 years old already. The signal quality and stability is better because I'm using a 525-01R to perform the frequency conversion.
WIll it work in the new Commodore Reloaded board?
It works well on the now discontinued C64r MK1. On the MK2, they have hidden everything.
How does the power consumption rate?
TOLB consumes less than 10mA. It's half the power of a green LED.
I am assuming that this is only suitable for later model C64 boards that have the 1 chip timing solution.

Can it be modified to fit all the C64 boards?
LumaTOLB sits under the VIC-II and works on all C64 boards. It probably also works on the C64r MK2 but it's not tested.
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: 419
Joined: Sat Jun 15, 2019 12:21 am
Contact:

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

Post by banman »

Hi eslapion,

eslapion wrote: Thu Feb 06, 2020 11:33 am This is a higher frequency signal and should be close to a square wave. If you tap there, the ground connection must be on the same chip (pin 8). Use an oscilloscope probe 10X only and nothing to 'extend' it.
Thank you for the advice on setting the probe to 10x and taking the probe's ground on the particular chip being tested. Makes sense....



I got a reading from u31 oscillator chip off pin 10 with the probes ground to pin 8 at the just before the start of this ferrite bead component....
IMG_20200207_075840[1].jpg
IMG_20200207_075929[1].jpg
IMG_20200207_075954[1].jpg
Then I took a reading with the probe connected just after the ferrite bead component.

Image

Image









I noticed there wasn't a sharp drop at the bottom of the wave.


From what I can see the ferrite bead is just slipped over a wire.... Amazing what difference it makes to the shape of the wave....



I got a reading from pin21 of the VIC II chip..
I made sure to keep all connections as short as possible.

Image


Image

Image






Here is a reading taken from one of the pins of the PAL crystal. I am not sure if I have the probes ground connection in the right place. It's on the ground pin of u31.....




Image

Image





eslapion wrote: Thu Feb 06, 2020 11:33 am
LumaTOLB sits under the VIC-II and works on all C64 boards. It probably also works on the C64r MK2 but it's not tested.
Image

WOW !
The LumaTOLB! I had to do a quick google search for that. A re-seller in Australia called GameDude sells it for $59 AUD ... :D

That's 2 products in one piggyback unit..would I have to disable anything on the old Factory Commodore timing circuit to install this LumaTOLB??

If I were rmzalbar could I buy the PAL version of LumaTOLB and use it with a PAL VIC II chip in his C64…?


So as I see it the LumaTOLB is about $30AIUD for the TOLB and about $30AUD Luma board...

I had 2 C64 boards that had bad timing circuitry. One a capacitor had leaked and secretly destroyed traces under itself.
The other had a dead 74ls629 chip.

I just did a quick search online for the price of one 74ls629 chip. They want approximately $10 US for a used one!

This would well be worth considering if there were problems around the timing circuity of the earlier C64 mainboards. Quite frankly from my perspective that area of the board is a real pain to work on .... :x






What rock have I been living under!! :o
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

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

Post by rmzalbar »

[Luma]TOLB is exactly what I would reach for when converting between standards, precisely because it does away with the need to calibrate. In fact I should obtain one of each of these for that use, and for spares in case of clock failure.

I went with the VIC-II2 in this case because I wanted the ability to switch, and this does seem to work fine. I should have a genuine PAL machine in my hands in a week or so, and I'll be able to compare behavior and see how the frequency measures out on same equipment.
Smooth operator
User avatar
eslapion
Active Member
Active Member
Posts: 1215
Joined: Mon Jul 20, 2015 10:11 am
Location: Canada
Contact:

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

Post by eslapion »

@rmzalbar
In theory, you could have a LumaTOLB of each version under your 2 VIC-2s and this would solve your problem but that's going to result in a pretty thick stack under the hood of your C64.

@banman
The questions you are asking about LumaTOLB, well, that's something you should already know if you're experienced enough to use the product.

"EXPERIENCED INSTALLERS ONLY"
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: 419
Joined: Sat Jun 15, 2019 12:21 am
Contact:

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

Post by banman »

Hi eslapion,


Well spotted at on the ad..

Oh well, that rules me out...LOL... :lol:


That's an interesting suggestion from eslapion, rmzalbar regarding using the LumaTOLB board with the VIC II2 board.

Maybe even getting by on just 1 just for the PAL side.

When your European C64 arrives you may be able to get a better understanding of those unusual vertical stripes...
User avatar
eslapion
Active Member
Active Member
Posts: 1215
Joined: Mon Jul 20, 2015 10:11 am
Location: Canada
Contact:

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

Post by eslapion »

banman wrote: Wed Feb 12, 2020 5:53 am When your European C64 arrives you may be able to get a better understanding of those unusual vertical stripes...
The understanding is simple.

Both in PAL and NTSC, colors are expressed as phase shifting from a reference signal. In PAL, this signal is 17.734475/4=4.4336 MHz.

However, if the reference generated is so off from the correct frequency that a complete 360 degree error occurs then you see a sort of 'rainbow' bars pattern all over the screen.

Each 'rainbow' represents a full error cycle that occurs on a single scanline.

As I said earlier, it's normal that you'll have a bit of error, usually a max of 50 ppm and that's why some sort of re-synchronization between the TV and video source is done on every scanline during the horizontal blanking interval. However in the case of rmbalzar, the error is so bad that there are multiple complete cycles of error on each scanline.

Added edit: ...could also be cause by ripples in the voltage coming from the power supply.
Wealth, like happiness, is never attained directly. It comes as a by-product of providing a useful service. -Harland D. Sanders
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

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

Post by rmzalbar »

A couple of points..

1. Going to TOLB on just one side is an interesting idea, as I could simply tune to the other standard on the non-TOLB side. Clearance would still be an issue however, as you can see I had to file down one end of each heat sink as it is to clear the keyboard. A custom PCB layout is the real fix, or I could bodge something off to one side.

2. The rainbow effect really only happens in combination with luma activity - solid areas look fine, text is meh, high frequency pattern is worst case. Also it is a faint effect, and I would expect a full phase error to be a vivid color cycling effect. Also the frequency of the effect didn't change when I changed the clock adjust pot. I think the luma is getting mixed in somewhere into the chroma and doing.. what, exactly? I looked at the composite version of the signal in the oscilloscope, and I have to say, I can't see how any decoder could pick out the chroma frequency as even remotely distinct from high-frequency luma shifts, there's barely room for one peak per pixel. Add the RC softening, and I am surprised you can get any sort of good picture at all. But, again.. I get the same effect in Y/C mode! so... huh.

3. Power supply ripple, interesting. Hmm. I'm using a switchmode power supply. Of course, the VIC-II gets its power from the 9VAC, which is transformer; and my oscilloscope shows that, by the time the power gets through the LMs, it's straight-across flat. But! What about the RF modulator that is in-circuit with the output? I will try out my original kamikaze brick to see if it makes any difference.
Smooth operator
Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 5 guests