Apple II graphics formats
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.
Contents |
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.
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.
