Macintosh Display Card 8o24 GC: The Naked Truth

Macintosh Display Card 8o24 GC: The Macintosh Display Card 8o24 GC, which supports monitors with depths up to 24 bits per pixel, allows use of a special version of 32-Bit QuickDraw that improves drawing performance on computers in the Macintosh II family. This article details the new card's features, describes how third-party developers can make sure their products are compatible, and tells how to take advantage of the card and its software.
Since the invention of the first computer, users and developers have been complaining about the amount of memory available, the speed of the machine, or the number of things that could be done at the same time. (Do you remember when 16K was considered a lot of memory? Of course not.) 

The new Macintosh Display Card 8o24 GC addresses the perennial issue of speed, specifically the speed with which the Macintosh executes drawing commands. With its on-board processor and accompanying software, the new 8o24 GC card can execute QuickDrawt commands from 5 to 30 times faster than standard 32-Bit QuickDraw. 

The Macintosh Display Card 8o24 GC has two independent components: the circuitry that controls the display and the hardware and software that accelerate 
32-Bit QuickDraw. 
Display Nuts and Bolts
We'll start with the display circuitry of the Macintosh Display Card 8o24 GC, which closely matches the behavior of the Macintosh Display Card 8o24. Figure 1 shows the principal components. 

Monitor Support
The new card supports all Apple monitors, including the Apple 13-Inch (B/W & Color) monitor, the Apple Portrait Display, and the Apple Two-Page Display.

The Macintosh Display Card 8o24 GC connects to a  monitor through a DB-15 connector and, via the sense lines, detects the type of monitor to which it is connected. At boot time the card senses the monitor and configures itself for it. Third party-monitors with sense lines that are compatible with Apple standards should work as well. One important difference between the 8o24 GC card and its companion Macintosh Display Card 8o24 is that the 8o24 GC does not fall back into a dormant state when it finds no monitor connected during boot time. To allow for cases when users may want to have an 8o24 GC to accelerate output to other monitors, but don't want to connect a monitor to the card, the 8o24 GC card remains active, allowing 8o24 GC software to operate. 
Depth Support
The 8o24 GC card supports depths of up to 8 bits for all monitors and 24-bit color for the 13-inch monitor (and RS-170A and PAL monitors). The 8-bit-per-pixel support for all Apple monitors implies, among other things, that true gray-scale output is possible with both the Apple Portrait Display and the Apple Two-Page Display. 

On a high-resolution (13-inch) monitor, the 8o24 GC card can display 24 bits of color per pixel. As many people have noted (repeatedly), with this level of depth support, applications can display more colors than most human eyes can discern.
NuBus Block Transfers
The new card uses NuBust block transfers to accelerate display in other display buffers present in the system. The Macintosh Display Card 8o24 GC is a NuBus master card. When it detects other cards in the system that can accept block transfer calls, the card uses block transfer mode to improve the performance of QuickDraw operations all across the board. For video buffer cards that do not support block transfer mode, the Macintosh Display Card 8o24 GC uses a special pseudo block transfer to optimize video performance.

Hardware developers should take special interest in designing cards that will make use of the block transfer mode, which will allow them to squeeze the most performance out of NuBus. The 8o24 GC card can receive block transfers (acting as slave), so other cards that may move data to the card's memory can move the data faster.

This is probably a good place to emphasize that, although you can have as many 8o24 GC boards as you  want (or as many as you can afford), only one will function as a graphics accelerator. At boot time QuickDraw GC uses the card in the lowest slot. Any other 8o24 GC card becomes a glorified display card that is basically equivalent to the  Macintosh Display Card 8o24.
Video Signals
The RS-170A standard video signals produced by the 8o24 GC card allow you to connect computers in the Macintosh II family to NTSC devices. Note, however, that the RS-170A signals are not directly NTSC compatible. A box is necessary to produce NTSC output that can be displayed on a standard television set or used along with other video equipment such as a VCR. You can generate NTSC black-and-white output by making a cable that uses the green video signal (which also carries  a sync pulse), as shown in Figure 2.

When displaying images Macintosh monitors refresh all the scan lines every time they refresh the screen. This process is called noninterlaced video. RS-170A monitors, which are interlaced devices, can scan only half the lines during each vertical scan. Every other line is "repainted" every time the screen is refreshed.

Interlaced video is reasonably good for pictures and images in general, but really poor for the display of thin horizontal lines, which seem to flicker when repainted only every other scan. Because the Macintosh desktop is ordinarily full of such lines, the desktop looks bad when displayed on interlaced devices. To overcome this problem, the RS-170A output of the 8o24 GC card uses a technique called Apple convolution. The technique is basically a filter that, before displaying a scan line, averages each line with the line above and the line below. This filter is applied to all depths except direct RGB (24 bits per pixel) when the card is operating in RS-170A mode .

 PAL-Compatible Signals
The Macintosh Display Card 8o24 GC also produces video signals that are compatible with PAL timings. These signals can be used to produce PAL output 
to drive video devices of the type used in most European countries.

The PAL-compatible signals have the same characteristics as the RS-170A output; that is, the output is interlaced. For settings of 1 to 8 bits deep, a convolution filter 
is applied before each line is produced. The PAL output mode is triggered through one of the extended sense-line configurations, as described in the accompanying sidebar, "Extended Sense Line Protocol."
All these components come in a single file called 8o24 GC, which must be moved to the System Folder as a single-step installation process. At boot time, after the "Welcome to Macintosh" screen appears, the System looks for the file and, when it finds it, installs the GC software as a transparent upgrade to 32-Bit QuickDraw. The installation consists of loading the GC QuickDraw code into the card memory, loading the GC kernel (GC OS) and initializing its structures, and loading and initializing the IPC software. At INIT time, the rocket icon appears to indicate the presence of the GC software in the System.
The 8o24 GC file contains a Control Panel device that allows the user to turn acceleration on and off. 
The Hand Is Quicker Than the Eye
A good way to start the discussion of GC QuickDraw is by separating QuickDraw calls into two global classes. The first class consists of the "drawing" commands-LineTo and FrameRect, for example. The second class consists of the "state"-oriented calls, such as SetPenState and RGBForeColor. 
Drawing Calls
When 32-Bit QuickDraw is running the show, all drawing commands cause one of the standard QuickDraw bottleneck procedures to be called. For example, calling PaintRect causes StdRect to be called, and calling FillPoly ends up invoking StdPoly. "Under" the bottleneck procedures, QuickDraw takes the commands and goes into a set of calls that execute commands based on the type of drawing taking place. The lowest level for QuickDraw is the code that actually draws to the devices affected by the drawing that is being executed.

The software for the 8o24 GC card takes effect at the level immediately under the standard (bottleneck) procedures. If DrawChar is called, for example, QuickDraw checks to see if the CQDProcs field in the current port is nil and, if so, calls the StdText routine. At this point the IPC software intercepts the call and passes the request to GC QuickDraw to initiate the accelerated process.

The previous paragraph points to an important fact: If an application completely replaces the standard bottleneck procedures, it is effectively turning acceleration 
off. Ordinarily standard bottleneck procedures are completely replaced only when driving nondisplay devices such as printers, so there is no conflict with the acceleration scheme. But some applications may bypass QuickDraw completely. 
By doing so they forgo the benefits of accelerated QuickDraw.

When the IPC takes control, it handshakes with the card kernel, queues the command in the asynchronous buffer, and returns control to the application. From the application's point of view, the call to QuickDraw returns almost immediately and allows the application to continue its execution. This parallelism reduces the apparent time it takes QuickDraw to perform a drawing operation. Performance is also enhanced because, while GC QuickDraw is performing the task, the application can be busy calculating whatever is necessary for the next call.

When GC QuickDraw processes one command from the queue, two paths are available. If the target is the current port, and if no changes have been made, 
GC QuickDraw goes ahead and does the drawing; it has in its cache everything it needs. On the other hand, if the target is a different port, or if the current port has changed, GC QuickDraw proceeds to import the necessary parameters from main memory, set its own structures, and finally do the actual drawing. In this discussion, we've used the word port, but the same principle applies to any change if the destination is a GWorld or if the GDevice associated with the destination has changed.

The application can issue as many drawing commands as necessary. The IPC software buffers them as needed, and GC QuickDraw completes all operations as quickly as it can. The result is a completely asynchronous operation that gives applications the fastest responsiveness and frees more processor time for application calculations (applications have more time to think!).

There are some exceptions to the complete asynchronous scheme. Calls (such as CopyBits) that involve not only the destination port/device combination, but also different source and destination environments, make it necessary to flush the queue by processing all pending operations and then performing the setup for the call. Once the CopyBits call has been initiated, it is executed in parallel for optimum performance. Software developers should note that using GWorlds to buffer PixMaps makes CopyBits intrinsically faster.
Parameter-Changing ("State") Calls
The Macintosh Display Card 8o24 GC acceleration mechanism concerns itself mainly with the drawing class of calls. Parameter-changing calls also have an important effect on the overall performance of GC QuickDraw. The  8o24 GC software does not work in its own environment, but heavily relies on the global structures that QuickDraw keeps in main memory. 

Instead of loading all the parameters with every call, GC QuickDraw caches all the data structures it needs, but has to reload the data when changes are detected. Some of the structures cached by GC QuickDraw are color tables, GDevices, GWorlds, PixPats, Fonts, and Width Tables. Changing the pen or modifying the foreground color, for example, invalidates the cached data. To squeeze the maximum out of the 8o24 GC card, it is therefore important to group calls that draw elements with shared characteristics (same color, same pattern, and so forth) instead of constantly changing port parameters between drawing calls.

Changing directly any structure maintained and used by QuickDraw has always been a clear and dangerous compatibility risk. The 8o24 GC software cannot detect changes to the drawing environment unless you use the proper calls to accomplish such changes.
Not all QuickDraw calls are redirected when acceleration is enabled. Acceleration affects only calls that either perform drawing operations or change the state of QuickDraw structures. A list of such calls follows.

SetPortBits PortSsize   MovePortTo
SetOrigin   SetClip ClipRect
StdLine StdBits StdText
StdRgn  StdArc  StdRRect
StdOval StdRect StdPoly
InitGDevice DisposGDevice   AddSearch
DelSearch   AddComp DelComp
DisposPixPat    CopyPixPat  MakeRGBPat
GWorldDispatch  HidePen ShowPen
SetPenState PenSize PenMode
PenNormal   BackColor   ColorBit
OpenRgn OpenPicture OpenPoly
CopyRgn SetRectRgn  RectRgn
OffsetRgn   InsetRgn    SectRgn
UnionRgn    DiffRgn XorRgn
MapRgn  RGBForeColor    RGBBackColor
CopyPixMap  PenPixPat   BackPixPat
OpColor HiliteColor SetPortPix
PenPat  BackPat CopyBits
DrawPicture PMgrDispatch    
The Developer Point of View
The best feature of the Macintosh Display Card 8o24 GC is that application developers have little to worry about when it comes to compatibility. You must put forth some effort to do something in an application that GC QuickDraw cannot straighten out. 

The one area that may require some rewriting is changing the way an application allocates offscreen drawing environments (see "Braving Offscreen Worlds" in 
d e v e l o p, issue 1). When a GDevice is created by hand (instead of by a call 
to NewGWorld), all the structures are kept in main memory. Drawing to this environment and then using CopyBits to display the result takes a greater number of NuBus transfers.

When a drawing operation that involves a GWorld occurs, GC QuickDraw immediately caches the complete GWorld structure in the card's memory if the structure has not yet been cached and if sufficient memory is available. (The card's optional DRAM kit is an important addition for applications that work with large GWorlds.) When CopyBits is called to display the results, the transfer of pixels to the screen driven by the 8o24 GC card is therefore really fast because there is no NuBus transfer. Even displaying the image into other monitors benefits, especially when the other cards can accept block transfers. Drawing operations to and from GWorlds can be executed in parallel. This is not the case when drawing to or from old-style offscreens (see Figures 6 and 7).

When applications create offscreen environments by hand, GC QuickDraw performance is affected because the data has to go many more times across NuBus. For example, if an application draws to an offscreen port and then calls CopyBits to display the results on the screen, the following happens:

1.  IPC passes the drawing command to GC QuickDraw.
2.  GC QuickDraw does the drawing across the Nubus to buffer.
3.  The application waits for the completion signal.
4.  IPC passes the CopyBits call to GC QuickDraw.
5.  GC QuickDraw copies from main memory.
6.  .to the frame buffer.

Finally, QuickDraw operates more efficiently when the PixMap's rowBytes is 
a multiple of four (long word alignment). It just happens that when NewGWorld 
is called it creates the offscreen PixMap in such a fashion, which increases the performance of QuickDraw even when the offscreen buffer could be in main memory. When an application uses GWorlds to buffer the display, GC QuickDraw can use the cached data in its memory and minimize NuBus traffic. The steps are as follows:

1.  IPC passes the draw command and returns control to the application immediately.
2.  GC QuickDraw executes the command as soon as possible.
3.  IPC passes the CopyBits call and returns.
4.  GC QuickDraw moves pixels from the local copy of the GWorld to the screen buffer while the application does its stuff.
Compatibility Issues
As mentioned earlier, GC QuickDraw is port oriented, which suggests that to improve performance it caches the port's structure in its entirety while drawing 
to a port. The implication is that, if an application draws to different ports in 
an alternating fashion, the application is forcing GC QuickDraw to flush its asynchronous buffer and move data from main memory with each drawing command.

To get the best performance from GC QuickDraw, a good programming technique 
is to bundle all drawing operations that affect a given port and complete them before changing ports to do some more drawing. As noted earlier, it is also important to 
put together all the calls that affect a single port and share characteristics such 
as color, pattern, and pen. The same admonition applies to GWorlds because 
GC QuickDraw caches the GWorld into its memory when a GWorld is the destination of a drawing operation. Changing GWorlds and drawing to each one 
in rapid succession means that GC QuickDraw has to keep flushing its asynchronous buffer and moving the necessary data from memory, which could imply copying 
the new GWorld, including its PixMap (and 32-bit PixMaps can be a lot of bytes to move).
Bottlenecks and Structure Changes
As mentioned earlier, two areas make life difficult for an application running under GC QuickDraw. These areas are replacing the bottleneck procedures and changing QuickDraw structures directly.

Replacing bottleneck procedures. Replacing the standard bottleneck procedures is a time-honored tradition in the Macintosh world. The problem is that, if an application replaces a standard procedure and does not end up calling the original default trap after it finishes its manipulations, the application is turning off acceleration. Whenever possible-and if acceleration is desired-the application 
that replaces the standard bottleneck procedures should call the original through the trap dispatcher before returning to the main program.

Changing QuickDraw structures. The dangers of messing up with QuickDraw structures directly are well known to all. Nevertheless, some applications still go about happily changing structures. As a rule, you should call the ToolBox whenever possible to change the state of the drawing environment. When the need is too strong, use the calls that alert QuickDraw to the changes you're making.
Timing
One interesting compatibility problem is not uniquely tied to the 8o24 GC card but has to do with faster hardware in general. Some techniques still being used are direct descendants of routines that were implemented for the 64K Macintosh. Now, with new machines, these techniques simply run too fast. 

One example is the "marching ants" technique of repeatedly calling FrameRect, with each repetition shifting a pattern 1 bit to create a rippling frame on the screen. The trick is still valid, but now causes a problem. In the time it took the Ol' Macintosh to make four passes through the FrameRect loop, a newer Macintosh can make hundreds of passes. With 8o24 GC acceleration on, the number is even greater. The result is that the marching becomes jerky and annoying, and the cursor tends to disappear, because HideCursor is being called to complete the FrameRect call. The cursor appears and disappears so quickly that it becomes invisible.

Do not time loops based on the performance of a given machine. For any form of animation, use the Time Manager routines to time your application. 

Drawing Directly to the Screen
As a final admonition, do not draw directly to the screen. Drawing directly to the 
screen puts any application at immediate compatibility risk with 32-Bit QuickDraw and with all Apple and third-party 24-bit video cards. Drawing directly into the 8o24 GC card's display buffer will probably cause crashes and, at the minimum, create weird artifacts if both the application and GC QuickDraw are drawing at the same time.
Programming the Am29000 (Nope!)
No, you can not program the Am29000 yourself. At the moment of this writing, third-party applications cannot make direct use of the Am29000 processor for any purpose. 

The good news is that Apple recognizes the burning desires developers have to use the Am29000 for more than accelerating QuickDraw, and future releases of the software may provide such capability. So if you have a brilliant idea, Apple wants to know about it. Although implementation details are not yet available, you can start by sending a message that describes what you want to do and what kind of support you hope the GC software can give you.

Send these and any other comments about programming the Am29000 on the 8o24 GC card to AppleLink address FAST.GRAPHIC. Apple will get back to you when more information is available.

One piece of software that has not been mentioned is the 8o24 GC cdev. With it users can turn acceleration on and off through the Control Panel. Although turning acceleration on and off should be left under the control of the user, you may want to provide users with some kind of on/off dialog box or menu option. The Developer Essentials disc (this issue) contains the GraphAccel.o file, an MPW library that accomplishes this task. A sample FKey for turning acceleration on and off is included with the library.

A new call was implemented with 32-Bit QuickDraw to allow an application to determine whether a drawing operation initiated by it, and affecting a given port, has been finished:

Function QDDone(pPtr: CGrafPtr): Boolean; 

This call may be of especially good use if you're interested in timing each individual call. It may also be of use in some animation situations, such as when you want to initiate the next drawing action only after execution of a prior call has definitely concluded.

QDDone returns FALSE if QuickDraw is in the process of drawing to pPtr and TRUE when QuickDraw is done.  If pPtr is nil, QDDone returns TRUE only when drawing to all ports is completed. Note that when nil is passed to the call, background processes such as clocks could prevent QDDone from ever returning TRUE.

Function QDDone(pPtr: CGrafPtr): Boolean;
INLINE $203C, $0004, $0013, $AB1D;  { Move.l #$00040013,D0
                                     _QDOffscreen
                        }
FINALLY
The Macintosh Display Card 8o24 GC is Apple Engineering's response to the demands for enhanced graphics performance for the Macintosh family of computers. Designers of graphics-intensive applications now can concentrate on the algorithms that will improve overall performance instead of using design resources to squeeze the last drops of display speed, a choice which often compromises compatibility and ease of use.

Developers get the benefits of the 8o24 GC card with almost no programming hit. Coding of special routines to achieve faster performance is unnecessary. Following old, simple QuickDraw rules, developers can be assured of faster graphics performance at no extra cost.

----------

GUILLERMO ORTIZ  (in a rare interview):  How long have you been with Apple and why?  Six years plus, and we've got good people and better beer busts.
 Did you enjoy your sabbatical? Yes, the energy it restored lasted a full two weeks. 
What's the best book you recently read? Between Past and Present by Neil A. Silberman, a new look at archeological findings and discussion of how facts present and past are seen according to the political/social currents of the times.
What're you reading now? Invisible Matter and the Fate of the Universe by Barry Parker.  He says that according to current knowledge, 90 percent of the matter of the universe is missing. This leaves some possibilities:
a.  We don't have a clue of what is going on. 
b.  Our current models don't closely enough represent the universe.
c.  Physical laws don't apply out of the local universe.
d.  I don't know what I am talking about.
e.  All or none of the above.
Now a paid political announcement: "Contrary to the lies of his opponents, Mark Harlan is not a crook. Trust me!" o

