PAL red/green color moire, not in NTSC
Re: PAL red/green color moire, not in NTSC
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.....
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.
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.....
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.
Re: PAL red/green color moire, not in NTSC
Not quite. But it's difficult to explain, long and tedious.
Yes. That's why using TOLB with an active oscillator which is extremely stable does improve image quality.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. 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.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.
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.
Yes. Older/cheaper scope can only trigger on one channel so you'll get junk if you display signals with 2 different frequencies.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.
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.
Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires. -John Steinbeck
Re: PAL red/green color moire, not in NTSC
Hi eslapion,
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.
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?
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.
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?
Re: PAL red/green color moire, not in NTSC
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.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?
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.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.
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.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)?
It works well on the now discontinued C64r MK1. On the MK2, they have hidden everything.WIll it work in the new Commodore Reloaded board?
TOLB consumes less than 10mA. It's half the power of a green LED.How does the power consumption rate?
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.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?
Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires. -John Steinbeck
Re: PAL red/green color moire, not in NTSC
Hi eslapion,
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....
Then I took a reading with the probe connected just after the ferrite bead component.
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.
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.....
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 ...
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 ....
What rock have I been living under!!
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....
Then I took a reading with the probe connected just after the ferrite bead component.
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.
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.....
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 ...
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 ....
What rock have I been living under!!
Re: PAL red/green color moire, not in NTSC
[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.
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
Re: PAL red/green color moire, not in NTSC
@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"
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"
Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires. -John Steinbeck
Re: PAL red/green color moire, not in NTSC
Hi eslapion,
Well spotted at on the ad..
Oh well, that rules me out...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...
Well spotted at on the ad..
Oh well, that rules me out...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...
Re: PAL red/green color moire, not in NTSC
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.
Socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires. -John Steinbeck
Re: PAL red/green color moire, not in NTSC
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.
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
Who is online
Users browsing this forum: Bing [Bot] and 4 guests