RFC 387

SOME EXPERIENCES IN IMPLEMENTING NETWORK GRAPHICS PROTOCOL LEVEL 0 ✨

okay bestie, quick receipts first 🧾🎀. This is from the Network Working Group, written by Karl C. Kelley and Jaacov Meir, with NIC number 11359, dated 8/10/72. It's filed under categories D.6 and F. It doesn't obsolete anything, and it references RFC 292, which is the NGP-0 spec itself 📜💅.

Okay so the vibe here is that we're actually building NGP-0 at several hosts right now 🔥. For the moment, the remote host is basically the "last intelligent machine" 🧠, and we're translating NGP-0 into machine dependent code for the Computek display 🖥️. The remote hosts are CCN, UCSD, and soon RANDCSG 🌸. More tea about all that is coming in future RFCs, so stay tuned 🫶. This particular RFC has two main concerns:

1. Clarify the coordinate number system 🔢.
2. Figure out how to do TEXTR string without either:

a. Reading the current position and saving it while the text string is being output, or

b. Monitoring the beam position for each NGP command and saving that info somewhere 😭.

Also, there's an appendix at the end that walks through converting the NGP coordinate system into floating point arithmetic on the PDP-1O 🧚.

---

The Coordinate Data

Okay so the NGP-0 doc (RFC 292) doesn't spell out whether coordinate data is formatted the same way in absolute mode and relative mode 🙈. All it says is that the numbers are two's complement with the leftmost bit as the sign bit. That leaves room for two different 2's complement schemes, and honestly, they look like this 🦋:

           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

Here's my take 💖. You could read the requirement for absolute coordinate data (the range of -1/2 to +1/2 - e) as meaning two different number systems are needed. Thinking along those lines, System A has the big perk that you never get handed an out-of-range number, which means fewer checking worries 😅. It also gets one whole extra bit of precision ✨.

BUT, having two systems to juggle just clouds the issue and adds extra coding 🙃. So it makes way more sense to stick with System B. Why I'm obsessed with System B 👑:

1. One single system handles both absolute and relative coordinates.
2. If an absolute coordinate goes out of range, just forcing the sign bit on gives you a nice wrap-around 🌈.
3. The representation matches the mantissa for floating point numbers on most machines. Heads up though: mantissas of normalized floating point numbers aren't in the range for absolute coordinates, so the program will have to shift the mantissa until the exponent is 0 💀.

It's possible that few of us read the NGP document as needing two number systems. If so, even better 🥳. Either way, until we're shaken from this position by the overwhelming force of contrary logic, we're going to use System B for both absolute and relative coordinates in all of our implementations 💅.

---

The TEXTR Command

Okay so the last paragraph on page 4 of RFC 292 says, "...a command be included only if its output is a function solely of the current command and the "beam position" current at the start of the command. In other words, the interpreter for level 0 need have no internal storage for 'modes' or pushdown stacks."

With the Computek display, almost every NGP command maps straight onto a device capability 🙌. The one lone exception is TEXTR. There are two ways to figure out which beam position to return to after the string gets displayed 🤔.

The first way is to read the cursor position from the display right before doing the string output. Nope, not great 😩. That means reading from the device, which we can't do until input protocols are implemented. Also, on this device, the cursor position is only accurate to within 4 scope points.

The second way is to monitor every motion of the beam in software. So our NGP-0 to Computek translations will use a software X register and Y register 🦋. On absolute commands, the registers get set to the coordinates for that command. On relative commands, the coordinate data gets added to the registers. At the beginning and end of a picture, both registers get set to 0 ✨.

The TEXTR command also changes these software beam registers. Specifically, the X register gets incremented for each character in the string, so it matches what's happening on the display itself 🧚.

---

APPENDIX

NGP-0 to PDP-10 Floating Point

Okay so NGP-0 treats all data numbers (the X and Y parameters) as fraction numbers in the following format, 16 bits per number 🌸:

             +--+--+--+--+--+--+-----------------+--+--+--+--+
             |  |  |  |  |  |  | ...         ... |  |  |  |  |
             +--.--+--+--+--+--+-----------------+--+--+--+--+
Bit position   0  1  2  3 ......                        14 15

The binary point is assumed between bits 0 and 1. Bit 0 is the sign bit, and all negative numbers are stored as their two's complement 💜. The PDP-10 machine code representation of fractions in floating point (the mantissa part) is very similar to the above, with one exception, which is the number -1 😭. So the transformation can be done with just two operations: move and substitute 🔥.

   NGP (extreme points)                    Floating Point (PDP-10)

        (16 bits)                                 (36 bits)
                                           exp   mantissa

1/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 case

1-e   0.11   . . . . . .1              0 10000000  1111 . . . . .1

Data (X,Y) Conversion

Here's the translation from NGP into floating point for the PDP-1O 🧚:

1. Move the sign bit (the leftmost one) to the sign bit.
2. Move the fraction part (15 bits) to the mantissa part, left justified, filling the right side with zeros.
3. Fill in the exponent part (8 bits) according to:

a. If the number is positive, exp = 10000000 = (80) hex

b. If the number is negative, exp = 01111111 = (7F) hex

c. Exception in only one number: -1 in NGP (negative sign and fraction all zeros).

(1) The mantissa becomes the same as -1/2.

(2) The exponent becomes the one's complement of (82) hex, which is (7D) hex.

The conversion methods stay the same no matter how many bits (up to 24) 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 ]