NSD Standard

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.

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

"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
   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.

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:

   - 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 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 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 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 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?