The present invention relates to small personal computers, and to methods for using them.
The innovations disclosed in the present application provide computer systems (especially very small portable personal computers) which have advantageous new capabilities for disk drive management. To better explain the significance and advantages of these innovations, the following paragraphs (down to page 5) will review some technological context. This technological context is not necessarily prior art, but is intended to help in pointing out the disclosed inventions.
Laptop and Smaller Computers
Portable personal computers were introduced in the early 1980s, and proved to be very useful and popular. As this market has developed, it has become increasingly dear that users strongly desire systems to have small volume, small weight, physical durability, and long battery-powered lifetime. Thus, small portable computers ("laptop" computers) have proven extremely popular during the late 1980s. Users continue to demand more features, longer time between recharges, and lower weight and volume. This combination of demands is difficult to meet. Moreover, as of 1990, another smaller generation of portable computers has begun to appear, referred to as "notebook" computers. This smaller form factor will only exacerbate the difficulty of the above tradeoffs.
Note that the hard drive in a notebook computer is normally bolted in, and is not intended to be readily changed by the user. Thus, since the choice of hard drives is controlled by the manufacturer, the system does not have as difficult a recognition problem as it would if users could freely introduce new hard drive modules.
Basic System Software
Whatever hardware is used will have its own procedures to return to a known state when a reset occurs. However, at some point these procedures end, and the CPU is ready to begin execution of instructions.
At this point the system performs various overhead tasks under software control. These may include surveying the system configuration, sanity checks, etc.
"Basic Input/Output System" Software (BIOS)
In modern personal computers, the initial target address is normally used as the entry point to a "basic input/output system" (BIOS) program. The BIOS program contains frequently-used routines for interfacing to key peripherals, for interrupt handling, and so forth..sup.1 In addition to these basic input/output routines, the "BIOS" software also includes some key pieces of overhead software, such as configuration update and the power-on-self-test (POST) routines..sup.2 The BIOS software will also launch the machine into the operating system software..sup.3 (Thus, the term "BIOS" has become somewhat broader nowadays, and normally refers to this whole collection of basic system routines.) FNT .sup.1 Thus, the BIOS software provides some degree of machine-independence. However, in PC-class computers, this independence is not fully exploited by the available commercial software. Many programs bypass the BIOS software, and directly access the underlying hardware addresses or devices. See generally Glass, "The IBM PC BIOS," Byte, April 1989, pp. 303ff. FNT .sup.2 The POST routines provide an extensive check for hardware integrity. FNT .sup.3 Depending on how the system has been set up, the BIOS software may direct program execution into DOS, Unix, PS/2, a DOS variant, or another operating system. However, the choice of operating system is not particularly relevant to the inventions described in the present application.
Disk Drive Management in Personal Computers
In standard personal computers, the operating system must be aware of a significant number of disk parameters, including the heads, cylinders, sectors, and interleave. See generally Rosch, "Sectors, tracks, and heads," PC SOURCES vol. 2 no. 1 (Jan. 1991), at 378, which is hereby incorporated by reference; and Roberts, "Finding disk parameters," PC TECH JOURNAL, vol. 4 no. 5 (May 1986), at 112ff, which is hereby incorporated by reference.
Normally, the user advises the system software of disk parameters, as follows:
When the computer is booted, it always offers the user the opportunity to branch into a SETUP utility. Also, if the computer detects corruption of the configuration memory data, or if the computer detects a mismatch between the configuration memory data and the installed equipment, or (sometimes) if a hardware error is encountered during the POST routines, the POST software will invite the user to enter the SETUP routine. PA0 When the user runs the SETUP routine, it displays a table of numbered drive types, with parameters for each. The user is asked to select one of these drive types. (Recent SETUP routines will query the drive to ascertain its parameters, and will suggest a choice to the user.) After the user selects a drive type, the relevant information is stored in the configuration memories in nonvolatile memory (battery-backed CMOS), and the user is prompted to reboot the computer.
Selecting a drive type is confusing to new users, and presents some possibility for error. Consequences of such errors can easily include inoperability or loss of data, ff an inexperienced user gets into manual SETUP without realizing what he is doing.
The Integrated Drive Electronics (IDE) Disk Interface
In recent years, interfacing to hard disk drives has been greatly simplified by the rapid introduction of Integrated Drive Electronics (IDE) disk drives. An IDE drive includes the drive controller electronics integrated with the drive, so the interface to it can be a high-level digital interface. As drives have evolved, the interface is becoming standardized; this evolving interface is referred to as the AT Attachment interface, hereinafter "ATA" and has been proposed for adoption as an American National Standards Institute, hereinafter ANSI standard. See generally Alford, "The IDE Hard Disk Drive Interface," BYTE magazine, March 1991 (vol. 16 No.3), at 317ff, which is hereby incorporated by reference.
An IDE drive controller does handle many low-level tasks (such as soft error detect and retry), and some can even remap the drive sectors invisibly to the operating system; but (at least with current IDE interface definitions, and with current operating systems such as DOS, OS/2, and UNIX) the IDE controller does not fully mask the drive specifics from the operating system. Thus, the CPU, under control of the system software, still needs to be able to ascertain the drive parameters.
Under the evolving ATA standard, one of the commands which an IDE drive controller will recognize is an identity query. In response to such a query, the controller will output a block of data which includes the drive's model number and serial number, as well as parameters for the drive.
Computer System with Automatic Drive: Model ID Recognition and Adaptation
The present application discloses a computer system in which the system software (while running as an overhead process which is not directly under control of the user) queries a disk drive to determine its model. The disk drive returns a data field which includes an ID string, and the system software compares this string against a table of recognized model strings. If the drive's response string is recognized in this table, then the drive parameters can be set appropriately. If not, then this portion of the system software will not set the drive parameters. (However, the normal manual setup procedure can still be used.)
The presently preferred embodiment implements this idea in an ISA architecture. In this case the POST process (stored in the BIOS ROM) queries the hard disk to determine what kind it is and automatically sets the CMOS hard disk drive type to its corresponding value. Previously, this required knowing the CMOS drive type number of the hard disk, or knowing the correct drive parameters and searching through all available CMOS drive types to find the one that corresponds.
Limited Use of Drive's Self-Description Capability
When the CPU is running the innovative software, it issues an identification query to the drive: for example, with an IDE drive, the CPU issues an "IDE.sub.-- identify" command. In response to this command, an IDE drive will return a block of data (in a format substantially defined by the ATA standard) which includes a model-unique identification string. That is, this string will specify the manufacturer's model number (e.g. "Conner Peripherals 42MB--CP2044") at byte 36.sub.H of the block of 512 bytes.
The block of data returned by an IDE drive also includes drive parameters. However, the present invention does not use these drive parameters (except, optionally, as additional bits of input to the string match, as detailed below.
The disclosed innovative architecture also provides additional options for exploitation. Thus, for example, an IDE controller might be running an emulation, which could be bypassed by software according to the present inventions, if the IDE's emulation would not produce optimal efficiency for a particular application.
Encryption
Preferably the table of permissible model strings is stored in encrypted format. This prevents competitors from simply reading out the list of permissible drive models (which would disclose supplier information). In this case the comparison operation must be adapted accordingly.
In the presently preferred embodiment, the table of permissible model strings is encrypted using a very simple algorithm: the values are simply XORed with a constant. This provides some minimal impediment to competitors' inspection.
The string returned by the disk drive is tested with reference to the encrypted entries. (The comparison operation itself includes translation steps which permit the unencrypted returned string to be compared, without a separate transformation operation, to the encrypted entries in the table.)
Launch from POST
The innovative routine is called out of POST. It recognizes the drive. It looks up the optimal type number for that drive, and writes the nonvolatile configuration memory accordingly. However, if this routine does not recognize the drive model string, it changes nothing.
As part of the POST routines, the innovative procedures will run every time the computer is booted. However, these procedures do not add any significant delay to the boot process.
Sequence of POST Steps
The innovative drive-recognition steps are preferably performed before any disk-access operations are needed. Thus, in the presently preferred embodiment, these drive-recognition steps are performed just after the reset and self-test of the drive is initiated.
Updating
To obtain the maximum benefit, the table of hard drive models in the system software should be updated to recognize new drive models, before systems with the new drive model are released. Thus, in practice, the engineering team which evaluates a new drive for possible inclusion will add the additional recognition entry into the BIOS. By the time the new drive model is cleared for shipping, the corresponding recognition capability is already in the BIOS.
Currently there are ten different drive models in the recognition table, but of course this is expected to change.
Forward Compatibility.
The disclosed system and method provides improved forward compatibility. New drive models continue to be introduced, and there remains at least a theoretical possibility that a new drive model might match an existing model in some parameters, but not in all. Thus, recognition by parameter comparisons raises a risk of misrecognition.
Of course, as new drive models are introduced, the BIOS software can be updated accordingly.
USPTO Backgrounds
USPTO Backgrounds