SUN-Spots Digest, v4n5
Scott Alexander
Sun-Spots-Request at RICE.EDU
Wed Feb 19 08:05:31 AEST 1986
SUN-SPOTS DIGEST Tuesday, 18 Feb 1986 Volume 4 : Issue 5
Today's Topics:
On March 1, >1-user Suns cost $2K more
Replacing VAXes with SUN/3s (2)
vfont format. (3)
CLU for the SUN
Re: lock removal by tip
Pixrect depth bugs
UNIFORUM demos/announcements??
question to whomever...
SUN 1Mb -> 4Mb conversion
Speed of Sun 3/50
are ie boards needed on clients?
SUN draw program wanted
Need a good (fast, cheap) printer for bitmap images.
Changing your cursor in a ttywindow....
------------------------------------------------------------------------
Date: Mon, 17 Feb 86 21:46:32 PST
From: hoptoad!gnu at lll-crg.ARPA (John Gilmore)
Subject: On March 1, >1-user Suns cost $2K more
I found a giant whammy in Sun's latest price list (effective January 22,
1986), on page 31. I'll just quote and then I'll comment.
"Right to Use Licenses for Latest Revision of Sun-2 or Sun-3 System Software
Note: 1. Prior to March 1, 1986, all workstations ordered (except
the 3/52M) include a 16-user right to use.
2. Effective March 1, all workstation ordered (except the
3/52M) must include on the customer order one of the
following licenses.
3. A license can only be purchased with a workstation on the
same order.
4. Licenses may be upgraded later to add more users (see below).
5. NO MEDIA OR MANUALS ARE INCLUDED. See previous page.
Maximum Number of Concurrent Users Allowed
(See Sun Object Code License for Details)
Single-user 16-user 32-user 64-user Unlimited
SYSL1 SYSL16 SYSL32 SYSL64 SYSL64P
No charge $2,000 / A $4,000 / A $10,000 / A $20,000 / A
" unquote.
I've talked to some of the people at Sun about this and indicated that,
both as a customer and a stockholder, I think this is a bad idea.
They seem disinclined to change it, so I thought I'd better warn
you-all that you should either scream loudly enough to get it changed,
or order your upcoming systems before March 1st.
Legally, if you attach a terminal to a Sun Workstation on one of the
serial ports, you are required to pay the extra $2000, effective March
1st. So it both raises the quotable price of each workstation by $2K
*and* it encourages customers to order the single-user license and
deliberately break their license agreement.
PS: The "/ A" after the prices is the discount category.
PPS: After you have ordered the workstation, you can upgrade to a
higher-cost license for the difference in cost plus $200. Except
when going from a 32-user license, when it's the difference + $1200.
Either they want to discourage 32-user licenses or they can't subtract.
-----------------------------
Date: Sun, 9 Feb 86 13:12:16 EST
From: bzs%bostonu.csnet at CSNET-RELAY.ARPA
Subject: Replacing VAXes with SUN/3s
At Boston University Computer Science we have sold our VAX/780 and
replaced it with two SUN/3 systems. Among other things we make
extensive use of NFS to make logging into either system quite
transparent to the user, we hope to extend this to more systems and
of course to extend it to people's desks. So far it seems to be
quite good although I would still like to hold off on specific
experiences for a few weeks (we are still waiting delivery of
a few pieces which aren't scheduled until early March.)
If there is interest I could put together an overview of our
experiences. Without going into specifics I would say yes, this
is something worth looking into. We more or less managed to
finance the cost of the upgrade out of the resale value of
the VAX which I still am fairly amazed at.
-Barry Shein, Boston University
-----------------------------
From: John Lee <mcvax!edcaad.ed.ac.uk!john at seismo.css.gov>
Date: Tue, 11 Feb 86 12:53:15 GMT
Subject: Re: Sun 3 as VAX replacement.
Sorry for misleading you, but what I should have typed was 3/160 or
3/180 rather than 3/75. If I can get any more info. from you as to
whether these bigger machines will successfully fill the role of a VAX,
I should be most grateful.
Thanks,
John Lee.
-----------------------------
Date: Mon, 10 Feb 86 00:02:22 est
From: mark at mimsy.umd.edu (Mark Weiser )
Subject: vfont format.
It turns out there is a sun supplied tool, called /usr/lib/vswap, which
converts vax vfont format to/from sun vfont format. See man vswap on your
sun for more into. (Thanks to Bill Shannon of Sun for pointing this out).
-mark
[And thanks to all the others who responded to sun-spots with notes about
vswap. I only included the most complete of these messages since there was
much overlap of information. ---dsa]
-----------------------------
Date: Mon, 10 Feb 86 11:25:27 pst
From: swagman%swagman at SUN.ARPA (Patrick J. McEvoy)
Subject: vfonts
> 4.2bsd came with a huge directory called /usr/lib/vfont. When I
> try to use the fonts in here on my sun (i.e. look at them with fonttool),
> I get the message that they are not in vfont format. Is this a byte-order
> problem, or did vfont format change?
>
> [By 4.2bsd, I assume you mean the VAX version. Talking to the people here
> who have played with vfonts I found that to move the fonts you need to
> byte swap the shorts in the header of the file and to pad the rows to word
> rather than byte boundaries. ---dsa]
Three things:
First, take a look at vswap(1). This program takes care of the
VAX/Sun byte ordering problems. vfontinfo(1) is also helpful.
Second, Sun also ships all those fonts. They come off the
distribution tape when you load the vtroff optional software.
Third, beware. Fonttool does not work too well on variable pitch
fonts. It assumes that all characters are as large as the max size.
Also, the suntools and sunview terminal emulators do not work well
with variable pitch fonts.
-----------------------------
Date: Mon, 10 Feb 86 19:14:30 CST
From: William LeFebvre <phil at dione>
Subject: Re: vfont format
> [By 4.2bsd, I assume you mean the VAX version. Talking to the people here
> who have played with vfonts I found that to move the fonts you need to byte
> swap the shorts in the header of the file and to pad the rows to word rather
> than byte boundaries. ---dsa]
Point of clarification: the bitmap rows should be padded to shortword
boundaries (16 bits). The term "word" is, at the least, ambiguous.
William LeFebvre
-----------------------------
Date: Mon 10 Feb 86 12:41:23-EST
From: Paul R. Johnson <PRJohnson at XX.LCS.MIT.EDU>
Subject: CLU for the SUN
With respect to the announcement of our release of an implementation
of CLU for the SUN Workstation:
Only send simple requests for the license form to Anne Rubin at the
address given. If you have ANY other questions please send them to
me:
Paul R. Johnson
M.I.T., L.C.S.
545 Technology Square, Room 531
Cambridge, Mass. 02139
(617) 253-1945
PRJohnson at XX.LCS.MIT.EDU
Thank you.
-----------------------------
Date: 11 Jan 86 (Sat) 12:26:47 EST
From: Sam G. Fulcomer <sgf at brunix.uucp>
Subject: Re: lock removal by tip
something easier than changing code is chowning uucp the uucp directory,
chowning uucp tip, and chmodding 4*** tip.
-----------------------------
Date: Mon 10 Feb 86 09:48:23-PST
From: Neil Hunt <Nhunt at SRI-KL>
Subject: Pixrect depth bugs
I first noticed problems when attempting to write text to a retained
graphics subwindow on a colour sun; the pw_text fails to notice that
the destination pixwin is depth 8, while the source is depth 1,
and the text is written compressed into one eigth of its normal width,
and looks almost as if the letters have been slotted into the page
sideways ! The problem only occurs when the pixwin is retained, and
the depth of the destination pixrect is greater than the depth of the
source pixrect (1, in the case of pixfonts).
I next tried simply creating a mem_pixrect of depth 8, and writing
text to it with pf_text and pf_ttext, then pw_rop'ing it to a window.
Same results !
I wasn't sure how pf_text used pf_rop or pf_replrop, so I decided to
see if it was some problem at the interface level; I rewrote
pf_text in terms of pf_rop's of the actual pixrects from the
pixfont. This was slower (probably because I was very naive about
locking) but worked fine with destination pixrects of depth 1;
however, this time, *nothing* appeared in mem_pixrects of depth 8 !
Not having any source code for pixrect library stuff, I debugged the
object code. I examined the program after it had allocated a
mem_pixrect of depth 8, and discovered that the pf_rop macro calls
a function called mem_rop for a memory pixrect. I examined this
function, and discovered that it checks that the source and destination
pixrects are the same depth, and if not, returns -1 without any further
work ! I re-read my documentation, and checked that it really
did say that pixrects of depth 1 can be used as sources in an operation
on destination pixrects of *any* depth. Clearly I have found a
"not implemented" bug.
There are still some unexplained phenomena:
Clearly pf_text and pw_text work to destination pixrects of depth 8
when the destination is not a memory pixrect; otherwise one couldn't
have text on a colour sun ! This is reasonable, as the pf_text macro
will call a different function for each different kind of destination
pixrect. What I cannot understand is how text in a retained window
comes out compressed. I would have expected that either
(1) The text would be written to the retained memory pixrect and
then copied to the screen with a pw_rop of the entire bounding rectangle,
or
(2) The text would be written to the retained pixrect with a pf_text,
and then to the screen with a pw_text.
In case 1, nothing would appear on the screen, as it is clearly impossible
to write text directly into a memory pixrect when mem_rop (called
also by mem_replrop) refuses to touch it.
In case 2, the text should appear correctly on the screen at the time
written, but should disappear completely from the first repair of damage.
In neither case should the observed effect where the text is written
as if the screen were 1 bit deep be observed.
A- Has anyone else had problems, or has anyone got any further light
to shed on the subject ?
B- Has anyone written a fix yet ? I am thinking of writing an alternative
mem_rop function which could be substituted for the existing mem_rop
as each mem_create returned.
PS: I checked the code on our brand new sun 3's, and although they run
much faster, the results are identical, so clearly sun hasn't fixed
the problem yet !
Neil/.
Nhunt at sri-kl.arpa (415) 496 4708
-----------------------------
Date: Fri, 14 Feb 86 18:27:33 est
From: Ken Mandelberg <km%emory at CSNET-RELAY.ARPA>
Subject: UNIFORUM demos/announcements??
Can anyone summarize what Sun demonstrated and announced at
Uniforum? For example, I have heard that Sun was showing
a PC running NFS, but did not show a 3B2 running NFS (or
a Sun running RFS) as earlier expected.
This is all rumor, I wasn't at UNIFORUM. Hence the question.
Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322
{akgua,sb1,gatech,decvax}!emory!km USENET
km at emory CSNET
km.emory at csnet-relay ARPANET
-----------------------------
From: lerner at isi-vaxa.ARPA (Mitchell Lerner)
Date: 13 Feb 1986 1050-PST (Thursday)
Subject: question to whomever...
Will/does Sun Unix 3.0 incorporate (partially or fully) the performance
(kernal) and/or functional mods found in 4.3BSD???
lerner at isi-nova.arpa
-----------------------------
Date: Sun, 16 Feb 86 05:39:40 EST
From: rpics!fujiirm at seismo.css.gov (Roger M. Fujii)
Subject: SUN 1Mb -> 4Mb conversion
I'm interested in retrofitting the SUN 1Mb board with 256K drams.
Has anyone done this? It seems straight-forward, but I am
uncomfortable in trying to do this without schematics (who knows,
you might have to cut a trace on the 2nd layer on the board :-))
Roger Fujii
-----------------------------
Date: Mon, 17 Feb 86 01:52:33 est
From: Ken Mandelberg <km%emory at CSNET-RELAY.ARPA>
Subject: Speed of Sun 3/50
I tried running the Dhrystone benchmark on a Sun 3/50 workstation.
I was expecting it to run 10% slower than our Sun 3/160 because of
the 10% slower clock. Instead I found that it actually ran 25%
slower.
There must be some additional architectural change beside the clock
to explain this.
Any ideas?
-----------------------------
From: allegra!mp at seismo.CSS.GOV
Date: Tue, 11 Feb 86 22:25:54 est
Subject: are ie boards needed on clients?
Because of the rumored demise of nd in release 3.2, we're going to
start running NFS here when 3.0 comes. We're definitely going to get
the Sun ethernet boards for our 6 file servers, but not everyone I've
talked to at Sun thinks that these boards are necessary for clients (of
which we have 40 with the 3com boards, so this would be a major
expenditure). Has anyone done a comparison to see if they really
help?
Mark Plotnick
allegra!mp
-----------------------------
Date: Thu, 13 Feb 86 15:33:34 est
From: dewitt at cca-unix.arpa (Mark DeWitt)
Subject: SUN draw program wanted
Does anyone out there have a reasonably reliable, not necessarily fancy
draw program which will run under SUN BSD 4.2 Version 2.0 and for which
s/he can send us the source?
We would like to do a mock-up of the output of a graphical demo before
we write the demo code itself, and for that we need a tool that will
allow us to create, save, and restore pictures roughly the size of a
standard terminal subwindow (or smaller). We will hack something out
of icontool.c if we must, but we'd rather not bother if someone else
already has. We are not interested in producing hard copy, only in
getting pictures to and from the display.
I should note that I tried using the 'draw' program supplied in the
demo directory but couldn't get it to do much of anything.
If you have source to such a program, please mail me a description of
its functionality (needn't be a manual, but a page or two would be
helpful) along with the program. Thank you in advance.
-----------------------------
Date: Fri, 14 Feb 86 10:07:34 est
From: rochester!srs!matt at seismo.css.gov (Matt Goheen)
Subject: Need a good (fast, cheap) printer for bitmap images.
We are in the market for a printer for our systems that can print
bitmap images at a good clip (i.e. we are currently using an Epson
and slow just doesn't describe the speed). We would like something
that is a good trade off between high speed and price. Since serial
transmission is so slow, something that hooks up to the Multibus
(we have all Sun-2's - 50's, 170's and a 120) would seem to be a
requirement. Even a VME based product would probably be ok. We
have heard of the Versatec printer but the price was part of what
we heard. Any recomendations?
Matt Goheen
S.R. Systems
UUCP (only): {allegra,seismo}!rochester!srs!matt
-----------------------------
Date: Wed, 12 Feb 86 10:49:35 PST
From: gerolima at Ford-wdl1.ARPA (Mark Gerolimatos)
Subject: Changing your cursor in a ttywindow....
Change the cursor (mouse) in a shelltool?
NO! YOU DON'T HAVE TO MODIFY SHELLTOOL.C!!!!!
Changing a cursor (as well as ALL WIN_xxxxx calls, I think) is an IOCTL
call that takes the UNIX file descriptor for the window.
It DOES NOT NEED THE TOOL INFORMATION.
Therefore, as long as you know what window you're in (using the WINDOW_ME
environment variable), you can take control over your cursor!
There are both {ad,and dis}advantages to doing it this way...
-> You MUST change the cursor on a window-by-window basis
(IE: each time you call up a new ttytool, you have to run
this program)
Actually, this might be useful...
-> You need not keep a HUGE binary in some /.../local/.../bin
directory.
But, hey! Who cares? All I know is that it shore is neato!
The program:
/* CHANGE CURSOR (Mark Gerolimatos, gerolima at ford-wdl1.arpa):
** change to an XOR'd cursor....
**
** Of course, you can always add stuff in to look at the command
** line (or even the cursor!), and change other things like the
** different function (other than XOR), cursor shape, etc.....
**
** to make: cc -o <whatever> change_cursor.c -lsunwindow -lpixrect
**
*/
#include <stdio.h>
#include <sys/file.h>
#include <sunwindow/window_hs.h>
unsigned char mr_pixrect_b [16] [16];
mpr_static(mr_pixrect,16,16,1,mr_pixrect_b);
struct cursor mr_cursor = { 0,0,0,&mr_pixrect};
main()
{
int fd;
/* Look in the environment for a window_me... */
char *mywin = (char *)getenv("WINDOW_ME");
/* I can't remember what getenv returns on failure... */
if((!(strcmp(mywin,""))) || mywin == NULL)
{
fprintf(stderr,"Could not find window\n");
exit(1);
}
/* get the UNIX file descriptor on the window */
if( (fd = open(mywin,O_RDWR)) < 0 )
{
fprintf(stderr,"Could not open window\n");
exit(1);
}
win_getcursor(fd,&mr_cursor);
mr_cursor.cur_function = PIX_SRC ^ PIX_DST;
win_setcursor(fd,&mr_cursor);
}
"For almost a quarter of a century..."
"Eeez next... Mark Gerolimatos
SOFTVARE!.... ARPA: gerolima at ford-wdl1.arpa
verrrry niiice..." UUCP: {sun,fortune}!wdl1!gerolima
-----------------------------
End of SUN-Spots Digest
***********************
More information about the Mod.computers.sun
mailing list