CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part application of U.S. nonprovisional application Ser. No. 09/650,515 filed on Aug. 29, 2000, the teachings of which are incorporated herein by reference, which itself claims the benefit of U.S. Provisional Application Nos. 60/182,448 filed Feb. 15, 2000, 60/183,181 filed Feb. 17, 2000, and 60/216,853 filed Jul. 7, 2000, all the teachings of which are incorporated herein by reference.
FIELD OF THE INVENTION The present invention relates generally to portable devices for reproducing audio and video recordings, and more particularly, to a device for reproducing compressed digital audio and video data.
DESCRIPTION OF RELATED ART Presently there exist various portable devices for replaying digital audio recordings that have been compressed in accordance with a compressed audio digital recording format called MP3. These devices can be divided into two classes, those which store the MP3 compressed digital audio recordings in an electronic solid state memory, and those which record the compressed digital audio for subsequent reproduction using an electromechanical device such as a compact disk (“CD”) player or on a hard disk drive of a digital computer.
Portable devices for replaying MP3 compressed digital audio recordings that use electronic solid state memory, i.e. flash-memory, are capable of storing about ten (10) music selections. With an add-in memory card, such devices can carry a total of about twenty (20) music selections. These MP3 players that store the MP3 compressed digital audio recordings in an electronic solid state memory consume comparatively little electrical power. Thus, such MP3 players provide an extended playing interval without battery replacement or recharging for the limited number of selections which they can store.
In addition to having a capacity for only a limited number of music selections, another characteristic of portable MP3 players that store compressed digital audio recordings in an electronic solid state memory is the inconvenience associated with loading the music selections into that memory. In general, such MP3 players require first downloading or obtaining copies of MP3 compressed digital audio recordings on a hard disk drive of a personal computer, and then transferring the MP3 compressed digital audio recordings from the personal computer to the portable MP3 player. The preceding operations are to be contrasted with the simplicity of merely inserting a compact disk (“CD”) into a CD player, or playing MP3 compressed digital audio recordings directly from a hard disk drive or CD drive of a digital computer.
MP3 players which preserve compressed digital audio recordings for reproduction using an electromechanical device are capable of storing many more music selections than portable MP3 players that store compressed digital audio recordings in an electronic solid state memory, e.g. hundreds or even more than one-thousand. However, usually MP3 players that use electro-mechanical devices require significant amounts of electrical power. Thus, portable players that reproduce music selections using an electro-mechanical device exhibit comparatively short playing interval, e.g. less than one (1.0) hour before batteries must be replaced or recharged.
Batteries used in laptop and notebook computers usually permit their operation for several hours before becoming discharged. As is readily apparent, a laptop or notebook computer can be to play MP3 compressed digital audio recordings using either the computer's CD-ROM or hard disk drive. Pending U.S. patent application Ser. No. 09/136,207, now U.S. Pat. No. 6,226,237, entitled “Low Power CD-ROM Player for Portable Computers” that was filed on Aug. 19, 1998, which is hereby incorporated by reference in its entirety, describes how a conventional laptop or notebook computer, when simply playing a conventional music CD, consumes an unnecessarily large amount of electrical energy. Such an excessive electrical energy consumption drains a laptop or notebook computer's battery of power that is more prudently applied in performing microprocessor intensive tasks such as word processing and spreadsheet analysis. The solution presented in the '207 application is a state machine that operates when main power to the portable device is OFF. The '207 invention couples a CD-ROM to the audio subsystem (when main power is OFF) so that CDs can be played, without excessive battery drain, or without having to boot up the portable computer.
SUMMARY OF THE INVENTION A computer system adapted to access data when the computer system is in an inactive state consistent with the invention includes a computer subsystem and a controller. The computer subsystem includes a system CPU and a drive for storing data. The controller includes a drive interface configured to selectively access data from the drive and a decoder circuit configured to decode the data and provide decoded data, wherein the controller is configured to access the drive to retrieve the data and decode the data when the computer subsystem is in the inactive state. The data may be audio data or video data.
In another embodiment, a method for playing files in a computer system when the computer system is in an inactive state includes the steps of: selecting data; generating a data stream from the selected data; and decoding the selected data and generating a decoded data stream. Again, the data may be audio data or video data.
It will be appreciated by those skilled in the art that although the following Detailed Description will proceed with reference being made to preferred embodiments and methods of use, the present invention is not intended to be limited to these preferred embodiments and methods of use. Rather, the present invention is of broad scope and is intended to be limited as only set forth in the accompanying claims.
Other features and advantages of the present invention will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and wherein:
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is an exemplary block diagram of a portable system in an ON state adapted to receive and play MP3 digital audio files, according to one embodiment of the present invention;
FIG. 2 is an exemplary block diagram of a portable system in an OFF or inactive state adapted to receive and play MP3 digital audio files, according to one embodiment of the present invention;
FIG. 3 is a more detailed system block diagram of the invention ofFIGS. 1 and 2;
FIG. 4 is a detailed block diagram of the MP3 audio controller of the invention ofFIGS. 1 and 2;
FIG. 5A is an exemplary block diagram of another embodiment of the present invention, depicting a portable system in an ON state, adapted to receive and play MP3 digital audio files, and utilizing an external MP3 decoding device;
FIG. 5B is an exemplary block diagram of another embodiment of the present invention, depicting a portable system in an OFF or inactive state adapted to receive and play MP3 digital audio files, and utilizing an external MP3 decoding device;
FIG. 6 is a block diagram of an exemplary computer system in an ON state where an audio/video controller consistent with the invention is transparent to the computer system;
FIG. 7 is a block diagram of the exemplary computer system ofFIG. 6 where the computer system is in an inactive state and the audio/video controller consistent with the invention enables a user to access data in the drives; and
FIG. 8 is a more detailed block diagram of the audio/video controller ofFIGS. 6 and 7.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTSFIGS. 1-4 depict an example of the preferred MP3 audio controller of the present invention. As an overview, the present invention is directed to anMP3 audio controller18 adapted to play stored MP3 files. It is intended, in this embodiment, that the MP3 controller of the present invention be integrated within a computer system10 (e.g., portable lap-top computer) and is adapted with the necessary logic to permit selection, retrieval and play of MP3 files stored locally on the computer, without the necessity of having the computer system turned ON. As used herein, the term inactive is defined to mean a state in which main power is not being supplied (i.e., an OFF state), or when the system is in a sleep mode (such as may be defined under power management specifications). Thus, the present invention provides significant power savings when playing MP3 audio files.
FIG. 1 depicts acomputer system10 adapted with theMP3 controller18 of the present invention in an ON state. Generally, thecomputer system10 includes asystem CPU12, aCorelogic chipset14, a hard disk drive (HDD)20, a CD-ROM drive (CD)22, and an audio subsystem (denoted as “audio IC”)16 coupled to aspeaker system24. When main power is being delivered to the system10 (i.e., the computer is ON), it is preferable that the MP3 controller does not control the play of MP3 files, since such functionality is usually handled by theCPU12 and an MP3 decoder (typically software). Thus, when the system is ON, theMP3 controller18 is transparent to commands between thedrives20 and/or22 and the CPU. Although the figures depictdrives20 and22 as a hard disk device and a CD-ROM device, respectively, it is intended that any drive mechanism (e.g., RAM drive, DVD drive, backup drive, etc.) known to those skilled in the art can be substituted for thesedrives20 and/or22 without departing from the present invention.
Conversely, when the system is OFF, as depicted inFIG. 2, the MP3 controller of the present invention operates to permit users to traverse thedrives20 and/or22 to play MP3 files stored therein directly, without requiring that theCPU12,CPU chipset14, oraudio subsystem16 be operating. To that end, as shown in this Figure, system power need only be supplied to thecontroller18, and to thedrives20,22.
The system block diagram ofFIG. 3 represent a more detailed view of thecomputer system10, adapted with the MP3 controller of the present invention. As shown, theCPU12 and Corelogic chipset14 (depicted as conventional “North Bridge” and “South Bridge” I/O chipsets) communicate withcontroller18, using both an SMBus and an IDE bus. As is understood in the art, coupling of thecontroller18 to an SMBus permits the user-programmability of thecontroller18. Thecontroller18 also communicates with thedrives20 and/or22 along the system IDE bus. As will be described in more detail below,controller18 can include an integrated audio DAC IC, or be adapted to feed a decompressed MP3 file to anexternal audio DAC26. Theexternal audio DAC26 may be included as part of theintegrated computer system10 and/or a subset of theaudio IC16. In either event, the converted audio files are amplified (at amplifier28) to provide an audible signal tospeaker system24. Additionally, as noted above,controller18 is adapted to controldrives20,22 to read MP3 files therefrom. To that end, to permit users to traverse directory structures on the drives, anexternal LCD display30 is preferably provided. The LCD display receives directory information fromdrives20 and22 (via controller18) and displays that information by file name/location. Likewise, the LCD display preferably displays current status information of thecontroller18, as will be described in greater detail below. It should be noted that the use ofLCD display30 requires thatcontroller18 be adapted with appropriate LCD display driver circuitry. It may be the case, however, that thecomputer system10 includes andLCD display34 andLCD driver circuitry32, in which case,controller18 may be coupled directly thereto.
FIG. 4 depicts a detailed block diagram of theMP3 controller18 of the present invention. As an overview,controller18 includes aninternal processor48,memory50 and52,IDE bus interface54,SMBus interface42 andMP3 decoding circuitry56. The overall functionality ofcontroller18 is the ability to traversedrives20,22, permit users to choose a desired MP3 file, decompress the MP3 file and output either a digital or analog signal (to be played by and external amplifier and speaker system). Each of these components depicted inFIG. 4 are described below.
Processor48 is provided to control the general I/O functions, including access, traversal and retrieval commands fordrives20 or22. In the preferred embodiment,external function keys66 are provided to permit users to operatecontroller18 and drives20 or22 to play MP3 files. Function keys can include play, pause, fast forward, rewind, next track, previous track, scan, etc. (or any combination thereof). Since, in the preferred embodiment, thecontroller18 of the present invention permits traversal of directory structures and retrieval of files, it is also preferable to include MENU andENTER function keys66.Controller18 includes afunction key interface46 to interpret commands generated byfunction keys66 and generate commands to theprocessor48. Instructions for retrieval and play of MP3 files are stored inflash memory52. These instructions are preferably user-programmable firmware, permanently resident inmemory52. Upon activation of a function key,processor48 receives instructions frommemory52. To communicate with drives containing MP3 data, aslave IDE interface54 is provided. Upon user commands generated by the function keys,processor48 instructs slave IDE interface to control one of the drives to begin traversing the directory structure. The directory structure in which MP3 files are stored by be fixed (for example, a directory may be user-specified and stored in flash memory52), or the controller can permit users to traverse all directories and files on the drive. Once a user has selected an MP3 file and wishes to play that file (by pressing a play function key, for example),processor48 instructs theslave IDE interface54 to retrieve that file from the drive. Preferably, to minimize disk activity once a file selection is obtained, the file is transferred intoRAM memory50. It is most preferable to includedual port SRAM50, as shown, to store both the audio file and to temporarily store instructions and/or program parameters used by theprocessor48. Once the audio file is loaded intomemory50, the data is fed toMP3 decoder circuitry56.
Decoder circuitry56 comprises astream audio decoder58,buffer memory60 and either aninternal audio DAC62, or aDAC interface64 for communicating with anexternal audio DAC26.Stream audio decoder58 receives streaming audio data frommemory50 and decodes the data according to a decoder algorithm stored therein. Alternatively, a decoder algorithm may be stored inflash memory52, loaded intomemory50 upon activation of the controller, and supplied to thedecoder58. Either way, it is preferable to permit users to update/modify the decoding algorithm. Accordingly, it is preferable thatmemory52 ordecoder58 stores an updatable version of the decoder algorithm. In the preferred embodiment,decoder58 is an MP3 audio file decoder. The output data generated bydecoder58 is decompressed digital audio data, and may include standard digital audio formats like PCM format data. The decoder outputs the decompressed data to a first in—first out (FIFO)buffer60. Ifcontroller18 is adapted with an internal DAC, data from thebuffer60 is fed into theDAC60, which generates an analog audio signal, which in turn is fed toamplifier28 and out to the speaker system (not shown). Alternately, if an external DAC is available in the computer system10 (for example, as part of the audio IC), the decoder can include anappropriate interface64.Interface64 receives digital data frommemory60 and communicates with an external DAC. In a similar fashion, theexternal DAC26 generates an analog signal which is supplied to theamplifier28 and speaker system.
As discussed briefly above, the controller preferably includes anSMBus interface42 to permitcontroller18 to communicate with an SMBus ofcomputer system10. The SMBus is provided for when the system is ON to pass along function key commands to thesystem14 and12, and is also used to access theflash memory52 of thecontroller18 to permit upgrades and/or changes therein. Once commands are sent to theinterface46, the commands are communicated to theprocessor48 for processing. It is also preferable thatcontroller18 include anLCD interface57, which is coupled to the SMBus (via register block44) andprocessor48. In this way, theLCD interface57 can generate signals indicative of both the users actions viafunction key interface46, and the processor status. Processor status may include overall operation status (e.g., file loading, decompressing, file not found, etc.) and specific operational parameters (e.g., error status, component failure, etc.). Additionally, it is preferable to display the drive data, which may include directory tree structure, file name(s), etc. Additionally, MP3 files typically contain an ID tag that is descriptive of the title, song, etc. It is preferable thatLCD interface57 be adapted to read and display this tag data. Thus,LCD interface57 is preferably adapted to display such drive data generate byprocessor48.
Controller18 includes aninternal clocking mechanism40 to clock the circuitry of the controller, and to communicate with timed devices (drives20 or22) over a timed bus (e.g., IDE bus). It will be understood by those skilled in the art that more than one clock frequency is typically required, for example, differing clocks supplied toprocessor48,decoder58 andaudio DAC62. The clock mechanism preferably includes a PLL timer that is clocked by a set crystal, as shown.
As described above, thecontroller18 of the preferred embodiment operates to play compressed audio files when thesystem10 is OFF. To that end, it is preferred that thecontroller10 is activated by a user pressing one of the function keys (i.e., system power is supplied tocontroller18 by pressing one of the function keys66). Upon this event, power is coupled to the components ofcontroller18, and to thedrive systems20 and/or22. By the same token, if thesystem10 is ON, the controller of the present invention includes switches68.Switches68 operate to decouple thecontroller18 from the IDE bus (as shown inFIG. 3), thereby becoming transparent to thedrives20,22 and theaudio subsystem16.
It should be noted that thecontroller18 is preferably operable with both hard disk drives20 and CD-ROM drives22, either of which are conventional storage media for MP3 audio files. Accordingly,function keys66 also preferably include activation keys for the CD-ROM drive, which may include EJECT, FF/SCAN-FF, RW/SCAN-RW, PLAY, PAUSE, STOP, MENU, ENTER etc.
FIGS. 5A and SB depict another embodiment of thecomputer system10′ of the present invention. Similar to the embodiment ofFIGS. 1 and 2, the present embodiment includes anMP3 controller18′ incorporated into acomputer system10′. In this embodiment, however, thecontroller18′ is operable with anexternal MP3 player70.FIG. 5A depicts thesystem10′ when power is supplied to the system components:CPU12′,Corelogic chipset14′,Audio IC16′ and drives20′ and/or22′. When the system is on, MP3 audio files stored on either drive20′ or22′ can be transferred to theexternal device70. External MP3 players may include aCD player72 for reading CDs having MP3 files stored thereon, and/orinternal memory74 for temporary storage of MP3 files. Similar to the previous embodiment,controller18′ preferable is transparent tosystem10′ when power is ON. InFIG. 5B, the system components are OFF or inactive.Controller18′ operates to decompress MP3 files and send the decompressed data toexternal player74. Alternatively,controller18′ can operate to transmit the compressed data to theexternal player74, where the data is decompressed into an appropriate audio format by theplayer74. It is preferable that theexternal device70 include conventional I/O interface (not shown) for connection tocontroller18′ (viasystem10′). For example,controller18′ andplayer70 may include conventional RS232 (serial), USB, and/or TCP/IP communications to exchange commands and transfer data therebetween. The decompressed files can be stored inmemory74 of theexternal player70.
Controller18′ includes similar components as thecontroller18 of the previous embodiment, except that it may not be necessary to includefunction keys66 andfunction key interface46, since it is likely thatportable player70 includes such functionality. Similarly, it may not be necessary to include display functionality withcontroller18′ ifportable player70 is equipped with an appropriate display to view drive directory structures and files.
Thus, it is evident that there has been disclosed an audio controller for portable electronic devices that satisfies the aims and objectives stated herein. Those skilled in the art will recognize numerous modifications that may be made to the present invention. For example, although thecontroller18 and18′ of the present invention has been described with reference to MP3 audio data, it should be readily apparent that thecontroller18 and18′ is independent of the specific format of audio data, and should instead be viewed as a general-purpose audio controller capable of receiving, playing, and/or decompressing any type of audio data, not limited to MP3 format data.
Other modifications are possible. For example, thecontroller18 ofFIGS. 3 and 4 is depicted and described as being coupled (or decoupled) to an IDE bus, those skilled in the art will recognize that the controller can likewise include other bus interface technologies, depending on the bus configuration ofsystem10. Thus, for example,controller18 may be modified to control SCSI drives, and include an SCSI interface for exchanging commands and data according to SCSI protocols. Likewise, it may be desirable to adaptcontroller18 with conventional network protocols (e.g., TCP/IP, etc.) for communication with remote systems (not shown) in a conventional network.
Still further modifications are possible. Thecontroller18 of the present invention has been described herein as including decodingcircuitry56 to decode audio data when thesystem10 is OFF. However, it is contemplated that audio files, such as MP3 files could be decoded and stored in a decoded format on thedrives20 and/or22, for example when thesystem10 is ON. If decoded (decompressed) is accessed by thecontroller18, this data is stored intomemory50 and supplied directly toaudio DAC62 oraudio DAC interface64. In other words, no decoding is necessary for such data andcontroller18 plays the decoded data directly.
Turning toFIGS. 6 and 7, another embodiment of acomputer system610 having an audio/video controller618 consistent with invention is illustrated. In general, the audio/video controller618 is adapted to permit access to audio data, video data, or combined audio/video data while the computer system is in an inactive state. Again, an inactive state is a state in which main power is not being supplied to thecomputer system610, i.e., an OFF state, or when the system is in a sleep mode (such as may be defined under power management specifications.)
FIG. 6 illustrates acomputer system610 having an audio/video controller618 consistent with the invention when thecomputer system610 is in an ON state. Generally, thecomputer system610 includes asystem CPU612, aCorelogic chipset614, anaudio subsystem616 coupled to an audio output device such asspeaker system624, avideo subsystem624 coupled to a video output device such asdisplay device626, ahard disk drive620 and anoptical drive622, e.g., a DVD-ROM or CD-ROM drive. When the main power is delivered to thecomputer system610, i.e., the computer is ON, the audio/video controller618 does not control the play of audio, video, or audio/video files, since such functionality is handled by theCPU612 and the appropriate decoder as represented byactive path632 from theCorelogic chipset614 to thedrives620,622 and theinactive paths634,636 from the audio/video controller618 to theCorelogic chipset614 and drives620,622 respectively. Therefore, when the computer system is ON, the audio/video controller618 is essentially transparent to commands between thedrives620,622 and theCPU612. Although thedrives620,622 are depicted as a hard disk drive and an optical drive, those skilled in the art will recognize that any drive or storage medium may be substituted for such drives without departing from the scope of the present invention.
Turning toFIG. 7, thecomputer system610 ofFIG. 6 is illustrated when thecomputer system610 is in an inactive state. In this instance, the audio/video controller618 consistent with the invention operates to permit users to have access to data, e.g., audio data, video data, or combined audio/video data, on thedrives620,622 without requiring that theCPU612, theCorelogic chipset614, theaudio subsystem616, or thevideo subsystem624 to be operating.
Turning toFIG. 8, a more detailed block diagram of the audio/video controller618 ofFIGS. 6 and 7 is illustrated. In general, thecontroller618 includes some similar components as the earlierdetailed audio controller18 ofFIG. 4 and has additional components as further detailed herein related to video functionality. Thecontroller618 includes aprocessor848 to execute user commands or host commands such as access, traversal, and retrieval of data fromvarious drives620,622 when the computer system is in an inactive state. In one embodiment, theprocessor848 may be a microprocessor.
User commands may be entered viafunction keys866 or via a remote control system. The remote control system includes aremote controller871 and associated circuitry (not illustrated) to enable a user to provide signals to thecontroller618. Suchremote controller871 may have at least all the keys and functionality of theaforementioned function keys866. The remote controller could utilize any known type of control technologies such as Infrared or radio frequency (RF). A transceiver circuit may accept such remote control signals and provide associated signals to theuser input interface846. As such, a user of thecomputer system610 can access available data in the drives via theremote controller871 or via thefunction keys866.
In any event, once a user inputs a desired command via thefunction keys866 or theremote controller871, a userinput interface circuit846 interprets such commands and generates associated commands to theprocessor848. Detailed commands for retrieval and play of various data files may be stored innon-volatile memory852.
Upon user commands, theprocessor848 instructs theslave interface854 to control one of the drives. Once a user has selected data, e.g., an audio file and/or a video file, by activation of the proper key on thefunction keys866 orremote controller871, theprocessor848 instructs theslave interface854 to retrieve that data from a drive. The data may then be stored in memory. Such memory may include aninternal memory850 of thecontroller618, e.g., SRAM. Such memory may also include any variety of external memory external to thecontroller618 for use by thecontroller618, e.g., external RAM. Amemory controller849 may also be coupled to both theinternal memory850 and the external memory. As such, theprocessor848 can control storage of selected data utilizing either the internal memory or external memory or both. In general, theprocessor848 will utilize theinternal memory850 for faster data access and when additional data buffers are needed it may then utilize the external memory as well. For instance, the external memory may be utilized when complex decoding by thedecoder circuit856 needs a significant amount of memory which is most cost effectively provided by the external memory.
Thecontroller618 may further include adecoder circuit856 configured to decode data selected by a user. Thedecoder circuit856 may generally include aparser circuit851 configured to parse required data into either audio data or video data. Audio data from theparser circuit851 is then provided to anaudio decoder857. Anoptional audio buffer853, e.g., a FIFO buffer, may be coupled between theparser circuit851 and theaudio decoder857 to temporarily store such audio data.
Theaudio decoder857 decodes the audio data according to an audio data decoder algorithm. The audio data decoder algorithm may be implemented in any variety of ways known in the art. For instance, the audio data decoder algorithm may be implemented using hardware, e.g., hardwire logic, or software, e.g., where the algorithm may be stored innon-volatile memory852 or internal memory inside theaudio decoder857 and may be updated or modified by users. The output of theaudio decoder857 is decompressed audio data. The audio outinterface859 may contain an internal DAC to generate an analog audio signal which in turn is fed to an amplifier and speaker. Alternatively, an external DAC may be utilized and the audio outinterface859 would provide digital audio data to the external DAC.
Thevideo decoder861 decodes the video data from theparser circuit851 according to a video data decoder algorithm. Anoptional video buffer855, e.g., a FIFO buffer, may be coupled between theparser circuit851 and thevideo decoder861 to temporarily store such video data. The video data decoder algorithm may also be implemented in a variety of ways known in the art. For instance, the video data decoder algorithm may be implemented using hardware, e.g., hardwire logic, or software, e.g., where the algorithm may be stored innon-volatile memory852 or internal memory inside thevideo decoder861 and may be updated or modified by users. The output of thevideo decoder861 is decompressed video data. A videooutput interface circuit863 accepts such decompressed video data and provides such data to an appropriated video output device depending on the state of thevideo switch network865 as further detailed herein.
Thecontroller618 also includes aswitch network880. The controller'sprocessor848 utilizes thisswitch network880 to perform data access from thedrives620,622 or to provide outputs to the externalvideo display device626 when the computer system is in an inactive state.
For instance, theswitch network880 may include adrive switch network868 and avideo switch network865. Thedrive switch network868 may have a first switch state when the computer system is in an active state and a second switch state when the computer system is in an inactive state. In the first switch state, thedrive switch network868 decouples thecontroller618 from the drive of the computer system such that thecontroller618 becomes transparent to the drive bus, e.g., the IDE bus. In contrast, in the second switch state thedrive switch network868 couples the controller to a drive of the computer system via the drive bus.
Similarly, thevideo switch network865 may also have a first switch state when the computer system is in an active state and a second switch state when the computer system is in an inactive state. In the first switch state, thevideo switch network865 decouples thecontroller618 from thevideo output device626. In essence, thevideo switch network865 couples an input video signal, e.g., from a VGA chip, directly to an output port to a video output device such that thecontroller618 is effectively bypassed. In contrast, in the second switch state thevideo switch network865 couples the controller to a video output device of the computer system.
Thecontroller618 may also include aninternal clocking mechanism840 to clock the circuitry of the controller and to communicate with time devices such as the drives over a timed bus such as an IDE bus. The clock mechanism may include a PLL timer that is clocked by a set crystal as shown.
Thecontroller618 may also include ahost interface842 to permit communication between thecomputer system610 and thecontroller618. Communication may occur via a serial bus such as SMBus or USB to reduce the number of pins and cost of thecontroller618. Aregister block844 may also be provided such that the host computer can utilize the register block to control various functions of thecontroller618, e.g., to enable access to thenon-volatile memory852 to permit upgrades and/or changes therein. Thecontroller618 may also include anLCD interface855 which is coupled to the host bus (via register block844) andprocessor848. In this way, theLCD interface855 can generate signals indicative of various activities such as user actions and processor status.
There is thus provided a computer system including a computer subsystem and a controller, the computer system adapted to play data when the computer system is in an inactive state. The computer subsystem includes a system CPU and a drive for storing data. The controller is configured to access the drive to retrieve data and decode the data when the computer system is in an inactive state.
It will be appreciated that the functionality described for the embodiments of the controller consistent with the invention may also be implemented using software, or a combination of hardware and software, and well-known signal processing techniques. If implemented in software, a processor and machine-readable medium is required. The processor can be any type of processor capable of providing the speed and functionality required by the embodiments of the invention. For example, the processor could be a process from the Pentium® family of processors made by Intel Corporation, or the family of processors made by Motorola. Machine-readable media include any media capable of storing instructions adapted to be executed by a processor. Some examples of such media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electronically erasable programmable ROM (EEPROM), dynamic RAM (DRAM), magnetic disk (e.g. floppy disk and hard drive), optical disk (e.g. CD-ROM), and any other device that can store digital information. In one embodiment, the instructions are stored on the medium in a compressed and/or encrypted format.
Those skilled in the art will recognize numerous additional modifications, and all such modifications are deemed within the spirit and scope of the present invention, only as limited by the appended claims.