Xref: utzoo unix-pc.general:2949 comp.sys.att:6549 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!shelby!agate!ucbvax!tut.cis.ohio-state.edu!ukma!rayssd!icus!limbic!gil From: gil@limbic.UUCP (Gil Kloepfer Jr.) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: resash of X-windows and 3b1/7300's Summary: Continued discussion about UNIX-pc "X" Message-ID: <500@limbic.UUCP> Date: 23 May 89 18:53:15 GMT References: <636@flatline.UUCP> <2067@umbc3.UMBC.EDU> Reply-To: gil@limbic.UUCP (Gil Kloepfer Jr.) Distribution: na Organization: ICUS Software Systems, Islip, NY Lines: 78 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