Re: Create Text & High Resolution into Screen

["Bryan Parkoff" <BParkoff4@satx.rr.com>]

    You claim that 40 column uses 7 pixels while 80 column uses 14 pixels.
I would have to disagree because 40 column uses A PAIR OF PIXELS to form 14
pixels that looks like 7 pixels.  Read below.
    In fact, both 40 and 80 columns still use 560x192 resolution.  Both GR,
HGR, and DHGR still use 560x192.  It is true that it makes you to think that
it is really 280x192.  When you use 40 column, GR and HGR, it always paints
A PAIR OF PIXELs each pixel.  It is a lot of trick to make us think that
way.  80 column and DHGR do not use A PAIR OF PIXELs so it uses one pixel
each pixel.
    Only NTSC monitors and TV display 560x192, but outside of 560x192 are
blank or unused.  I have no idea how RGB monitor for Apple IIgs can match
560x192 to 640x400 for GS/OS.  It makes us puzzled.  How can we recognize
the blue border around 560x192 before we switch to 640x400.  Didn't the blue
border stretch little bigger allowing 640x400 to fit?  If 640x400 switch to
320x200 for GS/OS 40 column.  It may still use A PAIR OF PIXEL each pixel.
It is unlike VGA monitors that they never use PAIR OF PIXELS.
    Please tell me if you have any ideas?

-- 
Bryan Parkoff

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20030913043323.19898.00001185@mb-m28.aol.com">news:20030913043323.19898.00001185@mb-m28.aol.com...
> Bryan Parkoff wrote:
>
> >    I understand that every 6502's half cycle reads $400-$7FF for Text
Mode
> >and $2000-$3FFF for HGR Mode before second half cycle paints 14 pixels to
> >the screen.  I think that Text Mode has to paint 56 pixels (7x8) to the
> >screen each Text character during every second half cycle, but only 14
> >pixels will be painted for HGR Mode.  Do you see the difference between
56
> >pixels and 14 pixels?
> >    Read $400-$7FF and $2000-$3FFF will do to paint 56 pixels and 14
pixels
> >(every time until 64 times) or (64 times) (64 cycles out of 65 cycles)
What
> >happen if it reaches to 65 out of 65 cycles)?  Will it reset back to 0
out
> >of 65 cycles to start over to repeat from the beginning?
>
> Actually, one byte (two bytes for 80 columns or DHR) is read each cycle,
> during the half-cycle that the processor does not access memory.
> During the _entire_ cycle, that byte (two bytes) is shifted out to form
> 7 (or 14) pixels in the current horizontal line.  (BTW, Apple II
> characters are 5x7 pixels in a 7x8 matrix--that's 5 character pixels
> per scan line plus 2 background pixels, for character spacing, and
> seven lines with font data followed by a black line for line spacing.)
>
> Since the characters are painted line-by-line, only 7 pixels per
> character need to be painted in each cycle (for 40 columns) or
> 14 pixels (for 80 columns)--thus, 280 or 560 pixels per line.
>
> Since the active scan line is only 40 cycles per line (the rest of the
> line is blanked), it doesn't matter to the display what data is read
> during the 15 cycles of horizontal blanking.  (Some clever code
> can determine what data is read during these "invisible" refresh
> cycles, and use it to synchronize processor execution with the
> video generator.)
>
> It is important that the video generator continue to cycle through
> a range of memory addresses that ensures that the DRAM refresh
> period is met.  One of the clever things about the Apple II is that
> "video refresh" is organized so that it also accomplishes "DRAM
> refresh".  This is what accounts for the "unusual" mapping of
> text page addressed to screen positions and hi-res addresses
> to screen positions.
>
> -michael
>
> Check out amazing quality sound for 8-bit Apples on my
> Home page:  http://members.aol.com/MJMahon/