> Thanks for the info. So, if I get that correctly, the temporary > space is > in fact sram, yet, the active row is selected by a shift register > (ie. a > single bit in a shift register). Yeah. You could instead do a binary counter and decoder, but this is a lot simpler eh :-) > Also, as this is really sram, I suppose, only one cell ("address") of > the bank can be accessed at a time, whether written or read (or both). Only one row is accessed at a time, yes. In principle you could write all rows at the same time; reading won't work, of course. > 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. > 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). >> I have no idea about TED badlines, never seen one or programmed one. >> Where do I read about it? > > I'm afraid there aren't any precise docs that describe them in good > detail. In principle, they work similarly to those of the VIC-II. In > practice, there are a lot of little details, which make the state > machine a lot more complicated... probably all due to the fact that > the > TED has no dedicated color ram, ie. it needs to do two DMA fetches to > display a single character row. 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 :-) Segher Message was sent through the cbm-hackers mailing listReceived on 2011-09-02 18:00:08
Archive generated by hypermail 2.2.0.