Sun-Spots Digest, v6n61
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri Apr 22 01:29:32 AEST 1988
SUN-SPOTS DIGEST Thursday, 21 April 1988 Volume 6 : Issue 61
Today's Topics:
Re: Menu items with varying heights under SunTools
Sun NFS UDP Checksum Fix
Bug in tod-patch.shar
Clients not responding immediately
Need suggestions about graphics software
Converting sun assembler to microtek asm?
Sun386i MS-DOS details: how compatible? (2)
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, 14 Apr 88 10:51:40 EDT
From: Chuck Musciano <chuck at trantor.harris-atd.com>
Subject: Re: Menu items with varying heights under SunTools
The only way to get menu items of varying heights is to render each item
into a pixrect yourself, and use this pixrect as the MENU_IMAGE to create
the item. Alternately, you could specify different fonts (using
MENU_FONT) for each item, which should produce different height items,
based upon the font size.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(305) 727-6131
ARPA: chuck at trantor.harris-atd.com
------------------------------
Date: Fri, 15 Apr 88 08:37:39 EST
From: glenn at xn.ll.mit.edu (Glenn Adams)
Subject: Sun NFS UDP Checksum Fix
As many of you know, Sun NFS's use of UDP excludes checksumming the UDP
packet. For lossy link layers such as SLIP, or for problem Ethernet
controllers, this can result in getting garbage data when using remote
mounted file systems.
A modified version of kudp_fastsend.o is now available via anonymous FTP
from XN.LL.MIT.EDU that employs UDP checksumming. Place this file in
/sys/OBJ, saving your old object file, prior to building the kernel.
The UDP checksumming is controlled by a global variable, kudpcksum, which
is enabled by default. Note well that this only controls the GENERATION
of checksums on transmitted NFS packets, it DOES NOT control the detection
of checksum errors on received packets or non-NFS packets. To enable the
latter, use adb to set the udpcksum variable to non-zero. By default,
this latter variable is set to zero by Sun, thus disabling tests for
checksum errors on incoming packets. It should be enabled to allow
symmetrical checksumming on NFS.
This fix will work on SUN OS versions 3.2 through 3.5.
Glenn Adams
MIT Lincoln Laboratory
Internet: Glenn at XN.LL.MIT.EDU
UUCP: {ames,cmcl2,decvax,harvard,mit-eddie}!ll-xn!glenn
------------------------------
Date: Thu, 14 Apr 88 11:42:42 CDT
From: stan at shell.UUCP (Stan Hanks)
Subject: Bug in tod-patch.shar
If you apply the TOD patch kit in the archives on a Sun-4, you will get a
rather annoying surprise due to the sys directory having been moved about.
This is accounted for when the OBJ/clock.o module is patched, but not when
it is backed up -- leaving you with a patched version and no unpatched
version.
Patch the makefile using the following diff to fix the problem:
diff mf2 Makefile
125c125
< backupclock4 patching-clock.o patch3b rebuild clean
---
> backupclock patching-clock.o patch3b rebuild clean
159,164d158
<
< backupclock4 :
< $Secho '>>> Now for the patches so you can build kernels with the fix'
< $Secho '>>> Making sure /sys/sun4/OBJ/clock.o is backed up'
< $S-sh -c "if test ! -r /sys/sun4/OBJ/clock.o-noclockfix ; \
< then cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o-noclockfix ; fi"
Stan Hanks
Research Computer Scientist, (and Postmaster!)
Shell Development Company, Bellaire Research Center (713) 663-2385
...!{sun,psuvax,soma,rice,decwrl,ut-sally,ihnp4}!shell!stan stan at rice.edu
[[ Mr. Hanks later sent us this message... --wnl ]]
In my previous message, I included some nifty fixes to the Makefile in the
TOD patch shar file. Well, I missed forgot some of the stuff which should
have been there. Here are some more diffs against the Makefile which will
also let you patch the diskless client kernel directly:
==================
diff Makefile Makefile+
79,81d78
< @echo ' Sun3-3.4-client'
< @echo ' Sun3-3.5-client'
< @echo ' Sun4-3.2FCS-client'
91,93c88,89
< Sun3-3.4-client : patch1x
< Sun3-3.5-client : patch1x
< Sun4-3.2FCS-client : patch3x
---
>
>
99,100d94
< patch1x : checking check1ax dodiff patching-vmunix patch1ax reboot clean
<
106,110d99
< check1ax :
< $Secho 'resettodr+c0?i' | adb /pub.MC68020/vmunix - | grep reset > $(TESTPATCHED)
< $Secho '_resettodr+0xc0: bnes _resettodr+0xca' > $(NOTPATCHED)
< $Secho '_resettodr+0xc0: bnes _resettodr+0xce' > $(ISPATCHED)
<
114,116d102
< patch1ax :
< $Secho 'resettodr+c0?w 660c' | adb -w /pub.MC68020/vmunix
<
139c125
< backupclock4 patching-clock.o patch3b rebuild clean
---
> backupclock patching-clock.o patch3b rebuild clean
141,142d126
< patch3x : checking check3ax dodiff patching-vmunix patch3ax reboot clean
<
148,152d131
< check3ax :
< $Secho 'resettodr+0x110?i' | adb /pub.SPARC/vmunix - > $(TESTPATCHED)
< $Secho '_resettodr+0x110: sub %i5, 0x1, %i5' > $(NOTPATCHED)
< $Secho '_resettodr+0x110: sub %i5, 0x0, %i5' > $(ISPATCHED)
<
156,158d134
< patch3ax :
< $Secho 'resettodr+0x110?W ba276000' | adb -w -k /pub.SPARC/vmunix /dev/mem
<
183,188d158
<
< backupclock4 :
< $Secho '>>> Now for the patches so you can build kernels with the fix'
< $Secho '>>> Making sure /sys/sun4/OBJ/clock.o is backed up'
< $S-sh -c "if test ! -r /sys/sun4/OBJ/clock.o-noclockfix ; \
< then cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o-noclockfix ; fi"
===================
Stan Hanks
Research Computer Scientist, (and Postmaster!)
Shell Development Company, Bellaire Research Center (713) 663-2385
...!{sun,psuvax,soma,rice,decwrl,ut-sally,ihnp4}!shell!stan stan at rice.edu
------------------------------
Date: Thu, 14 Apr 88 17:52:10 PDT
From: Jonathan Eisenhamer <jon at mira.astro.ucla.edu>
Subject: Clients not responding immediately
Yes, another simple question with simple answer: Simply, when our 3/260
server reboots, our 3/160 and four 3/50 clients fail to notice that the
server is once again available. They insist that the nfs server is
unavailable. After waiting approximately 1/2 hour, then they see the
server. Another department here is having the same problem. Has anyone
else experienced this problem? All suggestions, etc., etc. are more than
welcome. We are running SunOS 3.4.
Jonathan Eisenhamer
UCLA Astronomy
------------------------------
Date: Fri, 15 Apr 88 12:05:19 EDT
From: keeling at icase.arpa (Steve Keeling)
Subject: Need suggestions about graphics software
To Users of Graphics Software:
I am getting a Sun 4/110CE-8-P14, and would appreciate any suggestions
concerning graphics software. In particular, I am looking for a package
which offers 2-D and 3-D routines. It would be nice for the 2-D stuff to
represent several functions of a single variable with different colors or
dash patterns, and to allow various options for labeling the axes. It
would also be nice for the 3-D stuff to draw surfaces in color and in
perspective with hidden parts removed, and using a "wire frame" (line
drawing) format and/or a "continuous tone" (smooth image) format. Since
it may also be necessary to represent functions with an irregular domain,
the package should not be limited to say functions defined over a
rectangle. If the software is "polygon-based", it would be nice to have a
friendly mechanism for transforming a set of coordinates into a set of
polygons. As with the 2-D stuff, the 3-D routines should allow various
options for labeling the axes. Finally, I need to be able to create these
pictures in a Sun window, and then send a finished product to an Apple
laserwriter which supports Postscript. Apparently, all of this can be had
from UNIRAS for a truck load of money, which I don't have! Therefore, if
you know of some software which does any of the things mentioned, I would
certainly enjoy hearing about it.
Since at the moment, I am not on the sun-spots mailing list, would you
please send any information you have to my electronic address:
keeling at icase.arpa
Thanks very much,
Steve Keeling
ICASE, NASA LaRC
------------------------------
Date: 15 Apr 88 03:44:33 GMT
From: rochester!kodak!ektools!rwl at rutgers.edu (Richard W. Lourette)
Subject: Converting sun assembler to microtek asm?
I have a problem... Our project has to convert many files that were
written in SUN assembly to Microtek ( Greenhills ) 680x0 assembly or
Motorola format. The Microtek assembler is the one supplied with the
Microtek 'C' compiler. If anyone has already solved this problem, their
solution would be greatly appreciated.
Thanks in advance,
Rich Lourette ( rwl at ektools )
------------------------------
Date: Wed Apr 13 00:11:31 1988
From: portal!cup.portal.com!jxh at sun.com
Subject: Sun386i MS-DOS details: how compatible? (1)
[[ The original poster of this article went out to find answers to his own
questions before I had a chance to get this message out. Be sure to read
teh summary of his findings in the next message. --wnl ]]
As a prospective buyer of a Sun386i, and a reluctant PC wizard, I have
been trying to get information out of Sun that details just how far the
MS-DOS "compatibility" is taken. My sales rep says that one can have "up
to 4 MS-DOS windows." This, coupled with my knowledge of the Intel 80386
Virtual-8086 bit, makes me imagine how things might have been done; but I
need concrete answers. Receptionists have stonewalled me, so I appeal to
the net.
1. Will Ventura Publisher (under GEM) run in such an MS-DOS "window"?
My boss wants desktop publishing, and has asked my opinion of which
machine he should buy to run Ventura. I want him to buy a Sun386i
and run FrameMaker, but he already owns a copy of Ventura, so he will
want it to run there.
2. Why not?
3. Which level of "compatibility" is provided:
a. DOS 3.30 functions
b. NetBIOS
c. EMS/EEMS memory "management"
d. BIOS (video, keyboard)
e. display adapter writes trapped and emulated (CGA, EGA, VGA?)
f. I/O instructions trapped and emulated (CRTC)
g. direct access to I/O-channel slots
I expect that (a) (b) and (c) are provided. I hope that (d) is
provided. I doubt that (e) and (f) are provided; they are quite
ambitious. (g) would be interesting: which "window" gets access?
4. Most MS-DOS applications rely on some "feature" of the PC
that is not defined in any interface. At what level does SunOS admit
to the application that it is not running on an IBM PC, and how gracefully?
My fondest hope for this posting is that the Sun employee(s) that
implemented all this fun stuff will reply in loving detail, justifying
each desicion for the record. I am knowledgable enough to be critical of
such an implementation at every level (having been in the 8086 game since
its announcement in 1980); but I pledge to be an understanding critic.
Send me some credible answers and I will be forever in your debt.
-Jim Hickstein,
Sr. Software Engineer
VSAT Systems, Inc.
2190 Paragon Drive
San Jose, CA 95131
(408) 435-8016
jxh at cup.portal.com
------------------------------
Date: Thu Apr 14 19:17:02 1988
From: portal!cup.portal.com!jxh at sun.com
Subject: Sun386i MS-DOS details: how compatible? (2)
My earlier plea for detailed information about MS-DOS on a Sun386i
(roadrunner) has not yielded information (sun-spots has some delay;
unavoidably, no doubt). So I went to the Sun office in Mountain View, CA
to touch one myself and perform some *experiments*. I realize I should
not be the one to post this information (as someone inside Sun could do so
more accurately), but if there are any people out there as interested in
this as I am, they are not getting answers very fast, either, so here
goes:
The Sun386i will run an arbitrary number of DOS windows, each of which is
a virtual 8086 underneath, with MS-DOS V3.30 loaded into it, plus a BIOS
supplied by Phoenix (this bodes well). HOWEVER only WELL-BEHAVED
applications will run there. Well-behaved applications are those which
call DOS through INT 21H and certain BIOS functions, notably video through
INT 10H. Those that WRITE TO DISPLAY ADAPTERS directly will be
disappointed. Those that use I/O instructions to gain access to
peripherals such as the DMA controller and the serial port will not work.
Sun employees told me that Sun plans to provide a board that will plug
into one of the PC-compatible I/O Channel slots that enables direct
display adapter writes to be trapped and performed within the DOS window
somehow. I thought that a purely software solution was possible (as it
may, indeed, be) but, as I expected, it would be very slow. Since there
are only 4 slots, up to 4 such boards can be used to support up to 4 DOS
windows that write to display memory. Other DOS windows (well-behaved
ones) could, I suppose, run in addition.
Memory is also a limitation. I don't know whether the entire 640KB of RAM
devoted to each DOS window must be locked down in physical memory, but if
that is true, then physical memory would be a hard limit. Even if they
are swappable, a practical limit must exist somewhere. It does not seem
that they are capable of receiving hardware interrupts directly, so
locking them down is probably not necessary.
I/O channel access is restricted to device drivers under SunOS; DOS
applications that want to touch, say, the serial port, must ask politely
through a DOS driver loaded at boot time which asks politely for service
from the SunOS device driver. I interpret this to mean that PC I/O
channel slots are only accessible from privileged tasks, and the MS-DOS
tasks certainly do not have this privilege. Again, such violations could,
I think, be trapped and interpreted by privileged code, executing the
desired IN or OUT on behalf of the DOS application; but again, this is
probably slower than acceptable.
For most applications that are ill-behaved in one of these senses, there
is almost certainly another way to accomplish what you're trying to do
using a better tool that runs in native mode on the machine, but that is
of little consolation to those who have large committments to particular
tools on PCs, like editors and spreadsheets. They will have to wait for
the display-hook board; but at least there is hope.
There is much to tell about the file system that appears to the DOS
program, and I have not scratched the surface. Drive C: looks like a 20MB
drive, but as clusters are allocated they evidently make a SunOS file grow
to accomodate the highest cluster ever used. I put 5MB on my "20MB" drive
and /export (under SunOS) became full. CHKDSK thinks there are 15MB of
free clusters available; it's lying but it can't tell. The file that
contains these clusters seems never to shrink (this was February beta
software, so this may have changed). I deleted my 5MB of junk and /export
was still full (107%, in fact). Other drives, d:, r:, s:, had files that
seemed to map to the *real* file system under SunOS: d:\usr, for example.
Many filenames in there had tildes in them (emacs?). In short, the hooks
seem not to be NetBIOS, nor even PC-NFS, but something new and invisible.
Sun employees told me that NetBIOS was not supported; I forgot whether
they added "yet." It seems to try to convince you that you're really
alone, and you can really do anything you like to the disks. Drive d: was
write- protected, though.
The keyboard is nice, and looks rather like an IBM PC AT 84-key job, but
with function keys down the left side AND across the top. Those on the
left do "Sun" things; those on top are given to DOS functions. The
buffered input template (F3, etc., or <esc> U for old-timers), works fine.
So do the arrow keys on the numeric pad (in WordPerfect, at least).
I touched an RR250FC-8-P9 with the new 16-inch color display. Wow. It is
MUCH, MUCH nicer than the 19-inch tube (and $2K cheaper, too, though I'd
pay MORE for it!). It uses a Sony Trinitron CRT that I saw on sale for
use with a Mac-2: very impressive! The resolution on black-and-white
images is not visibly penalized for having a color display! (There are
some interesting artifacts visible in the CRT, but only once someone
points them out.)
The whole thing was kind of slow (a 25MHz 80386!!!) but I was assured that
this was due to the infancy of the Beta-test software (Feb. 9, 1988) and
the fact that it was "very poorly tuned." The mere concept of being able
to "tune" it brings back fond memories of when I used to work on *real*
computers. At least it's a step in the right direction. (I've been
exiled in PC-land tooooooooo long....)
I also learned that the clock line on the I/O channel is a function of the
processor speed: I think they said f/4: 20MHz 80386 == 5MHz I/O ch. CLOCK.
More tidbits as they surface. Some Sun employee: Please post the facts so
my babblings will not stand as Gospel.
Jim Hickstein VSAT Systems, Inc. San Jose, CA 95131 (408) 435-8016
...!sun!jxh at cup.portal.com
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list