RFC-292

by Darius Kazemi, October 19 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

First pass at graphics

RFC-292 is titled “Graphics Protocol – Level 0 Only”. It's authored by Jim Michener and Ed Meyer of MIT Project MAC, Ira Cotton of MITRE, Karl Kelly of University of Illinois, and Dave Liddle of Owens-Illinois. It's dated January 12, 1972.

The technical content

This RFC is a result of November's Network Graphics Meeting. The minutes of the meeting are already published in RFC-282. This RFC is documents a graphic protocol that they've landed on.

This is a “level 0” implementation of the protocol. The graphics committee defined this in the meeting as a protocol that describes only how graphics might be sent to a remote graphical display to be rendered. It doesn't cover interactivity. It also has nothing to do with the connection itself: this is simply a data format specification.

Because this protocol contains a lot of functionality, they are kind of ranking each chunk of functionality based on how hard it is to implement, and letting individual sites say “we support all graphics functions ranked level X and below at this site”.

The protocol works in 8-bit bytes. Commands are a command byte followed by some number of arguments. Individual arguments can be fixed or variable length. Arguments are typed and include “value” (a single 8-bit integer) and “string” (which is variable length).

Coordinates are sent as twos-complement fractions. I won't explain these in depth, and I can't find a good reference link for using twos-complement fractions, mostly because people don't often do that sort of thing anymore. But essentially it's a way to represent a fraction in binary and not use up a lot of bytes in the process.

In addition to being twos-complement, the coordinates are signed, meaning that they can represent a range of positive and negative numbers. The virtual screen that the protocol works with is a unit square, so if you can represent values between -½ and +½ on the X and Y axes then you can represent any value on the screen. Non-square hardware displays are supposed to take this data and use the largest square area they can on their given display.

A user can set the number of bytes used for coordinate data. This allows a user to send high-precision coordinate data as needed (basically the more bits you have, the more decimal points of precision you have in your data).

They very wisely decide to stick to atomic commands in the level 0 protocol. Specifically the rule is that the only outside information that can affect the output of a given command is the current beam position (the location of the pen, if you will) at the start of the command.

The list of commands is pretty similar to what we've seen in previous graphics protocol proposals, including: move beam, draw line to point from current beam, draw dot at point, display text. The only thing really different here is the inclusion of an “escape to device specifics” command, which is not recommended for use and lets you send device-specific commands if you know what device you're talking to (so like, on a dual screen device you could send its native command to start writing on screen 2 instead of screen 1 or whatever).

Analysis

The twos-complement fraction thing reminds me that all this is happening more than a decade before the IEEE 754 floating point standard was published.

I'm not sure if their “value” data type is signed or unsigned, or if it matters. I assume it would be signed since this is all stuff happening on a relative coordinate system around a 0,0 origin in the middle of the screen and having easy representation of negative numbers would be helpful, but that's just a guess. Also I guess if their coordinate data type is twos complement then that has negative value representation built in.

Apparently there was a ton of arguing about what commands get assigned which opcodes:

Each command in the graphics protocol will be assigned a non-negative value which will represent this command in the byte stream.  The algorithm whereby values and commands are associated is, it turns out, a very touchy subject.  There are five or ten different criteria for a "best" algorithm, each criterion different in emphasis.

This is hilarious to me, but also goes to show that so much of nitty-gritty computer programming is just emotional decision making. See also: the massive months-long debate about host site mnemonics.

Further reading

Owens-Illinois is a massive manufacturing company that specializes in glass. Of relevance to ARPANET is that in the early 1970s they manufactured plasma displays for interactive graphics systems. There will be more on this in a future RFC.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.