doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc184.txt b/doc/rfc/rfc184.txt
new file mode 100644
index 0000000..14973d6
--- /dev/null
+++ b/doc/rfc/rfc184.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        Karl Kelley
+Request for Comments 184                          University of Illinois
+NIC 7128                                                     6 July 1971
+Category:  D.6
+
+
+                     Proposed Graphic Display Modes
+
+   The ARPA Network node at the University of Illinois' Center for
+   Advanced Computation is somewhat different from other nodes in that
+   we are not simply attaching an existing computer center to the net.
+   We are in the process of establishing the computer system
+   specifically for use of the ILLIAC IV and the Network.  In this mode
+   we are establishing operating systems, network interface and utility
+   routines, and ILLIAC IV routines to be used over the network.
+
+   In the field of computer graphics we are in the process of building a
+   system essentially from scratch.  The building blocks of this
+   capability comprise a small -- but growing -- collection of display
+   hardware and a small cadre of persons with experience on separate and
+   unique graphics equipment at the University of Illinois.  Starting as
+   we are with little-or-no system type software for computer graphics,
+   we have a once-only opportunity to provide the system with computer
+   graphics applications and utility programs which encompass all the
+   features and capabilities that have heretofore been available only in
+   bits and pieces at various separate installations.
+
+   It is apparent at the outset that the design for this system will be
+   heavily weighted toward a network-type usage.  For this reason we are
+   eager to ensure that our system data structures, files, etc., be as
+   nearly compatible the Network Graphics Protocol as is practicable.
+   Our initial planning and first-version system will be pointed at the
+   network type of operation and we hope to stay flexible enough to
+   employ the Network Protocol on a local basis (between our PDP-11 and
+   the B6500) as the protocol is developed.
+
+   We have been considering (in the planning of our system and pondering
+   the protocol problem) just what display modes we would want to have
+   available and thus would want the protocol to include.  The purpose
+   of this RFC is to outline our initial thoughts on the matter and to
+   interact with other nodes about how they can/should be included in
+   the protocol.  We intend here not to belabor display modes which are
+   certain to be needed everywhere, such as vectors, points, and
+   characters, but rather to summarize those and outline in more detail
+   only those which are slightly different.
+
+
+
+
+
+
+Kelley                                                          [Page 1]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   The display system, and the network protocol, will require something
+   like the following list of display types:
+
+                                         /
+   1. Points                            | Including normal points,
+                                       <  plot a symbol at a point, plot
+                                        | a point with intensity
+                                        \
+
+                                        /
+   2. Lines(two-point)                  | These two (2 and 3) include
+                                       <  visible and not visible, dotted,
+   3. Vectors (from present beam        | dashed, overbright, and ?
+               location to a point)     \
+
+   4. Character Streams
+
+   5. Viewport and Window
+      Specifications (ala LDS-1)
+
+   6. Transformations (scaling and
+      rotation) of Instances
+
+   7. Equipment-Specific Byte Streams
+
+   8. Read-Back of Keyboards,
+      Function Buttons, Cursors, Etc.
+
+   It seems clear that some type of list or ring structure will be
+   needed to handle our display files.  Whether that structure need be a
+   part of the protocol is not evident (after all, you could just send
+   the equipment byte-stream), but it is our feeling that it will be
+   needed.  It is evident that the protocol must anticipate the needs of
+   various popular display devices as CalComp, Computek, and similar
+   storage displays, interactive displays such as Adage, LDS-1, Vector
+   General, IDIOM, grey-level displays like the PEP-1 and raster-
+   oriented gadgets like the Gould, Versatec, and garden-variety line
+   printers.
+
+   The standard display element types given above are assumed to be in
+   common use.  A point, for example, is a pen-down command followed by
+   a pen-up command on a plotter.  On an interactive device it is merely
+   an intensification of the beam.  To plot a symbol at a point the pen
+   (beam) is moved to the point with pen up (beam off) and then the
+   symbol is plotted incrementally with the pen down (beam on).
+   Graphics devices with beam intensity control will be expected to
+   handle the "plot-point-with-intensity" format.
+
+
+
+
+Kelley                                                          [Page 2]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   In terms of the standard display types the only difference between
+   lines of the two-point form and vectors is that in the former, four
+   data items are needed for each segment while in the latter, only two
+   data items are needed.  In either case, the user should be able to
+   reposition the pen (beam) absolutely by drawing an invisible line.
+   He should also be able to plot dotted or dashed lines without having
+   to separately specify each point or short vector.  In instances where
+   emphasis is needed it is useful to be able to selectively intensify a
+   line, or in the case of interactive displays, make it blink.
+
+   Character streams are used either for text or for labeling drawings.
+   In most applications the character stream is specified by its
+   starting location in screen coordinates, the number of characters,
+   and the location of a buffer of characters to be used.  In some
+   purely output graphics systems the character stream is specified via
+   a format similar to printer output, with the characters being placed
+   in the specified area on the display.
+
+   Items 5 and 6 of the above list primarily apply to displays like
+   Sketchpad and the Evans and Sutherland display.  Viewport is taken to
+   be synonymous with "observer parameters in the object space" while a
+   window means "selected portion of the display surface".
+   Transformations of instances refers to a feature of Sketchpad which
+   allows multiple uses of the same "pattern" for a graphical element.
+
+   Because new equipment is constantly coming into use, and special-
+   purpose equipment is available at some nodes, it is prudent to have
+   available a capability for sending equipment-specific information
+   over the net as a part of the protocol.  Such information would be in
+   the form of byte streams formatted according to the equipment
+   specifications and pointed at the proper node and equipment.  It
+   would not be expected that each node be able to interpret the
+   nonstandard byte stream.  Also very equipment specific is the
+   information passed from an interactive device back to the originating
+   program.  Elements such as joystick or cursor position, lightpen
+   hits, function buttons pressed, etc., are inherently dependent upon
+   the device employed.  Although these devices are widely used, their
+   general dependence upon display buffers, display lists, or interrupts
+   is of special concern to the network graphics protocol.
+
+   We are interested in expanding upon the uses of grey-scale display
+   modes for representation of computer-generated data and for three-
+   dimensional object representation.  To facilitate this, our system
+   will have available at least four, program-callable display element
+   types for production of pictures on grey-level display devices.  The
+   initial names for these modes are the procedure names: GRIDAREA,
+   MATRIXAREA, SCANLINE, and SCANPOINT.  The following paragraphs will
+   outline how the modes operate both from a user and a data-
+
+
+
+Kelley                                                          [Page 3]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   communications point of view.  The specific hardware involved is not
+   specified, nor do we ignore the possibility that hardware can be
+   designed to operate this way directly.  For example, the SCANLINE is
+   precisely the way one display does operate.  In the interim, however,
+   software sits between these procedures and actual devices.
+
+   GRIDAREA              The user specifies, in an initial call, the size
+   --------              grid he wishes to use and the number of intensity
+                         levels he will need.  Subsequent calls send, as
+                         data items, the i, j locations of an area and a
+                         byte for intensity.
+
+   The initializing call is GRIDSET(N, M, IRNGE)
+                                              |<--- I ------>|
+   where N is the number of spaces       ---  +--+--+--+--+--+--+--+--+
+   across, M is the number down,          ^   |--|--|--|--|--|--|--|--|
+   and IRNGE tells how many grey          |   |--|--|--|--|--|--|--|--|
+   levels to use.  This is primarily      J   |--|--|--|--|--|--|--|--|
+   for grey-scale displays or             |   |--|--|--|--|--|--|--|--|
+   pseudogrey-scale displays.             v   |--|--|--|--|--|--|--|--|
+                                         ---  |--|--|--|--|--|--|--|--|
+                                              |--|--|--|--|--|--|--|--|
+                                              +--+--+--+--+--+--+--+--+
+
+   On a Gould Electrostatic Printer-Plotter, for example, the system
+   would expect to have dot patterns with which to fill areas in order
+   to simulate the greys.  For purposes of other displays, a SETSQUARES
+   procedure should be available so that the user can specify various
+   kinds of cross- hatching and character filling to apply to the grid
+   areas.
+
+   To enter an item of data the procedure is
+
+                                              1 <= I <= N
+                  GRIDAREA(I, J, LEVEL)       1 <= J <= M
+                                              1 <= LEVEL <= IRNGE
+
+   where I and J select an area on the grid, and LEVEL tells how to fill
+   it.  Obviously, for this kind of display mode some provision must be
+   made to end the picture because the servicing routine will have to
+   work on it from either the top or the bottom in a sweep mode.  A
+   procedure call of GRIDAREA(0, 0, 0) will terminate it.  The GRIDAREA
+   mode is very similar to the following, MATRIXAREA, with the primary
+   difference being that the specification of areas is random and areas
+   which are not specified will be left blank.
+
+
+
+
+
+
+Kelley                                                          [Page 4]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   MATRIXAREA            The user specifies an area size and a "pseudo-
+   ----------            character" set, then writes from left to right,
+                         top to bottom, much like a line printer, using
+                         bytes to specify which of his "pseudo-character"
+                         set to use.
+
+The initializing call is MATRIXSET(N, M, DEFINITION, CODE)
+
+The display mode is raster                ________________________
+oriented, and each "pseudo-              |  _   _   _   _   _   _ |
+character" will be on a N x M            | |_| |_| |_| |_| |_| |_||
+matrix of dots.  (A later                |  _   _   _             |
+embellishment for printers               | |_| |_| |_| . . .      |
+would include matrix of characters.)     |  _   _                 |
+Parameters DEFINITION and CODE           | |_| |_| . . .          |
+are both arrays, used together to        | .    \ \               |
+specify the "pseudo-character" set.      | .     \  \             |
+DEFINITION is packed with bits           |________\___\___________|
+according to the following scheme:                \     \
+                                                   \      \
+                                                    \    __\_______
+                                                     \  /           \
+                                                      \/  ________   \
+                                                      /   |_|_|_|_|   \
+                                                     /    |_|_|_|_|    \
+                                                     |    |_|_|_|_|    |
+                                                     |    |_|_|_|_|    |
+                                                     \    |_|_|_|_|    /
+                                                      \   |_|_|_|_|   /
+                                                       \             /
+                                                        \___________/
+
+     n - bits
+    +--+--+--+--+
+    |XX|  |  |XX|
+    |--|--|--|--|
+s   |  |XX|XX|  |
+t   |--|--|--|--|
+i   |XX|  |  |XX|
+b   |--|--|--|--        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--\
+    |  |XX|XX|  |  <=== |1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|\
+-   |--|--|--|--|       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\
+m   |XX|  |  |XX|        \--v--/ \--v--/ \--v--/ \--v--/ \--v--/ \--v--/
+    |--|--|--|--|           n       n       n       n       n       n
+    |  |XX|XX|  |
+    +--+--+--+--+        \-------------------------v---------------------/
+                                                   m-groups
+
+
+
+
+Kelley                                                          [Page 5]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   The bit stream for the definition is irrespective of word boundaries.
+   We leave it up to the MATRIXSET routine to be able to undo this.
+   Obviously, for user convenience we have some standard sets they can
+   use to save having to define their own, and if they want to define
+   their own, we make routines to ease the pain.
+
+   The array CODE, on the other hand, is a byte-stream, i.e., a stream
+   of eight-bit groups of bits which will correspond to each of the
+   groups of (N x M)-bits.  This allows 256 pseudocharacters for one
+   set.
+
+   To enter an item of data in this mode the procedure is
+
+                  MATRIXAREA(ARRAY, LENGTH)
+
+   ARRAY is a buffer location and length is the number of code bytes
+   which are to be put out.  Each call will put out one row of the
+   display.  Unused bytes at the end of the stream (bytes left over in
+   the last word) should be zero.  Any codes in excess of the maximum
+   number allowed on a line will be discarded.
+
+   It should be noted that this routine is nominally used for special
+   character sets, or for that matter, any character sets that are
+   software generated on dot-raster devices.  In addition, however, it
+   can be used for photomosaic displays, area filling on maps, and
+   development of capability of producing audiovisual aids for
+   presentations.
+
+
+   SCANLINE               A raster-scanning display mode for which the
+   --------               user specifies a raster size, number of grey
+                          levels needed, and direction of scan.  The
+                          subsequent data items specify only the location
+                          and character of a change in the scanning
+                          beam (or program).
+
+   The initializing procedure is SCANLINESET(DELTA, LEVELS, ORGMODE)
+
+   DELTA is an integer specifying the number of display points to be
+   included in each step.  LEVELS denotes the number of intensity levels
+   to be used, and the sign of ORGMODE specifies whether the scan is to
+   be from the bottom up (plus) or top down (minus) on the display.  For
+   both cases we will assume left-to-right.  The absolute value of
+   ORGMODE gives the starting Y position.
+
+   All subsequent calls to this routine are of the form
+
+                          SCANLINE(X, INTENSITY)
+
+
+
+Kelley                                                          [Page 6]
+
+RFC 184              Proposed Graphic Display Modes          6 July 1971
+
+
+   The first such call denotes the origin in X and the initial
+   intensity.  Subsequent calls denote the X value of the next point on
+   the scan where the intensity is to change, and that new intensity.
+   The program (or device) takes care of the stepping of the scan by
+   DELTA across the page, with the current intensity.  Thus, the program
+   (device) only needs a data item for each change in the scan, not for
+   each position.  When the next X is less than the previous X, or the X
+   position has been stepped to its limit, the Y position in the
+   incremented or decremented to continue the scan on the next line.
+
+   We see the device which accepts such a display as accepting a stream
+   of triplets of bytes, where the first two bytes (16 bits) specify the
+   X and the third (8 bits) specifies the level.  The end of the stream
+   would be specified by three bytes of deletes (all ones).  This
+   display mode is implemented in hardware on the display at the
+   Coordinated Science Laboratory at this University.  It is the same
+   one which was used for the grey-scale work which has been reported by
+   Bouknight.
+
+
+   SCANPOINT            A point with intensity scanning mode in which
+   ---------            the scan is handled automatically and only the
+                        intensity of each point needs to be transmitted
+                        to the program (device).
+
+   The initializing call for this procedure is
+
+           SCANPOINTSET(DELTA, LEVELS, ORGMODE)
+
+   The arguments are the same as for SCANLINE.  The difference is in the
+   meaning of subsequent calls.  The origin for the scan is at the left
+   end of the line corresponding to the absolute value of ORGMODE.  The
+   stepping is done from left to right and at the end of each line, the
+   Y position is incremented or decremented by DELTA, according to the
+   sign of ORGMODE.
+
+   Subsequent calls to this procedure are of the form SCANPOINT(LEVEL)
+   where LEVEL denotes the intensity level at which the next point is to
+   be displayed.  In this mode every point must have its intensity
+   specified by a separate call to the routine (byte to the device).
+   However, beyond the starting point no position information is
+   required.
+
+
+       [ This RFC was put into machine readable form for entry ]
+        [ into the online RFC archives by Hamid Dastkar 09/99 ]
+
+
+
+
+
+Kelley                                                          [Page 7]
+