candle wrote:
my fault, i though about 7mhz, at 3.5mhz it works now producing 320x200 and 1bit/pixel at 15.65khz of line frequency
Weird -- I still only get 223 pixels given those frequencies, only 200 of which could ever be visible (22 pixel times would be devoted to sync/blanking). You would need at least (15650 Hz)(320 pixels) = 5.008MHz for the dotclock to get a true 320 pixels on the display. And this doesn't consider blanking or syncing; that might require an additional MHz or two (figure 400 pixels on a line, 320 of which are visible on the screen, then you need 6.26MHz for the dotclock).
Are you using the high AND low halves of the clock signal? In other words: (a) A new byte is loaded every four cycles, (b)
every edge, both rising and falling, causes a bit to be shifted? If so, then this is equivalent to using a 7MHz clock, which would meet timing constraints.
Remember the Commodore 64 used an 8.064 MHz dotclock for the NTSC version of its VIC-II chip (HT=512 pixels even), and IIRC, 7.36 MHz for its PAL version (HT=470 pixels) to get a 320 by 200 pixel display. About 51/47 (NTSC/PAL) pixels were used for horizontal timing requirements, and 141/103 (NTSC/PAL) pixels were used for the border around the actual image. (NOTE: My numbers are estimates, based on back-of-the-envelop simple math, and does not constitute a detailed analysis.)
In your circuit, you obviously can decide whether or not you want a border. The advantage to the border is that your generated image doesn't go off into the television's overscan area. The disadvantage is that it increases the dotclock (since you have more pixels per horizontal line) somewhat.