HDTenEightyP/NetNews huggingface dataset:
From: rgs@megatek.uucp (Rusty Sanders)
Newsgroups: comp.sys.sgi
Subject: Re: R4000 compiler directive, is there one ???
Date: 14 Aug 92 18:01:01 GMT
Organization: Megatek Corporation, San Diego, California

From article <1992Aug13.181236.18013@Veritas.COM>, by rogerk@Veritas.COM (Roger B.A. Klorese):
> In article <ogn3in4@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
[>>| from rgs@megatek.com   don't omit attributions like this please ]
>>| I seem to remember seeing in some version or other of the compiler
>>| (sorry, I don't know if it was beta, release, or what) that there
>>| was a switch -r4000.
>>
>>It is passed on to the assembler untouched, and the comments there
>>lead me to believe your recollection about instruction scheduling
>>is correct, but I don't know enough about compilers to know what
>>exactly (if anything!) it is doing.
> 
> It's omitting delay-slot nops.

It definitely does more than this, as I know it was causing a different
scheduling of floating point operations. As John Mashey has said in
a related article to this string, that's where most of the scheduling
differences will be between an R3000 (or R6000 for that matter) and an
R4000.

Net result; if you're using floating point on an R4000 you probably
should use -mips2 -r4000 to get best performance. Does MIPS/SGI
actually support (i.e. accept bug report calls) on the undocumented
-r4000 switch?

As an aside, the last time I looked at it, while -r4000 generated
much better scheduled code for the R4000, it was in no way optimal.
It appeared to (at that time) have a rather limited grasp of the
complexities of the R4000 floating point pipe. The one example of
that I saw (way back when) was that it scheduled mul.s executions
every 4 clocks (just like a mul.d), when they can actually be
scheduled every 3. Also, it looked like it didn't have a good idea
of the interactions between the multiplier and the adder (they do
have some rather nasty interactions).

Of course, SGI could fix this by "just" fully pipelining the adder
and multipliers. It's only silicon, after all :-).
-- 
----
Rusty Sanders, Megatek Corp. --> rgs@megatek.com or...
         ...ucsd!    ...hplabs!hp-sdd!    ...ames!scubed!   ...uunet!
Newsgroups: comp.sys.sgi
From: mogal@deadhead.asd.sgi.com (Joshua Mogal)
Subject: Re: SGI shadows/help
Organization: Silicon Graphics, Inc.
Distribution: usa
Date: Wed, 19 Aug 1992 01:50:46 GMT

In article <1992Aug10.153515.14594@husc3.harvard.edu>, basu@scws4.harvard.edu (Archan Basu) writes:
|> Hi!
|> 
|> 	I'm working on a Vision application on the SGI Iris Indigo.
|> The current problem is to render a human face (from lazer rangefinder data)
|> including cast shadows, say across the left eye due to occlusion by the 
|> nose, of incident light from the right. The face is an 86x31 rectangle
|> represented as a polygonal mesh (~5000 triangles) or perhaps as a NURB
|> with ~2600 control points. 
|> 
|> 	The shadows, ofcourse, are the stumbling block. One idea I had was
|> (assuming access to SGI's internal data representations, including
|> transform's, zbuffer's, etc): Place eye at light source. Perform hidden
|> surface elimination, and save zbuffer. Now transform to actual eye frame.
|> Determine, for each viewport pixel, whether its corresponding scene point 
|> was visible to light source. Hence, shade bright or dark.
|> 
|> 	Have others tried this? Are there other approaches? Where can I get
|> the info I need to access SGI memory, etc? I need your help BADLY. Please
|> respond with any relevant thoughts to basu@zeus.harvard.edu


Try checking back issues of the IRIS Universe magazine.  There was an article two or three issues back on using Stencil planes for shadow generation.  The article was written for a VGX class graphics machine, but it might work in software on an Indigo - try it out.

Joshua Mogal
Product Manager
Advanced Graphics Division
From: russo@rudedog.nrl.navy.mil (Kevin Russo)
Newsgroups: comp.sys.sgi
Subject: Missing Prototypes - Solution!
Keywords: prototypes, irix
Date: 22 Aug 92 02:52:12 GMT
Organization: Naval Research Lab, Washington, DC


Since we're all ANSI-fying our code these days, several people may
have run into the ol' missing prototype problem. It seems that the
prototype declarations for some system and library routines are not
anywhere to be found in the header files. (It's always the one you
want, too.)

I began investigating these inconsistencies between the man pages
and header files (IRIX 4.0.4) a few weeks ago.  I found that the
functions fell into 5 states of documentation.

Functions whose man pages...
 o were in sync with the #include files. These are what we want!

 o listed no #include files *and* the function was not prototyped
   in any header file.

 o listed no #include files but the function was prototyped in
   *some* header file.

 o listed #include files(s) but the function was prototyped somewhere else.

 o listed #include files(s) but the function was not prototyped anywhere.

Combinations! Permutations!
And of course there were some functions declared in headers but
had no man page. I'm not interested in these undocumented guys.

A few shell and awk scripts later, and there were ~280 functions whose
man pages didn't jive with the /usr/include tree.

In fairness to SGI, the IRIX man pages come from many sources outside
of SGI, eg AT&T, Sun, BSD, Mips, X11, and a good many of the ones with
problems were from those places. (I didn't attempt to check the X11 tree.)

I put all the missing prototypes and extern variables in one jumbo
header file. Since the file is 530 lines, I'm reluctant to post it,
but I'll send it to anyone who wants it. Or I'll post it if there's a
big demand.  Happy Hacking.


Kevin Russo
russo@orion.nrl.navy.mil
SFA, Inc. / US Naval Research Lab, Washington, DC
From: steve@chaos.ocean.fsu.edu (Steve Van Gorder)
Newsgroups: comp.sys.sgi
Subject: Backup&Restore Tool
Date: 18 Aug 92 17:43:26 GMT

Hi,

When I do a full system backup using the system manager backup-restore tool, 
the date of the last full backup (/etc/lastbackup) is never modified.  
Does anyone know why ?

4D35 running 4.0.1
------------------------------------------------------------------------
 Steve VanGorder                     Internet  steve@chaos.ocean.fsu.edu
 Dept. of Oceanography   B-169       Bitnet    gorder@fsu                
 Florida State University            Phone    (904) 644-2447             
 Tallahassee, Fl 32306               Fax      (904) 644-2581
------------------------------------------------------------------------
From: roberts@nimrod.wpd.sgi.com (roberts)
Newsgroups: comp.sys.sgi
Subject: Re:  4.0.5 and mail
Date: 20 Aug 92 16:17:46 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

suhonen@jalka.jyu.fi (Timo Suhonen) writes:
> 
> Just got 4.0.5 and installed it. Release Notes says that IRIX is now
> 8-bit system with Latin-1 as default.

What release note says that?  I write the release notes for mail/Mail/sendmail
and I never wrote anything of the sort.  In any event, IRIX sendmail is 
not an 8-bit system.  It strips the 8th bit from all incoming and outgoing
mail.

> 					Why does mail clear the 8:th bit?
> I know that RFCs allow mail to do it, but here in Finland I'd like
> to use the Latin-1 character set in my mails.

The RFCs do not *allow* sendmail to do it, they *require* it.  Check the
RFC 822 definition for CHAR from which the entire message is composed.  It
specifically forbids 8-bit characters anywhere within a message.

>                                                The international mails
> also seems to accept 8-bit. At least mails to HP at California (?) and
> mails to Iceland survives full 8-bit. 

You've been lucky.  There is no way to guarantee that 8-bit data will
always survive the trip from point A to point B.  There's no way of telling
whether or not some machine in between will strip the 8-th bit.  There are
*LOTS* of machines out there that do.

Worse yet, deep in the guts of the address parsing mechanism for sendmail
really really nasty things can happen if certain control characters (or what
*look* like control characters after the 8th bit is stripped) turn up.  I
had to write special code for IRIX sendmail to guard against such dangerous
characters in addresses sent by naive "8-bit clean" implementations.

Note that a number of IETF working groups have been studying the problem of
transporting 8-bit data via mail.  Just this week, several new RFCs have been
published:

RFC 1341: MIME  (Multipurpose Internet Mail Extensions):
          Mechanisms for Specifying and Describing
          the Format of Internet Message Bodies
RFC 1342: Representation of Non-ASCII Text in Internet
          Message Headers
RFC 1343: A User Agent Configuration Mechanism
          For Multimedia Mail Format Information
RFC 1344: Implications of MIME for Internet Mail Gateways


	- Robert Stephens
	  Silicon Graphics Inc.
Newsgroups: comp.sys.sgi
From: sysmark@helios.physics.utoronto.ca (Mark Bartelt)
Subject: Re: 4.0.5 confusion (again, still)
Reply-To: mark@cita.toronto.edu
Organization: University of Toronto Physics/Astronomy/CITA
Date: Thu, 20 Aug 1992 14:51:04 GMT

[ Dave Olson ]

| Of course they have 4.0.5A!  4.0.5D isn't released yet, nor is
| the r4k indigo itself.  I don't know how you arranged to get
| the disk, etc. early, but clearly the person with whom you
| arranged it misunderstood either you, or the situation.

To be fair to all involved, it was *me* that misunderstood:  I knew
that we would need 4.0.5D, but thought that SGI made a mistake.  It
turned out, our telesales guy knew what we needed, and *also* knew
that they wouldn't be able to ship the D release with our disk.  So
he's made arrangements for our local office to help us out.  So, it
was a case of me not knowing that he knew, and of me assuming that
he didn't.  He was actually on top of things, just fine.  (Funny
how we techies tend to have a knee-jerk tendency to assume that all
sales people don't know what's going on, isn't it ...)

| As I recall, 4.0.5D has everything different except for motif_eoe
| and other 'non-OS' things, such as nck, netls, explorer, and 
| inventor_eoe.  Hmm; let me say that differently.  In general, there
| is no rule.  It all depends on what was fixed.  I think that for
| 4.0.5A, just eoe1 and eoe2 had differences from 4.0.5.  I'm not
| at all sure what the story is for 4.0.5C.

Hmm...  I guess that doesn't really answer what I wanted to know,
but that's because I didn't really explain just what it was I'd
like to do:  Since many of our systems have *tiny* system disks
(several have Wren-IIIs!), we put only the most important stuff
in / and /usr, and NFS-mount the rest.  I assume that everything
that goes into the kernel is likely to differ among the various
4.0.5 releases, but that doesn't matter to us since it wouldn't
be on the shared-via-NFS disk anyway.

I guess what I'm driving at is:  Which of the non-kernel things
that appear on the 4.0.5D CD cannot be used by a system running
the 4.0.5C kernel; and which things that appear on the 4.0.5C CD
cannot be used by a system running the 4.0.5D kernel?  Is this
even an easy question to answer?

| | Sorry if I seem rather dense about all this, but I am rather confused
| | about what's the most recent officially-supported release for some of
| | our hardware configurations.
| 
| You aren't the only one, by a long shot.

Great!  Confusion loves company!  ;-)

Mark Bartelt                                                   416/978-5619
Canadian Institute for                                mark@cita.toronto.edu
Theoretical Astrophysics                              mark@cita.utoronto.ca

"Sheep not busy being shorn are busy frying" - Dylan, at a NZ lamb barbecue
Newsgroups: comp.sys.sgi
From: mohsen@pele.csd.sgi.com (Mohsen Hosseini)
Subject: Re: Video Card RGB
Organization: Silicon Graphics, Inc.
Date: Fri, 21 Aug 1992 20:50:54 GMT

In article <1992Aug20.233402.3335@news.nd.edu>, pbays@bach.helios.nd.edu (phil bays) writes:
|> In order to make the cable to connect to the 9 pin 
|> RGB input of the projection TV I need to know the 
|> RGB pin outs for the video bard.  I have talked to my 
|> local sales and tech people, the hot line, e mail to 
|> California tech, etc.  In every case, the initial 
|> statement is "that should be easy, we'll get back to 
|> you tomorrow."   The has been going on for three of 
|> four weeks and no one - NO ONE has called me back 
|> yet.  I keep calling and getting the same response - 
|> "we'll call you back" - but alas my phone remains 
|> silent.  Classes start next week.  I would really like to 
|> get this going.  Can anyone out there help???


Are you reffering to the startervideo option for the 
indigo for the starter graphics?

If that is the case, here is the pinout for the 15 pin connector.
pin1 - RED
pin6 -RED GND
pin2 - GREEN
pin8 - GREENGND
pin3 - BLUE
pin5 - BLUE GND
pin 13 - composite TV SYNC

If you are talking about the pinout for the 15pin connector without the
startervideo option, here it is:

Pin	Signal
1	red
2	green
3	blue
4	-not used
5	GND
6	GND
7	GND
8	GND
10	GND
11	GND
12	- Not used
13	H sync
14	V sync
15	- not used



-- 
---
Mohsen Hosseini (mohsen@csd.sgi.com) or (mohsen%relay.csd@sgi.com)

SGI Product Support
Newsgroups: comp.sys.sgi
From: davea@quasar.wpd.sgi.com (David B.Anderson)
Subject: Re: Slow C compiler??
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 13 Aug 1992 03:56:08 GMT

In article <HARI.92Aug12135105@robios5.me.wisc.edu> hari@robios.me.wisc.edu (Kambainathan Hari) writes:
>
>I have a Personal Iris and about a couple of months ago we upgraded
>the Op. System. Before the Upgrade the compilation was *slow* and
>after the upgrade it has gotten *even slower*. 
>
>Is there anything I can do about it like setting flags while using cc,
>or using a different compiler ?? Or is just a case that linking the

You don't say what release you are now on...

 A) If your slowness is due to NFS traffic due to
  remote mounted directories
and
 B) If your upgrade was to 4.0.4 or earlier

1).  you may get some benefit from upgrading to 4.0.5 and the 3.10 compilers
     (both have been released).

2) Be sure that you do NOT remote-mount directly on top of a directory in /

Try removing the -g flag.  If that speeds up compilation significantly,
then 1) will help.

Hope this helps.
[ David B. Anderson             (415)390-1548             davea@sgi.com ]

Xref: sparky comp.sys.sgi:12339 comp.graphics.visualization:1207 comp.graphics:8791
From: ken@uf.msc.edu (Ken Chin-Purcell)
Newsgroups: comp.sys.sgi,comp.graphics.visualization,comp.graphics
Subject: GVLware - patch1
Keywords: volume rendering raster streaming ftp archive
Date: 13 Aug 92 15:18:24 GMT
Reply-To: ken@msc.edu
Organization: AHPCRC, Minnesota Supercomputer Center

There was a minor fix needed in order for Bob, the interactive 
volume renderer, to work under IRIX 4.0.5.  The latest version 
of GVLware, or a patch file if you wish, is now available on 
our archive.

If it wasn't clear from my first posting, source and binaries 
for the SGI are included.  Also, I would suggest that Indigo
and Elan users use the -single option to Bob.

Machine:	ftp.arc.umn.edu (137.66.130.11)
Archive:	pub/gvl.tar.Z (linked to gvl-1.02.tar.Z)
Patch:	pub/patch-1.01-1.02

-- 
--  Ken Chin-Purcell, Graphics, AHPCRC, Minnesota Supercomputer Ctr.
--            also known as ken@msc.edu and 612-626-8075
From: matomira@disuns2.epfl.ch (Fernando Mato Mira)
Newsgroups: comp.sys.sgi
Subject: Cannot logout from IRIX 4.0
Date: 12 Aug 92 13:51:01 GMT
Reply-To: matomira@disuns2.epfl.ch (Fernando Mato Mira)
Organization: Ecole Polytechnique Federale de Lausanne

When trying to logout from a machine running IRIX 4.0, I keep on getting the
"Do you really want to logout?" popup. Clicking on "yes" simply doesn't work.
I tried removing my old .ps files without luck. Any ideas?

Thanks.
-- 
Fernando D. Mato Mira
Computer Graphics Lab
Swiss Federal Institute of Technology
matomira@ligsg1.epfl.ch
Newsgroups: comp.sys.sgi
From: bernardl@cs.Stanford.EDU (Bernard Lee)
Subject: dumb fortran fflust question
Keywords: dumb fortran fflush question
Organization: CS dept, Stanford University, CA 94305, USA
Date: Sat, 15 Aug 92 22:50:00 GMT

Because of the way logical unit i/o is implemented on SGI FORTRAN, 
we have to do a flush on a file descriptor.  Does any one know
how to do that without writing assembly code?  Or does anyone
happen to have any assembly code routine which allows us to 
do that?

Thanks,
 BERNARD LEE
 Stanford CS Dept
 (bernardl@cs.stanford.edu)
From: dpr@ohm.york.ac.uk (David Rossiter)
Newsgroups: comp.sys.sgi
Subject: Re: Audio on the Personal Iris
Keywords: audio, PI, MULAW, conversion
Date: 20 Aug 92 19:39:03 GMT
Organization: Electronics Department, University of York, UK

In <1992Aug20.123614@disuns2.epfl.ch> matomira@disuns2.epfl.ch (Fernando Mato Mira) writes:

>I have a couple of questions concerning the audio capabilities of the PI.

> I have some MULAW samples
>which I convert into
>16-bit linear, and then covert to 8-bit linear just by dividing by 256
>(no fancy filtering, sorry). All I get is noise. I hoped to get
>something horribly sounding but not so much. If the filtering is the
>problem, do you think I will manage to do the conversion in real-time?
>Any pointers to libraries?

It's probably worth looking at a program called 'sox' which actually
has nothing to do with smelly feet... it's a sound transformation
program (command line driven) which lets you re-sample, convert
between many different formats, bandpass/lowpass filter, add
effects such as echo + vibrato, etc. The source code is available
is you want to add to it... available via anon ftp from
ftp.cwi.nl   in   /pub 

Might be useful

Dave
From: beach@astro.umd.edu (Eric Beach)
Newsgroups: comp.sys.sgi
Subject: cdrom
Keywords: cdrom,sgi,os3.3.1,os3.3.2
Date: 21 Aug 92 13:08:17 GMT
Reply-To: beach@astro.umd.edu (Eric Beach)
Organization: Department of Astronomy, University of Maryland, College Park


   Has anybody attempted to connect a cdrom to an IRIS which uses 3.3.1 or
3.3.2 as its operating system? I know this can be done very easily with 4.0 .

  -Rico
From: joseph.maddry@matrix.sbs.com (Joseph Maddry)
Newsgroups: comp.sys.sgi
Subject: list
Date: 13 Aug 92 22:37:38 GMT


Date:        Tue, Aug. 11, 1992
From:        Joseph Maddry  <joseph.maddry@matrix.sbs.com>
Newsgroups:  comp.sys.sgi










                                 BASTARDLY MAILING LIST !!!!!!




Joseph Maddry
joseph.maddry@matrix.sbs.com
---
 . SLMR 2.1a . If at first you don't succeed, use BIG LETTERS!
                          
Newsgroups: comp.sys.sgi
From: rck@fangio.asd.sgi.com (Robert Keller)
Subject: Re: Help: new OS  -> the colormap gets confused
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: Fri, 21 Aug 1992 18:54:51 GMT


From the bottom of the mapcolor(3G) man page:

    In IRIX 4.0, mapcolor is implemented as an emulation layer on top of the
    request XStoreColors.  In order to avoid a serious degradation in perfor-
    mance, mapcolor requests are buffered and only sent to the window server
    when an input routine (e.g. qtest) or gflush is called.

    In situations where the immediate results of mapcolor are more important
    than speed, there is a glcompat call to disable this behavior.


...robert
From: andyr@rdr.chem.niu.edu (Andy Rollins)
Newsgroups: comp.sys.sgi
Subject: FAQ:Aging passwords and Pandora
Date: 13 Aug 92 22:02:30 GMT


So, obviously it's possible to age passwords and use pandora, problem is that
when I set the aging info in /etc/passwd, logged out and tried to log back in,
pandora would try to login with the old password, take it as a mistake, and
return me to the pandora login.  I see by the post from Jeff Hanson earlier 
today that it was possible.  What can I do to make it happen?  Thanks for the
answer to this question, even though I'm sure it's at least the millionth time
it's been asked.

Andy


andyr@rdr.chem.niu.edu or  |  Life is too important to be 
T40ANR1@NIU.BITNET or      |  taken seriously.
t40anr1@mp.cs.niu.edu      |  -Oscar Wilde
Newsgroups: comp.sys.sgi
From: chang@dizzy.alc.com (Sehyo Chang)
Subject: OpenGL status
Organization: Ascent Logic Corporation, San Jose, CA
Distribution: usa
Date: Thu, 13 Aug 1992 18:47:10 GMT

I have following questions regarding OpenGL:

(1) What platform does OpenGL is available and from whom.

    Eg.: SparcStations, Macintosh, Decstation 3100.,  etc?

    Prices?

(2) Where can get some information regarding feature set
    of OpenGL?. 



thanks
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Newsgroups: comp.sys.sgi
Subject: Re: Making QT movies from single-frame Insight images
Keywords: Quicktime Insight movies snapshot
Date: 19 Aug 92 17:38:33 GMT
Organization: Silicon Graphics Inc.

Just one small clarification to the recent message
I posted regarding the Media Mosaic movie tools:

In article <op902hc@zola.esd.sgi.com>, portuesi@tweezers.esd.sgi.com
(Michael Portuesi) writes:
|> Movieplayer plays back compressed digital movies, just
|> like Apple's Quicktime movie format.

These movies, however are *not* in Quicktime format.  They
are an SGI-specific format which will not be recognized by
Quicktime applications on the Macintosh.

SGI has licensed the Quicktime movie file format from
Apple Computer.  It seems pretty likely that we will be
supporting Quicktime movies alongside our current file format
in future releases, but I cannot make commitments about
features and specifications of our future products.  I only
write software....

m.

-- 
Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
Newsgroups: comp.sys.sgi
From: spencer@hailwood.asd.sgi.com (Paul Spencer)
Subject: Re: Videos from the screen?
Organization: Silicon Graphics, Inc., Mountain View, CA
Distribution: na
Date: Tue, 18 Aug 1992 02:24:29 GMT

dave@imax.imax.com (Dave Martindale) says:
> 
> I tried "setmon ntsc" on my XS24 and looked at the video output on an
> oscilloscope.  It sure looked like properly-timed NTSC

Well, no. There's no colorburst, to begin with. You're right, that the
basic R, G, and B signals are timed like NTSC; so all you have to do is
combine the three with an RGB->NTSC encoder, and you've got real NTSC.

You probably could connect one channel up to an NTSC VCR, and record the
signal; the VCR would treat it as a black-and-white signal, and the
playback on your TV would also be in black and white.

> So it *looks* like you could connect this directly to a video recorder
> with RGB inputs, such as the Sony LVR-5000 or LVR-3000 write-once videodisc.
> Has anyone actually tried this?

Yes, and yes. Works fine. These are not NTSC-input VCRs, though :-)

> A smaller issue: Does anyone know of a source of reasonably-priced
> video cables to do this?  They'd need a 13W3 connector on one end
> and BNC RGB connectors on the other end.

SGI sells such a cable, I believe; at least we have a bunch around here.

....paul

-- 
Paul Spencer                 Silicon Graphics Advanced Graphics Division
spencer@sgi.com                                Mountain View, California
From: joseph.maddry@matrix.sbs.com (Joseph Maddry)
Newsgroups: comp.sys.sgi
Subject: list
Date: 13 Aug 92 22:37:46 GMT


Date:        Tue, Aug. 11, 1992
From:        Joseph Maddry  <joseph.maddry@matrix.sbs.com>
Newsgroups:  comp.sys.sgi








          AT



Joseph Maddry
joseph.maddry@matrix.sbs.com
---
 . SLMR 2.1a . If at first you don't succeed, use BIG LETTERS!
                                                                               
Newsgroups: comp.sys.sgi