Re: Apple II graphics file format

["Dave Althoff, Jr." <dalloff.gcfn.org@sbcglobal.net>]

Ophidian <zacwbond@vt.edu> wrote:
: Andy McFadden wrote:
: >
: > I don't believe the image is compressed -- it's 8192 bytes long.  The
: > magic location $78 is in a "screen hole".
: 
: All right, the source of my confusion was that $78 in the image I am 
: examining has a 2, which was 560x192 based on the table, but that is too 
: large to fit in 8192 bytes (actually, my file is 8184 bytes, for 
: whatever reason).  However, Ciderpress is giving me a 280x192.
: 
: I guess the real question I should be asking is--how did the Apple II 
: display hardware work to create color images?
: 
: I am porting an slow & buggy old Applesoft game off the Apple, and I am 
: debating how to deal with the graphics stored in bitmap files.  In 
: particular, I have a color image with text, but the text looks 
: color-tinted and funny; I would like to make the text all white while 
: preserving the color elsewhere.

Yup.  That's what it would look like.

Even the text would look all color tinted and funny in the 4-line text 
window.  To get white text on the screen you'd need to use a double-wide 
font that would yield a 20x12 display.  Most people who wanted to blast 
text to the screen did it using a variant on the standard text font 
because it is easier to do that way.

Here's how the hi-res screen works, simplified version:

The hi-res screen is 280 pixels wide and 192 pixels tall.  Bitmap images 
have a 1-bit color depth, except that it is a lot more complicated than 
that.  

The actual screen is 40 bytes wide and 192 rows tall, a total of 7,680 
bytes.  Each pixel on the screen can be one of four colors:  green, 
violet, orange, or blue.  To get four colors plus white out of only one 
bit is of course a massive hack.  Here's how it works--

o All odd-numbered columns on the screen are either green or orange
o All even-numbered columns on the screen are either violet or blue

The first thing you should notice is that the screen width is 280 pixels, 
not 320 pixels.  This is because only seven bits of each byte are used 
for displaying graphics.  The eighth bit chooses the color set.  If the 
eighth bit is clear (values 00000000-01111111...$00-$7F...0-127) then the 
odd columns represented by that byte will be green and the even columns 
will be violet.  If the eighth bit is set (values 
10000000-11111111...$80-$FF...128-255) then the odd columns will be 
orange and the even columns will be blue.  As a bonus, all pixels in a 
byte with the eight bit set will also be shifted half a dot on the 
screen.  Apple exploited this to smooth the normal character set...with 
half-bit shifting it is actually possible to light up pixels in 560 
horizontal positions on the screen, with some severe 
limitations...notably that the half-dot shift AND the color set shift 
affects all seven pixels within the byte.

Okay, as if that wasn't bad enough, note that while the screen colors are 
arranged in an even-odd pattern, each byte contains only seven pixels, so 
every other byte has its color pattern reversed.  So to display a green 
line, the bit pattern for two bytes would be:
0 1010101 | 0 0101010
...likewise for a blue line:
1 0101010 | 1 1010101

ANY two adjacent lit points will show up as white.  The Apple ][ 
contained a "color killer" circuit which failed to provide an NTSC color 
burst signal when the graphic modes were turned off, so normal text was 
clean and white.  But text displayed in the 4-line text window at the 
bottom of the graphics screen (optional...covers up the last 28 lines 
of the graphic screen) would appear rainbow striped according to 
the same rules as the graphic screen.  The AppleColor Composite Monitor 
had a system in it that could detect the color burst signal and respond 
appropriately, generating crisp, clear text, and also giving a color 
signal optimized to the video output of the Apple ][.  That monitor also 
had a switch on the front panel so that you could manually force it into 
monochrome mode if you were trying to read text on a graphic screen.

Now if you're trying to translate the Apple hires graphic screen to 
something else, that is enough to give you an idea of what it is supposed 
to look like.  If you are trying to read the memory map, though...

Uhmmm...I really don't want to get into it here.  Suffice to say that if 
you want to dump an entire hi-res screen to disk you have to dump 8,197 
bytes to the disk, not the 7,680 bytes you would expect.  And if you want 
to see why I don't want to get into it, run the following Applesoft 
program and watch what happens on the screen.  Remember, the program is 
filling the contents of memory *sequentially*--

10 HGR : POKE -16302,0:REM 49234 = $C052 = soft switch for full screen
20 FOR M = 8192 TO 16379
30 POKE M,255
40 NEXT M : GET Q1$ : TEXT

Talk about *hacks*!  8-)

AD AD C4 E1 F6 E5 A0 C1 EC F4 E8 EF E6 E6 AC A0 DD DB 8D
    /X\        _      *** Respect rides. They do not respect you. ***
   /XXX\      /X\     /X\_      _     /X\__      _     _        _____
  /XXXXX\    /XXX\   /XXXX\_   /X\   /XXXXX\    /X\   /X\      /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX