Re: Blurry picture

From: Segher Boessenkool <>
Date: Fri, 18 Nov 2011 20:52:42 +0100
Message-Id: <>
>> So what causes the stripes? They coincide with AEC/Phi2, but that  
>> doesn't
>> mean it causes it. I don't see anything on the chip that could  
>> cause it,
>> so maybe it is interference on the board?
> Someone in the thread about the modulator removal mentioned that  
> that's how the signal comes out of the chip, so it's likely not the  
> board design.
> Could it be possible that the power consumption of the VIC is not  
> uniform with respect to AEC so that the resistance of the internal  
> traces comes into play? Meaning one of the drivers in the chain for  
> the luma signal has a power supply that fluctuates with the phase  
> of AEC?

As I'm sure you know, there are two power supplies on the VIC: one for
the digital logic, and one for the analog logic.

The analog supply should not draw more power on the leading edge of  
the digital will, but a) it is the wrong supply, and b) it will draw  
more on the leading edge of Phi1, and you get no stripes there.

The spikes are a voltage _drop_ on the luma output, if I understand the
german forum correctly.  This only happens on 85xx parts.  It looks to
me like the analog supply drops a bit.  On the C64C, the analog supply
is just the same 5V supply as the digital supply.  It has its own bypass
cap, but maybe this is not enough?

This hypothesis can be tested, yay!  Anyone want to try?  Put a scope
on the analog Vdd, and/or try a bigger bypass capacitor on it.

>>> What I do notice are the grey dots of the HMOS-II VICs.
>> That seems to be caused by the different boards, not the different  
>> VIC
>> revision: the #CS signal is too early (relative to the data bus),  
>> which
>> means that when you write a colour reg, it first gets written with  
>> all
>> ones, getting the correct colour only later that same cycle. Delaying
>> the #CS signal (adding a cap is enough) gets rid of the dots.
> Maybe in a C64 or C128, but TED shows the same 'feature' and it  
> handles its register decoding internally.

You mean it generates its own #CS from the address pins?  That will  
certainly cause #CS to be active earlier than the data showing up on the
data pins, sure.


       Message was sent through the cbm-hackers mailing list
Received on 2011-11-18 20:00:13

Archive generated by hypermail 2.2.0.