NSD History - Revision history

Steven Solie: /* Revision */

2013-04-11T19:15:56Z

Revision

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

	Version 1.4 (1997-05-15)

	= History & Conformance =		= History & Conformance =

Steven Solie: /* History & Conformance */

2013-04-11T19:15:31Z

History & Conformance

← Older revision		Revision as of 19:15, 11 April 2013
Line 9:		Line 9:
	The most recent changes are at the top of the list:		The most recent changes are at the top of the list:

			== Revision 1.7 ==
	- Public Revision 1.6: Minor text cleanups and clarifications
	for publication on ftp.amiga.de. No substantial changes.

			* Converted to MediaWiki.
	- This version of NSD fixes an obvious typo in the
			* Fixed several typos.
	define list that nobody noticed or reported previously.
			* Replaced references to "RKM" with links to the relevant sections.
			* Updated contact information.
			* Updated code fragments to V50 conventions.

			== Revision 1.6 ==
	The correct define name for audio type devices is:

			* Minor text cleanups and clarifications for publication on ftp.amiga.de. No substantial changes.
	#define NSDEVTYPE_AUDIO 8 /* like audio.device */

			* This version of NSD fixes an obvious typo in the define list that nobody noticed or reported previously.
	It used to be documented as NSDEVTYPE_AUDIOARD, which is
	wrong.

			* The correct define name for audio type devices is:
	The text "large enough" describing the mn_Length check has
			: #define NSDEVTYPE_AUDIO 8 / like audio.device */
	been replaced with a description of "at least the minimum
			*: It used to be documented as NSDEVTYPE_AUDIOARD, which is wrong.
	required size". It had turned out that people misunderstood
	"large enough" as meaning "exactly of the required size",
	which is obviously wrong in the context of devices supporting
	multiple request sizes for different types of commands.

			* The text "large enough" describing the mn_Length check has been replaced with a description of "at least the minimum required size". It had turned out that people misunderstood "large enough" as meaning "exactly of the required size", which is obviously wrong in the context of devices supporting multiple request sizes for different types of commands.
	Similar to the change mentioned above, other places have been
	reworded to avoid misunderstandings.

			* Similar to the change mentioned above, other places have been reworded to avoid misunderstandings.
	The basic NSD command set description reflects the
	distinction between command set and semantic consequences
	now by elaborating on the device types. There is also a
	description now on the standard V40 command slots for the NSD
	device types.

			* The basic NSD command set description reflects the distinction between command set and semantic consequences now by elaborating on the device types. There is also a description now on the standard V40 command slots for the NSD device types.
	The NSDEVTYPE_TRACKDISK specific section has been extended
	with a description for ETD like commands. Also, a note has
	been added that e.g. the V40 cd.device as used by C= for the
	CD32 game system should not be forgotten. It is a C= V40 OS
	device "like trackdisk", too. General clarification comments
	have been added in various places.

			* The NSDEVTYPE_TRACKDISK specific section has been extended with a description for ETD like commands. Also, a note has been added that e.g. the V40 cd.device as used by C= for the CD32 game system should not be forgotten. It is a C= V40 OS device "like trackdisk", too. General clarification comments have been added in various places.
	Notes for NSDEVTYPE_SANA2 have been added.

			* Notes for NSDEVTYPE_SANA2 have been added.
	As it turns out, NSD is not only about identifying device
	capabilities, but also about safe use of a device as a
	consequence. While 100% safety can probably never be reached
	within the existing frame, there are simple ways to make
	usage of devices a lot safer. The text now reflects this.

			* As it turns out, NSD is not only about identifying device capabilities, but also about safe use of a device as a consequence. While 100% safety can probably never be reached within the existing frame, there are simple ways to make usage of devices a lot safer. The text now reflects this.
	Due to the complexity of the issues involved, the document
	has been split into sub documents. The wording has been
	changed in several places to reflect this.

			* Due to the complexity of the issues involved, the document has been split into sub documents. The wording has been changed in several places to reflect this.
	Additionally, a "Thoughts & Consequences" section, a "Future
	Directions" section, and this "History & Conformance" section
	have been added as sub documents.

			* Additionally, a "Thoughts & Consequences" section, a "Future Directions" section, and this "History & Conformance" section have been added as sub documents.
	The requirement of changing TD_GETDRIVETYPE for NSD
	trackdisk like devices has been removed. The DRIVE_NEWSTYLE
	identifier for trackdisk like devices doesn't serve any
	useful purpose. It never has and has been introduced only
	because of an oversight during the revision process. While
	the trackdisk TD_GETDRIVETYPE command generally isn't exactly
	the most useful command in the world currently, and while it
	has been documented that anyone using a new style device
	should use TD_GETGEOMETRY, redefinition of TD_GETDRIVETYPE is
	obviously not a useful thing in this context and it would mess
	up the implementation of a true NSD trackdisk.device
	replacement.

			* The requirement of changing TD_GETDRIVETYPE for NSD trackdisk like devices has been removed. The DRIVE_NEWSTYLE identifier for trackdisk like devices doesn't serve any useful purpose. It never has and has been introduced only because of an oversight during the revision process. While the trackdisk TD_GETDRIVETYPE command generally isn't exactly the most useful command in the world currently, and while it has been documented that anyone using a new style device should use TD_GETGEOMETRY, redefinition of TD_GETDRIVETYPE is obviously not a useful thing in this context and it would mess up the implementation of a true NSD trackdisk.device replacement.
	The NSD recognition sequence contains an additional simple
	check now. Correctly written software will continue to work
	well, and software written now will be safer.

			* The NSD recognition sequence contains an additional simple check now. Correctly written software will continue to work well, and software written now will be safer.
	A recommendation has been added on how to set up a reused
	request structure for another OpenDevice() to do a general
	NSD query. As some strange device expect parameter data being
	set up on an OpenDevice() call, the request structure should
	not contain or point to garbage data.

			* A recommendation has been added on how to set up a reused request structure for another OpenDevice() to do a general NSD query. As some strange device expect parameter data being set up on an OpenDevice() call, the request structure should not contain or point to garbage data.
	- Revision 1.4 of NSD got published soon after the release of
	the Amiga Developer CD 1.1. It added the requirement to check
	mn_Length in OpenDevice for at least the minimum required
	size to be handled by the device and documented the "safer
	assumption" for querying a device. It had turned out that
	SANA devices can barf on a general query. As a device
	implementing the mn_Length check will at worst fail to open
	instead of messing up the system which could have happened
	previously, NSD got safer and better this way. A client not
	using the safer assumption is more likely to fail with bad
	devices, but it will still work with the updated NSD spec if
	it doesn't have bugs.

			== Revision 1.4 ==
	- Revision 1.0 of NSD, as published on the Amiga Developer CD

	1.1, unfortunately had no RCS Id string. It should
			* Published soon after the release of the Amiga Developer CD 1.1. It added the requirement to check mn_Length in OpenDevice for at least the minimum required size to be handled by the device and documented the "safer assumption" for querying a device. It had turned out that SANA devices can barf on a general query. As a device implementing the mn_Length check will at worst fail to open instead of messing up the system which could have happened previously, NSD got safer and better this way. A client not using the safer assumption is more likely to fail with bad devices, but it will still work with the updated NSD spec if it doesn't have bugs.
	be referred to as NSD revision 1.0.

			== Revision 1.0 ==

			* Revision 1.0 of NSD, as published on the Amiga Developer CD 1.1, unfortunately had no RCS Id string. It should be referred to as NSD revision 1.0.

Steven Solie: Created page with "= Revision = Version 1.4 (1997-05-15) = History & Conformance = This chapter will tell you about changes in different versions of NSD and about the reasons behind the chang..."

2013-04-11T16:52:11Z

Created page with "= Revision = Version 1.4 (1997-05-15) = History & Conformance = This chapter will tell you about changes in different versions of NSD and about the reasons behind the chang..."

New page

= Revision =

Version 1.4 (1997-05-15)

= History & Conformance =

This chapter will tell you about changes in different versions of NSD and about the reasons behind the changes.

The most recent changes are at the top of the list:

- Public Revision 1.6: Minor text cleanups and clarifications
for publication on ftp.amiga.de. No substantial changes.

- This version of NSD fixes an obvious typo in the
define list that nobody noticed or reported previously.

The correct define name for audio type devices is:

#define NSDEVTYPE_AUDIO 8 /* like audio.device */

It used to be documented as NSDEVTYPE_AUDIOARD, which is
wrong.

The text "large enough" describing the mn_Length check has
been replaced with a description of "at least the minimum
required size". It had turned out that people misunderstood
"large enough" as meaning "exactly of the required size",
which is obviously wrong in the context of devices supporting
multiple request sizes for different types of commands.

Similar to the change mentioned above, other places have been
reworded to avoid misunderstandings.

The basic NSD command set description reflects the
distinction between command set and semantic consequences
now by elaborating on the device types. There is also a
description now on the standard V40 command slots for the NSD
device types.

The NSDEVTYPE_TRACKDISK specific section has been extended
with a description for ETD like commands. Also, a note has
been added that e.g. the V40 cd.device as used by C= for the
CD32 game system should not be forgotten. It is a C= V40 OS
device "like trackdisk", too. General clarification comments
have been added in various places.

Notes for NSDEVTYPE_SANA2 have been added.

As it turns out, NSD is not only about identifying device
capabilities, but also about safe use of a device as a
consequence. While 100% safety can probably never be reached
within the existing frame, there are simple ways to make
usage of devices a lot safer. The text now reflects this.

Due to the complexity of the issues involved, the document
has been split into sub documents. The wording has been
changed in several places to reflect this.

Additionally, a "Thoughts & Consequences" section, a "Future
Directions" section, and this "History & Conformance" section
have been added as sub documents.

The requirement of changing TD_GETDRIVETYPE for NSD
trackdisk like devices has been removed. The DRIVE_NEWSTYLE
identifier for trackdisk like devices doesn't serve any
useful purpose. It never has and has been introduced only
because of an oversight during the revision process. While
the trackdisk TD_GETDRIVETYPE command generally isn't exactly
the most useful command in the world currently, and while it
has been documented that anyone using a new style device
should use TD_GETGEOMETRY, redefinition of TD_GETDRIVETYPE is
obviously not a useful thing in this context and it would mess
up the implementation of a true NSD trackdisk.device
replacement.

The NSD recognition sequence contains an additional simple
check now. Correctly written software will continue to work
well, and software written now will be safer.

A recommendation has been added on how to set up a reused
request structure for another OpenDevice() to do a general
NSD query. As some strange device expect parameter data being
set up on an OpenDevice() call, the request structure should
not contain or point to garbage data.

- Revision 1.4 of NSD got published soon after the release of
the Amiga Developer CD 1.1. It added the requirement to check
mn_Length in OpenDevice for at least the minimum required
size to be handled by the device and documented the "safer
assumption" for querying a device. It had turned out that
SANA devices can barf on a general query. As a device
implementing the mn_Length check will at worst fail to open
instead of messing up the system which could have happened
previously, NSD got safer and better this way. A client not
using the safer assumption is more likely to fail with bad
devices, but it will still work with the updated NSD spec if
it doesn't have bugs.

- Revision 1.0 of NSD, as published on the Amiga Developer CD
1.1, unfortunately had no RCS Id string. It should
be referred to as NSD revision 1.0.