HDTenEightyP/NetNews huggingface dataset:
From: smets@dmi.ens.fr (Jean-Paul Smets)
Newsgroups: comp.sys.sgi
Subject: digital audio sampling with the internal DAT or CD-ROM
Keywords: audio-DAT-CDROM
Date: 15 Oct 92 12:56:38 GMT
Organization: Ecole Normale Superieure, PARIS, France

How can I sample portions of audio DAT or audio CD using the internal DAT or CD-ROM on an SGI Indigo.
Preferably, I'd like to get an AIFF file.


JPS.
From: lsr-vax!brad@uunet.uu.net (Brad Zoltick - LMO)
Newsgroups: comp.sys.sgi
Subject: more questions about /dev/plp
Date: 13 Oct 92 17:37:29 GMT


/dev/plp with BSD spooling and transcript:

Can one post a proper /etc/printcap entry for using
transcript with a parallel printer and BSD spooling.  Can you
use transcript with a parallel printer? I can find no documentation
in creating a proper printcap entry in the lastest release
of transcript.

Thank you.

Brad Zoltick
Laboratory of Sensorimotor Research
National Institutes of Health

E-mail: brad@lsr.nei.nih.gov
	uunet!lsr-vax!brad
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: scsi split on single tower?
Date: 9 Oct 92 05:13:30 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1b2uqkINNd5i@darkstar.UCSC.EDU> mmcohen@cats.ucsc.edu (Michael M Cohen) writes:
| Now that we have the IO3 on our single tower 510vgx,
| can the 4 peripheral bays be split between the 2 scsi
| controllers?

Yes, it *can* be done.  Whether we support it in terms
of providing the right cabling solutions, I doubt.  I'm
a bit out of touch with just what the cabling looks like
on the Crimson though, so I could be wrong.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: trouble with dd and exabytes
Date: 14 Oct 92 05:33:18 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <3038@contex.contex.com> frank@marvin.contex.com (Frank Perdicaro) writes:

| In article <1992Oct9.194651.4782@dxcern.cern.ch> burow@dxcern.cern.ch (Burkhard Burow) writes:
| >
| >We're having trouble using dd to read/write to some exabyte drives. 
| >
| Although this is a long shot, this may be another symptom of the bug
| that we found in pio.c causing non-page-aligned io to cause R4000 and
| some R3000 systems with VME to halt.  Try doing the io in a different
| order.  It can matter.
| 
| Before any of the SGI folk flame me, I urge them to look up the issue,
| and cringe...

I doubt it.  The i/o sizes mentioned are too large, and that was
a *very* special case.  It couldn't ever affect an r3k system, so
apparently you are somewhat confused (it has to do with a bug/feature
on r4k systems cache behavior).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: roger@rod.swmed.utexas.edu (Roger S. Noss)
Newsgroups: comp.sys.sgi
Subject: swapbuffers() and finish()
Date: 9 Oct 92 19:06:29 GMT


  I want to reliably swap buffers and record the time of the swap.
  The only command to do this that I have found is finish().  My
  window is small (512 x 512 or so) and the pattern is simple.
  Occasionally finish() blocks for an extra frame - maybe 10% of
  the swaps.  Short of putting a photocell to the monitor and 
  omitting finish(), how can I improve the timing?  Is this a unix
  problem?  The problem is especially vexing for vision expts in
  which smooth motion is desired - if a refresh is missed, the
  line is redisplayed in its old position, then jumps twice the
  distance to catch up in the next frame.
  
  Any ideas?
  
  - Roger
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: How to synchronize time on two SGI computers ?
Date: 7 Oct 92 04:29:58 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Oct6.094122.20258@news.uni-stuttgart.de> wnkretz@ikesg1.energietechnik.uni-stuttgart.de (Oliver Kretzschmar) writes:
|    we want to synchronize the time of our two SGI computers,
|    running IRIX 4.04. Exists there any comfortable possibilities to
|    do this ? Please mail me your informations !

timed.  It is shipped on by default if I remember right.
See 'man timed' for details.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: ted@cs.utexas.edu (Ted Woodward)
Newsgroups: comp.sys.sgi
Subject: Re: How to find which system (4D/30, Indigo,etc) am I logged onto ?
Date: 7 Oct 1992 21:59:30 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: bovina.cs.utexas.edu

In article <qqb4m7g@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>Just to be complete, IP12 is 4D/30, 35, and Indigo, and IP20
>is the r4k Indigo.  IP5 was the first MP machines, the 1X0 
>series, and IP4 are the 4D/70 and 4D/8[05] machines.  There
>are a few others, but they mostly aren't interesting.

Just to be a bit more complete, the V35 (VME based 4D/35) claims to be an
IP12, even though it isn't.  But close enough, and certainly not worth enough
effort to change the PROM (and I expect that OSG doesn't have the volume
of sales to influence this much for the software hinv, but this can be good.
We are considering buying some more V35s where I work, and Dominick Arsi of
OSG came out and did a dual head demo.  Dog kinda freaks when you move the
mouse to the 2nd head to diddle with shadow.  MAJOR roll!)

(If I remember correctly, the V35 is really an IP17)


-- 
Ted Woodward (ted@cs.utexas.edu)

"Mad scientists HATE shopping for shoes!" -- Peaches
From: divin@sgi.com (Dave Immel)
Newsgroups: comp.sys.sgi
Subject: Re: IRIS Inventor: PHONG shading???
Date: 8 Oct 1992 23:00:04 GMT
Organization: Silicon Graphics
NNTP-Posting-Host: zeus.asd.sgi.com

In article <1992Oct8.200203.317@engage.pko.dec.com> gregg@eggoop.zko.dec.com (Edward P. Gregg) writes:
>
>
>As a previous reply stated, this refers to the lighting model, as opposed
>to the shading model used at rasterization time. I too find their use of
>PHONG in this context to be confusing though.
>
>What surprises me is their us of the lighting model field -
>an enumerated type that can be set to
>
>BASE_COLOR: no lighting, uses diffuse color
>PHONG: applies GL lighting
>DEPTH: no lighting, apply depth queing.
>
>From this, it appears that one can not apply both lighting and depth queing
>to the same scene. Is this so? Why is this? There is no such restriction
>in GL, and I can see no reason to impose this restriction.
>

The light model is not a per scene characteristic.  It is a per object
characteristic.  So the two lighting models may be freely intermingled
in the same scene.


>Also, PHIGS+ (and PEX?) have controls to toggle ambient, diffuse, and
>specular calculations of the lighting equation. If my memory serves me,
>GL, OpenGL, and Inventor do not. Is this functionality useful or 
>superfluous?
>

There is nothing which prevents portions of the material to be turned
off during lighting in either GL, OpenGL, or Inventor.  One simply has
to set those values to 0.0.  Are you talking about some sort of bit
field which might be passed in?  That seems superflous to me.


>-------------
>Ed Gregg
>Digital Equipment Corporation
>
>


Have you read the Technical Report on Inventor?  It might clear up some
of your misconceptions.  You can get one by contacting the Marketing Manager
for Inventor, Scott Bovenizer (bove@sgi.com).


Dave
Newsgroups: comp.sys.sgi
From: chehhm@gsusgi1.gsu.edu (Hui Mao)
Subject: HELP: install DAT tape drive on IRIS 4D/20
Summary: Installed 4mm DAT tape drive on 4D/20 is type unknown and can not work
Keywords: DAT Tape Drive
Organization: Georgia State University
Date: Thu, 15 Oct 1992 16:24:01 GMT

    We just got a 4mm 1.3 GB DAT tape drive for our IRIS 4D/20 workstation.  
After it was installed, I checked the *hinv* listing.  The message describing
the drive I just installed showed like:

     Tape drive : unit 4 on SCSI controller 0: type not known

I tried *MAKEDEV* to turn on those device software as shown on installation 
guide, but the *hinv* message I got was same as above.   I tried to do some
backup using this tape drive, even I know it's not installed correctly.  The 
tape was moving, but it didn't write angthing.

Dose anyone have any experience and suggestion about this?  We really appreciate
your help.

Thanks.  

BTW, we are running IRIX 3.3.3 on this 4D/20 workstation.
                                    

.........................................................................
   Hui Mao                           chehhm@gsusgi1.gsu.edu
   Department of Chemistry           mao@dixonsgi.gsu.edu
   Georgia State University
.......................................................................
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Too many tapes!
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 8 Oct 92 22:30:00 GMT

In <32958@adm.brl.mil> bob@caw2.4950tw.wpafb.af.mil (Bob Plested) writes:

| Howdy netlanders,
|    Yesterday I upgraded this 4D/320VGX from Irix 4.0.4 to 4.0.5A. Today
| I got my SGI CD-ROM drive in the mail, so that went in the machine too.
| Now, I try a hinv and get the following:
| 
| caw2:/usr/people/bob/ hinv
| 2 33 MHZ IP7 Processors
| FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 2.0
| CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0
| On-board serial ports: 2 per CPU board
| Data cache size: 64 Kbytes
| Instruction cache size: 64 Kbytes
| Secondary data cache size: 256 Kbytes
| Main memory size: 64 Mbytes
| I/O board, slot F: IO2 revision 2
| Integral Ethernet: et0, IO2
| VGX Graphics option installed
| Tape drive: unit 7 on SCSI controller 0: 8mm cartridge
| Tape drive: unit 6 on SCSI controller 0: 8mm cartridge
| Tape drive: unit 5 on SCSI controller 0: 8mm cartridge
| Tape drive: unit 4 on SCSI controller 0: 8mm cartridge
| Tape drive: unit 3 on SCSI controller 0: 8mm cartridge
| Disk drive: unit 2 on SCSI controller 0
| Disk drive: unit 1 on SCSI controller 0
| Integral SCSI controller 0: Version WD33C93A, revision 9

Your tape drive is set to SCSI ID 0, almost certainly.  Fix that,
and  your problems should go away.  Since you ran MAKEDEV when
the system was set up wrong, you should probably rerun it after
you fix this.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: Setuid shells scripts and perl
Originator: tchrist@pixel.convex.com
Date: Sat, 17 Oct 1992 04:22:18 GMT
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: Convex Computer Corporation, Colorado Springs, CO
Keywords: setuid perl
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

From the keyboard of vjs@rhyolite.wpd.sgi.com (Vernon Schryver):
:How would you have "more freedom" by ignoring the setuid bit?
:Wouldn't your scripts fail to do whatever they are intended to do?

Not if they were intended to get the perl setuid emulation feature.

Really a pity that vendors choose the easy way to fix setuid scripts,
(read: disable them, not fix them!) and then don't even allow any degree
of compatibility for those of us who understood the problem long ago and
worked to fix it.

--tom
-- 
    Tom Christiansen      tchrist@convex.com      convex!tchrist


I love California, I practically grew up in Phoenix  --Dan Quayle
Newsgroups: comp.sys.sgi
From: taylorf@sweetpea.jsc.nasa.gov (Frank S. Taylor IV 283-4278)
Subject: Re: comp.sys.sgi archives (was: Re: PLEASE read this newsgroup first)
Organization: McDonnell Douglas Space Systems Company
Date: Thu, 15 Oct 1992 20:51:45 GMT

In article <1992Oct15.173113.5023@cs.wayne.edu>, atems@igor.physics.wayne.edu (Dale Atems) writes:
|> Hi everyone
|> 
|> Dave Olson complained recently that some people ask questions here
|> without browsing earlier replies here first. A consensus seems to have
|> been reached that a FAQ list is in order for this newsgroup, and I
|> agree that this is a needed thing. Many questions answered here,
|> though, are not FAQs, and Dave suggested that people consult the
|> comp.sys.sgi archives at sgi.com.
|> 
|> As a relative novice, I may be missing something here, but is there
|> any easy way to browse these archives? Suppose I'm looking for a post
|> of Dave's on the R4K Indigo that I neglected to save, and all I know
|> about when it was posted is that it was sometime during the last
|> week. What the easiest way of going about finding it in the archives?
|> 
-- 
It would be nice if someone would set up a WAIS server for the comp.sys.sgi
archives.  This would be a quick and easy way to look through the
archives.

----------------------------------------------------------------------------
Frank S. Taylor IV  -  McDonnell Douglas Space Systems Company
16055 Space Center Blvd., Houston, Tx  77062
(713) 283-4278 (Voice)  ||  (713) 283-4020 (Fax)
taylorf@sweetpea.jsc.nasa.gov
----------------------------------------------------------------------------
From: jordan@IMSI.COM (Jordan Hayes)
Newsgroups: comp.sys.sgi
Subject: Re: Bug in SGI's malloc?
Date: 12 Oct 92 12:45:37 GMT
Organization: Investment Management Services Inc., NYC

Jeremy Higdon <jeremy@classic.asd.sgi.com> writes:

	My understanding is that there are some folks out there who
	have huge processes that want to do a quick fork and exec.

Isn't the traditional solution to this situation vfork()?

/jordan
Newsgroups: comp.sys.sgi
From: mguttman@scholia.wbme.jhu.edu (Mike Guttman)
Subject: pixmode bug on 4D30TG
Reply-To: mguttman@tempest.wbme.jhu.edu
Organization: Johns Hopkins University, Dept. of Biomedical Engineering
Distribution: na
Date: Tue, 13 Oct 1992 15:03:48 GMT


Greetings,

I can't seem to get
	pixmode(PM_TTOB, 1);
to work on our 4D30/TG.

The task is to make the pixmode call, then use lrectwrite.

It works fine on our 4D380/VGX.

When I run the program on the 4D30/TG, it acts as if I never
made the pixmode call.

When I run the program on the 4D380/VGX with the display set
to the 4D30/TG, the result looks butchered (cut in half horizontally).

I have been able to deduce anything from the relnotes or other postings,
so I was wondering if any of you have info on this.

Thanks for your help.  
Please e-mail to me if possible since I don't read the group regularly.

Mike Guttman
From: erikl@shogun.asd.sgi.com (Erik Lindholm)
Newsgroups: comp.sys.sgi
Subject: Re: anti-aliasing, perfly, reality-engine: question
Date: 16 Oct 92 20:14:55 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
NNTP-Posting-Host: shogun.asd.sgi.com

Brian sez:

>>- Our Inventor SceneViewer application features an anti-aliasing menu
>>  option.  When chosen, redraw time goes to several seconds and the CPU
>>  sighs heavily, suggestion software anti-aliasing.
>As on the VGX, you need 2 RMs to get the hardware accumulation buffer
>at 1280x1024.  The Inventor app is using accumbuf AA and falls back to
>the software accumbuf if the hardware one is not present.

This is not quite correct. The RE has two accumulation buffers: 12 bits 
unsigned (acsize(12)) and 24 bits signed (acsize(24)). If you are doing
a doublebuffer+zbuffer application on a 1RM system at 1280*1024, the
12 bit accumulation buffer will be in hardware while the 24 bit one will
be in software.

-- 


Of course I'm lying,  .....but I think I love you.       (Yello)
Newsgroups: comp.sys.sgi
From: shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin)
Subject: Re: Problem compiling Fortran program
Organization: Dept. of Chem, Barnard College, Columbia U, New York
Date: Thu, 8 Oct 1992 21:51:27 GMT
X-Posted-From: avogadro.barnard.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <1992Oct8.195435.28176@sol.ctr.columbia.edu> shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
>Can anyone illuminate the following error message?
>
>		f77 -g -C -static  -c bmin1v.f 
>	ugen: internal: binasm stms write error
>	*** Error code 1
>
>It results only from this single file, and only with -C (bounds-checking).

I eventually realized that this was because there wasn't enough room in
/tmp for the intermediate files;  solved by "setenv TMPDIR /usr/tmp".

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Columbia Univ.,  New York, NY 10027
(212)854-8402    shenkin@avogadro.barnard.columbia.edu   shenkin@cunixf.BITNET
*********************** UNIX:  the wave of the present ***********************
From: pj@sam.wpd.sgi.com (Paul Jackson)
Newsgroups: comp.sys.sgi
Subject: Re: to preallocate, or not to preallocate (that is the question AGAIN?)
Date: 15 Oct 92 10:42:15 GMT
Reply-To: pj@sgi.com
Organization: Silicon Graphics, Research & Development

In article <3048@contex.contex.com>, james@sam.contex.com (James McQueston) writes:
|> If so, maybe there is some other OS call we could make in a
|> home-brew version of malloc() that could ensure or force the backing store/
|> physical memory to be allocated, or even just compare the brk region
|> to the sum of: (main memory) + (swap) - (all other memory in use)
|> allocated and then cause home-brew malloc() to return 0?

Let me acknowledge, but not address here, your central and serious
concerns in providing software to run on systems when you cannot
control critical events.

Depending on your memory needs, there is something that I've done
in an experimental version of the "diff" command that I was
developing that _might_ happen to improve your situation, with
some additional work.  I needed to constrain diff to fit easily
in main memory, which could mean anything from perhaps 2 MBytes
on an small 8 MByte system to 50 or 100 MBytes on the largest
system I had for testing.  I couldn't simply malloc until failure
for the reasons that you have noticed.

So I determine main memory size at startup, and intentionally stay
within some constant fraction of that size (25%, it happens).  At
least in my case, the amount of memory thus allocated met my
performance objectives across the full range of platforms.  I
realize that this won't be true for some packages.

This doesn't guarantee that my process wont get killed, but it
drastically reduces the chances, while still making use of memory
when available.

In my case, I could directly constrain my memory to the chosen
amount.  If you'd like to have that constraint applied under the
covers by malloc and friends, then perhaps you could limit
your data segment to the desired size using the RLIMIT_DATA option
to getrlimit(2)/setrlimit(2).  This will control how much memory
sbrk(2) is willing to grant your process.

Olson can perhaps tell you if there is a way to size swap, if you
choose to consider that in your tuning.

You're welcome to use the following routine to size main memory,
if that helps.  Some minor details of the following code
involving getinvent() are subject to changes in future releases.

#include <invent.h>
/* Return size of main memory in bytes */
memsize(){
  inventory_t *getinvent(void);
  inventory_t *sp;
  static int sz = 0;

  if (sz == 0)
    {
      while ((sp = getinvent()) != 0)
        {
          if (sp->class == INV_MEMORY && sp->type == INV_MAIN)
            {
              sz = sp->state;
              break;
            }
        }
    }

  if (sz == 0)
    sz = 8*1024*1024;   /* 8 MByte default main memory size */

  return sz;
}

Hope that helps.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: disabling page cache on memmory mapped files
Date: 11 Oct 92 05:20:40 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <5265@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:
| I'm trying to port an application from SunOS to IRIX, and I'm looking
| for information on the transition ... specifically:
| 
| 1) In SunOS, you can set the sticky bit on a file, and it will disable
|    the use of the page cache for that file.  We've found this to be
|    *extremely* helpful in our application.  From the man page:
| 
| 	If the sticky bit is set on a regular file  and  no  execute
| 	bits  are  set,  the system's page cache will not be used to
| 	hold the file's data.
| 
|    Does IRIX have something similar?

No.  Tell me, why would you find this to be useful?  Do you like slow
i/o?

There *is* the ability to open with O_SYNC, so all writes happen
synchronously (the system call doesn't return until the data is on
disk), or you can use fsync() on a regularly opened file to sync it out
at a given point (doesn't have the performance problems that some older
SunOS versions had).  However, this is a very different thing.

| 2) In SunOS, newfs and tunefs were extended to allow multiple blocks to
|    be allocated before inserting rotational delay.  The -C flag to
|    newfs and the -a flag to tunefs are used to bump up the maximum
|    number of blocks to contiguously allocate.  For us (and for many
|    folks with modern fast disk drives), setting this value to 7 (for
|    56k read/write clusters rather than the default 8k) has doubled our
|    throughput.
| 
|    Does IRIX have something similar?

IRIX by default clusters i/o.  For writes, the clustering is in
64KB chunks, and for reads, it defaults to the largest power of
2 <= 64KB, or can be forced to a given value with the mount option
'lbsize'.  SGI's disk i/o, particularly for SCSI disks normally
is rated as quite good compared to equivalent systems (i.e., is
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi
From: schuman@eacces.wpd.sgi.com (Aaron Schuman)
Newsgroups: comp.sys.sgi
Subject: Re: Reading the prpsinfo structure...?
Date: 15 Oct 92 16:12:28 GMT
Organization: Silicon Graphics 415-390-1901
NNTP-Posting-Host: eacces.wpd.sgi.com

Rindress>  I can't seem to find "top" for the SGI on the net. :-(
Rindress>  Does anybody have a copy of "top" that has been ported
Rindress>  to the SGI?

Don't look on the net; /usr/sbin/top is on your install medium.
It is associated with the eoe2.sw.perf subsystem.  Make sure
you selected that subsys for installation, and you should find
the executable.


					Aaron

.............................................................................
Aaron Schuman     415-390-1901     schuman@sgi.com     Silicon Graphics, Inc.
From: ufe@dlva.dl.ac.uk
Newsgroups: comp.sys.sgi
Subject: Re: 3rd party CD drives
Date: 9 Oct 92 11:43:52 GMT
Reply-To: ufe@dlva.dl.ac.uk ()
Organization: SERC Daresbury Lab., Warrington, U.K.

We've installed software on an Indigo using a  DEC drive. (RRD40)
Cheers,
	Mark
========================================================================
Mark Enderby			   JANET - ENDERBY@UK.AC.DARESBURY
Systems Manager		  	   EARN/Bitnet - ENDERBY@DARESBURY.AC.UK
SERC Daresbury Laboratory
Keckwick Lane						
Daresbury
Warrington	tel:   0925-603353
WA4 4AD		Int:+44-925-603353
UK		fax:   0925-603174
Newsgroups: comp.sys.sgi