Hardware Design

When designing ISA Plug and Play, Plug and Play BIOS's, or other Plug and Play compatible hardware, the vendor must consider the supporting software requirements. The primary rule is that a logical device must be functionally independent.

If you need to maintain compatibility with existing driver sets, you must use the logical device breakdown and resource sets described in the following topics.

Logical Devices

The defined resource sets of the supported multimedia devices provide a logical device breakdown and account for the sometimes hidden dependencies inherent in the hardware design.

To determine if you should define a logical device, you must answer the question: "Does the resource set describe an independently functional device?" If yes, create a logical device. If no, you will need to merge these resources with the other components required to start and/or support this device.

The reason for this requirement is that there is no bus-independent method for a driver to determine the association of one logical device with another or which physical device contains the logical device. This reasserts the definition of a logical device: a logical device is functionally independent.

For example, a sound card could contain many functions: a 16-bit audio component (including internal FM synthesis and external MIDI), a joystick adapter, a SCSI adapter, and a second independent DAC for compatibility with other cards. The immediate response is to define a logical device for each of the functionally independent components. This is not necessary if the device is software-configurable, however. Instead of allowing each child component to configure the device independently, the parent retrieves the entire resource set and applies the configuration to the hardware. The Configuration Manager creates the child devices using subsets of the resources of the parent. Although this example is a special case, it serves the purpose of demonstrating the sometimes subtle dependencies of hardware devices.

Following is a list of general rules to use when determining if a resource set is an independent logical device:

Resource Organization

The following table contains specific resource ordering for specific components of each device.

Note

The resource sets for following multimedia devices are order dependent, particularly within a class of resource. The drivers included with Windows 95 parse the resource set based on class, size and ordinal of the resource.

The location of these components in I/O space is not a criterion for the parsing algorithm. This allows the device to "float" in I/O space when all optimal resource settings are in conflict.

Windows Sound System Resource Descriptors

Plug and Play implementations of the Windows Sound System designs should not include the "AutoSelect" range (for example: 530-533) in the base I/O resource descriptor. The reported range for the base address should be the CODEC only. Thus, a resource set for an ISA Plug and Play implementation of a WSS compatible device would contain:

• I/O size 4 for AD1848/CS4248 or compatible CODEC (534-537)
• I/O size 4 for YMF262 (388-38B)
• IRQ and DMA.

If the implementation provides additional hardware support for Sound Blaster compatibility and shares the DAC/ADC I/O path and IRQ/DMA resources with the WSS register plane (such as the Crystal Semiconductor CS4232 design), the resource set should contain both the CODEC and the Sound Blaster compatibility resources, as follows:

• I/O size 4 for AD1848/CS4248 or compatible CODEC (534-537)
• I/O size 4 for YMF262 (388-38B)
• I/O size 16 for Sound Blaster compatibility (220-22F)
• IRQ and DMA.

Again, please note that the above I/O resources structures are order-dependent. The standard device drivers shipped with Windows 95 handle the above cases correctly.

ESS AudioDrive Resource Descriptors

If your hardware implementation uses the ESS reference designs without modification, you may use the listed ESS device IDs as compatible device tags. However, if your implementation deviates from the ESS reference design, particularly with IRQ and DMA steering, you will need to create your own .INF files and include special IRQ/DMA steering information in these files. Please contact ESS Technology, Inc. or the Microsoft Hardware Vendor Relations Group for further information.

Shared Resources

When a design requires shared resources between functions such as an IRQ between the audio and SCSI functions on a PCMCIA design, the .INF file for the device implements multiple function definitions which allow child devices to be created from subsets of the parent's resources.

DSP Based Solutions

DSP-based solutions face numerous obstacles when implemented as ISA Plug and Play devices:

• The devices on a DSP based design tend to be dependent on the "parent" DSP device such that code must be present on the DSP for the various register planes to respond properly.
• DSPs are dynamic in nature. However, ISAPNP establishes a device with a static resource set.
• Because of the nature of Plug and Play, separate functions cannot have dependencies on other functions, because ISAPNP does not guarantee initialization order of the enumerated devices. The following statements support this claim:
  • Logical devices are, by definition, independent. There is no bus independent method to determine the association of a device node with a parent board.
  • Dependent components cannot determine when the supporting DSP initializes or relocates.
  • Dependent components do not receive notification when a supporting device is disabled.

The solution to these problems is to include all the resources in a single device function and using the multiple function support in Windows 95 to create the child devices from a subset of the resources. The "multiple function" specification, as described elsewhere in the Windows 95 DDK, allows a parent/child relationship between device nodes.

For an example of multiple function support, please investigate the parent/child relationships established in WAVE.INF for the Media Vision Pro Audio Spectrum 16 cards (device IDs *PNPB00D and *PNPB00E).

An alternative solution is to write a private enumerator for your DSP based device. Please contact the Microsoft Hardware Vendor Relationship Group for details.

Plug and Play BIOS Considerations

Be sure to register appropriate device IDs and resource structures in your Plug and Play BIOS for machines with on-board multimedia devices. In other words, just because an on-board device is compatible with Sound Blaster does not mean that the BIOS should report the *PNPB001 device ID.

To determine the appropriate IDs, first determine the chipset manufacturer (such as Analog Devices, Creative Labs, ESS, and so on) and then match the resource IDs using the table provided in . You may report the device ID from this table or you may register your own ID and report the device ID from the table as a compatible ID. However, if you register your own device ID and this ID is not included in the standard .INF files or is not included in the OEM's implementation of Windows 95, the user will be prompted with a dialog box and given the option to select the compatible device or select from a list of other devices.

If the device is partially software configurable (such as the Windows Sound System or ES688 and ES1688 reference designs), you have some options for the reported device structure:

• You may report only the fixed resources in the boot configuration and allow the Configuration Manager to fill in the remaining required resources determined by the dependent functions. The Configuration Manager will determine the highest priority and most feasible dependent function to fill.
• You may report all of the resources in the boot configuration and require a restart to apply a new configuration (this option is not recommended).

Note that BIOS is expected to configure these software configurable resources to match the resulting configuration.