Re: TED badlines, how do they work?

On 09/01/2011 09:20 PM, Hársfalvi Levente wrote:
>
>> Memory access to system RAM during badline 1 would look like this:
>>
>>   CACACACACACA
>>
>> Badline 2:
>>
>>   ACACACACACAC
>>
>> A = Attribute or character pointer load
>> C = Character ROM access.
>
> One thing is sure, in practice, the badline timing is always the same,
> whether it's currently a "first" or "second" badline. As to how the
> values read by the DMA are used, is another question.
>
> BA is pulled down 6, AEC 3 cycles before the start of the character
> area. The TED has 6 half cycles to organize things, before the first
> character mask needs to be displayed. The first one is actually always
> idle (read from $ffff).
>
> I'd doubt that roles could be reversed (ie. the TED would swap
> pointer/attribute fetch and graphic fetch roles of half cycles). That
> one both looks complicated to do at the first place, and would most
> probably also be reflected by detectable behaviour of the character
> counter logic ($ff1a/$ff1b), which is, in practice, not the case.

The problem is, during the first badline, TED has to grab data from 
character ROM first before it can put a new byte into internal RAM. 
During the second badline it has to grab the character pointer first 
before being able to use it in the next cycle for the access to the 
character ROM. The only way I could see that work differently would be a 
1 Byte buffer to allow the first badline to swap accesses. (get 
attributes for next row first while keeping the old data from that 
position in said buffer and then use it for the last time).



> IMHO the counters, timing, etc. are all likely to be the same, the
> different internal ram read/reload cases appear to be handled internally.

Yes, but you already have 2 RAM blocks with their own access control.

I doubt we will be able to solve this until we get hi res die shots of 
TED though. The one available at

  http://plus4world.powweb.com/images/hardware/ted_die.jpg

doesn't help much. There is still a lot of logic visible on it though 
and TED doesn't have to accomodate sprite logic. So I could imagine a 
more sofisticated state machine for character and attribute fetches 
(compared to VIC-II).

  Gerrit



       Message was sent through the cbm-hackers mailing list