Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/12/88)
SUN-SPOTS DIGEST Tuesday, 10 May 1988 Volume 6 : Issue 80 Today's Topics: Re: Format for byte encoded rasterfiles (4) Re: My favorite shell file (2) Re: Sun4/110 memory information Re: deskside Suns and acceptable noise levels LA SUG meeting May 13 at Caltech displaying 8-bit characters on shelltool and xterm MAXUSERS > 12 in SunOS 3.2 and 3.4 Rock and a hard place: unconditioned power problems with uucp Need help with Adaptec/Maxtor Configuration Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Thu, 5 May 88 9:41:42 PDT From: Steve Putz <Putz.pa@xerox.com> Subject: Re: Format for byte encoded rasterfiles (1) Reference: v6n71 By looking at files produced by "screendump", it appears that the run-length encoding for type 2 Sun rasterfiles is as follows: Each scan-line is run-encoded separately (runs do not cross scan lines). Runs of count consecutive bytes are encoded as <128> <count> <byte>. Actual 128 bytes are encoded as <128> <0>. The above plus rasterfile.h should be enough to figure out the exact format. The only programs I have for reading and writing this format are written in Smalltalk-80. I will make them available if there is interest. Steve Putz Xerox Palo Alto Research Center Putz.pa@Xerox.com ------------------------------ Date: Thu, 5 May 88 13:52:00 EDT From: Chuck Musciano <chuck@trantor.harris-atd.com> Subject: Re: Format for byte encoded rasterfiles (2) The format of Sun byte encoded raster files is not documented, but was pretty easy to pick apart. The header and color map are not encoded, but the raster data is. Any data byte with value 0x80 indicates the start of a run. The next byte is the count, minus one, and the byte after that is the true data, which is repeated (count + 1) times. Thus, a run of 32 bytes of value 7d is encoded as (all values in hex): 80 1f 7d Again, the count is one less than the true amount. If the count is zero, then there is no data byte, and a single byte of 80 is used. Thus, single occurences of the value 80 in the file appear as 80 00 Note that multiple occurences of 80 are encoded as a single run, so two or more 80 bytes are encoded as 80 xx 80 where xx is the count, minus one. All other bytes represent themselves, so a data stream of 01 02 03 80 04 04 04 04 04 04 05 05 80 80 is encoded as 01 02 03 80 00 80 05 04 05 05 80 01 80 (What a savings!) Note the representation of 80 as 80 00, the fact that runs of length two are usually not encoded, and that a run of 80's was encoded. This encoding occurs after monochrome bitmaps have been packed 8 bits to the byte. Chuck Musciano Advanced Technology Department Harris Corporation (407) 727-6131 ARPA: chuck@trantor.harris-atd.com ------------------------------ Date: Thu, 5 May 88 11:40:38 PDT From: beau@sun.com (Beau James - Sun USHQ Consulting Services Manager) Subject: Re: Format for byte encoded rasterfiles (3) The description of the built-in byte-stream-encoded format: /* * Encode/decode functions for RT_BYTE_ENCODED images: * * The "run-length encoding" is of the form * * <byte><byte>...<ESC><0>...<byte><ESC><count><byte>... * * where the counts are in the range 0..255 and the actual number of * instances of <byte> is <count>+1 (i.e. actual is 1..256). One- or * two-character sequences are left unencoded; three-or-more character * sequences are encoded as <ESC><count><byte>. <ESC> is the character * code 128. Each single <ESC> in the input data stream is encoded as * <ESC><0>, because the <count> in this scheme can never be 0 (actual * count can never be 1). <ESC><ESC> is encoded as <ESC><1><ESC>. * * This algorithm will fail (make the "compressed" data bigger than the * original data) only if the input stream contains an excessive number of * one- and two-character sequences of the <ESC> character. */ #define ESCAPE 128 There are many algorithms that yield better compression, especially if there is a priori knowledge of the characteristics of the input date. That's why the pr_load() and pr_dump() facility was designed to use external filter programs transparently; the manual contains information on how to construct such a filter. Beau James Sun Consulting Services ------------------------------ Date: Fri, 6 May 88 09:15:43-0000 From: mmm%informatics.rutherford.ac.uk@nss.cs.ucl.ac.uk Subject: Re: Format for byte encoded rasterfiles (4) The following code fragment describes it, I think. /* sun compressed form is marker byte 0200 followed * by num-1 of repeats of byte following. * If num-1==0, it is the data byte 0200. * If not marker byte 0200, it is a data byte. * ie: 0200<rpts-1>databyte | 0200 0000 | not 0200 */ #define MARKER (unsigned char)'\200' unsigned char *from,*to,*end; int i; end = from+<len of data given in header> while(from<end) if(*from==MARKER){ i = *++from; from++; if(i==0)*to++ = MARKER; else{ while(i-->=0)*to++ = *from; from++; } }else *to++ = *from++; Mark Martin. Rutherford Appleton Laboratory. England. JANET: mmm@uk.ac.rl.inf ARPA: mmm%inf.rl.ac.uk@nss.cs.ucl.ac.uk ------------------------------ Date: Thu, 5 May 88 09:34:07 CDT From: Jim Knutson <knutson%sw.MCC.COM@mcc.com> Subject: Re: My favorite shell file (1) > #!/bin/csh -f > set h = `/usr/bin/basename $0` > shelltool -Wl " rlogin $h" -WL "$h" rlogin $h $* -8 & Since we are talking about how to write better shell scripts, I suggest the following: in a case like this, where the last command is really what you wanted to run and all the shell script does is set things up, use exec to run the shelltool. This will keep you from having extra processes hanging around for long periods when they are not needed. It just might keep your process tables from filling up so fast. Jim Knutson knutson@mcc.com im4u!milano!knutson [[ In general you are correct. When the last thing a shell file does is invoke an executable, it should "exec" it. But in this case the shell file is starting up a background process and exiting immediately. Adding "exec" to the front of the last line seems to have to effect. Since the shell file is about to exit anyway, the concern about filling up the process table is unwarranted. --wnl ]] ------------------------------ Date: Fri, 6 May 88 11:09:17 HST From: Bob Cunningham <bob@kahala.hig.hawaii.edu> Subject: Re: My favorite shell file (2) I do rlogins (and ftp) with menus. Perhaps the technique isn't as well-know as it should be. First, set "walking menus" with the defaults editor so you can have submenus (mainly to keep your root menu from getting cluttered up with too many items). Then make up a .rootmenu file from the contents of /usr/lib/rootmenu or whatever and insert these lines: "rlogin" MENU .rootmenu.rlogin "ftp" MENU .rootmenu.ftp Set up a .rootmenu.rlogin file containing lines like: "rlogin alpha" shelltool -WL "alpha" -Wl "rlogin alpha" rlogin alpha "rlogin beta" shelltool -WL "beta" -Wl "rlogin beta" rlogin beta And a .rootmenu.ftp with lines like: "ftp alpha" shelltool -WI .ftp.icon -WL "alpha" -Wl "ftp alpha" ftp alpha "ftp beta" shelltool -WI .ftp.icon -WL "beta" -Wl "ftp beta" ftp beta "ftp ?" shelltool -WI .ftp.icon ftp Then you can "point and shoot" with the menus using your mouse. [[ Good idea. Perhaps some of us are just too "shell" oriented for our own good. The only real problem I have with the idea is that some networks have many many machines. My shell file currently has 16 links, which means that there are 16 different hosts to which I want an rlogin window on a regular basis. And there are probably still some I haven't added yet (the nice thing about that shell file is that one can add a host, say "foo" to the list of possible hosts by merely linking an old name to "foo"---"ln old foo"---and rehashing). I know that SunView rereads the root menu file when it changes and I would hope that it does the same for the submenus as well. --wnl ]] ------------------------------ Date: Thu, 5 May 88 08:38:10 PDT From: forward!jdgaye@sun.com (Dennis Gaye) Subject: Re: Sun4/110 memory information The Sun4/110 is user expandable to 32 Meg. JD ------------------------------ Date: Thu, 5 May 88 16:57:45 +0200 From: rainier!carola!pell@uunet.uu.net (P{r Emanuelsson) Subject: Re: deskside Suns and acceptable noise levels >This is simply an FYI item (and call to arms) for those who might be >concerned with this issue. I do NOT want to start a discussion in this >newgroup and I especially do not want to get a lot of messages back!!!!!! Well, hope you don't mind a bit of related information. >Almost everyone I know regards the Sun-x/160 and Sun-x/260 packages >(deskside cabinet on wheels) as far too noisy to put in an office. Agreed. However, we regard this as a serious problem with e.g. the new 3/50s too! The noise level is absolutely not acceptable. But this can be remedied rather simply. The builtin fan is DC powered and looks very cheap. It can be replaced by an AC powered, high-quality, low-noise fan, in a simple operation. The result is a quiet whisper, almost unaudible. Of course, the air flow is lower, but measurements have not shown alarmingly high temperatures on the CPU card. Anyway, it's certainly possible to get a quiet workstation on your desk, but please be sure you know what you're doing! And, of course, it's a shame that customers should have to undertake modifications like this. /Pell Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!pell University of Linkoping, Sweden pell@rainier.se, pell@rainier.UUCP ------------------------------ Date: 5 May 88 16:42:43 GMT From: pvt@wega.caltech.edu (Pravin Tulachan) Subject: LA SUG meeting May 13 at Caltech [[ This is getting out a little late...sorry. --wnl ]] Hi Sun users! Our meeting will be held on Friday 13 of May at California Inst. of Technology at Pasadena in Gates 22( the same room as our last meeting) from 11:10 to 3:00 <== PLEASE NOTE THE TIME CHANGE FROM PREVIOUS NOTICES. LALSUG Second Meeting California Institute of Technology Gates 22 Pasadena, Calif. May 13 1988 Theme: COMMUNICATION & NETWORKING time: Activities: Presentor: --------- ---------------------------- --------------------- 11:10 Panel presetation/discussion: Pravin Tulachan, Caltech All you wanted to know about Issac Salzman, R&D Lab. UUCP but did not know who to David Lundberg, Tiger ask? How to connect to network Media. and keep in touch with rest of us? 12:15 Chapter Business 12:30 Lunch Break 1:30 Vendor Presentation:Telebit Mike Ballard, Telebit 2:00 Technical Presentation:TCP/IP Direction in Networking and Bill Maholn, SUN Inc. Protocol Development 3:00 Meeting Adjorned All the participants are requested to give some thoughts as to what topics and program you would like for our next meeting. WE ENCOURAGE AND WELCOME EVERYONE OF YOU TO ACTIVELY PARTICIPATE AND CONTRIBUTE IN ANY WAY YOU CAN TO MAKE OUR MEETING A SUCCESS. Acknowledgement: We would like to express our appreciation to Cory Filler(Discover Computer) for helping us with putting this agenda together and Issac Salzman(R&D Labs.) for arranging our vendor presentation. We would also like to thank Dave Howard(SUG) for arranging our feature speaker and mailing. !! WE'LL SEE YOU THERE !! The direction is as follows: For those coming from L.A.: Take FW 110 North until it turns to Arroyo Parkway, keep on heading north and make a right on Del Mar Blvd. find a parking spot on the street and then head south towards the the **tallest building, Millikan library**, and Gates 22 is just north of the library. OR You could also make a right turn on California Blvd.(east) and then go past Lake and Caltech is to the left. You could then head north towards the Millikan Building and the Gates 22 just to the north of the library For those taking FW 134 or FW 210 heading East: Get off on Hill Ave. and make right turn(south) head pass Colorado Blvd and make right on Del Mar Blvd, and then find pparking . Then head south as mentioned above. * *** Parking as usual is in short supply, so car pooling is encouraged and will have to park in the unmarked spot or park on the steet. ********** pravin ------------------------------ Date: Wed, 4 May 88 17:40:17 +0200 From: mcvax!corto.inria.fr!vassili@uunet.uu.net (Vassilis Prevelakis) Subject: displaying 8-bit characters on shelltool and xterm In sunspots v6n60, Andy Galewsky is having difficulty in displaying characters with codes above 127 (i.e. codes with their 8th bit set). I tried answering him directly but I had difficulty with the path he gave in his letter. So here is my responce, You are absolutely right! Both xterm (for X windows) and shelltool for suntools strip the parity bit. In the shelltool, the 8th bit in each byte is then used to control the attribute of the corresponding character (normal or inverse video). Modified versions allowing both input and output of 8-bit codes are available for both the xterm and the shelltool. vassilis prevelakis vassili@corto.inria.fr or mcvax!inria!corto!vassili ------------------------------ Date: Wed, 4 May 88 13:44:36 EDT From: rrb%mathsun%jupiter.uucp@umix.cc.umich.edu (Robert Bruner) Subject: MAXUSERS > 12 in SunOS 3.2 and 3.4 I've used MAXUSERS = 16 in both 3.2 and 3.4 with no problems. (Also in SunOS 3.5) ------------------------------ Date: Thu, 5 May 88 09:24:28 EDT From: oravax!alex@cu-arpa.cs.cornell.edu (Alex Feldman) Subject: Rock and a hard place: unconditioned power We have some brand new terminal rooms and intend to fill them with 3/60's. Unfortunately, the air conditioning for these rooms is on the same panel as all the other power in the room. Up until now all of our workstations have either been plugged in to conditioned power or were on panels with relatively few bad devices (like refigerators or air conditioners) on them. The warm months are coming... it often gets to over 80F around here. Should we keep the air conditioners off, turn them on, or swallow hard and rewire? Anecdotes as well as any hard data would be welcomed. Alex Feldman alex%oravax.uucp@cu-arpa.cs.cornell.edu ------------------------------ Date: Thu, 5 May 88 10:20:35 EDT From: reg%lti.UUCP@bu-it.bu.edu (Rick Genter x18) Subject: problems with uucp I am having problems with UUCP. Occasionally we seem to generate a D.fooX* file that we can't send. Consistently uucico will fail transfering the file with daemon buita (5/5-9:12-12619) REQUEST (S D.ltiX06db X.ltiX06db daemon) daemon buita (5/5-9:14-12619) BAD READ (expected 'S' got FAIL) The only solution is to remove the offending file. I've looked at the file; there is nothing particularly unusual about it. The machine having the problem is a Sun-3/180 running SunOS 3.5. We are using a Hayes-compatible modem at 2400 baud. Thanks for any help anyone can provide. - reg Rick Genter ...!buita!lti!reg Language Technology, Inc. reg%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (617) 741-1507 ------------------------------ Date: Wed, 4 May 15:38:05 1988 From: eric%ulysses@clyde.att.com Subject: Need help with Adaptec/Maxtor Configuration I'm trying to hook up an Adaptec ACB4000 and a Maxtor XT-1140 to my Sun 3/75. On the recommendation of Adaptec, I ordered an ACB4000 with microcode 406301-00 Rev B (or later). I've hooked the drive up and when I try and format it with diag, the drive selects, seems to retry a few times and then diag dies with "bad format on volume". Are there any special considerations in configuring the ACB or the drive that I may have missed? Maybe my cables are bad? Has anyone else done this before? Thanks for the help, Eric ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com UUCP: ...{wherever!}ulysses!eric ...{wherever!}rutgers!topaz!eric SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854 ------------------------------ End of SUN-Spots Digest ***********************