Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/21/88)
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@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, 14 Apr 88 10:51:40 EDT From: Chuck Musciano <chuck@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@trantor.harris-atd.com ------------------------------ Date: Fri, 15 Apr 88 08:37:39 EST From: glenn@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@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@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@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@rice.edu ------------------------------ Date: Thu, 14 Apr 88 17:52:10 PDT From: Jonathan Eisenhamer <jon@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@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@icase.arpa Thanks very much, Steve Keeling ICASE, NASA LaRC ------------------------------ Date: 15 Apr 88 03:44:33 GMT From: rochester!kodak!ektools!rwl@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@ektools ) ------------------------------ Date: Wed Apr 13 00:11:31 1988 From: portal!cup.portal.com!jxh@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@cup.portal.com ------------------------------ Date: Thu Apr 14 19:17:02 1988 From: portal!cup.portal.com!jxh@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@cup.portal.com ------------------------------ End of SUN-Spots Digest ***********************