TV output on low-cost portable computers

[Dave Long]

> A normal NTSC frame contains 525 lines, of which 485 are active.  If
> you were to display 640x480 pixels, you'd need to emit a pixel 640
> times in 52 microseconds, or once every 81 nanoseconds --- a dot clock
> of about 12 MHz.  A microcontroller clocked at 20MHz would have a hard
> time keeping up with this; perhaps the 70MHz LPC2101 ($1.75 in
> quantity from Digi-Key) could cope, but it doesn't have enough RAM for
> a framebuffer, barely enough for an 80x24 character generator.

the 2600 (1Mhz 6502 variant driving a 160x192 TV display) used a very 
primitive sprite system, in which one would set up a few registers per 
scanline, to avoid the need for a framebuffer.  (it gets worse: to save 
on hardware, and perhaps carry delay, the pixel clocks don't even count 
in binary, but use LFSR sequences -- you can compare two values to see 
if they coincide, but extracting distances gets difficult)

http://en.wikipedia.org/wiki/Television_Interface_Adapter
> Programming for the TIA is very hard work. Such huge limitations as 
> the lack of a framebuffer, and the fact that 3 pixels clocks elapse 
> for every CPU clock make life hard for the programmer...

http://atarihq.com/danb/files/stella.pdf
> The actual TV picture is drawn one line at a time by having the 
> microprocessor enter the data for that line into the Television 
> Interface Adaptor (TIA) chip, which then converts the data into video 
> signals.  The TIA can only have data in it that pertains to the line 
> being currently drawn, so the microprocessor must be “one step ahead” 
> of the electron beam on each line.  Since one microprocessor machine 
> cycle occurs every 3 clock counts, the programmer has only 76 machine 
> cycles per line (228/3 = 76) to construct the actual picture (actually 
> less because the microprocessor must be ahead of the raster).  To 
> allow more time for the software, it is customary (but not required) 
> to update the TIA every two scan lines.  The portion of the program 
> that constructs this TV picture is referred to as the “Kernel”, as it 
> is the essence or kernel of the game. In general, the remaining 70 
> scan lines (3 for VSYNC, 37 for VBLANK, and 30 for overscan) will 
> provides 5,320 machine cycles (70 lines x 76 machine cycles) for 
> housekeeping and game logic.  Such activities as calculating the new 
> position of a player, updating the score, and checking for new inputs 
> are typically done during this time.

and according to the same file (which also has SECAM comments) 
adjusting for PAL is mostly a matter of timing:
> PAL 1. The number of scan lines, and therefore the frame time 
> increases from NTSC to PAL according to the following table:
> 		NTSC                   PAL
> 		scan 	micro 		scan		micro
> 		lines    seconds      	lines  	seconds
> VBLANK 	 40 		 2548 		 48 		 3085
> KERNAL	192		12228		228		14656
> OVERSCAN 30		 1910		 36		 2314
> FRAME	262		16686		312		20055
>
> 2. Sounds will drop a little in pitch (frequency) because of a slower 
> crystal clock.  Some sounds may need the AUDF0/AUDF1 touched up.
>
> 3. PAL operates at 50 Hz compared to NTSC 60Hz, a 17% reduction.  If 
> game play speed is based on frames per second, it will slow down by 
> 17%. This can be disastrous for most skill/action carts.  If the NTSC 
> version is designed with 2 byte fractional addition techniques (or 
> anything not based on frames per second) to move objects, then PAL 
> conversion can be as simple as changing the fraction tables, avoiding 
> major surgery on the program.

-Dave