17. Display Files.

17.1. Where are they used?



There are 3 areas where display files are used

 (1)  Refresh Displays

 (2)  Storage displays for "erasures"

 (3)  Data image preservation/transportation

A Refresh display needs the line segments redrawn every 1/30th sec so that the picture does not flicker. If it takes longer than that, then the first line segment may have faded or disappeared by the time that the last one is drawn. (A long persistence phosphor helps since it gives a longer time before first segment fades).


 If the computer has to draw the image repetitively then it

must have some list of the commands to output to the graphics screen.

This list is called a Display file.

The outputting of the commands may be in one of two different forms.


 (1) The host computer gets the command and sends out the correct

     characters to the device (dependent on move, draw, print, etc).

     Obviously, not over a terminal line since each character could

     take 1 millisec => 30 characters before flicker sets in.


Could be sent over a parallel output port at data rates of 40,000

characters/sec or more. Even this is normally too slow. Also host

must process list at 25 micro-seconds per character!!


 (2) The host indicates to the Display Processing Unit ( D.P.U. -

the processor in the graphics refresh display unit) the start address

of the list of commands and tells it to access them itself.

Therefore, both host and D.P.U. can access the list or display file in

memory. The list is in a format that D.P.U. can "interpret" directly.

D.P.U. could get/process 1 command every 1 or 2 microseconds = 20,000

commands without flicker.


                        The D.P.U. takes first "symbolic" instruction

  0:  move_abs X,Y     from display file (= in reality it is memory

  1:  draw_rel DX,DY   storage ) and executes it, it then gets next

  2:  draw_rel DX,DY   one , etc. Finally , in this case, it gets a

   :                   jump to 0 , where upon it starts to process

  n:  jmp      0      the list once more.


 
                   Hence refresh display.

Obviously the time taken to execute each instruction on average must be less than refresh time divided by N + 1, i.e. (1/30) / (1/N+1). Otherwise flicker will result. For very complex images made up of small line segments N may get quite large. The persistence of the tube and speed of the D.P.U. place an upper limit on the size of N.

A storage tube does not need to be refreshed but when updating a picture by erasing a small part of it, the entire screen must be cleared and the image rebuilt minus the deleted line segments. A display file can be used to hold a "copy" (in symbolic form) of the image.


 0:      move_abs X,Y     To remove the 3 line segments just:

         :            (1) change them to NO-OPs i.e. no operation

 20:      draw_rel        is performed by D.P.U.

 21:      draw_rel        OR remove them by compacting display file.

 22:      draw_rel     (2) erase screen.

          :           (3) "execute" the display file.

 n:      jmp      0     Image is rebuilt.

NOTE: it is still necessary to know which lines/commands to delete. The above is only valid for non-refresh displays as we shall see.

For design work (= interactive work) an image can be built up on the screen, changed, etc. and then finally a hardcopy may be required. If a hardcopy device is attached to the screen then the bit contents of screen may be directly copied onto the hardcopy device.


Use video signal from Raster scan. Why is this no good for T4010?

 Because it is not a RASTER SCAN device. No memory to scan for video signal.

If no hardcopy device then the information must be saved somehow and then later re-interpreted by a plotting program. This information saved can be the "display file". Note that this information is device specific and hence could probably not be used to reconstruct the image on another device. Reconstruction on another device could be done via a metafile.

Of the 3, the commonest use for display files is for refresh displays but since we have no refresh display we will be concerned with the concepts and the rebuilding of an image.

17.1.1. D.P.U. instruction set.

How is display file built up? When routines such as plot, symbol, setwindow, etc are called commands such as move_abs(x,y), display_text(x,y) and jmp addr are entered into the display file. New segments will (perhaps ) be surrounded by header information and jmp's to the next segment. Remember that each addition to the end of the display file must be terminated by a jmp 0 or a command that indicates that the end of the display file has been reached.

Therefore the routines used will add to the display file rather than sending commands such as "V[124,334]" to a device: obviously the commands sent to the device are in the display file. So our device driver takes commands and creates a binary bit pattern that is sent to the D.P.U.

The D.P.U. can use the commands in the display file as instructions. It doesn't need a program which looks at the commands one by one, figures out what it means and does the correct thing. The program can be the commands themselves! So a display file is just a machine language program for the D.P.U. and the D.P.U. is just a special computer with "strange" instructions.

Just as the PDP11 has a "cmp op1,op2" command, the Z80 has a "call nz,addr", and the DEC10 has a "jrst addr" instruction, so our D.P.U. may have a "move_abs x,y" instruction or a "call circle" instruction. This is why the D.P.U. can be so fast - it is just executing a machine language program.

17.2. Segments.

It is a common and very useful practice to break up a picture into segments (NOT line segments in particular). The image on the screen can then be looked at as being made up of many segments or distinct images, i.e. a circle, a triangle, a square or a little man perhaps.


    

   
           Fig. 17.1 : Segments in a display file.

Each of these segments can be isolated in the

display file and even named in some way to

distinguish it. It may even be in the form of

a display file subroutine.


 If we have to display 6 circles why not a circle drawing subroutine that can

be called and returned from (with infinite nesting). Might also be useful

to have parameters.

Our display file is now more compact although we take slightly longer to process it. ( calls and returns are added). However our D.P.U. may be smart enough to store commonly used subroutines in its own memory, therefore quicker.


Lets look at two typical D.F. layouts for the above.


   0 : CALL CIRCLE     5:          :            :         :

   1 : CALL TRIANGLE       Circle                    Square

   2 : CALL SQUARE         Routine                   Routine

   3 : CALL LITTLEMAN

   4 : JMP 0              RETURN   RETURN          RETURN          RETURN


 
  Display files with 4 calls plus the subroutines themselves.

To delete the triangle we simply change 1: to a no-op. Unfortunately we do not know (easily) if we can reclaim the space of the triangle routine.


 (We could add a counter to the triangle routine which indicates how many

calls there are to this routine.)

For instruction purposes, we will consider the following implementation of the problem.


    

   
   Fig. 17.2 : Implementation of segments in a display file.

To delete the triangle:
(1) identify the segment required
(2) change the jmp address in segment circle to jmp to the square instead.
(3) reclaim space lost (see later).

To add another segment, we create our new code at a particular "address", finish it with a jmp 0 and then change the jmp 0 in the littleman segment to jmp to the particular address of new segment.

QUESTIONS:
What type of code is in display file?
What commands do we need to manipulate these segments within our display file?
What of storage allocation for the segment creation/deletion?`

17.3. Segment Management.

In high level situations where we may be using a display file for a refresh display, the follow segment management commands would be useful:


 create-segment(name)            = open(name)

 close-segment(name)          or just close-segment

 delete-segment(name)          and reclaim space

 rename-segment(old,new)

 set-visibility (name,on/off)        = post/unpost(name)

 translate-segment(name,dx,dy):

 append-segment(name)         <--- useful but can lead to problems with

                                too many jumps

Read and understand Chapter 7 in Newman & Sproull.

17.4. Storage Allocation.

Storage allocation for segments is complicated by (1) Amount of memory needed is not known beforehand. i.e. appending to a segment, creating a new segment.
(2) Re-allocation or disposal of segments cannot be done in a simple manner iff the display file is being used for refreshing a display.


    

   
   Fig. 17.3 : Storage allocation of segments in a display file.

Suppose we have a two segment display file (0) and (1).

At some time during execution of the display file we

want to replace segment (1) by (2).

 We must create (2). Add the jmp 0 and then link it into

display file by changing jmp N at location M to a jmp Q.

If D.P.U. is executing code in (1) we may simply change m: to a jmp q. Next time around it executes (0) then (2).
If D.P.U. is executing code in (0) we may change m: to a jmp q if all is setup and we can do it in one indivisible operation.

In the latter case we can immediately reclaim the space allocated to segment (1) if the only entry point is at n: since it is never used again but in the former case we cannot reclaim (1) until it is finished with by the D.P.U. Otherwise we may alter code that the D.P.U. is executing as we re-use that space.


 We must wait until D.P.U. signals "all finished".

This is usually a flag in a register but in a dedicated system it could

cause an interrupt which goes to a routine which does garbage collection.

This problem of storage allocation is similar to problem encountered by an operating system when running programs - segmentation, compacting, etc. The solution is the same = paging or use of pages.


 Use the blocks of storage of a fixed length and allocate these for segment

storage.

Size of a page which gives the number of D.P.U. instructions must be

determined empirically in order to reduce wastage since not all pages

within a segment will be full.

e.g. Assume segment has 25 commands or instructions in it and that a page has room for 8 instructions.


    

   
          Fig. 17.4 : Storage allocation of pages.

Fills up 3 pages plus 1 instruction = 4 pages. Notice last page has 7 wasted instructions in it that can't be used.

In Pascal, we can use pointers and linked lists and the facilities offered by dynamic storage = HEAP.

In FORTRAN, we only have static storage therefore, we must use a large (gigantic?) array or arrays.