Copyright (c) Hyperion Entertainment and contributors.

Difference between revisions of "NSD Standard"

From AmigaOS Documentation Wiki
Jump to navigation Jump to search
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
  +
== Revision ==
  +
  +
Version 1.7 (2013-04-11)
  +
 
= What is this about? =
 
= What is this about? =
   
Up to and including OS 3.1 (V40), custom device commands usually started at CMD_NONSTD. Each developer added commands for custom device features freely. This lead to messy and incompatible devices and strange compatibility tricks to identify device capabilities.
+
Up to and including AmigaOS 3.1 (V40), custom device commands usually started at CMD_NONSTD. Each developer added commands for custom device features freely. This lead to messy and incompatible devices and strange compatibility tricks to identify device capabilities.
   
 
The goal of this document is to provide for a clean way to identify device types and capabilities, and, within this framework, to point out rules, strategies, and ideas to make device usage as safe as possible without introducing major overhead.
 
The goal of this document is to provide for a clean way to identify device types and capabilities, and, within this framework, to point out rules, strategies, and ideas to make device usage as safe as possible without introducing major overhead.
Line 7: Line 11:
 
= Terminology =
 
= Terminology =
   
  +
With "device" an Exec device is referred to as documented for the context of Exec in [[Exec_Device_I/O|Exec Device I/O]]:
"RKM" means, "Rom Kernel Manuals", the official OS documentation as
 
published by Addison Wesley. Typically the third Edition,
 
describing >=V36 is referred to. With "device" an Exec device is
 
referred to as documented for the context of Exec in the RKM
 
Libraries 3rd edition, chapter 19 "EXEC DEVICE I/O", page 445:
 
   
An Amiga device is a software module that accepts commands and
+
''An Amiga device is a software module that accepts commands and data and performs I/O operations based on the commands it receives.''
data and performs I/O operations based on the commands it
 
receives.
 
 
Underlying hardware is always mentioned if needed, but not referred
 
to as "device" to be consistent with RKM terminology in that field.
 
Commands in the reserved ranges are called "new style". A device
 
that supports new style commands correctly as described in this
 
document is called a "new style device". The abbreviation used to
 
easily refer to this standard or to devices adhering to this
 
standard is called "NSD" for "N"ew "S"tyle "D"evices. Other than
 
that, the use of "standardese" has been avoided if possible.
 
Comments on any unclear statements and on errors are very welcome.
 
There should not be any ambigous statements in this document.
 
   
  +
Underlying hardware is always mentioned if needed, but not referred to as "device" to be consistent with Exec terminology in that field. Commands in the reserved ranges are called "new style". A device that supports new style commands correctly as described in this document is called a "new style device". The abbreviation used to
  +
easily refer to this standard or to devices adhering to this standard is called '''NSD''' for '''N'''ew '''S'''tyle '''D'''evices. Other than that, the use of "standardese" has been avoided if possible. Comments on any unclear statements and on errors are very welcome. There should not be any ambigous statements in this document.
   
 
= Sub-Documents =
 
= Sub-Documents =
   
  +
While the basic NSD specification itself is very small and easy to implement, the discussion about the issues involved got more and more complex over time. For ease of use, the complete NSD documentation has been split up into sub documents that concentrate on specific issues. The sub documents shall not be regarded in isolation. They belong together and shall be used together. The whole set of sub documents make up the NSD specification:
While the basic NSD specification itself is very small and easy to
 
  +
implement, the discussion about the issues involved got more and
 
  +
[[NSD_Command_Specifications|NSD Command Specifications]] -- The basic NSD specification
more complex over time. For ease of use, the complete NSD
 
  +
documentation has been split up into sub documents that concentrate
 
  +
[[NSD_Device_Specifics|NSD Device Specifics]] -- Device type specific NSD issues
on specific issues. The sub documents shall not be regarded
 
  +
in isolation. They belong together and shall be used together. The
 
  +
[[NSD_Thoughts|NSD Thoughts]] -- Thoughts and Consequences
whole set of sub documents make up the NSD specification:
 
   
  +
[[NSD_Future|NSD Future]] -- The future of NSD
- NewStyleCommands The revision number of NSD
 
- NSD-README This document
 
- NSD-CommandSpecs The basic NSD specification
 
- NSD-DeviceSpecifics Device type specific NSD issues
 
- NSD-Thoughts Thoughts and Consequences
 
- NSD-Future The future of NSD
 
- NSD-History The history of NSD
 
   
  +
[[NSD_History|NSD History]] -- The history of NSD
   
 
= NSD Conformance =
 
= NSD Conformance =
   
Nothing is ever perfect and the better is always the enemy of the
+
Nothing is ever perfect and the better is always the enemy of the good. So NSD has evolved and will continue to evolve as needs change and expand in the future. The Revision section above is used as revision specifier and
  +
identifies the NSD revision for historic reasons. To avoid confusion about the terms version/revision, let us use these terms interchangably here to identify a certain issued NSD specification or a part thereof.
good. So NSD has evolved and will continue to evolve as needs
 
change and expand in the future. The RCS Id at the top of the sub
 
document "NewStyleCommands" is used as revision specifier and
 
identifies the NSD revision for historic reasons. To avoid
 
confusion about the terms version/revision, let us use these terms
 
interchangably here to identify a certain issued NSD specification
 
or a part thereof.
 
   
The RCS Id's at the top of the sub documents shall be referred to
+
Revision sections at the top of the sub documents shall be referred to as additional check to avoid confusing sub documents belonging to different revisions of NSD.
as additional check to avoid confusing sub documents belonging to
 
different revisions of NSD.
 
   
  +
The list of revisions may not be contigous, as internal, non published revisions may exists which are of no consequence to users or to implementers. Only the revisions listed as public in NSD-History, and of course this revision exist for public consumption. On request, an archive containing all revisions may be obtained.
The list of revisions may not be contigous, as internal, non
 
published revisions may exists which are of no consequence to users
 
or to implementers. Only the revisions listed as public in
 
NSD-History, and of course this revision exist for public
 
consumption. On request, an archive containing all revisions may be
 
obtained.
 
   
  +
It is strongly suggested that an NSD conforming device lists the revision of the standard it conforms to in its documentation. NSD is designed to make device usage easy and as safe as possible. As this standard is revised, new technique for getting closer to this goal may be found and worked in, while still keeping implementations adhering to previous revisions valid and usable.
It is strongly suggested that an NSD conforming device lists the
 
revision of the standard it conforms to in its documentation. NSD
 
is designed to make device usage easy and as safe as possible. As
 
this standard is revised, new technique for getting closer to this
 
goal may be found and worked in, while still keeping
 
implementations adhering to previous revisions valid and usable.
 
   
NSD relies on your support and ideas, so if you have comments or
+
NSD relies on your support and ideas, so if you have comments or gripes, please contact the [http://www.amigaos.net/contact AmigaOS Development Team]. Unreported problems that are not found here obviously cannot be fixed and we all want things to get better, don't we?
gripes, please mail them in to <bugs@amiga.de> and <heinz@amiga.de>
 
early on in an orderly fashion. Unreported problems that are not
 
found here obviously cannot be fixed and we all want things to get
 
better, don't we?
 

Latest revision as of 18:54, 11 April 2013

Revision

Version 1.7 (2013-04-11)

What is this about?

Up to and including AmigaOS 3.1 (V40), custom device commands usually started at CMD_NONSTD. Each developer added commands for custom device features freely. This lead to messy and incompatible devices and strange compatibility tricks to identify device capabilities.

The goal of this document is to provide for a clean way to identify device types and capabilities, and, within this framework, to point out rules, strategies, and ideas to make device usage as safe as possible without introducing major overhead.

Terminology

With "device" an Exec device is referred to as documented for the context of Exec in Exec Device I/O:

An Amiga device is a software module that accepts commands and data and performs I/O operations based on the commands it receives.

Underlying hardware is always mentioned if needed, but not referred to as "device" to be consistent with Exec terminology in that field. Commands in the reserved ranges are called "new style". A device that supports new style commands correctly as described in this document is called a "new style device". The abbreviation used to easily refer to this standard or to devices adhering to this standard is called NSD for New Style Devices. Other than that, the use of "standardese" has been avoided if possible. Comments on any unclear statements and on errors are very welcome. There should not be any ambigous statements in this document.

Sub-Documents

While the basic NSD specification itself is very small and easy to implement, the discussion about the issues involved got more and more complex over time. For ease of use, the complete NSD documentation has been split up into sub documents that concentrate on specific issues. The sub documents shall not be regarded in isolation. They belong together and shall be used together. The whole set of sub documents make up the NSD specification:

NSD Command Specifications -- The basic NSD specification

NSD Device Specifics -- Device type specific NSD issues

NSD Thoughts -- Thoughts and Consequences

NSD Future -- The future of NSD

NSD History -- The history of NSD

NSD Conformance

Nothing is ever perfect and the better is always the enemy of the good. So NSD has evolved and will continue to evolve as needs change and expand in the future. The Revision section above is used as revision specifier and identifies the NSD revision for historic reasons. To avoid confusion about the terms version/revision, let us use these terms interchangably here to identify a certain issued NSD specification or a part thereof.

Revision sections at the top of the sub documents shall be referred to as additional check to avoid confusing sub documents belonging to different revisions of NSD.

The list of revisions may not be contigous, as internal, non published revisions may exists which are of no consequence to users or to implementers. Only the revisions listed as public in NSD-History, and of course this revision exist for public consumption. On request, an archive containing all revisions may be obtained.

It is strongly suggested that an NSD conforming device lists the revision of the standard it conforms to in its documentation. NSD is designed to make device usage easy and as safe as possible. As this standard is revised, new technique for getting closer to this goal may be found and worked in, while still keeping implementations adhering to previous revisions valid and usable.

NSD relies on your support and ideas, so if you have comments or gripes, please contact the AmigaOS Development Team. Unreported problems that are not found here obviously cannot be fixed and we all want things to get better, don't we?