Re: TED badlines, how do they work?

On 2011-09-03 14:24, Segher Boessenkool wrote:
>>>  From that picture, I'm pretty sure it is a single 16x40 RAM.
>>
>> Looks like that to me too, but TED only has an 8 Bit data bus so there
>> must be a way to select upper and lower half of the RAM.
> 
> The way the RAM is written would make this automatic: when you write
> to the RAM, the drivers (coming from the data bus) overpower the coupled
> inverters in the selected bit cell; when you're not writing, they don't,
> and the bit cell keeps its value (the reading circuitry doesn't destroy
> the stored value, like with DRAM).
> 
> So it's really easy to write only one byte of a 16-bit word: simply do
> not drive the bitlines of the other byte.
> 
> I don't see how the timing with two badlines can work, unless the RAM
> can read and write the old and the new value at the same time.  Or maybe
> that's interleaved, hrm...  While reading the bit pattern for char N on
> a text line from memory, read the character pointer and attr for char N+1
> from the SRAM; on the next memory clock, write either the char pointer
> or the attr from memory to the RAM.  That makes everything completely
> symmetric between char pointer and attr (the only difference is what
> side is written); it requires the SRAM to be run at 2MHz (the VIC-II
> runs it at 1MHz).

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).

On a badline, things start 6 half clock cycles prior the time the first
character would be displayed on the screen. AEC having had gone low, the
process could be visualized somehow like this:

- 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.

I don't actually know if graphic mask fetch for pos 1 were done in (3)
or (5). 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).


Levente

       Message was sent through the cbm-hackers mailing list