Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP Path: utzoo!watmath!clyde!floyd!harpo!eagle!allegra!alice!rob From: rob@alice.UUCP Newsgroups: net.unix-wizards Subject: Blits and terminal paging Message-ID: <2568@alice.UUCP> Date: Fri, 3-Feb-84 02:32:22 EST Article-I.D.: alice.2568 Posted: Fri Feb 3 02:32:22 1984 Date-Received: Wed, 8-Feb-84 03:14:45 EST Organization: AT&T Bell Laboratories, Murray Hill Lines: 87 I have been implicated in the TTY paging discussion in some private mail, so here is how the (to you) unobtainable Blit affects my world view: Bart Locanthi and I built the Blit to provide cheap high-performance interactive graphics in our time-shared Unix computing environment. I think that, looking back, we are both surprised at how it turned out, and particularly that it is so popular and useful. The surprise is because the important decisions, from a systems point of view, were made in almost complete ignorance of how the terminal would be used. We were at least as lucky as we were capable. The Blit runs much like an extension of the Unix kernel, off-loading the expensive computation required for high-performance interaction, but staying tightly coupled (at least in function; it can run over 1200 baud telephone lines) to the Unix host. Many people, perhaps most, ask why we didn't just make the Blit a personal computer. The answer is that we didn't want personal computers, but the question can be rephrased as, "Why don't you turn it into a personal computer?" and the answer becomes more interesting, and unexpected: The division of function enforced by the architecture of a programmable terminal separated by an RS-232 line forces some design decisions that would not be made otherwise. We were lucky in that many of those decisions result in better interaction, simpler function and much simpler software than what would develop were the same functionality provided on the host. This is hard to defend in a brief note, because the reasons are many small things rather than a couple of obvious advantages, but one exemplary effect is that the operating system running in the terminal (sic) has a much simpler structure than Unix -- in fact, it is a real-time system; getting such good interaction from Unix would require a fair bit of real-time functionality in the Unix kernel. We were able to avoid that morass altogether. So where does terminal paging come in? The Blit is the interaction box, but is tightly coupled to Unix. In (at least the research version of) the Blit software, the tty driver runs in the terminal itself, connecting directly to the bare I/O system in the kernel. As a result, characters can be echoed locally (by the terminal) although the terminal is running full-duplex -- the Blit interprets the stty structure itself -- and Unix programs are completely unaware that the tty driver is running in the terminal. This architecture has enabled us to write a Unix tty driver that employs high-quality interactive computer graphics. The Blit lets you copy text from window to window, edit text on the screen and retransmit it (unlike csh history, this works for any command and on output as well as input), and interactively control when the terminal scrolls. The default is to never scroll without an explicit command, but if you want it to always scroll, just say so with the mouse. All this is achieved without adding special-purpose code to the kernel, although it does depend on the IPC mechanisms of the current research Unix system. Although the Blit is renowned for its windowing, this high-level support for interactive text manipulation is closer to the original spirit of the terminal, and, I feel, at least as important. This is probably a religious issue; the terminal feels so different that many users don't run this new software on their Blits, but they will in time. Paper terminals aren't too common any more. So discussing whether paging belongs in the kernel is skirting the real issue. Paging is only an instance of control over the contents of the display, and convenient though it may or may not be, it opens the door to a bewildering array of features that do not belong in the Unix kernel, but that fit perfectly into a different architecture: one that admits that interaction is important. I never used display editors until my terminal had a mouse, because two-dimensional output is too clumsy to manipulate with one-dimensional input. Since all the interaction with Unix involves text in one form or another, the obvious step is to develop the interactive components of the system until the `text editor' merely couples the general text- editing capabilities to files on disk. Such integration is difficult, of course, and I offer no solace to those without Blits. But I encourage those who would hack the kernel for more interaction to at least be aware of what they should be trying to achieve, and how much they can realistically accomplish. Rob Pike