Technical Note HW540

SCSI Port Q&As

CONTENTS Downloadables

This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site. [Oct 01 1990]

Macintosh Quadra 700 and 900 SCSI chip anomaly and fix

Date Written: 1/25/93

Last reviewed: 4/1/93

Once a while, my optical driver's Test Unit Ready command, which goes through the SCSI Manager, returns 0 on status byte but 2 on message byte, which is weird because there's no cartridge inserted. Is something wrong with the SCSI Manager?

A problem has recently been found with the SCSI chip on the Macintosh Quadra 700 and 900. In a nutshell, the National 53c96 chips that are used in the these models do something that the SCSI Manager doesn't expect (they sometimes hold onto a byte in the chip's on-board FIFO). Because of this, in certain cases, instead of the SCSI Manager retrieving the Status and Message bytes from the drive it just posted a command to, it gets the stuck byte as the Status byte, and the Message byte as the Status byte.

The end result is some peculiarities. For instance, users report that they can't get a CD-ROM drive to work with Macintosh Quadra 900s. Also, periodically users get "can't read such and such drive" messages on the desktop.

This may occur with a CD-ROM device (and most likely, with any removable-media device such as SyQuests). The reason is that, since these devices may or may not have media inserted, the drivers for these devices typically poll devices that don't have media inserted, looking for newly inserted media. Often, they do this by issuing a TestUnitReady SCSI command to the device. If the device returns a 0, which indicates NO ERROR, then it's assumed that some sort of media is inserted into the drive and the driver then tries to mount the newly mounted media.

Let's look at this in detail. Here's the command that's sent to the CD-ROM drive:

  0, 0, 0, 0, 0, 0
  |  |  |  |  |  |
  |  |  |  |  |  -  Linked command byte: On Macintosh systems, always 0
  |  |  |  |  -  -  Reserved
  |  |  |  -  -  -  Reserved
  |  |  -  -  -  -  Reserved
  |  -  -  -  -  -  Logical unit number (usually 0)
  -  -  -  -  -  -  SCSI command: TestUnitReady

The last byte (SCSI command such as Linked) is always 0. This is the byte that sticks in the FIFO of the c96, such that when you read the Status and Message bytes back, you get a 0 back as the Status byte, and a "Not Ready" (2) in the Message byte.

Unfortunately, 0 is the value returned to the driver, which says "Oh boy! The drive has some media in it and it's ready to be mounted!" The driver proceeds to issue (in the case of the CD-ROM) a _PostEvent that then causes other _Read trap calls and such, all of which fail, and you end up with the Uninitialized Disk dialog box.

Apple has figured out a SCSI Manager fix for this problem and the fix will be released in an upcoming System Disk release.

As a workaround, try doing a retry and see if the problem still occurs with System 7.1.

Macintosh Quadra SCSI data transfer

Date Written: 1/15/92

Last reviewed: 2/6/92

My application has problems with Macintosh Quadra SCSI data transfer. I think it depends on the SCSI-chip installed in the machine. Is there a Gestalt definition for the SCSI-chip installed?

You need to examine the 6th, 7th, and 21st bits of the gestaltHardwareAttr selector. To investigate hardware-dependent bit values, use the Gestalt DA, which you'll find on the latest Developer CD Series disc.

Make sure your software doesn't read or write to SCSI hardware directly. For example, the Quadra utilizes the 53C96, so it won't correctly interpret or queue a SCSIstat call. With the 53C96, you don't have access to the state of the SCSI bus lines. In implementation, the 53C96 is more abstract then the 53C80; software no longer has the same access to the physical layers of the chip's instruction set. Your software development should allow the SCSI Manager to handle the 53C96 chip/software interaction.

X-Ref:

"gestaltHardwareAttr hasSCSI selector" Q&A

gestaltHardwareAttr hasSCSI selector

Last reviewed: 1/27/92 Why does the gestaltHardwareAttr selector on the Macintosh IIfx return a selector indicating no SCSI available?

Labelling bit 7 of the response to the gestaltHardwareAttr selector "hasSCSI" is a bit misleading. gestaltHardwareAttr is supplying information about the very low-level hardware implementation. What bit 7 signifies is the presence of a standard 53C80 SCSI chip (the kind in use from the Macintosh Plus up to the IIfx). The IIfx has a different implementation of the 53C80 that allows for SCSI DMA, hence a different bit is used. The new Quadras have yet another chip, the 53C96, so different bits are used for those, as well.

The reason this is not more clearly documented is that it is very rare for applications to need this level of detail. Depending on such information virtually guarantees your application will be hardware dependent and so, incompatible in the future.

Here are the latest, official gestaltHardwareAttr flags from MPW 3.2.1. Any other flags remain undocumented.

gestaltHardwareAttr = 'hdwr';    { hardware attributes }
gestaltHasVIA1 = 0;              { VIA1 exists }
gestaltHasVIA2 = 1;              { VIA2 exists }
gestaltHasASC = 3;               { Apple Sound Chip exists }
gestaltHasSCC = 4;               { SCC exists }
gestaltHasSCSIDMA = 6;           {SCSI on the IIfx}
gestaltHasSCSI = 7;              { SCSI exists }
gestaltHasSWIMIOP = 8;           { SWIM IOP on IIfx }
gestaltHasSCCIOP = 9;            { SCC IOP on IIfx and Quadra 900 }
gestaltHasSCSI961 = 21;          { 53C96 SCSI controller on internal bus }
gestaltHasSCSI962 = 22;          { 53C96 SCSI controller on external bus }
gestaltHasUniversalROM = 24;     { Do we have a Universal ROM?}

You can use the GestaltDA in the Tools&Apps:OS/Toolbox folder on the latest Developer CD Series disc to see gestaltHardwareAttr and other Gestalt values.

Use Macintosh SCSI Manager for SCSI chip compatibility

Date Written: 10/22/91

Last reviewed: 10/22/91

Our SCSI driver asserts the SCSI bus protocol directly, according to the SCSI bus specs, using the low-memory global SCSIBase as the SCSI base address. Our code works fine on systems using the NCR 5380, but hangs with the new SCSI NCR 53C96. Do I need to add a NOP somewhere because the new chip is faster?

Although SCSIBase is exactly where a SCSI device driver should look to find the base address of a SCSI chip in the Macintosh, the NCR 53C96 is a physically different chip then the NCR 5380. Besides having its registers in different locations of the address map and a slightly different register set, the chip takes on much more of the burden (and control) of accessing the SCSI bus. The major difference is that with the 5380, the chip controller (drvr) needs to actively respond to the phases of the SCSI bus as the target changes them and to be ready to correctly react to any unexpected changes in state. For continued compatibility with the Macintosh product lines, your driver must use the SCSI Manager rather than to write directly to the chip. With the new chip (5396) the chip controller needs to set up all information for the entire command sequence (Arbitration thru Message In) and then tell the chip to execute it. The "controller" is not in direct control of the SCSI bus. (With the earlier chip, it's really the Target that's always in control, not your driver, but the 5380's interaction model gives the IMPRESSION that your driver is in control.)

Your best course of action is to make sure your SCSI driver uses the SCSI Manager so that you will automatically work on all Macintosh platforms in the event that Apple changes chips in the future. If there is something odd about your SCSI device that it just cannot be accommodated by the SCSI Manager (this is rare!) then you will need to get the documentation for the NCR 5396 (from NCR) and rewrite your driver to use this new "setup and go" interaction model.

Apple SCSI cable information

Date Written: 9/17/91

Last reviewed: 9/17/91

Where can we get specs for Apple's SCSI cables, similar to Apple's paint and finish standard, which allows us to match our hardware exactly to the Macintosh family? SCSI details we are concerned with are: single versus double shielding, contact types (such as gold), wire gage, and color.

The information you've requested is unavailable for distribution. Apple simply doesn't supply specifications for any of its hardware to outside parties. However, you might try looking at the following SCSI specifications for more information:

Specification:                         Available from:
_____________                          ______________

SCSI-1: ANSI X3.131-1986               American National Standards Institute
        ISO DP 9316                    1430 Broadway
        ECMA-111                       New York, NY  10018

CCS: X359.2/85-52,1986 (Rev 4.B)       American National Standards Institute
     (Common Command Set)              1430 Broadway
                                       New York, NY  10018

SCSI-2: ANSI X3.131-1990               Global Engineering Documents
(Revision 10c)                         2805 McGaw
                                       Irvine, CA  92714
                                       Tel: (800) 854-7179 or (714) 261-1455

These specifications discuss SCSI interface and, although they don't tell you exactly how to build a SCSI cable, they give you a good benchmark for engineering one. Both of the above specs are available from:

Another alternative is to go out and buy one of Apple's cables and reverse engineer it. Your local dealer might be the best location for this.

Currently A/UX is only OS to use Macintosh IIfx SCSI DMA chip

Date Written: 8/15/91

Last reviewed: 8/15/91

Does System 6.0.7 or 7.0 make use of the DMA portion of the Macintosh IIfx hardware?

System 7.0, or any version of the Macintosh operating system at this point, does not utilize the SCSI DMA chip in the Macintosh IIfx. A/UX is the only operating system on the Macintosh that does use this chip.

Transferring data from SCSI device to Macintosh

Date Written: 8/30/91

Last reviewed: 6/14/93 How can an external SCSI device interrupt the Macintosh system CPU? What's the procedure for transferring data from my external SCSI device's buffer to system RAM?

Transferring data from a SCSI device to a Macintosh is not a simple task. The Macintosh SCSI implementation does not support arbitration, so only the Macintosh can start a SCSI transaction. If someone else were to begin transferring data on the bus, and the Macintosh wanted to begin a transfer, it would not know how to deal with the situation.

This rules out your SCSI device being able to decide to send data to the Macintosh. The only way to accomplish what you need to do is to write a VBL or Time Manager task that periodically checks your device to see if it needs to be serviced, and if so, initiates a SCSI transfer to get the data from it. While this approach requires somewhat more care, because of its granularity, it should prove adequate.

Using Macintosh SCSI Manager for direct disk access

Date Written: 5/7/91

Last reviewed: 7/25/91 I would like to read and write sectors directly on a SCSI disk. Do I need to access the SCSI chip directly or can I use the SCSI Manager for this?

The normal way to access a SCSI disk is to use the Macintoshreg. file system, which calls the SCSI Manager to access the SCSI bus and command the hard disk to read or write data in various blocks. You should be able to directly command the hard disk yourself and directly send and receive the sector buffers by calling the SCSI Manager to perform the SCSI communication for you.

Pseudo code to perform this kind of transaction would be:

* Prepare a command block for read or write, etc.

* Prepare your data buffer and a transfer instruction block (tib) containing instructions for data transfer. For example, a tib for transferring six 512-byte blocks of data from or to address $67B50 contains the following:

        SCINC     $67B50    512
        SCLOOP    -10       6
        SCSTOP

• Call SCSIGet() to gain control of the buss
• Call SCSISelect(TargetId) to select the target device (your hard drive) and allow the target to command the bus.
• Call SCSICmd(CommandBlock,Length) to give the SCSI Manager the command you want it to transfer when the target requests the command.
• Call SCSIRead(tib) (or SCSIWrite) to tell the SCSI Manager where to put the bytes (or where to get them from on a write) when the target requests them.
• Call SCSIComplete(Status, message) to finish the transaction and receive the (potential) error code.

If what you intended to ask was how to write your own SCSI hardware driver, be aware that this is not an area that DTS normally supports. If you are developing for a unique SCSI device that cannot be interfaced to using the provided SCSI Manager, please let DTS know the details about your device and the problems you are encountering that will not allow its control via the SCSI Manager. Also, please note that the specific SCSI chip used in a specific Macintosh model may change in some future Macintosh model and will break your custom driver, requiring you to rev your driver if you want to continue to be compatible. For this reason we strongly suggest that you use the provided SCSIManager if at all possible.

Connecting two Macintosh systems via SCSI

Last reviewed: 7/26/91 How can I connect two Macintosh systems together using the SCSI port so they can run in parallel?

For many reasons, connecting any two systems via SCSI port to SCSI port should not be attempted. The most important reason is that you would then have two devices (the CPUs, and probably the internal drive) on the bus with the same SCSI ID. Further, a straight-through cable would connect outputs to outputs and inputs to inputs, which would bring communications to a halt.

However, a SCSI-to-SCSI connection, like the type mentioned below, is possible between the Macintosh Portable and a desktop Macintosh using LapLink Macintosh III from Traveling Software. It works only on the Macintosh Portable since the SCSI ID of the Macintosh Portable can be changed from 7 to 6, avoiding the ID conflicts. Traveling Software also provides a special SCSI-SCSI cable, which is required for this connection. (This setup cannot connect two desktop Macintosh systems unless the drive ID can be changed. This is not possible with Apple's internal drives but you may be able to do it with other internals. In any case, this is unsupported, so if you attempt this you do so at your own risk. You probably will void your warranty.)

LapLink Macintosh III
Traveling Software, Inc.
18702 North Creek Parkwaybr
Bothell, WA 98011
206-483-8088

Cannot make SCSI inquiries of CPU

Last reviewed: 1/16/91 Is there a way to get the SCSI information for the CPU (ID 7) using a SCSI call?

No, sorry. The SCSI protocol says that there is a SCSI bus Master and a SCSI target, and that the two will not be the same. Since the Macintosh is always the master, there is no way you can make inquiries of it.

SCSI/NuBus card development tools and resources

Last reviewed: 8/30/91 Are there any new tools or resources for developing a SCSI/NuBus card? None of the slot tools available on AppleLink have been updated since September 1989.

We recommend you look at the application named Slots, on the latest Developer CD Series disc. It allows you to look at declaration ROM sResources and make your own calls to the Slot Manager. It was written in 1990 by an engineer working on the Slot Manager.

Macintosh IIci SCSI power connector changes

Date Written: 1/1/91

Last reviewed: 1/1/91

What changes are there to the Macintosh IIci SCSI power connector?

The IIci SCSI power connector is supplied by Molex. It is plug housing part number 39-01-2040 with four crimp pins (part number 39-00-0039) per housing needed. You can contact Molex sales representatives Dave Rios in San Jose, CA (408-946-4700) or Randy Kempf in Lisle, IL (312-969-4550) for these parts.

Figure as seen looking down at the IIci logic board:

      +----------+      1  +12V
      |  3    1  |      2  ground
      |          |      3  ground
      |  4    2  |      4  +5V
      +----------+

Can I have a device powered off and connected to the SCSI bus?

Last reviewed: 11/19/90 Can I have a device powered off and connected to the SCSI bus?

The SCSI specification does not define how a device is to behave while powered off. The best advice and the official line from Apple is not to have devices on the bus and powered off. It's been found that having devices powered off and on the bus causes degradation to performance and the signals. This is the issue: electrical problems of termination and termination power. Some devices are NOT following the description of how Apple's devices work, and following the guidelines of the Apple cable guide does not apply with non-Apple devices. The termination problem can cause hardware damage. Therefore, the rule is this: Do NOT have devices connected to the bus with their power off. Also, do not power on a device connected to the bus after booting and never connect one while the system is on.

Macintosh Quadra and SCSI termination

Date Written: 11/27/91

Last reviewed: 11/27/91

Proper SCSI termination is critical for correct operation of the Macintosh Quadra computers, just as with all Macintosh computers. The Macintosh Quadra computers require external SCSI termination at the end of the device chain, either supplied by the last device in the chain, or using a standard Apple SCSI Cable Terminator (M0332LL/A). Note that this is the standard SCSI terminator, NOT the black terminator required by the Macintosh IIfx (although the black IIfx terminator may be used as well).

Termination is generally supplied at the factory for use with internal SCSI devices. Some early floppy-only Macintosh Quadra 700 units may not have internal termination, so users who attach external SCSI devices (without having added an internal SCSI device) may need to double terminate their external SCSI chain. Properly terminated floppy-only Macintosh Quadra 700 units will have a terminator inserted into the motherboard internal SCSI cable connector. Users of internal SCSI devices must, of course, remove this terminator before connecting their internal SCSI device.

The Macintosh Quadra 900 is the first Macintosh computer to provide a separate, internal SCSI bus. This bus is physically isolated from the external SCSI bus and must also be properly terminated. The cable provided with the machine includes all the termination necessary, so ALL internal devices must have SCSI termination removed before connecting to the internal Macintosh Quadra 900 SCSI cable. If extra termination is supplied it may cause intermittent hardware failures as well as physical damage to the device.

Developers who ship terminated SCSI devices for possible internal use in the Macintosh Quadra 900 must provide users with instructions for removing the termination.

Back to top

Downloadables

Back to top