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
