pete@Octopus.COM (Pete Holzmann) (03/15/90)
Based on experiences during the past 6 months, I've come to the sorry
conclusion that SCSI is not defined well enough as an interface standard,
at least in the PC world. [If SCSI is the base I/O scheme for peripherals,
as in the Mac, etc, then I'm sure things ought to be much better...]
I'd love to be proven wrong; I'd love for someone to tell me 'there will be
a good solution in N months'. Does anyone have any insight?
First: no complaints about the interface between SCSI controllers and SCSI
devices. That works, and works well.
Unfortunately, that isn't enough! There are 2 major problems:
1) There is no standard way for software to talk to a SCSI controller
2) There is no standard way for a DMA-based SCSI controller to deal with
the '386 or '486 CPU's, which make a habit of changing memory maps
on the fly.
Some pretty awful problems result:
From problem 1: Buy 4 SCSI peripherals. Likely as not, they will come with
some custom interface software (drivers, etc.), and 4 different SCSI
interface boards. All (or mostly) mutually incompatible. This is MUCH
worse than normal custom interface cards. The SCSI cards all think they
are 'standard', and end up interfering with other SCSI cards in the
system! Specific example: SCSI hard drive, SCSI 9 track tape, SCSI
magneto-optical drive, SCSI Worm drive. Can't make them play together!!!
Sick.
From problem 2: I know of no SCSI controller on the market that functions
completely correctly with multitaskers, RAM organizers, Disk Cachers,
and the like. I suppose a completely dumb one (polled I/O) might, but
then you lose the performance gain of DMA. Isn't there anybody out
there who's done a DMA-interface SCSI disk device driver that works
in these kinds of situations?
Feeling somewhat disgruntled by the whole mess...
Pete
--
Peter Holzmann, Octopus Enterprises |(if you're a techie Christian & are
19611 La Mar Ct., Cupertino, CA 95014 |interested in helping w/ the Great
UUCP: {hpda,pyramid}!octopus!pete |Commission, email dsa-contact@octopus)
DSA office ans mach=408/996-7746;Work (SLP) voice=408/985-7400,FAX=408/985-0859jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (03/17/90)
In article <1990Mar15.042028.16024@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >Based on experiences during the past 6 months, I've come to the sorry >conclusion that SCSI is not defined well enough as an interface standard, >at least in the PC world. [If SCSI is the base I/O scheme for peripherals, >as in the Mac, etc, then I'm sure things ought to be much better...] > >I'd love to be proven wrong; I'd love for someone to tell me 'there will be >a good solution in N months'. Does anyone have any insight? I wish I had an exact value for N, but I don't. There is an industry group working on the problem called the CAM Committee (Common Access Method). Dal Allan chairs this group and he can be reached at 408-867-6630. This group has a draft document and is making progress. IBM and Microsoft are also rumored to to working on their own solution. No one knows whether it is compatible with CAM or not. (That is, no one I know knows or they are not telling :-). As for the first-party DMA (bus master) problems with memory management software, I believe there are software solutions available for these problems. You might want to check with your host adapter vendor or with your software vendor. >Feeling somewhat disgruntled by the whole mess... I hope this helps. The PC market really needs the CAM standard or a decent IBM/Microsoft de facto standard. By "decent", I mean one that is generic enough to permit a wide range of solutions. Whatever IBM announces (and whenever), let's hope there is a decent software interface with it so people do not feel compeled to write code that speaks directly to the hardware. If this happens, then it will be difficult to offer higher or lower performance versions of the SCSI hardware. -- John Lohmeyer J.Lohmeyer@Wichita.NCR.COM NCR Corp. uunet!ncrlnk!ncrwic!entec!jlohmeye 3718 N. Rock Rd. Voice: 316-636-8703 Wichita, KS 67226 SCSI BBS 316-636-8700 300/1200/2400 24 hours
jesup@cbmvax.commodore.com (Randell Jesup) (03/18/90)
In article <1990Mar15.042028.16024@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >Based on experiences during the past 6 months, I've come to the sorry >conclusion that SCSI is not defined well enough as an interface standard, >at least in the PC world. [If SCSI is the base I/O scheme for peripherals, >as in the Mac, etc, then I'm sure things ought to be much better...] Well, on the Amiga it's rapidly becoming the standard I/O interface. In addition, Commodore and it's 3rd-parties have agreed on two standards: one for storing partitioning information on a drive (including executables for custom filesystems used by partitions on that drive). The other standard is a common I/O device interface to allow software to send direct SCSI commands (this is an extension of the base-level disk driver interface standard, and is even supported by some non-scsi drives). The low-level drivers are either in ROM on the controller, or loaded off your boot disk automatically. This allows some nice things: we can take a drive from one system, attach it to another (on a different manufacturers controller), and it comes up with all partitions (you can even boot off it). We can use anyone's partitioning program to partition a drive, regardless of controller/driver. Since we can use direct SCSI commands, partitioning programs can use MODE_SENSE, INQUIRY, READ_CAPACITY, etc to get all the info needed to set up the drive. >2) There is no standard way for a DMA-based SCSI controller to deal with > the '386 or '486 CPU's, which make a habit of changing memory maps > on the fly. This requires some OS support I suspect - for example, a VirtualToPhysical(addr,&length) that returns the physical address for DMA, and modifies length (if needed) to avoid any discontinuities. Almost all controllers on the Amiga are DMA. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
howardm@Neon.Stanford.EDU (Howard A. Miller) (03/19/90)
SCSI is late in coming to the IBM PC world. If the on controller BIOS is properly written, then there should be no problems using SCSI decives under DOS. For SCO Unix, the drivers must be properly written. From my "real" job it appears as if Adaptec is leading the way in making the standards fot the IBM PC environment. Also, Everex systems seems to have a few devices/controllers/BIOS which seems to work.