Apple II graphics formats

Latest revision as of 03:46, 18 February 2024

Modern-day computer users are used to standardized, platform-neutral graphic formats with built-in compression. Apple II graphic formats were nothing like that.

Rather, any saved graphics on the Apple II series of computers, particularly from the earlier days of that platform, were likely to be in a format that was highly specific to the (rather quirky) graphic modes of that machine. Perhaps it would be a raw dump of the graphic memory (which, in the Apple DOS file system, would be tagged as "B" for "binary file", but since Apple II users were not generally in the habit of using file extensions, there was nothing specific to indicate it was a graphical screenshot or in which graphic mode it was), or maybe some program-specific system of slicing or compressing the graphic, but in any case it was based directly on the way graphics were stored on the Apple. Apple themselves basically threw up their hands (or maybe just threw up) on the question of how one might convert Apple II graphics to a more modern platform. The best they could come up with was to find a program that can load the original image and save it out in something more standardized like GIF, but they couldn't actually come up with a specific program name. Presumably some of them existed at some point; the later stages of Apple II history, such as with the IIgs, overlapped the era of BBSing and GIFs. There must have been some art program that bridged the gap, and perhaps somebody will add more info about it to this article.

Lots of Apple software avoided the whole issue of graphic file saving by rendering the graphics real-time in code, something that could be done if it was mostly simple line art which could be built in vector form.

Anyway, to make some sense of Apple graphic files, then, you need to know something about how the graphic modes were implemented.

[edit] Lo-Res Graphics

Apple's lo-res graphic mode (accessed with the GR command) was stored in the same screen memory as text mode, at positions 400 (hex) through 755. A "second page" of text or graphics could be stored at hex 800 through BFF (yeah, the Apple was your BFF!), so the display could be switched between the two pages to display one while content is built or loaded on the other, but special preparation was needed to configure the system not to use the second page for BASIC program storage.

Text mode consisted of 40 columns in each of 24 lines, using 7-bit ASCII with the 8th bit setting inverse-video mode. The lines were interlaced 8:1 rather than being stored consecutively, so the first line was stored first, followed by the 9th line, and so on. Three 40-character lines were stored in each 128-byte block within the screen memory, leaving 8 bytes unused for characters or graphics, but this extra memory was used by various system functions for temporary data storage, which could cause problems if graphic screens were saved and loaded, which might cause alteration of such values. The proper solution was to load the screen to a different memory area first and transfer only the parts corresponding to screen positions, leaving the other locations ("screen holes") alone.

Lo-res graphics consist of a 40 x 40 graphic area with four text lines, or 40 x 48 if full-screen graphics with no text is used. Each pixel has a color value in a 16-color palette (though two of the gray colors were actually identical except on the IIgs), with the two pixels on top of one another at the position of one text character being stored in the same byte.

[edit] Hi-Res Graphics

Hi-res graphics, a 280 x 192 graphic screen if no text-mode lines were used, or 280 x 160 if four text lines were displayed at the bottom of the screen, are stored in separate memory from the text and lo-res modes. There are two hi-res pages which can be accessed with the HGR and HGR2 commands. Graphic lines were interlaced 64:1, meaning that the 65th line follows the 1st in storage.

Colors were handled oddly; there was technically a palette of 8 colors, but black and white were each repeated, so there were only six distinct colors. Due to the technical details of the storage, while any pixel can be black or white, only odd-numbered (by x coordinate) pixels can be green or orange, and even-numbered pixels can be violet or blue.

A screen row was divided into 40 blocks of 7 pixels, with the 7 lower bits of a byte determining the pixels' on-off status and the upper bit the color. Three or more "on" pixels in a row were considered white, three or more "off" pixels in a row considered black, and alternating pixels considered in color (which color depended on whether the "on" pixel was in an even or odd position, and on the status of the color bit in the byte).

These conditions made for peculiar constraints in which colors could be displayed at what positions, making graphic design and programming on an Apple a tricky thing.

As with the text and lo-res modes, there were some "screen holes" in the display memory, bytes which were not used for the graphics and might be used for temporary data storage by programs (due to the 40-byte lines being grouped in threes within 128-byte blocks, leaving 8 free bytes). Unlike the text/lo-res memory, these weren't used by low-level Apple system processes, but might be used by other programs.

[edit] Double Lo-Res

On later Apples supporting 80-column text, you could get a corresponding version of the lo-res graphic mode which was 80 pixels wide instead of 40.

[edit] Double Hi-Res

If you thought graphic modes couldn't get any weirder than the ones above, you hadn't encountered Double Hi-Res, which was a variant of the normal Hi-Res which had half-width pixels where the memory storage for the pixels alternated one pixel at a time between two totally different banks of memory. You ended up needing six pixels on in a row to force it to white instead of colors.

[edit] IIgs modes

The IIgs supported the above modes, plus a few new ones:

• 320 x 200, 16 colors
• 320 x 200, up to 16 palettes of 16 colors each. Each scan line can set a different palette.
• 320 x 200, up to 200 palettes of 16 colors, requires computationally-intensive swapping.
• 320 x 200, 15 colors plus a "fill color" at position 0, set to leftmost color in line; allows quick change of background color.
• 640 x 200, 4 pure colors.
• 640 x 200, 16 dithered colors, built from two palettes of 4 pure colors.

Graphic modes could be mixed on the screen, changing with each scan line. Parts of the data for these graphic modes were stored directly in the Video Graphics Chip (VGC).

[edit] Shape tables

The Apple supported shape tables in its hi-res mode, allowing shapes to be stored and plotted. The shapes were stored as vectors. No utilities were provided to create them, so this had to be done by hand, resulting in this feature being little-used. The SHLOAD command loaded shape tables from cassette, while loading them from disk required more complicated commands.

[edit] Software

• RECOIL

[edit] Sample files

• dexvert samples — image/a2eDoubleHighRes
• dexvert samples — image/a2gs320x
• dexvert samples — image/a2gsPreferred
• dexvert samples — image/a2gsSHStar
• dexvert samples — image/a2HighRes

[edit] Links

• Wikipedia article on Apple II graphics
• Single and Double Lo-Res and Hi-Res Graphics in the C Programming Language
• Wikipedia article on shape table
• Discussion on creating shape tables
• JSMESS in-browser Apple II emulator
• Pirate's Signature: program to create graphic screens for cracked software on Apple II; in-browser emulation from JSMESS
• Displaying Apple II Double Hi-Res Bitmapped Graphics in a cc65 C Program