erict@flatline.UUCP (J. Eric Townsend) (05/21/89)
Ok, I remember at one point in the past the statement "X windows won't happen on a 3b1/7300" being made. Why? I've just read some stuff on X-Windows, and it seems the whole point of X-Windows is that you can make it work on a C64, if you try hard enough. :-). Seriously, tho, what's stopping a port to the 3b1? -- "There's no way I'll crash this -- this is a *beer* truck, eh?" - Doug McKenzie J. Eric Townsend Inet: <temporarily disabled> 511 Parker #2 Houston,Tx,77007 EastEnders Mailing List: eastender@flatline.UUCP
alex@wolf.umbc.edu (Alex Crain) (05/22/89)
In article <636@flatline.UUCP> erict@flatline.UUCP (J. Eric Townsend) writes: >Ok, I remember at one point in the past the statement "X windows won't >happen on a 3b1/7300" being made. > >Why? I've just read some stuff on X-Windows, and it seems the whole >point of X-Windows is that you can make it work on a C64, if you try >hard enough. :-). Seriously, tho, what's stopping a port to the 3b1? THere are a couple of deficencies in X windows that make it a dubious investment for the 3b1. 1) The size of the investment. X windows is *huge*, and based entirely on network hardware and a good interface to a large screen device. The 3b1 has an expensive network interface that most of us do not possess, and minimal access to the screen hardware in the form of Fords vidio driver. Most of the workstations tha X runs on are either BSD or BSD extended, so the sysV process communication stuff has never been written (and we don't have streams anyway). 2) Even if you did write an IPC interface that is flexable enough for X, the X server is *huge* (something like .5 meg) and runs all the time. In my humble opinion, the unix-pc just doesn't have the cpu bandwith to run X at a tolerable speed as anything other then a network terminal. Now, some food for thought now that summer is apon us and there are bored hackers afoot. IF two things happened, a replacement window manageer might become a viable option. #1 - we need a public domain IPC mechanism for this machine, on the order of sockets or streams. The ability to deal with network I/O is a definate plus hear. #2 - we need a good general purpose screen driver, that can over ride the existing screen driver for development. I've been working on #1 for awhile, and I have a whole buch of code that needs some debugging but will be released shortly. The code is based in the berkley socket code, and implements most of the socket calls except for select(), which I'm saving for later. I shelved the project about a month ago in favor of pressing schoolwork and the PDP-11 I aquired :-), but I'll be getting back into it this week and should have something released by the time USENIX comes around. I also have some ideas for #2, but I don't have time to write it. What I will do is write a very basic screen driver with documented hooks for kernal hackers (and would be kernal hackers) to play with, and get it out either mid june or before if there is the demand. I think that an X subset is doable, if enough code shortcuts are taken. But somebody is going to have to write it... :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County umbc3.umbc.edu!nerwin!alex
dglo@clash.ADS.COM (Dave Glowacki) (05/23/89)
I think the easiest way to get X on the 3b1 is to port the full system. A 'resash' would probably involve trashing the client-server stuff entirely, and only porting the Xlib, Xt, and Xaw routines. (1/2 :-) In article <2067@umbc3.UMBC.EDU> alex@wolf.umbc.edu.UUCP (Alex Crain) writes: >In article <636@flatline.UUCP> erict@flatline.UUCP (J. Eric Townsend) writes: > >>Ok, I remember at one point in the past the statement "X windows won't >>happen on a 3b1/7300" being made. >> >>Why? I've just read some stuff on X-Windows, and it seems the whole >>point of X-Windows is that you can make it work on a C64, if you try >>hard enough. :-). Seriously, tho, what's stopping a port to the 3b1? > > THere are a couple of deficencies in X windows that make it a dubious >investment for the 3b1. But the positive benefits of 1) a REAL window interface and 2) lots of free software are sure do make it tempting :-) > 1) The size of the investment. X windows is *huge*, and based entirely >on network hardware and a good interface to a large screen device. The 3b1 has >an expensive network interface that most of us do not possess, and minimal >access to the screen hardware in the form of Fords vidio driver. Most of the >workstations tha X runs on are either BSD or BSD extended, so the sysV process >communication stuff has never been written (and we don't have streams anyway). Not necessarily. The size of the screen is a drawback, but tony@mcrsys posted an article last month in comp.windows.x on how he brought up X on his SysV/386 box with no networking hardware. Basically, he grabbed the PD Berkeley headers and played around with the source a bit, but it didn't look like a HUGE effort. I can forward the article to anyone who's interested. >... >#2 - we need a good general purpose >screen driver, that can over ride the existing screen driver for development. >... > I also have some ideas for #2, but I don't have time to write it. What >I will do is write a very basic screen driver with documented hooks for >kernal hackers (and would be kernal hackers) to play with, and get it out >either mid june or before if there is the demand. I'd be interested in this. With my miniscule spare time, I've been trying to figure out how '/etc/lddrv/wind' works. There's a LOT of stuff that could be chopped out of there if one were to lose the native interface... -- Dave Glowacki dglo@ads.com Advanced Decision Systems
mark@umbc3.UMBC.EDU (Mark Sienkiewicz) (05/23/89)
The big agony of porting X to the unixpc has to do with trying to just snarf an existing server. Alex's networking port will probably give us the networking end. The problem I see immediately is this: The sample servers seem to do 1 of two things: 1 - use an underlying graphics package to implement the root window. I think the Apollo implementation does something like this. Adapting this approach to some other machine could be awfully time consuming. 2 - expect a bitmap of the screen to appear in the address space of a user process. This would involve either a spy at CT or a really clever kernel hacker to find out how to work the paging stuff in the kernel. I think a compromise could work like this: Steal the mfb code. Instead of operating directly on the bitmap, operate on a copy. As you modify it, flag the modified scan lines. Periodically copy the modified lines into the screen area by using a special system call. Some less drastic (in my point of view, anyway) problems are: - you are limited in CPU power. You would gain a *** LOT *** of performance by changing all the 32 bit operations to 16 bit operations. This is a lot of work which would probably be left out of a first stab at it. - The are several megabytes of just server code to read. Of course, you can ignore most of it because it starts to all look alike, but sometimes it is really interesting reading. I am interested in hearing from anyone who wants to work on this. I might have tried it a long time ago, but I have a full time job, etc... -- Mark S. uunet!umbc3!nerwin!zilla!mark nerwin!zilla!mark@umbc3.umbc.edu
mike@thor.acc.stolaf.edu (Mike Haertel) (05/24/89)
In article <2070@umbc3.UMBC.EDU> mark@umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz) writes: >2 - expect a bitmap of the screen to appear in the address space of >a user process. This would involve either a spy at CT or a really >clever kernel hacker to find out how to work the paging stuff in the kernel. Due to brain damaged design of the hardware it is actually impossible to map the video memory into user process space. I have written programs that directly access video memory, but they only run standalone. >- you are limited in CPU power. You would gain a *** LOT *** of performance >by changing all the 32 bit operations to 16 bit operations. This is a lot >of work which would probably be left out of a first stab at it. Only multiplications should be downgraded. Bitwise operations especially should be done in 32 bits. However, due to brain damaged design, if you want to do screen ops in 32 bit words you have to swap them (the screen is wordwise little endian but bytewise big endian). But it is faster to swap all loads and stores from or to video memory than it is to do everything in 16 bits. -- Mike Haertel <mike@stolaf.edu> "There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself." -- J. S. Bach
gil@limbic.UUCP (Gil Kloepfer Jr.) (05/24/89)
In article <636@flatline.UUCP> erict@flatline.UUCP (J. Eric Townsend) writes: >Why? I've just read some stuff on X-Windows, and it seems the whole >point of X-Windows is that you can make it work on a C64, if you try >hard enough. :-). Seriously, tho, what's stopping a port to the 3b1? Before I address Alex's issues, I'll present one serious port-stopper to the 3B1. For us hackers that have trashed the phone manager, status manager, and window manager having X would be great. Unfortunately all three of those software packages, as well as many other ua-based applications, will not run under X unless recompiled (try it someday ;-). For those that doubt me .. remember that trying to emulate the user agent in X would mean hacking some kind of X-interface into the shared library, while keeping it the same size. Like I said, good luck... Now, if you wanted to trash all the prefab'd applications for this box... In article <2067@umbc3.UMBC.EDU> alex@wolf.umbc.edu.UUCP (Alex Crain) writes: > 1) The size of the investment. X windows is *huge*, and based entirely >on network hardware I don't know a LOT about X, but I don't believe having a network is a prerequisite, although it is desired... One viable way of supporting X entirely local, and many workstations are doing this now. > and a good interface to a large screen device. It really isn't based on a large screen device specifically, but it sure would be hell trying to use it on a small screen! > and minimal access to the screen hardware in the form of Fords vidio driver. We have lots of access to the screen hardware - it's just that there isn't much of it! The means of accessing the screen is by writing the raster image to the screen's bit-mapped memory located at some location in the memory map. It's easy to get at, but you have to realize that you'll spend much of the time rasterizing vectors. >the X server is *huge* (something like .5 meg) and runs all the time. >In my humble opinion, the unix-pc just doesn't have the cpu bandwith to run >X at a tolerable speed as anything other then a network terminal. This is the second key issue in porting X to the UNIX-pc. Again, I'm not familiar with the size of X, but it probably is a lot of baggage to carry around all the time. However, for those that want to use a 3B1 as a X terminal...hmmmm... There really is plenty of CPU bandwidth on the 3B1, but there's a big bottleneck in the the I/O bus. Too many devices on the 3B1 interrupt like mad or just plain hog the bus. Making the EIA board interrupt-driven was a really dumb move... >we need a good general purpose screen driver, that can over ride the >existing screen driver for development. Exactly WHAT kind of general purpose screen driver do you need? What would this driver do? Really, Ditto's vidram driver is as general purpose as you can get! If you want extra functionality, list it here so that maybe someone can do what you want! I really have only a passing interest in this .. but I'm sure someone wouldn't mind doing a more elaborate screen driver! > I think that an X subset is doable, if enough code shortcuts are >taken. But somebody is going to have to write it... > :alex >Alex Crain >Systems Programmer alex@umbc3.umbc.edu >Univ Md Baltimore County umbc3.umbc.edu!nerwin!alex I think so also .. maybe an implentation of simply the X toolkit would be useful for some... Good luck to those who want to do it! ------- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {icus,lilink}!limbic!gil or gil@icus.islp.ny.us