------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10901; 19 Apr 88 0:08 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10561; 18 Apr 88 23:08 EDT Date: Mon, 18 Apr 88 23:04:38 EDT From: Chuck Kennedy To: info-iris@BRL.ARPA Subject: mail archive updated Message-ID: <8804182304.aa10551@VMB.BRL.ARPA> I have recently updated the mail archive on host brl-vgr.arpa (192.5.23.6). It contains messages from 25-Sep-1987 to 15-Apr-88. Those messages are contained in the file info-iris.txt.02. The previous messages are now in the file info-iris.txt.01. These both sit in the directory info-iris and are available via anonymous ftp with any password. -Chuck Kennedy ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23314; 20 Apr 88 4:20 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22899; 20 Apr 88 2:56 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22888; 20 Apr 88 2:49 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa11212; 20 Apr 88 2:44 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 19 Apr 88 23:43:57 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA18457; Tue, 19 Apr 88 09:43:43 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 88 14:55:59 GMT From: Thomas Palmer Organization: NCI Supercomputer Center, Frederick, MD Subject: Read/Write Z buffer access? Message-Id: <452@fcs280s.ncifcrf.gov> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Is there any way to directly access the Z buffer of a 4D/60T? I need to both read and write the Z buffer on a pixel level. -Tom Thomas C. Palmer NCI Supercomputer Facility c/o PRI, Inc. Phone: (301) 698-5797 PO Box B, Bldg. 430 Uucp: ...!uunet!ncifcrf.gov!palmer Frederick, MD 21701 Arpanet: palmer@ncifcrf.gov ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01066; 20 Apr 88 16:34 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa29565; 20 Apr 88 15:00 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29559; 20 Apr 88 14:57 EDT Received: from orville.nas.nasa.gov by SMOKE.BRL.ARPA id aa28242; 20 Apr 88 14:47 EDT Received: Wed, 20 Apr 88 11:47:26 PDT by orville.nas.nasa.gov (5.54/1.2) Date: Wed, 20 Apr 88 11:47:26 PDT From: "David A. Tristram" Message-Id: <8804201847.AA15294@orville.nas.nasa.gov> To: info-iris@brl.MIL Subject: zbuffer There doesn;t seem to be much in the way of documentation for z-buffer access for 3000 or 4d/60's, however, if its any consolation, the GT has *extensive* access to the z-buffer, including read/write and control of the comparison mode (ALWAYS,<,==,>,<=,>=,!=,NEVER), primitive writemasks (on or off, basically), and when drawing, z-type comparisons may also be made from the regular image planes. How's that for the old 'its fixed in the next version' frustrations? tristram ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01318; 20 Apr 88 16:55 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa29410; 20 Apr 88 14:47 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29385; 20 Apr 88 14:43 EDT Received: from FORD-WDL1.ARPA by SMOKE.BRL.ARPA id aa27786; 20 Apr 88 14:39 EDT Received: by FORD-WDL1.ARPA (5.51/5.9) id AA12515; Wed, 20 Apr 88 11:40:26 PDT Date: Wed, 20 Apr 88 11:40:26 PDT From: Rion Cassidy Message-Id: <8804201840.AA12515@FORD-WDL1.ARPA> To: info-iris@BRL.ARPA Subject: disk warning You may remember me from my "reliablity questions" survey that I did a while back. Many of you responded with amazement that anyone could have so many hardware problems with their IRIS. I am posting this as a follow up because we have been given a *HINT* from SGI that our disk problems MAY HAVE BEEN caused by mistakes made by others. Note that I use the word HINT here, because they have made no specific admissions in that regard, and I don't intend to put words in their mouth (or libel myself). As bad as our problems had been, only a couple of weeks after posting my survey, our disk went down again. The tech put in another new disk drive, but we suddenly had 10 meg less disk space to use (50 as opposed to 60 before). We assumed he had done *something* wrong. We had been very tight on disk space before, so of course we insisted he come back and do things *properly*. I'm going to cut out a lot of the intervening conversations here and give you an important observation made by a senior level engineer at SGI: >Our disk had been improperly formatted initially, giving us more >storage space, but putting it in a position to crap out when the disk >capacity is reached. So now we have about 11 less meg of disk space, but it is formatted reliably. I did not format our disk. It is my belief that someone from SGI has always done that (until this week). And now we are being told that the way it was done previously caused our disk problems. I am wondering how many users out there have the same potential problem. A sure sign is that if you have the 72 meg disk with 60 meg of usable storage, because that's what we had. I'm posting this to warn others of the potential disk problems. My suggestion is that if you have a maintenance contract, you write down all your pertinent disk statistics and give the hotline a call. Tell them that you want to verify that your disk is not a potential basket case due to improper formatting. Rion Cassidy Ford Aerospace rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disclaimer: I speak only for myself. The opinions expressd here are mine, not my employers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10820; 21 Apr 88 14:36 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09111; 21 Apr 88 12:41 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa09086; 21 Apr 88 12:34 EDT Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa19684; 21 Apr 88 12:24 EDT Received: by nps-cs.arpa (5.51/1.26) id AA25090; Thu, 21 Apr 88 09:23:15 PST Date: Thu, 21 Apr 88 09:23:15 PST From: michael zyda Message-Id: <8804211723.AA25090@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: Z-buffering Problems... IRIS 4D/70G Z-Buffering Problems... One of my students is having some problems with the z-buffering on the IRIS-4D. He gave me the following letter to post on info-iris. Any similar experience or solutions would be greatly appreciated... "I had some unexpected and unwanted results from using Z-buffering on the IRIS 4-D. I am modeling terrain from a digital database of elevation data. To cut down the number of polygons drawn, I start with a big blue polygon at 0 elevation, "ocean", and only draw polygons that have elevations > 0. Problem: At the intersection of the sea and land you cannot rely on the Z-buffer to always draw the land over the water or even to consistently draw it the same. This is with near and far clipping planes set to 100yds and 120000yds respectively. I believe this problem is due to the resolution of the Z-buffer. I can get an acceptable picture if I draw sea level at -10, close, to -100, far, and set the far clipping plane to 1200000, 10 times the area I'm drawing. This effectively decreases the resolution and wastes 90% of the Z-buffer resolution. With this solution, the coastline, drawn at a distance, is still erratic. By lowering the sea and increasing the area that will be mapped to a certain z value, I insure that land will be drawn over water in a consistent manner. This solution is not very acceptable. Does anyone out there have similar experiences?" Frank Harris fharris@nps-cs.arpa Responses can be sent through zyda@nps-cs.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17410; 22 Apr 88 10:12 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa17254; 22 Apr 88 10:02 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa17185; 22 Apr 88 9:53 EDT Date: Fri, 22 Apr 88 9:40:29 EDT From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: storing/retrieving objects Message-ID: <8804220940.aa13286@TBD.BRL.ARPA> I would like to be able to store display lists in a file for later retrieval. The subroutines might look something like writeobj C writeobj(obj,stream) Object obj; FILE *stream; FORTRAN subroutine writeo(obj, file) Pascal procedure writeobj(obj:Object, stream:FILE); DESCRIPTION writes graphics object "obj" at the end of the file. Leaves file positioned at end of information. -------- writeobj C readobj(obj,stream) Object obj; FILE *stream; FORTRAN subroutine readob(obj, file) Pascal procedure writeobj(obj:Object, stream:FILE); DESCRIPTION Reads the next graphics object from the file and use the information to create an object "obj" in the symbol table and memory. Leaves file positioned ready to read or overwrite the next object on the file, if any. NOTE If the object contains calls to other objects, the user is responsible for making sure that all such objects exist and have the same "obj" object identifiers as when the object was written out. -------- Has anyone written such subroutines or equivalents? It would help to have some documentation of the internal structure of the display list. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17506; 22 Apr 88 10:23 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16199; 22 Apr 88 8:58 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa16167; 22 Apr 88 8:49 EDT Date: Fri, 22 Apr 88 8:36:29 EDT From: Glenn Randers-Pehrson (WMB) To: brl-tbd!brl-smoke!brl-adm!cmcl2!nrl-cmf!mailrus!ames!pasteur!ucbvax!NPS-CS.ARPA!zyda@BRL.ARPA Subject: Re: Z-buffering Problems... Resent-Date: Fri, 22 Apr 88 8:37:40 EDT Resent-From: glennrp@BRL.ARPA Resent-To: info-iris@BRL.ARPA Message-ID: <8804220837.aa12653@TBD.BRL.ARPA> > From: zyda@NPS-CS.ARPA (michael zyda) > Subject: Z-buffering Problems... > IRIS 4D/70G Z-Buffering Problems... > > Problem: At the intersection of the sea and land you cannot > rely on the Z-buffer to always draw the land over the water > or even to consistently draw it the same. > > This solution is not very acceptable. Does anyone out there > have similar experiences?" > Yes. On a 2500T, 3130, and 3030, I attempted to do a hidden-line wireframe by drawing the filled polygons in a background color and then drawing unfilled polygons. It did not work very well. I complained to SGI and was told it was due to the resolution of the geometry engine calculations. I think the exact quote was that "It works as designed". [i.e. not necessarily as specified in the manual]. Here's a copy of my e-mail to SGI: Glenn Randers-Pehrson Date: Thu, 3 Dec 87 12:21:54 EST From: Glenn Randers-Pehrson (WMB) To: dave@sgi.com Subject: polly() Re: HOTLINE log 1824, 3 Dec 87 program pollytest c demonstrates that poly() does not outline polygons properly c in conjuntion with polf() in z-buffer mode. Tests polly() c by Glenn Randers-Pehrson, which attempts to do this properly. dimension square(3,4) integer near,far character*1 key data near,far/x'c000',x'3fff'/ call ginit call greset call cursof call setdep(near,far) call ortho (0., 1.0, 0.0, 1.0, 1.0,-1.0) call zbuffe(.true.) call color(0) call clear do 200 mode=0,1 call zclear kol=1 do 100 k=1,2 x=.025*k + .5*mode y=.025*k + .1 z=k-1.5 + x*.01 square(1,1)=x square(2,1)=y square(3,1)=z+.01 square(1,2)=x+.3 square(2,2)=y square(3,2)=z+.01 square(1,3)=x+.3 square(2,3)=y+.3 square(3,3)=z+.02 square(1,4)=x square(2,4)=y+.3 square(3,4)=z call color(kol) call polf(4,square) call color(3) call cmov2(x,.5) if(mode.eq.1)then if(k.eq.1)call charst('polly()',7) call color(2) call polly(4,square) else if(k.eq.1)call charst('poly()',6) call color(2) call poly(4,square) endif kol=4 100 continue 200 continue 300 continue read(*,'(a1)')key call fhalt(1) end subroutine polly(n,xyz) c FORTRAN version of poly() that uses zbuffer consistently c with polf(), for use in making outlined polygons c by Glenn Randers-Pehrson c U.S. Army Ballistic Research Laboratory c Aberdeen Proving Ground, MD 21005-5066 dimension xyz(3,n) dimension temp(3,2) do 10 j=1,3 temp(j,1)=xyz(j,n) 10 continue do 40 i=1,n do 20 j=1,3 temp(j,2)=xyz(j,i) 20 continue call polf(2,temp) do 30 j=1,3 temp(j,1)=temp(j,2) 30 continue 40 continue return end ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab17506; 22 Apr 88 10:23 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16375; 22 Apr 88 9:16 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa16297; 22 Apr 88 9:00 EDT Date: Fri, 22 Apr 88 8:56:16 EDT From: Glenn Randers-Pehrson (WMB) To: brl-tbd!brl-smoke!brl-adm!cmcl2!nrl-cmf!mailrus!ames!pasteur!ucbvax!NPS-CS.ARPA!zyda@BRL.ARPA cc: info-iris@BRL.ARPA Subject: Re: Z-buffering Problems... Message-ID: <8804220856.aa12870@TBD.BRL.ARPA> I meant to include this in my previous message: Date: Fri, 4 Dec 87 10:35:57 EST From: Glenn Randers-Pehrson (WMB) To: dave@sgi.com Subject: zbuffer and polygons Re: log 1824, 3 Dec 87. Dave, I have done some more testing with the program I sent you yesterday and find that in general it does not do much better than the regular poly() routine (It gives the "lumpy, gloppy" edge that you described on the phone), no doubt due to the floating point differences you mentioned. Case closed, I guess. ...Glenn Randers-Pehrson ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19476; 22 Apr 88 13:32 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab19335; 22 Apr 88 13:22 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab19291; 22 Apr 88 13:16 EDT Received: from [128.186.3.1] by SMOKE.BRL.ARPA id aa01768; 22 Apr 88 13:10 EDT Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA07602; Fri, 22 Apr 88 13:12:31 EST Date: Fri, 22 Apr 88 13:12:31 EST From: "John D. McCalpin" Message-Id: <8804221812.AA07602@masig1.ocean.fsu.edu> To: info-iris@BRL.ARPA Subject: IRIS 3000 floating-point With regard to the floating-point results I just posted, the SUN workstations pass the test perfectly in single and double precision..... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21038; 22 Apr 88 15:27 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19335; 22 Apr 88 13:22 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa19291; 22 Apr 88 13:16 EDT Received: from [128.186.3.1] by SMOKE.BRL.ARPA id aa01652; 22 Apr 88 13:06 EDT Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA07594; Fri, 22 Apr 88 13:08:39 EST Date: Fri, 22 Apr 88 13:08:39 EST From: "John D. McCalpin" Message-Id: <8804221808.AA07594@masig1.ocean.fsu.edu> To: info-iris@BRL.ARPA Subject: IRIS 3000 floating-point I found a set of floating-point tests by a Richard Karpinsky of UC/San Fran on the netlib server at Argonne. I ran them on my IRIS 3030 and got the following results: A Paranoid Program to Diagnose Floating-point Arithmetic ... Single-Precision Version ... Please send suggestions and interesting results to Richard Karpinski Computer Center U-76 University of California San Francisco, CA 94143-0704 USA In doing so, please include the following information: Precision: Single; Version: 31 July 1986; Computer: Silicon Graphics IRIS 3030 Compiler: Silicon Valley Software f77 version 2.5 Optimization level: default Other relevant compiler options: -fZ (Weitek fpa) Running this program should reveal these characteristics: b = radix ( 1, 2, 4, 8, 10, 16, 100, 256, or ... ) . p = precision, the number of significant b-digits carried. u2 = b/b^p = one ulp (unit in the last place) of 1.000xxx.. u1 = 1/b^p = one ulp of numbers a little less than 1.0. g1, g2, g3 tell whether adequate guard digits are carried; 1 = yes, 0 = no; g1 for mult., g2 for div., g3 for subt. r1,r2,r3,r4 tell whether arithmetic is rounded or chopped; 0=chopped, 1=correctly rounded, -1=some other rounding; r1 for mult., r2 for div., r3 for add/subt., r4 for sqrt. s=1 when a sticky bit is used correctly in rounding; else s=0. u0 = an underflow threshold. e0 and z0 tell whether underflow is abrupt, gradual or fuzzy v = an overflow threshold, roughly. v0 tells, roughly, whether infinity is represented. Comparisons are checked for consistency with subtraction and for contamination by pseudo-zeros. Sqrt is tested. so is y^x for (mostly) integers x . Extra-precise subexpressions are revealed but not yet tested. Decimal-binary conversion is not yet tested for accuracy. The program attempts to discriminate among: >FLAWs, like lack of a sticky bit, >SERIOUS DEFECTs, like lack of a guard digit, and >FAILUREs, like 2+2 = 5 . Failures may confound subsequent diagnoses. The diagnostic capabilities of this program go beyond an earlier program called "Machar", which can be found at the end of the book "Software Manual for the Elementary Functions" (1980) by W. J. Cody and W. Waite. Although both programs try to discover the radix (b), precision (p) and range (over/underflow thresholds) of the arithmetic, this program tries to cope with a wider variety of pathologies and to say how well the arithmetic is implemented. The program is based upon a conventional radix representation for floating-point numbers, but also allows for logarithmic encoding (b = 1) as used by certain early wang machines. Program is now RUNNING tests on small integers: -1, 0, 1/2 , 1, 2, 3, 4, 5, 9, 27, 32 & 240 are O.K. Searching for radix and precision... Radix = 2. Closest relative separation found is 5.96046400E-08 Recalculating radix and precision confirms closest relative separation . Radix confirmed. The number of significant digits of radix 2. is 24.00 Test for extra-precise subexpressions: Subexpressions do not appear to be calculated with extra precision. Subtraction appears to be normalized as it should. Checking for guard digits in multiply divide and subtract. These operations appear to have guard digits as they should. Checking for rounding in multiply, divide and add/subtract: Multiplication appears to be correctly rounded. Division is neither chopped nor correctly rounded. Add/subtract appears to be correctly rounded. Sticky bit used incorrectly or not at all. FLAW: lack(s) of guard digits or failure(s) to correctly round or chop (noted above) count as one flaw in the final tally below. Does multiplication commute? Testing if x*y = y*x for 20 random pairs: No failure found in 20 randomly chosen pairs. Running tests of square root... Testing if sqrt(x*x) = x for 20 integers x. Found no discrepancies. Sqrt has passed a test for monotonicity. Testing whether sqrt is rounded or chopped: Square root is neither chopped nor correctly rounded. Observed errors run from -.6050455E+00 to .5000000E+00 ulps. Testing powers z^i for small integers z and i : Start with 0.**0 . No discrepancies found. Seeking underflow threshold and min positive number: Smallest strictly positive number found is minpos = 1.17549400E-38 Since comparison denies MINPOS = 0, evaluating ( MINPOS + MINPOS ) / MINPOS should be safe; what the machine gets for ( MINPOS + MINPOS ) / MINPOS is .2000000E+01 This is O.K. provided over/underflow has not just been signaled. DEFECT: what prints as MINPOS = .11754940E-37 compares different from MINPOS /1 = .00000000E+00 FLAW: x = .32326090E-37 is unequal to z = .23509890E-37 , yet x-z yields .0000000E+00 Should this not signal underflow, this is a SERIOUS DEFECT that causes confusion when innocent statements like if (x.eq.z) then ... else ... ( f(x)-f(z) )/(x-z) ... encounter division by zero although actually x/z = 1 + .37500000E+00 The underflow threshold is .23509890E-37 , below which calculation may suffer larger relative error than merely roundoff. since underflow occurs below the threshold = ( 2.00000000E+00)^( -1.25000000E+02) , only underflow should afflict the expression ( 2.00000000E+00)^( -2.50000000E+02) ; actually calculating it yields -.64000400E+02 SERIOUS DEFECT: this is not between 0 and underflow threshold= .23509890E-37 Testing x^((x+1)/(x-1)) vs. exp(2) = .73890560E+01 as x-> 1. Accuracy seems adequate. Testing powers z^q at four nearly extreme values: No discrepancies found. Searching for overflow threshold: Can " z = -y " overflow? trying it on y = ---------------- Seems O.K. Overflow threshold is v = 3.40282400E+38 Overflow saturates at sat = ++++++++++++++++ No overflow should be signaled for v*1 = 3.40282400E+38 nor for v/1 = 3.40282400E+38 Any overflow signal separating this * from one above is a DEFECT. DEFECT: comparison alleges that what prints as z = ++++++++++++++++ is too far from sqrt(z)^2 = .34028230E+39. FLAW: unbalanced range; UFLTHR * V = .80000E+01 IS TOO FAR FROM 1. FAILURE: x/x differs from 1 when x = .34028E+39 instead, x/x - 1/2 - 1/2 = -.10000E+01 What messages and/or values does division by zero produce? About to compute 1/0... Trying to compute 1/0 produces 0.0000000E+00 About to compute 0/0... Trying to compute 0/0 produces 0.0000000E+00 The number of FAILUREs encountered = 1 The number of SERIOUS DEFECTs discovered = 1 The number of DEFECTs discovered = 2 The number of FLAWs discovered = 3 The arithmetic diagnosed has unacceptable Serious Defects. Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses. End of Test. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26684; 23 Apr 88 14:06 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26399; 23 Apr 88 13:04 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26391; 23 Apr 88 12:51 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa18174; 23 Apr 88 12:43 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 23 Apr 88 09:43:20 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09228; Fri, 22 Apr 88 16:31:17 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Apr 88 19:20:27 GMT From: Rusty Sanders Subject: Re: Z-buffering Problems... Message-Id: <338@megatek.UUCP> References: <8804211723.AA25090@nps-cs.arpa> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU From article <8804211723.AA25090@nps-cs.arpa>, by zyda@NPS-CS.ARPA (michael zyda): > IRIS 4D/70G Z-Buffering Problems... > > One of my students is having some problems with the z-buffering > on the IRIS-4D. [...] > > Problem: At the intersection of the sea and land you cannot > rely on the Z-buffer to always draw the land over the water > or even to consistently draw it the same. This is with near and > far clipping planes set to 100yds and 120000yds respectively. The Z-buffer on the 4D is 24 bits deep, which would imply that the resolution would be 1 part in 2^24 (1 part in 16777216). Your model (if accurate to the .1 yard level) requires only one part in 1200000, which is about 2^20.195. One would think that this would be easy to represent. Unfortunately, it just ain't so. While there may be 24 bits to store the data, nowhere near that many bits are accurate. The first bit of accuracy is obvious, IEEE only has 23 bits of mantissa. Feeding the pipe in double precision may help a little bit there, but I doubt it. SGI does it's math in the pipe in some single precision form (not IEEE). Chances are it's only 23 bits of mantissa in any case. Additionally, each math operation adds in a bit more inaccuracy. By the time you've done a few rotations and translates you've done several math operations. After all those you have to finally pass the vector through the 4x4 to generate a screen space vector. After all that math you probably only have 19 bits of precision, maybe 20 if you're really being careful. That means somewhere between 2^19 (1 part in 524288) and 2^20 (1 part in 1048578) precision in the z buffer. This is clearly not enough for your model (even if you're only modeling on one tenth yards, smaller levels would be harder still). Something you can try is to clean up your transformations (as an experiment). Do all the matrix calculations in the CPU using double precision. Then just do a loadmatrix at the end to set up the final viewing matrix. This would mean you can't use any of those nice ortho, lookat, polarview, translate, scale, rotate, multmat, or similar calls. Lookup what they do in the appendix to the reference manual and do that matrix math in the host. All this work will probably buy you 2 bits of precision, giving you about 2^21 (1 part in 2097152). That would be sufficient. It won't be as fast that way, and you won't be able to put display manipulations in your display list (if you're using one). But it should work. Note that my imprecision calculations are not very precise themselves. And it is really affected by just how many display manipulations you do. You're mileage may very by quite a bit, and you could be as low as only 17 or 18 bits of precision by the time you get to the screen (in a really bad case). All of this is mathematical conjecture on my part, having not worked with a 24 bit Z buffer before. I would like to hear back if you can verify my thoughts on this, however. Rusty Sanders, Megatek Corp. --> rgs@megatek or... ...ucsd! ..hplabs!hp-sdd!megatek!jay ...ames!scubed! ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00625; 24 Apr 88 16:57 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00595; 24 Apr 88 16:46 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00577; 24 Apr 88 16:39 EDT Received: from RUTGERS.EDU by SMOKE.BRL.ARPA id aa26572; 24 Apr 88 16:28 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA26137; Sun, 24 Apr 88 15:39:32 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA07428; Sun, 24 Apr 88 16:05:12 EDT Received: by hombre.MASA.COM (smail2.5) id AA03462; 24 Apr 88 15:03:31 EDT (Sun) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA22363; Sun, 24 Apr 88 14:30:30 EDT Date: Sun, 24 Apr 88 14:30:30 EDT From: Rodian Paul Message-Id: <8804241830.AA22363@dasys1.UUCP> To: Info-Iris@BRL.ARPA Subject: mail routing I have a 4D/70 (gungadin) and a CS12 (sabu) both running NFS. I want to keep all mail on 'sabu', so in my /usr/lib/aliases on 'gungadin' all mail gets forwarded to 'sabu'. The problem is that I want to notify users who are logged onto 'gungadin' that they have mail on 'sabu'. If I execute a shell via cron on 'sabu' to send a message via mail to the user on 'gungadin' that they have new mail on 'sabu', the mail obviously gets re-routed back to 'sabu'. Given that I'm a novice at this stuff, can anyone offer a solution to this problem? Cheers, Rod. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00704; 24 Apr 88 17:39 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00554; 24 Apr 88 16:35 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00548; 24 Apr 88 16:28 EDT Received: from RUTGERS.EDU by SMOKE.BRL.ARPA id aa26551; 24 Apr 88 16:24 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA26046; Sun, 24 Apr 88 15:38:00 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA07394; Sun, 24 Apr 88 16:04:43 EDT Received: by hombre.MASA.COM (smail2.5) id AA03442; 24 Apr 88 15:03:17 EDT (Sun) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA22049; Sun, 24 Apr 88 14:04:44 EDT Date: Sun, 24 Apr 88 14:04:44 EDT From: Rodian Paul Message-Id: <8804241804.AA22049@dasys1.UUCP> To: Info-Iris@BRL.ARPA Subject: Kermit on 4D series Does anyone have a version of kermit running on the 4D series of machines. If you do, could you let me know what modifications to the code are. Cheers, Rod. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab00704; 24 Apr 88 17:39 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab00554; 24 Apr 88 16:35 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00550; 24 Apr 88 16:28 EDT Received: from RUTGERS.EDU by SMOKE.BRL.ARPA id aa26567; 24 Apr 88 16:26 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA26063; Sun, 24 Apr 88 15:38:26 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA07406; Sun, 24 Apr 88 16:04:56 EDT Received: by hombre.MASA.COM (smail2.5) id AA03452; 24 Apr 88 15:03:25 EDT (Sun) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA22240; Sun, 24 Apr 88 14:17:56 EDT Date: Sun, 24 Apr 88 14:17:56 EDT From: Rodian Paul Message-Id: <8804241817.AA22240@dasys1.UUCP> To: Info-Iris@BRL.ARPA Subject: nroff Can anyone point me in the direction of a public domain version of nroff for SYS V. Anyone else out there with only Clover (4D series) machines has a problem in that AT&T wouldn't allow SGI to release nroff on the distribution tapes. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00962; 24 Apr 88 19:03 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00813; 24 Apr 88 18:22 EDT Received: from brl-vgr.arpa by VMB.BRL.ARPA id aa00805; 24 Apr 88 18:15 EDT Date: Sun, 24 Apr 88 18:12:11 EDT From: Doug Gwyn (VLD/VMB) To: Rodian Paul cc: Info-Iris@BRL.ARPA Subject: Re: nroff Message-ID: <8804241812.aa23223@VGR.BRL.ARPA> I'm sure that AT&T would allow SGI to ship nroff, but only under a Documenter's WorkBench sublicensing agreement. I rather doubt that anyone has implemented a public-domain nroff. You could obtain it yourself from AT&T, but you'll have to port it. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06564; 25 Apr 88 11:50 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05667; 25 Apr 88 10:37 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05613; 25 Apr 88 10:24 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa09996; 25 Apr 88 10:11 EDT Received: Mon, 25 Apr 88 10:12:09 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Mon, 25 Apr 88 10:12:09 EDT From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8804251412.AA00295@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Time Zones Does anyone know how to change the dates on which the automatic time zone takes effect? We have both System V and BSD systems and we can't find out how to do it. The manuals say it can be done, but they say how. This is one of those small anoyances you wish you could correct, but can't figure out how. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02773; 27 Apr 88 9:40 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01273; 27 Apr 88 8:15 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ad01215; 27 Apr 88 8:07 EDT Received: from uunet.UU.NET by SMOKE.BRL.ARPA id aa24913; 27 Apr 88 8:04 EDT Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA05833; Wed, 27 Apr 88 08:04:12 EDT Received: by mcvax.cwi.nl; Wed, 27 Apr 88 13:42:23 +0200 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA19506; Wed, 27 Apr 88 12:13:03 +0200 Received: by unizh.UUCP (4.12/4.7) id AA22090; Wed, 27 Apr 88 11:43:03+0100 Date: Wed, 27 Apr 88 11:43:02 +0200 From: mcvax!unizh!meyer@uunet.uu.net MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Message-Id: <8804270943.AA29083@gorgo.uucp> Received: by gorgo.uucp id AA29083; Wed, 27 Apr 88 11:43:02 +0200 To: info-iris@BRL.ARPA Subject: Problems with cron Hi out there, We are experiencing problems with cron. Sporadically it executes a command setup in some crontab entry twice. An excerpt from the cron log is shown below. Has anybody noticed this problem? What can be done to get around it? Our environment: 4D/70G, Unix Release 4D1-2.0 Urs Meyer ------- cron log (/usr/lib/cron/log): > CMD: /usr/lib/sa/sa1 > sys 1994 c Wed Apr 27 04:00:00 1988 < sys 1994 c Wed Apr 27 04:00:00 1988 > CMD: /usr/lib/sa/sa1 > sys 2001 c Wed Apr 27 04:59:59 1988 < 1. < sys 2001 c Wed Apr 27 05:00:00 1988 > CMD: /usr/lib/sa/sa1 > sys 2004 c Wed Apr 27 05:00:00 1988 < 2. < sys 2004 c Wed Apr 27 05:00:00 1988 > CMD: /etc/dump/daydmp 2>&1 | /bin/mail root > root 2011 c Wed Apr 27 05:59:59 1988 < 1. > CMD: /usr/lib/sa/sa1 > sys 2021 c Wed Apr 27 06:00:00 1988 > CMD: /etc/dump/daydmp 2>&1 | /bin/mail root > root 2023 c Wed Apr 27 06:00:00 1988 < 2. really don't like to dump twice < sys 2021 c Wed Apr 27 06:00:03 1988 < root 2023 c Wed Apr 27 06:00:46 1988 < root 2011 c Wed Apr 27 06:02:34 1988 > CMD: /usr/lib/sa/sa1 > sys 2204 c Wed Apr 27 06:59:59 1988 < 1. > CMD: /usr/lib/sa/sa1 > sys 2207 c Wed Apr 27 07:00:00 1988 < 2. < sys 2204 c Wed Apr 27 07:00:00 1988 < sys 2207 c Wed Apr 27 07:00:01 1988 crontabs: # crontabs/sys 0 * * * 0-6 /usr/lib/sa/sa1 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A # crontabs/root ... 5 6 * * 2-6 /etc/dump/daydmp 2>&1 | /bin/mail root ... -------------------------------------------------------------------------- Urs Meyer, University of Zuerich, UUCP: mcvax!cernvax!unizh!meyer Computer Science Dept., 8057 Zuerich CHUNET: meyer@ifi.unizh.ch Switzerland ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07681; 27 Apr 88 15:18 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05733; 27 Apr 88 13:00 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05707; 27 Apr 88 12:52 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa03356; 27 Apr 88 12:41 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 27 Apr 88 09:41:06 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA23035; Wed, 27 Apr 88 06:01:57 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Apr 88 23:47:04 GMT From: Bob Toxen Organization: Stratus Computer, Inc., Marlboro, MA Subject: Re: Time Zones Message-Id: <330@cloud9.UUCP> References: <8804251412.AA00295@aero4.larc.nasa.gov> Sender: info-iris-request@sumex-aim.stanford.edu To: info-iris@sumex-aim.stanford.edu For System V (except where source code was hacked) you need to change the setting of the TZ environment variable from its default EST5EDT or PST8PDT to EDT4 or PDT7 for a month or so and then change it back so it will work for the "fall behind" later. Iterate until you get an new rev which has this fixed. You can put the fix in /etc/profile or $HOME/.profile for sh or /etc/cshrc or ~/.login for csh. -- Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob Stratus Computer, Marlboro, MA Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01161; 28 Apr 88 3:42 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00862; 28 Apr 88 2:27 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00855; 28 Apr 88 2:20 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.ARPA id aa01418; 28 Apr 88 2:13 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1280; Mon, 25 Apr 88 06:45:22 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 25 Apr 88 07:27:01 Date: Mon, 25 Apr 88 07:26:01 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: Kermit and GL-Questions To: info-iris@BRL.ARPA X-VMS-To: X%"info-iris@BRL.ARPA" Message-ID: <8804280213.aa01418@SMOKE.BRL.ARPA> Hello everybody, two questions: 1.) Did anybody out there manage to compile C-Kermit (4D(061)) on a 4D/70 with the 'make BSD' option in order to generate a Kermit that can do wildcard operations on NFS directories? I fail with a lot of compiler messages in ckutio.c and ckufio.c complaining about unknown structure tags. 2.) We have a 4D/70 with Rev. 2.0 software (versions tells me 4D1-2.0, and all installed products have a trailing 210 in their version-number). We have the problem that we can't close windows using the winclose gl routine. SGI tells this is a known problem and we should attach to the window before win-closing it. But that doesn't help. Any solutions? Which version of the gl-software will solve the problem? Is it available? Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt West-Germany BITNET: ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa09229; 28 Apr 88 16:42 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa06955; 28 Apr 88 14:04 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06916; 28 Apr 88 13:57 EDT Received: from RUTGERS.EDU by SMOKE.BRL.ARPA id aa15946; 28 Apr 88 13:41 EDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA18363; Thu, 28 Apr 88 12:13:31 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA01061; Thu, 28 Apr 88 11:07:32 EDT Received: by hombre.MASA.COM (smail2.5) id AA11459; 28 Apr 88 10:52:54 EDT (Thu) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA05705; Thu, 28 Apr 88 10:00:12 EDT Date: Thu, 28 Apr 88 10:00:12 EDT From: Rodian Paul Message-Id: <8804281400.AA05705@dasys1.UUCP> To: Info-Iris@BRL.ARPA Subject: Missing things?.. SGI gave me some help yesterday on the phone regarding a couple of minor fixes for the 4D series running Version 2.0 If you want to use the unix command 'newgrp' you need to do the following: su chown root /bin/newgrp chgrp sys /bin/newgrp chmod 4755 /bin/newgrp ( can't remember if that's right I'll check) If you don't do this 'newgrp' will say sorry and kick you off the system when you try to change groups. If you want 'calendar' to send you mail you need a short program that SGI forgot to distribute: /usr/lib/calnames. I'll post the source (it's only about 8 lines) if anybody wants it. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12180; 29 Apr 88 17:51 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10523; 29 Apr 88 16:07 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10509; 29 Apr 88 16:00 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00553; 29 Apr 88 15:55 EDT Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Fri, 29 Apr 88 12:55:13 PDT Received: from ai.toronto.edu by RELAY.CS.NET id aa01099; 29 Apr 88 15:04 EDT Received: from csri.toronto.edu by ai.toronto.edu via ETHER with SMTP id AA17304; Fri, 29 Apr 88 15:03:49 EDT Received: from alias by csri.toronto.edu via phone with UUCP id AA21406; Fri, 29 Apr 88 14:59:30 EDT Message-Id: <8804291859.AA21406@csri.toronto.edu> Received: by alias.uucp (4.12/celerity) id AA12315; Fri, 29 Apr 88 11:54:40 edt Date: Fri, 29 Apr 88 11:54:40 edt From: Kevin Tureski To: info-iris@sumex-aim.stanford.edu Subject: Re: Problems with cron Has anybody noticed [that cron tends to run things twice]? What can be done to get around it? Our environment: 4D/70G, Unix Release 4D1-2.0 Urs Meyer Yes, we've noticed it and complained about it. The answer: wait for 3.0. Now we've got 3.0 (an early VAR release) and the problem has disappeared. In the meantime, you might consider a simple lockout mechanism for your own commands that are to be run via the crontab. If you're not sure whether cron is running things twice, then try the following entry in a crontab: 00,10,20,30,40,50 * * * * date >> /tmp/date Kevin Tureski Alias Research Inc. 110 Richmond St E. Toronto Canada M5C 1P1 416 362-9181 UUCP: {allegra,ihnp4,watmath!utai}!utcsri!alias!ktureski ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa16356; 30 Apr 88 13:34 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16238; 30 Apr 88 12:00 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16236; 30 Apr 88 11:51 EDT Received: from uunet.UU.NET by SMOKE.BRL.ARPA id aa11104; 30 Apr 88 11:39 EDT Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA09732; Sat, 30 Apr 88 11:38:48 EDT Message-Id: <8804301538.AA09732@uunet.UU.NET> Received: from godzilla.me.rmit (via goanna) by munnari.oz with SunIII (5.5) id AA25127; Sun, 1 May 88 00:41:19 EST Received: by godzilla.me.rmit.oz (5.15/4.7) id AA05244; Sat, 30 Apr 88 14:09:59 PDT Date: Sat, 30 Apr 88 14:09:59 PDT From: Bernard Kirby To: info-iris@BRL.ARPA Subject: Woof woof Now that we have more than one IRIS on a network (One 4D one 3130 and one 3120), we would like to take full advantage of the demonstration potential offered by the "dog" program :-) The problem is that dog fails with an "Ethernet init failed" message on the 3100 machines and a "Can't find broadcast udp service dog" on the 4D. Can anyone PLEASE tell us what we have to do to make dog work over the ethernet? We are running TCP/IP on all machines. Bernie Kirby. bernie%cidam.oz.au@uunet.uu.net bernie%godzilla.me.rmit.oz.au@uunet.uu.net ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11646; 3 May 88 14:32 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11444; 3 May 88 14:22 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11367; 3 May 88 14:11 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa19247; 3 May 88 14:04 EDT Received: Tue, 3 May 88 14:09:17 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Tue, 3 May 88 14:09:17 EDT From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8805031809.AA06164@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Color Printers Cc: blbates@aero4.larc.nasa.gov Has any one heard of a company called Howtek? They have a color printer, called a Pixelmaster, with 240dpi resolution and uses plain paper. Has anyone seen, used, or heard of these printers before. We are thinking of getting a Pixelmaster and using it as a color hard copy device for our Iris. We are trying to find out what current owners think of them and what software they have for it. Thanks for any information you may have. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa16952; 4 May 88 7:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16415; 4 May 88 6:06 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16388; 4 May 88 5:53 EDT Received: from aero2.larc.nasa.gov by SMOKE.BRL.ARPA id aa28615; 4 May 88 5:53 EDT Received: Wed, 4 May 88 05:53:56 EDT by aero2.larc.nasa.gov (5.52/5.17) Date: Wed, 4 May 88 05:53:56 EDT From: TAD system manager Message-Id: <8805040953.AA21294@aero2.larc.nasa.gov> To: blbates@aero4.larc.nasa.gov, info-iris@BRL.ARPA Subject: Re: Color Printers Cc: fox@aero2.larc.nasa.gov Howtek and its products are covered in the May 1988 issue of Computer Graphics World magazine. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01241; 4 May 88 14:44 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21865; 4 May 88 11:36 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21830; 4 May 88 11:23 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05996; 4 May 88 11:19 EDT Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 4 May 88 08:20:38 PDT Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Wed, 4 May 88 07:23:07 PDT Date: Wed, 4 May 88 07:23:07 PDT From: PEPKE%FSU.MFENET@nmfecc.arpa Message-Id: <880504072307.21200215@NMFECC.ARPA> Subject: RE: Animation! To: info-iris@sumex-aim.stanford.edu.arpa Comment: From PEPKE@FSU.MFENET on 4-MAY-1988 10:22:01.40 EDT X-ST-Return-Receipt-Requested: Brodie Lockard writes: > es1o+@andrew.cmu.edu (Eric Mitchell Snider) writes: >> Ok, here's another problem I'd like some help with. I'm working on >>a program where several small objects move around in front of a >>background. The problem is I don't know a good way to replace the >>background after my objects have been erased and moved. At the moment >>everything (including the background) is a separate picture (PICT) >>resource. What do I need to do?!? > A typical algorithm used for animation like you mentioned is to > 1. Figure out where you're first going to draw the foreground (the > thing being moved), and save what's there (call this "Under"). > 2. Draw your foreground where it belongs. > 3. Whenever your object moves, > A. Redraw Under where it came from. > B. Figure out where you're first going to draw the foreground, > and save what's there in Under again. > C. Draw your foreground in the new place. I have an application which involves a variable number of objects (typically a half dozen or so) moving around in 3-space. My first attempt was similar to what Brodie describes, but I found it to be too slow, especially as all the special cases that test for objects moving in front of each other adds code. What I instead adopted was a simpler approach which lends itself to some good optimizations. For each object on the screen (including the background) I keep an offscreen bitmap and mask (if it's not rectangular). Every time I want to emit a frame, I copy the bitmaps from back to front. When objects move, all you have to do is change the position at which you copy the bitmaps. When the pictures of objects change, you have to redraw the PICTs into the bitmaps and possibly change the size of the bitmaps. All the redrawing is done into an off-screen bitmap, which is then CopyBitsed onto the screen. Now for the optimizations: The off-screen bitmap has no regions to deal with, so CopyBits is much faster. In some cases you don't even need to do a CopyBits. For example, if you ensure that the background has the same bounds and rowBytes as the off-screen bitmap, you can simply use BlockMove or a tight assembly loop to put the background down. For the other objects that don't move very often, ensure that the CopyBits will start on a word boundary. You might even consider keeping 16 preshifted bitmaps around for small objects. I can think of many more optimizations that I am too lazy to implement, and you probably can too. My application has to do massive amounts of other work per frame including sorts, editing heierarchies, environment searches, et cetera, but even so, I saw almost an order of magnitude speed improvement. With tighter and simpler code you will probably see a greater improvement. Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University "You're living in your own private Idaho Tallahassee, FL 32306-4052 On the ground like a wild potato." Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00191; 5 May 88 12:49 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03989; 5 May 88 11:11 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa03987; 5 May 88 11:01 EDT Date: Thu, 5 May 88 11:02:27 EDT From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: rotated fonts Message-ID: <8805051102.aa03897@TBD.BRL.ARPA> I have written some FORTRAN subroutines which rotate character strings. They are charup, chardn, and charud, and are called in the same manner as charst. They write vertically upward, downward, and horizontally upside down, respectively. I'll e-mail the sources to anyone who is interested. Is there a volunteer to convert them to C and Pascal? Glenn Randers-Pehrson ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04370; 5 May 88 22:10 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03893; 5 May 88 19:44 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03891; 5 May 88 19:40 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09673; 5 May 88 19:35 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 5 May 88 16:36:30 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA03813; Thu, 5 May 88 15:26:09 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 88 14:31:30 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Sample Programs using Lighting Models Message-Id: <49@etl.ARPA> Sender: info-iris-request@sumex-aim.stanford.edu To: info-iris@sumex-aim.stanford.edu Does anyone have any programs, including source code, that demonstrate the use of lighting models (lighting models as described in Graphics Library User's Guide, Chapter 14, Lighting Models) on SGI IRIS 4D/60T? The programs liquid, light, and sdisp appear not to use these facilities. Please, please, correct me if I am wrong or, better yet, explain how these programs work. Obviously, I am trying to teach myself about lighting. Thanks. -- Richard Rosenthal | ARPANET: richr@etl.arpa US Army Engineer Topographic Laboratories | UUCP: ??? Ft. Belvoir, VA 22060-5546 | PHONE: +1 202 355 2830 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04575; 5 May 88 23:04 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04541; 5 May 88 22:54 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab04453; 5 May 88 22:42 EDT Received: from USNA.MIL by SMOKE.BRL.ARPA id aa10781; 5 May 88 22:30 EDT Date: Thu, 5 May 88 22:28:59 EDT From: "David F. Rogers" To: richr@etl.arpa cc: dfr@usna.mil, info-iris@BRL.ARPA Subject: lighting models Message-ID: <8805052228.aa04073@CAD.USNA.MIL> G'day Dick, Please do not construe this as commercial. I can suggest three places of increasing completeness to learn about lighting models. 1. Procedural Elements for Computer Graphics by David F. Rogers, McGraw-Hill 1985, ISBN 0-07-053534-5. Chapter 5 is what you want. Hopefully your library has it. 2. Roy Hall's paper in Techniques for Computer Graphics, `Color Reproduction and Illumination Models' pp 194-238, 1987, Editors David F. Rogers and Rae A. Earnshaw, ISBN 0-387-96492-4 and ISBN 3-540-96492-4. 3. There is a new book by Roy Hall on illumination models. Publisher is Springer-Verlag. Publication sometime this summer. Title is not totally decided on but should be something like `Illumination Models ...' Again, I am involved. This is the most complete and detailed source on illumination models for computer graphics. There is even code in the book. And lots of good color plates showing the differences between models! Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA Tel: 301-267-3283/4/5 ARPANET: dfr@usna.mil UUCP: ~uunet.uu.net!usna!dfr ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12727; 6 May 88 16:00 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11204; 6 May 88 14:16 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11166; 6 May 88 14:05 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa13448; 6 May 88 13:44 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 6 May 88 10:43:50 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA16329; Fri, 6 May 88 03:53:11 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 88 10:21:51 GMT From: "Dr. Michael M. Cohen" Organization: Univ. of Calif. - Santa Cruz, Program in Exp. Psychology Subject: composite video encoders Message-Id: <3167@saturn.ucsc.edu> Sender: info-iris-request@sumex-aim.stanford.edu To: info-iris@sumex-aim.stanford.edu I'm looking for a inexpensive RS170A RGB-> composite encoder for a 3030. Saw an ad for a TEL-ENC-1G from Communications Specialties Inc, of Commack, NY which costs $395. Anyone know anything about this unit? Could I use a monitor with RGB in-composite out (e.g SONY PVM1271Q) for this purpose? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14381; 6 May 88 23:36 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa14089; 6 May 88 22:01 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa14083; 6 May 88 21:57 EDT Date: Fri, 6 May 88 21:53:43 EDT From: Phil Dykstra To: info-iris@BRL.ARPA Subject: Vanishing .rhosts problem Message-ID: <8805062153.aa21638@SPARK.BRL.ARPA> Is anyone out there familiar with the vanishing .rhosts problem? Description: Running with an NFS mounted home directory, rloging into or rcping to a 3030 or 4D, every once in a while the .rhosts file vanishes. The file entry is still there - ls even shows its original (correct) length - but if you try to cat it nothing comes out. Examining more closely you find that the open on the file works, but the first read fails with "permission denied." A local "stat" of the file shows the correct owner and permissions though. It is as if either the client or server forgot who you are (uid wise). It is rumored that SGI has seen and fixed this problem, but not yet released the fix. Is there someone out there that knows why this happens, or what has/had to be done to fix it? - Phil ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15843; 7 May 88 8:35 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15566; 7 May 88 7:11 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15544; 7 May 88 7:00 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa25353; 7 May 88 6:58 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04053; Fri, 6 May 88 19:22:33 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 88 09:08:34 GMT From: uucp Organization: Unexsys Systems, Edmonton,AB. Subject: Non-standard drives on a 3030 Message-Id: <3089@edm.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Hi: We've currently got a 3030 with two 170MB ESDI drives, and need more space. As it happens, I know someone who is willing to give us a trade-in for one of our 170s if we buy a 380 from them. Has anyone done something like this? do you know of any problems with this? (SGI's "support" people took the fifth when I started asking questions about this). We really could use the extra space, but buying an eagle is out of the question ($$), and SGI isn't likely to have an official 300MB drive for some time yet. -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00952; 7 May 88 15:25 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00871; 7 May 88 14:12 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00866; 7 May 88 14:05 EDT Received: from [128.186.3.1] by SMOKE.BRL.ARPA id aa27906; 7 May 88 14:03 EDT Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA07360; Sat, 7 May 88 14:04:48 EDT Date: Sat, 7 May 88 14:04:48 EDT From: "John D. McCalpin" Message-Id: <8805071804.AA07360@masig1.ocean.fsu.edu> To: info-iris@BRL.ARPA Subject: NFS trouble I have had repeated trouble with an NFS problem that sounds suspiciously like the "vanishing .rhosts" problem just reported by phil@brl.arpa. I have a 3030 and a 3130, with most of the 3130's /usr partition mounted on the 3030. When working on the 3130 (client), but accessing the 3030 (server) disk, I find that interrupting a program that is writing to a file on the server often causes that file be be made permanently unavailable to the client. The directory listing is fine, but cat returns nothing. I have to re-start the nfs daemons to get access to the file again. The file is perfectly accessible from the server machine side. This is extremely frustrating. Unfortunately, it gets worse.... When I interrupt a Make (for example) in the few fractions of a second during which it is loading an executable (like a compiler) from the server, I find that that file becomes inaccessible as well! When I try to access it again, I get the message "Interrrupted System Call", and again have to re-start the nfs daemons.... Have other people seen this trouble ??? john mccalpin mccalpin@nu.cs.fsu.edu mccalpin@masig1.ocean.fsu.edu P.S. All this is not to mention the fact that I still cannot cp a large file between machines without having it occassionally corrupted. It is pretty silly to tell all the users that they do not need to pay any attention to what machine a file is on, unless it happens to be bigger that about 1MB, in which case they have to use rcp to copy it!!! SGI has told me that this is a known bug with no known fix --- great!.... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01700; 8 May 88 0:28 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01576; 7 May 88 23:26 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01574; 7 May 88 23:24 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00193; 7 May 88 23:20 EDT Received: from rutgers.edu by SUMEX-AIM.Stanford.EDU with TCP; Sat, 7 May 88 20:20:50 PDT Received: by rutgers.edu (5.54/1.15) with UUCP id AA21748; Sat, 7 May 88 19:28:53 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA11882; Sat, 7 May 88 17:50:27 EDT Received: by hombre.MASA.COM (smail2.5) id AA00587; 7 May 88 16:03:11 EDT (Sat) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA15323; Sat, 7 May 88 11:56:52 EDT Date: Sat, 7 May 88 11:56:52 EDT From: Rodian Paul Message-Id: <8805071556.AA15323@dasys1.UUCP> To: info-iris@sumex-aim.stanford.edu, psych36@ucscc.ucsc.edu Subject: Re: composite video encoders Just about any encoder should be better than the $1.50 encoder chips that SGI uses. Be warned though, even if you have the gen-lock option, SGI machines never output broadcast quality NTSC video. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14412; 9 May 88 22:28 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14201; 9 May 88 21:15 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa14199; 9 May 88 21:11 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa28833; 9 May 88 21:05 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA20554; Mon, 9 May 88 01:41:32 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 88 11:22:20 GMT From: "Dr. Michael M. Cohen" Organization: Univ. of Calif. - Santa Cruz, Program in Exp. Psychology Subject: Re: composite video encoders Message-Id: <3206@saturn.ucsc.edu> References: <8805071556.AA15323@dasys1.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <8805071556.AA15323@dasys1.UUCP> rpaul@dasys1.UUCP (Rodian Paul) writes: .Just about any encoder should be better than the $1.50 encoder chips .that SGI uses. Be warned though, even if you have the gen-lock option, .SGI machines never output broadcast quality NTSC video. Pardon my ignorance, but WHAT $1.50 encoder chips? Do you mean that the 3030 already puts out composite video? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03058; 11 May 88 8:06 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01906; 11 May 88 6:43 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01883; 11 May 88 6:34 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa02544; 11 May 88 6:24 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09912; Wed, 11 May 88 03:08:27 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 88 06:35:00 GMT From: Adam Alexander Margulies Organization: Universiy of California, Santa Cruz Subject: fun font for the irises Message-Id: <3252@saturn.ucsc.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA The following is a uuencoded font for the irises. You can load it using the "loadfont" utility. To unpack it, simply strip any extraneous text before the "begin" command and after the "end" command. The use uudecode to restore the font file. Have fun, and I hope that you will mail me and tell me what you think. begin 600 lemonade.fnt M 0^0 $/D $ " \T D! "0 !"0$ ) () 0 D PD! M"0 $"0$ ) 4) 0 D !@D! "0 '"0$ ) @) 0 D "0D! M "0 *"0$ ) L) 0 D # D! "0 -"0$ ) X) 0 D M#PD! "0 0"0$ ) !$) 0 D $@D! "0 3"0$ ) !0) 0 M D %0D! "0 6"0$ ) !<) 0 D & D! "0 9"0$ ) !H) M 0 D &PD! "0 <"0$ ) !T) 0 D '@D! "0 ?"0$ ) M " ) 0 D (0D* "0 K"00 !@ ) "\)"@ D .0D, /\ "0!%"0H M ) $\)"@ D 60D$ 8 "0!="0T _@ ) &H)#0#^ D =PD( ( "0!_ M"0< 0 ) (8)!0#] D BPD! 0 "0","0( ) (X)# D F@D* ( M"0"D"0L 0 ) *\)# ! D NPD- "0#("0L 0 ) -,)"P ! D W@D, M /\ "0#J"0P _P ) /8)#@#^ D!! D- /X "0$1"0< ) 1@)"@#] D! M(@D+ $ "0$M"04 P ) 3()"P ! D!/0D* $ "0%'"0H 0 ) 5$)"P M D!7 D* $ "0%F"0L 0 ) 7$)# D!?0D* ( "0&'"0L 0 ) 9() M# ! D!G@D, /\ "0&J"0L 0 ) ;4)"P ! D!P D. /T "0'."0H 0 ) M =@)"P ! D!XPD* ( "0'M"0H 0 ) ?<)#0#_ D"! D, /\ "0(0"0H M 0 ) AH)# ! D")@D, /\ "0(R"0L ) CT)"P D"2 D* "0)2 M"0P ) EX)"P ! D":0D+ $ "0)T"0T _P ) H$)# D"C0D- /\ M"0*:"0, !P ) IT) 0 D"G@D$ < "0*B"0@ P ) JH)# D"M@D) M "0*_"0L @ ) LH)!P " D"T0D* $ "0+;"0L _@ ) N8)# ! D" M\@D* $ "0+\"0P _P ) P@)"P ! D#$PD- /\ "0,@"0< @ ) R<)!P ! M D#+@D' $ "0,U"0T _0 ) T()# #] D#3@D( $ "0-6"0@ @ ) UX) M"P ! D#:0D' ( "0-P"0< @ ) W<)!P " D#?@D) $ "0.'"0L _0 ) M Y()!@ % D#F D- /\ "0.E"0T _P ) [()"P ! D#O0D# < "0/ "0T M_P ) M $ $ 0 !@ " 8 ! $ D M "0 $@ D $@ 2 !( /X ) D '\ $@ 2 !( $ X %0 5 4 !@ , !0 %0 M5 X ! 3 !2 #( + 0 ! : "8 )0 9 !F )@ B ", %( ( P $@ 2 P M " $ ( @ ! ( ! $ @ " ( @ " $ 0 @ ! @ ! " ( 0 M! $ 0 ! ( @ $ @ " $ !4 #@ . !4 ! " 0 ! $ #^ ! $ 0 M " $ ( !@ & !^ # , " $ 0 @ " $ 0 @ " $ 0 @!\ ,( MP0#A *$ D0"9 (T QP!^ #X # , @ " ( !@ " ( #@ & !G 'P 6 !\ M 0 !@ " , 00!! #, '@!\ ,0 P@!# , P!^ #P !@ " (, Q@!X @ M& 8 @ ?@!( "@ * 8 !@ " 8 /P @ " ( 0@#, +@ P ! 'P #@ [ M &$ \0"1 (\ P # , 0 !B #X 0 !@ # $ 8 @ #0 $ 8 @ & '\ M# ^ $, 00!A "$ /@!L $( 0@"" $( 9@ \ " ( P ! $ 8 @ ' !\ M (0 Q@!" 'X & 8 !@ & @ ! " 8 !@ & 8 ( M! ( ! ( ! " $ ( 0 @!^ 'X 0 @ ! " $ ( ! ( M ! ( ! @ @ " $ ( 0@!" #P ' B $ 3 !2 %( 3@!" "0 M& "" (, Q@#^ &X ; !L "@ * X !@ 8 !^ (( @@"& (P ^ #( ,@ > ^ M &( P@" ( @ " ( 1@!L #@ ? !& $$ 00!! $$ 00!C $( 8@!\ #@ M/@!@ $ 0 !$ 'P 8 @ # '@! $ 0 ! $ 0 !\ &( ( !@ 'X /@!# M ,$ @0"? ( @ " , 0 !R !P 1 !$ $0 A "$ &0 ? !$ $0 1 !& $( M_@ @ " ( P ! $ 0 ! _@ 4 '@ 3@!& $( 0@ " ( !@ & !\ #P! M $ $( 1@!$ $P 2 !H '@ < !< $8 P #_ , 0 ! $ 0 ! $ M0 "" (( L@"Z *H J@#J ,H 3@!& ( @@#" .( L@"2 )H B@!& ,8 @ ^ M ', 80!! $$ 00!C ", (@ ? $ 0 ! $ 0 ! '\ 00!# ,( P@#& /P M!@ $ 'X :@!* %H 0@!" $( 8@!F 'P (@!B &8 1 !( 'P 0@#$ ,8 _ ^ M $, 00!# < ' !@ $ 00!# 'X " 8 @ " ( !@ " 0 ! $ 0 %< M^ !X $0 0@!" $, 0P!" $( @@!" $( $ P #@ * H "@ 1 !$ ,0 A "& M "0 ) !D &X :@!Z %H F@"; ($ PP!" $0 * X !@ , H $0 1 "& (( M$ 8 ! $ 0 !@ * !D $8 P@"" 'X 0 ! ' & , 8 @ " 'X _@ \ M " ( @ " ( @ " ( P ! $ < ( ! $ @ " 0 ! ( @ $ M0 " #@ " ( P ! $ 0 ! $ 0 ! $ #P 0@ D !@ _@ ( ! ( @ M &0 7 !, $@ > 8 ' , !8 '8 8P A "$ (P!^ $P 0 ! $ 0 X 'P MP " ( P@!B #P " ( #P ; !D $0 9 D #X @ " ( ' P " ? !& M &8 / @ # $ 0 % / 0 ! , < #P (@ R ( @!Z $X 1@!D #8 M' !@ &( 8@!B &( 8@!T %@ 0 ! $ 0 8 !@ & 0 ! & ( ' < M #@ : !, 0 ! , 0 ! $ # , &( 9 !$ &@ > P "@ ) D & M0 , !@ " ( !@ $ 0 ! & ( @ & P $D 20!) &L ?@!T ( (@ B M "( 9@!D &0 7 < &8 Q@#" $0 ? \ $ 8 !@ $ 0 !@ 'X 8@!" $$ MP@!B #X P " ( @ " #( _@"& (8 Q@!B #P 8 !@ & 8 !@ & =@"< M '@ S #$ P $ @ #0 ' ( !@ $ 0 ! $ !0 'P % 0 # .@!. (8 MA@#& $8 1@ 0 "@ 2 !$ $8 PP" &@ ? !6 )( D@"2 (( P@!F #P & X M &0 1 "" ( 8 !P # $ 0 !@ & X &0 0@!" 'X ! ( ! ( !_ X M$ @ " $ 0 & $ 0 @ " 0 X $ 0 " ( 0 ! 0 ! " ( M ! $ X 0 " ( 8 " ( 0 ! ( ' 3 !: #( !@ ) D "0 ) 8 . "0 ) X "0 ) X end I said, type it NOW, Adam! || ||Adam Margulies | \ ||_ /| ||ARPA: vespa@ucscb.ucsc.edu | ||\`o_O' ||BITNET: vespa@ucsci.BITNET | || ( ) ||UUCP: ...!ucbvax!ucscc!ssyx!vespa | ----------------------------||--mU-m-||WEIRD:vespa%ssyx.ucsc.edu@RELAY.CS.NET | |DISCLAIMER: ||ATT: (408)429-8868 | | These are NOT my opinions. They are my dog's. | ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01187; 12 May 88 0:44 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00869; 11 May 88 23:00 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00814; 11 May 88 22:44 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa02133; 11 May 88 22:14 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA24645; Wed, 11 May 88 18:14:40 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 88 18:22:45 GMT From: Rodian Paul Organization: The Big Electric Cat, NYC, NY Subject: SGI IRIS for sale Message-Id: <4393@dasys1.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA For sale: Silicon Graphics IRIS 2400 Turbo, 24 bit planes 2 380 meg Fujitsu Eagle Drives plus other odds and sods. Asking: 35K or best offer. Contact: Jeff Marvin (212) 664-9414 -- Rodian Paul Big Electric Cat Public UNIX ..!cmcl2!phri!dasys1!rpaul ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01573; 12 May 88 3:15 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01394; 12 May 88 1:41 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01325; 12 May 88 1:30 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa03403; 12 May 88 1:17 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA27014; Wed, 11 May 88 20:20:19 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 88 20:45:31 GMT From: Vince Pugliese Organization: Engineering Computing Facility, University of Toronto Subject: displaying rgb on an IRIS Message-Id: <613@mv03.ecf.toronto.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA i was hoping some kind sgi user out there could help me with the following: i have a file containing rgb values for pixels on a screen and i wish to display them on an IRIS. essentially what i have done is translated an image into a more "portable" format that consists of # of pixels red_value green_value blue_value # of pixels red_value green_value blue_value and so on. since i don't regularly use IRIS' i'm not familiar with how to do this sort of thing so I was hoping that someone had a "short(?)" program that would take this data and display it. thanks in advance vince pugliese apollo@ecf.toronto.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08916; 14 May 88 0:10 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa08437; 13 May 88 21:54 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa08435; 13 May 88 21:48 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa14404; 13 May 88 21:37 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA28159; Fri, 13 May 88 14:54:51 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 May 88 19:25:50 GMT From: josh Organization: Los Alamos National Laboratory Subject: NeWS for sgi... Message-Id: <14296@hc.DSPO.GOV> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Does anybody know when NeWS/Foursight (sp?) is shipping? -- Josh Siegel (siegel@hc.dspo.gov) I like using a C-47A "puff dragon" to go hunting with. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11983; 15 May 88 3:14 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11790; 15 May 88 1:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11777; 15 May 88 1:38 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa22666; 15 May 88 1:33 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA21192; Sat, 14 May 88 20:53:53 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 88 15:16:53 GMT From: Larry Grose Organization: Camax Systems Inc, Minneapolis, MN Subject: Re: Sample Programs using Lighting Models Message-Id: <168@camax01.UUCP> References: <49@etl.ARPA> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA A warning concerning SGI's implementation of their lighting model. In order to differentiate between when transformations are intended to modify just the model and when they are intended to modify both the model and the lights, they have added an mmode() call, which is described in section 14.4 of the Graphics Library User's Guide. It claims that the calls perspective, window, ortho, and ortho2 work under both MVIEWING and MPROJECTION modes. However, when I was out at their headquarters porting to the GT and scratching my head over why my lighting model code no longer worked (normals appeared to be reversed), I talked to one of their software gurus, who helped implement the lighting model for the GT. He pointed out I wasn't using MPROJECTION mode with the above calls and I pointed him to SGI's documentation. He politely said 'ouch', and admitted that it was wrong for the GT (ie, perspective, window, ortho, and ortho2 must be used under MPROJECTION mode only). Unfortunately, the buck apparently stopped there, because the new documentation that came with 3.0 still has the same error. In the 4 examples provided in section 14.6 for using mmode, only the first one will work on the GT (all 4 work for non-GT's). To the best of my knowledge, the rest of the lighting model documentation is correct, though admittedly it is not very tutorial in nature. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22530; 16 May 88 15:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21090; 16 May 88 13:15 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21079; 16 May 88 13:03 EDT Received: from orville.nas.nasa.gov by SMOKE.BRL.ARPA id aa12323; 16 May 88 12:56 EDT Received: Mon, 16 May 88 09:57:05 PDT by orville.nas.nasa.gov (5.54/1.2) Date: Mon, 16 May 88 09:57:05 PDT From: "David A. Tristram" Message-Id: <8805161657.AA16213@orville.nas.nasa.gov> To: info-iris@BRL.ARPA, siegel@hc.dspo.gov Subject: Re: NeWS for sgi... I don't know when it will be shipping, but we have been running beta versions of the NeWS server on 4d's for about a month. Before then the mex emulation mode (now called "max") was not happening. Now, max is pretty good for non- demanding applications, but can be hosed by really flipping windows around or be creating a huge number of windows. The source release, by the way, builds pretty nicely, compared with earlier sgi releases. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24170; 16 May 88 18:50 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23460; 16 May 88 16:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23450; 16 May 88 16:42 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16696; 16 May 88 15:33 EDT Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Mon, 16 May 88 12:23:38 PDT Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Mon, 16 May 88 11:56:25 PDT Date: Mon, 16 May 88 11:56:25 PDT From: PEPKE%FSU.MFENET@nmfecc.arpa Message-Id: <880516115625.20600216@NMFECC.ARPA> Subject: Flex Bug To: info-iris@sumex-aim.stanford.edu.arpa Comment: From PEPKE@FSU.MFENET on 16-MAY-1988 14:54:57.79 EDT X-ST-Return-Receipt-Requested: I installed the Flex INIT/cdev on my color Mac II, and it produced some strange results. Sometimes, when I leave the Flex display with a VersaTerm pro window on top, the next occasion that the terminal scrolls, it scrolls right up through the title bar and into (and perhaps through) the menu bar. Once, the top line that had been scrolled into the menu bar appeared in Chicago rather than pseudo-Monaco. One of my office mates had a similar problem with Flex and MacTerminal. So, we both removed the file from our systems. Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University "You're living in your own private Idaho Tallahassee, FL 32306-4052 On the ground like a wild potato." Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10042; 19 May 88 14:49 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa08744; 19 May 88 12:33 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa08612; 19 May 88 12:14 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa16751; 19 May 88 12:00 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa11614; 19 May 88 9:02 PDT Date: Thu, 19 May 88 9:00:42 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: system V ct ... Message-ID: <8805191200.aa16751@SMOKE.BRL.ARPA> Has anyone managed to get the 'ct' command to function on the 4D? I keep getting a "NO 1200 BAUD DIALERS ON THIS SYSTEM" error, even though I have a correct entry in the Devices file : "Direct ttyd4 - 1200 direct", which seems to allow 'kermit' and 'cu' to function. If I have left anything out, please let me know. Thanx. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12210; 19 May 88 18:01 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12085; 19 May 88 17:50 EDT Received: from brl-vgr.arpa by VMB.BRL.ARPA id ac12047; 19 May 88 17:45 EDT Received: by VGR.BRL.ARPA id be00138; 19 May 88 17:41 EDT Date: Wed, 18 May 88 22:52:19 EDT From: Mike Muuss To: CAD@BRL.ARPA cc: Info-Iris@BRL.ARPA Subject: Shifts on 4-D Message-ID: <8805182252.aa07032@VGR.BRL.ARPA> I just discovered that on the SGI 4-D, negative shifts on (at least) variables declared "register unsigned" don't work. It would appear that perhaps such a shift is being interpreted as a large positive shift. At any rate, the values always came up zero in the low byte. I wouldn't ordinarily write code that does this sort of thing -- this particular piece of code was something that somebody else had written quite a while ago, and I just chose this evening to port it to the 4-D. On the other hand, the VAX and the Gould and probably many other machines all permit negative shifts, so this seems like something that other folks may encounter. K&R are silent on this point (ref: pages 44, 189). No help there. So, I'm not asking that this be fixed, just surfacing it as an issue for others to watch out for. The upshot of this is that CAT-FB (a port of Ron Natalie's ICAT program) now runs on the 4D, and very quickly. It takes TROFF output and "typesets" it into the current framebuffer, using the vfont bitmaps. Very nice for making slides. -Mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14505; 20 May 88 6:02 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab14399; 20 May 88 5:51 EDT Received: from brl-vgr.arpa by VMB.BRL.ARPA id ab14386; 20 May 88 5:37 EDT Date: Fri, 20 May 88 5:35:33 EDT From: Doug Gwyn (VLD/VMB) To: Mike Muuss cc: CAD@BRL.ARPA, Info-Iris@BRL.ARPA Subject: Re: Shifts on 4-D Message-ID: <8805200535.aa02005@VGR.BRL.ARPA> > K&R are silent on this point (ref: pages 44, 189). K&R second edition p.206: The result is undefined if the right operand is negative, ... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00448; 24 May 88 21:49 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00425; 24 May 88 21:38 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00416; 24 May 88 21:26 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa00633; 24 May 88 21:13 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA14333; Tue, 24 May 88 11:32:05 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 88 15:45:07 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: VCL and EDT for 4D Message-Id: <893@virginia.acc.virginia.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I am extremely interested in obtaining two software products from a company called Boston Business Computing (Lawrence, MA). These products are VCL and EDT for the 4D series machines. VCL is a VMS like shell and EDT is the VAX-VMS editor. The problem is that BBC does not want to port the software to the silicon graphics machine unless there is a demand. Since most of our users are from VAX-VMS I want to get these products to help them get onto the SG machine. If anyone else thinks that they might be interested, please let me know and also let Silicon Graphics know. Maybe if enough of us want the product we can motivate SG. Thanks. (804)-924-2496 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00463; 24 May 88 21:59 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00252; 24 May 88 20:21 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00237; 24 May 88 20:10 EDT Received: from [36.2.0.98] by SMOKE.BRL.ARPA id aa00376; 24 May 88 20:01 EDT Received: by sierra.STANFORD.EDU (3.2/4.7); Tue, 24 May 88 16:56:19 PDT Date: Tue 24 May 88 16:56:18-PDT From: "Lloyd J. Lacomb" Subject: mandrill and fft To: info-iris@BRL.ARPA Cc: lacomb@sierra Message-Id: <580521378.0.LACOMB@SIERRA> Mail-System-Version: I need to see if anyone out there has or knows where I can get a couple of things. The first thing is an 8 bit version of the standard mandrill image either in color or in grayscale. The second thing I need to find out is does anyone have or know where there is a public domain FFT program written in C with the following attributes: 1) handles arbitrary number of dimensions 2) handles arbitrary number of points along any dimension 3) uses conjugate symmetries to imporve speed I have a public domain routine written by Norman Brenner in trusty old FORTRAN but I'm getting tired of using wrappers and having to have the main routine in FORTRAN so I'd like to have a C routine that is as good as my old routine but without all the interlanguage hassles. Thanks Lloyd LaComb lacomb@sierra.stanford.edu ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01175; 25 May 88 1:48 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00981; 25 May 88 1:35 EDT Received: from sem.brl.mil by VMB.BRL.ARPA id aa00956; 25 May 88 1:21 EDT Date: Wed, 25 May 88 1:10:30 EDT From: Mike Muuss To: "Lloyd J. Lacomb" cc: info-iris@BRL.ARPA, lacomb@sierra Subject: Re: mandrill and fft Message-ID: <8805250110.aa01691@SEM.BRL.ARPA> vgr.brl.mil:images/mandrill.pix.Z -- that is our image exchange area. Contact about the FFT program. He is traveling, and will return on 9-June. -Mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01728; 25 May 88 5:22 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01690; 25 May 88 5:11 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01688; 25 May 88 5:07 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa03484; 25 May 88 4:52 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA21164; Tue, 24 May 88 17:54:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 88 21:07:48 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: Large capacity backup devices Message-Id: <894@virginia.acc.virginia.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Does anyone know of a large capacity (>500 Mbyte) backup device that can be installed on a 4D/70? At first I thought that an Exabyte drive would be nice since it has a SCSI interface, but we have not been able to find anyone who has installed this drive on a 4D. It is however interesting to note that I know of one vendor who wants to install this drive on a 4D, but has been unable to interest Silicon Graphics in the project. If anyone out there beside me is interested in this type of an item maybe we should "send a petition" to silicon graphics and request such an item. (804)-924-2496 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11354; 25 May 88 17:30 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09496; 25 May 88 15:32 EDT Received: from [128.196.6.1] by VMB.BRL.ARPA id aa09292; 25 May 88 15:25 EDT Received: by megaron.arizona.edu; Wed, 25 May 88 10:30:29 MST Received: by uazchem.SGI (5.15/5.6) id AA05972; Wed, 25 May 88 10:28:46 PDT Date: Wed, 25 May 88 10:28:46 PDT From: uazchem!dolata@arizona.edu (Dolata) Message-Id: <8805251728.AA05972@uazchem.SGI> To: arizona!info-iris%brl-vmb.arpa@arizona.edu Subject: EDT for IRIS'es EDT for IRIS'es. I have a hack for you... GNUEMACS is up and running on IRISes (IRII?), and has an EDT simulation mode. Since GNUEMACS is to EDT as an IRIS is to a Tek-4010 scope, this has the following advantage; as you users become more proficcient with GNUEMACS they can use the extra capabilities, and increase thier productivity. GNUEMACS is distributed free, which is another big advantage. Dan ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12449; 25 May 88 22:44 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12418; 25 May 88 22:34 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12379; 25 May 88 22:25 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa24350; 25 May 88 22:13 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04898; Wed, 25 May 88 10:24:45 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 88 14:55:50 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: GNUemacs Message-Id: <897@virginia.acc.virginia.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Does anyone know where I can get GNUemacs with EDT emulation to run on a 4D system? I could do the port, but someone else probably already has. Thanks for the info. (804)-924-2496 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12735; 26 May 88 0:06 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12633; 25 May 88 23:56 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12589; 25 May 88 23:43 EDT Received: from [128.102.22.61] by SMOKE.BRL.ARPA id aa25237; 25 May 88 23:29 EDT Received: Wed, 25 May 88 20:27:08 PDT by ew09.nas.nasa.gov (5.52/1.2) Date: Wed, 25 May 88 20:27:08 PDT From: "Eric L. Raible" Message-Id: <8805260327.AA05688@ew09.nas.nasa.gov> To: mlj8e@virginia.edu Cc: info-iris@BRL.ARPA In-Reply-To: "Michael L. Johnson"'s message of 25 May 88 14:55:50 GMT <897@virginia.acc.virginia.edu> Subject: GNUemacs for iris 4D + bug fix Reply-To: raible@orville.nas.nasa.gov Date: 25 May 88 14:55:50 GMT From: "Michael L. Johnson" Does anyone know where I can get GNUemacs with EDT emulation to run on a 4D system? I could do the port, but someone else probably already has. Thanks for the info. (804)-924-2496 Michael L. Johnson The latest distribution of gnu emacs (18.51) comes with Iris 4D support, as well as EDT emulation. (See below for info on getting this software for free). Beware that m-iris4d.h has one extremely nasty bug - the last line should be: #define XUNMARK(a) ((a) = (((unsigned)(a) << INTBITS-GCTYPEBITS-VALBITS) >> INTBITS-GCTYPEBITS-VALBITS)) instead of #define XUNMARK(a) ((a) = (((a) << INTBITS-GCTYPEBITS-VALBITS) >> INTBITS-GCTYPEBITS-VALBITS)) - Eric Raible (raible@orville.nas.nasa.gov) -------- from etc/DISTRIB ----------- If you have Internet access, you can copy the latest Emacs distribution from host prep.ai.mit.edu. There are several ways to do this; see the file `FTP' in the same directory as this file for more information. Even better, get the latest version of the file from `/u2/emacs/etc/FTP' on prep.ai.mit.edu for the most current arrangements. It may also be possible to copy Emacs via uucp; the file `FTP' contains information on that too. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13974; 26 May 88 6:54 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13735; 26 May 88 5:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13733; 26 May 88 5:47 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa28148; 26 May 88 5:35 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA14762; Wed, 25 May 88 19:54:22 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 88 19:43:48 GMT From: Rion Cassidy Subject: serial port question Message-Id: <4610001@wdl1.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Does anyone out there have experience in read/write-ing "RAW" data to one of the serial ports on an IRIS? I have been trying to use ioctl to set the mode of the port, but so far have been unable to send any data out from my program. If I do an echo or cat, I can get my interface box to indicate that its recieving data, so the port and box are operating to some extent. My program opens the port, sets the mode with ioctl, and then tries to write out a byte. Nothing ever gets recieved, however. Any ideas? Rion Cassidy Ford Aerospace ** PLEASE REPLY TO: ** rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disclaimer: My employer forced me to write this at gun-point. I assume no responsibility whatsoever for what I've said here. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23292; 26 May 88 22:16 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23086; 26 May 88 20:31 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23084; 26 May 88 20:25 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa03867; 26 May 88 20:16 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA27422; Thu, 26 May 88 10:10:29 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 88 15:17:23 GMT From: Steve Gaarder Organization: Computer Aided Design Instructional Facility, Cornell Univ. Subject: dbx problem Message-Id: <4968@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I tried to use the dbx debugger on a Fortran program, and got: dbx version 3.75 of 11/3/86 19:32 Type 'help' for help dbx: fatal error: Invalid argument The program was compiled and linked with the -g switch. It and dbx work fine on a Vaxstation under Ultrix. I'm using an Iris 3020 running 3.5. Any ideas? -- Steve Gaarder Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389 UUCP: {cmcl2,shasta,rochester,uw-beaver}!cornell!batcomputer!sparks BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00571; 27 May 88 13:21 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa29139; 27 May 88 11:27 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29107; 27 May 88 11:10 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa15984; 27 May 88 11:07 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09155; Thu, 26 May 88 21:52:53 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 88 21:40:02 GMT From: dave Organization: Graftel Systems Inc., Wilmington MA Subject: long version control message Message-Id: <275@graftel.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA The "version" control message printed below is strongly suspected of breaking our Silicon Graphics 3130 for almost a week. Our site "graftel" responded to this message but was unable to later forward a response from a downstream site. The response from "graftel" has since been to "oddjob" and returned. Path: graftel!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!nosuch!sitesas!these!madeup!namesin!hereexist!ijust!addedthem!tomakethe!pathline!aslongas!theonein!theother!testmessage!thatisent!atthesame!timeas!thisone!iamsure!youseewhy!oddjob.uchicago.edu!bbtest1 From: bbtest1@oddjob.uchicago.edu (Matt Crawford) Newsgroups: news.admin.ctl Subject: version Message-ID: Date: 12 May 88 18:22:47 GMT Control: version Reply-To: bbtest2@oddjob.uchicago.edu (Matt Crawford) Distribution: usa Organization: University of Chicago Lines: 0 Approved: Matt The word "breaking" needs some elaboration. The machine would appear to operate normally for periods varying from a few seconds to 15 min and then freeze. Symptoms included frozen graphics and no response to any key or set of keys at the console, over a serial line or ethernet. The system never crashed and the processor was not halted. The status lights continued to cycle between 2 and 3. The system would just become totally unresponsive. Sounds like a hardware problem? The SGI field engineer thought so and spent the better part of a week testing every hardware subsystem. Removing the data and execute files for the control message from /usr/spool/uucp fixed the problem. I think it's pretty strange that a program running in user space should be able to break a machine in this way. I reported this to Silicon Graphics but as of yet have received no feedback. Did anyone else have problems dealing with this message? iamsure!idonot!seewhy!thiswas!done ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07678; 28 May 88 20:23 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa07419; 28 May 88 19:10 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07417; 28 May 88 19:02 EDT Received: from HARVARD.HARVARD.EDU by SMOKE.BRL.ARPA id aa11368; 28 May 88 18:45 EDT Received: by harvard.harvard.edu; Sat, 28 May 88 18:19:02 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA12783; Sat, 28 May 88 13:49:02 EDT Received: by phri.UUCP (smail2.5) id AA28802; 28 May 88 13:22:04 EDT (Sat) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA04477; Sat, 28 May 88 10:09:19 EDT Date: Sat, 28 May 88 10:09:19 EDT From: Rodian Paul Message-Id: <8805281409.AA04477@dasys1.UUCP> To: info-iris@BRL.ARPA, mlj8e@dale.acc.virginia.edu Subject: Re: VCL and EDT for 4D Hey if you wanna run VMS just buy a vax, just in case you didn't notice IRIS's run on the UNIX os. I think it's a ludicrous idea to run a VMS shell on top on UNIX. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05603; 3 Jun 88 15:07 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04906; 3 Jun 88 12:41 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab04853; 3 Jun 88 12:27 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa25160; 3 Jun 88 12:22 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa24894; 3 Jun 88 9:22 PDT Date: Fri, 3 Jun 88 9:10:43 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: coordinate transformations Message-ID: <8806031223.aa25160@SMOKE.BRL.ARPA> I am using the following graphics routines to place character strings and record their positions : cmov(), charstr(), getcpos(). 'cmov' and 'charstr' work well together -- I assume because they use the same coordinate system. After placing a character string, I use 'getcpos' to record where I left off, but it aparently uses a different coordinate system because I can not make sense out of a subsequent call to 'cmov' using the returned values to reposition the character cursor. Does anyone know what needs to be done to make this scenario work the way I would expect it to? Thanx ... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08030; 4 Jun 88 4:00 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07655; 4 Jun 88 2:16 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07590; 4 Jun 88 1:56 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa05103; 4 Jun 88 1:53 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA19625; Fri, 3 Jun 88 16:56:06 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Jun 88 21:47:17 GMT From: Steve Gaarder Organization: Computer Aided Design Instructional Facility, Cornell Univ. Subject: Re: dbx problem Message-Id: <5040@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I asked a week or so ago about a problem using dbx on an Iris 3020 under gl 3.5. The answer was that dbx does not work in an nfs directory under rev 3.5. The temporary solution is to use a local directory; the long- term one is to upgrade to 3.6. Thanks to all who took the time to reply. Now I have another question: How do I have the system notify me when mail comes in? Biff and comsat seem to be missing. -- Steve Gaarder Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389 UUCP: {cmcl2,shasta,rochester,uw-beaver}!cornell!batcomputer!sparks BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa09446; 4 Jun 88 19:51 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09355; 4 Jun 88 18:59 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab09341; 4 Jun 88 18:47 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa10690; 4 Jun 88 18:42 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA05430; Sat, 4 Jun 88 14:59:28 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Jun 88 19:31:33 GMT From: "Martin R. Wittmann" Organization: Princeton University, NJ Subject: Plotting functions or package? Message-Id: <3055@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I would like to find some public domain source code (preferably in C) for data plotting applications designed to work on the Iris 3000 series. Specifically, I would like: a) functions that operate on 2 or 3D datasets (or functions returning same) and generate axes, tic and grid lines, labels, legends, etc., and plot the data by various means (different linestyles, error bars, symbols, etc.); b) functions providing database capabilities for controlling a number of datasets and associated plots in a window; c) editting functions allowing change of scale of axes, positioning of labels or legend, or other features of the plot composition easily, say using 'pick mode' or mouse movement to change scalar values. The Irises are great machines, but I am surprised that they are not supplied with a simple plotting package to produce attractive data plots. (This may be under-utilization, but there is clearly a value in having something like this alongside all the other gee-whiz things you might have running on an Iris!) Please post or email. Many thanks! 'careful, Bwana... we are in lion country now' //////////////I//I//////////////////..//////////////////////////////// Martin Wittmann (mrwittma) -- Dept. of Chem. Eng. -- Princeton Univ. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11321; 5 Jun 88 19:04 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11227; 5 Jun 88 17:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11223; 5 Jun 88 17:41 EDT Received: from HARVARD.HARVARD.EDU by SMOKE.BRL.ARPA id aa17041; 5 Jun 88 17:33 EDT Received: by harvard.harvard.edu; Sat, 4 Jun 88 00:21:25 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA23744; Fri, 3 Jun 88 19:28:14 EDT Received: by hombre.MASA.COM (smail2.5) id AA00633; 3 Jun 88 13:42:22 EDT (Fri) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA20705; Fri, 3 Jun 88 13:35:42 EDT Date: Fri, 3 Jun 88 13:35:42 EDT From: Rodian Paul Message-Id: <8806031735.AA20705@dasys1.UUCP> To: Info-Iris@BRL.ARPA Subject: Getting Kermit to run on a 4D Having problems porting kermit to the 4D? Here's a hack that works TO AN EXTENT. I was getting core-dumps any time I tried to "connect" with kermit, and dbx just pointed at fork() as the culprit. I found out how to get around the problem but not how to fix it. My .kermrc looked like this set modem hayes set line /dev/ttyd6 set speed 1200 set flow none Take out the line "set flow" and everything worked fine. The following two files are from the 2000-3000 series machines and should be placed in the source directory. You then need to edit the files: ckufio.c ckutio.c Replace the given lines in both files: replace line: #include with: #include "types.h" replace line: #include with: #include "dir.h" Thanks to frobinso@cirm.northrop.com for help on this one. Compile with "make sys3nid". You'll still get compiler warnings but otherwise you'll have a working version of kermit. /* ------------------- dir.h ----------------------- */ #ifndef DIRSIZ #define DIRSIZ 14 #endif #ifndef __DIR__ #define __DIR__ struct direct { ino_t d_ino; char d_name[DIRSIZ]; }; #endif __DIR__ /* ------------------ types.h ---------------------- */ #ifndef __TYPES__ #define __TYPES__ /* generic unsigned data types */ typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong; /* system data types */ typedef struct { int r[1]; } * physadr; typedef long daddr_t; typedef long swblk_t; typedef char * caddr_t; typedef ushort ino_t; typedef short cnt_t; typedef long time_t; typedef int label_t[13]; typedef short dev_t; typedef long off_t; typedef long paddr_t; typedef long key_t; /* these are for berkeley compatibility */ typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; typedef short size_t; #endif __TYPES__ ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17018; 6 Jun 88 14:21 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16231; 6 Jun 88 12:26 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16210; 6 Jun 88 12:14 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa00781; 6 Jun 88 12:09 EDT Received: by nrtc.nrtc.northrop.com id aa01097; 6 Jun 88 9:08 PDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa01064; 6 Jun 88 9:02 PDT Date: Mon, 6 Jun 88 8:32:19 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: VPL DATAGLOVE Message-ID: <8806061209.aa00781@SMOKE.BRL.ARPA> I am beginning a project which involves the animation of a human hand on a 4D. The driving force behind the animation will come from VPL's GLOVEBOX II. Has anyone graphed or animated a human appendage? Is there any public domain code out there? I am really not sure how to proceed. I have the communications with the electronics unit down pat, but I am not quite sure how to begin drawing fingers that will bend and rotate. My ultimate intension is to implement a 'touchless' touch screen and a virtual stick in an F/A-18 fighter aircraft. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa20695; 7 Jun 88 4:52 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa20335; 7 Jun 88 3:08 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa20321; 7 Jun 88 2:54 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa14071; 7 Jun 88 2:45 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA17997; Mon, 6 Jun 88 20:37:38 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jun 88 16:44:20 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: coordinate transformations Message-Id: <15457@sgi.SGI.COM> References: <8806031223.aa25160@SMOKE.BRL.ARPA> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <8806031223.aa25160@SMOKE.BRL.ARPA>, frobinso@cirm.northrop.COM (Fletcher Robinson) writes: > I am using the following graphics routines to place character strings > and record their positions : cmov(), charstr(), getcpos(). 'cmov' and > 'charstr' work well together -- I assume because they use the same > coordinate system. After placing a character string, I use 'getcpos' > to record where I left off, but it aparently uses a different coordinate > system because I can not make sense out of a subsequent call to 'cmov' > using the returned values to reposition the character cursor. Does anyone > know what needs to be done to make this scenario work the way I would > expect it to? Thanx ... Unfortunately, cmov() works in world coordinates, while getcpos() works in screen coordinates (don't shoot me; I'm only the piano player). I've found it works best to keep several pieces of information and do the mapping as necessary. Thus, I keep world coordinates of where I want to draw along with a basic mapping to screen space. Then, when I want to place characters, the mapping is a simple calculation. -- Jim Barton Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' -- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24048; 7 Jun 88 10:40 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22992; 7 Jun 88 9:04 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa22973; 7 Jun 88 9:01 EDT Date: Tue, 7 Jun 88 8:54:16 EDT From: Glenn Randers-Pehrson (WMB) To: jmb@sgi.com cc: info-iris@BRL.ARPA Subject: Re: coordinate transformations Message-ID: <8806070854.aa16102@TBD.BRL.ARPA> .... > > I am using the following graphics routines to place character strings > > and record their positions : cmov(), charstr(), getcpos(). 'cmov' and > > 'charstr' work well together -- I assume because they use the same > > coordinate system. After placing a character string, I use 'getcpos' > > to record where I left off, but it aparently uses a different coordinate > > system because I can not make sense out of a subsequent call to 'cmov' > > using the returned values to reposition the character cursor. Does anyone > > know what needs to be done to make this scenario work the way I would > > expect it to? Thanx ... [Fletcher Robinson] > > Unfortunately, cmov() works in world coordinates, while getcpos() works > in screen coordinates (don't shoot me; I'm only the piano player). I've > found it works best to keep several pieces of information and do the > mapping as necessary. Thus, I keep world coordinates of where I want > to draw along with a basic mapping to screen space. Then, when I want > to place characters, the mapping is a simple calculation. > > -- Jim Barton Why not let the SGI keep track of the world vs screen coordinates and mapping, viz: pushmatrix(); screenspace(); getcpos(ix,iy); cmov2s(ix,iy); charstr(str2); popmatrix(); ... Glenn Randers-Pehrson ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00844; 9 Jun 88 19:01 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00347; 9 Jun 88 17:38 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00275; 9 Jun 88 17:28 EDT Received: from CS.UTAH.EDU by SMOKE.BRL.ARPA id aa23511; 9 Jun 88 16:06 EDT Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA10661; Thu, 9 Jun 88 14:04:38 MDT Received: by gr.utah.edu (5.54/utah-1.0-gr) id AA26341; Thu, 9 Jun 88 14:04:11 MDT Date: Thu, 9 Jun 88 14:04:11 MDT From: "Rod G. Bogart" Message-Id: <8806092004.AA26341@gr.utah.edu> Subject: GNU on 4d Newsgroups: fa.iris To: info-iris@brl.mil Keywords: crash, die I recently ftp'ed a copy of GNU from MIT, and tried to bring it up on an Iris4d running beta3.0. It dies during garbage-collect. Has anyone else had the same problem? The GNU version is 18-51. I hear that 2.0 user are having no problems. Any leads, fixes, or other info is appreciated, ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11359; 13 Jun 88 19:58 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10946; 13 Jun 88 18:03 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10927; 13 Jun 88 17:47 EDT Received: from SGI.COM by SMOKE.BRL.ARPA id aa02922; 13 Jun 88 17:43 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.vjs) (for info-iris@brl.arpa) id AA04487; Fri, 10 Jun 88 18:57:57 PDT Received: by elvin.sgi.com (5.51/880418.vjs) (for dietrich@sgi.SGI.COM) id AA00457; Fri, 10 Jun 88 18:56:32 PDT From: Frank Dietrich Message-Id: <8806110156.AA00457@elvin.sgi.com> Date: 10 Jun 1988 1856-PDT (Friday) To: info-iris@BRL.ARPA Cc: dietrich@sgi.com Subject: International Iris User Forum at Siggraph INTERNATIONAL IRIS USER FORUM For the third time Silicon Graphics will be hosting the International Iris User Forum at Siggraph to be held this year in Atlanta, Georgia. The Forum is an ideal place for you to touch base with many interesting people in the Iris community and to be informed about current and future technical developments at Silicon Graphics. Marriott Hotel, Atlanta Imperial Ballroom A & B Wednesday, Aug. 3, 1988 ------------------------------------------------------------------- 11-1 | SIG CAD-Geometric Modeling | SIG Art & Animation | ------------------------------------------------------------------- 2 -4 | SIG Visual Simulation | SIG Scientific Visualization | ------------------------------------------------------------------- 5-7:30| General Session: Iris Applications & Technology | ------------------------------------------------------------------- 7:30-9| Iris User Reception | ------------------------------------------------------------------- INTERNATIONAL ATTENDANCE Siggraph attracts many international visitors and is acclaimed as the premier show for the most up-to-date trends in computer graphics worldwide. This is your chance to communicate with leading researchers, programmers, and artists who will showcase the expanding international scope of the Iris user community. GENERAL SESSION: IRIS APPLICATIONS & TECHNOLOGY As in previous years we will organize a general session for everyone. This session will highlight the best applications developed by you on Iris workstations. SGI's top technical officers will discuss future technological developments in computing and graphics. Again, we will encourage an open exchange of ideas between you and members of Silicon Graphics' executive team. SPECIAL INTEREST GROUPS (SIGs) Due to the growth of the Iris community we made arrangements to add four special interest groups. Each will last 2 hours, two will run simultaneously in parallel. These sessions encourage a high degree of user participation and interaction. SGI liasons will help to coordinate the special interest groups. YOU CAN MAKE IT HAPPEN If every member of the Iris community takes personal responsibility for at least one activity at the International User Forum we can all look forward to an exciting and spirited event. * Do you want to give a presentation? * Would you like to share your favorite program in the Software Exchange? * Do you have any interesting information or terrific images for the next Iris Universe? * What is the most important issue you would like to discuss? Let me know and stay in touch! Frank (415) 962-3348 P.S. after an already long message: The next Iris Universe will come out in full-color with many digitally printed images. And we are working on getting the Software Exchange going. It looks pretty good! ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12486; 14 Jun 88 1:52 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12235; 14 Jun 88 0:08 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12226; 13 Jun 88 23:53 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa05751; 13 Jun 88 23:40 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA17144; Mon, 13 Jun 88 17:02:21 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Jun 88 20:41:42 GMT From: Steve Gaarder Organization: Computer Aided Design Instructional Facility, Cornell Univ. Subject: want help with error message Message-Id: <5141@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA Our 2 Iris 3020's, running gl 3.5 with tcp and nfs, occasionally (several times a day) display the following message on the main display: ex0: transmit error: Nothing seems to act up, we just get this message, which is a pain. Any ideas? -- Steve Gaarder Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389 UUCP: {cmcl2,shasta,rochester,uw-beaver}!cornell!batcomputer!sparks BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24685; 15 Jun 88 10:00 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22741; 15 Jun 88 7:53 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22713; 15 Jun 88 7:39 EDT Received: from [128.155.20.81] by SMOKE.BRL.ARPA id aa05724; 15 Jun 88 7:33 EDT Received: Wed, 15 Jun 88 07:35:12 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 15 Jun 88 07:35:12 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8806151135.AA03067@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: NFS for IRIS 3030 What do you think of NFS on the IRIS? Is anyone having any problems? What machines have you NFS to the 3030's? Has anyone NFS'ed between a 3030 and a Gould? We are thinking of getting NFS for our IRIS, but have heard there are some nasty bugs in Silicon Graphics NFS software. Any input would be apreciated. Thank you. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27211; 15 Jun 88 13:03 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26850; 15 Jun 88 12:52 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26841; 15 Jun 88 12:48 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa15986; 15 Jun 88 12:44 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id ab02955; 15 Jun 88 9:43 PDT Date: Wed, 15 Jun 88 9:40:43 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: kernel and tar errors Message-ID: <8806151244.aa15986@SMOKE.BRL.ARPA> I have come up against two problems on our new 4D 70G. One machine with very little user activity(..waiting for software..), after sitting idle for several days will begin to display the following error : error in kernel #42 severity=2 , etc. This locks me out of the system with the only way to recover is to power down. After power is restored, it functions as before for several days until it displays the same error again. Another problem is using tar to backup files. There is a profusion of the following error message: 1ps0d0s6: error csr=0x4000 bn=?????? statcode=83 recovered, errcode=0x1 accompanied sparingly by : tp7: (18) correctable data error Anyone have any insight into these errors? Are they aviodable? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00806; 15 Jun 88 19:12 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00758; 15 Jun 88 19:02 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00737; 15 Jun 88 18:56 EDT Date: Wed, 15 Jun 88 18:51:22 EDT From: Phil Dykstra To: "Brent L. Bates TAD/HRNAB ms294 x2601" cc: info-iris@BRL.ARPA Subject: Re: NFS for IRIS 3030 Message-ID: <8806151851.aa11045@SPARK.BRL.ARPA> At BRL we run NFS from the Iris 3030's and 4D's, to both Gould PN machines and Alliants. If general it works quite well, and I would say that its benefits outweigh any of its problems. For the record, the problems that I know about are: 1) Occasional unreliable data transfer. This problem is true of the Suns as well (at least I can speak for SunOS 3.4). Particularly during very large file copies, say several megabytes, the new copy may be corrupted. I have examined three cases in which this happened, and in every case a single byte had changed to all ones (0xff). The location of the bytes in the file was different every time. The cause of the corrupted bytes may be software or hardware, I don't know which, but there is something you can do that will help. Sun, and thus SGI as well, has tried to increase the efficiency of NFS by turning off UDP checksumming on incomming and outgoing NFS/UDP packets. You can enable checksumming by: a) Use adb and set "udpcksum" in the kernel to 1. This will enable UDP checksumming on *incomming* packets. Fix it in your source code too if you've got it. The file is netinet/udp_usrreq.c. b) For outgoing NFS packets, the routine ku_sendto_mbuf() in rpc/subr_kudp.c uses ku_fastsend() which skips checksumming rather than the usual udp_output() which does it (if udpcksum is nonzero). You can recompile subr_kudp.c with -DSLOWSEND defined which will cause it to use udp_output() instead. Unfortunately we don't have source code for the current SGI software, so I haven't been able to fix this one yet. I did add this fix to the Sun's, and have caught a few bad packets since then that otherwise would have gotten through. A pat on the back by the way to whoever at Gould decided NOT to use the ku_fastsend() routine. They don't have this problem. 2) Occasional unreadable files. This one is real elusive and usually strikes on .rhost files, though it has happened to other files as well. I have observed it on the SGI's, as well as a couple of rare instances on SunOS 3.x (perhaps 3.2 or 3.4, I'm not sure). A description I sent a few months ago: Running with an NFS mounted home directory, rloging into or rcping to a 3030 or 4D, every once in a while the .rhosts file vanishes. The file entry is still there, and ls even shows its original (correct) length, but if you try to cat it nothing comes out. Examining more closely you find that the open() on the file works, but the first read() fails with "permission denied." A local "stat" of the file shows the correct owner and permissions though. It is as if either the client or server forgot who you are (uid wise). Often touching the file on the server machine, or perhaps copying it, is enough to make it come back. If anyone knows what causes this, and/or a fix, I would really appreciate hearing about it. Its one of those things that you can never get to happen when you want it to, so its very hard to debug. 3) Pwd problems (prior to release something-or-other). The above two problem were generic to Sun's NFS, this one is SGI specific and has been fixed on the 4D's and patched (mostly anyway) on recent 3030 releases. Description: cd to somewhere on an NFS filesystem. pwd will sometimes die with "can't change back to ." or "read error in .." or something along those lines. The cause of this was 16bit inode numbers (ino_t) on the SGI Irises. 4.nBSD machines such as Suns and Goulds, use 32bit inode numbers. SGI had to make the stat() call return a puny inode number. Truncation from 32 to 16 bits would sometimes map multiple files onto the same dev/inode pair and thus confuse things like getwd(). On the 4D's SGI went to 32bit inodes and thus don't have this problem. On the 3030's, ino_t is still 16bits, but stat returns a long inode instead. They claim that whatever they did works 99.9+% of the time and I don't recall seeing it fail since then. So be it. - Phil ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05428; 16 Jun 88 8:58 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03176; 16 Jun 88 6:49 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa03156; 16 Jun 88 6:31 EDT Date: Thu, 16 Jun 88 6:24:53 EDT From: Mike Muuss To: Info-Iris@BRL.ARPA Subject: Hyperchannel on 4D Message-ID: <8806160624.aa14491@SPARK.BRL.ARPA> Does anybody have any experience with the NSC VME Hyperchannel interface on the SGI 4D? We have the hardware, and are looking for advice on how to install it. If you have a driver, that would also be useful to know. (Note, this is NOT the Ikon board, but a real NSC board for the VME bus). -Mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08882; 16 Jun 88 13:05 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06714; 16 Jun 88 10:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06693; 16 Jun 88 10:39 EDT Received: from PRINCETON.EDU by SMOKE.BRL.ARPA id aa05983; 16 Jun 88 10:33 EDT Received: from phoenix.Princeton.EDU by Princeton.EDU (5.58+++/1.64) id AA25314; Thu, 16 Jun 88 10:32:07 EDT Received: by phoenix.Princeton.EDU (1.2/1.62) id AA11892; Thu, 16 Jun 88 10:27:00 edt Date: Thu, 16 Jun 88 10:27:00 edt From: "Kevin R. Perry" Message-Id: <8806161427.AA11892@phoenix.Princeton.EDU> To: frobinso@cirm.northrop.com, info-iris@BRL.ARPA Subject: Re: kernel and tar errors >From info-iris-request@brl-vmb.arpa Thu Jun 16 10:03:04 1988 >Date: Wed, 15 Jun 88 9:40:43 PDT >From: Fletcher Robinson >To: info-iris@BRL.ARPA >Subject: kernel and tar errors >Message-Id: <8806151244.aa15986@SMOKE.BRL.ARPA> > >I have come up against two problems on our new 4D 70G. One machine with >very little user activity(..waiting for software..), after sitting idle >for several days will begin to display the following error : > error in kernel #42 severity=2 , etc. Haven't seen this one, sorry. > >Another problem is using tar to backup files. There is a profusion of >the following error message: > 1ps0d0s6: error csr=0x4000 bn=?????? statcode=83 recovered, errcode=0x1 >accompanied sparingly by : > tp7: (18) correctable data error We have experienced this problem on our 4D's. I recently asked an SGI field service person about it. He claims the problem is known to SGI, and they're working on it. It's in the hardware, and they supposedly understand what is wrong. Something about impedence-matching on something in the tape-drive unit. He says it's perfectly safe to ignore these messages, and maybe someday they'll have a fix. Hey, at least it gives you something to watch while you're doing backups! :-) K.Perry perry%phoenix@princeton.edu Sys Prog Computing & Info. Technology Princeton Univ. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12772; 16 Jun 88 21:41 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12542; 16 Jun 88 19:15 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12521; 16 Jun 88 19:07 EDT Received: from HARVARD.HARVARD.EDU by SMOKE.BRL.ARPA id aa21850; 16 Jun 88 18:58 EDT Received: by harvard.harvard.edu; Thu, 16 Jun 88 18:29:09 EDT Received: by cmcl2.NYU.EDU (5.54/25-eef) id AA04928; Thu, 16 Jun 88 18:02:41 EDT Received: by cucard.med.columbia.edu (5.51/5.10) id AA25104; Thu, 16 Jun 88 17:01:04 EDT Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA21234; Thu, 16 Jun 88 16:08:53 EDT Date: Thu, 16 Jun 88 16:08:53 EDT From: Rodian Paul Message-Id: <8806162008.AA21234@dasys1.UUCP> To: cucard!cirm.northrop.com!frobinso@harvard.harvard.edu, cucard!brl.arpa!info-iris@harvard.harvard.edu Subject: Re: kernel and tar errors > Another problem is using tar to backup files. There is a profusion of > the following error message: > 1ps0d0s6: error csr=0x4000 bn=?????? statcode=83 recovered, errcode=0x1 > accompanied sparingly by : > tp7: (18) correctable data error You are probably running a 380 meg Hitachi drive on the 4D in question? SGI will be replacing cables for these drives pretty soon, seems the controller can't keep up with the drive sometimes (so I've been told), thus the drive error messages. Apparently nothing to worry about so long as 'recovered' comes up. The tp7: (18) has been a real bitch for me. I get the message about 7 out of 10 'tar cv's. The message is specific to the tape drive. Several weeks ago I had some corrupted data on a couple of tapes. 'tar' read them off fine, but the data was trashed. After chatting with SGI someone said that they'd had the same problem at SGI (later on I was told by many people there, that this could never happen), anyway a field engineer came out and we ran a whole lot of tests. We still got lot's of 'correctable data error' messages, but no trashed data. Since then things seem fine, I don't know what trashed my data before, or if it's related to the flakey controller/disk cables, only time will tell... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21232; 17 Jun 88 17:45 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19915; 17 Jun 88 14:58 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab19837; 17 Jun 88 14:40 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa11902; 17 Jun 88 14:36 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA14969; Fri, 17 Jun 88 03:48:06 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Jun 88 21:09:23 GMT From: Brian Wyvill Organization: U. of Calgary, Calgary, Ab. Subject: Memory problem Message-Id: <1682@vaxb.calgary.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA We are running 2 Iris 3020s and are having the following problem. These machines say that they have 8 megs of memory on boot up, but when I wrote a 10 line program to malloc a little over 4 meg it returns with not enough memory?? Why can't this supposed 8 meg machine access more then 4 meg at one time? Has anyone else run into this? Is there a fix or work around? -- Brian Wyvill ..!{ubc-vision,ihnp4}!alberta!calgary!blob ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22339; 17 Jun 88 22:40 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21917; 17 Jun 88 21:07 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21909; 17 Jun 88 21:01 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa18446; 17 Jun 88 20:55 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA21034; Fri, 17 Jun 88 11:02:26 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Jun 88 21:40:02 GMT From: Stephen Samuel Organization: Unexsys Systems, Edmonton,AB. Subject: Re: want help with error message Message-Id: <3143@edm.UUCP> References: <5141@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA From article <5141@batcomputer.tn.cornell.edu>, by sparks@batcomputer.tn.cornell.edu (Steve Gaarder): > Our 2 Iris 3020's, running gl 3.5 with tcp and nfs, occasionally (several > times a day) display the following message on the main display: > > ex0: transmit error: loose cable seems likely: I had this problem when I first installed our ethernet and it was finally solved by putting together a 6 inch extender cable on the tranciever cable. To check: have someone watch the CD led on your tranciever box (you DO have at least one LED on it, don't you??) while you fiddle with the connector a bit. If the LED blinks, then chances are the connector is your problem.. (you should also try to do this while the ethernet is lightly loaded). -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UQV-MTS ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa25589; 18 Jun 88 16:02 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa25406; 18 Jun 88 14:28 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa25398; 18 Jun 88 14:08 EDT Received: from PRINCETON.EDU by SMOKE.BRL.ARPA id aa26075; 18 Jun 88 14:02 EDT Received: from phoenix.Princeton.EDU by Princeton.EDU (5.58+++/1.65) id AA25134; Sat, 18 Jun 88 14:00:42 EDT Received: by phoenix.Princeton.EDU (1.2/1.62) id AA23712; Sat, 18 Jun 88 14:01:25 edt Date: Sat, 18 Jun 88 14:01:25 edt From: "Kevin R. Perry" Message-Id: <8806181801.AA23712@phoenix.Princeton.EDU> To: alberta!access!edm!rroot%ucbvax.berkeley.edu@att, info-iris@BRL.ARPA Subject: Re: want help with error message >From info-iris-request@brl-vmb.arpa Fri Jun 17 22:51:44 1988 >Date: 16 Jun 88 21:40:02 GMT >From: Stephen Samuel >Organization: Unexsys Systems, Edmonton,AB. >Subject: Re: want help with error message > >>From article <5141@batcomputer.tn.cornell.edu>, by sparks@batcomputer.tn.cornell.edu (Steve Gaarder): >> Our 2 Iris 3020's, running gl 3.5 with tcp and nfs, occasionally (several >> times a day) display the following message on the main display: >> >> ex0: transmit error: >loose cable seems likely: I had this problem when I first installed our >ethernet and it was finally solved by putting together a 6 inch >extender cable on the tranciever cable. ...on the other hand, all our IRISes saw a fair number of these messages while running 3.5, and we tried fiddling with the cables, which didn't really seem to do anything. But since the day we installed 3.6, we haven't seen ANY of these messages. (well, maybe 1 or 2, but orders of magnitude less than before). So this seems to be another possible solution to the problem. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08661; 20 Jun 88 16:25 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07585; 20 Jun 88 14:30 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07503; 20 Jun 88 14:15 EDT Received: from [128.228.1.2] by SMOKE.BRL.ARPA id aa23794; 20 Jun 88 14:01 EDT Received: from SCFVM.NSESCC.GSFC.NASA.GOV by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3308; Mon, 20 Jun 88 13:59:59 EDT Received: by SCFVM (Mailer X1.25) id 8834; Mon, 20 Jun 88 14:00:57 EDT Date: Mon, 20 Jun 88 13:57:11 EDT From: "Thomas D. Schardt" Subject: TN3270 To: INFO-IRIS@BRL.ARPA Message-ID: <8806201401.aa23794@SMOKE.BRL.ARPA> Does anyone know of a TN3270 implementation for the Iris 4D/60T? BTW, TN3270 allows the user to login to an IBM mainframe as if he/she was using a real 3270 terminal via TCP/IP. Tom Schardt NASA Space and Earth Sciences Computing Center Goddard Space Flight Center BITNET: K4TDS at SCFVM ARPANET: K4TDS@SCFVM.BITNET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08065; 21 Jun 88 15:46 EDT Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05092; 21 Jun 88 12:49 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05017; 21 Jun 88 12:32 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa24810; 21 Jun 88 12:24 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa06108; 21 Jun 88 9:23 PDT Date: Tue, 21 Jun 88 9:16:11 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: security ... Message-ID: <8806211224.aa24810@SMOKE.BRL.ARPA> What is SGI's policy regarding replacement of defective mass storage media(hard disk drives) from a secure area when under warranty or service maintenance contract and security will not allow you to remove the media? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26799; 28 Jun 88 12:14 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa24620; 28 Jun 88 9:38 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa24549; 28 Jun 88 9:24 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa18549; 28 Jun 88 1:10 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA12604; Mon, 27 Jun 88 19:11:51 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Jun 88 01:53:30 GMT From: "G. Murdock Helms" Organization: NASA Ames Research Center, Calif. Subject: Strange enp0 errors on 4D60Turbo Message-Id: <967@eos.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In January of this year we purchased an SGI 4D60Turbo. Around February or March of this year, this strange error began popping up on the console: enp0: bad recieve packet length of 0 Usually we noticed this on entering the lab in the morning, late evening, or on a weekend, usually when no one had been using the machine for a while. The number of messages started at about 6, went up to about 50, and currently hover around 12 to 25. We don't always find these messages: it seems to be a somewhat sporadic problem that crops up for a week or two and dies out again. We had originally thought it was just something wrong with our machine, until I went to use a 4D70 in another lab (not ours) and found the screen full of these errors. The Hotline is puzzled by these errors, and neither our 2500T or 3120 Irises show any indication of burping in this manner. Has anyone else experienced or found a solution to this little mystery? G. Murdock Helms ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01055; 29 Jun 88 1:25 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00865; 28 Jun 88 23:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00860; 28 Jun 88 23:33 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa20893; 28 Jun 88 23:24 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA06431; Tue, 28 Jun 88 20:01:59 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Jun 88 17:26:46 GMT From: Vernon Schryver Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Strange enp0 errors on 4D60Turbo Message-Id: <16645@sgi.SGI.COM> References: <967@eos.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <967@eos.UUCP>, timelord@eos (G. Murdock Helms) writes: > In January of this year we purchased an SGI 4D60Turbo. Around February or > March of this year, this strange error began popping up on the console: > > enp0: bad recieve packet length of 0 This means that an invalidly small packet came in from the ether. Future releases of the driver will have a printf based on: "if_enp%d: packet too small (length = %d)\n" We infrequently get flurries of these in our network. They mean something is broken or not yet working somewhere on the wire. Vernon Schryver Silicon Graphics vjs@sgi.com or {pyramid,allegra,research,sun,pacvax}!sgi!vjs ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03271; 29 Jun 88 9:01 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03171; 29 Jun 88 8:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03027; 29 Jun 88 8:38 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa25327; 29 Jun 88 8:24 EDT Received: Wed, 29 Jun 88 08:23:57 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 29 Jun 88 08:23:57 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8806291223.AA07270@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Larger disks for 3030 Has anyone bought disks from someone other than SGI and installed them in their 3030? We have two 170M drives and are thinking about replacing them with larger drives, but don't want to pay SGI's expesive prices. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03956; 29 Jun 88 11:06 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02574; 29 Jun 88 7:54 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02482; 29 Jun 88 7:45 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa23962; 29 Jun 88 7:38 EDT Received: Wed, 29 Jun 88 07:38:33 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 29 Jun 88 07:38:33 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8806291138.AA07126@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: NFS on 3030 I have another question about NFS. I have been told that SGI NFS uses a signed 16 bit number for inodes, thus limiting the total number of inodes to 32767. Our Gould sets up disk space with 2048 bytes/inode, thus an NFS mount is limited to 64M bytes. Has this given anyone problems? Has SGI fixed this problem? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04469; 29 Jun 88 12:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02956; 29 Jun 88 8:28 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02954; 29 Jun 88 8:25 EDT Received: from aero2.larc.nasa.gov by SMOKE.BRL.ARPA id aa25073; 29 Jun 88 8:18 EDT Received: Wed, 29 Jun 88 08:14:16 EDT by aero2.larc.nasa.gov (5.52/5.17) Date: Wed, 29 Jun 88 08:14:16 EDT From: TAD system manager Message-Id: <8806291214.AA19923@aero2.larc.nasa.gov> To: blbates@aero4.larc.nasa.gov, info-iris@BRL.ARPA Subject: Re: NFS on 3030 Cc: fox@aero2.larc.nasa.gov i am still looking into this. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23916; 1 Jul 88 19:27 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23654; 1 Jul 88 17:11 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23569; 1 Jul 88 16:59 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa24475; 1 Jul 88 16:44 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa17549; 1 Jul 88 13:42 PDT Date: Fri, 1 Jul 88 13:41:26 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: graphics Message-ID: <8807011644.aa24475@SMOKE.BRL.ARPA> Does anyone know what the function call equivellent to the 2400T 'gammapcolor()' is on the 4D ? Thanx ... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24426; 1 Jul 88 23:29 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa24239; 1 Jul 88 21:34 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa24232; 1 Jul 88 21:21 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa26400; 1 Jul 88 21:12 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA08755; Fri, 1 Jul 88 17:01:06 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Jul 88 18:08:17 GMT From: Brendan Eich Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: NFS on 3030 Message-Id: <16845@sgi.SGI.COM> References: <8806291138.AA07126@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA > I have another question about NFS. I have been told that SGI NFS uses > a signed 16 bit number for inodes, thus limiting the total number of inodes > to 32767. Our Gould sets up disk space with 2048 bytes/inode, thus an NFS > mount is limited to 64M bytes. Has this given anyone problems? Has SGI > fixed this problem? SGI 3000 series Unix, based on AT&T System 5.0, uses the traditional 16 bit unsigned inode number representation. The 4D series uses an unsigned 32 bit representation. In neither case does the representation *limit* the total number of inodes which a client may access from a Gould, Sun, or BSD-based server. NFS, to be NFS, must follow the protocol standard and use an XDR unsigned long for the filesystem node identifier (same as inode number for Unix servers). The problem (much commented upon) with inumbers is what representation stat(2) uses. Stat must not chop any bits from NFS inumbers, or pwd(1) and its ilk may be confused. Release 3.5 of the 3000 series software returned only the low 16 bits of NFS inumbers, causing occasional pwd failure. Release 3.6 of 3000 series software contains a new version of stat that returns 32 bits of inumber. The kernel and local filesystem (EFS) still use the old System 5.0 16 bit representation. The 4D kernel uses 32 bits everywhere. In short, release 3.6 for the 3000, and all 4D versions of NFS suffer no NFS inode number bugs. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00494; 3 Jul 88 21:24 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00311; 3 Jul 88 20:22 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00299; 3 Jul 88 20:11 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa13215; 3 Jul 88 20:05 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA09123; Sun, 3 Jul 88 13:00:44 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Jun 88 15:39:53 GMT From: Peter Shenkin Organization: Biology Dept., Columbia Univ., New York, NY Subject: Query on 3130 Iris Message-Id: <64@cubsun.BIO.COLUMBIA.EDU> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA To make a long story short, someone is offering me a used but maintained 3130 for $25k. (1) Do you think this is a good price? (2) I've heard the Fortran compiler is awful -- eg, can't use units 5,6 as stdin and stdout for UNIX redirects. Do you know a way around this? Is there a 3rd party Fortran compiler around which corrects this? (3) Can you suggest any sgi guru's worth consulting? (4) Can you suggest any questions that I should have asked, but didn't? (And if you know the answers, too, so much the better!) Thanks, if you can help.... -P. ******************************************************************************* Peter S. Shenkin, Department of Biological Sciences, Columbia University, New York, NY 10027 Tel: (212) 280-5517 (work); (212) 829-5363 (home) shenkin@cubsun.bio.columbia.edu shenkin%cubsun.bio.columbia.edu@cuvma.BITNET -- ******************************************************************************* Peter S. Shenkin, Department of Biological Sciences, Columbia University, New York, NY 10027 Tel: (212) 280-5517 (work); (212) 829-5363 (home) shenkin@cubsun.bio.columbia.edu shenkin%cubsun.bio.columbia.edu@cuvma.BITNET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07226; 5 Jul 88 13:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa06490; 5 Jul 88 15:38 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06439; 5 Jul 88 15:23 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa12491; 5 Jul 88 15:04 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa24163; 5 Jul 88 12:03 PDT Date: Tue, 5 Jul 88 11:52:39 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: edge ... Message-ID: <8807051504.aa12491@SMOKE.BRL.ARPA> I am trying to isolate under what circumstances, that when I 'exit' from edge debugger, it kills the graphics subsystem in such a way that /etc/gl/restartgl will not restart it. It becomes necessary to reboot because the monitor keeps 'winking out'. Of cousrse, exiting from edge does not always kill the graphics. Is there anything that one should NOT do while using edge? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13287; 6 Jul 88 10:20 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11466; 6 Jul 88 9:07 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11305; 6 Jul 88 8:51 EDT Received: from [128.155.20.81] by SMOKE.BRL.ARPA id aa00258; 6 Jul 88 8:28 EDT Received: Wed, 6 Jul 88 08:21:21 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 6 Jul 88 08:21:21 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8807061221.AA17910@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: frobinso's mail on edge I have had similar monitor 'wink outs' with our 3130. On the 3130, it happens when I accidentally kill the window manager while there are windows, other than the console, present. Some times I can correct the problem by manualling killing each window, leaving the console, and then restarting mex. However, this doesn't work all the time. Sometimes I have to reboot to clear things up. I hope this is of some help. P.S. I tried sending this directly to you but the message was returned. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14668; 6 Jul 88 12:10 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab13287; 6 Jul 88 10:23 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13236; 6 Jul 88 10:18 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa04158; 6 Jul 88 10:01 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA15581; Tue, 5 Jul 88 15:42:33 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Jul 88 21:35:57 GMT From: Steve Gaarder Organization: Computer Aided Design Instructional Facility, Cornell Univ. Subject: Can I make system calls from Iris Fortran? Message-Id: <5377@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I am writing a program in Fortran on a 3020 that needs to do some Unix calls to read and change directories. The usual set of Fortran library routines for the purpose are totally absent from the manual. Do they really not exist, or are they just not documented? Even AT&T("all you get is system V") provides the Fortran routines! Is there a reasonably portable way to make system calls directly from Fortran? -- Steve Gaarder Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389 UUCP: {cmcl2,shasta,rochester,uw-beaver}!cornell!batcomputer!sparks BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15261; 6 Jul 88 13:02 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa14304; 6 Jul 88 11:28 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa14233; 6 Jul 88 11:18 EDT Received: from [128.155.20.81] by SMOKE.BRL.ARPA id aa07182; 6 Jul 88 10:54 EDT Received: Wed, 6 Jul 88 10:58:28 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 6 Jul 88 10:58:28 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8807061458.AA18364@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: rep.: system calls from IRIS FORTRAN As far as I know there are only the couple listed in the FORTRAN manual. If you want anything else, your FORTRAN will have to call a C subroutine which in turn will call the library. Royal pain-in-neck, but that is what you get from SGI software. Good luck, you'll need it. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17966; 6 Jul 88 19:30 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa17687; 6 Jul 88 17:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa17676; 6 Jul 88 17:40 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa20103; 6 Jul 88 17:23 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04585; Wed, 6 Jul 88 12:51:11 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jul 88 18:02:04 GMT From: "G. Murdock Helms" Organization: NASA Ames Research Center, Calif. Subject: enp0 errors (recent occurances) Message-Id: <1009@eos.UUCP> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I'd like to thank everyone for their postings/mail on this topic. From the responses I've gotten, it appears that my machine is not the only one suffering from this problem. Just to provide some more info to those of you who do have this problem, my machine has been coughing up a lot of enp0 errors both yesterday (7/5) and today (7/6)....has anyone else gotten error messages these two days also? Murdock ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26017; 7 Jul 88 14:10 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23063; 7 Jul 88 11:02 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa21889; 7 Jul 88 8:57 EDT Date: Thu, 7 Jul 88 8:52:49 EDT From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: exp(-100.)=-.43e34 on IRIS Message-ID: <8807070852.aa22044@TBD.BRL.ARPA> The behaviour of the EXP() function for large negative numbers on the IRIS is shameful. I've tried the following program on a number of machines (VAX f77, Gould f77, Alliant FORTRAN, Cray-2 cft77) and all return 0.0 for out-of-range negative numbers. The IRIS returns not-a-number if the floating point board isn't used. Worse, if the floating point board is used it returns wrong numbers. This on a 3130 running 3.5r2 and a 2500T running 3.6. program bugexp dimension trial(10) data trial/-1., -20., -50., -80., -85., -88.02968, -88.02970, & -100., -1000., -10000/ do 10 i=1,10 x=trial(i) xx=exp(x) write(*,'('' exp('',f13.6,'')='',g15.8)')x,xx 10 continue stop end Results with f77 -Zf: exp( -1.000000)= .36787950 exp( -20.000000)= .20611540E-08 exp( -50.000000)= .19287500E-21 exp( -80.000000)= .18048510E-34 exp( -85.000000)= .12160990E-36 exp( -88.029680)= .15974800E-42 exp( -88.029700)=??????????????? exp( -100.000000)= -.43075530E+34 exp( -1000.000000)= .12234650E+29 exp(-10000.000000)= .41732680E-27 Programmed STOP ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28160; 7 Jul 88 18:39 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26254; 7 Jul 88 15:31 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26132; 7 Jul 88 14:22 EDT Received: from [128.186.3.1] by SMOKE.BRL.ARPA id aa01679; 7 Jul 88 13:56 EDT Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA09822; Thu, 7 Jul 88 13:56:09 EDT Date: Thu, 7 Jul 88 13:56:09 EDT From: "John D. McCalpin" Message-Id: <8807071756.AA09822@masig1.ocean.fsu.edu> To: info-iris@BRL.ARPA Subject: RE: exp(large numbers) on IRIS Cc: mccalpin@masig1.ocean.fsu.edu Silicon Graphics has known about the pathetic behavior of the exp function for a long time, but they do not seem at all interested in doing anything about it.... As I understand it, they bought the compiler from Silicon Valley Software, and did an in-house rewrite of the intrinsic transcendental functions. The behaviour can be modified (though not corrected) by initializing the floating-point exception handler. You will need to add the following lines to the example code: #include ! somewhere in declarations call setfpe (NOCOREDUMP, ZEROVALS) ! first executable statement This makes MOST underflows go gently to zero, but it does not fix the exp() problem. I don't know why the floating-point exception handler is not active by default.... I have to uses a fix to the exp() problem, I use x = min(x,88.0) x = max(-88.0,x) result=exp(x) or, in one line: result = exp(max(-88.0,min(x,88.0))) The constant 88.0 is the largest value which returns a correct result with 32-bit precision. I can't recall the number for 64-bit precision --- I think it is about 300. Now that the 4D's are the SGI's main interest, I would not count on getting any improvements to the SVS Fortran on the IRIS 3000's.... especially since they did not respond when the IRIS 3000 was their only entry. I suggest that you try a SUN machine. They have troubles, but at least the Fortran numerics are quite robust. John D. McCalpin mccalpin@nu.cs.fsu.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28524; 7 Jul 88 22:21 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa28252; 7 Jul 88 20:36 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa28241; 7 Jul 88 19:16 EDT Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa11392; 7 Jul 88 19:03 EDT Received: by nps-cs.arpa (5.51/1.26) id AA27269; Thu, 7 Jul 88 16:02:40 PDT Date: Thu, 7 Jul 88 16:02:40 PDT From: mark fichten Message-Id: <8807072302.AA27269@nps-cs.arpa> To: info-iris@BRL.ARPA Hello. My name is Mark Fichten and I am a graduate student at the Naval Postgraduate School in Monterey, California. My thesis advisor, Dr. Mike Zyda, told me about your net and I would like to 'join'. I am very involved with the IRIS graphics workstations from the 3120 up to the 4D/70GT. My thesis research is on the FOGM system that you may have heard of from Dr. Zyda. It is a moving vehicle simulator that uses a terrain database from Fort Hunter Liggot, California. It is working very well right now on the 4D/70G and is is 99% ported to the GT. I have one very big gripe with the GT. The winattach() command is no longer part of the software. Wherever the mouse is determines the active window. In order to override this, the user must hold down any key on the keyboard. THIS IS COMPLETELY UNACCEPTABLE! I am unable to 'detach' the user from my process and allow him to attach himself to another process arbitrarily since he may move the mouse over other windows accidentely! Is there any way to 'turn off' this PROBLEM???? Help!! Mark Fichten fichten@nps-cs.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00818; 8 Jul 88 20:35 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02824; 8 Jul 88 16:20 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02780; 8 Jul 88 14:00 EDT Received: from [128.186.3.1] by SMOKE.BRL.ARPA id aa26500; 8 Jul 88 13:52 EDT Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA01368; Fri, 8 Jul 88 13:53:13 EDT Date: Fri, 8 Jul 88 13:53:13 EDT From: "John D. McCalpin" Message-Id: <8807081753.AA01368@masig1.ocean.fsu.edu> To: info-iris@BRL.ARPA Subject: Square Root Madness ! Cc: davis@masig1.ocean.fsu.edu, simmy@masig1.ocean.fsu.edu And you thought the exp() function had trouble --- look at what happens when you give a negative argument to sqrt() while using the floating-point accelerator ! Probably not what you expected! By the way, this gives reasonable results without the fpa.... ------------------------------------------------------------------------- program test #include call setfpe ( 0, 0 ) do 10 i=-9,9 print *, float(i), sqrt(float(i)) 10 continue end ------------------------------------------------------------------------- -9.000000 -6.159989 -8.000000 -3.464574 -7.000000 +5.890877 -6.000000 +2.086059E+01 -5.000000 -8.948573 -4.000000 -2.449822 -3.000000 +1.475061E+01 -2.000000 -1.732287 -1.000000 -1.224911 +0.000000E+00 +0.000000E+00 +1.000000 +1.000000 +2.000000 +1.414214 +3.000000 +1.732051 +4.000000 +2.000000 +5.000000 +2.236068 +6.000000 +2.449490 +7.000000 +2.645751 +8.000000 +2.828427 +9.000000 +3.000000 ------------------------------------------------------------------------- John D. McCalpin mccalpin@nu.cs.fsu.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01023; 8 Jul 88 21:59 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00668; 8 Jul 88 20:25 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03073; 8 Jul 88 14:37 EDT Received: from orville.nas.nasa.gov by SMOKE.BRL.ARPA id aa27658; 8 Jul 88 14:24 EDT Received: Fri, 8 Jul 88 11:22:35 PDT by orville.nas.nasa.gov (5.54/1.2) Date: Fri, 8 Jul 88 11:22:35 PDT From: "David A. Tristram" Message-Id: <8807081822.AA04383@orville.nas.nasa.gov> To: fichten@nps-cs.arpa, info-iris@BRL.ARPA Subject: "mex" on the GT and input focus Mark Fichten complains about the key down hack that allows a user to keep input focus when the mouse leaves his window. Also, Mark doesn't like the NeWS paradigm of input to window mouse is over. Well, the behaviour of the window manager is programmed using a bunch of PostScript, and is therefore supposedly easily customizable, hah, but it is not. In fact, the PostScript that handles the input events is so crufty and has so many interdependencies, that it requires a detailed understanding of the entire body of code to make a modification. SGI's manuals even recommend hooking up an ascii terminal if you are going to attempt to program the NeWS server so that you can recover when you lock it up. But enough of this. There is one more bug in the current input focus paradigm that I would like to see fixed: You hold a mouse button down to keep input focus as the mouse leaves a window. Then you release the button. The 'mouse-up' event goes to the window you are now over, not the original one! This bugs me. My application continues to track the mouse because it hasn't heard that I have released the mouse button. Having the event go to the original window would be an elegant solution, but that's not what happens. This is the kind of thing that PostScript and NeWS are supposed to let us get at and fix, but its just not a trivial hack. Also, I have the feeling there are only a few people at SGI who understand the mex PostScript and they are unlikely to read this, or have time to grovel through and fix it. David Tristram ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06662; 11 Jul 88 13:33 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03779; 11 Jul 88 11:07 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab00290; 11 Jul 88 0:15 EDT Received: from SGI.COM by SMOKE.BRL.ARPA id aa07609; 10 Jul 88 23:07 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.vjs) (for info-iris@brl.arpa) id AA02586; Sun, 10 Jul 88 20:07:09 PDT Received: by elvin.sgi.com (5.51/880418.vjs) (for info-iris@brl.arpa) id AA05331; Sun, 10 Jul 88 20:05:39 PDT From: Frank Dietrich Message-Id: <8807110305.AA05331@elvin.sgi.com> Date: 10 Jul 1988 2005-PDT (Sunday) To: info-iris@BRL.ARPA Cc: Subject: Northern California Iris User Group Meeting Northern California Iris User Group Meeting hosted by Llyod LaComb, Stanford University Thursday, July 14, 1988 1:00pm - 4:30pm Applied Physics Laboratory, Stanford University "Image Processing and Display for Microscopy" Llyod LaComb, Stanford University "Computer Animation and its Role in Engineering" Baron Roberts, Failure Analysis and Associates "Inexpensive Real-time Interactive 3D Simulators" Dr. Michael Zyda, Naval Postgraduate School "Programming Techniques that Release the Graphics Power Locked up in your IRIS", Tom Davis, Silicon Graphics, Inc. Including: Presentation from Silicon Graphics Customer Support "Hotline". The first edition of the Iris Software Exchange Catalog. Please RSVP by calling (415) 960-1940 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02020; 12 Jul 88 8:51 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00379; 12 Jul 88 8:29 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00300; 12 Jul 88 6:29 EDT Received: from SGI.COM by SMOKE.BRL.ARPA id ab00523; 12 Jul 88 5:57 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.vjs) (for dat@orville.nas.nasa.gov) id AA09330; Mon, 11 Jul 88 15:25:32 PDT Received: by elvin.sgi.com (5.51/880418.vjs) (for fichten@nps-cs.arpa) id AA10914; Mon, 11 Jul 88 15:23:32 PDT From: Frank Dietrich Message-Id: <8807112223.AA10914@elvin.sgi.com> Date: 11 Jul 1988 1523-PDT (Monday) To: "David A. Tristram" Cc: fichten@nps-cs.arpa, info-iris@BRL.ARPA Subject: Re: new window manager In-Reply-To: Your message of Fri, 8 Jul 88 11:22:35 PDT. <8807081822.AA04383@orville.nas.nasa.gov> The button up problem was a bug and it has been fixed in the 3.0 maintenance release. There is no question that server programming is hard. However all the PostScript source is delivered (it has to be, of course) and anyone who develops an understanding of it can change it. The ASCII terminal is suggested because during development it is easy to make mistakes that render the server inoperative and the ASCII terminal provides a way to connect to the server and find the problem, to look at the logfile output and to kill the server. This is not true for programming in the user.ps file. This is protected so that if an error is detected while reading it the server ignores the entire contents and runs as if you didn't have a user.ps file. -Mark ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10269; 14 Jul 88 16:05 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03750; 14 Jul 88 14:23 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03541; 14 Jul 88 10:06 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa00270; 14 Jul 88 1:11 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa13107; 13 Jul 88 15:02 PDT Date: Wed, 13 Jul 88 15:03:40 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: system time ... Message-ID: <8807140111.aa00270@SMOKE.BRL.ARPA> Every time I reboot a 4D it is neccessary to reset the system time clock. Is this a bug? Can it be fixed? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11485; 14 Jul 88 19:33 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ac08886; 14 Jul 88 14:51 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04845; 14 Jul 88 11:05 EDT Received: from [128.228.1.2] by SMOKE.BRL.ARPA id aa02772; 14 Jul 88 7:08 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 0415; Thu, 14 Jul 88 07:05:54 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 14 Jul 88 07:57:25 Date: Thu, 14 Jul 88 07:48:34 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: Tmesh routinen in 4D/70G 3.0 Software To: info-iris@BRL.ARPA X-VMS-To: X%"info-iris@brl.arpa" Message-ID: <8807140708.aa02772@SMOKE.BRL.ARPA> Hallo, we have a small problem with the 3.0 Software on a 4D/70G (not GT). We are using tmesh structures in our molcad software. on a 4D/70G with our own tmesh-emulation (running 2.0 Software) and on a GT with 3.0 Software everything is okay (thats why I don't look for the error in our code). Yesterday we upgraded our 70G to the 3.0 Software and it seems that the first triangle after a bgntmesh is not drawn correctly. Has anybody seen this before? Solutions? Suggestions? Thanks in advance Martin Knoblauch TH-Darmstadt Dept. Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt West-Germany BITNET: ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00399; 16 Jul 88 23:54 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00245; 16 Jul 88 22:31 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00240; 16 Jul 88 22:18 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa02317; 16 Jul 88 22:09 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA03081; Sat, 16 Jul 88 12:50:04 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Jul 88 17:51:06 GMT From: Jeff Doughty Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: system time Message-Id: <17466@sgi.SGI.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA > Every time I reboot a 4D it is neccessary to reset the system time clock. > Is this a bug? Can it be fixed? There was a bug in the 2.0 operating system for 4D turbo (aka IP4, single board computer) systems that caused this behavior. It has been fixed in release 3.0. If you have a multiboard system or you ARE running 3.0, post to this news group or email to me at jeffd@sgi.com. Jeff Doughty Silicon Graphics Inc. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10474; 18 Jul 88 23:30 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09921; 18 Jul 88 21:55 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa09919; 18 Jul 88 21:49 EDT Received: from SGI.COM by SPARK.BRL.ARPA id aa05290; 18 Jul 88 21:32 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.vjs) (for info-iris@brl.arpa) id AA12105; Mon, 18 Jul 88 09:37:01 PDT Received: by elvin.sgi.com (5.51/880418.vjs) (for news-engr-all@sgi.SGI.COM) id AA04824; Mon, 18 Jul 88 09:31:05 PDT From: Frank Dietrich Message-Id: <8807181631.AA04824@elvin.sgi.com> Date: 18 Jul 1988 0931-PDT (Monday) To: info-iris@BRL.ARPA Cc: all@elvin.sgi.com Subject: IRIS User Forum at SIGGRAPH International IRIS User Forum at SIGGRAPH'88 Wednesday, August 3, 1988 Atlanta, Georgia Marriott Marquis Hotel Imperial Ballroom Participate in the International IRIS User Forum in Atlanta. Select from four Special Interest Groups covering a broad spectrum of applications. View groundbreaking software and visual fireworks created live on Iris 4D's and GT's. Interact with colleagues and Silicon Graphics' staff and executives at the General Session. Get to know first-hand where visual computing technology is going. Enjoy southern hospitality at the IRIS User reception. CAD & Geometric Modeling SIG, Salon A, 11:00-1:00pm --------------------------------------------------- Analysis of Real Surface Data David Addleman, Cyberware Laboratory Modeling with NURBS Dr. Richard Riesenfeld, University of Utah Russel Fish, Engineering Geometry Systems Trimmed NURBS on the IRIS 4D-GT Reuel Nash, SGI A Design System for Free-Form Surfaces Dr. Hiroaki Chiyokura, Ricoh Corp. Distributed Graphics and Parallel Processing Michael Muuss, Ballistic Research Laboratory Art & Animation SIG, Salon B, 11:00-1:00 ---------------------------------------- Real Time Graphics Interfaces for Advanced Computer Animation Daniel Borenstein and Jean Charles Hourcade, Thomson Digital Image Rendering of realistic Images Roy Hall, Wavefront Technologies Procedural Animation Gavin S. Miller, Alias Research Inc. Simulating Dynamic Animation Matthew Moore, UC Santa Cruz Computer Graphics in Video Animation Dean Winkler, Post Perfect Visual Simulation SIG, Salon A, 2:00-4:00pm ------------------------------------------- Chair: Dr. Sarah Stead, Bell Helicopter Textron Inc. Using the IRIS as a Simulator Control Station Mike Snook, McDonnell Douglas Helicopter The 4D-GT as a Ship Simulator Dr. Micahel Zyda, Naval Postgraduate School Real Time Programming Features Jim Barton, SGI Silicon Graphics Q&A Dick Deonigi and Jim Barton, SGI Scientific Visualization SIG, Salon B, 2:00-4:00pm -------------------------------------------------- Software Environments and Cooperation in Scientific Research Donna Cox and Ray Idaszak, Univ. of Illinois and NCSA, Urbana Interactive Data Visualization Creon Levitt and David Tristram, NASA Ames Research Center Visualization Tools for Electron Optics Design Joanna Alexander and Norman Winarsky, David Sarnoff Research Center Real Time Volume Rendering of Biological Structures Dr. Vincent Argiro, Maharishi International University Simulation of Networks of Neurons Dr. Michael Mascagni, National Institutes of Health IRIS User Forum: General Session, Salon B, 5:00-7:30pm --------------------------------------------- Chair: Maxine Brown, Univ. of Illinois, Chicago Keynote Speech Dr. Larry Smarr, Director National Center for Supercomputing Applications Simulation of Plants and Growth Dr. Przemyslaw Prusinkiewicz, Univ. of Regina Mars Sample Return Mission Guenter Sabionski, NASA Johnson Space Center Info-IRIS Network Group Charles M. Kennedy, Ballistic Research Laboratory IRIS Software Exchange Frank Dietrich, SGI Multi Processing Technology and the Future of Graphics Workstations Dr. Jim Clark, Chairman of the Board, SGI Dr. Forest Baskett, VP of Research and Development, SGI Executive Roundtable Discussion IRIS User Reception, Salon A, 7:30-9:00pm ----------------------------------------- You are welcome to participate, registration is free. See you at SIGGRAPH. Frank Dietrich User Services Manager Silicon Graphcis, Inc. 2011 N. Shoreline Blvd. Mt. View, CA 94039-7311 (415) 962-3348 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10506; 18 Jul 88 23:41 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09996; 18 Jul 88 22:07 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa09923; 18 Jul 88 21:50 EDT Received: from UCBVAX.Berkeley.EDU by SPARK.BRL.ARPA id aa05359; 18 Jul 88 21:38 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA17904; Mon, 18 Jul 88 17:43:13 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Jul 88 19:21:46 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: ksh on 4D Message-Id: <1000@virginia.acc.virginia.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I have been trying to get the Korn shell "ksh" to run on my 4D/70 (software release 2.2) and I need help. If I "make" it for system V then the wild card expansion in statements like "rm *.o" does not work correctly. If I make it for BSD then it thinks that I should have job control. My local unix guru tells me that I need to "fix the source code". I am very new at unix and/or silicon graphics and quite frankly I need help. Does anyone have a working version of ksh and/or the patched source code for the 4D? We have what my academic computing center claims to be a "site license" for ksh so it would actually be legal for me to get it from almost any source. Thanks for your help. Michael L. Johnson mlj8e@mljsg.pharm.Virginia.EDU (804)-924-2496 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01324; 21 Jul 88 0:48 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00773; 20 Jul 88 23:31 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00763; 20 Jul 88 23:19 EDT Received: from NRTC.NORTHROP.COM by SPARK.BRL.ARPA id aa00648; 20 Jul 88 23:11 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa20633; 20 Jul 88 16:03 PDT Date: Wed, 20 Jul 88 15:55:41 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: I/O ... Message-ID: <8807202311.aa00648@SPARK.BRL.ARPA> When I open a graphics window for a program, how do I associate it with 'stdin', 'stdout', 'stderr', in place of the original 'console' window? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01002; 22 Jul 88 5:03 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00880; 22 Jul 88 3:50 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00869; 22 Jul 88 3:33 EDT Received: from UCBVAX.Berkeley.EDU by SPARK.BRL.ARPA id aa00994; 22 Jul 88 3:24 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA28792; Thu, 21 Jul 88 20:34:36 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Jul 88 19:49:21 GMT From: Paul Margolin Organization: Raytheon Company, Marlborough MA Subject: Info requested on System V SCSI Driver Message-Id: <228@turbo.RAY.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I am about to write a SCSI device driver for System V Unix as supplied to us by Silicon Graphics. I will also be writing a formatter/exerciser (FEX) for SCSI disks. It looks like we will be using the NCR ADP-32 SCSI Host Adapter board for the Multibus. Is there anyone out there that can point me to documents, sample source code, tips, hints...? Please e-mail. I will post if people are interested. Thanks in advance, -Paul =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Paul Margolin Raytheon Company MS 3-1-3124 1001 Boston Post Road Marlborough, MA 01752 Phone: (508)490-3724 INTERNET: paul@turbo.ray.com UUCP: {cbosgd, gatech, linus, mirror, necntc, uiucdcs}!rayssd!turbo!paul -- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01023; 22 Jul 88 5:14 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab00880; 22 Jul 88 3:50 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id ab00869; 22 Jul 88 3:33 EDT Received: from UCBVAX.Berkeley.EDU by SPARK.BRL.ARPA id aa00996; 22 Jul 88 3:26 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA28971; Thu, 21 Jul 88 20:47:29 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Jul 88 23:42:13 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: ksh on 4D Message-Id: <17739@sgi.SGI.COM> References: <1000@virginia.acc.virginia.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <1000@virginia.acc.virginia.edu>, mlj8e@dale.acc.Virginia.EDU (Michael L. Johnson) writes: > I have been trying to get the Korn shell "ksh" to run on my 4D/70 > (software release 2.2) and I > need help. If I "make" it for system V then the wild card expansion > in statements like "rm *.o" does not work correctly. If I make it for BSD > then it thinks that I should have job control. My local unix guru > tells me that I need to "fix the source code". > > Michael L. Johnson > mlj8e@mljsg.pharm.Virginia.EDU The big problem is that the older versions of KSH did not deal with the V.3 directory access routines correctly. If you take a look at expand.c, you'll notice it refers to a 'struct dirent', which is Berkeley flavor. V.3 uses a 'struct direct' which is slightly different. I fixed it by modifying to the V.3 scheme and turning on the BSD define locally in the file. You'll also want to use '-lsun -lbsd' on the link line, so as to pull in proper yellow pages and NFS support. Also, turn on the VIRAW define and run in raw all the time. You'll avoid lots of problems. Finally, compile everything with the -signed option, which treats characters as signed (which is compatabile with most systems). MIPS does unsigned chars by default because they are much simpler to generate code for. -- Jim Barton Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' -- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03377; 22 Jul 88 9:38 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01710; 22 Jul 88 7:12 EDT Received: from brl-vgr.arpa by VMB.BRL.ARPA id aa01294; 22 Jul 88 6:58 EDT Date: Fri, 22 Jul 88 6:41:50 EDT From: Doug Gwyn (VLD/VMB) To: Jim Barton cc: info-iris@BRL.ARPA Subject: Re: ksh on 4D Message-ID: <8807220641.aa01423@VGR.BRL.ARPA> SVR3 has struct dirent and 4.3BSD has struct direct, not the other way around. The SVR3 struct direct is the raw 16-byte filesystem entry format (same as 7th Edition UNIX) and should never be used by portable applications. IEEE 1003.1 specifies struct dirent. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08052; 22 Jul 88 15:45 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05911; 22 Jul 88 12:58 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05862; 22 Jul 88 12:48 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa05881; 22 Jul 88 12:36 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA09541; Fri, 22 Jul 88 07:40:15 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jul 88 13:17:32 GMT From: Thomas Palmer Organization: NCI Supercomputer Center, Frederick, MD Subject: Re: ksh on 4D Message-Id: <531@fcs280s.ncifcrf.gov> References: <1000@virginia.acc.virginia.edu>, <17739@sgi.SGI.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <17739@sgi.SGI.COM>, jmb@patton.SGI.COM (Jim Barton) writes: > The big problem is that the older versions of KSH did not deal with the > V.3 directory access routines correctly. If you take a look at expand.c, > you'll notice it refers to a 'struct dirent', which is Berkeley flavor. > V.3 uses a 'struct direct' which is slightly different. I fixed it by > modifying to the V.3 scheme and turning on the BSD define locally in the file. . . . > -- Jim Barton > Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" > jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb Why don't you post your ksh fixes? -Tom Thomas C. Palmer NCI Supercomputer Facility c/o PRI, Inc. Phone: (301) 698-5797 PO Box B, Bldg. 430 Uucp: ...!uunet!ncifcrf.gov!palmer Frederick, MD 21701 Arpanet: palmer@ncifcrf.gov ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08954; 22 Jul 88 18:24 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa08861; 22 Jul 88 17:22 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab08845; 22 Jul 88 17:11 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa00170; 22 Jul 88 17:02 EDT Date: Fri, 22 Jul 88 13:58:08 PDT From: Marty Cohen To: info-iris@BRL.ARPA cc: mcohen@nrtc.northrop.com Subject: cheep disks Message-ID: <8807221702.aa00170@SMOKE.BRL.ARPA> I am probably the 2^29 person to asks this but, here goes ... I am looking at an ad for Toshiba disks with 18ms seek time and ESDI (or SCSI) interface. The price is $1295 for a 150MB disk and $2195 for a 330MB disk. We have a 3130 with the standard (= too small) disk. Can these Toshiba disks be added to our system, and how much work is involved? Thanks, Marty Cohen (mcohen@nrtc.northrop.com) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13866; 26 Jul 88 4:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa13431; 26 Jul 88 2:14 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa13355; 26 Jul 88 2:00 EDT Received: from [192.12.141.129] by SPARK.BRL.ARPA id aa05579; 26 Jul 88 2:00 EDT Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA07135; Tue, 26 Jul 88 01:58:31 EDT Message-Id: <8807260558.AA07135@uunet.UU.NET> Received: from cidam (via goanna) by munnari.oz with SunIII (5.5) id AA06682; Tue, 26 Jul 88 15:53:18 EST (from bernie@cidam for uunet!info-iris@brl.arpa) Received: by cidam.rmit.oz (5.51/4.7) id AA05722; Tue, 26 Jul 88 15:16:41 EST Date: Tue, 26 Jul 88 15:16:41 EST From: Bernard Kirby To: info-iris@BRL.ARPA Subject: the /debug partition We recently had one of our machines upgraded to a 4D-70GT running version 3 of the operating system (4sight 1.0 etc). After all the software was installed we noticed that a "df" showed an "extra" partition /dev/debug of type dbg mounted on /debug. It was about 50Mb in size! There appeared to be files in the /debug directory, but whenever you tried to look at them, nothing happened, like they were zero length files, except that "ls -l" showed that some of them were quite large in size. The number and size of files varied as the machine was used. This partition was not in /etc/fstab but was in /etc/mtab. So, one day in a fit of experimentality we simply "umount"ed it, and it hasn't reappeared since, even after a reboot. Now for the questions. a) Is this a "hidden" partition that is secretly present on all SGI machine's disks, only manifesting itself when explicitly mounted? b) Is it really about 50Mb in size, or is that simply a function of "df" misinterpreting a file system of type dbg. OR c) Did the Version 3 system repartition our disk without telling us? If it did, then it must have zapped some files. d) Can we use it for something else, like an NFS partition? e) If we can't use it for anything else, can we reclaim the disk space? (If in fact is really is using disk space) f) What the F**k's it for? Why did it just show up unannounced, with no documentation about what it's doing. Thanks, Bernie Kirby. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21723; 26 Jul 88 16:21 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19474; 26 Jul 88 13:08 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa19367; 26 Jul 88 13:03 EDT Received: from UCBVAX.Berkeley.EDU by SPARK.BRL.ARPA id aa07582; 26 Jul 88 12:52 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA14810; Tue, 26 Jul 88 09:33:52 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Jul 88 08:01:29 GMT From: "George S. Kong" Organization: Silicon Graphics Inc, Mountain View, CA Subject: position open for graphics/system person Message-Id: <17905@sgi.SGI.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I'm looking for a person with a strong background in both systems and 3D graphics. I have a position open on a team responsible for graphics system software and microcode for a family of super-high-performance graphics workstations. The team is currently completing the implementation of a RISC-based multi-processor workstation with 3D polygon-rendering hardware that can draw 100,000 independent, 4-sided, phong-lighted, gouraud-shaded, clip-tested, z-buffered, 10x10-pixel polygons per second. The team also has begun architecting future-generation workstations with even higher performance goals and with more graphics functionality implemented in hardware. The applicant must be able to design and implement graphics functions that span multiple CPUs and micro-programmable graphics engines. Good design and implementation skills and industry experience are required. Silicon Graphics is the leading manufacturer of high-performance 3D graphics workstations. We're a six-year-old company located in Mountain View, CA. We're a rapidly-growing company, with current annual revenues of $150,000,000 and a revenue growth rate of 100% annually. Silicon Graphics' stock is publicly traded, but we're still offering stock options to new employees. We offer outstanding compensation and work environment and a corporate culture that is characterized by enthusiasm, technical excellence, teamwork, fun, and a strong sense of pride. If you're interested, please send me your resume, preferably by e-mail, otherwise by US mail. If you'll be attending SIGGRAPH this year, you can contact me through the Silicon Graphics booth. George S. Kong, Silicon Graphics, Inc., (415)962-3281 2011 N. Shoreline Blvd., Mountain View, CA, 94039-7311 gsk@sgi.com ...{decwrl,allegra,sun,adobe,ucbvax,pyramid,ames}!sgi!gsk ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22063; 26 Jul 88 17:07 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22019; 26 Jul 88 16:56 EDT Received: from brl-spark.arpa by VMB.BRL.ARPA id aa21997; 26 Jul 88 16:48 EDT Received: from orville.nas.nasa.gov by SPARK.BRL.ARPA id aa10323; 26 Jul 88 16:36 EDT Received: Tue, 26 Jul 88 13:28:27 PDT by orville.nas.nasa.gov (5.51/1.2) Message-Id: <8807262028.AA22948@orville.nas.nasa.gov> To: Bernard Kirby Cc: info-iris@BRL.ARPA Subject: Re: the /debug partition In-Reply-To: Your message of Tue, 26 Jul 88 15:16:41 EST. <8807260558.AA07135@uunet.UU.NET> Date: 26 Jul 88 13:28:24 PDT (Tue) From: creon@orville.nas.nasa.gov The /debug partition is basically /dev/proc. The files change as processes are born and die (I guess). ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01432; 27 Jul 88 5:37 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab01412; 27 Jul 88 5:26 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab01404; 27 Jul 88 5:14 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa11966; 27 Jul 88 4:55 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA02234; Wed, 27 Jul 88 00:51:47 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 88 03:26:19 GMT From: Kelvin Thompson Organization: U. Texas CS Dept., Austin, Texas Subject: 'boxview' -- part 2 of 2 Message-Id: <3061@cs.utexas.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA This is the second of two shar files that contain source for 'boxview', a 3D object viewer. The program displays a faceted object (read from a data file) and lets the user rotate it and alter the viewing geometry used to project it. 'Boxview' is different from other viewers because it uses a unique, intuitive user interface that provides excellent feedback to the user. (I consider the standard set of Iris demos to have *awful* feedback.) 'Boxview' will run only on an Iris, because it makes extensive use of the Iris' architecture. I've tested it on a 3000-series Iris running a fairly old OS, and fairly new 4D. The program may not work well on Irises with 8 or fewer bitplanes. I decided to post the program after I noticed that Siggraph next week will have a paper entitled (roughly) "A Study in 3D Rotation with a 2D Pointing Device," which is exactly what I think 'boxview' is good at. I thought I might grab myself some credit by letting people compare my rotater with the one(s?) from the published paper. Instructions for unpacking and running: (1) Save this article and the accompanying one into two Iris files. (2) Trim the text before and after the "--- cut here ---" lines in each of the two files. (3) Unpack the files by typing "sh file1" and "sh file2". (4) If you have a 4D system, edit 'Makefile' and remove the "-Zf" from the 'CFLAGS' definition. (5) Run "make" without parameters. (6) Read the documentation in README and 'boxview.1l' (the latter by typing "nroff -man boxview.1l".) (7) Run the program by typing either "boxview" or "boxview sticks.geom". (8) Exit 'boxview' by hitting the escape key. Have fun. I've got gobs more '.geom' files -- most stolen from DEC's OFF release a year ago. Send questions or comments to me at: kelvin@cs.utexas.edu {backbone}!cs.utexas.edu!kelvin If you want to see a live demo at Siggraph, you can contact me (Kelvin Thompson) at the Nth Graphics booth, or at the Radisson Hotel. I will have a tar-tape (cartridge), but not an Iris (but maybe we can find one). #------------------- cut this line and above ---------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by cs.utexas.edu!kelvin on Tue Jul 26 21:19:44 CDT 1988 # Contents: boxobj.c boxview.c manip.c rotate.c view.c xh.c echo x - boxobj.c sed 's/^@//' > "boxobj.c" <<'@//E*O*F boxobj.c//' /* FILENAME: boxobj.c AUTHOR: Kelvin Thompson, 10/87 DESCRIPTION: Routines for handling the object(s) displayed in the viewbox. You can modify this file to have 'boxview' display objects of your own creation. Just write a new version of 'init_obj' (which 'boxview' calls shortly after startup) and 'draw_obj' (which 'boxview' calls every time it wants to draw the object). See the function code itself for more information. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include #include #include "ktypes.h" #include "idraw.h" /* programs in this file */ extern void init_obj(); extern void draw_obj(); extern void gen_sphere(); extern int gen_geomobj(); /* globals */ static Object theobj; /* ************************************ * * * init_obj * * * ************************************ DESCRIPTION: Initialize the object to be shown. This routine is called once, shortly after 'boxview' starts up. Graphics operations have been initialized, but the user has not yet seen anything on the screen. This routine should do its initializations based only on input provided by the entry parameters 'argc' and 'argv'. This routine should not ask the user for information. Programmers should use calls of the form cm_mapcolor( seg1, s1_OBJSTART+idx, R, G, B ); to define color map entries. 'seg1' and 's1_OBJSTART' are globals; idx varies for different index values; R,G,B are the color entries in the table. Corresponding references to the color map should take the form color( s1_OBJSTART+idx ); ENTRY: argc,argv -- Standard Unix input. */ void init_obj ( argc, argv ) int argc; char *argv[]; { FILE *geomfile; /* init */ theobj = genobj(); if ( argc == 2 ) { makeobj( theobj ); if ( ! gen_geomobj(argv[1]) ) gen_sphere(); closeobj(); } else { makeobj( theobj ); gen_sphere(); closeobj(); } } /* ************************************ * * * draw_obj * * * ************************************ DESCRIPTION: Draw the object. This routine is called every time 'boxview' wants to redraw the object it is showing. It is called every refresh time (up to 60 times a second) even if the user performs no action, so moving objects can be displayed in this routine. The drawn object should fit inside the cube from (-1,-1,-1) to (1,1,1). Only drawing and model-transforming calls should be made inside this routine (i.e. no viewing or windowing calls). */ void draw_obj ( ) { pushmatrix(); callobj( theobj ); popmatrix(); } /* ************************************ * * * gen_sphere * * * ************************************ DESCRIPTION: Generate a colorful sphere-like object. This is intended to be a cheap default object, in case the real object can't be obtained. */ void gen_sphere ( ) { /* three colors in sphere */ cm_mapcolor( seg1, s1_OBJSTART+0, 255, 100, 100 ); cm_mapcolor( seg1, s1_OBJSTART+1, 100, 255, 100 ); cm_mapcolor( seg1, s1_OBJSTART+2, 100, 100, 255 ); color( s1_OBJSTART+0 ); circ( 0.0, 0.0, 0.5 ); rotate( 90*10, 'x' ); color( s1_OBJSTART+1 ); circ( 0.0, 0.0, 0.5 ); rotate( 90*10, 'y' ); color( s1_OBJSTART+2 ); circ( 0.0, 0.0, 0.5 ); } /* ************************************ * * * gen_geomobj * * * ************************************ DESCRIPTION: Load an object consisting of polygons from a file and store it in an Iris display list. The object will render as a wireframe. ENTRY: Filename of a geometry file. EXIT: Returns FALSE if something went wrong, TRUE otherwise. */ #define MAX_POLY_EDGES 10 int gen_geomobj ( filename ) char *filename; { register i,j,temp; int vcount,pcount,ecount,vindex; register VEC3 *vertex,*vptr; register float thisdist,maxdist; VEC3 thispoly[MAX_POLY_EDGES]; FILE *gstream; /* open the file */ gstream = fopen( filename, "r" ); if ( gstream == 0 ) return FALSE; /* read top line */ temp = fscanf( gstream, "%d %d %d", &vcount, &pcount, &ecount ); if ( temp != 3 ) { fclose(gstream); return FALSE; } /* allocate for vertex array */ vertex = (VEC3 *) malloc( vcount * sizeof(VEC3) ); if ( vertex == 0 ) { fclose(gstream); return FALSE; } /* read in vertex array */ maxdist = 0.0; for ( i = 0, vptr = vertex; i < vcount; i++, vptr++ ) { /* read in the point */ temp = fscanf( gstream, "%f %f %f", &vptr->x, &vptr->y, &vptr->z ); if ( temp != 3 ) { free(vertex); fclose(gstream); return FALSE; } /* update maximum distance */ thisdist = vptr->x * vptr->x + vptr->y * vptr->y + vptr->z * vptr->z; if ( thisdist > maxdist ) maxdist = thisdist; } /* scale vertex array */ maxdist = 1.0 / sqrt(maxdist); for ( i = 0, vptr = vertex; i < vcount; i++, vptr++ ) { vptr->x *= maxdist; vptr->y *= maxdist; vptr->z *= maxdist; } /* define and set object color */ cm_mapcolor( seg1, s1_OBJSTART, 255, 100, 100 ); color( s1_OBJSTART ); /* read in polygons */ for ( i=0; i "boxview.c" <<'@//E*O*F boxview.c//' /* FILENAME: boxview.c AUTHOR: Kelvin Thompson, 10/87 DESCRIPTION: Central routines for boxview program. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #define CENTRAL #include #include #include #include #include #include "ktypes.h" #include "idraw.h" /* programs in this file */ extern main(); extern void init_iris(); extern void init_globs(); extern void st_draw(); extern void readystate(); /* programs in 'rotate.c' */ extern void st_axis(); /* programs in 'wm.c' */ extern WINDOW *open_wdw(); /* programs in 'view.c' */ extern VIEW *open_view(); /* local globals */ UNS16 objplanes; /* ********************* * * * main * * * ********************* DESCRIPTION: */ main ( argc, argv ) int argc; char **argv; { /* initialize */ init_iris(); init_globs(); init_manip(); init_view(); init_rot(); init_obj( argc, argv ); /* open main window */ w0ptr = open_wdw( wminx, wmaxx, wminy, wmaxy ); v0ptr = open_view( w0ptr ); open_xh( v0ptr ); /* initialize states */ init_states(); readystate(); while ( TRUE ) { if ( !do_state() ) break; writemask( 0xffffffff ); swapbuffers(); } /* shut down */ close_wdw( w0ptr ); close_states(); gflush(); finish(); ginit(); gexit(); } /* ********************* * * * init_iris * * * ********************* DESCRIPTION: Initialize iris and and a couple of globals. GLOBALS: mexon -- boolean indicating that we're running under 'mex' */ /* color table */ #define LAST_ENTRY 0xfff typedef struct CLR_ENTRY { Colorindex idx; short r,g,b; } CLR_ENTRY; static CLR_ENTRY s0_entry[] = { { s0_2CURSOR, 255, 0, 0 }, { s0_3WDW, 200, 200, 200 }, { s0_2WDW, 255, 255, 255 }, { s0_AXES, 100, 100, 255 }, { s0_AXNAMES, 200, 0, 0 }, { s0_XH_EDGE, 180, 180, 0 }, { LAST_ENTRY, 0, 0, 0 } }; static CLR_ENTRY s1_entry[] = { { s1_BLACK, 0, 0, 0 }, { s1_BACKG, 0, 0, 0 }, { s1_VW_BACKG, 0, 0, 0 }, { s1_VW_LINES, 0, 0, 255 }, { s1_VW_GRABS, 250, 0, 0 }, { s1_VW_BUTT, 200, 0, 0 }, { s1_VW_AREA, 100, 100, 100 }, { s1_SPLAT, 200, 200, 0 }, { LAST_ENTRY, 0, 0, 0 } }; void init_iris ( ) { register i; register struct CLR_ENTRY *clr; int buffbits; unsigned maxcolor; /* mex preferences */ foreground(); prefposition( 0, XMAXSCREEN, 0, YMAXSCREEN ); /* start & init graphics */ getport( "idraw" ); greset(); /* see if we're running mex */ getsize( &wmaxx, &wmaxy ); mexon = ( wmaxx != 1024 || wmaxy != 1024 ); /* basic initialization */ color( BLACK ); clear(); onemap(); doublebuffer(); swapinterval(1); gconfig(); setvaluator( MOUSEX, (XMAXSCREEN+1)/2, 0, XMAXSCREEN ); setvaluator( MOUSEY, (YMAXSCREEN+1)/2, 0, YMAXSCREEN ); /* enqueue all keyboard buttons */ for ( i=BUT0; iidx != LAST_ENTRY; clr++ ) cm_mapcolor( seg1, clr->idx, clr->r, clr->g, clr->b ); /* color segment 0 */ for ( clr = s0_entry; clr->idx != LAST_ENTRY; clr++ ) cm_mapcolor( seg0, clr->idx, clr->r, clr->g, clr->b ); /* cursor stuff */ setcursor( 0, cm_truecolor(seg0,s0_2CURSOR), 0xffff ); curson(); } /* ************************************ * * * init_globs * * * ************************************ DESCRIPTION: Initialize various globals. PREREQUSITES: Need to run 'init_iris' first. */ void init_globs ( ) { /* set up window bounds */ if ( FALSE && mexon ) /* mex presently uses full screen */ { getorigin( &wminx, &wminy ); wmaxx += wminx - 1; wmaxy += wminy - 1; } else if ( getmonitor() == NTSC ) { wminx = NTSC_XMIN; wminy = NTSC_YMIN; wmaxx = NTSC_XMAX; wmaxy = NTSC_YMAX; } else { wminx = VP_XMIN; wminy = VP_YMIN; wmaxx = VP_XMAX; wmaxy = VP_YMAX; } /* the screen-coord matrix */ map_rects( default_mtx, &screenrect, &ndcrect ); } /* ************************************ * * * st_draw * * * ************************************ DESCRIPTION: The main drawing state. ENTRY: ignored */ void st_draw ( val1, val2 ) { register pickcode; register UNS16 thisleft; static UNS16 prevleft=FALSE; if ( !getbutton(ESCKEY) ) { if ( (thisleft = getbutton(LEFTMOUSE)) && !prevleft ) { if ( !check_view(v0ptr) && !check_rot(v0ptr) && !check_xh(v0ptr) ) readystate(); } else readystate(); prevleft = thisleft; } } /* ************************************ * * * readystate * * * ************************************ DESCRIPTION: */ void readystate ( ) { use_view( v0ptr ); cm_color( seg1, s1_BACKG ); /* writemask( 0xffff ); */ /* color( 0 ); */ clear(); draw_obj(); draw_box(); draw_xh( v0ptr ); draw_view( v0ptr ); add_state( st_draw, 0, 0 ); } @//E*O*F boxview.c// chmod u=rw,g=r,o=r boxview.c echo x - manip.c sed 's/^@//' > "manip.c" <<'@//E*O*F manip.c//' /* FILENAME: manip.c DESCRIPTION: Subroutines for user manipulations. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "idraw.h" /* programs in this file */ extern void init_manip(); extern void make_boxes(); extern void draw_box(); extern check_pick(); /* local variables */ static Object box_obj; /* ************************************ * * * init_manip * * * ************************************ DESCRIPTION: Manipulation initializations. */ void init_manip ( ) { make_boxes(); } /* ************************************ * * * make_boxes * * * ************************************ DESCRIPTION: Make object(s) for the main manipulator box. */ void make_boxes ( ) { /* get the object ID */ box_obj = genobj(); /* the drawn box with axes */ makeobj( box_obj ); cm_color( seg0, s0_3WDW ); /* the extent box */ move( -1.0, -1.0, -1.0 ); draw( -1.0, 1.0, -1.0 ); draw( 1.0, 1.0, -1.0 ); draw( 1.0, -1.0, -1.0 ); draw( -1.0, -1.0, -1.0 ); move( -1.0, -1.0, 1.0 ); draw( -1.0, 1.0, 1.0 ); draw( 1.0, 1.0, 1.0 ); draw( 1.0, -1.0, 1.0 ); draw( -1.0, -1.0, 1.0 ); move( -1.0, -1.0, -1.0 ); draw( -1.0, -1.0, 1.0 ); move( -1.0, 1.0, -1.0 ); draw( -1.0, 1.0, 1.0 ); move( 1.0, -1.0, -1.0 ); draw( 1.0, -1.0, 1.0 ); move( 1.0, 1.0, -1.0 ); draw( 1.0, 1.0, 1.0 ); closeobj(); } /* ************************************ * * * draw_box * * * ************************************ DESCRIPTION: Draw the main manipulator box. */ void draw_box ( ) { callobj( box_obj ); } /* ************************************ * * * check_pick * * * ************************************ DESCRIPTION: See if we pick anything that is drawn. ENTRY: generate -- Pointer to a function which will generate the objects to be matched. param -- parameter passed to this function EXIT: Returns last matched 'passthrough' code. PREREQUISITES: Need to set viewport first. */ check_pick ( wdw, xform, generate, param ) WINDOW *wdw; Matrix xform; void (*generate)(); { register long count; register outcode; register betwflag; register short *codeptr; RECT mousebox; static Matrix pickmatx=I_INIT; /* get the box for the mouse */ if ( ! getmousebox( wdw, &mousebox ) ) return 0; /* figure the transform */ qmap_rects( pickmatx, &mousebox, &ndcrect ); /* check for hits */ pushmatrix(); loadmatrix( pickmatx ); multmatrix( xform ); feedback( fb_buff, FB_MAX ); (*generate)( param ); count = endfeedback( fb_buff ); popmatrix(); /* consolidate into a result */ outcode = 0; betwflag = FALSE; for ( codeptr = fb_buff; (outcode==0) && (count>0); --count ) switch ( *codeptr++ ) { case 8: /* passthrough */ if ( betwflag ) { outcode = *codeptr; betwflag = FALSE; } codeptr++; --count; break; case 16: /* move command */ case 17: /* draw command */ case 18: /* pnt command */ case 48: /* pmv command */ case 49: /* pdr command */ case 51: /* pclos command */ betwflag = TRUE; codeptr += 2; count -= 2; break; case 56: /* xfpt command */ betwflag = TRUE; codeptr += 4; count -= 4; break; default: betwflag = TRUE; break; } return outcode; } @//E*O*F manip.c// chmod u=rw,g=r,o=r manip.c echo x - rotate.c sed 's/^@//' > "rotate.c" <<'@//E*O*F rotate.c//' /* FILENAME: rotate.c (version II) DESCRIPTION: Various programs dealing with rotations. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include #include "idraw.h" #define DRAWSPLAT FALSE #define DRAWCELL FALSE /* programs in this file */ extern void init_rot(); extern check_rot(); extern void pick_rot(); extern void st_axis(); extern void st_rotate(); extern void gen_splat(); extern void drawsplat(); extern void drawcell(); extern void draw_rot(); extern void make_wbox(); extern void gen_wbox(); /* programs in 'xform.c' */ extern void rot_x(),rot_y(),rot_z(); /* other programs */ extern void st_draw(); static Object wbox_obj; typedef struct SPLATCELL { float a,b; float ang; } SPLATCELL; /* tweakable parameters */ #define NUM_TESTS 45 #define SPLAT_ANG (PI/5.3) #define NEG_START 0.0 #define POS_START 0.0 #define RANGE 1.4 /* basic parameters */ #define NUM_AXES 3 #define NUM_CORNERS 4 #define NUM_DIRS 3 /* derived parameters */ #define NUM_SPLATS (NUM_TESTS|1) /* make it odd */ #define SPLAT_SEP (SPLAT_ANG/(NUM_SPLATS-2.0)) /* corner constructs */ #define CORNER(a,b) (((a&1)?2:0) | ((b&1)?1:0)) static SPLATCELL cornsplat[NUM_CORNERS] = { { -1.0, -1.0, -0.75*PI }, { -1.0, 1.0, 0.75*PI }, { 1.0, -1.0, -0.25*PI }, { 1.0, 1.0, 0.25*PI } }; /* direction symbols */ #define NO_DIR 0 #define POS_DIR 1 #define NEG_DIR 2 /* axis symbols */ #define X_AXIS TOKCOD_X #define Y_AXIS TOKCOD_Y #define Z_AXIS TOKCOD_Z /* splat arrays */ static SPLATCELL splat[NUM_CORNERS][NUM_DIRS][NUM_SPLATS]; static Object splatobj[NUM_AXES][NUM_CORNERS][NUM_DIRS]; /* state of rotate action */ typedef struct ROTSTATE { void (*func)(); float ang; UNS8 axis; UNS8 corner; UNS8 dir; } ROTSTATE; static ROTSTATE rstate; /* ********************* * * * init_rot * * * ********************* DESCRIPTION: Initialize rotation stuff. */ void init_rot ( ) { register corner,i,dir; float relang,absang; float aa,bb; /* first splat for each direction and corner is zero offset angle */ for ( corner=0; corner>1) * SPLAT_SEP ); for ( corner=0; cornerwdw; viewport( wdw->edge.a.x, wdw->edge.b.x, wdw->edge.a.y, wdw->edge.b.y ); pickcode = check_pick( vptr->wdw, &vptr->total, gen_wbox ); switch ( pickcode & TOKTYP_MASK ) { case TOKTYP_ROT: /* reactive rotation */ pick_rot( pickcode & TOKCOD_MASK ); draw_rot( vptr ); out = TRUE; break; default: /* can't interpret -- punt */ out = FALSE; break; } return out; } /* ********************* * * * pick_rot * * * ********************* DESCRIPTION: Perform actions after picking a rotate bar. ENTRY: Code for selected object. */ void pick_rot ( code ) UNS16 code; { static void (*rotfunc[NUM_AXES])() = { rot_x, rot_y, rot_z }; rstate.axis = code & TOKCOD_DIR; rstate.dir = NO_DIR; rstate.corner = (code & TOKPT(1,1)) >> 2; rstate.func = rotfunc[rstate.axis]; rstate.ang = 0.0; add_state( st_rotate, 0, 0 ); } /* ************************************ * * * st_axis * * * ************************************ DESCRIPTION: The axis rotation state. ENTRY: axis -- Axis of rotation. dum -- ignored dummy parameter */ void st_axis ( axis, dum ) UNS8 axis; { if ( !getbutton(LEFTMOUSE) ) readystate(); else { switch ( axis ) { case TOKCOD_X: rot_x( & v0ptr->box_to_rot, 2.0*PI/200.0 ); break; case TOKCOD_Y: rot_y( & v0ptr->box_to_rot, 2.0*PI/200.0 ); break; case TOKCOD_Z: rot_z( & v0ptr->box_to_rot, 2.0*PI/200.0 ); break; } draw_rot( v0ptr ); add_state( st_axis, axis, 0 ); } } /* ********************* * * * st_rotate * * * ********************* DESCRIPTION: Reactive rotation ENTRY: dum1,dum2 -- ignored */ void st_rotate ( dum1, dum2 ) { register i; register SPLATCELL *splatptr; register float ang; UNS16 pickcode; /* go back to waiting state if no mouse button */ if ( !getbutton(LEFTMOUSE) ) readystate(); else { # if DRAWSPLAT drawsplat(); # endif pickcode = check_pick( v0ptr->wdw, &v0ptr->total, gen_splat ); if ( pickcode == 0 ) { if ( rstate.dir != NO_DIR ) (*rstate.func)( & v0ptr->box_to_rot, rstate.ang ); rstate.dir = NO_DIR; } else { # if DRAWCELL drawcell( pickcode-1 ); # endif rstate.ang = ang = splat[rstate.corner][rstate.dir][pickcode-1].ang; if ( ang == 0.0 ) rstate.dir = NO_DIR; else { (*rstate.func)( & v0ptr->box_to_rot, ang ); rstate.dir = (ang>0.0) ? POS_DIR : NEG_DIR; } } draw_rot( v0ptr ); add_state( st_rotate, 0, 0 ); } } /* ************************************ * * * gen_splat * * * ************************************ DESCRIPTION: ENTRY: */ void gen_splat ( ) { callobj( splatobj[rstate.axis][rstate.corner][rstate.dir] ); } #if DRAWSPLAT /* ********************* * * * drawsplat * * * ********************* DESCRIPTION: ENTRY: */ void drawsplat ( ) { register i; register SPLATCELL *splatptr; cm_color( seg1, s1_SPLAT ); switch ( rstate.axis ) { case X_AXIS: for ( i = 0, splatptr = splat[rstate.corner][rstate.dir]; i < NUM_SPLATS; i++, splatptr++ ) { move( -RANGE, splatptr->a, splatptr->b ); draw( RANGE, splatptr->a, splatptr->b ); } break; case Y_AXIS: for ( i = 0, splatptr = splat[rstate.corner][rstate.dir]; i < NUM_SPLATS; i++, splatptr++ ) { move( splatptr->b, -RANGE, splatptr->a ); draw( splatptr->b, RANGE, splatptr->a ); } break; case Z_AXIS: for ( i = 0, splatptr = splat[rstate.corner][rstate.dir]; i < NUM_SPLATS; i++, splatptr++ ) { move( splatptr->a, splatptr->b, -RANGE ); draw( splatptr->a, splatptr->b, RANGE ); } break; } } #endif #if DRAWCELL /* ********************* * * * drawcell * * * ********************* DESCRIPTION: ENTRY: */ void drawcell ( idx ) UNS16 idx; { register SPLATCELL *splatptr; splatptr = & splat[rstate.corner][rstate.dir][idx]; finish(); @@@color( RED ); switch ( rstate.axis ) { case X_AXIS: move( -RANGE, splatptr->a, splatptr->b ); draw( RANGE, splatptr->a, splatptr->b ); break; case Y_AXIS: move( splatptr->b, -RANGE, splatptr->a ); draw( splatptr->b, RANGE, splatptr->a ); break; case Z_AXIS: move( splatptr->a, splatptr->b, -RANGE ); draw( splatptr->a, splatptr->b, RANGE ); break; } } #endif /* ************************************ * * * make_wbox * * * ************************************ DESCRIPTION: ENTRY: */ void make_wbox ( ) { wbox_obj = genobj(); /* the marked box with axes (for feedback) */ makeobj( wbox_obj ); /* do the edges of the box */ move( -1.0, -1.0, -1.0 ); draw( -1.0, 1.0, -1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Y | TOKPT(0,0) ); draw( 1.0, 1.0, -1.0 ); passthrough( TOKTYP_ROT | TOKCOD_X | TOKPT(1,0) ); draw( 1.0, -1.0, -1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Y | TOKPT(0,1) ); draw( -1.0, -1.0, -1.0 ); passthrough( TOKTYP_ROT | TOKCOD_X | TOKPT(0,0) ); move( -1.0, -1.0, 1.0 ); draw( -1.0, 1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Y | TOKPT(1,0) ); draw( 1.0, 1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_X | TOKPT(1,1) ); draw( 1.0, -1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Y | TOKPT(1,1) ); draw( -1.0, -1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_X | TOKPT(0,1) ); move( -1.0, -1.0, -1.0 ); draw( -1.0, -1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Z | TOKPT(0,0) ); move( -1.0, 1.0, -1.0 ); draw( -1.0, 1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Z | TOKPT(0,1) ); move( 1.0, -1.0, -1.0 ); draw( 1.0, -1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Z | TOKPT(1,0) ); move( 1.0, 1.0, -1.0 ); draw( 1.0, 1.0, 1.0 ); passthrough( TOKTYP_ROT | TOKCOD_Z | TOKPT(1,1) ); #if 0 /* do the axes */ move( 0.0, 0.0, 0.0 ); draw( 1.5, 0.0, 0.0 ); passthrough( TOK_XAXIS ); move( 0.0, 0.0, 0.0 ); draw( 0.0, 1.5, 0.0 ); passthrough( TOK_YAXIS ); move( 0.0, 0.0, 0.0 ); draw( 0.0, 0.0, 1.5 ); passthrough( TOK_ZAXIS ); #endif closeobj(); } /* ************************************ * * * gen_wbox * * * ************************************ DESCRIPTION: ENTRY: */ void gen_wbox ( ) { callobj( wbox_obj ); } /* ************************************ * * * draw_rot * * * ************************************ DESCRIPTION: */ void draw_rot ( vptr ) VIEW *vptr; { use_view( vptr ); cm_color( seg1, s1_BACKG ); clear(); draw_obj(); draw_box(); draw_xh( vptr ); } @//E*O*F rotate.c// chmod u=rw,g=r,o=r rotate.c echo x - view.c sed 's/^@//' > "view.c" <<'@//E*O*F view.c//' /* FILENAME: view.c DESCRIPTION: Programs for manipulating viewing geometry. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "idraw.h" /* programs in this file */ extern void init_view(); extern VIEW *open_view(); extern void use_view(); extern void calc_vwtot(); extern void gen_view(); extern void draw_view(); extern void draw_vmanip(); extern void draw_vbutt(); extern check_view(); extern void runwind(); extern void runwend(); extern void runeye(); extern void runorg(); extern void donevmanip(); extern void draw_main(); /* programs in 'wm.c' */ extern WINDOW *open_wdw(); #define VW_SIZX 100 #define VW_SIZY 80 #define VW_RATIO ((float)VW_SIZY/(float)VW_SIZX) #define VW_BUTTRAD 8 static VIEW *now_vptr; static VIEWGEOM prevgeom; static float prev30,prev31,prev33; /* ************************************ * * * init_view * * * ************************************ DESCRIPTION: */ void init_view ( ) { } /* ************************************ * * * open_view * * * ************************************ DESCRIPTION: EXIT: */ VIEW *open_view ( wdw ) register WINDOW *wdw; { register VIEW *vptr; /* allocate & link */ vptr = (VIEW *)malloc( sizeof(VIEW) ); vptr->wdw = wdw; /* viewing parameters */ vptr->g.R = VP_R; vptr->g.D = VP_D; vptr->g.wx = VP_WX; vptr->g.wy = vptr->g.wx * (float)(wdw->edge.b.y - wdw->edge.a.y + 1) / (float)(wdw->edge.b.x - wdw->edge.a.x + 1); /* matricies */ vptr->box_to_rot.a = I; set_view( &vptr->rot_to_ndc, vptr->g.R, vptr->g.D, vptr->g.wx, vptr->g.wy ); vptr->total.a = vptr->rot_to_ndc.a; calc_vwtot( vptr ); /* button's edges */ vptr->butt.a.x = wdw->edge.a.x; vptr->butt.a.y = wdw->edge.a.y; vptr->butt.b.x = vptr->butt.a.x + VW_BUTTRAD; vptr->butt.b.y = vptr->butt.a.y + VW_BUTTRAD; /* view-manipulation window */ vptr->vw = open_wdw( wdw->edge.a.x, wdw->edge.a.x+VW_SIZX, wdw->edge.a.y, wdw->edge.a.y+VW_SIZY ); vptr->viewon = FALSE; return vptr; } /* ************************************ * * * use_view * * * ************************************ DESCRIPTION: ENTRY: */ void use_view ( vptr ) register VIEW *vptr; { use_wdw( vptr->wdw ); loadmatrix( & vptr->rot_to_ndc ); multmatrix( & vptr->box_to_rot ); getmatrix( & vptr->total ); } /* ************************************ * * * reuse_view * * * ************************************ DESCRIPTION: ENTRY: */ void reuse_view ( vptr ) register VIEW *vptr; { use_wdw( vptr->wdw ); loadmatrix( & vptr->total ); } /* ************************************ * * * check_view * * * ************************************ DESCRIPTION: ENTRY: EXIT: */ check_view ( vptr ) register VIEW *vptr; { register long mx,my; register pickcode; VEC3 vec1,vec2; SCRNRECT srect; pickcode = 0; mx = getvaluator( MOUSEX ); my = getvaluator( MOUSEY ); /* see if we're toggling the view window */ if ( vptr->butt.a.x <= mx && mx <= vptr->butt.b.x && vptr->butt.a.y <= my && my <= vptr->butt.b.y ) { vptr->viewon = ! vptr->viewon; readystate(); pickcode = TRUE; } /* see if we're trying to change the view */ else if ( vptr->viewon ) { /* check for a pick */ vp_wdw( vptr->vw ); loadmatrix( &vptr->vwtot ); now_vptr = vptr; pickcode = check_pick( vptr->vw, &vptr->vwtot, gen_view ); /* see if we hit any view manipulators */ if ( (pickcode & TOKTYP_MASK) != TOKTYP_VW ) { pickcode = 0; } else { /* remember the previous geometry */ prevgeom = vptr->g; switch ( pickcode ) { case TOK_VORG: /* try to map part of the X-axis to screen coords */ vec1.x = 0.0; vec1.y = 0.0; vec1.z = 0.0; vec2.x = vptr->g.D - vptr->g.R; vec2.y = 0.0; vec2.z = 0.0; if ( !getslidepts( &vec1, &vec2, &srect ) ) goto badpick; /* remember stuff */ prev30 = vptr->vwtot.m[3][0]; prev31 = vptr->vwtot.m[3][1]; prev33 = vptr->vwtot.m[3][3]; /* slide */ doslide( &srect, runorg, donevmanip ); break; case TOK_VEYE: /* try to map part of the X-axis to screen coords */ vec1.x = -vptr->g.R; vec1.y = 0.0; vec1.z = 0.0; vec2.x = vptr->g.D - vptr->g.R; vec2.y = 0.0; vec2.z = 0.0; if ( !getslidepts( &vec1, &vec2, &srect ) ) goto badpick; /* slide */ doslide( &srect, runeye, donevmanip ); break; case TOK_VWTOP: /* try to map part of the X-axis to screen coords */ vec1.x = vptr->g.D - vptr->g.R; vec1.y = 0.0; vec1.z = 0.0; vec2.x = vec1.x; vec2.y = vptr->g.wy; vec2.z = 0.0; if ( !getslidepts( &vec1, &vec2, &srect ) ) goto badpick; /* slide */ doslide( &srect, runwend, donevmanip ); break; case TOK_VWBOT: /* try to map part of the X-axis to screen coords */ vec1.x = vptr->g.D - vptr->g.R; vec1.y = 0.0; vec1.z = 0.0; vec2.x = vec1.x; vec2.y = -vptr->g.wy; vec2.z = 0.0; if ( !getslidepts( &vec1, &vec2, &srect ) ) goto badpick; /* slide */ doslide( &srect, runwend, donevmanip ); break; case TOK_VWIND: /* try to map part of the X-axis to screen coords */ vec1.x = -vptr->g.R; vec1.y = 0.0; vec1.z = 0.0; vec2.x = 0.0; vec2.y = 0.0; vec2.z = 0.0; if ( !getslidepts( &vec1, &vec2, &srect ) ) goto badpick; /* slide */ doslide( &srect, runwind, donevmanip ); break; default: badpick: ringbell(); readystate(); break; } } } return pickcode; } /* ************************************ * * * draw_view * * * ************************************ DESCRIPTION: ENTRY: */ void draw_view ( vptr ) register VIEW *vptr; { if ( vptr->viewon ) draw_vmanip( vptr ); draw_vbutt( vptr ); } /* ************************************ * * * draw_vmanip * * * ************************************ DESCRIPTION: Draw view manipulation structures. ENTRY: */ void draw_vmanip ( vptr ) register VIEW *vptr; { register float temp; /* set up the view window */ use_wdw( vptr->vw ); loadmatrix( & vptr->vwtot ); cm_color( seg1, s1_VW_BACKG ); clear(); /* draw the clipping box */ cm_color( seg1, s1_VW_AREA ); circf( 0.0, 0.0, SQRT_2 ); /* draw the axis */ cm_color( seg1, s1_VW_LINES ); move2( -100.0, 0.0 ); draw2( 100.0, 0.0 ); /* draw the window plane */ temp = vptr->g.D - vptr->g.R; move2( temp, -vptr->g.wy ); draw2( temp, vptr->g.wy ); /* draw the fostrum edges */ move2( -vptr->g.R, 0.0 ); rdr2( vptr->g.D * 100.0, -vptr->g.wy * 100.0 ); move2( -vptr->g.R, 0.0 ); rdr2( vptr->g.D * 100.0, vptr->g.wy * 100.0 ); /* draw the selectable markers */ font( GRAB_FONT_IDX ); cm_color( seg1, s1_VW_GRABS ); cmov2( -vptr->g.R, 0.0 ); charstr( "\001" ); cmov2( 0.0, 0.0 ); charstr( "\001" ); cmov2( temp, -vptr->g.wy ); charstr( "\001" ); cmov2( temp, 0.0 ); charstr( "\001" ); cmov2( temp, vptr->g.wy ); charstr( "\001" ); } /* ************************************ * * * draw_vbutt * * * ************************************ DESCRIPTION: ENTRY: */ void draw_vbutt ( vptr ) register VIEW *vptr; { viewport( 0, XMAXSCREEN, 0, YMAXSCREEN ); loadmatrix( default_mtx ); cm_color( seg1, s1_VW_BUTT ); rectfi( vptr->butt.a.x, vptr->butt.a.y, vptr->butt.b.x, vptr->butt.b.y ); } /* ************************************ * * * calc_vwtot * * * ************************************ DESCRIPTION: ENTRY: */ #define VW_PAD 0.1 void calc_vwtot ( vptr ) register VIEW *vptr; { register float wantdx,wantdy,factor; RECT ext; /* calculate the rectangle we want to see */ ext.a.x = -(1.0+VW_PAD) * vptr->g.R; ext.b.x = VW_PAD * vptr->g.R; ext.b.y = (1.0+VW_PAD) * vptr->g.wy; ext.a.y = -ext.b.y; /* calculate width, height, and ratio */ wantdx = ext.b.x - ext.a.x; wantdy = ext.b.y - ext.a.y; /* expand the rect to make its ratio fit */ if ( wantdy / wantdx > VW_RATIO ) { /* window too tall -- need to make wider */ factor = wantdy / (wantdx * VW_RATIO); ext.a.x += (1.0 - factor) * 0.5 * wantdx; ext.b.x = ext.a.x + wantdx * factor; } else { /* window too narrow -- need to make taller */ factor = (wantdx * VW_RATIO) / wantdy; ext.a.y += (1.0 - factor) * 0.5 * wantdy; ext.b.y = ext.a.y + wantdy * factor; } map_rects( &vptr->vwtot, &ext, &ndcrect ); } /* ************************************ * * * gen_view * * * ************************************ DESCRIPTION: */ void gen_view ( ) { register float temp; register VIEW *vptr; vptr = now_vptr; temp = vptr->g.D - vptr->g.R; pnt2( -vptr->g.R, 0.0 ); passthrough( TOK_VEYE ); pnt2( 0.0, 0.0 ); passthrough( TOK_VORG ); pnt2( temp, -vptr->g.wy ); passthrough( TOK_VWBOT ); pnt2( temp, 0.0 ); passthrough( TOK_VWIND ); pnt2( temp, vptr->g.wy ); passthrough( TOK_VWTOP ); } /* ************************************ * * * runwind * * * ************************************ DESCRIPTION: ENTRY: */ void runwind ( tt ) register float tt; { register VIEW *vptr; /* initialize */ vptr = now_vptr; /* adjust 'tt' */ if ( tt < 0.1 ) tt = 0.1; else if ( 0.9 < tt ) tt = 0.9; /* adjust the parameters */ vptr->g.D = tt * prevgeom.R; set_view( &vptr->rot_to_ndc, vptr->g.R, vptr->g.D, vptr->g.wx, vptr->g.wy ); /* draw the main 3-box */ draw_main( vptr ); } /* ************************************ * * * donevmanip * * * ************************************ DESCRIPTION: ENTRY: */ void donevmanip ( tt ) register float tt; { calc_vwtot( now_vptr ); } /* ************************************ * * * runwend * * * ************************************ DESCRIPTION: ENTRY: */ void runwend ( tt ) register float tt; { register VIEW *vptr; /* initialize */ vptr = now_vptr; /* adjust 'tt' */ if ( tt < 0.1 ) tt = 0.1; else if ( 2.0 < tt ) tt = 2.0; /* adjust the parameters */ vptr->g.wy = tt * prevgeom.wy; vptr->g.wx = tt * prevgeom.wx; set_view( &vptr->rot_to_ndc, vptr->g.R, vptr->g.D, vptr->g.wx, vptr->g.wy ); /* draw the main 3-box */ draw_main( vptr ); } /* ************************************ * * * runeye * * * ************************************ DESCRIPTION: ENTRY: */ void runeye ( tt ) register float tt; { register VIEW *vptr; /* initialize */ vptr = now_vptr; /* adjust 'tt' */ if ( tt < -2.0 ) tt = -2.0; else if ( tt > 0.9 ) tt = 0.9; /* adjust the parameters */ vptr->g.R = prevgeom.R - tt * prevgeom.D; vptr->g.D = prevgeom.D - (prevgeom.R - vptr->g.R); set_view( &vptr->rot_to_ndc, vptr->g.R, vptr->g.D, vptr->g.wx, vptr->g.wy ); /* draw the main 3-box */ draw_main( vptr ); } /* ************************************ * * * runorg * * * ************************************ DESCRIPTION: ENTRY: */ void runorg ( tt ) register float tt; { register VIEW *vptr; register float dx; /* initialize */ vptr = now_vptr; /* adjust 'tt' */ if ( tt < -2.0 ) tt = -2.0; else if ( tt > 0.9 ) tt = 0.9; /* adjust the viewing geometry */ vptr->g.R = prevgeom.R - tt * (prevgeom.R - prevgeom.D); set_view( &vptr->rot_to_ndc, vptr->g.R, vptr->g.D, vptr->g.wx, vptr->g.wy ); /* adjust the transform for the view window */ dx = prevgeom.R - vptr->g.R; vptr->vwtot.m[3][0] = prev30 - dx * vptr->vwtot.m[0][0]; vptr->vwtot.m[3][1] = prev31 - dx * vptr->vwtot.m[0][1]; vptr->vwtot.m[3][3] = prev33 - dx * vptr->vwtot.m[0][3]; /* draw the main 3-box */ draw_main( vptr ); } /* ************************************ * * * draw_main * * * ************************************ DESCRIPTION: ENTRY: */ void draw_main ( vptr ) VIEW *vptr; { use_view( vptr ); cm_color( seg1, s1_BACKG ); clear(); draw_obj(); draw_box(); draw_vmanip( vptr ); } @//E*O*F view.c// chmod u=rw,g=r,o=r view.c echo x - xh.c sed 's/^@//' > "xh.c" <<'@//E*O*F xh.c//' /* FILENAME: xh.c DESCRIPTION: Deal with the crosshairs COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include #include "idraw.h" /* programs in this file */ extern void init_xh(); extern void open_xh(); extern void draw_xh(); extern check_xh(); extern void st_xhmov2(); extern void map2d3d(); /*extern unsigned mostest(); */ /* programs in other files */ extern void st_axis(); #define EDGE_FLAG (TOKCOD_p << 1) #define MOUSE_MAX 512 #define FABS(x) fabs(x) typedef struct MOUSEFLAT { VIEW *vptr; int xsign,ysign; } MOUSEFLAT; /* ************************************ * * * init_xh * * * ************************************ DESCRIPTION: Initialize crosshairs. */ void init_xh ( ) { } /* ************************************ * * * open_xh * * * ************************************ DESCRIPTION: Open crosshairs. ENTRY: vptr -- Pointer to VIEW struct to hold crosshair info. */ void open_xh ( vptr ) register VIEW *vptr; { vptr->xhon = TRUE; vptr->xhdir = FALSE; vptr->xhpos.x = 0.0; vptr->xhpos.y = 0.0; vptr->xhpos.z = 0.0; } /* ************************************ * * * draw_xh * * * ************************************ DESCRIPTION: Draw the 3-D crosshairs. ENTRY: EXIT: */ void draw_xh ( vptr ) register VIEW *vptr; { if ( vptr->xhon ) { /* crosshair color */ cm_color( seg0, s0_AXES ); /* X hair */ move( -1.0, vptr->xhpos.y, vptr->xhpos.z ); draw( 1.0, vptr->xhpos.y, vptr->xhpos.z ); /* Y hair */ move( vptr->xhpos.x, -1.0, vptr->xhpos.z ); draw( vptr->xhpos.x, 1.0, vptr->xhpos.z ); /* Z hair */ move( vptr->xhpos.x, vptr->xhpos.y, -1.0 ); draw( vptr->xhpos.x, vptr->xhpos.y, 1.0 ); /* edges */ if ( vptr->xhdir ) { cm_color( seg0, s0_XH_EDGE ); switch ( vptr->xhdir & TOKCOD_DIR ) { case TOKCOD_X: move( vptr->xhpos.x, -1.0, -1.0 ); draw( vptr->xhpos.x, 1.0, -1.0 ); draw( vptr->xhpos.x, 1.0, 1.0 ); draw( vptr->xhpos.x, -1.0, 1.0 ); draw( vptr->xhpos.x, -1.0, -1.0 ); break; case TOKCOD_Y: move( -1.0, vptr->xhpos.y, -1.0 ); draw( -1.0, vptr->xhpos.y, 1.0 ); draw( 1.0, vptr->xhpos.y, 1.0 ); draw( 1.0, vptr->xhpos.y, -1.0 ); draw( -1.0, vptr->xhpos.y, -1.0 ); break; case TOKCOD_Z: move( -1.0, -1.0, vptr->xhpos.z ); draw( 1.0, -1.0, vptr->xhpos.z ); draw( 1.0, 1.0, vptr->xhpos.z ); draw( -1.0, 1.0, vptr->xhpos.z ); draw( -1.0, -1.0, vptr->xhpos.z ); break; } } /* labels */ font( 0 ); cm_color( seg0, s0_AXNAMES ); cmov( 1.0, vptr->xhpos.y, vptr->xhpos.z ); charstr( "X" ); cmov( vptr->xhpos.x, 1.0, vptr->xhpos.z ); charstr( "Y" ); cmov( vptr->xhpos.x, vptr->xhpos.y, 1.0 ); charstr( "Z" ); } } /* ************************************ * * * gen_xh * * * ************************************ DESCRIPTION: Generate feedback instructions for 3D crosshairs. ENTRY: */ void gen_xh ( vptr ) register VIEW *vptr; { move( 0.0, vptr->xhpos.y, vptr->xhpos.z ); draw( -1.0, vptr->xhpos.y, vptr->xhpos.z ); passthrough( TOK_XH_Xn ); move( 0.0, vptr->xhpos.y, vptr->xhpos.z ); draw( 1.0, vptr->xhpos.y, vptr->xhpos.z ); passthrough( TOK_XH_Xp ); move( vptr->xhpos.x, 0.0, vptr->xhpos.z ); draw( vptr->xhpos.x, -1.0, vptr->xhpos.z ); passthrough( TOK_XH_Yn ); move( vptr->xhpos.x, 0.0, vptr->xhpos.z ); draw( vptr->xhpos.x, 1.0, vptr->xhpos.z ); passthrough( TOK_XH_Yp ); move( vptr->xhpos.x, vptr->xhpos.y, 0.0 ); draw( vptr->xhpos.x, vptr->xhpos.y, -1.0 ); passthrough( TOK_XH_Zn ); move( vptr->xhpos.x, vptr->xhpos.y, 0.0 ); draw( vptr->xhpos.x, vptr->xhpos.y, 1.0 ); passthrough( TOK_XH_Zp ); } /* ************************************ * * * check_xh * * * ************************************ DESCRIPTION: See if mouse over crosshairs. ENTRY: EXIT: Returns status code. */ check_xh ( vptr ) register VIEW *vptr; { register UNS16 pickcode; UNS16 pos; register WINDOW *wdw; register out; short xinit,yinit; static MOUSEFLAT thisflat; wdw = vptr->wdw; viewport( wdw->edge.a.x, wdw->edge.b.x, wdw->edge.a.y, wdw->edge.b.y ); pickcode = check_pick( vptr->wdw, &vptr->total, gen_xh, vptr ); if ( (pickcode & TOKTYP_MASK) != TOKTYP_XH ) { out = FALSE; } else { /* init */ pos = pickcode & TOKCOD_p; vptr->xhdir = EDGE_FLAG | (pickcode & TOKCOD_DIRp); /* redraw screen */ cursoff(); draw_rot( vptr ); /* figure mapping of mouse to 3d crosshairs */ thisflat.vptr = vptr; thisflat.xsign = 1; thisflat.ysign = 1; map2d3d( & thisflat ); /* modifies 'thisflat' */ /* reset the mouse scaling */ switch ( vptr->xhdir & TOKCOD_DIRp ) { case TOKCOD_Xp: xinit = vptr->xhpos.y * MOUSE_MAX; yinit = vptr->xhpos.z * MOUSE_MAX; break; case TOKCOD_Xn: xinit = vptr->xhpos.z * MOUSE_MAX; yinit = vptr->xhpos.y * MOUSE_MAX; break; case TOKCOD_Yp: xinit = vptr->xhpos.z * MOUSE_MAX; yinit = vptr->xhpos.x * MOUSE_MAX; break; case TOKCOD_Yn: xinit = vptr->xhpos.x * MOUSE_MAX; yinit = vptr->xhpos.z * MOUSE_MAX; break; case TOKCOD_Zp: xinit = vptr->xhpos.x * MOUSE_MAX; yinit = vptr->xhpos.y * MOUSE_MAX; break; case TOKCOD_Zn: xinit = vptr->xhpos.y * MOUSE_MAX; yinit = vptr->xhpos.x * MOUSE_MAX; break; } xinit *= thisflat.xsign; yinit *= thisflat.ysign; setvaluator( MOUSEX, xinit, -MOUSE_MAX, MOUSE_MAX ); setvaluator( MOUSEY, yinit, -MOUSE_MAX, MOUSE_MAX ); /* set new state */ add_state( st_xhmov2, &thisflat, 0 ); out = TRUE; } return out; } /* ************************************ * * * st_xhmov2 * * * ************************************ DESCRIPTION: Move the crosshair position in 2D. ENTRY: axis -- code for frozen axis */ void st_xhmov2 ( thisflat, dum ) register MOUSEFLAT *thisflat; { register VIEW *vptr; register float xpos,ypos; /* init */ vptr = thisflat->vptr; if ( ! getbutton(LEFTMOUSE) ) { VEC4 xhwld,xhscn; XFORM toscreen; short xx,yy; /* reset variables */ vptr->xhdir = FALSE; /* */ map_rects( &toscreen, &ndcrect, &vptr->wdw->bounds ); mmul( &toscreen, &vptr->total, &toscreen ); xhwld.x = vptr->xhpos.x; xhwld.y = vptr->xhpos.y; xhwld.z = vptr->xhpos.z; xhwld.w = 1.0; vmul( &xhscn, &xhwld, &toscreen ); xx = xhscn.x / xhscn.w; yy = xhscn.y / xhscn.w; /* reset mouse scaling */ setvaluator( MOUSEX, xx, 0, XMAXSCREEN ); setvaluator( MOUSEY, yy, 0, YMAXSCREEN ); curson(); /* go to base state */ readystate(); } else { /* get 2D real mouse position */ xpos = thisflat->xsign * getvaluator( MOUSEX ) * (1.0/(float)MOUSE_MAX); ypos = thisflat->ysign * getvaluator( MOUSEY ) * (1.0/(float)MOUSE_MAX); /* change the position */ switch ( vptr->xhdir & TOKCOD_DIRp ) { case TOKCOD_Xp: vptr->xhpos.z = ypos; vptr->xhpos.y = xpos; break; case TOKCOD_Xn: vptr->xhpos.z = xpos; vptr->xhpos.y = ypos; break; case TOKCOD_Yp: vptr->xhpos.z = xpos; vptr->xhpos.x = ypos; break; case TOKCOD_Yn: vptr->xhpos.z = ypos; vptr->xhpos.x = xpos; break; case TOKCOD_Zp: vptr->xhpos.x = xpos; vptr->xhpos.y = ypos; break; case TOKCOD_Zn: vptr->xhpos.x = ypos; vptr->xhpos.y = xpos; break; } draw_rot( v0ptr ); add_state( st_xhmov2, thisflat, 0 ); } } /* ************************************ * * * map2d3d * * * ************************************ DESCRIPTION: Fill 'vptr->xhdir' and '?sign' in a MOUSEFLAT struct to determine how the mouse moves the 3D crosshairs. ENTRY: */ #define SLPD(ax,dir) FABS(axslp[ax][dir]) #define MOSTER(ax1,ax2,dir) \ ( \ ( SLPD(ax1,dir) > SLPD(ax2,dir) ) \ ? ( (axslp[ax1][dir] > 0.0) ? (ax1) | TOKCOD_p : (ax1) ) \ : ( (axslp[ax2][dir] > 0.0) ? (ax2) | TOKCOD_p : (ax2) ) \ ) void map2d3d ( fptr ) register MOUSEFLAT *fptr; { register VIEW *vptr; register XFORM *total; UNS16 upaxis,rtaxis; Matrix axslp; /* axis slopes */ /* init */ vptr = fptr->vptr; total = & vptr->total; vptr->xhdir &= ~TOKCOD_p; /* discover arrangement of axes on screen */ axslopes( total, axslp ); switch ( vptr->xhdir & TOKCOD_DIR ) { case TOKCOD_Z: rtaxis = MOSTER( XX, YY, XX ); upaxis = MOSTER( XX, YY, YY ); if ( (rtaxis & TOKCOD_DIR) == XX ) vptr->xhdir |= TOKCOD_p; break; case TOKCOD_X: rtaxis = MOSTER( YY, ZZ, XX ); upaxis = MOSTER( YY, ZZ, YY ); if ( (rtaxis & TOKCOD_DIR) == YY ) vptr->xhdir |= TOKCOD_p; break; case TOKCOD_Y: rtaxis = MOSTER( XX, ZZ, XX ); upaxis = MOSTER( XX, ZZ, YY ); if ( (rtaxis & TOKCOD_DIR) == ZZ ) vptr->xhdir |= TOKCOD_p; break; } fptr->xsign = (rtaxis & TOKCOD_p) ? 1 : -1; fptr->ysign = (upaxis & TOKCOD_p) ? 1 : -1; } @//E*O*F xh.c// chmod u=rw,g=r,o=r xh.c echo Inspecting for damage in transit... temp=/tmp/shar$$; dtemp=/tmp/.shar$$ trap "rm -f $temp $dtemp; exit" 0 1 2 3 15 cat > $temp <<\!!! 257 905 6488 boxobj.c 289 786 5896 boxview.c 186 523 4071 manip.c 602 1530 12654 rotate.c 662 1719 13891 view.c 455 1231 10431 xh.c 2451 6694 53431 total !!! wc boxobj.c boxview.c manip.c rotate.c view.c xh.c | sed 's=[^ ]*/==' | diff -b $temp - >$dtemp if [ -s $dtemp ] then echo "Ouch [diff of wc output]:" ; cat $dtemp else echo "No problems found." fi exit 0 #------------------- cut this line and below ---------------------- -- -- Kelvin Thompson, Lone Rider of the Apocalypse kelvin@cs.utexas.edu {...,uunet}!cs.utexas.edu!kelvin ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03407; 27 Jul 88 9:15 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01412; 27 Jul 88 5:26 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01404; 27 Jul 88 5:14 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa11964; 27 Jul 88 4:52 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA01254; Wed, 27 Jul 88 00:25:37 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 88 03:23:22 GMT From: Kelvin Thompson Organization: U. Texas CS Dept., Austin, Texas Subject: 'boxview' -- Part 1 of 2 Message-Id: <3060@cs.utexas.edu> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA This is the first of two shar files that contain source for 'boxview', a 3D object viewer. The program displays a faceted object (read from a data file) and lets the user rotate it and alter the viewing geometry used to project it. 'Boxview' is different from other viewers because it has a unique, intuitive user interface that provides excellent feedback to the user. (I consider the standard set of Iris demos to have *awful* feedback.) 'Boxview' will run only on an Iris, because it makes extensive use of the Iris' architecture. I've tested it on a 3000-series Iris running a fairly old OS, and fairly new 4D. The program may not work well on Irises with 8 or fewer bitplanes. I decided to post the program after I noticed that Siggraph next week will have a paper entitled (roughly) "A Study in 3D Rotation with a 2D Pointing Device," which is exactly what I think 'boxview' is good at. I thought I might grab myself some credit by letting people compare my rotater with the one(s?) from the published paper. Instructions for unpacking and running: (1) Save this article and the accompanying one into two Iris files. (2) Trim the text before and after the "--- cut here ---" lines in each of the two files. (3) Unpack the files by typing "sh file1" and "sh file2". (4) If you have a 4D system, edit 'Makefile' and remove the "-Zf" from the 'CFLAGS' definition. (5) Run "make" without parameters. (6) Read the documentation in README and 'boxview.1l' (the latter by typing "nroff -man boxview.1l".) (7) Run the program by typing either "boxview" or "boxview sticks.geom". (8) Exit 'boxview' by hitting the escape key. Have fun. I've got gobs more '.geom' files -- most stolen from DEC's OFF release a year ago. Send questions or comments to me at: kelvin@cs.utexas.edu {backbone}!cs.utexas.edu!kelvin If you want to see a live demo at Siggraph, you can contact me (Kelvin Thompson) at the Nth Graphics booth, or at the Radisson Hotel. I will have a tar-tape (cartridge), but not an Iris (but maybe we can find one). #------------------- cut this line and above ---------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by cs.utexas.edu!kelvin on Tue Jul 26 22:05:00 CDT 1988 # Contents: Makefile README boxview.1l cube.geom sticks.geom idraw.h ktypes.h # cm.c slide.c states.c tables.c wm.c xform.c echo x - Makefile sed 's/^@//' > "Makefile" <<'@//E*O*F Makefile//' # This is the makefile to generate 'boxview'. # # by Kelvin Thompson, 10/4/87, 7/14/88 # Use the line below on 4D Irises (remove the '#' if you're on a 4D). #CFLAGS = -Zv -Zg -O -DIRIS # Use the line below in non-4D Irises (add a '#' if you're on a 4D). CFLAGS = -Zv -Zg -Zf -O -DIRIS BVFILES = boxview.o states.o manip.o xform.o tables.o rotate.o \ view.o wm.o slide.o xh.o cm.o boxobj.o boxview: $(BVFILES) ktypes.h cc $(CFLAGS) -o $@ $(BVFILES) @//E*O*F Makefile// chmod u=rw,g=r,o=r Makefile echo x - README sed 's/^@//' > "README" <<'@//E*O*F README//' The files in this release will generate the application 'boxview', which allows users to view 3D objects with an interesting human interface. This application can only run on Iris workstations from Silicon Graphics (and I have tested it on only a single Iris 3000-series turbo). The files are: Makefile README -- This file boxobj.c -- code for generating objects boxview.1l -- application document in nroff format boxview.c -- code for core of the program cm.c -- code for allocating bitplane layers and colors cube.geom -- data file describing a cube sticks.geom -- data file describing some sticks idraw.h -- include file for 'boxview' application ktypes.h -- generic inlcude file manip.c -- code for user manipulations rotate.c -- code for object rotations slide.c -- code for sliders states.c -- code for application states tables.c -- code for making database tables view.c -- code for viewing-geometry manipulations wm.c -- code for managing windows xform.c -- code for doing transforms xh.c -- code for manipulating crosshairs To build the application, type "make" without parameters. To run the application, type either "boxview" or "boxview sticks.geom". To read the documentation, type "nroff -man boxview.1l" and direct output to a file, a pager (like 'more' or 'less'), or standard output. If you want to have boxview display something besides polygonal objects, you can insert your own object-generating code fairly easily. See the documentation in the file 'boxobj.c'. Everything in this release is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. Please direct questions and comments to ARPA/INTERNET: kelvin@cs.utexas.edu UUCP: {...,uunet}!cs.utexas.edu!kelvin Have fun. -- Kelvin Thompson, 7/14/88 @//E*O*F README// chmod u=rw,g=r,o=r README echo x - boxview.1l sed 's/^@//' > "boxview.1l" <<'@//E*O*F boxview.1l//' @.TH BOXVIEW 1L @.SH NAME boxview \- 3D object viewer @.SH SYNOPSIS @.B boxview [file] @.SH DESCRIPTION @.I Boxview is an interactive viewer for 3D objects. @.I Boxview also acts as a demonstration of an interesting way of manipulating 3D objects with a mouse. @.PP If @.I boxview is called with no parameters, it displays three colored, orthogonal circles. If it is called with a single parameter @.I file, it draws the 3D polygons described in @.I file. The format of @.I file is described later. @.PP @.I Boxview displays a 3D object inside a 3D manipulation cube (or "3D window"), which is in turn inside a normal 2D window. The 3D window contains a set of 3D crosshairs for identifying points in 3-space. In the present implementation of @.I boxview the user may perform manipulations on the following attributes: @.TP "\w'\f3\-n\f1\|\ \ 'u" @.B Object orientation. Position the mouse cursor over one of the edges of the 3D manipulation cube, press the left mouse button, and move the cursor slowly, perpendicular to the selected edge. The cube and object will rotate to follow the motion of the mouse. @.TP @.B Projection geometry. Click the left mouse button on the small red square in the lower left corner of the 2D window. A sylized view of the projection geometry will appear in the lower left corner of the window. The apex at the left represents the viewier's eye, the circle at the right represents the sphere enclosing the 3D manipulation window, and the vertical line in the middle represents the projection plane. The red dots may be dragged to change the viewing geometry. Click on the small red square to make the projection window disappear. @.TP @.B 3D Crosshair position. Position the mouse cursor over one of the X, Y, or Z axes, press the mouse button, and move the mouse. The 3D crosshairs don't do anything besides move around. @.PP Press the escape key to exit @.I boxview. @.SH FILE FORMAT Input files for @.I boxview should be ASCII text files following the form of geometry files from DEC's OFF format. Each input file is divided into three parts: a single line describing the number of verticies and polygons in the object, several lines containing the coordinates of the verticies of the object, and several lines describing the polygons themselves. Each line consists of floating-point or (decimal) integer numbers separated by whitespace. @.PP The first line contains three integers: @.I Vcount, Pcount, and @.I Ecount. @.I Vcount is the number of verticies in the object, @.I Pcount the number of polygons, and @.I Ecount the number of edges (actually, @.I Ecount is ignored). The next @.I Vcount lines contain three floating-point numbers apiece, so that each line has the coorinates of a single vertex. Then the final @.I Pcount lines of the file each describe a polygon. Each of these lines starts with an integer @.I N, the number of verticies in the polygon, followed by @.I N integers referring back to the table of verticies (1 refers to the first vertex, 2 the second, and so on). @.PP The following file describes a cube centered around the origin: @.sp @.nf @.na 8 6 24 -1.0 -1.0 1.0 -1.0 1.0 1.0 1.0 1.0 1.0 1.0 -1.0 1.0 -1.0 -1.0 -1.0 -1.0 1.0 -1.0 1.0 1.0 -1.0 1.0 -1.0 -1.0 4 1 2 3 4 4 5 6 2 1 4 3 2 6 7 4 3 7 8 4 4 1 4 8 5 4 8 7 6 5 @.fi @.ad @.sp @.SH BUGS This program has only been exercised on a single, 3000-series Iris. It may exhibit odd behavior on different Irises, especially those with 8 or fewer bitplanes. @.PP Performance slows down for very large objects. Edges on adjacent polygons are drawn twice. @.SH AUTHOR Kelvin Thompson, The University of Texas at Austin @.SH COPYRIGHT @.I Boxview is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. @//E*O*F boxview.1l// chmod u=rw,g=r,o=r boxview.1l echo x - cube.geom sed 's/^@//' > "cube.geom" <<'@//E*O*F cube.geom//' 8 6 24 -1.0 -1.0 1.0 -1.0 1.0 1.0 1.0 1.0 1.0 1.0 -1.0 1.0 -1.0 -1.0 -1.0 -1.0 1.0 -1.0 1.0 1.0 -1.0 1.0 -1.0 -1.0 4 1 2 3 4 4 5 6 2 1 4 3 2 6 7 4 3 7 8 4 4 1 4 8 5 4 8 7 6 5 @//E*O*F cube.geom// chmod u=r,g=r,o=r cube.geom echo x - sticks.geom sed 's/^@//' > "sticks.geom" <<'@//E*O*F sticks.geom//' 24 18 72 0.967443 0.4 -0.272129 1.00217 0.4 -0.0751674 1.00217 0.2 -0.0751674 0.967443 0.2 -0.272129 -0.967443 0.4 0.272129 -1.00217 0.4 0.0751674 -1.00217 0.2 0.0751674 -0.967443 0.2 0.272129 -0.137311 -1.03783 -0.272129 -0.154676 -1.06791 -0.0751674 -0.327881 -0.967907 -0.0751674 -0.310516 -0.93783 -0.272129 0.830132 0.63783 0.272129 0.847496 0.667907 0.0751674 0.674291 0.767907 0.0751674 0.656927 0.73783 0.272129 -0.830132 0.63783 -0.272129 -0.847496 0.667907 -0.0751674 -0.674291 0.767907 -0.0751674 -0.656927 0.73783 -0.272129 0.137311 -1.03783 0.272129 0.154676 -1.06791 0.0751674 0.327881 -0.967907 0.0751674 0.310516 -0.93783 0.272129 4 1 2 3 4 4 5 6 7 8 4 6 1 4 7 4 5 2 1 6 4 8 3 2 5 4 7 4 3 8 4 9 10 11 12 4 13 14 15 16 4 14 9 12 15 4 13 10 9 14 4 16 11 10 13 4 15 12 11 16 4 17 18 19 20 4 21 22 23 24 4 22 17 20 23 4 21 18 17 22 4 24 19 18 21 4 23 20 19 24 @//E*O*F sticks.geom// chmod u=r,g=r,o=r sticks.geom echo x - idraw.h sed 's/^@//' > "idraw.h" <<'@//E*O*F idraw.h//' /* FILE: idraw.h DESCRIPTION: Types, symbols, globals for 'boxview' (previously 'idraw'). COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #ifndef __IDRAW_H__ #define __IDRAW_H__ #include "ktypes.h" /* the three directions as offsets */ #define XX 0 #define YY 1 #define ZZ 2 /* macros for accessing bits describing directions */ #define ROLLBIT(ax,dir) ((1<<(dir))<<(ax)) #define AX_MASK(ax) (07<<(3*(ax))) /* types of pickable things */ #define TOK_NULL 0 #define TOKTYP_MASK 0xff00 #define TOKCOD_MASK 0x00ff #define TOKTYP_AX 0x0100 /* axes */ #define TOKTYP_ROT 0x0200 /* rotation bars */ #define TOKTYP_VW 0x0300 /* view handles */ #define TOKTYP_XH 0x0400 /* crosshair */ #define TOKCOD_DIR 0x0003 #define TOKCOD_DIRp 0x0007 #define TOKCOD_X XX #define TOKCOD_Y YY #define TOKCOD_Z ZZ #define TOKCOD_p 0x0004 #define TOKCOD_Xp (TOKCOD_p | TOKCOD_X) #define TOKCOD_Xn ( 0 | TOKCOD_X) #define TOKCOD_Yp (TOKCOD_p | TOKCOD_Y) #define TOKCOD_Yn ( 0 | TOKCOD_Y) #define TOKCOD_Zp (TOKCOD_p | TOKCOD_Z) #define TOKCOD_Zn ( 0 | TOKCOD_Z) #define TOKPT(a,b) ( ((a&1)<<3) | ((b&1)<<2) ) /* the axes */ #define TOK_XAXIS (TOKTYP_AX | TOKCOD_X) #define TOK_YAXIS (TOKTYP_AX | TOKCOD_Y) #define TOK_ZAXIS (TOKTYP_AX | TOKCOD_Z) /* the pick window */ #define TOK_VEYE (TOKTYP_VW | 0x0001) #define TOK_VORG (TOKTYP_VW | 0x0002) #define TOK_VWIND (TOKTYP_VW | 0x0003) #define TOK_VWTOP (TOKTYP_VW | 0x0004) #define TOK_VWBOT (TOKTYP_VW | 0x0005) /* the crosshairs */ #define TOK_XH_Xp (TOKTYP_XH | TOKCOD_Xp) #define TOK_XH_Xn (TOKTYP_XH | TOKCOD_Xn) #define TOK_XH_Yp (TOKTYP_XH | TOKCOD_Yp) #define TOK_XH_Yn (TOKTYP_XH | TOKCOD_Yn) #define TOK_XH_Zp (TOKTYP_XH | TOKCOD_Zp) #define TOK_XH_Zn (TOKTYP_XH | TOKCOD_Zn) #define TOK_XH_O (TOKTYP_XH | 0x0007) #define TOK_XH_B (TOKTYP_XH | 0x0008) /* screen & pixel entities */ typedef struct SCRNPOINT {Scoord x,y} SCRNPOINT; typedef struct SCRNRECT {SCRNPOINT a,b} SCRNRECT; /* window struct */ typedef struct WINDOW { Matrix mous_m; SCRNRECT edge; RECT bounds; RECT bord; } WINDOW; /* viewing geometry */ typedef struct VIEWGEOM { float R; /* distance between eye and object */ float D; /* distance between eye and window */ float wx,wy; /* half of height and width of window */ } VIEWGEOM; /* viewing data */ typedef struct VIEW { VIEWGEOM g; WINDOW *wdw; WINDOW *vw; SCRNRECT butt; XFORM rot_to_ndc; XFORM box_to_rot; XFORM total; XFORM vwtot; UNS16 viewon; /* boolean -- TRUE if visible */ UNS8 xhon; /* boolean -- TRUE if crosshair visible */ UNS8 xhdir; /* direction of 2-D xh projection */ VEC3 xhpos; } VIEW; GLOBAL WINDOW *w0ptr; GLOBAL VIEW *v0ptr; GLOBAL long wminx,wmaxx,wminy,wmaxy; /* constants */ #define VP_R 4.0 #define VP_D 2.0 #define VP_WX 1.0 #define VP_WY 0.7 #define VP_XMIN 50 #define VP_XMAX 749 #define VP_YMIN 50 #define VP_YMAX 700 #define NTSC_XMIN 0 #define NTSC_YMIN 0 #define NTSC_XMAX 635 #define NTSC_YMAX 484 GLOBAL UNS16 mexon; GLOBAL Matrix default_mtx; /* oft-used rectangles */ #ifdef CENTRAL RECT ndcrect={ {-1,-1}, {1,1} }; RECT screenrect={ {0,0}, {XMAXSCREEN,YMAXSCREEN} }; #else extern RECT ndcrect,screenrect; #endif /* font containing grab boxes */ #define NUM_GRAB_CHARS 1 /* number of characters in the grab font */ #define GRAB_FONT_IDX 1 /* font number of grab font */ #define GRAB_MAX_HEIGHT 5 /* max height of grab font character */ #define NUM_GRAB_RASTS 5 /* number of raster elements */ #ifdef CENTRAL Fontchar grabchar[NUM_GRAB_CHARS+1] = { { 0, 0, 0, 0, 0, 0 }, /* dummy zero-th character */ { 0, 5, 5, -1, -2, 6 } }; short grabrast[NUM_GRAB_RASTS] = { /* first grab box -- 5x5 diamond */ 0x2000, 0x7000, 0xf800, 0x7000, 0x2000 }; #else extern Fontchar grabchar[NUM_GRAB_CHARS]; extern short grabrast[NUM_GRAB_RASTS]; #endif /* the feedback buffer */ #define FB_MAX 128 GLOBAL short fb_buff[FB_MAX]; /* color indicies of various things */ #define MAX_MAPCOLOR 4095 #define CLR_BLACK 0 #define CLR_2CURSOR 1 /* 2-d cursor (little arrow) */ #define CLR_BACKG 2 /* background of everything */ #define CLR_3WDW 3 /* edge of 3-d window */ #define CLR_2WDW 4 /* edge of 2-d window */ #define CLR_AXES 5 /* axes in 3-d window */ #define CLR_AXNAMES 6 /* labels for axes */ #define CLR_VW_BACKG 8 /* background of view-manip window */ #define CLR_VW_LINES 9 /* view-manip lines */ #define CLR_VW_GRABS 10 /* view-manip handles */ #define CLR_VW_AREA 11 /* viewing area in VW window */ #define CLR_VW_BUTT 12 /* selector button for VW window */ #define CLR_SPLAT 13 /* splat color (when drawn) */ #define CLR_3CURS_EDGE 14 /* color of edge of 3-D crosshairs */ #define CLR_OBJSTART 32 /* start of object colors */ /* bitplane segment (segment 0) colors */ #define s0_CLEAR 0 /* transparent color */ #define s0_2CURSOR 1 /* 2-d cursor (little arrow) */ #define s0_3WDW 2 /* edge of 3-d window */ #define s0_2WDW 2 /* edge of 2-d window */ #define s0_AXES 3 /* axes in 3-d window */ #define s0_AXNAMES 4 /* labels for axes */ #define s0_XH_EDGE 5 /* color of edge of 3-D crosshairs */ #define s0_3FADE 6 /* faded 3-D window color */ /* other colors */ #define s1_BLACK 0 /* background black */ #define s1_BACKG 0 /* background of everything */ #define s1_VW_BACKG 0 /* background of view-manip window */ #define s1_VW_LINES 1 /* view-manip lines */ #define s1_VW_GRABS 2 /* view-manip handles */ #define s1_VW_AREA 3 /* viewing area in VW window */ #define s1_VW_BUTT 4 /* selector button for VW window */ #define s1_SPLAT 5 /* splat color (when drawn) */ #define s1_OBJSTART 10 /* start of object colors */ /* globals for two segments */ GLOBAL UNS16 seg0,seg1; #define WROWS 20 #define WCOLS 20 #endif @//E*O*F idraw.h// chmod u=rw,g=r,o=r idraw.h echo x - ktypes.h sed 's/^@//' > "ktypes.h" <<'@//E*O*F ktypes.h//' /* FILENAME: ktypes.h DESCRIPTION: Standard datatypes for kelvin's stuff. LINK WITH: everything COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #ifndef KTYPES_H /* see if we've been here before */ #define KTYPES_H /* corresponding #endif at end of file */ /* Boolean values */ #ifndef TRUE #define TRUE 1 #define FALSE 0 #endif #ifdef CENTRAL #define GLOBAL #else #define GLOBAL extern #endif /* fixed-length integer types */ typedef char INT8; /* 8-bit signed */ typedef short INT16; /* 16-bit signed */ typedef int INT32; /* 32-bit signed */ typedef unsigned char UNS8; /* 8-bit unsigned */ typedef unsigned short UNS16; /* 16-bit unsigned */ typedef unsigned int UNS32; /* 32-bit unsigned */ #define PI 3.141592653 #define SQRT_2 1.414213562 /* say what kind of CPU this is */ #define M68000 1 #define M68020 2 #define VAX 3 #define CPU M68000 #if CPU==M68000 /* processor-specific integer types */ typedef int INTREGSIZ; /* register-sized signed */ typedef unsigned UNSREGSIZ; /* register-sized unsigned */ typedef short INTDATASIZ; /* data-bus-sized signed */ typedef unsigned short UNSDATASIZ; /* data-bus-sized unsigned */ typedef int INTPTRSIZ; /* pointer-register-sized signed */ typedef unsigned int UNSPTRSIZ; /* pointer-register-sized unsiged */ /* processor-specific sizes */ # define DATAWIDTH 16 /* width of data bus */ # define REGWIDTH 32 /* width of register */ # define PTRWIDTH 24 /* meaningful width of pointer */ #endif #if CPU==M68020 /* processor-specific integer types */ typedef int INTREGSIZ; /* register-sized signed */ typedef unsigned UNSREGSIZ; /* register-sized unsigned */ typedef short INTDATASIZ; /* data-bus-sized signed */ typedef unsigned UNSDATASIZ; /* data-bus-sized unsigned */ typedef int INTPTRSIZ; /* pointer-register-sized signed */ typedef unsigned int UNSPTRSIZ; /* pointer-register-sized unsiged */ /* processor-specific sizes */ # define DATAWIDTH 32 /* width of data bus */ # define REGWIDTH 32 /* width of register */ # define PTRWIDTH 32 /* meaningful width of pointer */ #endif #if CPU==VAX /* processor-specific integer types */ typedef int INTREGSIZ; /* register-sized signed */ typedef unsigned UNSREGSIZ; /* register-sized unsigned */ typedef int INTDATASIZ; /* data-bus-sized signed */ typedef unsigned UNSDATASIZ; /* data-bus-sized unsigned */ typedef int INTPTRSIZ; /* pointer-register-sized signed */ typedef unsigned int UNSPTRSIZ; /* pointer-register-sized unsiged */ /* processor-specific sizes */ # define DATAWIDTH 32 /* width of data bus */ # define REGWIDTH 32 /* width of register */ # define PTRWIDTH 32 /* meaningful width of pointer */ #endif /* geometric entities */ typedef float MATRIX[4][4]; typedef struct MTX_STRUCT {MATRIX m} MTX_STRUCT; typedef struct VEC2 {float x,y} VEC2; typedef struct VEC3 {float x,y,z} VEC3; typedef struct VEC4 {float x,y,z,w} VEC4; typedef struct POINT {float x,y} POINT; typedef struct RECT {POINT a,b} RECT; typedef union { MATRIX m; /* 4x4 matrix of values */ MTX_STRUCT a; /* struct containing 4x4 array */ VEC4 v[4]; /* 4 homogeneous vectors (rows) */ float s[16]; /* array 16 scalars */ } XFORM; /* constants */ #ifdef CENTRAL MTX_STRUCT I = {{ {1.0, 0.0, 0.0, 0.0}, {0.0, 1.0, 0.0, 0.0}, {0.0, 0.0, 1.0, 0.0}, {0.0, 0.0, 0.0, 1.0} }}; #else extern MTX_STRUCT I; #endif #define I_INIT \ { \ {1.0, 0.0, 0.0, 0.0}, \ {0.0, 1.0, 0.0, 0.0}, \ {0.0, 0.0, 1.0, 0.0}, \ {0.0, 0.0, 0.0, 1.0} \ } #endif /* end self protection */ @//E*O*F ktypes.h// chmod u=rw,g=r,o=r ktypes.h echo x - cm.c sed 's/^@//' > "cm.c" <<'@//E*O*F cm.c//' /* FILENAME: cm.c DESCRIPTION: Programs for allocating different sets of bitplanes and assigning color. Assumes double buffering. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include /* programs in this file */ extern cm_reset(); extern cm_avail(); extern unsigned cm_alloc(); extern cm_mapcolor(); extern cm_color(); extern Colorindex cm_truecolor(); typedef struct SEG { unsigned char start; /* first bitplane in segment */ unsigned char depth; /* number of bitplanes in segment */ unsigned short baseidx; /* base global index */ unsigned short maxidx; /* maximum segment color index */ unsigned short mask; /* mask in global index space */ } SEG; static SEG cmseg[64]={ {0,0} }; /* array of segment descriptions */ static unsigned segcount=0; /* number of segments allocated */ /* ************************************ * * * cm_reset * * * ************************************ DESCRIPTION: Resets the color map and associated allocations. EXIT: Returns number of available bitplanes. */ cm_reset ( ) { /* reset the color map */ mapcolor( 0, 0x0000, 0x0000, 0x0000 ); mapcolor( 1, 0xffff, 0x0000, 0x0000 ); mapcolor( 2, 0x0000, 0xffff, 0x0000 ); mapcolor( 3, 0xffff, 0xffff, 0x0000 ); mapcolor( 4, 0x0000, 0x0000, 0xffff ); mapcolor( 5, 0xffff, 0x0000, 0xffff ); mapcolor( 6, 0x0000, 0xffff, 0xffff ); mapcolor( 7, 0xffff, 0xffff, 0xffff ); /* reset allocations */ cmseg[0].depth = 0; segcount = 0; return getplanes(); } /* ************************************ * * * cm_avail * * * ************************************ DESCRIPTION: Gives number of unallocated bitplanes left. EXIT: Number of unallocated bitplanes. */ cm_avail ( ) { register unsigned total; register SEG *sptr; sptr = & cmseg[ segcount - 1 ]; total = sptr->start + sptr->depth; return getplanes() - total; } /* ************************************ * * * cm_alloc * * * ************************************ DESCRIPTION: Allocate a set of bitplanes. Later segments occlude earlier segments. Segments use bits starting in the low-order part of the word. ENTRY: bits -- Number of bits desired for segment. EXIT: Returns two values stored in a single, 32-bit, unsigned word. Upper 16 bits (masked with 0xffff0000) contain number of planes actually allocated. Lower 16 bits (masked with 0x0000ffff) contain segment id number (the index to the 'cmseg' array). Returns 0 if no more bitplanes available. */ static unsigned short hibits[]= { 0xffff, 0xfffe, 0xfffc, 0xfff8, 0xfff0, 0xffe0, 0xffc0, 0xff80, 0xff00, 0xfe00, 0xfc00, 0xf800, 0xf000, 0xe000, 0xc000, 0x8000, 0x0000 }; unsigned cm_alloc ( bits ) register unsigned bits; { register unsigned total,avail; register SEG *sptr; /* see what's already been allocated */ if ( segcount != 0 ) { sptr = & cmseg[ segcount - 1]; total = sptr->start + sptr->depth; sptr++; } else { sptr = cmseg; total = 0; } /* quit if everything taken */ avail = getplanes() - total; if ( avail == 0 ) return 0; /* fill the next SEG cell */ sptr->start = total; sptr->depth = ( avail > bits ) ? bits : avail; sptr->baseidx = (1 << sptr->start) - 1; sptr->maxidx = (1 << sptr->depth) - 1; sptr->mask = sptr->maxidx << sptr->start; sptr->mask = hibits[ sptr->start ]; /* mark the last SEG cell */ sptr[1].depth = 0; return (sptr->depth << 16) | segcount++; } /* ************************************ * * * cm_mapcolor * * * ************************************ DESCRIPTION: Allocate a color in a bitplane segment. ENTRY: segid -- ID of segment whose color is to be defined. coloridx -- Color index to be defined. red,grn,blu -- Color description. Set red color to (int)(-1) or 0xffffffff for transparent color. EXIT: Returns 0 if 'segid' or 'coloridx' was bogus; nonzero otherwise. */ cm_mapcolor ( segid, coloridx, red, grn, blu ) unsigned segid; Colorindex color; unsigned red,grn,blu; { register unsigned i,loopmax,newcolor; register SEG *sptr; short prevred,prevgrn,prevblu; /* get segment cell */ if ( segid >= segcount ) return 0; sptr = & cmseg[segid]; /* check index */ if ( coloridx > sptr->maxidx ) return 0; /* define the color */ loopmax = sptr->baseidx; newcolor = coloridx << sptr->start; if ( red == 0xffffffff ) { /* defining transparent color */ for ( i=0; i<=loopmax; i++ ) { getmcolor( i, &prevred, &prevgrn, &prevblu ); mapcolor( newcolor, prevred, prevgrn, prevblu ); newcolor++; } } else { /* defining an occluding color */ for ( i=0; i<=loopmax; i++ ) { mapcolor( newcolor, red, grn, blu ); newcolor++; } } return 1; } /* ************************************ * * * cm_color * * * ************************************ DESCRIPTION: Set the current color to a segment's color. Leaves other segments the same. ENTRY: segid -- ID of segment being referred to. coloridx -- Color index. EXIT: Returns 0 if 'segid' is bogus; nonzero otherwise. */ cm_color ( segid, coloridx ) unsigned segid; Colorindex coloridx; { register SEG *sptr; /* fprintf( stderr, "Called 'cm_color' with %d, %d\n", segid, coloridx ); */ /* get segment cell */ if ( segid >= segcount ) return 0; sptr = & cmseg[segid]; /* mask planes and set color */ writemask( sptr->mask ); color( (coloridx & sptr->maxidx) << sptr->start ); /* fprintf( stderr, "Mask = 0x%x; color = 0x%x\n", sptr->mask, ((coloridx & sptr->maxidx) << sptr->start) ); */ return 1; } /* ************************************ * * * cm_truecolor * * * ************************************ DESCRIPTION: Return the true color associated with a segment color. Also turns on all writemasks. ENTRY: */ Colorindex cm_truecolor ( segid, coloridx ) unsigned segid; Colorindex coloridx; { register SEG *sptr; /* get segment cell */ if ( segid >= segcount ) return 0; sptr = & cmseg[segid]; /* unmask planes and set color */ writemask( 0xffffffff ); return (coloridx & sptr->maxidx) << sptr->start; } @//E*O*F cm.c// chmod u=rw,g=r,o=r cm.c echo x - slide.c sed 's/^@//' > "slide.c" <<'@//E*O*F slide.c//' /* FILENAME: slide.c DESCRIPTION: Routines to implement sliders. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "idraw.h" /* programs in this file */ extern getslidepts(); extern void doslide(); extern void st_slide(); static SCRNRECT slidept; static float slidex[3][3]; static void (*runfunc)(),(*donefunc)(); /* ************************************ * * * doslide() * * * ************************************ DESCRIPTION: ENTRY: */ void doslide ( endpt, rfunc, dfunc ) register SCRNRECT *endpt; void (*rfunc)(),(*dfunc)(); { register float dx,dy,denom; /* store the endpoints and functions in the static location */ slidept = *endpt; runfunc = rfunc; donefunc = dfunc; /* fix up the transform matrix */ dx = endpt->b.x - endpt->a.x; dy = endpt->b.y - endpt->a.y; denom = 1.0 / (dx*dx + dy*dy); slidex[0][0] = dx * denom; slidex[0][1] = -dy * denom; slidex[0][2] = 0.0; slidex[1][0] = -slidex[0][1]; slidex[1][1] = slidex[0][0]; slidex[1][2] = 0.0; slidex[2][0] = -(dy * endpt->a.y + dx * endpt->a.x) * denom; slidex[2][1] = -(dx * endpt->a.y - dy * endpt->a.x) * denom; slidex[2][2] = 1.0; /* perform the sliding action */ st_slide( 0, 0 ); } /* ************************************ * * * st_slide * * * ************************************ DESCRIPTION: ENTRY: */ void st_slide ( dum1, dum2 ) { register float newx; register long mx,my; /* get mouse location */ mx = getvaluator( MOUSEX ); my = getvaluator( MOUSEY ); /* get the transformed X location */ newx = (float)mx * slidex[0][0] + (float)my * slidex[1][0] + slidex[2][0]; if ( !getbutton(LEFTMOUSE) ) { (*donefunc)( newx ); readystate(); } else { /* call the update routine */ (*runfunc)( newx ); add_state( st_slide, 0, 0 ); } } /* ************************************ * * * getslidepts * * * ************************************ DESCRIPTION: Map a 3D line segment to a clipped screen line segment. ENTRY: EXIT: Returns TRUE if the mapping was successful, FALSE otherwise. PREREQUISITES: The viewport and transform must be set before calling. */ getslidepts ( v1, v2, srect ) register VEC3 *v1,*v2; register SCRNRECT *srect; { register long fbcount; /* check for hits */ feedback( fb_buff, FB_MAX ); move( v1->x, v1->y, v1->z ); draw( v2->x, v2->y, v2->z ); fbcount = endfeedback( fb_buff ); /* make sure it's in a format we want */ if ( fbcount != 6 || fb_buff[0] != 16 || fb_buff[3] != 17 ) return FALSE; /* move the results to the return rectangle */ srect->a.x = fb_buff[1]; srect->a.y = fb_buff[2]; srect->b.x = fb_buff[4]; srect->b.y = fb_buff[5]; return TRUE; } @//E*O*F slide.c// chmod u=rw,g=r,o=r slide.c echo x - states.c sed 's/^@//' > "states.c" <<'@//E*O*F states.c//' /* FILENAME: states.c DESCRIPTION: Programs that deal with the idraw state machine. LINK WITH: tables.c -- Handles allocation of fixed-sized things. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "ktypes.h" /* programs in this file */ extern void init_states(); extern void close_states(); extern do_state(); /* constants */ #define MAX_STATES 32 /* maximum number of states allowed */ /* local types */ typedef struct STATE { struct STATE *next; void (*func)(); int val1,val2; } STATE; /* local variables */ static STATE *pres_state=0, *futr_state=0; static list1,list2, futr_list; /* ************************************ * * * init_states * * * ************************************ DESCRIPTION: Initialize stuff for state parser. */ void init_states ( ) { list1 = init_table( MAX_STATES, sizeof(STATE) ); list2 = init_table( MAX_STATES, sizeof(STATE) ); futr_list = list1; } /* ************************************ * * * close_states * * * ************************************ DESCRIPTION: Free space used by state parser. */ void close_states ( ) { close_table( list1 ); close_table( list2 ); } /* ************************************ * * * do_state * * * ************************************ DESCRIPTION: Execute all state programs. */ do_state ( ) { register STATE *this_state; /* move the future to the present */ if ( futr_state == 0 ) return FALSE; pres_state = futr_state; futr_state = 0; /* swap lists */ if ( futr_list == list1 ) { reset_table( list2 ); futr_list = list2; } else { reset_table( list1 ); futr_list = list1; } /* loop through current states */ for ( this_state=pres_state; this_state!=0; this_state=this_state->next ) (*(this_state->func))( this_state->val1, this_state->val2 ); return TRUE; } /* ************************************ * * * add_state * * * ************************************ DESCRIPTION: Add a state to the list to be executed in the future. ENTRY: */ void add_state ( func, val1, val2 ) void (*func)(); int val1,val2; { register STATE *this_state; /* initialize */ this_state = (STATE *)get_cell( futr_list ); this_state->func = func; this_state->val1 = val1; this_state->val2 = val2; /* put in linked list */ this_state->next = futr_state; futr_state = this_state; } @//E*O*F states.c// chmod u=rw,g=r,o=r states.c echo x - tables.c sed 's/^@//' > "tables.c" <<'@//E*O*F tables.c//' /* FILENAME: tables.c DESCRIPTION: Utility programs for generic tables. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ typedef struct TABLE { unsigned short tblsize; unsigned short cellsize; char *nextcell; } TABLE; /* programs in this file */ extern int *init_table(); extern void reset_table(); extern char *get_cell(); extern void close_table(); extern void fill_table(); extern char *next_cell(); /* ********************* * * * init_table * * * ********************* DESCRIPTION: Create a table. ENTRY: EXIT: */ int *init_table ( tblsize, cellsize ) register tblsize; register cellsize; { register TABLE *out; /* allocate space for TABLE and init struct */ out = (TABLE *)malloc( sizeof(TABLE) + tblsize * cellsize ); out->tblsize = tblsize; out->cellsize = cellsize; out->nextcell = (char *)out + sizeof(TABLE) + (tblsize-1) * cellsize; /* return pointer to struct */ return (int *)out; } /* ********************* * * * reset_table * * * ********************* DESCRIPTION: Initialize the elements of a table. ENTRY: */ void reset_table ( tbl ) register TABLE *tbl; { tbl->nextcell = (char *)(& tbl[1]) + (tbl->tblsize-1) * tbl->cellsize; } /* ********************* * * * get_cell * * * ********************* DESCRIPTION: Return the next cell from the table. ENTRY: EXIT: */ char *get_cell ( tbl ) register TABLE *tbl; { register char *out; if ( tbl->nextcell != (char *)(&tbl[1]) ) { out = tbl->nextcell; tbl->nextcell -= tbl->cellsize; } else out = 0; return out; } /* ********************* * * * close_table * * * ********************* DESCRIPTION: Destroy a table. ENTRY: EXIT: */ void close_table ( tbl ) register TABLE *tbl; { free( tbl ); } /* ********************* * * * fill_table * * * ********************* DESCRIPTION: Initialize the elements of a table by calling a function for every element. ENTRY: */ void fill_table ( tbl, func ) register TABLE *tbl; register void (*func)(); { register idx; register char *nextcell; /* initialize for loop */ idx = tbl->tblsize - 1; tbl->nextcell = nextcell = (char *)tbl + sizeof(TABLE) + (tbl->tblsize-1) * tbl->cellsize; /* loop through all elements in table */ do { /* call the filling function */ (*func)( nextcell, idx ); /* decrement counters */ --idx; nextcell -= tbl->cellsize; } while ( idx >= 0 ); } /* ********************* * * * next_cell * * * ********************* DESCRIPTION: Return the next cell from the table. ENTRY: EXIT: */ char *next_cell ( tbl ) register TABLE *tbl; { register char *out; /* get contents of next cell */ out = tbl->nextcell; if ( tbl->nextcell == (char *)(&tbl[1]) ) tbl->nextcell = (char *)tbl + sizeof(TABLE) + (tbl->tblsize-1) * tbl->cellsize; else tbl->nextcell -= tbl->cellsize; return out; } @//E*O*F tables.c// chmod u=rw,g=r,o=r tables.c echo x - wm.c sed 's/^@//' > "wm.c" <<'@//E*O*F wm.c//' /* FILENAME: wm.c DESCRIPTION: Window manager routines. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "idraw.h" /* programs in this file */ extern char *open_wdw(); extern void use_wdw(); extern void vp_wdw(); extern void close_wdw(); extern getmousebox(); #define PICK_RAD 4 static WINDOW *curr_wdw; /* ************************************ * * * open_wdw * * * ************************************ DESCRIPTION: Open a window on the screen. ENTRY: EXIT: */ char *open_wdw ( minx, maxx, miny, maxy ) long minx,maxx,miny,maxy; { register WINDOW *wdw; wdw = (WINDOW *)malloc( sizeof(WINDOW) ); if ( mexon ) { getorigin( &wminx, &wminy ); getsize( &wmaxx, &wmaxy ); wmaxx += wminx - 1; wmaxy += wminy - 1; minx = wminx; miny = wminy; maxx = wmaxx; maxy = wmaxy; } /* record bounds of window */ wdw->edge.a.x = minx; wdw->edge.a.y = miny; wdw->edge.b.x = maxx; wdw->edge.b.y = maxy; wdw->bounds.a.x = minx; wdw->bounds.a.y = miny; wdw->bounds.b.x = maxx; wdw->bounds.b.y = maxy; wdw->bord.a.x = minx-1; wdw->bord.a.y = miny-1; wdw->bord.b.x = maxx+1; wdw->bord.b.y = maxy+1; /* calculate mapping from screen to window */ map_rects( wdw->mous_m, &wdw->bounds, &ndcrect ); return (char *)wdw; } /* ************************************ * * * close_wdw * * * ************************************ DESCRIPTION: ENTRY: */ void close_wdw ( wdw ) { free( wdw ); } /* ************************************ * * * use_wdw * * * ************************************ DESCRIPTION: Set the screen mask and current transform to reflect a given window. ENTRY: */ void use_wdw ( wdw ) register WINDOW *wdw; { /* draw the window's border */ viewport( 0, XMAXSCREEN, 0, YMAXSCREEN ); loadmatrix( default_mtx ); cm_color( seg0, s0_2WDW ); rect( wdw->bord.a.x, wdw->bord.a.y, wdw->bord.b.x, wdw->bord.b.y ); viewport( wdw->edge.a.x, wdw->edge.b.x, wdw->edge.a.y, wdw->edge.b.y ); curr_wdw = wdw; } /* ************************************ * * * vp_wdw * * * ************************************ DESCRIPTION: Set the viewport to the indicated window. ENTRY: */ void vp_wdw ( wdw ) register WINDOW *wdw; { viewport( wdw->edge.a.x, wdw->edge.b.x, wdw->edge.a.y, wdw->edge.b.y ); curr_wdw = wdw; } /* ************************************ * * * clear_wdw * * * ************************************ DESCRIPTION: ENTRY: */ void clear_wdw ( wdw ) register WINDOW *wdw; { pushmatrix(); loadmatrix( default_mtx ); rectfi( wdw->edge.a.x, wdw->edge.a.y, wdw->edge.b.x, wdw->edge.b.y ); popmatrix(); } /* ************************************ * * * getmousebox * * * ************************************ DESCRIPTION: ENTRY: EXIT: */ getmousebox ( wdw, boxptr ) register WINDOW *wdw; register RECT *boxptr; { register long mx,my; /* init */ mx = getvaluator(MOUSEX); my = getvaluator(MOUSEY); /* make sure it's inside the window */ if ( mx < wdw->edge.a.x || wdw->edge.b.x < mx || my < wdw->edge.a.y || wdw->edge.b.y < my ) return FALSE; /* do the transform to window coords by hand */ boxptr->a.x = (mx-PICK_RAD) * wdw->mous_m[0][0] + wdw->mous_m[3][0]; boxptr->a.y = (my-PICK_RAD) * wdw->mous_m[1][1] + wdw->mous_m[3][1]; boxptr->b.x = (mx+PICK_RAD) * wdw->mous_m[0][0] + wdw->mous_m[3][0]; boxptr->b.y = (my+PICK_RAD) * wdw->mous_m[1][1] + wdw->mous_m[3][1]; return TRUE; } @//E*O*F wm.c// chmod u=rw,g=r,o=r wm.c echo x - xform.c sed 's/^@//' > "xform.c" <<'@//E*O*F xform.c//' /* FILENAME: xform.c DESCRIPTION: Various matrix processors for idraw. COPYRIGHT: This software is Copyright 1986,1987,1988 by Kelvin Thompson and carries GNU-like restrictions: Permission is granted to use, copy, modify, and redistribute this software for non- commercial purposes, as long as copies and derivative works carry these same restrictions. */ #include #include #include "ktypes.h" #include "idraw.h" /* programs in this file */ extern XFORM *mmul(); extern VEC4 *vmul(); /* extern void set_vp(); */ extern void rot_x(); extern void rot_y(); extern void rot_z(); extern void set_view(); extern void map_rects(),qmap_rects(); extern unsigned getdirs(); extern XFORM *axslopes(); #define MINISCULE 1.0e-32 /* ********************* * * * mmul * * * ********************* DESCRIPTION: Multiply two 4x4 matricies. ENTRY: a,b -- two matricies to be multiplied result -- result matrix, perhaps the same as an input matrix */ XFORM *mmul ( result, a, b ) register XFORM *a,*b,*result; { XFORM tempx; tempx.m[0][0] = a->m[0][0] * b->m[0][0] + a->m[0][1] * b->m[1][0] + a->m[0][2] * b->m[2][0] + a->m[0][3] * b->m[3][0]; tempx.m[0][1] = a->m[0][0] * b->m[0][1] + a->m[0][1] * b->m[1][1] + a->m[0][2] * b->m[2][1] + a->m[0][3] * b->m[3][1]; tempx.m[0][2] = a->m[0][0] * b->m[0][2] + a->m[0][1] * b->m[1][2] + a->m[0][2] * b->m[2][2] + a->m[0][3] * b->m[3][2]; tempx.m[0][3] = a->m[0][0] * b->m[0][3] + a->m[0][1] * b->m[1][3] + a->m[0][2] * b->m[2][3] + a->m[0][3] * b->m[3][3]; tempx.m[1][0] = a->m[1][0] * b->m[0][0] + a->m[1][1] * b->m[1][0] + a->m[1][2] * b->m[2][0] + a->m[1][3] * b->m[3][0]; tempx.m[1][1] = a->m[1][0] * b->m[0][1] + a->m[1][1] * b->m[1][1] + a->m[1][2] * b->m[2][1] + a->m[1][3] * b->m[3][1]; tempx.m[1][2] = a->m[1][0] * b->m[0][2] + a->m[1][1] * b->m[1][2] + a->m[1][2] * b->m[2][2] + a->m[1][3] * b->m[3][2]; tempx.m[1][3] = a->m[1][0] * b->m[0][3] + a->m[1][1] * b->m[1][3] + a->m[1][2] * b->m[2][3] + a->m[1][3] * b->m[3][3]; tempx.m[2][0] = a->m[2][0] * b->m[0][0] + a->m[2][1] * b->m[1][0] + a->m[2][2] * b->m[2][0] + a->m[2][3] * b->m[3][0]; tempx.m[2][1] = a->m[2][0] * b->m[0][1] + a->m[2][1] * b->m[1][1] + a->m[2][2] * b->m[2][1] + a->m[2][3] * b->m[3][1]; tempx.m[2][2] = a->m[2][0] * b->m[0][2] + a->m[2][1] * b->m[1][2] + a->m[2][2] * b->m[2][2] + a->m[2][3] * b->m[3][2]; tempx.m[2][3] = a->m[2][0] * b->m[0][3] + a->m[2][1] * b->m[1][3] + a->m[2][2] * b->m[2][3] + a->m[2][3] * b->m[3][3]; tempx.m[3][0] = a->m[3][0] * b->m[0][0] + a->m[3][1] * b->m[1][0] + a->m[3][2] * b->m[2][0] + a->m[3][3] * b->m[3][0]; tempx.m[3][1] = a->m[3][0] * b->m[0][1] + a->m[3][1] * b->m[1][1] + a->m[3][2] * b->m[2][1] + a->m[3][3] * b->m[3][1]; tempx.m[3][2] = a->m[3][0] * b->m[0][2] + a->m[3][1] * b->m[1][2] + a->m[3][2] * b->m[2][2] + a->m[3][3] * b->m[3][2]; tempx.m[3][3] = a->m[3][0] * b->m[0][3] + a->m[3][1] * b->m[1][3] + a->m[3][2] * b->m[2][3] + a->m[3][3] * b->m[3][3]; result->a = tempx.a; /* copy temporary product to result matrix */ return result; } /* ************************************ * * * vmul * * * ************************************ DESCRIPTION: Multiply a row vector by a matrix. ENTRY: EXIT: */ VEC4 *vmul ( result, v, m ) register XFORM *m; register VEC4 *result,*v; { VEC4 tempv; tempv.x = v->x * m->m[0][0] + v->y * m->m[1][0] + v->z * m->m[2][0] + v->w * m->m[3][0]; tempv.y = v->x * m->m[0][1] + v->y * m->m[1][1] + v->z * m->m[2][1] + v->w * m->m[3][1]; tempv.z = v->x * m->m[0][2] + v->y * m->m[1][2] + v->z * m->m[2][2] + v->w * m->m[3][2]; tempv.w = v->x * m->m[0][3] + v->y * m->m[1][3] + v->z * m->m[2][3] + v->w * m->m[3][3]; *result = tempv; return result; } /* ************************************ * * * rot_x * * * ************************************ DESCRIPTION: Add an X rotation to a matrix. ENTRY: */ void rot_x ( matx, ang ) register XFORM *matx; float ang; { XFORM rotmatx; register float sinx,cosx; /* initialize */ sinx = sin(ang); cosx = cos(ang); /* set up the local matrix */ rotmatx.a = I; rotmatx.m[1][1] = cosx; rotmatx.m[1][2] = sinx; rotmatx.m[2][1] = -sinx; rotmatx.m[2][2] = cosx; /* multiply */ mmul( matx, &rotmatx, matx ); } /* ************************************ * * * rot_y * * * ************************************ DESCRIPTION: Add a Y rotation to a matrix. ENTRY: */ void rot_y ( matx, ang ) register XFORM *matx; float ang; { XFORM rotmatx; register float sinx,cosx; /* initialize */ sinx = sin(ang); cosx = cos(ang); /* set up the local matrix */ rotmatx.a = I; rotmatx.m[0][0] = cosx; rotmatx.m[0][2] = -sinx; rotmatx.m[2][0] = sinx; rotmatx.m[2][2] = cosx; /* multiply */ mmul( matx, &rotmatx, matx ); } /* ************************************ * * * rot_z * * * ************************************ DESCRIPTION: Add a Z rotation to a matrix. ENTRY: */ void rot_z ( matx, ang ) register XFORM *matx; float ang; { XFORM rotmatx; register float sinx,cosx; /* initialize */ sinx = sin(ang); cosx = cos(ang); /* set up the local matrix */ rotmatx.a = I; rotmatx.m[0][0] = cosx; rotmatx.m[0][1] = sinx; rotmatx.m[1][0] = -sinx; rotmatx.m[1][1] = cosx; /* multiply */ mmul( matx, &rotmatx, matx ); } /* ************************************ * * * set_view * * * ************************************ DESCRIPTION: ENTRY: */ void set_view ( matx, r, d, wx, wy ) register XFORM *matx; register float r,d,wx,wy; { matx->a = I; matx->m[0][0] = d / wx; matx->m[1][1] = d / wy; matx->m[2][2] = 0.0; matx->m[2][3] = -1.0; matx->m[3][3] = r; } /* ************************************ * * * map_rects * * * ************************************ DESCRIPTION: ENTRY: */ void map_rects ( m, from, to ) register MTX_STRUCT *m; register RECT *from,*to; { register float fromdiff,todiff,ratio; *m = I; /* figure X transform */ fromdiff = from->b.x - from->a.x; todiff = to->b.x - to->a.x; ratio = todiff / fromdiff; m->m[0][0] = ratio; m->m[3][0] = to->a.x - from->a.x * ratio; /* figure Y transform */ fromdiff = from->b.y - from->a.y; todiff = to->b.y - to->a.y; ratio = todiff / fromdiff; m->m[1][1] = ratio; m->m[3][1] = to->a.y - from->a.y * ratio; } /* ************************************ * * * qmap_rects * * * ************************************ DESCRIPTION: ENTRY: */ void qmap_rects ( m, from, to ) register MTX_STRUCT *m; register RECT *from,*to; { register float fromdiff,todiff,ratio; /* figure X transform */ fromdiff = from->b.x - from->a.x; todiff = to->b.x - to->a.x; ratio = todiff / fromdiff; m->m[0][0] = ratio; m->m[3][0] = to->a.x - from->a.x * ratio; /* figure Y transform */ fromdiff = from->b.y - from->a.y; todiff = to->b.y - to->a.y; ratio = todiff / fromdiff; m->m[1][1] = ratio; m->m[3][1] = to->a.y - from->a.y * ratio; } /* ************************************ * * * getdirs * * * ************************************ DESCRIPTION: Find out which way coordinate axes are pointing on the screen. ENTRY: mtx -- pointer to an XFORM struct describing the world-to-eye transform EXIT: Returns 9 bits in an 'unsigned'. The bits may be read via the ROLLBIT macro (in 'idraw.h'). DERIVATION: We want to find out if the positive end of axis A maps to a positive D component in eye space. Assume we have a general 4x4 transform matrix 'mtx'. To see which way the X axis is pointing, we send the vector [+inf 0 0 1] throuh 'mtx' and see what comes out. The signs of things in the result vector tell us which way the axes are pointing. Because of the infinite component in the input vector, the bottom row of 'mtx' doesn't matter. Each component of the result vector is a ratio of two infinities, but we only care about the sign of each ratio. The sign of a ratio is the XOR of the signs of its numerator and denominator. */ unsigned getdirs ( mtx ) register XFORM *mtx; { register unsigned num,den; /* init */ num = 0; den = 0; #define DO_NUM(ax,dir) \ {if ( mtx->m[ax][dir] > 0.0 ) num |= ROLLBIT(ax,dir);} DO_NUM(XX,XX); DO_NUM(XX,YY); DO_NUM(XX,ZZ); DO_NUM(YY,XX); DO_NUM(YY,YY); DO_NUM(YY,ZZ); DO_NUM(ZZ,XX); DO_NUM(ZZ,YY); DO_NUM(ZZ,ZZ); #define DO_DEN(ax) \ {if ( mtx->m[ax][3] > 0.0 ) den |= AX_MASK(ax);} DO_DEN(XX); DO_DEN(YY); DO_DEN(ZZ); return num ^ den; } /* ************************************ * * * axslopes * * * ************************************ DESCRIPTION: Find out the slopes of the coordinate axes in eye space. ENTRY: mtx -- Pointer to an XFORM union containing the current world-to-eye transform. slope -- Pointer to another XFORM union to receive the slope matrix. Only the upper left 3x3 submatrix will be filled, where each row describes the slope of an axis. EXIT: Returns the 'slope' pointer. */ XFORM *axslopes ( mtx, slope ) register XFORM *mtx,*slope; { register float denom; #define XXPPQQ(ax,dir) \ slope->m[ax][dir] = \ (mtx->m[ax][dir] + mtx->m[3][dir]) \ / (mtx->m[ax][3] + mtx->m[3][3]); #define DO_AX_SLP(ax) \ { XXPPQQ(ax,XX); XXPPQQ(ax,YY); XXPPQQ(ax,ZZ); } DO_AX_SLP(XX); DO_AX_SLP(YY); DO_AX_SLP(ZZ); return slope; } @//E*O*F xform.c// chmod u=rw,g=r,o=r xform.c echo Inspecting for damage in transit... temp=/tmp/shar$$; dtemp=/tmp/.shar$$ trap "rm -f $temp $dtemp; exit" 0 1 2 3 15 cat > $temp <<\!!! 15 83 454 Makefile 53 287 2095 README 129 686 3892 boxview.1l 15 57 175 cube.geom 43 165 872 sticks.geom 214 909 6298 idraw.h 135 566 4216 ktypes.h 300 936 7083 cm.c 148 429 3269 slide.c 148 352 3045 states.c 202 455 3520 tables.c 209 486 4351 wm.c 475 1363 10811 xform.c 2086 6774 50081 total !!! wc Makefile README boxview.1l cube.geom sticks.geom idraw.h ktypes.h cm.c slide.c states.c tables.c wm.c xform.c | sed 's=[^ ]*/==' | diff -b $temp - >$dtemp if [ -s $dtemp ] then echo "Ouch [diff of wc output]:" ; cat $dtemp else echo "No problems found." fi exit 0 #------------------- cut this line and below ---------------------- -- -- Kelvin Thompson, Lone Rider of the Apocalypse kelvin@cs.utexas.edu {...,uunet}!cs.utexas.edu!kelvin ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04764; 27 Jul 88 10:10 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04442; 27 Jul 88 9:59 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04354; 27 Jul 88 9:52 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa25097; 27 Jul 88 9:27 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA05878; Wed, 27 Jul 88 05:58:50 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jul 88 10:51:47 GMT From: "George S. Kong" Organization: Silicon Graphics Inc, Mountain View, CA Subject: position open for graphics/systems person Message-Id: <17879@sgi.SGI.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA I'm looking for a person with a strong background in both systems and 3D graphics. I have a position open on a team responsible for graphics system software and microcode for a family of super-high-performance graphics workstations. The team is currently completing the implementation of a RISC-based multi-processor workstation with 3D polygon-rendering hardware that can draw 100,000 independent, 4-sided, phong-lighted, gouraud-shaded, clip-tested, z-buffered, 10x10-pixel polygons per second. The team also has begun architecting future-generation workstations with even higher performance goals and with more graphics functionality implemented in hardware. The applicant must be able to design and implement graphics functions that span multiple CPUs and micro-programmable graphics engines. Good design and implementation skills and industry experience are required. Silicon Graphics is the leading manufacturer of high-performance 3D graphics workstations. We're a six-year-old company located in Mountain View, CA. We're a rapidly-growing company, with current annual revenues of $150,000,000 and a revenue growth rate of 100% annually. Silicon Graphics' stock is publicly traded, but we're still offering stock options to new employees. We offer outstanding compensation and work environment and a corporate culture that is characterized by enthusiasm, technical excellence, teamwork, fun, and a strong sense of pride. If you're interested, please send me your resume, preferably by e-mail, otherwise by US mail. If you'll be attending SIGGRAPH this year, you can contact me through the Silicon Graphics booth. George S. Kong, Silicon Graphics, Inc., (415)962-3281 2011 N. Shoreline Blvd., Mountain View, CA, 94039-7311 gsk@sgi.com ...{decwrl,allegra,sun,adobe,ucbvax,pyramid,ames}!sgi!gsk ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17135; 28 Jul 88 13:56 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab17011; 28 Jul 88 13:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab16807; 28 Jul 88 13:31 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa02095; 28 Jul 88 11:46 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA18157; Wed, 27 Jul 88 17:51:18 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 88 15:36:30 GMT From: Archer Sully Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: the /debug partition Message-Id: <18021@sgi.SGI.COM> References: <8807260558.AA07135@uunet.UU.NET> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <8807260558.AA07135@uunet.UU.NET>, bernie@cidam.rmit.OZ.AU (Bernard Kirby) writes: > > We recently had one of our machines upgraded to a 4D-70GT running > version 3 of the operating system (4sight 1.0 etc). After all the > software was installed we noticed that a "df" showed an "extra" > partition /dev/debug of type dbg mounted on /debug. It was about > 50Mb in size! There appeared to be files in the /debug directory, > but whenever you tried to look at them, nothing happened, like they > were zero length files, except that "ls -l" showed that some of them > were quite large in size. The number and size of files varied as the > machine was used. This partition was not in /etc/fstab but was in > /etc/mtab. So, one day in a fit of experimentality we simply "umount"ed > it, and it hasn't reappeared since, even after a reboot. > Now for the questions. > > a) Is this a "hidden" partition that is secretly present on all SGI > machine's disks, only manifesting itself when explicitly mounted? yes, it is present, because it is really the swap partition. > > b) Is it really about 50Mb in size, or is that simply a function of "df" > misinterpreting a file system of type dbg. > > OR > > c) Did the Version 3 system repartition our disk without telling us? > If it did, then it must have zapped some files. > It really is 50MB. > d) Can we use it for something else, like an NFS partition? > no > e) If we can't use it for anything else, can we reclaim the disk space? > (If in fact is really is using disk space) > Since it doesn't use any space that wasn't already allocated, this isn't a problem. > f) What the F**k's it for? Why did it just show up unannounced, with no > documentation about what it's doing. > /debug is used by debuggers and other programs that like to control processes other than themselves. The idea is that when you access a file in the /debug partition, the kernel actually performs an operation on another process. This is what allows dbx to attach to a running process. If /debug won't remount, check your /etc/fstab. it should have this line in it: /debug /debug dbg rw 0 0 If it doesn't, put it back. If it does, make sure that the /debug mount point is still there. If both conditions are true, then I have no idea what you've done to your system. Try re-installing 3.0, or waiting for the maintenance release to get there. There will be a man page for /debug in the next general software release. > Thanks, > Bernie Kirby. You're Welcome, Archer Sully ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa18882; 28 Jul 88 15:30 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16771; 28 Jul 88 13:33 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16750; 28 Jul 88 13:25 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id ab01345; 28 Jul 88 11:38 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA17986; Wed, 27 Jul 88 17:42:40 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 88 14:18:57 GMT From: Gary Tarolli Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: the /debug partition Message-Id: <18020@sgi.SGI.COM> References: <8807260558.AA07135@uunet.UU.NET> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA /debug is the swap partition made visible. Files are actually pids, file size is the process size. The "df" command reveals the swap partition's size, usage, and availability. As for the documentation and how to get /debug mounted again, I don't know... ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19444; 28 Jul 88 16:01 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa17011; 28 Jul 88 13:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16807; 28 Jul 88 13:31 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa02049; 28 Jul 88 11:45 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA18365; Wed, 27 Jul 88 18:01:50 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 88 16:52:58 GMT From: "D. Christopher Dunlap" Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: the /debug partition Message-Id: <18025@sgi.SGI.COM> References: <8807260558.AA07135@uunet.UU.NET>, <18021@sgi.SGI.COM> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <18021@sgi.SGI.COM>, archer@elysium.SGI.COM (Archer Sully) writes: > > If /debug won't remount, check your /etc/fstab. it should have this > line in it: > > /debug /debug dbg rw 0 0 > > If it doesn't, put it back. If it does, make sure that the /debug > mount point is still there. If both conditions are true, then I > have no idea what you've done to your system. Try re-installing > 3.0, or waiting for the maintenance release to get there. > > There will be a man page for /debug in the next general software release. > > > Thanks, > > Bernie Kirby. > > > You're Welcome, > Archer Sully > > Actually, the thing that mounts "/debug" is the script "/etc/rc2.d/S01MOUNTFSYS". This is the script that actually does the mounting of the filesystems, and if you look in there, you will see that it explicitly mounts "/debug". Chris Dunlap Silicon Graphics "I Knew something Archer didn't know.... YA YAAA YA YA.." P.S. You should NEVER touch anything in those directories. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02249; 30 Jul 88 11:26 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02174; 30 Jul 88 10:13 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02152; 30 Jul 88 10:04 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.ARPA id aa09331; 30 Jul 88 9:57 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA23209; Sat, 30 Jul 88 06:01:33 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Jul 88 20:12:45 GMT From: Larry Grose Organization: CAMAX Systems Inc, Minneapolis, MN Subject: Re: the /debug partition Message-Id: <174@camax01.UUCP> References: <8807260558.AA07135@uunet.UU.NET> Sender: info-iris-request@BRL.ARPA To: info-iris@BRL.ARPA In article <8807260558.AA07135@uunet.UU.NET> bernie@cidam.rmit.OZ.AU (Bernard Kirby) writes: > >We recently had one of our machines upgraded to a 4D-70GT running >version 3 of the operating system (4sight 1.0 etc). After all the >software was installed we noticed that a "df" showed an "extra" >partition /dev/debug of type dbg mounted on /debug. It was about >50Mb in size! There appeared to be files in the /debug directory, >but whenever you tried to look at them, nothing happened, like they >were zero length files, except that "ls -l" showed that some of them >were quite large in size. The number and size of files varied as the >machine was used. This partition was not in /etc/fstab but was in >/etc/mtab. So, one day in a fit of experimentality we simply "umount"ed >it, and it hasn't reappeared since, even after a reboot. (Specific questions deleted.) Basically, this is your standard swap partition which has been there all along. There has been no change in your disk partitioning. Each file in the partition corresponds to a running task (I believe the file "name" is the process id), and the size of the file corresponds to the size of the process's virtual memory. Our in-house users had the same questions about whether or not that partition could be used for storing files, and the answer from SGI was "no". This window into the swap partition was made available so that you could debug programs that were already running (I didn't ask how). One other convenient use is that you can quickly see how full virtual memory is by doing a 'df'. I haven't tried dismounting it, but I don't imagine there should be any problem with it if it bothers you to see it in the 'df' listing. I agree with the complaint about the lack of documentation concerning it. It was a rather disconcerting thing for us to discover, too. -- Larry Grose CAMAX Systems, Minneapolis MN ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13780; 1 Aug 88 13:57 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12296; 1 Aug 88 12:34 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12258; 1 Aug 88 12:14 EDT Received: from NRTC.NORTHROP.COM by SMOKE.BRL.ARPA id aa01594; 1 Aug 88 12:02 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa24519; 1 Aug 88 9:02 PDT Date: Mon, 1 Aug 88 8:46:41 PDT From: Fletcher Robinson To: info-iris@BRL.ARPA Subject: autoboot Message-ID: <8808011202.aa01594@SMOKE.BRL.ARPA> Is there a way to have a 4D automatically reboot on power up? ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00426; 1 Aug 88 20:09 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00354; 1 Aug 88 19:07 EDT Received: from brl-smoke.arpa by VMB.BRL.MIL id aa00326; 1 Aug 88 18:56 EDT Received: from NPS-CS.ARPA by SMOKE.BRL.MIL id aa02450; 1 Aug 88 18:37 EDT Received: by nps-cs.arpa (5.51/1.26) id AA11432; Mon, 1 Aug 88 15:35:59 PDT Date: Mon, 1 Aug 88 15:35:59 PDT From: mark fichten Message-Id: <8808012235.AA11432@nps-cs.arpa> To: info-iris@BRL.MIL Has anyone came across the following problem under 4Sight ver. 1.0: The first popup menu that my program calls, sometimes fails to display on the screen, however each selection 'bar' will appear if I move the mouse over it. The title will not appear at all. All subsequent popups display perfectly. This problem occurs about once in every 40 or so runs of the program. Mark Fichten fichten@nps-cs.arpa ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06809; 5 Aug 88 14:41 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05030; 5 Aug 88 9:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05025; 5 Aug 88 9:49 EDT Received: from DREA-XX.ARPA by SMOKE.BRL.MIL id aa04771; 5 Aug 88 9:41 EDT Date: Fri, 5 Aug 88 10:28:25 ADT From: Jim Diamond Subject: [Jim Diamond : sendmail] To: info-iris@BRL.MIL Message-ID: <12420005599.16.DIAMOND@DREA-XX.ARPA> We have a 3130 which is connected to a local area network (speaking TCP/IP). One of the systems on the LAN is an arpanet gateway. I wanted to get sendmail set up to communicate with the rest of the world. I tried reading the S.G. documentation. It talked about a couple of files in a directory which didn't even come with our system. Thus that was little use. I tried modifying the copy of the sendmail.cf file which came with the system, according to the instructions contained therein. That didn't help either. Depending on how I set it up, I either get "user unknown" or "host unknown" type messages. Since we have ftp and telnet working fine, I assume that the problem is most likely with my sendmail.cf file and not elsewhere. Before I spend possibly outrageous amounts of time becoming a sendmail expert, is there anyone out there who can either 1) enlighten me with a few sentences, or 2) send me a working sendmail.cf for a similar system. Thanks. Jim Diamond diamond@drea-xx.arpa ------- ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05041; 8 Aug 88 0:30 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04814; 7 Aug 88 23:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04797; 7 Aug 88 22:57 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa05946; 7 Aug 88 22:51 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA00553; Sun, 7 Aug 88 19:46:03 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Aug 88 21:51:47 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: 'expand.c' diffs for ksh-i under SGI UNIX Message-Id: <18617@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Several people have asked for what I did to make ksh filename handling work under IRIX. Following is a context diff for 'expand.c' in the sh/ directory. Apply by hand or with 'patch' or other suitable tool. Note that this is for KSH-I. For older versions of ksh, the fix is essentially identical. (I've been involved with SIGGRAPH very heavily the last few weeks, and thus the delay ...). Also remember to add '-lsun -lbsd' in the link line to insure getting routines that cooperate with NFS and Yellow Pages. -- Jim Barton Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' -- ----------------------- cut here ------------------------------------ *** expand.c Sun Aug 7 14:35:27 1988 --- Oexpand.c Sun Aug 7 14:35:38 1988 *************** *** 22,27 #include #include #include "defs.h" #include "brkincr.h" #include "stak.h" --- 22,28 ----- #include #include + #include #include "defs.h" #include "brkincr.h" #include "stak.h" *************** *** 28,45 #include "sym.h" #include "shtype.h" - #ifdef mips - # define BSD_4_2 - # include - #else - # ifdef sgi - # define BSD_4_2 - # include - # else - # include - # endif - #endif - void rm_files(); int expand(); --- 29,34 ----- #include "sym.h" #include "shtype.h" void rm_files(); int expand(); *************** *** 83,92 /* this union forces enough space for the NULL byte */ union Dirent { - # ifdef mips - struct dirent entry; - char entrybuf[sizeof(struct dirent)+1]; /* room for null byte */ - # else struct direct entry; char entrybuf[sizeof(struct direct)+1]; /* room for null byte */ # endif --- 72,77 ----- /* this union forces enough space for the NULL byte */ union Dirent { struct direct entry; char entrybuf[sizeof(struct direct)+1]; /* room for null byte */ }; *************** *** 89,95 # else struct direct entry; char entrybuf[sizeof(struct direct)+1]; /* room for null byte */ - # endif }; union Dirent dirent; # ifdef mips --- 74,79 ----- { struct direct entry; char entrybuf[sizeof(struct direct)+1]; /* room for null byte */ }; union Dirent dirent; struct direct *entry = &dirent.entry; *************** *** 92,100 # endif }; union Dirent dirent; - # ifdef mips - struct dirent *entry = &dirent.entry; - # else struct direct *entry = &dirent.entry; # endif #ifndef BSD_4_2 --- 76,81 ----- char entrybuf[sizeof(struct direct)+1]; /* room for null byte */ }; union Dirent dirent; struct direct *entry = &dirent.entry; #ifndef BSD_4_2 char dirbuff[BUFSIZ]; *************** *** 96,102 struct dirent *entry = &dirent.entry; # else struct direct *entry = &dirent.entry; - # endif #ifndef BSD_4_2 char dirbuff[BUFSIZ]; #endif /* BSD_4_2 */ --- 77,82 ----- }; union Dirent dirent; struct direct *entry = &dirent.entry; #ifndef BSD_4_2 char dirbuff[BUFSIZ]; #endif /* BSD_4_2 */ ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13530; 8 Aug 88 16:09 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa13340; 8 Aug 88 15:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13338; 8 Aug 88 15:51 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26333; 8 Aug 88 15:40 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA11740; Mon, 8 Aug 88 10:33:55 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Aug 88 15:35:50 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: Better KSH-I 'expand.c' diffs Message-Id: <18631@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Looking back, I realized that the context diff I posted was pretty confusing for the ksh expand.c changes needed. They really are simple. Here is a simple 'diff' comparison: < old expand.c > new expand.c The #ifdef sgi is for IRIS machines, the #ifdef mips is for the 4D series. 25d24 < #include 31a31,42 > #ifdef mips > # define BSD_4_2 > # include > #else > # ifdef sgi > # define BSD_4_2 > # include > # else > # include > # endif > #endif > 74a86,89 > # ifdef mips > struct dirent entry; > char entrybuf[sizeof(struct dirent)+1]; /* room for null byte */ > # else 76a92 > # endif 78a95,97 > # ifdef mips > struct dirent *entry = &dirent.entry; > # else 79a99 > # endif -- Jim Barton Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' -- ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15143; 8 Aug 88 20:10 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14842; 8 Aug 88 18:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14827; 8 Aug 88 18:37 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa28901; 8 Aug 88 18:28 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA16990; Mon, 8 Aug 88 14:43:50 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Aug 88 17:09:45 GMT From: Jeff Doughty Organization: Silicon Graphics Inc, Mountain View, CA Subject: The /debug partition Message-Id: <18635@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've seen a few questions concerning the /debug partition. I developed the interface and modified dbx to deal with it, so I'll try to explain it as clearly as I can. The /debug file system is modeled after AT&T's /proc file system. It is entirely a software construct where "files" under /debug are actually handles to running UNIX processes. Currently, it is used exclusively by dbx to trace multiple processes. For example, to set a breakpoint in a running process, dbx will open() the corresponding /debug file. It will then make a fcntl() call on the file descriptor to suspend the process. It will then lseek() to the desired address, and write() a break instruction there. Many users are concerned about the size of the partition. The most important point I want to stress is that it DOES NOT use any disk space. It is a file system (under System V's file system switch), but it is, as I have said, entirely a software construct. We could conceivably build file systems where file name actually represent remote files (already done) or processors in a multiprocessor system (a fun idea!). We used the /debug file system since it seemed a natural, efficient way to access UNIX processes rather than to continue to hack on ptrace(). There were, and are, lots of ideas about where to go with the /debug directory. For example, several people suggested having "rm /debug/XXX" mean the same as "kill -9 /debug/XXX". One idea I took seriously was making df /debug return something meaningful. I thought about it, and since the "size" of /debug files represented process size, the total capacity of the /debug system should really be the total capacity of process size (virtual memory) in the system. So the available field of a df listing really represents the total virtual memory available in the system: swap + real memory. Jeff Doughty ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23685; 9 Aug 88 15:05 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa22826; 9 Aug 88 13:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22787; 9 Aug 88 13:14 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa12916; 9 Aug 88 13:01 EDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA02797; Tue, 9 Aug 88 08:28:15 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Aug 88 14:52:34 GMT From: Ken Seefried iii Organization: School of Information and Computer Science, Georgia Tech, Atlanta Subject: old sgi machines... Message-Id: <17350@gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone still run the old 1400 and 2400 series silicon graphics machines? Does SGI still support them? thanks... ken seefried iii ken@gatech.edu ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28879; 10 Aug 88 1:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa27959; 10 Aug 88 0:24 EDT Received: from orville.nas.nasa.gov by VMB.BRL.ARPA id aa07518; 12 Jul 88 14:16 EDT Received: Tue, 12 Jul 88 11:15:42 PDT by orville.nas.nasa.gov (5.54/1.2) Date: Tue, 12 Jul 88 11:15:42 PDT From: David A. Tristram Message-Id: <8807121815.AA05461@orville.nas.nasa.gov> To: info-iris-request@vmb.brl.mil Subject: NeWS Resent-Date: Wed, 10 Aug 88 0:12:15 EDT Resent-From: Chuck Kennedy Resent-To: info-iris@BRL > The button up problem was a bug and it has been fixed in the 3.0 > maintenance release. > > There is no question that server programming is hard. However all > the PostScript source is delivered (it has to be, of course) and > anyone who develops an understanding of it can change it. The ASCII > terminal is suggested because during development it is easy to > make mistakes that render the server inoperative and the ASCII terminal > provides a way to connect to the server and find the problem, to look > at the logfile output and to kill the server. > > This is not true for programming in the user.ps file. This is protected so > that if an error is detected while reading it the server ignores the > entire contents and runs as if you didn't have a user.ps file. > > -Mark I'm pleased to hear that the button up problem has been fixed, we're looking forward to receiving our mantenance release. Thanks to Archer and Mark for your responses. Mark, while its true that syntax errors or stack operand errors in a user.ps file will not crash the server, it is possible (even easy) to write correct PostScript code that, when executed in the course of processing a user.ps file, will hang or terminate the server. I guess I am taking exception to your implication that programming the server via a user.ps file is 'safe'. Dave Tristram ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29257; 10 Aug 88 4:36 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa29163; 10 Aug 88 3:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29145; 10 Aug 88 3:01 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa00381; 10 Aug 88 2:56 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA17408; Tue, 9 Aug 88 22:17:17 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Aug 88 14:30:14 GMT From: Rob Gabbard Organization: Structural Dynamics Research Corp., Cincinnati Subject: SGI 4D NFS/Ethernet problems Message-Id: <343@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've been having problems with NFS and Ethernet on a CS-12 and I was wondering if anyone else was having the same problems. I've got a CS-12 with 4 380 meg disks, 3 of which are mounted via NFS to a number of 4Ds. Under 3.0 I used to get the message "if_enp0: firmware died and restarted" followed by "if_enp0: failed to restart" and then no Ethernet operations would work until a reboot or /etc/init.d tcp stop and /etc/init.d/tcp start. This would happen 2 to 3 times a week. Under 3.0 Rev B I haven't gotten these messages yet (only been running it 2 days) but after about a day and a half of heavy trafic on the CS-12 I get ALOT of NFS timeouts on the 4Ds onto which the CS-12's drives are mounted on. Also, I was using bootp to upgrade one system without a tape drive with one that had a tape drive and on the one with the tape drive I was getting "if_enp0: firmware died and restarted" messages a couple of times during the remote tape operations which hosed my update. I got this same symptom on 2 different systems. (both 4Ds) I've talked to SGI about this and they were going to test their Ethernet driver under heavy load since that was where the problem seemed to lie. I haven't heard anything back from them yet on the outcome. Archer, are you out there ? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard | UUNET: uunet!sdrc!crgabb Workstation Systems Programmer | PHONE: (513)576-2600 Structural Dynamics Research Corporation | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03909; 10 Aug 88 11:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa02422; 10 Aug 88 9:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02386; 10 Aug 88 9:34 EDT Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa05453; 10 Aug 88 9:29 EDT Received: Wed, 10 Aug 88 09:30:05 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 10 Aug 88 09:30:05 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8808101330.AA10110@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Pop-up Menus I am tring to use the advanced menu formats from FORTRAN, but they don't work. The main problem I am having is when I try to use %F or %f in a addtopup. The functions either not called or the program bombs. Has anyone tried to use SGI's menus? The people I have talked to here; have either given up or didn't bother to try and wrote there own menu software. I would like to try SGI's. Any suggestions? ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03909; 10 Aug 88 11:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02422; 10 Aug 88 9:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab02386; 10 Aug 88 9:34 EDT Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa05524; 10 Aug 88 9:31 EDT Received: Wed, 10 Aug 88 09:31:30 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 10 Aug 88 09:31:30 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8808101331.AA10119@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Pop-up Menus cont. P.S. I wish SGI supported FORTRAN. ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06129; 10 Aug 88 13:56 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04116; 10 Aug 88 12:01 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04054; 10 Aug 88 11:49 EDT Received: from ZORAC.ARPA by SMOKE.BRL.MIL id aa10418; 10 Aug 88 11:35 EDT Received: by zorac.ARPA (4.12/25-eef) id AA10789; Wed, 10 Aug 88 11:35:26 edt Date: Wed, 10 Aug 88 11:35:26 edt From: Tim Pointing Message-Id: <8808101535.AA10789@zorac.ARPA> To: blbates@aero4.larc.nasa.gov, info-iris@BRL.MIL Subject: Re: Pop-up Menus I think that you'll find that your problem is caused by the fortran compiler seeing the %f in the string and assuming that it is a C formatting request. See what happens if you replace it with "%%f" (i.e. double the '%'). Tim Pointing, DCIEM tim@zorac.arpa ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10035; 10 Aug 88 19:20 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa10000; 10 Aug 88 19:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09953; 10 Aug 88 18:56 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa22171; 10 Aug 88 18:44 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA02068; Wed, 10 Aug 88 14:05:07 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Aug 88 19:58:10 GMT From: josh Siegel Organization: Los Alamos National Laboratory Subject: Lemons Message-Id: <14357@hc.DSPO.GOV> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anybody else been having problems with 4D/70GT's and foursight?!? Lets all get together and send a letter to SGI.... --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) I like using a C-47A "puff dragon" to go shooting beer cans with. ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10176; 10 Aug 88 20:23 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09919; 10 Aug 88 18:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09904; 10 Aug 88 18:45 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa22136; 10 Aug 88 18:39 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA01836; Wed, 10 Aug 88 13:55:23 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Aug 88 19:57:09 GMT From: josh Siegel Organization: Los Alamos National Laboratory Subject: Dial box on SGI Message-Id: <14356@hc.DSPO.GOV> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What "tty" is associated with port "a" on a 4D/70GT. We are trying to get diald up and it is asking for the port. thanks much --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) I like using a C-47A "puff dragon" to go shooting beer cans with. ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12528; 11 Aug 88 1:36 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11677; 11 Aug 88 0:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab11650; 10 Aug 88 23:55 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa24880; 10 Aug 88 23:50 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA07861; Wed, 10 Aug 88 19:20:25 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Aug 88 01:12:23 GMT From: Jeff Anton Organization: Postgres Research Group, UC Berkeley Subject: Re: old sgi machines... Message-Id: <4958@pasteur.Berkeley.EDU> References: <17350@gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17350@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: >Does anyone still run the old 1400 and 2400 series silicon graphics machines? >Does SGI still support them? Well, I have a 1400 workstation and a 1000 terminal as the core of my collection of "Personal Computers." There aren't any recent OS upgrades and I understand the line was junked early on. However, I find the machine quite useful for getting my graphics fix and for a home UNIX box which I can code on my own. The 1000 and 1400 share several boards so I hope to survive hardware failure for some time. I'm interested in contacting anyone else who might be running these old machines to exchange hints on management, maintainance, and software. Jeff Anton ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00202; 11 Aug 88 9:49 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14312; 11 Aug 88 7:33 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab14302; 11 Aug 88 7:29 EDT Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa27629; 11 Aug 88 7:25 EDT Received: Thu, 11 Aug 88 07:26:21 EDT by aero4.larc.nasa.gov (5.15/5.6) Date: Thu, 11 Aug 88 07:26:21 EDT From: "Brent L. Bates TAD/HRNAB ms294 x2601" Message-Id: <8808111126.AA02785@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Pop-up Menus cont. I forgot to say that we have a IRIS 3030. ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09863; 12 Aug 88 1:58 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09845; 12 Aug 88 1:55 EDT Date: Fri, 12 Aug 88 1:54:09 EDT From: Chuck Kennedy To: info-iris@brl.mil Subject: mailing list change of address Message-ID: <8808120154.aa09633@VMB.BRL.MIL> Folks, Info-Iris is changing it's address. It's new address is: info-iris@BRL.MIL Please make a note of it. Also, requests to the coordinator (me), etc. should now go to: info-iris-request@BRL.MIL All this because of the demise of the .arpa domain. I announced this at the Iris User Forum at SIGGRAPH, but some may have missed the announcement. And unfortunately, not everybody goes to SIGGRAPH. Info-iris@BRL.ARPA may work for a while longer but don't rely on it. Best, -Chuck Kennedy ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15387; 12 Aug 88 8:16 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13222; 12 Aug 88 6:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab12775; 12 Aug 88 6:09 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21035; 12 Aug 88 5:53 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA03604; Thu, 11 Aug 88 21:46:00 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Aug 88 12:50:24 GMT From: Stephen King Organization: D.C.I.E.M., Toronto, Canada Subject: Re: old sgi machines... Message-Id: <906@client2.DRETOR.UUCP> References: <17350@gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17350@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: >Does anyone still run the old 1400 and 2400 series silicon graphics machines? Yes, we have two of these ^^^^ >Does SGI still support them? No. But we can still get replacement parts. To the best of my knowledge, the 2400T (Turbo - 68020) is the 'base' machine for SGI. Most software is being written for this, or the 4D. For our non-turbo 2400 there is no longer a software subscription service; we do self-maintenance and can get boards to swap, so I assume SGI will still service these machines themselves. Hope this helps. -- ***** DCIEM Simulation & Training Group *********** Stephen J King ********** - is not responsible for this message. {utzoo|mnetor}!dciem!dretor!king ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18091; 12 Aug 88 11:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17957; 12 Aug 88 10:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab17949; 12 Aug 88 10:52 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27220; 12 Aug 88 10:46 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA11233; Fri, 12 Aug 88 04:20:33 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Aug 88 19:19:56 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: Lemons Message-Id: <475@voodoo.UUCP> References: <14357@hc.DSPO.GOV> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <14357@hc.DSPO.GOV> siegel@hc.DSPO.GOV (josh Siegel) writes: >Has anybody else been having problems with 4D/70GT's and foursight?!? > >Lets all get together and send a letter to SGI.... > > --Josh Siegel Yeah, we're having problems with our 4D/70GT, but nothing too serious. The biggest problem we had was that our application ran about 6 times slower on the GT than a 4D/70G when we first ported it over. It took us a while to find the problem, but once it was found, it was a very easy fix -- it seems that popattributes is very expensive on the GT (it also does not restore the color attribute correctly), so we put in or own code to emulate push/popattributes, and most everything works fine (and fast, except for picking, which we're working on). Another problem we're working on now is that some keys generate extra events -- so far we've identified ENTER and DELETE. The work around for these is very simple -- just check for those extra events and discard them. There's a bunch of other small problems that we'll work when we get the time (cursors don't look quite the same is one that comes to mind). I think it's important to keep things in perspective. Porting existing code to a 4D/70GT is a two step port -- a port to 4SIGHT (or is it 4SITE?) and a port to the the GT architecture. There are bound to be some problems. We are getting good response from SGI in fixing bugs -- we've had the GT since the end of June and have received 3 system software releases (one just arrived yesterday, but I haven't had time to install it). We also had LOTS of problems with our 4D60 Turbos (now called 4D/70G's) when we got them in during August of last year -- it took a couple months to shake out the big bugs but they're running fine now. We like 'em so much we've got 22 in production and 4 for development. The workstation market is extremely competitive. I think that forces vendors to get things out the door a bit too quickly at times. SGI is no exception. We have found new systems from SGI (and other vendors for that matter) to be buggy at first. That is a price we're willing to pay to keep on the leading edge. We look forward to getting new systems from SGI. Now, if SGI would only support C++... -- Mike York Boeing Computer Services, Renton, Washington (206) 234-7724 uw-beaver!ssc-vax!voodoo!zombie ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00254; 12 Aug 88 23:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22271; 12 Aug 88 20:28 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa22266; 12 Aug 88 20:20 EDT Date: Fri, 12 Aug 88 20:11:21 EDT From: Phil Dykstra To: Mike York cc: info-iris@BRL.MIL Subject: Re: Lemons Message-ID: <8808122011.aa28652@SPARK.BRL.MIL> > The biggest problem we had was that our application ran about 6 times > slower on the GT than a 4D/70G when we first ported it over. We had a similar surprise. A display manager for our solid modeling package ran at first about half as fast on the 4D/70GT as it did on the 4D/60! After some head scratching we realized the problem: on every screen update we were also updating the status of the function key lights on the keyboard. The keyboard interface on the 70GT must be slower than on the 60; apparently only 9600 baud. After removing the keyboard update the tide happily turned in favor of the 4D/70GT. - Phil ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08261; 14 Aug 88 22:20 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa08064; 14 Aug 88 21:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08051; 14 Aug 88 20:58 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa20618; 14 Aug 88 20:52 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA04507; Sun, 14 Aug 88 16:44:38 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Aug 88 16:54:48 GMT From: Barnacle Wes Organization: the Well of Souls Subject: Re: old sgi machines... Message-Id: <152@obie.UUCP> References: <17350@gatech.edu>, <906@client2.DRETOR.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <906@client2.DRETOR.UUCP>, king@client2.DRETOR.UUCP (Stephen King) writes: > In article <17350@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: > >Does anyone still run the old 1400 and 2400 series silicon graphics machines? > Yes, we have two of these ^^^^ > >Does SGI still support them? > No. But we can still get replacement parts. Does anyone out there know of any of the older SGI machines for sale? I would be very interested in picking one up if they're available for a reasonable price. Is the software written for the newer machines (like the 4D) compatible with the older machines? I assume the software written for the older ones runs OK on the newer ones, right? Thanks, Wes Peters -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein -- ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00368; 16 Aug 88 5:32 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00229; 16 Aug 88 4:29 EDT Received: from [192.5.23.3] by VMB.BRL.MIL id aj00151; 16 Aug 88 4:12 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01136; 16 Aug 88 2:47 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA22361; Mon, 15 Aug 88 13:57:39 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Aug 88 18:05:15 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: old sgi machines... Message-Id: <19239@sgi.SGI.COM> References: <17350@gatech.edu>, <906@client2.DRETOR.UUCP>, <152@obie.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL SGI will sell you new or used 3000 series machines for very good prices. This is part of our remarketing program for these machines. Contact Craig Olson at the factory in Mountain View (408-962-3360) for details. -- Jim Barton Silicon Graphics Computing Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb -- ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10400; 16 Aug 88 17:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10378; 16 Aug 88 16:49 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10308; 16 Aug 88 16:36 EDT Received: from CORNELLC.CCS.CORNELL.EDU by SMOKE.BRL.MIL id aa17154; 16 Aug 88 16:19 EDT Received: from UALTAMTS.BITNET by CORNELLC.CCS.CORNELL.EDU ; Tue, 16 Aug 88 16:20:59 EDT Date: Tue, 16 Aug 88 13:49:56 MDT From: Mark Israel Subject: Queries about fonts, mex, and Unipress emacs on the Iris 3030 To: info-iris@BRL.MIL Message-Id: <1264367@UALTAMTS.BITNET> (1) When the Iris 3030 first boots up, a really beautiful font appears on the console screen. This is replaced fairly early in the booting procedure by "iris10.fnt". The original font does not appear in /usr/lib/gl2/fonts, and I imagine it's defined in the hardware. Does anyone know of a way of re-loading it? (2) Is there a function I can call from a program which will cause the Iris console to exit mex? I have a program that needs mex to run, and I would like it to call ismex() at the beginning, start up mex, run, and then if the user wasn't in mex at the beginning, exit mex. At the moment I have to leave it to the user to exit mex, because I can't figure out a way to make the program do it. (3) We are running version GL2-W3.6 on our Iris 3030 and have the same version of Unipress Emacs. When I try to run Emacs from the console and when not in mex, Emacs seems to think my screen is much bigger than it actually is. When my font is default.fnt, the top of my screen displays the middle of line 14, and there is no way of windowing back to the first 13 lines. The smaller the font I use, the greater the number of hidden lines. The "-L" option doesn't seem to do anything; and "set-screen-lines" doesn't help, because it causes the screen to be truncated at the bottom rather than at the top! I have no problem whatever when using emacs from within mex, or from a remote terminal. Has anyone out there encountered a similar problem, or have an idea how I might fix it? Mark Israel Bitnet: USERISRA@UALTAMTS Usenet: Mark_Israel@uqv-mts.alberta ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11863; 17 Aug 88 1:33 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11483; 16 Aug 88 23:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11479; 16 Aug 88 23:14 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01711; 16 Aug 88 22:56 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA21182; Tue, 16 Aug 88 16:40:08 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Aug 88 22:07:14 GMT From: "G. Murdock Helms" Subject: 3.0 System with 4Sight for the 4D Message-Id: <1318@eos.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We just recently received the 3.0 system upgrade for our 4D. We're still noticing the enp0: bad receive packet errors, and are also still experiencing the "correctable data error" messages during backups. Was the data error problem and/or the packet problem supposed to be fixed in this update? -Murdock PS I've also been asked if there will be a TCP version of arena. ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12052; 17 Aug 88 2:04 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab11483; 16 Aug 88 23:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab11479; 16 Aug 88 23:14 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01723; 16 Aug 88 23:01 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA21268; Tue, 16 Aug 88 16:44:46 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Aug 88 16:51:41 GMT From: "Dr. R.P. Alston x8225 " Organization: Raytheon Company, Marlborough MA Subject: TBL broken on SGI 3130 running 3.6 but not 3.5 Message-Id: <232@turbo.RAY.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Am I going nuts or is this really true. The following file drops a core on doing a tbl tbl_dump when I do it on our recent (early august 88) 3130 running the SGI 3.6 distribution, yet if I do it on an older 2400T (running 3.5) it works fine and when run through troff generates the correct output. Can someone else confirm this so I can then go and breath on the SGI hotline. ================================================================== ==== text of tbl_dump ==== ==== replace all # with a tab character (ctrl-I) before using ==== ================================================================== -- CUT HERE -- .TS center box; l l l l c | n | n l. Partition#Starting Cylinder#Size in Cylinders#Description _ a#1#75#(root) b#76#75#(swap) c#151#75#(diskless root) d#226#75#(diskless swap) e#301#439#(user) f#740#470#(other) g#1#1210#(all less label) h#0#1210#(all) .TE -- ------------------------------------------------- # Whats worse than two MA drivers on a freeway? # Dr. Robin the REAL # Answer: One Toronto driver # SuperUser Atilla! ------------------------------------------------- (617)-490-3028 Robin@turbo.ray.com .....!rayssd!turbo!Robin ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21492; 17 Aug 88 20:06 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19622; 17 Aug 88 15:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19550; 17 Aug 88 15:17 EDT Received: from amsaa-seer.arpa by SMOKE.BRL.MIL id aa16697; 17 Aug 88 15:04 EDT Date: Wed, 17 Aug 88 14:54:56 EDT From: Del Hanson (AWD) To: info-iris@BRL.MIL Subject: Digitized Terrain Models Message-ID: <8808171454.aa08382@AMSAA-SEER.AMSAA-SEER.ARPA> I am looking for any models which can be used to display digitized terrain data on a 4D/60T. Our IRIS does not have a graphics turbo board, but we may be able to get one if necessary. If anyone knows of a model, please send me a contact name. Thanks. Del Hanson (dhanson@amsaa-seer.arpa) ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22246; 18 Aug 88 0:40 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa21943; 17 Aug 88 22:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21939; 17 Aug 88 21:59 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21468; 17 Aug 88 21:50 EDT Received: by ucbvax.Berkeley.EDU (5.59/1.30) id AA02612; Wed, 17 Aug 88 18:34:09 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.arpa (info-iris@brl.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Aug 88 23:08:30 GMT From: "G. Murdock Helms" Subject: /debug partition Message-Id: <1334@eos.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I noticed our /debug partition is 14% full. It has collected quite a few files in it that date back several days. I remember Archer saying that /debug was used by debuggers and other programs, but what I don't remember was anyone asking how often /debug cleans up after itself. Does it have a magic date it does this on, or does root have to periodically empty /debug out? -Murdock ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25904; 18 Aug 88 9:40 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa25591; 18 Aug 88 9:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab25490; 18 Aug 88 9:15 EDT Received: from SGI.COM by SMOKE.BRL.MIL id aa26283; 18 Aug 88 9:03 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.SGI) (for info-iris@brl.arpa) id AA03452; Thu, 18 Aug 88 06:01:14 PDT Received: by elvin.sgi.com (5.51/880418.SGI) (for info-iris@brl.mil) id AA00589; Tue, 16 Aug 88 14:10:40 PDT From: Frank Dietrich Message-Id: <8808162110.AA00589@elvin.sgi.com> Date: 16 Aug 1988 1410-PDT (Tuesday) To: info-iris@BRL.MIL Subject: Iris Universe & Software Exchange For those of you who have not yet received a copy of the new Iris Universe Magazine. It has just been published and copies are available free for users of Iris workstations. Please send me your mailing address. Thanks to all contributors who made this project so exciting. In particular it was a lot of fun to print a set of very nice color images with direct digital color conversion methods. We are now preparing the next issue to be published in November. Deadline for articles and visual contributions is September 15. Frank ------- Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25904; 18 Aug 88 9:40 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab25591; 18 Aug 88 9:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25518; 18 Aug 88 9:15 EDT Received: from SGI.COM by SMOKE.BRL.MIL id aa26299; 18 Aug 88 9:06 EDT Received: from elvin.sgi.com by sgi.sgi.com (5.52/880418.SGI) (for info-iris@brl.arpa) id AA03443; Thu, 18 Aug 88 06:00:53 PDT Received: by elvin.sgi.com (5.51/880418.SGI) (for info-iris@brl.mil) id AA00528; Tue, 16 Aug 88 13:51:12 PDT From: Frank Dietrich Message-Id: <8808162051.AA00528@elvin.sgi.com> Date: 16 Aug 1988 1351-PDT (Tuesday) To: info-iris@BRL.MIL Subject: TeX on Iris Does anybody have information about the availability of TeX or a dialect of TeX on the Iris? There are quite a number of requests from Iris Users, but we have been unsuccessful to identify a reliable source for TeX within the Software Exchange. Please contact me directly or post to info-iris. Frank Dietrich SGI, User Services