moraes@cs.toronto.edu (Mark Moraes) (02/21/90)
In <TQV1CHCxds13@ficc.uu.net>, Peter da Silva asks: >Is there any way other than NeWS, then, to move the UI where it belongs... >in the display the user is working on? There's the Blit family. (Blit, Jerq, DMD5620, 630, and their associated software -- mpx, mux, layers) One writes the program in two parts, a host end and a terminal end. Instead of using PostScript for the terminal end, one uses C, cross-compile, link and download to run. (The downloading provides a great incentive to keep programs small) Since the terminal runs compiled code, it can be made to run quickly. This is A Good Idea, since terminals tend to be CPUs with less horsepower than the host. (of course, since various vendors want to sell you More Powerful Machines for your desktop, they may view this sort of efficiency as A Bad Thing) Since the terminal end is in C, one doesn't have to learn a new language to program the display in. (I know some people would vociferously deny that PostScript is a language:-) And one gets to use all the tools that exist on Unix for working with C code as a peripheral advantage. (One could probably use some other compiled language if one had an appropriate cross compiler -- it's just the only cross compiler I know of for blits is a C compiler) The graphics library has none of the fancy classing stuff and "advanced imaging model" of NeWS -- a simple old bitblt, line and rectangle, character drawing and a few communication primitives. It has non-preemptive scheduling (like NeWS), and mouse tracking is done by the terminal. Only monochrome, unfortunately. No subwindows -- the theory is that subwindows are easy to do in the application, since they're really a UI component. None of the gazillion graphics context options of X11. But then, the terminal component has access to the raw frame buffer bits, so if it wants to do something fancy, it can just go and do it. Each blit application is given a bytestream, it can invent its own protocol. Which means a bit more work, but more flexibility. Hello world is not a great blit example -- it can be coded entirely in the terminal. A better example would be something like a text editor, where the terminal handles display of the current screen and mouse/kbd interaction, and the host end handles the file/unix interface. Conceptually, it's the window system I like best, and its performance is outstanding -- it remains the only window system I know of that runs effectively over 9600 (or slower) baud serial lines, and runs faster on a 68000 based 1M platform than most X11 implementations on bigger hardware. (X11R4 is faster, I think, I've seen at least one blit fanatic work semi-contentedly on a Sun running X11:-) The blit doesn't bother too much about look and feel issues - it provides a fast kernel in the terminal and lets the applications worry about the look and feel. (I don't particularly like the trend towards enforcement of uniform look and feel, and the megatons of marketing hype that surrounds things like Open Look -- I always preferred the "make it functional, make it fast, then make it pretty" axiom) Alas, last I heard, the nicer blits cost about as much as an X terminal (I don't like the old Blits with long-persistence green screens, which are cheaper), and the software doesn't come with full src unless you get Research Unix. Its software is also somewhat, er, hard to port (at least judging from the cussing and swearing I heard when someone here was trying to get mux working on his brand new 5620:-) AT&T has kept the blits a well guarded secret, it would seem. For those who want to know more about it, the main reference is: %A Rob Pike %T The Blit: a multiplexed graphics terminal %J Bell Laboratories Technical Journal %V 63 %N 8 (part 2) %D October 1984 %P 1607-1631 The programmer's manual qualifies as the smallest window system programming manual around -- at 12 pages, it is well under the ~45 page MGR manual and the ~60 page X10 manual. I don't know of it in published form anywhere, alas. %A Rob Pike %T The Blit Programmer's Manual (TTY Edition) %J Eighth Edition Unix source, /usr/blit/doc/manual %P 1-12 %A Rob Pike %T Window Systems Should Be Transparent %J USENIX Computing Systems %V 1 %N 3 %P 279-296 %D Summer 1988. %A Rob Pike %T A text-oriented terminal multiplexor for Blits (abstract) %J Proceedings of the USENIX 1984 Summer Conference %C Salt Lake City, Utah %D June 1984 %P 173 The next two are implementation refs. The paper on hardware/software trade-offs is good one -- that, and a paper by Bart Locanthi in a EUUG conference ("Fast BitBlt using asm() and cpp", I think -- I don't have the exact ref or my copy handy) explain why the blit is so darn fast -- someone cared about performance. :-) %A Rob Pike %T Graphics in overlapping bitmap layers %J ACM Transactions on Graphics %V 2 %N 2 %D April 1983 %P 135-160 %A Rob Pike %A Bart Locanthi %A John Reiser %T Hardware/software trade-offs for bitmap graphics on the Blit %J Software - Practice and Experience %V 15 %N 2 %D February 1985 %P 131-151 A slightly less serious article, included here since it had Blit in the keywords:-) %A A.K. Dewdney %T Computer recreations: at Bell Labs work is play and terminal diseases ate benign %J Scientific American %V 253 %N 3 %D September 1985 %P 12-16 %K Blit, DMD 5620, crabs There are also related references for sam (a nice text editor, not my first preference, but certainly my second. It also runs under X11) and pi (a debugger -- also in the Oct 84 Bell Labs Tech. Journal) And there's Rob Pike's paper on "A Concurrent Window System" in Usenix Computing Systems, v2, no.2, pp. 133-153, Spring, 1989 describing a multithreaded window system written in NewSqeak ("a language for communicating with mice":-)
jesup@cbmvax.commodore.com (Randell Jesup) (02/22/90)
In article <90Feb20.084318est.1445@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: >Conceptually, it's the window system I like best, and its performance >is outstanding -- it remains the only window system I know of that >runs effectively over 9600 (or slower) baud serial lines, and runs >faster on a 68000 based 1M platform than most X11 implementations on >bigger hardware. (X11R4 is faster, I think, I've seen at least one >blit fanatic work semi-contentedly on a Sun running X11:-) Then again, a 1M (of non-display memory) 68000 Amiga can run X11 faster than most suns can. Of course, having a hardware blitter and fast lightweight tasks doesn't hurt. Disclaimer: I work for Commodore. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
chet@cwns1.CWRU.EDU (Chet Ramey) (02/24/90)
Mark Moraes writes about the Blit: >The programmer's manual qualifies as the smallest window system >programming manual around -- at 12 pages, it is well under the ~45 page >MGR manual and the ~60 page X10 manual. I don't know of it in >published form anywhere, alas. > >%A Rob Pike >%T The Blit Programmer's Manual (TTY Edition) >%J Eighth Edition Unix source, /usr/blit/doc/manual >%P 1-12 It is available, as a tech report from Bell Labs. I have a copy, and go back and re-read it occasionally when I get too frustrated with the volumes of X11 documentation. Write to: Comp. Sci Tech. Reports AT&T Bell Laboratories Room 2C-579 600 Mountain Ave. Murray Hill, NJ 07974 Ask for CSTR #121. It's free. Chet -- Chet Ramey "Can't you pay a grad student to Network Services Group read the manual for you?" Case Western Reserve University -- Bill Wisner, chet@ins.CWRU.Edu to Peter Honeyman