Re: TED badlines, how do they work?

From: Segher Boessenkool <>
Date: Sun, 4 Sep 2011 09:19:50 +0200
Message-Id: <>
>>> BTW, what do you know about how the VIC-II handles attribute data? I
>>> mean: the character pointer fetch / character mask fetch / display
>>> mechanism looks to work straightforward (current character  
>>> pointer byte
>>> is taken from the internal ram bank, whether the cell is being
>>> overwritten or not --> do graphic mask fetch --> mask data is put on
>>> some temporary space, from which it is displayed bit by bit  
>>> (optionally
>>> delayed by 0..7 dot clocks, as defined by bit0..3 of $d016).
>> It's not so much delayed as that those three bits say at what X  
>> coordinate
>> the whole thing starts each line.

Looking at it again: the XSC bits actually say at which 8MHz cycle the
character shift reg does a load (the other cycles it does a shift).

> Hmmm, one would think, implementing horizontal smooth scroll requires
> something which is clocked by the dot clock; and at the same time, it
> needs to be completely sync-ed to the bitmask data fetch, something  
> like
> "fetch bitmask data, and store it in a temporary register for 0...7  
> dot
> clock cycles, until it can be loaded into the pixel shift register"...
> In other words, one would expect yet another temporary register here,

And there is.  Three latches in a row, transparent on phi1,phi2,phi1- 

For the sprites, there is no such thing, it looks like it messes up big
time if it loads while it is displaying.  But since it is loaded well
off-screen, you'll never see :-)

Btw, fun trick on the output of all those shift regs, for the multi- 
mode: there are two output bits, the highest two bits in the shift reg;
if MCM=1, this is latched every second cycle; if MCM=0, it is latched
every cycle, and the low bit is forced to 0.  So the effect of that is
that you always have "multi-colour" out, but only 00 and 10 if MCM=0 :-)

> since graphic bitmask fetch can't be done into the pixel shift  
> register
> directly (...due to the fact that Phi0 and (8*dot clock) are generally
> out of phase), once horizontal smooth scroll is implemented and  
> used. Is
> that so?

The clocks are perfectly in phase: in fact, the low bits of the "X  
are just all the separate clocks.  Phi0 is a slightly delayed version of
phi2, which is (the second phase of) the input clock divided by eight.

> AFAIK there aren't any badlines on the VIC-I

That's right, exactly my point -- it has only half the horizontal  
of the VIC-II, so naturally it can get twice the memory accesses in  
the same
time.  Which leads to really simple logic, almost no buffering.


       Message was sent through the cbm-hackers mailing list
Received on 2011-09-04 08:00:08

Archive generated by hypermail 2.2.0.