HDTenEightyP/NetNews huggingface dataset:
From: trevc@sal.reading.sgi.com (Trevor Cotton)
Newsgroups: comp.sys.mips
Subject: Re: Looking for 1/4" tape drive, RC3330
Keywords: Archive Viper
Date: 13 Nov 92 15:56:50 GMT
Reply-To: trevc@cix.compulink.co.uk
Followup-To: comp.sys.mips
Organization: Trevor Cotton Associates, UK

In article <2017@tekadg.adg.tek.com>, tonyr@tekadg.adg.tek.com (Tony Rick) writes:
|> I have recently acquired an RC3330 that doesn't have a 1/4" cartridge
|> tape drive.  What kind of drive would it ordinarily be (make, model)?  Where
|> can I get one?
|> 
|> Tony Rick
|> Tektronix, Inc. Beaverton, OR
|> email: tonyr@tekadg.adg.tek.com
|> voice:(503) 627-2942

The MIPS supplied drive is an Archive Viper 2150S.
Don't forget that you will have to get a mounting bracket and power
cable as well, and these will only be available from SiliconGraphics
unless you want to try and make your own.

-- 
--trevc--
Newsgroups: comp.sys.mips,list.epixinfo
From: peter@merlin.acadiau.ca (Peter Steele)
Subject: Where is wait3?
Organization: Acadia University
Date: Mon, 9 Nov 1992 14:18:02 GMT

I am compiling a package (CAP) that uses a routine called
wait3. During the link phase it complains that wait3 is
undefined. Man wait3 does describe such a routine, but
I can't find it in any of the libraries. There is a wait
routine, as well as a wait2, but no wait3. I presume that
since it is described in the man pages this routine does
exist somewhere. Can any one tell me where it is?

Thanks.
--
Peter Steele        Unix Services Manager            peter.steele@acadiau.ca 
Acadia Univ., Wolfville, NS, Canada B0P 1X0  902-542-2201  Fax: 902-542-4364
From: tonyr@tekadg.adg.tek.com (Tony Rick)
Newsgroups: comp.sys.mips
Subject: Looking for 1/4" tape drive, RC3330
Keywords: Archive Viper
Date: 13 Nov 92 15:23:12 GMT
Article-I.D.: tekadg.2017
Distribution: na
Organization: Tektronix Inc., Beaverton, Or.

I have recently acquired an RC3330 that doesn't have a 1/4" cartridge
tape drive.  What kind of drive would it ordinarily be (make, model)?  Where
can I get one?

Tony Rick
Tektronix, Inc. Beaverton, OR
email: tonyr@tekadg.adg.tek.com
voice:(503) 627-2942
From: dbw@svl.cdc.com (Dave Woerner)
Newsgroups: comp.sys.mips
Subject: Re: Where is wait3?
Summary: Location of wait3
Keywords: wait3
Date: 10 Nov 92 18:40:23 GMT

In article<peter.721318682@merlin>peter@merlin.acadiau.ca(Peter Steele)writes:
>I am compiling a package (CAP) that uses a routine called
>wait3. During the link phase it complains that wait3 is
>undefined. Man wait3 does describe such a routine, but
>I can't find it in any of the libraries. There is a wait
>routine, as well as a wait2, but no wait3. I presume that
>since it is described in the man pages this routine does
>exist somewhere. Can any one tell me where it is?

wait3 is in the BSD side of things.  There are several ways
to get at it.  If you got through the compilation ok, you probably
just need to add -lbsd to your link.

Just FYI, there is also a -systype flag that takes "sysv" or "bsd43"
to get either the system V or BSD includes and libraries.

Dave
From: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
Newsgroups: comp.sys.unisys
Subject: Host Lan Controllers
Date: 10 Nov 1992 10:13:42 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
NNTP-Posting-Host: hela.ins.cwru.edu



Several weeks ago I posted a request for information on improving
FTP file transfers between a 2200+DCP40 system and UNIX machines.
I'm still in the process of putting in fixes and making changes to
get our site on the latest releases.

I'm now interested in people's experience of the UNiSYS
Host Lan Controller, data transfer rates would be nice.
Our current setup can reach the heights of 4.2k bytes/sec,
can we expect to better that with a HLC.

Stephen Fitch
The Open University
Milton Keynes, England, MK7 6AA.
Newsgroups: comp.sys.unisys
From: MPA15AB!RANDY@TRENGA.tredydev.unisys.com
Subject: testing from mpa15ab -- sorry for the annoyance
Organization: C-S-U Gateway
Date: Mon, 9 Nov 1992 23:44:00 GMT


Newsgroups: comp.sys.unisys
From: eginsber@oracle.com (Eric Ginsberg)
Newsgroups: comp.sys.unisys
Subject: Re: CTOS <-> DOS disk conversion (yes, you can)
Date: 10 Nov 92 19:22:30 GMT
Organization: Oracle Corp
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

A friend of mine from my Unisys days who has been a CTOSian  from 
day 1 has this to say:

Received: 11-10-92 10:52                                 Sent: 11-10-92 10:11
From:     B._Weast@network.convergent.com
To:       eginsber@us.oracle.com 



For accessing DOS floppies on Ngen hardware, the CTOS Executive commands
MSDOS READ and MSDOS WRITE are available on CTOS Standard Software version
12.0.0 and higher.

All 9.x, 10.x, and 11.x versions supported MSDOS READ and MSDOS WRITE with
the separate package known as PC Emulator, if installed.  Though PC Emulator
needed a hardware slice on non-386 systems to run DOS, the MSDOS READ and
MSDOS WRITE Executive commands do not need the slice to access DOS diskettes,
as those utilities run on the native CTOS processor, 186, 286, or 386.

Floppy capacity is limited by Ngen hardware present.  All "classic" Ngens can
read/write all single/double sided double density DOS diskettes (360K &
640K).
Only SCSI-based Xbus modules and 286i/386i processors can read/write high
capacity (1.2M) floppies.  SuperGens and the new combination dual-floppy Xbus
module can also use the 3 " floppy in either density.

Floppy formatting is automatically determined by the utility with a
read/retry algorithm that attempts single sided, then double sided, then high
capacity (on capable machines) mounting operations.  

The commands (for any version) are executed by one runfile,
[Sys]<sys>MsReader.run with accompanying MsReaderMsg.bin message file, now
bundled with Standard Software 12.0.0 and higher.  Command case is 00 for
Read and 01 for Write.

Only one caveat: The file must be coming from, or going to, the ROOT
directory of the floppy ... no \MUMBLE\FOO\BS though it's possible (and don't
quote me on this) that the latest version, under Vpc, will support
subdirectories, maybe.

And, of course, when writing, the CTOS file should conform to the DOS
limitations of filenaming before the write is attempted.

Contact your Unisys Sales Representative or Value Added Reseller for pricing
information or orders.



			  << E N D   O F   M E S S A G E >>
Xref: sparky comp.sys.unisys:634 alt.folklore.computers:16215 comp.sys.misc:960
From: Pat_Barron@transarc.com
Newsgroups: comp.sys.unisys,alt.folklore.computers,comp.sys.misc
Subject: Burroughs B20
Date: 13 Nov 92 17:05:10 GMT
Article-I.D.: transarc.cf16naP0Bwx25HbsAe
Organization: Carnegie Mellon, Pittsburgh, PA

So, I seem to have aquired a Burroughs B20.  Looks like it was meant
to be used as a word processing system.  It's running an operating
system called BTOS.

What else is there to know about this system?  Can it run any sort of
"real" operating system?  Anyone have any software for it that they no
longer want...?

Thanks!
--Pat.
From: dold@mitisft.Convergent.COM (Clarence Dold)
Newsgroups: comp.sys.unisys
Subject: Re: CTOS <-> DOS disk conversion (no help yet)
Date: 8 Nov 92 18:35:37 GMT
Organization: Unisys Unix Systems Group, San Jose, CA

in article <1992Nov6.231858.1857@opusc.csd.scarolina.edu>, berry@opusc.csd.scarolina.edu (Berry Mobley) says:

> A couple of weeks back, someone posted an article with a reference to
> a utility that either read CTOS disks in a PC, or wrote DOS disks in
> a CTOS machine.  Either of these would be very useful to us.  

If such a program does not readily exist as PD, perhaps some CTOSian
programmer woiuld be interested in porting Emmet P. Gray's mtool package.
It was originally written for the 3B1, in .c.  It has been ported to other
platforms.  It contains all of the source for the DOS directory layout and
such.  The only port required would be the CTOS File System side, and the
raw read/write to diskette.

Trivial, right? ;-)

-- 
---
Clarence A Dold - dold@tsmiti.Convergent.COM
               ...pyramid!ctnews!tsmiti!dold
Newsgroups: comp.sys.unisys
From: TRANSFER@TRENGA.tredydev.unisys.com
Subject: test nsg -- please excusse the noise
Organization: C-S-U Gateway
Date: Mon, 9 Nov 1992 23:41:00 GMT


Newsgroups: comp.sys.unisys
From: berry@opusc.csd.scarolina.edu (Berry Mobley)
Subject: CTOS <-> DOS disk conversion
Organization: Univ. of South Carolina, Columbia
Date: Fri, 6 Nov 1992 23:18:58 GMT

A couple of weeks back, someone posted an article with a reference to
a utility that either read CTOS disks in a PC, or wrote DOS disks in
a CTOS machine.  Either of these would be very useful to us.  

If you have any info, please email.

Berry

berry@bigbird.csd.scarolina.edu

Newsgroups: comp.sys.unisys
From: edpep@opal (Egil Pedersen)
Subject: Unisys equipment for 2200 series for sale
Reply-To: edpep@opal (Egil Pedersen)
Organization: University of Bergen, Norway
Date: Thu, 12 Nov 92 13:00:48 GMT


University of Bergen have for sale:
1 * FACU
1 * 8494 disk (2.2 GB)
2 * 5057 disk cu
1 * 8480 disk
2 * 8470 disk
1 * Uniservo 30 tape contr.
2 * Uniservo 36 drive
1 * UTS 4020
4 * UTS 20 Workstations
a lot of UTS SS
1 * DCP/40 

All equipment is available now and will be sold very cheap. If you are  
interested send me an email.

Egil Pedersen
pedersen@edb.uib.no
From: rskinner@mipos2.intel.com (Rod Skinner)
Newsgroups: comp.sys.intel
Subject: Re: Performance of Intel 80x86 CPUs in UNIX environment (repost)
Date: 9 Nov 92 16:05:55 GMT
Organization: Intel Corporation, Santa Clara, CA USA

In article <TMH.92Nov7193313@bigfoot.first.gmd.de> tmh@bigfoot.first.gmd.de (Thomas Hoberg) writes:
>In article <1992Nov3.041557.20712@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>   SPEC benchmark is no longer a typical user program. My main load now is
>   the running of X-window applications. Anyone has figures for X11 running on
>   Intel Microprocessors?
>
>   I only try it on our 386/25(no cache)  and 486/33. The figure for
>    X11perf -bigtilerect500
>   is about 2 versus 4.4 per second. The speedup is only 120% which shows that
>   the internal cache effect becomes negligible.
>	   Even then x11perf is a repetition benchmark which can make available
>   cache look more impressive than it should be.
>Be very careful when using Xperf as a benchmark on an ISA based system.
>You might end up measureing ISA throughput and unsurprising there is
>little difference there. To get some useful numbers you should use the
>pixmap/pixmap values and no window/window or pixmap/window
>window/pixmap values (although they might be interesting in an other
>context). Actually I'd be very interested to see those values for
>otherwise identical systems using the various DX, DX2 processors from
>25 to 60MHz.

I would suspect that the QUALITY of the GRAPHICS board would have even 
a larger impact on performance than the ISA bus bandwidth.  Can you
describe the GRAPHIC subsystem in the two machines that you used to 
get your CPU ratios?  The CPU only can speed up that portion of the
execution time it controls.  When you configure a system with a
bottleneck that consumes large portions of the execution time the 
processor cannot scale that fixed time with CPU performance improvement.

The Intel definition of a 80486DX processor includes the performance
improvement of 2x of a DX-25 over a 80386DX-33.  This holds true
for Intel processors on all benchmarks when the computer system disk,
memory, and graphics systems are properly configured.  Slow down anyone
of those three to where they begin to limit user performance and there 
is no reason to buy faster CPUs.  

rod

>   --
>   Othman bin Ahmad, School of EEE,
>   Nanyang Technological University, Singapore 2263.
>   Internet Email: eoahmad@ntuix.ntu.ac.sg
>   Bitnet Email: eoahmad@ntuvax.bitnet
>---
>Thomas M. Hoberg   | Internet: tmh@first.gmd.de
>1000 Berlin 41     |           tmh@cs.tu-berlin.de
>Wielandstr. 4      |
>Germany            | BITNET:   tmh@tub.bitnet 
>+49-30-851-50-21   |


Rod Skinner				I speak for myself only.
Intel Corp
3065 Bowers Avenue   MS NW1-20            PH (408) 765-4474
Santa Clara, CA 95052                     FAX (408) 765-4920
Newsgroups: comp.sys.intel
Subject: Re: P24T
From: CUNY/Spartacus <I18BC@CUNYVM.BITNET>
Date: Tuesday, 10 Nov 1992 17:53:30 EST
 <92311.134450I18BC@CUNYVM.BITNET><1992Nov8.115914.16716@bilver.uucp>
Organization: City University of New York/ University Computer Center

In article <1992Nov8.115914.16716@bilver.uucp>, wbeebe@bilver.uucp (Bill Beebe)
says:
>The reason for the success of the 386SX is in the fact that it is cheaper
>to build 16-bit MBs as compared to the cost and complexity of building a
>full 32-bit MB. As an example, a 33MHz 386sx MB costs around $100, while
>a 25MHz i486sx MB costs around $200(US). Another point to consider; MB
>designs require a minimum memory compliment to match the data width. With
>16-bit designs, that's two SIMM sticks, which cost $60US. With 32-bit
>designs, that's four SIMMs, which cost $120US (both cases 1MB SIMMS at
>$30US each). With a 64-bit design, that would be eight SIMMs, which would
>be $240US for 8MB or nearly $1000US for 64MB (using 4MB SIMMs at around
>$125US each). So there are some real cost differences to consider between
>32- and 64-bit designs.
>
>--
>William H. Beebe, Jr. - wbeebe@bilver.UUCP

Okay, but anyone can sell their old 486 motherboard to make up
the difference in price, right?

Example:
(486MB w/p24t socket + p24t chip) =~ (True Pentium) - (Sale of 486 MB)

hmm, well at least a year from now I guess it (should/could/?) be
like that.  Especially when memory prices drop some more.
-------
------------------------------+      All The Best,
Reply To:                     |
     I18BC@CunyVM.Cuny.Edu    |      Edward Galarza,
     I18BC@CunyVM.BitNet      |      Brooklyn College Of The
     IRC: Spartacus           |      City University Of New York
------------------------------+      "Que viva el OS/2!"
From: mcnab@dinsdale.nas.nasa.gov (David McNab)
Newsgroups: comp.sys.intel
Subject: Pentium/Paragon
Date: 12 Nov 92 19:59:31 GMT
Organization: NAS Program (CSC), NASA/Ames Research Center

Nobody responded to my little joke that the plural of "pentium"
should be "paragon" (philistines!).  But there was actually a
shred of a serious question in there.  I remember reading on this
newsgroup that pentium was supposed to be a replacement for
the '486 and the '860, from which I infer that a future paragon
could be based on pentium.  Clearly Intel will not continue to
use the '860 as the paragon processor indefinitely; can anybody
comment on what they are considering for future machines?

David

----------------------------
David McNab
Parallel Systems Support
NAS Program (CSC), NASA/Ames
mcnab@nas.nasa.gov
Newsgroups: comp.sys.intel
Subject: Re: Undocumented instructions in x86 CPUs
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Fri, 6 Nov 1992 03:49:17 GMT
Organization: Computer Science Dept. University of Auckland

In <15341@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:

>However, it *doesn't* mention what happens in AAM if the second byte of
>the instruction *isn't* 0A.  The "One-Byte Opcode Map" on page A-4
>shows AAM in the D4 location, which seems to indicate that D4 is the AAM
>opcode, so maybe, in fact, the second byte is a secret operand that's
>the base of the number system for which it's doing the adjustment.

Correct.  Supposedly Intel ran out of space in the microcode for the operand
so they made it external.  You can use other operands if you want.

>Note, though, that they may have cut corners in future implementations,
>such as the 586^H^H^HPentium, so that hex A is the only operand that
>works correctly.

It works with everything up to a '386, but does *not* work on the NEC CPU's.

There is some other instruction which does this as well and which does work
on the NEC CPU's (I think), but I can't look up the exact details since all the
info is at home.

Peter.
--
    pgut1@cs.aukuni.ac.nz || peterg@kcbbs.gen.nz || peter@nacjack.gen.nz
			       (In order of preference)
From: jle9162@zeus.tamu.edu (ECKHARDT, JASON LEE)
Newsgroups: comp.sys.intel
Subject: Re: LOADALL and the 486
Date: 11 Nov 92 01:59:00 GMT
Article-I.D.: zeus.10NOV199219595243
Distribution: usa
Organization: Texas A&M University, Academic Computing Services
News-Software: VAX/VMS VNEWS 1.41

In article <1992Nov9.115520.5893@fct.unl.pt>, jpl@antares.fct.unl.pt (Joao Prospero Luis [ps]) writes...
>Marcus Jenkins (marcusj@apricot.co.uk) wrote:
>: I know this may be an FAQ, but I am just a little confused.  Is
>: LOADALL implemented in the 486?  PC Magazine said that it is
>: in all processors from 2-486.  It also said that Microsoft use
>: the instruction in HIMEM.SYS, SMARTDRV.SYS and RAMDRIVE.SYS in
>: MS-DOS.  On the other hand, an instructor from Intel (while lecturing
>: on an i386/486 programming and architecture course) alleged that
>: LOADALL is only there on 286 and earlier steps of the 386.  Does
>: anybody know the REAL answer?  Is there commercial software out
>: there that does use this reserved instruction.  This enquiry is
>: out of curiosity only - I have no intention of putting LOADALL
>: into any of my programs!
> 
>	As far as I know (it isnt that much) LOADALL isnt implemented in
>the 386, but is simulated by some BIOSes. When it traps an invalid opcode
>it goes to check if it is a LOADALL, if it is it is simulated otherwise
>it does something else (in fact I think it tests some other invalid opcode
>first but I dont remember which). This was confirmed with my AMI BIOS.
> 
>	JPL
> 
>--
>Joao Prospero Luis                 |
>Universidade Nova de Lisboa        | Internet: jpl@fct.unl.pt
>Faculdade de Ciencias e Tecnologia |
>Departamento de Informatica        | Fax:   (+351) (1) 295-5641
>2825 Monte Caparica, PORTUGAL      | Phone: (+351) (1) 295-4464

There are two different LOADALL's, the 286 LOADALL and 386 LOADALL.
Although they don't exist on the 486, the 286 LOADALL is emulated by every
386/486 BIOS.

For a great article on both LOADALL's, check out the October 1991 issue
of Tech Specialist. It's around 15 pages of info plus its got some 
interesting code that shows interesting features of the instruction.

jason.
From: rrn@po.cwru.edu
Newsgroups: comp.sys.intel
Subject: re: Intel internet addresses
Date: 13 Nov 1992 17:00:07 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: b62053.student.cwru.edu


When is the latest word from the money grubbers at intel as to when
the P5 is due out?

Thanks
BOB
From: tmh@keks.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.sys.intel
Subject: Intel is wasting too much money on ads!
Date: 11 Nov 92 03:53:16 GMT
Distribution: comp
Organization: GMD-FIRST, Berlin

I live in Berlin, Germany. Walking through the streets, I see a big
486(Intel inside) sign on every second billboard all across the city,
that means you can hardly go anywhere and not see at least of those
signs...
I can not recall that any company however loosely associated with the
computer industry has ever come close to putting up that many signs.
I don't know how much money goes into this, but the only other
companies that have been able to afford such extravagance were those
that sell cancer sticks (Reynolds et.al.).

I've always paid dearly for my Intel CPUs. I used to think that it was
because they had high R&D costs and low yields. I'm getting my doubts.
I'd prefer it if Intel were to use it's money pile to make their CPUs
cheaper not to pay for ads or lawyers to sue the socks off AMD or
Cyrix. They could just keep on being better instead of trying to rape
the industry and the computer user. If this trend continues, I see it
as my duty as a citizen, to boycott Intel, just as I would (and have)
boycott a political tyrant.
---
Thomas M. Hoberg   | Internet: tmh@first.gmd.de
1000 Berlin 41     |           tmh@cs.tu-berlin.de
Wielandstr. 4      |
Germany            | BITNET:   tmh@tub.bitnet 
+49-30-851-50-21   |
From: gordon@robots.ox.ac.uk (Gordon Buxton)
Newsgroups: comp.sys.intel
Subject: Re: Plural of Pentium (was Re: Why not INTEL586?)
Date: 12 Nov 92 17:19:11 GMT
Organization: Robotics Research Group, Engineering Science Dept, Oxford, UK.
Originator: gordon@lucrece.robots

In article <2134@shaman.wv.tek.com> andrew@frip.wv.tek.com writes:
>
>	"The ending is all wrong."
>
>In English, "all wrong" never stopped anybody.  Other adjectives with
>this ending include medium and premium.

Both of which are also used as nouns.

Gordon.
Newsgroups: comp.sys.intel,comp.sys.ibm.pc.hardware,comp.benchmarks
From: smithbm@craft.camp.clarkson.edu (Azrak)
Subject: Re: ATI Ultra PRO 24-bit?
Organization: Clarkson University
Date: Fri, 6 Nov 1992 14:51:11 GMT

pfk@rz.uni-jena.de (Frank Klemm) writes:


>In article <smithbm.720819736@craft.camp.clarkson.edu>, smithbm@craft.camp.clarkson.edu (Azrak) writes:
>|> The ATI Graphics Ultra Pro with 2 Megs of VRAM will do the following
>|> resolutions (I am only including a portion of what it can do for brievity):
>|> 640x480x16.7M    (True 24 bit color)
>|> 800x600x16.7M    (True 24 bit color)
>|> 1024x768x65536   (Hi-color 16 bit) (No 24 bit color in this resolution)
>|> 1280x1024x256    (8 bit color)
>|> 
>|> Note that 1024x768x65536 uses 1.5 Megs of memory. Impossible to get 24 bit
>|> color at this resolution due to memory limitations.
>|> Note that 1280x1024x256 uses 1.3 Megs of memory. Impossible to get 16 bit
>|> color at this resolution due to memory limitations.

>Why do this card not support 1152x900x64k and 960x720x16M ???

I don't actually have the card in front of me (It is at home, 320 miles from
me at college), but I would imagine if you were to write some nasty assembly
code, you could tweak the card into some "undocumented" resolutions like
the two you mentioned above. I think I remember Fractint could switch the
old ATI VGAWonder (Which USED to be in the PC at home) into some weird
resolutions to gain a few hundred extra pixels for displaying fractals.
Maybe the same type of things can be done to the new Graphics Ultra Pro.

For the PC, the two resolutions you mentioned are not standard resolutions.
Are they SUN resolutions?

>Frank

- Brian  (smithbm@craft.camp.clarkson.edu)