U.S. Pat. No. 7,338,376

DETAILED DESCRIPTION OF PRESENTLY PREFERRED EXAMPLE EMBODIMENTS

FIG. 2shows an example exemplary video game play delivery network including one or more servers S1. . . SN coupled by a network “cloud” N to one or a number of display devices D1, . . . , DM. Network N may comprise any conventional network such as for example, an Ethernet-based local area network, a wide area network, the Internet, a telephone network, a cable television network, a wireless network, a satellite network, or any other convenient network arrangement that permits display devices D to communicate with server(s) S.

Servers S may in one particular embodiment comprise conventional file servers, but in other embodiments could comprise web servers, cable television head ends, wireless computing device servers, satellites, or any other convenient server architecture.

Devices D in the preferred illustrative embodiment comprise any sort of general or special purpose device with some computing capability and including a display, a user input device and preferably also a sound reproduction capability, for example:an airline, train, bus, car, van or cruise ship seat back or armrest based controller;a cable television set top box;a satellite television receiver;a wired or wireless personal digital assistant, handheld computer or pocket PC;a personal computer;a video game playing platform;a microprocessor-based television set or other consumer appliance;a hotel or cruise ship based television or other display;any other special or general purpose display device.

In the example embodiment, devices D may each include, for example, a display device64such as, for example, a black and white or color liquid crystal display, a CRT, or any other convenient display. In the example and illustrative embodiment, devices D may also include preferably some ability to reproduce sound (e.g., audio amplifiers and associated headphones H or loudspeakers). In the exemplary and illustrative embodiment, devices D may each include a user input device56that allows users to interact with the device D in order to play interactive video games. As one example, user input device56may have a configuration shown inFIG. 2H, and may be a multi-purpose device that provides both the telephone capability and a general-purpose control interface including special-purpose video game controls. In other exemplary configurations, user input device56may provide any convenient means for inputting user interactions to device D including, for example, keyboards, wireless television controllers, the controls on personal digital assistants, or the like.

In the example illustrative embodiment, servers S have mass storage devices M associated therewith. Such mass storage devices M (e.g., magnetic hard drives, optical disks, etc.) store software emulators100that servers S can download onto devices D over network N for execution on devices D. Additionally, mass storage devices M may also store a library of games G that can be interpreted or otherwise “executed” by emulator100running on devices D.

In the example embodiment, emulator100and each of the game files G is assigned an individual part number that conforms with predetermined quality assurance procedures. Additionally, depending on the load process that the exemplary system is able to support, there may also be a need for a part number for individual load sets. Such part numbers will allow, for example, an airline to confirm what software is loaded onto an aircraft by using a conventional cabin maintenance terminal coupled to server(s) S.

In the example embodiment, the process of loading emulator100and game files G onto server(s) S conform with a conventional software loading process, with the main practical limit being the amount of free disk space on the mass storage device M of file server S. In practice, this may or may not be an issue depending upon the size of mass storage devices M. For airlines that have a compact disk optical drive fitted to their aircraft, the load process may be performed in a single software load with all the available games and the emulator100being loaded together. For airlines that do not use an optical disk drive, the load operation is preferably performed (i.e., in order to load the emulator100onto the mass storage device M of file server S) using a floppy disk (multiple floppy disks will probably have to be used). A complete load by floppy diskette may in some circumstances have the advantage of requiring only a single part number to cover the entire load and all of the available games are loaded at once allowing the airline flexibility. However, a disadvantage is that the load process may take considerably longer than if just the required games are loaded. To improve loading time, the disk loader may detect games already loaded and only extract and load new games if the target system provides this functionality. A partial load by floppy has the advantage that the load process will be quicker, but the disadvantage that individual part numbers may be required to cover each of the load disks (meaning an individual part number for the emulator100and for each of the games).

In the exemplary, illustrative embodiment, servers S also may provide and download a variety of other applications to devices D, such applications including but not limited to:movies,electronic books,digital music,multimedia presentations,telephone and other communications applications,stock quotes and trading,Internet browsing,electronic mail,games other than video games (e.g., text-based cross-word puzzles or the like),electronic program guides, andnumerous other applications.
Example Game Downloads

Loading of game and other application software may be provided via conventional mass storage device M via network N.FIG. 2Ashows an illustrative flowchart of exemplary steps performed by a general purpose computing device D in the preferred embodiment, andFIGS. 2B-2Ishow exemplary corresponding screen displays.

Referring toFIG. 2A, device D typically upon power up will generally display a general menu providing a number of different selection options that may vary depending upon the particular application. For example, in a flight-based entertainment system, this main selector screen might display in-flight movies, stock trading, world wide web access, airplane position tracking, weather, and “play video games.” Upon the user selecting the “play video games” option, the device D generates a request across network N to one of servers S requesting loading of emulator100(FIG. 2A, block3002). In the exemplary embodiment, the emulator100authenticates the device D to ensure that the device D is appropriate for running the emulator (FIG. 2A, block3004). In one exemplary embodiment, this authentication can be relatively unsophisticated, i.e., the emulator100is written for a specific hardware platform and will not run on any other hardware platform. However, in other embodiments, there may be positive authentication tests of various sorts (e.g., checking for the presence of appropriate machine codes, encrypted information, pass words, or the like) implemented to ensure that the device D is appropriate for running emulator100.

If the device D is not appropriate (“no” exit to decision block3004), the emulator100will fail and an error message may be generated (block3006). Otherwise, the emulator100will begin loading (“yes” exit to decision block3004). During this loading process, a “loading” informational screen (seeFIG. 2B) may be displayed. The emulator100may then display a game selector menu (FIG. 2G, block3008—seeFIG. 2Cfor an example) allowing the user to choose a particular game or type of game to play. A number of nested menus may be displayed (e.g., see illustrativeFIG. 2D) that allows the user to pick a particular game (seeFIG. 2A, decision block3010).

Once the user has selected a particular game to play (seeFIG. 2E), the device D generates a request message across network N that requests a server S to download all files associated with that particular game (FIG. 2A, block3012). In the example embodiment, this request may be in the form of a particular string (e.g., the name of a particular game). A small executable on server S may provide a lookup table that associates this particular game name with a list of one or a number of files (e.g., the “game ROM” binary image corresponding to the particular game code, and associated help file and any other auxiliary data files). These files are then downloaded by server S to the requesting device D upon request.

In the example embodiment, one or more of these files may be encrypted with some form of encryption. As an example, an initial portion of the game binary image may be encrypted using any conventional encryption mechanism. Upon downloading the game, the device D decrypts the file (block3014), and loads the resulting binary image (and any other files associated therewith) into the work space of emulator100for interpretation (block3016). If the initial part of the game is not successfully decrypted, the game will “crash” when emulator100tries to interpret it. A checksum. check may also be used for both error correction and as a security measure. If a checksum test performed by emulator100fails, the emulator may refuse to execute the emulator. In one example embodiment, all executable binary files to be performed by theFIG. 3emulator may be encrypted prior to distribution. The emulator may decrypt the instructions on-the-fly before executing them. The executable may be decrypted before executing it. In other arrangements, encryption may not be provided and the emulator may simply execute the binary ROM image without decrypting it first.

In one example embodiment, the emulator emulates the security system of the original platform. For example, a splash screen (seeFIG. 2F) including certain information (e.g., “NINTENDO”) may be displayed prior to game play. The code to display this screen is stored in each game or other application binary file. This code is compared to code in the master file located on a hard drive or within the emulator itself. Game play is allowed only if codes match. In another example, this security arrangement may be disabled to allow any compatible application to execute.

During the loading process, in the exemplary embodiment, an image of what a Nintendo GAME BOY COLOR looks like is displayed on the display64of device D (seeFIGS. 2E,2F) for security reasons, and also in order to simulate as closely as possible that the user is playing on a real GAME BOY. This image of a GAME BOY is, in one illustrative embodiment, used to “frame” the game play in order to provide a more realistic game playing experience and also use the excess area of the display for constructive purpose (as opposed to simply blanking it out).

In the example embodiment, emulator100may also display a special “help” file contents customized for the play of the selected game on the device D in order to help the user understand the emulated user interface (seeFIGS. 2G,2H). Such help file contents can be provided in different languages (e.g., English, French, Japanese, German, Spanish, other) to accommodate different native speakers. Selecting a different language may be relatively straightforwardly accomplished by having server S send down a “help” file in a different language upon user request or selection of a “language” menu pick.

Additional control provided by preferred exemplary embodiment emulator100allows the user at any point to pause the game play (seeFIG. 2I). Upon pausing game play, the user may choose to continue the current game; view game information, choose another game, or quit playing games (FIG. 2I). In some airline embodiments, game play may also be paused automatically in response to in flight announcements (e.g., when the pilot or crew speaks over the airplane intercom system). In particular, one use of theFIG. 2system is to execute video games within a seat-back controller of an in flight airplane entertainment system. In such an arrangement, if there is a public address announcement (e.g., from the pilot) to the cabin, the emulator may institute a pause operation and display a message informing the passenger that the game is paused. Once the announcement has ended, the emulator may remain paused and display a message instructing a passenger to press any handset button to proceed. Game play may then resume from where the game was paused. In an exemplary embodiment for airline or other use, there may be a further control input provided by network N to devices D (e.g., via the same interface used for the user input device(s)) that provides a “halt” or “terminate” command. Upon receiving such a “halt” command, emulator100may exit and return control back to the operating system (if any).

The example emulator may need to be integrated with other applications and/or operating systems. To provide such integration, the emulator may be launched by an interactive menu application (e.g., with a specific game name). Such launching may be achieved by passing game name to the emulator on the command line. This may mean that the emulator needs to be shut down and restarted between selected games. Other embodiments may provide dynamic loading of games without a need to shut down the emulator between loads. In one example embodiment, emulator100provides a “watchdog” function of writing to a predetermined hardware register or other location within device D periodically in order to satisfy the device that an active application is running and that the application has not “crashed” or otherwise terminated abnormally. Different devices D may have different requirements.

The maximum game size the emulator may support is limited by a combination of physical memory of the new platform and the amount of memory used by the emulator itself. If there is available free memory, the emulator may support up to the maximum game size that the original platform supports. For example, the emulator may support at minimum 32 megabit games. Some original platform games use a memory management chip. The emulator in the example embodiment supports various versions of this memory management chip if adequate resources are available on the new platform.

FIG. 2Jshows an example software emulator architecture provided by an example embodiment of the present invention. TheFIG. 2Jemulator architecture includes four separate “engines” to handle the specific tasks and emulate the various structures of a real GAME BOY or other emulated video game platform. These separate engines include:microprocessor core emulation engine500,memory manager emulation engine600,sound synthesizer emulation engine700, andvideo emulation engine800.

In the example embodiment, these various engines500,600,700,800communicate with one another via C or x86 assembly function calls. Each engine500,600,700,800is preferably implemented as a separate state machine using one or more virtual device drivers (V×D) to communicate with the input/output vectors and other structures of the platform executing the emulator.

Example Core Microprocessor Emulation Engine500

The main task performed by the core microprocessor emulation engine500in the example embodiment is to simulate/emulate instruction op codes. As described above, the original handheld video game platform microprocessor core comprises a Z80 microprocessor that executes the Z80 instruction set. However, the example platform on which emulator runs may use a completely different microprocessor (e.g., a 386 or 486 microprocessor or equivalent executing the x86 instruction set). Because video games and other applications written for the original platform are compiled into the Z80 instruction set that is incompatible with the Intel x86 instruction set, the example embodiment microprocessor emulation engine500simulates a Z80 microprocessor by interpreting the Z80 op codes and translating them appropriately into the new platform (e.g., x86) instruction set/op codes.

In some instances, the microprocessor emulation engine500may perform a single instruction corresponding to an instruction in the Z80 instruction set. In other situations, the microprocessor emulation engine500may need to perform multiple instructions to complete the task specified by a single Z80 instruction. There are also situations in which the microprocessor emulation engine500might be able to perform fewer instructions to accomplish the same result as a corresponding set of Z80 instructions.

In some instances, it may be desirable for microprocessor emulation engine500to selectively replace sections of game and emulator code for certain games. To accomplish this, the microprocessor emulation engine500may include an interface that examines a file (e.g., rplc.tcl) and replaces code according to a pre-defined scripting language (e.g., TCL or equivalent). For example, if it is desirable to replace a Z80 instruction “LD H, L” with a block of predefined code, the microprocessor emulation engine500during binary parsing may look for the file (e.g., rplc.tcl) for the target game. If the file exists, then the microprocessor emulation engine500may read the file and replace the code as specified in that file. For example, the emulator code for “LD H, L” might be replaced with any desired code from the file.

In addition to simulating Z80 op codes, the microprocessor emulation engine500in the example embodiment maintains-three counters:a Z80 clock counter: this counter allows the emulation engine500to synchronize with original platform events such as interrupts;horizontal synchronization (line) counts: this counter increments every time a hsync should occur on the original platform to simulate display timing;timer countdown: this time counts down a value past by the memory manager engine600for the smallest timer value.

The microprocessor emulation engine500must also simulate/emulate interrupts that would be generated on the original platform. In the example embodiment, the original platform has four different types of interrupts:LCD display vertical blanking interrupts,status interrupts from liquid crystal display controller (four modes),timer overflow interrupt,serial transfer completion interrupt (not needed). This interrupt in the original platform indicates the end of input signal for serial ports P10-P13(i.e., key presses).

In the example embodiment, all interrupts except the keyboard/controller are handled with countdown timers. An interrupt handler function is called when an appropriate count reaches 0. Detection of keyboard/controller data occurs in a conventional manner using an operating system in the personal computer serial port. Emulation engine500must yield to the operating system periodically to give the operating system the opportunity to detect serial port data and pass it to the memory manager engine600.

Example Memory Manager Emulation Engine600

The memory manager emulation engine600in the example embodiment simulates the original platform object attribute memory and creates video memory images in the new platform system memory (e.g., in an off-screen buffer). The example embodiment memory manager engine600maintains two off-screen buffers. Memory manager emulation engine600maintains a buffer pointer to point to the off-screen buffer representing the current display. Once a flag is set for one of the buffers, no data will be moved to that buffer and only read operations will occur. This frees the video engine800to BLIT the buffer to the new platform video memory for display. Once the second buffer is built with a full screen of display information, the buffer pointer is changed to point to this buffer and the off-screen buffer is then transferred to video memory by the video engine800during the next vertical blanking interval.

The moving object (OBJ) and background (BG) characters and pointers are maintained while monitoring and enforcing overlay rules.

A VGA color palette is maintained to match the colors of the original platform. This palette is changed on-the-fly as required. If such on-the-fly matching is inadequate to provide correct colors for particular games, then additional control information may be provided on a game-by-game basis and associated with particular games to supply the correct color information.

The memory manager engine600in the example embodiment maintains and simulates RAM and ROM memory areas. Memory manager engine600also keeps track of paged memory. This requires extra work when the 0×FFxx page is accessed—since hardware registers are mapped into this page. If a timer is enabled as a result of a series of writes to this page, memory manager engine600“pokes” a value into a timer table corresponding to the number of Z80 clock ticks for the timer value. In the example embodiment, this timer can be programmed to fire every n clock tick. The timer table may include six entries—four corresponding to the four possible timers and one for each h sync and v sync of the original platform (seeFIG. 4). The microprocessor emulator engine500as well as the remainder of the emulator performs all necessary processing between vertical blanking periods at a rate equivalent to the original platform processor clock. If this processing overlaps any given vertical blanking period, the screen update is skipped for that period. In the example embodiment, the frame rate is thirty frames per second. If interframe processing cannot be completed before the next vertical sync, then the frame is skipped to allow the emulator to catch up. This allows certain games to run properly at a reduced frame rate. Reductions in required frame rate may be altered on a title-by-title basis. In the example embodiment, the smallest value of the x′ column is passed to the microprocessor emulator engine500, where it is counted down to zero. When zero is reached, the microprocessor emulator engine500instructs memory manager engine600to update the timer table values shown inFIG. 4. At this point, all table values are updated and a software function is called to handle the timer interrupt.

Memory manager engine600also handles all direct memory access requests in the example embodiment. This may be done in-line with assembly language if necessary for speed performance. The following types of direct memory access requests are serviced by memory manager engine600in the example embodiment:from main RAM0h-DFFFh to object attribute memory,16 bytes from ROM and work RAM to VRAM during next horizontal blanking interval, andmemory transfer from ROM and work RAM to VRAM during vertical blanking.
Example Video Emulator Engine800

In the example embodiment, the video emulator engine800includes a pair of off-screen buffers as described above and is responsible for transferring (e.g., using a conventional BLIT operation) the off-screen screen buffer contents to active video memory on vertical blanking interval. The video emulator engine800is also responsible for maintaining color palette information. As explained above, the color palette for the game or other application currently being emulated is created by the emulator at run time.

Vertical synchronization in the new platform may be asynchronous (as it is in the original platform). The microprocessor emulator engine500and memory manager600preferable keep track of vertical blanking as it would have occurred on the original platform, and also keep track of vertical blanking as it is actually occurring on the new platform. A BLIT from the current screen buffer to the active video memory may occur during any vertical blanking interval on the new platform as long as a vertical blank is not being simulated at the same time for the original platform. Example minimum display resolution of 160×144 pixels may be provided.

The video emulator engine800in the example embodiment maps each original platform color palette to the closest matching SVGA controller color palette for each screen based on subjective criteria. This mapping is performed in a manner that maintains optimal game play with no color jitter or irregularities.

Example Sound Emulator Engine700

In the example embodiment, sound emulator engine700simulates the four sound synthesizers of the original platform using a conventional sound blaster sound synthesizer. The sound emulator engine700interprets sound instructions on-the-fly and translates them into sound blaster commands compatible with the sound blaster API. Adequate time must be allowed to program the sound blaster registers (for example, the FM synthesizer requires over 200 set up instructions). Additionally, it is desirable to synchronize sound generation with real time (e.g., latency between when sounds should start and when they actually do start should not differ by more than about 16 milliseconds to ensure proper synchronization between sound and display).

Example User Controller Inputs

While not shown inFIG. 2J, the emulator also receives and processes user-manipulable control inputs in real time. In one example, a game controller input provided in the original platform is simulated using a personal computer keyboard. For example, key up and key down messages received from the conventional keyboard controller can be translated into particular control inputs as would appear based upon depression or other operation of control switches and other configurations of the original platform.

One example emulator is to take Game Boy Color (hereafter known as “CGB”) and Game Boy (hereafter known as “DMG”) binary files and execute these files natively on all Intel based seat box computers for Matsushita system 2000E and 3000 in-flight systems including compatibility with all controllers on the Matsushita systems.

Example Technical Details and Specifications

One example illustrative emulator100is compatible with the MAS S3000 32 Mb or 64 Mb DSEB and the MAS 2000E 486 16 Mb IVASEB made by Matsushita, and may also run on the original MAS 2000E IVASEBs 386s×25 4 Mb to 386s×33 16 Mb. There can be 2 versions of the CGB emulator to support both Win 3.1 and Linux. The MAS 2000E 486 IVASEB runs Win 3.1 in enhanced mode. The MAS S3000 DSEB will run either Win 3.1 in enhanced mode or Linux.

Additional design considerations for CGB emulator100are as follows:Z80 runs at two clock speeds: DMG/CGB, 4 MHz/8 MHzTwo Z80 instruction speeds: 0.954 microseconds & 0.477 microsecondsLCD display 160×144 (+10 vertical blank)59.7 frames/second==16.75 milliseconds/frame==16750 microsecondsClocks/horizontal blanking==1/59.7/(144+10)/(0.477/1e+6)=228 Z80 clocks/horizontal line (double speed)=114 Z80 clocks/horizontal line (normal)

Some GAME BOY® cartridges use one of a variety of memory management chips (called MBC1-5). The following cartridge issues are addressed in the exemplary emulator100:1. paged ROM2. paged RAM3. real time clock4. different behavior for each cartridge

The device D in the example embodiment uses a modified Z80 microprocessor with certain specialized hardware. The input/output, clock generator, timing control, data buffer and address buffer are not shown inFIG. 2J, but are part of the system. Shown are the example hardware elements that emulator100emulates.

DSEB PC486 80 MHzInstruction clock=0.0125 microsecondsOne Z80 clock==38 x86 clocks (486 has single instruction pipe)During one horizontal line period==8,701 x86 clocksDuring one vertical blanking period==87,015 x86 clocksDuring one frame==1,339,954 clocksWindows 3.1 running in enhanced modex86:core processing is fast, I/O is slow

I/O

Types of I/O:1. Real time clock2. Video register access3. Programming sound chip4. Programming timer/counter maintain three counters:

Windows 16-bit:1. Windows runs at each system timer tick (55 milliseconds)2. Support code such as heart beat, MAS system message are processed during system tick3. The emulator100pauses when public address system is on with notification from MAS.4. Original MAS system only has 1 megabyte of RAM available for application

Linux:

32-bit1. SVGA mode and/or X-window2. Multi-tasking so that MAS support is accomplished without yield3. Timer tick is “jiffy” about 10 milliseconds, but may be different
Example Target Platform

The emulator system described above might include software and/or hardware components that emulate of simulate some or all of hardware and/or software components of the system for which the application software was written. For example, the emulator system could comprise a general-purpose digital computer such as a personal computer, which executes a software emulator program that simulates the hardware and/or firmware of the system. The emulator could also comprise a personal digital assistant (PDA) that simulates the hardware and/or firmware of the system. An emulator may execute the game software so that a particular game functions and/or appears somewhat differently from how it functions and/or appears on its intended platform. Thus, the emulator may show a color game in monochrome or a play a game without its accompanying sound. Emulation as used herein is intended to include emulation that results in these and other such differences in functions and/or appearance.

Some general purpose digital computers (e.g., IBM or MacIntosh personal computers and compatibles) are now equipped with 3D graphics cards that provide 3D graphics pipelines compliant with DirectX or other standard 3D graphics command APIs. They may also be equipped with stereophonic sound cards that provide high quality stereophonic sound based on a standard set of sound commands. Such multimedia-hardware-equipped personal computers running emulator software may have sufficient performance to approximate the graphics and sound performance of the system. Emulator software controls the hardware resources on the personal computer platform to simulate the processing, graphics, sound, peripheral and other capabilities of the portable game machine platform for which the game programmer wrote the game software. Similarly, PDAs running emulator software may have sufficient performance to approximate the graphics and sound performance of the system.

FIG. 2Millustrates an example overall emulation process using a host platform1201, an emulator component1303, and a game software executable binary image provided on a storage medium42. Host1201may be a general or special purpose digital computing device such as, for example, a personal computer, a laptop computer, a palm-top computer, a video game console, a portable game machine, a personal digital assistant, an internet appliance, a set-top box, or any other platform with sufficient computing power. Emulator1303may be software and/or hardware that runs on host platform1201, and provides a real-time conversion of commands, data and other information from storage medium62into a form that can be processed by host1201. For example, emulator1303fetches “source” binary-image program instructions intended for execution by portable game machine10from storage medium42and converts these program instructions to a target format that can be executed or otherwise processed by host1201.

As one example, in the case where the software is written for execution on a platform using an IBM PowerPC or other specific processor and the host1201is a personal computer using a different (e.g., Intel) processor, emulator1203fetches one or a sequence of binary-image program instructions from storage medium1305and converts these program instructions to one or more equivalent Intel binary-image program instructions. The emulator1203also fetches and/or generates graphics commands and audio commands intended for processing by the graphics and audio processor114, and converts these commands into a format or formats that can be processed by hardware and/or software graphics and audio processing resources available on host1201. As one example, emulator1303may convert these commands into commands that can be processed by specific graphics and/or or sound hardware of the host1201(e.g., using standard DirectX, OpenGL and/or sound APIs).

An emulator100used to provide some or all of the features of the video game system described above may also be provided with a graphic user interface (GUI) that simplifies or automates the selection of various options and screen modes for games run using the emulator. In one example, such an emulator1303may further include enhanced functionality as compared with the host platform for which the software was originally intended.

FIG. 2Millustrates an example emulation host system1201suitable for use with emulator100. System1201includes a processing unit1203and a system memory1205. A system bus1207couples various system components including system memory1205to processing unit1203. System bus1207may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory1207includes read only memory (ROM) (or RAM)1252and random access memory (RAM)1254. A basic input/output system (BIOS)1256, containing the basic routines that help to transfer information between elements within personal computer system1201, such as during start-up, is stored in the ROM (RAM)1252. In one exemplary embodiment, the BIOS may be loaded through software at startup time of device D; in other example, the BIOS may be resident in ROM.

System1201may further include optional additional drives and associated computer-readable media. For example, a hard disk drive1209reads from and writes to a (typically fixed) magnetic hard disk1211. An additional (optional) magnetic disk drive1213reads from and writes to a removable “floppy” or other magnetic disk1215. An optional optical disk drive1217reads from and, in some configurations, writes to a removable optical disk1219such as a CD ROM or other optical media. Hard disk drive1209and optical disk drive1217can be connected to system bus1207by a hard disk drive interface1221and an optical drive interface1225, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules, game programs and other data for personal computer system1201. In other configurations, other types of computer-readable media that can store data that is accessible by a computer (e.g., magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs) and the like) may also be used. Note that these additional peripheral devices are generally not used in airline seat back controllers or set top boxes, but could be present in other configurations.

A number of program modules including emulator100may be stored on the hard disk1211, removable magnetic disk1215, optical disk1219and/or the ROM1252and/or the RAM1254of system memory1205. Such program modules may include an operating system providing graphics and sound APIs, one or more application programs, other program modules, program data and game data. A user may enter commands and information into personal computer system1201through input devices such as a keyboard1227, pointing device1229, microphones, joysticks, game controllers, satellite dishes, scanners, or the like. These and other input devices can be connected to processing unit1203through a serial port interface1231that is coupled to system bus1207, but may be connected by other interfaces, such as a parallel port, game port Fire wire bus or a universal serial bus (USB). A monitor1233or other type of display device is also connected to system bus1207via an interface, such as a video adapter1235.

System1201may also include an optional modem1154or other network interface means for establishing communications over a network1152such as the Internet. Modem1154, which may be internal or external, is connected to system bus123via serial port interface1231. A network interface1156may also be provided for allowing system1201to communicate with a remote computing device1150(e.g., another system1201) via a local area network1158(or such communication may be via wide area network1152or other communications path such as dial-up or other communications means). System1201will typically include other peripheral output devices, such as printers and other standard peripheral devices.

In one example, video adapter1235may include a 3D graphics pipeline chip set providing fast 2D or 3D graphics rendering in response to graphics commands issued based on a standard graphics application programmer interface such as Microsoft's DirectX 7.0 or other version. A set of stereo loudspeakers1237is also connected to system bus1207via a sound generating interface such as a conventional “sound card” providing hardware and embedded software support for generating high quality stereophonic sound based on sound commands provided by bus1207. These hardware capabilities allow system1201to provide sufficient graphics and sound speed performance to play software stored in storage medium1305.

An emulator100used to provide some or all of the features of the video game system described above may also be provided with a graphic user interface (GUI) that simplifies or automates the selection of various options and screen modes for games run using the emulator. In one example, such an emulator100may further include enhanced functionality as compared with the host platform for which the software was originally intended.

FIG. 2Nillustrates another example emulation host system1201′ suitable for use with emulator100. The emulation host system inFIG. 2Nis generally configured along the lines of a personal digital assistant such as those available from Palm Inc., Handpsring, Inc. and Sony and running an operating system such as Windows CE, EPOC or PalmOS. Typically, such personal digital assistants provide capabilities for a diary/scheduler, to-do lists, phone/address books and the like. System1201′ includes a processing unit1503and memory1505. A system bus1507couples various system components including memory1505to processing unit1503. Memory1505includes read only memory (ROM)1252and random access memory (RAM)1254. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within system1201′, such as during start-up, is stored in the ROM1252. Memory1505may also include external memory in the form of memory cards or memory sticks inserted into a suitable port provided in the housing for the components of system1201′. A touch-sensitive display screen (e.g., a touch-sensitive liquid crystal display screen)1509is also connected to system bus1507via an interface1511. Inputs via touch-sensitive screen1509are typically made using a stylus. Other input devices1513such as pushbuttons, switches, pointing devices and the like are also connected to system bus1507via an interface1515. The input devices may also include external keyboards or game control devices (e.g., joystick, game controller). The input devices may be used as game controls (e.g., starting the game, character movement, character action, etc.) when system1201′ is used with emulator100. Games may be written to memory1505using communication circuit1521which may take the form of a modem for downloading the game from the Internet, for example, or of a cradle (e.g., a USB cradle) for connecting system1201′ to a personal computer.

One or more speakers or headphones1517are connected to system bus1507via an audio interface1519to output sounds. A communication circuit1521is connected to system bus1507via a communications interface1523to permit communication with other devices. By way of illustration, communication circuit1521may, for example, be a modem and/or communications interface1523such as a serial port. Generally speaking, communication circuit1521may be configured for wired or wireless communication in accordance with any conventional communication protocol. A power supply1525provides power for the components of system1201′.

Example Emulator Architecture

FIG. 2Oshows an example more detailed software emulator100provided by a preferred embodiment of the invention. Emulator100is designed to operate on a target platform of the types described above, but could run on any desired platform.

In the example embodiment, the target platform includes:a microprocessor (e.g., an Intel 386);a local or remote disk-based or other file system52;a keypad interface54coupled to a handheld controller56;a sound blaster or other audio interface card58coupled to a loud speaker or other sound transducer such as headphones; anda VGA or other graphics adapter62that outputs video information to a display64such as a liquid crystal display screen or video monitor.

Emulator100(which executes on the target platform microprocessor and uses the resources of the target platform) receives the binary image of a game (or other application) file66stored on disk or other file system52. Emulator100parses and interprets this binary image. Emulator100also receives user inputs from handheld controller56via target platform keypad interface54. In response to these inputs, emulator100generates sound commands for the audio adapter58and generates graphics commands for application to the video graphics adapter62—creating sounds on audio transducer60and images on display64. These sounds and images nearly duplicate what one would hear and see if running file66on a native GAME BOY® platform.

In the example embodiment, the game file binary image66can be a video game or any other application that can run on a GAME BOY®, COLOR GAME BOY® or GAME BOY ADVANCE®. Binary image66includes binary audio commands and binary graphics commands, compatible with a GAME BOY® native platform but which are not compatible with the application programming interface features of audio interface58and VGA adapter62. Emulator100interprets those graphics commands and sound commands, and generates a corresponding sequence of graphics and sound commands that are understandable by and compatible with the audio and sound capabilities of the target platform.

In the example embodiment, emulator100includes a virtual machine including a virtual microprocessor core102. Virtual microprocessor core102interprets instructions within the binary game file66that would be executed by the actual GAME BOY® native platform (Z80) microprocessor, and provides a corresponding sequence of microprocessor instructions for execution by the target platform microprocessor (which in the general case, is different from the microprocessor found in GAME BOY® and does not understand and is incompatible with the native platform microprocessor instruction set).

Virtual microprocessor core102receives inputs from a keypad emulation block104. Block104in turn, receives interactive inputs from the user via target platform keypad interface54. Keypad emulator block104emulates the GAME BOY® control input circuitry and associated functionality and translates inputs received from the target platform keypad interface—which may have a different set of control inputs and configurations from that found in a GAME BOY® native platform.

Virtual microprocessor core102also communicates with sound emulation block106and graphics emulation block108. Sound emulation block106emulates or simulates the sound generation circuitry within a GAME BOY®, GAME BOY COLOR® and/or GAME BOY ADVANCE® to provide a set of sound commands for application to the target platform sound adapter58. Graphics emulation block108emulates or simulates the hardware acceleration and other graphics circuitry found within a GAME BOY®, GAME BOY COLOR® and/or GAME BOY ADVANCE® platform to provide a set of graphics commands for application to a target platform graphics adapter62.

In the example embodiment, virtual microprocessor core102also includes a virtual liquid crystal display controller103used for the purpose of maintaining timing. Events within the GAME BOY®, GAME BOY COLOR®, and GAME BOY ADVANCE® native platforms are generally driven by activities relating to updating the liquid crystal display every one-sixtieth of a second. The example embodiment of emulator100emulates the native platform liquid crystal display controller in order to synchronize events occurring within the emulator with emulated events that would occur within a GAME BOY®, GAME BOY COLOR®, and/or GAME BOY ADVANCE® native platform. As will be described below in detail, the virtual liquid crystal display controller103of the example embodiment does not actually perform any display functions, but rather is used to tell emulator100what would be going on in terms of display timing on a real GAME BOY®, GAME BOY COLOR®, or GAME BOY ADVANCE®. A virtual liquid crystal display controller103allows emulator100to synchronize its pace with what the pace of a real GAME BOY®, GAME BOY COLOR®, and/or GAME BOY ADVANCE® native platform would be running the same application file66. Virtual liquid crystal display controller103may be viewed as a software-implemented model of the event timing sequence of a GAME BOY®, GAME BOY COLOR®, and/or GAME BOY ADVANCE® native platform.

Emulator100also includes an emulated random access memory110, an emulated read only memory112, and an emulated memory bank controller (MBC)114. Emulated random access memory110and emulated read only memory112provide memory storage locations within the (read/write) random access memory68of the target platform. The emulated random access memory110emulates or simulates the random access memory of a GAME BOY®, GAME BOY COLOR® and/or GAME BOY ADVANCE®, and the emulated read only memory112emulates or simulates the read only memory within the game cartridge of a GAME BOY®, GAME BOY COLOR® and/or GAME BOY ADVANCE®. The emulated memory bank controller114emulates or simulates the hardware memory bank controller (bank switching) circuitry found within certain a GAME BOY®, GAME BOY COLOR® and/or GAME BOY ADVANCE® game cartridges.

In one example embodiment, emulator100may provide certain game-specific functionality, i.e., it may change or optimize its emulation characteristics dynamically depending on the particular game G being played, in order to achieve better speed performance, audio playback, or other characteristics. This can be implemented in a variety of ways. In one preferred illustrative embodiment, header information associated with each game file G includes a set of “flags” that instructs the emulator100to set certain characteristics (e.g., enable within-frame color palette swaps, disable frame skipping, change virtual clock speed, enable full color, or any number of other values). In other example embodiments, emulator100could dynamically adjust its operation to accommodate different requirements based on tests performed before or during game execution.

Example Emulator Implementation Details

FIGS. 3-29show at various levels of detail, one preferred exemplary implementation of an emulator100suitable for use in the preferred and exemplary system described herein. Explanation of those details and description of the corresponding figures may be found in U.S. patent application Ser. No. 09/723,322 entitled “Software Implementation Of A Handheld Video Game Hardware Platform”, incorporated by reference herein.

In yet another embodiment, rather than creating a virtual machine, emulator100could operate based on dynamically compiling the game binary image into a different format. In this example, a compiler is written to accept a game binary image as source code and to generate an executable. The compile could be fully custom or could be a front end to an existing compiler (e.g., like the FORTRAN front end to the Gnu GCC compiler). In this example, one executable is generated for each game and no ROM files are required at run-time. This compilation process eliminates the overhead of interpreting opcodes and can result in higher efficiencies—since the output from the compiler is native target code that can execute directly on the microprocessor of device D. In one compiler embodiment, emulator100can be based on a precompilation procedure that requires game binary images to be preprocessed by running them through a compiler ahead of time. The resulting native target code is then downloaded from server S over network N to devices D for execution. In this example, there may still be a need for emulating non-CPU tasks as separate tasks, but the fact that native code can be executed by the device D microprocessor means that there is no need to emulate the source platform CPU. Of course, it may also be possible to match the microprocessor within device D so it is the same as the microprocessor within the source platform—obviating the need to emulate the CPU.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment. For example, while the preferred embodiment has been described in connection with Nintendo's GAME BOY® handheld video game platform, the invention is not limited to GAME BOY® but could be used to emulate any other video game platform (e.g., Nintendo's NES, SNES or N64 game playing platforms, or platforms made by other manufacturers). Thus, the invention is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims.