HDTenEightyP/NetNews huggingface dataset:
From: sritchie@cs.ubc.ca (Stuart Ritchie)
Subject: Re: Max Serial Port Speed stuck at 9600
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Fri, 11 Sep 92 09:33:46 GMT

In article <BuEI5J.4sp@iat.holonet.net> bwilliam@iat.holonet.net (Bill Williams) writes:
>Believe me, The Mac handles serial better than the NeXT allows currently.

Unless you're running Unix on the Mac.  I guess that a Mac
will suffer similar interrupt overhead in this case.

>And the computer I own (A IIfx) has dedicated computer subsystems using 
>65C02 processors to handle the serial ports. (This is a feature that was
>discontinued by Apple years ago and was only put in the Mac IIfx)

Perhaps the Apple engineers added this feature to help reduce
interrupt overhead when running heavyweight operating systems.
Do you run Unix on your IIfx?  Can you compare serial port
performance: Unix vs. MacOS?  Just curious...

Stuart
Newsgroups: comp.sys.next.hardware
Subject: Re: Mono Monitor Size: 17" or 16" or 15.5" ?
From: feijai@endor.byu.edu (Sean Luke)
Date: 9 Sep 92 13:47:48 -0700
Reply-To: sean@digaudio.byu.edu

In article <1992Sep7.174828.312@nntpd.lkg.dec.com>  writes:

>Sony makes a 28" monitor (20" on a side) that displays 2048x2048.
>If you absolutely MUST have it, its a mere $40,000.  -Steve


Phillips makes a black 423-mile monitor with infinite resolution.   
Phillips does not specify the price but has been known to settle for small  
third-world countries.   Unfortunately, immediately after purchase, it   
dims and becomes washed-out-looking and must be replaced.  However,  
although Phillips offers a warranty until 2102, you pay shipping.  

|)	<--Geordi LaForge smiley for the Star-Trek-smiley-impaired.

--

Sean Luke
Brigham Young University                   MILK:  It Comes From Cows
sean@digaudio.byu.edu  
NeXTmail and nifty Mac stuff welcome
From: rseymour@reed.edu (Robert Seymour)
Newsgroups: comp.sys.next.hardware
Subject: The Future of NeXT Hardware
Keywords: NeXT, future, NeXTcube
Date: 7 Sep 92 04:34:35 GMT
Organization: Reed College, Portland, OR


Hello,
	I'm planning on buying a NeXTcube and I wanted to find out if anyone  
knows what NeXT has in store for the future of the hardware platform. I've  
heard a variety of stories from NeXTstep running on a SPARC chip or and HP  
workstation to two MC88110s on a NeXT logic board (a Twin Turbo?). I would like  
to know what the upgrade paths will be and which models will continue with the  
chip change (I heard a rumor that the NeXTcube was history) or will NeXT just  
wait around for the '060. I'd like to hear what they have announced as a  
policy, hinted on, or even rumors. Also does anyone know what type of removable  
media they plan to support? Hard drive and CD-ROM are great for system  
software, but developers have to ship products, and people need backups. Are  
they going with 3.5" 128MB Magneto-Opticals, 21MB Floptical Drive, or just the  
current 2.88MB floppy? Please respond to me via email or a post.

--
Robert Seymour				rseymour@reed.edu
Reed College #611			
3203 SE Woodstock Blvd			
Portland, OR 97202-8199			(NeXTmail OK)
From: bwebster@pages.com (Bruce F. Webster)
Newsgroups: comp.sys.next.hardware
Subject: Re: Best place to buy toner cartridge for NeXT printer?
Date: 10 Sep 92 03:40:47 GMT
Reply-To: bwebster@pages.com
Organization: Banzai Research Institute

In article <1992Sep3.151127.4000@fcom.cc.utah.edu> alex@fff.chem.utah.edu (Alex  
Dommasch) writes:
> Can you get toner cartridges by mail order?  And if so, who knows of a place  
to  
> get them cheap?  Also, do most places take a spent cartridge for recycling?
> 

You can probably find a local place for recycled toner cartridges (which is  
what we use here). This is because the cartridge is standard for Canon copiers,  
and there are lots of businesses which likewise recycle toner cartridges  
(rather than pay $100+ for a new one). Check the yellow pages. The place we use  
here in San Diego actually does delivery/pick up.  ..bruce..

Bruce F. Webster
CTO, Pages Software Inc.
bwebster@pages.com
#import <pages/disclaimer.h>
Newsgroups: comp.sys.next.hardware
From: steves@truevision.com (Steve Spicklemire)
Subject: IBM SCSIs on NeXTs?
Organization: Truevision Inc., Indianapolis, IN
Date: Tue, 08 Sep 1992 12:06:47 GMT

Hi,
	I posted a note like this to comp.sys.next.sysadmin and got one 
response that TECOR couldn't get it to work, but I still (perhaps naively)
hopeful that someone out there in netland has successfully used an IBM
SCSI drive on a NeXT. I've finally convinced the folks in our computer
center to try NeXT, but it will only work if we can get them to work
with IBM SCSIs! I'm gonna be *really* depressed if they cannot, and 
I have to eat all that crow.

Please help!

thanks!
-steve
-- 
Steve Spicklemire
steves@truevision.com (daily)	spicklemire@gandlf.uindy.edu (sometimes)
Dept. of Mathematics and Physics, Univ of Indianapolis 
(317) 788-3313
Newsgroups: comp.sys.next.hardware
From: dls7627@zeus.tamu.edu (SLOTNICK, DAVID LOUIS)
Subject: Overheated sound box?
News-Software: VAX/VMS VNEWS 1.41    
Organization: Texas A&M University, Academic Computing Services
Date: Sun, 13 Sep 1992 01:43:00 GMT


Hello NeXT users!  I have a question that hopefully one of you kind people
can help me with.  What I am about to describe sounds completely insane,
but I have tried everything obvious and cannot find the cause.

I recently bought a modem and installed it on my NeXTStation Turbo Station
16/400.  To conserve desk space, I placed the sound box on top of the modem.
To my surprise, in about thirty minutes my machine COMPLETELY locked up---
it would accept NOTHING from the keyboard (even the command-command-~ and
alternate-alternate-* key sequences) and nothing from the mouse.  The only
thing I could do to get the computer to respond was press the "power" key,
but even then I couldn't hit the "turn it off" button because my mous wouldn't
work!  After calling NeXT support to no avail, I was forced to pull the plug
in a hard power-down.  To my surprise, WHEN THE MACHINE BOOTED UP IT WAS STILL
LOCKED!  I continued to power down again and again (four times total) until
finally I, by chance, removed the sound box from the top of the modem and 
placed it on the desk surface.  Then the reboot succeeded!!  After many trials
I determined that placing the modem on top of the modem somehow causes the
machine to lock up--trust me, I am a veteran NeXT user.

My question is this:  has anyone experienced this or a similar problem?
If not, can anyone hypothesize an explanation?

Since the top of the modem is moderately warm, I think that the sound box
may be overheating somehow, although this doesn't seem possible to me.

To repeat, it isn't the cables, slab, monitor, physical movement, or
ANYTHING ELSE which causes the failure---only placing the sound box
on top of the modem.

Any help would be greatly appreciated.

Thanks,
Dave
Newsgroups: comp.sys.next.hardware
From: mp@augur.han.de (Mathias Pruestel)
Subject: Re: DEC DE3105 hard disk
Reply-To: mp@augur.han.de (Mathias Pruestel)
Organization: Pruestel Group
Date: Sat, 5 Sep 92 14:29:18 GMT

In article <1992Sep2.222236.21238@muddcs.claremont.edu>  
jim@ptnext.claremont.edu (Jim Kieley) writes:
> I received a quick response to an earlier post I made today.  I am posting  
this  
> on the net at the respondee's request.
> > >In comp.sys.next.hardware article  
<1992Sep2.183858.16034@muddcs.claremont.edu>  
> >you wrote:
> >> Has anyone attempted to put a DEC DE3105 1.05 GB 3.5" drive internally in  
a 
> >> NeXTstation?  For those that don't know, DEC is attempting to aggressively 
> 
> >Don't don't DON'T!
> 
> >The drive overheats and crashes, there is not enough ventilation inside a  
> >station.
> >Please post this on the net also, since I have no post-access at the moment,  
> >only read.
> 
> >--
> >Gerben Wierda                 Tel. (+31) 35 833539
> >	"If you don't know where you are going, any road will take you there."
> >	Lewis Carroll, "Alice in Wonderland".
> 
> 
> 
> I have heard that HP has had technical problems with their 3.5" 1GB drive.   
So,  
> I guess the best option for NeXTstation people who want a large hard disk is  
to  
> go with an external.  This negates the need to stick with the 3.5" format.
> 
> jim kieley
> jim@ptnext.claremont.edu



I have been using the DEC drive in my Cube for several weeks now. Works great.
For Stations I highly recommend installing a higher capacity fan! Over all,  
even 500MB Fujitsu drives get pretty hot in a Station, and I am aware of many
defects.
Cheers
Mathias
From: bwilliam@iat.holonet.net (Bill Williams)
Newsgroups: comp.sys.next.hardware
Subject: Re: Terrible SCSI Transfer
Date: 6 Sep 92 14:46:52 GMT
Article-I.D.: iat.Bu5vq5.3wF
Distribution: usa
Organization: HoloNet (BBS: 510-704-1058)

> These generate a lot of interrupts for each SCSI transaction 

I Believe that NO COMPUTER could efficiently use individual interrupts
during the data tranfer phase of a SCSI transaction. For example, though
using an interrupt driven buffer for ASYNCHRONOUS I/O might sound like a
good idea, it is much more likely that trying to get a NeXT or a Mac
Quadra 950 to handle over three million interrupts per second would
be ludicrous.

Therefore what the computers probably REALLY do is POLL.

The Macintosh, for example, locks up into a tight loop during a data
transfer phase and polls a register of the 53C90A until timeout failure
watchdog intervenes or until expected logical data block size is
reached.

Polling does indeed tie up the CPU dramatically on computers that use the
primary system CPU to perform the polling of the SCSI interface chip 
directly (for each byte)... I don't think NeXT computers even do that.
For example, I think the DMA services on the NeXT with the "Generic" 
user accessable SCSI Driver (Slow) do not use the system CPU to POLL.

PS The main advantages of a NCR53720 or NCR53710 chip (according to
the preface of the NCR53720 programming applications guide) is TO 
SIMPLIFY THE INTERFACE TO THE SCSI PROTOCOL CHIP. For example a
complete plain vanilla SCSI manager (not driver) can be written with 
only 400 NCR opcodes (actually a special meta-language with a NCR 
SCSI command compiler)... BUT A OLD STYLE 53C90 CHIP IS A STATE MACHINE
REQUIRING PINBALL LOGIC RESULTING IN OVER 4,000 opcodes minimum.

I am assuming that in my definition of usage asynchronous, narrow (8
bit) data is being used. Obviously a NCR53720 with "fictional"
32 bit wide synchronous data from an array server approaching
TWENTY MEG PER SECOND is a clear benefit of of a 720 chip.

The NeXT is fine. Quite bellyaching about SCSI Transfer when you
probably don't have either:

(1) a SCSI Network
(2) a SCSI Device containing an array of devices
(3) a SCSI solid state storage device
(4) a application on a NeXT capable of RAID striping across devices

If you do, fine, go ahead and complain.

BWilliams (My first Internet post in my life!)
Newsgroups: comp.sys.next.hardware
From: jeffo@ux1.cso.uiuc.edu (J.B. Nicholson-Owens)
Subject: Drives disappearing from label query commands, but still boot and operate
Reply-To: jeffo@ux1.cso.uiuc.edu
Organization: University of Illinois at Urbana
Date: Mon, 14 Sep 1992 20:28:44 GMT

Something kinda weird happened to me recently: my hard disks (one
swap, one system) boot fine and operate fine (that I can see) but when
I do a "scsimodes /dev/sd0a", "scsimodes /dev/sd1a" or use the "disk"
program to get info about the make, model and other info about the
drives, they come back with "<commandname>: bad ioctrl" (I'm not at
the NeXT in question now, so the spelling might not be exact, sorry).

The disk labels can't even be accessed, but they can be during boot
because that is how the system knows that the 105MB labeled "swapdisk"
should be used for swap and tmp space.

What would cause the label for a disk to only be visible during boot
but at all other times (using the scsimodes command) the info comes back
with 0 cylinders, 0 sectors, 1023 bytes/sector, couldn't get label name,
couldn't get drive make (QUANTUM or IMPRIMIS or something should come
back here, normally).

Thanks for any help you can offer.
-- 
-- Jeff (jeffo@uiuc.edu)
-- No NeXTmail please
Newsgroups: comp.sys.next.hardware
From: worstell@ece.ucdavis.edu (Glen Worstell)
Newsgroups: comp.sys.next.hardware
Subject: NeXT Cube backplane pinouts
Date: 15 Sep 92 18:46:07 GMT
Distribution: na
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Originator: worstell@madrone.eecs.ucdavis.edu

A hardware question:  what is the backplane pin number of the reset line?
Does the power supply pull the reset line low or high after power
has stabilized - or something else?
Thanks,
Glen.
Newsgroups: comp.sys.next.hardware,comp.sys.next.sysadmin
From: martin@weigele.de (Martin Weigele)
Subject: External HD FUJITSU M2266S-512, Partitioning and owner of dirs problem
Keywords: Partitioning SCSI HD owner
Organization: M. Weigele
Date: Tue, 15 Sep 1992 20:53:56 GMT

Hi there,

how can I partition the above Gigabyte HD ? I want three partitions, 25%, 25%  
and 50 %. The manuals aren't very specific about this (at least I couldn't find  
enough infos), FAQs treat only smaller disks.

Anybody done this? BTW the disk seems to work using the standard menu-based  
initaliziation option (= one 900 MB partition), except for a very strange  
change in ownership occuring.
When changing directories using chown -R on the new disk, owners of other  
directories on the same tree level keep changing while the one wanted is  
reported correctly by ls -l afterwards.
OS version is 2.1

Is this a size problem, perhaps, or could it have to do with the fact that the  
disk is apparently recognized as an `optical' (an OD icon is displayed)?

Any help much appreciated. Email preferred, I will summarize.
Regards
-- 
Martin Weigele, Kapellenweg 32, D-W-5300 Bonn 2
phone +49 228 333252 home, +49 228 9866385 office
email: martin@weigele.de
Newsgroups: comp.sys.next.hardware
From: moksha!mgb (Michael Branton)
Subject: Re: DEC DE3105 hard drive
Reply-To: mgb@stetson.bitnet
Organization: Totally Disorganized
Date: Sun, 6 Sep 1992 14:38:03 GMT

In article <1992Sep2.183858.16034@muddcs.claremont.edu>  
jim@ptnext.claremont.edu (Jim Kieley) writes:
> Has anyone attempted to put a DEC DE3105 1.05 GB 3.5" drive internally in a  
> NeXTstation?  For those that don't know, DEC is attempting to aggressively  
> market these drives so they will be sopped up by the workstation market (e.g.  
> SUN people).  These are fast SCSI-2 drives operating at 5400 rpm that can be  
> purchased for under $1800 with a 5 year warranty.  I am assuming getting  
these  
> to work in a NeXT will involve little more than disabling the SCSI-2 features  
> via a jumper.  My concern is with the heat potentially generated by a 5400  
rpm  
> drive (presumably this is much greater than that generated by the 3600 rpm  
> drives typically found in NeXTstations).  There have been reported problems  
> with putting these drives in certain VAXstations without fans.  Since the  
> NeXTstations have fans I am assuming the potential problems will be  
negligible,  
> but you never know.  The CPUs in NeXTs have heatsinks so heat sensitivity  
must  
> be a fairly serious consideration in the overall design.  Any experiences or  
> comments are welcome.


I have had two vendors and one person who is using this drive tell me that  
mounting it internally is a bad idea, as the drive runs too hot for the  
enclosure.

-- 


-Michael

Newsgroups: comp.sys.next.hardware
From: jon@afs.com (Jonathan Hendry)
Subject: Re: HD on old cubes
Distribution: USA
Date: Thu, 10 Sep 1992 14:18:25 GMT

In article <1992Sep5.045734.7698@ra.msstate.edu>  
hybowie@sunvis1.vislab.olemiss.edu (Randy Bowie) writes:
>I got this idea, and mebbe you can help.
>
>the original Cubes have that magneto-optical drive, right?
>it's ESDI... could an ESDI drive be substituted, and perhaps even become the  
primary drive?
>NeXT folks have no idea... i might try it.
>any ideas?
>
>Please reply via mail, 'cause my usenet access is quite limited.
>ward@hydra.cche.olemiss.edu (NeXTMail prefered)
>ward@papagayo.srcc.lsu.edu (Non-NeXTMail prefered)

I believe that the MO drive uses a custom interface, not ESDI.
--
Jonathan Hendry  Anderson Financial Systems
jon@afs.com  (Nextmail Welcome!) or hendryjw@duvm.ocs.drexel.edu
Newsgroups: comp.sys.next.hardware
From: mrr@scss3.cl.msu.edu (Mark Riordan)
Subject: Re: Conner CP3540 users out there?
Organization: Michigan State University
X-Newsreader: Tin 1.1 PL3
Date: Sat, 5 Sep 92 02:27:01 GMT

alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal) writes:
: Hi there!  I'm considering the purchase of one of these drives to
: stick into my NeXTstation (this is their new 540MB drive).  I called
: I wasn't overly impressed with Conner tech support, so is there
: somebody out there who knows for sure?

I have an external Conner 540MB disk on my NeXTstation, and I'm
very pleased with it.  It's fast and quiet.
I got it from MacDirect for $1248.  There was no trouble in formatting
it--I just had NeXTStep do it.

Mark R.   
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: A secret option to [acfm]bcast_l...
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 11 Sep 1992 12:38:17 GMT

A few people in a row have sent me email asking how to disable the
Isis causality property selectively.

For example, suppose that your application has groups A and B and
that activity in A is totally independent of activity in B (A and
B could even be classes of groups).  

Normally, if m1 is a cbcast in A, m2 in B, and m3 in A, then
Isis will go to some trouble to figure out if m1 -> m2 -> m3 (causal
relationship) and some expense to ensure that m1 is delivered before
m2 which is delivered before m3 at destinations these have in common.

Normally, this is what you would want.  

However, there may be times when you KNOW that m2 is independent of
m1, m3 and don't want to allow such a causal chain to be detected and
enforced because of cost implications.  Perhaps, m2 is an advisory
message concerning system overload and needs to get through promptly,
even if it violates causality in group A to do so.

Two new options are available in V3.0.6/V2.2.6 in support of this
possibility.  They are specified by including "NO" in the options
list to a long-form broadcast, as in cbcast_l("NOx", ....)

  - Option "N" means don't block for flow control: No flow control.
	(In fact, this is just advisory and Isis might block anyhow)
        since if we don't do any flow control, UNIX might lose a lot of
        data.
  - Option "O" means don't enforce causality when switching groups.
       So, m1 -> m2 iff: (sent in the same group) or (sent with "O" not
       specified and sent in different groups).

The highest performance architecture for many applications is to build
a lot of overlapped groups, one per (possible-sender,destination-set) pair,
and then use cbcast_l("NOx", ..., 0) -- asynchronous optimistic, non-flow
controlled cbcast, excluding the sender.  

These options also work for abcast, fbcast and even mbcast.  However, O
is a no-op on the latter two sorts of multicasts, which don't respect
causality in any case.

A warning: don't use these options unless you understand causality...


-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: rcbc@honir.cs.cornell.edu (Robert Cooper)
Subject: Re: ISIS3.0 and C++
Reply-To: rcbc@cs.cornell.edu
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 8 Sep 1992 20:17:49 GMT

In article <1992Sep8.011740.2412@msuinfo.cl.msu.edu> adc@tardis.msu.edu (Alan D. Cabrera) writes:

   I'm registering some routines in C++ with isis_task and it seems that I
   must cast the routines to F570810ac.  Am I doing something wrong?  I'd
   like to use something more mnemonic.

If you cast the parameter as a void (*)(void *) you should be OK.
E.g.

     isis_task(void (*foobar)(void *), "foobar")

A shorthard typedef for this function type is declared isis.h but
unfortunately the typedef's name "v_routine_vs" was accidentally obscured
by our obscurifier, to become the highly mnemonic "F570810ac". We'll fix
this in the next release.

An alternative to casting the isis_task call (and the t_fork call as well)
is to declare the function itself with the types that isis_task expects:

void foobar (void *arg_void) {
   wombat *arg = arg_void;
   ....
}

...and then cast the void * argument to whatever type was actually passed
in. Most optimizing compilers won't create an extra variable or any extra
code for this example.

-- Robert Cooper
--
-- 
Newsgroups: comp.sys.isis
From: adc@tardis.msu.edu (Alan D. Cabrera)
Subject: ISIS3.0 and C++
Reply-To: adc@tardis.msu.edu
Organization: Michigan State University
Date: Tue, 8 Sep 92 01:17:40 GMT


I'm registering some routines in C++ with isis_task and it seems that I
must cast the routines to F570810ac.  Am I doing something wrong?  I'd
like to use something more mnemonic.

---
Alan Cabrera				internet:  adc@tardis.cl.msu.edu
Computer Laboratory			phone:     (517) 353-3027
Michigan State University		fax:       (517) 353-9847
514 Computer Center			bitnet:    CABRERA@MSU
East Lansing, MI 48824

Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: blocking requests
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Distribution: usa
Date: Tue, 15 Sep 1992 20:30:20 GMT

In article <15353@borg.cs.unc.edu> krishnar@weiss.cs.unc.edu (Rajarama Krishnan) writes:
>In my ISIS application a process has to join a process group. It has to get
>some data from the group. I didnt put that in the state transfer routine
>because I am also using logging and I dont want all this data to be passed
>during logging. To get around problem, what I am doing is join the group and
>then get the data separately. But this causes a problem. I start getting
>requests even before I have transferred this data. How can I avoid this?
>Is there anyway of blocking requests after the pg_join till I explicitly
>allow the requests to come?

There is a subtle way to do what you want.  You should code your state
transfer routine so that the receive routine in the process that is
joining does an RPC to a process (or group) that has the data it wants
from within the state receive routine.

The key thing is that it has to be inside the reception routine when it
does the call.

At this stage of a computation, new requests are still blocked out, and
they will remain blocked out in this case until the RPC finishes and
hence the state reception routine finishes.  At least, I think that is
what will happen.  

If this doesn't work, try initiating the operation from the send state
routine in the process doing the transfer out.  E.g. the group sends
a message into the new process "while state transfer is under way" that
causes it to load the extra state.  I think this would work, too.

To avoid having the state logged, I think you just need it to show up
as a reply to a message -- replies aren't logged.

A third approach would be to use isis_connect to make a TCP connection
and send the data "out of band" over the TCP socket, during the join.
Isis doesn't log data on TCP connections created this way.

All of these slip the data transfer in during the state transfer
period, when you have requests blocked because the transfer is underway.
In fact, what you are trying to do pushes a little beyond what the
Isis join model can currently accomodate.  But, hopefully one of these
tricks will work.
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428