Re: TECH: AppleColor RGB Sync frequencies and dots sent Question

[Eric Jacobs <mkjacobs@erols.com>]

Mitchell Spector wrote:
> 
> In article rubywand@swbell.net writes...
> >
> >     Right; which brings up another question: Including the left and
> >right borders, how many dots are actually sent per line in 320 and 640
> >modes?
> 
>     The answer is given in your question. The border area may give you
> a smaller viewable area, but that doesn't change the number of pixels
> used on screen. You get 320 pixels horizontial by 200 pixels vertical,
> or 640 pixels horizontial by 200 pixels vertical. Go load up a paint
> program and draw a line pixel by pixel, while counting each, and you
> will come up with exactly that number of pixels (make it full screen
> though, the menubar or window area will occupy some of those pixels).

I think you misunderstand what rubywand was asking. Including the left
and right borders, plus the horizontal retrace, the video sends out
more than 320 or 640 "dots" before the screen begins scanning the next
line. Here's a quick summary of the Apple II video that's been used
throughout the whole series (assuming 60 Hz video here). It's a slightly
modified NTSC signal, though the differences are small enough for
most monitors to accomodate.

Everything in the Apple II is derived from a 14.31818 MHz master
clock. This runs both the video and the processor/memory subsystems.
The cycle time is therefore 69.8 ns. For 640-mode (or 80 cols, or
double-hires) the dots are sent out at simply this rate. In 320-mode
(40 cols or single-hires) the dots are sent out at half that rate,
7.15909 MHz (one pixel every 139.6 ns). The NTSC standard calls for
227.5 cycles of color reference (3.579545 MHz) per horizontal line,
for a horizontal scan rate of 15.734 KHz (3.579545/.2275). The Apple II
rounds this up to 228 cycles of 3M, so the horizontal scan rate is
15.699 KHz (3.579545/.228). This is well within the tolerance of most
monitors. So therefore in 320-mode 228*2 = 456 "dots". In 640-mode
there are 912 "dots". I put dots in quotes because, obviously, only
320 or 640 of them are actually seen as part of the screen.

When the GS is outputting a composite video signal, each horizontal line
must contain a horizontal sync pulse and color burst, and there can't be
a border during this time, or else the TV won't register a sync. On the
RGB, the GS puts the border color on. So, the answer to your question
is 456-320 or 136 pixels in 320-mode and 912-640 or 272 pixels in 640-
mode. This includes both borders and the horizontal sync. Of course, a
good proportion of this time is not visible; this depends on the overscan
settings of the particular monitor.

Since the processor clock and the video clock are derived from the same
source, it's easy to write an assembly-language subroutine that keeps in
sync with the dot clock. This is how the FTA did their little border tricks.
The catch is that the GS must be switched into "Normal" (IIe) speed. The
processor will then clock at 14.31818/14 = 1.0227 MHz. At this speed, one
processor clock is equal to a single 40-column text mode character (7 pixels).
One line will then fit an even 65 characters (455 pixels), plus an extra
pixel. That extra pixel is how the 227.5 rounds up to 228. Since the processor
and video are in sync, it also means that every 65th cycle of the processor
is slower than all the rest! This "extended cycle" design is a major claim
of the patents filed for the Apple II, and is also the number one cause of
the abhorrent color fringing on the composite output. As well as the impure
frequency making the Apple II impossible to comprehend on a 'scope.