resash of X-windows and 3b1/7300's

[Gil Kloepfer Jr.]

In article <636 at flatline.UUCP> erict at 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 at umbc3.UMBC.EDU> alex at 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 at 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 at icus.islp.ny.us