Re: TED badlines, how do they work?

Hi!,


On 2011-09-01 18:26, Gerrit Heitsch wrote:
> Hello,
> 
> I'm trying to understand how the TED handles the badlines it needs to
> get character and attribute info.
> 
> 
> TED on the other hand has only 8 Bits on the data bus and 8 Bit
> attributes so it needs 2 badlines per character row, one for the
> character pointer and one for the attributes (color, brightness, flash).
> It also needs 2 internal RAM blocks of 40 x 8 Bits. 

Correct.

> The problem I see is
> that in order to produce a correct character row all the information
> necessary for that row needs to be present at all times. So you cannot
> just have one badline at the first raster line and one at the second
> raster line of a character row since that would mean that you don't have
> the correct attributes during the first raster line.
> 
> The only working way I could come up with is that the badlines happen at
> the last raster line of the preceeding character row and at the first
> raster line of the current character row.

Correct.

> Also the access timing for the internal RAM blocks and system RAM access
> needs to differ between the 2 badlines. During the first badline (at the
> end of a character row) TED first hands the Byte from internal RAM to
> the video logic and then replaces it with the one it read from system
> RAM during the next cycle since it no longer needs the internally
> buffered Byte by then. During the second badline, TED first grabs a Byte
> from system RAM, stores it internally and then uses it together with the
> data from the character ROM it gets in the next cycle.

Yes, some difference is evident. During the first badline, the mask to
be displayed is still pointed to by the character code in the internal
ram; during the second badline, the color to be displayed is the value
that has just been read from ram. AFAIK that one is done by some
multiplexing (whose control input comes from a flip-flop, that tells
whether it's a "first" or "second" badline).

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

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

BTW, I thought that these internal rams were in fact 40-stage shift
registers (2x8) with feedback paths. Normally, the feedback is in
effect, and the shift registers simply count 40 cycles a row, ie. one
round. Only a single position (probably at the point of the feedback
path) needs to be used by the video display logic at a time. Badlines
simply affect how the feedback path works - if new data is being read,
the feedback bit would be simply thrown away, and the newly read bit
used and shifted in. In the case of the Plus/4, the badline logic should
generally only differ from the VIC-II in how this read / reload logic
here was implemented. Unless I'm missing something, for the "first"
badline, it's enough if the value of the current position of the
shiftreg is displayed (used for graphic mask fetch), and the value read
by the DMA logic is shifted in. For the case of the "second" badline,
the value read by the DMA logic is both displayed (...better said: put
in a 1-cycle temporary storage and then displayed) and shifted in. Maybe
there isn't a dedicated 1-cycle "delay" storage, only the tap position
where the value to be displayed comes from, is located one position "forth".

> I have no idea if that's the way it's really implemented but that's the
> only way I could come up with that would work. Looks like a rather
> complicated state machine though, especially at the end of the screen.
> 
> Also, TED seems to be the only MOS video controller that needs 2 badlines.
> 
> I'm open for suggestions and corrections.

IMHO your best bet should be analyzing some emulators code. Both Yape
and plus4emu implements TED internal logics incredibly well... they
usually run even the most trickiest codes. You probably can't inspect
Yape's code, because it's closed source, but plus4emu is opensource (you
can download it from sourceforge).


Levente

       Message was sent through the cbm-hackers mailing list