Re: Apple II graphics file format

["Michael J. Mahon" <mjmahon@aol.com>]

Dave Althoff, Jr. wrote:

<snip>

> 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.

The half-dot shift *is* the color shift--they are not different things.
Put another way, if the pixel didn't shift a half-dot, it wouldn't be
in the second color set.

And the text display never does a half-dot shift.  All 40-column
characters are made with dots on the 280x192 grid.  This is why
a normal hi-res screen can display a perfect replica of the text
screen on a monochrome monitor by using only one color set.

<snip>

> 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-)

Of course, that "hack" saved having to steal processor cycles to refresh
the DRAM in the machine, so I'd say it was a very elegant hack.  ;-)

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."