Re: Improve Video Counter???

[BryanParkoff@yahoo.com (Bryan Parkoff)]

>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.

Michael,

    Thank you for the information.  It makes sense that Apple II can't
use 320x200 because you said that it is under 300.  Apple Computer Inc
made wise decision to choose 280x192 resolution.
    You are right that 7 pixels per half video cycle for even and
another 7 pixels per half video cycle for odd to form 80 column text
and DHR pixels that they go into 560x192 resolution.
    Do you think that it is possible to have 256 colors per pixel in
280x192 resolution and 560x192 resolution?  If I am going to implement
that one pixel will be displayed during 1/7 video cycle to create one
of 256 colors?

Bryan Parkoff

>
>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/