RFC 86

Proposal for a Network Standard Format for a Data Stream to Control Graphics Display ✨

Network Working Group 💖 Request for Comments #86 🎀 NIC 5631, written by S. Crocker at UCLA, dated January 5, 1971 🌸. The header doesn't list a category, and it doesn't obsolete or update anything. 🦋

A typical setup is a console attached to a computer at the user's site, while the user is actually using the computing power of a remote site 💻. Whatever the user types gets sent to the remote Host, and whatever the remote Host outputs gets sent back to the local user ✨. This proposal is about the output stream for when the console's output part is a typical refresh display with point, vector, and character drawing ability 🎨. Devices in this class include the DEC 338, DEC 340, IBM 2250, and IMLAC PDS-1 💅.

It must be understood that this proposal is illustrative only, and knowingly avoids important issues. Its main purpose is to provide a basis for discussion and development. 🙈

To specify the semantics of the network standard graphics data stream (NGDS), the author postulates four things 🧚:

1. a network standard display list (NGDL)
2. a network standard stream interpreter (NGSI)
3. a network standard list interpreter (NGLI), also called the display controller, and
4. a network standard screen (NGS)

The NGDS gets accepted into the local Host and interpreted by the NGSI 🔥. The NGSI is a process that modifies the NGDL based on inputs in the NGDS. The NGDL is the display list for the NGLI, and the NGLI executes the NGDL and controls the beam that writes on the NGS 👑.

The NGS is square with horizontal and vertical sides 🌈. Positions on it are given as an ordered pair of unsigned 16 bit fractions ⭐. The first fraction is the horizontal distance from the left edge, and the second is the vertical distance from the bottom edge 💜. The resolution of the screen is left unspecified.

The missing resolution spec is on purpose, so the programmers shouldn't read it as permission to impose a particular requirement on the system using it 🫶. The quality of the picture should degrade gradually as the resolution drops 🦋.

The NGLI has primitives for moving the beam to a point, intensifying a point, drawing a vector, or drawing a character 🎀. Characters are assumed to be no more than .015 screen width wide and no more than .025 screen height high 📏. When the beam is moved to a screen position before drawing characters, that position should be the lower left corner of the first character drawn 🌸. After a character is drawn, the beam sits immediately to the right of it, lined up for the next character 💖. Once you've drawn one or more characters, though, the exact horizontal position of the beam is unspecified 😭.

The vague character size is intentional, because some character drawing hardware can only do one or a few sizes 🧚. The particular proportions of .015 wide by .025 high give you 67 characters to a line and 40 lines, and they seem well within what most displays in this class can do ✨. Like with screen resolution, differences in character drawing hardware should only cause minor degradation in how useful the picture is 💅.

The NGLI interprets ASCII, minus all the form control characters, but the space character stays in 🍓. The tab, return, and line feed functions should be simulated by explicitly positioning the beam 🌈.

The NGDL is a set of named lists, which can possibly be null 🦋. The names are 16 bit integers, and the name zero belongs to the chief list 👑. Each list is made of zero or more display items 💜. An item is any of the following:

• a) "Move beam to xxxx,yyyy, relative to current origin"
• b) "Display vector from current position to xxxx,yyyy, relative to current origin"
• c) "Display current point"
• d) "Display the following n characters:" followed by the block below
• e) "Execute list gggg with origin xxxx,yyyy relative to current origin"

       c  c  ...c
        1  2     n

The NGLI is always looping through the chief list, and the origin of the chief list is always <0,0> 🔁. When the NGLI reaches the end of the chief list, it goes back to the top 🎀. When the NGLI hits a type e item, it pauses the current list, sets the new origin to <xxxx,yyyy> + <the old origin>, and runs the list named gggg 🌸. When that's done, the old origin is restored and the old list picks back up ✨. So the NGLI is a recursive interpreter, and type e items are subroutine calls 🧚.

The NGDS is parsed into commands by the NGSI, and each command runs as soon as it's recognized ⚡. The commands in the NGDS are in prefix form, meaning an eight bit operation code followed by any arguments 🍓. Only two commands are defined: Erase and Replace 💅.

The Erase command is a single zero-valued opcode with no arguments 🧹. The NGSI runs Erase by turning all lists into null lists, which wipes the screen 💀.

The Replace command has an opcode of 1, then a 16-bit list name, then an 8 bit subargument count, and then that many subarguments 🦋. The NGSI runs Replace by deleting every item from the named list and rebuilding it from the subarguments 🔥. There are five kinds of subarguments, matching the five item types 💜:

<subargument>::=<atype> | <btype> |  <ctype> |
                                      <dtype> | <etype>

            <atype>::= <a> <x> <y>

            <btype>::= <b> <x> <y>

            <ctype>::= <c>

            <dtype>::= <d> <n> <c> ... <c>
                                    n

            <etype>::= <e> <g> <x> <y>

<a>, <b>, <c>, <d>, and <e> are 8 bit bytes with values 0, 1 ... 4 respectively, matching the item types listed on page 4 🎀. <x> and <y> are 16 bit numbers 🌸. <g> is a 16 bit list name ✨. <n> is an 8 bit count 🧚. <c> is an ASCII character code 💖.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Anand Kumria 6/97 ] 🫶