Apple II graphics

All Apple II machines featured an RCA jack providing a rough NTSC, PAL, or SECAM composite video output (on non-NTSC machines before the Apple IIe this output is black-and-white only). This enabled the computer to be connected to any composite video monitor conforming to the same standard for which the machine was configured. However the quality of this output was unreliable; the sync signaling was close enough for monitors—which are fairly forgiving—but did not conform closely enough to standards to be suitable for broadcast applications, or even input to a video recorder, without intervening processing. (The exception was the Extended Back version of the Bell & Howell branded black II Plus, which did provide proper video sync, as well as other media oriented features.)

In addition to the composite video output jack, the IIc, IIc Plus, and the IIGS featured a two-row, 15-pin output. In the IIc and IIc Plus, this connector was a special-purpose video connector for adapters to digital RGB monitors and RF modulators. In the IIGS it was an output for an analog RGB monitor specially designed for the IIGS.

Numerous add-on video display cards were available for the Apple II series, such as the Apple 80-Column Text Card. There were PAL color cards which enabled color output on early PAL machines. Some other cards simply added 80-column and lowercase display capabilities, while others allowed output to an IBM CGA monitor through a DE9 output jack.

The Apple II video output is really a monochrome display based upon the bit patterns in the video memory (or pixels). These pixels are combined in quadrature with the colorburst signal to be interpreted as color by a composite video display.

High resolution provides two pixels per Colorburst cycle, allowing for two possible colors if one pixel is on, black if no pixels are on, or white if both pixels are on. By shifting the alignment of the pixels to the colorburst signal by 90°, two more colors can be displayed for a total of four possible colors. Low resolution allows for four bits per cycle, but repeats the bit pattern several times per low resolution pixel. Double high resolution also displays four pixels per cycle. See the sections below for more details.

Low-resolution colors 0 (black), 3 (purple), 6 (medium blue), 9 (orange), 12 (light green) and 15 (white) were also available in high-resolution mode. Colors 5 and 10 (gray) are indistinguishable on original hardware; however, some emulators (such as older AppleWin versions) display them as different shades. Note that some of the AppleWin emulator colors seen here differ markedly from those shown on original hardware.

The blocky, but fast and colorful Lo-Res graphics mode (often known as GR after the BASIC command) was 40 pixels wide, corresponding to the 40 columns on the normal Apple II text screen. This mode could display either 40 rows of pixels with four lines of text at the bottom of the screen, or 48 rows of pixels with no text. Thus two pixels, vertically stacked, would fill the screen real estate corresponding to one character in text mode. The default for this was 40×40 graphics with text.

There are 16 colors available for use in this mode (actually 15 in most cases, since the two shades of gray are identical in brightness on original Apple hardware, except on the Apple II_GS). Note that six of the colors are identical to the colors available in High-Resolution (Hi-Res) mode.

The colors were created by filling the pixel with a repeating 4-bit binary pattern in such a manner that each bit group fit within one cycle of the Colorburst reference signal. Color displays would interpret this pattern as a color signal. On monochrome monitors, or if the Colorburst signal was turned off, the display would reveal these bit patterns. There are two equivalent grey shades as 5 (0101) is equivalent to 10 (1010) based on how the colors mix together; the "on" bits are polar opposites of each other on the quadrature color signal, so they cancel each other and display as grey.

This mode is mapped to the same area of memory as the main 40-column text screen (0x400 through 0x7FF), with each byte storing two pixels one on top of the other.

The Lo-Res graphics mode offered built-in commands to clear the screen, change the drawing color, plot individual pixels, plot horizontal lines, and plot vertical lines. There was also a "SCRN" function to extract the color stored in any pixel, one lacking in the other modes.

A block of 128 bytes stores three rows of 40 characters each, with a remainder of eight bytes left after the third row is stored. But these bytes are not left empty. Instead, they are used variously by motherboard firmware and expansion card firmware to store important information, mostly about external devices attached to the computer. This created problems when the user loaded a text or a lo-res graphics screen directly into video memory—replacing the current information in the holes with what was there at save-time. (Disk head recalibration was a common side-effect, when the disk controller found its memory—in a screen hole—of where the head was, suddenly not to match the header data of the track that it was reading). The programmers at Apple responded by programming ProDOS so the user could not directly load a file (screen data, or otherwise) into 0x400-0x7FF. ProDOS programs to properly load data to this portion of memory soon arose; several appeared in Nibble magazine.

Having two screens for displaying video images was an integral part of the Apple II family design. Accessing memory location 0xC055 (49237) displayed "Screen 2" regardless of how the other "soft switches" were set. The text and Lo-Res Screen 2 space ranged from 0x800 (2048) to 0xBFF (3071). The interleaving is exactly the same as for the main screen ("Screen 1"). Applesoft BASIC programs are loaded at 801h (2049) by default; therefore, they will occupy the Text Screen 2 space unless the computer is instructed to load a program elsewhere in memory. By contrast, some commercial software programs for the Apple II used this memory space for various purposes — usually to display a help screen.

Unlike the other Apple II machine types, the Apple IIGS featured a processor (the 65816) which could address more than 64K of RAM without special tricks. In the IIgs, RAM was demarcated into banks of 64K. For example, bank 0xE0 consisted of the range 0xE00000 through 0xE0FFFF. The Apple IIgs had a chip called the "Mega II" which allowed it to run most programs written for other Apple II computers. The IIgs architecture mapped the screen data to memory bank 0xE0. However, in IIe emulation mode, screen data was stored in bank 0x00. This presented a problem. The designers of the Mega II included routines to copy most screen data to bank 0xE0 to ensure that Apple IIe-specific programs worked properly. But they forgot about the rarely used Text Screen 2. This was not discovered until the Mega II chips had made it into the IIgs machines. So the firmware designers added a CDA (classic desk accessory—accessible from the IIgs Desk Accessories menu, invoked with Apple+Control+Escape) called "Alternate Display Mode",[1] which, at the expense of a little bit of CPU time, performed the task for the few programs that needed it. It could be turned on and off at whim, but reverted to off upon resetting the computer.

Improved compatibility with Text Screen 2 was addressed with the introduction of the Apple IIGS with 1 megabyte of RAM (better known as the ROM 3) in 1989. The new motherboard provided hardware shadowing of Text Screen 2, at no cost to CPU time, therefore not affecting the speed of software running. Although Alternate Display Mode remained an option in the CDA menu, the machine would automatically detect the presence of Text Screen 2 and enabled hardware shadowing of Text Screen 2 into bank 0xE0 on ROM 3 machines.

It is possible to generate smooth color boundaries between a color and black or white; however, the "correct" black or white must be chosen. The two upper images show the black and white from the green/purple palette against a green background. The two lower images show the black and white from the blue/orange palette against a green background; this forces many of the bordering green pixels to turn orange.

The horizontal borders between two colors generate "fringe effects" on the Apple II. In the lower left image, drawing a blue star on a green background causes the Apple II to add black, white and orange pixels at and near the horizontal boundaries between the green and blue.

When the Apple II came out, a new mode had been added for 280×192 high-resolution graphics. Like Lo-Res mode, hi-res mode had two screens; in Applesoft BASIC, either one could be initialized, using the commands HGR for the first screen or HGR2 for the second.

The Applesoft BASIC ROM contained routines to clear either of two Hi-Res screens, draw lines and points, and set the drawing color. The ROM also contained routines to draw, erase, scale and rotate vector-based shapes. There were no routines to plot bitmapped shapes, draw circles and arcs, or fill a drawn area, but many programs were written; many appeared in Nibble and other Apple II magazines.

The user could "switch in" four lines of text in the Hi-Res mode, just like in Lo-Res mode; however, this hid the bottom 32 lines, resulting in a 280x160 picture. (The ROM routines could still modify the bottom, even though it was hidden.)

The Apple II's Hi-Res mode was peculiar even by the standards of the day. While the CGA card released four years after the Apple II on the IBM PC allowed the user to select one of two color sets for creating 320×200 graphics, only four colors (the background color and three drawing colors) were available at a time. By contrast, the Apple offered eight colors for high-resolution graphics (actually six, since black and white were both repeated in the scheme). Each row of 280 pixels was broken up into 40 blocks of seven pixels each, represented in a single byte. Each pair of adjacent pixels generated a single color pixel via artifact color, resulting in an effective resolution of 140×192. The lower seven bits of each byte represented the pixels, while the most significant bit controlled the phase offset for that block of pixels, altering the color that was displayed.

High Bit	Pixel Pair	Color Number	Color Name	Y	Pb (rel.)	Pr (rel.)
0	00	0	Black 1	0	0	0
0	01	1	Green	0.5	−1	−1
0	10	2	Purple	0.5	1	1
0	11	3	White 1	1	0	0
1	00	4	Black 2	0	0	0
1	01	5	Orange	0.5	−1	1
1	10	6	Blue	0.5	1	−1
1	11	7	White 2	1	0	0

While this feature allows six colors onscreen simultaneously, it does have one unpleasant side effect. For example, if a programmer tried to draw a blue line on top of a green one, portions of the green line would change to orange. This is because drawing the blue line sets the MSB for each block of seven pixels in this case. "Green" and "orange" pixels are represented the same way in memory; the difference is in the setting (or clearing) of the MSB. Another side effect is that drawing a pixel required dividing by seven. (For the Apple's 6502 processor, which had no division hardware, dividing by seven was relatively slow. If drawing a pixel had only required dividing by a simple power of two, such as eight, this would have only needed a sequence of bit shifts, which would have been much faster.)

The Hi-Res mode on the Apple II was also peculiar for its 64:1 interleave factor. This was a direct result of Steve Wozniak's chip-saving design.[2] The 64:1 factor resulted in a "Venetian blind" effect when loading a Hi-Res screen into memory from floppy disk (or sometimes RAM disk) with the soft switches already set. "Screen holes" occur in the Hi-Res mode just as they do in the Lo-Res and text modes. Nothing was usually stored there—though they were occasionally used to store code in self-displaying executable pictures. Another notable exception is the Fotofile (FOT) format[3] inherited by ProDOS from Apple SOS, which included metadata in the 121st byte (the first byte of the first hole) indicating how it should be displayed (color mode, resolution), or converted to other graphics formats.

Finally, another quirk of Wozniak's design is that while any pixel could be black or white, only pixels with odd X-coordinates could be green or orange. Likewise, only even-numbered pixels could be purple or blue.[4] This is where the so-called "fringe benefit" comes in. The Apple video hardware interprets a sequence of two or more turned-on horizontal pixels as solid white, while a sequence of alternating pixels would display as color. Similarly, a sequence of two or more turned-off horizontal pixels would display as black.

There was no built-in command to extract the color of a pixel on the Hi-Res screen, or even to determine whether it was on at all. Several programs to determine if a pixel was lit were written, and a program to extract the pixel's true color was published in the April 1990 edition of Nibble.

Just as there are two text screen pages (and two Lo-Res graphics pages), so there are also two Hi-Res pages, mapped one right after the other in memory. (The second Hi-Res screen was mapped to 0x4000-0x5FFF, or 16384–24575 in decimal.) IBM's CGA supported only one graphics page at a time. This simplified animation on the Apple II, because a programmer could display one page while altering the other (hidden) page.

Provided that the reset vector had not been occluded by an actively running program, invocation of Control+Reset would interrupt a program and escape to the monitor or Applesoft command prompt. The use of Control+Open-Apple+Reset would force a reset at the expense of a small amount of memory corruption. Creative configuration of some soft switches at the monitor or at the prompt enabled immediate viewing of images from interrupted programs. Favorite scenes from games could be then recorded. On the Apple //e and //c, use of Control+Open-Apple+Reset would result in the pattern 0xA0A0 being written sparsely across all memory, including Hi-Res pages 1 and 2 at $2000 – $5FFF. Corruption by these artifacts could be edited out using a paint package. On the enhanced Apple //e, Hi-Res video memory could be preserved without artifact by the following sequence: pressing Control+Closed-Apple+Reset, and feathering the Reset key up then down for a fraction of a second, repeating until the self-diagnostic color pattern began to fill the first line of text in the upper left corner. Since the self-diagnostic progressed from $0000 upward, once the beginning address of text page 1 ($400) was clobbered, so then was the checksum of the reset vector ($3F4), which meant that a subsequent rapid press of Control+Reset would force the firmware to reboot without clobbering memory above $0800 in either main or the auxiliary banks. It was possible to BSAVE these images to a floppy and create a slide show or a static image, because a soft reset did not clear the video memory on Hi-Res images.

Soon after the introduction of the Apple IIe, the Apple engineers realized that the video bandwidth doubling circuitry used to implement 80-column text mode could be easily extended to include the machine's graphics modes. Since the signal was present at the auxiliary slot connector which housed the Extended 80 Column Card, Annunciator 3 on the game port was overloaded to activate double resolution graphics when both 80 column video and a graphics mode was selected. Replacement motherboards (called the Revision B motherboard) were offered free of charge to owners of the Apple IIe to upgrade their machines with double resolution graphics capabilities. For this reason, machines with the original Revision A motherboard are extremely rare. Subsequent Apple II models also implement the double resolution graphics modes.

This was an 80×40 (or 80×48) graphics mode available only on 80-column machines. Under Applesoft BASIC, enabling this mode required three steps. First, enabling 80 column mode with PR#3, Then enabling double-density graphics with POKE 49246,0, followed by GR.

10 PRINT CHR$(4)"PR#3" : PRINT CHR$(0); : POKE 49246,0 : GR

(Note that PR#3 is deferred to the operating system, with PRINT CHR$(4) to avoid disconnecting it from BASIC. This is followed by a PRINT command to send a null character, because the newly assigned output device doesn't get initialised until the first character is sent to it—a common source of confusion.)

Once this was done, the Double Lo-Res screen was displayed and cleared, and the PLOT, HLIN, and VLIN commands worked normally with the x coordinate range extended to 0 though 79. (Only the Apple IIc and IIgs supported this in firmware. Using Double Lo-Res mode from BASIC on a IIe was much more complicated without adding an & command extension to BASIC.)

There were two major problems when using this mode in Applesoft. First, once the mode was activated, access to the printer became complicated, due to the 80 column display firmware being handled like a printer. Second, the SCRN (pixel read) function did not work properly. However, there was a program in the March 1990 issue of Nibble that took care of this problem.

At least one commercially available BASIC compiler, ZBASIC from Zedcor Systems, was known to support Double Lo-Res graphics.

The composition of the Double Hi-Res screen is complicated. In addition to the 64:1 interleaving, the pixels in the individual rows are stored in an unusual way: each pixel was half its usual width and each byte of pixels alternated between the first and second bank of 64KB memory. Where three consecutive on pixels were white, six were now required in double high-resolution. Effectively, all pixel patterns used to make color in Lo-Res graphics blocks could be reproduced in Double Hi-Res graphics.

The ProDOS implementation of its RAM disk made access to the Double Hi-Res screen easier by making the first 8 KB file saved to /RAM store its data at 0x012000 to 0x013fff by design. Also, a second page was possible, and a second file (or a larger first file) would store its data at 0x014000 to 0x015fff. However, access via the ProDOS file system was slow and not well suited to page-flipping animation in Double Hi-Res, beyond the memory requirements.

Despite the complexities involved in programming and using this mode, there were numerous applications which made use of it. Double Hi-Res graphics were featured in business applications, educational software, and games alike. The Apple version of GEOS used Double Hi-Res, as did Broderbund's paint program, Dazzle Draw. Beagle Bros provided a toolkit, Beagle Graphics, with routines for developing Double Hi-Res graphics in AppleSoft BASIC. Numerous arcade games, and games written for other computers, were ported to the Apple II, and many took advantage of this graphics mode. There were also numerous utility programs and plug-in printer cards that allowed the user to print Double Hi-Res graphics on a dot-matrix printer or even the LaserWriter.

In addition to supporting existing modes, the Apple IIGS adds new modes similar to those of the Atari ST and Amiga.