Sun-Spots Digest, v6n80
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu May 12 05:24:45 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at Xerox.com
------------------------------
Date: Thu, 5 May 88 13:52:00 EDT
From: Chuck Musciano <chuck at 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 at trantor.harris-atd.com
------------------------------
Date: Thu, 5 May 88 11:40:38 PDT
From: beau at 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 at 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 at uk.ac.rl.inf
ARPA: mmm%inf.rl.ac.uk at nss.cs.ucl.ac.uk
------------------------------
Date: Thu, 5 May 88 09:34:07 CDT
From: Jim Knutson <knutson%sw.MCC.COM at 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 at 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 at 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 at 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 at 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 at rainier.se, pell at rainier.UUCP
------------------------------
Date: 5 May 88 16:42:43 GMT
From: pvt at 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 at 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 at corto.inria.fr or mcvax!inria!corto!vassili
------------------------------
Date: Wed, 4 May 88 13:44:36 EDT
From: rrb%mathsun%jupiter.uucp at 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 at 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 at cu-arpa.cs.cornell.edu
------------------------------
Date: Thu, 5 May 88 10:20:35 EDT
From: reg%lti.UUCP at 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 at bu-it.bu.edu
27 Congress St., Salem, MA 01970 (617) 741-1507
------------------------------
Date: Wed, 4 May 15:38:05 1988
From: eric%ulysses at 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 at topaz.rutgers.edu or eric at ulysses.att.com
UUCP: ...{wherever!}ulysses!eric
...{wherever!}rutgers!topaz!eric
SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list