Method and Apparatus for Allowing Communication Between a Host Computer and at Least Two Storage Devices Over a Single Interface

This present invention relates to data archival systems for use with computer systems and, more specifically, to a tape backup system compatible to be coupled with a hard disk controller on, for example, an IBM PC/AT or compatible.

Virtually anyone who uses a computer system, and especially, a personal computer system, has considered the possibility of some hardware failure making data stored on that system inaccessible. The unfortunate among us have not only considered the possibility, but have had the possibility become a reality. Due to this possibility, it is today commonplace to employ some backup (or archival) system to periodically copy data stored in the computer system in order that the data may be restored at a later time in the event of such a hardware failure. In the personal computer world, most commonly, the backup system either employs so-called "floppy disks" onto which data is transferred, through the computers floppy disk drives, for storage or a tape drive which is coupled to the computer and which allows data to be communicated between the computer and tape drive for recording onto a tape medium (e.g., magnetic or optical tape).

In personal computers, such as the IBM PC and compatible family, known tape drives are coupled with the computer through a floppy disk interface. This design is employed largely to save the cost of requiring a separate controller for the tape drive and to avoid occupying one of the computer's slots with a separate tape controller. However utilizing the floppy controller as an interface presents certain problems in the operation and design of a backup system. For example, in the typical IBM PC or compatible, a floppy drive controller is capable of supporting up to two separate drives. Using one of the slots on the floppy drive controller to interface with a tape drive may be undesirable. Further, use of the floppy drive controller allows for a relatively slow interface data rate, e.g., 500 kilobits per second (Kb/s). Present day disk controllers may provide for relatively faster interface data rates, e.g., 5 or more megabits per second (Mb/s). Therefore, it is desired to provide for coupling of a tape drive to a controller having a interface data rate more compatible with present day disk controllers.

Therefore, as one object of the present invention it is desired to provide a tape drive design which allows interfacing a tape drive to a computer system without need to interface through the floppy controller.

It is, of course, possible to provide for interfacing of a tape drive through a separate and relatively faster interface. However, in computer systems such as may utilize the preferred embodiment of the present invention, a separate interface requires use of one of a limited number of "card slots" on the motherboard of the computer system. Users of such computer systems generally prefer to avoid use of card slots whenever possible so that the card slots may be saved for other uses.

Therefore, as a second object of the present invention, it is desired to provide an interface for a tape backup system which does not require use of a separate card slot for interfacing with the host computer.

Recently, an interface has been developed known as the Intelligent Device Electronics (IDE) interface. The IDE interface typically allows for interfacing of at least two hard disk drives, each having an embedded controller. In typical operation, one disk drive may be addressed by the host computer through standard operating system routines in order to access data on that drive. During the time when the disk drive is executing the command to access data, the drive sets a bit indicating the interface is busy, preventing the host computer from issuing additional commands over the interface (e.g., a command to write data to the second device). Therefore, the IDE interface, utilizing standard operating system commands, is relatively incompatible with attempts to couple a tape drive to the device for purposes of "backing up" a disk drive coupled with the interface.

It is therefore, an object of the present invention to provide apparatus and methods for interfacing a tape drive with an IDE interface and to allow simultaneous operation of a disk drive and the tape drive coupled with the interface.

Finally, embedded controller circuits on present day disk drives designed for coupling with the IDE interface typically comprise standard, off-the-shelf, disk controller circuits, such as the Cirrus Logic CL-SH-260 disk controller circuit. It is desired to develop a tape drive utilizing standard, off-the-shelf, disk controller circuits. However, certain incompatibilities exist between outputs provided by such circuits and formats compatible for writing to industry standard tapes.

Therefore, as another object of the present invention, it is desired to provide circuitry for adapting outputs of standard, off-the-shelf, disk controller circuits to provide data compatible for writing industry standard tape formats.

A data archival system is disclosed which is especially useful in computer systems, for example, in computer systems known as IBM PC's and compatibles therewith. The data archival system preferably comprises a tape backup device coupled with an Intelligent Device Electronics (IDE) interface such as may be available on an IBM PC/AT or compatible.

In particular, the present invention teaches a computer system having an interface for interfacing with at least a first storage device and a second storage device. Preferably the first storage device comprises a disk drive or similar random access storage apparatus. The second storage device preferably comprises a tape drive or similar data archival device. The first storage device comprises a first indicator having a first state for indicating the device is executing a command and a second state for indicating the device is not executing a command. The second storage device comprises a second indicator having a first state for indicating the second device is receiving information over the interface and a second state for indicating the second device is not receiving information over the interface.

Thus, the second device may receive information over the interface and during a period of time associated with receiving the information the second indicator may be in its first state thereby indicating the second device is receiving data. Upon completion of receiving the information, the second indicator may change states to indicate the second device is no longer receiving data. The second device may subsequently process the received information, such as by preferably accessing a storage medium such as tape and either reading or writing information thereto. At the same time, a command may be communicated to the first storage device over the interface; responsive to receiving the first command, the first storage device may set the first indicator means to a first state to indicate it is processing the command. For example, the command may instruct the device to read data from a disk storage media. Upon completion of the command, the first indicator means is returned to a state indicating the first storage device is not executing a command.

It is taught that the second device may continue executing a command after having completed receipt of information through the interface and after having set the second indicator to indicate completion of receipt of such information. For example, the second device may have received a command to write data to tape and, further, the second device may have received such data, for example, into a buffer memory. Subsequent to having received such a command and data, the second device may set its indicator to indicate it has completed receipt of the information and a processor may then direct a command to the first device to read data from a disk. The second device may then continue the process of writing data to tape simultaneously with the first device reading information from disk. Importantly, this simultaneous operation is accomplished while having both the first and second device coupled with a single interface.

The present invention further discloses use of a data archival application process for managing access to an interface having coupled thereto a disk drive and a tape drive wherein the application process initially replaces interrupt vectors pointing to standard ROM BIOS disk service routines with vectors pointing to routines in the data archival application. The application is then able to manage access to the disk service routines. Specifically, during operation the data archival process may call an operating system routine to, for example, read data from the disk for archival onto the tape. The operating system routine attempts to access the disk service routine through the appropriate intercept vector. However, as taught by the present invention, the application has replaced the address in the intercept vector with an address a routine in the archival application. Therefore, the data archival application intercepts the call to the disk service routine. The data archival application then switches control of the interface from the tape drive to the disk drive and then calls the ROM BIOS disk service routines.

In this manner, the data archival application may control simultaneous operation of the disk and tape drive while utilizing the ROM BIOS disk service routines to ensure compatibility.

In addition, a format adapter circuit is disclosed which advantageously allows use of industry standard disk controller circuits in a tape drive and provides for adapting output signals of such disk controller circuits to a format compatible with industry standard tape formats.

These and other aspects of the present invention will be better described with reference to the Detailed Description of the Preferred Embodiment and the accompanying Figures.

FIG. 1 is a block diagram illustrating a computer system as may be utilized by the present invention.

FIG. 2 is a block diagram illustrating coupling of a host computer through an IDE (Intelligent Drive Electronics) interface to a tape drive and a disk drive as is taught by the present invention.

FIG. 3 is a block diagram illustrating components of a tape drive of the present invention.

FIG. 4 is a block diagram further illustrating certain components of a tape drive of the present invention including a controller circuit, an IDE interface, a microprocessor, a RAM and a write/read interface.

FIG. 5 is a diagram illustrating contents of a task file as may be implemented by the present invention.

FIG. 6 is a diagram illustrating contents of a write control store as may be utilized by the present invention.

FIG. 7(a) is an illustration of an encoder circuit and corresponding timing information as may be utilized by the present invention.

FIG. 7(b) is an illustration of an decoder circuit and corresponding timing information as may be utilized by the present invention.

FIG. 8 is a flow diagram illustrating an overall process for backing up a hard disk drive as may be utilized by the present invention.

FIG. 9 is a flow diagram illustrating a backup loop of the backup process as may be utilized by the present invention.

FIG. 10 is a flow diagram illustrating a method for reading information from disk as may be utilized by the present invention.

FIG. 11 is a flow diagram illustrating a data restore process as may be utilized by the present invention.

FIG. 12 is a flow diagram illustrating a restore data loop as may be utilized in the data restore process of the present invention.

FIG. 13 is a flow diagram illustrating a method of writing information to a disk as may be utilized by the present invention.

FIG. 14 is a diagram illustrating DOS address space as may be configured by the present invention.

FIG. 15 is a flow diagram illustrating a prior art method of executing commands by a disk drive.

FIG. 16 is a flow diagram illustrating a method of the present invention for executing commands by a tape drive.

A tape backup system is described. In the following description, numerous specific details are set forth such as specific circuits, etc., in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to unnecessarily obscure the present invention.

The Computer System of the Preferred Embodiment

The overall computer system of preferred embodiment is described with reference to FIG. 1. The preferred embodiment of the present invention is implemented on one of members of the IBM Personal Computer family or computer systems compatible with members of this family. In particular, the computer system of the present invention is implemented on a IBM PC/AT or compatible implementing the Intelligent Drive Electronics (IDE) interface 107 (also known as the "AT-Drive" interface or the ATA (AT attachment) interface. The IDE interface will be discussed in greater detail below. It will, of course, be obvious to one of ordinary skill in the art that any number of other computer systems may employ the teachings of the present invention.

In any event, a computer system as may be utilized by the preferred embodiment generally comprises a bus or other communication means 101 for communicating information, a processing means 102 coupled with the bus 101 for processing information, a random access memory (RAM) or other dynamic storage device 104 (commonly referred to as a main memory) coupled with said bus 101 for storing information and instructions for said processor 102, a read only memory (ROM) or other static storage device 106 coupled with said bus 101 for storing static information and instructions for said processor 102, an interface 111 for allowing coupling of data storage devices, such as hard disk 107 (in addition, as will be seen, a data archival device such as a tape drive may be coupled with the interface), with the bus 100 for storing information and instructions, a display device 122, such as a cathode ray tube, liquid crystal display, etc, coupled to the bus 101 for displaying information to the computer user, an alphanumeric input device 125 including alphanumeric and other keys coupled to said bus 101 for communicating information and command selections to said processor 102, and a cursor control device 127, such as a mouse, track ball, cursor control keys, etc, coupled to said bus 101 for communicating information and command selections to said processor 102 and for controlling cursor movement. Finally, it is useful if the system includes a hardcopy device 129, such as a printer, for providing permanent copies of information. The hardcopy device 129 is coupled with the processor 102, main memory 104, static memory 106 and mass storage device 107 through bus 101.

The processor 102 of the preferred embodiment is one of the 80.times.86 microprocessor family manufactured by Intel Corporation of Santa Clara, Calif. In the preferred embodiment, the system is operated using a standard IBM PC-compatible operating system such as MS-DOS available from Microsoft Corporation of Beaverton, Oreg.

It will be apparent, from an understanding of the present invention from the below description, that several of the above-mentioned components of the computer system of the preferred embodiment are not essential to operation of a computer system employing aspects of the present invention. For example, as will be described in more detail below, the display 122, keyboard 125, cursor control device 127, and hard copy device 129 may not be present in certain implementations.

The IDE interface has evolved from earlier hard disk interfaces in which a hard disk adapter card, including a controller, was installed in a "slot" of a computer system. Such hard disk adapter cards are typically capable of supporting up to two hard disk drives, although only one drive may be written to or read from at a time. The two drives interface to the card through an interface known as the ST506 interface. More recently developed hard disk drives comprise an embedded controller and processor removing the requirement for the adapter card to include its own controller. The interface allowing for use of embedded controllers in a hard disk is known as the IDE or Intelligent Device Electronics interface. The programming model and command codes for the IDE interface are the same as for the ST506 interface; however, as controllers are embedded in the drives themselves, the IDE interface must allow for two controllers to be coupled with the interface and must provide for proper management of information transferred. To manage access to the drives, the IDE interface depends on a status bit (the BUSY bit) in a set of registers (the "task file") associated with each drive. The task file 500 and the BUSY bit 521 of the preferred embodiment are described in greater detail below with reference to FIG. 5.

FIG. 2 illustrates in somewhat greater detail the coupling of a data archival device 108 and a hard disk storage device 107 with an IDE interface 111 of a host computer 201. In particular, the data archival device 108 and hard disk storage device 107 are both coupled to communicate data with the host computer 201 over data lines 202. The preferred embodiment provides 16 lines for communication of data between the host computer 201 and devices 107 and 108. In addition, devices 107 and 108 are coupled to receive 3 bits of address information on lines 203 and to receive control information on line 204 through interface 111. The control information comprises read/write strobes, chip select control information and ready signals.

Finally, the devices 107 and 108 are coupled to provide interrupts to the host computer through interface 111 on line 205.

The circuitry of the data archival device 108 of the preferred embodiment is described in greater detail with reference to FIG. 3. FIG. 3 illustrates the device 108 comprises a connector 301 for coupling with the IDE interface 111 of the host computer 201. The connector 301 is preferably a 40-pin connector and comprises 16 data pins for communicating data information between a controller circuit 302 of the device 108 and the interface 111 of the host computer 201; 3 address pins for receiving address information from the host computer 201 for communication to the circuit 302; a control pin for receiving control information from the computer 201 for communication to the circuit 302; an interrupt pin for signalling interrupts generated by the circuit 302 to the computer 201; and a ready signal line for communicating ready status to the computer 201.

The controller circuit 302 is responsible for communicating information with the host computer over connector 301; for managing access to RAM buffer 303; and for formatting data to be written by the device. In the preferred embodiment, part number CL-SH260 Hard Disk Controller available from Cirrus Logic, Inc. of Milpitas, Calif. is utilized. However, in alternative embodiments it is recognized that alternative circuitry may be utilized. For example, functions of the CL-SH260 may be implemented in discrete circuitry, in a gate array or in a programmed logic array. Further, alternative commercially available circuits may be employed which provide similar or compatible circuity. For example, part number AIC-6060 hard disk controller available from Adaptec may be substituted as a compatible part.

The controller circuit 302 is illustrated in greater detail with reference to FIG. 4. As previously stated, the controller circuit 302 provides the functions of interfacing with the host computer through host interface section 402; of providing for buffer management of RAM buffer memory 303 through buffer manager section 404; and of providing for formatting data through formatter section 403. The particular workings of each of these sections will be well understood by one of ordinary skill in the art, especially with an understanding of the CL-SH260 controller circuit as utilized by the present invention. Further information on the CL-SH260 controller is available from Cirrus Logic, Inc. as CL-SH-260 Integrated PC XT/AT Disk Controller Data Sheet and Application Notes AN-SHI & AN-SH5. However, it is worthwhile to discuss here that the controller 302 provides registers for the task file 500 as part of host interface 500. The task file register 500 will be described in greater detail below with reference to FIG. 5. Additionally, formatter section 403 provides a writeable control store circuitry 409 for storage of control information. Write control store 409 will be discussed in greater detail below with reference to FIG. 6.

The controller circuit 302 is coupled to communicate control, data and interrupt information with processor 304 and gate array 307. Processor 304 and gate array 307 are provided to control the drive electro-mechanics such as circuitry for controlling tape movement. In the preferred embodiment, the processor 304 is an Intel 8052 microprocessor. Again, it will be apparent to one of ordinary skill in the art that alternative embodiment may employ alternative processing means to provide for control of the controller circuit 302.

In addition to providing for control of the drive electro-mechanics, processor 304 is programmed, via 32K ROM 305, to provide certain control over controller circuit 302. Of particular interest to the present invention, and as will be discussed in greater detail below, processor 304 is programmed to set the BUSY bit whenever information (i.e., a command or data) is being received over the interface and to clear the BUSY bit after the information has been received.

The formatter section 403 of controller 302 is further coupled to provide output information to encoder 311 and to receive input information from decoder 312. In the preferred embodiment, controller 302 is designed to provide output information to encoder 311 and to receive input information from decoder 312 in a format commonly referred to as modified FM or MFM. Encoder 311 is provided to convert the MFM information to non-return to zero (NRZ) format in a well known fashion. Decoder 312 is provided to convert NRZ information back to MFM information for presentation to the controller 302, again in a well known fashion. Encoder 311 and decoder 312 are implemented as programmed logic arrays in the system of the preferred embodiment. Although it is known in prior art hard disk drive systems to provide circuitry for encoding MFM signals and decoding NRZ signals, certain advantages of the encoder 311 and decoder 312 allowing for use of the circuitry of the present invention with a data archival system and, specifically, with a tape drive format as utilized by the preferred embodiment. These advantages will be described in greater detail below with reference to FIGS. 6, 7(a) and 7(b).

As can be seen with reference to FIG. 5, the task file 500 of the preferred embodiment of the present invention comprises ten separate eight-bit registers which may be referred to as (1) the status register 501; (2) the alternate status register 502; (3) the drive select register 503; (4) the error code register 504; (5) the segment number (low) register 505; (6) the segment number (high) register 506; (7) the segment count register 507; (8) the mode register 508; (9) the data register 509; and (10) the digital input register 510.

The status register comprises eight indicator bits. Of particular interest to the present invention is the BUSY bit 521 (bit 7 counting from bit 0 at the right). In a typical disk drive operation in the prior art, at the beginning of a command sequence, the BUSY bit 521 is set under the control of a local processor. The BUSY bit 521 remains set until completion of an operation. During the time period when the BUSY bit 521 is set, the host computer is not allowed access to the remaining registers in the task file 500. Further, the host computer may not access any other device coupled with the IDE interface during the time period when one controller coupled with the bus has its BUSY bit 521 set. In essence, the BUSY bit 521 is used as a collision avoidance mechanism and it is assumed in prior art systems utilizing the IDE interface that it is not desirable, and in fact, it is not allowed, to access two devices coupled with the IDE interface simultaneously. After the BUSY bit 521 is cleared, the controller is not allowed to change the contents of the remaining registers of the task file 500. Thus, it is understood that, in prior art systems, the use of the BUSY bit 521 as a contention avoidance mechanism prevents access to one device coupled with an IDE interface when a second device, also coupled with the same IDE interface is busy executing a command. In essence, the interface simulates a situation in which a single controller is available to control access to both devices.

It should be noted that the IDE interface allows for one special case, the SEEK command, in which the controller clears the BUSY bit 521 after beginning execution of the command and prior to its completion. Therefore, a second drive coupled with the IDE interface may be accessed while the SEEK command is executing. Implementation of this special case in the IDE interface requires use of a special status bit (SEEK Complete) in the task file of the disk drive.

As will be seen, the present invention provides capability for simultaneous reading and writing access to a data archival device and a hard disk, both attached to a single IDE interface of a host computer.

The status register is also used as a command register and is written with the command to be executed.

The drive select register 503 is written by the host computer to select either one of the two drives coupled with the IDE interface before programming of the task file registers and issuing commands. In the preferred embodiment, a hard disk drive may be attached as drive 0 (also referred to as the "master") and a tape drive may be attached as drive 1 (also referred to as the "slave"). In certain embodiments, such as a system with a secondary IDE channel, the tape drive could be coupled as drive 0. Use of the BUSY bit will be discussed in greater detail below.

In the preferred embodiment, a drive select bit 522 (bit 4 counting from bit 0 being the far right hand bit) is set or cleared to select the desired drive. The remaining bits (bits 0-3 and 5-7) are not used in current implementations.

The alternate status register 502 is identical to the status register 501; however reading the alternate status register does not acknowledge and clear interrupt requests which are acknowledged and cleared by reading the status register 501. This register is useful where it is desired to be able to inquire into the device status without losing a pending interrupt.

The error code register 504 is a two field register indicating error information: an error report pending status bit and a 7-bit error code.

The data register 509 is utilized to allow direct interface with the tape controller's buffer management logic to allow reads or writes with the drives buffer RAM memory.

The Segment Count Register

The segment count register 507 is loaded with a segment count prior to issuing a read or a write command. If a count of zero is loaded, it is interpreted as an indefinite count and the command will continue until terminated by another command. During the transfer of data, the segment count is updated by the tape drive after each segment is transferred, unless an indefinite count is specified.

The Segment Address Registers

The segment address registers 505 and 506 are loaded with a beginning segment address prior to reading or writing to the tape. The segment address is a 16-bit value with the low order eight bits stored in register 505 and the high order eight bits stored in register 506. During multiple segment read and write operations, the segment address is incremented as each transfer is completed.

The Mode Register

The mode register 508 comprises a set of bits to control and report operational modes of the tape drive of the preferred embodiment including a format code, length of tape code, tape cartridge present code, tape cartridge write protected code, interrupt mode select, and a data packing method code.

Prior art methods of operating data archival devices in, for example, an IBM PC or compatible, provide for coupling the tape drive through a interface separate from the interface for the hard disk. For example, it is common to couple a tape drive to a floppy disk interface. In this way, one interface is available for allowing access to the disk drive while a separate interface is available for allowing access to the tape drive. In this arrangement, the respective interfaces may operate to allow simultaneous operation of the tape and disk drives. However, in certain computer systems it is desirable for a number of reasons to allow for coupling of both a tape and disk drive through a single interface.

Therefore, as one aspect of the present invention it is disclosed to allow coupling of both a tape drive and a disk drive to a single interface while providing for simultaneous operation of both the tape and disk drive.

Known devices (e.g., disk devices) which interface with the IDE interface operate by setting their BUSY bit in their status register when the device is executing a command. A well-known processing utilized by disk drives which interface with the IDE interface is illustrated with reference to FIG. 15. First, the host processor sets the drive select bit 522 to select the disk (e.g., in a typical configuration, the host processor sets the drive select bit to 0), block 1522. The host proceeds to program the task file registers of the disk drive to execute the command, block 1502. After the task file registers are programmed by the host, an on-board processor on the drive sets the BUSY bit 521 and begins executing the command. Execution of the command may include communicating (e.g., reading or writing) information over the interface. For example, data to be written to the disk may be communicated by the host processor over the interface to the disk drive. The disk drive may initially accept the data into a buffer memory and then retrieve the data from the buffer memory for writing to disk. Typically, the buffer memory is a higher speed device than the disk itself and, therefore, the host computer may complete transmission of the information before the drive completes execution of the command to write the data to disk. In any event, eventually the disk completes execution of the command, block 1505. Upon completion of the command, the on-board processor clears the BUSY bit, block 1506.

During the period the BUSY bit was set (i.e., from block 1503 through block 1506), the host processor is prevented from accessing registers 503-509 of the task file registers on both the disk drive and tape drive. As a result, during the period in time when the disk drive is executing the command, even after it may have received all necessary information over the interface, the host computer is prevent from accessing the tape drive.

FIG. 16 illustrates a method of the present invention for processing commands to the tape drive. Similar to the discussion in connection with FIG. 15, the host processor initially sets the drive select bit to select the tape drive, block 1601, and the host processor programs the tape drives task file register, block 1602. The tape drives on-board processor then sets the BUSY bit 1603 and begins executing the command. For example, the command may be a request to write information to tape, in which case, information is communicated by the host processor, over the interface, to the tape drive, block 1604. After completion of communicating information over the interface, the tape drives on-board processor clears the BUSY bit, block 1605. In the exemplary case of a request to write information to tape, the tape drive may accept information to be written over the interface and temporarily store the information in a relatively high speed buffer memory prior to the information being written to tape. Therefore, the tape drive may not have completed processing of the command prior to clearing the BUSY bit. In any event, at some point in time the tape drive completes execution of the command, block 1606; however, as has been explained, the BUSY bit has been cleared prior to completion of execution of the command. In this way, the host may begin communications with the disk drive while the tape drive completes execution of the command "off-line".

The process of backing up and restoring information in the system of the preferred embodiment will be explained in greater detail with reference to FIGS. 8-14.

FIG. 8 is an overall flow diagram of a backup (or data archival) process as may be utilized by the present invention. In the preferred embodiment, an application program is provided to manage the backup process. The application program is initialized in any of a number of well-known manners, block 801. For example, a user may input a command into the host computer to initialize or start-up the application process.

When the application program initializes it determines and stores the addresses of interrupt vectors for the system hard disk interrupt (referred to as INT 14 in the MS-DOS operating system) and the ROM BIOS hard disk service routine (referred to as INT 13 in the MS-DOS operating system). The application program then installs the address of certain of its own routines in place of the addresses of the interrupt vectors; effectively the application program takes control of the disk service routines, block 802. This may be better understood with reference FIG. 14.

FIG. 14 illustrates certain portions of the address space in an MS-DOS system. The address space includes certain interrupt vectors 1401 including a hard disk interrupt vector (hardware interrupt vector 1402) and a ROM BIOS hard disk service vector (INT 13H vector 1403). During typical operations, vector 1402 is an address pointer to the ROM BIOS disk interrupt handler 1423 in the ROM BIOS code 1421 and vector 1403 is a pointer to ROM BIOS INT 13 disk services handler 1422, again in the ROM BIOS code. However, as mentioned above, when the tape application program initializes, interrupt vector 1402 is changed to point to an interrupt handler routine 1413 in the tape application program 1411 and interrupt vector 1403 is changed to point to a "gatekeeper" routine 1412 in the application program 1413.

As will be explained in greater detail below, these routines allow the application to have its own driver routines for interfacing with the tape drive and to use the ROM BIOS routines for accessing the disk.

The "gatekeeper" routine 1412 ensures that when the operating system (MS-DOS) is accessing the disk, all hardware interrupts are directed to the ROM BIOS's routines for servicing and when the disk is not being accessed, the IDE bus is available for tape drive commands and interrupts.

The IDE interrupt gatekeeper and tape drive interrupt function 1413 allows the application to redirect the hardware interrupt vector 1402 to point to the disk service routine when disk drive operations are being performed and to use the applications own interrupt routines when the tape operations are being performed.

Referring back to FIG. 8, the application program then issues a command to the tape drive to write data to tape (i.e., to backup data) by programming its task file registers, block 803. The application then directs archiving of data from the disk drive to the tape drive by reading data from the disk, blocking the data into 32K blocks, and transferring the data to tape. These functions will be explained in greater detail with reference to FIGS. 9 and 10.

Upon completion of the archival process, the application releases control of the disk service routines by writing the stored addresses for vectors handlers 1422 and 1423 back to vectors 1402 and 1403, respectively, block 805. The application then terminates, block 806.

Referring now to FIG. 9, the processing of backing up data from the disk is essentially a loop in which, first, data is read from the disk, block 901; assuming there is more data to read, block 902, the data is blocked into 32K blocks and transferred to the tape drive, block 904. The process of reading data from the disk is explained in greater detail with reference to FIG. 10. This process essentially entails the "gatekeeper" process referred to earlier. Initially, the application program uses operating system calls, in the conventional manner, to request data be read from the disk. The operating system calls attempt to call the disk service routine (INT 13) at the address given by vector 1403. As discussed earlier, the application program had previously replaced the address of INT 13 with the address of gatekeeper function 1413. Therefore, the call to the disk service routine is intercepted by the application program, block 1003.

The application program then switches access to the IDE bus from the tape drive to the disk drive (the state of the drive select bit in the drive select register of both the tape and disk drive is inverted, e.g., changed from a 1 to a 0). The tape drive is then disabled from accepting further data transmitted on the bus by clearing the data request status bit 523. In this way, the tape drive is controlled to prevent it from mistakenly accepting data transferred on the interface from the disk drive to the host computer.

As previously noted, the application program has stored the address of the ROM BIOS INT 13 disk services routine. At this point, having disabled the tape from receiving further data and having set the disk select bit 521 to allow the disk drives task file registers to be programmed, the application program calls the ROM BIOS INT 13 disk services routine to initiate transfer of data from the disk to the host. The ROM BIOS INT 13 routine programs the disks task file registers and the disk begins execution of the command. As discussed previously with reference to FIG. 15, the disk will set its BUSY bit prevent other accesses to the bus during the time it is executing the command. Upon completion of execution of the command, the disk clears the BUSY bit and the ROM BIOS INT 13 routine returns control to the operating system routine. The operating system routine then returns control to the application process, block 1006.

The application program then proceeds to switch communications back to the tape drive by switching the state of the disk select bit (e.g., from a 0 to a 1), block 1007. The tape drives DMA transfer is then again enabled, block 1008, and the application process continues to transfer data to the tape.

FIGS. 11-13 illustrate the process of the preferred embodiment for restoring data from the tape to disk. The restore process is similar to the backup process and begins by initializing the application program, block 1101 and by the application process taking control of the disk services routine, block 1102. The application program then programs the tape drives task file registers to read data from tape, block 1103 and the tape drive begins reading data from the tape and transferring the data to its buffer memory 303 under control of controller 302. The tape drive then transfers the data across interface 301 to the host computer and the application program transfers the data to disk, block 1104 and continues this process until all requested data has been restored (see FIG. 12). Upon completion of the restore process, the application process releases control of the disk services processes, block 1105, and terminates, block 1106.

The process of transferring data from tape to disk of block 1104 is illustrated in greater detail with reference to FIG. 12 which illustrates that initially data is read from tape 1201. In the preferred embodiment, data is read from tape using the method and mechanisms described above. That is, first a command is issued by the host processor to the tape drive. The tape drive then proceeds to read data from tape and to store the data in its internal buffer. This process may continue without requiring access to the IDE interface (i.e., the tape drive is "offline"). As data is placed in the buffer it may be transferred to the host computer main memory 104 using a DMA transfer facility, block 1203. During the period of time that data is actually being transferred, the tape drive indicates to the host computer that the IDE interface is unavailable for other uses by setting its BUSY bit. After the data is transferred from the data buffer 303 of the tape drive to the main memory 104 of the host computer, the tape drive clears the BUSY bit allowing the tape application software to again control access to the bus.

The tape application software then begins the process of writing the data from the main memory 104 to disk, block 1204. During the period of time that data is being written to disk, the tape drive continues to process the read tape command and to store data in its on-board buffer memory 303.

FIG. 13 illustrates the process of writing data to disk, block 204, in greater detail. This process is similar to the process of FIG. 10 which illustrated reading data from disk. Initially, the tape application software calls standard operating system routines for accessing the tape drive. The operating system routines attempt to call the disk service routine, block 1301. As has been explained, especially with reference to FIG. 8, 11 and 14, the application program replaced the interrupt vectors of the ROM BIOS disk service routines with vectors to routines in the application process. Therefore, the calls by the operating system routines to the disk service routines are intercepted by the application process, block 1302. The application process then switches access to the IDE bus to disk, block 1303 by setting the disk select bit 522.

To the extent not already specifically discussed, it should be noted that the disk select bit 522 provides for control of which device coupled with the IDE bus is to be accessed. When the host writes the drive select register 503 to alter the state of the drive select bit, the task file registers of both the disk and tape drive are effected. Likewise, when other registers are written by the host, the task files of both drives are effected irregardless of which drive is selected by the drive select bit 522. In the system of the preferred embodiment, when issuing a command, the host computer first determines that the IDE bus is available by determining the state of the BUSY bit, 521. The host then writes the disk select register, 522 followed by the other registers needed for the operation and finally writes the command register 501 (as stated previously, the command register is a dual purpose register and is used as the status register while the drive is executing a command). The drives are each programmed such that only the drive selected by the drive select bit 522 will respond to the command. As soon as the command is written, the BUSY bit is set and the operation proceeds as has been described.

Again referring to FIG. 13, the tape drive responds to being deselected by disabling DMA transfers, block 1304, thus preventing inadvertent writing of data into its buffer memory during transfers on the IDE bus directed to the disk.

The application software then calls the ROM BIOS INT 13 disk service routine, block 1305. As a reminder, the application process has previously saved the address of this routine and, thus, has the address available to call directly without having to access the interrupt vector 1403. The disk service routine handles writing of data to the disk drive over the IDE interface. During the time that the write data command is being processed, the disk drive sets the BUSY bit. During the period of time when the BUSY bit is set, the disk drive performs DMA transfers from main memory 106.

Upon completion of writing of data, the disk service routine returns control to the application program, block 1306. The application program then writes the disk select bit 522 to select the tape drive, block 1307, and the tape drive again enables DMA writes from the tape's buffer memory to the main memory 104.

Thus, it can be seen that the present invention allows for effective simultaneous access to two independently controlled devices both coupled with a host computer through a single interface. This simultaneous access provides for improved performance of the devices, especially as described in connection with the system of the preferred embodiment, during tape backup and restore processes.

As one aspect of the present invention, it is taught to utilize industry standard disk drive controller circuits for control and interfacing of a tape drive. For example, as has been previously discussed, in the preferred embodiment a Cirrus Logic CL-SH-260 disk controller circuit is utilized as controller circuit 302. Responsive to the host interface 402 portion of the controller circuit 302 receiving a command from the host computer, the formatter portion of the circuit writes instructions to the writeable control store 409. An exemplary set of instructions is given with reference to FIG. 6. The instructions may include such information as a command 601, a segment address 603 and count 602. Initially, a command may be given such as command 0001 to begin tape movement, followed by a command such as a synchronize command 0002, a write address mark command (WAM), and a command to begin writing data from the buffer memory 0004.

It is noted that in the data archival system of the present invention it is highly desirable to provide for compatibility with existing tape formats. Unfortunately, such existing tape formats are not compatible with standard disk drive formats, and especially with the write formats produced by standard controller circuits such as the Cirrus Logic CL-SH-260.

One area of incompatibility is in the the area of writing address marks. In writing address marks to standard disk drive formats a single address mark byte is typically written. The standard controller circuits begin CRC calculations when the write address mark command is issued. Standard tape drive formats require writing of three consecutive address marks to tape. Unfortunately, in order to provide for accurate calculation of the CRC, it is not desirable have the controller circuit 302 issue three separate write address mark instructions. Therefore, what is desired is to provide circuitry which will effectively provide for separation of the write address mark and "start CRC" instructions in a standard disk controller circuit such as the SH-260.

The present invention implements such circuitry by providing in the NRZ to MFM encoder circuit 311 circuitry to effectively write three address marks each time an address mark is received from the controller circuit 311. This circuitry may be referred to as an address mark generator. In the preferred embodiment, encoder 311 is implemented as in a programmed logic array. In a similar fashion, when reading information from tape, the controller circuit is programmed to start CRC calculations upon receipt of each address mark. However, when reading standard tape formats, as has been discussed, three consecutive address marks are read from tape and it is required to begin calculation of the CRC with the first address mark and not to recalculate the CRC for each of the address marks. Therefore, the MFM to NRZ decoder 312 of the present invention provides address mark detection circuitry for detecting address marks and removing from the information transmitted to the controller two of three address marks in a sequence of three consecutive address marks. This is better illustrated with reference to FIG. 7(a) and FIG. 7(b).

FIG. 7(a) illustrates the encoder 311 which receives NRZ (non-return to zero) information from the controller circuit 302 and produces MRM (modified FM) output. The encoder includes circuitry 701 (coded in a PLA circuit) for detecting instructions to turn on the address mark on the NRZ input. In the prior art, as illustrated by signal 711, each "turn address mark on" instruction will result in one address mark being generated on the MFM output to the drive. The present invention provides for generation of three address marks responsive to each "turn address mark on" instruction as illustrated by signal 712.

In a similar fashion, as illustrated by FIG. 7(b), the present invention provides address mark detection circuitry which detects sequences of three address marks being read from the drive and being supplied on the MFM input to the decoder 312, such as the three address marks illustrated by signal 732. Responsive to detecting three consecutive address marks, decoder 312 provides a single address mark output on the NRZ output to controller circuit 302.

In this way, the present invention provides for compatibility with standard disk drive controller circuits allowing interface with the IDE bus while providing for compatibility with the format of existing tape backup systems.

Thus, what has been described is an improved apparatus and method for providing for data archival in a computer system. The described method is especially useful in computer systems utilizing the Intelligent Device Electronics (IDE) interface, such as may be utilized by IBM PC-ATs or compatibles.