NTSC VIC-20 Video exploration

[JonBrawn]

I wanted to know about the NTSC VIC-20 video, so scope in hand I went exploring. I am thoroughly shocked at how bad it is.

http://www.brawn.org/VIC-20/Video

If you spot anything that looks complete rot please let me know.
If you think of anything that I should have investigated and included, also please let me know.

[mathop]

Not much more to add, just to note FWIW that the C64 has the same issue as the VIC20 where the vertical equalization and sync pulses are not timed correctly, so in theory it should have the same wobblyness at the top.
I did some research about this, documented here. Note that this is about PAL, NTSC should be similar with slightly different timing.
The VIC chip (i.e. not the VIC-II) uses a slightly different method to generate equalization and sync pulses, I think there is a post on this forum here somewhere that describes how it works.

[RobertBe]

...just to note FWIW that the C64 has the same issue as the VIC20 where the vertical equalization and sync pulses are not timed correctly, so in theory it should have the same wobblyness at the top.

For filming a presentation for CLASS 2021, we tried two, different C64's, and both displayed the same shakiness at the top. However, when we used a flat C128 in C64 mode, the screen was rock solid.

Happy New Year!
Robert Bernardo
Fresno Commodore User Group - http://www.dickestel.com/fcug.htm
Southern California Commodore & Amiga Network - http://www.portcommodore.com/sccan
Commodore Los Angeles Super Show - http://www.portcommodore.com/class

[JonBrawn]

Now I'm puzzled...

1) The incoming clock to the 6560 is 14.31818MHz (It's NTSC remember), with a period of about 69.8ns. I shall refer to this as qclk - the base clock for all the timing (or so I thought).

2) The Phi1 output clock on pin 35 that drives the CPU is qclk divided by 14, about 1.02 MHz, with a corresponding period of 978ns

3) For each character displayed the 6560 needs to perform two fetches, one to get the character code and the color, the other to get the bit pattern for the current line of the character from the chargen ROM.

4) from (2) and (3), the period to display a single character is 978ns * 2 = 1.96us

5) Each character is 8 pixels wide, so from (4) each pixel takes 1.96us / 8 to display, i.e. about 245ns.

6) From (1) and (5) we find that the pixel duration in qclk cycles is 245 / 69.8 = 3.5 qclks.

However, 3.5 is not a "normal" number that one would expect to find in a digital circuit. I have starred at my 'scope, and yes, the dot clock rate really is qclk/3.5

I *could* design a circuit that would produce a clock that is qclk / 3.5, but it would require using both edges of qclk to clock a counter.

Does the VIC chip have a PLL on it to get this bizarre dot clock divider? Do any of you know how this works inside the chip?

[Mike]

[...] a clock that is qclk / 3.5, [...] would require using both edges of qclk to clock a counter.

VIC-I gets a two-phase clock (in-phase and inverted, non-overlapping) on pins 38 (Phi2 in) and 39 (Phi1 in).

Does the VIC chip have a PLL on it to get this bizarre dot clock divider?

No. It doesn't need to.

[JonBrawn]

Brilliant! Thanks, Mike, that's just the nugget I needed to settle my mind. Totally obvious (once somebody points it out to you).

Cheers!