🚀 go-pugleaf

In article <28116@brunix.UUCP> gwk@cs.brown.edu (Greg Kilcup) writes:
>
>Has anyone ported X to the Celerity?  We have just
>brought in a 1260D to live out its last days in
>a comfortable pasture serving some disks, but it
>would be nice if it could double as an X server.
>

Yup.  The port of X11R3 was nice and easy.  There's one spot where the 
compiler blows up in the Xt libraries due to a string that's too long.
Other than that it's fairly easy.  Unfortunately we only support X for
the Model 500's and I'm not allowed to give away the code.

--
David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"I'm trying to think, but nothing happens!" - Curly Howard

In article <28116@brunix.UUCP> gwk@cs.brown.edu (Greg Kilcup) writes:
>
>Has anyone ported X to the Celerity?  We have just
>brought in a 1260D to live out its last days in
>a comfortable pasture serving some disks, but it
>would be nice if it could double as an X server.

It doesn't make an especially good server (no screen, keyboard, or input
device), but I seem to recall Boston University porting the client libraries
and clients pretty easily.
-- 
ROGER B.A. KLORESE      MIPS Computer Systems, Inc.      phone: +1 408 720-2939
928 E. Arques Ave.  Sunnyvale, CA  94086                        rogerk@mips.COM
{ames,decwrl,pyramid}!mips!rogerk
"Two guys, one cart, fresh pasta... *you* figure it out." -- Suzanne Sugarbaker

In article <28116@brunix.UUCP> gwk@cs.brown.edu (Greg Kilcup) writes:
 > 
 > Has anyone ported X to the Celerity?

We have not tried it as a server (would that even be sensible?), but I have
three sitting here happily running client processes for an NCD X-terminal.
There are two (known to me) problems:

1.  X11.src/lib/Xt/TextTr.c contains nothing but a comment at the top of the
file, and the initialization of a char array to a *long* string.  /lib/cpp
(on the Celerity) treats the entire file as a single token; by that, I mean
that the comment is NOT elided prior to tokenizing the character array.  This
causes /lib/cpp to generate a "token too long" error.  Which is stupid.  This
problem is most easily dealt with (not 'fixed') by deleting the comment from
the top of lib/Xt/TextTr.c

Celerity's bcopy() has a problem with negative 'length' arguments.  It will
actually copy between one and eight bytes from 'src' to 'dest', depending on
the *unsigned* value of 'length'.  This condition can actually occur in some
of the 'Resource' associated routines (and possibly elsewhere).  While I
question the philosophical correctness of handing bcopy() a negative length,
it is clear that the actual behavior is incorrect.  Assuming you have bcopy.s,
the following will fix it:

	_bcopy:
	# Collect the arguments.  (This line and next two are original)
		tfsc	s32,%source
		tfsc	s33,%dest
	# The next four lines were added to detect a negative length argument.
		tfsc	s34,%endsource
		aw	%endsource,%source
		cwu	%endsource,%source
		jleq	nop_exit
	# Select direction of move.  (This and balance of file is original)
	...

This fix to bcopy.s may well not be the optimal one.  When I made this I could
not find my copy of the 1230/1260 architecture manual, so I hand to sort of
guess at what the best assembly language would be.  I do know that making this
change allowed the X window system to run correctly on all Celerities at UCSD,
and they would not run correctly (at all, actually) without it.  I don't know
what you do if you don't have source for bcopy.s.  I suppose you either replace
it with a C equivalent that would be a lot slower, or scream a lot at your
field service rep to get you the source.

These problems occur in porting X11.r3 to the Celerity 1230 and 1260D.
Celerity now belongs to Floating Point Systems, and I do not know if these
problems remain in the new FPS boxes.

-- 
   John Pierce	Chemistry, B-032, UCSD, La Jolla,  CA 92093
		jwp@chem.ucsd.edu  jpierce@ucsd  +1 619 534 0203

I've got X11R4 up and running on my Model 500.  There was a hitch
in compiling mit/extensions/lib/xinput, but this library isn't used
by anything in the standard distribution anyway, so who cares!

The problem arises due to the small mindedness of the C compiler,
which uses static tables for everything, and is much to small for
compiking big codes.  I'm still trying to compile XView, but with
no luck; I just can't break things up small enough for that compiler.

here's my accell.cf file:
(you'll have to put the obvious #ifdef accell stuff into Imake.tmpl)
/* try it */

#define OSMajorVersion          4
#define OSMinorVersion          1

#define HasPutenv		YES
#define HasVoidSignalReturn	NO

#define HasBsearch		YES
#define HasFortran		YES
#define HasNdbm			YES
#define HasDESLibrary		NO

#define BuildServer		NO
#define BuildExamples		NO

#define StripInstalledPrograms  YES

I've got X11R4 up and running on my Model 500.  There was a hitch
in compiling mit/extensions/lib/xinput, but this library isn't used
by anything in the standard distribution anyway, so who cares!

The problem arises due to the small mindedness of the C compiler,
which uses static tables for everything, and is much to small for
compiking big codes.  I'm still trying to compile XView, but with
no luck; I just can't break things up small enough for that compiler.

here's my accell.cf file:
(you'll have to put the obvious #ifdef accell stuff into Imake.tmpl)
/* try it */

#define OSMajorVersion          4
#define OSMinorVersion          1

#define HasPutenv		YES
#define HasVoidSignalReturn	NO

#define HasBsearch		YES
#define HasFortran		YES
#define HasNdbm			YES
#define HasDESLibrary		NO

#define BuildServer		NO
#define BuildExamples		NO

#define StripInstalledPrograms  YES