Path: utzoo!attcan!uunet!fernwood!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.sys.mac.programmer
Subject: Re: SCSI help
Message-ID: <33595@cup.portal.com>
Date: 6 Sep 90 11:03:27 GMT
References: <1002@beguine.UUCP>
Organization: The Portal System (TM)
Lines: 105

Here are some examples of using the SCSI Manager.  None of them
do exactly what you want, but they will show you how things
work.

The first function writes a single block of data to the device.
The device is assumed to be a disk.  It is assumed that TARGET_ID
is defined as the SCSI ID of the device you wish to talk to.
There is minimal error handling.

int WriteBlock( long blockNumber, void * dataPtr )
{
	char cmd[6];
	SCSIInstr tib[2];
	int stat, mesg;
	int ret;
	
	cmd[0] = 10;
	cmd[1] = (blockNumber >> 16) & 0x1f;
	cmd[2] = blockNumber >> 8;
	cmd[3] = blockNumber;
	cmd[4] = 1;
	cmd[5] = 0;
	
	tib[0].scOpcode = scNoInc;
	tib[0].scParam1 = (long)dataPtr;
	tib[0].scParam2 = 512;
	tib[1].scOpcode = scStop;
	
	if ( SCSIGet() )
		return -1;
	if ( SCSISelect( TARGET_ID ) )
		return -1;
	if ( SCSICmd( cmd, 6 ) )
		return -1;
	ret = 0;
	if ( SCSIWrite( tib ) )
		ret = -1;
	if ( SCSIComplete( &stat, &mesg, 10L ) )
		return -1;
	return ret;
}


The above was for a simple program that just need infrequent access
to the SCSI device.  For something whose needs are more I/O intense,
use a TIB like this:

	SCSIInstr tib[3] = {
		{ scInc, BufPtr, 512 },
		{ scLoop,-10L, BlkCount },
		{ scStop, 0L, 0L }
	};

where BufPtr is a pointer to the data buffer, and BlkCount is how many
block of data will be transfered.  Then use SCSIRBlind or SCSIWBlind
instead of SCSIRead or SCSIWrite.

The reason for the loop form of the TIB is that the SCSI Manager will
synchronize with the SCSI device each time the scInc instruction is
executed.  This minimizes the chance of blind mode causing a problem
on a Mac plus (burbles in the transfer from the device are likely to
happen only at block boundaries).

The ANSI SCSI spec is close to useless.  Nearly everything useful is
optional and vendor unique.  Most of the vendors have settled on a
common form for many of these optional commands, so if you get a
manual for a reasonable device, you will have enough information
to deal with most devices of that type.

The manuals for Quantum drives are excellent.  They include enough
about SCSI in general so that you can get everything about SCSI you
would need from the ANSI spec, and since Quantum implements all the
things common to most drives, the Quantum manual contains almost all
you will need to talk to nearly any drive.

The spec for the ANSI SCSI-2 standard has standardized all these option
things, so it would be good reading.  You can get more information on
this by calling the SCSI BBS with your modem.

The number for the SCSI BBS is:

	316-636-8700

The SCSI BBS has a copy of the SCSI-2 spec online.  If you can deal
with IBM PC files, there is a ZIPed copy that is 300K.  It's in
WordStar format.  There are programs available that turn WordStar
files into ASCII files.  There is one on the SCSI BBS, but it sucks.

A place called Global Engineering Documents, which is, I think,
in Aneheim, CA, sells this document for, I think $25.  You can
get their number from the SCSI BBS.  You can also get it from
ANSI, I think.

					Tim Smith

ps: if you ever start dealing with SCSI devices at a low level, be
aware that some of these have bugs.  For example, let's just say
that you wanted to play around with synchronous data transfer.
So you grab an Apple 40 meg hard disk that you happen to have
lying about and hook it up to a SCSI card that can support
synchronous.  You will be in for quite a surprise.  The Sony
40 meg drive that Apple uses has a screwed up implementation
of SCSI.  I mean, those guys at Sony just blew it.  It violates
the SCSI message protocol when you try to negotiate for synchronous
transfer.