Browse Prior Art Database

Some experiences in implementing Network Graphics Protocol Level 0 (RFC0387)

IP.com Disclosure Number: IPCOM000003566D
Original Publication Date: 1972-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K.C. Kelley: AUTHOR [+1]

Related Documents

10.17487/RFC0387: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Network Working Group Karl C. Kelley Request for Comments: 387 Jaacov Meir NIC: 11359 8/10/72 Categories: D.6, F Obsoletes: References: RFC #292

SOME EXPERIENCES IN IMPLEMENTING NETWORK GRAPHICS PROTOCOL LEVEL 0

We are in the process of implementing NGP-0 at several hosts. For the time being, we are forced to consider the remote host as the "last intelligent machine". We are attempting to translate NGP-0 to a machine dependent code for the Computek display. The remote hosts are CCN, UCSD, and soon RANDCSG. More comments about that work will be made in subsequent 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 NGP coordinate 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 the format of coordinate data is the same whether the command is in absolute or relative mode. The only thing stated is that they are in two’s complement notation with the leftmost bit being the sign bit. It is possible 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 absolute coordinate data to be in the range -1/2 to +1/2 - e as requiring that two different number systems should be used. Thinking along those lines, System A has the advantage that you never get handed a number out of range, which saves some checking worries. It also has one whole bit more of precision.

I further submit that having two systems to contend with merely clouds the issue and requires extra coding. It makes more sense just to stick 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 ni...

Processing...
Loading...