Network Working Group                                  Karl C. KelleyRequest for Comments:  387                                Jaacov MeirNIC:  11359                                                   8/10/72Categories:  D.6, FObsoletes:References:  RFC #292   SOME EXPERIENCES IN IMPLEMENTING NETWORK GRAPHICS PROTOCOL LEVEL 0    We are in the process of implementing NGP-0 at several hosts.  Forthe time being, we are forced to consider the remote host as the "lastintelligent machine". We are attempting to translate NGP-0 to a machinedependent code for the Computek display. The remote hosts are CCN, UCSD,and soon RANDCSG. More comments about that work will be made insubsequent RFC's. The concern of this RFC is twofold:    1.  Clarify the coordinate number system.    2.  Puzzle over how to do TEXTR string without either:        a.  Reading current position and saving it while the text string            is being output, or        b.  Monitoring the beam position for each NGP command and saving            this information somewhere.    An appendix to this RFC will outline the conversion from the NGPcoordinate system to the floating point arithmetic on the PDP-1O.The Coordinate Data    The document for NGP-0 (RFC 292) does not say specifically that theformat of coordinate data is the same whether the command is in absoluteor relative mode. The only thing stated is that they are in two'scomplement notation with the leftmost bit being the sign bit.  It ispossible to use two different 2's complement schemes:Kelley & Meir                                                   [Page 1]RFC 387      Experience Implementing Net Graphics Protocol   August 1972           System A                            System B    (Absolute Coordinates)              (Relative Coordinates)  -1 -2 -3                 -16         0 -1 -2                 -15 -2  2  2  ...          ...2         -2  2  2  ...             2 +--+--+--+--+---------+--+--+       +--+--+--+--+---------+--+--+ |  |  |  |  |         |  |  |       |  |  |  |  |         |  |  | +--+--+--+--+---------+--+--+       +--+--+--+--+---------+--+--+ ^                                      ^ .0111 ...............11 = +1/2-e    0.11 ..............11 = 1-e .00 .................01 = +e        0.100 .............00 = 1/2 .00 .................0 = 0          0.00...............01 = e .111 ................11 = -e        0.00 ..............00 = 0 .100 ................   = 1/2       1.11 ..............11 = -e                                     1.10 ..............00 = -1/2                                     1.00 ..............01 = -1+e = -(1-e)                                     1.00 ..............00 = -1               -16                               -15 Where:    e = 2                     Where:  e = 2                          -16                           -15 Range:    -1/2 to +1/2 - 2          Range:  -1 to +1 - 2    I submit that one could interpret the requirement for absolutecoordinate data to be in the range -1/2 to +1/2 - e as requiring thattwo different number systems should be used.  Thinking along thoselines, System A has the advantage that you never get handed a number outof range, which saves some checking worries.  It also has one whole bitmore of precision.    I further submit that having two systems to contend with merelyclouds the issue and requires extra coding.  It makes more sense just tostick with System B above.  Among the advantages in its use are:    1.  The single system can handle both absolute and relative        coordinates.Kelley & Meir                                                   [Page 2]RFC 387      Experience Implementing Net Graphics Protocol   August 1972    2.  If an absolute coordinate exceeds range, simply forcing the sign        bit on causes a nice wrap-around.    3.  The representation is the same as the mantissa for floating        point numbers on most machines.  Notice, however, that mantissas        of normalized floating point numbers are not in the range for        absolute coordinates.  The program will have to shift the        mantissa until exponent is 0.    It may be that few of us interpreted the NGP document to mean twonumber systems were needed.  If that is the case, so much the better.In any case, until shaken from the position by the overwhelming force ofcontrary logic, we will, in all of our implementations, use System Babove for both absolute and relative coordinates.The TEXTR Command-----------------    The last paragraph on page 4 of RFC 292 says, "...a command beincluded only if its output is a function solely of the current commandand the "beam position" current at the start of the command.  In otherwords, the interpreter for level 0 need have no internal storage for'modes' or pushdown stacks."    In the case of the Computek display, most of the NGP commandscorrespond to capabilities of the device. The lone exception is theTEXTR command. There are two ways to know what beam position to returnto after the string is displayed. One way is to read the cursor positionfrom the display just before doing the string output. This is no goodbecause it requires reading from the device (which we can't do untilinput protocols are implemented). Also, on this device, the cursorposition is accurate only to within 4 scope points.    The second way to know what beam position to return to is to monitorall motions of the beam in software. Thus our implementations of NGP-0to Computek translations will employ a software X register and Yregister. On absolute commands, the registers will be set to thecoordinates for that command.  On relative commands, the coordinate datawill be added to the registers.  At the beginning and end of picture,these registers will be set to 0.    The TEXTR command will also cause these software beam registers tobe changed.  That is, the X register will be incremented for eachcharacter of the string to correspond to what is happening in thedisplay itself.Kelley & Meir                                                   [Page 3]RFC 387      Experience Implementing Net Graphics Protocol   August 1972                                APPENDIX                     NGP-0 to PDP-10 Floating Point                     ------------------------------       The NGP-0 looks at all data numbers (X and Y parameters) as afraction number in the following format (16 bits per number).             +--+--+--+--+--+--+-----------------+--+--+--+--+             |  |  |  |  |  |  | ...         ... |  |  |  |  |             +--.--+--+--+--+--+-----------------+--+--+--+--+Bit position   0  1  2  3 ......                        14 15with the binary point assumed between bits 0 and 1.  Bit 0 is the signbit and all negative numbers are represented as their two's complement.The PDP-10 machine code representation of fractions in floating point(mantissa part) is very similar to the above (with one exception--thenumber -1), so the transformation could be obtained simply by twooperations, move and substitute.                         Data (X,Y) Conversion                         ---------------------   NGP (extreme points)                    Floating Point (PDP-10)        (16 bits)                                 (36 bits)                                           exp   mantissa1/2   0.1000 . . . . . .0              0 10000000  10 . . . . . .0-1/2  1.1000 . . . . . .0              1 01111111  10 . . . . . .0-1    1.00   . . . . . .0              1 01111101  10 . . . . . .0                                                        Special case1-e   0.11   . . . . . .1              0 10000000  1111 . . . . .1Kelley & Meir                                                   [Page 4]RFC 387      Experience Implementing Net Graphics Protocol   August 1972    Translation from NGP into floating point for PDP-1O:    1.  Move sign bit (leftmost one) to sign bit.    2.  Move fraction part (15 bits) to mantissa part (left justified;        fill with zero's to right).    3.  Fill in exponent part (8 bits) according to:        a.  If positive number      exp = 10000000 = (80) hex        b.  If negative number      exp = 01111111 = (7F) hex        c.  Exception _in_only_ one number            -1 in NGP (negative sign and fraction all zero's)            (1)  mantissa becomes same as -1/2            (2)  exponent becomes the one's complement of (82) hex                 = (7D) hex    The methods of conversion will remain the same regardless of the    number of bits (up to 24) that are used for the NGP fraction.         [ This RFC was put into machine readable form for entry ]         [ into the online RFC archives by Alex McKenzie with    ]         [ support from GTE, formerly BBN Corp.             9/99 ]Kelley & Meir                                                   [Page 5]