TrackDisk64 Standard - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:10:44Z

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

← Older revision		Revision as of 19:10, 26 January 2025
Line 11:		Line 11:
	The command names are similar to their respective 32 bit counterparts.		The command names are similar to their respective 32 bit counterparts.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	#define NSCMD_TD_READ64 0xc000		#define NSCMD_TD_READ64 0xc000
	#define NSCMD_TD_WRITE64 0xc001		#define NSCMD_TD_WRITE64 0xc001

Steven Solie: /* Recommended use */

2015-10-02T18:33:29Z

Recommended use

← Older revision		Revision as of 18:33, 2 October 2015
Line 32:		Line 32:
	= Recommended use =		= Recommended use =

	It is recommended that availability is tested once only, e.g. on startup of a ~~filesystem~~. At that time it should be decided first wether the 32 bit command or the 64 bit commands need to be used as the test for 64 bit commands is obviously not necessary if 32 bit is enough to do the job~~. This decision should remain firm, i.e~~.		It is recommended that availability is tested once only, e.g. on startup of a file system. At that time it should be decided first wether the 32 bit command or the 64 bit commands need to be used as the test for 64 bit commands is obviously not necessary if 32 bit is enough to do the job.

	both command sets should not be mixed. If the access range lies completely within the 32 bit range, only the 32 bit commands should be used. If not, the 64 bit commands must be used. This can be achieved very easily by using variables for the command numbers. Note that there does not need to be a test if io_HighOffset should be set up. io_HighOffset can be set up for both sets of commands. For 32 bit commands, it will be ignored.		This decision should remain firm, i.e. both command sets should not be mixed. If the access range lies completely within the 32 bit range, only the 32 bit commands should be used. If not, the 64 bit commands must be used. This can be achieved very easily by using variables for the command numbers. Note that there does not need to be a test if io_HighOffset should be set up. io_HighOffset can be set up for both sets of commands. For 32 bit commands, it will be ignored.

	= Notes =		= Notes =

Steven Solie: /* Revision */

2013-04-11T19:37:08Z

Revision

← Older revision		Revision as of 19:37, 11 April 2013
Line 1:		Line 1:
	= Revision =		= Revision =

	Version 1.2 (~~1996~~-07-13)		Version 1.3 (2013-04-11)

	= Support for large storage devices =		= Support for large storage devices =

Steven Solie: Created page with "= Revision = Version 1.2 (1996-07-13) = Support for large storage devices = Up to and including V40 (OS 3.1), there was only support for disk like storage devices up to a s..."

2013-04-11T19:35:18Z

Created page with "= Revision = Version 1.2 (1996-07-13) = Support for large storage devices = Up to and including V40 (OS 3.1), there was only support for disk like storage devices up to a s..."

New page

= Revision =

Version 1.2 (1996-07-13)

= Support for large storage devices =

Up to and including V40 (OS 3.1), there was only support for disk like storage devices up to a size of 4GB. This text specifies a command set for 64 bit based access to trackdisk/scsidisk like drivers. It is based on the "new style device" standard which is described in the [[NSD_Standard|NSD Standard]]. Note that these commands may not be implemented unless the implementation fully conforms to the "new style device" standard. Note the recommendations and restrictions for NSDEVTYPE_TRACKDISK well.

= Command Set =

The command names are similar to their respective 32 bit counterparts.

<syntaxhighlight>
#define NSCMD_TD_READ64 0xc000
#define NSCMD_TD_WRITE64 0xc001
#define NSCMD_TD_SEEK64 0xc002
#define NSCMD_TD_FORMAT64 0xc003
</syntaxhighlight>

= Transfer Offset and Size =

The transfer size used for io_Length is still an unsigned 32 bit value. This is not considered to be a problem. To specify a 64 bit transfer offset, io_Actual is used for the upper 32 bit of the transfer offset when setting up a struct IOStdReq. io_Actual is aliased io_HighOffset for this purpose. The io_Offset field still represents the lower 32 bit of the 64 bit offset. It is necessary to reinitialize all the fields on every I/O operation as described in the official OS documentation.

= Implementation behaviour =

Any 64 bit command may be used in the full 64 bit range, including the current 32 bit range of course. The behaviour for both 32 bit and 64 bit commands is undefined if the respective range is exceeded via a offset/length combination. Obviously this should be avoided.

= Command Identification =

Identification of the availability of these new 64 bit commands must be tested according to the "new style device" standard.

= Recommended use =

It is recommended that availability is tested once only, e.g. on startup of a filesystem. At that time it should be decided first wether the 32 bit command or the 64 bit commands need to be used as the test for 64 bit commands is obviously not necessary if 32 bit is enough to do the job. This decision should remain firm, i.e.
both command sets should not be mixed. If the access range lies completely within the 32 bit range, only the 32 bit commands should be used. If not, the 64 bit commands must be used. This can be achieved very easily by using variables for the command numbers. Note that there does not need to be a test if io_HighOffset should be set up. io_HighOffset can be set up for both sets of commands. For 32 bit commands, it will be ignored.

= Notes =

This specification does not cover ETD commands. For ETD commands there is no 64 bit specification available. It is not expected at this time that there is a need.

= Acknowledgements =

Written by Heinz Wrobel

This document is largely based on previous work by Ralph Schmidt, Ralph Babel, Randell Jesup and others. Many thanks to them for working out all the necessary details. Without their work, there would not be a 64 bit command set. This document basically puts these details into the New Style Device frame to make them a standard part of the OS framework.