HDTenEightyP/NetNews huggingface dataset:
From: dplatt@ntg.com (Dave Platt)
Subject: Re: So Maxtor Won't work on SUN Microsystems anymore?
Keywords: Maxtor,SunOs 4.1.2
Organization: New Technologies Group, Inc.  Palo Alto CA
Distribution: comp
Date: Sun, 26 Jul 1992 18:43:07 GMT

>Just talked to Maxtor tech support, and found out that SUN will not support
>Maxtor drives in release 4.1.2!  Now this sounds a bit strange to me, I'm
>going to call SUN and hear their side of the story before I get too
>disappointed!  

It's news to me.

>Anyone out there using a Maxtor MAX-P012S (1.2 GB) SCSI on a SPARC station
>running Sun/Os 4.1.2?  This makes my week!

Yes.  I have four of these drives on four SparcStation-2GX systems here
at NTG.  I also have five XT-8760S Maxtors, and a bunch of smaller
Maxtor internal drives (LXT-213S, both Sun-labelled and from anDATAco).
In fact, the only Sun-branded drives here are the internal drives which
came with the SparcStations... all of our external drives are non-Sun.

I just finished upgrading our entire network to 4.1.2 on Friday.  No
problems with the disks... zero, nada, none.  The machines boot from
Maxtor disks (the 2GX machines boot from LXT-213s, the Sparc-1 boots
from an XT-8760S).

I'm not sure what the Maxtor tech-support representative was referring
to.  My recollection is that older versions of SunOS (up through 4.1.1)
required a special patch to be able to support the full capacity of
1.2-gig disks.  This patch isn't supplied for 4.1.2, because it's not
necessary - gigabyte-disk support was rolled into the SCSI driver in
4.1.2.

It may be true that Sun does not _officially_ support these drives...
the XT-8760S entries in /etc/format.dat are commented out, and there's
no entry at all for the MAX-P012S drive at all.  This shouldn't stop you
from researching the drive geometry, creating a format.dat entry to
suit, and formatting and partitioning the drive in a suitable fashion.
One of the Sun gigabyte-disk entries (1.0 or 1.3 gig) might serve as a
suitable starting point.

I've gotten some "unsupported" Micropolis drives on line here, using
this technique.  They haven't given a bit of trouble.

Frequently, what a vendor means when they say "X isn't supported under
version Y" is really "We haven't tried it ourselves, we don't promise
that it will work, and we don't promise to fix it if it doesn't". Other
times, what they mean is "We produce a configuration Z which is similar
to X, we'd really rather that you buy Z from us than X from somebody
else, and thus we're not going to say that we support X."  Sometimes,
both of these apply.

"We do not support X" does not, fortunately, mean "X doesn't work."  At
least, not always.

-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
Newsgroups: comp.periphs.scsi
From: neese@adaptx1.UUCP (Roy Neese)
Subject: Re: Adaptec 1542b and Fujistu driver problems
Organization: Adaptec Inc., Texas
Distribution: usa
Date: Wed, 29 Jul 1992 20:39:12 GMT

In article <1992Jul21.004024.20070@picard.agames.com> yaturner@picard.agames.com (D'arc Angel) writes:
> I just upgraded my controller from an Adaptec 1522 to a 1542b (thank you
> Windows NT) and I have encountered a problem that did exist before. If
> I don't use the disk for a while (about 5-10 minutes), the first time 
> I access it, it recalibrates the drive. This is very reproducable, any
> ideas, suggestions ??

You're not, by chance, confusing this with the Fujitsu doing it's own
recalibration are you?  Every Fujitsu disk driver I have ever seen does
recalibration on it's own.  Just a thought.
---

			Roy Neese
			Adaptec Senior UNIX/SCSI Software Engineer
			UUCP:	convex!egsner!adaptex!neese
			Inet:	neese%adaptex@cirr.com
From: ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy)
Newsgroups: comp.periphs.scsi
Subject: Re: Panic, WD chip availability
Keywords: WD scsi 33C93A
Date: 31 Jul 92 06:14:59 GMT
Organization: Stanford Linear Accelerator Center

In article <1992Jul30.005211.11307@eng.ufl.edu> jon@alpha.ee.ufl.edu
(Jon Mellott) writes (edited):
>BTW, for those of you who are building systems with SCSI interfaces 
>(or were afraid to because of the difficulty of writing SCSI drivers), 
>take a long, hard look at the WD/Am33C93A. This is a very smart device
>which handles most of the SCSI protocol all by itself. I first got my 
>hands on them early in the game (I've got beta silicon) when the NCR 
>53C90 was the only game in town: I had been really dreading implementing 
>SCSI on the 53C90. 
>
>Good Luck,
>Jon Mellott
>High Speed Digital Architecture Laboratory
>University of Florida
>(jon@alpha.ee.ufl.edu)

Either we are not talking about the same chips, or we disagree
completely. The 53C80 (note the eight) is the dreaded chip where you
have to do all the protocol yourself (lots of work). The 53C90 (nine)
is very smart, and does a lot of the protocol (more than the
WD33C93A). For example, look at the number of interrupts you have to
handle for a typical select-command-and-transfer cycle with the two
chips; the difference is about a factor of two. Much more important to
me: The WD33C93A is full of bugs (the bug list is several pages long),
some of which are greatly anoying (ABORT doesn't work on full moon and
such). The other difference was the support: NCR sent me a lot of
material, including sample code, a thick manual, and free sample
chips. It took weeks of phone calls to just get the bug sheet out of
the WD office, and the manual for the 33C93A is pretty bad compared to
the NCR 53C90.

Disclaimer: I have built SCSI-boards for my cp/m system with both
chips. And I probably have some hard feeling towards the WD chip,
which made life hell for me for a few weekends. And I probably have a
specially soft spot for the NCR chip, which was like seeing the light
at the end of the SCSI tunnel for me. So take everything I see with a
grain of salt. Plus, my employer probably wouldn't know what a SCSI
chip is if he (she? it?) found one floating in the coffee cup.

Disclaimer: I unfortunately own no stock in either company. Too poor,
I guess.

-- 
Ralph Becker-Szendy                          RALPH@SLACVM.SLAC.STANFORD.EDU
Stanford Linear Accelerator Center                      RALPH@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309                    (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.
From: rogoza@FASECON.ECON.NYU.EDU (Kenneth T. Rogoza)
Newsgroups: comp.periphs.scsi
Subject: Exabyte 8200 and data compression
Date: 30 Jul 92 05:38:06 GMT
Organization: New York University

We are going to purchase a Exabyte EXB-8200 (can't wait for the 8205) and 
would like to add a data compression board. Any idea of what kind of data 
compression board works best? What would such a board typically cost? Any 
important considerations to look for when deciding on the type of board? 
Thanks in advance.
*************
Ken Rogoza C.V. Starr Center for Applied Economics, New York University
Internet: rogoza@fasecon.econ.nyu.edu
**************
Xref: sparky comp.periphs.scsi:3818 comp.sys.ibm.pc.soundcard:890
From: wegrzyn@nic.cerf.net (Chuck Wegrzyn)
Newsgroups: comp.periphs.scsi,comp.sys.ibm.pc.soundcard
Subject: Re: AHA1542B and Sound Blaster Pro Problem
Keywords: SCSI SB Pro, 1542B, SCSI
Date: 30 Jul 92 19:05:50 GMT
Followup-To: comp.periphs.scsi
Organization: CERFnet

I am sorry you are having so many problems with the 1542B. The
system I run has the 1542B, Maxtor and CDC drives, the Pioneer
Dual Media Optical drive, a NEC CDR-84 CDROM player and the
Archive 2150S tape drive. I have had a Soundblaster Pro in the
box, and have replaced it with a MediaVision board. The mother
board I use is an EISA 486/33 from Micronics. All I can say is
that I have had no problems with playing audio through the
sound boards -- none what so ever.

Furthermore, I run Windows 3.1 with QEMM and ASPI4DOS and, other
than not being able to load ASPI34DOS into high memory I've
had to do nothing "secret" or "special" to my setup. Of course,
I had to run the QEMM fixup for Windows, but that was nothing
special.

While I can complain about the Adaptec BBS, I find having Roy Neese
on the Internet very helpful and nice to have around. Perhaps
Adaptec will either deal with end users at some time or get
better distributors for their stuff. But that is another story...

Chuck Wegrzyn
From: neese@adaptx1.UUCP
Newsgroups: comp.periphs.scsi
Date: 17 Jul 92 18:39 MDT
Subject: Re: Adaptec 1542b + disk probs
Nf-ID: #R:ucdavis.ucdavis.edu:15059:1992Jul17.143929.10103@adaptx1.u:-398367562:001:556
Nf-From: adaptx1.uucp!neese    Jul 17 18:39:00 1992


> How about the 1542a? SCSI-2 also?? Is this card sufficiently equal 
> to the 1542b that even ROM upgrades (from the Adaptec BBS) will work?

The 1542A is SCSI-2 compatible.  The ROM upgrades for the 1542B cannot
work in a 1542A due to differences in the logic implementations of both.
The 1542B had more of the 1542A firmware moved to hardware.  The BIOS
ROM's for the 1542B may work in a 1542A, but it is not garanteed.
---

			Roy Neese
			Adaptec Senior UNIX/SCSI Software Engineer
			UUCP:	convex!egsner!adaptex!neese
			Inet:	neese%adaptex@cirr.com

Newsgroups: comp.periphs.scsi
From: clear@cavebbs.welly.gen.nz (Charlie Lear)
Subject: Re: AHA1542B+Colorado Tape=DismalPerformance???
Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ
Date: Sun, 26 Jul 92 06:17:11 GMT

In article <1992Jul26.012007.11066@cavebbs.welly.gen.nz> clear@cavebbs.welly.gen.nz (Charlie Lear) writes:
>However, retoring from tape the situation is the same if not worse: it has
>taken over three hours to restore 41MB so far (233k/min).  Only another 240MB
>to go... feh.

Here I am, reduced to following up my own post as a means of eating humble
pie...

While waiting for the restore, I read the Adaptec manuals again.  I read the
motherboard manual, the disk manuals, the DOS manual, and the tape manual.

Lo, it came to pass that on the very last page of the tape manual, yea,
even unto the one immediately before the index, there was inscribed the
problem and the workaround:

	"If you are using Adaptec 1540 or 1542 SCSI hard drive controller,
	you may notice slow backup and restore times.  This is due to DMA
	timing conflicts between our backup system and the Adaptec controller.
	To improve performance and fix the conflict, start up the Adaptec
	controller, ASPI4DOS.SYS with the /n2 option.  Refer to your Adaptec
	manual for more information."

And upon doing as I was bid and rebooting the computer, I beheld that a
miracle had happened and that my few remaining hairs would not indeed be
pulled out in frustration.
 
	C:	75829k	302min	251k/sec
	D:	60982k	147min	414k/sec
	Add /n2 to the ASPI4DOS in my config.sys
	F:	40924k	 19min 2153k/sec

So let my months of hunting for a solution be a lesson to you all... when 
you move a peripheral between machines, check the bloody manual of the
peripheral to see if there's any gotchas.
 
I *hate* it when that happens...

-- 
Charlie "The Bear" Lear | clear@cavebbs.welly.gen.nz | Kawasaki 750GT DoD#0221
Ph/Fax +64 4 564-5307 |  You're not paranoid.  They really ARE out to get you.
  The Cave MegaBBS +64 4 5642269 V32 | PO Box 2009, Wellington, New Zealand
From: sjb5@ns1.cc.lehigh.edu (STACY JOHN BEHRENS)
Newsgroups: comp.periphs.scsi
Subject: Adaptec 1542b.  HEEELLLLPPPPPP!
Date: 25 Jul 92 21:10:47 GMT
Organization: Lehigh University

I recently purchased an Adaptec 1542B.  After several reformats of my drive,
and disabling the parity checking in my system (not SCSI) BIOS, I have been
able to achieve some functionality under DOS.  Not all programs will run
properly, and many crash and burn shortly after boot up.  I want to install
OS/2 but until I clear up these bugs, that will be impossible.

I have:
        Adaptec 1542B SCSI card
        Quantum 170MB SCSI drive
        40 MHz 386 motherboard w/ AMI BIOS  (hi-flex version)
        8 megs of RAM
        Paradise Pro VGA card
        Some other miscellaneous cards which are not currently in use.
           (translation, can be removed)

I can get any technical info desired and would greatly appriciate any and all
help.  Thanks.

                                                        Stacy John Behrens
                                                        *===)-------------
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.periphs.scsi
Subject: Re: AHA1542 && SBPro conflict
Date: 24 Jul 92 10:46:10 GMT
Organization: St. Peter's College, US

In article <76482@ut-emx.uucp>, vax@ccwf.cc.utexas.edu (Vax) writes:
> Once again, I have the same problem I did before - someone please help!
> (I called adaptec 2 weeks ago, still no response, not even a call!)
> I am postponing a substantial purchase of scsi secondary store because
> there seems to be a conflict between a AHA1542B and an Sound Blaster Pro,
> particularly in data-intensive writes to the digital audio output port.

  What exactly is happening? I have a 1542B w/ a CDC 766Mb drive at ID 0
and a Wangtek 5150ES at ID 4. I dropped in a SBPro (and somehow corrupted
my MS-DOS filesystem) but after I restored it the disk, tape, and SBPro
are all working together flawlessly. This is on a no-name 486/50, 16Mb,
Symphony chipset, 256Kb external cache.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
Newsgroups: comp.periphs.scsi,comp.os.os2.misc
From: moncrg@iear.arts.rpi.edu (gregory d moncreaff)
Subject: Re: Future Domain SCSI Adapter
Organization: the committee for asethetic deletions
Date: Wed, 22 Jul 1992 17:58:56 GMT

In article <1992Jul22.113737.28378@murdoch.acc.Virginia.EDU> dtl8v@holmes.acc.Virginia.EDU (Heraclitus) writes:
>
>  In considering SCSI controllers that OS/2 2.0 supports, I ran across
>several variants of the Future Domain 1670 16-bit SCSI card.  It seems
>to have a bare version, an SVP version, and a DNK version.  Can anyone
>enlighten me as to the differences between them (and the meanings of
>the acronyms)?
>
the bare vs SVP vs DNK refers to the level of driver support
offered. bare does MSDOS, SVP will also do OS/2, DNK adds Unix.

what i'm unfamiliar with is what versions support tape and
cd-rom devices (and also windowsNT) as far as i can tell, if
you want the greatest range of supported peripherals and OS's
you basically have to go with the DNK version. if your needs
are less than you can save $50 to $100 by only getting a bare
or SVP version

(if you get the full details, please post!)
-- 
gregory d moncreaff dorsai@iear.arts.rpi.edu dorsai@rpi.edu 
	rensselaer polytechnic institue troy ny
	chelmsford ma
Newsgroups: comp.periphs.scsi
From: toreh@bootes.sds.no (Tore Haraldsen)
Subject: Re: AHA1542A problem
Organization: Statens Datasentral A/S, SDS, Norway
Date: Tue, 21 Jul 1992 10:26:24 GMT

In article <1992Jul21.001616.5201@ulrik.uio.no> toreh@bootes.sds.no (Tore Haraldsen) writes:
>In trying to install the bew freebie unix 386BSD (look into
>comp.unix.bsd for pointers) I have run into a problem with my Adaptec
>1542A Rev.D w/version 3.07 proms.
>
>The SCSI driver in the 386BSD release uses scatter/gather w/r functions
>(2, 4 aren't they). Is this not supported by a 1542A Rev.D adapter, or
>are there rom revisions around to cure the problems? Or am I out in the
>bushes, beating the wrong one?
>
>
>-- Tore Haraldsen

(following up myself again..)
The above refers to opcodes with scatter/gather functionality that
returns residual length...

-- Tore Haraldsen
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.periphs.scsi
Subject: Re: Adaptec 1542b question
Date: 30 Jul 92 00:06:44 GMT
Organization: St. Peter's College, US

In article <1992Jul29.192732.29465@mtu.edu>, ajchuah@mtu.edu ([*BARK*]) writes:
> 
> 	I thought i'd just ask this question since we are in
> to this question on the Adaptec pricing.  Does anyone know
> or has anyone been able to get the Adaptec 1542b card to work
> with more than 1G drives?  I called Sound Electro Flight 
> a couple of days ago and they said the Adaptec 1542b does
> not support drives above 1G.  If the Adaptec 1542b does
> not support drives above 1G, what happens when i give it a drive
> which is above 1G, in DOS that is.  Does it not recognize the
> drive at all or does it just ignore the rest of the space?

  Adaptec has new ROM images available on their BBS (and also for sale if
you're not comfortable with programming your own). In conjunction with new
versions of ASPI4DOS and ASPIDSK (ASW-410 if I recall correctly) these will
support disks all the way up to the SCSI architectural limit.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
Newsgroups: comp.periphs.scsi
From: clear@cavebbs.welly.gen.nz (Charlie Lear)
Subject: AHA1542B+Colorado Tape=DismalPerformance???
Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ
Date: Sun, 26 Jul 92 01:20:07 GMT

I'm having problems with my system and I'd like to know if I'm the only
one, or if anyone has experienced and fixed this...

System -  386/33 ISA, 12MB RAM, all the usual bits
105MB RLL drive C:, WD RLL controller with floppy support
213MB SCSI drive D:, Adaptec 1542B with floppy disabled
Colorado Jumbo 250 DJ20 tape backup hooked up to WD card
Aspi4dos in config.sys.

Backing up with Fastback to 1.44MB floppies was fine - data rates of around
2000k/minute depending on compression.

I originally ran the Colorado in a 386/25 with twin IDE disks and got between
2000 and 2200k/min consistently with Colorado's backup s/w.

After installing the tape in the /33, I found it would back up the RLL disk
at an average rate of 2182k/min, but backing up partitions on the SCSI disk
would cause it to fall to 363k/min, 427k/min, 267k/min, 298k/min, 350k/min
etc.  Quite inconsistent, with no compression as I was backing up archives.

In fact, backing up the original 386/25 over a parallel "cheapnet" cable was 
getting better than 800k/min - two to three times faster than the local SCSI!

Pretty bloody dismal all round.  Disillusionment was setting in!

I just bought a new Seagate ST3283N SCSI disk to replace the RLL.  Pulled out
the WD controller and RLL disk, installed the Seagate and re-enabled floppy
support on the 1542B.  Disks are working fine.

However, retoring from tape the situation is the same if not worse: it has
taken over three hours to restore 41MB so far (233k/min).  Only another 240MB
to go... feh.

I bought the tape drive because I wasn't backing up as often as I should have.
I'm supposed to be backing up completely once a week and incrementally every
day.  The slight technical hitch is that I don't have all these hours to waste
waiting for the SCSI and tape to get their act together.

Somebody please tell me where I'm going wrong and what the hell I can do to
tweak the 1542B or my software to get things working.  Please post your reply
immediately - I'm sitting here waiting to hear from you - I can't do anything
else until this bloody restore is finished!

-- 
Charlie "The Bear" Lear | clear@cavebbs.welly.gen.nz | Kawasaki 750GT DoD#0221
Ph/Fax +64 4 564-5307 |  You're not paranoid.  They really ARE out to get you.
  The Cave MegaBBS +64 4 5642269 V32 | PO Box 2009, Wellington, New Zealand
Newsgroups: comp.periphs.scsi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: SCSI Bus Analyzers ???
Keywords: SCSI Bus Analyzer
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 24 Jul 92 06:04:56 GMT

In <45542@shamash.cdc.com> sjc@pooky.udev.cdc.com (Steven J Craig) writes:

| I am starting to look for a decent SCSI Bus Analyzer.  I have tried several
| times to get in contact with my local Adaptec 'Guy' and have had little
| luck.  They have two newer analyzers (SDS-310F and SDS-318FD)  
| 
| I would like to hear from you that have tried these (or others) and your
| thoughts about them (strengths / weeknesses).  I will summarize the
| results.
| 
| The analyzer should be able to handle SCSI-1 and SCSI-2 controller boards
| SCSI-2 FAST would also be a plus.  Actual data transfer capture capabilities
| a must.  I do not really care if the analyzer is a PC-AT board or not. 
| DIFF and SE connections a must.

The sds310f handles fast scsi, scsi 1 and scsi 2 don't require
differnces in the controller (aside from fast scsi).

The full 310f, including a PC runs around 25K with all the software.
It is pretty decent, for both analysis, conformance, and target
emulation, with relatively few glitches in the current s/w.

Get a 386 PC with either a fast disk, or configure it to have a
RAM disk; the display of the gathered data is very largely gated
by disk i/o rates.

The HP module that drops into a 1650 analyzer is pretty good if
all you need is an analyzer, it also supports fast scsi.
--
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: kev@hpcpbla.bri.hp.com (Kevin Jones)
Date: Thu, 30 Jul 1992 06:26:29 GMT
Subject: Re: SCSI ABORT COMMAND
Organization: HP Computer Peripherals Bristol, UK
Newsgroups: comp.periphs.scsi

> / hpcpbla:comp.periphs.scsi / masood@ee.rochester.edu (Taha Masood) /  3:55 pm  Jul 29, 1992 /
> I am trying to find a better and more graceful way to abort a SCSI write
> operation during file transfer to a SCSI disk. SCSI ABORT Command seems
> ungraceful, since it does not return any status back, I am trying to find
> an alternate command set that would achieve the same goal. My goal is not
> to loose any data that has already been written on the disk (after aborting
> the operation), issue another SCSI command and then continue with my write
> operation.

"Abort" is a message, not a command, but it has the effect you describe.
The good news is that SCSI defines another message:
"Terminate I/O Process" (code 0x11) sent from an initiator to a
target. The target should stop the WRITE, keep whatever data it
has received and report status ASCQ: I/O PROCESS TERMINATED.
The bad news is that I doubt you will find any disk's out there that
implement this message since it was never very popular.


-----------------------------------------------------------------
Kevin Jones.                       | Hewlett Packard Ltd,
                                   | Computer Peripherals Bristol,
kev%hpcpbla@hplb.hpl.hp.com        | Filton Road,
                                   | Stoke Gifford,
Tel: 011 44 272 228351             | Bristol.   BS12 6QZ.
                                   | ENGLAND.
-----------------------------------------------------------------

This response does not represent the official position of, or
statement by, the Hewlett-Packard Company.  The above data is
provided for informational purposes only. It is supplied
without warranty of any kind.
Newsgroups: comp.periphs.scsi
From: masood@ee.rochester.edu (Taha Masood)
Subject: SCSI ABORT COMMAND
Organization: Univ of Rochester, College of Engineering and Applied Science
Date: Wed, 29 Jul 1992 14:55:47 GMT

I am trying to find a better and more graceful way to abort a SCSI write
operation during file transfer to a SCSI disk. SCSI ABORT Command seems
ungraceful, since it does not return any status back, I am trying to find
an alternate command set that would achieve the same goal. My goal is not
to loose any data that has already been written on the disk (after aborting
the operation), issue another SCSI command and then continue with my write
operation.

Taha Masood

P.S Please send replies to masood.wbst311@xerox.com or
        masood@ee.rochester.edu
any response will be greatly appreciated.



Newsgroups: comp.periphs.scsi
From: gburton@magnus.acs.ohio-state.edu (Garland O Burton)
Subject: parallel<->scsi on zenith eaZy-pc?
Organization: The Ohio State University
Distribution: usa
Date: Mon, 27 Jul 1992 15:37:24 GMT

will this trantor device work on my machine?

what kind of hard drive can i use?

what limitations do they have?

gb

-- 
gburton@magnus.acs.ohio-state.edu...buckeye.hoopsters=1992.big.ten.champs!
Newsgroups: comp.periphs.scsi