[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Apple II/IIGS graphics & converting to Mac
- Subject: Apple II/IIGS graphics & converting to Mac
- From: vantune@fraser.sfu.ca (Joseph Van Tunen)
- Date: Tue, 18 Jan 1994 16:35:46 GMT
- Keywords: RGB, NTSC, Mega II, VGC, Hi-Res, Double Hi-Res, graphics, converting,
- Newsgroups: comp.sys.apple2
- Organization: Simon Fraser University, Burnaby, B.C., Canada
- Sender: news@sfu.ca
- Summary: How does the IIGS convert Hi or Double Hi-Res to RGB?
This message is a rewritten version of a question I posted before that
Michael Foegelle (foegelle@ccwf.cc.utexas.edu) responded to (thanks). I added
more technical info, fixed some mistakes, clarified things and explained more.
I want to know how the IIGS converts hi-res and double hi-res into RGB. The
IIGS Hardware Reference pg 56 and Call-A.P.P.L.E. April 1987 pg 12 say that the
Mega II, after reading the graphics information, outputs a 4 bit code (at pins
30-32,34 I guess) 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 at pins
20-23) and is used to lookup a 12 bit RGB value that is passed (out of pins
62-68,1-5) to 3 digital to analog converters (one each for red green, and blue).
****** The manual doesn't say how the Mega II gets the 4 bit code!
What I need to know is how does the Mega II gets the 4 bit code, and how often
it gets a code. (What digital algorithm does it use to convert hi-res and
double hi-res bits into 4 bit color codes?) I want to duplicate the process in
software to convert Hi-Res graphics on to the Mac without ignoring some of the
subtle quirks / overlooked, little known side effects.
-Maybe somebody out there knows...
-Or someone could find out...
-Or build some kind of breadboard electronic thing that checks what the Mega II
is outputing to the 4 pins (at 14MHz I guess)...
-Or maybe the patent says something (Call-A.P.P.L.E mentioned it... I know
nothing of patents, what information they hold, what accessibility a person has
to them or what you're allowd to do with them... What is "patent pending"
anyway?)
-Doesn't SHR Convert do Hi-Res? I know it does Double Hi-Res but it does it the
simple way (4 bit pixel boundaries. eg. 4 bits is white here: 1111 but not
here: 01111).
The following is what I could figure out (a whole bunch of technical stuff
(some might be irrelevant but still interesting) and the method explained in
the IIGS Hardware Reference and tn-aiie-003):
--------------------------------------------------------------------------------
references used:
technote tn-iigs-063 "Master Color Values"
technote tn-aiie-003 "Double High-Resolution Graphics"
Call-A.P.P.L.E. April 1987 pp. 10-13
COMPUTE! August 1983 pp. 172-177
Apple ][ Reference Manual (c1979, 1981)
Apple IIe Technical Reference Manual (c1986)
Apple IIGS Hardware Reference 2nd Edition (c1989)
--------------------------------------------------------------------------------
Table 1. Color Values reference: technote tn-iigs-063 "Master Color Values"
Color Color Register LR HR DHR Master Color R,G,B
Name Value # # # Value
----------------------------------------------------
Black 0 0 0,4 0 $0000 (0,0,0)
(Magenta) Deep Red 1 1 1 $0D03 (D,0,3)
Dark Blue 2 2 8 $0009 (0,0,9)
(Violet) Purple 3 3 2 9 $0D2D (D,2,D)
Dark Green 4 4 4 $0072 (0,7,2)
(Gray 1) Dark Gray 5 5 5 $0555 (5,5,5)
(Blue) Medium Blue 6 6 6 C $022F (2,2,F)
(Cyan) Light Blue 7 7 D $06AF (6,A,F)
Brown 8 8 2 $0850 (8,5,0)
Orange 9 9 5 3 $0F60 (F,6,0)
(Gray 2) Light Gray A A A $0AAA (A,A,A)
Pink B B B $0F98 (F,9,8)
(Green) Light Green C C 1 6 $01D0 (1,D,0)
Yellow D D 7 $0FF0 (F,F,0)
(Aqua) Aquamarine E E E $04F9 (4,F,9)
White F F 3,7 F $0FFF (F,F,F)
LR: Lo-Res HR: Hi-Res DHR: Double Hi-Res
(Sometimes I spell gray, grey but I haven't spelled color, colour)
--------------------------------------------------------------------------------
Method for getting 4 bit color code:
technote, tn-aiie-003 "Double High-Resolution Graphics", explains:
"An NTSC color monitor decides what color to display based on its view of four
bit windows in each line, starting from the left edge of the screen. The
monitor looks at the first four bits, determines which color is called for,
then shifts one bit to the right and determines the color for this new four-
bit window. But remember, the color depends not only on the pattern, but also
the position of the pattern. To compensate for relative position from the left
edge of the screen, the monitor keeps track of where on each line each of these
windows start. (For those of you of the technical persuasion, this is done
through the use of the color burst signal, which is a 3.58 MHz. clock)."
Which basically says that every sequence of 4 bits in DHR 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 that the Mega II outputs is
changed at a frequence of 14M (The rate at which DHR bits are output to the
screen).
This method is also explained in the IIGS Hardware Reference pg 88. I can't see
how this method results in what is displayed on the screen. I'll explain at the
end...
--------------------------------------------------------------------------------
Table 2. Transfer of info to the screen (sizes and frequencies)
DHR bits | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
14M -----------------------------------------------------------------------
HR bits | LSB 0 | bit 1 | bit 2 | bit 3 | bit 4 | bit 5 | bit 6 |
7M -----------------------------------------------------------------------
colrburst| cycle or pixel 0 | pixel 1 | pixel 2 | pixe
3.5M -----------------------------------------------------------------------
DHR bytes| (auxilary memory) byte 0 | (main memory) byte 1 |
2M -----------------------------------------------------------------------
HR byte | byte 0 |
1M -----------------------------------------------------------------------
notes:
LSB = Least Significant Bit of the byte (bit 0).
MSB = Most Significant Bit (bit 7) is not shown because it is not displayed.
A 14M clock crystal (14.31818MHz) is used to get the frequencies.
7M = 1/2*14M 3.5M = 1/4*14M 2M = 1/7*14M 1M = 1/14*14M
7.159MHz 3.580MHz 2.045MHz 1.023MHz
On the IIGS a 28M crystal is used (28.636360MHz) /10=2.86MHz.
1M is the same frequency used by the Apple ][, //e, //c and IIGS in normal
speed.
3.5M is used for the color burst at the beginning of each scan line of an NTSC
(or composite) monitor. A pixel is 3.5M for a reason described below.
dot/pixel/bits: (convention I try to use to avoid confusion..)
double hi-res hi-res
dot (B&W) 1 bit 1 bit (a double hi-res dot is a hi-res half dot)
pixel (color) 4 bits 2 bits
--------------------------------------------------------------------------------
NTSC standard: reference "Call-A.P.P.L.E April 1987 pp. 10-13"
(Apple IIGS Hardware Reference pg 87)
At the beginning of each scan line output to the monitor is the horizontal sync
and color burst, (burst phase, color subcarrier). The rest of the line used for
display includes:
Luminance: Brightness information sent to the monitor (proportional to the
voltage amplitude of the composite video signal). eg: Black has less luminance
than white.
Chrominance (chroma): color info that rides on top the luminance signal, and is
of the same frequency as the color burst. Chroma includes Hue and Saturation:
Hue: Phase shift of chroma (relative to burst phase) eg: Green is phase shifted
180 degrees relative to Purple. (I don't know what the phase shift is for the
colors relative to the burst phase) More explanation later.
Saturation: Amplitude of chroma (relative to luminance level). eg: Pink is less
saturated then red. A saturation of zero eliminates the chroma, ie. no
amplitude means no wave, therefore no phase shift or hue or color, just grey
level or luminance.
Figure 1. NTSC stuff. Two colored pixels side by side with color phase above.
(Imagine the waves as being cureved (sinusoidal or sine wave shape))
3.5M /\ /\ /\ /\ /\ /\ /\
color phase / \ / \ / \ / \ / \ / \ / \
\ /| \ / \ / \ / \ / \ / \ /
\/ | \/ \/ \/ \/ \/ \/
|
white level-> |hue |
(phase shift|
270 degrees)| _
/\ | /\ } saturation
luminance_> / \ |/ \ _} (amplitude
(average | \ / \ /| of wave > 0)
voltage 50%)| \/ \/ |
| |
| |
black_level______| |____________
A B&W monitor ignores color burst and chroma (because of there high frequency,
I guess) and use only the luminance (which is the average of the chroma
relative to the black level).
--------------------------------------------------------------------------------
Apple ][ NTSC output
After an Apple ][ outputs the horizontal sync and color burst, they output the
pixels on the graphics line.
The Apple IIGS uses the RGB anolog signals to create a real NTSC signal.
The other Apple ][s use a simpler method that output a compatible NTSC signal.
For HR, a byte is loaded into a shift register and each bit is shifted out the
right side (LSB first) directly into the NTSC signal (1 is high voltage or
bright dot, 0 low). The bytes are taken at a frequency of 1M, and the bits are
shifted at 7M so that only 7 of the 8 bits are used. 2 bits are output at 3.5M.
This is very important for color!
The colors are a seqence of ones and zeros that make a 3.5M square wave:
black white
________________----------------
purple: --__--__--__--__
green: __--__--__--__--
Note: the green wave is 180 degrees phase shifted relative to purple.
On a monochrome monitor, this would be white and black dots.
On a B&W TV (with less bandwidth than a computer monitor), this would be 50%
grey (luminance is average of chroma, (white 100% + black 0%)/2=50%).
Although the signal is not exactly NTSC, the circuitry of a color monitor still
manages to interpret the 3.5M square wave as color.
After the original Apple ][ (Revision 0 Board), the colors orange and blue were
added. The serialized output stream of a byte would be delayed a half of the 7M
clock cycle (the size of a DHR dot) if the byte's high bit was set. This has
the effect of adding an additional 90 degrees phase shift to purple and green.
0 1 2 3 4 5 6 0 1 2 3 4 5 6
--__--__--__--__--__--__--__
black white
______________--------------
black2 white2
_______________-------------
purple: --__--__--__--__--__--__--__
blue: _--__--__--__--__--__--__--_
green: __--__--__--__--__--__--__--
orange: ___--__--__--__--__--__--__-
(note: while the byte is being delayed, the last dot (black or white) is still
being drawn. See the section on converting HR to DHR)
Now, look at the Macintosh color wheel (which shows hue, saturation, and
brightness (the HSV model where V is for value which is brightness. Brightness
is not the same as lightness though. I think the HSL model is better for NTSC
comparison) and note the positions of the 4 colors on the circle:
Green Orange The green hue is 90 degrees away from orange (and blue) and 180
\ / from purple. Purple is 90 from blue (and orange) and 180 from
__\/__ green.
/\
/ \
Blue Purple
--------------------------------------------------------------------------------
Double Hi-Res Apple ][ NTSC output
Bytes loaded at 2M into a shift register, alternating between auxillary memory
first and main second, bits shifted out at 14M, and high bit ignored.
Purple, Green, Orange, and Blue are a sequence of 2 ones and 2 zeros which make
a 3.5M square wave again (because 4 bits are drawn at 14M/4=3.5M). These colors
have a luminance of 50%(approx).
The other colors are a repeating pattern of 1 one and 3 zeros (25%), or 3 ones
and 1 zero (75%). All of those colors have a pattern that repeats at 3.5M.
Black is 4 zeros (0%) and White is 4 ones (100%). Light gray and dark gray are
repeating one and zero (a 14M signal that the monitor circuitry interprets as
grey because it can't find any 3.5M pattern). This would mean a luminance of 50%
for both but on the IIGS, the grays are different. The Other Apple's don't have
the ability to output any color they want like the IIGS (The IIGS could have any
RGB value for the grays). I don't remember, but maybe on the other Apple ][s,
the greys are the same. This would explain why the grays are called gray 1 and
gray 2 in the Apple books (except the IIGS books). On the other hand, the
composite monitor's circuitry might output a different color for the grays
because of their different phase shifts (if the circuitry notices it) which
might make the luminance appear different........
--------------------------------------------------------------------------------
Converting Hi-Res to Double Hi-Res (by example)
Symbols:
'|' = End of byte or pixel; screen boundary
'#' = White dot, set bit
' ' = Black dot, cleared bit
Hi-Res Symbols:
notes: The left and right borders of the screen are considered to have no shift.
Previous byte means byte associated with previous bit.
Next byte means byte associated with next bit.
A Shifted byte has the high bit set.
'.' = Black dot. The previous byte is shifted (hi bit set) and half of bit 6 is
not drawn because the next byte is not shifted and is drawn on top.
'`' = Black dot. The next byte is shifted and the previous byte's last bit (bit
6) is clear.
'*' = White dot. Bit 6 of the previous byte is set and the next byte is shifted
so that bit 6 is extended a half HR dot while the next byte is�being
delayed.
'?' = White dot if next byte is shifted, or the next byte is not shifted and the
first bit is set; black otherwise.
'!' = White dot if next byte is not shifted and first bit is set; black dot
otherwise.
Shown below are the DHR colors
1) sorted by number
2) grouped by luminance and sorted by shift
3) grouped by color and sorted by luminance
|0123456012345601234560123456012345601234560123456012345601234560123456 : bit
| ab0 | mb1 | ab2 | mb3 | ab4 | mb5 | ab6 | mb7 | ab8 | mb9 | : byte
| | | | | | | | | | | | | | | | | | : pixel
| Black # # Magenta # # Magenta
| # # # # # # # Magenta # # Brown # ## # Purple
| # # # # # # # Brown # # Dark Green # ### ## Pink
| ## ## ## ## ## ## ## Orange # # Dark Blue
| # # # # # # # Dark Green ## ## Orange # # Brown
| # # # # # # # # # # # # # # Dark Gray ## ## Green ## ## Orange
| ## ## ## ## ## ## ## Green ## ## Blue ### ### Yellow
| ### ### ### ### ### ### ### Yellow # ## # Purple
|# # # # # # # Dark Blue ### ### Yellow # # Drk Green
|# ## ## ## ## ## ## # Purple ### ### Aqua ## ## Green
|# # # # # # # # # # # # # # Light Gray ## ### # Light Blue ### ### Aqua
^|# ### ### ### ### ### ### ## Pink # ### ## Pink
||## ## ## ## ## ## ## Blue Black # # Dark Blue
||## ### ### ### ### ### ### # Light Blue # # # # Light Gray ## ## Blue
||### ### ### ### ### ### ### Aqua # # # # Dark Gray ## ### # Lite Blue
||############################ White ######## White
|
Shown below are the HR colors (converted to DHR, each # is a HR half dot). They
line up with the DHR colors above. Note that the DHR screen is 1 HR half dot
right of the HR screen (compare position of purple in HR and DHR at left side
of screen).
|--==--==--==--==--==--==--==--==--==--==--==--==--==--== : a bit is two chars
| --==--==--==--==--==--==--==--==--==--==--==--==--==--= : shifted byte's bits
|0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 : bit
| even byte 0 | odd byte 1 | even byte 2 | odd byte 3 | : byte
| | | | | | | | | | | | | | | : pixel
|## ## ## ## ## ## ## ## ## ## ## ## ## ## ! purple
|`## ## ## #* ## ## ## `## ## ## #* ## ## ## ! blue
| ## ## ## ## ## ## ## ## ## ## ## ## ## ##? green
|` ## ## ## `## ## ## #* ## ## ## `## ## ## #? orange
|
|########################################################?
|`#############*#############*#############*#############?
If you have a color monitor, you can see how each color is shifted a half a dot
from the one above. You can see the individual dots better in monochrome. The
IIGS has a B&W mode for hi-res but it eliminates the shifting. Use an NTSC
monochrome monitor instead of the RGB display..
The following shows other colors you can get in HR. It shows that 2 bits side
by side don't always give white! 2 bits are set at either side of an even/odd
or odd/even byte boundary or 1 bit is set at the end of a byte boundary. The
colors that the bits line up with are abbreviated P, B, G, O. s means high bit
set, c means high bit clear.
(these line up with the tables above also)
|0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 : bit
| even byte 0 | odd byte 1 | even byte 2 | odd byte 3 | : byte
Aqua ### BG
Dark Blue #. Bc
Light Blue ##* Ps
OP ### Pink
Oc #. Brown
Gs ##* Yellow
The applesoft program below draws some color lines on the HR screen and shows
all the colors you can get (you have to press a key alot. 80 columns is used
for labeling the colors):
10 PRINT CHR$ (4)"PR#3"
20 TEXT : HOME : VTAB 20: HGR
30 REM ****** COLOR BANDS PURPLE BLUE GREEN ORANGE (ORDERED BY HALF DOT
40 REM POSITIONS FROM LEFT SIDE OF SCREEN).
50 HCOLOR= 2: HPLOT 0,10 TO 279,1
60 HCOLOR= 6: HPLOT 0,11 TO 279,11
70 HCOLOR= 1: HPLOT 0,12 TO 279,12
80 HCOLOR= 5: HPLOT 0,13 TO 279,13
90 HCOLOR= 3: HPLOT 0,14 TO 279,14
100 HCOLOR= 7: HPLOT 0,15 TO 279,15
110 GET A$
120 HGR
130 C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5
140 REM ****** DRAW 2 COLORS SIDE BY SIDE.
150 REM LEFT COLOR ON EVEN BYTE, RIGHT ON ODD.
160 XL(0) = 6:XL(1) = 6:XL(2) = 5:XL(3) = 5
170 XR(0) = 8:XR(1) = 8:XR(2) = 7:XR(3) = 7
180 FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
190 HCOLOR= C(CL): HPLOT X + XL(CL),0 TO X + XL(CL),79
200 GET A$
210 HCOLOR= C(CR): HPLOT X + XR(CR),0 TO X + XR(CR),79
220 GET A$
230 NEXT : NEXT
240 REM ****** DRAW 2 COLORS SIDE BY SIDE.
250 REM LEFT COLOR ON ODD BYTE, RIGHT ON EVEN.
260 XL(0) = 12:XL(1) = 12:XL(2) = 13:XL(3) = 13
270 XR(0) = 14:XR(1) = 14:XR(2) = 15:XR(3) = 15
280 FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
290 HCOLOR= C(CL): HPLOT X + XL(CL),80 TO X + XL(CL),159
300 GET A$
310 HCOLOR= C(CR): HPLOT X + XR(CR),80 TO X + XR(CR),159
320 GET A$
330 NEXT : NEXT
340 REM ****** DRAW DARK BLUE, BROWN, LIGHT BLUE, YELLOW LINES.
350 HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159
360 HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159
370 GET A$
380 HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
390 GET A$
400 REM ****** LABEL THE COLOR LINES WITH THE COLORS USED ON THE LEFT AND
410 REM RIGHT SIDE OF THE BYTE BOUNDARY. ALSO LABEL OTHER COLORS.
420 C$(0) = "P":C$(1) = "B":C$(2) = "G":C$(3) = "O"
430 VTAB 21
440 FOR CL = 0 TO 3: FOR CR = 0 TO 3: PRINT " "C$(CL)C$(CR);: NEXT : NEXT
450 PRINT " BcOcPsGs"
460 PRINT "TOP ROW: EVEN BYTE/ODD BYTE ";
470 PRINT "BOTTOM ROW: ODD BYTE/EVEN BYTE"
480 REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF EVEN/ODD COLOR LINES.
490 FOR I = 0 TO 279 STEP 14
500 HCOLOR= 0: HPLOT I,30 TO I,39: HPLOT I + 13,30 TO I + 13,39
510 HCOLOR= 4: HPLOT I,40 TO I,49: HPLOT I + 13,40 TO I + 13,49: NEXT
520 REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF ODD/EVEN COLOR LINES.
530 FOR I = 7 TO 266 STEP 14
540 HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119
550 HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT
--------------------------------------------------------------------------------
Line addresses: reference COMPUTE! August 1983 pp. 172-177
Brief explanation of line number (eg 0-191) to line start address conversion
(eg $2000-$4000):
For text mode, the display is divided in 3 and each third is split in 8 rows.
A row is a character's vertical position. For HR and DHR, these are split into
8 character lines (the height of a character is 8 pixels or hi-res lines).
third: 00,01,10__ ___character line 000..111
bit: 76543210 text line number: 000ABCDE
HGR line # bits: ABCDEFGH lo-res line #: 00ABCDEF
^^^row in third 000..111 even/odd row, lo, hi nibble^
high byte 76543210 76543210 low byte
HGR line start address bits: 0xxFGHCD EABAB000
xx = 01 for page 1, 10 for page 2.
text or lo-res line start address bits: 0000xxCD EABAB000
xx = 01 for page 1, 10 for page 2.
For lo-res, if F is 0 then top even line of row, low nibble $0x for byte,
else bottom odd line of row, high nibble $x0 for byte.
--------------------------------------------------------------------------------
The problem with the method in tn-aiie-003 and IIGS Hardware Reference is:
(example)
Take a white DHR pixel at bit 4 of first byte:
|0123456012345601234560123456
| ab0 | mb1 | ab2 | mb3 |
| ####
Take 4 bit windows at every bit (| | is a 4 bit window). Look in the DHR
table at the window's postion and match the 4 bits with a color:
DHR color table
|0123456012345601234560123456
| Black
| # # # # # # # Magenta
| ## ## ## ## ## ## ## Orange
| ### ### ### ### ### ### ### Yellow
|# # # # # # # Dark Blue
|## ## ## ## ## ## ## Blue
|### ### ### ### ### ### ### Aqua
|############################ White
<-bit position of moving window
<-bits in the window
<- color the window represents
0| | Black K <- abbreviation
1|| #| Dark Blue D
2| | ##| Blue B
3| | ###| Aqua A
4| |####| White W
5| |### | Yellow Y
6| |## | Orange O
7| |# | Magenta M
8| | | Black K
Using this method, the white dot is output not as WWWW but as DBAWYOMK (in very
small color pixels). But this doesn't seem it would look white on the IIGS's
screen (and it won't like white on a Mac screen). It's supposed to be a white
dot. Maybe the colors just blend together to make it look more white? (because
of the size of the phosphors compared to the size of the pixels..) Maybe it's
like dithering in 640 Super Hi-Res mode? (DHR is 560).............
Does the Mega II actually use this method for it's DHR conversion to RGB?
It definitely has to do more than just say 010 is green and 101 is purple and
any 2 adjacent 1's is white.. etc.
--------------------------------------------------------------------------------
-- Joe van Tunen (e-mail: vantune@sfu.ca)
-- Fort Langley, B.C., Canada.
-- Undergraduate, Computing Science, Simon Fraser University
-- Burnaby, B.C., Canada.