Re: How does NTSC VIC-II produce 65 cycles per line

On 1/12/2023 10:43 PM, Robin Harbron wrote:
> I'd love to hear if anyone has any insights into this.
>
> Adding an extra bit to the X position counter probably would have had 
> far more serious design implications compared to this little hack that 
> could have been added to the already extensive group of horizontal 
> screen position decodes; probably a much less intrusive solution.

I'm no HDL expert, but I'm *assuming* there's a 3 bit counter to count 
off the 8 pixels of the char in the fabric somewhere.  If so, then the 
*hack* would be to do a compare for $188, and then latch that in a bit.  
Then, the output of that latch would be anded with invert of the carry 
on the 3 bit counter, and the output of that would be used to reset the 
latch (when going low) and inhibit the 9 bit counter (when high).  So, a 
single flip/flop and a bit of boolean logic.

Adding in the 10th bit would have made every X "magic value" boolean 
logic instance have to have another input, which was probably considered 
risky, as I think the 65 cycle VIC was last to arrive (so the design was 
already in use, and no one wanted to QA a complete new design.)

It looks like $18c is already boolean decoded as a magic value, so it 
was an easy output to use for the latch and logic.  Past $18c, you're 
just in the front porch, and they probably wanted to inject the kludge 
at a spot before the line blank, which is probably a counter reset that 
resets a while both of things.  And, I think the front porch is the 
least cared about portion of the NTSC signal, since you're just waiting 
around after visible data and overscan is over to run out the clock and 
switch to the next line.  Most digital NTSC devices probably don't even 
look at the signal at that point, until they see the line blank.

It does appear to be a hack, though.  I assume the 65 cycle design was 
because of complaints on sync with certain televisions?

Jim