diff --git a/docs/DTJ-1991-v03-04_full-issue.md b/docs/DTJ-1991-v03-04_full-issue.md new file mode 100644 index 0000000..28c3624 --- /dev/null +++ b/docs/DTJ-1991-v03-04_full-issue.md @@ -0,0 +1,52 @@ +# Digital Technical Journal, Vol. 3 No. 4 (Fall 1991) — the full issue + +`DTJ-1991-v03-04_full-issue.pdf` is the **whole 83-page issue**, +*Image Processing, Video Terminals, and Printer Technologies*, Digital +Equipment Corporation, Fall 1991 (documentation number `EY-H889E-DP`, +ISSN 0898-901X). `DTJ-1991-v03-04_full-issue.txt` is its +`pdftotext -layout` rendering, kept so the text is searchable with `rg`. + +## Provenance + +- Source: +- Fetched: 2026-11-01 +- Size: 4,882,168 bytes +- `md5 46e69c98eb669fabec7a6ce704d35850` +- 83 pages, 601.2 × 829.2 pt; OCR scan made 2006-04-08 with + Adobe Acrobat 7.05 Paper Capture (so the text layer is OCR, with the usual + OCR errors — "Techuologies", "j ournal", `1`/`l` mixes). + +## Contents + +| pages | item | +|---|---| +| 1–6 | Foreword (Larry Cabrinety) and author biographies | +| 7–8 | Editor's Introduction (Jane C. Blake) | +| 9–25 | *Hardware Accelerators for Bitonal Image Processing* — Christopher J. Payson, Christopher J. Cianciolo, Robert N. Crouse, Catherine F. Winsor | +| 26–35 | *X Window Terminals* — Björn Engberg, Thomas Porcher | +| 36–42 | *ACCESS.bus, an Open Desktop Bus* — Peter A. Sichel | +| 43–54 | *Design of the DECprint Common Printer Supervisor for VMS Systems* — Richard Landau, Alan Guenther | +| 55–60 | *The Common Printer Access Protocol* — James D. Jones, Ajay P. Kachrani, Thomas E. Powers | +| 61 ff. | *Design of the Turbo PrintServer 20 Controller* — Guido Simone, Jeffrey A. Metzger, Gary Vaillette | + +The two articles with direct VT1200 content are the first two: the bitonal +accelerator paper is the DECimage 1200 / S/XIE material, and *X Window +Terminals* is the VT1000 / VT1200 / VT1300 / VXT 2000 design paper (it is the +source the Lance / font-daemon analysis quotes as +`docs/DTJ-1991-vol3num4_X-Window-Terminals.txt`). + +## Two excerpt copies already in the tree + +Neither is a duplicate of this file; both are subsets and both are different +scans: + +| file | what it holds | +|---|---| +| `DTJ-1991-vol3num4_X-Window-Terminals.pdf` / `.txt` | article 2 only, *X Window Terminals* (pp. 26–35) — a 20-page text-only reflow, no figures, 28 KB | +| `../xie/docs/dec/DTJ-1991-v03-04-bitonal-image-accelerators.pdf` | article 1 only, *Hardware Accelerators for Bitonal Image Processing* (journal pp. 9–25) — a 17-page Paper Capture excerpt, 1.6 MB, 590 × 802 pt | + +`../xie/docs/dec/README.md` describes the second of those as "the DTJ issue from +the mirror at `mrynet.com`". That wording overstates what was kept — it is one +article, not the issue. The file belongs to another worker's in-flight tree, so +the correction is left to its owner; this note is the authoritative record +until then. diff --git a/docs/DTJ-1991-v03-04_full-issue.pdf b/docs/DTJ-1991-v03-04_full-issue.pdf new file mode 100644 index 0000000..92823f8 Binary files /dev/null and b/docs/DTJ-1991-v03-04_full-issue.pdf differ diff --git a/docs/DTJ-1991-v03-04_full-issue.txt b/docs/DTJ-1991-v03-04_full-issue.txt new file mode 100644 index 0000000..f926b56 --- /dev/null +++ b/docs/DTJ-1991-v03-04_full-issue.txt @@ -0,0 +1,5559 @@ +Image Processing, Video Terminals, and Printer Techuologies + + + + +Digital Technical Journal + Digital Equipment Corporation + + + + + Volume 3 Number 4 + + Fall 1991 + Editorial + Jane C. Blake, Editor + Helen L. Patterson, Associate Editor + Kathleen M. Stetson, Associate Editor + Leon Descoteaux, Associate Editor + + Circulation + Catherine M. Phillips, Administrator + Sherry L. Gonzalez + + Production + Mildred R. Rosenzweig, Production Editor + Margaret L. Burdine, Typographer + Peter R. Woodbury, Illustrator + + Advisory Board + Samuel H. Fuller, Chairman + Richard W Beane + Robert M. Glorioso + Richard]. Hollingsworth + John W McCredie + Alan G. Nemeth + Mahendra R. Patel + F Grant Saviers + Victor A. Vyssotsky + Gayn B. W inters + + The Digital Technicaljournal is pub Iished quarterly by Digital + Equipment Corporation, 146 Main Street ML01-3/B68, Maynard, + Massachusetts 01754-2571. Subscriptions to thejournal are $40.00 + for four issues and must be prepaid in U.S. funds. University and + college professors and Ph.D. students in the electrical engineering + and computer science fields receive complimentary subscriptions + upon request. Orders, inquiries, and address changes should be + sent to the Digital Technicaljournal at the published-by address. + Inquiries can also be sent electronically to DTJ@CRLDECCOM. + Single copies and back issues are available for $16.00 each from + Digital Press of Digital Equipment Corporation, 1 Burlington + Woods Drive, Burlington, MA 0 1 80 3-45 39. + + Digital employees may send subscription orders on the ENET to + RDVAX::)OURNAL or by interoffice mail to mailstop MLOI-3/B68. + Orders should include badge number, site location code, and + address. All employees must advise of changes of address. + + Comments on the content of any paper are welcomed and may + be sent to the editor at the published-by or network address. + + Copyright© 1991 Digital Equipment Corporation. Copying + without fee is permitted provided that such copies are made for + use in educational institutions by faculty members and are not + distributed for commercial advantage. Abstracting with credit + of Digital Equipment Corporation's authorship is permitted. + All rights reserved. + + T he information in thejournal is subject to change without + notice and should nor be construed as a commitment by Digital + Equipment Corporation. Digital Equipmem Corporation assumes + no responsibility for any errors that may appear in thejournal. + + lSSN 0898-901X + + Documentation Number EY-H889E-DP + + The following are trademarks of Digital Equipment Corporation: + ALL-IN-1, DECimage, DECnet, DECprint, DECserver, DECstarion, + DECwindows, Digital, the Digital logo, LAT, LN03, MicroVAX, + PrintServer, Q-bus, ReGIS, rtVAX, ULTRIX, VA,'\, VAXELN, + VAXstation, VMS, VT1000, VTI200, VT1300, and VXT 2000. + + Apple DeskTop Bus is a trademark and LocalTalk is a registered + trademark of Apple Com purer, Inc. + + Motorola and 68000 are registered trademarks of Motorola, Inc. + + Open Software Foundation is a trademark and OSF and OSF/1 are + +Cover Design registered trademarks of Open Software Foundation, Inc. + +High-performance screen display of bitonal images is one PostScript is a registered trademark of Adobe Systems, Inc. +of the topics in this issue. The handwriting and manually Texas Instruments is a trademark of Texas Instruments, Inc. +produced technical drawings on our cover are types of images + UNIX is a registered trademark of UNIX System Laboratories, Inc. +that can be scanned, st01·ed electronically, ana then displayed + X W indow System is a trademar.k of the Massachusetts Institute +on an X terminal screen; portions of an image can be enlarged + of Technology. +or rotated on screen. + Book production was done by Digital's Database Publishing Group +The cover was designed try Sandra Calef of Calef Associates. in Northboro, MA. + I Contents + 7 Foreword + Larry Cabrinety + + + Image Processing, Video Terminals, and Printer Technologies + + + + + 9 Hardware Accelerators for Bitonal Imag e Pro cessing + Christopher ). Payson, Christopher ]. C ianciolo, + Robert N. Crouse, and Catherine F. Winsor + + 26 X Window Terminals + Bjorn Engberg and Thomas Porcher + + 36 ACCESS. bus, an Open Desktop Bus + Peter A. Sichel + + 43 Design of the DECprint Comm on Printer Supervisor + for VMS Systems + Richard Landau and Alan Guenther + + 55 T he Comm on Printer Access Protocol + James D. Jones, Ajay P Kachrani, and Thomas E. Powers + + 61 Design of the Turbo PrintServer 20 Controller + Guido Simone, Jeffrey A. Metzger, and Gary Vaillette + + + + + 1 + I Editor's Introduction + + boards, mice, and t ablets, a l l of which m ay not be + made by the same company. A new open desktop + bus, described by Peter Sichel, is a simple means to + connect as many as 14 l ow-speed devices to a desk­ + top system. In his pap er, Peter presents the project + background, reviews the I 'C technology on which + the bus is based, and describes the protocol and the + configuration process. + Hard-copy presentation of data and recent deve l ­ + opments i n printer tec hnologies are the topics of t he + next th ree papers. Rick Landau and Alan Guenther + review t he DECprint Printing Services, whi c h is + jane C. Blake + software that controls nu merous printer features + Editor + for a wide range of printers. Also cal led a common + print symbiont, this component of t he VMS print­ + Products designed for quali ty, high-performance ing system supports several p age description lan­ +presentation of data in both video and hard-copy guages, hand les m ultiple media simul taneously, +form are the topics of p apers in this issue of the and uses different I /0 interconnections and com­ +Digital Technical journal. The design cha l lenges n mnication protocols. +range from managing the h uge storage require­ Both DECp rint Printing Services and the s ubject +ments of images for display on X terminals to ensur­ of the next pap er, the common printer access pro­ +ing h igh-perform ance in a feature-rich printer tocol, are part of the DECprint architecture. The +environment. CPAP provides t he fund amental services necessary + Image processing is the subject of t he opening for the presentation of data at the printer. Jim +paper by Chris Payson, Chris C ianciolo, Bob Crouse, Jones, Ajay Kachrani, and Tom Powers describe the +and Cathy Winsor. The a uthors note that one advan­ c hallenge s of developing a protocol that operates +tage of scanning images for screen disp l ay is t he in a heterogeneous, internetworking environment +i n p ut time saved; however, t he scanned i mages and that also ensures backward compa tibil ity with +and data can consume sign i ficant amou nts of stor­ older pro d ucts. Their success in developing a high­ +age space. They then review the development of an performance protocol is evidenced by OSF accep­ +image accelerator board that not only helps solve tance of CPAP for inclusion in a future release of +the problem of storage but also addresses t he need OSF/ 1 . +for high-performance display-view and manipu la­ A s was the case with the CPAP, perform ance +tion-of bitonal i mages. In addition to specifics of was also key in the development of the t urbo +the board implementation, the authors offer an PrintServer 20 controller. Guido Simone , Jeff Metzger, +overview of imaging concepts, terms, and future and Gary Vai l lette explain that the req uirements of +directions for image accelerators. complex docu ments demanded turbo controller + T he terminal on which the image accelerator performance that was five to eight times that of the +board resides is D ECimage 1200, an X terminal. c urrent control ler. To a i el t hem in making design +X terminals development in general , incl uding a decisions, a performance analysis tool, RETrACE, +discussion of the VT1200, is the sub ject of a paper was created and is descri bed here . Authors also +by B j orn Engberg and Tom Porcher. Bjorn and Tom relate how they used existing chips in order to keep +focus their d iscussion on a comparison of the development costs low and still del iver a high­ +X terminal and X workstation environments, and p e rformance control ler. +explain why X termi nals are a low-cost alterna tive . The editors thank Liz Griego-Powel l of the Video, +The au thors present the design choices debated by I m age and Print Systems Gro up for her help i n +the engineers during the development of Digital's preparing this issue. +X terminals , including t he selection of a hardware +plat form, terminal and window management, +X server, com mu nications protocols, and fo nt fi le +systems. + Video terminal and workstation users need the +assistance of a n umber of 1/0 devices, such as key- + + + +2 + Biographies I + +Christopher J. Cianciolo As a hardware design engineer in the Video, Image +and Print Systems Gro up , Chris C i anciolo is currently working on the design +for the group's l atest imaging product. Chris jo ined D igital in 1985 after par­ +ticipating in a co-op session in the Power Supply Engineering Gro up . He also +participated in co-op sessions for Charles Stark Draper Laboratory, Inc. on a +fiber-optic m issile guidance system project. He received his B . S.E.E. from +Northeastern University in 1988 and is c urrently pursui ng an M . S.E.E. , also from +Northeastern. + + + +Robert N. Crouse Senior engineer Bob Crouse is a member of the Video , +Image and Print Systems Group. He is currently working on the advanced devel­ +opment of new imaging technology for X window terminals. Bob was project +engineer for the development of a bitonal imaging accelerator for a low-end +VAXstation workstation. As a member of the Electronic Storage Development +Group , he designed a double-bit error detection and correct ion circuit for a VAX +mainframe. Bob received his B.S.E.E. from Northeastern University and h o lds one +patent. + + + +Bjorn Engberg As a principal software e n gineer in the Video, Image and Print +Systems Group, Bj orn Engberg was the main architect and software project +leader for the VTIOOO and VT1200 X window term inals. He joined Digital in 1978 +and worked as a development engineer a t CSS i n Sweden, where he modified +D igital's terminals for the European m arket. He relocated to the United States +in 1982 to work on the VT240, the VT320, the LJ250, and several advanced devel­ +opment projects. Bj orn received an M . S.E.E. (honors) from the Royal Institu te of +Technology in Stockholm. + + + + 3 + Biographies + + + + + A. Alan Guenther As a member of the technical st aff i n the DECprint System + Software Group, Al an Guenther is involved in the ongoing design and implemen· + t at ion of the DECprint common print symbiont. Prior to this, he was the prim ary + designer and implementor of the d istri buted queuing services. Alan h as worked + at Digi t al since 1973, both as a fu ll-time employee and as an independent consul­ + t ant (from 1982 to 1990). After receiving a B.S. 01onors, 1970) from the University + of Mo man a, he worked at the university until he joined D igi tal. + + + + + James D. jones Jim Jones is a princip al engineer in the H ardcopy Systems + Engineering Grou p . He joined D igital in 1974 and was p ar t of a team developing + diagnostic programs for the DECsystem-10 and DECSYSTEM-20 systems. After run­ + ning his own software business for five years, Jim rejoined D igi t al to design + printer contro llers and software. Most recently, he provided software for t h e + PrintServer products, authored the Common Printer Access Protocol speci fica­ + tion, and is helping to define the next generation of network printers. Jim is a + member of IEEE and ACM and p articip ates i n the JETF. + + + + Ajay P. Kachrani Princip al software engineer Ajay Kachrani cu rrently works + on the OSF/1 socket and XTI kernel interfaces and security proj ect. Previously , + he led the development of the overal l PrintServer software version 4.0 with + d u al network protocol support (DECnet and TCP/IP), from inception through + field test. Aj ay presented the CPAP protocol as an Internet st and ard to the IETF + and added PrintServer support in version 1 .0 of the P al l adium Print System at + MIT/Project Athen a. Aj ay holds a B.S.E.E. (honors) from the University of Mysore, + Ind i a, and an M .S.C.S. from the University of Lowell. + + + + Richard B. Landau Richard L an d au is the DECprint program m an ager for the + Video, I m age and Print Systems Group . Working to i mprove the interaction of + printing soft w are and hardware, he initiated the DECprint, Font, and PostScrip t + programs. Prior to this, Rick w as the program and development m an ager for the + VAX DBMS, DATATRlEVE, COD, and Rdb/VMS products and for the rel ational + d at ab ase architecture. Before joining Digit al in 1974, Rick w as an independent + consu l t ant and was also employed by Appl ied D at a Research, Inc. He holds A.B. + (cum l aude, 1969) and M.A. (1973) degrees in statistics from Princeton University . + + + + Jeffrey A. Metzger Presently a senior engineer, Jeff c ame to Digi t al as a co-op + student in 1983, working first in the Semiconductor Engineering Group and then + in H ardcopy Engi neering. He bec ame a fu ll-time employee after gradu ating from + Cornel l University in 1985. He introduced H ardcopy to system-level logic simu­ + l ation, contributed to the hardware, software, and firmware development of the + PrintServer 20, an d developed R ETrACE, which is used to ch aracterize the exe­ + cution behav ior of PrintServer systems. Jeff is currently working in the Entry + Systems Busi ness Group on a n e xt-generation processor product. + + +4 + I +Christopher J. Payson Chris Payson joined D igital as a hardware design +engineer in 1989 after five co-op terms. He is currently working on XIE software +and i m age hardware accelerators. Chris previously worked on performance +testing, d iagnostics, logic design, and demonstration software, all associatt:d +with imaging. He is coapplicant for a patent related to an image clipping algo­ +rithm and hardware logic. Chris received a B.S.C.E. from Rochester Institu te of +Technology with highest honors and is currently pursu ing an M.S.C.E. from +Northeastern University. + + + +Thomas C. Porcher Principal engineer Tom Porcher is a member of the +Video, Image and Print Systems Group. He provided technical leadership in the +development of the VXT 2000 X terminal. Previously he was a technical leader +for the VT240 terminal, VAX Session Support Utility, and the DEctt:rm terminal +emulator. Tom holds five patents for work on the VT240 terminal and on the multi­ +session protocol used in the VT340 and VT400 series terminals. Tom received his +B.S. in mathematics from Stevens Institute of Technology (1975). Ht: is a member +of the ACM. + + + +Thomas E. Powers As a consultant engineer in the Hardcopy Engineering +Firmware/Software Group, Tom Powers is a vendor l iaison for desktop +PostScript printer products. He chairs the DECprint PAP Architecture Team +and was a contributor to the PrintServer 40 internal hardware/firmware archi­ +tecture. Tom represented Digital on American and intern ational standards com­ +mittees on computer graphics from 1979 to 1989. He led several firmware teams +and is coinventor of the ReGIS Graphics Protocol. Tom has a B.S. E. E. from Tufts +University and an M .S.E.C.E. from the University of Massachusetts at Amherst. + + + +Peter A. Sichel As a principal software engineer in the Video Terminals Archi­ +tecture Group, Peter Sichel led the development of the ACCESS. bus architecture +and device protocol specifications, in addition to writing the init i al ACCESS. bus +device firmware. He worked on the VT420 video terminal and the DECterm +DECwindows terminal emulator, and helps maintain D igital standards for video +terminals and keyboards. Peter joined Digital in 1981 after receiving B.S. and M .S. +degrees in computer engineering from the University of Michigan. + + + + +Guido R. Simone G u ido Simone is a principal engineer in the Print Systems +Engineering Group and was the project leader and architect for the turbo +PrintServer 20 controller. He is currently working on the development of a +new print system architecture to be used with advanced printing technologies. +In previous work, G u ido was the project leader and architect for an rtVAX +78R32 CPU chip-based laser printer controller. Before joining Digital in 1980, he +received a B.S. in electrical engineering from Rensselaer Polytechn ic Institute. + + + + + 5 + Biographies + + + + + Gary P. Vail lette Senior hardware engineer Gary Vai l lette has heen involved + in the design and implementation of printing system hardware since joining + Digi tal in 1983. His current work incl udes performance characterization of + PostScript printers and PrintServer products, and hardware implementation of + cern decomp ress ion in the t u rbo PrintScrver 20 product. Previously, Gary + worked at Data General Corporation and helped to develop their token bus + network product. He holds an A.A.E.E (1974) from Quinsigamond Com m u n i ty + College and expects to receive a B.S.C.S. (May 1992) from Boston Universi ty. + + + + Catherine F. Winsor As a senior engineer in the Video, Image and Print Sys­ + tems Group, Cathy Winsor has worked on image accelerators. As the project + leader for the DEC:image 1200 hardware and the image u t il i ty l ibrary software, + Cathy was involved i n the planning and development of an i mage-capable + VT1200. She is curre n t ly leading the project to support im aging on the next + generation of Digital's X terminals. The project i nclucles an image accelerator + board and XIE software. Cathy received an A.B. i n engineering sciences from + Dartmouth Co l lege and a B.S.E.E. from the Thayer School of Engineering. + + + + +6 + I Foreword + + processing. The X terminal user can now benefit + from the graphical user interface, sophisticated + appl ications, and standards of performance previ­ + ously available only on workstati ons. X terminals + run X l l server code which is operating system + independent and ideal ly suited for heterogeneous, + network-based computing environments. In this + issue you wil l read about the engineering decisions + made as the X terminals were developed. + There is a growing need in the industry to have + imaging applications run alongside conventional + text and graphics appl ications. Technical docu­ + Larry Cabrinety + mentation is an example of this. Imaging appl ica­ + Vice President, + tions, however, have special requirements to achieve + Video, Image and Print + acceptable end-user performance. Although the X l l + Systems Group + software can handle images a s bit-map data, soft­ + ware and hardware assistance is requ ired to achieve + acceptable p erformance. Digital has designed +For the m i l l ions of people worldwide who use DECimage hardware accelerators for rapid process­ +Digital's computer equipment, the computer is not ing of i mage data. This technology is included in +the sophisticated system in the back room, or the the DECimage 1200 and will be incorporated in +complex network. It is the equ ipment they use fol lowing generations of X terminals. To make this +each day- the terminal or monitor, keyboard and possible, Digital developed extensions to the +mouse, desktop printer or network printer system. X server software that support the high-speed + Today's users demand products with h igh levels transport and display of image data. To assure open +of usabil ity and superior ergonomic features. standards, the extensions have been proposed to +D igital's products set worldwide standards for the M IT for incorporation into releases of the X l l +user i nterface to computer systems. In the 90s our server software. +focus is to offer products that operate i n m u lti­ In November 1990, D igital announced its next +vendor environments with the goal of delivering a generation of X terminals. The VXT2000 terminal +complete compu ting sol ution. In this issue you will provides virtual memory and supports both a tra­ +read about some of the Video, Image and Print Sys­ ditional host-based model with software down­ +tems (VIPS) Group's products and technologies that loaded to the terminals as well as the server style of +support network computing and standards-based X terminal compu ting. +environments. The VXT2000 terminal was designed to support + D igital entered the video terminal market in 1975 TCP/IP and LAT protocols, and further demonstrates +with the VT52 for i t s time-sharing users. Its replace­ our comm itment to openness and support for cus­ +ment, the VT100, embodied two important princi­ tomers' m u lt ivendor environments. Th is same phi­ +ples-the use of standards in data com munications losophy is seen in our printer products and our open +in terchange and the protection of customer invest­ desktop bus. +ments through backward compatibility of new gen­ Digi tal pioneered the distri bu ted printing busi­ +erations of products. The VT220, introduced in ness with networked laser printers. Th is prod­ +1983, and the cost-effective VT320 terminals saw uct area began when we combined two concepts +the addition of functional i ty and ergonomic fea­ which had not been combined before-mid- range +tures which establ ished D igi tal as a leader i n the l aser printers and networks. I n the mid-1980s most +commodities market. large-scale comp uting was done on mainframe + I n March 1990, Digital entered the X terminal compu ters with l arge printers attached directly +market with the i ntroduction of the VTlOOO, fol­ to these systems. Typically these dedicated print­ +lowed by the VT1200 and VT1300 terminals later ers were only accessible to users on that particular +that year. The emergence of MIT's X Window system. D igital's distributed compu ting provided +Systems as the accepted industry standard for an alternative to the ma inframe. By combi ning the +windowing systems provided a standards-based power of multiple systems in c lusters or on net­ +environment for distri buted applica tions display works, a new distribu ted large system was created. + + + + 7 + Foreword + + + + +A printing sol ution was needed to effectively work original PrintServer 40, a l ong with cu stom hard· +in t h i s new d i stribu ted computing environment. ware acceleration hoards developed by the liard­ +The Print Server serie s add n:ssed this n eed. copy Group to enable printing a t 40 pa gt:s per + PrintServer products enabled printing resources mi nute. In this issue you wi l l read about t h <.: single· + to be directly connected to networks for the fi rst board control ler that replace s the Mic roVAX 11 and + time, and since they were on the network and not offe r s far more processing power. Using the latest +tied to any one system, they were acce ssible hy a l l system-on-a-chip technology, our new turbo board +systems o n those n etworks. They enabled the com· provides lea d ership p erformance for our prin ters. +plex printer fu nctiona l i ty previously found only in The CCITI image decompression chip enables us to +dedicated mainframe printers to be d i st ribu ted provide fu ll-speed image printing to our customers +throughout end-u ser environments. as the image market develops. + As these mid-range printers migrated out of the The first PrintServer systems supported printing +computer room and into the office, new demands from VMS hosts ovt:r D ECnet networks. Since then +for funct iona lity were created. Large groups of users the breadth of platform support has i ncreased to +brought many d ifferent requi rement s for printing, include first ULTRJX system s and then UNIX operat· +and our goal was to sat isfy as m any as possi ble in a ing systems. A software kit for Sun systems wil l be +single PrintServer. For example , some people need available soon. In expanding PrintServer connectiv· +"A" size paper for office c orrespondence, while ity to include UNIX systems and TCP/11' network s, +others may n eed "B" size paper for CAD/CAl\1 or we again faced the problem that no network print· +accoun ting work, and stil l others need transparen­ ing protocol existed for TCP/IP. With the h elp of +cies for presentation s. The PrintServer is flex ible D igital's experts at the We stern Re search Labora· +enough to have a l l of these d ifferent types of tory, we were able to devdop a solution. In this +media available and offer both simplex and duplex issue, we discuss the creation of a network printer +printing. access protocol for TCP/ IP. Today this network pro­ + In 1985 when Digital was first developing the tocol is a proposed standard at the Internet Engi· +PrintServer, there was no industry standard way neering Task Force, the body control l ing the TCP/IP +of describing the conten ts of a page to a print er. protocol. +Each m ajor vendor had its proprietary language, The development of the ACCESS. bus product has +and none offered the compa tibil ity necessary to brought an easy, st andard way to l i nk a desktop +achieve our print system vision. Our goal was to computer to many interactive u ser interfaces. This +create a fam ily of produc t s, from large to small, open desktop bus is currently implemented on the +that offered compa t i bi l i ty for all app l ications. To Personal DECstation 5000 wor k station, and im ple· +achieve this goal we had to select a protocol mentations on future RISC workstations and video +that would enable us to print any file on any terminals is u nderway. Developers of Digita l's prod· +printer. At that time Adobe Systems, the developer u cts wi l l continue to pl ace a h igh priority on open +of PostScript, was a s m a l l start-up company in standards. The papers included i n this issu t: of the +Silicon Val ley . PostScript was not a standard, and in Digital Technicaljournal will providt: insight into +fact, only a single PostScript laser printer model the key areas of technology u st:d in the design and +had been shipped, the original Apple LaserWriter. development of VJPS product s. +Our technical co mmunity fe lt PostScript was the +best s olution to ou r net:ds, and at that point Digi tal +com mitted to adopting PostScript as our strategic +page description language. PostScript printers and +PostScript application support are now pervasive +throughout the industry and standard printing +protocols enable interactive com mun ication with +hosts on the network. + Signi ficant advances have taken place in the +PrintServer series over the past seven years. An +entire :VlicroVAX II system was housed wi thin the + + + +8 + Christopher]. Payson + Christopher]. Cianciolo + Robert N. Crouse + Catherine E Winsor + + + + +Hardware Accelerators for +Bitonal Image Processing + + Electronic imaging systems transfer views of real-world scenes or objects into + digital bits for storage, manipulation, and viewing. In the area of bitonal images, + a large market exists in document management, which consists of scanning vol­ + umes of papers for storage and retrieval. However, high scan densities produce + huge volumes of data, requiring compression and decompression techniques to pre­ + serve system memory and improve system througbput. These tecbniques, as well as + general image processing algorithms, are compute-intensive and require high + memory bandwidth. To address tbe memory issues, and to acbieve interactive + image display petformance, Digital bas designed a series of bitonal image hard­ + ware accelerators. Tbe intent was to create interactive media view stations, with + imaging applications alongside other applications. In addition to achieuirzg mem­ + ory, performance, and versatility goals, the hardware accelerators have signifi­ + cantly improved final image legibility + + + +Bitonal image technology, which can be viewed as should come of age in the 1990s. Digital imaging +the electronic version of today's microfilm method , is a l ready in use in many areas and new applica­ +is experiencing a high rate of growth . However, the tions are being created for both com mercial and +electronic image data objects generated and manip­ scientific markets. The emergence of d igital images +u lated in this technology are very l arge and require as standard data types supported by the majority +intensive processing. In a generic system, these of systems (like text and graphics of today) seems +requirements can resul t in poor image processing assured . For a greater understanding of specific +performance or reduced appl ication performance. imaging appl ications, this section presents general +To address these needs, Digital has designed a series imaging concepts and terms used throughout the +of imaging hardware accelerators for use in the doc­ paper. +ument m anagement market. + This paper provides a brief tutorial on electronic Concepts and Terms +imaging. It begins with a general description of the In its simplest form, imaging is the d igital repre­ +imaging data type and compares this type to the sentation of real-world scenes or objects. Just as a +standard text and graphics data types. It continues camera transfers a view of the real world onto a +with a discussion of specific issues in bitonal imag­ chemical film, an electronic imaging system trans­ +ing, such as image data size, network transport fers the same view i nto d igital bits for storage, +method, rendering speed , and end-user legibility. manipulation, and v iewing. In this paper, the term +The paper then focuses on D igital's DECimage 1200 image refers to the digi tal bits and bytes that repre­ +hardware accelerator for the VT 1200 X window sent the real-world view. +terminal developed by the Video, Image and Print The process of digitizing the v iew may be done +Systems Group. It concludes with fu ture image through various methods, e.g., a n image scanner +accelerator demands for the processing of multi­ or image camera. A scanner is the conceptual +media applications and continuous-tone images. inverse of a normal printer. A printer accepts an + electronic stream of bits that describe how to +Introduction to Imaging place the ink on the paper to create the desired +Just as graphics technology blossomed in the 1980s, p icture. Conversely, optical sensors in the scanner +electronic imaging and its associated technologies transform l ight intensity values reflected from a + + + +D igital Technical journal Vol. 3 No. 4 Fa/11991 9 + Image Processing, Video Terminals, and Printer Technologies + + + + +sheet of paper and create a stream of electronic bits media density. Scaling an image may be as simple as +to describe the p icture. Simi lar sensors in the focal repl icating and dropping pixels, or i t may involve +plane of a camera produce the other common d igi­ i n terpola t ion and other algorithms that take neigh­ +tization method, the electronic i mage camera. boring pixels into account. Generally, the more + The format of a digitized image has many param­ complex scaling algorithms require more process­ +eters. A p ixel is the common name for a group of ing power but yield higher-quality images, where +d igitized image bits that all correspond to the same qua l i ty refers to how wel I the original scene is rep­ +location in the image. This pixel contains informa­ resented in the resulting image. +tion about the intensity and color of the image a t Before an image can be displayed, i ts pixel values +o n e location, in a format that c a n b e interpreted often require conversion to account for the charac­ +and transformed into a visible dot on a d isplay teristics of the d isplay device. As a simple example, +device such as a printer or screen. The amoun t of a color image cannot retain its color when output +information in the pixel classifies the image into to a black-and-whi te video moni tor or printer. I n +one of three basic types. general, when a device can d isplay fewer colors + than an image contains, the i mage p ixel values must +• A bitonal image has only one b i t in each pixel; + be quantized . Simple quantizing, or thresholding, + the bit is ei ther a one or a zero, representing one + can be used to reduce the number of image colors + of two possible colors (usually black and white). + to the number of d isplay colors, but can resu lt in +• A gray-scale image has multiple bits in each pixel, loss of image quali ty. Di thering is a more sophisti­ + where each p ixel represents an intensity value cated method of quantizing, which produces the + between one color (al l zeros) and another color il lusion of true gray scale or color. Although dither­ + (all ones). Since the two colors are usually black ing need use no more colors than simple quantiz­ + and white, they produce a range of gray-scale i ng, it results in d isplayed i mages of much higher + values to represent the image. qual i ty. + Image compression is a transformation process +• A color image has mu ltiple components per + used to reduce the amoun t of memory required to + p ixel, where each component is a group of + store the information that represents the image. + bits representing a value within a given range. + Different compression methods are used for bi tonal + Each component of a color image corresponds + images than those used for gray-scale and color + to a part of the color space in which it is repre­ + images. These methods are standardized to specify + sented. Color spaces may be thought of as dif­ + exactly how to compress and decompress each + ferent ways of representing the analog, visible + type of image. For bitonal images, the most com­ + range of colors in a d igitized, numeric form. The + mon standards are the ones used in facsimile + most popular color spaces are television's YlN + machines, i.e. , Recommendations T.4 and T.6 of the + format (one gray-scale and two color compo­ + Comite Consultatif Internationale de Telegraphique + nents) and the bit-mapped computer d isplay's + et Telephonique (CCJTT).1·2 Commonly known as + RGB format (red, green, and blue components). + the Group 3 and Group 4 standards, the desig­ + The resolution of an image is simply the density nations are often shortened to G3-I D , G3-2D, and +of pixels per unit distance; the most common den­ G4-2D, referring to the particular standard group +sities are measured i n dots per inch (dpi), where aod to the coding method, which may be ei ther +a pixel is cal led a dot. For example, a facsimile one- or two-dimensional. For gray-scale and color +machine (which is nothing more than a scanner, images, the joint Photographic Experts Group +printer, and phone modem in the same unit) typi­ OPEG) standard is now emerging as a joint effort of +cally scans and prints at 100 dpi, although newer the International Standards Organization (ISO) and +models are capable of up to 400 dpi. As another CCITI.0 Whichever format or process is used, com­ +example, most workstation d isplay monitors are pression is a compute-intensive task that involves +capable of 75- to 100-dpi resolution, and some high­ mathematically removing redundancy from the +end monitors achieve up to 300-dpi reso lution. pixel data. + To d isplay an i m age a t a density different from A typical compression method creates an +its scanned density, without altering the image's encoded bit stream which cannot be d ispl ayed +original size, requi res the i m age to be scaled, so directly; the compressed b i ts must be decom­ +that the new image density matches the output pressed before anything recognizable m ay be + + + +10 Vol. 3 No. 4 Fu/119')1 Digital Techuicaljournal + Hardware Accelerators for Bitonal Image Processing + + + +d isplayed. The term compression ratio represents The major drawback in the imaging process is +the size of the original image divided by the size of increased data size, which results in storage mem­ +the compressed form. For bi tonal images using ory and network transport problems. High scan +the CCITI standards, the ratio is commonly 20:1 on densities and color information components create +normal paper documents, bu t can vary widely with large volumes of data for each image; a bitonal +the actual content of the image. The CCITI stan­ image scanned at 300 dpi from an 8.5 -by-11-inch +dards are also " lossless" methods, which means that sheet of paper requires over 1 megabyte of mem­ +the decompressed image is guaranteed to be iden­ ory in its original pixel form. Therefore, compres­ +tical to the original image (not one bit d ifferent). sion and decompression are integral parts of any +In contrast, many " lossy" compression methods imaging system. Even in compressed form, a bitonal +al low the user to vary the compression ratio such image of a text page requires about 50 kilobytes +that a low ratio yields a nearly perfect image repro­ of storage, whereas its American standard code +duction and a high ratio yields a visible degradation for information interchange (ASCII) text equivalent +in image qual i ty. This trade-off between compres­ requires only 4 to 5 kilobytes. Similarly, a graphics +sion and image qual i ty is very useful because of the file to describe a simple block d iagram is much +wide range of applications in imaging. An applica­ smal ler than its scanned image equivalent. +tion need pay no more in memory space and band­ Based on these advantages and l imitations, sev­ +width than necessary to meet image quality eral appl ications have emerged as perfect matches +requirements. for imaging technology. Bitonal images are used + in the expanding market of docu ment manage­ +A New Data Type and Its Features ment, which consists of scanning volumes of +The image data type is fundamentally different papers into images. These images are stored and +from text and graphics. When a user views charac­ indexed for later searching and viewing. Basically +ters or pictures on a display device, the source of an electronic file cabinet, this system resu lts in +that view is usually not important. A sheet of text large savings in physical cabinet space, extremely +from a printer may have come from either a text file fast document access, and the abi l i ty for mul tiple +where the printer's own fonts were used, a graph­ users to access the same document simu ltaneously. +ics file where the characters were drawn with line Gray-scale imaging i s often used in medical appli­ +primitives, or an image file where the original text cations. Electronic versions of X rays can be sent +document was scanned i nto the system. In any instantly to any special ist in the world for d iagno­ +case, the same letters and words present the user sis, and the ordering of sequential computer-aided +with approx imately the same information; the dif­ testing (CAT)-scan images into a "volume" can pro­ +ferences are mostly in character qual ity and format. vide valuable three-dimensional views. The appli­ + In spite of their large storage space require­ cations for color imaging are relatively new and +ments, images have several advantages over graph­ still emerging, but some are already in use commer­ +ics or text. F irst, consider the process of getting cially, e.g., l icense and conference registration pho­ +the information into the computer. With the imag­ tographs. A fu rther extension to still imaging is +ing process, documents may be scanned automati­ digital video, which can be considered as a stream +cally in a few seconds or less, compared to the time of still images. In conjunction with audio, d igital +required for someone to type the information cor­ video is commonly known as m u ltimedia, appl ica­ +rectly (absolutely no errors) into a text file. Also, tions for which range from promotional presenta­ +even though the software exists to convert elec­ tions to a manufacturing assembly process tutorial. +tronic raster images into graphic primitive files, the In this paper, we focus on the static bitonal imag­ +process loses detail from the original image and is ing method of representing real-world data inside +relatively slow. Next, consider the variety of infor­ computers. Static imaging is a simpler method of +mation possible on a sheet of paper: a user can­ representing a broader range of information than +not easily reproduce a diagram or a signature on a the text and graphics media types, but i t carries +document. A scanned image preserves not only the a greater requirement for processing power and +characters, but their font, size, boldness, relative memory space. In addition, static imaging can be +position, any pictures on the page, and even viewed as one part of true multimedia, as can text, +smudges or tears depending on the quality of the graphics, audio, video, and any other media for­ +image scan. mats. Yet static imaging does not have the system + + + +D igital Technical journal Vol. 3 No. 4 Fall 1991 11 + I mage Processing, Video Terminals, and Printer Technologies + + + + +speed requirements of a motion v ideo and a u d i o m ately 3 k ilobytes of memory. If the same sheet of +system, which mu st present d a t a at real - time rates. paper is d ig i tized by scan n i ng at various dot den­ +As long as the user can tlcal with static i magcs at sities, the result ing data tiles are huge, as shown +an i n teractive rate, i . e . , being ablc to v iew the by the decom pressed bitonal im age sizes in Table ! . +images in the fo rmat of choice as fast as the user Note t ha t Table 2 i ncludes the size of the scanned +can sdect them, then static i m aging is a powerful i m age if scan ned in gray-scale and color modes, +media presentation too l. The next section presents alt hough using these modes would not make sense +the important issues concerning bitonal imaging in on a black-and-whit�: sheet of paper. The image +a tlocumcnt managcment env ironment. sizes arc included for comparison and are d iscussed + in the section Future I mage Accelerator Requi re­ +Bitonal Imaging Issues ments. The clara presented in Tables 1 and 2 i l l us­ +As previously mentioned, b i tonal electro n i c i m ag­ trates that the size of the original ASCII file is much +ing as an alternative to paper documcnts offers smal ler than any of the scanned versions. The data +many benehts, such as reducctl physical storage also gives evidence that scanned images, in general, +space, instant and simu ltaneous access of scanned require considerable memory. +images, and in general a more accessible media. Since the typical use for b i tonal images is for +Serious issues need to be resolvetl before a produc­ vol u m e document archival, an imaging application +t ive i m aging operation can be implemented. The must include a compression process to reduce mem­ +chief issues are the image data size, transport ory usage. This process must transform the original +method , perceivetl rendering speed, and final legi­ scanned image file to a much smaller file without +b i l ity. In the fol lowing sections, we examine each losing the content of the original scanned data. +issue and present sol u tions. Compression algorithms may take d ifferent paths + to achieve the same result, but they share one basic +Digitized Image Data Size process, the removal of red u n d a n t i nformation to +The most important issue concerns image data size. reduce the obj ect size. A common compression +I mages are typically documents, drawings, or p ic­ rout i n e searches the p ixel data for groupings, or +tures that have been d igitized i nto a computer­ "run lengths," of black or white pixels. Each run +readable form for storage antl retrieval. Depending length is assigned a code sign ificantly shorter than +o n the dot densi ty of the scanner, a s i ngle i m age the ru n length i tself The codes are assigned by +can be I to 30 megabytes or more in size. However, sta tistics, where the most frequent run lengths +storing a single image in i t s scanned form is not the are assigned the shortest codes; statistics have been +typical usage model . I nstead , a company may have amassed on a variety of document types for d iffer­ +tens of thousands of scanned documents. Clearly, e n t scan densi ties and document sizes. A compres­ +with today's storage technologies, a company can­ sion process p arses through the origi nal im age +not af ord to store such a large vol u m e of i mages file, genera t i ng another tile that contains the codes +in that format. representing the origi nal image. Figure I , a sample + A typical ASC I I file represen t i ng the text on an b i t o n a l i m age co mpression, i l lustrates these com­ +8.5 -by-1 1-inch sheet of paper requires approxi- pressed codes in a serial bi t stream. + + + +Table 1 Sa m ple Bitonal I mage Sizes + + Scan Kilol'ytes of Data +Document Type Density Pixel Form Ty pical +(Paper Size) (dpi) (Decom pressed) Compressed + +A size 1 00 114 46 +(8.5 X 11 i nch) 200 457 47 + 300 1 027 50 + +E si ze 1 00 1 826 1 06 +(44 x 34 i n ch) 200 7305 114 + 300 1 6436 1 27 + + + + +12 Vol. 3 No. 4 Fall 1991 Digital Technical journal + Hardware Acceleratorsfor Bitonal Image Processing + + + +Table 2 Sample Gray-scale a n d Color Network Transport Constraints + I mage Sizes The network transport performance for an image + Kilobytes of Data + is important, because images arc most often stored +Document Ty pe in Pixel Form on a remote system and v iewed on a widespread +and Size (Decom pressed) group of d isplay stations. For example, one group in + an insurance company receives and scans claim +1 28 x 1 28 pixel, 1 2 bits per pixel 24 + papers to create a central ized image database, +g ray-scale i m age + while users in another group acn:ss the documents +51 2 X 512 pixel, 8 bits per pixel 256 +color i mage + simultaneously to process clai ms. For the imaging + 768 + system to be productive. this image data needs +51 2 x 51 2 pixel, 24 bits per pixel +color image to be transported quickly from one group to the +8.5 X 11 i nch, 100 d p i , 24 bits 2740 other: telephone attendants answering calls must +per pixel, color i m age have im mediate access to the data. + Scanned image documents take a long time to + transport between systems, simply because they are + Several algorithms for bitonal compression are so large. When compression techniques are used , a +widdy used today. As mentioned in the previous typical u ncompressed image stored in 1 megabyte +section, the most common for bitonal images are can be reduced to approxima tely 50 kilobytes. +the CCllT standards G3-l D, G3-2D, and G4-2D, which Since transport time is proportional to the number +all use the approach just described. For the one­ of packets that must be sent across the network, +dimensional method, the algorithm creates run reducing the data size to .:; percent of its original +lengths from all pixels on the same scan l ine. In the size also reduces the transport time to 5 percent +two-dimensional methods, the algori thm some­ of the original time. Therefore, you can now send +times creates run lengths the same way, but the twenty compressed images in the same time previ­ +previous scan l ine is a lso examined. Some codes ously spent sending one uncompressed image. +represent run lengths and even whole scan l ines Even with compression techniques, the image +as " the same as the one in the previous scan line, files are stil l larger than their text file equivalents. +except offset by .v pixels," where N is a small inte­ Moreover, most network protocols limit their +ger. The two-dimensional method takes advan­ packet size to a maximum number of bytes, i.e . , an +tage of most of the redundancy in an image and image file larger than the maximum packet size +returns the smallest compressed file. In addition to gets divided over mul tiple packets. If the protocol +preserving system memory, these compression requires an acknowledgmenr between packets, then +methods significantly improve network transport the transport of a large file over a busy network +performance. becomes a lengthy operation. + + + IMAGE PI XELS + + + + + r + t?t �� �U + AN LI N E o F ' + + + + 1 r--- + o Ls + + + + 1 + - _ - + _� __,...,. --, + + + + + 600 W H I TE 250 WHITE 845 WHITE + ACK + + + + + . . . 0 1 1 0 1 0000 1 0 1 000 00000 1 1 0 1 000 0 1 0 1 1 1 0 1 0 1 1 0 1 1 00000 1 1 0 1 000 0 1 1 0 1 00 1 00000 1 1 . . + + C O M P R E S S E D C O D E S I N A CONTINUOUS B I T STREAM + + + + + Figure I Bitonal Image Compression + + + +Digital Techllical Jour11al VlJI. 3 No. 4 Fall 1991 13 + I mage Processing, Video Terminals, and Printer Technologies + + + + + The platform for our most recent accelerator is them. The disk acce ss time data from the DECim age +the VT1200 X window term inal, which uses the project a n al ysis shown in Table 3 d emonstrates that +l ocal are a transport ( I.AT) network protoco l . We the disk file re ad time is a significant portion of the +soon realized that the X server packet size w as overal l response time. Thus, the display station +l imited to 16 kilobytes and the t yp ical A-size render time is the onl y are a of the disp l ay response +compressed docu ment was approximatel y 50 kilo­ time which can be clear l y intluenced and is, there­ +bytes. With this arrangement, each i m age transport fore, the m ai n focus of our image accelerators. The +woul d have required four large data packets and local processing that must occur at the display sta­ +four acknowledgment p ackets. Working with the tion is not a trivial t ask; an im age must be decom­ +X Window Terminal B ase System Software Group, pressed, scaled, and clipped to fit the user's current +we were able to r ai se the packet size limit to window size, and optional l y rotated. +64 ki lobytes. The b ase s ystem group also imple­ The decompression procedure inverts the com­ +mented a delayed acknowledgment scheme, which pression process; both are computational l y com­ +eliminates the need for the c l ient to wait for an p lex . Input to the procedure is compressed data, +acknowledgment packet before sending the next and output is the origi n al scan l ine p ixel data, +d at a packet. Table 3 shows compressed image d at a which can be written to a disp l ay device. Scal ing +taken during the DECim age 1200 d evelopment the data to fit the current window or fill a region +c ycle. Notice that the network transport t imes of interest is not trivi al either: a huge inpu t dat a +for Digi t al docu ment interch ange format (DDIF) stre am must b e processed (the decompressed, orig­ +decrease sharpl y after the p acket changes. inal file), and a moderate output data stream must + be cre ated (the viewable image to be displ ayed). +Perceived Rendering Speed While simple pixel replicate and drop algorithms +Because the imag e scanning and compression m ay be used to scale the d a t a, a more sophisticated +operations occur only once, they are not as scaling algorithm h as been shown to grea t l y +perform ance-cri tical as the decompression and enh ance the output i m age qual i t y. +rendering for displ ay operations, which are done In add i tion to scal ing and cl ipping, the orthogo­ +m any times. Decompression and rendering are p art n al rotation of image s (in 90-degree increments) +of the s ystem's disp l ay response time, which is a is a useful function on a display station. Some docu­ +critical factor in a system designed for high-volume ments m a y h ave words running in one direction +appl ications that access thousands of i m ages dai ly. while pictures are oriented another way, or the user +This time is measured from the inst an t the user m ay wish to view a portrait-mode image in l and­ +presses the ke y to s elect an im age to view, to the scape mode. In either case, orthogonal rotation +moment the image is displayed completely on the c an help the user understand the inform ation; i.e . , +screen. The disp l ay response time is a fu nction of the increased time to ro t ate the view is warranted. +the disk read time, network transport time, and dis­ When an image is scan ned, p articu l arl y with a +play st ation render time. h and-held scanner, the p aper is never perfectl y + Although network transport time and disk file al igned. Thus, the image often requires a rotation of +read time have a direct effect on the response time, I to 10 degrees to m ake the view appear straight +accelerator developers rarel y have any control over in the i m age file. However, m u l tiple users want the + + +Table 3 DD I F I mage F i le Read Ti me a n d F i l e Tra nsport Perfo rma nce + + Network Tra nsport Time + (mi l l iseconds) + Disk Read Time After Before +I mage Size (m i l l iseconds) Packet Packet +(kilobytes) M i c roVAX I I VAX 8800 VAX 6440 Change Change + + 19 1 223 480 281 325 960 + + 41 1 5 34 655 332 61 4 1 792 + + 99 2351 1 035 598 1 351 3928 + + 1 57 3288 1 380 71 6 2283 6430 + + + + +14 Vol. 3 No. 4 Fall 1991 Digital Teclmicaljourual + Hardware Accelerators for Bitonal Image Processing + + + +information from the document as quickly as pos­ General Design Strategy +sible , and should not have to ro tate the image by The nu mber of applications using bitonal i mage +a few degrees to make it perfectly straight on the data continues to increase. In general, these appli­ +screen. Therefore, this m inimal ro tation should cations attempt to offer low cost while achieving +be done after the initial scanning process; i.e., an interactive level of performance, defined as +only once, prior to indexing the material into no more than 1 second from point of request to +the database, and not by every user in a distributed complete image display. Ultimately, software may +environment. Because any form of rotation is provide this fu nctio nality without hardware accel­ +compute-intensive, allowing the user to perfo rm eration, but today's software cannot. Mo reover, the +minimal ro tations at a h igh-vol u me view station parameters of image systems are n o t static; scan +wo uld reduce the application's perceived ren­ densities, overall image size, and the number of +dering speed and add l i ttle value to the station 's images per database will a l l increase. These +function. increases will provide the most incentive for hard­ + ware assist at the low end of the X window ter­ +Final Legibility minals market, because software alone cannot +While the primary issue facing im aging applica­ perform the amount of processing that users will +tions is data size, image viewing issues must also be expect for their investment. +addressed. In short, an effective b i tonal imaging + The User Model Although a single mo del cannot +display system must be responsive to overal l image + suit every application, imaging is centered o n cer­ +display performance and the resulting quality of + tain functions. Therefore, a user mo del built on +the image displayed. To enhance our products, we + these fu nctions wou ld be very useful in mapping +optimized the display perfo rmance parameters as + individual steps to the hardware: hardware versus +best we could, given that some parameters are not + software performance, the fu nction 's frequency of +under our control. Improvements to m o nitor reso­ + use, and the cost of implementation. +lution and scanner densit ies continue to increase + The general user model for bitonal imaging sys­ +the legibility of images. An affordable image system + tems is relatively simple. A small market exists fo r +should increase the image legibility by rendering + image entry stations, i n which documents are +a bitonal image into a gray-scale image using stan­ + scanned , ed i ted, and indexed into a database. While +dard image processing techniques. We discuss the + a high throughput rate is important at these sta­ +method used in our accelerators, i.e., an intel ligent + tions, a general-purpose image accelerator is not +scale operation in the hardware pipel i ne , in the + the solution-dedicated entry stations already +next section. + exist in the market. Instead, we designed a general­ + purpose platform, or versatile media view station, +Hardware Accelerator Design to be used for imaging appl ications alongside other +As explained i n the previous section, transforming applications. The user model fo r this larger market +documents into a stream of electronic bits is not is a set of operations for viewing and manipu lating +the demanding part of a bitonal imaging process images al ready entered i nto a database. The most +for document management. Also, scanners and common operations in this mo del are decompres­ +dedicated i mage data-entry stations abound in the sion, scal ing, clipping, orthogonal ro tation, and +marketplace al ready. Instead, the challenge l ies i n : region-of-interest zooming. +( 1 ) managing t h e image data size t o control +memory costs and reduce network slowdown; Display Performance and Quality Optimization +(2) increasing the i mage rendering speed, i.e., The main thrust of the DECimage accelerator is to +decompress the image , scale it, and clip i t to fit achieve interactive perfo rmance for the operations +the window size with optional rotation; and defined in the user model. A secondary goal is to +(3) increasing the quality of the displayed images. bring added value to the system by increasing the +This section describes the way our strategy qual ity of the displayed image compared to the +i nfluenced the design of DECimage products. We quality of the scanned image. A side effect of maxi­ +also discuss the chips used for deco mpression and mizing performance in hardware is that the main +scaling, and how Digital's existing client-server pro­ system processor has wo rk off-lo aded fro m it, free­ +tocols support these imaging hardware accelerators. ing it for other tasks. + + + + +Digital Technical ]oun1al Vol. 3 No. 4 Fall 1991 15 + Image Processing, Video Te rminals, and Printer Tech nologies + + + + + The general design of the accelerator uses a The most straightforwa rd method o f i n t egra tion is +pipel ined approach. Since maximum performance to relocate the hardware from the present option +is desired and a large amount of data must be pro­ to the m a i n system processor board; successive +cessed by the accelerator board, m u l t iple passes steps of i ntegra tion wou ld consol idate m apped +through the board arc not feasible. Simi larly, the tar­ hardware to fewer total devices. The most cost­ +geted low cost does not a llow a whole image bu ffer effective i ntegra tion wil l be the inclusion of the +on the board. With one exception (rota ti on), a l l mapped hardware in the processor in a way simi lar +board processing shou ld b e dune i n one pipel i ne, to a float ing-point u n i t (FI'l"). Just as gra phics accel­ +with the system processor simply feeding the i n p u t eration is now being i ncl uded in system processor +e n d of t h e pipe and dra i n i ng t h e o u t p u t encl . design, images w i l l eventu a l ly achieve the status of +lkcause of t h e large amount of d a t a t o b e read from a requ ired data type and thus be supported in the +the board and displayed on the screen , the proces­ base system p rocessor. +sor should o n ly have to move that data, not do any +further opera t ions on i t. lo this end, any logic Product Definition- What Does the User +requ i red to format the p ixels for the display b i t map Want? +shou ld be included in the pipeline. The previously descri bed strategy was u sed in the + design of the image accell"rator board for the +Cost Reduction through Less E\pensive System DECimage 1200 system. The product req u i rements +Components The net cost of a bitonal imaging cal led for a low-cost, high-performance document +system is i nfluenced by the capab i l i t y of the assist i mage view statio n . These req u i rements evolved +hardware. The capabil ity of the hardware impl ies from the belief t h a t most users currently i nvesti­ +Oexibil i t y in the choice of other system hardware. gating imaging systems are i n terested i n appl ica­ +In t h is regard, the most significant impact o n cost tions and hardware that will enable them to quickly +occurs in the memory and the display. A system that and s i m u l taneously view document im ages and run +makes use of fast decompression and sca l i ng hard­ their existing non imaging appl ica tions. These users +ware can quickly d isplay compressed im ages from are involved with com mercial and business appl i­ +memory. This means either more images can be cations, rather than scie n tific app l i ca t ions. The +maintai ned in the same memory, or the system can DECimage 1200 system was planned for the manage­ +operate with less memory than i t wou ld witho u t ment of insurance claims processing, hosp i tal +the assist hardware; less memory means lower cost. pa tient medical records, bank records, a nd manu­ + A mon.: dramatic effect on system cost is in the facturing documents. As previously stated, the +d isplay. Imaging systems general ly need higher­ i m aging fu nctions requ i red for these view-oriented +density displays than n o nimaging systems, but the appl ications are high-speed decompression, scal­ +cost of a 150-dpi disp l ay is approximately twice the i ng, rotation, zooming, and clipping. +cost of a 100 - d p i display of the same d imensio ns. +However, we found that we could i ncrease legi b i l­ General Product Design +ity, i .e . , expand a bitonal im age to a gray-scale repre­ + In defining the image capable system, the key +senta tion, by using an intel l igent sca le opera t i on + points in the product requirements l ist were +in the hardware pipeline. For example, a bitonal +i mage rendered to a 100-dpi d isplay using the i ntel­ • High-performance image display +l igent scale process gives the perceived legi b i l i t y + • Low cost +of the same i m age rendered to a 150 - d p i di splay +with a simple sca l i ng method. That is, hy adding the • Bitonal images only (not gray-scale or color) +i n te l l igent scale, a 100-dp i d isplay can be used + • View-o n ly functions +where prev iously o nly a 150-dpi di splay wou ld be +adequate. The need for h igh-performance display influ­ + enced the project team to design the hardware +Cost Reduction through In tegration Presently, as accelerator board to handle im age decom press ion, +in the DECimage 1200, hardware-assisted image scali ng , a nd ro tation. Previous performance test­ +manipulation exists as a board-ll"vel option. Higher ing on a 3-VUP (VAX-1 1/780 u n i ts of p erformance) +levels of i ntegra tion with the base p l a t form w i l l CPU had yie·lded image software disp lay t i mes from +provide lower overa l l cost for an imaging system. 5 to 19 seconds. These images were compressed + + + + +16 lk)f. 3 No. 4 rail 19'JI Digital Techt�ical journal + Hardware Acceleratorsfor Bitonal Image Processing + + + +according to the cenT Group 4 standard (300 dpi, Group 3 and Group 4 bitonal compression algo­ +8.5 -by-1 1 inches), and ranged from 20 to 100 kilo­ rithms. This specialization al lowed the use of a +bytes in size. In addition, the software display times Digital application-specific integrated circu it (ASIC) +were highly dependent on the image data content. decompression chip. Finally, the view-only require­ +The more complex image files, which had lower ment limited the scope and complexity of the +compression ratios, took significantly longer to design by eliminating the need for extra hardware +decompress, scale, and display than the simpler to hand le the compression of im ages after they +image files. For example, an A-size, 300 -dpi, cenT have been scanned and edited . +Group 4 compressed image w i th a compression +ratio of 10:1 took approximately 18 seconds to + Specific Product Design +d isplay, while another with a ratio of 3 3 : 1 took +approximately 7 seconds. The decisions described in the previous section led + The other three requi rements Jed to decisions to our design of an image accelerator board that +about the specific design of the image accelerator supports: CCI1T Group 3 and Group 4 image decom­ +board. The need for low cost meant designing an pression using an ASIC decompression chip; integer +option for an existing low-cost platform, which led scaling using an ASIC scaling chi p ; orthogonal rota­ +us to D igital's VT1200 X window terminal. This tion; and image d isplay. Figure 3 shows a general +requ irement also led to our support of the pro­ block d i agram of the board and how it fits into +posed X Image Extension (XIE) protocol.4 The XIE Digital's VT1200 system architecture. The accelera­ +protocol extends the X l l core protocol to enable tor board is a ttached to the system address/data +the transfer of compressed images across the wire bus, and its registers, data input port, and data +and to enable interactive image rend i tion and d is­ output port are m apped into the C PU s 110 space. + ' + + + + +play at the server. In the X windowing client-server The accelerator board is accessed by reading and +environment, image applications and compressed writing specific addresses l ike any other system +im age files exist on the client host machine, as memory space . Note that the image accelerator +depicted in Figure 2. In addition, the XIE protocol logic is separate from the video terminal logic. +standardizes the interface-to-image functions in Decompressed images are read from the image +the X windowing environment and enables the board and writ ten to the base system video mem­ +development of a common appl ication that can be ory for d isplay. +used on any XIE-capable station. The client appl ica­ The main operation consists of the fol lowing +tion issues commands to the X server display sub­ steps: compressed image data is read from system +system and the XIE special ized image subsystem . memory and wri tten to the ASIC decompression +When a user selects an i mage to view, the com­ bu ffer by the processor; the data is then decom­ +pressed image file is transported from the client­ pressed, scaled by the ASIC seal ing chip, packed +side storage device to the X server memory. into words, and written to the out p u t buffer. + Because the proposed accelerator would han­ Figure 4 shows a detailed block d iagram of the +d le only bitonal images, we could special ize our image accelerator board logic. The scal ing chip out­ +board to decompress only the standard CCilT puts p ixels of data (1 bit per p ixel in this case) + which are packed into words using shift registers. + As soon as a word of data is available, the scaling + chip output halts. Control signals generated in pro­ + X/X I E C L I E NT X/X I E + APPLICATION SERVER + grammable array logic (PAL) write the packed word + X 1 1 AND XIE + WIRE + into the output buffer and tell the scal ing chip to + + + + I + PROTOCOL begin outpu t ting pixels again. When the out p u t + buffer is ful l , the processor reads the rendered + image data from the buffer. If rotation is requ ired, + COMPRESSED the processor writes the data to the rotation + IMAGE STORAGE IMAGE matrix; otherwise, the data is cl ipped and wri tten + D ISPLAY + • D ISK H A R DWARE + • C D ROM to the bit map. The image driver software, after set­ + ting up the board, al ternates between checking + whether the input bu ffer is empty and whether the + Figure 2 X Client-server Architecture output buffer is fu ll. + + + + +D igital Techllicaljournal Vol. 3 No. 4 Fall 1991 17 + Image Processing, Video Terminals, and Printer Tech nologies + + + + + c:J + NETWORK SYSTEM IMAGE + INTERFACE MEMORY HARDWARE + + + + t ! t ! + < SYSTEM ADDRESS/DATA BUS + > + f ! ! + OPTION DIAGNOSTIC VIDEO + MEMORY ROM MEMORY f- DISPLAY + + + + + F(!{ure 3 VT/200 System Architecture + + + The rotation circu it handles 90- and 270-degree to be decompressed before it can begin scaling; +rota tion, whereas 180-clegree rotation is hand led insteacl, scal ing begins as soon as the first byte of +in the data packing shift registers by changing the data is ou tput from the decom pressor. Thus dif­ +shift direction. The circu it rotates an 8-by-8-bit ferent pieces of the image fi le are being decom­ +bl ock of data at a time. The fi rst byte of eight con­ pressed, scaled, and rotated simu ltaneously. The +secut ive scan l ines is wri t ten into eight individual hardware pipeline also eliminates the need to +byte-wide registers. The most significant bit (MSB) store the ful ly uncom pressed image (approximately +of each of these registers is connected to the byte­ 1 megabyte of data for A-size 300 -dpi im ages) in +wide rotation output port latch. A processor read memory. The compressed image is written from +of this port triggers a simultaneous shift in a l l of the system memory to the accelerator board and a +rota tion data registers so that the next bit of each decompressed, scaled, and clipped image is read +register is now l atched at the rotation output port from the board . Because of the speed of the hard­ +for the next read. Figure 5 diagrams the rotation ware, the software can redisplay an i mage with dif­ +circuitry just described. ferent seal ing, cJ ipping, or ro tation parameters; i t + lb achieve the best performance, we p ipel ined merely changes t h e hardware setup for t h e differ­ +the functional blocks in the hardware. The scal ing ent parameters and sends the compressed image +engine docs not need to wai t for the entire image tile back through the accelerator board pi pel in e. + + + + IN PUT SCAN LINE + BUFFER RAM B U FFER + + + + ! ! + DECOMPRESSOR SCALING DATA PACKING FIFO OUTPUT + CHIP - CHIP r-- CIRCUIT - BUFFER + + + + ! SYSTEM ADDRESS/DATA BUS + t + + COMMAND + I t + 8x8 + AND STATUS ROTATION + REGISTER MATR IX + + + + Figure 4 Block Diagram of DECimage 1200 Accelemtor Hardware + + + +18 Vol. . i No. 4 Fall 1991 Digital Technical journal + Hardware Acceleratorsj01· Bitonal /mage Processing + + + + 8 SCAN LINES OF IMAGE DATA the word contain the number of consecutive white + 8-BYTE 1 8-BYTE 1 8-BYTE + + + I + or black pixels (called the run length). The upper + BLOCK BLOCK BLOCK + #1 #2 #3 bit of the word contains the run-length color code + I (0 for a white run and 1 for a black run). An FLC is + read from the FIFO buffer and decoded into one of + eight routine types. Each routine is made up of sev­ + 8x8 ROTATION + ROTATION OUTPUT eral states that control the color code toggling, run­ + M AT R I X REGISTER + length adder, and accumu lator circuits. At the end + 0 1 2 3 4 5 6 7 of each routine, a new word containing the run­ +SCAN LINE 0 t---1 length and color information is written into a FIFO +SCAN LINE 1 + buffer for the final stage. +SCAN L I N E 2 + t---1 +SCAN LINE 3 1---i - The final stage of the decompressor chip con­ +SCAN L I N E 4 + 1---t verts the run-length and color information to black +SCAN LINE 5 1---i or whi te pixels. This stage outputs these pixels in +SCAN LINE 6 1---i + 16-bit chunks when the scaling chip sends a signal +SCAN LINE 7 + '---' + indicating a readiness to accept more data. + + 0 1 2 3 4 5 6 7 + Scaling Chip The primary purpose of the scal ing + D I S P LAY BYTE chip is to input h igh-resolution document images + (300 dpi) and scale them for display on a medium­ + density moni tor ( 100 dpi). The chip offers inde­ + pendent scaling in the horizontal and vertical + Figure 5 Rotation Matrix + d i rections. The scaling design implemented in the + chip is a patented algorithm that maps the input +ASIC Design Description image space to the output image space. General +The ASIC design consists of a decompressor chip, M-to-N pixel scaling is provided where M and N are +which decodes the compressed image data to pixel integers between 1 and 127, with the delta between +image data, and a scal ing chip, which converts the them less than 65. M represents the number of pix­ +image from the input size to the desired d isplay size . els in and N represents the number of p ixels out (in + the approximated scale factor) . +Decompressor Chip The decompressor chip acts Given an image inpu t size and a desired d isplay +as a CCITT binary image decoder. The chip contains size, we must find the M and N scale factors that +three distinct stages, which are pipel ined for the best approximate the desired scale factor, wi thin +most efficient data processing. Double buffering the range l imits of M and N as previously stated. +of compressed input data is implemented to enable Thus an input width of 3300 and a desired out­ +simultaneous input data loading and image decod­ put width of 550 are represented by an 111 of 6 and +ing to occur. Compressed data is loaded into the an N of 1. The approximated M and N values are +input buffer by the processor through a 16- or 32-bit loaded into the chip scale registers for downscaling +port. Handshaking controls the transfer of decom­ or upscal i ng. +pressed data from the decompressor's 8-bit-wide The chip scaling logic uses the scale register val­ +output bus to the scal ing chip. ues to increment the input pointer position and + The first stage of the decompressor chip con­ generate output pixels. A la tched increment deci­ +verts CCITT-standard Huffman codes, which are of sion term is updated every clock cycle, based on +variable-length, to 8-bit, fixed-length codes (FLCs) 5 the previous term and the scale register values. +A sequential tree fol l ower circu i t is implemented When scal ing down (where fewer pixels are outpu t +to handle this conversion. Every Huffman code cor­ than are input), the logic increments the input +responds to a unique path through the tree, which pointer position every clock cycle, but on ly out­ +ends at a leaf indicating the FLC. The 8-bit FLC is puts a pixel when the increment decision term is +sent to a first-in, first-out (FIFO) buffer, which holds greater than or equal to zero. Figure 6a il lustrates +the data for the second stage. how this algorithm maps input pixels to output pix­ + The second stage of the chip generates a 16 -bit, els for a sample reduction. When scal ing up (where +run- length value from the FLC. The lower 15 bits of every input pixel represents at least one output + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 19 + Image Processing, Video Terminals, and Printer Technologies + + + + + SCALE DOWN FROM 10 I N PUT PIXELS TO 5 OUTPUT PIXELS + ( M 2 AND N 1 ) + = = + + + + + I NIT = N 1 = + + + DELTA1 2N 2 = = + + + DELTA2 = 2N - 2M = - 2 + + 2 3 4 5 6 7 8 9 10 + I NPUT • • 0 0 • • 0 • • • + + + INCREMENT + DECISION D = 1 D = -1 D = 1 D = - 1 D = 1 D = -1 D = 1 D = - 1 D = 1 D = - 1 + REGISTER + + OUTPUT • 0 • 0 • + 1 2 3 4 5 + + + + (a) Downscaling + + + + SCALE U P FROM 3 INPUT PIXELS TO 9 OUTPUT PIX ELS + (M 1 AND N 3) + = = + + + + + I N IT 2M N = -1 + = - + + + DELTA1 = 2M = 2 + DELTA2 2M 2N= - = -4 + + + 2 3 + I NPUT • • • + + + I NCREMENT + DECISION D = - 1 D = 1 D -3 D + = = -1 D = 1 D = -3 D = -1 D = 1 D -3 = + + + REGISTER + + OUTPUT • • • 0 • 0 0 0 • + 2 3 4 5 6 7 8 9 + + + + (b) Upscaling + + + Figure 6 Chip Scaling Examples + + +pixel), the.: logic outputs a pixel every clock cycle, tion and display at the server using the hardware +but only increments the input pointer position accelerator board. Like the X l l protocol, the XIE +when the increment decision term is greater than protocol consists of a client-side l ibrary called +or equal to zero. Figure 6b il lustrates how this algo­ XIElib, which provides cl ient applications access +rithm maps input pixels to output pixels for a sam­ to image routines, and a server-side piece, wh ich +ple magn i.fication. For both cases, the value of the executes the cl ient requests. The X I E server imple­ +pixel (black or w h i te) being output is t he value of ments support at two levels: device-independent +the input pixel pointed at du ring that clock cycle. and device-dependen t. The device-dependent level +In this dc.:scription, simply substitute rows for pix­ supports the fu nctions that benefit from optimi­ +els to repn:sent the vertical scaling process. zation for a particular platform , or functions that + are implemented i n hardware accelerators. The +Software Supportfor the Hardware device-independent level enables qu ick porting of +Software support is needed to enhance the func­ functional ity from platform to pla tform. Figure 7 +tions of the hardware accelerator in our image view illustrates the X/XIE cl ient-server architecture. +station. As ment ioned in the section General The c l ient-s ide X I Ei i b offers the minimum +Product Design, the XI E protocol extends the X l l functions necessary for im age re ndition and dis­ +core protocol to enable the transfer of compressed play. The tool kit level offers higher-level rou tines +images across the wire and to enable image rendi- that assist with windows application development. + + + +20 11JI. 3 No. 4 Fall 19';)1 Digital Technical journal + Hardware Acceleratorsfor Bitonal /mage Processing + + + + which is essentially as fast as the user can ask for + APPLICATIONS the d isplays. This speed is possible because the + image already resides in compressed form in the + server memory. Thus, the image does not have to + be read from the disk or transported across the + network. + + + + + + + Future Image Accelerator + + XLIB XIELIB I Requirements + Hardware accelerators will continue to be required + for bi tonal imaging until software can provide the + same functional ity at the same performance level. + This section d iscusses the more complex image + schemes that are used for gray-scale imaging and + DEVICE INDEPENDENT ( D I X) multimedia applications. In contrast to bitonal + -- + X SERVER X I E SERVER imaging, these appl ications will requ ire the use of + hardware accelerators wel l into the future. + DEVICE DEPENDENT (DDX) + Other appl ications wil l require richer user inter­ + l + + I I + faces util izing continuous-tone images, video, and + + + I I + IMAGING aud io. All of these new data types are generally + DISPLAY + HARDWARE data-intensive, and compression or decompression + of any one of them is a significant processing bur­ + den. Hand l ing them in combination indicates that + Figure 7 X/XIE Architecture the need for specialized hardware assistance will + persist for the foreseeable future. + +An example of a routine at this level might be Continuous-tone Images +lmageDisplay, which d isplays an image in a previ­ Bi tonal images are either black or white at each +ously created window. lmageDisplay parameters point, but some appl ications requ ire smoothly +might include x and y scaling values, the rotation shaded or colored images. These images are typi­ +angle, and region-of-interest coord inates. Whether cally referred to as continuous-tone images, a term +programming with the XIE protocol at the l ibrary that denotes e i ther color or gray-scale, e . g . , photo­ +or toolk i t level, applications developers benefit graphs, X rays, and still video. The representation +from the platform i nteroperability of the standard and required processing of this image format is +interface. Image accelerator hardware and opti­ significantly different from that of bitonal images. +mized device-dependent XI E code changes the Continuous-tone images are represented by mul­ +application's image display performance, but an tiple bits per pixel. This format al lows a greater +application developed using the XIE protocol can range of values for each pixel, which yields greater +run on any XJE-capable server. accuracy in the representation of the original + object. Additionally, each pixel can consist of mul­ +Accelerator Performance Results tiple components, as i n the case of color. The num­ +With the DECimage I200 X terminal, we have ber of bits used to represent a continuous-tone +achieved i nteractive performance rates, reduced image is chosen according to the nature of the +memory usage, and increased final image legibil i ty. image. +We achieved these rates by transporting com­ For example, medical X rays require a high +pressed files instead of huge pixel files and by imple­ degree of accuracy. Consequently, 12 bits are gener­ +menting specialized image processing hardware. ally regarded as the minimum acceptable for the +The DECimage 1200 can read, transport, decom­ rendering of this class of image. Color images typi­ +press, scale, and d isplay an 8.5 -by-1 1-inch b itonal cally require 8 bits per pixel for each component +document in I to 2 seconds. Successive displays, (YUV or RGB format) for a total of 24 bits per pixel. +i . e . , rotating, region-of-interest zooming, panning Table 2 shows the relative size of samples of each +around the image, all occur in less than I second, image. The need to express these images in a + + + +D igital Techtzical ]ournal Vol. 3 No. 4 Fall 1991 21 + Image Processing, Video Terminals, and Printer Technologies + + + + +compressed format is obvious from the storage because any change to either the evolving standard +space requi rements and the current storage med ia or a standard extension coul d be easily introduced +limits. to the firmware. The fastest implementations arc + The compression of cont inuous- tone images can achieved by special-purpose hardware accelerators. +be accomplished in several ways. However, most The ]PEG i mplementation docs not requ ire hard­ +imaging appl ications are not closed systems; ware, i . e . , the algorithm can be performed com­ +inevitably, each system needs to manipulate i mages pletely in software. The case for hardware assist +that are not of i ts own making. for this reason we is made in performance. Table 5 describes t he +acloptccl the ]PEG standard , which specifics an algo­ reduced instruction set computer (!USC) processor +rithm for the compression of gray-scale and color performance, in m i l l ions of operations per seconcl +images. Specifically, the ]PEG compression method (mops), needed to provide the specified operation +is based on the two-dimensional (20) d iscrete at a motion video rate of 30 frames per second 7 +cosine transform (OCT). The OCT decomposes an However, generic IUSC processors of those speeds +8-by-H rectangle of p ixels into i ts 64 20 spatial­ are not avai lable today Therefore, dedicated, ctts­ +frequency components. The sum of these 64 20 tom very large-scale integration (VLSI) devices +sinusoids exactly reconstructs the 8-by-8 rectangle. (such as the CL550-10 from C - Cube Microsystems) +However, the rectangle is approximated-and com­ must be used to perform the operations 8 Even +pression is achieved-by discarding most of the if the motion video rate is not requi red , the ASIC +64 components. Typically adjacent pixel values devices offer the simplest hardware solution. +vary slowly, thus there is l i ttle energy in most of the +d iscarded high-frequency components. + Live Video and Video Compression + The edges of objects generally contribute to the + Video captures the natural progression of events in +high-frequency components of an i mage, whereas + an environment, and is the refore a natu ra l and +the low-frequency components are made up of + efficient way to comm unicate. Consider, for exam­ +intensities that vary more grad ually The more + ple, the assembly of a set of components. One way +frequency components included in the approxi­ + to express the assembly process is to show a series +mation, the more accurate the approx i ma tion + of photographs of the assembly at successive steps +becomes. Table 4 shows some sample ]PEG image + of completion. As an alterna tive, video can show +compression ratios -" + the actual assembly process from start to finish. + The most popular part of the ]PEG stanclarcl , + Subtle details of the process such as part rotations +the "' baseline" method , was defined t o be easily + and movements can be clearly conveyed , with the +mapped into software, firmware, or hardware. + added dimension of time. +Straightforward OCT algorithms can be efficiently + Obviously, information expressed in video form +implemented in firmware for program mable DSP + can be valuable; however, significant problems arise +chips, clue to their pipel ined architecture. The fi rst + in adap t i ng video for use in computer systems. +systems to embody the standard did so using DSPs, + First, the huge data size of video appl ications can + strain the system's storage capabi l i ty. Video can +Ta ble 4 Ty pica l Compression Parameters be characterized as a stream of continuous-tone + for J P EG images. Each of these images consists of p ixel val­ + ues with individual components making up each +Compression Com pression Rendered I mage p ixel . For video to have fu l l effectiveness, the sti l l +Ratio Method I ntegrity + i mages must b e presented at video rates. I n many + 2:1 Lossless H i g hest qual ity- ctses the rate to faithfu l ly reproduce motion is + no data loss 30 frames per second, wh ich means that one + 1 2:1 Lossy Excellent quality- minute of u ncompressed v ideo (512-by-480 p ixels + i n d isti n g u i shable a t 24 bits per pixel) would consume over 1 gigabyte + from the original + of storage. In addi tion to storage demands, large + 32:1 Lossy Good qual ity- vo lu mes of data cause bandwidth problems. + satisfactory for + Presenting 30 frames per second to the video out­ + most appl ications + put with the above parameters wou ld require a + 1 00 : 1 Lossy Low qual ity- + transfer rate of more than 22 megabytes per sec­ + recognizable + ond from the storage device to the video outpu t. + + + +22 Vol. 3 No. 4 Fall l991 D igital Techuicaljournal + Hardware Acceleratorsfor Bitonal /mage Processing + + + +Table 5 Processing Requ i re m e nts for I ma g i n g Functions + + Processor +I ma g i ng Processor Operations per Pixel* Operations +Functions Read Write ALUt M u ltiply Tota l at 30 fps (mops) + +Pixel move .25 .25 0 0 .5 15 + +Point operation 2 1 0 4 1 20 + +3 X 3 convolve 9 8 9 27 81 0 + +8 X 8 DCT 24 14 16 65 1 950 + +8 x 8 block 1 28 1 91 0 320 9600 +match ing + +'RISC processor, 1M pixels, 30 frames per second (Ips), 8 bits. +tALU = arithmetic logic unit + + + + +Thus, reducing the amount of data used to repre­ Audio and A udio Compression +sent the video stream would al leviate both storage Video is usual ly accompanied by audio. The audio +and bandwidth concerns. can be reproduced as i t was recorded (with the + The starting point for the compression of video video), or it can be mixed with the video from +is with still i mages and, as previously mentioned, a separate source (such as a compact elise (CD) +the J PEG algorithm can be used to compress sti l l player). The audio data is defined by appl ication +continuous-tone i mages. Because video can b e rep­ requirements. I f the application a l l ows lower +resented as a sequence of still images, the algori th m qua l ity, the audio can be sampled at lower rates +coul d b e appl ied to each sti l l . T h i s procedure with fewer bits per sample, such as telephony rates, +wou ld produce a sequence of compressed video which are sampled at 8 kilohertz and 8 b i ts per +frames, each frame independent of the other sample. For appl ications requ iring high-quality +frames in the sequence. (CD) audio, samples are usu a lly taken at 44 k ilo­ + The evolving Motion Picture Experts Group hertz and 16 b i ts per sample. +(MPEG) standard takes advantage of frame-to-frame Integrating a u d io data into an application creates +similarities in a video sequence, thereby enabling special problems. The major characteristic that +more efficient compression than the appl ication d ifferenti a tes audio from the other data formats +of the ]PEG algorithm alone.9 I n most situations, presented here is i ts continuous nature. Audio +video sequences contain high degrees of s i m ilar­ must flow u ni n terrupted for it to convey any mean­ +ity between adjacent frames. The compression of ing. In video systems, the flow of frames may slow +video can be increased by encoding a frame using down u nder heavy system loading. The user may +only the differences from the previous frame. The never notice i t , or may not be annoyed by it. Audio, +majority of scenes can be greatly compressed; how­ however, cannot slow or stop. For this reason, large +ever, scene transitions, l ighting changes, or condi­ buffers are u sed to al low for load variations that +t ions of extreme motion need to be compressed as may affect a u d io reproduction. +independent frames. A more subtle problem i n creating applications + The need for hardware assist in this area is com­ using audio is in synchronization. Audio data is +pel l ing. Table 5 shows that to sustain a .JPEG decom­ usually included to add another dimension of infor­ +pression at 30 frames per second wou l d require a mation to the app lication (such as speech). +1950-mops processor. The same result can be Without a method of synchronizing the video and +obtained using the CL550-10 ]PEG Image Compres­ audio, one data stream w i l l drift out of phase with +sion Processor.9 Although this device does not the other. One way to include synchronization is to +make use of interframe similarities to increase com­ use time stamps o n the audio and video. This is par­ +pression efficiency, a device implementing the ticularly useful because standard time codes are +M PEG standard would exploit these similarities. used in most production machines. +Table 5 shows that motion compensation, to be The compression of audio data is not as efficient +supported at 30 frames per second, requires a as that of the other data formats. Since a statistical +9600-mops processor. approach to coding audio is h ighly dependent on + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 23 + I mage Processing, Video Terminals, and Printer Technologies + + + + +the type of input (i.e. , voice, musical instru ment), referenced. As the data is i ncorporated , it is com­ +another method i s required for generalized inpu ts. p ressed and stored. Authors requ i re the capabi l ity +Differential pulse code modulation (DPC .VI) is often to edi t and mix video and audio passages to get t he +used to encode aud io data. DPCM codes only the dif desired resu lt. Moreover, the video and audio may +ference between ad j acent sample values. Since the originate from d ifferent devices and may. even be in +difference i n value between samples is usua l l y less d ifferent formats. +than the magnitude of the sample, modest compres­ As defined above, " user systems" do not require +sion can be achieved (4 : 1) . The l im i tation using this all of the functions that aut horing systems need: +technique is i n the codi ng of h igh-frequency data. only. decompression is requ i red i n a typical user + Hardware assist for the audio data format w i l l system. Most ex isting user systems require a n ana­ +probably come i n t h e for m of hardware t o perform log video source (videodisk), which is purchased +functions other than compressi o n . For instance, as part of the appl ication. The device control is per­ +DSP algorithms can perform equa l ization, noise formed by the application, i .e . , when a user selects +reduction, ami special effects. a passage to be replayed, the application sends + commands to the videodisk. Figure 8 depicts an +Multimedia authoring system and a user system, along with +As the term impl ies, m u l t imedia may integrate a l l suggested I/O capabi l i ty. +o f the previously. mentioned image formats. The Next-generation m u ltimedia platforms w i l l make +word " may." is important in this context. This area fu l l use of d igital video and audio. This impl ies that +has been mainly technology-driven, due to such systems wil l be able to receive and transm i t m u lti­ +factors as l ack of standards, developing 1/0 devices, media appl ications and data over networks. This +insufficient system bandwidth, differing clara for­ interactive capabil i t y will improve the efficiency of +m ats, and a vast amount of software integra tion. many m u ndane appl ications and devices. For exam­ + It is currently a topic of debate whether typical ple, electronic mail can be extended with video and +users will require the abi l i ty to create. as opposed audio annotations, or meetings can be transformed +to only access, m u lt i media source material. How­ into v ideo teleconferencing. The adoption of com­ +ever, for d iscussion p u rposes, m u ltimedia plat­ pletely d igital data for multimedia a lso implies that +forms can be classified into two categories: the platform I/O w i l l change. Some user systems +authoring and user. Authoring refers to creation wil I not requ i re ana log device i nterfaces or contro l : +of multimedia source m a terial and req u i res differ­ t h e u s e r will load the application over the network +ent capabi li ties than user p latforms. In the creation or from a n optical disk. +of a m u ltimedia application, data from many differ­ Each of the i mage formats described i n this +ent devices may need to be d igi tized and cross- section has different characteristics, and each wil l + + + + AUTHORING USER + + + + + 110 A N D D E V I C E + 110 A N D D E V I C E + CONTROL + CONTROL + COMPRESSION/ + DECOMPRESSION + DECOMPRESSION + + + + + NETWORK NETWORK + + + + + Figure 8 Sample Multimedia Platforms + + + + +24 Vol. .3 To. 'I Fall 1991 Digital Technical journal + Hat"dware Acceleratorsfor Bitonal image Processing + + + +be presented in the embodiment of mul ti media. References and Note +Given the size, processing requirements (compres­ + 1 . Standardization of Group 3 Facsimile Appa­ +sion and decompression), and real-time demands of + ratus for Document Transmission, cenT +applications, hardware assist w i l l be a necessity. + Recommendations, Vol u me VI-Fascicle VII.3, + Recommendation T.4 (1980). +Summary +Imaging is a un ique data type with special sys­ 2. Facsimile Coding Schemes and Coding Control +tem requ irements. To achieve interactive rates of Functions for Group 4 Facsimile Apparatus, +bitonal image d isplay performance today, hardware CCITI Recommendations, Volume Vl l - Fascicle +accelerators are needed ; that has been the primary VIJ .3, Recommendat ion T.6 (1984). +focus of this paper. In the future, a general-purpose + 3. Digital Compression and Coding of Continuous­ +processor should be able to hand le the imaging pro­ + Tone Still Images, Part I, Requirements and +cess at the necessary speed, and beyond that, the + Guidelines, ISO!IEC JTC 1 Draft International +processor shou ld be affordable in a low-cost b i tonal + Standard 10918-1 (November 1991 ). +imaging system. However, the bitonal document +processing market wil l not wait; it is in a high state 4. J. Mauro, X Image Extension Concepts, Version +of growth and requ ires that products l i ke accelera­ 2. 4 (Cambridge: MIT X Consortium, June 1988). +tors be developed for at least a few years. + 5. D. A. Huffman, "A Method for the Construction + Continuous- tone docu ments and mu ltimedia + of Minimum Redundancy Codes," Proceedings +applica t ions will place an even heavier processing + IRE, vol. 40 (1962): 1098- 1 101 . +load on an imaging system. These areas wil l require +accelerators for several years. As imaging applica­ 6. G. K. Wa l lace, "The .JPEG Still Picture Compres­ +tions, including bitonal, expand to cover more mar­ sion Algorithm," Communications of the ACIVI, +kets, the quali ty enhancements and performance vol. 34, no. 4 (April 1991 ): 30-44. +benchmarks met by accelerators today wil l set + 7. Table 5 is adapted from Y. Kim, " Image Com­ +customer expectations. Consequently, our future + puting Requirements for the 1990's: From Multi­ +imaging products must be designed to meet these + media to Medicine," Proceedings of Electronic +expectations. + Imaging West (April 1991 ). + +Acknowledgments 8. CL550 ]PEG Image Compression Processor, Pre­ +The authors wish to express thanks to the liminary Data Book (San Jose, CA: C- Cube +X Window Terminal Hardware and Software Design Microsystems Inc., November 1990). +Groups for their support in developing the 9. Coding of Moving Pictures and Associated +DECimage 1200 option . The two major ASICs used Audio, Com mittee Draft of Standard ISO 1 1 172: +in the design were developed for previous pro­ ISO/MPEG 90/ 176 (December 1990). +jects, and those two design teams are also offered +our thanks. Special thanks to Frank G lazer and +Tim Hel lman for their insightful research on the +image rendering process. + + + + +Digital Tech-nical journal Vol. 3 No. 4 f'i:lll 1991 25 + Bjorn Eng berg + T homas Porcher + + + + +X Window Terminals + + X window terminals occupy a nicbe between X window workstations and grapbics + terminals. Tbe pU!pose of terminals in general is to provide low-cost user access to + bost computers or smaller dedicated systems. X window terminals furtber tbe + advance in grapbics terminals and prm•ide new and interesting wczys to utilize bost + systems. Etbernet cable provides for grapbics performance previous�}' not seen in + terminals. Tbe X Window 5)!stem developed by MIT allows multiple applications + to be displayed and contml/ed from tbe user's workstation. Now, with X window + terminals, tbe same poweJful user inte1face is available on bost and other non­ + workstation computers. + + + +In mid 1987, the Video, I mage and Print Systems graphics, but their performance was far below the +(VIPS) Group began the design of Digital's first expectations of a workstation user. Few p eople +X window terminal, the VTIOOO terminal and its have the patience to ru n , for example, a compu ter­ +code upgrade, the VT 1200 terminal. Our goal was to aided design appl ication on a VT240 terminal, assum­ +design and implement an X window terminal that ing such a version of the application is available. +would a l l ow the use of windowing capabi l ities on Although a workstation offers fast graphics capa­ +large computer systems. I n 1989, Digi tal developed b i l ities, its applica tions sometimes need more CPU +the VT l ) OO X terminal and in 1991 the VXT 2000 power or more disk space to do calculations in a +X terminal. The designs of these X window termi­ timely fash ion. Graphics appl ications written for +nals are all quite different. Our design approach workstations cou ld not run on faster host comput­ +changed as the u nderlying technology changed. ers, which did not provide a d isplay. Nor was there + This paper first compares host -system comput­ a standard way to get data from the host to d isplay +ing with appl ications that run on workstations. on a workstation. Each appl ication requ i red a +It summarizes the significance of the X Window unique solution to this problem. +System developed by MIT and discusses the cl ient­ Since the introduction o f the new c l ient-server +server model. The paper then present s the need for model of compu ting and modern networks, many +X window terminals and fol lows their development tasks can be d ivided into subtasks that can r u n +stages. It compares and contrasts Digi tal's differ­ on t h e most suitable processor. The X Window Sys­ +ent design strategies for the VTlOOO, VT I200, and tem uses the cl ient-server approach, as shown in +VT I300 X terminals. The paper concl uues with a Figure 1 . The appl ication is viewed as an X c l ient, +sum mary of the recently annou nced VXT 2000 and a workstation or a terminal can run an X server +X termina l . that controls the display. The X server also controls + inp u t from the keyboard and mouse or other point­ +Background ing devices. +Before the development of the X Window Sys­ +tem, there was very l i ttle overlap in fu nctional i ty +between workstations and other kinds of compu t­ +ers. Workstations had stunning and fast graphics, +and many powerful applications were avai lable on +them . Those applications were not available to users +of basic 80 -by-24 character-cel l text d isplay termi­ +nals connected to a host system located in a clean +room. Graphics t<.:rminals, of course, al lowed the use +of ReGIS or another protocol for m a t h and busin<.:ss Figure 1 Client-seruer Model + + + + +26 Vr>l. 3 No. 4 /-(i/1 /'}')/ D igital Teclmical journal + X Window Terminals + + + + + An X cl ient and an X server use an X wire to CPU as the X server, or it may execute on a host, +com municate, as shown in Figure 2. The X wire another workstation, or a compute server. The +is simply a two -way error-free byte stream , which X server can be connected to several X cl ients +can be i mplemented in many different ways. The simultaneously, with any combination of local +X Window System archi tecture does not stipu­ (running on the same CPU) or remote (running on +late how the X wire shou ld be implemented , b u t another CPU) X clients. The X server treats local and +several d e facto standards have emerged . Manu­ remote clients equally. +facturers have designed X wires usually based on +the clata transport mechanisms that were avai lable Workstation Environment +and convenient when the X Window System was Figure 3 compares a traditional non-X windowing +implemented. The X wires use transmission control workstation with an X windowing workstation. In +protocol/internet protocol (TCP/IP), DECnet, Local both workstations the appl ication must use a +Area Transport (LAT), and o t her protocols, and even graphics l ibrary to com mu nicate with the d isplay +shared memory buffers as a transport to avoid hardware and software. +protocol overhead. A single implementation often In an X windowing cl ient environment, the +supports several transport mechanisms. l ibrary of routines is cal led Xl i b . An application + The X server typica l ly executes on a processor designer can choose from a wide variety of toolk its , +with display hardware. The X cl ient can execute on which are essentially a level of addi tional l ibrary +almost any processor. It may execute on the same routines between the application and Xlib. The use + of a tool kit can significantly reduce the amount + of work an appl ication programmer has to do. The + appl ication software, Xl ib, optional too l kit, and + other l ibraries compose the X cl ient, as shown in + Figure 4. + Wi th few exceptions, the X server comes with + the d isplay hardware and input devices (keyboard + and pointer) indicated in Figure 5. + The X Window System with its flexibil i ty neatly + solves the problems of CPU power and d isk space + versus d isplay availabi l ity. Applications written for + X can execute on a wide variety of compu ters, and + the resu lts can be d isplayed on any of a m u l t i tude + Figure 2 X Wires of devices, even on a workstation that would not + + + TRADITIONAL X W I N DOWING + WORKSTATION WORKSTATION + + + + APPLICATION I A P PLICATION + + + GRAPH ICS + L I B RARY + + + + + I + WINDOWING + SOFTWARE + + DISPLAY HARDWARE + + + I I + KEYBOARD I I SCREEN + + + + + I MOUSE + I + Figure 3 Inside the Workstation + + + + +Digital Teclmicnl Journal Vol. 3 No. 4 Fall 1991 27 + Image Processing, Video Terminals, and Printer Technologies + + + + + stations. In a software development or document + APPLICATION + edi ting environment, the users often set up their + OPTIONAL TOOL·KIT X CLIENT workstat ·ions as terminals. They usually created a + AND OTHER LIBRARIES + few termina1l emu lation windows and used SET + XLIB + HOST or RLOGIN commands to connect to a host + system on which they stored their working envi­ + ronment and fiks. Only two features of a work­ + + Figure 4 1he X Client station were frequently used . Users kept several + terminal emulators on their screens a t the same + time, and set the terminal emulator windows to be + larger than 80 by 24 characters. Only rare.ly d id t he + X PROTOCOL H A N D L E R + X SERVER average workstation user take advantage of the fu l l + DIS PLAY AND + I N P U T HARDWARE power o f graphics applications. + The resu lts of our study ind icated a need for + a cost-effective a l ternative to a workstation that + Figure 5 The X Server wou ld provide the features desi red by a large num­ + ber of users. We envisioned a new k ind of termi­ +have the capacity to run the app l ication local ly. nal, one that would al low people to have m u ltiple +Figure 6 shows how the X Window System fits into windows of arbitrary size, to connect with m u l­ +a network environment. tiple hosts, ami, since the X architecture al lowed it, + The X Window System has already generated to be able to use the same kind of graphics as a +many useful appl ications, and its widespread popu­ workstation. +larity ensures that many more applica tions will be From an X arch i tecture standpoint, X terminals +made available in the future. and X workstations are qui te similar. They can in + fact use the same hardware. For example, Digital's +Needfor X Terminals VT1300 term inal runs on the same hardware as the +In a study to determine how worksta tions are used, VA.'Cstation 3100 worksta tion. X terminal software +the VIPS Group fou nd that many users did not take can also be made to run wel l on hardware plat­ +advantage of the fu ll potential of their work- forms that are not sui table for worksta tions. + + + + + HOST CPU 1 HOST C P U 2 + + + + + I X CLIENT I 1x C L I E NT 1 1x CLIENT 1 r x CLIENTl + I + l l 1 + I NETWORK + I N T E RFACE: + I I NETWORK I N T E R FACE + I + I I ETH E R N ET + + + + I X W I N DOWING WORKSTATION + + + + I NETWORK + I N T E R FACE: + I + I X C L I E NT I I X CLIENT l + I I + I X SERVER + I + I l + I KEY B OAR D II MOUSE + II SCREEN I + + Figure 6 X Window Network Environment + + + + +28 Vol. .3 Nu. 4 Fat/ 1991 Digital Techrtica l ]ournal + X Window Terminals + + + + + The main architectural d ifference between host, via the Ethernet or the serial l ines as shown +the X terminal and X workstation software is that in Figure 7. This capabi l i ty m a kes the VT1200 ter­ +X terminals are closed systems that do not sup­ minal useful in an environment that does not have +port local user applications. Although this may X window support. +seem to be an unnecessary restriction, i t does al low Although any X server can ru n windows soft­ +X terminals to be made for less money. An open sys­ ware, it does not provide a user interface. To manip­ +tem that a l l ows any user appl ication to run local l y u late the windows, the user needs a window +m u s t have a n established CPU architecture, a sup­ manager. The window manager creates window +ported operating system, such as the VMS, UNIX, frames that al low the user to invoke fu nctions to +or ULTRIX system, and, subsequently, sufficient move windows, resize windows, change stacking +memory and/or disk space to support such an envi­ order, and use icons. This capabil i ty also makes the +ronment. A closed system, on the other hand, can VT 1200 terminal useful when no host is available to +be designed with simpler hardware, a smaller oper­ run a remote window manager. A terminal with a +ating system, less memory, and thus lower cost. local window manager generates less network +The absence of the abili t y to run user applications traffic, and window management i s not slowed +locally does not i mpact usability significantly since by host congestion or network round-trip delays. +the user can run any desired application on another The VT1200 X terminal allows use of a remote win­ +CPU. D igital's VTlOOO and VT1200 X terminals were dow manager, if the user prefers a different style of +designed based on this approach. window management. + The local terminal manager provides the user +X Te rminal Environment i nterface to initiate connections to host systems. +X terminals often have local applicatio ns, but they It is also responsible for the terminal customization +must be built i n to the terminal by the designers. interface. +The VT1200 terminal has a video terminal emulator All clients commu nicate with the X server using +(VTE), a window manager, and a terminal m anager standard X wire comm ands only. Any window man­ +as the local applications. The VTE a ll ows the VT1200 ager, remote or local, can manage all the windows +terminal to m ake American National Standards on the screen, regard less of whether the clients are +Institute (ANSI) character-cel l connections to a remote or local. + + + + HOST C P U 1 HOST CPU 2 + + + + + S E R IAL + LINES + + + + + Figure 7 The X Terminal Environment + + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 29 + Image Processing, Video Te rminals, and Printer Tech nologies + + + + +Development of X Window Terminals col without some compression of the wire protocol +The development process of the VT 1000 and i tself. We had to build D igi tal's first X terminal with +VT1 200 X terminals has important lessons to teach an Ethernet interface. +us. The knowledge we gained in 1987 has helped us We needed to determine if this hardware platform +develop future generations of X terminals. could give us sufficient performance. We made sev· + When we designed the VTlOOO X terminal and eral performance estimates, based on what we +its code upgrade, the VTl200, we held many discus­ knew then about the X server and other software +sions within the group and with people from other components. We went through each step in as much +groups. We planned many i terations before we detail as we could (before anything was built) . We +arrived at the final architecture. It was by no means calcula ted how many instructions were necessary +the only way to design an X terminal, and in 19H9 to perform each task in the chain of receiving a +we tried a different approach with the design of the command and displaying i t on the screen. By .know­ +VT1300 terminal . We knew that the best decision at ing the speed of the CPU, we could estimate per· +a particu lar time might be very d ifferent from the formane<.: in characters or vectors per second . +best decision one year later, since the technical and Our estima tes showed that the VTIOOO X terminal +marketing environment is constantly changing. would not be exceedingly fast, but the perfor· +New tools, standards, and practices enter the field mance would most probably be sufficient, de.fi· +while others become obsolete. Newer products ni tely faster than a VA.'I(station 2000 in most cases. +must always have new features to meet changing In retrospect, actual performance of the VT1000 +technology requirements. terminal and the later software upgrade , the + VT1200, was close to our estimates, but i t took sev­ + eral passes of code optimization to ach ieve such +Hardware Platform + performance . + Our .first step was to discuss the hardware plat­ We also discussed alternate hardware designs + fo rm and select the kind of CPU to use, memory for p erformance improvements. One solution pro· +size, 110 considerations, type of d isplay, etc. We posed two CPUs, the TMS34010 microprocessor to +stud ied many diffe rent CPUs to determine which + hand le the display and a 68000 microprocessor to +one would provide the most capabi l ities for the hand le I/0 and other tasks. Unfortunately, we fou nd +lowest cost. A VAX chip was rejected because, at the no easy way to balance the workload between the + time, it was far too expensive for the required price two crus. We estimated that the different software + range of the VTIOOO terminal. The Motorola 68000 components would have the fo llowing relative CPU +series CPUs are quite powerful, but we had to con· demands: +sicler other factors such as ava i labi l i ty of software +and hardware tools, cross comp ilers and l inkers • Interrupts, 5 percent +that could run on the VMS system, and hardware + • Com munications, lO percent +debugging facil ities of sufficient power. We fma l ly +selected Texas Instruments' TMS34010 micro· • Operating system, 5 percent +processor with video support and several built -in +graphics instructions that made it a cost-effec tive • X server (minus d isplay routines), 60 percent +sol ution. It also came with VMS development tools, • Display routines, 20 percent +a c compiler, an assembler and linker, a single-step, +hardware trace buffer with disassembler, and a To equalize the load between the CPUs, we would +powerful in-circ u i t emulator that made it possible have had to spli t the X server in two, a solution that +to control execution in detail, inspect registers and was not feasible. Any other spl i t of tasks wou ld +memory, and set break poi nts and hardware watch cause one CPU to spend most of i ts time waiting +points (for example, break when writing value .x for the other, and the overal l performance gain +into locationy). would be minimal. Communication between m u l· + We further discussed the kind of l/0 to use. A tiple CPCs is complex and is very d ifficult to debug. +sample implementation of the MIT X server on a Therefore, we decided that two CPUs were not +VAXstation 2000 workstation and a primi tive serial worth the trouble or the cost. The best way to +l ine protocol showed, as expected , that serial l i nes double performance is to insta l l a single CPU that +were clearly insufficient to carry the X wire proto· is twice as fast. At that time, the TMS34020 was + + + + +30 Vol. _) No. 4 Fall 19')1 D igital Teclmical]ou>·naf + X Window Terminals + + + + +al ready being mentioned as a fol low-u p m icro­ u ncovered l ittle timing windows and race condi­ +processor. Since its software wou ld be compatible tions that had not been hand led properly. Even +wi th the TMS34010, we decided to keep it in mind w i th i n-circu it e m u l a tors, such bugs could take +for possible use in a future terminal. weeks to track clown. + In the VT1300 we decided to use the VAXELN +Code Selection operating system. We wanted to avoid the possibil­ + ity of time wasted on finding and patching holes in +The use of read-only memory (ROM)-based code + the design of a new operating system. +versus downloaded code has been debated for +some time. ROM-based code starts up faster and +incurs less network traffic at startup time (espe­ Local Terminal Manager +cia l ly on a site with m a n y X terminals), but is not The VTlOOO X terminal is self-starting at power-up, +flexible when software is upgraded. On the other b u t without a host system, it needs a local user +hand, downloaded code can be easily distributed. i n terface. We decided that this i nterface shou ld +An entire site can be upgraded with one or a few resemble a workstation session manager and thus +installations by a system manager as opposed to called it the local terminal manager. Although it +changing ROMs in a large number of terminals. covers a different set of functions, we wanted the +(Wit h the VT1200 X terminal, customers can change local terminal manager to implement a similar set of +ROM boards.) From the point of view of terminal objects and operations (the "look and feel" or style) +business, it made sense to use ROM-based code in of a workstation session m anager. The style of the +1987. We reasoned that not a l l sites would have DECwindows session manager was chosen to make +E thernet, but with ROMs the X terminal would it easier for a user to swi tc h between an X terminal +still be usefu l as a m u ltiwindow terminal emu la­ and a DECwindows workstation. We wrote a subset +tor. We real ized that such concerns would change toolk i t for all the " customize" screens and ensured +with time, and on t he whole, downloaded code that the VTE could use the same subset tool k i t for +would become the better approach. The only its "customize" screens. As DECwindows has pro­ +exceptions wou ld be i n the home or small office gressed, subsequent X terminals have adapted the +markets where a boot host or an Ethernet might not new user interface preferences, i n this case Motif. +be avai lable. Subsequent X termina ls are being +made in both downloaded (for example, in the Local Terminal Emulator +VT1300 terminal) and ROM versions. We considered a local terminal emu la tor to be an + important component. We knew that X-based ter­ +Operating System Selection minal emulators could run on the host, but in 1987 +Next we considered which operating system to hosts with X windowing support were rare. Since +use. We looked at other vendors' operating sys­ we were in the terminal group, a terminal that +tems, but found they were either too complex and could not manip u l a te ordinary text by i tself was +big or inadequ a te . One of our coworkers had writ­ considered u nsel lable . We wanted the ability to +teo a very compact operating system for a VAX access both X and non-X hosts and we wanted +system used on a nother project. We used it in our to support m u ltiple text windows. Therefore we +prototype and then adapted i t for the TMS34010 defined the terminal emu lator as an X cl ient so that +processor. We implemented add i t ional functions text windows could coexist with X client windows. +to run the rest of the software with minimum This feature has proved to be exception a l ly popu­ +changes. lar. A large n u m ber of users use nothing but v ideo + There are many advantages to working with terminal emulator windows. They are not inter­ +"your own" operating system. It is easy to make ested in X windowing graphics, but do want mul­ +changes, to work around trick)' problems, and to tiple and/or larger text windows on a l arge screen. +make special enhancements. But operating system +code is difficult to debug. Timing is very critical, Local Window Manager +and throughout the project, we fou nd strange bugs We debated whether or not to implement a local +in code that had i n i t ia l ly appeared to be a l l right window manager. The DECwindows window man­ +to everyone involved . We fou nd bugs u nder heavy ager was u nder development and was constantly +load condi tions after a rare sequence of events changing. The DECwindows window manager + + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 31 + Image Processing, Video Termina ls, and Printer Technologies + + + + +contained far too many VMS depende ncies to be Communications Protocol +ported easily. Also the X terminal did not have Many com mu nications protocols were available, +enough memory to run the DECwindows wol k i t but our choice was d ic ta ted by market pressures +local l y. We cou l d have ported other window man­ rather than technical reasons. The market demanded +agers, but they lacked the essential characteristics TCP/IP. DECnet would have been acceptable, but +of the DECwindows window manager. For a wh i le it was running out of avai l able addresses, a t least +we considered letting the local clients have a primi­ within D igital. DECnet address space supports +tive way £0 manage their own windows, until a ful l ­ only 64,000 nodes and requires manual address +featured window manager could be started o n a and name assign ments. After waiting weeks to get +host. Again, this alternative lacked the DI:Cwindows addresses for a few worksta tions, we real i zed that +system's quali ties. We eventu a l ly decided to write adding thousands of X terminals into Digi ta l 's inter­ +a window manager based only on X l i b and our nal network wou ld not be possible. DECnet Phase v +subset toolk i t calls. It has the essential characteris­ software has solved this problem. +tics of the DECwindows product. Al so, s ince the Next we looked at the LAT protocol used by +DECwindows window manager of necessity wou ld Digital terminal servers and fou nd that i t bad sev­ +keep changing, we wrote the l ocal window man­ eral advantages. first, the VMS operating system +ager in such a way that it cou ld rel i nquish control supports the LAT protocol. LAT uses u nique 48 -bit +to a remote window manager. This solution gave us Ethernet addresses to iden tify each node, which +the most flexibility for this hardware platform. The al lows a large node address space. LAT a lso does not +recently announced VXT 2000 X terminal has been requ ire any system management to add another ter­ +designed with virtual memory to accom modate a minal. A user can connect a terminal to a power +well-establ is heel unmodified window manager, the source, and the terminal a u tomatically becomes +Motif Window Manager. part of the network. Our performance evaluati ons + found that the LAT interface on the host could be +X Server writ ten to incu r Jess host overhead than DECnet, + which is important when many X terminals are con­ +We a l s o needed to choose an X se rver. We cou ld + nected to hosts. +have based our code on the d istribut ion tape from + Changes were needed i n the VMS LAT d river to +M IT, bu t a t the time the X Window System was not + accommodate X wire and font service connections. +yet a mature product. Every implementor had to + The VMS Software Engineering Group worked with +spend considerable time stabilizing the implemen­ + us to ensure that we would have those changes +ta tion enough to yield a prod uct and i mprove per­ + on schedule and in the appropriate VMS releases. +formance. Since the VMS DECwindows Group had + As a resu lt, we chose the LAT protocol for the VMS +been writing code for the server, we decided to use + com munity and TCP/IP for users of ULTRIX and UNIX +DECwindows code. Once the porting effor t started, + systems. +we found that most of the performance had been +improved by V;'w'{ MACRO cod e. Consequen tly, we +had to re-engineer a l l the modu les or adapt new Font File System +ones from the MIT tape. As we kept porting and Storing fonts and changing fo nt file formats were +enhancing performance, our code changed more major problems. Since the VT IOOO X terminal d id +and more until it became extremely difficult to not have a local file system, some fonts had to be +track bug fixes made by the DECwindows Group. stored in ROM to a l low the VT lOOO terminal to func­ +The MIT patches were also nearly impossible to use tion in standalone mode. A quick review of the +because of code changes and because our starti ng available DECwinJows fon ts showed that not a l l of +code was one step removed from the tape. them fit in the ROM space al lowed for the term inal . + 1b rang e ( -1 27 1 27) + mechanisms such as keycl icks, bells, and l ight­ + d Q ( dname ( X ) ) emi tting d iodes. These mechanisms are controlled + d1 ( dname ( Y ) ) + explicitly from the host so that minimal keyboard +) + state model ing is required. The capabili ties infor­ + After assigning a unique address to a device, the m a ti o n is used to identify the keyboard mapping +computer retrieves the device's capabi lities string table and the feedback mechanisms available. The +as a series of fragments using the Capabil ities keyboard mapping table can also be stored in the +Request and Capabil i ties Reply messages. The com- keyboard i tself as part of the capabi lities string. + + + + +Digital TechnicalJourna.l Vol. 3 No. 4 Fa/11991 4l + Image Processing, Video Terminals, and Printer Technologies + + + + +Locators appl ications. As the advantages of this open desk­ +The locator device protocol is designed to accom­ top bus design become wel l known, we expect +motla te a range of basic locator devices such as wider adoption of this product. The ACCESS. bus +a mouse or tablet. More complex devices can be is currently implemented on Digital's Personal +modeled as a combination of basic devices or can OECstation 5000 workstation, with implementa­ +provide their own device driver, thus minimizing tions underway for the next generation of RISC +the burden on the protocol. workstations and v ideo terminals. + A generic locator consists of one or more dimen­ +sions described by numeric values and , optional ly, Acknowledgments +a small number of key swi rches. The standard driver Many people contributed to the design ancl devel­ +requires the locator device to identify the type of opment of ACCESS.bus. I would especial ly l ike to +data it wil l report from a small list of options and acknowledge Tom Stockcbrand and Tom Furlong +adjusts to hand le this data type. These options are for their vision and early support; Chris Cued, Mark + Shepard, and Ernie Soul iere for their contributions +• Number of d imensions, e . g . , two, for a mouse or + to the ACCESS. bus electrical design and protocols; + a tablet + and Robert Clemens for the excellent demonstra­ +• Dimension type: absol ute, i . e . , referenced to tion hardware and firmware development support. + some fixed origin, li ke a tablet: or relative. i . e . , + changed since last report, l i ke a mouse Gene ral Rej(e rences +• Resolution in divisions per unit, e.g. , counts per D. Lieberman, " Desktop Bus Is Born Free," Elec­ + inch or counts per revolut ion tronic Engineering Tintes (September 2, 1991 ) : 16. +• Dynamic range of val ues that can be reported, ACCESS. bus Developer's Kit (Palo Alto, CA: Digital + i.e., the minimum and maximum values Equipment Corporation, Workstation Systems +• Number of key switches, from 0 to 15 Engineering TRJ/ADD Program, 1991 ). + + The assignment of scalar-value dimensions Signetics f l C Bus Specification (Sunnyvale, CA: +returned from one or more devices to the user Signetics Company, a Division of North American +interface functions is left to the appl ication. How­ Philips Corporation, February 1987). +ever, to accommodate most conventions. the scalar +d imensions and the key switches can be l abeled in +the capabilities string. + +Text Devices +The text device protocol is intended to provide a +simple way to transmit character data to and from +character devices such as a bar code reader or a +sma l l character display. A generic text device trans­ +mits a stream of 8-bit bytes from a character set. +Simple control messages are defined to support +flow control and to select communication parame­ +t<.:rs that might be used to i nterface with a modem. +The capabilities string contains informa tion that +identifies the specific character set and communi­ +cation parameters used. + +Summary +The ACC.ESS. bus network interconnect offers the +possibility of a standardized, low-speed, plug-and­ +play serial communications channel that can untan­ +gle peripheral i nterfacing and open the way to new + + + + +42 Vol. ."> No. 4 t�{t/1 J')')J Digital Teclmicaljournal + Ri chard Landau + Alan Guenther + + + + +Design of the DECprint +Common Printer Supervisor +for VMS Systems + + DECprint Printing Services software controls a variety of printerfeaturesfor a wide + range of printers. It supports several different page description languages, handles + multiple media simultaneously, and uses different I/0 interconnections and commu­ + nication protocols. Operating within the VMS printing environment, it imple­ + ments a large number of user-specified options to the PRINT command. DECprint + Printing Services functions as the supervisor in the VMS printing system for all + PostScript printers supplied by Digital. The common printer supervisor bas an espe­ + ciallyflexible internal structure and processing method to serve complex printing + environments. + + + +The increasing variety and complexity of printing the design of CPS, focusing on its capabilities within +devices in the last decade have strained the abi l i­ the VMS system. The paper then d iscusses the oper­ +ties of operating systems to support them. Users a tion of the VMS printing system and the enhanced +demand access to, and control over, the increas­ printing environment made possible by CPS. +ingly sophisticated features of their p rinters. At the +same time, appl ication programming resources are Printing System Dirnensions +stretched by the requirement to support various A printing system is the set of software and hard­ +devices and features. Modern operating systems ware components through which print requests +include printing systems that support printers and pass from the time the user decides to print a docu­ +insu late applications from many details of printing. ment u ntil the appropriate hard copy arrives. + DECprint Printing Services software was designed The variety of printing devices in use is a chal­ +to handle a wide variety of printers, with a range lenge for the printing system and for applica­ +of I/O connections, media hand l ing capabili ties, tion program mers. We use the word "printer" in +fi n ishing equipment, data syntaxes, and so forth. this article to imply the fu l l range of output devices +It provides the controll ing software that supports that are at tached to systems and networks. A sys­ +the fu ll range of Digital printers capable of printing tem today must support a wide number of d imen­ +PostScript documents. sions: marking technologies, media, medium sizes, + DECprint Printing Services functions as a compo­ speeds, transmission rates, and interconnects. +nent of the VMS printing system at the level of +printer supervisor, cal led symbiont in VMS termi­ The DECprint Model of Printing +nology. The supervisor is known within Digital as + The DECprint model of printing is composed of sev­ +the DECprint common printer supervisor or com­ + eral layers. Each layer has defined functions and 1/0 +mon print symbiont (CPS). It is called common + interfaces. The layers of the DEC print model and their +because it replaces a number of different symbionts + relationships to VMS and CPS are shown in Figure 1 . +and is com mon to a range of printers. CPS is a com­ + This model of print ing describes a usefu l structure +pletely new program developed by the Video, + with consistent functions and responsibilities. +Image and Print Systems Group. + This paper explores the environment in which • Appl ication. An application program creates +printing systems now reside. It describes the struc­ information that the user may want to print. Al l +ture and functions of DECprint Printing Services and types of applications fit into the model at this + + + +Digital Techu'icaljourual Vol. 3 No. 4 Fall /991 43 + Image Process ing, Video Te rminals, and Printer Technologies + + + + + DECPRINT ARCHITECTU R E VMS CPS + + + APPLICATION + + + + USER D IGITAL + JOB INTERFACE COMMAND + + - - -1- - - - - +- - + SUBMISSION LANGUAGE + INTERFACE - - + + + + + PRINT + ( N ETWORK) CLIENT SYS$SNDJBC + + 1 - -+- - + PRINTING + INTERFACE - - - - - - - - - + + + + + PRINT QUEUE + SPOOLER MANAG E R + PR I NT + I SE AVICE I + P R I NT PRINT COMMON + PRINTER PRINT + + - - - -1- - - - - -+- - + SUPERVISOR SYMBIONT + ACCESS SYMBIONT + INTE RFACE + + + MARKING PRINTERS + ENGINE + + I PR INTER + + FINISHING + EQUIPMENT + + + + Figure 1 Relationships of the Vll1S Printing System Components to the DECprint Model + + + level, from data processi ng programs and simple • Pri nt c l ient. The client accepts requests through + text edi tors to high-quality document formatting its API, performs defau lting for the user, assists in + and publ ishing appl ica tions The appl ica tion may + . selecting the correct prin t service, ga thers the + pres e n t a printing interface directly to the user, print instructions and docu ment files, and sub­ + or may create a final form document from which mits the job to the print service. The protocol + the user can access other print ing i nterfaces. used to submit the job may be operating system­ + specific or may be based on emerging standards +• User printing interface. A user expresses the + for network printing. The print service may be + desire to prin t through a user interface to the + local to the print cl ient (and the user), or it may + prin ting system. The i nterface may be oriented + be located elsewhere in t he network. + to written com mands, to user selection of + menu choices, or to a point -and-sdcct graph ical • Print service. The print service is a convenient + int e rfac e . abstraction that includes t he prin t spooler and aU + su bsequent layers in the execution of the print +• ]ob subm ission interface. User interface pro­ + job, for some set of physical printers. Printers + grams com m unicate with the lower kv<.: b of the + are often grou ped together based on their static + printing system through an applic a tion program­ + characteristics, such as type of printer, printer + ming interface (API) to the print client. The API + data syntax, ancl defa u l t media. + contains fu l l ca pabili ties for creating, d estroying , + + + + + a nd man aging print jobs of all types. The job sub­ • Print spooler. The print spooler accepts the print + mission i nterface may be operating svstcm­ job from the client, spools the files and queues + specific or may he based on emerging standards the job for later execution if necessary, ancl + for network printing. then schedu les the job for execution. If the job + + + +44 Vol. 3 No. 4 Fall 1991 Digital Technical jou rnal + Design of the DECprint Common Printer Supervisorfor VMS Systems + + + + requires resources that are not immediately avail­ Implementations of the model in various operat­ + able, human intervention may be necessary. For ing systems and printers may express the layers + example, if a job requires a special print medium, differently, sometimes skipping certain layers. The + then an operator or other printer attendant must VMS printing system contains components at most + provide the medium for the printer. If the job levels of the DECprint model. The DECprint com­ + requires a special font, the spooler may be able to mon printer supervisor (CPS) operates within the + obtain the fon t from a l ibrary without human VMS system, as indicated in Figure 1 . We designed + intervention. CPS to satisfy the requ irements and projected needs + of users, system managers, and programmers. In the +• Printer supervisor. The supervisor d irectly con­ + next section we discuss the design of CPS. + trols the printer. It interprets the print i nstruc­ + tions for the job, manages the printer and its fin­ Sharing Devices + ishing equipment, and writes the document data + Printers are often shared, especially high-end or + to the page description language (PDL) inter­ + specialized, expensive devices. Since shared print­ + preter. It also monitors the status of the printer, + ers are not always immediately available to the + supplies some resources on demand, and responds + user or application program, the printing system + to error conditions. On the VMS operating sys­ + is required to hold jobs for printing later. The sys­ + tem, the printer supervisor is cal led a symbiont; + tem must be able to store the user's instructions for + on ULTRIX and UNIX systems, a daemon. + printing, along with the contents of the document, +• PDL interpreter. Generally, final form document until they are needed. + data is written in a data syntax intended for print­ + ing, but it is not in the native form required Insulating the Application from Details + by the marking engine. A PDL interpreter trans­ A printing system insulates appl ications from the + forms the printer language into the lower-level details of printing devices. For example, DECprint + form for the marking engine. For example, in a typ­ Printing Services provides communications mecha­ + ical laser printer, a PostScript interpreter trans­ nisms and protocols, determines whether a shared + forms the PostScript language into a device-level device is currently busy, and sometimes translates + bi t map and media control instructions for printer data syntax. + the print engine. In a simpler impact printer, Appl ication programmers generally prefer to + the controller turns characters and control deal with as few external interfaces as needed to + sequences into pin timing and paper movement perform the task. Thus it is desirable to minimize + instructions. the number of d ifferent classes of printing devices + while maximizing the variety and flexibility of +• Marking engine. The marking engine consists of + printing devices. The DECprint architecture speci­ + the media transport and printing mechanisms, + fies that the printing system take responsi b i l i ty for + generally controlled at a low level. Marking may + matching the needs of the appl ication to the capa­ + be done by a wide spectrum of technologies, and + bilities of the output device, whenever possible. + the media used may also vary widely. For the + For example, a printing system might need the abil­ + most part, descriptions in this paper use raster + i ty to transform the printer data stream from a + devices such as laser printers as examples. + data syntax used by the application to a data syntax +• Finishing equipment. The overall printing sys­ used by the printer. Hidden transformation makes + tem includes finishing options that are not often the system easier for applications to use. DECprint + considered part of the (largely electronic) print­ Printing Services provides a certain number of + ing system. Currently affordable components of printer data syntax transformations of this type, + the printing system are typically automated. For from languages such as DEC PPL3 (which is com­ + example, several years ago duplex (two-sided) monly referred to as "ANSI" within Digi tal) and + printing was not economical for most office ReGIS to PostScript, and from PostScript to printer + applications; today it is, and many office printers bit maps. + include this finishing fea tu re. Stapli ng, on the + other hand, is still not economical for most office Internal Structure of CPS + applications, though i t is i mplemented i n many In designing CPS, our primary goal was to create a + high-end production printers. flexible system that would hand le all the printer + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 45 + Image Processing, Video Te rminals, and Printer Technologies + + + + +features we could foresee ancll many tha t we could as simple as "create a separator page·· or as complex +not foresee, a system that could be modified as as the sequence "read a file, perform carriage con­ +needed to hand le not just new printers but new trol convt:rsion , add /HEADER, translate from A:'-ISI +classes of printers. CPS is capable of managing a data syntax to PostScript, a nd write the ITs u l t to +wide variety of character, l i ne , page, and document the printer." A print job is a set of job steps that per­ +printers. forms a l l fu nctions the user requests explici tly or + lb create a flexible printing system, we needed to implicitly. The CPS fac i l i t y that transla tes sekcted +design a highly modu lar internal structure. This inter­ prin ter data syntaxes into the PostScript language is +nal structure combines modules i n to sequences a t discussed in the section Data Syntax Tra nslation. +several levels t o provide a general framework for +control l i ng and manipula ting I/O devices. + Printjob A nalyzers + At the bottom level of the structu re are fi lter + To simpl ify the addition of new printers and new +modu les, which are l ightweight, independently + cl asses of printers, CPS contains a software struc­ +schedulable subprocesses within a VMS process. +Filter modu les commlmicate with each other by ture that corresponds to the hardware mechanisms + of a printer. +means of 1/0 rou tines and a shared data structure +containing joh information. Pointers to the 110 rou­ A print job ana lyzer (PJA) determines which + +tines and shared data are suppl ied in the invoca­ job steps are requ ired to process a job. CPS i ncludes + a separate print job analyzer for each major class +tion of the filter module. The effect of the stream + of printer that it supports: serial PostScript, +1/0 routines is much l ike that of pipes i n the UNIX + PrintServer, and LN03 I mage printer devices. When +operating systems. + the symbiont begins execu tion, a PJA is chosen based + A t the next h igher level is a set of com municating + on the type of device associa ted with the queue. +filter modu les; each stream of filter modu les is + This PJA is used u n t i l the symbiont is stopped. If a +cal led a job step. Final ly, a module cal led the print + term inal device, such as a TI or TX or LT device, is +job ana lyzer combines a sequence of job steps to + associated with the queu e , then the PJA for a serial +hand le a complete print job. + device is i nvoked. I f a n LD device is used, then the +Filter Modules andjob Steps PJA for an LN03Q printer is c hosen . Otherwise, the +Filter modu les can read input from a preceding fil ter PJA associated with PrintServer devices is used. +modu le and write data to a succeeding filter mod­ Each PJA contains a l ist of al l job steps requ i red to +u le. h lter mod u les may p erform fu nctions such as execute a job on the class of pri n ters it supports. +reading a file, converting carriage control , translat­ The PJA selects the job steps it needs from this l ist, +ing data syntax, or writing data to the printer. A depending upon the i nstructions received from the +filter modu le receives as argu ments an input stream queue manager. +and an ou tpu t stream , like a UNfX process, and a Job steps are I i nked together. The first job step +shared data structure, u n l ike a Ul\TJX process. A sim­ chosen by the PJA is l inked to the termination of the +ple fi l ter moclulc reads data from the inpu t stream, P.JA i tself; when t he PJA finishes compil ing the job, +processes data, and wri tes data to the output stream. it termina tes, thus starting the execution of the job. + A fi l ter modu le may condition i ts operation based At the begi n n i ng of each job step, each filter mod­ +on informa tion from the shared data structure or u le is assigned stack space and a stack fra me. Its ini­ +the contents of the data strea m. For example, a t i a l program counter address and arguments are +translator filter modu le might form a t data based on stored in i ts saved registers for process activation. +the page size, margins, and aspect ratio specified CPS uses a piped stream 1/0 mechanism similar in +in the shared data structure, or based on control fu nction to a U N IX stream; a filter module 's input +sequences in the data stream, or bot h . comes from the outpu t of the previous module, and + Not a l l filter modu les use t h e input o r output its output becomes input to the following mod u le. +streams. The file reader filter module reads from the I3y convention, the first filter mod u le of the job step +file instead of the input stream. Similarly, the device is activated first i n the job step; when a filter blocks +output mod ule writes to the printer instead of the for output, t he next fi lter module is activated . That +output stream . fil ter modu le then runs u n ti l i t blocks for inpu t or + A j o b step i s a s e t o f filter modu les piped together output, a t which point the previous or fol lowing +to perform one complete subtask. A subt:tsk may be filter module is activated . + + + + +46 Vr>l. 3 Nu. 4 Fall 1991 D igital Technical journal + Design of the DECprint Common Printer Supervisorfor VMS Systems + + + +Ta ble 1 Simpl ified Job-step Sequence Table 1 shows a simplified listing of the job steps + compiled by the serial PJA to process a simple job: +Job Step Functi o n + one file to be printed in ANSI mode. Each of the job +init_ps_device Ensure the device is "fixed up." steps shown contains one or more filter modu les +check_prologues Ensure that persistent piped together. For example the job-burst job step + prologues are loaded. has two modules piped together: the job-burst mod­ +sheet_count Get the beg i n n i ng page count. u le and the write-to-printer module. Figure 2 shows +job_burst Print job bu rst page. several job steps with several filter modules each. +sheet_size Get the cu rre nt sheet_size. + If an error occurs at any point in the processing + of a job, CPS skips job steps until it reaches the +wait_sheet_size Wait for the sheet_size before + conti n u i ng . identified error job step set by the PJA. In Table 1 , +fi le_set up Send a n y f i l e /SETUP mod u l es. + the error job step points to the sync job step that + precedes the job-trailer job step . In this case, CPS +get_vmbytes Get the amount of local printer + memory avai lable on the resynchronizes with the printer and prints the job­ + printer. trailer page, includ ing the error message. +wait_vmbytes Wait for the local printer + memory message f rom t h e Event Handling + pri nter. In addition to the output side of processing a job, +file_out Read the f i le to print and send there is a corresponding input side. The input side + it to the DECansi translator. reads messages from the printer, parses them , and +sync Wait for the printer to finish all notifies the appropriate hand ler of the event. The + pages. + handler is chosen based on the type of message sent. +init_ps_device Ensure the device is "fixed up." +sheet_count Get the ending page count. + • CPS internal messages are d ispatched to the + appropriate symbiont routines. For instance, +wait_sheet_count Wait for the page count to + come back. printer resource messages contain information +job_trai ler Print the job trailer page. + that affect CPS internal operations: paper size is + stored for later use by layup (the general map­ +sync Wait f o r the printer to finish + the job-trailer page. ping of page images to sheets) and translators; +d i sconnect Release the printer. + virtual memory size is stored for translators; and + page count is stored for la ter use in accou nting. + + + + + JOB STEPS + + FILTER + MODULES + + + + + J READ GET + VMBYTES + MODULE + WAIT + FOR + VMBYTES + + + + + Note that data flows from top to bottom and job steps progress from left to right. + + + + + Figure 2 job Steps and Filter Modules + + + +Digital Technical Journal Vol. 3 No. 4 Fall 1991 47 + Image Processing, Video Termj oals, and Printer Technologies + + + + +• Printer status messages arc dispa tched to the The VMS Printing SJ'Stem Environment + operator and, in some cases, to the current user. CPS funct ions as a component of the VMS printing + CPS uses the normal V.\·IS OI'CO:vl notifica tion system at the level of printer supervisor. As such, i t + mechanism to send messages to the system opn­ interacts with, and is shaped by, the other compo­ + at or. If the user specified /NOTIFY in the print nents of the VMS system . The term printer sup er­ + inst ructions, then CPS us<.:s the V.\IS SllRKTI IRt : visor is used in this paper to be consistent with the + syst<.:m service to send the message to the user term inology of the em erging Interna tional Stan­ + also. dards Organ ization (ISO) Document Printing Appl i­ + cation draft standard, ISO/IEC DIS 10175. + In some cases, printer status messages require + addi tional processing. for example. paper jams + Components + requ ire spe<.:ial hand ling on some print<.:rs: since + CPS cannot determine how many pages were lost The V M S Batch/Print system is a general queue man­ + in th<.: jam, it invok<.:s human intervention by plac­ agement service, capable of queuing, schedu l ing, + ing the job on hold. The operator or user can and executing jobs in response to a variety of user­ + determine what parts of t he job, if any, to reprint. specified instructions. 1 On the VMS system, the + printing instructi ons arc stored in a print job +• Program status messages and user data messages object, which is pl aced in a queue of jobs for a + arc dispatched to the job log. If the user specified printer. Modern print jobs often resemble batch + /NOTIFY. then they are also displayed with the jobs, due to complex stored processing instruc­ + $ ll R KTHRU system s<.: rvice. These messages may tions and the heavy computing load placed on + be printed or logg<.: d . graphics printer control lers. + The V.\15 printing system contains components a t + The input and output sides of the symbiont run + most levels o f the DECprint architectural model. +asynchronously most of the time, hut occasionally it +is necessary for the ou tpu t sid<.: to wa it for a mes­ • l lser printing interface. The V M S system includes +sage from the printer. This synchronization between interactive Digital Command Language (DCL) +the input side and output side of the symbiont is interfaces for printing and managing print jobs, +accompl ished by an internal event- signaling facil­ printers, and t he printing system i tsel f. 2 For +ity. When synchronization is r<.:qu ired, the output DECwindows appl ications. the DECwindows Print +side wai t s for a specific named <.:vent and the input Widget provides a graphical interface that per­ +side signals that event when i t is detected . For mits users to specify all the options for printi ng , +example, a t the end of a job, CPS needs the final a n d the ALL-IN-1 appl ication provides character­ +printer sbeet_count i n order to calcu late the cel l menus for choosing print options, includ ing +sheet_ count for the job; this count is printed on the the enhanced options offered by CPS. +trailer page and stored in the VMS accounting + • job submission in terface. The VMS system +records. When CPS ne<.:ds the sheet_count, the out­ + includes program cal l interfaces that give the +put side waits for an event named sheet_count. The + program a l l the capabilities of the DCL user +input side parses the incoming sheet_count mes­ + interface. 1 +sage, stores the returned value in the shared data +structure, and signals the sheet_cou nt event. The • Print cl ient and service for remote printing. The +processing of this event is asynchronous: at the d istri buted queuing services product currently +time the message comes in, the output s ide may or provides transparent remote printing in net­ +may not have stal led while wa iting for the works using a proprietary network protocol. +sheet_count even£. If the output side was wai ting + • Print spooler. The VMS job Control ler, recently +for that event, it is sched ul ed for fu rther process­ + replaced by the VMS Queue Manager, fu nctions as +ing; if the output side was not waiting, the event is + queue manager and sched uler. (The function of +remembered, in case the output side attempts to + spo oling printer data to temporary files is per­ +wa it for this cond ition in the near hnw-e. + formed by the VMS file system and is transparent + In the next section we describe the ways CPS is + to most components of the printing system.) +controlled and managed in the VMS printing system +and how it expands printing capabili ties in the VMS • Printer sup ervisors. The VMS system provides +environment. two standard symbionts to support most l ine + + + + +48 \kJI. j No. 4 Faii i'.J'Jt Digital Techllica l jourtwl + Design of the DECprint Common Printer Supervisorfor VMS Systems + + + + printers and serial printers. PRTSMB supports job, but cannot specify certain other qualifiers such + printers attached directly to communication as DATA_TYPE. It can also permit users of old appli­ + ports on the CPU, e.g. , the printer port on a VAX cations to access new fea tures of the printing + workstation. LATSYM provides support for print­ system. + ers attached to the serial or parallel ports of + DECserver network communications servers. For VMS Print Commands and Interfaces + PostScript printers, CPS is used instead of these The VMS printing system is manipulated through + standard symbionts. DCL commands and qualifiers. Many of the + The VMS printing system also contains compo­ qualifiers are hand led by the queue m anager and +nents that affect CPS processing. have no impact on the operation of print sym­ + bionts; others directly affect the operation of CPS.2 +• Device control libraries are col lections of sma ll The VMS system also supplies a call interface to + text sequences that can be inserted i nto the data these functions.·' + stream from the symbiont to the printer. The + sequences are ideally organized into text l ibraries VMS Interfaces to Symbionts + containing named mod ules, with a separate + The VMS Job Controller/Queue Manager provides + l ibrary for each type of output device . Device + two interfaces for customizing print symbionts: the + control modules can be associated with a printer + PSM modu le-replacement interface, and the SMB + queue by the system manager as part of a FORM + server symbiont interface. CPS is currently imple­ + definition or a job reset function, or accessed + mented as a single-stream symbiont through the + d irectly by the user with the /SETUP qualifier. + SMB interface. + Device control l ibraries frequently contain The SMB interface perm its a user to replace the + device-specific control sequences that alter the flow of control of the symbiont with a separate pro­ + format of the text and pages, for example, setting cess. The process may be writ ten in any style and + printer paper margins, setting character pitch, or structure suitable to the task a t hand, and need fol­ + enabling landscape printing. They may also con­ low only certain minor guidelines with respect to + tain downloadable font data or preprinted data the operating system environment. To use the SMB + for each page. interface, we replaced the entire symbiont process. + The result was much greater flexibility, but we +• VMS form definitions contain page size and mar­ + were required to write more program code. + gin specifications that guide the print formatting + The SMB interface provides services to the sym­ + process for a print job. The user can also specify + biont process through subroutine entry points and + page setup strings and can prohibit the symbiont + callbacks that pass messages between the symbiont + from wrapping l ines during processing. + and the VMS queue manager. Messages from the +VMS Print Queues system to the symbiont specify functions such as + start up, shut down, begin job, pause, resume, and +VMS has several distinctly d ifferent types of queues. + interrupt. Messages from the symbiont to the +Execution queues process jobs through a symbiont, + system return information such as job status, job +and generic queues transfer jobs to other queues. + completed, device status and error information, +Often generic queues are used for load balancing: + and checkpoint and accounting data. +one generic queue may feed several printers of sim­ +ilar capabi l i ty and location. + CPS also uses generic queues in an unusual way. + Range of Printers Supported +Default attribu tes can be specified for generic CPS currently supports the fu l l range of PostScript +queues that cause all jobs subm i tted through the printers supplied by Digital, from a low-speed +queues to inherit certain default print instructions. color printer up to a 40-page-per-minute laser +For example, a queue can be established that, by printer that can hand.le 11 different paper sizes. +defau lt, assumes that jobs are PostScript docu­ +ments, or assumes that jobs should be printed in Special I/0 Processing +landscape orientation. This abil ity to set defau lt CPS supports several different means of com muni­ +queue attributes is essential for supporting appl ica­ cation wi th the printer: serial, Ethernet, and a spe­ +tions that can specify the queue name for a print cial high-speed video connection. + + + +Digital Technical journal V!Jl. 3 No. 4 Fal/ 1991 49 + Image Processing, Video Terminals, and Printer Tec h nologies + + + + + The serial connection may be either a d i rect con­ video connection or data bus. For such a controller­ +nection between the compmer and the printer or less printer to be general ly usefu l , the printing +a local area t ransport (LAT) connection by which system must em u l a te a n existing class of prin ter. +printer is a ttached to a serial port of a DECscrver The LN03 I m age printer (LN03Q) is a bit-map +terminal server. The two methods differ only i n prin ter of this type. I t uses a special h igh-speed +t h e way johs are started and terminated . For DMA bi t -map i nterface that p lugs into a Q-bus and +LAT-connccted printers, CPS must establ ish a nd d is­ provides the speed required for print i ng scanned +miss the LAT connection a t the start and end of images. The protocol between this i n terface and +each job. the printer consists of bit maps and a sm a l l amount + Once t he connection is establ ished with the of status and synchronization information. +serial printer (via IAT or d i rect connect), CPS begins The engine i ts e l f includes only the laser imaging +a dialogue with the printer using an asynchronous and paper ha n d ling equipmen t. CPS hand les the +serial l ine protocol and PostScript programs. The rest of the control ler fu nctions i n the host com­ +asynchronous serial I ine protocol, defined by puter. Because of the level of support and emu la­ +Adobe Systems Inc . , consists of five control charac­ tion provided, the LN03Q printer appears to be an +ters that alter or query the state of the printer. ord inary PostScript job printer with some special + The symbiont forces the printer into an id le state image capabi l i ties. +by a series of contro i/T, control/C, and controi/ D For a given print job, CPS performs the normal +characters. When a controi/T resu lts i n an I DLE processing up to the point a t which the PostScript +message from the printer, the symbiont and pri nter languag�.: data stream would normally be sent to the +are ready to process a job. printer. At this poi nt, CPS d i rects the data stream to + PrintServer printers on Ethernet networks are a special PostScript interpreter subrou tine that pro­ +DECoct nodes. To write to a PrintServer prin ter, CPS duces a bi t-map im age of the printed page in mem­ +establ ishes a DECoct task-to-task session at the ory The bit-map image is then sent to the prin ter +beginning of the job. The dialogue requi red for syn­ through a special LNV21 d i rect memory access 1/0 +chronizing serial printers is not necessary for the interface on the Q-bus. +Ethernet printers; the PrintServer protocols pro­ The software for the LN03Q printer a lso has one +vide synchronization ancl device control opera­ special processing path. The l.N03Q printer is +tions through separate control channels. in tended as an i m age printer for bi t-map images. + Printers connected through Ethernet use several CPS supports im age fi les containing page im ages +protocols, which are layered on DECnet task-to-task that are scanned or precomputed at device resolu­ +com munications. The protocol used depends upon tion (300 clots per inch) and optionally compr<.:ssed +the version of the PrintServer code. with Comite Consu ltatif I nternationale de Tek­ + The local area print service (LAPS) protocol was graphique et Tetephon ique (CCJTT) Group 3 (l D) or +developed fo r the PrintServer family and is sti l l in Group 4 (20) compression methods. Image files can +use. The Common Prin ter Access Protocol (CPAP) be transm it ted directly to the printer w ithout con­ +wi ll replace LAPS in a l l PrintServer printers. ; PAP is verting to PostScript. I m age files can only be sent +based on the earlier Reid-Kent protocol, I n ternet directly to t he p rinter if they are printed one page +Socket 170, and is being discussed as a possible new per sheet; if the user requests printing mu ltiple pages +Internet standard. ' per sheet, or other layup fu nctions, then the image + is processed through the PostScript in terpreter. +Special Processingfor "Dumb" Printers I mage fi les are structu red in Digital document +I n some printer configurations, i t is economical to in terchange for m a t (DDI F), wh ich expresses text, +use the worksta tion or CPU as the printer con­ graphics, and images together. Files intended for the +troller. In t h is case, the printer i ncludes only the LN03Q printer must contain only image bit maps. +print engine and media hand l ing and finishing If the print job specifies DATA_TYVE= DDIF or the +equ ipment, ancl none of the electronics, comput­ file is a DDIF file, then CPS examines the file i n a spe­ +ers, and interpreter programs that render the cial mode. If the file correctly contains only image +graphics language into the elements requi red by the b i t maps. CPS decompresses t he images in memory +print engine (usual ly a n array of pixels). Such a if necessary, using the DECimage I mage Support +"dumb" printer is physical ly connected to the com­ Li bra11' rou tines. and then sends the u ncompressed +puter by a very high-speed l ink such as a direct b i t map directly to the LN03Q print engine. Thus + + + + +50 !4JI. 3 Nu. 4 l-it// 1991 D igital Techn ical jou r, at + Design of the DECprint Common Printer Supervisorfor VMS Systems + + + +the image goes directly to the printer without pass­ Data Syntax Translation +ing through the PostScript interpreter. CPS provides a facil ity that translates selected + printer data syntaxes into the PostScript language. +Special Processing in CPS The translating programs are subroutines, some +CPS includes a number of special features and func­ quite large and complex, that accept a data stream +tions to satisfy the requ irements of the DECprint in one format and produce a data stream in another +architecture and the VMS printing system. In this format. The translators are responsible for all for­ +section, we d iscuss the features that extend the matting, including sheet size, page orientation, +process of standard print symbionts or are com­ aspect ratio, and type sizes; CPS is responsible for +pletely new. all I/0 and coordination with the printer. The trans­ + lation facility currently supports the fol lowing +Reading Print Instructions printer data syntaxes: DEC PPL3, ReGIS, Tektronix +CPS reads the print instructions for a job from the 4010/4014, and PCL Level 4. +VMS queue manager through the SMB$READ_ The translation facil i ty has several restrictions. A +MESSAGE and SMB$READ_MESSAGE_ITEM functions file may consist of only one data syntax, and all files +of the SMB interface. Print instructions are in a job must be of the same data syntax. +expressed as attributes with values. Each attribute In general, CPS performs the translation from +has an associated numeric code and symbol, called one data syntax to another on the host computer. +an i tem code, and a value of a specific data type. In this way, simple printers that support only the +The symbiont reads each item code and value, and PostScript language interna l ly can be extended +stores the information in a static data structure. to support a number of printer languages. This +The information is used later to determine the pro­ reduces the requ irement for a complex printer con­ +cessing sequence for the job, special information to troller that supports m u ltiple data syntaxes inter­ +be displayed on separator pages, and so forth. nal ly. Host translation can guarantee consistent use + across jobs of the printer's internal fonts, page ori­ +Bidirectional Communication with entation, finishing equipment, and page layup The +PostScript Printers general mapping of page images to sheets supplied +CPS requires a fu l l duplex communications path to as part of CPS requires that the printer operate in +PostScript printers since they report many condi­ PostScript mode. To ensure consistent use of fonts +tions by sending messages to the host computer. and consistent positioning of pages with respect to +These messages include device status messages, finishing such as duplexing and stapling, all lan­ +program status and error messages, user data mes­ guage translation must be done by the symbiont. +sages, and replies to CPS inquiries. + CPS also requests information from the printer Page Layup Multiple Pagesper Sheet +for synchronization, formatting, and accounting Page layup is the process of printing more than one +purposes. For instance, to determine how to for­ page image on a sheet of paper. When more than +mat ANSI text, the symbiont needs to know what one page i m age is placed on a sheet of paper, the +paper is loaded in the printer. i m ages are rotated and scaled to fit on the page, but + CPS receives the messages from the printer and are altered in no other way. The layup facility works +parses them to determine what it should do with with all data types, includ ing PostScript and PCL +the message. If the message is device status, then data syntaxes. Layup also permits formatting for +CPS routes the message to the operator and/or the larger paper sizes and then printing on smal ler +user whose job is being printed. If the message is an sheets. +internal CPS communication, then CPS processes it. Layup is invoked expl icitly with one or both +Otherwise, the message is e ither a program status of the extended qualifiers NUMBER_UP and LAYUP_ +message or a user data message. In either case it is DEFINITION. NUMBER_UP specifies the maximum +Jogged for the user. number of page images that will be printed on a + Al l messages are parsed except user data mes­ single side of a sheet; for example, two-up printing +sages. Messages from the printer's interpreter are is specified by the " NUMBER_UP = 2 " option. Two or +converted to a standard format that would, if four page images per side may save significant quan­ +desired, permit the message to be translated i n to ti ties of paper for draft printing, handouts, and the +the user's native language. l ik e . Up to 100 page i mages may be placed on a + + + +Digital Technical jounwl Vol. 3 No. 4 Fall 1991 51 + I mage Processing, Video Terminals, and Printer Tec hnologies + + + + +single sheet of paper for thumbnail d raft printing to PostScript environment, including the alt<.:rctl p:1ge +review the overal l l ayou t of a document. geometry, e.g., layup established by the print j o b . + Layup may also he invoked thro u gh a combina· CPS defines two n e w separa tor pages. T h e fi le +tion of PAGE_SIZE and SHEET _SIZE with NUMHER_UP. error page is print ed when a tile cannot be opcn�.:d +for example, the combination of PAGE_SIZE = E, o r an error occurs while r�.:ad ing the file. The file +SHEET_SIZE = A , NUMBER_UP= 1 perm i t s printing error page informs the usn of the error cond ition +draft cop ie s of large-format documents on small which caused i t to be print<.:d . The job log page con· +paper. Conversely, the combination of PAGE_ tains up to 40 l ines of the job log fi le. The job log file +SIZE =A,SHEET_SIZE = B,NU.\1 BER_U P= 1 magnifies the contains j o b events such as job start and job com· +smal ler page to tit the larger sheet. pletion as wel l as program status messages and user + data returned from the printer. +Duplex Printing +Pri n t i ng on both sides of the paper i ntroduces a Managing Printer Resources +numbcr of n e w options and interact ions that Once com mun ication is established with the +req u i re spe ci al processing in C P S . CPS begins each serial printer, the symbiont must esta blish what +document on the first siclc of a new sheet, so that resources are available on the printer. These +recto and vcrso (right-hand and left-hand) pages resources include prologues, which are comm only +and a lte rna t ing margins arc a l igned with the cor· used Post Scrip t rou t ines, the amount of available +rect sides of sheets as they arc stacked by the virtual memory, and the med ium in the default +prin ter. This function :1lso interacts with the d i r<.:c· paper tray. For example, CPS persistently loads the +tion in which the medium is physi cal ly loaded i nto PostScript prologue fo r the output of th e ANSI text +the printer if the medium is not symmetric left-to· translator into the PostScript interpreter. Th is +right, top- t o - bot t o m , or front· tO·back, such as pre· resou rce might be lost to the printer because of a +drilled paper. power fai l u re or might become obsolete clue to a + The interactions of POL coordinate systems, page software upgrade. CPS interrogates the pr i n t er at +layup, media selection, asymmetric media, duplex the beginning of any job req u i ring the translator +p ri nt i ng and binding are the most elusive engineer· + , prologue and loads a new prologue, if necessary. +ing problems in t h e printing :1 p pl ic a t i on space. No CPS also performs similar processing for the +gennal model of these interactions h as been devel· PostScript prologue that is used to generate the +oped, despi te considerable effort in standards com· separator pages. +mittees. I t appears that i t is necessaq• to implement For trad itional resources such as paper, CPS relies +every p oss i ble option. on status messages from the printer to indica te that + the pr i nte r is stopped because paper supply is +Separator Pages empty or j ammed. These condi tions are relayed to +CPS prints a l l the separator pages defined by th e + the operator and to the current user by s ta ndard + VMS mechanisms. +VMS queuing system as wel l as some generated by +CPS. Fl a g, burst, and trailer pages for j o b and file lev­ +els are ava i lable as defined by VMS, and contain Library Search Lists +the same informat ion presented in a hi gh l y lcgible I n the standard VMS print symbiont, only one +format. In addition to the standard V:'v!S infor· device control l i brary may be associated with a +mation, the j o b trai ler page also conta ins the first queue. This is not a probl.em since the standard VMS +two PostScript language errors returned from the print symbiont deals with only one data syn tax . +printer. This often makes it unnecessary tO use (Recall that clevice control l i braries are often writ· +M ESSAGES= PRJNT to see simple errors. ten in device-dependent data syn tax.) CPS, on the + To ensure that the job separator pages can always other hand , uses more than one data syntax when +be printed correctly, CPS r<.:s<.:ts the POL interpreter printing a non-PostScript job: the data stream to the +in the printer befor<.: printing these pages. The CPS· printer is PostScript, but the data stream ro tbe +generated scparator pages do not alter the coordi· translator is in another data syntax. +nate system of the interpreter; the user's document Early versions of symbionts that supported +starts printing with the default Pos t Script state. File PostScript su ffered from the same restriction: only +separator pag�.:s, in contrast, print in the current one device control l i brary was ava i lable, and i ts + + + + +52 Vol. 3 No. 4 Fall 1')')1 Digital Tecbnicaf jou ,..,w l + Design of the DECprint Common Printer Supervisorfor VMS Systems + + + +modules were expre�seu i n PostScript. This made i t on this article. F inal ly, we thank the many si tes and +impossible for users t o share device control p eople who have tested the DECprint Printing +l ibraries with their stand ard VMS print symbiont Services software. +ami their non-PostScript printers. + To solve the problem of multiple data �yntaxes References +in a job. CPS introduced device control l ibrary +search lists. The system manager, rather than speci­ 1 . VMS Utility Rou tines Manual (Maynard: D igital +fying a single file specifica t ion in the I N!TlALIZE/ Equipment Corpora tion, Order No. AA-LA67B-TE, +QUEUE/LIBRARY com mand. creates a logical name 1990). +instead . CPS transla tes that specific logical name 2. VMS DCL Dictionary, 2 vols. (Maynard: D igital +and uses each element of the resu lt as a device con­ Equipment Corporation, Order Nos. AA-PBK 5A-TE +trol l i brary. Each l ibrary in the search li st can have a and AA-PBK6A-TE, 1991 ). +data syntax associated with i t by adding the +qual ifier, /DATA_TYPE = . 3. Vil,.JS System Services Reference (Maynard: D igital + CPS suppl ies a device control l ibrary, Equipment Corporation, Order No. AA-LA69A-TE, +CPS$ DEVCTL, wh ich must be included in the search 1991 ). + l ist, usual l y as the first, or on ly, element in the 4. ]. Jones, A. Kachran i, and T. Powers, "The +search I ist. Common Printer Access Protocol," Digital + Technical journal, val. 3, no. 4 (Fall 1991 , this +Summary issue): 55-60. +The DECprint model of prin ting describes a useful + 5. B. Reid and C. Kent, "TCP/IP PrintServer Print +structure w i th consistent functions and responsi­ + Server Protocol," Western Research Lab Technical +bil ities. CPS is an advanced print symbiont that runs + Note TN-4 (Maynard: D igital Equ ipment +in the VMS printing system. I t includes many spe­ + Corporation, 1988). +cial ized functions to support the features of a wide +range of modern printing devices. It provides, we +feel, an extraordinary level of support. It was General References +designed with a highly modular and flex ible inter­ +nal structure to permi t enhancements to be engi­ Guide to Maintaining a VJ11S System (Maynard : +neered with minimal interactions with current D igital Equipment Corpora t ion, Order No. +operations. AA-LA34A-TE, 1990). + CPS is currently shipping its fourth version. Th is DECprint Printing Services User's Gu ide (Maynard: +version fu l ly supports the ten d ifferent PostScript D igital Equ ipment Corpora tion, Order No. +printers suppl ied by Digi tal. which range from a A A-PBZGA-TE, 1991) . +low-speed color printer to a h igh-speed laser +prin ter. It also supports five different data syntaxes DECprint Prin ting Services System !Hanager's +in which appl ications can wri te documents. We Guide (Maynard : Digital Equ ipment Corporation, +expect that more printers and more capabil i ties Order No. AA-PBZFA-TE, 1990). +will be added in future versions, and that CPS wil l Digital ANSI-Compliant Printing Protocol Level 3 +require a minimum o f add i tional engineering effort Programming Reference Manual (Maynard: D igital +due to its very general internal structure. Equipment Corporation, Order No. EK-PPLV3-PM, + 1991) . +Acknowledgments + Digital ANSI-Compliant Printing Protocol Level 3 +We would l ike to thank Peter Conkl i n for actively + Programming Supplement (Maynard: Digi tal +initiati ng CPS and Gary L. Brown for even more + Equipment Corpora tion, Order No. EK-PPLV3-PS, +actively expanding i t . We would also like to thank + 1991) . +past and cu rrent CPS developers: Ned Batchelder, +Cathy Cal lahan, Mark DeVries, Rich Emmel, Dave PostScript Translator's Reference Manualfor ReGIS +Gabbe, David Larrick, Klara Levin. Mary M arotta, and Tektronix 4010/4014 (Maynard: Digital +Doug Stcf:tnd l i , and Charlotte Tim lege. We would Equ ipment Corpora tion, Order No. AA-PBWFA-TE, +like to thank Bill Fisher fo r h is extensive com ments 1991) . + + + + +Digital Techuicaf ]ouruaf Vol. _; No. 4 Pall 1991 53 + Image Processing, Video Terminals, and Printer Technologies + + + + +PostScript Printers Programmer's Supplement +(Maynard : Digital Equipmen t Corpora tion, Order +No. EK-POSTP-PS, 1991 ). + +PostScript Language Reference Manual, 2nd ed . , +Adobe Systems Incorpora ted, ISBN 0-201-18127-4 +(Reading, MA: Addison-Wesley, 1990). + +Information Technology- Text and Office Sys­ +tems-Document Printing Application (DPA), +ISO/IEC JTC 1/SC 18 N, Draft International Standards +10175-1 and 10175-2 (September 1991 ) . + +CDA Base Services Technical Overview (Maynard : +Digital Equipment Corpora tion, Order No. +AA-PHJYA-TE, 1991 ). + +Creating Compound Documents Using CDA Base +Services (Maynard: Digital Equipment Corporation, +Order No. A A-PHK2A-TE, Il)89). + +Writing Converters Using CDA Base Services +(Maynard: D igital Equipment Corporation, Order +No. AA-PHK 1 A-TE, 1991 ). + +CDA Base Services Reference Manual, 2 vols. +(Maynard: Digital Equipment Corporation, Order +Nos. A A-PHJZA-TE and AA-PHKOA-TE, 1991). + +CDA: DDIF Technical Specification (Maynard : D igital +Equipment Corporation, Order No. A A-PHK3A-TE, +1991) . + +('DA: DTIF Technical Specification (Maynard: Digi tal +Equipment Corporation, Order :-.Jo. A A-PH K4A-TE, +1991 ). + +DDIS .�vn tax Spec�fication (Maynard: Digital +Equipment Corporation, Order No. EL-00081-00-1 , +1987). + + + + +54 Vol. .3 No. 4 Fa/1 1')91 Digital Tecbnical ]ournal + james D. jones + Ajay P. Kachrani + Thomas E. Powers + + + + +The Common Printer Access Protocol + The DEC PrintServer Supporting Host Software version 4.0 incotporates Digital's + first implementation of the new common printer access protocol (CPAP). This pro­ + tocol is compatible with the local area print server (LAPS) protocol, which was + optimized for VMS access and DECnet transport, and with tbe Reid-Kent proto­ + col, a PostScript-based, TCP/!P-connected print server for a client-server environ­ + ment. The CPAP protocol supports a variety of data presentation protocols + and allowsprinters to be connected to driving applications by various communica­ + tions and process-to-process intetfaces. Tbe protocol also couples entities running + different operating systems across disparate networks. Because of its superior + performance, the new CPAP protocol has been accepted by the Open Software + Fou ndation for inclusion in a future release of OSF/1. + + + +The presentation of computerized data has become cal prin ting device. The comm o n printer access +a remarkably sophisticated and subtle operation. p rotocol (CPAP) described in this paper provides +Video displays now support windows with com­ the fundamental services required by a printer +plex al locations of display space, variable fonts, and supervisor for the presentation of data and col lec­ +real-time user input operations. Printing devices tion of accounting information. In addition, the +now offer support for publication-quality fonts, CPAP supplies easier network access between +line art, and images. These devices can present printer supervisors and printers, as well as ancil­ +visual objects on a variety of media, from many lary control of p rinters for network management +sources, and in variable orientations and presenta­ and device configuration. The CPAP also provides +tion modes. In addition, both video and printing services to d istribute the processing requ irements +devices are now decoupled from dedicated com· of the printer i tself, most notably a mechanism for +puting environments, and are shareable from many del ivery of network fo nt services. This last capabil­ +hosts and by many users or programs. ity al lows a printer to offer what amounts to vir­ + Now, only the simplest printing devices are l im­ tual services, i .e . , the abi l i ty to configure i tself +i ted to presenting just characters, and many users dynamically to the demands of a print job without +are finding such restricted capabi l ities inadequate. the involvement of the printer supervisor. +Also, most printing devices still requ ire dedicated This paper begins with a discussion of the +connections to single computers. However, more influence of existing protocols and the DECprint +printers now offer fu ll network accessibil ity; i.e. , architecture on our CPAP design goals. The sections +network printers are capable of offering sophisti­ that fol low present the printer session concepts +cated services to a wide variety of users and their and the functional i nterface between the protocol +applications. and appl i cations. We then describe the implemen­ + The paper entitled " Design of the DECprint tation of the new protocol in a server environment, +Common Printer Sup ervisor for VMS Systems" including interoperabili ty, compatibility, and the +in this issue of the Digital Technical journal translation of the older PrintServer protocol. At the +describes access methods and interrelations close of the paper, we discuss ongoing standard­ +among services that provide for these increasingly ization issues. +sophisticated data presentation capabil i t ies. 1 The +printe r access protocol (PAP), a service interface in History +the DECprint arch itecture, couples the printer The PrintServer 40, D igital's first ful ly networked +supervisor component to the logical printer for pri nter, was first shipped in 1986. Its local area print +presenting data and otherwise controlling a physi- server (LAPS) protocol was analogous to later + + + +Digital Technical journal Vol. 3 No. 4 Fa/1 1991 55 + Image Processing, Video Terminals, and Printer Technologies + + + + +printer access protocols. The PrintServer 40 was a problem was a major conceptual test in the first +ground-breaking p roduct for D igital, and the LAPS implementation of a CPAP server. Th is is discussed +protocol was a major aspect of the PrintServer in more detail in the sect ion The CPAP Server +development effort, portions of which date back to Implementation. +198:1 . The LAPS protocol was designed and devel­ The Reid-Kent protocol met many of the techn i­ +oped with particular product-oriented deliverables cal design requirements for a new PAP . It was built +in mind, and was optimized for VMS access and on industry-standard components, and contained +DECnet transport. While this protocol predates no proprietary technology that wou ld prevent its +much of the architectural work now being imple­ publication. +mented in Digital's printing products, it was (and However, certain PAP design goals were not cov­ +still is) a signi.ficant element of PrintServer archi­ ered by the Reid-Kent protocol in its 1988 version. +tecture and implementation. • There was no faci l i t y to select a specific page + Work began on more general PAPs in 1987 as + description language (PDL) for printers support­ +part of the early work on the D ECprint archi tec­ + ing multiple interpreters. +ture (known at the time as the Printing Systems +Model). The specifics of what would become the • There was no method for soliciting the capabi l i­ +CPAP emerged in late 1988 in two internal papers ties and media available on the printer. +by Brian Reid and Chris Kent of Digi tal's Western • The only language supported was English +Research Laboratory. These papers presented the (contrary to the corporate guidelines for +initial design concepts for a PostScript-based , international ization). +TCP/IP-connected (transmission control protocol/ + • Data sent from the printer was not ca tegorized ; +internet protocol) print server in a clearly defined + user-specific information was mixed with opera­ +c l ient-server environment. This print server proto­ + tor and service data. +col came to be known as the Reid-Kent protoco l. + • No means was provided to solicit the status of + the printer. +Design Rationale and Goals +By early 1988, design goals for (and constraints on) a • There was no encoding to discriminate between +PAP were wel l u nderstood, and had been col lected binary and text files. +and publ ished as part of Digi t a l 's Printing Systems However, these flaws were largely omiSSIOns +Model. Chief among these goals and constraints was from the design goals, not fundamental conflicts +the need to support a variety of data presentation with them. The archi tecture team decided that the +protocols, and to al low printers to be connected to Reid-Kent protocol could be extended to add ress +driving appl ications by a variet y of com mu nica­ these omissions without serious conflict. I n fact, +tions and process-to-process interfaces. the necessary extensions were designed to al low + The i ncreasing corporate comm i t ment to open cl ients and servers conforming to the original Reid­ +systems made i t clear that a PAP would also have to Kent protocol to remain in conformity with the fu l l +couple entities runn ing various operating systems C:PAP specification. +across different networks. Thus, the DF.Cprint PAP +architecture team decided early in the design pro­ Architecture +cess that a PAP should be designed for public The CPAP is primarily a com m u n ication-orien ted +access: that is, t he specification for the protocol protocol, i.e. , the presentation of its function is +should be put into the public domain and submit­ closely coupled with its encoding. The major syn­ +ted for industry standardization. tactic fea tures of the < : PAP derived from the Reid­ + Jnteroperability is a most serious constraint. Kent protocol are the fol lowing. +Digi tal has a strong tradition of maintaining back­ + • All encoclings are ASCII strings. This eases the +ward compatibility within and among its product + generation of protocol streams and ensures inde­ +fam i l ies. I n a distributed processing environment, + pendence from the u nderlying comm u n ications +however, backward compatibil i t y takes on the + channels. +added burden of i nteroperabil i t y. Mult iple clients +must com m unicate with mult iple servers. any of • No data fields are fixed length. This provides for +which can be u pgraded to new versions of sup­ extensibi l i ty of the protocol and eases the gener­ +ported pwtocols asynchronously. Addressing this ation of a protocol stream . + + + +56 Vol. 3 No. 4 Fall I'J'J/ Digital Technical journal + The Common Printer Access Protocol + + + +• Multiple channels of communication use the will use for each document and which virtual cir­ + same basic format. Common parsing of separate cuit will be used for its transmission. + channels simplifies implementations. Selection of the proper virtual circuit for trans­ + m ission of documents to the printer is performed +• Simple numeric tokens define the operators. + by passing tokens from the printer to the printing + service. The tokens are then mapped to whichever +Session Concepts v irtual-circuit service is being used by both the +The CPAP architectu re defines separate contexts for printing service and the print server. This map­ +each type of work the CPAP can perform. Each con­ ping approach avoids passing network-specific +text requires that a separate session be established information within the protocol. Not only does the +for its own tasks, and each session involves the cre­ approach make the CPAP independent of the net­ +a tion and use of a separate network connection works on which i t might run, it ensures that the +between the controll ing cl ient and the server. Each network services need no knowledge of CPAP +connection identifies the type of session the initia­ encodings. Such v irtual-circuit m apping is criti­ +tor requires. The CPAP defines three d ifferent ses­ cal to allow CPAP cl ient-server processing to be +sion types: print, management, and console. implemented in a heterogeneous, internetworking + The set of CPAP operators al lowed for a session is environment. +restricted to those needed to support that type of During the printing of the document, some data +session. All session types have access to printer presentation interpreters (PostScript, for example) +status and configuration information. In addi tion, send data back to the user or print service. In addi­ +mu ltiple concurrent sessions are permitted. Print tion, the printer may run out of paper or toner, +sessions and management sessions may have one or may have a ful l output tray, or may encounter other +more virtual circu its active to a printer at a time. exception conditions not directly related to the +The use of mu ltiple circu its permits the streaming interpretation of page description data. The CPAP +of data to the printer over logically separate chan­ categorizes such conditions and delivers relevant +nels, thereby eliminating application protocol over­ messages to the user, the operator, or the event logs. +head for the most frequent operations. In contrast, Upon completion of the job, the printing service +console sessions use a single virtual circui t for is notified of the media used , the number of pages +exchange of data with remote terminals. printed, and the printer processing time requi red + to complete the job. The protocol also includes a +Print Sessions Print sessions usually consist of a provision to abort jobs, e.g., an improperly formed +series of documents printed for a user on a given document that might otherwise hang the printer. +host by a printing service (a "printer supervisor" +as defined by the DECprint architecture). With the Management Sessions The CPAP supports certain +operators provided by the CPAP, the printing ser­ printer services through management hosts. A man­ +vice can determine the language interpreters, agement host is a network entity (not necessarily +printer options, fonts, prologues, and media that the same entity as the printing service) with which +are currently instal led at the server. These opera­ the printer can exchange i nformation or request +tors also provide the current operational state, services. Such services include +number of jobs queued to the printer, and the cur­ + • Time service +rent job status. These features permit the printing +service to select the printer (server) that can satisfy • Centralized event logging +the user's request and to determine a method for + • Centralized accounting +submitting the job to the printer. + Once the printing service has begun a session • Program loading and configuration +and identified itself, it identifies the user and the + • Font services +user's job code to the printer. This information may +be used by the printer to provide usage information An important aspect of the CPAP is that the +to a centralized accounting service. The printing printer is always passive with regard to initiating +service can then present documents to the printer. management services. A cand idate management +A transaction between the printing service and the host advertises that it has services to offer, and a +printer establ ishes which interpreter the printer print server accepts or rejects the offer. Once a + + + + +Digital Tecbnicaljourual Vol. 3 No. 4 Fall 1')91 57 + Image Processing, Video Terminals, and Printer Tech nologies + + + + +connection with one or more management hosts programm ing interface (API) that a i i O\:vs access to +is established, the printer may use such hosts as all CPAP facil ities is included in the protocol's +servers for time synchronization, configuration file specification. +access, and font lookup. Additional functions for A connection block, which is passed as a parame­ +these hosts may be loading program images, event ter to all functions, provides support for vari­ +logging, accounting, and general file access. ous printer types, their device identifications, and + File naming to access general file services is a descriptors for command and data channels. This +problem that needs special attention if the server support includes separate com mand and data +and the protocol are to maintain independence channels for printers supporting mu ltiple virtual +from the host operating systems. Commonly used circuits or channels. Just as in the case of the data­ +files a n: identified in the CPAP by reserved tokens, stream form of the protocol, the API form allows +such as $CONFIG, $ DEFAULTS, $ RESOURCES, and separate channels for data and comm ands. +$SETUP. Arbitrary path names are allowed, but can A separate command channel allows ease of con­ +access only a limi ted domain (from a known root trol flow between client and server. This may +directory) to preserve file system independence include the client receiving the server's status or +and to maintain security. events, or the cl ient sending aborts to the server. + Translation to the host's services is provided For devices that support only a single channel, the +by the host i tself. This permits the printer to be generic printer driver can set both command and +served by d ifferent hosts using a wide variety of data channels to the same valu e . For supporting +operating systems (and their implicitly different mu ltiple jobs active at the same time (job overlap), +file-naming conventions and syntaxes) without any a job identification (ID) parameter is passed with +awareness of a management host's implementation all functions. +by the server. To support various message types, the address + of a read-ca l l back routine is passed to the open +Console Sessions A console session is a form of printer function along with a pointer to read-cal l­ +printer management. The content of the data back arguments. These arguments may signal vari­ +exchanged du ring a console session is specific to ous events, or may consist of messages for the user, +the printer, and is not specified by the CPAP. operator, accounting, or resources available in the +Services performed within a console session might printer. +include An early version of the generic fu nctional inter­ + face was part of MIT Project Athena's Pallad i u m +• Operator services, such as tel ling a printer what + Print System. The printer supervisor in D igita l 's + media have been loaded (e.g., by color, weight, + LN03R ScriptPrinter product was modified to cre­ + or transparency), or sett ing physical printer + a te a generic printer i n terface for both the + defaults (e.g. , duplex versus si mplex, or default + ScriptPrinter device and the PrintServn fam i ly. + medium selection) + This conversion from an API-accessible base took +• Network management configuration services, one week to execute, whereas it typically takes + such as control I ing domain access to or from six months of effort to develop a new printer + the printer supervisor for a device as complex as the + PrintServer product. +• Troubleshooting or debugging services + + D igital's implementation of console services on The CPAP Se rver Implementation +cu rrent PrintServer products conforms to the The implementation of a protocol gives rise to +Enterprise Management Architecture. problems different from those related to its design. + When defining the archi tecture, one strives to pro­ +Application Program Interface vide an ideal that includes all of the desired features +The fu nctional interface to any protocoJ provides in an elegant manner. When performing an imple­ +an additional abstraction between an application mentation, one finds that elegance often has to take +and a protocol. This abstraction answers many of a back seat to pragmatics. This is especially true + +today's software appl ication needs, including inter­ when the new protocol is intended to replace two +operability, portability. modu larity, and reusabil­ different protocols in a new version of an existing +ity across mu ltiple architectures. An applica tion product. Merely implementing the new protocol + + + +58 V!J!. 3 No. 4 Fall 1991 Digital Tee/mica/ journal + The Common Printer Access Protocol + + + +is not enough-the implementation must some­ biont (CPS), several versions of the U LTRIX oper­ +how coexist with the protocols being replaced. ating system, and a source kit version running on + D igital's first production implementation of the a Sun Microsystems workstation. +CPAP was targeted for the DEC PrintServer Sup­ Unfortunately, this testing uncovered latent +porting Host software version 4.0, which loads and defects in the implementation of the existing prod­ +drives the PrintServer fam i ly of printers. For the ucts. We had to analyze each of these defects and +rest of this paper, we refer to this software by the plan corrective action. Since updating the existing +PrintServer product designation of LPS version 4.0. products in the field is a difficult process (both + We started the implementation by modifying technically and procedurally), we corrected most +D igital's ULTRJX PrintServer client, which already of the defects by altering the server to deal with the +used the Reid-Kent subset of the CPAP, to use problems. Retesting was performed over several +DECnet network transport and run on the VMS oper­ baselevels to ensure that our changes caused no +ating system. We then updated the LPS server regression. +code to permit ei ther DECnet or TCP/IP transport. At one of the early baselevels, the interface +This was accomplished by using the direct -to-port between the network distribution software and the +communication features of the VAXELN operating server's PostScript interpreter was updated to use a +system. The server establ ishes a circui t u sing the stream-based connection in place of the previous +appropriate transport and then spawns a process packet protocol. This update permitted the new +for deal ing with each incoming connection. Thus, CPAP data channel to be mapped by reference to +the same code can service print sessions, manage­ the input of the PostScript POL or any other POL +ment sessions, and console sessions without con­ supported by the printer. This change alone per­ +cern for the type of network transport. mitted the performance of the server to be main­ + The CPAP was, by design, directly upward­ tained even when the server was translating from +compatible with the Reid-Kent protocol subset. the old LAPS protocol to the CPAP. +However, D igital's PrintServer offerings prior to In general, development proceeded incremen­ +LPS version 4.0 were LAPS-based, and LAPS was not tal ly, i . e . , key features were identified and added +CPAP-compatible. To permi t users of existing with each baselevel. While this technique limits the +PrintServer printers to continue to use these complexity of prod ucing the product, it raises an + products, we had to find a way for the new CPAP important business issue. Specifically, the provi­ + implementation to coexist with the older LAPS sion of enhanced services in a cl ient-server envi­ +application protocol. We achieved this coexistence ronment often exposes aspects of the proverbial +by having the server p erform translations from the " chicken-and-egg" situation. There is l ittle call to +older protocol to the new one in the server i tself. offer enhanced features in a server if clients have +When the client establishes the initial connection, not been programmed to solicit the features. How­ +the server senses which protocol is being used by ever, cl ients are not readily upgraded to solicit +the client system. If the initial message indicates features that might not be widely available. +the use of LAPS, the server spawns i ncoming and The LPS version 4.0 project team met i ts backward +outgoing filters to deal with the incoming connec­ compatibility design goals by including the LAPS-to­ + tion, and a new internal circu i t replaces the CPAP filters. In doing so, they undercut the need +network connection to handle the interpretation to provide the enhanced feature support that the +of the CPAP. CPAP was designed to deliver, since existing cl ients + The coding of the LAPS filters was the last step (earlier versions) coul d not avail themselves of +in implementation before testing began. The the added features. In addition, the risks of includ­ +PrintServer 20, PrintServer 40, PrintServer 40 plus, ing fu l l CPAP support in LPS version 4.0 (possible +and the new turbo PrintServer 20 all had to be increase in time to market, and the creation or expo­ + tested using both LAPS and the Reid-Kent subset of sure of more latent defects in all supported environ­ + the CPAP. In addition, the new implementations of ments) seemed to outweigh the benefits. However, +the management cl ient and the console cl ient on a last-minute change to use the new protocol's data +the VMS system requi red verification. This verifi­ channel for loading fonts yielded such a large per­ +cation entailed a mu ltitude of tests using the LPS formance advantage that resistance to using the +symbiont running on older versions of the VMS new features crumbled , and the project team was +operating system, the newer common print sym- allowed to submit the fu ll protocol to field test. + + + +Digital Technical journal Vol. 3 No. 4 Fall 1991 59 + Image Processing, Video Te rminals, and Printer Tech nologies + + + + +Standardization architecture and created the first prototype imple­ +Network printing became widely available i n the mentations. Jim jones championed the proto­ + mid-1980s, but products from different vendors col in the DECprint PAP archjtecture team (Alan +were not compatible. Network printing protocols G uenther, Tom Hastings, Jim Jones, Tom Powers, +were largely proprietary efforts by vendors who and Eric Rosen) and coded the LPS version 4.0 +had developed them for their own printer prod­ server. Carol Gal lagher wrote the LAPS fi lters to +ucts. Digi tal's PrintServer 40 and i ts LAPS protocol translate from the old protocol to the new. M ike +were typical in this rega rd . By the late 1980s, Augeri and John McLain ported the management + network printing was an establ ished and competi­ and console clients to the VMS system from the +tive technology, but there was still l i ttle i nter­ U LTRI X system . ]. K. Martin rewrote the Berkeley +operabil ity among the various vendors' p roducb. Software Development (BSD) sou rce kit to use the + In the absence of printing protocol standards, the new protocol. Ajay Kachrani developed our ULTRIX +Internet Engineering Task Force (I ETF) formed a and M IT Athena clients and represented the proto­ +Network Printing Protocol working group in col d uring early phases of the IETF standardization +early 1990. This group's charter was to examine effort. Many others supported these efforts, and +prin ting protocols then in existence or u nder devel­ others are yet beginning to develop new CPAP +opment, assess their appl icabi l i ty to Internet-wide clients. We thank them all for their efforts. +use, and suggest cha nges. Digital's representatives +to the I ETF working group on the Palladium Reference +Printing Systems standardiza t ion reported the inter­ + 1 . R. Landau and A. Gu enther, " Design of the +est shown in D igital's Reid-Kent protocol. Thus, in + DECprint Common Printer Supervisor for V M S +July of 1990, Digital submitted a version of the PAP + Systems," Digital Technicaljournal, vol. 3, no. 4 +that was u nder consideration by the DECprint PAP + (Fall 1991 , this issue): 43- 54. +archi tecture team. + Early consideration of this PAP by IETF and the +LPS version 4.0 implemen tation effort ran concur­ +rently. This provided a unique opportunity for +Digi tal's implementers to obtain feedback from a +very knowledgeable architectural communi ty. In +turn, they could report implementation experi­ +ences that affected the review and progress of the +specifi cation towards standardization. Implemen­ +ta tions of CPAP clients and servers by companies +other than Digital are in progress. + As part of Project Athena's Palladium Printing +System, the CPAP has been accepted by the Open +Software Foundation for inclusion in a future +release of OSF/ 1 . + A draft of the CPAl' i s being circulated among +Internet members for com ment. Meanwh ile, work +on future enhancements cont inues. Wo rk is now in +progress to specify a superset of the existing pro­ +tocol that deals with a u thentication and encryp­ +tion to strengthen security. This work is being +done in the spirit of the original migration from the +Reid-Kent protocol to the CPAP; i.e., the security +features being added will not adversely impact +users who do not need the new features. + +Acknowledgments +The CPAP effort has been the work of many devel­ +opers. Chris Kent and Brian Reid drafted the base + + + +60 VIii. 3 No. 4 Fall 1991 Digitttl Technical journal + Guido Sim one + jeffre y A. Metzg er + Gary Vaillette + + + + +Design of the Turbo +PrintServer 20 Controller + + The turbo PrintServer 20 controller is a pe1formance enhancement of the original + PrintServer 20 system controlle�: The turbo controller was developed to enable + PostScript code to execute faster and thus improve page throughput for complex + documents. The RETrACE analysis system was designed to analyze tbe pei formance + of the original PrintServer 20 system and estimate expected performance future + systems. Tbe turbo controller's processor and its three subsystems for memory, + write buffer; and bit-map data transfer were selected based on the analysis results. + Performance tests conducted on both the original and the turbo PrintServer 20 + indicate the enhanced processing performance of the turbo controller. + + + +In 1988 the turbo controller project was conceived We were to use existing, qualified chips wherever +as a means of extending the l ife of the PrintServer 20 possible in order to avoid new part qualification +platform by introducing a performance-enhanced costs and appl ication-specific integrated circui t +system controller. The system control ler in the (ASIC) development costs. +PrintServer 20 is housed within and powered by Early investigations indicated that the p erfor­ +the printer or "print engine"; it is a concise i mple­ mance target was indeed achievable with existing +mentation of a single-board computer containing a inexpensive ruse processors, as well as a high­ +CPU, a memory subsystem, an Ethernet interface, speed Digital proprietary VAX processor. A ruse +and a printer interface. It suppl ies an environment processor would require porting a 2 . 5 -megabyte +in which a multi tasking software system manages (MB) software system, wh ich was far beyond the +communications with remote cl ients and with the scope of the project. The highest performance +print engine, performs data conversion from the VAX processor and the associated support chips, +page description language (PostScript) to bi t-map which would not cause a problem with the soft­ +images, and provides management of physical print ware system, were far too expensive to be consid­ +engine resources. ered. Alternatives were therefore limited to less + The original controller provided a maximum expensive, lower speed VAX processors: the low­ +print speed of 20 pages per minute, but this perfor­ risk, 60-nanosecond (ns) CMOS VAX or CVAX pro­ +mance could not be maintained when the docu­ cessor was proven, ancl the higher speed and more +ment included complex text, graphics, or images. To cost-effective "system on a chip " or SOC processor +i mprove page throughput for complex docu ments, was u nder development. Ei ther choice would have +a controller was needed on which PostScript code a minimal impact on the software system and +could execute faster. To enhance performance, the would provide a cost-effective solution. +competi tion was moving toward control lers based The original performance estimates for the CVAX +on new industry-standard reduced instruction set and the soc processors in general-purpose process­ +computer (RISC) processors. Therefore, to be com­ i ng environments were below the lower bound of +petitive, Digital's new controller was required to the performance target. The design team was also +improve performance by five to eight times that of uncertain of the actual execution characteristics of +the original control ler, which hacl been based on the PrintServer software. For these reasons, it was +the rtVA.,'C m icroprocessor. decided to begin the project wi th a performance + As challenging as the performance improve­ analysis of the origi n a l control ler to determine the +ment would be to achieve, budgetary pressures expected performance of a design based on either +forced restrictions on the implementation strategy. processor. + + + +Digitttl Teclmicaljourmrl Vol. 3 No. 4 Fall /991 61 + I mage Process ing, Video Te rminals, and Printer Technologies + + + + + This paper discusses the problems encou ntered The RETrACE hardware consists of the following: +t.l uring our analysis and the solutions d<:vised by the + • Two ime rco nnect boards boot and operate a +Hart.lcopy Systems Engineering Group to overcome + system control ler on a table top. Developed as +them. The RETrACE tool suite, a performance ana ly­ + part of the original PrintServer 20, the boards +sis system, is described and the analysis resu lts are + connect the controiJer to a prin t engine and an +provided. The paper then discusses the hart.lware + Ethernet. +architecture of the turbo control ler and ends with a +presentation of the performance resu lts obtai ned • The PrintServer 20 server controller was modi­ +for standard PostScript benchmarks. fied for use as an intell igent trace bu ffe r system. + + • The PrintServer 20 server control ler's memory +Performance Analysis of the Original capacity (12MB) was extended using the standard +Controller 4MB memory module used on the Kanji version +The Pri ntServcr 20 software system consists of a of the PrintServer 20. + VA-'\ ELN opera ting system, an Adobe Systems, Inc. + PostScript interpreter, and a substantial amount of • The RETrAC E mother board was developed specif­ +software to manage communications and resources. ically for this tool su i te. I t contains a 32-bi t wide, +The task of analyzi ng its performance was compli­ first- i n , first-out (Fi fO) buffer a nd two loosely +cated by two additional factors. First, the software coupled state machines. +system's behavior depended on the characteristics • A standard PrintServer 20 system controller and +of the user's PostScript document. PostScript is print engine were used as the "system u nder +an interpreted program m ing language. Thus, like observation." +any computer program, low-level machine perfor­ +mance can be dramatically affected by the program • The console terminal was selected from the stan­ +being executed . Second, ami more painfu l , the dard VT series of term inals. +proprietary nature of the PostScript interpreter A diagram of the RETrACE hardware system is +prohibited us from obtaining code sources, and d is­ shown in Figure 1. +cussing its i nternal architecture with engineers The RETrACE mother board performed the data +from Adobe Systems. capture, using the modi.fi ed control ler's memory as + While the characterization of a complex, par­ a la rge bu ffer. The board m o n i tored the processor +tially proprietary, real -time software system is bus of the system under observation by copying +difficult, it is not impossible. Programmer cou nter al I addresses and com m u n ications between the +address (PC) traces have offered many systems r tVA-'\ processor and its external floating-point +designers very detai led insight i nto the execution unit. This copied data was placed into a FIFO bu ffer +performance and characteristics of systems. PC that in turn was writ ten into the memory of the +traces provide a means to observe a system at a mod ified controll er using a direct memory access +macroscopic level, allowing a view of the complex (Oi'vlA) device. Since a standard PrimServcr 20 con­ +i n teractions between the hardware a nd software tro l ler and its optional memory expansion provide +systems. System designers can use captured address 16.VIB of storage, approximately 3 seconds of real­ +trace; from current machine performance to extra­ time execution address traces cou ld be caprured. +polate expected performance of future systems and The data capture continued until the trace bu ffer +help them make architectural trade-offs. memory was exhausted , at which point the data + was uploaded over a network connection to a VAX +The RETrACE Analysis System VMS computer for analysis. +The HETrACE tool suite was created to provide Due to the design of the original PrintServer 20 +a nonintrusive means of capturing real-time PC system, many large data areas and code sections +traces and ana lyzing the captured addresses. The were mapped into different explicit memory spaces. +tool su ite consists of both hardware and software This subdivision provided a means of determining +components. which code function was executing in any given + In order to keep expenses at a minimum, existing segment of the add ress trace. With a simple statisti­ +hardware was used wherever possible. Only one cal study it was possible to generate software exe­ +small module had to be developed to complete the cution histograms and to determine many of the +RETrACE hardware platform. characteristics of the system, including translation + + + +62 Vr>l. 3 No. 4 Fall 1991 D igital Technical journal + Design of the Turbo PrintServer 20 Controller + + + + RETRACE + CONSOLE + TERMINAL + + + + + PRINTSERVER 20 + SYSTEM + CONTROLLER + + SYSTEM UNDER + OBSERVATION + + + Figure 1 RETrACE Analysis System Hardware + + +buffer, floating point, instruction stream (!-stream) fou nd , then a m iss was signaled and the simula tor +versus data stream (D-stream), read versus write, would proceed to the next level of memory in the +and interrupt performance. Hit rates for fu l ly asso­ hierarchy. +ciative caches of separate !-stream and D-stream, Whenever a hit occurred at a given level, it +as wel l as a combined I- and D-stream cache, were was logged and all levels of memory in the hier­ +also provided. These hit rates were determined for archy above it would al locate entries based on +first-level wri te- through caches from 128 bytes up their defined al location rules. While this procedure +to 256 kilobytes (KB). Thus an upper bound for an indicated the memory system performance for +optimum-perform ance cached memory system a p roposed architecture, the overall system per­ +was determined. formance was still u nknown . Using a simple rule + Both processors under consideration possessed based o n the average execution time per address +the abi l i ty to access a memory subsystem at speeds for the existing control ler, and scaling that time +greater than that achievable with existing low-cost based on the clock speed increase of proposed pro­ +dynamic random-access memory (DRAM) technol­ cessors, an overa l l performance number was esti­ +ogy. The performance nu mbers predicted by the ma ted for a system based on either processor with +processor groups indicated that cached memory any arbitrary memory architecture. +subsystems were required. Because these sub­ +systems can be expensive and their performance is Benchmark Selection +subject to the pecul iari t ies of the software that The RETrACE tools sui te provided the components +executes on them, a m u ltilevel memory simulator required to study the execution characteristics of +was developed to al low accurate studies to be per­ the PrintServer system without changing the char­ +formed on proposed cache architectures. acteristics of i ts normal operation. The only diffi­ + The simulator was configured at ru n-time to sim­ culty was to narrow the focus of the benchmark l ist +ulate an arbitrary hierarchical memory system that to provide a representative sample of PostScript +was N levels deep, with an arbitrary size, associa­ documents to print. Due to time constraints, the +tivity, performance, and behavior at each level. list was l i m i ted to five benchmarks. +The memory level nearest the processor was +defined as the first level, and the l as t as m a i n mem­ BM1 The BM 1 benchmark stresses those aspects of +ory. The simu lator processed a trace file by wa lk­ the system that convert the mathematical represen­ +ing each address in the file through the memory tations of characters to bit-map representations, +hierarchy starting nearest the processor a t the first wh ich comprise the form that is printed. This +level. If a copy of the address was found at a given benchmark uses several fonts in standard character +memory level, then a hit was signaled and the next orienta tions, stressing both very large and small +address was processed. If that address was not character sizes. + + + +Digital Tecbnicaljour11al Vol. 3 No. 4 Fall 1991 63 + Image Processing, Video Terminals, and Printer Tech nologies + + + + +R.\12 Of the same type as B.\1 1 , this benchmark the overa l l h i t rate to approxim ately 81 to 84 per­ +stn::sses the transforms from ma thematical to hit­ cent. As the ana lysis of the data progressed, i t was +mapped character representa tions; howcvt.:r, the understood that the write data must be studied +characters printed are at arbitrary orie nt ations very closely since it cou ld have a dramatic i mpact +with sizes ranging from typical to very small. on the overal l cache miss rate. Du ring the cache + model simula tions, the hit rates of the 1-stream +BM3 The B�1.1 benchmark is one of the standard were between 85 to 90 percent. However, the +benchmarks for PostScript performance qua l i fica­ D-stream h i t rates were between 35 to 45 percent, +tion. I t is a simpk: 41-page document that contains with writes accou n ting for 60 to 90 percen t of the +st.: veral different fonts. The benchmark is designed tota l D-stream misses. To achieve the greatest posi­ +to characterize the standard text-hand l ing per­ tive effect on the h i t rate of the system, enhance­ +formance of a printer. This benchmark is printed ment of write-miss performance was the most +n.vice to ensure that a l l characters to be primed advantageous. The two options to improve this per­ +have been converted from ma thematical ou tl ines formann: were either to implement a wri te-back +to bi t-map representations of the characters. Thus cache or to add a write buffe r to the system. Further +the focus of the benchmark is to move the text cache simu la tions showed that a write buffer wou ld +data through the system, to copy the character bit provide an 8 to 16 percent overa l l system perfor­ +maps to the 1 MB region in memory that conta ins mance improve ment, which was equal to t h a t of a +the image to be printed , and to print the image. I t write-back cache. The wri te bu ffe r, however, was +should b e noted that this is t h e only benchmark the more stra igh tforward solution to implement. +that printed at engine speed on the Prin tScrver 20 Cache analys is revealed that the processors +system controller powered by the rtVAX system. required different memory archi tectures. The CVA.X + had an internal l KB, two-way set associative cache. +HOUSE A binary image file, the HOUSE bench mark This was to be configured as a mixed 1- and D-stream +was used to stress the com munications aspects of cache. An addi tionai 32KH ro 64KB, two-cycle wri te­ +the PrintServcr system. through cache was to be added exte rnal ly. This + wou ld also be configured as a mixed I- and D-stream +SCHEll'! The SCHEM benchmark was a vector repre­ cache. A si ngl.e- longword, two-cycle wri te buffer +sentation of a logic schematic. This benchmark was would provide enough buffering to reduce the +used to stress the PostScript interpreter's ability to drama tic impact of write misses. The soc was +interpret nonnative PostScript code and to exh ibit proposed to have an internal write-back cache +the characteristics of drawing vectors. between 5 KB and 8KB, with each l KB region mak­ + ing up a single set. Cache simu l a tions indicated +Analysis Results that with a minimum internal mixed 1- and 0-stream +The thrust of the analysis was to provide credible cache of 5KB, five-way set associative, an externa l +evidence to support architectu ral and imp lemen­ data cache would have to be over 64KB to have even +tation trade-offs. The major areas of focus were a negligible effect on ovnal l system performa nce. + Therefore no external cache was recom mended. To +• Mem ory system organization + mi tigate the write-miss penalty, a two-cycle write +• Printer in tnface performance buffer of 4 to 6 longwords was reco mmended. + As an accelera tion technique, the original +• Main memory bandwidth + PrintServer 20 control ler contai ned a memory +• Overa l l system performance access capability that a l lowed data written to mem­ + ory to be logical.ly ORed with data that was al ready +Memory Syste-m Organization The statistical anal­ stored. This technique was particularly useful when +ysis of the trace information provided many clues the software system was wri ting the image that was +to direct our investiga tion toward the optimum u ltimately printed. As part of the process of gener­ +mcmorv system archi tecture. The overa ll read-to­ ating an image to print, the individual characters +write ratio for the observed benchmarks ranged appearing on a page must be copied from a region +from as low as 4 . 5 : 1 up to '5.'5: 1 , which me:1ns for of memory ca l led the font cache to another region +a wri te-through cache system with a theoretical cal led the frame bu ffe r. The frame buffer contains +100 percent read h i t rate, the writes would degrade the actual data that is sent to the print engi ne. + + + +64 Vol. 3 No. 4 Fall I')<)I Digital Technical ]ourual + Design of the Turbo PrintServer 20 Controller + + + +To complicate things, the data written to the frame Overall System Performance The execution char­ +buffer must be able to overlay data that may al ready acteristics of the original PrintServer 20 provided +be there, thus requi ring a logical OR function. some interesting surprises. Most floating-point + When a document was printing at or near the calculations were performed in double precision; +maxim u m engine speed of 20 pages per m inute, and even more interesting, for each floating-point +analysis showed this low-level copying function operation, there was a floating-point conversion +consumed approximately 20 p ercent of the total from si ngle to double precision, and then back +system time al lotted to generate and print one page. aga i n . Since the precise operations were not +Thus a logical OR fu nction i n the memory system requ i red, a simple compi ler switch removed the +would reduce the number of memory data cycles conversions and provided a 3 percent overa l l sys­ +from "2 reads 1 write" to " 1 read 1 write," and tem p erformance improvement for floating-point­ +reduce the impact from a second read occupying a intensive PostScript documents. A second su rprise +useful cache l ocation. Without this capabil i ty, the came from the resu lts of the BM3 benchmark, +degrada tion would be between 5 and 10 percent of which indicated a translation bu ffer hit rate of +overal l system performance when printing at or 85 percent. At the time of the discovery, the +near 20 pages per m inute. Therefore memory capa­ PrintServer 20 was configured with a standard +bil i ty with a logical OR function was recommended. M ic roVA..'( processor ; however, by substituting an + rtVAX, which uses one less memory access to refer­ +Printer interface Performance When a PrintServer ence its page tables, an 1 1 percent system per­ +20 is printing, every page that ex i ts the printer formance improvement was achieved. With this +requi res the 1 MB frame bu ffer to be copied from i mprovement, the rtVA.c'C processor provided +memory to the print engine interface. Changing a enough power to al low the original PrintServer 20 +program-controlled p ri n ter interface to one d riven to ship with its 20-page-per-minute designation. +by a DMA device provided two significant advan­ This information led the turbo contro l ler designers +tages. The first was to reduce the rea l- time requ i re­ to determine that the transla tion buffer of the SOC +ments on the PrintServer software system, and the would be large enough for a l l the entries requ ired . +second was to a l l ow for a l i m i tecl degree of paral­ +lelism on the controller. The para l lel ism was due to Results +the abil ity of the processor to co ntinue to execute + The final analysis revealed that the expected perfor­ +from i ts cache memory system while the DMA + mance of a CVAX or SOC processor wou ld place +device accessed memory. The processor only stops + either design on the low side of the p e rformance +executing when a cache m iss occurs. + requi rement. Therefore close attention to detail + would be requ i red d ur ing the implementation +Main Memory Bandwidth With a CVAX processor + phase of the project as every ounce of performance +configured as recommended in the section Memory + m a t tered . The expectation was to have a choice +System Organization, the main memory system + between an SOC processor with a 40-ns cycle time +bandwidth requ irement of the processor was + and a CVAX processor with a 60-ns cycle time. The +60 percent. For the soc , it was 70 p ercent when + performance i mprovements of the two processors +an existing DRAl\1 contro l ler was used. A Dl\'lA­ + are compared in Table 1 . +driven printer interface requi red 15 percent, and +an Ethernet interface required nom inal ly 4 percent +with bu rsts up to 20 p ercent. Each subsystem was Table 1 Performa nce I m prove ment Relat ive +scrutinized to reduce its required memory band­ to Original Pri ntServer 20 Contro l ler +width. The resulting recommendation was to add a +32-bit bus to the memory subsystem to provide a soc CVAX + Be nchmark Processor Processor +dedica ted channel for a l l data being sent to the +printer interface. This provision would reduce 8M1 4.7 3.7 +required memory bandwidth for the printer inter­ 8M2 4.9 4.0 +face from 15 percent to about 7 percent. The sys­ 8M3 4.3 3.3 +tem would then have a nominal memo1-y bandwidth HOUSE 4.9 4.2 +requirement of 71 percent for a CVAX system and + SCHEM 4.7 3.7 +81 percent for an soc . + + + + +Digital Tecbtticaljournal Vol. 3 No. 4 Fa/1 1')')1 65 + Image Processing, Video Te rminals, and Printer Technologies + + + + + As the project schedule progressed, the risk asso­ In each case existing chips satisfied some of the +ciated with the new soc processor decreased. As requirements for the subsystem. In the end these +this risk window col lapsed, i t was u nderstood that chips met all ou r requirements, bu t only because +a turbo control ler based on the soc processor tht.:y wt.:re used in ways not originally intt.:ndcd by +would not only perform better, but would also cost the chip designers. +less as it would not require an external cache. + Main Memory +Turbo Controller Hardware Design + Since the SOC has a bus interface that is compati­ +The turbo controller was destined for a relatively ble with the CVAX chip, the most obvious chip to +high-end pri nter. Therefore the hardware archi tec­ use as a main memory control ler was the CVAX +ture had to provide maximum performance, even memory control ler (CMCTL) chip.1 It responds to all +though this implementation would increase costs. bus cycles generated by the soc, anct si nce it was +Based on the results obtained during RETrACE analy­ + already used on a munber of pla tforms supported +sis, the hardware design had the fo ll owing imple­ by the VAXELN operating system, i ts use greatly +mentation goals: simplified port ing VAX ELN to the turbo control ler. +• The SOC would provide the CPU, the float ing­ However, the turbo controller requires two special + point accelerator (FPA), and the cache subsystem. mem ory modes that are not provided directly by + No secon d-level cache would be implemented . the CMCTL, namely OR mode and scan- erase mode. +• A four- to six-entry write buffer would be I t was essential to devise a way to include these + implemented. two modes if the CMCrL were to be used. + OR-mode memory is a technique used to improve +• The transfer of bi t-map data to the print engine performance during the wri ti ng of the page bit + would requ ire a 32-bit DMA subsystem with scan­ map into memory (scan conversion). D uring nor­ + erase capabi l i ty. mal memory operation (cal led replace mode) , the +• The memory subsystem would support OR-mode dest i nation operand in memory is replaced by the + memory access by the CPU and scan-erase access sou rce operand . D u ring an OR-mode write cycle, + by the DMA control ler. the destination operand is mod ified as fol lows: + Although both the SOC and rtVAX chips comply • For each logicaJ zero in the source data being +with the VAX arch itecture standard and both are writ ten, the corresponding dest ination bit in +conceptually very similar, they have significant dif­ memory rem ains unchanged . +ferences in the bus interface. For example, the +soc uses a quadword cycle (one 32-bit address fol­ • For each logicaJ one in the source data being +lowed by two 32-bit data reads) to fil l one i nternal written , the corresponding destination bi t in +cache block, while the rtV�'\ processor, which does memory is written with the corresponding bit in +not support caching, does not usc this type of the pattern register. +cycle. AJso, the clocking system on the SOC was + • The p attern register is a 32-bi t register which +enhanced, and the timing rela tionships between + determines the "color" pattern of the "ink" being +signals were modified to improve performance. + written on the pagt.:. + The changes to the SOC bus in terfact:, plus the +requ ired functional changes revealed by RETrACE Figure 2 shows a portion of the logic between +analysis, meant that very l i ttle of the original the CMCTL and the memory array that implements +PrintServer 20 con troller design cou ld be appl ied the OR-mode fu nction in hardware. The OR-mode +to the new control ler. One of the first questions to operation is accomplished by inverting the source +be answered before the design of the turbo con­ data and connecting it to 32 independent write +tro l ler cou ld begi n, was whether or not one or enables of the memory array. When a zero is wri t­ +more AS!Cs wou ld be requi red for the design. This ten, it is inverted and the write cycle for that bit +question had to be answered for three subsystems: becomes a read cycle, thus preventing any change + to the memory contents. When a one is written, it +• Main memory + is inverted and the write is aiJowed to occur, but +• Write buffer the data actually wri tten depends on the value pre­ +• Bit-map data transfer subsystem viously wri t ten into the pattern register. + + + + +66 vbl. 3 No. 4 Faii i')'JI Digital TeciJIIicaljournal + Design of the Turbo PrintServer 20 Controller + + + +MEMORY DATA BUS FROM CMCTL 32 Three operations occur during a single scan­ + erase cycle. Refer to the circuit drawing in Figure 3. + 1. The bus m aster asse rts the signal's "bit-map + + + D� + 32 + DATA + IN + DATA + OUT � [> I-- + load" and "bit-map erase" and requests a masked + write. The C1viCTL performs a read, and the bit + map is read ontO the mem ory data bus. + PATTERN READ 2. Bit -map data is automatica l ly transferred from + REGISTER DATA PATH + the memory data bus intO the FIFO bu ffer. + 3. The CMCTL performs a write. However, since + the bit-map erase signal has disabled the data + '--- + [> � WRITE + ENABLE + path a nd the pul l-down resistors have set the + data-in l i nes to all zeros, the write cycle, which + was intended by the designers of the chip as a + OR-MODE MAIN MEMORY masked write, has in fact become a memory + WRITE ARRAY + DATA PATH clear opera tion. + + Write Buffer + Figure 2 OR-mode Circuit + The LR3220 chip was chosen as the base for the + write buffer subsystem. It provides a six-entry FIFO + Two fea tu res of the CMCTL chip m ake it possible buffer for address, data, and byte mask and detects +to im plement OR-mode memory. First, its 64MB whether the processor has requested a read at a +address space is divided i nto 4 arrays of 4 banks memory location for which a write is stil l pending. +(16 banks total). Second, the CMCTL chip can selec­ I t also supports two opera ting modes: LR3000 +tively disable parity checking on an array. mode and Harvard mode. + The large address space of the CMCTL al lows the If it were not fo r the Harvard-mode fea ture, it +use of 2 arrays for replace mode and 2 arrays for would have been more difficult to inclucle the +OR mode, since the turbo controller supports up to LR3220 chip into the turbo control ler. The LR3000 +32MB of memory. The control signals of the two processor, for which this chip was designed, has +sets of arrays are combined such that OR mode and staggered address tim ing. Some of the address and +replace mode access the same physical memory, byte-mask bits are asserted on the fall ing edge of +though in diffe rent ways. Parity error detection the clock, and the remaining bits are asserted on +is disabled on the OR-mode arrays; thus a read­ the rising edge of the clock. When the LR3220 chip +through OR-mode address space cannot cause a par­ is configured in LR3000 mode, the processor sub­ +ity error. This is necessary because OR-mode write system must meet these timing requirements. +cycles may corrupt pari ty. Normal ly any bit map However, when the LR3220 chip is configured i n +created using OR-mode write cycles is read using Harvard mode, a l l address, data, a n d byte-mask +OR-mode read cycles. information is read at the same rising clock edge. + The other special mode req uired for the main The basic strategy for including the wri te buffer +memory system is cal led scan-erase mode. It is an into the turbo controller was to insert the write buf­ +opera ting mode designed to i mprove bus util iza­ fer between the soc ancl the rest of the system as +tion during the transfer of the bit map from main shown in Figure 4. The SOC wou ld issue read and +memory to a FIFO buffer connected to the printer write requests to the write bu ffer, ancl the write +data l i nes. This mode is made possible by a side buffer would issue read and wri te requests to the +effect of the error-correcting code (ECC)/parity rest of the system. During CPU cycles the soc and +genera tion logic i n the CMCTL. Any time a masked the write buffer have a master-slave rela tionsh ip +write occurs (any write other than an al igned long­ in which the SOC is the master. The rela tionship +word , such as a byte write), the destination long­ between the write buffe r and the rest of the system +word must fi rst be read by the CMCTL, then is also a master-slave relationship; however. the +combined with the bytes tO be wri t ten in order write bu ffer is the master. In fact, the wri te-bu ffer +to generate the parity or ECC check bits for that output interface must look al most identical to the +longword . soc. + + + + +Digital Technicaljoumal Vol. 3 No. 4 Pall 1991 67 + Image Processing, Video Terminals, and Printer Technologies + + + + + FIFO BUFFER + + + + + [[IlJ + DATA TO + PRINT ENGINE + + + + + BIT-MAP LOAD I + MEMORY DATA BUS FROM CMCTL 32 + + RE PLACE-MODE + WRITE DATA PATH + + + + [> + 32 + + [> + 32 + DATA DATA + '-- + r-+- '-- + + + i + IN OUT + + + + + I + READ + BIT-MAP ERASE DATA PATH + + + + WRITE ENABLE + FROM CMCTL 1 COMMON + --- + .::._ + c__:_c__:_ + c__:_______ -f� WRITE + ENABLE + + + MAIN M E MORY + ARRAY + + + Figure 3 Scan-erase Circuit + + + The structure of the write-buffer subsystem is entries in the LR3220 chip have data, the bus cycle +shown i n Figure 5. The bus interface unit responds generator (BCG) removes the next entry ancl issues +to read or write requests from the soc. During a write request to the appropriate subsystem. +write cycles, the bus in terface writes the data into The write-buffer subsystem al lows the SOC to +the LR3220 chip and im mediately alerts the SOC to " read around" the write buffer, provided rhe address +terminate the cycle quickly. Whenever om� or more being read does not have a pending write in the + + + TO OTHER + SYSTEM WRITE-BUFFER SUBSYSTEMS + ON A CHIP 1--- SUBSYSTEM + + + + CVAX UN IVERSAL + MEMORY DI RECT MEMORY + CONTROLLER ACCESS + (CMCTL) CONTROLLER + + + I I + PRINTER MAIN + DATA FIFO MEMORY + BUFFER ARRAY + + + I + TO PRINT ENGINE + + + Figure 4 Interconnection of Turbo Controller Subsystems + + +68 Vol. 3 No. 4 l'i:t/1 1')91 Digital Tech11ical jourt�al + Design of the Turbo PrintServer 20 Controller + + + + + LOCAL BUS CYCLE + BUS GENERATOR SYSTEM CONTROL + SOC CONTROL INTERFACE CONTROL + SIGNALS AND + UNIT ARBITRATOR + I-- r-- + r-- + ADDRESS IN + r-I> + r---. + SOC DATA/ADDRESS + ...._ + LATCH + DATA I N + L_ ADDRESS OUT + DATA OUT + SYSTEM DATA/ADDRESS + + + SOC BYTE MASK + v + MULTIPLEXER + LR3220 WRITE BUFFER SYSTEM BYTE MASK + + + Figure 5 Write Buffer + + +LR3220. To handle this, the BCG includes an arbitra­ Bit-map Transfer Subsystem +tion circuit. When the SOC requests a read cycle, The bit-map transfer subsystem transfers bit-map +the bus interface unit of the write bu ffer passes data, created by the PostScript interpreter, to the +the request to the BCG. The BCG responds once print engine. It is composed of the 32-bit DMA con­ +it has completed any write cycle cu rren tly in trol ler, a FIFO subsystem, and scan-erase logic in +progress, provided that the address to be read does main memory as described in the section Main +not have a pending write in the write buffer. When Memory. +the slave device being read acknowledges the BCG , The main requ irements for the 32-bit DMA con­ +the acknowledgment is passed back to the bus troller were +interface ancl finally to the soc to terminate the + • 32 MB address range +cycle. The BCG then resumes its task of removing +entries from the LR3220 chip and issuing writes to • Abil ity to transfer 32 bits at a time +the rest of the system. • Abil ity to transfer the frame buffe r forward + In order to maintain data coherency, the wri te­ (incrementing the source add ress) or backward +buffer subsystem enforces some additional (decrementing the source address) +protocols. + None of the available DMA contro l ler chips met +• Al l wri tes to any location other than main all our requirements, but the AMD 9516 universal + memory require a wri te-fl ush cycle; that is, the DMA controller (UDC) met some of them. The uoc + bus interface mu st wait until the LR3220 chip is a 16-bit DMA controller with a 16MB address + is empty before wri ting the data to it. Further­ range and the ability to increment or decrement the + more, the bus inte rface must wait u ntil the BCG source address. There were two drawbacks to the + has finished the cycle before it acknowledges the use of this chip. The software would have to ensure + SOC and al lows it to pe rform the next cycle. that the frame buffer was always within the lower + 16MB of memory, and the UDC would use twice as +• All reads to any location other than main mem­ + much bus bandwidth since it could transfer only + ory require a read tl ush, which has the same + 16 bits at a time. + restrictions as a write fl ush. These restrictions + It was proposed that the UDC cou ld be used as a + are required to avoid the possibil i ty of reading + ful l 32-bit DMA controller if i t was connected to the + around a pendi ng 110 space write, which often + bus "incorrectly" by shifting the data/address l i nes + has side effects to other addresses. + to t he left by one bit. That is, data/address l ine 0 on +• The write-buffer subsystem must pass a l l DMA the UDC would be connected to data/add ress line 1 + bus transactions to the soc to ensure that a l l on the bus; data/address line 1 of the UDC would be + cached memory locat ions that are modified by connected to data/address line 2 on the bus; etc. + DMA cycles have their correspond ing cache This type of connection doubles the address range + entry inva lidated. of the chip and causes the sou rce address on the + + + +Digital Technical journal 14">1. 3 Nu. 4 Fa/1 1991 69 + Image Processing, Video Terminals, and Printer Technologies + + + + +bus to i ncrement by 4 bytes (32 bits) instead of Table 3 Benc h m a r k F i le Attributes +2 bytes (16 bits). + F i le N a m e General Attributes o f F i l e + This decision had a few impl<.:mcntation impacts. +For example, the register definitions were now B M 1 . PS Contains 39 pages of text with +incorrect, since a l l the bits in a l l the registers were 13 fonts of various si zes. Some +shifted one b i t to the left. However, once the soft­ text strings are at varyi ng angles. + +ware was modified to compensate for this, the UDC B M 2 . PS Contains 1 page of spiral text +functioned properly as a 32-bit DMA control ler. of va rious point sizes. + +When combined with the scan-erase feature of BM3.PS Contains 41 pages of text with + 5 fonts. +main memory, i t a llowed u s to achieve our b i t -map + HOUSE.PS Contains a 1 -page bitonal image +transfe r goal of reading 32 hits from memory, load­ + of 3000 blocks (DECnet l i m ited). +ing i t into the FII'O subsystem, and clearing the + SCH E M . PS Contains a 65-page schematic +memory location, all in a single DMA cycle. + of g raphics (vecto rs) and text. + +Pe rformance +In this section, the performance of the original Math Operators Performance of the +PrintServer 20 is compared to the enhanced perfor­ PostScriptjob +mance of the turbo PrintServer 20. Figure 6 i l l ustrates the control lers' performance + Except for performance, the original PrintServer resu lts in math operations per second. The test +20 and the turbo PrintServer 20 have identical func­ determines the time needed to perform 50,000 +tional capabi l i ties. Table 2 l ists the five functional primitive m a th operators (e.g. , adding two mJm­ +subsets that were characterized for performance bers 50,000 times) during a PostScript test docu­ +on both printers. The first fou r fu nctional subsets ment. The real-time operator reads the current +were rated using the PostScript real-time operator; time, and the repeat construct repeats the math +they measure the elapsed CPU time needed to operator. This test measures the performance of +complete a test. The last functional subset was the CPU only. +rated according to the rate of pages exi ting +the printer. The term " DECnet/DPS" refers to the + 0 1 4000 +DECnet job (a job is one of several m u ltiprocessing + z +tasks running on the controller) and the '"dis­ 8 1 2000 + w +tributed PrintServer software'' job. The term (/) + a: 1 0000 +" printer system" refers to the complete printer w + Cl.. +system, i ncluding the PostScript job and the p r int­ (/) 8000 + z +ing overhead jobs. The printer system was rated 0 +accord ing to the rate of pages exiting the printer. + � 6000 + II + Table 3 reports the general attributes of the five � + + � : + 4000 + 0 +files that were run with the RETrACE system and I + + I I _[ I I I I + 200 +chara<:terized for performance. + + ADD DIV MUL SORT COS EXP LOG + +Ta ble 2 Functional Subsets of the Pri nters KEY: + + 0 OR I G I NAL CONTROLLER +Functional Subsets C h a ra cter iza t i o n • TURBO CONTROLLER + T U R BO = 6.7 x O R I G INAL CONTROLLER +PostScript job Math operations per second + +PostScript job Text: characters per second + +PostScript job G raphics: vector inches per + Figure 6 PostScriptjob Performance with Math + second + +DECnet/DPS jobs DECnet/DPS: kilobytes per Text Performance of the PostScriptjob + second Figure 7 compares the text performance of the +Printer system I mage pri n ti n g : square PostScript job on the original controller and the +exc l u d ing inc hes per second + turbo control ler. The test determines bow long it +DECnet/DPS + takes the PostScript job to compose 250,000 equally + + + +70 14>1. 3 No. 4 Fall 1991 Digital Technical journal + Design of the Turbo PrintServer 20 Con troller + + + + 20000 Image Performance + The i mage test characterized the complete printer +0 +z +0 + system, inclu d i ng the PostScript job and the print­ +() 1 5000 +w ing overhead jobs, but excl ud ing the DECnet/ DPS +(f) +a: time requi red to transfer an image file to a printer. +w +(l_ +(f) 1 0000 Three one-square-inch bitonal i mages at device +a: +w resolution were placed into the user dictionary +f- +() +<>: + and were used repeated ly d uring the performance +a: 5000 +<>: measurement. The result of using these precached +I + + + + I I I, _I, I I +() i mages was to el iminate the DECnet and DPS soft­ + ware t ime that would be requi red to transfer a full­ + 0 + 2 4 10 12 page i m age from a host to the printer. Performance + FONT P O I N T SIZE + was measured by printing 10 pages of 80 square +KEY: inches of image per page. +0 O R I G I NAL CONTROLLER The pages were printed landscape and portrai t +• TURBO CONTROLLER + t o measure the i mage performance both o n axis and +TURBO = 5 . 2 x O R I G INAL CONTROLLER + off axis. (On axis means that the printer sequen­ + Figure 7 PostScriptjob Performance with Text t ia l ly prints a l l b i ts of a word from the image on a + single scan line. Off axis by 90 degrees means that +sized characters to the page buffer i n memory, the printer prints one bit from each word and does +which eventually is sent to the print engine to be not print the next bit i n the word until it is a t +printed. t h e same position o n t h e next scan l ine.) Figure 9 + shows the results of the image p erformance test in +Graphics Performance of PostScriptjob square inches per second . + +An important means of characterizing graphics per­ +formance is in vector inches p e r second. Figure 8 22.0 + +shows the results obtained by running a PostScript 0 20.0 + z +vector program in which all vectors are at 0 + () + 1 8.0 + w +45 degrees and vector lengths are from 0.1 inch to (f) 1 6.0 + a: +3 inches. w 1 4 .0 + (l_ + (f) 1 2.0 + w + I 1 0 .0 + () + 3000 + ?; 8.0 + w +0 a: 6.0 +15 25oo <>: + ::::J 4.0 +() a +w (f) + 2.0 +� 2000 +w 0 +(l_ +� 1 500 +I KEY: +() +?; 1 000 0 O R I G INAL CONTROLLER +a: • TURBO CONTROLLER +0 +f- T U R BO = 3.0 x O R I G I NAL CONTROLLER +() 500 +w +> + + + Figure 9 Image Performance Measurement + of the Printing System +KEY: + +0 O R I G I NAL CONTROLLER DECnet/DPSjobs Performance +• T U R BO CONTROLLER + DECnet/DPS transfer rates can be ignored for text +TU RBO = 4 . 6 x O R I G I NAL CONTROLLER + and graphics files, but these rates can consume + most of the time needed to print large image files. + Figure 8 PostScriptjob Performance For example, a single, letter-size page of image + with Graphics contains more than 1 MB of i mage data, but the + + + +Digital Technical journal Vol. j No. 4 Fall 1991 71 + Image Processing, Video Terminals, and Printer Technologies + + + + +corresponding PostScript file con tains morT t han to file printed and by the amount of CPU time used +2 M B . Because the image data is represented in Amer­ to print the job. For example, in t he B.\1 :) bench­ +ican standard code for information interchange mark, the speed is limited by the 20-page­ +(ASCII) hexadecimal characters in PostScript, S bits per-minu te print engine, but the CPU time needed +of the PostScript file are needed to represent 4 hits to print the file can be used as a performance +of image data. measurement. + 'I(> measure DECnct/ DPS, a PostScript file of I M R +o f comments was sent t o the printer. The clock was Summary +started ·when the beginning of the file was tTccived The turbo controller enhanced the performance of +by the PostScript interpreter and stopped when the the PrintScrver 20 printer system. Its design was +end of the file was received . The assumption of this prompted by the need to maintain print speed +test method was that the PostScript interpreter can performance for complex documents containing +parse comment I ines much faster than DECnet/ DPS text, graphics, and images. The RETrACE system was +can t ransfer them. designed to analyze the PrintServer 20 system to + The DECnet/DPS transfer rate is basica l ly propor­ determine which architectural changes would pro­ +tional to the slower of the host and printer proces­ vide the greatest improvement in PostScript perfor­ +sors. Figure 10 shows the DECnct/DPS results. mance. By optimizing hardware only in areas where + it was truly worthw hile, we were able to use exist­ +RETrACE Benchmark Files ing chips and reduce development costs. The sub­ +The benchmark files l isted in Table 4 arc charac­ systems of the turbo control ler hardware that +terized both by the elapsed time from file arrival were optim ized as a resu lt of this analysis were + the processor (SOC which provided CPU , floating­ + point accelerator, and cache subsystem), a memory + 90 + subsystem with OR-mode and scan-erase access, + 80 +0 + a write-bu ffer subsystem, and a 32-bit DMA sub­ +z 70 system. Results of the p erformance tests for five +0 +() +w 60 benchmarks, includ ing PostScript jobs, indicate the +(/) +cc 50 levels of enhanced performance. +w +a_ +(/) 40 +w Acknawledgments +f-- +>- 30 +C) +0 Chris Mayer designed and i mplemented the +...J 20 +52 RETrACE multilevel cache simulator. He developed + 10 a ticketing algorithm that simpl ified the manage­ + 0 ment of delayed behavior memory constructs such +KEY: as write buffers. +0 O R I G I N A L CONTROLLER +• TURBO CONTROLLER Refe rence +TURBO = 4.9 " O R I G I N A L CONTROLLER + 1 . D. K. Morgan, "The CVAX CMCTL-A CMOS + Memory Control ler Chip," Digital Technical + Figure 10 DECnet/DPS}obs Perjonnance journal, vol. 1, no. 7 (August 1988): 139 - 143. + + + +Table 4 Bench m a r k F i les Cha racterized by Ela psed Time a n d CPU Ti m e (Seconds) + +Be nchmark Original Tu rbo Original Tu rbo delta delta +File CPU CPU Elapsed Elapsed CPU Elapsed + + +BM1 7585 1 707 7735 2050 4.4 3.8 + +8M2 238 51 241 51 4.7 4.7 + +8M3 56 15 1 28 1 20 3.7 1 .1 * + +HOUSE 67 15 1 06 31 4.5 3.4 + +SCHEM 2802 625 3073 675 4.5 4.6 +"Limited by engine. + + + + +72 Vol. 3 No. i Full 1991 Digital Technical journal + I Further Readings + + + The Digital Technical Journal DECwindows Program + publishes papers that explore Vol. 2, No. 3. Summer 1990 + the technologicalfoundations An overview and descriptions of the enhance­ + of Digital's major products. Each ments Digital's engineers have made to MIT's + J ournal fixuses on at least one X Window System in such areas as the server, tool­ + product area and presen ts a kit, interface language, and graphics, as we l l as + cornpilation of papers written contributions made to related industry standards + by the engineers who developed + VAX 6000 Model 400 System + the product. The contentfor + Vol. 2, No. 2, Spring 1990 + the Journal is selected by the + The h ighly expandable and con.figurable midrange + journal Advisory Board. + fami l y of VAX systems that includes a vector proc­ + Digital engineers who would + essor, a high-performance scalar processor, and + like to contribute a paper + advances in chip design and physical technology + to the Journal shou/.d contact + the editor at RDVAX.::BLAKE. Compound Document Architecture + Vol. 2, No. 1, Winter 1990 +Topics covered in previous issues of the Digital The CDA family of archi tectures and services that +Technicaljournal are as fol lows: support the creation, interchange, and processing + of compound documents in a heterogeneous net­ +Availability in VAXcluster Systems/ work environment +Network Performance and Adapters + Distributed Systems +Vol. 3, No. 3, Summer 1991 + Vol. 1, No. 9,june 1989 +Discussions of VMS volume shadowing, VAXcluster + Products that a l l ow system resource sharing +application design, and new ava i labil i ty features of + throughout a network, the methods and tools +local area VAXcluster systems, together with detai ls + to evaluate product and system performance +of high-performance Ethernet and FDDI adapters, +and an analysis of FDDI LA N performance Storage Technology + Vol. 1, No. 8, February 1989 +Fiber Distributed Data Interface Engineering technologies used in the design, man­ +Vol. 3, No. 2, Spring 1991 u facture, and maintenance of Digital 's storage and +The FDDI IAN system and Digital's products that information management products +support this technology, with an overview and +papers on the physical and data l i nk layers, CVAX-based Systems +Common Node Software, bridge and concentrator Vol. 1, No. 7, A ugust 1988 +devices and related management software, and an CVAX chip set design and multiprocessing archi­ +ULTR.IX network adapter tecture of the m idrange VA.,'\ 6200 fam i l y of systems + and the MicroVA.,'< 3500/3600 systems +Transaction Processing, Databases, and + Software Productivity Tools +Fault-tolerant Systems +Vol. 3, No. 1, Winter 1991 Vol. 1, No. 6, February 1988 + Tools that assist programmers in the development +The archi tecture and products of Digital's d is­ +tribu ted transaction processing systems, with of high-quali ty, rel iable software +information on moni tors, performance measure­ VAXcluster Systems +ment, system sizing, database availabi l ity, commit Vol. 1, No. 5, September 1987 +processing, and fau l t tolerance System com m unication architecture, design and + implementation of a d istributed lock manager, and +VAX 9000 Series + performance measurements +Vol. 2, No. 4, Fall 1990 +The technologies ami processes used to build VAX 8800 Family +Digi tal's first mainframe computer, including Vol. 1, No. 4, February 1987 +papers on the architecture, m icroarchi tecture, The microarchitecture, internal boxes, VAXBI bus, +chip set, vector processor, and power system, and VMS support for the VAX 8800 high-end mul ti­ +as wel l as CAD and test methodologies processor, simulation, ancl CAD methodology + + + +Digital Tecbnical ]ou mal Vol. 3 No. 4 Fall /')91 73 + Further Readings + + + + Networking Products J Delahu nty and T. Kielty, "Automated Pareto + Vol. 1, No. 3, September 1986 Analysis for Continuously Improving a VLSI + The Digital Network Architecture (DNA), network Fabrication Area's Process Stabi l i ty," Advanced + performance, LANbridge 100, DECnet-l i LTRIX and Semiconductor A1anufacturing Conference + DECnet-DOS, monitor design (September 1990). + MicroVAX II System S. Del l , " Promoting Equal ity of the Sexes through + lf)/. 1, No. 2, March 1986 Technical Writing," Society. for Technical Commu­ +The implementation of the microprocessor and nication (August 1990). +floating point chips, CAD su ite, MicroVAX work­ + B . Doyll' and K. Mistry, "A Lifetime Prediction +station, disk controllers, and TK';O tape drive + Method for Hot-carrier Degradation in Surface­ +VAX 8600 Processor channel P-MOS Devices," IEI:.'F [i-ansactions on + Vol. 1, No. 1, August 1985 Electron Devices (May 1990). +The system design with pipel inecl architecture, +the 1-box, F-box, packaging considerations, signal E. Freedman and Z. Cvctanovic, " Efficient +integrity, and design for reliability Decomposi tion and Performance of Para l lel + POE, FFT, Monte Carlo Simulations Simplex +Subscriptions to the Digital 1'echnical.fournal are + ami Sparse Solvers," IEEE Supercomputing '90 +available on a yearly, prepaid basis. The subscrip­ + (November 1990). +tion rate is 540.00 per year (four issues). Requests +should be sent to Cathy Phi l l ips, D igital Equipment A. Garde! and P Deosthali, " Hub-centered Pro­ +Corporation, M LO I-3/B68, 146 Main Street, Maynard, d uction Control of Wafer Fabrication," Advanced +MA 01754, U.S.A. Subscriptions must be paid in U.S. Semiconductor Manufacturing Conference +dol lars, and checks should be made payable to (September 1990). +Digital Equipment Corporation. + A. Hartzel l , " I ntroduction of Argon as a Heat +Single copies and past issues of the Digital Transfer Gas in a Single Wafer RJ E System ," +Technical.fournal can be ordered from D igital Jntenwtional Symposium for Testing and +Press at a cost of $16.00 per copy. Failure A nalysis (October 1990). + +Technical Papers by Digital Authors A. Heyman and J Thottuvelil, " L inear Averaged and + Sampled Data Models for Large Signal Control of +R. Al-Jarr, ''A Methodology for Evaluating Decision High Power Factor AC-DC Converters," IEEE Power +Making Architectmes for Automated Manufactu r­ Electronics Specialists Oune 1990). +ing Systems,'' Eleventh JF-AC Conference (August +1990). L. Hill, "Video Signal Analysis for EMI Control," + IEEE Electromag '91 (1991). +S. Angebranndt, R. Hyde, D Luong, and N. Siravara, +"Integrating Audio and Tel<.:phony in a Distribu ted L. H i l l and A . Metsler, "Video Subsystem Design + +Workstation Envi ronment," Proceedings of the for EMI Control," IEEE Electrmnag '91 (1991) . +Summer 1991 T!SLNIX Conference Oune 1991 ). S . Kasturi, " Forced Convection: The Key t o the + Versatile Reflow Process," NEPCON East '90 +S . Batra, M . Mallary, a n d A. Torabi, " Frequency + Oune 1990) +Response of Thin-lilm Heads with Longitudinal +and Transverse Anisotropy," !J:'I:'f:' lntermag '90 D. Mirchandani and P Biswas, " Characterization +(April 1990). and Modeling Ethernet Performance of + Distributed DECwinclows Applications," +R. Csencsits, N. Riel, ]. D ion and S. Arsenault, + ACM Sigmetrics (May 1990) +"Interfacial Structure and Adhesion of Metal-on­ +polyamide," International Symposium for Testing W Metz, "Au tomated On- l ine Optimization of an +and Failure Analysis (October 1990). Epi taxial Process," International Semiconductor + Manufacturing Science Symposium (May 1990). +R. Csencsits, J. Rose, R. St. Amand, L. E ll iott, +A. Hartzel l , L. Kisselgof, and ]. Lloyd, "Aluminum K. Mistry, B. Doyle, and D. Krakauer, "Im ract of +Interconnect Microstructure and Its Role in Snapback I nduced Hole Injection on Gate Oxide +Electromigration," Jntentational SymjJOsium Rel iabil ity in N-MOSFET's," //.;/:1:.' Electron Device +for Testing and Failure A na�ysis (October 1990). Letters (October 1990). + + + +74 Vol. .) No. .:j Fall I'J'JI Digital Technical journal + I +C. Pan, "Gas Lubrication," ASME/STLE Tribology VAX/VMS: Writing Real Programs in DCL +Conference (October 1990). Paul C. Anagnostopou los, 1989, softbou nd, + 409 pages, Order No. EY- C 168 E -D P-EEB ($ 29.95) +A. Philipossian, "Fluid Dynamics Analysis of +Thermal Oxidation Systems via Residence Time This book contains information that can help the +Distribution (ROT)," Electromechanical Society reader Jearn to write powerful and wel l-organized +(October 1990). programs in DCL, the command language for the + VAX/VMS operat i ng system. The text includes a +M. Sidman, "Convergence Properties of an + review of the syntax and semantics of DCL and a +Adaptive Runout Correction System," ASME + discussion of significant issues in the development +Winter Meeting (November 1990). of serious DCL software. Programming paradigms +M. Sidman, " Parametic System Identification are presented, as wel l as the correct way to +on Logarithmic Frequency Response Data," implement them. The book presents good pro­ +IEEE Transactions on Automatic Control gramm i ng techniques and helps the student to +(September 1991 ). make effective use of the VMS operating system . + +D. Skendzic, "Two Transistor Flyback Converter + X WINDOW SYSTEM TOOLKIT: +Design for EM! Control," IEEE Symposium on + The Complete Programmer's Guide +Electromagnetic Compatibility (August 1990). + and Specification +A. Smith and W Gol ler, " New Domain Configura­ Paul ). Asente and Ralph R. Swick, 1990, softbound, +tion in Thin-film Heads," Intermag '90 (April 1990). 1000 pages, Order No. EY-E757E-DP-EEB ($44.95) + +H. Smith and ). Beagle, " SIMS for Accurate This book consists of two parts, "Programmer's +Process Monitoring i n CoSi2-on-Si MOSFET G uide" and "Specification." "Programmer's G u ide" +Technology," Secondary Jon Mass Spectrometry describes how to use the X Toolkit to write +(September 1989). appl ications and widgets, and i nc ludes many + examples. Each chapter i n this part contains an +). Thottuve l i l , "Using SPICE to Model the Dynamic + appl ication writer's section and a widget writer's +Behavior of OC-to-DC Converters Employing Mag­ + section. Application program mers need to read the +netic Amplifiers," IEEE Applied Power Electronics + widget writer's sections only if they are curious +Conference (March 1990). + about what is going on behind the scenes; +R. Ulichney, "Frequency Analysis of Ordered widget program mers shou ld read both sections. +Dither," Hard-copy Output OE!LASE 89 SPIE '89 " Specification" provides a complete and concise +Proceedings (1991). description of every component of the X Too l k i t + Intrinsics, a s standardized b y t h e MIT X Consor­ +R. Ulichney, "Challenges in Device Independent + tium. The level of detail i n this part is sufficient +Image Rendering," Applied Vision Optical Society + to enable a program mer to create a new imple­ +ofA merica Technical Digest Series '89 (1991). + mentation of the X Toolkit. +E. Zimran, " Performance Efficient Mapping of +Applications to Paral lel and Distri buted Archi­ PRODUCTION SOFTWARE TIIAT WORKS: +tectures," International Conference on Parallel A Guide to the Concurrent Development +Processing (August 1990). of Realtime Manufacturing Systems + john A. Behuniak, Iftikhar Ahmad, and +Digital Press + Ann l\1 . Courtright, 1992, softbound , 204 pages, +D igital Press is the book publ ishing group of Order No. EY-H895E-DP-EEB ($24.95) +D igital Equipment Corporation. The Press is an + This is a practical gu idebook for manufacturing +i nternational publ isher of computer books and + m anagers and process engineers who must develop +journals on new technologies and products for + better process methodologies to stay competitive +users, system and network managers, program­ + and for developers of realtime manufacturing +mers, and other p rofessionals. Proposals and ideas + software who need to cut time and costs from their +for books in these and related areas are welcomed . + work. The presentation, which provides useful +The fol lowing book descriptions represent a advice ancl easy-to-follow procedures, addresses +sample of the books available from Digital Press. three basic tasks of realtime software development + + + +Digital Technical journal Vol. 3 No. 4 Full 1991 75 + Further Readings + + + +in a manufacturing plant: ( 1 ) managing the design VAX Pascal progra m m ing language, this is the first +of the system; (2) setting up and managing a book to actual ly discuss the construction of real +development organization; and (3) implementing VMS applications. It sets forth a methodology for +tools for successfu! completion and managem<..: nt. producing h igh-qua l ity, p rofessional VMS appli­ + ca tions by focusing on the aspects of the V M S +UNIX FOR VMS USERS opera ting system crucial to every well-written +Phi l ip E. Bourne, 1990, softbound, 36R pages, application. +Order No. EY-C 177E-DP-EEU (S28.95) + +This book emphasizes the practical aspects of THE DIGITAL GUIDE TO SOFTWARE +making the transition f rom the ViviS to the U N I X DEVELOPMENT +operating system. Every concept p r<..: s ented i s The staff of the Corporate User Information +il lustrated w i t h o n e or more examples, comparing Products (CUIP/ASG), D igital Equ ipment +how to perform a par ticular task in each of the Corpora tion, 1989, softbound, 239 pages, +two operating systems. The book is organized in a Order No. EY-C l 78E-DP-EEB ($ 27.95) +logical order and covers the following topics: fun­ THI:' DIGITA L GUIDE TO SOF1 mlRE DEVELOPNIENT +damental concepts to be grasped before touching is the tirst publ ished description of the method­ +the keyboard, the first terminal sessions, the first ol ogy that Digi tal uses to design and develop i ts +commands, editing, com mu nica ting with users, software . For the engineer ancl other professionals +resource u t i l iza tion, using devices, more advanced associated with the creation ami marketing of +commands, using h igh- level languages, program­ software applications, this book gives a rare look a t +ming the operating system, text processing, and t h e practices o f a n industry leader and provides a +networking. Appendixes provide extensive cross­ model for others who wish to introduce software +reference tables to make this a valuable reference enginet:ring methods and tools i nto their own +tool for even the experienced UNIX user. companies. Also discussed are the use of selected + VMS case tools to exped i te the process; the roles of +LOGISTICAL EXCELLENCE: + teams and team leaders; the use of review meetings +It's Not Business as Usual and docu ments; and formal procedures for testing +Donald ). Bowersox, Pa tricia J Daugherty, + and ma intenance. The guide includes numerous +Cornel ia L. Drogue, Richard N. Germain, and diagrams and tables, c l ear guidel ines for the coding +Dale S. Rodgers, 1992, 300 pages, and documentation of software modules, a l isting +Order No. EY-1 1953E-DP-EEB of related VMS documen tation, and coding gu ide­ +This book focuses on the interpretation of research l ines for VAX C. +findings that have been compiled to help managers +who seek to improve logistical competency within DIGITAL GUIDE TO DEVELOPING +their organization . It provides a sequent ia l model, I NTERNATIONAL SOFTWARE +the best p ractices of "excellent" logistics managers The staff of the Corporate User Information +with supportive statistica l evidence, and extensive Products (O J I P/AS< i), D igita l Equipment +coverage of Electronic Data Interchange in the Corporation, 1991, softbound, 381 pages, +logistics process. It also includes a brief overview Order No. EY-F577E-DP-EEB ($28 95) +of the expanding role that logistics has recently + This book introduces the grou nd-breaking pack­ +played i n the overall corporate strategy of increas­ + aging and design gu idelines recommended by +ing speed and qual ity. lb facili ta te i nterest and ease + Digi tal for products destined for overseas markets. +of reading, an action-oriented case d ia logue ru ns + Al ready used by more..: than 400 independent soft­ +throughou t the eight chapters. + ware vendors and development groups, as wel l as + by Digital engineers, this book offers an approach +WRITING VAX/VMS APPLICATIONS USING + that grea t ly simplifies the steps required to adapt +PASCAL + software to local markets once the parent product +Theo de Klerk, 199 1 , hardbound , 748 pages, + has been released. The book fea tures a description +Order No. EY-F592E-DP-EEB ($ 39.9';) + of Digital's international product model, a scheme +Written for the professional appl ica t ion program­ for separating the core functions of a product from +mer on the VAX/VMS opera t i ng system using the those that require t ranslation or modification for + + + + +76 1-h/. J No. 4 l'ali i'J'JI Digital Technical]ou.-nal + I +specific markets. Also included are guideli nes for Qual i ty. The Epilogue, Part IV, concludes with +developers working in DECWindows, VMS, and three appendices detai l ing Benchmarking, Build­ +ULTRIX environments; special considerations ing Networks, and Networking Capabi l i t ies. +involved in preparing a product for multibyte Asian +languages or for mu ltilanguage environments; and THE ART OF TECHNICAL DOCUMENTATION +append ixes with information o n the systems issues Katherine Haramundanis, 1992, softbound, +in computer architecture. 267 pages, Order No. EY-H892E-DP-EEB ($ 28.95) + + Wri tten primarily for novice and aspiring technical +USING MS-DOS KERMIT: Connecting your + writers within the computer industry, The Art +PC to the Electronic World, Second Edition + of Technical Documentation has u nique features, +Christine M. Gianone, 1991 , softbound, + including i ts advice on planning and process, +344 pages with software d isk included, + research techniques, use of graphics, audience +Order No. EY-H893E-DP-EEB ($ 34.95) + analysis, definition of qua l ity, standards, and +As in the first edition, this software package leads careers that are valuable to experienced technical +the novice step by step through instal lation, com­ writers as well . Haramundanis views the practice +munication setup, terminal emulation, fi le transfer, of technical writing as being d ifferent from that +and script programming, and also serves as a com­ of scientific writing, and closer to investigative +plete reference work for the experienced user. reporting. In keeping with this premise, this book +Complete with 5Y.-inch diskette containing the is not a style guide that deals with a l l aspects of +official M5-DOS KERMIT Version 3.1 1 program from typography and copy edit ing, but instead presents +Columbia University, t h is revision includes a new the distil led knowledge of the author's many years +section on local area networks, additional m a terial experience. +on running Kermi t in windowed environments +such as M icrosoft Windows and Quarterdeck A COMPREHENSIVE GUIDE TO Rdb/VMS +DesqView, a new appendix containing tables of Lilian Hobbs and Kenneth England, 1991, +the escape sequences used by Kermit's text and softbou nd, 352 pages, Order No. EY-H873E-DP-EEB +graphics terminal emulators, and expanded ($ 34.95) +descriptions of many of Kermit's features. + The Rdb/VMS relational database system was +ENTERPRISE NETWORKING: developed by D igital Equipment Corporation for +Working Together Apart VAX computers using the VMS operating system. +Raymond H. Grenier and George S. Metes, 1991 , This system is one of a number of information +hardbound, 260 pages, Order No. EY-H878E-DP-EEB management products that work together to +($ 29.95) faci l i tate the sharing of i nformation. The Rdb/VMS + system is used, for example, in high-performance +To successfu l ly compete in the next century, com­ + transaction processing systems. This book is based +panies must recognize and adapt to exponential + on Rdb!VMS Version 4.0, which Digital made avail­ +changes, including the d ispersion of markets and + able to customers at the end of 1990, and thus +resources and acceleration in market demands. + includes the latest functiona l ity. +ENTERPRISE NETWORKJNG: Working Together +Apart, describes how management can support + DIGITAL GUIDE TO DEVELOPING +this d istributed electronic information environ­ + INTERNATIONAL USER INFORMATION +ment and move through planned transitions to + Scott Jones, Cynthia Kennel ly, Claud i a Mueller, +a new organization, confident they wil l prosper. + Marcia Sweezey, B i l l Thomas, and Lydia Velez, 1992, +Intended for individuals in charge of d irecting + softbound, 2 14 pages, Order No. EY-H894E-DP-EEB +transition of information-focused groups that + ($24.95) +extend across geograph ies, this book is segmented +into four parts. The Introduction, Part I, defines Designed for the busy profession a l , this book +the assumptions and reali ties. Part II focuses on presents models that extend beyond Digital and +Capabi l ity Based Environments. Part I I I d iscusses English speaking countries in a quick read/ +Simu ltaneous Distributed Work, both Goals and reference format. Nine chapters and fou r appen­ +Processes, ancl Continuous Design and Quest for dices outl ine methods for creating written, visual, + + + + +Digital Technical jottrlla/ Vol. 3 No. 4 Fat/ 1991 77 + Further Readings + + + + +and verbal information for cost-e!Iective trans­ VMS FILE SYSTEM INTERNALS +lation. Primarily for information sp ecial ists, Ki rby McCoy, 1990, softbound, 460 pages, +including writers, ed itors, i l lustrators, course Order No. EY-F575 E-0P-EEB ($49.95) +developers, and their managers, this book wil l also + VIIIJS FILE SYSTEM INTERNA LS, based on VMS Version +help software developers and students enhance + 5.2, is a book for system program mers, software +the ir background in technical communication. + special ists, system managers, applications design­ +PRACTICAL KNOWLEDGE ENGINEERING: ers, and other VAX/VMS users who need to under­ +Creating Successful Commercial Expert stand the i nte rfaces to and the data structures, +Systems algorithms, and basic synchronization mechanisms +Richard V Kel ly, Jr. , softbound, 212 pages, of the v,'viS file system. Th is system is the part of +Order No. EY-F591 E-OP-EEB ($28.95) the VAX/VMS operating system responsible for + storing and managing files and i nformation in +This book is a concise guide to practical methods memory and on secondary storage. The book is +for initiating, designing, building, managing, also intended as a case study of the V.\'fS imp lemen­ +and demonstrating commercial expert systems. tation of a tile system for graduate and advanced +It is a front-l ine report of what works (and what umkrgraduate courses in operating systems. +does not) in the construction of expert systems, +drawn from the au thor's decade of experience DECNET PHASE V: An OSI Implementation +gained working on such projects in all major James ,vlartin and Joe Leben, 1992, hardbound, +areas of application for American, European, and 572 pages, Orcler No. EY-H882E-DP-EEB ($49.95) +Japanese organizations. It also briefly reviews + This book provides a first in-depth look at DECnet +the knowledge representation, program ming, + Phase V and the important issues that must be +and management techniques commonly used to + resolved in the design and implementation of very +implement expert systems today, and describes the + large networks. It presents key Open Systems In ter­ +intel lectual, organizational, financial, and manage­ + connection (OSI) concepts and shows how DECnet +rial issues that knowledge engineers face daily in + Phase V hardware and software products imple­ +performing their jobs. Among the topics covered + ment interna tional standards associa ted wi th the +are: prospecting for " legitimate" problems; fore­ + OSI model. +casting costs, establ ishing project metrics and +wri ting specifica tions; preparing for system + VAX/VMS OPERATING SYSTEM CONCEPTS +"demos''; interviewing and selecting engineering + David Miller, 1991 , hardbound, 512 pages, +team members; and solving common difficulties + Order No. EY-F590E-DP·EEB ($44.95) +in design and implementation. + This book begins with an overview that centers +COMPUTER PROGRAMMING AND on one visi ble aspect of an operating system, +ARCHITECTURE: The VAX, Second Edition terminal input and output; it proceeds into wel l ­ +Henry M. Levy and Richard H. Eckhouse, Jr. , 1989, organized chapters o n process definition, paging +hardbou nd, 444 pages, Order No. EY-6740E-DP-EEB and memory management, securi ty, protection +($3800) and privacy; and it concludes with a chapter + on orera ting systems at D igital Equipment +This book is both a reference for compu ter profes­ + Corporation. Each chapter provides an intro­ +sionals and a text for students. A systems approach + duction, theoretical discussion, general ly recog­ +helps the reader understand the issues crucial to + nized solutions, a lgorithms and da ta structures, +the comprehension, design, and use of modern + and questions to encourage review of the centra l +computer systems. Using the VA)( computer as an + concept presented . +example, the first hal f of the book is a text sui table +for a complete course in assembly language pro­ + THE VMS USER'S GUIDE +gramming. The second half of the book describes + James F. Peters, III and Patrick ). Holmay, 1990, +higher-level systems issues in computer architec­ + softbound, 304 pages, Order No. EY-6739E-DP·EEB +ture, namely, support for operating systems and + ($ 28.95) +operating systems structures, virtual memory, +paral lel processing, microprogramm ing, caches, This up-to-elate guide for new VMS users provides +and translation buffers. a sequence of steps for learning the VMS operating + + + +78 1-b/. 3 No .; + . Fall 1')91 Digital Tee/mica/ journal + I +system and includes hands-on experiments with " X Protocol," " XLib," "X Tool kit Intrinsics," " Motif," +step-by-step instructions. The book also can be and " General X " ; all routines and data structures +used as a reference for com mands and utili ties. are organized alphabetically within each of these +THE V1VIS USER'S GUIDE, reflecting VMS Version 5, sections. +provides complete VMS coverage-from Jogging +in to creating command procedures; contains FIFfH GENERATION MANAGEMENT: +a thorough discussion of files and d irectories; Integrating Enterprises through Human +covers both the EDT and the EVE editors in detail; Networking +and introduces programming with VA,'