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 listReceived on 2011-09-01 20:00:05
Archive generated by hypermail 2.2.0.