home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc387.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  9.1 KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  Karl C. Kelley
  8. Request for Comments:  387                                Jaacov Meir
  9. NIC:  11359                                                   8/10/72
  10. Categories:  D.6, F
  11. Obsoletes:
  12. References:  RFC #292
  13.  
  14.  
  15.    SOME EXPERIENCES IN IMPLEMENTING NETWORK GRAPHICS PROTOCOL LEVEL 0
  16.  
  17.  
  18.     We are in the process of implementing NGP-0 at several hosts.  For
  19. the time being, we are forced to consider the remote host as the "last
  20. intelligent machine". We are attempting to translate NGP-0 to a machine
  21. dependent code for the Computek display. The remote hosts are CCN, UCSD,
  22. and soon RANDCSG. More comments about that work will be made in
  23. subsequent RFC's. The concern of this RFC is twofold:
  24.  
  25.     1.  Clarify the coordinate number system.
  26.  
  27.     2.  Puzzle over how to do TEXTR string without either:
  28.  
  29.         a.  Reading current position and saving it while the text string
  30.             is being output, or
  31.  
  32.         b.  Monitoring the beam position for each NGP command and saving
  33.             this information somewhere.
  34.  
  35.     An appendix to this RFC will outline the conversion from the NGP
  36. coordinate system to the floating point arithmetic on the PDP-1O.
  37.  
  38. The Coordinate Data
  39.  
  40.     The document for NGP-0 (RFC 292) does not say specifically that the
  41. format of coordinate data is the same whether the command is in absolute
  42. or relative mode. The only thing stated is that they are in two's
  43. complement notation with the leftmost bit being the sign bit.  It is
  44. possible to use two different 2's complement schemes:
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kelley & Meir                                                   [Page 1]
  59.  
  60. RFC 387      Experience Implementing Net Graphics Protocol   August 1972
  61.  
  62.  
  63.            System A                            System B
  64.     (Absolute Coordinates)              (Relative Coordinates)
  65.  
  66.   -1 -2 -3                 -16         0 -1 -2                 -15
  67.  -2  2  2  ...          ...2         -2  2  2  ...             2
  68.  +--+--+--+--+---------+--+--+       +--+--+--+--+---------+--+--+
  69.  |  |  |  |  |         |  |  |       |  |  |  |  |         |  |  |
  70.  +--+--+--+--+---------+--+--+       +--+--+--+--+---------+--+--+
  71.  ^                                      ^
  72.  
  73.  
  74.  .0111 ...............11 = +1/2-e    0.11 ..............11 = 1-e
  75.  
  76.  .00 .................01 = +e        0.100 .............00 = 1/2
  77.  
  78.  .00 .................0 = 0          0.00...............01 = e
  79.  
  80.  .111 ................11 = -e        0.00 ..............00 = 0
  81.  
  82.  .100 ................   = 1/2       1.11 ..............11 = -e
  83.  
  84.                                      1.10 ..............00 = -1/2
  85.  
  86.                                      1.00 ..............01 = -1+e = -(1-e)
  87.  
  88.                                      1.00 ..............00 = -1
  89.  
  90.  
  91.                -16                               -15
  92.  Where:    e = 2                     Where:  e = 2
  93.  
  94.                           -16                           -15
  95.  Range:    -1/2 to +1/2 - 2          Range:  -1 to +1 - 2
  96.  
  97.     I submit that one could interpret the requirement for absolute
  98. coordinate data to be in the range -1/2 to +1/2 - e as requiring that
  99. two different number systems should be used.  Thinking along those
  100. lines, System A has the advantage that you never get handed a number out
  101. of range, which saves some checking worries.  It also has one whole bit
  102. more of precision.
  103.  
  104.     I further submit that having two systems to contend with merely
  105. clouds the issue and requires extra coding.  It makes more sense just to
  106. stick with System B above.  Among the advantages in its use are:
  107.  
  108.     1.  The single system can handle both absolute and relative
  109.         coordinates.
  110.  
  111.  
  112.  
  113.  
  114. Kelley & Meir                                                   [Page 2]
  115.  
  116. RFC 387      Experience Implementing Net Graphics Protocol   August 1972
  117.  
  118.  
  119.     2.  If an absolute coordinate exceeds range, simply forcing the sign
  120.         bit on causes a nice wrap-around.
  121.  
  122.     3.  The representation is the same as the mantissa for floating
  123.         point numbers on most machines.  Notice, however, that mantissas
  124.         of normalized floating point numbers are not in the range for
  125.         absolute coordinates.  The program will have to shift the
  126.         mantissa until exponent is 0.
  127.  
  128.     It may be that few of us interpreted the NGP document to mean two
  129. number systems were needed.  If that is the case, so much the better.
  130. In any case, until shaken from the position by the overwhelming force of
  131. contrary logic, we will, in all of our implementations, use System B
  132. above for both absolute and relative coordinates.
  133.  
  134. The TEXTR Command
  135. -----------------
  136.  
  137.     The last paragraph on page 4 of RFC 292 says, "...a command be
  138. included only if its output is a function solely of the current command
  139. and the "beam position" current at the start of the command.  In other
  140. words, the interpreter for level 0 need have no internal storage for
  141. 'modes' or pushdown stacks."
  142.  
  143.     In the case of the Computek display, most of the NGP commands
  144. correspond to capabilities of the device. The lone exception is the
  145. TEXTR command. There are two ways to know what beam position to return
  146. to after the string is displayed. One way is to read the cursor position
  147. from the display just before doing the string output. This is no good
  148. because it requires reading from the device (which we can't do until
  149. input protocols are implemented). Also, on this device, the cursor
  150. position is accurate only to within 4 scope points.
  151.  
  152.     The second way to know what beam position to return to is to monitor
  153. all motions of the beam in software. Thus our implementations of NGP-0
  154. to Computek translations will employ a software X register and Y
  155. register. On absolute commands, the registers will be set to the
  156. coordinates for that command.  On relative commands, the coordinate data
  157. will be added to the registers.  At the beginning and end of picture,
  158. these registers will be set to 0.
  159.  
  160.     The TEXTR command will also cause these software beam registers to
  161. be changed.  That is, the X register will be incremented for each
  162. character of the string to correspond to what is happening in the
  163. display itself.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kelley & Meir                                                   [Page 3]
  171.  
  172. RFC 387      Experience Implementing Net Graphics Protocol   August 1972
  173.  
  174.  
  175.                                 APPENDIX
  176.  
  177.                      NGP-0 to PDP-10 Floating Point
  178.                      ------------------------------
  179.  
  180.        The NGP-0 looks at all data numbers (X and Y parameters) as a
  181. fraction number in the following format (16 bits per number).
  182.  
  183.  
  184.              +--+--+--+--+--+--+-----------------+--+--+--+--+
  185.              |  |  |  |  |  |  | ...         ... |  |  |  |  |
  186.              +--.--+--+--+--+--+-----------------+--+--+--+--+
  187. Bit position   0  1  2  3 ......                        14 15
  188.  
  189.  
  190.  
  191. with the binary point assumed between bits 0 and 1.  Bit 0 is the sign
  192. bit and all negative numbers are represented as their two's complement.
  193. The PDP-10 machine code representation of fractions in floating point
  194. (mantissa part) is very similar to the above (with one exception--the
  195. number -1), so the transformation could be obtained simply by two
  196. operations, move and substitute.
  197.  
  198.  
  199.                          Data (X,Y) Conversion
  200.                          ---------------------
  201.  
  202.    NGP (extreme points)                    Floating Point (PDP-10)
  203.  
  204.         (16 bits)                                 (36 bits)
  205.                                            exp   mantissa
  206.  
  207. 1/2   0.1000 . . . . . .0              0 10000000  10 . . . . . .0
  208.  
  209. -1/2  1.1000 . . . . . .0              1 01111111  10 . . . . . .0
  210.  
  211. -1    1.00   . . . . . .0              1 01111101  10 . . . . . .0
  212.                                                         Special case
  213.  
  214. 1-e   0.11   . . . . . .1              0 10000000  1111 . . . . .1
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Kelley & Meir                                                   [Page 4]
  227.  
  228. RFC 387      Experience Implementing Net Graphics Protocol   August 1972
  229.  
  230.  
  231.     Translation from NGP into floating point for PDP-1O:
  232.  
  233.     1.  Move sign bit (leftmost one) to sign bit.
  234.  
  235.     2.  Move fraction part (15 bits) to mantissa part (left justified;
  236.         fill with zero's to right).
  237.  
  238.     3.  Fill in exponent part (8 bits) according to:
  239.  
  240.         a.  If positive number      exp = 10000000 = (80) hex
  241.  
  242.         b.  If negative number      exp = 01111111 = (7F) hex
  243.  
  244.         c.  Exception _in_only_ one number
  245.  
  246.             -1 in NGP (negative sign and fraction all zero's)
  247.  
  248.             (1)  mantissa becomes same as -1/2
  249.  
  250.             (2)  exponent becomes the one's complement of (82) hex
  251.                  = (7D) hex
  252.  
  253.     The methods of conversion will remain the same regardless of the
  254.     number of bits (up to 24) that are used for the NGP fraction.
  255.  
  256.  
  257.  
  258.          [ This RFC was put into machine readable form for entry ]
  259.          [ into the online RFC archives by Alex McKenzie with    ]
  260.          [ support from GTE, formerly BBN Corp.             9/99 ]
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kelley & Meir                                                   [Page 5]
  283.  
  284.