gwk@cs.brown.edu (Greg Kilcup) (02/06/90)
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. Thanks, Greg Kilcup (kilcup@qcd.physics.brown.edu)
dave@fps.com (Dave Smith) (02/06/90)
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
rogerk@mips.COM (Roger B.A. Klorese) (02/06/90)
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
jwp@chem.ucsd.edu (John Pierce) (02/08/90)
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
scp@blanche.LANL>GOV (Stephen C. Pope) (02/14/90)
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