Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!valthoff
From: valthoff@magnus.acs.ohio-state.edu (Victoria M Althoff)
Newsgroups: comp.sys.apple2.programmer
Subject: Hi-res Graphics
Date: 11 Oct 1993 05:07:29 GMT
Organization: The Ohio State University
Lines: 75
Message-ID: <29apmh$der@charm.magnus.acs.ohio-state.edu>
NNTP-Posting-Host: bottom.magnus.acs.ohio-state.edu
Disclaimer:  "Apple" is a registered tm. of You-Know-Who

I have received an EMAIL request to expound upon the design of the Apple ][ 
hi-res/double hi-res screen.  In case others are interested, I post it here.  
As usual, comments, additions, corrections, etc. are encouraged L8-)

You-Know-Who's hi-res pages begin at $2000.  Each occupies 8k of memory; two 
can be displayed.  Hires page 3 ($6000-$7FFF) exists only in the minds of 
certain programmers, as it cannot be displayed.
QUESTION:  Why does hi-res start, inconveniently, in the middle of BASIC 
program workspace (which starts at $800)?
ANSWER:  So that you can display hi-res graphics on an Apple ][ with only 16k 
memory (much more common in 1975 than it is today!)

Those 8k of graphic space are mapped out in a strange way.  If you display the 
hi-res page 1 and start filling the memory spaces from $2000-$3FFF with $FF's, 
you will see the screen begin to fill with white.  First the top line, then a 
line about 1/3 of the way down, then a line near the bottom.  Then the EIGHTH 
line from the top, eight lines below the second line filled, eight lines below 
the third line, then the 16th line.
QUESTION:  WHY?????
ANSWER:  Lots of 6502 graphics programmer would like to know.  Actually, it 
involves saving a couple of chips in the display hardware.  That means saving 
1975-era dollars when chips were expensive.

If you perform the experiment above (from APPLESOFT, try...
]HGR:POKE-16302,0:FOR X = 8192 TO 16383:POKE X,255:NEXT),
you will notice that each line fills in chunks...40 chunks per line, to be 
exact.  Funny how everything on the screen seems to be in 40's!  Each chunk is 
seven pixels, so 7*40=280.  Now for the trickery:  This is (a) how you can 
display four different colors using only 1 bit per pixel, and (b) why BLACK and
WHITE appear twice in the hi-res color chart.

The screen is laid out so that the horizontal position of a pixel will 
determine its color.  All EVEN horizontal positions will be either VIOLET or 
BLUE, and all ODD horizontal positions will be either GREEN or ORANGE.  And, 
there is no such thing as a WHITE point.  Try this:  Using HCOLOR=3 (white), 
try HPLOT 0,0 TO 0,191.  You should get a violet line running down the left 
edge of the screen.  If you then issue a "HGR:HPLOT 1,0 TO 1,191" you should 
get a green line running down the left edge.  Notice that in both cases, you 
use HCOLOR=3, which the Applesoft ][ manual says should be WHITE.  Instead of 
white, you get violet or green!
QUESTION:  How do you get white?
ANSWER:  Plot two pixels side-by-side!  Try this:
]HGR:HCOLOR=1:HPLOT 1,0 TO 1,191:REM You get a green line.
]HCOLOR=2:HPLOT 0,0 TO 0,191:REM Adding the violet line makes both lines appear
white.
This means that you cannot display green and violet in adjacent pixels...the 
result will look white.  This also means that the HCOLOR= command just 
restricts the horizontal positions where pixels will be turned on.
QUESTION:  What about orange and blue?
ANSWER:  Remember that a standard byte is 8 bits?  Remember how only 7 are used
to represent the pixels on the screen?  The 8th bit (128's place) is used to 
select the color set.  This is why white and black appear twice in the color 
pallette:  HCOLOR = 0 and 3 leave the 128's bit cleared, while HCOLOR=4 and 7 
will set the high bit.  Try this:
]HGR:HCOLOR=3:HPLOT 1,0 TO 1,191:REM Plots a green line.
]HPLOT 4,0 TO 4,191:REM Plots a violet line
]HCOLOR=4:HPLOT 3,0 TO 3,191
How's that?  You plot a black line between the violet and green; the green 
turns orange, and the violet turns blue.  The lines also shift a half-pixel to 
one side.  All you did was to turn on the 128's bit in all 192 bytes along the 
left edge of the screen.  That shifted your color set.
OKAY, LET'S REVIEW THE RULES:
1.  Odd columns will ALWAYS be either GREEN or ORANGE.
2.  Even columns will ALWAYS be either VIOLET or BLUE.
3.  When two adjacent columns are turned on, the result will be WHITE.
4.  All pixels in any given byte MUST be EITHER GREEN/VIOLET or ORANGE/BLUE.  
You CANNOT display Green and Blue, Green and Orange, Violet and Orange, or 
Violet and Blue within the same BYTE.  Each byte has its own color-select bit, 
so all four (six if you count black and white) colors may be displayed at once 
on the same screen.

That's the basics of standard hi-res.  I need to get some sleep, so I'll 
briefly mention double hi-res next time (unless someone beats me to it 8-) !)
--Dave Althoff, Jr.
(tired Applesoft Ace)
Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!cs.utexas.edu!geraldo.cc.utexas.edu!sleepy.cc.utexas.edu!not-for-mail
From: foegelle@sleepy.cc.utexas.edu (Michael Foegelle)
Newsgroups: comp.sys.apple2
Subject: Re: Apple IIGS RGB graphics conversion
Date: 12 Jan 1994 12:02:59 -0600
Organization: The University of Texas - Austin
Lines: 110
Message-ID: <2h1e0j$h09@sleepy.cc.utexas.edu>
References: <vantune.758371333@sfu.ca>
NNTP-Posting-Host: sleepy.cc.utexas.edu
Keywords: RGB, Apple IIGS, hi-res, Mega II, VGC

In article <vantune.758371333@sfu.ca>,
Joseph Van Tunen <vantune@fraser.sfu.ca> wrote:
>I want to know how the IIGS converts hi-res and double hi-res into RGB.
  Ok...
>The IIGS Technical Manual says that the Mega II outputs a 4 bit code
>representing one of the 16 standard Apple colors (eg the colors for the IIGS
>border, background and text, or the lo-res or double hi-res colors). The value
>is input into the Video Graphics Controller (VGC) and is used to lookup a 12 bit
>RGB value that is passed to 3 digital to analog converts (one each for red, 
>green, and blue). The RGB values for the 16 colors are listed in a technical
>note.

  Right..  This just means that the actual colors you see on the screen are
mapped to the sixteen bit codes that are programmed in screen memory using the
palette that the VGC looks up.  That is the way any palette based graphics 
system works (like IBM EGA, VGA, etc).  Thus color 5 could be set to solid 
bright blue, being 0,0,15 in RGB.  The default palette is typically set so that
color 15 is white (15,15,15), color 7 is grey (7,7,7), color 14 is yellow 
(15,15,0 or something like that).

>What I need to know is how does the Mega II get the 4 bit code, and how often it
>gets a code. This is what I could figure out:

>Another technote says that every sequence of 4 bits in double 
>hi-res is used for a color (bits 0 to 3, 1 to 4, 2 to 5, etc) with the shifting
>of bits taken into consideration. This suggests that the RGB value is changed
>at a frequence of 7MHz. I know how to convert hi-res bits into double hi-res
>bits (each bit of a hires byte is expanded to two bits, a half dot shift shifts the double hires byte right 1 bit and the right most bit of the previous byte
>goes into the left bit of the double hi-res byte.).

Right.  This means that for hi-res, a byte-to-pixel representation is as 
follows  (I'm using letters to represent numbers greater than 10):

Byte #                  1                2                3
bits of byte --  0 1 2 3 4 5 6 7  0 1 2 3 4 5 6 7  0 1 2 3 4 5 6 7
mono pixel   --  1 2 3 4 5 6 7    8 9 A B C D E    F G H I J K L
color pixel  --   1   2   3   \4 /   5   6   7      8   9   A

Now, for hires, the colors depend on the high bit (bit seven) and adjacent
pixels only.  Thus you have purple/green or blue/orange pairing with high
bits off or on respectively.  Thus the byte:  01101001 would give color 
pixels of purple, orange, small black space, and white, because ANY two 
pixels set side by side gives white, whether it's bits 0 & 1 or 1 & 2 or 2 & 3,
etc.  (Remember to reverse the bit order of the byte to get pixels, so that
binary number above gives a mono pixel order of 1001011.)

Double hires gets smarter (or at least simpler) with the color scheme by 
switching to using a sequence of every four bits representing a color from 
0 to 15 (or one of sixteen possible colors).  However, to maintain simple
circuit compatability, it still uses the bass ackwards format of hires in 
that the hi-bit of each byte is not used.  Thus your colors get split over
multiple bytes.

The GS 320x200 Shires mode works identically except for the palette mapping
and the fact that each byte now holds two pixels.  The high bit was reclaimed
for the GS modes.  640x200 doubles the number of pixels by reducing the number
of colors to four (two bits instead of four).
  
>A white hi-res or double hi-res dot whould be 4 on bits:
>     1111

No, that's a white dhires pixel, or TWO white hires pixels..  

>Using the method above, this white dot would be converted into:
>
>  MPBWAGB  (magenta,purple,brown,white,aqua,green,brown)
>
>The colors may be different depending on the location of the 4 bits. The point
>is, only the single middle bit is coloured white. This doesn't seem right...

No, you're confusing features of the hires and double-hires modes.  In Dhires,
every four bits makes a pixel--that's it.  There is no overlapping of pixels
vs. bits.  

It's this:
bytes:          1              3              3
bits:    0 1 2 3 4 5 6  0 1 2 3 4 5 6  0 1 2 3 4 5 6 
pixels:  \  1  / \   2 /  \  3  / \  4   / \  5  / 

NOT this:
bytes:          1              3              3
bits:    0 1 2 3 4 5 6  0 1 2 3 4 5 6  0 1 2 3 4 5 6 
pixels:  \  1  / 
           \  2  /
             \  3  /
               \  4  /
                 \  5   / 
     

I hope that makes sense...  The concept for everything but standard hires is
quite easy to understand.

As for clock speeds, it's easy to figure out what's necessary to have an NTSC
compatable output.  If I remember correctly, NTSC scanline frequency is about
16 khz, and to get 320 4 bit pixels on a horizontal line would require a 
clock rate of just over 5 MHz.  On the other hand, the double-hires pixel 
frequency would be half that, and the 640 pixel mode for the GS would require
twice that.  Of course you also have to factor in retrace time, so that adds 
a bit to it.  (Note that actual memory access timing varies a bit from this.. 
After all, on the GS, you could access a single byte and buffer the second 
half.  For the //e video modes (hires and dhires) the memory isn't accessed
by the video circuitry as standard 8-bit bytes anyway.  It has a bit more 
complex access scheme I believe..)

Michael Foegelle
-- 
   Michael Foegelle  | Call Wunderland BBS! |   foegelle@ccwf.cc.utexas.edu
    University of    | (512) 472-0544  8n1  |   foegelle@utaphy.ph.utexas.edu
   Texas at Austin   | 14.4kbaud, v.32/bis  |   GEnie:   M.FOEGELLE2
  Physics Department | 500 megs on a //e!   |   > Ask me about Columns //e! <