Method and apparatus for displaying a page with graphics information on a continuous synchronous raster output device

Abstract

An apparatus and method used to perform image rendering is capable of producing complex, high resolution images for a continuous synchronous raster image output device, such as a laser printer or a video display, using a minimum of random access memory. High level graphics instructions defining an image to be displayed or printed are provided by a processor executing an applications program. These instructions are interpreted to generate a set of graphics orders that are subsequently processed to create a bitmap image for output to a display or printer device. The graphics order processing system is independent of the central processor and thereby significantly reduces the central processor's image output overhead.

Claims

We claim:

1. An apparatus for creating an image which includes graphics information for display on a continuous synchronous raster output device, said apparatus comprising:

a) means for receiving and interpreting commands in a high level graphics language which define the image to be output;

b) means for generating a set of graphics orders from the interpreted high level graphics language commands, wherein a graphics order is a graphics function represented as a low level primitive;

wherein said set of graphics orders comprises initialization orders, flow control orders, bitmap transfer orders, and scanline orders;

c) means for generating a bitmap image from said graphics orders;

d) means for outputting said bitmap image to said output device at a speed required by the output device, said graphics orders representing a complete page image and using an amount of memory which is less than the amount of memory which would be needed to store the complete page image as a bitmap image;

wherein said graphics orders generation means comprises:

a) graphics interface subsystem means for receiving said interpreted high level graphics language commands and passing said received commands to at least one of a memory manager means, an immediate image data transfer means and an order construction means:

b) said memory manager means for allocating and deallocating blocks of a memory in response to calls from said graphics interface subsystem means, said order construction means and an order compaction means:

c) said immediate image data transfer means for drawing pixels in a user memory based upon pixel drawing commands passed by said graphics interface subsystem means:

d) said order construction means for building stored orders based upon blit arguments passed by said graphics interface subsystem means:

e) said order compaction means for combining multiple orders operating on the same destination pixel groups built by said order construction means.

2. The apparatus defined by claim 1 wherein said bitmap image generation means comprises a realtime image data transfer means for traversing said stored orders and converting the stored orders into bitmap images corresponding to sections of said image to be output.

3. The apparatus defined by claim 2 further comprising scanline table storage means for storing bitmap image data in a scanline run format and wherein said realtime image data transfer means retrieves said scanline run formatted bitmap image data to generate at least one of said sections of said image.

4. The apparatus defined by claim 1 wherein said image outputting means comprises a display frame buffer.

5. A method for creating an image which includes graphics information for display on a continuous synchronous raster output device, said method comprising the steps of:

a) receiving and interpreting commands in a high level graphics language which define the page image to be output;

b) generating a set of graphics orders from the interpreted high level graphics language commands, wherein a graphics order is a graphics function represented as a low level primitive such that:

i) said graphics orders are processed into bands of bitmap images which are delivered to the output device at a speed required by the output device, said graphics orders representing a complete page image and using an amount of memory which is less than the amount of memory which would be needed to store the complete page image as a bitmap image; and

ii) while the graphics information in a first one of said band is being output by said output device, the bitmap images for a second one of said bands are being generated;

c) generating said bands of bitmap images from said graphic orders;

d) outputting said generated bands of bitmap images to said output device;

e) declaring a band fault if one of said graphics orders produces only a partial bitmap image within one of said bands:

f) modifying said one graphics order for processing in a next of said bands so as to produce only a remaining part of said partial bitmap image.

6. A method for creating an image which includes graphics information for display on a continuous synchronous raster output device, said method comprising the steps of:

a) receiving and interpreting commands in a high level graphics language which define the image to be output;

b) generating a set of graphics orders from the interpreted high level graphics language commands, wherein a graphics order is a graphics function represented as a low level primitive, wherein said graphics orders are processed into bands of bitmap images for delivery to the output device at a speed required by the output device, said graphics orders representing a complete page image and using an amount of memory which is less than the amount of memory which would be needed to store the complete page image as a bitmap image, wherein said set of graphics orders comprises initialization orders, flow control orders, bitmap transfer orders, and scanline orders;

c) generating said bitmap image from said graphic orders;

d) outputting said bitmap image to said output device;

e) declaring a band fault if one of said graphics orders produces only a partial bitmap image within one of said bands:

f) modifying said one graphics order for processing in a next of said bands so as to produce only a remaining part of said partial bitmap image.

7. The method of claim 6 wherein step (c) further comprises the steps of retrieving bitmap image data in a compressed format from a scanline table;

wherein the compressed format comprises a list of bitstring specifiers each of which specifies a displacement from an origin and a run length of a scanline.

Description

SUMMARY OF THE INVENTION

The present invention is an apparatus and method used to perform image rendering in a manner which is capable of producing complex, high resolution images for a continuous synchronous raster image output device, such as a laser printer or a video display, using a minimum of random access memory. This invention yields substantial performance improvements for the processor to which the output device is attached.

A continuous synchronous raster image output device requires delivery of the output data in a fixed period of time. If the data is not delivered within the fixed period of time, the output image is corrupted. The invented method and apparatus decomposes basic graphics functions into a compact series of orders or commands suitable for realtime processing and then generates the output image on the fly. By way of contrast, excepting for applications with limited or no graphics capability, prior art techniques for continuous synchronous raster image output devices require that an entire image be constructed in memory before the image is sent to the output device.

The invented technique defines the graphic content of an image in much less memory than the rendered image would otherwise require, but in a form that can be processed and delivered to an output device at the speed required by the output device. In order to accomplish this, graphics functions are represented as low level primitives, referred to herein as orders, to guarantee that they can be converted to bitmapped images in realtime. Additionally, the quantity of orders or commands is reduced by eliminating redundant or overlapping graphics functions to minimize the memory used by the orders. This approach substantially reduces the output-related processing overhead of the central processor since it is only required to generate a high level language definition of the output image.

For printer applications, the invention uses a realtime output processor which operates on a small section of a page image at a time. Such a section is called a band. A band consists of a predetermined number of scanlines where each scanline is a series of pixels to be delivered to the output device at the speed required by the output device.

After building a first band, a second band is created while the first band is being printed. Using prior art techniques, and given the present speed of processors used to generate bitmaps of the image to be printed which is sent to the output device, it would not be possible to finish creating a bitmap for the second band before the printer finished printing the first band. That is, since continuous synchronous raster image printers print at a fixed speed, to ensure that a page is printed correctly, prior art techniques require the creation of a bitmap image of the entire page to be printed before any part of the image is passed to the printer.

By using a technique for generating bitmap images which are less than the complete page, and sending only that portion to the printer, while the bitmap image for another portion of the page is being created, the present invention results in a great cost savings by using less memory. Additionally, even if there is sufficient memory to build a complete page, by using the banding technique of the present invention, a second page can be constructed in one band while a first page in another band is being printed, thereby increasing the throughput of the printer.

The present invention accomplishes its goal by deferring the execution of application generated commands that draw pixels in the page image. These commands are converted to graphics orders rather than directly to bitmaps. The graphics orders take up much less memory than corresponding bitmaps, but can be converted to bitmaps for sending to a printer at a speed fast enough to keep up with the printer.

Since a single graphics command may affect more than one band, an order may be processed multiple times. In this connection, order command blocks, which are represented as tabular structures in memory, include information to allow selection of those graphics commands needed for a given band.

More particularly, image rendering according to the present invention uses an order construction step and two image drawing steps. The order construction step is used to build orders for deferred execution. Applications commands for pixel drawing in memory other than the page image result in bitmaps stored in user memory and do not result in stored orders because these commands are processed immediately. The bitmaps produced by immediate memory block transfers (blits) later may be used by a PDL interpreter as source bitmaps for blits into the page image.

Inputs to the order construction step are presented through a graphics subsystem interface such that each graphics call delivers arguments which the order construction step reduces to a compact command block which may include a "band" number to be used by the image drawing steps to select a subset of commands for each band of the page to be drawn.

The order construction step attempts to eliminate redundant orders by combining multiple inputs into single command blocks thus reducing the number of command blocks and the memory required to contain them.

The first (immediate) image drawing step proceeds in parallel with the generation of orders that draw objects in the page image. Objects drawn in this step are stored in the above-mentioned user memory for use as source data for the second drawing step, but the order command blocks for them are released for reuse.

The second (deferred) image drawing step starts when all orders for the page image have been generated. This step may process order commands multiple times, once for each image band affected. Orders that do not affect the current band are skipped.

The first band affected by an order command is identified by the band number included in the command. When an order command is processed, the band number is updated to the next band number if the order command affects multiple bands.

The invented technique is applicable not only to printers, but to raster scanned displays as well. The ever increasing x-y resolution of computer displays, in combination with the even more rapidly increasing color (z) resolution, has resulted in video memory requirements that are comparable to those of high resolution graphics printers. For example, a 600 dpi laser printer requires approximately 4MB of RAM, whereas high resolution displays now on the market require approximately 3MB of RAM. However, there have not been corresponding improvements in the CPU to video controller interface. Consequently, CPU performance suffers due to the large number of CPU cycles required to update the video RAM. Even though CPU throughput has increased dramatically, such increased performance is not realized during video transfers since the CPU must wait to carry out each memory transaction to the video memory across a relatively slow interface.

The video display update bottleneck is being addressed through two implementations: execution of higher level drawing operations within the display adapter itself and placement of the video adapter memory on a bus more tightly coupled to the microprocessor.

The execution of higher level drawing operations within the display adapter are embodied in a class of adapters typified by IBM's XGA display architecture. These higher level operations consist of straight line drawing and screen-to-screen movement of data. In reality, neither of these operations occur frequently in typical display applications, minimizing the benefits these controllers provide.

The move to place the display adapter closer to the microprocessor on its "local" bus requires a significant change to current PC motherboard architecture. Two proposals to modify this architecture are underway by the Video Equipment Standards Association (VESA) and Intel Corporation through the Peripheral Component Interconnection (PCI) bus. Should either of these standards be adopted, video screen updates will significantly improve due to the removal of the current interface bottleneck present in current architectures. However, overall system performance will be less than optimal as the processor must still carry out all operations to the display memory. The proposed local bus standards simply increase the efficiencies of accessing this memory.

The present invention converts application generated display commands to graphics orders rather than directly to a bitmap image. Conversion of the graphics orders to a bitmap image is performed in a co-processor external to the CPU, thereby substantially relieving the CPU of display transfer overhead. For a typical high resolution display, a 40:1 reduction in CPU display activity can be achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is block overview diagram of a process for generating a printed page based upon an application which generates graphic images which are to be printed.

FIG. 2 is a functional block overview diagram of output controller 15 and bit map image generator 17.

FIG. 3 is a functional diagram of an implementation of output controller 15 and bit map image generator 17 according to the prior art.

FIG. 4 is a functional diagram of an implementation of output controller 15 and bit map image generator 17 for printer applications according to the present invention.

FIG. 5 is a functional diagram of an implementation of output controller 15 and bit map image generator 17 for display applications according to the present invention.

FIGS. 6A-6B show typical Laser Printer Paper Paths.

FIG. 7 shows pass 1 and pass 2 image placement.

FIGS. 8A-8B general bitmap structure.

FIG. 9 shows logical bit addressing.

FIG. 10 shows blitter/printer functional block diagram.

FIG. 11 shows blitter and printer register set.

FIG. 12 shows PCB record structure.

FIG. 13 shows common boolean transfer functions.

FIG. 14 shows three operand boolean functions.

FIG. 15 shows display list example.

FIGS. 16A-16B shows bitstring specifier internal address positions.

FIGS. 17A-17B shows bitstring specifier formats.

FIGS. 18A-18B companion halftone specifier formats.

FIG. 19 shows bitstring specifier table example.

FIGS. 20A-20D shows Halftone specifier table example.

FIG. 21 shows illegal usage of bitstring specifier.

FIGS. 22A-22B show halftone specification for BitBLT operations.

FIGS. 23A-23B shows halftone specification for scanline operations.

FIG. 24 shows destination BLT to Banded Bitmap, front side of a page.

FIG. 25 shows destination BLT to Banded Bitmap, back side of a page.

FIGS. 26A-26B show Source/Destination BLT to banded bitmap, front side of a page.

FIGS. 27A-27B show Source/Destination BLT to banded bitmap, back side of a page.

FIGS. 28A-28C shows Source/Halftone/Destination BLT to banded bitmap, front side of a page.

FIGS. 29A-29C shows Source/Halftone/Destination BLT to banded bitmap, back side of a page.

FIGS. 30 shows Destination BLT to frame.

FIGS. 31A-31B show Source/Destination BLT to frame.

FIG. 32A-32C show Source/Halftone/Destination BLT to frame.

FIGS. 33 shows Destination BLT to unbanded bitmap.

FIGS. 34A-34B show Source/Destination BLT to unbanded bitmap.

FIGS. 35A-35C show Source/Halftone/Destination BLT to unbanded bitmap.

FIGS. 36 shows Banded Bitmap Parameters.

FIGS. 37A-37B shows Halftone Bitmap Parameters.

FIG. 38 shows Unpacked Source Bitmap.

DETAILED DESCRIPTION OF THE INVENTION

The present invention handles rendering of an image and delivery of the image to a continuous synchronous raster image output device. The invention will first be described in the context of outputting a page image to the print engine of a laser printer or other raster printing device. Referring to FIG. 1, an application 11 according to instructions from a user through an application service interface generates a representation of an image to be printed in a page description language (PDL) 13 such as Postscript which is available from Adobe Corporation. A PDL defines commands which allow complete and precise control of bitmap and halftone images as well as all of the attributes of character fonts including point size, orientation, shade and slant. Although the present invention is described for use with a PDL, it will be recognized that any high level graphics language may be employed. The application service interface which generates PDL instructions representing the image is the same regardless of underlying hardware and/or software support. For example, assume a user instructs an application program to draw a line from point A corresponding to a bitmap image coordinate of x1,y1 to point B corresponding to a bitmap image coordinate of x2,y2. Such an instruction would generate a series of Postscript instructions (excluding page and line setup instructions) as follows:

newpath

x1 y1 moveto

x2 y2 lineto stroke

In the simplest case where there is no special hardware and no banding according to the present invention, the PDL instructions are, in effect, directions to a PDL interpreter in output controller 15 which produces the page image. The PDL interpreter interprets the PDL instructions, producing graphics objects and character bitmaps as directed. Only a few of the PDL instructions result in drawing. The remaining instructions control the use and positioning of objects in the page image.

For example, in the Postscript instructions above, the newpath operator causes the PDL interpreter to initialize internal information to control subsequent operations. The moveto operator establishes an initial position within the coordinate system. The lineto operator establishes a new position with an unexpressed or "uninked" line between the initial position and the new position. When the interpreter processes the stroke operator, it will generate one or more graphics commands to underlying pixel drawing routines which draw the line in the page image memory.

In this case, the graphics calls are handled by the output controller synchronously. That is, a particular graphics call generates a portion of an image which is to be printed which is stored in a page buffer after which control is returned to the PDL interpreter. The interpretation and drawing steps continue work on the same page image until a page termination operator is found. Then the page image memory is copied to the output device by the hardware. The output copying step may operate asynchronously to the interpreter and graphics functions if there is enough memory to allow the interpreter to produce an image for the next page while the hardware delivers output from the previous page via DMA or other means.

Output controller 15 utilizes a graphics interface which includes graphics support routines which operate in the coordinate system of the output device 19 wherein the origin of the image coordinate system of the output device corresponds to the first pixel written to the output device. The x-axis of the image coordinate system is parallel to the output device scan (raster) lines. Thus, in left to right printing, pixels are output in increasing x-coordinate order, but in top to bottom printing, scan lines are output in increasing y-coordinate order.

The PDL interpreter part of the output controller specifies the size of the page image by giving its width and length. The PDL interpreter part of the output controller also specifies the placement of the image within the physical page by supplying top and left margin parameters. These parameters are expressed in pixels.

The graphics interface of output controller 15 creates two types of calls as follows:

1) calls relating to pages; and

2) calls which draw bit images.

Calls relating to pages are as follows:

1) New Page--performs initialization for a new page image.

2) End Page--starts the realtime printing process if the output device is idle or queues the image orders if the output device is busy.

3) Abort Page--if the printing phase has not started, throws away the orders for the page.

4) Abort All--throws away all pages waiting to be printed.

There are six classes of bit image drawing calls as follows:

1) Two Operand Blit--performs a two dimensional bit block transfer between two bitmaps, a source and a destination.

2) Three Operand Blit--performs a two dimensional bit block transfer using three bitmaps, a source, a halftone, and a destination.

3) Draw Scanline--writes pixel groups on a contiguous block of scanlines within the destination bitmap. The input includes a table defining pixel groups to be written.

4) Draw Scanline Halftone--writes pixel groups to the destination bitmap according to the contents of a halftone source bitmap and a table defining pixel groups to be written.

5) Draw Pixels--draws individual pixels in the destination bitmap according to a pixel table.

6) Draw Pixels Halftone--draws individual pixels in the destination bitmap according to the contents of a halftone source bitmap and a pixel table.

Generally each of the six classes has at least two calls, one for writing to the page image bitmap which the graphics subsystem interface manages; the other for a PDL interpreter managed destination, typically, a RAM user memory.

Interface to Bit Image Drawing Calls

Generally, bitmap image drawing calls expect user and halftone bitmap descriptors as input. A user bitmap descriptor contains bitmap origin byte address, i.e., the memory address of the upper left corner of the bitmap, bitmap width in pixels, i.e., the number of pixels per scanline, and bitmap height in pixels, i.e., the number of scanlines. Bitmap width and height may be arbitrary pixel values. Clipping occurs to the specified bitmap width and height for destination bitmaps; no source bitmap clipping is performed.

While user bitmap dimensions have no boundary constraints, a halftone bitmap width is constrained to be 0 mod 32 pixels (32-bit word multiple). In addition to bitmap origin, width, and height, a halftone bitmap descriptor has three additional fields. Two of the additional fields are x,y origin parameters specifying the point in the halftone bitmap that corresponds to the destination bitmap origin. The third additional field provides halftone bitmap size in bytes. Halftone bitmap usage wraps instead of clipping. This causes the halftone bitmap to appear to repeat in the destination bitmap in both the x and y dimensions.

Normally the contents of a source bitmap do not change except by means of subsequent calls to the graphics service routines performed by output controller 15. However, occasionally the PDL interpreter needs to directly change the contents of a source bitmap after using it in a graphics service call. Since graphics services are not necessarily performed synchronous to the requests (that is, completed prior to the service requests return), a direct change may change the bitmap contents prior to its use by the output controller. In such a case, the bitmap must be declared "volatile," for example, by the PDL interpreter passing a "volatile" flag as an argument to the graphics interface of output controller 15.

This feature must be used sparingly and only where truly needed due to the expense in memory and processor time. It is not intended as a substitute for PDL interpreter management of required memory. When the PDL interpreter and the other portions of output controller 15 operate synchronously, no problem arises. If the two processes run asynchronously as they do when the controller includes hardware assistance or when double buffering is in effect, the output controller must make a copy of a "volatile" bitmap so that the bitmap does not change before it can be used. The caller, i.e., the PDL interpreter can flag a bitmap as volatile in its descriptor.

FIG. 2 shows the functions according to the present invention performed by output controller 15 which inputs PDL commands, interprets the PDL commands and generates graphics commands or orders, and by bitmap image generator 17 which generates a bitmap of the image to be printed from the graphics orders and outputs the image to the printer.

A functional block diagram of output controller 15 and bit map image generator 17 as implemented in the prior art will now be described with reference to FIG. 3. Specifically, output controller 15 and bitmap image generator 17 comprise a graphics interface subsystem 23 which receives the graphics calls generated by PDL interpreter 21 based upon the PDL instructions 13 generated by application 11. The graphics interface subsystem passes the graphics calls to immediate blit processor 29. User memory 24 is a random access memory used by PDL interpreter 21 as a temporary storage of source bitmaps which will be passed to graphics interface subsystem 23 as source arguments to graphics calls. Memory manager 43 allocates and deallocates RAM memory blocks as requested by graphics interface subsystem 23. When an End Page instruction is called by the PDL interpreter, the actual bitmap images to be printed are transferred from page buffer 42 to DMA hardware or a FIFO buffer 53 for transfer to a printer by operation of output interface 47, output interrupt handler 49, and graphics interface subsystem 23.

The specific manner in which the elements shown in FIG. 3 operate to produce a raster output suitable to be sent to a printer is as follows.

PDL interpreter 21 processes the incoming PDL source statements, calling the graphics interface subsystem 23 as necessary using calls relating to pages and bit image drawing.

When the PDL interpreter calls the graphics interface subsystem 23 to start a new page, the graphics interface subsystem calls memory manager 43 to allocate memory for the page image.

Subsequently, the graphics interface subsystem 23 calls immediate blit processor 29 for each blit command from the PDL interpreter 21 after checking the command for errors and adjusting the parameters as necessary to perform destination clipping, i.e., assuring that a blit cannot extend beyond the boundaries of the destination as defined in the blit command arguments or the extent of the page image.

PDL interpreter 21 calls the graphics interface subsystem 23 when it has completed processing for the page. The graphics interface subsystem then calls output interface 47 to deliver the image for output.

The output interface checks to see if output is in progress and if not starts the printer hardware and delivers the first data to the DMA or FIFO device 53.

If output is in progress, output interface 47 places the new output image on its internal queue to be started when current activity completes.

Interrupt handler 49 operates by continuing the delivery of data to the DMA or FIFO 53 and by starting a queued image, if any, when the output for the current image is complete. When the output of a page image is completed, interrupt handler 49 calls a completion routine in graphics interface subsystem 23 to announce this completion. At this time graphics interface subsystem 23 can return the page image buffer 42 to memory manager 43 or re-use it for another page.

FIG. 4 is a functional block diagram showing the functions of output controller 15 and bitmap image generator 17 when implemented according to the teachings of the present invention. Before describing the elements of FIG. 4 in detail, it will be helpful to explain the major differences between the technique for rendering the output image in small bands according to the present invention and rendering it in a full page image buffer according to the prior art. These differences are as follows:

1. When using a full page buffer, graphics interface subsystem 23 uses the immediate blit processor for every pixel drawing call the PDL interpreter makes. That is order construction 31, order compaction 33, realtime blit processor 37, and the stored graphics orders 35 shown in FIG. 4 are not used in the prior art.

2. Additionally, in the prior art, output interface 47 and output interrupt handler 49 do not need to coordinate processing with a realtime blit processor which does not exist using prior art techniques, eliminating the need for what may be called an "extended interrupt processing thread."

The invented banding technique includes the following requirements:

1. An ability to differentiate between graphics requests which can be performed immediately by immediate blit processor 29 and those which must be converted to stored orders for subsequent handling by realtime blit processor 37.

2. Design of the stored order formats.

3. An order compaction function.

4. A capability for updating the stored orders by the realtime blit processor to eliminate those that it completes or mark those that it must reprocess in a way so it can efficiently reprocess an order that spans multiple bands.

While the invented technique may be implemented in software, when implemented using co-processor hardware, the hardware replaces both the immediate blit processor and the realtime blit processor. In addition, in the preferred embodiment, a hardware implementation incorporates the output FIFO or DMA device 53. A hardware implementation of the realtime blit processor does the same type of order updating as that performed by a software implementation. However, since a hardware implementation runs much faster than a software implementation, the hardware implementation can band much more complex pages and keep up with much faster output devices. It also may employ a separate hardware bus for access to the band buffers 41a, 41b and 41c.

However, in a hardware implementation, software will still normally be used to construct the stored orders since the order information must be represented in a manner suitable for processing by a state machine which can be implemented in a cost effective manner.

The following is a brief description of each of the functional elements comprising the invention as shown in FIG. 4.

Graphics Interface Subsystem 23

PDL interpreter 21 calls graphics interface subsystem 23 which is a set of standard interface routines for graphics services. The graphics interface determines whether it can perform an immediate blit based on whether or not the destination is user memory 24 or band buffers 41. If it cannot do an immediate blit, it calls order construction function 31 to create stored orders 35.

After either the immediate blit is done or the orders have been constructed, the graphics interface subsystem returns to PDL interpreter 21.

Immediate Blit Processor 29

This function draws pixels in user memory 24 as requested and returns. This function is known in the prior art and is performed whenever pixel drawing commands affect a user memory destination.

Order Construction 31

Order construction processing 31 generates orders 35 which are stored in a memory for subsequent use during realtime blit processing performed by realtime blit processor 37. The orders include initialization, program flow control, bit-block transfer (for rectangular regions of bitmaps) and scanline transfers (for arbitrarily-shaped regions of bitmaps). Blit processor 37 executes both bit-block and scanline transfers.

For certain types of orders where it may be possible to combine subsequent orders with ones already known, the order compaction function 33 is called to keep track of the orders. In the preferred embodiment, at least scanline blit orders are subject to compaction. Other types of orders can be compacted in accordance with the teachings of this invention.

Order Compaction 33

This function keeps records of the orders that may be compressed until informed by the order construction processing function that it must wrap up a set of orders. Then it reinitializes its internal information to start collecting information about the next set. This function is very important in cases where many small scanline blit orders operate on a small region of the page image. Such compaction provides major reductions in the amount of memory required in cases because the blits overlap.

Stored Orders 35

Stored orders 35 is an internal representation of commands to create the images the application requested.

Realtime Blit Processor 37

When the PDL interpreter issues a call to say it has completed all the requests for a page, graphics interface subsystem 23 starts the realtime processing phase. It traverses stored orders 35 once for each band to be output. When all orders that effect a band have been processed, it calls output interface 47 to queue the band for output or start it immediately if the DMA or FIFO buffer output hardware 53 is available. If another band buffer 41a, 41b or 41c is available, it will construct the next band. When no more buffers are available, it returns to the graphics interface subsystem 23 which returns to PDL interpreter 21. The PDL interpreter may continue interpreting input and working on the next page. From this point on, realtime blit processor 37 is driven by interrupts initiated by output hardware 53.

Realtime blit processor 37 converts the stored orders into a bitmap image corresponding to a band or section of the page to be printed which is stored in band buffers 41a, 41b or 41c.

Specifically, interrupt handler 49 is notified by output hardware 53 when a band has been delivered to the printer. Realtime blit processor 37 is then called as an "extended interrupt thread" to continue its processing.

A "band fault" is declared when a stored order pertains to a bitmap image that crosses a band boundary. In such event, the stored order is marked and updated so that the order will be more efficiently processed in the next band. For example, if a character image straddles the boundary between band n and band n+1, the stored order for creating the bitmap image of the character is first processed in band n. When the band boundary is reached, the order is marked and updated with a modified source address, destination address and height for the character image so that only the remaining portion of the image is retrieved from memory when the order is processed in band n+1.

Band Buffers 41a, 41b, 41c

Band buffers 41a, 41b and 41c is a random access memory used to hold the bitmapped page image. If banding is not used, a single band buffer is used to hold a complete page. Otherwise there may be 2 or 3 band buffers of a size much smaller than the complete page.

Memory Manager 43

Memory manager 43 allocates and deallocates blocks of memory in response to calls from graphics interface subsystem 23, order construction 31, order compaction 33 or realtime blit processor 37. Memory manager 43 is a software function that manages the memory containing the stored orders and the band buffers according to well known memory management techniques which need to be employed when the other software components need to acquire or free blocks of memory. The actual bitmap images to be printed are transferred from the band buffers 41 to DMA hardware or a FIFO buffer 53 for transfer to a printer by operation of output interface 47, output interrupt handler 49, realtime Blit processing 37 and memory manager 43. In this connection, although three band buffers are shown in FIG. 4, in practice, there may be two, three or more band buffers, although in most cases two or three band buffers is sufficient.

Output Interface 47

Output interface 47 receives completed bands from the realtime blit processor and either passes them on to the output hardware 53 or queues them for output interrupt handler 49 to pass to the output hardware when it is no longer busy. With the help of output interrupt handler 49, output interface 47 monitors synchronization signals from the printer engine to determine when it can deliver a band for output. Print engines send a "frame sync" signal to indicate top of page. The output interface cannot deliver any data until the "frame sync" signal is true.

When a FIFO buffer is used as the output hardware, the software moves data from the band buffer to the FIFO a scanline at a time. A DMA controller can be used the same way. Top and left margins are created by delivering zeroes for an output device that writes black or by delivering ones for an output device that writes white.

Output Interrupt Handler 49

As the output hardware finishes delivering a band to a video interface of the print engine, it generates an input. The output interrupt handler gets the next band from its queue and passes it to the output hardware. It then returns the previously completed band buffer so the realtime blit processor may reuse it.

When the output interrupt handler returns, realtime blit processor 37 runs again until it has rendered another band before the graphics interface system returns to the PDL interpreter. This "extended interrupt thread" is implemented differently on different CPUs depending on their architectures. The "extended interrupt thread" runs on a separate stack with CPU priority lowered so that it can be interrupted.

Output Hardware 53

When banding according to the present invention is implemented in software, a FIFO or DMA controller is used to handle video output to the print engine. If the banding implementation is done hardware, it may incorporate a FIFO or DMA controller output hardware.

In the preferred embodiment, the functional elements shown in FIG. 4 are implemented in hardware, although if one or more of such elements are implemented in software, the function performed by each such element is actually performed by operation of a microprocessor executing a set of instructions in a memory such that the microprocessor generates control signals appropriate to the function being performed. In this connection, just as the specific hardware implementation details are not needed for a person skilled in the field of the invention to make and use the same, the particulars of a microprocessor, memory, data and address bus, clock and the like needed to implement the invention in software would be readily apparent to a person skilled in the art based upon the description provided herein. The following is a complete software specification for implementing the invention.

DEFINITION OF TERMS

1.1 PRINTER "LANGUAGES"

PCL: Printer Control Language. PCL is a term coined by HP upon introduction of the LaserJet laser printer. It embodies a relatively simple set of escape sequences reminiscent of ANSI 3.64. PCL is considered to be of moderate complexity.

PDL: Page Description Language. PDL's, such as Adobe PostScript and Microsoft TrueImage, are actual "document" programming languages, much like BASIC, FORTRAN, and C. PDLs are interpreted languages rather than compiled languages. The instructions for how the page is to be formed are described in lexical verbs such as FINDFONT and MOVETO. This means that the parsing and interpretation of these languages must be done in the printer engine itself. Generally, PDLs describe one page at a time, where each page is a separate PDL program. PDLs are considered to be of difficult complexity.

DDL: Document Description Language. DDLs, such as Xerox Interpress, are similar to PDLs in that they are programming languages with lexical verbs. The difference between DDLs and PDLs are that DDLs generally describe an entire document consisting of multiple pages. This adds to the storage requirements in that the entire document must be parsed and interpreted before any printing can begin. DDLs are considered to be of difficult complexity.

1.2 DUPLEX PRINTING

Duplex printing is the operation of placing an image on both sides of a page before it leaves the printer.

In a single sided laser printer, shown in FIG. 5, paper travels from the input hopper 11, under the drum 13 to receive a toner image, through the fuser 15 to set the toner into the paper, and to the output hopper 17.

In a duplex laser printer, paper travels from the input hopper 11, under the drum 13 to receive a toner image, through the fuser 15 to set the toner into the paper, and either to the output hopper 17 or to an internal duplex hopper 19. To print on both sides of a page, the paper moves from the input hopper to the duplex hopper, and then from the duplex hopper to the output hopper, passing under the drum and fuser twice.

This is further illustrated in FIG. 6A and 6B. During the first pass, paper travels from the input hopper and under the drum, where a "1" is placed. After fusing, this page is placed face down in the duplex hopper. During the second pass, paper travels from the duplex hopper and under the drum, where a "2" is placed. After fusing, this page is placed in the output hopper with the second pass image facing up. Note that in order to properly orient the two images on the page the second pass data must be sent to the printer in right to left and bottom to top order.

1.3 BANDING

Banding involves building an image to be output in strips or "bands". Generally, strip n+1 is being composed while strip n is being output to the print engine.

Banding is a process in which the page to be printed is represented in an intermediate form which describes the graphics operations necessary to construct the bit mapped image for the page. This intermediate form is commonly referred to as a `display list`. The PDL or PCL emulator firmware running on the main processor generates this display list before the print engine begins the actual printing process. The Graphics Execution Unit in PBC executes the display list to form the bit mapped image in bands after the print engine is started.

Banding is desirable in printer controllers due to its potential memory savings and system performance improvements. For banding to be viable, the intermediate representation must meet two requirements: it must fit in considerably less memory than the full image would require, and the commands to generate a band must be executable within the time it takes to print the previous band.

The graphics orders of PBC are designed to be an extremely compact representation of the printed page. RLL compression of graphics data and the elimination of redundant information in the display list enables the intermediate form of the printed page to be significantly smaller than the actual bit mapped image.

The PBC graphics coprocessor is a very high performance bit image processor. The pixel drawing rate of PBC can approach 50 million pixels per second. This level of performance enables PBC to be used effectively in banding applications or in other high speed or high density bit mapped graphics products.

1.3.1 PCL IV And PCL V (HP LaserJet Series II and LaserJet lID

The simple command set and relatively limited image generation capabilities of PCL based printers allows printer directives to be easily represented in the intermediate form required for banding. Even the additional page complexities enabled by PCL V, poses no problems for PBC. All of HP's PCL laser printers use the banding technique.

1.3.2 PostScript And Other PDLs/DDLs

PostScript and other PDLs/DDLs support a robust set of commands. These commands allow complete control of the image generation. They permit control of all of the attributes of character fonts including point size, orientation, shade, and slant.

Banding has not been possible in PDL laser printer applications due to the potential complexity of the images which can be constructed by these languages. An acceptable intermediate representation had not been developed until the introduction of the PBC graphic orders. Using the compact PBC orders, all PostScript pages, except the most complex, can be represented in less than 250 Kbytes of memory. All pages can be represented with additional memory.

1.4 BITMAP

A bitmap is a two dimensional array of memory bits, generally referred to as pixels or dots, as shown in FIG. 7. When stored in memory, this two dimensional array is represented in a contiguous run of bits with no gaps or holes.

Each row 21 of the array is referred to as a scanline or line. There is no special reference for each column of the array.

The X dimension of the bitmap array is referred to as pitch, width, or warp. Width is commonly used to describe smaller arrays, such as character bitmaps. Warp is typically used when describing page image bitmaps. The warp of a bitmap is a particularly useful parameter in that it is the value that, when added to the position in memory of a particular pixel of a scanline, results in a position in the same pixel column in the next lower scanline; warp is the amount to move to result in a Y-only movement within the bitmap.

The Y dimension of the bitmap array is referred to as height.

In addition to the physical size of the bitmap, there are two other attributes associated with it: a physical base address for the upper left pixel of the array and, optionally, a logical Y coordinate for the first line of the array. The physical base address is a bit address. The logical Y coordinate is required for banding.

1.5 HALFTONING

Halftoning involves applying a "halftone screen" or pattern to a data transfer in order to modify its appearance. Halftone screens are used to produce shades of gray in a monochrome printing environment such as printing presses, dot matrix printers, or laser printers.

Halftone screens are repetitive in both the X and Y dimensions. For example, to achieve a 50% gray level, an alternating 10101010 01010101 pattern is used, where the 10101010 pattern is repeatedly applied to the even scanlines and the 01010101 pattern is applied to the odd scanlines.

Halftone screens are commonly seen in a newspaper where a photograph with levels of gray must be represented with a medium which only allows black and white. The graininess of halftoning is an accepted side-effect for monochrome printing, although this side-effect can be relieved by increasing the resolution of the output device to the point where the human eye cannot distinguish the individual dots which make up the gray pattern.

1.6 MEMORY ADDRESSING

All address fields are 32 bits wide. The granularity of the address fields, however, depends on the type of data being referenced: Bitmap structures are always pointed to by 32-bit bit addresses, while all other data structures are referenced with 29-bit byte addresses.

In a 32-bit address field, a bit address occupies the entire width. A byte address, however, occupies only the least significant 29-bits. This provides 4 Gbits or 512 Mbytes of addressability.

When specifying a bit address in a bitmap, the traditional numbering of the bits in a word is abandoned for a more logical sequence. The most significant bit in a word corresponds to the leftmost pixel in that word. Thus, the bit addresses increase as one moves from most significant bit to least significant bit. This is further illustrated in FIGS. 8A and 9B, which show eight bytes 0.times.88, 0.times.77, 0.times.66, 0.times.55, 0.times.44, 0.times.33, 0.times.22, and 0.times.11 stored in two words of a bitmap.

The following sections describe the data structures used by the PBC to control its operation and render graphical images.

GRAPHICS EXECUTION UNIT & PRINT ENGINE VIDEO CONTROLLER

The PBC contains two independent subsystems to simultaneously render and print page images: the Graphics Execution Unit (GEU) and the Print Engine Video Controller (PVC). The Graphics Execution Unit is used to execute a display list of graphic orders and render a page image, while the Print Engine Video Controller is used to transfer the rendered page image data to the laser print engine. This section describes the software interfaces to PBC for controlling the Graphics Execution Unit and Print Engine Video Controller.

The software interfaces to the Graphics Execution Unit and Print Engine Video Controller employ a combination of resources: PBC registers, memory-resident command blocks, and microprocessor interrupts. The following is a brief overview of the operation of the Graphics Execution Unit and Print Engine Video Controller.

2.1 BASIC OPERATION

A functional block diagram of the PBC's Graphics Execution Unit and Print Engine Video Controller is shown in FIG. 9. The Graphics Execution Unit is started by writing the beginning address of a display list to an PBC register. The Graphics Execution Unit executes the display list and renders a page or band image. When the end of the display list is reached, the Graphics Execution Unit generates an interrupt to the microprocessor, and waits for another display list address. A second display list address can be loaded while the Graphics Execution Unit is working on the first display list. In this case, upon completion of the first display list, an interrupt is generated and the second display begins executing immediately. A second interrupt is generated upon completion of the second display list.

The Graphics Execution Unit can render an entire page from a display list, or multiple bands from a single "banded" display list. A banded display list contains band information near the beginning of the list. This band information includes the address and size of the band as well as the band number that is to be processed. The Graphics Execution Unit uses this information to determine which orders from the display list to process and where in memory to create the bit map image for this specific band. Thus after one band is fully rendered and the Graphics Execution Unit generates an interrupt, software simply adjusts the display list to reflect the next band information and then restarts the Graphics Execution Unit.

This interface between the processor and the Graphics Execution Unit allows complete freedom in the design of the banded memory system. The quantity, size, and location of band buffers is determined by the main processor's software. These band parameters can be dynamically altered to suit a particular application or page complexity. The desired band number is included to allow for non-sequential band processing applications such as duplex printing.

After a page image (or band image) is created by the Graphics Execution Unit, the Print Engine Video Controller is used to transmit the page image to the print engine. The Print Engine Video Controller is started by writing an address of a print command block, or PCB to an PBC register. Upon activation, the Print Engine Video Controller reads the parameters from the PCB, fetches the first page image data from memory, and then waits for the beginning of page signal (Frame sync, FSYNC) from the print engine. When FSYNC is detected, the Print Engine Video Controller generates a "band begin" interrupt, and starts transmitting the page image video data to the print engine. When the entire page or band image has been transmitted, a "page end" interrupt is generated, allowing software to reuse the page image memory space.

When banding, the Print Engine Video Controller must be given several PCB addresses throughout the course of one page. After each "band begin" interrupt is generated, software may load another PCB address to the next band's page image. It may reuse the band image memory and the PCB structure used in the previous band at this time.

The Print Engine Video Controller automatically manages all parameters associated with the video image. Top margins and left margins are automatically inserted by the Video Controller. The Page Width parameters are used to calculate the beginning address of each scanline. The page or band height parameters are used to determine the end of the page or band.

This type of print engine video interface eliminates all software overhead associated with the transfer of the bit mapped image to the print engine. Software merely starts the transfer and waits for the end of page or band interrupt. This frees the software to start processing the next page.

This type of print engine interface also saves a significant amount of hardware cost. Static RAM's or FIFO's are not necessary as the bit mapped image is DMA'ed directly from the DRAM memory. The Print Engine Video Controller uses an efficient page mode access to DRAM to maximize memory bandwidth and contains an internal 4 word queue for printer video data.

2.2 REGISTER SET

There are eight PBC registers that provide control of, and status from, the Graphics Execution Unit and Print Engine Video Controller. These registers are shown in FIG. 10.

2.2.1 Display List Address Register

The Display List Address Register is used to start the Graphics Execution Unit. When the Display List Address Register is initially loaded, the specified display list address is immediately copied into the Graphic Order Instruction Pointer, and the first graphic order is fetched. At this time, BLT BIJSY is set in the GEU/PVC Status register to indicate that the Graphics Execution Unit is running.

The Display List Address Register in PBC is "double buffered" to maximize Graphics Order execution. A second operation may be started prior to the completion of the first operation. The second operation will be automatically started upon completion of the first operation. The Status bit DLA EMPTY indicates when a subsequent display list starting address may be loaded. Refer to Section 2.2.7 for a detailed discussion of the function of this status bit.

2.2.2 Graphic Order Instruction Pointer Register

The Graphic Order Instruction Pointer Register contains the address of the second byte of the graphic order currently being executed. This register can be read at any time. When the Graphics Order Execution Unit detects an error, BLT ERROR is set in the Interrupt Event register and the Graphic Order Instruction Pointer is frozen until a soft reset of the Graphics Execution Unit is issued.

2.2.3 PCB Address Register

The PCB Address Register is loaded with an address of a Printer Control Block. Loading this register starts a Print Engine Video Controller operation. When the PCB Address Register is loaded, the Print Engine Video Controller reads the PCB parameters from memory. The PCB contains the starting address of the page image, its warp, width, and height, and other parameters and settings. The exact structure of the PCB is discussed below in section 2.3.

The PCB Address Register is "doubled buffered" to maximize Print Engine Video Controller operation. A second PCB operation to be started prior to the completion of a previous operation. The second PCB operation will automatically be started upon the completion of the first operation. The status of a PCB is indicated by the PCB EMPTY bit in the GEU/PVC Status register. The PCB Address Register cab only be loaded when the PCB EMPTY bit is set. Refer to Section 2.2.7 for a detailed discussion of the function of this status bit.

2.2.4 Print Signal Control Register

The PRINT Signal Control register is a 1 bit register that is used to start and control the operation of the print engine. The PRINT bit is a direct connection to the print engine via the PBC's PRINT output signal.

2.2.5 Interrupt Event Register

The Interrupt Event and Interrupt Mask registers are discussed in detail below, section 2.4. They indicate the source of an interrupt, and allow masking of each interrupt source. There is a total of eight interrupt sources.

2.2.6 Interrupt Mask Register

2.2.7 GEU/PVC Status Register

The Graphics Execution Unit and Print Engine Video Controller Status Register (GEU/PVC) is a 4 bit register that indicates the state of the Graphics Execution Unit and Print Engine Video Controller. These bits indicate when the respective controllers are operating and their memory control structures are available for use.

The PCB EMPTY bit when true, indicates that PCB Address Register and the PCB pointed to by the PCB Address Register are available for use by a new operation. This bit when false, indicates that neither the PCB Address Register nor the PCB pointed to by the PCB Address Registers may be altered. The PCB EMPTY bit will be reset when the PCB Address Register is loaded. The PCB EMPTY bit will be set by the Print Engine Video Controller when both the PCB and the PCB Address Register are available for the next PCB. If a PCB address is loaded when PCB EMPTY bit is reset, then the address is ignored and lost.

The DLA EMPTY status bit indicates the state The second load of the Display List Address Register will cause DLA EMPTY to be reset, and this bit will stay reset until the Graphics Execution Unit has finished executing the first display list and started on the second. If a display list address is loaded when DLA EMPTY is not set, the address is ignored and lost. The PRINT BUSY bit indicates that the Print Engine Video Controller is in operation. The Print Engine Video Controller sets PRINT BUSY true when the PCB Address Register is loaded. This bit will be reset upon the completion of a PCB operation. A PCB operation is complete when the last video data word is fetched from memory and loaded into the internal PBC video FIFO. The PRINT BUSY bit will not be reset upon the completion of a PCB operation if a subsequent PCB address has been loaded into the PCB Address Register prior to the completion of the previous PCB operation.

2.2.8 GEU/PVC Soft Reset Registers

The Graphics Execution Unit and Print Engine Video Controller Soft Reset registers allow software to independently initialize each subsystem to a known state. When the Graphics Execution Unit detects an error and sets BLT ERROR, it must be reset by writing a one into the GEU RESET bit. The Graphics Execution Unit is disabled from further operation when the BLT ERROR is set. Similarly, when PRINT ERROR is detected, the Print Engine Video Controller must be reset by writing a one to PRINTER RESET. Writing a zero to either soft reset bit has no effect.

2.3 PRINT COMMAND BLOCK STRUCTURE

The Print Engine Video Controller makes use of a print command block, or PCB. This address is loaded to start Print Engine Video Controller operations. The PCB is a 20 byte, 9 record structure, as shown in FIG. 11.

The Page Image Bit Address is a pointer to the starting address of the page image or band. It is interpreted as bit address, and must be byte aligned (the PBC zeroes the three least significant bits). PBC has the capability to interface to a variety of print engines. The address written into the Page Image Address Register will depend on the scanning direction of the print engine. Table 1 indicates the proper starting address for each of the 4 scanning options supported by PBC.

The Vertical Margin parameter specifies the number of non-printable scanlines from the FSYNC signal to the first printable scanline, and Horizontal Margin PCB parameters define the printable area of the printed page. These parameters specify the number of scanlines or pixels between the FSYNC or LSYNC to amount of time number of indicate the number of white-filled scanlines and white bits, respectively, that are to be automatically shifted out to the print engine before page image data is sent. The BOTTOM TO TOP and RIGHT TO LEFT bits in the PCB Control Field affect the interpretation of Top Margin and Left Margin parameters. When printing bottom to top, the Vertical Margin parameter specifies the number of white scanlines to be transmitted before any page image scanlines, thus providing a bottom margin instead of a top margin. When printing fight to left, whim bits are shipped before any bit of any scanline, resulting in a right margin instead of a left. This reversal of meaning comes about because white padding is always shipped before any page image video data.

The Page Height and Page Width PCB parameters describe the dimensions of the page image. The scan direction bits have no effect on these parameters. The Page Warp parameter allows the page image bitmap to be unpacked, and must always be greater than the Page Width to insure proper operation. The Page Warp value is used to calculate Y movement when either BOTTOM TO TOP or RIGHT TO LEFT is exclusively set.

The Video Clocks and Video Scanlines PCB parameters are used for specifying print engine parameters for those print engines that don't provide an FSYNC and/or LSYNC signals. The Video Clock parameter specifies the number of clocks the print engine will generate per scanline. The Video Scanlines parameter specifies the number of scanlines that must be transmitted per page.

When the Video Clocks parameter value equals zero, the Engine Video Controller will wait for the assertion of LSYNC before transmitting each scanline.

When the Video Scanlines parameter value equals zero, the Print Engine Video Controller will wait for the assertion of FSYNC at the beginning of each new page.

The Video parameter values are sampled at the top of every page. In banding applications, the parameters are read on the first band of the page, and ignored for successive bands in the page.

Note that the Vertical and Horizontal Margin values have no effect on other Video parameters.

The Control field of the PCB contains three control bits. LAST BAND is used by software to indicate the final band of the page; LAST BAND must also be set for unbanded page images. The Print Engine Video Controller returns an "page end" interrupt when the last word of the last scanline of the page image has been read from memory. Software can then reclaim page image memory space.

LAST BAND also determines the print engine signals used for video synchronization for the next band to be printed. When LAST BAND is reset, the Print Engine Video Controller will start the transfer of video data for the next band on the first assertion of LSYNC. When LAST BAND is set, the Video Controller will wait for the assertion of FSYNC and then will start the data transfer for the next band on the next LSYNC.

The last two control bits in the Control field are the BOTTOM TO TOP and RIGHT TO LEFT. These bits are used to indicate to the Print Engine Video Controller the scanning direction of the laser engine.

Table 1 shows how BOTTOM TO TOP and RIGHT TO LEFT affect the PCB's Page Image Address parameter. The Page Image Address must always point to the first pixel to be transferred to the print engine. These bits also affect interpretation of the Top Margin and Left Margin parameters.

                  TABLE 1
    ______________________________________
    Page Image Address for Duplex Printing Applications
    Bottom          Right Page Image Address Required
    To Top          To Left
    ______________________________________
    0     0         Top leftmost pixel in page image
    0     1         Top rightmost pixel in page image
    1     0         Bottom leftmost pixel in page image
    1     1         Bottom rightmost pixel in page image.
    ______________________________________

                  TABLE 2
    ______________________________________
    PBC Graphic Order Instruction Set
    ______________________________________
    INITIAL-
            SET.sub.-- BBMAP
                          Set banded destination bitmap
    IZATION               parameters
    ORDERS  SET.sub.-- UBMAP
                          Set unbanded destination
                          bitmap parameters
            SET.sub.-- SBMAP
                          Set source bitmap parameters
            SET.sub.-- HTBMAP
                          Set halftone bitmap parameters
            SET.sub.-- BOOL.sub.-- D
                          Set boolean code for
                          "one op" graphic orders
            SET.sub.-- BOOL-HD
                          Set boolean code for
                          "two op" halftone/
                          destination orders
            SET.sub.-- BOOL.sub.-- SD
                          Set boolean code for
                          "two op" source/
                          destination orders
            SET.sub.-- BOOL.sub.-- SHD
                          Set boolean code for
                          "three op" graphic orders
    FLOW    JUMP          Jump to specified graphic
    CON-                  order in display list
    TROL    STOP          Stop execution of display list
    ORDERS
    BITBLT  BLT2F.sub.-- D
                          "One op" bitBLT to frame
    ORDERS  BLT2F.sub.-- SD
                          "Two op" bitBLT to frame
            BLT2F.sub.-- SHD
                          "Three op" bitBLT to frame
            BLT2UB.sub.-- D
                          " One op" bitBLT to unbanded
                          bitmap
            BLT2UB.sub.-- SD
                          "Two op" bitBLT to unbanded
                          bitmap
            BLT2UB.sub.-- SHD
                          "Three op" bitBLT to
                          unbanded bitmap
            BLT2BB.sub.-- D
                          "One op" bitBLT to banded
                          bitmap
            BLT2BB.sub.-- SD
                          "Two op" bitBLT to banded
                          bitmap
            BLT2BB.sub.-- SHD
                          "Three op" bitBLT to banded
                          bitmap
    SCAN-   SL2F.sub.-- D Scanline transfer to frame
    LINE    SL2F.sub.-- HD
                          Scanline transfer to frame
    ORDERS                with halftone
            SL2UB.sub.-- D
                          Scanline transfer to unbanded
                          bitmap
            SL2UB.sub.-- HD
                          Scanline transfer to unbanded
                          bitmap with halftone
            SL2BB.sub.-- D
                          Scanline transfer to banded
                          bitmap
            SL2BB.sub.-- HD
                          Scanline transfer to banded
                          bitmap with halftone
    ______________________________________

    ______________________________________
    d   0      Zero fill the destination region.
    d   1      One fill the destination region.
    d   d      Refresh the destination region. No operation.
    d   NOT d  Invert the destination region.
    ______________________________________

    ______________________________________
    d   0        Zero fill the operand 1 region.
    d   1        One fill the operand 1 region.
    d   d        Refresh the operand 1 region.
    d   NOT d    Invert the operand 1 region.
    d   op2      Replace the operand 1 region with the
                 operand 2 region.
    d   NOT op2  Replace the operand 1 region with the
                 inverted operand 2 region.
    d   d AND op2
                 Replace the operand 1 region with the
                 logical AND of the operand 1
                 and operand 2 regions.
    d   d AND NOT op2
                 Replace the operand 1 region with the
                 logical AND of the operand 1
                 and inverted operand 2 regions.
    d   NOT d AND op2
                 Replace the operand 1 region with the
                 logical AND of the inverted
                 operand 1 and operand 2 regions.
    d   NOT (d AND op2)
                 Replace the operand 1 region with the
                 inversion of the logical AND
                 of the operand 1 and operand 2 regions.
    d   d OR op2 Replace the operand 1 region with the
                 logical OR of the operand 1
                 and operand 2 regions.
    d   d OR NOT op2
                 Replace the operand 1 region with the
                 logical OR of the operand 1
                 and inverted operand 2 regions.
    d   NOT d OR op2
                 Replace the operand 1 region with the
                 logical OR of the inverted
                 operand 1 and operand 2 regions.
    d   NOT (d OR op2)
                 Replace the operand 1 region with the
                 inversion of the logical OR of
                 the operand 1 and operand 2 regions.
    d   d XOR op2
                 Replace the operand 1 region with the
                 logical XOR of the operand 1
                 and operand 2 regions.
    d   d XNOR op2
                 Replace the operand 1 region with the
                 logical XNOR of the operand
                 1 and operand 2 regions.
    ______________________________________

                  TABLE 3
    ______________________________________
    Keys Used To Determine Boolean Codes
    ______________________________________
                Zero      00000000
    For example, the
                One       11111111 boolean code for
                Destination
                          10101010
    dest   dest OR
                Source    11001100 source
                Halftone  11110000
    is calculated by               logically ORing the
    destination and source boolean keys:
    11101110 = 10101010 OR 11001100
    ______________________________________

                  TABLE 4
    ______________________________________
    BLT2BB.sub.-- D
    Destination Only BitBLT to Banded Bitmap
    ______________________________________
    0x30      BLT2BB.sub.-- D opcode (8 bits)
    * BAND    Band number when graphic order is executed
    * DA      Destination logical bit address (29 bits)
    FW        Frame width in bits (16 bits)
    * FH      Frame height in scanlines (16 bits)
    ______________________________________
     (*) These operands are updated by the PBC when the frame crosses a band
     boundary.

                  TABLE 5
    ______________________________________
    BLT2BB.sub.-- SD
    Source/Destination BitBLT to Banded Bitmap
    ______________________________________
    0x32      BLT2BB.sub.-- SD opcode (8 bits)
    * BAND    Band number when graphic order is executed
    * DA      Destination logical bit address (32 bits)
    FW        Frame width in bits (16 bits)
    * FH      Frame height in scanlines (16 bits)
    * SA      Source physical bit address (32 bits)
    ______________________________________
     (*) These operands are updated by the PBC when the frame crosses a band
     boundary.

                  TABLE 6
    ______________________________________
    BLT2BB.sub.-- SHD
    Source/Halftone/Destination BitBLT to Banded Bitmap
    ______________________________________
    0x33      BLT2BB.sub.-- SHD opcode (8 bits)
    * BAND    Band number when graphic order is executed
    * DA      Destination logical bit address (32 bits)
    FW        Frame width in bits (16 bits)
    * FH      Frame height in scanlines (16 bits)
    * SA      Source physical bit address (32 bits)
    HXR       Halftone X remainder (16 bits)
    * HYR     Halftone Y remainder (16 bits)
    * HA      Halftone physical bit address of the starting pixel
              (32 bits)
    ______________________________________
     (*) These operands are updated by the PBC when the frame crosses a band
     boundary.

                  TABLE 7
    ______________________________________
    BLT2F.sub.-- D
    Destination Only BitBLT to Frame
    ______________________________________
    0x10       BLT2F.sub.-- D opcode (8 bits)
    DA         Destination physical bit address (32 bits)
    FW         Frame width in bits (16 bits)
    FH         Frame height in scanlines (16 bits)
    ______________________________________

                  TABLE 8
    ______________________________________
    BLT2F.sub.-- SD
    Source/Destination BitBLT to Frame
    ______________________________________
    0x12       BLT2F.sub.-- SD opcode (8 bits)
    DA         Destination physical bit address (32 bits)
    FW         Frame width in bits (16 bits)
    FH         Frame height in scanlines (16 bits)
    SA         Source physical bit address (32 bits)
    ______________________________________

                  TABLE 9
    ______________________________________
    BLT2F.sub.-- SHD
    Source/Halftone/Destination BitBLT to Frame
    ______________________________________
    0x13  BLT2F.sub.-- SHD opcode (8 bits)
    DA    Destination physical bit address (32 bits)
    FW    Frame width in bits (16 bits)
    FH    Frame height in scanlines (16 bits)
    SA    Source physical bit address (32 bits)
    HXR   Halftone X remainder (16 bits)
    HYR   Halftone Y remainder (16 bits)
    HA    Halftone physical bit address of the starting pixel (32
    ______________________________________
          bits)

                  TABLE 10
    ______________________________________
    BLT2UB.sub.-- D
    Destination Only BitBLT to Unbanded Bitmap
    ______________________________________
    0x20       BLT2UB.sub.-- D opcode (8 bits)
    DA         Destination physical bit address (32 bits)
    FW         Frame width in bits (16 bits)
    FH         Frame height in scanlines (16 bits)
    ______________________________________

                  TABLE 11
    ______________________________________
    BLT2UB.sub.-- SD
    Source/Destination BitBLT to Unbanded Bitmap
    ______________________________________
    0x22       BLT2UB.sub.-- SD opcode (8 bits)
    DA         Destination physical bit address (32 bits)
    FW         Frame width in bits (16 bits)
    FH         Frame height in scanlines (16 bits)
    SA         Source physical bit address (32 bits)
    ______________________________________

                  TABLE 12
    ______________________________________
    BLT2UB.sub.-- SHD
    Source/Halftone/Destination BitBLT to Unbanded Bitmap
    ______________________________________
    0x23  BLT2UB.sub.-- SHD opcode (8 bits)
    DA    Destination physical bit address (32 bits)
    FW    Frame width in bits (16 bits)
    FH    Frame height in scanlines (16 bits)
    SA    Source physical bit address (32 bits)
    HXR   Halftone X remainder (16 bits)
    HYR   Halftone Y remainder (16 bits)
    HA    Halftone physical bit address of the starting pixel (32
    ______________________________________
          bits)