>>> 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. Looking at it again: the XSC bits actually say at which 8MHz cycle the character shift reg does a load (the other cycles it does a shift). > Hmmm, one would think, implementing horizontal smooth scroll requires > something which is clocked by the dot clock; and at the same time, it > needs to be completely sync-ed to the bitmask data fetch, something > like > "fetch bitmask data, and store it in a temporary register for 0...7 > dot > clock cycles, until it can be loaded into the pixel shift register"... > In other words, one would expect yet another temporary register here, And there is. Three latches in a row, transparent on phi1,phi2,phi1- and-8phi2. For the sprites, there is no such thing, it looks like it messes up big time if it loads while it is displaying. But since it is loaded well off-screen, you'll never see :-) Btw, fun trick on the output of all those shift regs, for the multi- colour mode: there are two output bits, the highest two bits in the shift reg; if MCM=1, this is latched every second cycle; if MCM=0, it is latched every cycle, and the low bit is forced to 0. So the effect of that is that you always have "multi-colour" out, but only 00 and 10 if MCM=0 :-) > since graphic bitmask fetch can't be done into the pixel shift > register > directly (...due to the fact that Phi0 and (8*dot clock) are generally > out of phase), once horizontal smooth scroll is implemented and > used. Is > that so? The clocks are perfectly in phase: in fact, the low bits of the "X counter" are just all the separate clocks. Phi0 is a slightly delayed version of phi2, which is (the second phase of) the input clock divided by eight. > AFAIK there aren't any badlines on the VIC-I That's right, exactly my point -- it has only half the horizontal resolution of the VIC-II, so naturally it can get twice the memory accesses in the same time. Which leads to really simple logic, almost no buffering. Segher Message was sent through the cbm-hackers mailing listReceived on 2011-09-04 08:00:08
Archive generated by hypermail 2.2.0.