Craig,

8k memory is a good amount of memory to do a bit mapped monochrome TV display. A good looking one. I think the direct video input on this 5" el cheapo TV results in a clarity i see so far.

I did a TV vs. VGA display to "get a feel" for the implication and coding possibilities for Horz/Vert Sync operations. One issue was progressive scan vs. interlacing. Interlacing at TV speeds makes Horizonal lines "fuzzy" so the TVT demo does not interlace.

The DS'420 had the Clock Doubler enabled so forward speed was 22.1184 MHz. This rate was needed more for "granularity" of timing than for rate of execution. If you look at the Horizonal Data going out you will see a lot of compensitory "NOP"s:

;	-- pixel cycle --

vid_rld:
	movx	a,@dptr		;2 Fetch 8 bits of Video data
vid_lp:
	rlc	a		;1 Rotate each bit to Video Interface
	mov	pix,c		;2
	anl	dph,#3		;3 Wait .. equiv of one "DJNZ"
 	nop			

The above routine Fetches a byte of pixel data and emits the most sig. bit.

The next routine outputs all but the last remaining pixel bits:

;	-- "inner " pixel cycle --

	nop				;1 Wait .. equiv of movx
	nop				;1
	rlc	a			;1 Rotate each bit to Video Interface
	mov	pix,c			;2
	nop				;4 Wait .. Equiv of one DJNZ
	nop
	nop
	nop

This final part outputs the last pixel and loops to reload another 8 display pixels:

;	-- end pixel cycle --

	nop				;1 Wait .. equiv of movx
	nop				
	rlc	a			;Rotate each bit to Video Interface
	mov	pix,c
	djnz	r2,vid_rld	

You might notice that there's no "INC DPTR" as the DS'420 does this for me. All those NOPs could actually be hard coded to do something else regularly, (like more audio data like the original MAC did, perhaps the SILabs DACS...).

The accuracy and determinism of the code impact the display geometry and apparent clarity. I mentioned i expect to move the display to an "even steven" 14.318 MHz xtal to ease the generation of Video rates and still allowing 19.2 serial input.

regards,
p