[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple IIGS RGB graphics conversion
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! <