BILLW@SRI-KL.ARPA@sri-unix.UUCP (06/10/84)
From: William Chops Westfield <BILLW@SRI-KL.ARPA> Here the original description of the Zubkoff code for compressing data streams. Please note the date: many of the files mentioned no longer exist, and the marketing info is of course out of date. BillW ------ Date: 5 Aug 1981 2251-EDT From: (Leonard N Zubkoff) <Zubkoff at CMU-20C> Subject: New Concept-100/104 Software This is a general announcement to the ArpaNet community of an alternate set of software that may become available for the Concept line of terminals made by Human Designed Systems (HDS). For the past several months, I have been engaged in a personal project to rewrite the Concept software in order to provide a level of functionality more in keeping with the needs and capabilities of the Computer Science community. While the software is not yet completely written, it has been operational for the last 3 months and is in use in several terminals here at Carnegie-Mellon University. Since we at CMU have copies of the original HDS software under a non-disclosure agreement, I am not at liberty to distribute the software I have written beyond CMU. I have been in contact with officials of HDS, and they have shown interest in making this available to the Concept user community if there is sufficient demand. The purpose of this message is two-fold. First, I want to solicit comments about the software I've designed in order that I may incorporate other features that I may have overlooked. Second, I need to determine whether there is a demand in the Concept user community either to upgrade existing terminals or purchase new ones with my software as opposed to the standard software supplied by HDS. Let me begin by giving a brief description of the goals I set for the software. The software was designed explicitly for the type of environment we have now and are developing at CMU. At present, screen oriented editing with Tops-20 Emacs/Tops-10 Fine/Unix Emacs is the norm and terminals are used both at home over dialup lines and in offices at 1200 baud and 9600 baud. In the future, Spice (personal) machines will be the dominant resource in the department and terminals like the Concept will have little use except as a home terminal with which to call up one's Spice machine. Thus the dominant use of the terminal where sophisticated capabilities are required is in the area of screen management by an editor. In addition, the likelihood that most of these terminals will ultimately be used from home over a 300 or 1200 baud dialup line has made the issue of efficient screen management extremely critical. All office terminals will be supported at 9600 baud in the near future. Thus the issues of efficient screen management and data transmission to the terminal emerged as the most critical areas deficient in most terminals available commercially, and it is to optimize the Concept terminal in these respects that the greatest part of the development of my software has been devoted. Since we already have a great deal of software that supports Concept terminals, it was also necessary that my software be able to emulate a Concept with HDS software to such a degree that the normal Emacs, Fine, BBoard, and other programs would operate properly without change. In order to utilize the unique features of my software, and to gain information about how it is performing, I have written a screen management program that I use to run Tops-20 Emacs. This program is invoked like Emacs but crosspatches the terminal through to an Emacs running as a subfork. In general, support for the new terminal software should be placed in the editor itself, but the nature of the implementation of Emacs/Teco is such as to preclude doing this directly without a great deal of work. Emacs itself provides a very poor screen management facility; it is not smart about making optimal use of the primitives available in a terminal to cut down on the number of characters sent to update the screen. My program maintains screen images representing the actual state of the screen and the desired state of the screen, and attempts to perform an near-optimal transform from the actual to desired states at appropriate intervals. In order to measure the improvement in screen update time, the program keep counts of both the number of characters that Emacs sent to the program (which would have gone to the terminal if it were not for the screen management algorithms) and the number of characters that the program was required to send to the terminal in order to effect the same resulting screen image. I term the ratio between these two numbers the compression ratio achieved by the screen management program. It represents a very real measure of the actual speedup in screen redisplay provided by the program. In actual use, this program now achieves compression ratios ***Error on net connection*** === brl-aos netread error from sri-kl.arpa at Sat Jun 9 23:26:08 ===