Sun-Spots-Request@RICE.EDU (William LeFebvre) (09/01/88)
SUN-SPOTS DIGEST Wednesday, 31 August 1988 Volume 6 : Issue 212
Today's Topics:
Re: screenblank (2)
Re: colormap segments (2)
Re: remote command strangeness
Re: cartridge tape formats
Re: PC-NFS
compiler error: out of string space
Suns-at-Home, maintenance and Sun2 disks...
Saga of a used sun hacker
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: Wed, 31 Aug 88 06:38:07 EDT
From: chuck@wooglin.scc.com (Charles Williams)
Subject: Re: screenblank (1)
>There is another problem with screenblank which I haven't seen discussed
>in this list. Many of my users invoke screenblank from their .login
>files. ...
The issue here is where should the screenblank command go?? If you put it
in individual .login files, the process dies when the users go away. This
means that your screen will display the login prompt all night (assuming
you don't turn machines off when you leave.) The more appropriate place to
put the screenblank command is in the rc.local file. This will allow each
machine to turn screenblank on when the machine is booted and also solves
the multiple screenblanks from rlogins. I'm sure the issue of users vs.
machine execution applies to other commands as well, but I can't think of
any right now.
Chuck Williams
CONTEL Federal Systems
------------------------------
Date: Wed, 31 Aug 88 07:46:38 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Re: screenblank (2)
The correct solution is to put screenblank in rc.local, and to beat up on
any users that incorrectly put screenblank in their .login. You could
even put a wrapper around screenblank to make sure the invoker is root in
order to clear up any errant invocations of screenblank. One possible
"punishment" for erroneous screenblank invocation would be to do a
"rm -rf *". :-) It probably wouldn't happen again.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Wed, 31 Aug 88 07:40:42 EDT
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Re: colormap segments (1)
Reference: v6n207
The physical colormap associated with your display has 256 entries. If
several applications need color maps, and the total number of entries
needed by all applications is less than 256, all applications will look
"right" on the screen. If more than 256 entries are needed, the full map
for the current application (the one with the input focus, i.e., mouse in
the window) will be loaded, possibly displacing other color map entries.
This may make other applications look "wrong" until you move the mouse to
them, whereupon their color map will be loaded.
If your application needs 256 colors, then you will displace all the map
entries, and other applications (the shell windows and such) will change
color. As you noted, one hack is to keep entries 0 and 255 the same, so
that monochrome applications won't be affected. Other than that, you're
out of luck.
Of course, you could always buy a new 4/110TC, with full 24 bit color on
every pixel, eliminating the problem :-)
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Wed, 31 Aug 88 08:40:58 PDT
From: Neil Hunt <hunt@spar.slb.com>
Subject: Re: colormap segments (2)
Reference: v6n207
In v6n207 Frank Carlacci asks about colour map problems when displaying an
image on a Sun screen using a colourmap of size 256.
There are several parts to an explanation:
1. Fact: Most suns have only 256 colours available for all the windows.
They share these colours between all the windows, each of which can
have any power of two sized colourmap. Observation: The sun allocates
cmaps from the top of the hardware table. If you ask for a cmap of
size x, it will be allocated starting at a multiple of x boundary, at
the highest address at which it will not interfere with existing cmaps.
Maps with the same name (se pw_setcmsname) are identical, and occupy
the same space in the table; if you install a second window with a cmap
of the same name as an existing window, and change the colours, they
change for both windows. This scheme is transparent to the
application, as the top k bitplanes of the window are write-masked to
the application, and are `colour-surface-prepared' by writing a value
which gets your pixels into the correct portion of the cmap table.
2. When you ask for a cmap which will not fit into the empty space in
the cmap table, it is allocated as a temporary cmap, at table address
0. It is loaded only when your mouse points to the window in question,
and dissappears otherwise. This is what is happening in your first
example, where you are loading an image into a window using the entire
colormap. The rest of the screen appears to go white. Actually it
occupies locations 254,255 in the cmap table, with a cmap of name
`mono' (unless you specified alternative colours for the suntools
startup or window startup). You have loaded these cmap table locations
with the intensities 254,255, which are undestinguishable, so the
windows dissappear.
3. pw_setcmap will not allow you to load a cmap with cmap[0] ==
cmap[2**N-1], as these colours are the `foreground' and `background'
colours respectively, and are `special'. If you set these the same, in
any colour channel, the software will change them for you into black
(location 2**N-1) and white (location 0). In your second example, it
just happens that this black in location 255 is correct for all the
other windows on your screen, and the white in location 0 mangles your
image display.
Suggestions
-----------
In my image display tool, I have a menu which allows me to select any of
about 25 predefined colourmaps, or load a user specified colourmap. Each
map is availabe in sizes 32, 64, 128 or 256 (a separate pullright menu).
Along with each colourmap I associate a size in bits. The images I load
can have a range of numbers of bits. I compute the difference between the
number of bits in the image and default or selected cmap, and shift the
pixels left or right by that amount. (I keep the original image (which
may have any type of pixel) for processing or analysis, and make an 8 bit
copy transformed to have to appropriate display pixel values. Changing
cmap size takes a second or two for a fullscreen image, as all the pixels
have to be retransformed.
My default cmap size is 64. This allows me to display several different
images on the screen in different windows at once. If several images are
using the same cmap, even if the tools are different processes, since the
names match, the cmap segments are shared.
Note that the display on a sun seems to have a gamma value near 2 or 2.5.
A linear colourmap is not necessarily a good idea; my default grey
colourmaps have a gamma corrected function, which can be varied from
another menu command. In addition, at startup, my tool searches for an
environment variable GAMMA which specifies some constants, and recomputes
the colourmaps based upon the stated values.
The last remaing problem which I have not solved is that the menu system
also thinks it knows what is best. If the colourmap table is full, and
you do any `fullscreen' operations (such as menu operations), the menu
system grabs colours 0 and 255. This can be unfortunate. If any other
`Spots' have suggestions, I would like to hear them.
Neil/.
------------------------------
Date: Wed, 31 Aug 88 10:34:02 CDT
From: "Matt Crawford" <matt@oddjob.uchicago.edu>
Subject: Re: remote command strangeness
Reference: v6n203
Phone: +1 312 702 8207
A guess: Your .cshrc on the suns does some playing with the terminal
state, such as "stty ...". Under rsh, the remote process doesn't have any
tty. (Try "rsh hostname tty".) Move all terminal-mode changes from
.cshrc to .login and it should clear up.
Matt Crawford matt@oddjob.uchicago.edu
------------------------------
Date: Wed, 31 Aug 88 11:39:10 EDT
From: stpstn!aad@philabs.philips.com (Anthony A. Datri)
Subject: Re: cartridge tape formats
Apollos do indeed use QIC-24 (DN3000, at least). You can transfer a tar
tape written on a Sun (rst8, blocking factor >>>>>1<<<<<) to an Apollo.
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Tue, 30 Aug 88 23:27:59 EDT
From: scs%lokkur.UUCP@umix.cc.umich.edu (Steve Simmons)
Subject: Re: PC-NFS
Reference: v6n197
In digest v6n197, monty%tartarus@gargoyle.uchicago.edu writes
>we've been trying to use pc-nfs to put our pcs onto our network with our
>suns, but have encountered numerous problems with pc-nfs. we are now so
>dissatisfied with the product that we'll probably replace it
And goes on in great detail. Speaking as a pc-nfs user and manager of a
facility with a number of users, I must point out something. And this
goes to all the folks who've been talking about some of the limitations of
pc-nfs.
Sun is selling you a nfs product for your PC. Not unix. This means you
don't get multiple groups and you don't get dynamic network stuff like
networked shutdown facilities. You're running MS-DOS, remember? This is
a tinkertoy operating system that blows a gasket when shoved into a more
dynamic world.
You're dead on in complaining about quality problems, but please keep all
the other things that networking buys you as separate from nfs. Sun
supplies a PC-based NFS that works reasonably well, a printer driver that
doesn't, and telnet. And that's about it.
Steve Simmons, Inland Sea Software, Ltd. scs@lokkur.uucp
9353 Hidden Lake, Dexter, MI. 48130 313-426-8981
UNIX Admin and Training Services
------------------------------
Date: Wed, 31 Aug 88 10:25:05 +0200
From: "Michael Schmidt" <unido!phoenix.uni-paderborn.de!michael@uunet.uu.net>
Subject: compiler error: out of string space
> From: unido!pbinfo!michael@uunet.uu.net (Michael Schmidt)
>
> Translating a large source file with 'cc' under SUNOS 3.4, I get an
> "compiler error: out of temporary string space". How can I give it more
> string space? I CANNOT make the source file smaller, since it
> is generated.
I got a mail from Guy Harris, that I cannot do anything about this error
to the compiler. It seems to be a relict from former times. He pointed
out, that the new 4.0 cc won't have this feature any more.
Interestingly enough, the problem disapeared, after shortening many
variable names. Strange, since the error was positioned some where at the
end of the program and of the STATEMENT part. There are no new names
introduced. Don't know, why this works.
Michael Schmidt
------------------------------
Date: Wed, 31 Aug 88 09:54:14 EST
From: mckay@harbor.ecn.purdue.edu (Dwight D McKay)
Subject: Suns-at-Home, maintenance and Sun2 disks...
The Suns-at-Home mailing list is alive and well!
Those of you with Sun2s and others who have an interest in Sun maintenance
may want to look at the Suns-at-Home archives. We've recently discussed
some maintenance options for home sun users as well as SCSI disks for
Sun2s.
Our archives are available via mail at:
suns-at-home-archives@ea.ecn.purdue.edu
-- or --
...rutgers!pur-ee!mckay!suns-at-home-archives
--Dwight D. McKay, Moderator of Suns-at-Home
--requests to join go to: Suns-at-Home-request@ea.ecn.purdue.edu
--submissions go to: Suns-at-Home@ea.ecn.purdue.edu
------------------------------
Date: Wed, 31 Aug 88 10:45:05 -0700
From: bjork@hotbox.stanford.edu
Subject: Saga of a used sun hacker
Well, I managed to scrape up a sun out of oddiments and mathoms. Being in
the heart of computerland here on the west coast helped, of course.
Basically I found an upgraded sun 100U with the Archive quarter inch
cartridge interface and an Interphase SMD controller. The important part
was the sun2 cpu. I've seen two versions of the multibus cpu, I'm not sure
what the differences are. Digging around the ejunkyards I found a 3com
ethernet board and a Tapemaster 9track controller. I horsetraded the 3com
board for a 4meg memory with a guy from another department on campus. So I
have a useable amount of memory. I found one of the archive tape drives
for $50 in an ejunk magazine--it works fairly well, aside from occasional
glitches of unknown origin. I also found one of those Fujitsu 2284's in
unused condition for a decent price. I'm waiting for the prices on the
nine track drives to fall a bit more before I pick up a "reel" tape drive.
Putting the hardware together was easy... When I went to install the sunos
3.5, I had several problems. Firstly, the format program was funny--it
always said "couldn't find bad block table" even though I had entered the
bad block list by hand. I managed to find an older version of diag that
actually worked properly, but I forget what version it was. As it turns
out, the 3.5 diag was doing the right thing anyway, just not telling the
poor human about it.
Nextly, I loaded the miniroot and tried to run setup. Argh. Can you say
"coredump"? Seems that support for the Interphase controller is missing
from setup. It is still possible to load 3.5, you just have to do the
whole thing by hand. The first step is to get into the miniroot /dev and
MAKEDEV the ip and ar devices. Then you do a newfs on ip0a and ip0g. With
your disks ready, you then mount them on your miniroot partition and
proceed to untar the release from tape. It's necessary to manually cd to
the proper directories before you give the tar commands--you put the root
and sys stuff on /, and all the other stuff on /usr. Of course, they won't
be the real / or /usr, but whatever name you gave them when you mounted
them on miniroot. I used ip0a and ip0g to make it easier for the feeble
human to keep track of what was going where. Once all the tape stuff is
loaded, you get into the ip0a /dev and do a MAKEDEV for the ip device, as
well as a bunch of others. I think I had to make the win (window) stuff,
a bunch of pty's for ether logins, and several others. The only mistake I
made was to forget to do a sync before I tried to boot the newly created
file system. Booting died horribly, sigh. I ended up having to reboot the
miniroot and fsck the / partition. As part of the fix, I also had to
reMAKEDEV the ip stuff, since that's what got trashed by my failure to
sync.
So it is possible to run 3.5 with the "unsupported" ip controller.
Unfortunately, 4.0 seems to completely lack a driver for the ip, which
means I'll be stuck at 3.5 release. Unless I can find a Xylogics
controller for a reasonable price, that is. I refuse to pay more for an xy
controller (list) than the whole rest of my computer.
--Steve
------------------------------
End of SUN-Spots Digest
***********************