|
Compatibility is one of the main reasons why environments such as the Windows NT and OS/2 2.x operating systems support SCSI-based CD-ROM hardware. However, if you want to use non-SCSI CD-ROM drives with them, you'll have to write your own device drivers. This article discusses how you code those drivers for Windows NT. Thanks to Corinne H. Godon of Neuron Data (Palo Alto, CA) for helping with the systems and software shown on the cover and elsewhere in this issue.
March 01, 1994
URL:http://www.drdobbs.com/embedded-systems/writing-non-scsi-cd-rom-device-drivers/184409198
Copyright © 1994, Dr. Dobb's Journal
Copyright © 1994, Dr. Dobb's Journal
Copyright © 1994, Dr. Dobb's Journal
Copyright © 1994, Dr. Dobb's Journal
The author is a product architect with Media Synergy in Toronto. He develops for embedded systems, GUIportability platforms, and device drivers. You can contact him at [email protected].
One advantage of SCSI interfaces is their high data-transfer rate--anywhere from 5 to 20+Mbytes/second. But when you consider the 300 Kbytes/second data-transfer rate typical of CD-ROM drives, you wonder, "Why bother?" The answer is, of course, compatibility. Although usually more expensive and often slower, standard interfaces such as SCSI do allow you to mix-and-match CD-ROM drives. Software development is also easier because you only support one standard. This explains, in part, why the initial release of Microsoft Windows NT and IBM OS/2 2.x only supported SCSI-based CD-ROM hardware.
However, there are still times when you'll want to use non-SCSI CD-ROM drives with these operating systems. For one thing, non-SCSI CD-ROM drives often sell for several hundred dollars less than their SCSI cousins. In other instances, you may already have a number of proprietary-interface drives and may not want to reinvest in new ones that provide essentially the same capabilities. Whatever the case, I'll present in this article a non-SCSI CD-ROM device driver for NT. But first, some background on CD-ROM formats and NT device drivers.
The physical format of audio CDs (detailed in the "Red Book" from Philips) is commonly referred to as the "CD-DA," or compact-disc digital-audio format. A CD-DA disc is divided into sectors, each containing 2352 bytes of audio data. Additionally, each sector contains 784 bytes of error-correction data and 98 control bytes. On all CD drives, these 784+98 bytes are handled exclusively by the read hardware.
During audio play of all audio CD drives and most CD-ROM drives, Red Book audio data is fed directly to decoding digital-to-analog conversion hardware. Consequently, direct computer reading of Red Book audio from audio CDs usually isn't possible. Some CD-ROM drive manufacturers make drives capable of directly accessing Red Book audio. This gives you the capability to enhance, manipulate, and edit commercial music.
While the Red Book describes the CD-DA format, the "Yellow Book" from Philips/Sony describes the recording format for digital computer data on CD-ROMs. Data on Yellow Book sectors is laid out in two "modes" based on the 2352 data bytes available on a CD-DA sector. Most currently available CD-ROM titles are recorded in Mode 1, which specifies 2048 bytes of user data, 288 bytes of error-detection/correction data, and 16 bytes of synchronization and header information; see Figure 1(a). Mode 1 sectors can be recorded on a disc containing CD-DA audio--a "mixed-mode disc." The first "audio track" of a mixed-mode disc is reserved for computer data recorded in Yellow Book Mode 1 sectors. Many popular multimedia titles, including Loom, 7th Guest, and Just Grandma and Me, use mixed-mode format to incorporate professionally recorded, stereo-CD audio tracks.
Mode 2 format is the base format for CD XA (Extended Architecture) discs. With this mode, 2336 bytes are available for user data on each sector. This means that the 288 bytes of Mode 1 error detection/correction is removed. Since the chance of uncorrectable error is higher, this mode is seldom used for raw computer data. Potentially, it can be used to store raw audio, image, or video information in which single-bit errors aren't critical. The XA format builds on this mode, making it more robust for handling data; see Figure 1(b).
The CD XA specification, specifically designed for multimedia, is an extension to the Yellow Book, although currently hardware which can handle the standard is lacking (CD-ROM drives and controllers). In the future, Kodak Photo CD, Philips Video CD, and the MPC 2 standard may create more demands for CD-ROM titles recorded in XA format. On top of a Yellow Book Mode 2 sector, the CD XA standard can record data onto the 2336 available user data bytes in two different forms. Form 1 has 2048 bytes of data, with an 8-byte leading subheader, and 280 bytes of error-detection/correction information; see Figure 1(c). Form 1 is typically used for storing computer data on XA discs and is similar to the Mode 1 format, with 2048 bytes of error-corrected data. The Form 2 specification replaces the 280 bytes EDC/ECC of Form 1 with only four bytes of error-detection data; see Figure 1(d). Lacking robust error-correction capabilities, Form 2 sectors are typically used for audio or video data only. The XA standard calls for ADPCM compression of audio data, and the playback is usually assisted by decoding hardware.
On an actual XA CD disc, Form 1 and Form 2 sectors can be interleaved--this is the XA's key advantage for multimedia applications. XA provides for interleaving of data with audio or video, allowing playback of high-quality multimedia content directly off the CD-ROM without expensive hardware configurations. Distinction between sectors of the two forms is typically handled via hardware by scanning the 8-byte subheader.
Since Mode 1, Mode 2, and XA sectors are based on the Red Book sector format, it's theoretically possible to use an audio CD mechanism for CD-ROM purposes. Some early CD-ROM drives took advantage of this. These designs quickly became obsolete because of the slow audio-mechanism access time (typically 600 milliseconds to 1 second) and the intensive software decoding necessary to extract data. Almost all CD-ROM drives use custom-designed CD-ROM mechanisms with fast seek times and hardware data detection.
The logical format of a CD-ROM specifies how files and directory structures are laid out over the physical sectors. The most commonly used logical format is the ISO-9660 standard. As a cross-platform standard, ISO-9660 CD-ROMs can be read by DOS, Macintosh, VMS, and UNIX workstations. Consequently, ISO-9660 inherits all the restrictions of the differing file systems, the most severe being the eight-character filename and eight-level directory restrictions. Since this is especially troublesome for UNIX, several UNIX-based companies have proposed an extension to ISO-9660 standard--the Rock Ridge Extensions. (For more on the Rock Ridge Extensions, see Lynne Jolitz's "Extending Standards for CD-ROM" in the July 1993 issue of DDJ.)
Full ISO-9660 provides enhancements including security, multivolume sets, and multiple-extent files (interleaving). In practice, most operating-system extensions (such as MSCDEX on MS-DOS) don't currently support these features. Consequently, few published CD-ROM titles use these enhancements.
Kodak introduced the Photo CD as its flagship product in the popular digital photography market. Anyone can get up to 100 photo prints stored on a digital Photo CD. Each picture is stored in six different resolutions, the highest approaching the definition of the original 35mm negative. Besides direct viewing of the photos on television, Photo CD can also be used to make prints and even to recreate the original negative. Photo CD discs can be read on XA-compatible CD-ROM drives, Philips CD-I systems, or consumer Photo CD players.
The Kodak Photo CD format is compatible with the CD XA specifications. The actual format is called "CD-I Bridge," and it is proprietary to Philips and its licensees. Photographs are digitized via high-resolution scanners and stored on the Photo CD in ISO-9660 format over CD XA Mode 2 Form 1 sectors. The actual disc medium is a writable compact disc. Unlike injection-molded "silver" CD-ROMs, Kodak Photo CDs are made with a gold substrate on pregrooved discs writable via a modulated high-power laser beam.
Multisessions allow you to add new files (photos) to the write-once medium each time you bring the Photo CD back to your photo finisher. Since the medium is not rewritable, the directory structure of the original disc can't be changed. However, on a multisessions Photo CD, a new directory structure of the entire disc is created as each new session is written to the disc. Multisessions-compatible CD-ROM drives will always seek and use the latest directory structure when referring to the content of the disc. Noncompatible drives will be able to read only the content of the original single session.
As Figure 2 illustrates, NT is a layered, packet-driven system in which every I/O request is represented as an I/O request packet. Since NT supports multiple operating-system environments via subsystems, I/O must be flexible and generic enough to handle demands from native NT, 16-bit Windows, DOS, OS/2, and POSIX applications.
To simplify device-driver design for layered device drivers, NT uses Filter, Class, Port, and Miniport drivers. Devices such as CD-ROM drives have common requirements which can be abstracted. The only code that absolutely needs to be rewritten for each device is the device-specific commands and protocol handling. Under NT, monolithic drivers (which handle a single device type/model or a list of specific devices, each requiring its own specific driver code) can be divided into cooperating-operating driver layers. For example, to control a SCSI CD-ROM device, you have a SCSI CD-ROM Class driver that handles generic, data-related CD operation common to all CD-ROM drives. To perform its task, the SCSI CD-ROM Class driver calls on the SCSI Port driver, which provides a high-level generic SCSI command send/retrieval interface, shielding any adapter-specific details from the Class driver. The Port driver also understands the SCSI protocol and its implementation. To control the device through a SCSI bus, the Port driver calls on the adapter-specific SCSI Miniport to implement the low-level send, signal control, and synchronization tasks that must be individually designed for each adapter. Additionally, the SCSI Miniport driver makes use of services provided by the SCSI Port driver to carry out its duties. In this way, the SCSI Miniport is wrapped and will be transparent to changes within the SCSI Port driver and the operating system. Figure 3 illustrates the relationship between the layered drivers.
The SCSI Port and Miniport driver stack can service any SCSI device other than CD-ROM, including hard disks, tapes, and the like. The CD-ROM driver only has to be written once for any combination of SCSI CD-ROM drive and adapter. In actual implementation, each SCSI CD-ROM drive may have its own unique features not found in other devices. This is especially true when it comes to nondata command handling.
Since the SCSI interface was designed to handle storage devices, the storage-device management command has become a de facto standard, and most CD-ROM devices comply with it. Extension commands (such as audio control, multi-session handling, and so forth) are a different story, as most drive manufacturers have their own extensions. Fortunately, the SCSI CD-ROM Class driver can handle this. However, this requires modifying the SCSI CD-ROM Class driver each time a new drive type is added. This approach is impractical since Microsoft retains ownership of the SCSI CD-ROM Class driver under NT. Thus was born the "CDAudio Filter driver," a collection of exceptions implemented as a middle-layer device driver and presented in this article. The function of the Filter driver (which sits between the I/O manager and the SCSI CD-ROM Class driver) is to recognize and intercept any device-specific commands and process them without passing them to the SCSI CD-ROM driver.
The upcoming SCSI 2 addresses the audio-control problem by providing audio-control commands. This means that SCSI 2-compliant CD-ROM drives will respond to the same set of audio-control commands, allowing implementation of such extension in the SCSI Port driver and freeing the SCSI CD-ROM Class or the CDAudio Filter.
The most obvious approach (and that recommended by Microsoft) is to hook into the layers at the lowest level. This means writing a Miniport driver to receive the SCSI command, decode it, handle the request, repackage the response into SCSI status blocks, and transmit it back to a SCSI Port driver--a software emulation of a SCSI adapter. While inefficient, this approach does have the advantage of operating-system independence. This is the approach I'll describe here.
This driver handles data-read operations for ISO-9660 Mode 1 discs and is sufficient for installing Windows NT from the distribution CD-ROM. For this purpose, the driver will also assume that the CD-ROM is inserted into the drive before the driver is started, and that there'll be no CD changes during the operation of the driver.
The Windows NT installation procedure consists of an initial text setup during which the user boots the setup floppy disk, which in turns loads in the minimal keyboard, mouse, video, machine/HAL, disk, and SCSI drivers. This is where you install this CD-ROM driver. TXTSETUP.OEM, the file which provides the NT setup program with information concerning the Miniport driver, is an ASCII script file included with the Windows NT DDK.
Once the drivers are loaded, the setup procedure lets you prepare the hard disk and select location for installation of Windows NT. After this, the setup program copies a working set of files from the CD onto the Windows NT partition. My CD-ROM driver will also be copied during this process. Upon completion, the hard-disk version of Windows NT can be booted to continue the second phase of installation where NT is booted from the hard disk and the driver is loaded in the operating system. The setup program then prompts you to select the remaining installation option. Finally, the rest of the NT system files are copied from the CD onto the hard disk.
The driver consists of CDNOW.C, (Listing One, page 110) which contains common device-independent code identical to drivers on any CD-ROM drive, and CDREAD.C, which contains code specific to the drive. In this case, the code is specific to the Panasonic/MKE CR522b drive. This approach isolates the code that must be changed when adapting the code for other drivers so that only CDNOW.H and CDREAD.C need to be modified. The Panasonic CD-ROM drive controller is typically configured as four I/O port locations which map into the registers in Table 1. The drive and controller support only the polling mode of data transfer. CDREAD.C and other relevant files and programmer notes are available electronically; see "Availability," page 3.
To initially determine where the drive is installed, the CDREAD.C routine LocateAdapterSpecific() scans all the legal I/O locations, looking for the actual address of the drive. It then allocates the address from NT before accessing it, and frees it if the drive isn't found at a specified location.
CDNOW.C contains routines which follow the classic SCSI Miniport format. Microsoft provides various Miniport source-code examples with the Windows NT DDK which can be used as reference. Since we aren't actually dealing with an SCSI device, we will have to provide emulation at the appropriate spot. By design, we'll only deal with data reads; other function requests are left as unimplemented.
When Windows NT loads the driver, DriverEntry is called. For a SCSI Miniport driver, the routine initializes the function tables with the Initialization(), StartIo(), Interrupt(), FindAdapter(), and ResetBus() function pointers. It also allocates and initializes a private area in the device extension for storage of private data. The last thing the routine does is call ScsiPortInitialize() (supplied by the SCSI Port driver) and return the status.
When ScsiPortInitialize() is called, the Port driver enumerates the adapters, resets them, and locates all the devices on each adapter. It does this by calling the functions registered in the functions table. FindAdapter initializes required system data structures, and calls findAdapterPort() which in turn calls LocateAdapterSpecific() in CDREAD.C to locate the adapter.
Once the adapter is located, NT calls StartI/O() with various SCSI requests. These comes in the form of SCSI Request Blocks (SRBs). Within StartI/O(), we must emulate the action of a SCSI host-bus adapter and a connected SCSI CD-ROM drive.
For the purposes of this driver, it's sufficient to handle Bus Reset, Inquiry, Read Capacity, and Read Data requests. The current Bus Reset function does nothing, but may be modified to reset the CD-ROM drive. For the Panasonic drive, this isn't necessary since the drive is reset via hardware each time the system restarts.
In handling the Inquiry request, you must emulate the existence of a CD-ROM drive at a specific SCSI target ID. In the emulation, the target ID of 3 is used. For Read Capacity requests, return a hardcoded capacity for a CD-ROM disc. Since not all drives support the read-capacity command, you don't have to call Panasonic's read-capacity command.
For Read Data requests, ReadCDRom() is called. This decodes the read request and converts it to a form usable by CDRead() in CDREAD.C. To keep the driver design simple, each read request is completed immediately. The CDRead() function issues the command, waits until the data becomes available, and fills the data buffer with the requested sector before returning.
Every request that we handle in StartIo() is completed synchronously. In situations where interrupts and/or DMA are used, it's possible to return a request pending status that allows the system to proceed with other tasks while data is being read. In these cases, the interrupt-service routine must queue a deferred-processing routine where the data can be transferred into the buffer area and the request packet can be completed via ScsiPortNotification(). Queuing of request is handled by the I/O Manager/SCSI Port driver in these cases.
The driver presented here is for installing the operating system. To modify it for normal data access, device-state changes must be tracked and handled carefully. Requests, other than data read from higher-level software, must also be considered.
For example, all audio functions can be implemented. To track device-state changes, there are a total of five different types of popular CDs: audio only, data only, data and audio mixed mode, XA single session, and XA multisessions. The driver should theoretically handle all changes from one CD to another, as well as tracking changes of CD of the same type. This gives a total possibility of 120 state changes. To code a robust driver, all 120 cases should be handled and tested individually. In reality, typical drivers handle only a couple of dozen cases via ad hoc design.
SCSI Miniport emulation is only one way of implementing the driver. It's also possible to replace the entire SCSI Filter/Class/Port/Miniport stack with a single monolithic driver, or to design your own CD class/IDE port/IDE miniport driver stack. Such designs can be much more attuned to the actual hardware controlling the device. They can stand to gain in configuration flexibility and performance.
(a) 16 bytes Sync Header + 2048 bytes User Data + 288 bytes EDC/ECC data = 2352 bytes (b) 16 bytes Sync Header + 2336 bytes User Data = 2352 bytes (c) 8 bytes subheader + 2048 bytes data + 280 EDC/ECC data = 2336 bytes (d) 8 bytes subheader + 2324 bytes data + 4 bytes EDC data = 2336 bytes
I/O Port Read Write --------------------------------------------------------- Base Port Status code register Command register Base Port+1 Hardware status bits Not used Base Port+2 Data register Hard reset Base Port+3 Not used Configuration
Copyright © 1994, Dr. Dobb's Journal
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.