CA1237199A - Method of graphical manipulation in a potentially windowed data display - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

A method is disclosed which enhances the ability of digital computer system to manage displays, especially in an environment where a single physical display supports a plurality of logical displays (windows). Machine-language instructions are provided which, in conjunction with user-supplied form descriptors describ-ing each of the windows, enable management and generation of dis-play image data to be performed directly by the processing hardware of the digital computer system, eliminating any need for interven-ing interpretive software. Data computed from form descriptors may be encached, enhancing the speed of consecutive operations on win-dows. Graceful creation is enhanced by permitting processing con-trol to escape to software fault handlers.

Description

~L~3~

TITI.E: A metho(l o~ gra~h:icnl manipulat;ion in a potent:ially ~indowed data display.

C~OSS-REFEI~NCF. TO REL~TL'D APPI,IC~TIONS:

There are no related applications.

BACKGROULD OF TIIE I~VEPTION:

l. FlE~D OF TIIE I~YENTION:

rrhis invention relates generally to digital data system~, and more particularly to techniques for managing the display of data by such systelns in an environment wherein a single display device may provide for a plurality of logical displays functioning independently of each other. Each logical display is known as a "window". Windows may all be displayed concurrently in their entirety, or some windows may be partially or completely covered by other windows.

2. DESCRIPTIO~ OF THE PRIOR ART:
REFERENCES:

Graphics in Overlapping Bitmap Layers9 Rob Pike, ACM Transac-tions on Graphic~, April, 1983.

SMALL'rALK-BD, The L~nguage and its Implementation, Adele Goldberg and David Rob~on, Addi~on-We~ley, 1983. (Particularly chapters 17, 18, 20).

kh/

~L2~ 9 Ui~ital data ~3y~ tem~ have been equipped with d-isplly devlces almost since their adven-t. 'rhe -type of display that ha~
taken ~re-omin~nco a9 the mo~t t-Lexible for in-te~fflo:lne with thc u~er i~ -the cathode ray -tube display. A recently evolved ~lode of thn use of such displays is to per~it several users, several progrulns, or ~everal processes to share the available space on a displuy, with each such u~er, program, or process being allocated a certain amount of di~play area. Each such area is known as a "window".

Windows, -then, may be thought of as independen-t logical displays co-existing on one physical display. An analogy i~ ~everal sheets of paper on a desktop; -they may be arranged ~o that all are si~.ultaneously visible, or as they are manipulated some may completely cover (obscure) or partially cover (occlude) others. When ob~cured or occluded sheet~ are again uncovered, they still contain all the information that was temporarily invi~ible.

Windows on a display may likewisQ be manipulated 90 that some are ~ometimes partially or completely invisible on the di~play -- i.e., they pre~ent the appearance of being "covered" by o-ther windows. A good embodiment permits the data in windows to be manipulated even while the affected windows or portions of windows are not vi~ible on the ~creen, with subsequent "uncovering" revealing -the manipulations that were performed on a window while invi~ible.

~ indowing ~a~ heretofore bee~ accompli~hed primarily by ~oftware. While ~uch an implementation o~ windo~ing can provide sufficient capabilityS it doe~ co at the expense of comput~tional overhead -- the u~er'~ reque~t~, taking the form of ~oftware calls, mu~t go through level~ of interpretation by software in order to derive a ~erie~ of machine-langùage in~truction3 that the ey~tem can execute, even for simple (i.e., unoccluded) windows. Another rea~on for the severity of thi~ overhead is that the descriptive information (of which there i~ a much larger amount for a windowed display than for a simple unitary display) must be completely reproce~ed every kh/

request -- there is no architectural provision for retaining the results of previous computations aEfecting those portions of the display not involved in a current change As the windowing capabilities are made more sophisticated, this overhead becomes more and more severe.

Sl:IMMARY OF TE~E IN~ENTION:

The present invention discloses a method of managing displays of a data system which includes memory, a processor, a display, and a display interface. The processor is capable of executing machine language instructions that may direct]y (i.e., without intervening interpretation by software) manipulate displayed data. The method comprises providing a series of such instructions and providing a set of form descriptors which describe the characteristics of windows on the display. The processor takes each such instruction in turn, associates it with a form descriptor, determines the previous state of the display, and modifies the set of data to which the display interface is responsive to produce the modified display specified by the instruction.

Specifically, the invention relates to a method for controlling the displays o~ a digital computer system. The system comprises: main memory means for storing instructions and data; processing means for performing operations on data in response to the instructions; and display means for displaying representations of data. The method comprises the steps of:
a) storing in the main memory means form descriptors ~or describing organization of data to be displayed; b) storing in the main memory means instructions for specifying first data and for specifyin~ representations of first data which are to be displayed, and for describing the position within the organization described by the form descriptors at which the representations of the first data are to be displayed; c) selecting an instruction and a form descriptor to obtain a kh/~ ~

r,2 r ~ S

selected instruction and a selected form descriptor; d) calculatingr in the processing means, second certain data.which is a function of the selected instruction, the selected form descriptor, and certain first data specified by the selected instructionl the second certain data being a representation of what is to be displayed; and; e) forwarding the second certain data to the display means for representations of the second certain data to be displayed.

It is thus a feature of the present invention to provide an improved data processing system.

It is another feature of the present invention to provide data systems with ability to efficiently manage windowed displays.

It is also a feature of the present invention to provide data systems in which user-supplied instructions directly effectuate windowed displays with no need for intervening software.

It is an additional feature of the present invention to provide data systems in which efficiency is enhanced by retaining the results of intermediate calculations relative to windowed displays.

- 3a -kh/ ~c.

.

r Other objects and advantayes o~ the present invention will by understood by those of ordinary sklll in the art, a~ter ~e~erring to the description o~ the preferred embodiments and the appended draw-ings wherein:

BRIEF nESC~IP~IO~ O~ T~E DRAWINGS:

Fi~. 1 is an ovexview of the prior art.

~ . 2-11 relate to the present invention~ wherein:

Fig. 2 i~ a block diagram of the method of the present inven~ion a~
practiced on a typical data processing system.

Fige 3 depicts a single window displayed on a screen Fig. ~ depic~s a forms descriptor.

Fig. 5 depicts two win~ows on a screen, one occluding the other.
.
.
Fig. 6.depict~ a orm control record ~cheme.

~igO 7 depicts a character font ~cheme.

Pig.~8 depict~ a bit map of a typical character in a character font.

Fig. 9 depic~s a display memory su~system.

Fig. 10 depicts the central processing unit of a digital computer sy~temO

Fig. 11 depicts the control subsystem of a digital computer system.

( RlCP~ION OF TE3E: PREFERE~ HBOD:lHl~NT:

INTR~UUCTION:

In the prior art, the management of windowed displays has ~een performed by sof~ware. This is illustrated in Fig. 1~ ~Fig. 1 does not purport to depic~ a data sys~em in it~ entirety, but only those elementfi that are necessary to generate and produ~e di~plays.~ The system i~ seen to comprise a central proce~ing unit ~C~U 101), a memory (102~, a display inter~ace ~109), and a display (110). User software 103 (resident in memory 102) may in~lude all manner of so~t-ware entities, including software calls for di~play ~ervices; ~uch 60~kware calls invoke system software 104 ~also resident in ~emory 102) which interprets t~e user's calls and presen~s to the CPU ins-truc~io~s which wil~ res~lt in carrying out the req~ests issued ~y t~e user ~of~ware. The sys~em softwa~e may interro~a~e t~e display data~ase 105 to determine ~e prevaous state o~ the display, and will upda~e the display da~a~ase so tha~ it reflects any changes brou~ht a~out ~y ~he current call from user software.
.
- . . .
S'~ill re~erring to ~ig. 1, ma~hine iangudge ins~ru~tions pre~ent-~d to CPU l01-by system ~o~twa~e 1~4 a~e decoded by element 106 which ~re~ardless of whether ~y "~ard-wired~ or microcoded means) directs arithmetic and loyic unit ~LU) 107 in executing the ins~rustions.
Note that these are all ~t~aditional" ins~ructi~ns (ADD, MOV, etc.) ~he descriptive information in display database 1~5 must all ~e re-proce~sed-in order to c~eate a new screen ~it ~ap 108, which would then contain a ~screen image~ of the display screen as it should now appear, ~eflecting the manipulations called for ~y ~he current calls ~rom user software. ~i~pla~ interface 109 ~regardless of whether by programmed I/O or Direct Memory Access means? reads and processes the bit map to generate appropriate signals to display 110 causing it to display the information specified in bit map 108.

Note that the term ~bit map~ is used herein by convention, and , _5_ 3t~

may denote a character map for a cha~acter-oriented display, o~ a yi~e~ or a pixel~oriented di~play:
.

-- On a character-oriented display, the smallest addres~able element is a chaxacter position, which may be occupied by any character from a defined ~ont o~ characters. The selec~
tion of which character is to occup~ a particular character position is made by placing the binary code representing that character in the corres~on~ïng position oL the bit ma~.

-- On a pixel-orien~ed display, ~he smallest ad~ressable ele-ment is essentially de~ermined by the size of the "dot n that would be made to appear on the screen ~y the elec~ron beam i~ it did not move. (~his is termed a ~picture element~, from which the ~erm npixel~ was coined.) In ~he sim~lest pixel bit map, a single bit position in the bit map repre sents each p:ixel position on ~he display; a ~1~ at a posi-tion in the bit map ~enotes il~umina~ion ~on" at t~e corres-ponding position on the screen, and "0~ ~enotes ~off~. ~n more cowplex i~ple~entationsr several bi~6 in the bit map represent ea~h pixel position on the ~isplay; a com~inatio. -several bits a$ a position in ~he bit map might ~enote -the in ensity level, or t~e c~l~r, or both, ~b be dis~làyed~
at t~e corresponding pixel position on the screen. - -The prior art approach can be success~ully implementedr ~ut it- ~:
has t~e di~advanta~es of introducin~ substantial overhead, because of the need to interpret all of the ~ser's cal~s and because t~e soft- -ware is isolated from t~o bit map by ~he CPU and is therefore con- -strained to completely reprocess descriptive information wheneve~ it is desired to change anything on the disp~ay. Such implementation~
have been co~fined to faixly powerful machines, on which ~ey u~e u~
a ~ubstantial proportion of the processing power. ~ :

The met~d of the present invention overcomes these disadvantages by enab~iny t~e construction of a data system in which ~pecial-~'7~

purpo~e mnchine-langunge lnstruct:Lons are avai:Lable for manlpulating data in windowed dlaplays, above and beyond -the traditlonal in~ltruction~ (~DD, MOV, and eo fottil). Since these Lnstruotiorl~ are directly execu-tabl~ by the CPU, no intervening ~ortware le re(llllrcd -to lnterpret them. Since -they execute directly in the CPU, whlch can include a scra-tchpad memory for encaching descriptive information, there i9 no need to reprocess descriptive information on every instruction. Thus the method of the present inven-tion uses significantly les~ of the proces~ing power of a given machine, or permits :implementation of windowed dlsplays on a smaller, less powerful mnchine -than is possible for a prior ar-t implementation.

DETAILED DESCRIPTION:

Instruction execution and form descriptor~:

The method of the present invention is depicted in Fig. 2.
(Fig. 2 does not purpor-t to depict all elements of a data system, but only tho~e element~ necessary to generate and produce displays. All hardware element~ of a data sy~tem on which the method of the pre~en-t invention is currently embodied are shown for reference in ~'igs. lO
and ll.) The data sy~tem i9 again seen to comprise a CP~ (201), a memory (202), a display interface (203) and a display; in thi~
particular embodiment the di~play i9 a pixel-oriented video monitor (204) and not a character-oriented terminal. (Display interface 203 is, of course, an appropriate one to drive a video monitor. Two-bit pixels are employed; for a black-and-white monitor they ccnnote a four-step grey scale, and for a color monitor they connote "Off"
(black), "Red", "Green", or "Blue".) User software 208 i~ seen not to be constrained to software calls for manipulating the bit map in order to a-ffect displays, but may now Ich/

~: .

al~o contain in~truction~ which wlll directly stimulate CPU 201 for ~hat purpose. ~hese are special-purpose instructions and permit CPU
hardware to dlrectly construct "~c~een imagesn in the bit ~ap, which is inherently fa~ more efficient than manipulating the bit map by mean~ o~ traditio~al instructions, to which the bit map i.s an abs~
traction.
It is also 6een that form descriptors 209 are required. Some defini~ions are in order at thi~ point: .

-- The attributes o~ a win~ow (e,g., its height, wid~h, charac-teristics of what it may con~ain, etc. ~ collectively com-prise a ~form~. As windows are manipulated, some may become invisible-- but their or~s continue to exist.

-- A data entity con~aining t~e data specifying a form is known as a ~form descriptor~. In order for a window to have ex-istence, a form descri~tor must have ~een provided for it.

Still referring to FigO 2, it is seen that user sotware 208 ~ay make software call~ to a ~iece of ~y~tem software c~.lled t~e window ` mar.agee ~210), which ma~ p~oduce f~rm ~escrLpt~rs~ ~ ~ser may, if~;
i she wishes, provide he~ own form descriptors, but ~e capabili~y exists to have the window mana~er ~rovide th~m for her~ This ~s desirable in a multi~user, mul~i-program, or multi-~rocess en~iron-I ment to arbitrate among the various users, programs, or processes ! -that are contending for window space on the same ~hysical screen.
., Each special display instruction contains a re~erence to a form descriptor, which the CPU will retrieve as discussed below, and which the CPU will use to modiy the effect of the instruction. This e~-a~les windowed display management capability to be taken out of soft-ware and placed directly into hardware.

Instructions or writing into windows are presented by user soft-ware 208 to CPU 201 where they are interpreted by n,icrocode unit 205, ~ 3 which in re~pon~e to each in~truction ~e~che6 ~n appropriate ~equence o~ microinstructio~ls to direct ALU 207 in performing the instruction.

As mentloned~ each such instruction contains a reference to a form descriptor. ALU 207 interrogates the forms control record~ 212 (t~ be ~i~cussed in more de-tail further on) to determine whether the ~orm descriptor is encached in 6cra~chpad memory ~06, or stored ân foEms cache overflow 213); i~ the lattert it is retri~ved from forms ca~e overflow 213 and restored to scra~ch pad memo~y ~06 ~possibl~
displacing another form de~cri~tor, which is saved in ~orms cache over~low 213); if neither, the form descrip~or is retrieved fro~ the list o~ user-supplied forms ~escriptors 209, -transformed into inter-nal form, and encached in scr~c~ad memory 206.
.

~ he tra~sformation to inte~nal form consist~ o~ calculatin~
screen-~lobal coordinates ~rom wi~dow-local coordinates provided by the user in the orm descriptor. ~The ~er is not required ~o know where on ~he screen her window is loca~ed. Also, a window may sub-sequently be moved around on ~he screent and user conve~ience is enhanced i~ the user is not required to provide new coor~inates o~
ea~h n~w position.) ~eferring to Fi~. 3, a window positioned o~ a screèn .i.s de~icted. ~it~in ~e window are a u~er-specified orisin ~o~ (307) ~the u~e~ may speci~y coordinates in the win~ow relative to ~his origin) and a poînt ~'P~ (3V8~ at s~hich the user may wish to operate. Listed o~ FigO 3 are the glo~al coordinates of ~he corne~s of the screen, and the global and local coo~dinates of ~oints o interest of the window- i~s four corner~r the origin ~O~, and ~be point ~pu. In the user-supplied form descriptor, the user is requi~-ed to specify the height and width of the window (in pixels), and the local coordinates (relative to the origin UO") O~ the window's U~C
(upper le~t corner~. ~Note that this im~licitly specifies the loca-tion o~ the origin ~OU.) Fig. 4 depic~s a form descriptor in internal form. The transfor-mati~n spoken of consists in calculating and filling in the glo~al coordinates of the window's ULC (409 and 410~ and a pointer to glo~al .

_g_ ~ 7~4~
0,0 (BlS). Since the ~orm descriptor call now be encached a~ a ~ormR
cache entry, ~here is no need to recalculate 6uch informa~ion on subsequen~ references to the same window.

Again with ~eference ~o Fig. 3 and Fig~ 4, suppo~e that the u~er de~ire5 to operate at point P (308~. The encached form descriptor supplie6 vectors AE (~'s glo~al coordinates 409, 410) and OE (E's local coordinates 413, 414). Instruction inputs supply vector OP
(P'~ local coordinates: XL,YL relative to'the origln 307). The vec-~or AP i~ calcul~ted as part of executing the instr~ction.
!
Returning to Fig. 2, the scratchpad memor~, then, alwa~s contains ~e t~ansformed version~ of the "nn mo~ recen~ly us~ed ~orms descrip-tors. This can greatly accelerate execution~ since in ~ractice many forms w~ll often be u~ed repeti~tively. (The determination o~ the value of i~n" is left to the designers of a particula~ e~bodiment.) Since bit map 215 con~ains an image of what is to be displayed on the ~creen, execution of ~he present instruction ma~ ~e rega{ded as complete when bit map 215 is upda~ed to corltain the new display in-formation specified ~ ~he cuirrent instruction. Transla~ing t~e bit ~a~ t4 ~ visible display is a function of di~play in~er~a~e 203, t~e ~i~ing o~ which is asynchr~nous to the timing o~ instruction execu-~ion.

AL~ 20~ may inter~ogate the previous contents of bit map 215 if t~e operation c~lled for by the present in~truction is a fun~tion of ~he previous display. ALU 2~7 will write an appropriate new portion of bit map ~lS to result in a corresponding new display on video monitor 204~

The method will not permit a user to write outside of the window he has referenced. For example, i~ a ~ser instruction specified a hori~ontal line ~00 pixels long in a window that is only 200 pixels wide, only that po~tion of the line that fits within the window is written to bit map 215, and the rest is ignored~ This is known as --1 0 ~

'7~
"clipping". In order to inform the u~er that clipping has been performed, a carry indication is re-turned to her upon completion of the instruction.

Note that bit map 215 i~ contained in VRAM'~ (video random acces~ memory chip~). The VRAM's are acce~ible to the ALU ju~t a~
any other portion of main memory. What is different about the VRAM's i~ that they possess a special provision for rapid unloading to display interface 203, a~ will be discussed later in the Di~play Memory section.

OCCLUSION: ("BROKEN WINDOWS"):

A complication occurs in the describing proces~ when a window is occluded (partially covered) by another window. I~eferring to Fig. 5, it i8 ~een that Window A (502) is partially covering Window B (501). Prior to this occlu~ion, the proces3ing was able to regard Window B a~ a single entity, but must now regard it as a complex entity made up of several simple entities -- Panes Bl, B2, and B~. (The term "pane" denotes a portion of a window.) In order to keep the ~imple entities as simple as po~ible, the con~traint i~
imposed that panes must always be rectangular -- i.e., the method does not allow consideration of the occluded rectangle and the L-shaped remainder, but requires division of the L-shaped remainder into two rectangles, B2 and B3.

The user of window B is not required to know that this occlusion has occurred (it may have been caused by a different user, program, or proce~s), and hence does not bear the burden of providing form descriptors for the panes -- the method does this automatically and in a manner that is transparent to the user. A form descriptor describing a rectangle is known a~ a "simple form descriptor". (The form descriptors provided by the user, deacribing entire windows, are simple form descriptors.) When occlusion requires breaking a window into panes, the processing will automatically create new simple form descriptors for the panes, and will create a "complex form descrip-kh/~

tor" or the window. In Euture embodiment~ ~hi~ automatic crea~ionmay take place under con~rol o~ microcodel bu~ in the present embodi-ment it i8 done by software, invoked by the microcode-to-~oftware fault capa~llity, to be discussed further on, which invokes ~a~lt ~andler~ 211.

A complex form descri~tor for a window e6~entially comprises a li6t o~ pointer~ to the simple form descriptors for the panes ~aking up that window. In the current embodimen~, these pointers exist in forms control records 212. Another u~e o~ the ~orms control records i5 to keep track of the location6 o~ bit maps of panes and windows.
When a pane becomes occluded, the data that were displayed on it are no~ be di~played any longer, indicating that ~he corre~ponding l~ca-~ions in bit map 215 will ~e overwrit~en ~y the da~a for the occlud-ing window. Rather than discard t~is information, which wo~ld neces-sitate recomputing it later when the pane is to become visible a~ain, i or- when the user wishes to manipulate data within the ~ane (recall that it is possible to ~ani~ulate data in an invisible ~ane), it is retained as an qoff-screen bit map~ ~214) in main memory. Re~erring to Fiq. 6, whic~ depicts the for~s control records entries tha~ re-flect the occlusion sit~ation depicted in Fig~ ~, it i~ ~een that Mas~.er:~FOr~ Control Record 6~1 cont~ins po~nters to ~rms co~ ol - .- . ~ - ..
record. A (602~ and B ~605) (for windows A and ~ or~s con~rol reco~d A poil2ts to fo~m descriptor A and to window P~'s bit map (the locatiotl within bit map 215 where the information for k~indow A is ored).
- -~
Prior ~o occlusion, window B ' s form control ~ecord structure was 6imilar. to the structure ~us'c described for window Ao Upon detecting the occurrerlce of occlusion, however~ the processing makes up new form descriptors for panes Bl, B2, and B3; moves pane Bl's bit map data from bit map 215 to off-screen bit map 214; and makes up a new for~ control record 60S, w~ich contains pointers (606, 608, and 610) ~o the three new ~orm descriptors, and pointe~s to Bl I s off-screen bit ~iap (607~ B2's bit map (609), and B3 ' s bit map ~611) .

i ~Xq3~9 Subsequent user in~-tructions to manipula-te window B can now be handled. For example, (referring to ~ig. 5) if the user specifies a line from I to J in window B, processing will automatically translate -that to three requeata: one for line I-I' in pane B~, one for line I'-J' in pane ~1, and one for ~ine J'-J in pane ~2. (For ~implicity, the -three requests might each call for the full line I-J, and the clipping function previously described would result in writing in each pane only the segments that fall within those pane~.) Handling these three requeata will, a~ uaual, reault in recording the line in the bit mapa for the three panea. Ilowever, ~ince pane Bl ia presently occluded, line I'-J' ia written into -the off-screen bit map and will not presently be visible on the display.
Subsequent removal of window A will result in reconstitu-ting the ~imple form de~criptor for window B, discarding the complex form descriptor for window B and -the simple form descriptors for panes Bl, B2, and B3, and moving pane Bl'a bit map information from the off-acreen bit map 214 to bit map 215; thus the complete line I-J
will become visible even though part of it was invisible when drawn.

The de~cribed interception of the request to draw the line I-J and re~olving it into three reque~ts may in future embodiment~ be performed by the CPU under microcode control, but in the pre3ent embodiment it ia performed by ~oftware invoked by microcode-to-aoftware fault 216.

MICROCODE-TO-SOF'~WARE FAUIT:

Microcode-to-software fault is the mechaniam that permits taking complex issues out of microcode and into software in the current embodiment while leaving the way clear to cons-truct improved fu-ture embodiments with more functions performed by microcode. It also provides a guide for implementation ataging and for migration of functionality up and down.

When an operation lnitiates, microcode must de-termine whether i-t can do the operation, and whether it can deal with the form~ on which it must operate. If the anawer ia no in either case, -- 1~ -kh/mla . . ~.

~2~
the microcode must "fault" (or "escape") to sof-tware. A fault handler address i8 supplied as part of each instruction. Thu~, there can be a plurality of fault hnndlers.

The faul-t handler will emulate the requested opera-tion, subdividing forms if neceæsary (as deæcribed above), and using more primitive instructions if necesæary. The invoking program is resumed via the WPOPJ instruction of the Data General 32-bit instruction set. Recursive faults are thuæ supported implicitly.

The combination of faulting mechanism, clipping, and window-local coordinate systems gives a unique benefit: a display-affecting operation on a complex window is equivalent to the same operation applied in turn to all conætituent simple windows. The user is thus relieved of responsibility for complex windows.

Diaplayable Data l~pe~.

Depending on the particular instruction (see Appendix A) operands denoting what the user to wishes to write in her windows may be immediate operands (contained in the instruction), or the instruction may contain a pointer to data outside the instruction (element 217 in Fig. 2). Explanation of various data types is here provided.

Linestyle~

Linestyle is a way of drawing other than solid lineæ.
Specified as a bit string of leng-th ~2, it controls which pixels computed during line drawing are actually to be planteù. For each draw position, the leftmost bit in the linestyle is examined. If set, the pixel is planted; if clear, no change occurs. The linestyle is rotated left one bit position, and the next draw position is computed. Examples of linestyle (expresæed in hexadecimal) are:

-- 1~ --kh/~

~Z~'7~3 FFFFFFFF: solid AAAAAAAA: somewhat grey FOFOFOFO: almost dotted FFFOFFFO: long dashes FFFFOFFO: long/short dashes FFFFF060: dash-dot ~8888888: very faint FFFF0660: dash-dot-dot Forts Fonts are sets of special forms that are used by character-drawing operations. They are descriptions of how each individual character is to be drawn. This description (not necessarily in bit map form) must be translated into actual screen-relevan-t format before drawing can occur. Conditioning for character height and width must be performed. Alignment and padding may also be required. This latter enti-ty is a "strike font". Character instructions deal in strike fonts specified by denoting a Strike Font Descriptor. Fig. 7 depicts -this scheme.

A font organi~ation has been chosen that uses one bi-t per pixel. Scan lines are padded to a power-of-two number of bits, and occupy successive memory locations. Each scan line must ~-tart on a boundary equal to its width. The number of scan lines must also be a power of two. All characters in a font occupy the same amount of space, implicitly a power-of-two number of bits. The first scan line of a strike cell is not drawn. It identifies with ONE's those columns which make up the proportionally spaced sub~et of the cell.
Fig. 8 shows the layout of a 12x24 strike font entry for the character "1".

Character drawing is controlled by a linestyle-iike process. Conceptually, a character drawn by "strip mining" its strike font entry row-wise. Each bit of the row is examined in turn, ignoring in proportional spacing mode these columns wi-th ZE~O's in the control line. If l, then a drawing-colored (foreground) pixel is ~0 ~ourced. If 0, a background-colored pixel is sourced instead.

kh/l"

Sourced pixel values are subjected to prin-t control; ~oreground and background pixels can be suppressed independently. This allows for trial spacing (no printing a-t all), drawing characters on an existing background, and drawing characters and background simultaneously tall subject to further combination rules outlined below). A 2-bi-t print s-tyle is defined O O ___O_ ________________________________O
~ Fore- ~ Back- ~ Printing Effect 10 ~ ground ~ ground ~ Font=1 --> foreground pixel ~ Suppress ~ Suppress ~ Font=O --> background pixel +___________~___________+__________________________________ O ~ O ~ Plan-t all pixels of cell O ~ 1 ~ Plant foreground pixels only 1 ~ O ~ Plant background pixels only Plant nothing, just count space ______O__________________________________O

C~mbinati~n ~ules Many of the instructions will employ a Combination Rule to deal with superposition of source pixels on destination pixels. One does no-t always wish s-tric-tly to replace the des-tination pixel with thè source pixel; it may be desired to plant a pixel whose valus is some func-tion of source and destination. This implies that destination may also be an inpu-t.
A scheme has been adopted in which is specified a single BOOL-rule and a mask that applies to logical pixels.
The bi-ts of the logical pixel corresponding to Os are unchanged in the targe-t form; those corresponding to 1s are combined according to the BOOL-rule. The logical pixels are already only the rightmost bits of a physical pixel~

mls/JC

Access Methods By way o~ defining the instruc-tions, graphics practice reveals -tha-t cer-tain "favorite" operations are performed frequen-tly, including:
reading or writing a pixel's value * moving a rectangular area of pixels around.
* drawing a line or series of connected line segmen-ts.
~ filling a polygonal area with a pattern.
* drawing a string of ASCII characters.
These opera-tions comprise three major methods of drawing on a display: pixels, figures, and characters.

Character Acce~s Method This method provides ways to plant tex-t in a window. The Gharacter Bleck Transfer (CHARBLT) ins~ruction allows for arbitray font specification in translating ASCII
character strings to their pixel representations. It also checks for characters that may require special handling.

Figure Access Method Drawing a line is an important part of technical computer graphics. It is used in CAD/CAM packages, architectural design packages, and business graphics packages. Since this operation is performed so often, special instructions are provided. Both con-tinuous (LINESEG) and incremental (BRESENHAM-STEP) forms of line drawing are included. Lines can be drawn closed, half-open, mls/JC

or fully open. The ac-tual algorithm mus-t be reversible so as to make things such as line erasure precise. A line wid-th argument has been included to support this func-tion at -the low level.

Pi~el ~ccess Method This access method deals with individual pixels and rec-tangular areas of them. It can serve as the foundation of higher-level accessing methods, so -that users can create their own display manipula-tion instructions (for image manipulation, conic section generation3 etc.) Read Pixel and Write Pixel operators allow direct access to pixels. Although only thesa two operations are strictly necessary to do the job, higher level operations are much more common.
These are the only drawing instructions that do not take a combination rule specifier. They are intended as the simplest of all building blocks. The modal of use is one of many WRPIXELs to the same form in rapid sequence.
A Bit Block Transfer operator is a very useful pixel-level operator. It is essentially a rectangular combination and assignment function. This is done especially when scrolling windows, moving windows around, and creating and dastroying windows that obscure other windows. A special rectangular fill operation is also useful for dealing with clearing screens and repartitioning windows.
BITBLT is the only operation that takes two ~orms, _ 18 -mls/JC

~2~'7~

since certain re3trictions are placed on source and targetforms. Source legical pixels will be padded or chopped to conform to the target ~orm's parame-ters.

Instruction Repertoire All display-affecting instructions share a common instruction stream format. The first 16-bit word of all such instruc-tions is Octal 107151 (hexadecimal 8E69, Nova ADDOB# 2,0,SKP). The next two 16-bit words hold a program counter-relative offset (non-indirectable), of a so~tware emulator/fault handler. The fourth 16-bit word contains a small, unsigned integer sub-opcode that specifies the particular function to be performed.

Primary ~ : ~ Secondary ~GIS Opcode ~ Displacement to Emulator Code ~ Sub-opcode ~l ~107151 octal ~ : ~ for ~unction O_____________O __________ _ _ O

RDPIXEL (Read Pixel)............ O
WRPIXEL (Write Pixel)......... ... 1 RDPAL (Read Palette Entry)...... 2 WRPAL (Write Palette Entry)..... 3 LINESEG (Draw Line Segment)......
BITBLT (Bit Block Transfer)..... 5 CHARBLT (Write Characters)...... 6 PFORMS (Purge Form Cache)....... 7 NOTE: "GIS" = "Graphics Instruction Set"
A full delineation of the repertoire of display-affec-ting instructions is found in Appendix A.

Display Memory Module The screen bit map (215 on Fig. 2) is maintained in a special area of main memory know as display memory or mls/JC

~L2~

video memory. An embodiment of vicleo memory for a black-and-whlte monitor is now described.
Referring to Fig. 9, video memory 901 is composed of thir-ty-two 64K Video RAMs (VRAMs) and i9 organized into a 1024 x 1024 x 2 space, permitting two-bit-pixel representation of a screen 1024 pixels high by 1024 pixels wide. RS-343A moni-tor timing allows display of the entire array. A free-running blink clock selects one of two complete palettes (904) capable of mapping any pixel value 10 to one of four levels of gray (O=black to 3=white). Palette I/O and other local operations are transacted through "Graphics Space", actually encoded as the IOC Auxilliary Processor (AP) Communication channel. In order to support the "Register-Transfer" function peculiar to VRAMs and additional diagnostic and boot-time character drawing, display memory timing and control logic will arbitrate for the memory bus as a requestor through memory bus interface 902.

VIDEO MEMORI PROPER
~0 The 64K double-word (i.e., 32-bit) video memory is manipulated by the CPU as normal system memory. The screen is generated from a logical bit-map packed within a linear array of double-words which are ordered in the classical sense of lef-t-to-righ-t and top-to-bottom. Two bi-t pixels will be packed left-to-right with their msb's toward the double-word msb.
Texas Instruments VRAM random access cycles are mls/JC

'~2~3 17~
essen-tially identical wi-th those of standard DRAMs. Their unique charac-teristic is -the ability to transfer an entire 256 bi-t row of internal s-torage to a serial shif-t register (903) in one special access. This register may then be clocked independently o~ ~urther random acce99 activity.
Additional controls allow multiplexing four 64 bit sections of this l'OW register to aid in configurability.

Timing and Control Dot and CRT timing will be derived from a local oscillator opera-ting at approximately 44 MHz. Due to the independent nature of VRAM serial clocking, no explicit synchronization with exi~ting memory timing, other than the arbitration for register-transfer cycles, is required.
specific VRAM row and mux address sequence must be maintained to properly refresh the interlaced display.
Relatively simple multiplexing will be all that is required to pass pixel values to the palette. The above capabilities are optimally satisfied by an intelligent micro-controller (uC) (906), the Intel~ 8051 being the best choice in that minimal cost and CEQs will result, although an 8031/2732 EPROM implementation may be utilized in furture embodiments.

Rotate and Merge Logic 905 In the course of analyzing the microcode necessary to implement the BITBLT instruction, a need was noted to accelerate graphics memory references on arbitrary bit boundaries. Consequently, the hardware required to mls/JC

J~

implement -this function as a Memory-Bus-residen-t device was developed. A control bit specifies -the direction of the merge sequence. A "merge-enable" bit is also avai:Lable in order not to preclude a circular "rotate-only~'. All references are made via Graphics Space UABAs.

The Palette & DAC
The present embodiment uses a pixel value as simply an index into a palette. A palette is a special hardware map, which translates pixel values to (digital~
beam intensities. Instructions exist to set and retrieve pixel-to-color translations. The palette is organized as a 4 x 2 x 2 array arranged within a single double-word of storage. Two-bit pale-tte data written through -the AP
Graphics Space will encode the desired gray level to be associated with a given pixel value for each phase of the blink clock in palette multiplexor 907. Although direct reading of this register is not available, microcode will maintain an image of it in a single scratchpad loca-tion.
The EDH13400 DAC (digital-to-analog converter 908) will be utilized to produce the analog composlte-video signal. Red, ~reen, and Blue outputs are available; for the mon~chrome monitor the signal will be forwarded on the Green output.
The DAC not only performs sync-mixing, but is capable of direct 75-Ohm drive, and will be available in a 24-pin, 600 mil ceramic package.

mls/JC

Blinking The presen-t embodiment provides a "blink clock".
It-toggles the palette with a 50% duty cycle at a fixed rate of about 1.0-1.5 Hz. Thus, there are two palettes, one for each phase of the Blink Clock. Entries in the two pQlette~
are specified separately. This allows a user to program a given Pixel Value to alternate between two levels of intensi-ty (or two colors on a color display). The chart below shows some of the effec-ts possible using this palette scheme for two-bit pixels. Individual palette entries specify four intensi-ties as 32-bit unsigned binary fractions between zero and one.

O__________O_______________O_______________O________ _O
11 ~I 11 11 11 1I Pixel ~ Phase-0 11 Phase-1 ~ visual 1I Value 1I Palette 11 Palette ~ effect +__________~_______________+_______________+__________+

1l 00 1I black 11 black 11 off 11 01 ~ dim white ~ dim white ~ dim 1l 10 ~ white ~ white ~ on 11 1l 11 ~ black ~ ~hite ~ blink O________ O__ O O O
Monitor Characteristics In that ~S-343A video is provided, a 19" off-the-shelf monitor is used. The sync-on-green analog interface will be cabled directly via coax from backplane pins to the monitor BNC connector.

Memory Programming UABA Encodings The following table summarizes the display memory mls/JC

UA~A ~ncodings which will be supported by graphics microcode:
FUNCTION API APIDO71 BCMDO,1 IOC Equivalent Command WR 1 01 00 "Instruction to IOC"
Status RD 1 01 00 "Instruction to IOC"
[ unused ] O 01 00 "Data to IOC"
Palet-te WR O 01 01 "Data from IOC"
Skew Reg WR O 00 10 "Microcode to IOC"
Merged Data RD O 01 11 "Abort IOC"
The inven-tion may be embodied in yet other specific forms without depar-ting from the spirit or essential characteristics thereof. Thus, the present embodiments are to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

mls/JC

APPENDIX ~
INSTRUCTION DICTION~RY

RDPIXEL [107151,000000~
This in6truction reads a sinyle pixel from a form and returns its val~e masked to the form's logical pixel width. If the ~peci~
~ied pixel i6 out~ide the boundaries o~ the form, then no value is returned. Insteadr a clipping indication is returned in Carry.
INPUTS
AC0: ignored ACl: INTEGER local X-coordinate AC2: INTEGER local Y-coordinate AC3- POINTER TO Form Desceiptor ~UTPUTS
AC0: O~DINAL Logical Pixel ~alue (i~ in form) unchanged (if ~oint not in form) ACl: unchanged AC2: unchanged AC3s unchanyed C~ SET if [X,Y~ not in Form, unchanged otherwise.
o~5 ~ 9~3 ~ 1107151,000001]

pale~trmbaSslglcal pixel width Pidel valUe ln a ~orm INPUTS
AC0: ORDINAL Logical Pixel Yalue ACl: INTEGER local X-coordinate AC2: INTEGER local Y-coordinate AC3: POIN~ER TO Form Descri~tor OUTPUT~
AC0: unchanyed I ACl: unchanged AC2: unchanged AC3: unchanged C: SET i~ lX,Y] not in Form, unchanged otherwise.
MET~OD
l) Start ~ith the Logical P1xel Yalue from AC~
2~ AND it with the Form's Logical Pixel Mask to remove any stray high order bits O~ in the For~'s Logical Palette Base to turn local color i~to global -color.
~) Plant the P~ysical Pixel Yalue at [X,Y~

-~2-.l~d ~

L~NESEG [107151,0000041 This instruction draws a single line segment. The control packet contain~ our items that are updated ~or restartability: X-and Y-off~ets, ep~ilon, and the rotated linestyle specifier.
I~PUTS
AC0: POINTER TO Endpoint 1 ~X,Y~ pair ACl: POINTER TO Endpoint 2 [X,Y] pair AC2: POINTER TO LINESEG Packet .INTEGER X-delta (for restart) .INTEGER Y-delta ~or res~art) .INTEGER Epsilon (~or res~art) .BIT(3~) Linestyle (updated) .BIT(32) Operation Ma~k .BIT(32) Control Word:
~BIT(01~ ~up~res~ ~ndpoint 1 .BIT~01) Sup~ress Endpoint 2 .BIT~26) ~iller, must be zero ~BIT(04) Com~ination Rule .ORDINAL Pixel Yalue ~or Drawing ,O~DINAL Line Width AC3: POINTER TO Form Descriptor OUTPUTS
~C0: unchan~ed ACl; unchanged AC2: unchanged X-delta in packet updated Y-delta in pac~et u~dated Epsilon in packet updated . hinestyle kotated~ in ~acket updated AC3: unchanged C: SET if clipping occurred, unchanged otherwise /

-~3-C~AR~LT [107151,000006]
This instruction plants characters in a form uslng gl~phs held in a Font. The data manipulated b~ CUARBLT fall into ~our categories: string data, font data, form data, and other opera-tional paramenter~ Accordingly, this instruction takes pointers in all 4 ACs. It also is the only one of the initial GIS to take a skip return on final (sic) completion.
INPUTS
AC0: POINTER TO Stri~g Packet .BYTEPOINTER TO Character $tring ll-origin) .ORDINAL ~aximum Index into String .ORDINAL Starting Index in S~ring (u~dated~
ACl: POINTER TO C~A~BLT Packet .INT~GER X-start (restart value, up~ated) .~NTEGER Y-sta~t (res~art value, updated) .ORDIN~L X-delta (initially 0, updated) .ORDINAL Y-delta (initially 0, u~dated) .ORDINAL Foreground (drawing) Pixel ~alue .ORDINAL Background Pixel ~alue .BIT(32) Operation Mask .BIT(32) Control Word .BIT(01) Suppress Foreground .BIT(01) Suppress Background .~IT~01) Space ~roportionally .~T(2~) Filler, must be zero .BIT(04) C~mbination Rule .POINTER TO Exception Bit-Vector AC2: POINTER TO Font Descriptor ~ORDINAL ~eig~t of character cell (in lines) OR~ L Width ~f ;nonosp~ce character ceil .ORDINAL Strike font cell width (in b~ts) .ORDINAL Strike font cell height (in lines) .POINTER TO Strike Font Bitmap AC3: POI~TER TO Form Descriptor ~UTPlJTS
AC0: unchanged (string index updated in packet) ACl: unchanged (X-startr Y-start, X-delta, Y-delta updated) AC2: unchanged AC3: unchanged C: SET if any clipping occurred, unchanyed otherwise PC: Set to PC~4 if string denoted by ACQ exhausted. Otherwise, execution ~kips to PCt5 if a character exception is indi-cated by a 1 in the bit vector (like CMT) denoted throug~
ACl.
M~T~OD
1) I~ XDEL~A, YDELTA not bo~h zero then resume character drawing from interrupt point within character.

~ 2 ~ ~9~

2) Eor each character in ~he ~tring starting at SINDEX, repeat the following steps:

3~ Eetch current character, STRING[SINDEX~, and call it C~

4) If EXCEPTIONS ~C] is 1 then ~done" and skip, PC :~ PC~5;
S) Locate the strike font cell for C's glyph. The ~irst ~it is at the offset yiven by the product of the integer value of the character r the fitrike cell width, and the strike cell hei~ht.
6) If proportional, u6e the first scan line as a control mask, ignoring columns corresponding to Os in the mask. The number of ls is therefore the width of the ~articular character in proportional spacing. If monospace, ignore the first lineO
~) Scan the lines of the fon entry, determining and planting foreground and background pixels as described in GISoO02t under control of the operation mask, print control, and com~o rule.
8) Bump XSTART by character width and SINDEX by one.
9) If SINDEX > MAXINDEX then done at PC := PC~4, el~e re~ea~.
10~ When done, SINDEX ~ ~AXINDEX*l, and XDELTA and Y~ELTA are both zero.

~q ( ;

BITBLT [107151,000005~
Pixels startillg from the ULC o~ the Source Rectangle in t~le Source Form are paired with pixels starting at the ULC of the ~arget Rectangle of the Target Form. Consistent with the boundar~
ies o~ both forms, source and target pixels are (optionally~
c~mbined and the target pixel replaced.
This must be done in such a way that no target pixel is modi~ied before it is used as a ~ource pixel, since source and ~arget boxes may overlap. BITBLT never smears pixels the way that WC;~V smears characters. BITBLT must choose the correct ~irection ~or walking the two rectanglesO
~PUTS
AC0: ignored ACl: ~OINTER TO BITBLT Packet .INTEGER X-delta (initially 0, for restart) .INTEGER Y-delta (initially 0, for restart) .POINTER TO Source Start ULC Speci~ier .-~OINTER TO Target Start ULC S~ecifier .ORDINAL X-extent (in pixels) .O~DINAL Y-extent (in pixels~
.BIT(32) Operation ~ask .BIT(32) Combina~ion Rule ~low 4 bits~
AC2: POI~TE~ TO (So~rce) ~orm Descriptor AC3: POINTER TO ~a~get) Form Descriptor OUTPUTS
AC0: unchang~d AC~: unchanged (X-delta, Y-delta up~ated) AC2: unchanged AC3: unchanged C: SET if clipping occurred, unchan~ed otherwise ~3 RDPAL 1107151,000002~
This instcuction retrieves the contents o~ a palette entry for a pacticular pixel value within the context of a given orm. It reflects the actual intensities stored in the palette, rather than the values that were input to a prior WRPAL (Write Palette).
I~PUTS
AC0: ORDINAL Logical Pixel Value ~relative to Form) ACl: POINTER TO Phase 0 RGBL-~uple .BIT(32) Red Intensity ti~nore~) .BIT(32) Green Intensity ~ignored~
.BIT(32) Blue Intensity (ignored) ~BIT(32) Gre~-L2vel (ignored) AC2: POINTER TO Phase 1 RGBL-~uple .BIT(32~ Red In~ensity (ignored) .B~T(32~ Green Inten~ity (ignored) .BIT(32) Blue InteRsity (i~nored) oBIT(32~ Grey-~evel ~ignored) AC3: POINTER TO Form Descriptor OUTPUTS
AC0; unchanged ACl: unchanged. POINTER ~0 Phase 0 R~BL-~uple ~81T(32~ Red Intensity (undefined if mono~
~BI~132) Green Intensity ~undefi~ed if mono) ~BIT~32) Blue ~ntensity ~undefined if mono) ~B~T(32) Grey-Level (undefined if color~
AC2: unchanged, POINTE~ TO Phase 1 RGBL-Tuple .BI~(32~ Red ~ntensity ~undefined if mono~
.B~T~32) Green Intensi~y ~unde~ined if mono) .BIT~323 Blue Intensity (undefined if mono) .BIT(32) Grey-Level (undefined if color) AC3: unchanged MET~OD
1) The physical palet~te unit is identified using the unit desi~nation cell of t~e form descriptor.
2) The logical pixel value input in AC0 is masked with the Lo~ical Pixel Mask of the form denoted by AC3.
3) The actual physical palette index is computed by ORing the Logical Palette Base from that same form descriptor.
4) The RGBL-tuples returned reflect the actual resolutions of the imple~entation.

5) Color implementations render L-slots undefined; Monochrome implementations render ~GB-slots undefined.

6~ Blink-less i~plementations render Phase-l tuples undefined.

; 3~

j WRPAL ~107151,000003~
This instruction sets up palette entries ~or both pha~es of the blink clock (if one exists). It allows color and gre~-level to ~e specified independently. It is assumed that control so~tware sets up the tarqet form's Palette Base and prevents abuse of the ~RPAL.
INPUTS
ACOo O~DINAL Logical Pixel Value (relative to Form) ACl: POINTER TO Phase 0 RGB~-Tuple .BIT~32) Red Intensity (ignored if mono) .BIT(32) Green Intensity (ignored if mono) .BIT~32~ Blue Intensity (ignored if mono) .BIT(32) Grey-Level (ignored if color) AC2^ ~OINTER TO Phase 1 RGB~-Tu~le .BIT(32) Red In~ensity (ignored if mono) .BIT~32~ Green In~ensity (ignored if mono) .BIT(323 Blue In~ensity (ignored if mono) .BIT(32) Grey-Level (ignored if color) AC3: POINTER TO Form Descriptor l:)UTPUTS
AC0: unchan~ed ACl: un~hanged AC2: unchanqea AC3: unchange~
MET~OD
- 1) The p~ysical palette unit is identified using the ~nit designation cell of the form descri~tor.
2) Th~ logical pixel value input in AG0 is mas~ed usin~ the Form Mas~ found in the form descriptor denoted ~y AC3.
3) The physical palette index is computed by ORing the indi-cated form's Logical Palette Base to t~e masked pixel value.
4) ~on-color implementations ignore RGB intensities; color implemen~ations ignoret gre~-level.
5~ RGBL values are truncated on the right to internal palette resolution.
6) Blink-less implementations ignore Phase-l color.

~ 3 PFOR~S -1107151,000007~
This function perorms the form cache equivalent o~ PATU
~Purge the ATU) or SPTE (Set Page Table Entry). LSB~S and LSBRA
~Load Some/All Seyment Base Registers) may also invalidate associa-tions o~ logical address to form de~criptor information. Thus P~oRMs mus~ also occur as an implicit consequence of executing any o~ the above instructions, INPUTS
AC0: ignored ACl: ignored AC2: ignored AC3: POINTER TO Form Descriptor OUTPUTS
AC0: unchangea ACl: unchanged AC2: unchanged AC3: unchanged 3~3

Claims (10)

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:

1. A method for controlling the displays of a digital computer system, the system comprising:
main memory means for storing instructions and data;
processing means for performing operations on data in response to the instructions; and display means for displaying representations of data;
the method comprising the steps of:
a) storing in the main memory means form descriptors for describing organization of data to be displayed;
b) storing in the main memory means instructions for specifying first data and for specifying representations of first data which are to be displayed, and for describing the position within the organization described by the form descriptors at which the representations of the first data are to be displayed;
c) selecting an instruction and a form descriptor to obtain a selected instruction and a selected form descriptor;
d) calculating, in the processing means, second certain data which is a function of the selected instruction, the selected form descriptor, and certain first data specified by the selected instruction, the second certain data being a representation of what is to be displayed; and, e) forwarding the second certain data to the display means for representations of the second certain data to be displayed.

2. The method of claim 1, wherein in step d) the second certain data is further a function of previous second certain data, in addition to being a function of the selected instruction, the selected form descriptor, and certain first data specified by the selected instruction.

3. The method of claim 1 wherein:
the processing means of the digital computer system on which the method is practiced includes a scratchpad memory means, in which data can be stored significantly more rapidly than in the main memory means, and from which data can be retrieved significantly more rapidly than from the main memory means;
and wherein step d) is immediately preceded by:
c1) determining whether the selected form descriptor is encached in the scratchpad memory means;
c2) if the selected form descriptor is encached in the scratchpad memory means, retrieving it therefrom;
c3) if the selected form descriptor is not encached in the scratchpad memory means, retrieving it from the main memory means and encaching it in the scratch-pad memory means.

4. The method of claim 1, wherein:
the processing means of the digital computer system on which the method is practiced includes a control store; and wherein in step d) the processing means performs the calculating under control of a sequence of micro-instructions from a plurality of sequences of micro-instructions provided in the control store.

5. The method of claim 4 wherein a sequence of microinstructions currently controlling the processing means may relinquish control of the processing means and direct that the processing means be placed under control of a sequence of instructions from a plurality of sequences of instructions provided in the main memory means.

6. The method of claim 1 wherein:

if in step d) it is determined that the selected inst-ruction has specified that certain portions of the data represent-ations displayed on the display means are to become obscured or occluded by other data representations, the portions of the second certain data corresponding to the certain portions of the data representations are removed to a retention area within the main memory means; and wherein:
if in step d) it is determined that the selected inst-ruction has specified that certain portions of the data represent-ations that previously became obscured or occluded are again to become visible, the corresponding portions of the second certain data are restored from the retention area;
whereby there is no need to recompute those portions of the second certain data.

7. The method of claim 1 wherein:
if in step d) it is determined that a first certain selected form descriptor delimits a portion of the second certain data already delimited by a second certain selected form descrip-tor, and if in step d) it is further determined that the second certain selected form descriptor also delimits a portion of the second certain data not delimited by the first certain selected form descriptor:

resolving the second certain specified form de-scriptor into subform descriptors:
a first subform descriptor delimiting the portion of the second certain data delimited by both the first certain and second certain selected form descriptors; and one or more next subform descriptors delimit-ing the portion of second certain data delimited by the second certain selected form descriptor but not by the first certain se-lected form descriptor.

8. The method of claim 7 wherein: .

if in step d) it is determined that a selected form descriptor has previously been resolved into subform descriptors:

resolving the function of the selected instruction, the selected form descriptor, and certain first data specified by the selected instruction into:
a function of the selected instruction, the subform descriptors, and certain first data specified by the se-lected instruction.

9. The method of claim 7 wherein:

if in step d) it is determined that a portion of the second certain data that was previously delimited by two or more form descriptors becomes delimited by only one form descriptor:

discarding subform descriptors delimiting that portion of the second certain data.

10. A digital computer system with improved display control capa-bilities, the system comprising:
memory means for storing instructions and data;

display means for producing displays in response to first certain data stored in the main memory means; and processing means with for performing operations on data in response to the instructions;

wherein the processing means has the ability to generate the first certain data in response to certain of the instructions wherein each certain of the instructions specifies a form descriptor from a plurality of form descriptors stored in the memory means for specifying organization of data to be displayed; and second certain data in the main memory means, representations of which are to be displayed;

and wherein the processing means produces the first certain data as a function of each certain of the instructions, the form descriptor specified by each certain of the instructions, and the second certain data specified by each certain of the instruc-tions.