Project Athena - X Window System Users and Developers Conference, Day 2 [2/6]

[INTRO MUSIC]

PRESENTER: What I'm going to talk about is a project which-- which we're doing at Berkeley, having to do with building a programming interface for a database system. And in particular, it's for the next generation extensible relational system being built at Berkeley, by the name of Postgres. This is the follow-on to the Ingres project that Mike Stonebraker and I are doing.

I will mostly today talk about the programming front end system that we're building. And this is really work in progress. So this is not-- I will tell you at the end what's completed and what's not.

First off, the goals for this system. Object FADS. FADS stands for Forms Application Development System. It's the third system in a series that I've been building for the last six, eight years, where you build applications by filling in forms. And those forms then cause pieces of the application to be built.

This system is going to be on a workstation interface, multiple window mouse interface, graphical data and program display, all these good things. After working for a while, it's pretty clear you want an object-oriented programming environment. And my real goal was to build something that was portable, that we could pass around to a lot of different people to use. And so we've decided to use Common Lisp as the implementation language. We're using Common Loops as the object hierarchy system. We actually got the PCL implementation from Xerox and have been using that.

The database portion of this is that we're going to make that object hierarchy, or a part of that object hierarchy, be shared across multiple workstations, so that the programs can access objects, but those objects might be persistent and might be simultaneously referenced and accessed by other workstations. In terms of the programming environment, the specific stuff that we're working on is an Extensible Form system from the database world of form. It's what you see on a screen. And we've built a couple of these and they've pretty much been static beasts. And we want to make it extensible. And I'll say something more about that later.

Then lastly, the model that we use for describing these chunks of application that get built is a notion of a frame. And we're going to make the system extensible in that dimension as well. And I won't have a chance to talk very much about that, because of the time. Rather, I'm going to focus on the software architecture and interconnection to the X window manager.

This is what the world will look like. Inside the machine, there will be multiple processes centered around this Lisp process. And within the Lisp process, you have to have some concept of subprocesses. So you're going to have multiple windows on the screen and you want to have a concept of a chunk of Lisp code bound to a particular window. So we have multiple what we're calling subprocesses and an event driven scheduler in there to pass events to it. So Lisp interfaces to the X server, which displays the windows up on the screen.

In addition, we're using Emacs as our editor environment. And we've built an interface between Emacs and the Lisp system such that the window objects, which we've defined in the PCL hierarchy, can either be X window objects up here or they can be Emacs buffers. So it's possible for you to write Lisp code that takes events and data from one of those Lisp buffers and goes off and manipulates it as well. What we plan to do with that is to eventually do things like have the debugger when it wants to dump the stack trace actually just pass that stack trace up to an Emacs buffer and then let you search it and play with it up there.

On the other side, there's an interface to Postgres, which is the database system, and then it has to manage access to the disk. And the database system has some additional processes that it has to deal with, which is the postmaster. Postmaster, the startup daemon, if you will, for starting up Postgreses.

So that's what the system architecture looks like. A little bit of details about some of the pieces and what we've built. we have an object-oriented interface to X. And we've implemented it very similarly in spirit to the system that was described just in the last talk. We took and foreign function interfaced the X live interface into the Lisp that we're using. We're using extended Common Lisp from Franz Inc.

And we've got it both on Suns and on VAXes. And we move the Lisp process around to one place or another, depending on where we can find some free cycles. In fact, last week we got our 8800 working. And the students working on the project tell me that the world's best personal machine is to have a Sun-3 up front with a lot of memory on it connected to the 8800. And they run the Lisp process back on the 8800, so. I hope they don't find out about the Cray in the basement, or-- [LAUGHS]

What we've done with PCL is that we've actually defined a bunch of objects which correspond to the kind of high-level objects you'd like to have, like display objects window objects, font objects. We have a very primitive set of menu things. We also act-- foreign-function-interfaced in the X menu package as well. We have a concept of events in the environment and we're working on the forms objects, which I'll talk about in a bit.

We've built and in-- well, we're in the process of building an Object Browser for the PCL object hierarchy, and we could actually-- I saw the other day an actual hierarchy displayed on the screen. And the idea is it's a standard sort of thing where you can button the objects and take a look at the instance variables class, variables, methods, and the like, and edit them and that sort of thing. The thing that we've gotten running that's kind of the core of the system is this event driven scheduler. Basically, we have multiple windows connected to a Lisp subprocess.

And as I mentioned before, these processes can have access to an X met-- X window or Emacs buffer. The interesting thing about the way the scheduler works is that we get events, convert them into PCL objects of type event, and then we do just a straight method call. And that does the determination of which event handler to call. And I'll show an example of this on the next slide. In addition, the scheduler handles a primitive concept of global and local variables.

Now, the scheduler currently is written in kind of neutral common Lisp. So we don't do preemption or anything like that. And the reason for that is that I'm really trying to build a system that will be ultimately portable. The comment that the previous speaker made is absolutely true. Around Berkeley, if I wander around the halls and look at what sort of workstations there are, we seem to get one of most. And so in the past, we did real well by having portable code that would run across them. And so that's why, if you notice in most of my decisions, is what we're doing. We're doing it with portable, public domain types of code.

Just briefly to show you how someone would code a subprocess, here is an example of a part of the event hierarchy. You have the event and then the X event. For example, you could have a keydown event or a button press event. And to define a particular subprocess, say P1, all you have to do is define a method that takes an argument of whatever the events are that you'd like to catch. And so the collection of those methods in a sense defines the process-- the subprocess.

And what the scheduler does is to take the events from the server in through Xlib, pass it through this thing that converts the event to a PCL object, hands that PCL object off to the scheduler. Scheduler looks up the window process subprocess binding and then just does a straight method call to get to the correct code within that thing. And that works fine for events that don't happen real frequently, but for events like pressing the key, if you had to-- if you had to create a PCL object and do a method call on every keypressed, the 8800 would be reduced to rubble in terms of performance. So one of the things that we've done is that for events which are collecting up larger objects, so if you have a sequence of characters you're collecting into an s-expression, or if you're filling in a form and you have a sequence of characters that go into one field, what we're going to do is have that event handler, are going to custom-code those in a way that after they get the first X event through the PCL hierarchy, they'll turn around and ask the lower-level interfaces to get more events of that same type without having to create the PCL object and pass it on. So essentially, an optimization to try and make that go faster.

And we actually have the scheduler running and text window, and we even had a listener window up and that sort of thing. And it runs-- it runs acceptably performance. I wouldn't say it's blazing fast, but it was certainly acceptable interactive behavior.

Okay, the shared object hierarchy, this part is not really done yet, so this is really futures. Basically, what we're going to do is define in PCL a metaclass called DB class. And then anytime you define a class, which is of class DB class, then objects of that instance will, in fact, be stored out in the database system. And what we're going to have to do in the list system is maintain an object cache to fetch objects from the database system into this object cache. And I've written a paper on a design for that object cache, including prefetching and some precomputation of the objects which are being stored out in the database system, since they are going to be normalized into a tabular representation. Distributed Cache update and some ideas on transaction management for objects. So anybody who is interested in that paper on shared object hierarchies or Postgres, send me mail at Berkeley and we'll be glad to send you a copy of that design.

Let's see. When do I have 'til? What was my deadline? Ten 'til? You're going to try and make me give it all back? Okay.

Let's talk a bit about the form-- the forms interface and the kinds of visual programming tools that we're trying to build. Just so that we all understand the same thing by a form, here's a form displayed on a screen. It's what you would think if you were doing a paper form on the display. And these forms can get very complex. And here's just a small listing of the kinds of complexity that you have. First off, the form is composed of all sorts of different fields where data is entered and displayed.

So here we have a field where you enter name. Here is something that looks kind of like a table down here, and this table obviously should be scrollable left, right, and that sort of thing. Now these components in here can be various things. They can be trim, like employee information up there, which doesn't change. Labels, like the label associated with a field, which, incidentally, if you want to pick this field up and move it elsewhere, you really want to get both the label and the field itself. And then you have the actual data field where the data is entered and displayed.

In any form system worth its salt, you've got to have a bunch of facilities for display enhancements, font, blinking, color, dot, dot, dot. In fact, that list seems to go on forever. In addition, you want to have all sorts of usage characteristics about those various fields. So if, for example, you're doing data entry, you want a concept of a mandatory field so that if someone is entering values, that they're forced to put a value there.

Sometimes when you're using the display or the form for output, you want to display a value. You want to say, look, I'll display a value in this field, but you're not supposed to be able to update it. So it's a display only field. And there's a lot of other usage characteristics.

In addition, you can have a concept of an active form where doing things in the form can in fact cause computations to be done. So for example, leaving a field, you might want to invoke an edit check. Entering the value of a name, might want to spawn a computation to go look up the street and city-- city address and the like.

Okay. Well, there's what you got to do if you're going to do a form system. And what we're trying to do is to satisfy two constraints, which I haven't seen a system that satisfied before. Which is one, we want to make the form system extensible, which is to say that you can put in new kinds of fields in the form.

But we also want to build a WYSIWYG interface for allowing you to define these forms. And so here is a set of abstractions of objects for describing these various components in the field that we're off implementing. First off, the composition is going to be that everything is a form. So you can have character forms, text forms, bitmap forms, graphics forms, kind of the primitives.

Then you have structured form types. So you can have a collection form, which is what that previous slide was showing. Table form, showed one of those. And here's one that everybody's seen and it's hard to figure out how to model, but a variant form, where if you enter a value into one-- into one field, it will cause one or more of the variants to be displayed.

So the obvious example is, I suppose, if you enter marital status, it asks for information related to different marital status. Or if you're married, maybe asks for spouse's name or something. Then you have, if you're in the business racket or statistical racket, you get these cross-tab forms where there's variability in the data down the column as well as across the top, which are pretty common.

Now the thing we're trying to build is something that will allow you to do a form kind of like this. Excuse my poor drawing. Where you can nest things inside of other things. So you have a standard kind of master detail form. And here you have a table, but the rows of the table can in fact contain these more complex objects.

So here we have say, personnel, in a department. You have a name. And then within this one column you have another table field that lists performance evaluations or reviews or something. And just to show we're going to do graphics. You can put a bitmap over there that shows the-- person's picture as well.

But the thing that we've got to do-- I mean, you could build this sort of beast today, and there have been several Lisp programming systems that have built object-oriented user interface mechanisms. But they don't really have, at least I haven't seen, WYSIWYG forms. What you really want to be able to do is you want to be able to say, gee, give me a-- give me a bitmap form right there.

And it will then drop it up there. You say, well, gee, I don't like it there. Let's move it over here. Let's change this thing.

So that you really get a "what you see is what you get" editor for these forms objects. So what we're doing is trying to define what the abstractions are for objects of type form and then build the editor that would operate on those kinds of things so that we can build forms interfaces.

What are we doing, five.

Okay, just for advertising's sake, let me put up the one page description of what Postgres is. This is the new database system that we're building. It's going to be an extensible relational DBMS and extensible in the sense it's going to support data types and access method extensions.

One of the big things in the database racket is a problem having to do with support for complex objects. And in particular, Mike and I have this idea for how to support complex objects in the database system by supporting procedures as built-in types which can be stored in fields in a table. In addition, some precomputation and caching, which is what we're going to use to support this shared object hierarchy I described earlier-- mentioned earlier.

From the database perspective, the world looks like there are these great AI expert systems and you can build very sophisticated expert systems, but they operate on in-core databases. And you talk to people who are building commercial-strength AI applications and they say, gee, I've got this great expert system over here that works on this in-core database. And I've got this 10 megabyte database over here on the disk. How do I get those two guys together?

And so one of the things that we're looking at is how to provide support for rules and inferencing in the database system. And it turns out that there's a nice way that you can use some mechanisms that are already found in most database systems, triggers and alerters, to support forward and backward chaining priorities, and the notion of early versus late evaluation, which really factors in the precomputation.

Another thing in the database world that you really need is version control and historical data support. Basically, it's going to be a write-once storage system so that, in fact, you can roll the database back to a previous state and look at it. Or you couldn't ask queries that involve time-- time series. So give me the names of all employees who've gotten more than a 10% raise in the last six months.

And the hardware technology that both the database system and the front end are based on is a notion that optical disks are here to stay and we want to support optical disk. But probably more importantly is this tightly coupled multiprocessors that we see a lot of people building. The SPUR project at Berkeley is one example of such a beast. And so one of the things we're doing in the design is we're saying let's spawn a lot of processing in the background to take advantage of all those extra processors, because we don't know how-- I mean, the SPUR system is talking about building 610 processor workstations. And it's not clear how you take standard Unix programs and run them on 610 processor workstations.

Okay, here is something that tells you what the current status is. Next Tuesday we have a big demo of both Postgres and some of the front end that will execute-- the back end at this point executes the core of the query language. It doesn't work on the historical storage system yet, but it does do all the querying kinds of things. Query optimization and access methods and the like.

The Object FADS environment, we've got the Lisp server running, the X window manager interface. We have PCL objects for windows, fonts, events, and all these kinds of things. The Emacs integration works. We have the primitive Object Browser. We've also got a low-level implementation of Postgres that we can actually take data from the database. And what they're working on this week and hopefully will get done is the ability to take that data from the database and actually show it through a form so that you can actually do data entry and browsing through the form.

So that's where we are. Our intention is to get these two systems working well enough that we could actually send them around to other people. In fact, we've already sent around the foreign function interface of X into Franz Common Lisp. And we're perfectly happy to send that to anybody who wants, just send mail to me at Berkeley again and we'll be glad to send it. And probably sometime late this summer, we'll have enough of the rest of the system that we can actually send that out as well.

Okay, questions?

AUDIENCE: [INAUDIBLE] implementation [INAUDIBLE] versus others?

PRESENTER: The only code that I am aware of that's nonstandard is the foreign function interface part. And so we plan-- around Berkeley, if I count machines, okay. There are a lot of Suns, a relative number of MicroVAXes, and one each of everything else. And so we plan to port it to the Common Lisp basically when they get their act together, get the thing debugged and running a little bit better so we can do it.

We actually are using one MicroVAX on the project. But if somebody else wants to take it and do the foreign function interface changes, we're perfectly willing to send them to you and help you, no problem.

AUDIENCE: Which brand of Emacs?

PRESENTER: We're using the GNUMACS. In fact, I think somebody before was asking about mapping mouse events into whatever. I think that works in GNUMACS. I mean, so get GNUMACS. That's all taken care of. Okay, thank you.

[APPLAUSE]

MODERATOR: Okay, we're going to break for coffee. There's a lot of people here. Maybe try and stagger yourselves a little bit. As you get coffee and stuff, some of you should move back in here so the [INAUDIBLE].

[SIDE CONVERSATIONS]

COLEMAN: Okay, okay, if we're all ready, I guess I'm ready. My name is Greg Coleman and I'm from Locus Computing Corporation. And the work we're doing involves two things. And I've titled it, DOS in a Window on System V or at least three-- 386 UNIX system. Actually, let me say a few more words at the overview level.

What we have is the ability to one, run X windows on a small machine that looks like an IBM PC/AT. It actually has a 386 processor. And we can run a DOS task in a window in this system. You can have a C-colon prompt and run DOS programs. You hear little bit more about that later on.

So the effort-- very independent effort-- so the port itself to the System V release 3 kernel and the development of a client process that interacts with the VM86 task to allow it to be displayed and to provide keyboard input to the DOS task.

The development environment for the task, we actually started with an early release of a kernel, an alpha port of the kernel. There are some functionality not available that influenced some of the choices we made in our implementation. This is like I said System V release 3 as ported to the 386 system. And actually ported by Interactive Systems Corporation.

We used an Intel 310-based system for much of the development work. That's our main workhorse system. The 386 processor is very fast, so that the small system offers approximately five times the CPU performance of a VAX 750, although the disks and so forth are not of the same comparable capabilities. The actual target machine, again, was a AT-compatible machine with an Intel 386 processor.

The port involved-- there's a few changes to Unix to allow this to work. System-- System V release 3 was the first System V system that inherently had some of the features that are very important to make a system like X work. In X, all the-- it depends on the-- asynchronous event processing and the clients and server. And System V release 3 now has a poll system call that was used as the basis to make all this work.

But it did not support polling on devices. We had to-- or we chose to extend the polling support to include devices. You could choose to write a device driver with very few changes to make it be pollable.

We had-- we modified the PTY driver and the-- and the device drivers that we wrote that were part of the virtualization of the real mode 8086 machine. The VKBD is a virtual keyboard device, and we had a display device. And-- and the actual device that VCT-- CRT, which is the device-- a Unix device that connects to the virtual DOS display. Some this will be explained a little bit more later.

We also took a little more work to add the shared memory support in the-- to communicate between the X server and the display and keyboard. Actually, mostly, it is for the mouse events and for the keyboard events, communication to the server. Had to make some changes to the memory management portions of the kernel.

The server changes, most-- many of them had to do with the fact that we had to change the interprocess communication from TCP or DECnet to a streams-based system. It is a simple streams device that's actually distributed with the SVR3 kernel that is used for the IPC. And of course it only works within the processor, and does not allow networking.

The networking support was not available in the kernel when we started the project. And so that was not an option to use, actually use the networking-- the TP4-type transport layer that they have. And of course the event processing, we wrote an emulation of SELECT using the poll system call to avoid the changes to the code as much as possible.

The last item is something that many people might find objectionable about-- that we did, but we actually have a capability of allowing the DOS task to get a special type of full screen to-- full screen display where it attaches directly to it. Since we have large bodies of DOS application programs that manipulate the display directly and translating those through the X system is difficult or impossible, or at least takes large amounts of CPU cycles. This-- some of this will also be explained a little bit more later.

The Xlib changes-- again, mostly confined to the stuff associated with interprocess communication and the polling and event processing and handling. Much of the rest of it ported over with minor changes and allowances for the different operating systems.

Xterm, of course, one of the first applications we ported. Again, nothing terribly difficult. A few that required a good understanding of what was going on with the-- setting up the controlling terminal and so forth that is sort of mysterious in the Unix world.

AUDIENCE: [LAUGHTER]

COLEMAN: But most people-- a lot of people have been through it. And if you've been through it, then it's fairly easy to figure out. For those of you that probably have never looked at this, you have no idea what I'm talking about.

The other thing I will say is that the Xterm was used as a basis for the process we called X DOS. For the PC with a monochrome display, much of what has to happen with Xterm, and we called it X DOS, was very similar. The Xterm has a virtual terminal implemented within it where it saved the state of the terminal, and then uses that to update the window display. And with X DOS you have a PC display memory area that sort of corresponds to the virtual display implemented in Xterm. And so we used most of Xterm in the process.

That's for character-oriented displays. When we made it-- when we went to support even some graphics display-- or graphics DOS devices, there's less use from the basic Xterm. Keep wanting to flip these over.

I thought I'd talk a little bit about the nature of the display that we're using, because that ends up being fairly important to some of the stuff later on. It's not near as-- not as many pixels as a Sun display, for example. It's basically like taking a fourth of a Sun display or something. And this was the highest resolution available as a standard PC display. And it's adequate in that respect.

But certainly larger displays, I believe, are needed and will be coming before too long. It has-- when used in color mode, it actually has four planes and they actually occupy the same address space. And one has to do I/O operations to address the different planes. It makes it very difficult to get high-performance operation.

Of course, the other thing contributing to that is the fact that the display is actually a byte-oriented display. I mean, it works on an 88-based IBM PC. And it also is sort of inherently slow because it's designed so you don't have to wait for retrace or blanking to do updates, which implies it inserts wait states as necessary to coordinate the activities of the CRT controller and the main processor. So we have a very fast processor trying to drive this thing. We have sort of a bottleneck there actually getting to the display.

We actually have color working and it has-- it works four times slower than monochrome, basically. And the monochrome was marginally fast enough as it was. The device is-- the actual programming of the device is not very well documented. It's one of these devices with thousands of registers. A slight exaggeration, but-- and there's always a few bugs in the documentation where it doesn't do exactly what it says and you have to find out the hard way disassemble some code here and there to see how someone else did it or whatever.

And the I/O instructions are a problem, because normally the I/O instructions are privileged. And so you're going to have to do some kind of a system call to do that operation, whereas the actual display updates we have mapped into the process memory space. And so we didn't have to pay any penalty for that type of operation.

On to what we did for the X EGA lib. The device driver is modeled after-- I think we actually started with like [? 2VSS ?] or something. It was one that was available. And we-- it just maps in the display to use-- to the server's address base. Also, provides this direct-- direct access to the screen memory.

Cancel that last statement. I was trying to imply something that was incorrect. This is what sets up the mapping so that the server can access the physical display. And establishes a shared memory for the event queue that's used to pass events to the server. The support for direct-screen attachment is the thing I alluded to earlier, where a DOS task can be given the full display.

The way it's done is we actually have a virtual EGA device as part of the DOS task. And we can plug that in to the physical display and unplug it also. So we can allow the DOS direct access to it. And X windows sources spins and knows about when this is happening. And can revoke that when it needs to.

The keyboard driver-- we did make it part of the same driver like we suggested. This is not too much. I'm going explain a little bit, well-- the basic portions of the DOS client. One question is-- I'm going to explain a little bit more about what the-- how the DOS environment is set up and what Merge/386 is about, and then how the DOS client communicates with the VM86 task. The DOS client is a client like most any other X client, except for the fact that it communicates with this different type of Unix task.

Merge/386 provides a virtual PC/AT on this Unix system. The processor itself has the basic support necessary to virtualize an 8086, 286, or a 386 operating in the real mode or unprotected mode. Real dressing is real mode addressing. The product allows integration, migration, allows people to grow up into Unix, maybe, and still carry over their favorite applications and the things that they're used to. Or for people that don't want to leave DOS, that allows them to use the DOS environment on a Unix system.

So DOS programs can operate on a Unix system with integrated file system. The DOS files are Unix files, is the way it looks. And this is done by mapping the DOS system calls into Unix system calls with a server process.

The virtual machine monitor for the PC, three basic parts. You've got the emulation, the privilege instruction sets. And you've got the device emulation.

You have to build all these devices that are normally part of a PC and software. Several of those then have to interact with the X client. And you have the integrated file system, which is provided by a system called redirector.

Now, the DOS client-- the way it operates, it basically-- this is sort of the simplified version. It reads from the virtual PC display and then updates the windows display, the X windows display, by making Xlib calls. And then similar and fairly simple in terms of keyboard events, it accepts keyboard events and one thing different here than other things, it has to get the keyboard-- the scan codes. Ultimately, you have to deliver scan codes to the DOS task. That includes not-- keypress, key release events.

And turns out, X was actually-- it was fairly easy to adapt this-- to make this all work. It's something that when we first looked at it might have been pretty scary, trying to make this all work, but it was very easy to do. We haven't completed it yet. We want to set it up so that mouse events can be focused on a DOS task, so that the mouse will be available to the DOS task, can be translated and passed into a mouse device driver that DOS expects.

I'm going to talk mostly about the display aspects of this interface, because that's the most interesting one, really, out of them. The other ones-- the way the keyboard is handled is fairly straightforward and not too interesting. We're actually-- currently handling two types of displays, one the monochrome or character-oriented display, and the other a color graphics adapter, which is a basic-- a low-resolution color adapter. And it's-- the basic subsystem consists of the display memory and a CRT controller.

So our virtual machine has display memory allocated in the-- what appears to be the normal place in a PC for the display memory. Essentially, that the DOS environment is built with everything appearing in its normal place. And the CRT controller is a software virtualization so that all I/O operations trap and cause updates to the state of the virtual CRT controller. Okay.

Then there is a Unix device that interfaces to this display subsystem. And the basic method approach it uses then to update the X windows display is we use a page dirty bits to detect that a DOS task was actually written to the display. That may be the only indication we have that a DOS program written to the display, because they do direct-- many DOS programs write directly to the display memory.

For the character-oriented monochrome-type displays, we actually copy the 25x80 columns and rows of characters to make a copy of it and determine what has changed from the previous copy to the current copy and use that information, then, to update the display. For the color-- or graphics display, rather-- which we don't support in color mode, but we support a limited grayscale capability of graphics programs. And they're a slightly different algorithm, but the principle is the same. You detect areas of the screen that have changed and then update those reasons on the using Xlib calls.

The DOS client is not involved in setting up the virtual 8086 environment. There's other things that take care of that. It's just started up with its task of communicating with the X server. The keyboard is handled and the mouse and full screen attach. Those-- that's the set of events and things that are-- that the X DOS task does in this system.

Are there any questions? If I have a few minutes left.

AUDIENCE: [INAUDIBLE]

COLEMAN: The question was, did I do anything about the aspect ratio differences? Yes and no. It turns out for the character-oriented, you can use whatever fonts you want and the-- it becomes-- it's sort of hidden and irrelevant.

It actually just doesn't look too bad squished up. What it amounts to is stuff that would have been full on a CGA. The EGA has about twice the resolution, so you end up with it taking about twice as much space. And so no, we didn't try, say, doubling every pixel, or anything like that, although we considered it. That may have to be dealt with if the characteristics of the display varied greatly.

AUDIENCE: [INAUDIBLE]

COLEMAN: How big is your page size? We'd have been happy if it had been smaller, but it's 4K. It's very tightly wired into the architecture of the chip.

AUDIENCE: Why did you [INAUDIBLE]

COLEMAN: Because we wanted to detect which line-- which lines of change and do minimal--

AUDIENCE: [INAUDIBLE]

COLEMAN: Yeah. Yeah, and it turns out for the monochrome display we only have-- the page is so large, we only have one-- the whole page fits-- the whole display fits on a page in that case. And the other reason-- this was-- this also-- the same basic screen handling turns out also works on terminals. So from an ASCII terminal you can also a DOS task.

And so there's a reason to keep the-- to minimize the updates, whereas with X you could've afforded to update a larger-- the bandwidth is higher with X than it is for an ASCII terminal, for example. And the process also works on an ASCII terminal.

AUDIENCE: [INAUDIBLE]

COLEMAN: Well, in terms of X, with X and the systems we do-- we clearly notice that there's more processes involved and so stuff doesn't run as fast. There's a perceptible difference whether you're running with X or without the-- X on this system. The DOS emulation for CPU-intensive stuff, it works very well. There's very little degradation.

Trapping [INAUDIBLE] structures takes a significant amount of time. We've-- we're doing what we can and making significant improvements to minimize the number of traps that a process takes. Did that answer your question?

AUDIENCE: [INAUDIBLE]

COLEMAN: He's a little-- did we emulate the EGA or use CGA? And let me-- I'll explain that. We did the hardest one first. We actually emulate a CGA and if you directly attach it, we translate to EGA.

And the X always work-- treats it as an EGA display. But X is built on an EGA display and we don't tend to do it on a CGA. The resolution is so I don't think anyone would want to use it.

AUDIENCE: Can you talk to us briefly about performance of native applications [INAUDIBLE]

COLEMAN: They've [INAUDIBLE] like Xterm.

AUDIENCE: Things like Xterm or [INAUDIBLE]

COLEMAN: It's borderline. It's slow. I don't know that we've got all the speed squeezed out of it we can, but the display is slow. I think that's an issue.

We believe that, yes. I believe it's just actually display characteristics. And I'm about out of time. All right, I'm out of time. So save your questions-- I had that up first. You goofed. Everybody got that?

AUDIENCE: [APPLAUSE]