that Apple IIgs choose 640x200 resolution for super high resolution,
but it should be 560x192 resolution.
If you replace from 560x192 resolution to 640x200 resolution, all
undisplayed pixels in the top, left, bottom, and right margins can be
displayed. The problem is that it will not work because it is done
with video counter.
Video counter is used to manipulate binary that it can be mapped into
absolute address to display $400-$BFF and $2000-$5FFF.
The problem is that it is designed to support only 16 colors using
standard NTSC, but NTSC can only support maximum 256 colors.
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.
I have studied Video Counter and Video schematic on the Understanding
Apple //e manual. It would be fun to design a video controller card
with NTSC port to handle 256 colors per pixel. It will need 53,760
pixels for 560x192 resolution and 64,000 pixels for 640x200
resolution. It is too much space that it has to take in the memory
space.
Please let me know when you have some ideas to support 256 colors on
Apple //c, //e, and Apple IIgs rather.
Bryan Parkoff