Re: TED badlines, how do they work?

From: Hársfalvi Levente <hlpublic_at_freestart.hu>
Date: Sat, 03 Sep 2011 17:35:13 +0200
Message-ID: <4E624931.9090702@freestart.hu>
Hi!,


On 2011-09-02 19:20, Segher Boessenkool wrote:
>> 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.

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,
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?

>> From the
>> other hand, the attribute info needs to be delayed by one cycle (the
>> cycle of graphic data fetch), until it can be displayed. Similarly, even
>> the character pointer data needs to be delayed by one cycle, when the
>> VIC-II is in bitmap mode (ie. the character pointer data is no longer a
>> pointer to the character rom, it's used as attribute info instead, which
>> needs no additional memory fetch). Does the VIC-II have temporary
>> registers for this 1-cycle delay, or does it handle this problem by some
>> other (smart) trick?...
> 
> Yes.  It's the (quite big) structure at the center top in the picture;
> it's 12 bits.
> 
> From there it is moved to immediately left of the colour registers, sort
> of like virtual colour registers (they are used exactly the same).
> 
> When the character # is used to fetch bitmap data (in text mode), it is
> directly put on the address bus (immediately when read from the video
> matrix).

Yet another detail, having been solved...

> Well, so does the VIC (6560/1), and that was simple ;-)
> 
> I don't think there are any complicated state machines really; just a
> bunch of simple ones, that work together in intricate ways.  I.e. just
> like VIC-II :-)

AFAIK there aren't any badlines on the VIC-I (...it'd do twice as much
transparent DMAs for the displaying of the same number of
(twice-as-wide) characters, that's true...). ...For the record, I do
love the VIC-20, being it Commodore's first attempt of producing a home
computer, and the VIC-I being their first attempt to produce an on-chip
composite color video generator. A true, (...well, sort of) living piece
of history... especially if one can get hold of an early-chipset,
PET-keyboard model... :-D It feels pretty raw and coarse, still, one can
already find the roots of most things later seen in a polished form in
the C64, let alone the Plus/4 and C128.


Levente

       Message was sent through the cbm-hackers mailing list
Received on 2011-09-03 16:00:21

Archive generated by hypermail 2.2.0.