Sixteen-bit microprocessors are changing the look of personal computer graphics. Here's an inside view of what makes graphics different on 16-bit computers such as the Amiga, Atari ST, and Macintosh.

---

Few people interested in computers have failed to hear about the new 16-bit computers like the Atari ST, Amiga, and, most recently, the Apple IIGS. But are these computers truly superior to earlier, 8-bit computers? Part of the answer, of course, depends on what they're used for. For math, virtually any 8bit computer can generate respectable results, but most computer users enjoy graphics. And, to a large extent, the better a computer's graphics look, the more fun it is to use.
    One area where 16-bit machines definitely outshine their 8bit brethren is graphics. What makes 16-bit graphics different from 8-bit graphics, and how are software companies taking advantage of these new capabilities? We'll begin with a comparison of graphics on 8-bit and 16-bit computers, and then look at some 16-bit software that differs notably from what's available in the 8-bit world.

Pixels And Bits
All microcomputers display graphics by lighting up patterns of phosphorescent screen dots known as pixels on a monitor or TV screen. The term pixel is short for picture element.




    Most personal computers use memory-mapped video to control which pixels are lit and which are dark. Part of the computer's memory-which we'll loosely term screen memory-is reserved to contain information for the screen. The computer's video hardware translates the contents of the screen memory into video signals. The monitor, in turn, translates the video signals into the desired pattern of on and off pixels. Figure 1 illustrates this basic arrangement.
    Screen memory is usually arranged in a manner that corresponds to the pattern of dots on the screen. Like all other memory, screen memory is composed of bits, the smallest information units a computer can handle. A bit, or binary digit, can contain either a 1 value or a 0 value. A byte contains eight bits, and a word contains sixteen bits.
    The two possible states of a pixel-light or dark-correspond neatly to the two possible states of a bit-1 or 0, on or off. The term memory-mapped video aptly describes the process of mapping, or translating the on and off bit patterns found in screen memory into patterns of light and dark pixels on the screen.

Text And Graphics Modes
Eight-bit computers such as the Commodore 64 and Atari 800 have both text modes and graphics modes. Text modes generally require less memory and operate faster than graphics modes.
    In graphics mode, the computer has direct control over individual dots on the screen. In the simplest case, if a bit is on, its corresponding screen pixel is lit; if a bit is off, its corresponding pixel is dark.


In text mode, the computer "stamps" an
entire, multipixel character image onto the
screen in one operation. Text operations are
usually faster and more memory-efficient than
bitmapped graphics operations.


Bitmapped graphics screens require more
memory and take more time to draw than
text screens, since the computer must draw
each screen pixel individually. This photo
illustrates a screen drawn with KoalaPaint
for the Commodore 64.

    In text mode, the screen is divided into rows and columns of character-sized cells. Each charac ter cell is further subdivided into rows and columns of dots. In this mode, each byte of data corresponds to a single character: When you press a key on the keyboard or PRINT a character, the computer's video hardware automatically draws an entire multidot character on the screen. Thus, a single text operation affects a number of pixels at once. Aided by special video hardware, the computer can "stamp" an entire character on the screen with one stroke, much as if it were using a rubber stamp.
    Text screens require less memory than graphics screens because the video hardware translates one byte (the character code) into more than eight bits of display information. On the 64, for instance, only 1000 bytes are needed to store all the shape information for an entire 40 X 25 text screen. By comparison, the 64's bitmapped graphics mode requires 8000 bytes for shape data. For the same reason, text screens can be drawn much more rapidly than graphics screens.



No Rubber Stamps
One major difference between 8-bit and 16-bit computers is the way they handle text. On 16-bit machines, the trend is to dispense with a separate text mode and display everything-including characters-via bitmapped graphics. This slows text operations somewhat, but permits much greater flexibility in the display of characters.
    Both the ST and Amiga, for instance, lack a true text mode. Instead of stamping an entire character onto the screen in one operation, the computer draws it pixel by pixel with relatively slow software routines. However, the computer can change the appearance of text by making only slight alterations in the logic of character-drawing routines. This makes it easy to generate different sizes of characters and implement special effects such as italics, boldface, and underlining. To create italics, the computer simply slants the normal characters, and so on. Figure 2 illustrates such special text effects on the Atari ST.
    The Amiga, Macintosh, and Apple IIGS also have a number of predefined fonts (text styles) that can be substituted for the normal system font. The following photo illustrates various fonts available on the Amiga. These patterns are part of the system software: You can simply load the desired font from disk and instruct the computer to use it in place of the normal font.



    Eight-bit computers have the ability to display modified characters, but only at the cost of considerable programming. The system typically includes only one font, so you must create new character patterns from scratch. And the computer has no innate ability to modify the normal font's appearance for special effects such as boldface.
    Conventional text mode has another limitation: On most computers, you can display only one type of text on the screen at any given time. If you change the "rubber stamp" pattern for the letter A, for example, every A on the screen appears in that pattern. This constraint is largely avoided on 16-bit computers. Since each character is drawn individually, many different types and sizes of text can appear on the same screen.

Sprites, Bobs, And Outlaws
Much arcade-style animation involves moving a graphics object over an underlying background of some sort. To create an illusion of independence, the object must not change the appearance of the background over which it moves. The Commodore 64 and 128 solve this problem with special objects known as sprites; eight-bit Atari computers have a similar capability known as player/missile (P/M) graphics. Sprites and P/M graphics are created through special hardware, so they can be displayed with far less effort than if you had to do the same job entirely through software. However, sprites are limited both in size and in number.
    The IBM PC/PCjr lacks hardware sprites, but compensates with GET and PUT commands that can store a graphics object in a BASIC array and stamp it onto the screen at any location. By stamping the same shape twice in XOR (exclusive OR) mode, you can restore whatever previously appeared in that area, making it possible to move a graphics object nondestructively. Unlike sprites, these objects are not limited in size or number; however, they are slower to manipulate and tend to produce unstable, flickering animation.



    The Amiga includes eight hardware sprites which behave almost exactly like their cousins on the Commodore 64 and 128. Not surprisingly, the Amiga uses the hardware sprite capability to display its mouse pointer. Like any other hardware sprite, the mouse pointer has the ability to move rapidly over any sort of display without changing the background. And since it appears in a different logical plane from that of other graphics objects, the pointer sprite always appears "on top" of everything else on the screen, no matter how many windows are open.
    The Amiga's sprites are subject to most of the same limitations of sprites on the Commodore 64. Only eight can appear on a given horizontal line under normal circumstances, and each sprite can have only a few colors, even if it appears on a screen that supports, say, 32 colors. Because of their independence, hardware sprites can also be tricky to integrate with the Amiga's Intuition user interface. Other graphics objects belong to the current bitmap: If you close or resize a window, Intuition knows that it should erase or resize that window's contents. But sprites have no logical connection to the bitmap, so Intuition does not automatically erase them if you close the current window, nor does it change their appearance or location in concert with Intuition events such as window resizing.
    In addition to eight hardware sprites, the Amiga supports spritelike objects known as vsprites (virtual sprites) and bobs (blitter objects). Both involve significant programming overhead, but they offer different ways to overcome the limitations of hardware sprites.


The Amiga's bobs (blitter objects) move like
hardware sprites, but are not limited in size,
colors, or number. This screen from an Amiga
BASIC game contains several bobs.

    The Amiga's vsprite system essentially lets you redisplay a hardware sprite at more than one screen location. Each hardware sprite can serve as the parent for several vsprites, which can have different colors, shapes, and locations from those of the parent. Among other things, this feature permits you to display more than eight sprites on the same horizontal screen line.
    Bobs are the creation of another custom Amiga chip known as a blitter. Like sprite hardware, the blitter chip makes it possible to move an object nondestructively over a detailed background. This feature is analagous to GET and PUT animation on the IBM PC/PCjr, but it works much faster because of the blitter chip's hardware support. Bobs, unlike hardware sprites, are not limited in size or number, and they can have as many colors as are available in the current screen (up to 32 colors under normal circumstances). However, large bobs consume more memory and move more slowly than sprites (or smaller bobs, for that matter), particularly in Amiga BASIC.
    The Atari ST has no hardware sprites, but it does have a spritelike software capability which, again, derives from the need for a mouse pointer. The ST's sprite facility is part of the line A assembly language interface that supports the VDI (Virtual Device Interface) portion of GEM. Software sprites are limited in size; the familiar busybee pointer shape is very close to the maximum size. However, there is no limit to the number of such sprites, and line A instructions operate rapidly enough for quite convincing animation. The sprite can have only two colors, but it may be placed on the screen in various modes, including XOR mode.
    Like the Amiga's hardware sprite, an ST software sprite is a bit of an outlaw in relation to the computer's operating system interface. GEM provides no means for managing such an object except in the form of the mouse pointer. Using software sprites for arcade-style animation requires that you program at the machine level and create means of your own for integrating the sprite's activity with GEM events such as closing and resizing windows.
    The VDI portion of GEM includes two raster copy routines which copy rectangular areas of memory from one location to another-usually from a portion of main memory into screen memory, or vice versa. As with GET and PUT in IBM or Amiga BASIC, the shape can be placed on the screen in various modes, including an XOR mode which allows nondestructive movement. Like the Amiga's bob facility, the ST's raster copy routines place no particular limit on the number of graphic objects you can move about the screen. However, raster copies are not supported with hardware like the Amiga's blitter chip. As a result, these operations are too slow for rapid, flicker-free animation, even in a compiled language such as C. At the time of this writing, ST BASIC has no commands that support raster copy operations.


The ST lacks hardware sprites, but it relies on low-level operating
system routines to display a mouse pointer with spritelike
characteristics. In this screen, the man with a pipe is a software
sprite, created by a short assembly language program that runs
during the ST's vertical blank interrupt.

    The ST's line A interface offers another operation known as BITBLT (Bit Blitter), which closely resembles a VDI raster copy. Though it's somewhat more flexible than the VDI facility, BITBLT is scantily documented like all line A operations, and is available only in assembly language.

Bit Planes
Another notable difference between 8-bit and 16-bit computer graphics has to do with how the computer constructs a screen image. Figure 1 illustrates how a simple shape-the letter A-is displayed on the screen. The computer looks at the on/off pattern of bits in a specific area of memory and translates those patterns into a matching pattern of light and dark pixels on the screen. This mapping process is repeated for as many bits as are needed to define the entire screen.
    In the simplest case-the ST's hi-res screen, for instance-the correspondence between bits and pixels is simple and direct. Each dark pixel corresponds to one bit containing a 0. and each light pixel corresponds to a bit containing a 1 value. Figure 4 illustrates this simple, one-to-one relationship.
    Thus, you can visualize the ST's screen memory in the form of a plane arranged in rows and columns which match the rows and columns of the screen. The first 80 bytes (640 bits) of memory contain on/off data for the top line of the screen, which-not coincidentally-contains exactly 640 pixels. The next 80 bytes of memory contain the dot pattern for the second screen line, and so on. An entire hires screen contains 256,000 pixels and requires 256,000 bits (32,000 bytes) of memory.
    Adding color is usually a matter of combining two or more memory planes into a single screen image. The details of how this is done varies from machine to machine, but the concept of planes (usually called bit planes to accentuate the correspondence between bits and pixels) is useful for understanding all of them.
    On most eight-bit computers, a maximum of two separate memory planes are combined to produce the final image. The Commodore 64's text mode, for instance, combines shape data from its screen memory with color data from its color memory to produce a screen of variously colored characters. In multicolor bitmap mode, the 64 draws shape and color information from different sources, but, again, combines only two planes. Sixteen-bit machines, on the other hand, can combine more than two bit planes for an even greater variety of colors.


The ST's monochrome screen consists of a single bit plane in
which each bit of data corresponds to a single screen pixel.
Eighty bytes (640 bits) of data are needed to define each of
the 400 screen lines; therefore, 32,000 bytes (256,000 bits)
are required to define the entire screen.

    The next step up from a two-color screen is a four-color screen. Figure 5 represents a four-color, medium-resolution screen.
    In a four-color screen, each pixel's color is defined by a pair of bits rather than a single bit. Since there are four possible combinations of two bits (00, 01, 10, and 11), a maximum of four colors are available.
    To add more colors, you simply stack up additional bit planes. The next step up is typically a 16 color, 4-bit plane screen. Figure 6 is a diagram of the ST's 16-color screen.
    For this resolution, four bits are required to define each pixel's color. Since there are 16 possible combinations of four bits (0001, 0010, 0011, and so on), a maximum of 16 colors are available.


In the Atari ST medium-resolution screen, each bit plane contains
16,000 (80' 200) bytes. A total of 32,000 (2' 16,000) bytes are
needed to define the entire screen. Four colors are obtained by
layering two bit planes.


In the ST's lo-res mode, each bit plane contains 8000 (40 * 200) bytes.
Thirty-two thousand (4 * 8000) bytes are needed to define the entire
screen. Sixteen colors are obtained by layering four bit planes.

    At four bit planes, we reach the limit for the ST, (The IBM PC/PCjr, by the way, offers four-color and sixteen-color screens similar to those on the ST, but color usage on the four-color screen is severely limited.) The Amiga can go even further, adding a fifth bit plane to display a total of 32 colors at one time. A 32-color screen is the limit under normal circumstances. However, the machine also supports two special modes that use six bit planes. In hold and modify mode, the Amiga can display as many as 4096 different color shades simultaneously. In extra halfbrite mode (not available on the earliest Amigas) the computer can display up to 64 distinct shades of color. The Amiga's six-bit plane modes are rarely used, however, because they are difficult to program and not documented as thoroughly as more conventional modes.

Memory Versus Resolution
Extra colors, as we have seen, require additional memory. Pixel for pixel, the 16-color screen in Figure 6 requires four times as much memory as the 4-color screen in Figure 5. The Amiga and ST allocate memory for bit planes in quite different ways.
    On the Amiga, each extra bit plane costs you another 8000 bytes. In noninterlaced modes, which are most widely used, a 32-color, low-resolution screen requires 40,000 bytes, while a 16-color, high-resolution screen requires 64,000 bytes. On a multitasking computer like the Amiga, memory consumption is always a major consideration, since the more memory one application uses, the less there is for other applications to use.
    The ST simplifies the allocation problem by using the same amount of memory for bit planes regardless of resolution. Figures 4-6 demonstrate the arithmetic. In high resolution, the ST's screen memory consists of a single, 32,000-byte bit plane. In medium resolution, it consists of two 16,000-byte planes, and in low resolution it consists of four 8,000byte planes. The same contiguous 32,000-byte memory zone is used in every case: The computer simply interprets its contents differently for different resolutions.
    Since the amount of memory available for bit planes is always constant, the ST has to sacrifice resolution to gain extra colors. The medium-res screen gains two additional colors (one extra bit plane) by cutting vertical resolution in half: It is only 200 lines high, compared to 400 lines in a hi-res screen. The lo-res screen gains another 12 colors (two more bit planes) by cutting horizontal resolution in half; its display is 320 X 200 pixels, exactly half the number of pixels contained in the hi-res screen.
    As a general consequence of this scheme, the ST offers far fewer screen options than the Amiga. Only three ST screen modes are available: low, medium, and high resolution. The Amiga offers nine different modes in noninterlaced modes, and a total of 20 different modes counting interlaced, extra halfbrite, and hold and modify.

Palettes
Color usage is another area in which 16-bit computers differ sharply from their 8-bit cousins. Simply put, a palette provides the means for redefining standard colors. This concept may be foreign to Commodore 64 users, who are used to a world in which color 0 is always black, color 1 is always white, and so on. On 8-bit Ataris and the IBM PC/PCjr, however, colors are easily redefined. Similar mechanisms are available on the Amiga, ST, and Apple IIGS.






    The ST's palette, for instance, contains 16 color definitions. Each color is defined as a combination of three values, which correspond to intensities of red, green, and blue light. These colors can be remixed with the Control Panel desk accessory or under program control. Not all of the palette colors are significant in every resolution, of course. In medium resolution, only four colors are redefinable (the others can be redefined, but are not visible), while in high resolution only one palette setting (actually the low bit of the color 0 setting) is useful.
    The Amiga's palette can define as many as 32 colors under normal circumstances. Again, the screen mode determines how many colors are actually available.
    The Apple IIGS handles its palette in interesting ways. A basic palette consists of 16 color definitions, just as on the ST. However, you may redefine the palette for any screen line. This may be done a maximum of 16 times for a given screen under normal circumstances. In effect, the IIGS offers 16 separate palettes which can be assigned to different horizontal screen zones. With clever programming (which involves interrupt techniques) this capability can be extended even further.
    Besides allowing you to choose exactly the shades you want, a modifiable palette lets you change large areas of the screen almost instantaneously. For instance, say that you define color 2 as black and draw a filled square in that color. If you redefine color 2 as orange, the entire square changes to orange immediately.
    By shifting the palette through a series of combinations, you can even make various objects seem to appear and disappear, a simple kind of animation. Such color cycling is familiar to those who have used programs such as NEOchrome on the ST or Graphicraft on the Amiga. The next photos illustrate a Graphicraft screen that uses color cycling to create an animated owl and rabbit: When color cycling is turned on, the owl and rabbit seem to move across the screen. In fact, all of the owl and rabbit images are on the screen at all times. Only one pair of animal images appears at any given time because all the others are given the same color as the background.
    Color cycling can be used for many other subtle effects, as well. Shapes, including text, can fade in and out of view; highlights can sparkle; water can shimmer and flow; and so forth. In the hands of an accomplished programmer, color cycling can create powerful, almost magical effects. Much of the impact of the Amiga program Polyscope, for instance, is achieved through carefully contrived manipulations of a 32-color palette.

My Interface, Right Or Wrong
The graphics capabilities of 16-bit machines are not always fully exploited. One reason why some 16-bit software looks like 8-bit software concerns maintaining a consistent user interface. Certain complex programs-word processors, databases, flight simulators, or whatever-involve many commands and take time to learn. For instance, imagine that you already have a very popular, keyboard-driven PC word processor named "Word Whiz," and wish to introduce a new version for the Atari ST. If the translation works just like the original, existing users can easily migrate to the new version without learning a host of new commands. This logic is especially compelling for programs which already have a large installed base or which, as in the case of a word processor, are used in both homes and offices.



The Right Stuff
Interface philosophy notwithstanding, there are many pieces of 16-bit software that go far beyond the capabilities of any 8-bit machine. In some cases, this is due to unique graphics features. In others, the difference arises from the superior processing power of a 16-bit machine.
    Not surprisingly, most graphics programs for the Macintosh, ST, and Amiga offer at least a few features that would be difficult or flatly impossible to achieve on any eight-bit computer. The most obvious differences are based in hardware. The Amiga, for instance, has the hardware to support many more screen modes and colors than any eight-bit machine can possibly emulate, and its graphics software tends to reflect that fact. The flexible color palette of the Amiga, ST, and Apple IIGS also opens the door to color cycling and similar effects that few eight-bit computers can simulate.
    Other differences relate to the drawing tools themselves. Every drawing program must provide some sort of movable cursor, pointer, or stylus as a means of indicating the current screen position. On 16-bit computers, the mouse and mouse pointer are integral to the operating system interface: Hardware and system software handle most of the work of reading the mouse and displaying the pointer. Because it "comes with the computer," the mouse pointer is very responsive and can be maintained with little programming overhead. Eight-bit computers weren't designed with a mouse in mind, and must use a graphics pad, joystick, game paddles, or keyboard as a substitute.
    Other 16-bit strengths can be emulated by 8-bit machines, but only at the cost of considerable extra programming. Cut and paste operations, for instance, are very common in drawing programs. On a Macintosh, ST, or Amiga, the programmer can simply call native system routines to read the drawing tool's location and movement, draw an expanding box around the captured portion of the screen, store that image elsewhere in memory, and paste it back onto the screen at a later time. On any 8-bit computer, these operations must be programmed from scratch, which increases the size of the program and may also lead to slower execution.
    The computer's memory capacity is another important factor. Half-megabyte and megabyte (one million byte) memories are common among 16-bit machines, while 8-bit machines usually have forty to fifty thousand bytes of free RAM.
    Increased memory also makes programs less disk-dependent and simplifies many programming problems. Consider an undo option, for instance. The easiest way to let the user undo the most recent operation is to store a complete copy of the screen between every drawing event. When you choose to undo something, the program simply copies the saved screen image back into the work area. With a half-million or a million bytes of memory, a 16-bit program shouldn't have much difficulty finding room for a spare screen image. In an 8-bit environment, where the program itself might consume half of available RAM, that simple solution may not be available, leading the programmer to invent a more circuitous solution or omit the option altogether.

The Heart Of The Matter
Perhaps the most important graphics device of all, however, is the microprocessor itself. The great processing speed of the 68000 chip (65816 on the Apple IIGS) now opens up entirely new categories of programs.
    Consider, for example, CAD (Computer-Aided Design) software. Many of the operations in a CAD program, such as drawing a complex, three-dimensional projection or repeatedly scaling a two-dimensional image, require an enormous number of calculations. It's possible, of course, for an eightbit computer to perform those calculations, but it lacks the number-crunching horsepower to do the job at acceptable speeds. For this reason, professional-quality CAD software has historically been available only to mainframe and minicomputer users.
    The Macintosh, Amiga, ST, and Apple IIGs have enough processing power to perform calculation-intensive graphics activities at acceptable speeds. A number of professional design systems are already available for these machines, and that number is likely to increase as the 16-bit programming community gains maturity and the professional graphics market proves its viability.
    Two examples, Easy Draw for the ST and Aegis Draw for the Amiga, are programs of a type that virtually didn't exist in the home computer market as recently as two years ago. As the photos illustrate, these programs are primarily intended for making structured drawings for architecture, engineering, business charts, and similar pursuits.
    Business graphics are another newly emerging category. As you might expect, business-specific pro grams such as Impact!, another Aegis package for the Amiga, place heavy emphasis on charts, graphs, and text.

Home Movies
Among the showiest new 16-bit graphics programs are those which simulate television or films. These programs are also good examples of software that's simply too big and complicated to run successfully in an 8-bit environment.
    Deluxe Video, a current Amiga offering from Electronic Arts, lets you create your own "videos" com plete with detailed moving graphics and musical accompaniment or sound effects in the background. This highly sophisticated package (it occupies three Amiga disks) provides everything you need to create quite elaborate animated sequences. You may import IFF-format image files from Deluxe Paint and sound effects or music files from Deluxe Music and compatible programs. The program is also compatible with the Amiga frame grabber, a utility that captures digitized video images in IFF-format files, and the genlock peripheral, which lets you overlay Amiga-generated graphics onto other video footage.
    In the pure-entertainment category, the yet-to-be released Cinemaware series from Mindscape offers interactive movies: highly realistic, role-playing adventures with detailed graphics and cinematic viewing options such as zooms, cuts, pans, and shifts of perspective. The plot is nonlinear, like an interactive text adventure. Instead of passively watching events unfold, as in a motion picture, you act through a computerized alter ego, deciding at the moment where to go and what to do.
    Not surprisingly, Mindscape plans to release interactive movie software solely for 16-bit computers (the Mac, Amiga, and ST). Full 3-D animation requires huge amounts of information: One of the Cinemaware adventures reportedly includes a full megabyte of graphics data alone.
    What does the future hold? If present trends continue, we'll see more sophisticated drawing programs with an increasing emphasis on animation and easy integration with other media such as film and video. In the entertainment arena, programs will rely more on three-dimensional animation and provide highly detailed simulations of reallife events. When software reaches this level of sophistication, the personal computer will likely be found in nearly every home.

---

Aegis Draw
Impact!
Aegis Development
2210 Wilshire #227
Santa Monica, CA 90403

Cinemaware series
Defender of the Crown
Mindscape
3444 Dundee Rd.
Northbrook, IL 60062

Deluxe Paint
Deluxe Video
Electronic Arts
1820 Gateway Dr.
San Mateo, CA 94404

Easy Draw
Migraph
720 S. 33, Suite 201
Federal Way, WA 98003

Graphicraft
Commodore Business Machines
1200 Wilson Dr.
West Chester, PA 19380