Although we present the Apple II family identification bytes in Apple II Miscellaneous Technical Note #7, many +href="/docs/technote/misc/07/">Apple II Miscellaneous Technical Note #7, many people would prefer a routine they can simply plug into their own program and call. In addition, this routine serves as a small piece of sample code, and there is no reason for you to reinvent the wheel.
@@ -550,7 +550,7 @@ release)This Technical Note formerly introduced the SmartPort firmware interface.
+ +This Note formerly contained a general introduction to the SmartPort +firmware interface. Information on SmartPort as found in the Apple IIe +and IIc is now found in the Apple IIc Technical Reference Manual, Second +Edition.
+ +For a more complete reference on SmartPort, including information on +Extended SmartPort (for peripherals which can address more than one 64K +bank of memory) and its parameters, please see chapter 7 of the Apple +IIGS Firmware Reference.
+ + +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt02.md b/_pages/docs/technote/smpt02.md new file mode 100644 index 0000000..190fde7 --- /dev/null +++ b/_pages/docs/technote/smpt02.md @@ -0,0 +1,95 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #2' +description: 'SmartPort Calls Updated' +permalink: '/docs/technote/smartport/02/' +--- + +This Technical Note documents SmartPort call information which is notfound in the descriptions of SmartPort in the Apple IIGS FirmwareReference and the Apple IIc Technical Reference Manual, Second Edition. The device-specific information which had been included in this Note isnow found in these manuals.
+ +Changes since November 1988: Added diagram and information on vendor ID numbers.
+ +A STATUS call with unit number = $00 and status code = $00 is a request to return the status of the SmartPort host, as opposed to unit numbers greater than zero which return the status of individual devices. The number of devices as well as the current interrupt status is returned. The format of the status list returned is illustrated in Figure 1.
+ ++ + +------------------+ + Byte 0 | Device Count | + +------------------+ + Byte 1 | Interrupt Status | + +------------------+ + Byte 2 | Vendor | $0000 Vendor unknown + + +---$0001 Apple Computer, Inc. + Byte 3 | ID | $0002-$FFFF Third-Party Vendor + +------------------+ + Byte 4 | Interface | _____|___________________|_____ + + +--|F|E|D|C|B|A|9|8|7|6|5|4|3|2|1|0| + Byte 5 | Version | |_______|_______________|_______| + +------------------+ | | | + Byte 6 | Reserved | |Major | Minor |$A=Alpha + +------------------+ |Release| Release |$B=Beta + Byte 7 | Reserved | |$E=Experimental + +------------------+ |$0=Final + + Figure 1 - Host General Status Return Information + ++ +
The Number of devices byte tells the caller the total number of devices hooked to this slot or port.
+ +The Interrupt Status byte is used by programs which try to determine if the SmartPort was the source of an interrupt. If bit 6 of this byte is clear, there is a device (or devices) in the chain that require interrupt service. + +You cannot use this value to determine which device in the chain is actually interrupting. Your interrupt handler, having determined that a SmartPort interrupt has occurred, must poll each device on the chain to find out which device requires service. The UniDisk 3.5 and Memory Expansion Card do not generate interrupts, so in these cases, this byte has bit 6 set.
+ +The vendor ID number may be used to determine the manufacturer of a specific SmartPort peripheral interface card, a useful piece of information when dealing with device-specific calls. Contact Apple Developer Technical Support if you require a specific vendor ID number. The version word follows the +SmartPort Interface Version definition described later in this Note.
+ + +Before May 1988, control code $04 was defined as device-specific. It is now defined as EJECT, and all SmartPort devices which support removable media must support this call. If a device does not support removable media, it should simply return from this call without an error.
+ +Note that the Apple II SCSI card firmware was revised in early 1988 to support this change.
+ + +An application should never make an INIT call (SmartPort code $05), since doing so is likely to destroy operating system integrity and may cause media damage as well.
+ +If you are writing your own operating system (not encouraged) and need to reset all SmartPort devices, the INIT call with unit number = $00 will do just that. Note that SmartPort devices cannot be selectively reset, and INIT must never be made at all with any unit number other than $00.
+ + +The SmartPort Interface Version definition uses the most significant nibble of the word as the major version number, the next two most significant nibbles as the minor version number, and the least significant nibble as a release indicator:
+ ++ + $0 = Final $A = Alpha $B = Beta $E = Experimental + ++ +
Therefore, the interface version word for an experimental SmartPort interface 1.15 would be $115E while the interface version word for SmartPort interface 2.0 would be $2000. GS/OS driver version numbers also follow this definition.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt03.md b/_pages/docs/technote/smpt03.md new file mode 100644 index 0000000..6f463eb --- /dev/null +++ b/_pages/docs/technote/smpt03.md @@ -0,0 +1,19 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #3' +description: 'SmartPort Bus Architecture' +permalink: '/docs/technote/smartport/03/' +--- + +This Technical Note formerly described the SmartPort Bus architecture, but this information is now documented in the Apple IIGS Firmware Reference.
+ +Do not be confused by the name "SmartPort Bus" architecture. The information in the Apple IIGS Firmware Reference describes the mechanics of how devices interface with the disk port on a IIGS or IIc and with the UniDisk 3.5 Interface card on a ][+ or IIe. It is not necessary to understand this information to use SmartPort firmware calls, nor do all devices which have SmartPort firmware necessarily have to connect mechanically through the disk port or UniDisk 3.5 Interface card.
+ +The physical or electrical side of the hardware is called the "SmartPort Bus," while the firmware protocols are called the "SmartPort Interface." Although the term "SmartPort" can refer to either or both parts, it is most often used to refer to the SmartPort Interface. Only those developers who are designing products which will attach to either the IIGS or IIc disk port or to the UniDisk 3.5 Interface card need be concerned with the SmartPort Bus architecture. Software developers need not learn about the SmartPort Bus architecture to use the SmartPort Interface firmware.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt04.md b/_pages/docs/technote/smpt04.md new file mode 100644 index 0000000..7744fab --- /dev/null +++ b/_pages/docs/technote/smpt04.md @@ -0,0 +1,38 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #4' +description: 'SmartPort Device Types' +permalink: '/docs/technote/smartport/04/' +--- + +This Technical Note documents additional device types which the SmartPort firmware recognizes, but which may not be currently documented in the technical reference manuals which cover SmartPort.
+ +The following is an updated list of possible SmartPort device types, extended to support an increasing variety of third-party peripheral products. A device type byte is returned as part of the Device Information Block (DIB) from a SmartPort STATUS call ($03).
+ +This Technical Note describes two CONTROL codes which have changed in +revision C of the Apple II SCSI card firmware.
+ +Changes since January 1989: Added notes about the Apple II +High-Speed SCSI Card.
+ +Revision C of the Apple II SCSI card firmware includes two CONTROL code changes.
+ +CONTROL code $04, previously defined as FORMAT, is now defined as +EJECT. This change reflects the revised SmartPort requirement that all +devices maintain CONTROL code $04 as EJECT. See SmartPort Technical Note #2, SmartPort Calls +Updated, for more information. CONTROL code $15 is now defined as FORMAT +instead of RESERVED. Note that there are two EJECT calls in this version, +as CONTROL code $26 is still defined as EJECT.
+ +To determine which version of the SCSI ROM is on any particular Apple +II SCSI Interface Card, issue a $03 SmartPort STATUS call. The revision C +SCSI ROM returns the word $0200. This does not follow the SmartPort +Interface Version scheme described in SmartPort +Technical Note #2. However, future revisions of the Apple II SCSI +card will follow this scheme. Therefore, applications should expect any +SmartPort SCSI firmware to behave as described in this Note if the version +number is $0200 or if it is greater than or equal to $2000. The Apple II +High-Speed SCSI Card returns version $3000 (3.0). + +
To maintain compatibility with the Apple II High-Speed SCSI Card and future +SCSI products, you should use the following guidelines when programming with +the revision C card:
+ +The Apple II SCSI Card firmware was designed to operate with SCSI CD-ROM and +disk drives only; however, the Apple II High-Speed SCSI Card works with most +SCSI devices, including removable drives, scanners, and tape backup units.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt06.md b/_pages/docs/technote/smpt06.md new file mode 100644 index 0000000..3871e7c --- /dev/null +++ b/_pages/docs/technote/smpt06.md @@ -0,0 +1,27 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #6' +description: 'Apple IIgs SmartPort Errata' +permalink: '/docs/technote/smartport/06/' +--- + +This Technical Note documents two bugs in the Apple IIgs SmartPort firmware.
+ +Changes since November 1988: Documented corrections in ROM 03 and an additional ROM 03 bug.
+ +Developers should be aware of the following two bugs in the Apple IIgs ROM 01 SmartPort firmware:
+ +The ROM 03 firmware fixes these bugs; however, it has a bug in the ResetHook device-specific CONTROL call for the Apple 3.5" Drive. With this bug, hook numbers of nine or greater crash the machine. At present, hook numbers in this range are invalid, so this bug should not be a problem.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt07.md b/_pages/docs/technote/smpt07.md new file mode 100644 index 0000000..0bb299e --- /dev/null +++ b/_pages/docs/technote/smpt07.md @@ -0,0 +1,56 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #7' +description: 'SmartPort Subtype Codes' +permalink: '/docs/technote/smartport/07/' +--- + +This Technical Note clarifies information about SmartPort subtype codes.
+ +Following is a definition of the SmartPort subtype code as given in the +Apple IIGS Firmware Reference:
+ ++ +_________________________________________________ +| | | | | | | | | +| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +| | | | | | | | | +_________________________________________________ + | | | | | | | | + | | | |_____|_____|_____|_____|___ Reserved + | | |_________________________________ 0 = Removable Media + | |_______________________________________ 1 = Supports disk-switched + | errors + |_____________________________________________ 1 = Supports Extended + SmartPort + + Figure 1 - SmartPort Subtype Byte + ++ +
Note that the value for subtype is defined for certain characteristics of the device; it is not assigned to the device as with Smartport device types (see SmartPort Technical Note #4, SmartPort Device Types for a complete list).
+ +Attempting to distinguish different kinds of the same device by the subtype field can be confusing. For example, the Apple IIc Plus has an internal 3.5" disk drive. This drive does not support disk-switched errors nor does it support Extended SmartPort, and it has removable media. This combination of features gives it a subtype definition of $00. However, this is the same subtype returned for a UniDisk 3.5. Any program which finds type $01 (3.5" Disk) and subtype $00 and assumes the drive is a UniDisk 3.5 will be misled by any other 3.5" drive matching the characteristics of the UniDisk 3.5.
+ +Some Apple technical manuals state that the subtype byte may be used for identification purposes, but this cannot be supported if more than one variety of a specific device has the same characteristics and subtype.
+ +To determine if a particular device type is the subtype you want, you may examine the name returned in the Device Information Block (DIB) from a STATUS call with statcode = 3. For 3.5" drives, however, this is not too helpful (both a UniDisk 3.5 and an Apple 3.5 Drive return DISK 3.5).
+ +Because the subtype can not conclusively identify different flavors of 3.5" +drives (and perhaps other individual device types), applications must look +for errors on device specific calls and respond appropriately. Typical errors +returned from making a device-specific call to the wrong device are $21 +(BADCTL) and $22 (BADCTLPARM), although these are not the only ones. Also +note that error codes in the range $20 - $2F are duplicated as $60 - $6F, the +difference being that codes in the latter range are returned if the error was +a soft error -- a non-fatal error returned when the operation is completed +successfully but an abnormal condition is detected.
+ +The Reserved fields in the SmartPort subtype byte are reserved for future expansion. Present peripherals must have them set to zero so that they will not appear to support future features which are not presently defined. For this reason, programs checking the status of bits in the subtype byte should do so on a bit-by-bit basis only. For example, if you need to know if a device supports Extended Smartport, mask off all bits except bit 7 in the subtype byte before doing any comparisons. Blindly comparing to existing common subtype values (like $00 and $C0) will cause comparisons to fail when future bits in the subtype byte are defined.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt08.md b/_pages/docs/technote/smpt08.md new file mode 100644 index 0000000..c53d721 --- /dev/null +++ b/_pages/docs/technote/smpt08.md @@ -0,0 +1,56 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #8' +description: 'SmartPort Packets' +permalink: '/docs/technote/smartport/08/' +--- + +This Technical Note describes the structure and timing of a sample SmartPort packet.
+ +SmartPort devices communicate using SmartPort packets. The following packet shows the timing and content of a SmartPort READBLOCK call. For further explanation of the structure, please see the Apple IIGS Hardware Reference and the Apple IIGS Firmware Reference.
+ +Note: The CPU will recognize and act on any packet put on the bus by a SmartPort Device.+ +
+ +DATA MNEMONIC DESCRIPTION TIME +(SmartPort Bus) (Relative) +_____________________________________________________________________________ +FF SYNC SELF SYNCHRONIZING BYTES 0 +3F : : 32 micro Sec. +CF : : 32 micro Sec. +F3 : : 32 micro Sec. +FC : : 32 micro Sec. +FF : : 32 micro Sec. +C3 PBEGIN MARKS BEGINNING OF PACKET 32 micro Sec. +81 DEST DESTINATION UNIT NUMBER 32 micro Sec. +80 SRC SOURCE UNIT NUMBER 32 micro Sec. +80 TYPE PACKET TYPE FIELD 32 micro Sec. +80 AUX PACKET AUXILLIARY TYPE FIELD 32 micro Sec. +80 STAT DATA STATUS FIELD 32 micro Sec. +82 ODDCNT ODD BYTES COUNT 32 micro Sec. +81 GRP7CNT GROUP OF 7 BYTES COUNT 32 micro Sec. +80 ODDMSB ODD BYTES MSB's 32 micro Sec. +81 COMMAND 1ST ODD BYTE = Command Byte 32 micro Sec. +83 PARMCNT 2ND ODD BYTE = Parameter Count 32 micro Sec. +80 GRP7MSB MSB's FOR 1ST GROUP OF 7 32 micro Sec. +80 G7BYTE1 BYTE 1 FOR 1ST GROUP OF 7 32 micro Sec. +98 G7BYTE2 BYTE 2 FOR 1ST GROUP OF 7 32 micro Sec. +82 G7BYTE3 BYTE 3 FOR 1ST GROUP OF 7 32 micro Sec. +80 G7BYTE4 BYTE 4 FOR 1ST GROUP OF 7 32 micro Sec. +80 G7BYTE5 BYTE 5 FOR 1ST GROUP OF 7 32 micro Sec. +80 G7BYTE5 BYTE 6 FOR 1ST GROUP OF 7 32 micro Sec. +80 G7BYTE6 BYTE 7 FOR 1ST GROUP OF 7 32 micro Sec. +BB CHKSUM1 1ST BYTE OF CHECKSUM 32 micro Sec. +EE CHKSUM2 2ND BYTE OF CHECKSUM 32 micro Sec. +C8 PEND PACKET END BYTE 32 micro Sec. +00 FALSE FALSE IWM WRITE TO CLEAR REGISTER 32 micro Sec. +_____________________________________________________________________________ + ++ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt09.md b/_pages/docs/technote/smpt09.md new file mode 100644 index 0000000..4b35547 --- /dev/null +++ b/_pages/docs/technote/smpt09.md @@ -0,0 +1,23 @@ +--- +layout: 'page' +title: 'SmartPort Technical Note #9' +description: 'Apple II SCSI Errata' +permalink: '/docs/technote/smartport/09/' +--- + +
This Technical Note documents SCSI-specific anomalies that were +discovered in the development of the Apple II High-Speed SCSI card.
+ +During the testing of the Apple II High Speed SCSI Card, several SCSI-related issues of interest to developers were discovered. Most of these issues directly relate to SCSI devices with removable media.
+ +If a CD-ROM has a bad directory, the firmware hangs because it gets a "Read In Progress" error. There is no timeout. The system can be recovered if the CD-ROM is manually ejected.
+ +If the media is ejected while a SmartPort DIB Status call is in progress, the call returns with incorrect results (it reports DISKSW and that the block count of the device is zero). In order to avoid this conflict, bracket the DIB Status call with the SmartPort SCSI specific Control Calls Prevent Removal ($1A) and Allow Removal ($1B).
+ +A SmartPort FORMAT call, in some cases, does not update the DIB correctly to reflect the new or changed partition map. If a SmartPort Init call is always made immediately after the FORMAT, the DIB is rebuilt correctly. Note that after formatting a tape, the tape should be removed from the SCSI tape drive before an Init call is made. An Init call causes the tape to rewind, hanging the system with no time-out until the rewind is complete.
+ +{% include technote_credit.html %} diff --git a/_pages/docs/technote/smpt1.md b/_pages/docs/technote/smpt1.md new file mode 100644 index 0000000..ae256bd --- /dev/null +++ b/_pages/docs/technote/smpt1.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/1/' +target_url: '/docs/technote/smartport/01/' +--- diff --git a/_pages/docs/technote/smpt2.md b/_pages/docs/technote/smpt2.md new file mode 100644 index 0000000..0a63787 --- /dev/null +++ b/_pages/docs/technote/smpt2.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/2/' +target_url: '/docs/technote/smartport/02/' +--- diff --git a/_pages/docs/technote/smpt3.md b/_pages/docs/technote/smpt3.md new file mode 100644 index 0000000..9ff96d7 --- /dev/null +++ b/_pages/docs/technote/smpt3.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/3/' +target_url: '/docs/technote/smartport/03/' +--- diff --git a/_pages/docs/technote/smpt4.md b/_pages/docs/technote/smpt4.md new file mode 100644 index 0000000..e69dc52 --- /dev/null +++ b/_pages/docs/technote/smpt4.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/4/' +target_url: '/docs/technote/smartport/04/' +--- diff --git a/_pages/docs/technote/smpt5.md b/_pages/docs/technote/smpt5.md new file mode 100644 index 0000000..8f53300 --- /dev/null +++ b/_pages/docs/technote/smpt5.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/5/' +target_url: '/docs/technote/smartport/05/' +--- diff --git a/_pages/docs/technote/smpt6.md b/_pages/docs/technote/smpt6.md new file mode 100644 index 0000000..29d8509 --- /dev/null +++ b/_pages/docs/technote/smpt6.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/6/' +target_url: '/docs/technote/smartport/06/' +--- diff --git a/_pages/docs/technote/smpt7.md b/_pages/docs/technote/smpt7.md new file mode 100644 index 0000000..2d711d2 --- /dev/null +++ b/_pages/docs/technote/smpt7.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/7/' +target_url: '/docs/technote/smartport/07/' +--- diff --git a/_pages/docs/technote/smpt8.md b/_pages/docs/technote/smpt8.md new file mode 100644 index 0000000..8b6bd53 --- /dev/null +++ b/_pages/docs/technote/smpt8.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/8/' +target_url: '/docs/technote/smartport/08/' +--- diff --git a/_pages/docs/technote/smpt9.md b/_pages/docs/technote/smpt9.md new file mode 100644 index 0000000..93b85b0 --- /dev/null +++ b/_pages/docs/technote/smpt9.md @@ -0,0 +1,7 @@ +--- +layout: 'redirect' +title: '' +description: '' +permalink: '/docs/technote/smartport/9/' +target_url: '/docs/technote/smartport/09/' +--- diff --git a/_pages/docs/technote/technote11.md b/_pages/docs/technote/technote11.md index 7160998..58e84af 100644 --- a/_pages/docs/technote/technote11.md +++ b/_pages/docs/technote/technote11.md @@ -54,7 +54,7 @@ and a clock card.The information formerly in this Note, the proposed file format for Apple II -double high-resolution graphics images, is now covered in the Apple II Type Notes, File Type $08.
+double high-resolution graphics images, is now covered in the Apple II Type Notes, File Type $08.This Technical Note describes how to identify ProDOS devices and their -characteristics given the ProDOS unit number. This scheme should only be used -under ProDOS 8.
+This Technical Note describes how to identify ProDOS devices and their characteristics given the ProDOS unit number. This scheme should only be used under ProDOS 8.
-Changes since January 1990: Modified AppleTalk call code for -compatibility with ProDOS 8 versions earlier than 1.5 and network-booted -version 1.4.
+Changes since January 1990: Modified AppleTalk call code for compatibility with ProDOS 8 versions earlier than 1.5 and network-booted version 1.4.
There are various reasons why an application would want to identify ProDOS -devices. Although ProDOS itself takes great pains to treat all devices -equally, it has internal drivers for two types of devices: Disk II drives and -the /RAM drive provided on 128K or greater machines. Because all devices -really are not equal (i.e., some cannot format while others are read-only, -etc.), a developer may need to know how to identify a ProDOS device.
- -Although the question of how much identification is subjective for each -developer, ProDOS 8 offers a fair level of identification; the only devices -which cannot be conclusively identified are those devices with RAM-based -drivers, and they could be anything. The vast majority of ProDOS devices can -be identified, however, so you could prompt the user to insert a disk in -UniDisk 3.5 #2, instead of Slot 2, Drive 2, which could be confusing if the -user has a IIc or IIGS.
- -Note that for the majority of applications, this level of identification is -unnecessary. Most applications simply prompt the user to insert a disk by its -name, and the user can place it in any drive which is capable of working with -the media of the disk. You should avoid requiring a certain disk to be in a -specific drive since doing so defeats much of the device-independence which -gives ProDOS 8 its strength.
- -When you do need to identify a device (i.e., if you need to format media in -a Disk II or /RAM device), however, the process is fairly straightforward. -This process consists of a series of tests, any one of which could end with a -conclusive device identification. It is not possible to look at a single ID -byte to determine a particular device type. You may determine rather quickly -that a device is a SmartPort device, or you may go all the way through the -procedure to identify a third-party network device. For those developers who -absolutely must identify devices, DTS presents the following discussion.
+There are various reasons why an application would want to identify ProDOS devices. Although ProDOS itself takes great pains to treat all devices equally, it has internal drivers for two types of devices: Disk II drives and the /RAM drive provided on 128K or greater machines. Because all devices really are not equal (i.e., some cannot format while others are read-only, etc.), a developer may need to know how to identify a ProDOS device.
+ +Although the question of how much identification is subjective for each developer, ProDOS 8 offers a fair level of identification; the only devices which cannot be conclusively identified are those devices with RAM-based drivers, and they could be anything. The vast majority of ProDOS devices can be identified, however, so you could prompt the user to insert a disk in UniDisk 3.5 #2, instead of Slot 2, Drive 2, which could be confusing if the user has a IIc or IIGS.
+ +Note that for the majority of applications, this level of identification is unnecessary. Most applications simply prompt the user to insert a disk by its name, and the user can place it in any drive which is capable of working with the media of the disk. You should avoid requiring a certain disk to be in a specific drive since doing so defeats much of the device-independence which gives ProDOS 8 its strength.
+ +When you do need to identify a device (i.e., if you need to format media in a Disk II or /RAM device), however, the process is fairly straightforward. This process consists of a series of tests, any one of which could end with a conclusive device identification. It is not possible to look at a single ID byte to determine a particular device type. You may determine rather quickly that a device is a SmartPort device, or you may go all the way through the procedure to identify a third-party network device. For those developers who absolutely must identify devices, DTS presents the following discussion.
ProDOS 8 does not support an "ID nibble." Section 5.2.4 of the ProDOS 8 -Technical Reference Manual states that the low nibble of each unit number in -the device list "is a device identification: 0 = Disk II, 4 = Profile, -$F = /RAM."
+ProDOS 8 does not support an "ID nibble." Section 5.2.4 of the ProDOS 8 Technical Reference Manual states that the low nibble of each unit number in the device list "is a device identification: 0 = Disk II, 4 = Profile, $F = /RAM."
-When ProDOS 8 finds a "smart" ProDOS block device while doing its search of -the slots and ports, it copies the high nibble of $CnFE (where n is the slot -number) into the low nibble of the unit number in the global page. The low -nibble then has the following definition:
+When ProDOS 8 finds a "smart" ProDOS block device while doing its search of the slots and ports, it copies the high nibble of $CnFE (where n is the slot number) into the low nibble of the unit number in the global page. The low nibble then has the following definition:
ProDOS 8 Technical Note #20, Mirrored +
ProDOS 8 Technical Note #20, Mirrored Devices and SmartPort, discusses this kind of mapping in detail. It also presents a code example which gives you the correct device-driver entry point (from the global page) given the unit number as input. Here is the @@ -278,7 +245,7 @@ third-party network device.
Auxiliary-slot RAM disks are identified by convention. Any device in slot 3, drive 2 (unit number $B0) is assumed to be an auxiliary-slot RAM disk since ProDOS 8 does not recognize any card which is not an 80-column -card in slot 3 (see ProDOS 8 Technical Note +card in slot 3 (see ProDOS 8 Technical Note #15, How ProDOS 8 Treats Slot 3). There is a chance that some other kind of device could be installed with unit number $B0, but it is not likely.
@@ -376,10 +343,11 @@ This call returns the ASCII name of the device, a device type and subtype, as well as the size of the device. Some SmartPort device types and subtypes are listed in the referenced manuals, with a more complete list located in the Apple IIGS Firmware Reference. A list containing SmartPort -device types only is provided in SmartPort +device types only is provided in SmartPort Technical Note #4, SmartPort Device Types. +One fork of the identification tree comes to an end at this point. If the @@ -470,7 +438,7 @@ Changes and Minutia of Auxiliary Memory -