Re: Improve Video Counter???

[mjmahon@aol.com (Michael J. Mahon)]

Bryan Parkoff wrote:

<snip>

>	If you intend to implement 256 colors per pixel instead of 16 colors
>per pixel, there must be a big change in the Video Counter because it
>is designed to display 7 pixels per one video cycle.
>	If you want to display 256 colors, you will need one pixel per one
>byte or 7 bytes.  There must be some ways to create 7 sub-cycles so it
>would be 7 bytes per one video cycle.
>	It is impossible, but if you intend to do, you must change or
>increase the frequency for NTSC.  In fact, NTSC will not support more
>than 15KHz for horizontal line and 60Hz for vertical line.  What about
>digital resolution like DVD-ROM movies that they use NTSC TV?
>	It does not make sense because NTSC can only support 8 bits while
>Apple II family still use 4 bits.  Then, we have to add an extra 8
>bits to the Video Counter that it would be 24 bits instead of 16 bits.
> For higher resolutions than 640x200 resolution, Video Counter will
>have to use 32 bits.

Let me suggest another way to think about the problem.

It is a problem of bandwidth.  How much video refresh bandwidth
can be sustained?  the answer will set a limit to the product of
the number of pixels per unit of time and the color "depth" of those
pixels.

In the original Apple II's (prior to the //e and //c), only one bank of
memory could be read per video cycle (and there is one video cycle
per processor cycle, alternating).  This means that 8 bits per microsecond
were available.  In a scan line with 40 active microseconds (to allow
the use of an overscanned TV monitor), that means that a total of
320 bits are available.

The logic of the text display clearly preceded the design of the
hi-res modes.  The text display was designed to maximize the
number of characters per line, while preserving the readability of
the characters on a TV monitor (40-column mode).

Maximizing clarity required keeping the number of horizontal
pixels under 300, and, since the number had to be a multiple
of 40, 280 was selected.

When the hi-res logic was designed, it was natural to simply
substitute memory data for character generator line data that
was used to load the video shift register, so hi-res also has 280
pixels in a line.  This left one memory bit unused for pixel data,
so a later revision used it to shift the phase of the shift register
clock to choose between two different "color sets".

When the //e was designed, 80-column text was a must.  Again,
the text logic design preceded the graphic design.  Since double
the bandwidth was required, a parallel (auxiliary) bank of memory
was added to provide it.

Later, it was observed that if the auxiliary memory was enlarged
to parallel the existing hi-res pages, that the shifting mechanism
could be exploited in a way very similar to the hi-res case to get
double-hi-res graphics.

Since now twice as many pixels per line were available, in
mnochrome mode, the DHR display has twice as many pixels,
or 560.

The Apple II graphics system was never designed as a
"conventional" graphics system (at least until the pallette-
based IIgs SHR modes).  All color was "directly" synthesized
as NTSC "artifact" colors, by the logical scheme used to create
the video signal.

Attempts to re-envision Apple II graphics as "conventional" are
somewhat beside the point.  Apple II graphics are what they are.
There is no Apple software to use any other form of graphics,
so dreaming about what might have been, or could now be, is
also beside the point.  It may be fun, but it isn't real.

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/