3.      SCSI and PC's

        PC-specific SCSI standards include mostly software depending on
        the operating system. However, if you choose SCSI for your PC,
        think about your needs before buying a SCSI host adapter.

3.1.    Software Interfaces

        Besides various vendor-specific implementations like, for
        example, Bernoullis OAD (Open Architecture Drivers) there are
        a few vendor-independent standards:

        - ASPI for DOS, OS/2 and Netware
        - CAM/SCAM for DOS (and OS/2 ?)
        - LADDR for OS/2 1.x

3.1.1.  ASPI

        ASPI stands for Advanced SCSI Programming Interface. Mainly, it
        originated at Adaptec and was soon adopted by major companies.
        ASPI provides a communication layer to the SCSI adapter and the
        devices without the need to know about the host adapter - all
        communication is made to the ASPI interface. So, basically the
        host adapter manufacturer writes an ASPI driver for his host
        adapter and he's in business without the need of writing a new
        CDROM driver, a disk driver and so on.
        Most actual tape backup software needs ASPI as a communication
        layer or - at least - support it.
        ASPI generally exists for DOS, OS/2 and NetWare. Also, Adaptec
        supplies ASPI for Windows with their host adapters, and ASPI for
        Win32 should follow soon. I could see ASPI for Windows support
        only with Adaptec controllers, but other manufacturers should
        (hopefully) follow soon. What's missing (imho) is an ASPI layer
        for Unix... But this seems not so easy with Unix's kernel/driver
        concept.

3.1.2.  CAM

        CAM is the "official" ANSI software interface for SCSI devices.
        I'm not absolutely sure if it's a draft or a standard yet.
        However, it seems to be used only by NCR and Future Domain with
        their SCSI host adapters, and at least FD supplies an additional
        ASPI-over-CAM driver with their boards.

3.1.3.  SDMS

        NCR now calls its CAM drivers NCR SCSI Device Management System
        (SDMS). SDMS is based on a standard SCSI BIOS, that can be ROM-
        (bootable) or RAM-based (non-bootable) to address the host
        adapter hardware. The SCSI drivers link to this BIOS. Generally,
        a SDMS driver is completely hardware-independant. One special
        case with SDMS is that NCR also offers so-called "concatenated"
        SCSI device drivers, where a SCSI-chip specific SCSI BIOS is
        appended to the driver code.
        See also - CAM drivers for DOS

3.1.4.  LADDR

        LADDR (LAyered Device DRiver) was Microsoft and IBM's (and
        others like Adaptec and Compaq...) approach to embed a disk
        driver and SCSI interface into OS/2 1.2 and 1.3. For OS/2
        1.x's small market share and LADDR's limitation to a single
        OS, it didn't get bigger acceptance and has been replaced by
        direct SCSI support beginning with OS/2, version 2.0.
        The concept wasn't bad, however. LADDR support was built in
        OS/2 1.3 (and it was possible to integrate it in 1.2).
        If you look at the actual driver concept in OS/2 2.x, you will
        see that it isn't much different - mostly just names changed.
        A concept diagram would look like this:

        Ŀ
         OS/2 File System 
        
         Ŀ Ŀ Ŀ
                    
         TSD-VSD-BID-Ŀ
                               
                      
                                  
           Ŀ      Ŀ
               IOS                         
        Ŀ   Host Adapter  
           OS/2  LADDR                     
           

        Module types are:

        BID - Bus Interface Driver, the host adapter specific driver

        VSD - Vendor Specific Driver, drivers to modify or enhance the
              operation of specific peripherals. VSD's were used to add
              features or correct incompatibilities with devices.

        TSD - Type Specific Driver, the driver for a specific type of
              peripheral, for example CDROM drives

        The drivers were:

        - BASEDD01.SYS, IOS12.sys, IOCONFIG.SYS, all from Microsoft, for
          implementing LADDR.

        - a host adapter .BID file, for example WD7000AX.BID. Some of
          these came with OS/2, others were available from the host
          adapter vendors.

        - STDDISK.VSD and DISK.TSD, both from Microsoft, for disk
          integration.

        - CDROM.VSD, CDROM.TSD and CDROM.FSD, all from Microsoft, for
          CDROM operation.

        - correct .VSD and .TSD modules for addressing tape devices or
          other SCSI devices.

3.2.    Host Adapters - Variants and Terminology

        There are some flavors of SCSI host adapters; with and without
        BIOS, with or without cache, ISA 8 Bit or 16 Bit, EISA, VL and
        PCI bus interfaces, SCSI-IDE combo adapters, standalone or
        integrated with sound cards, disk-only adapters, and, and ....
        Let's try to bring some light in here ...

3.2.1.  BIOS: If you want to boot from a SCSI device, you need a SCSI
        BIOS, that handles the boot process, for a standard PC BIOS
        doesn't know anything about SCSI. The SCSI BIOS handles the
        translation between SCSI's Logical Block addressing scheme
        and the PC's Cylinder/Head/Sector scheme.
        There is a small point for potential trouble here - there
        isn't a common translation scheme, only an approximation....
        Adaptec normally uses a translation scheme with 64 heads and
        32 sectors, what gives roughly about 1 MByte per emulated
        cylinder. However, to overcome DOS's 1024 cylinder limit, a
        different translation scheme is neccessary for disk with over
        1 GByte. Again, Adaptec uses a scheme with 255 heads and 63
        sectors, setting the emulated cylinder size to 8 MBytes.
        Keep in mind that DOS has an inherent disk size limit of
        8.4 GBytes, calculated from 512 Byte sector size, 63 sectors
        per track, 1024 cylinders and 256 heads (= 8.455.716.864 Bytes).

        Some motherboards (mostly PCI) and notebooks with a SCSI upgrade
        option have the SCSI BIOS already, so that it is much easier to
        integrate a specific SCSI adapter.
        -- See also the Bus/PCI paragraph 3.2.6. below --

3.2.2.  Bus mastering: Some PC host adapters use "DMA Bus mastering" to
        achieve higher data rates from the SCSI host adapter's buffer to
        system memory.  Bus mastering is a method to move data over the
        system bus directly to memory by bypassing the CPU and giving
        control over the bus and memory interface to the peripheral
        controller, so that the bus can be used up to its maximal data
        rate without the CPU overhead of a 'normal' I/O transfer.
        On ISA PCs, don't forget that ISA doesn't have logic to prevent
        concurrent bus master accesses, so having - for example - an
        Adaptec 1542 and a busmastering network adapter like the NE2100
        can (and mostly will) give you sudden lockups and other trouble.
        Identical busmaster adapters normally don't have this problem,
        as the manufacturer mostly keeps an eye on this for their own
        adapter coexistence. Two 1540 host adapters, for example, aren't
        a problem.
        Also, remember that an ISA card can "see" only 16MB RAM on the
        bus, so, with a busmastering ISA adapter and more than 16MB
        RAM, you also _may_ have trouble. All this, together with the
        speed considerations, are strong points for EISA, VL and PCI
        bus systems.
        Bus mastering adapters profit from an additional concept called
        Scatter/Gather. For the requested transfer locations in the host
        systems memory and on the disk aren't neccessarily contiguous,
        the adapter might have to transfer lots of small, "scattered"
        data blocks. A scatter/gather table keeps track about all these
        transfer locations and allows the SCSI driver to transfer these
        pieces in a single transfer process to or from the device.

3.2.3.  Cache host adapters: a hardware cache is a good method to speed
        up the disk interface. However, you should define if your
        environment can benefit from a hardware cache _before_ buying it.
        The pro-cache and the anti-cache societies fight "holy" wars
        about cacheing, so please allow me to clarify that the following
        is my _personal_ opinion on this theme:

        A cache controller is a good investment for multitasking environ-
        ments like Unix and especially Network servers. With DOS, it's
        generally better to spend the money for main RAM than for cache
        RAM and use a software cache.
        My personal experiences are that various DPT and AMI EISA SCSI
        adapters in Novell and NFS Servers brought _big_ performance
        gains, especially with heavy-loaded servers.
        In DOS systems, a performance gain was visible, and the various
        benchmark programs screamed, but in real work situations this
        didn't equalize the price tag, especially with the expensive
        EISA cache controllers. However, this may differ with different
        cache controllers, as the possible performance gain is strongly
        dependent on the cache algorithm.

3.2.4.  Sound cards with SCSI: There are basically two types of them:
        one has a full-fledged SCSI adapter integrated on the PCB,
        without any difference to a standard SCSI host adapter without
        BIOS. One example for this type is the SoundBlaster 16/SCSI,
        with an Adaptec SCSI chip on the board. The other variant I
        know about is the ProAudio Spectrum with a SCSI interface,
        that's "embedded" into the sound card ports.
        The PAS type is limited in speed, but not in SCSI functionality.
        If you get standard drivers for them, they all give you full
        SCSI capabilities, but you can't boot from them. If you want to
        boot from a SCSI disk, you need a full-fledged SCSI adapter with
        BIOS. Relatively new in the market is Adaptec's SCSI Audio
        Machine AMM 1570.
        It combines a sound card and a full-featured host adapter with
        SCSI BIOS. Its sound part implements General MIDI, but i wasn't
        impressed by its sound quality compared with my PAS and
        especially the TurtleBeach boards. The SCSI part seems a bit
        slow compared with a standard SCSI adapter and i don't like that
        it still needs jumpers. To me, it seems a bit too expensive with
        a list price of about $500 here in Germany - i could get a
        1542CF kit and a SoundBlaster 16 for the same price..
        However, it's a full-featured and bootable SCSI host adapter
        and sound board in one package. For the idea seems not too bad,
        it might get competitors soon.

3.2.5.  Disk-only SCSI host adapters: Mostly the Seagate ST-01 and ST-02.
        These adapters had their time when SCSI was a new disk interface.
        As they could be used only for disks and didn't have standard
        drivers for ASPI or CAM, they soon became obsolete.
        I saw a few of those used as controllers for Syquest removeable
        disk drives, but there seem to be no generic drivers like ASPI
        or CAM - in case you have one, the latest BIOS and installation
        information are available on Seagate's BBS (see Appendix B).

3.2.6.  ISA, EISA, VL and PCI: clearly the PC bus affect system
        performance. As for example the Adaptec 1542 supports DMA bus
        mastering speeds up to 10 MByte/sec, it would be fast enough
        for Fast SCSI-2. However, most ISA designs support only 5MB/sec
        DMA speed, so the ISA bus is a bottleneck with fast SCSI devices.
        EISA busmasters can transfer up to 33MBytes/sec over the bus, so
        in this case you really can benefit from faster devices, as the
        bottleneck is the device or the SCSI bus here.
        The same is true for VL and PCI SCSI host adapters. Also, if
        you want to have more than 16MB of RAM, you bypass some
        potential problems with the more advanced bus systems. (see
        also 3.2.2. - Bus mastering)

        PCI boards have a speciality: Normally the SCSI BIOS is part of
        the SCSI adapter, but there are PCI boards with SDMS (NCR SCSI
        Device Management System) support in the BIOS, but without SCSI
        chip. So, for these boards, you can get cheap PCI SCSI adapters
        without BIOS, only with the NCR 53C810 chip on it, but never-
        theless bootable from a SCSI disk. So, with a PCI board, the
        best choice seems to be one with the SCSI chip on it. It is
        cheap, and, if performance or driver compatibility isn't what
        you expect, you can add a different SCSI card any time.

3.2.7.  PCMCIA and Parallel-to-SCSI adapters: I have very limited
        experience with both of these; Personally I use a Trantor
        T348, at the office there are some different parallel-to-SCSI
        devices. All of them work and all share the same experiences.
        My Trantor T348 seems to be a stable and - if the parallel
        port allows it - fast SCSI interface. A friend of mine uses
        this T348 for backing up his notebook to a DAT tape and this
        works without flaws.
        However, the T348 and its pre- and successors T338 and T358
        (an EPP variant of the T348) need a SCSI device that provides
        termination power, as they draw their operating current from
        the SCSI bus. This may give you problems, as normally I disable
        termination power on my external devices, for only one device
        on the bus (normally the host adapter) should provide TP.
        Keeping this in mind and acting accordingly, Parallel-to-SCSI
        adapters seem to be a possible solution for attaching SCSI
        devices to a system without a SCSI adapter, but they are limited
        in speed, especially with parallel ports that work only uni-
        directional.
        PCMCIA - I never used a PCMCIA SCSI adapter, so I can't comment
        on them. However, with the full PCMCIA driver set on my Toshiba
        needing about 130 kB of memory, plus the SCSI drivers, I can't
        take PCMCIA too serious with DOS, especially when working with
        SCSI or network drivers. OS/2 should solve this problem, though,
        as memory isn't a primary concern there, and PCMCIA SCSI host
        adapters are reportedly significant faster than EPP-based ones.

3.3.    SCSI or IDE/ATAPI ?

        Much is talked about SCSI speed higher or lower than ESDI
        or ATAPI. This discussion generally only covers disk drives,
        without comparing overall performance or flexibility.

        At work, over years I've tested a lot of disk drives with
        ATAPI and SCSI versions against each other, and generally,
        you won't find much difference in speed between the various
        interfaces, as they all are fast enough to handle disk drives.
        Also, I've seen a lot of comparisons where the contenders were
        choosen according to the opinion they should prove.
        Personally, I find it of more interest that "standard" SCSI,
        as a universal 8-bit interface, can reach the speed of a 16-bit
        interface like ATAPI without problems. Wide SCSI has more
        potential than ATAPI here, but is hard to compare with ATAPI,
        as you will not easy find similar devices in ATAPI and Wide
        SCSI. For both interfaces deliver similar speed, I believe the
        "SCSI is faster/better" - "No! ATAPI/EIDE is faster/better"
        debate completely misses the point.
        If just a disk interface is needed for a desktop PC, IDE/ATAPI
        is significantly cheaper, mainly for it's mass production and
        the cheaper adapters.
        If it comes to multiple devices as CDROM, tapes or scanners,
        this changes. SCSI is _very_ flexible here, and today, drivers
        are not the problem they were in the past. Also, the ongoing
        SCSI integration in motherboards will drop SCSI cost.
        So, the battle is still open <g>.
        Skip Lutz says the battle is long over and the SCSI Warriors
        are running around stabbing the wounded, so you decide which
        way it went. <VBG>

        One additional key point here is portability. IDE/ATAPI is a
        technology that is used mainly in the IBM line of PCs. If you
        have other systems, you may not have a choice but SCSI.

        The same occurs on Enhanced IDE, of course, although with its
        additional CDROM and potential Tape support, it should be
        suitable for most SoHo PCs. Actually, in a bit practical work
        with EIDE devices, it seems that compatibility issues are even
        worse than with 'standard' IDE devices - two competing Fast-IDE
        variants, device drivers, BIOS incompatibilities and all that
        stuff. This should change over time, but at the moment, if you
        want to use EIDE to its full potential, choose your parts
        carefully and, before buying, insist on a return right, in case
        it gives you trouble.

        (For the EIDE hardliners - don't get me wrong; i don't want to
        take EIDE down, but at the moment, it seems to me it's not
        really mature technology.)

        -- see also chapter 8 for ATA/EATA

3.4.    Speed considerations

        A small maximal speed table for the SCSI transfer modes could
        read like this:

        Transfer type           Bits    Speed/Data rate

        Asynchronous             8       3.3 MBytes/sec **
        Synchronous              8       5.0 MBytes/sec
        Fast Synchronous         8      10.0 MBytes/sec
        Wide Synchronous        16      10.0 MBytes/sec
        Fast Wide Synchronous   16      20.0 MBytes/sec
        UltraSCSI Synchronous    8      20.0 MBytes/sec
        UltraSCSI Synchronous   16      40.0 MBytes/sec
        Wide Synchronous        32      20.0 MBytes/sec
        Fast Wide Synchronous   32      40.0 MBytes/sec

        to compare:
        EIDE (fastest DMA-Mode) 16      16.6 MBytes/sec

        When reading things like "data rate buffer-to-bus 10 MB/sec"
        with SCSI devices, keep in mind that this doesn't mean the real
        sustained data rate your hard disk or CDROM can deliver - it's
        just the speed the device can post its cache contents to the
        SCSI bus. With hard disks, you will mostly find statements like
        "internal data rate 30-47 MBit/s", what would mean in this
        example, the disk drive could transfer 5,875 MBytes/sec raw data
        internal. But this value cannot be reached - you'll loose some
        speed due to the disk architecture: If you have a disk drive with
        60 sectors per track and 5400 rpm, the value could be not better
        than:  ( sectors * bytes/sector * rpm ) / seconds per minute,
                  (60    *   512        * 5400) / 60   = 2,765 MBytes/sec
        Add to this some command overhead, head movement times and so on,
        then you get an impression, how realistic these values are ...
        Another good example are CDROM drives - my Toshiba 3401 has
        330 kB/sec sustained data rate, but its burst data rate can go
        up to 4.2 MB/sec in synchronous mode.
        No one expects 4.2 MB/sec from a double-speed CDROM, i hope <g>.

        ** 3.3 MB/sec is sometimes mentions as a "standard" value for
        asynchronous transfers, but there is no real "official" transfer
        rate defined. As newer host adapters generally reduce command
        overhead, the transfer rates generally get nearer to the
        theoretical limits, also in asynchronous mode. Real-world
        asynchronous transfer rates are mostly around 1.5 to 2.5 MB/sec.

