RFC 184
Proposed graphic display modes
RFC 184: Proposed Graphic Display Modes 🎀
Bestie, okay, RFC 184 is titled Proposed Graphic Display Modes and it's from the Network Working Group. Karl Kelley wrote it at the University of Illinois. It's dated 6 July 1971, it's filed as NIC 7128, and its category is D.6. The header doesn't list anything it obsoletes or updates, so this one's standing on its own ✨
So the ARPA Network node at the University of Illinois' Center for Advanced Computation is kinda different from the others 💅 They aren't just plugging an existing computer center into the net. They're building the computer system specifically for the ILLIAC IV and the Network. That means they're setting up operating systems, network interface and utility routines, and ILLIAC IV routines that get used over the network. Main character energy, honestly 👑
In computer graphics they're basically building everything from scratch 🛠️ The building blocks are a small (but growing!) collection of display hardware, plus a small crew of people who've worked on separate, one-of-a-kind graphics equipment at Illinois. They're starting with little-or-no system-type software for graphics, so they get a once-only chance to give the system graphics applications and utility programs that cover every feature that's only ever been available in bits and pieces at different installations. Iconic 🌈
The design is going to be heavily weighted toward network-type usage 🌐 So they're eager for their system data structures, files, etc. to be as nearly compatible as practicable with the Network Graphics Protocol. Their first-version system is pointed at network operation, but they want to stay flexible enough to use the Network Protocol on a local basis (between their PDP-11 and the B6500) as the protocol gets developed 🧚
The whole point of this RFC is to share their early thoughts and get other nodes talking about how display modes can or should be included in the protocol 💜 They're not going to belabor the stuff that's needed everywhere anyway, like vectors, points, and characters. They'll just sum those up and go deeper only on the ones that are a little different. Efficient, I love it 🍓
The display system and the network protocol are going to need something like this list of display types:
/
1. Points | Including normal points,
< plot a symbol at a point, plot
| a point with intensity
\
/
2. Lines(two-point) | These two (2 and 3) include
< visible and not visible, dotted,
3. Vectors (from present beam | dashed, overbright, and ?
location to a point) \
4. Character Streams
5. Viewport and Window
Specifications (ala LDS-1)
6. Transformations (scaling and
rotation) of Instances
7. Equipment-Specific Byte Streams
8. Read-Back of Keyboards,
Function Buttons, Cursors, Etc.It's pretty clear they'll need some kind of list or ring structure to handle their display files 🦋 Whether that structure has to be part of the protocol isn't obvious, since you could just send the equipment byte-stream instead. Still, they feel it'll be needed. They also say the protocol has to anticipate what popular display devices need, like CalComp, Computek, and similar storage displays, interactive displays like Adage, LDS-1, Vector General, and IDIOM, grey-level displays like the PEP-1, and raster-oriented gadgets like the Gould, Versatec, and garden-variety line printers 🖨️
The standard display element types above are assumed to be in common use. Take a point: on a plotter it's a pen-down command followed by a pen-up command, but on an interactive device it's just an intensification of the beam ✨ To plot a symbol at a point, the pen (beam) moves to that point with the pen up (beam off), and then the symbol gets plotted step by step with the pen down (beam on). Graphics devices with beam intensity control are expected to handle the "plot-point-with-intensity" format 💖
Here's the difference between the two-point lines and vectors, in standard display terms: the two-point form needs four data items per segment, while vectors only need two 🦋 With either one, the user should be able to reposition the pen (beam) absolutely by drawing an invisible line. They should also be able to plot dotted or dashed lines without specifying every point or short vector separately. And when something needs emphasis, they want to be able to selectively intensify a line or, on interactive displays, make it blink 💅
Character streams are for text or for labeling drawings 📝 Most of the time the stream is specified by its starting location in screen coordinates, how many characters there are, and where the buffer of characters lives. In some purely output graphics systems, it's specified with a format like printer output, where the characters get placed in the designated area on the display.
Items 5 and 6 on that list mostly matter for displays like Sketchpad and the Evans and Sutherland display 🌸 Viewport is treated as a synonym for "observer parameters in the object space," and a window means "selected portion of the display surface." Transformations of instances refer to a Sketchpad feature that lets you use the same "pattern" for a graphical element multiple times 🔁
New equipment keeps showing up, and some nodes have special-purpose gear, so it's smart to have a way to send equipment-specific info over the net as part of the protocol 🧚 That info would be byte streams formatted to the equipment specs and pointed at the right node and equipment. Each node wouldn't be expected to interpret the nonstandard byte stream. Equipment-specific stuff also includes the info that goes back from an interactive device to the program that started it: joystick or cursor position, lightpen hits, function buttons pressed, and so on. Since those depend heavily on the device, and they lean on display buffers, display lists, or interrupts, the network graphics protocol has to watch out for them 👀
Now the grey-scale stuff, which they're really excited about 🌈 They want to expand what grey-scale display modes can do for showing computer-generated data and for representing three-dimensional objects. So their system will have at least four program-callable display element types for making pictures on grey-level devices. The working names are the procedure names GRIDAREA, MATRIXAREA, SCANLINE, and SCANPOINT. The next bits explain how these modes work from both a user's and a data-communications point of view. The specific hardware isn't pinned down, and they don't rule out that hardware could be built to run this way directly. The SCANLINE is exactly how one display already operates, for example. For now, though, software sits between these procedures and the actual devices 🫶
GRIDAREA
In GRIDAREA mode, the user starts with an initial call that sets the size of the grid they want and how many intensity levels they need. After that, each call sends i, j locations of an area and a byte for intensity 🍓
The initializing call is GRIDSET(N, M, IRNGE). N is the number of spaces across, M is the number down, and IRNGE is how many grey levels to use. It's mainly for grey-scale or pseudogrey-scale displays. Here's the picture:
|<--- I ------>|
where N is the number of spaces --- +--+--+--+--+--+--+--+--+
across, M is the number down, ^ |--|--|--|--|--|--|--|--|
and IRNGE tells how many grey | |--|--|--|--|--|--|--|--|
levels to use. This is primarily J |--|--|--|--|--|--|--|--|
for grey-scale displays or | |--|--|--|--|--|--|--|--|
pseudogrey-scale displays. v |--|--|--|--|--|--|--|--|
--- |--|--|--|--|--|--|--|--|
|--|--|--|--|--|--|--|--|
+--+--+--+--+--+--+--+--+On a Gould Electrostatic Printer-Plotter, the system would need dot patterns to fill areas and fake the greys 🖤 For other displays, a SETSQUARES procedure should be available, so the user can pick different kinds of cross-hatching and character filling for the grid areas 🧵
To enter a data item, you call the procedure like this:
1 <= I <= N
GRIDAREA(I, J, LEVEL) 1 <= J <= M
1 <= LEVEL <= IRNGEI and J pick an area on the grid, and LEVEL says how to fill it 🎨
Obviously, this mode needs a way to end the picture, since the servicing routine has to work on it from the top or the bottom in a sweep mode. Calling GRIDAREA(0, 0, 0) terminates it 🙈
GRIDAREA is really similar to MATRIXAREA, which comes next. The main difference is that in GRIDAREA, the areas get specified randomly, and any areas that aren't specified get left blank.
MATRIXAREA
In MATRIXAREA, the user sets up an area size and a "pseudo-character" set, then writes from left to right and top to bottom, kinda like a line printer 🖨️ Bytes pick which of their "pseudo-character" set to use each time 🦋
Okay so the setup call is MATRIXSET(N, M, DEFINITION, CODE) 💖
The display is raster oriented, which means each "pseudo-character" gets drawn on an N x M matrix of dots 🌈. (A later printer add-on would bring in a matrix of characters 🖨.) DEFINITION and CODE are both arrays that work together to specify the pseudo-character set 🎀. Here's the whole picture, with the original's art and words kept intact:
The display mode is raster ________________________
oriented, and each "pseudo- | _ _ _ _ _ _ |
character" will be on a N x M | |_| |_| |_| |_| |_| |_||
matrix of dots. (A later | _ _ _ |
embellishment for printers | |_| |_| |_| . . . |
would include matrix of characters.) | _ _ |
Parameters DEFINITION and CODE | |_| |_| . . . |
are both arrays, used together to | . \ \ |
specify the "pseudo-character" set. | . \ \ |
DEFINITION is packed with bits |________\___\___________|
according to the following scheme: \ \
\ \
\ __\_______
\ / \
\/ ________ \
/ |_|_|_|_| \
/ |_|_|_|_| \
| |_|_|_|_| |
| |_|_|_|_| |
\ |_|_|_|_| /
\ |_|_|_|_| /
\ /
\___________/DEFINITION gets packed with bits like so 🧩:
n - bits
+--+--+--+--+
|XX| | |XX|
|--|--|--|--|
s | |XX|XX| |
t |--|--|--|--|
i |XX| | |XX|
b |--|--|--|-- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--\
| |XX|XX| | <=== |1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|\
- |--|--|--|--| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\
m |XX| | |XX| \--v--/ \--v--/ \--v--/ \--v--/ \--v--/ \--v--/
|--|--|--|--| n n n n n n
| |XX|XX| |
+--+--+--+--+ \-------------------------v---------------------/
m-groupsSo the bit stream for the definition doesn't care about word boundaries at all 🙈. It's on the MATRIXSET routine to be able to undo that, not on you 💅. Obvi, for user convenience there are standard sets you can grab so you don't have to make your own 🎀. And if you do want your own, we make routines to ease the pain 🫶.
The CODE array is different: it's a byte-stream, so a stream of eight-bit groups, and each group lines up with one of the (N x M)-bit groups 💜. That gives you 256 pseudocharacters for one set ✨.
To enter an item of data in this mode, you call:
MATRIXAREA(ARRAY, LENGTH)ARRAY is a buffer location, and length is the number of code bytes that get put out 📦. Each call puts out one row of the display 🌸. Unused bytes at the end of the stream (the leftovers in the last word) should be zero 🧁. Any codes beyond the maximum allowed on a line get discarded 🗑.
Real talk: this routine is nominally for special character sets, or honestly any character sets that are software generated on dot-raster devices 🖥. But it can also do photomosaic displays, area filling on maps, and developing the ability to make audiovisual aids for presentations 🎞. Iconic range 👑.
SCANLINE ✨
SCANLINE is a raster-scanning display mode where the user picks a raster size, the number of grey levels needed, and the direction of the scan 🌈. After that, the data items only tell you the location and character of a change in the scanning beam (or program) 🦋.
The initializing procedure is:
SCANLINESET(DELTA, LEVELS, ORGMODE)DELTA is an integer for how many display points go into each step 🧚. LEVELS is how many intensity levels to use, and the sign of ORGMODE says whether the scan goes bottom up (plus) or top down (minus) on the display 📍. Either way, we assume left-to-right. The absolute value of ORGMODE gives the starting Y position 💅.
All subsequent calls to this routine look like this:
SCANLINE(X, INTENSITY)The first call gives the origin in X and the starting intensity 🌸. Later calls give the X value of the next point where the intensity changes, plus that new intensity 💖. The program (or device) takes care of stepping the scan by DELTA across the page at the current intensity, so you only send a data item for each change and not each position 🫶. When the next X is less than the previous X, or X has hit its limit, the Y position gets incremented or decremented so the scan continues on the next line 🌈.
We see the device that accepts this display as taking a stream of triplets of bytes 💜. The first two bytes (16 bits) give the X, and the third (8 bits) gives the level 🔥. The end of the stream is three bytes of deletes (all ones) 🙈. This display mode is implemented in hardware on the display at the Coordinated Science Laboratory at this University. It's the same one that was used for the grey-scale work reported by Bouknight 🔬.
SCANPOINT ✨
SCANPOINT is a point with intensity scanning mode 🎀. The scan is handled automatically, and only the intensity of each point needs to be sent to the program (device) 💅.
The initializing call for this procedure is:
SCANPOINTSET(DELTA, LEVELS, ORGMODE)The arguments are the same as for SCANLINE 🧁. The difference is in what the subsequent calls mean. The origin for the scan is at the left end of the line corresponding to the absolute value of ORGMODE 📍. Stepping goes from left to right, and at the end of each line, the Y position is incremented or decremented by DELTA, depending on the sign of ORGMODE ✨.
Subsequent calls to this procedure look like SCANPOINT(LEVEL), where LEVEL is the intensity level at which the next point gets displayed 🦋. In this mode, every point must have its intensity specified by a separate call (a byte to the device) 😭. Beyond the starting point, though, no position information is required 💖.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Hamid Dastkar 09/99 ]📦 where this page comes from
- ietf: rfc184 1971-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms