Apple II graphics formats
Dan Tobias (Talk | contribs) (→Hi-Res Graphics) |
Dan Tobias (Talk | contribs) (→Double Lo-Res) |
||
| Line 32: | Line 32: | ||
== Double Lo-Res == | == 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. | ||
== Double Hi-Res == | == Double Hi-Res == | ||
Revision as of 01:53, 27 August 2013
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.
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.
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.
