Blits and terminal paging

[rob at alice.UUCP]

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