Re: TED badlines, how do they work?

> There's IMHO yet one more small detail to consider: the TED starts
> fetching the character data 3 cycles prior to the character being
> displayed (as pointed out previously).

As measured how?  "Being displayed" does not mean "data put on the
LUM/CHROM pins" here (that number is higher), so what does it mean?

> - 1 read character mask (idle, ie. read from $ffff)
> - 2 read character pointer or attribute memory for row pos 1
> - 3 read character mask
> - 4 read character pointer or attribute memory for row pos 2
> - 5 read character mask
> - 6 read character pointer or attribute memory for row pos 3
>
> - 7 read character mask, start displaying mask of pos 1
>
> As you can see, the character pointer is read _two_ cycles prior to  
> the
> point the mask needs to be displayed.
>
> Reading the character mask needs one cycle. Consequently, we seem to
> have an extra cycle in the line.

Dunno.

> I don't actually know if graphic mask fetch for pos 1 were done in (3)
> or (5).

Well that's important data to have isn't it?  At least it _means_  
something :-)

> Ie. I don't know if graphic mask would be done right in the next
> (half) cycle of pointer fetch, or one full cycle later. ...But that  
> one
> can be sorted out (it's just a question of bringing the machine, a  
> small
> trigger code, and an o'scope together).
>
> In any case, it appears that either the character pointer or the  
> graphic
> mask byte needs to be stored temporarily (let alone the attribute  
> data,
> that is displayed 2 cycles past where it's read from system memory).
> That is, unless some clever trick was used in the sram block (...or
> unless I'm completely mistaken).

Oh, almost all signals are latched one or more times, that's perfectly
normal.  Almost nothing is used immediately.  When exactly something  
happens
isn't so interesting, timing relative to other things is :-)


Segher


       Message was sent through the cbm-hackers mailing list