SCSI Device - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:05:03Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:05, 26 January 2025
Line 60:		Line 60:
	To send SCSI-direct or other commands to the SCSI device, an extended I/O request structure named IOStdReq is used.		To send SCSI-direct or other commands to the SCSI device, an extended I/O request structure named IOStdReq is used.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct IOStdReq		struct IOStdReq
	{		{

Steven Solie: /* RigidDiskBlock – Fields and Implementation */

2015-10-02T18:39:17Z

RigidDiskBlock – Fields and Implementation

Steven Solie: /* Device Interface */

2012-05-22T20:59:35Z

Device Interface

← Older revision		Revision as of 20:59, 22 May 2012
Line 54:		Line 54:
	== Device Interface ==		== Device Interface ==

	The SCSI device operates like other Amiga devices. To use it, you must first open the SCSI device, then send I/O requests to it, and then close it when finished. See ~~the~~ [[~~Introduction~~ to ~~Amiga System Devices~~]] ~~chapter~~ for general information on device usage.		The SCSI device operates like other Amiga devices. To use it, you must first open the SCSI device, then send I/O requests to it, and then close it when finished. See [[Exec_Device_I/O\|Exec Device I/O]] for general information on device usage.

	The power of the SCSI device comes from its special facility for passing SCSI and SCSI-2 command blocks to any SCSI unit on the bus. This facility is commonly called ''SCSI-direct'' and it allows the Amiga to perform SCSI functions that are “non-standard” in terms of the normal Amiga I/O model.		The power of the SCSI device comes from its special facility for passing SCSI and SCSI-2 command blocks to any SCSI unit on the bus. This facility is commonly called ''SCSI-direct'' and it allows the Amiga to perform SCSI functions that are “non-standard” in terms of the normal Amiga I/O model.

Alexandre Balaban: Categorizing

2012-05-10T23:18:22Z

Categorizing

← Older revision		Revision as of 23:18, 10 May 2012
Line 1:		Line 1:
	{{NeedUpdate}}		[[Category:Devices\|SCSI]]{{NeedUpdate}}
	== SCSI Device ==		== SCSI Device ==

Alexandre Balaban: /* Device Interface */

2012-05-10T23:16:15Z

Device Interface

← Older revision		Revision as of 23:16, 10 May 2012
Line 54:		Line 54:
	== Device Interface ==		== Device Interface ==

	The SCSI device operates like other Amiga devices. To use it, you must first open the SCSI device, then send I/O requests to it, and then close it when finished. See the ~~“Introduction~~ to Amiga System ~~Devices”~~ chapter for general information on device usage.		The SCSI device operates like other Amiga devices. To use it, you must first open the SCSI device, then send I/O requests to it, and then close it when finished. See the [[Introduction to Amiga System Devices]] chapter for general information on device usage.

	The power of the SCSI device comes from its special facility for passing SCSI and SCSI-2 command blocks to any SCSI unit on the bus. This facility is commonly called ''SCSI-direct'' and it allows the Amiga to perform SCSI functions that are “non-standard” in terms of the normal Amiga I/O model.		The power of the SCSI device comes from its special facility for passing SCSI and SCSI-2 command blocks to any SCSI unit on the bus. This facility is commonly called ''SCSI-direct'' and it allows the Amiga to perform SCSI functions that are “non-standard” in terms of the normal Amiga I/O model.

Steven Solie: /* RigidDiskBlock – Fields and Implementation */

2012-05-09T16:29:05Z

RigidDiskBlock – Fields and Implementation

← Older revision		Revision as of 16:29, 9 May 2012
Line 282:		Line 282:
	The RDB scheme was designed to allow the automatic mounting of all partitions on a hard drive and subsequent booting from the highest priority partition even if it has a soft loaded filing system. Disks can be removed from one controller and plugged into another (supporting the RDB scheme) and will carry with it all the necessary information for mounting and booting with them.		The RDB scheme was designed to allow the automatic mounting of all partitions on a hard drive and subsequent booting from the highest priority partition even if it has a soft loaded filing system. Disks can be removed from one controller and plugged into another (supporting the RDB scheme) and will carry with it all the necessary information for mounting and booting with them.

	The preferred method of creating RigidDiskBlocks is with the ''HDToolBox'' program ~~supplied by Commodore~~. Most controllers include an RDB editor or utility.		The preferred method of creating RigidDiskBlocks is with the ''HDToolBox'' program. Most controllers include an RDB editor or utility.

	When a driver is initialized, it uses the information contained in the RDB to mount the required partitions and mark them as bootable if needed. The driver is also responsible for loading any filing systems that are required if they are not already available on the filesystem.resource list. Filesystems are added to the resource according to DosType and version number.		When a driver is initialized, it uses the information contained in the RDB to mount the required partitions and mark them as bootable if needed. The driver is also responsible for loading any filing systems that are required if they are not already available on the filesystem.resource list. Filesystems are added to the resource according to DosType and version number.
Line 380:		Line 380:
	#define RDBFB_CTRLRID 5 /* rdb_Controller... identification valid */		#define RDBFB_CTRLRID 5 /* rdb_Controller... identification valid */
	#define RDBFF_CTRLRID 0x20L		#define RDBFF_CTRLRID 0x20L
	/* added 7/20/89 ~~by commodore~~: */		/* added 7/20/89: */
	#define RDBFB_SYNCH 6 /* drive supports scsi synchronous mode */		#define RDBFB_SYNCH 6 /* drive supports scsi synchronous mode */
	#define RDBFF_SYNCH 0x40L /* CAN BE DANGEROUS TO USE IF IT DOESN'T! */		#define RDBFF_SYNCH 0x40L /* CAN BE DANGEROUS TO USE IF IT DOESN'T! */

Steven Solie: /* Amiga BootStrap */

2012-05-04T21:43:38Z

Amiga BootStrap

← Older revision		Revision as of 21:43, 4 May 2012
Line 514:		Line 514:

	<table>		<table>
	<thead>
	<tr class="header">		<tr class="header">
	<th align="right">Priority</th>		<th align="right">Priority</th>
	<th align="left">Drive</th>		<th align="left">Drive</th>
	</tr>		</tr>
	</thead>
	<tbody>
	<tr class="odd">		<tr class="odd">
	<td align="right">5</td>		<td align="right">5</td>
Line 537:		Line 534:
	<td align="left">df3:</td>		<td align="left">df3:</td>
	</tr>		</tr>
	</tbody>
	</table>		</table>

Steven Solie: /* SCSI-Direct */

2012-05-04T21:42:42Z

SCSI-Direct

← Older revision		Revision as of 21:42, 4 May 2012
Line 171:		Line 171:

	== SCSI-Direct ==		== SCSI-Direct ==



	SCSI-direct is the facility of the Amiga’s SCSI device interface that allows low-level SCSI commands to be passed directly to a SCSI unit on the bus. This makes it possible to support the special features of tape drives, hard disks and other SCSI equipment that do not fit into the Amiga’s normal I/O model. For example, with SCSI-direct, special commands can be sent to hard drives to modify various drive parameters that are normally inaccessible or which differ from drive to drive.		SCSI-direct is the facility of the Amiga’s SCSI device interface that allows low-level SCSI commands to be passed directly to a SCSI unit on the bus. This makes it possible to support the special features of tape drives, hard disks and other SCSI equipment that do not fit into the Amiga’s normal I/O model. For example, with SCSI-direct, special commands can be sent to hard drives to modify various drive parameters that are normally inaccessible or which differ from drive to drive.
Line 180:		Line 178:
	The SCSI device uses a special data structure for SCSI-direct commands named SCSICmd.		The SCSI device uses a special data structure for SCSI-direct commands named SCSICmd.

			<pre>

		⚫	struct SCSICmd

⚫	~~<pre>~~struct SCSICmd
	{		{
	UWORD scsi_Data; / word aligned data for SCSI Data Phase */		UWORD scsi_Data; / word aligned data for SCSI Data Phase */
Line 202:		Line 199:
	/* request w/ SCSIF_AUTOSENSE, must be 4..255 */		/* request w/ SCSIF_AUTOSENSE, must be 4..255 */
	UWORD scsi_SenseActual; /* amount actually fetched (0 means no sense) */		UWORD scsi_SenseActual; /* amount actually fetched (0 means no sense) */
	};~~</pre>~~		};
			</pre>

	See the include file devices/scsidisk.h for the complete structure definition.		See the include file devices/scsidisk.h for the complete structure definition.

		⚫	SCSICmd will contain the SCSI command and any associated data that you wish to pass to the SCSI unit. You set its fields to the values required by the unit and the command. When you have opened the SCSI device and set the SCSICmd to the proper values, you are ready for SCSI-direct.
	SCSICmd

⚫	will contain the SCSI command and any associated data that you wish to pass to the SCSI unit. You set its fields to the values required by the unit and the command. When you have opened the SCSI device and set the SCSICmd to the proper values, you are ready for SCSI-direct.

	You send a SCSI-direct command by passing an IOStdReq to the SCSI device with a pointer to the SCSICmd structure set in io_Data, the size of the SCSICmd structure set in io_Length and HD_SCSICMD set in io_Command.		You send a SCSI-direct command by passing an IOStdReq to the SCSI device with a pointer to the SCSICmd structure set in io_Data, the size of the SCSICmd structure set in io_Length and HD_SCSICMD set in io_Command.

			<pre>
	~~<pre>~~struct IOStdReq *SCSIreq = NULL;		struct IOStdReq *SCSIreq = NULL;
	struct SCSICmd Cmd; /* where the actual SCSI command goes */		struct SCSICmd Cmd; /* where the actual SCSI command goes */

Line 217:		Line 215:
	SCSIreq->io_Data = (APTR)&Cmd;		SCSIreq->io_Data = (APTR)&Cmd;
	SCSIreq->io_Command = HD_SCSICMD;		SCSIreq->io_Command = HD_SCSICMD;
	DoIO(SCSIreq);~~</pre>~~		DoIO(SCSIreq);
			</pre>

	The SCSICmd structure must be filled in prior to passing it to the SCSI unit. How it is filled in depends on the SCSI-direct being passed to the unit. Below is an example of setting up a SCSICmd structure for the MODE_SENSE SCSI-direct command.		The SCSICmd structure must be filled in prior to passing it to the SCSI unit. How it is filled in depends on the SCSI-direct being passed to the unit. Below is an example of setting up a SCSICmd structure for the MODE_SENSE SCSI-direct command.

			<pre>
	~~<pre>~~UBYTE buffer; / a data buffer used for mode sense data */		UBYTE buffer; / a data buffer used for mode sense data */
	UBYTE Sense[20]; /* buffer for request sense data */		UBYTE Sense[20]; /* buffer for request sense data */
	struct SCSICmd Cmd; /* where the actual SCSI command goes */		struct SCSICmd Cmd; /* where the actual SCSI command goes */
Line 234:		Line 235:
	Cmd.scsi_SenseActual = 0; /* how much has been received */		Cmd.scsi_SenseActual = 0; /* how much has been received */

	Cmd.scsi_Command=(UBYTE )ModeSense;/ issuing a MODE_SENSE command */~~</pre>~~		Cmd.scsi_Command=(UBYTE )ModeSense;/ issuing a MODE_SENSE command */
			</pre>

	The fields of the SCSICmd are:		The fields of the SCSICmd are:

			; scsi_Data
	This field points to the data buffer for the SCSI data phase (if any is expected). It is generally the job of the driver software to ensure that the given buffer is DMA-accessible and to drop to programmed I/O if it isn’t. The filing system provides a stop-gap fix for non-conforming drivers with the AddressMask parameter in DEVS:MountList. For absolute safety, restrict all direct reads and writes to Chip RAM.		: This field points to the data buffer for the SCSI data phase (if any is expected). It is generally the job of the driver software to ensure that the given buffer is DMA-accessible and to drop to programmed I/O if it isn’t. The filing system provides a stop-gap fix for non-conforming drivers with the AddressMask parameter in DEVS:MountList. For absolute safety, restrict all direct reads and writes to Chip RAM.

			; scsi_Length
	This is the expected length of data to be transferred. If an unknown amount of data is to be transferred from target to host, set the scsi_Length to be larger than the maximum amount of data expected. Some controllers explicitly use scsi_Length as the amount of data to transfer. The ''A2091'', ''A590'' and ''A3000'' drivers always do programmed I/O for data transfers under 256 bytes or when the DMA chip doesn’t support the required alignment.		This is the expected length of data to be transferred. If an unknown amount of data is to be transferred from target to host, set the scsi_Length to be larger than the maximum amount of data expected. Some controllers explicitly use scsi_Length as the amount of data to transfer. The ''A2091'', ''A590'' and ''A3000'' drivers always do programmed I/O for data transfers under 256 bytes or when the DMA chip doesn’t support the required alignment.

			; scsi_Actual
	How much data was actually received from or sent to the SCSI unit in response to the SCSI-direct command.		: How much data was actually received from or sent to the SCSI unit in response to the SCSI-direct command.

			; scsi_Command
	The SCSI-direct command.		: The SCSI-direct command.

			; scsi_CmdLength
	The length of the SCSI-direct command in bytes.		: The length of the SCSI-direct command in bytes.

			; scsi_CmdActual
	The actual number of bytes of the SCSI-direct command that were transferred to the SCSI unit.		: The actual number of bytes of the SCSI-direct command that were transferred to the SCSI unit.

			; scsi_Flags
	These flags contain the intended data direction for the SCSI command. It is not strictly necessary to set the data direction flag since the SCSI protocol will inform the driver which direction data transfers will be going. However, some controllers use this information to set up DMA before issuing the command . It can also be used as a sanity check in case the data phase goes the wrong way.		: These flags contain the intended data direction for the SCSI command. It is not strictly necessary to set the data direction flag since the SCSI protocol will inform the driver which direction data transfers will be going. However, some controllers use this information to set up DMA before issuing the command . It can also be used as a sanity check in case the data phase goes the wrong way.

	One flag in particular, is worth noting. SCSIF_AUTOSENSE is used to make the driver perform an automatic REQUEST SENSE if the target returns CHECK CONDITION for a SCSI command. The reason for having the driver do this is the multitasking nature of the Amiga. If two tasks were accessing the same drive and the first received a CHECK CONDITION, the second task would destroy the sense information when it sent a command. SCSIF_AUTOSENSE prevents the caller from having to make two I/O requests and removes this window of vulnerability.		: One flag in particular, is worth noting. SCSIF_AUTOSENSE is used to make the driver perform an automatic REQUEST SENSE if the target returns CHECK CONDITION for a SCSI command. The reason for having the driver do this is the multitasking nature of the Amiga. If two tasks were accessing the same drive and the first received a CHECK CONDITION, the second task would destroy the sense information when it sent a command. SCSIF_AUTOSENSE prevents the caller from having to make two I/O requests and removes this window of vulnerability.

			; scsi_Status
	The status of the SCSI-direct command. The values returned in this field can be found in the SCSI specification. For example, 2 is CHECK_CONDITION.		: The status of the SCSI-direct command. The values returned in this field can be found in the SCSI specification. For example, 2 is CHECK_CONDITION.

			; scsi_SenseActual
	If the SCSIF_AUTOSENSE flag is set, it is important to initialize this field to zero before issuing a SCSI command because some drivers don’t support AUTOSENSE and won’t initialize the field.		: If the SCSIF_AUTOSENSE flag is set, it is important to initialize this field to zero before issuing a SCSI command because some drivers don’t support AUTOSENSE and won’t initialize the field.

			; scsi_SenseData
	This field is used only for SCSIF_AUTOSENSE. If a REQUEST SENSE command is directly sent to the driver, the data will be deposited in the buffer pointed to by scsi_Data.		: This field is used only for SCSIF_AUTOSENSE. If a REQUEST SENSE command is directly sent to the driver, the data will be deposited in the buffer pointed to by scsi_Data.

	Keep in mind that SCSI-direct is geared toward an initiator role so it can’t be expected to perform target-like operations. You can only send commands to a device, not receive them from an initiator. There is no provision for SCSI messaging, either. This is due mainly to the interactive nature of the extended messages (such as synchronous transfer requests) which have to be handled by the driver because it knows the limitations of the controller card and has to be made aware of such protocol changes.		Keep in mind that SCSI-direct is geared toward an initiator role so it can’t be expected to perform target-like operations. You can only send commands to a device, not receive them from an initiator. There is no provision for SCSI messaging, either. This is due mainly to the interactive nature of the extended messages (such as synchronous transfer requests) which have to be handled by the driver because it knows the limitations of the controller card and has to be made aware of such protocol changes.

Steven Solie: /* Device Interface */

2012-05-04T21:39:56Z

Device Interface

← Older revision		Revision as of 21:39, 4 May 2012
Line 60:		Line 60:
	To send SCSI-direct or other commands to the SCSI device, an extended I/O request structure named IOStdReq is used.		To send SCSI-direct or other commands to the SCSI device, an extended I/O request structure named IOStdReq is used.

			<syntaxhighlight>
	~~<pre>~~struct IOStdReq		struct IOStdReq
	{		{
	struct Message io_Message;		struct Message io_Message;
Line 72:		Line 73:
	APTR io_Data; /* points to data area */		APTR io_Data; /* points to data area */
	ULONG io_Offset; /* offset for block structured devices */		ULONG io_Offset; /* offset for block structured devices */
	};~~</pre>~~		};
			</syntaxhighlight>

	See the include file exec/io.h for the complete structure definition.		See the include file exec/io.h for the complete structure definition.

Line 86:		Line 89:

	<table>		<table>
	<tbody>
	<tr class="odd">		<tr class="odd">
	<td align="right">'''SCSI unit'''</td>		<td align="right">'''SCSI unit'''</td>
Line 107:		Line 109:
	<td align="left">not valid: both logical units and addresses range from 0–7</td>		<td align="left">not valid: both logical units and addresses range from 0–7</td>
	</tr>		</tr>
	</tbody>
	</table>		</table>

Line 113:		Line 114:

	<table>		<table>
	<tbody>
	<tr class="odd">		<tr class="odd">
	<td align="right">'''2090/A unit'''</td>		<td align="right">'''2090/A unit'''</td>
Line 134:		Line 134:
	<td align="left">Perhaps it’s an ST506 unit.</td>		<td align="left">Perhaps it’s an ST506 unit.</td>
	</tr>		</tr>
	</tbody>
	</table>		</table>

	Some controller boards generate a unique name for the second controller board, instead of implementing the 100s digit (e.g., the ''2090A''’s iddisk.device).		Some controller boards generate a unique name for the second controller board, instead of implementing the 100s digit (e.g., the ''2090A''’s iddisk.device).

			<pre>
	~~<pre>~~struct MsgPort SCSIMP; / Message port pointer */		struct MsgPort SCSIMP; / Message port pointer */
	struct IOStdReq SCSIIO; / IORequest pointer */		struct IOStdReq SCSIIO; / IORequest pointer */

Line 152:		Line 152:
	/* Open the SCSI device */		/* Open the SCSI device */
	if (error = OpenDevice("scsi.device",6L,SCSIIO,0L))		if (error = OpenDevice("scsi.device",6L,SCSIIO,0L))
	cleanexit("Can't open scsi.device\n",RETURN_FAIL);~~</pre>~~		cleanexit("Can't open scsi.device\n",RETURN_FAIL);
			</pre>

	In the code above, the SCSI unit at address 6 of logical unit 0 of board 0 is opened.		In the code above, the SCSI unit at address 6 of logical unit 0 of board 0 is opened.

Line 159:		Line 161:
	Each OpenDevice() must eventually be matched by a call to CloseDevice(). All I/O requests must be complete before calling CloseDevice(). If any requests are still pending, abort them with AbortIO().		Each OpenDevice() must eventually be matched by a call to CloseDevice(). All I/O requests must be complete before calling CloseDevice(). If any requests are still pending, abort them with AbortIO().

			<pre>
	~~<pre>~~if (!(CheckIO(SCSIIO)))		if (!(CheckIO(SCSIIO)))
	{		{
	AbortIO(SCSIIO); /* Ask device to abort any pending requests */		AbortIO(SCSIIO); /* Ask device to abort any pending requests */
	WaitIO(SCSIIO); /* Wait for abort, then clean up */		WaitIO(SCSIIO); /* Wait for abort, then clean up */
	}		}
	CloseDevice(SCSIIO); /* Close SCSI device */~~</pre>~~		CloseDevice(SCSIIO); /* Close SCSI device */
			</pre>

	== SCSI-Direct ==		== SCSI-Direct ==

Steven Solie: /* Additional Information on the SCSI Device */

2012-05-02T06:01:34Z

Additional Information on the SCSI Device

← Older revision		Revision as of 06:01, 2 May 2012
Line 828:		Line 828:
	== Additional Information on the SCSI Device ==		== Additional Information on the SCSI Device ==

	Additional programming information on the SCSI device can be found in the include files for the SCSI device and RigidDiskBlock. Both are contained in the ~~''Amiga ROM Kernel Reference Manual: Includes and Autodocs''~~.		Additional programming information on the SCSI device can be found in the include files for the SCSI device and RigidDiskBlock. Both are contained in the SDK.

	For information on the SCSI commands, see either the ANSI-X3T9 (draft SCSI-2) or ANSI X3.131 (SCSI-1) specification~~. The NCR SCSI BBS—phone number (316)636-8700 (2400 baud)—has electronic copies of the current SCSI specifications~~.		For information on the SCSI commands, see either the ANSI-X3T9 (draft SCSI-2) or ANSI X3.131 (SCSI-1) specification.

			{\| class="wikitable"
	\|ll\|
			! Includes

			\|-
	2c'''SCSI Device Information'''<br />
	~~Includes &~~ devices/scsidisk.h~~<br />~~		\| devices/scsidisk.h
			\|-
	& devices/scsidisk.i<br />
	~~&~~ devices/hardblocks.h~~<br />~~		\| devices/hardblocks.h
			\|}
	& devices/hardblocks.i<br />

← Older revision		Revision as of 18:39, 2 October 2015
Line 275:		Line 275:

	== RigidDiskBlock – Fields and Implementation ==		== RigidDiskBlock – Fields and Implementation ==



	The RigidDiskBlock (RDB) standard was borne out of the same development effort as HD_SCSICMD and as a result has a heavy bias towards SCSI. However, there is nothing in the RDB specification that makes it unusable for devices using other bus protocols. The XT style disks used in the ''A590'' also support the RDB standard.		The RigidDiskBlock (RDB) standard was borne out of the same development effort as HD_SCSICMD and as a result has a heavy bias towards SCSI. However, there is nothing in the RDB specification that makes it unusable for devices using other bus protocols. The XT style disks used in the ''A590'' also support the RDB standard.
Line 284:		Line 282:
	The preferred method of creating RigidDiskBlocks is with the ''HDToolBox'' program. Most controllers include an RDB editor or utility.		The preferred method of creating RigidDiskBlocks is with the ''HDToolBox'' program. Most controllers include an RDB editor or utility.

	When a driver is initialized, it uses the information contained in the RDB to mount the required partitions and mark them as bootable if needed. The driver is also responsible for loading any filing systems that are required if they are not already available on the ~~filesystem~~.resource list. ~~Filesystems~~ are added to the resource according to DosType and version number.		When a driver is initialized, it uses the information contained in the RDB to mount the required partitions and mark them as bootable if needed. The driver is also responsible for loading any filing systems that are required if they are not already available on the FileSystem.resource list. File systems are added to the resource according to DosType and version number.

	The following is a listing of devices/hardblocks.h that describes all the fields in the RDB specification.		The following is a listing of devices/hardblocks.h that describes all the fields in the RDB specification.

			<pre>
	~~<pre>~~/*--------------------------------------------------------------------		/*--------------------------------------------------------------------
	*		*
	* This file describes blocks of data that exist on a hard disk		* This file describes blocks of data that exist on a hard disk
Line 469:		Line 468:
	#define IDNAME_LOADSEG 0x4C534547 /* 'LSEG' */		#define IDNAME_LOADSEG 0x4C534547 /* 'LSEG' */

	#endif /* DEVICES_HARDBLOCKS_H */~~</pre>~~		#endif /* DEVICES_HARDBLOCKS_H */
			</pre>

	=== How a Driver Uses RDB ===		=== How a Driver Uses RDB ===

Line 480:		Line 481:
	# Checks the PBFB_NOMOUNT flag. If set then this partition is just reserving space. Skip to the next partition without mounting the current one.		# Checks the PBFB_NOMOUNT flag. If set then this partition is just reserving space. Skip to the next partition without mounting the current one.
	# If PBFB_NOMOUNT is false, then the partition is to be mounted. The driver fetches the given drive name from pb_DriveName. This name will be of the form dh0, work, wb_2.x etc. A check is made to see if this name already exists on eb_MountList or DOS’s device list. If it does, then the name is algorithmically altered to remove duplicates. The ''A590'', ''A2091'' and ''A3000'' append .n (where ''n'' is a number) unless another name ending with .n is found. In that case the name is changed to .n+1 and the search for duplicates is retried.		# If PBFB_NOMOUNT is false, then the partition is to be mounted. The driver fetches the given drive name from pb_DriveName. This name will be of the form dh0, work, wb_2.x etc. A check is made to see if this name already exists on eb_MountList or DOS’s device list. If it does, then the name is algorithmically altered to remove duplicates. The ''A590'', ''A2091'' and ''A3000'' append .n (where ''n'' is a number) unless another name ending with .n is found. In that case the name is changed to .n+1 and the search for duplicates is retried.
	# Next the driver constructs a parameter packet for MakeDosNode() using the (possibly altered) drive name and information about the Exec device name and unit number. MakeDosNode() is called to create a DOS device node. MakeDosNode() constructs a ~~filesystem~~ startup message from the given information and fills in defaults for the ROM filing system.		# Next the driver constructs a parameter packet for MakeDosNode() using the (possibly altered) drive name and information about the Exec device name and unit number. MakeDosNode() is called to create a DOS device node. MakeDosNode() constructs a file system startup message from the given information and fills in defaults for the ROM filing system.
	# If MakeDosNode() succeeds then the driver checks to see if the entry is using a standard (“DOS0”) filing system. If not then the routine for patching in non-standard filing systems is called (see “Alien File Systems” below).		# If MakeDosNode() succeeds then the driver checks to see if the entry is using a standard (“DOS0”) filing system. If not then the routine for patching in non-standard filing systems is called (see “Alien File Systems” below).
	# Now that the DOS node has been set up and the correct filing system segment has been associated with it, the driver checks PBFB_BOOTABLE to see if this partition is marked as bootable. If the partition is not bootable, or this is not autoboot time (DiagArea == 0) then the driver simply calls AddDosNode() to enqueue the DOS device node. If the partition is bootable, then the driver constructs a boot node and enqueues it on eb_MountList using the boot priority from the environment vector. If this boot priority is -128 then the partition is not considered bootable.		# Now that the DOS node has been set up and the correct filing system segment has been associated with it, the driver checks PBFB_BOOTABLE to see if this partition is marked as bootable. If the partition is not bootable, or this is not autoboot time (DiagArea == 0) then the driver simply calls AddDosNode() to enqueue the DOS device node. If the partition is bootable, then the driver constructs a boot node and enqueues it on eb_MountList using the boot priority from the environment vector. If this boot priority is -128 then the partition is not considered bootable.
Line 488:		Line 489:
	When a filing system other than the ROM filing system is to be used, the following steps take place.		When a filing system other than the ROM filing system is to be used, the following steps take place.

	# First, open ~~filesystem~~.resource in preparation for finding the ~~filesystem~~ segment we want. If ~~filesystem~~.resource doesn’t exist then create it and add it via AddResource(). Under 2.0 the resource is created by the system early on in the initialization sequence. Under pre-V36 Kickstart, it is the responsibility of the first RDB driver to create it.		# First, open FileSystem.resource in preparation for finding the file system segment we want. If FileSystem.resource doesn’t exist then create it and add it via AddResource(). Under 2.0 the resource is created by the system early on in the initialization sequence. Under pre-V36 Kickstart, it is the responsibility of the first RDB driver to create it.
	# Scan ~~filesystem~~.resource looking for a ~~filesystem~~ that matches the DosType and version that we want. If it exists go to step 4.		# Scan FileSystem.resource looking for a file system that matches the DosType and version that we want. If it exists go to step 4.
	# Since the driver couldn’t find the ~~filesystem~~ it needed, it will have to load it from the RDB area. The list of FileSysHeaderBlocks (pointed to by the “RDSK” block) is scanned for a ~~filesystem~~ of the required DosType and version. If none is found then the driver will give up and abort the mounting of the partition. If the required ~~filesystem~~ is found, then it is LoadSeg()’ed from the “LSEG” blocks and added as a new entry to the ~~filesystem~~.resource.		# Since the driver couldn’t find the file system it needed, it will have to load it from the RDB area. The list of FileSysHeaderBlocks (pointed to by the “RDSK” block) is scanned for a file system of the required DosType and version. If none is found then the driver will give up and abort the mounting of the partition. If the required file system is found, then it is LoadSeg()’ed from the “LSEG” blocks and added as a new entry to the FileSystem.resource.
	# The SegList pointer of the found or loaded ~~filesystem~~ is held in the FileSysEntry structure (which is basically an environment vector for this filing system). Using the patch flags, the driver now patches the newly created environment vector (pointed to by the new DosNode) using the values in the FileSysEntry being used. This ensures that the partition will have the correct filing system set up with the correct mount variables using a shared SegList.		# The SegList pointer of the found or loaded file system is held in the FileSysEntry structure (which is basically an environment vector for this filing system). Using the patch flags, the driver now patches the newly created environment vector (pointed to by the new DosNode) using the values in the FileSysEntry being used. This ensures that the partition will have the correct filing system set up with the correct mount variables using a shared SegList.

	The eb_Mountlist will now be set up with prioritized bootnodes and maybe some non-bootable, but mounted partitions. The system bootstrap will now take over.		The eb_Mountlist will now be set up with prioritized bootnodes and maybe some non-bootable, but mounted partitions. The system bootstrap will now take over.