CN116635120A - System and method for converting legacy code into updated code - Google Patents

Abstract

A method for facilitating the play of a conventional game is described. The method comprises the following steps: receiving user input during said playing of said legacy game; determining whether one or more code blocks for servicing the user input are cached; and accessing one or more instructions of the legacy game code upon determining that the one or more code blocks are not cached. The method further comprises the steps of: compiling the one or more code blocks of the one or more instructions from the legacy game code; caching the one or more code blocks; and executing the one or more code blocks to display the virtual environment.

Description

System and method for converting legacy code into updated code

Technical Field

The present disclosure relates to systems and methods for converting legacy code into updated code.

Background

As electronic games and network technologies become more advanced, the complexity of the games has increased accordingly. Thus, there may be more complex storylines, game play goals, missions and tasks, capabilities associated with playing a game avatar, and scoring. Scoring may occur in various ways and be weighted and may likewise be determined by various categories or on an individual or team basis.

The importance of the foregoing problems only increases as the complexity of electronic games increases. Thus, some players may wish to play older games that are less complex.

It is against this background that embodiments of the present invention have evolved.

Disclosure of Invention

Embodiments of the present disclosure provide systems and methods for converting legacy code into updated code.

In one embodiment, a method for facilitating the play of a traditional game is described. The method comprises the following steps: receiving user input during play of the legacy game; determining whether one or more code blocks for servicing the user input are cached; and accessing one or more instructions of the legacy game code upon determining that the one or more code blocks are not cached. The method further comprises the steps of: compiling the one or more code blocks of the one or more instructions from the legacy game code; caching the one or more code blocks; and executing the one or more code blocks to display the virtual environment.

In one embodiment, a computing device for facilitating the play of a traditional game is described. The computing device includes a processor configured to receive user input during play of a legacy game. The computing device also includes a cache coupled to the processor and a memory device coupled to the processor. The processor determines whether one or more code blocks for servicing user input are stored in the cache. The processor accesses one or more instructions of legacy game code from the memory device upon determining that the one or more code blocks are not stored in the cache. Moreover, the processor compiles the one or more code blocks of the one or more instructions from the legacy game code. The processor stores the one or more code blocks in the cache and executes the one or more code blocks to display a virtual environment.

In one embodiment, a method is described. The method includes generating a first validation result from one or more instructions of a legacy game code. The one or more instructions of the legacy game code are associated with one or more code blocks. The method also includes checking one or more memory addresses associated with the one or more instructions to determine whether the one or more code blocks are marked as invalid. The method comprises the following steps: determining whether the one or more code blocks are to be executed; and determining, when it is determined that the one or more code blocks are to be executed, whether the one or more code blocks are marked as invalid. The method comprises the following steps: checking the one or more memory addresses to generate a second validation result from the one or more instructions; comparing the first verification result with the second verification result to determine whether the one or more code blocks are invalid; and recompiling one or more additional code blocks associated with the one or more instructions upon determining that the one or more code blocks are invalid. The method includes executing the one or more additional code blocks to display the virtual environment.

Some of the advantages of the systems and methods described herein for converting legacy code to updated code include: allowing the functionality of legacy code to be performed by the updated machine. Without conversion, the updated machine cannot perform the functionality of the legacy code due to security issues. For example, there is no authority to execute legacy code from the updated machine and write data generated when the legacy code is executed to registers in the updated machine. Thus, by providing conversion, execution of the functionality of legacy code by the updated machine is facilitated.

Other advantages of the systems and methods described herein include saving execution time. As an example, two or more instructions of conventional code (such as routines and subroutines or two similar instructions) are combined into one basic block of updated code. Therefore, the update code is executed faster than the conventional code.

Additional advantages of the systems and methods described herein for converting legacy code into updated code include: one or more additional basic blocks of the update code are recompiled upon determining that the one or more basic blocks of the update code are invalid. For example, when one or more basic blocks are marked as invalid, it is determined whether the one or more basic blocks are actually invalid. Once determined to be, one or more additional basic blocks are compiled and executed instead of executing the one or more basic blocks. The one or more additional basic blocks correspond to the same game to which the one or more basic blocks correspond.

Other advantages of the systems and methods described herein for converting legacy code into updated code include: it is not necessary to check the invalidity of all basic blocks. For example, validity checks are performed only on those basic blocks that are marked as invalid after the basic blocks are compiled. This reduces the latency of displaying the virtual environment from one or more basic blocks. Furthermore, the processing capability for checking invalidity of all basic blocks is not required.

Moreover, the advantages of the systems and methods described herein for converting legacy code into updated code include: when the update code for the game has been compiled, processing time and processing power are saved. Once the update code is generated at the server or at the game console, it does not need to be recompiled. Instead, the update code may be transferred from the server or game console to another game console. Thus, processing time and processing power to regenerate the update code at another game console is saved.

Other aspects of the present disclosure will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the embodiments described in the present disclosure.

Drawings

The various embodiments of the disclosure are best understood by referring to the following description taken in conjunction with the accompanying drawings in which:

FIG. 1 is a block diagram to illustrate an embodiment of a system for generating basic blocks of update code.

Fig. 2 is a flow chart to illustrate an embodiment of a method for compiling and executing a basic block of game code.

FIG. 3 is a block diagram to illustrate an embodiment of a system for compiling and executing a basic block.

FIG. 4A is a diagram to illustrate an embodiment of a system for compiling basic blocks within a game console.

Fig. 4B is a diagram illustrating an embodiment of a system for compiling basic blocks within a server system.

Fig. 5A is a diagram to illustrate an embodiment of a basic block.

Fig. 5B is a diagram to illustrate an embodiment of a compiling operation performed by the basic block compiler.

FIG. 6A is a diagram to illustrate an embodiment of a system that emulates components of a processor system.

Fig. 6B is a flow chart to illustrate an embodiment of a method for compiling and executing a basic block.

Fig. 6C is a diagram to illustrate an embodiment of a system that dynamically compiles different basic blocks for different user inputs.

FIG. 7A is a diagram to illustrate an implementation of a system to delete emulated Processing Unit (PU) code from a memory device.

FIG. 7B is a flowchart to illustrate an implementation of a method for deleting emulated PU code from a memory device.

FIG. 8A is a diagram of an embodiment of an emulated processor system to illustrate verification of a basic block.

FIG. 8B is a flowchart to illustrate an embodiment of a method of verifying operations performed by the emulated processor system of FIG. 8A.

Fig. 8C is a continuation of the flow chart of the method of fig. 8B.

Fig. 9A is a diagram for explaining an embodiment of a conventional machine.

Fig. 9B is a diagram to illustrate an embodiment of the machine after updating.

Fig. 10A is a diagram for explaining an embodiment of a system in which a plurality of basic blocks are combined into one basic block by a basic block compiler.

Fig. 10B is a diagram of an embodiment of a system to illustrate modifications to one or more of the basic blocks.

FIG. 10C is a diagram to illustrate an embodiment of a system that combines basic blocks created based on a subroutine with basic blocks generated based on emulated PU code instructions that call the subroutine.

Fig. 10D is a diagram to illustrate an embodiment of a system for inserting a basic block between two basic blocks.

Fig. 10E is a diagram for explaining an embodiment of a system for switching in the execution order of basic blocks.

Fig. 11A is a flowchart to illustrate an embodiment of a method of using a count of the number of cycles stored in a basic block n.

Fig. 11B is a continuation of the flow chart of the method of fig. 11A.

Fig. 12 is a diagram to illustrate an embodiment of a system to transfer basic blocks from a first client device to a second client device.

Fig. 13 is a flowchart conceptually illustrating various operations performed for streaming a cloud video game to a client device, in accordance with an implementation of the present disclosure.

FIG. 14 is a block diagram of an embodiment of a compatible game console for interfacing with a display device of a client device and capable of communicating with a game host system via a computer network.

Fig. 15 is a diagram for explaining components of a Head Mounted Display (HMD).

Fig. 16 illustrates an implementation of an information service provider (INSP) architecture.

Detailed Description

Systems and methods for converting legacy code into updated code are described. It should be noted that various embodiments of the present disclosure may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the various embodiments of the present disclosure.

Fig. 1 is a block diagram to illustrate an implementation of a system 100 for generating basic blocks 1 through n of update code, where n is a positive integer. The system 100 includes a cache 102, a basic block compiler 104, and emulation Processing Unit (PU) code 106 for a legacy game N having a game name GN, where N is a positive integer. As an example, a cache as used herein is a hardware or software component that stores data so that future requests for data can be serviced faster. A cache hit occurs when the requested data can be found in the cache, and a cache miss occurs when the requested data cannot be found. By reading data from the cache to service a cache hit, this is faster than computing results or reading from a slower data storage device (such as a memory device), and therefore the more requests that can be serviced from the cache, the faster the system will perform. To illustrate, a cache is a set of registers that may be accessed faster than a main memory device, such as 10-fold to 100-fold.

As an example, a cache has a smaller number of memory addresses than a main memory device. In the example, the processor first determines whether data used in operation is stored at a memory address in the cache, and if not, the processor accesses the memory address in the main memory device to find the data.

As an example, a basic block compiler, as used herein, is a computer program that transcodes emulated PU code 106 into game code GCN, which is an example of updated code. The game code GCN represents the functionality of a conventional game N. The computer program is simulated byOne or more processors of the true processor system execute. The game code GCN is sometimes referred to herein as an intermediate code. As an example, the intermediate code is neither source nor machine code. For illustration, the intermediate code includes basic blocks that are not specific to the architecture of the Central Processing Unit (CPU) or Graphics Processing Unit (GPU) of the updated machine, examples of which are provided below. In the description, the intermediate code includes basic blocks executable by the CPU or GPU of the updated machine, examples of which include Sony PlayStation ^TM 4(PS4 ^TM ) Or Sony PlayStation ^TM 5(PS5 ^TM ) Or a desktop or laptop computer or a smart phone or a smart television. As an example, the source code is written using a human-readable programming language, which may be plain text. As an example, a basic block compiler, as used herein, is implemented using hardware or software, or a combination thereof. For purposes of illustration, the functionality of the basic block compiler is implemented using a controller or Programmable Logic Device (PLD) or Application Specific Integrated Circuit (ASIC).

As used herein, examples of a controller include a processor and a memory device. The processor is coupled to the memory device. As used herein, a processor is, by way of example, a microprocessor, or CPU, or GPU, or microcontroller, or ASIC, or PLD. As used herein, examples of memory devices include Random Access Memory (RAM) and Read Only Memory (ROM). For purposes of illustration, the memory device is a flash memory device, or a hard disk, or a solid state storage device, or a Redundant Array of Independent Disks (RAID), or a combination thereof.

An example of emulation PU code 106 is machine code that directs a processor (such as a CPU or GPU) of a conventional machine to perform operations. For example, the emulated PU code 106 includes a sequence of instructions that instruct the CPU of the legacy machine to perform specific operations, such as load, store, transfer, or Arithmetic Logic Unit (ALU) operations on data stored within registers of the CPU. As another example, emulated PU code 106 is a binary code that includes a series of ones and zeros. As another example, the emulated PU code 106 includes a sequence of instructions that instruct the GPU of the legacy machine to perform specific operations, such as load, store, transfer, or ALU operations on data stored within registers of the GPU. The GPU of a conventional machine performs operations on virtual objects to assign graphics parameters, such as color, or intensity, or shadows, or textures, or combinations thereof, to the virtual objects.

The emulated PU code 106 is specific or unique to the architecture of the CPU or GPU of the legacy machine. For example, the emulated PU code 106 cannot be executed by the CPU or GPU of the updated machine. As another example, the method can be performed at Sony PlayStation ^TM 1 (PS 1) the emulated PU 106 executing on cannot be played at Sony PlayStation ^TM 2 (PS 2), and vice versa.

As an example, the emulated PU code 106 is executed by the processor of the legacy machine to perform operations in the legacy game N. To illustrate, the emulated PU code 106 is executed to perform the following tasks such as PS1 ^TM Or PS2 ^TM To play a conventional game on a conventional machine. Examples of traditional games include games such as Warhawk ^TM 、Tango Dance Fever ^TM 、Castlevania Chronicles ^TM 、Pacman ^TM 、Resident Evil 2 ^TM And Streetfighter Alpha 3 ^TM Is a video game of (a).

The basic block compiler 104 accesses the emulated PU code 106 for the legacy game N and converts the emulated PU code 106 into one or more basic blocks, such as basic blocks 1 through N. As an example, each basic block 1 to n has a start identifier and an end identifier to distinguish the basic blocks from each other. The basic block compiler 104 stores basic blocks 1 through n in the cache 102. When the basic blocks 1 to N are executed, the conventional game N is emulated.

FIG. 2 is a flow chart to illustrate an embodiment of a method 200 for compiling and dispatching basic blocks of game code GCN. The method 200 is performed by one or more processors of the updated machine. The method 200 includes an operation 202: it is determined whether there is a cache hit, e.g., whether the basic block is stored in cache 102. For example, operation 202 is performed or triggered when user input is received during the play of a conventional game. To illustrate, user input is received to change the position or orientation of a virtual object of a conventional game N, or a combination thereof. In the illustration, after determining that user input is received, it is determined whether a basic block (such as one of basic blocks 1 through n) is stored in cache 102 (FIG. 1). In the illustration, a basic block will be executed to change the position or orientation of a virtual object, or a combination thereof.

As another illustration, operation 202 is performed when a user input is received that changes parameters (such as look and feel) of a virtual object of a traditional game. In the illustration, after determining that user input is received, it is determined whether a basic block (such as one of basic blocks 1 through n) is stored in cache 102. In the illustration, a basic block will be executed to change parameters of the virtual object.

In response to determining that the basic block is cached, the basic block is dispatched in operation 204 of method 200. For example, the basic block is executed or run in operation 204. To illustrate, the basic block is run by the updated machine's CPU to move a virtual object from one location to another location or from one orientation to another orientation or a combination thereof. As another illustration, the basic block is executed by the GPU of the updated machine to assign the parameters to a portion of the virtual object. Examples of a portion of the virtual object include a pixel of the virtual object or a triangle portion of the virtual object or a portion of a predefined shape of the virtual object. To illustrate, a virtual object is divided into a predetermined number of pixels, and a parameter value is assigned to each pixel.

In response to determining that the basic block is not cached, an operation 206 of compiling the basic block is performed in method 200. Operation 206 is performed by basic block compiler 104 (fig. 1). For example, the basic block compiler 104 parses the emulated PU code 106 (FIG. 1) of the legacy game N to identify emulated PU code instructions that include functionality for servicing received user input during play of the legacy game prior to operation 202. User input received prior to operation 202 triggers operation 202. To illustrate, the basic block compiler 104 traverses each of the emulated PU code instructions of the emulated PU code 106 to determine if the emulated code PU code instructions include operations, such as functions, to satisfy (such as generate responses to) user input received during play of a conventional game. In the illustration, once a function is identified, the basic block compiler 104 converts the emulated code PU code instructions to generate basic blocks. In the illustration, in response to user input received prior to operation 202, other emulated code PU code instructions of a conventional game that are not required to service the user input are not compiled into basic blocks by the basic block compiler 104.

In operation 208 of the method 200, the basic block generated in operation 206 is stored in the cache 102 by the basic block compiler 104. The cached basic block is then executed in operation 204 to service the user input received prior to operation 202.

In one embodiment, the method 200 is performed by one or more processors of a server system. As an example, the server system includes the updated machine as a server. For illustration, each server blade is PS4 ^TM Or PS5 ^TM 。

In one embodiment, the method 200 is not performed until user input is received. For example, a basic block (such as one of basic blocks 1 through n) is not compiled and not executed until a user input is received to determine whether the basic block is stored in the cache 102.

In one implementation, the basic block compiler 104 compiles one or more of the basic blocks 1 through N in response to a first user input during the play of the legacy game N and compiles the remaining one or more of the basic blocks 1 through N in response to a second user input during the play of the legacy game N. To illustrate, basic block compiler 104 generates basic blocks 1 and 2 to service a first user input and basic blocks 3 through 7 to service a second user input. A second user input is received after the first user input.

Fig. 3 is a block diagram to illustrate an embodiment of a system 304 for compiling and dispatching basic blocks, such as basic blocks 1 through n. The system 300 includes a basic block compiler 104, a cache 102, and a block dispatcher 302. As an example, block dispatcher 302 is hardware or software or a combination thereof that performs the operations of one or more of basic blocks 1 through n to service user inputs. For illustration, the block dispatcher 302 is a PLD or ASIC or controller. As another illustration, block dispatcher 302 is computer software. By way of example, block dispatcher 302 is the GPU or CPU of the updated machine.

The basic block compiler 104 decodes a portion of the emulated PU code 106 (FIG. 1), such as operation code (opcode), and translates the portion into an intermediate representation of the processing unit for the updated machine. For example, the basic block compiler 104 parses a portion of the CPU code, such as one or more instructions, of the emulated PU code 106 to determine if the portion of the CPU code includes functionality to service user input. After the determination is made, the basic block compiler 104 translates the portion of the CPU code into one or more basic blocks, such as basic blocks 1 through n. As another example, the basic block compiler 104 parses a portion of GPU code, such as one or more instructions, that emulates the PU code 106 to determine if the portion of GPU code includes functionality to service user input. After determining yes, basic block compiler 104 translates the portion of the GPU code into one or more basic blocks, such as basic blocks 1 through n.

Moreover, the basic block compiler 104 estimates the number of execution cycles per basic block generated from the portion of the emulated PU code 106 to generate an estimated count. For example, the basic block compiler 104 determines that the basic block 1 includes a skip operation and the skip operation takes a predetermined amount of time. The basic block compiler 104 estimates that the jump operation of the basic block 1 takes the predetermined amount of time. The block compiler 104 stores the estimated count in the cache 102. For example, the block compiler 104 stores the estimated count in the base block n for which the number of loops is estimated.

Once the basic blocks are compiled, they are stored in the cache 102 to enable fast lookup. For example, when another user input is received after receiving a user input in response to which a basic block is compiled and the same basic block may be used to service other user inputs, the basic block may be quickly accessed from cache 102 without regeneration.

Further, one or more of the basic blocks stored in cache 102 may be marked as invalid after being compiled. One or more of the basic blocks marked as invalid are later verified or invalidated during runtime of the basic blocks. One or more additional basic blocks are compiled when one or more of the basic blocks are invalidated. The compilation of one or more additional basic blocks is sometimes referred to herein as a recompilation of one or more basic blocks.

Each of the one or more additional basic blocks has the same structure as that of the one or more basic blocks 1 to n. For example, each of the one or more additional basic blocks has a source register address, a destination register address, and an operation. As another example, each of the one or more additional basic blocks has a source register address, a destination register address, an operation, and a number of execution cycles of the operation of the additional basic block. In the example, some of the one or more additional basic blocks include an invalid flag. As yet another example, each of the one or more additional basic blocks has a source register address, a destination register address, an operation, and a number of execution cycles of the operation of the additional basic block. It should be noted that each of the additional code blocks is performed in the same manner as each of the basic blocks 1 through n.

Block dispatcher 302 executes or runs one or more of basic blocks 1 through n based on user input. For example, block dispatcher 302 executes basic blocks 1 and 2 to service a first user input and basic blocks 3 through 7 in response to a second user input. As an example, block dispatcher 302 includes a clock source, such as a digital clock oscillator or clock generator, that counts the number of cycles used to execute one or more of basic blocks 1 through n based on user input to generate an actual count. The block dispatcher 302 sends the actual count to the block compiler 104 to update the estimated count using the actual count. For example, the actual count is stored in the basic block n for which the actual count is calculated. To illustrate, the actual count is stored in one or more memory registers assigned to the cache 102 of basic block n.

In one embodiment, the basic block compiler 104 does not estimate the number of execution cycles of any basic block. In this embodiment, there is no replacement of the estimated count with the actual count. Rather, in the described embodiment, the actual count is stored by the block compiler 104 in the base block n for which the actual count was determined.

Fig. 4A is a diagram illustrating an implementation of a system 400 for compiling basic blocks 1 through n within a game console 402. The system 400 includes a game console 402, a server system 404, a computer network 408, and a display device 410. Server system 404 includes one or more servers. By way of example, server system 404 is located within a housing of a data center. The server system 404 includes a memory device 412 that stores emulated PU code, such as emulated PU code 104. For example, the memory device 412 stores game code 1 (gc 1), game code 2 (gc 2), and so on until game code N (gcN). Game code gcN is an example of emulated PU code 106 (fig. 1). Each of the game codes 1 to N is a conventional code of a conventional game. To illustrate, the game code gc1 is a machine code for playing a first conventional game, and the game code gc2 is a machine code for playing a second conventional game. The second legacy game is different from the first legacy game. It should be noted that memory device 412 is, by way of example, a memory device of a conventional machine.

As an example, none of the game codes gc1 to gcN can be executed in the updated machine, and can be executed in the conventional machine. To illustrate, the updated machine's CPU or operating system cannot support execution of the game codes gc1 through gcn. On the other hand, the CPU or the operating system of the conventional machine supports execution of game codes gc1 to gcN. As used herein, examples of computer networks include a Wide Area Network (WAN) such as the internet, or a Local Area Network (LAN) such as an intranet, or a combination thereof.

Game console 402 is an example of an updated machine. For example, game console 402 is PS4 ^TM Or PS5 ^TM . Examples of display devices 410 include televisions, smart televisions, and computer monitors. For illustration, the display device 410 is a Liquid Crystal Display (LCD) device, or a Light Emitting Diode (LED) display device, or an Organic Light Emitting Diode (OLED) display device.

The system 400 also includes a handheld controller 414 that is held in one or both hands of the user 1. Examples of handheld controllers as used herein include controllers with buttons, from Sony ^TM Move from Corporation ^TM A controller, and a gun-shaped controller. Examples of buttons of the handheld controller include a joystick, buttons for moving a virtual object up, down, left, or right on the display screen 410, and other buttons for selecting various features of the conventional game N having a game name GN.

The game console 402 includes a memory device 406 and an emulation processor system 409. As an example, a processor system as used herein includes one or more processors coupled to each other. The emulation processor system 409 is coupled to the memory device 406. The emulation processor system 409 includes a basic block compiler 104 and a cache 102. The basic block compiler 104 is coupled to the cache 102.

The game console 402 is coupled to the display device 410 via a wired communication medium such as a High Definition Media Interface (HDMI) cable or a wireless connection. As used herein, examples of wireless connections include Wi-Fi ^TM Connection and Bluetooth ^TM And (5) connection. Also, the handheld controller 414 is coupled to the game console 402 via a wired connection or a wireless connection. Examples of wired connections, as used herein, include serial transfer cables, parallel transfer cables, and Universal Serial Bus (USB) cables.

Examples of client devices include a combination of a handheld controller, a game console, and a display device. Another example of a client device includes a combination of a handheld controller and a display device.

When the user Identification (ID) and password are authenticated by the server system 404, user 1 logs into his/her user account. The server system 1 assigns a user ID1 to the user 1. Once user 1 logs into his/her user account 1, user 1 may access a plurality of game names, such as game name G1, game name Ga, game name G2, and so on, until game name GN. Game names G1, G2, and so on until game name GN is an example of the name of the conventional game. The game name Ga is the name of a game other than the conventional game Is called. Instead, the game name Ga belongs to the current game, such as Fortnite, which cannot be played in a conventional machine ^TM 。

After logging into his/her user account, user 1 selects one or more buttons on handheld controller 414 to select game name GN to play conventional game N. Once user 1 selects the game name GN, user input 418 indicating the selection is sent from the handheld controller 414 to the server system 404 via the game console 402 and the computer network 408. As an example, the user input is an input signal. After receiving user input 418 indicating a selection of game name GN, server system 404 identifies game code gcN based on user input 418. For example, server system 404 recognizes that game code gcN has the same game name as game name GN, indicating its selection in user input 418.

The server system 404 sends the game code gcN to the game console 402 via the computer network 408. After receiving game code gcN, emulation processor system 409 stores game code gcN in memory device 406 of game console 402.

When user input 420 is received from handheld controller 414 via a wireless connection during a conventional game N in which the toy has game code gcN, emulation processor system 409 executes basic block compiler 104 to generate a portion of game code GCN from a portion of game code gcN stored in memory device 406. A portion of the game code GCN is generated based on the user input 420. For example, when user input 420 includes WarHawk being entered during play of the legacy game N ^TM Upon a request for a fighter to move from position P1 to position P2, the basic block compiler 104 parses the game code gcN to identify instructions to calculate position P2 from position P1. The basic block compiler 104 converts the instructions into basic blocks of the game code GCN and then executes the basic blocks to transform WarHawk ^TM The position of the fighter changes from P1 to P2. In the example, the basic blocks of game code GCN are executed by a GPU of the emulation processor system 409 to generate one or more image frames 422. To illustrate, one or more image frames 422 are displayed on the display device 410 to display WarHawk ^TM Fighter planeA virtual environment located at position P2. In this way, most or all of the game code GCN is compiled by the basic block compiler 104 and stored in the cache 102 for execution. As an example, a virtual environment, such as a virtual scene, includes one or more Virtual Reality (VR) images or one or more Augmented Reality (AR) images.

In one embodiment, data communication between server system 404 and game console 402 is via a network communication protocol, such as the transmission control protocol over internet protocol (TCP/IP). For example, the server system 404 includes a network interface controller to convert data into packets. As used herein, examples of network interface controllers include Network Interface Cards (NICs) and network adapters. The network interface controller of the server system 404 is coupled to the memory device 412 to receive data from the memory device 412. Upon receiving the data from the memory device 412, the network interface controller of the server system 404 embeds the data in one or more packets by applying a network communication protocol to the data. The one or more packets are communicated from the network interface controller of the server system 404 to the game console 402 via the computer network 408. The game console 402 includes a network interface controller that extracts data from the one or more packets by applying a network communication protocol. The network interface controller of the game console 402 is coupled to an emulation processor system 409. The network interface controller of the game console 402 provides data received from the computer network 408 to the simulation processor system 409. In addition, the network interface controller of game console 402 receives data from emulation processor system 409 and embeds the data within one or more packets by applying a network communication protocol and transmits the one or more packets to server system 404 via computer network 408. The network interface controller of server system 404 applies a network communication protocol to one or more packets received from computer network 408 to extract data from the one or more packets and send the data to memory device 412 for storage.

In one embodiment, a cellular network is used to transfer data between server system 404 and game console 402 in addition to or in lieu of computer network 408. For example, wireless technology is used to facilitate communication between the server system 404 and the game console 402. The wireless technology includes, for example, 4G or 5G wireless communication technology. As used herein, 5G is a fifth generation cellular network technology. Also, a 5G network is a digital cellular network in which a service area covered by a provider is divided into small geographical areas called cells. In the 5G wireless communication technology, analog signals representing sound and images are digitized in a telephone, converted by an analog-to-digital converter, and transmitted as a bit stream. All 5G wireless devices in a cell communicate by radio waves with the local antenna array and low power automatic transceivers (transmitters and receivers) in the cell via frequency channels assigned by the transceivers from a pool of frequencies, which are reused in other cells. The local antenna is connected to the cellular network via a high bandwidth fiber optic or wireless backhaul connection. As in other cell networks, a mobile device that crosses from one cell to another will automatically go to the new cell. It should be understood that 5G networks are merely exemplary types of communication networks, and that embodiments of the present disclosure may utilize previous generation wireless or wired communications, such as 3G or 4G, and subsequent generation wired or wireless technologies after 5G.

In one implementation, either of the game console 402 and the server system 404 is referred to herein as a computing device. Other examples of the computing device include tablet computers, smartphones, laptops, desktop computers, and smart televisions.

In one implementation, each of the game codes gc 1-gcN is stored in a separate memory device of the server system 404 or a legacy machine. For example, the game code gc1 is stored in the memory means of the first conventional machine, and the game code gc2 is stored in the memory means of the second conventional machine. As another example, game code gc1 is stored in a first storage device of server system 404, and game code gc2 is stored in a second storage device of server system 404.

In one implementation, memory device 412 or memory device 406 is not a cache. Rather, each of memory device 412 or memory device 406 is a main memory, such as RAM.

In one implementation, the memory device 412 is coupled to a memory controller. The memory controller reads data from the memory device 412 and writes data to the memory device 412. The memory controller is coupled to a network interface controller of the server system 404. The memory controller sends data received from the network interface controller of the server system 404 to the memory device 412 for storage. The memory controller also sends data received from the memory device 412 to the network interface controller of the server system 404 for transmission to the game console 402 via the computer network 408.

Fig. 4B is a diagram of an embodiment of a system 450 to illustrate that an emulation processor system 409 is located within the server system 404 and that one or more image frames 422 are sent from the server system 404 to the display device 410 via the computer network 408 in order to display a virtual environment or virtual scene. The system 450 includes a server system 404, a display device 410, and a handheld controller 414.

The server system 404 includes a memory device 412 and an emulation processor system 409. A memory device 412 is coupled to the emulated processor system 409. The display device 410 is coupled to the computer network 408 via a network interface controller of the display device 410. The display device 410 includes a processor coupled to a network interface controller of the display device 410. The processor of the display device 410 receives user input 420 during a conventional game in which the toy has a game name GN and a game code gcN, and sends the user input 420 to the network interface controller of the display device 410. The network interface controller of the display device 410 sends user input 420 to the simulation processor system 409 of the server system 404 via the computer network 408.

After receiving the user input 420, the simulation processor system 409 performs the same functions as described above with respect to game code gcN with reference to fig. 4A to compile basic blocks 1 through N to generate one or more image frames 422. Server system 404 communicates one or more via computer network 408 The image frames 422 are sent to the display device 410 to display a virtual environment, such as virtual environment 452, on a display screen of the display device 410. For example, virtual environment 452 includes a virtual object 454, which is Warhawk ^TM Examples of fighter aircraft. In the example, virtual environment 452 includes a virtual background that includes one or more virtual objects, such as virtual pyramid 455 and virtual structure 456. In this example, virtual object 454 is capable of launching a virtual missile toward virtual pyramid 455 and virtual structure 456 during a conventional game N in which the toy has game code gcN.

In one embodiment, data communication between the server system 404 and the display device 410 occurs via a network communication protocol. For example, the server system 404 includes a network interface controller to convert data into packets. The network interface controller of the server system 404 is coupled to the emulation processor system 409 to receive data from the emulation processor system and embed the data in one or more packets by applying a network communication protocol. The packets are communicated from the network interface controller of the server system 404 to the display device 410 via the computer network 408. The network interface controller of the display device 410 extracts data from the one or more packets by applying a network communication protocol. The network interface controller of the display device is coupled to the processor of the display device 410. The network interface controller of the display device provides data received from the computer network 408 to the processor of the display device 410. The processor of the display device 410 renders data, such as image frames 422, on a display screen of the display device 410. Further, the network interface controller of the display device 410 receives data from the processor of the display device 410 and embeds the data within one or more packets by applying a network communication protocol and transmits the one or more packets to the server system 404 via the computer network 408. The network interface controller of server system 404 applies a network communication protocol to one or more packets received from computer network 408 to extract data from the one or more packets and send the data to emulation processor system 409.

In one embodiment, a cellular network is used in addition to or in lieu of computer network 408 to transfer data between server system 404 and display device 410. For example, wireless technology is used to facilitate communication between the server system 404 and the display device.

In one implementation, instead of the display device 410, a Head Mounted Display (HMD) is used. The head mounted display is worn on the head of the user 1 and comprises a display screen, such as an LED screen or an OLED screen or an LCD screen. The HMD performs the same functions as the display device 410 performs.

Fig. 5A is a diagram to illustrate an embodiment of a basic block. Each basic block includes a source register address, a destination register address, and an operation. For example, basic block 1 includes source register address 1, destination register address 1, and operation 1. Basic block 2 includes source register address 2, destination register address 2, and operation 2, and basic block n includes source register address n, destination register address n, and operation n. As an example, the source register address is an address of one or more source registers within cache 102, and the destination register address is an address of one or more destination registers within cache 102. Examples of operations of the basic block include a jump operation and a branch operation, a read operation, a write operation, a compare operation, and a return operation. Other examples of operations of the basic block include arithmetic operations such as addition operations, subtraction operations, multiplication operations, and division operations.

As an example, when the operation n is a read operation, data is read from the source register address n to execute the basic block n. As another example, when operation n is a write operation, data is written to the destination register address n to execute the basic block n. As another example, when the operation n is a move operation, data is read from the source register address n, the operation n is performed on the data, and the data is written to the destination register address n to perform the basic block n. As yet another example, when the operation n is a comparison operation, a first value of data stored at a first source register address mentioned in the basic block n is compared with a second value of data stored at a second source register address mentioned in the basic block n to generate a comparison result, and the comparison result is stored at a destination register address n to execute the basic block n. As another example, when the operation n is an addition operation, a first value of data stored at a first source address mentioned within the basic block n is added to a second value of data stored at a second source address indicated within the basic block n to generate an addition result, and the addition result is stored at the destination register address n to execute the basic block n. As yet another example, when the virtual object described herein is to be moved from location P1 to location P2 and operation n is a write operation in which the location of the virtual object is to be updated from P1 to P2, location P1 at destination register address n is overwritten by location P2 to execute basic block n. In the example, execution of basic block n indicates to simulation processor system 409 that the virtual object is to be moved from location P1 to location P2. Also, in the example, user input 420 (FIG. 4A) instructs simulation processor system 409 to move the virtual object from location P1 to P2. Similarly, as another example, when the virtual object described herein is to be moved from orientation O1 to orientation O2 and operation n is a write operation in which the orientation of the virtual object is to be updated from O1 to O2, orientation O1 at destination register address n is overwritten by orientation O2 to perform basic block n. In the example, execution of basic block n indicates to simulation processor system 409 that the virtual object is to be moved from orientation O1 to orientation O2. Further, in the example, user input 420 instructs simulation processor system 409 to move the virtual object from orientation O1 to O2.

As yet another example, when a portion of the virtual object described herein is to change color from red to green and operation n is a write operation in which the color of the virtual object is to be updated from red to green, the data representing the red color at the destination register address is overwritten by the data representing the green color to perform basic block n. In the example, execution of basic block n indicates to simulation processor system 409 that the color of the portion of the virtual object is to change from red to green. Also, in the example, user input 420 instructs simulation processor system 409 to change the color of the portion of the virtual object from red to green. Similarly, other parameters, such as intensity and texture, may be modified based on user input 420.

Each basic block includes the number of execution cycles of the basic block. For example, basic block 1 includes the execution cycle number 1 of basic block 1. As another example, basic block 2 includes the execution cycle number 2 of basic block 2, and basic block n includes the execution cycle number n of basic block n. As an example, the basic block compiler 104 (fig. 1) estimates the estimated number of execution cycles of a basic block when compiling the basic block. In the example, the estimated number of loops is stored in the basic block. Also in the depicted example, after block dispatcher 302 (FIG. 3) executes a basic block, block dispatcher 302 updates the estimated number of execution cycles using the actual count in the manner described above and provides the actual count to block compiler 104. The estimated number of loops is replaced by the block compiler 104 with the actual count in the basic block. As another example, an actual count of the number of execution cycles of operation n is generated by block dispatcher 302 and stored in base block n. In this example, the number of execution cycles of operation n is not estimated.

Further, as another example, one or more of the basic blocks 1 to n include an invalidation flag indicating validity checking of one or more of the basic blocks 1 to n. For example, the basic block n includes an invalid flag n.

It should be noted that by converting the emulated PU code 106 into the basic blocks 1 through n of game code gcN, hooks, such as blocks of hooks, may be inserted between any two of the basic blocks 1 through n. For example, a hook block n may be inserted between the basic blocks (n-1) and n. The hook block n has the same structure as that of the basic block n. For example, a hook block includes a source register address, a destination register address, an operation, and a number of execution cycles of the operation of the hook block. As an example, hooks as described herein cannot be inserted between instructions stored in a legacy machine for emulated CPU code 106 (fig. 1) executing on the legacy machine due to security issues associated with the legacy machine.

It should be further noted that basic blocks 1 through n are entered (such as fixed) into cache 102 (fig. 1). For example, basic block 1 has a start memory address 1 indicating the start position of basic block 1 in cache 102. Furthermore, basic block 1 has an end memory address 1, which indicates the end position of basic block 1 in cache 102. As another example, the end address 1 of basic block 1 is indicated by an offset from the start memory address 1 in the cache 106. As yet another example, basic block 2 has a start memory address 2 indicating the start position of basic block 2 in cache 102. Furthermore, basic block 2 has an end memory address 2, which indicates the end position of basic block 2 in cache 102. As another example, the end address 2 of basic block 2 is indicated by an offset from the start memory address 2 in the cache 106. Similarly, as another example, basic block n has a starting memory address n that indicates the starting location of basic block n in cache 102. Furthermore, the basic block n has an end memory address n indicating the end position of the basic block n in the cache 102. As another example, the ending address n of the basic block n is indicated by an offset from the starting memory address n in the cache 106. The emulated processor system 409 (fig. 4A), such as the basic block compiler 102, may identify the locations of basic blocks 1 through n in the cache 102 from the beginning memory addresses and ending memory addresses of basic blocks 1 through n stored in the cache 102.

It should also be noted that in the event that the user input instructs the block dispatcher 302 of the updated machine to execute basic block n immediately after executing basic block 1, the block dispatcher 302 skips execution of basic blocks 2 through (n-1) in the cache 102 and jumps from basic block 1 to basic block n. In this case, when the block dispatcher 302 jumps to the basic block n, the block dispatcher 302 shuts down the execution of the basic block 1. Also in this case, the start address of the next basic block is continuous with the end address of the previous basic block. For example, the start address 2 is continuous with the end address 1, and the start address n is continuous with the end address (n-1) of the basic block (n-1).

In one embodiment, source register addresses 1 through n are memory addresses of registers of cache 102 and destination register addresses 1 through n are memory addresses of registers in cache 102.

In one embodiment, the basic block includes a plurality of operations. For example, basic block n includes a first operation, a first source register address, and a first destination register address. The basic block n further comprises a second operation, a second source register address and a second destination register address.

In one embodiment, a basic block includes an operation, a plurality of source addresses, and a destination address.

In one embodiment, a basic block includes an operation, a plurality of destination addresses, and a source address.

In one embodiment, a basic block includes a plurality of operations, a plurality of source addresses, and a plurality of destination addresses.

In one embodiment, a basic block includes one or more operations, one or more source addresses, and one or more destination addresses.

In one implementation, the basic block includes a source register address or a destination register address, but not both.

In one embodiment, the block compiler 102 does not estimate the number of execution cycles of the basic block n. Instead, block dispatcher 302 generates an actual count of the number of execution cycles of basic block n and stores the actual count in basic block n.

Fig. 5B is a diagram to illustrate an embodiment of a compiling operation performed by the basic block compiler 104 (fig. 1). An example of an emulated PU code instruction M is illustrated as instruction 550, and an example of a basic block n is illustrated as basic block 552, where M is a positive integer. Instruction 550 includes a source address M of length a bits, a destination address M of length b bits, and an operation M represented by bits of length c, where a, b, and c are positive integers. By way of example, a is 4, b is 4, and c is 32. As an example, the a-bit, b-bit, and c-bit are stored in one or more memory devices of a conventional machine. For example, the a-bit is stored in memory device 406 or 412 (fig. 4A and 4B). Operation 552 includes a source register address n of length d bits, a destination address n of length e bits, and an operation n represented by a bit of length f, where d, e, and f are positive integers. As an example, d is 8,e is 8 and f is 64. As an example, the d, e, and f bits are stored in one or more registers of the updated machine. As an example, d is greater than a, e is greater than b, and f is greater than c. For illustration, when a is 4, b is 4, and c is 32, d is 8, e is 8, and f is 64. As another example, when a is 4, b is 4, and c is 32, d is 16, e is 16, and f is 128.

To perform the compiling operation, the basic block compiler 104 (fig. 1) converts the source address M into a source register address n, the destination address M into a destination register address n, and the operation M into an operation n to generate the basic block n from the emulated PU code instruction M. For example, the basic block compiler 104 shifts the 4 bits of the source address M to the right to occupy the 4 memory addresses of the 8 source registers in the cache 102 and masks any bits in the remaining four memory addresses of the 8 source registers. The four memory addresses occupied by 4 bits of source address M are located at the least significant locations of the 8 source registers in cache 102, and the remaining four memory addresses with the bits masked are located at the most significant locations of the 8 source registers in cache 102.

As another example, the basic block compiler 104 shifts the 4 bits of the destination address M to the right to occupy 4 memory addresses of 8 destination registers in the cache 102 and masks any bits in the remaining four memory addresses of the 8 destination registers. The four memory addresses occupied by the 4 bits of destination address m are located at the least significant locations of the 8 destination registers in cache 102, and the remaining four memory addresses with the bits masked are located at the most significant locations of the 8 destination registers in cache 102.

Similarly, as another example, the basic block compiler 104 shifts 32 bits of operation M to the right to occupy 32 memory addresses of 64 operation registers in the cache 102, and masks any bits in the remaining 32 memory addresses of the 64 operation registers. The 32 memory addresses occupied by the 32 bits of operation M are located at the least significant locations of the 32 operation registers in the cache 102, and the remaining 32 memory addresses with the bits masked are located at the most significant locations of the 64 operation registers in the cache 102. Operation n is stored in an operation register of the cache 102.

Fig. 6A is a diagram of an embodiment of a system 600 to illustrate components of an emulated processor system 409. The system 600 includes a memory device 412 and an emulation processor system 409. The basic block compiler 104 of the emulation processor system 409 includes a parser or decoder 602. The basic block compiler 104 also includes a block creator 604, a block buffer 606A, and a block reader 608. The emulation processor system 409 includes a block dispatcher 302.

As an example, each of the parser 609, the block creator 604, the block buffer 606, the block reader 608, and the block dispatcher 302 is implemented using software or hardware or a combination thereof. For example, each of the parser 609, block creator 604, block buffer 606, block reader 608, and block dispatcher 302 are separate integrated circuits, such as a PLD or ASIC or a portion of a controller or processor or computer program. As another example, each of the parser 609, the block creator 604, the block buffer 606, the block reader 608, and the block dispatcher 302 are separate computer software programs.

Game code gcN includes a plurality of instructions, such as emulated PU code instruction 1, emulated PU code instruction 2, and so forth, up to emulated PU code instruction M. For example, each instruction of game code gcN is a series of bits executable by a processor of a conventional machine to implement a function, such as moving a virtual object from position P1 to position P2, or changing the orientation of a virtual object from O1 to O2, or modifying a parameter of a portion of a virtual object.

The parser 602 is coupled to a block creator 604, which is coupled to a block buffer 606 and a block reader 608. The block buffer 606 and the block reader 608 are either coupled to the buffer 102. Block reader 608 is coupled to block dispatcher 302.

Fig. 6B is a flow chart to illustrate an embodiment of a method 650 for compiling and executing basic blocks 1 through n. The method 650 is illustrated using the system 600 of fig. 6A. In operation 652 of method 650, block creator 604 determines whether any user input, such as user input 1, was received. As an example, user input 1 is a signal including one or more identifications of one or more buttons of handheld controller 414 (fig. 4A) selected by user 1. As another example, user input 1 is a signal generated based on movement metrics such as pitch, yaw, and roll relative to an origin of an xyz coordinate system centered on handheld controller 414. As yet another example, the user input 1 is a signal including movement metrics such as pitch, yaw, and roll relative to an origin of an xyz coordinate system of the HMD. An example of user input 1 is user input 420 (fig. 4A).

After determining that no user input has been received, the block creator 604 continues to check whether user input has been received in operation 652. For example, when no user input is received in operation 652, the basic block compiler 104 does not run any of the basic blocks (n+1) through p stored in the cache 102 (FIG. 1), and the basic block compiler 104 (FIG. 1) does not identify any of the emulated PU code instructions 1 through M (FIG. 6A), where p is a positive integer. Assume that basic blocks 1 through n are not generated and are not stored in the cache 102 when user input is received in operation 652.

On the other hand, in response to determining that user input was received in operation 652, in operation 654 of method 650, block creator 604 determines whether one or more of the basic blocks (n+1) through p stored in cache 102 satisfy the user input. For example, the block creator 604 sends a request to the block reader 608 to access the basic blocks (n+1) through p from the cache 102. In the example, block reader 608 reads basic blocks (n+1) through p from cache 102 after receiving the request and sends basic blocks (n+1) through p to block creator 604. Further, in the example, the block creator 604 determines whether the functionality of one or more of the basic blocks (n+1) through p meets (such as serves) user input 1. To illustrate, when the user input 1 indicates that the position of the virtual object is changed from the position P1 to the position P2, the block creator 604 determines whether any of the basic blocks (n+1) to P includes an operation of overwriting the position P1 with the position P2. After determining that one or more of the basic blocks (n+1) through P includes an operation to overwrite position P1 with P2, block creator 604 determines that one or more functionalities of one or more of blocks (n+1) through P satisfy user input 1. On the other hand, after determining that none of the basic blocks (n+1) to P includes an operation of overwriting the position P1 with P2, the block creator 604 determines that the functionality of the basic blocks (n+1) to P does not satisfy the user input 1.

As another illustration, when user input 1 changes the orientation of the virtual object from orientation O1 to orientation O2, the block creator 604 determines whether any of the basic blocks (n+1) through p includes an operation to overwrite orientation O1 with orientation O2. After determining that one or more of the basic blocks (n+1) through p includes an operation to overwrite orientation O1 with O2, block creator 604 determines that one or more functionalities of one or more of the basic blocks (n+1) through p satisfy user input 1. On the other hand, after determining that none of the basic blocks (n+1) to p includes an operation of overwriting the orientation O1 with O2, the block creator 604 determines that the functionality of the basic blocks (n+1) to p does not satisfy the user input 1. As yet another illustration, after the user input 1 is to change the value of the parameter of the portion of the virtual object from the first value to the second value, the block creator determines whether any of the basic blocks (n+1) through p includes an operation to overwrite the first value with the second value. After determining that one or more of the basic blocks (n+1) through p includes an operation to overwrite the first value with the second value, the block creator 604 determines that one or more functionalities of the one or more of the basic blocks (n+1) through p satisfy user input 1. On the other hand, after determining that none of the basic blocks (n+1) to p includes an operation of overwriting the first value at the second value, the block creator 604 determines that the functionality of the basic blocks (n+1) to p does not satisfy the user input 1.

After determining that the functionality of one or more of the basic blocks (n+1) through p satisfies user input 1, in operation 656 of method 600, block dispatcher 302 executes one or more of the basic blocks (n+1) through p. For example, after determining that the functionality of one or more of the basic blocks (n+1) through p satisfies user input 1, the block creator 604 sends instructions to the block dispatcher 302 to execute the one or more of the basic blocks (n+1) through p. In the example, in response to receiving the instruction, block dispatcher 302 sends a command to block reader 608 to read one or more of basic blocks (n+1) through p from cache 102 in order to satisfy the user input received in operation 652. Also, in the example, block dispatcher 302 executes one or more of basic blocks (n+1) through p after receiving one or more of the basic blocks from cache 102 in response to the command.

On the other hand, after determining that the functionality of blocks (n+1) through p does not satisfy user input 1, in operation 658 of method 600, block compiler 102 identifies one or more of emulated PU code instructions 1 through M for servicing the user input received in operation 652. For example, upon determining that the functionality of blocks (n+1) through p does not satisfy user input 1, block creator 604 sends a request to parser 602 to parse game code gcN to identify and obtain one or more of emulated PU code instructions 1 through M of game code gcN that satisfy the functionality identified in user input 1. In the example, in response to receiving the request, the parser 602 accesses the memory device 412 to parse the game code gcN to determine whether the functionality of one or more of the emulated PU code instructions 1-M satisfies the user input 1, and upon determining that the functionality of one or more of the emulated PU code instructions 1-M satisfies the user input 1, the parser 602 provides one or more of the emulated PU code instructions 1-M to the block creator 604.

To illustrate, when user input 1 is to change the position of the virtual object from position P1 to position P2, parser 602 determines whether any of emulated PU code instructions 1 through M includes an operation to overwrite position P1 with position P2. After determining that one or more of the emulated PU code instructions 1 through M includes an operation to overwrite position P1 with P2, parser 602 determines that one or more functionalities of one or more of emulated PU code instructions 1 through M satisfy user input 1. On the other hand, after determining that none of the emulated PU code instructions 1 through M includes an operation to overwrite position P1 with P2, parser 602 determines that the functionality of emulated PU code instructions 1 through M does not satisfy user input 1.

As another illustration, when user input 1 changes the orientation of the virtual object from orientation O1 to orientation O2, parser 602 determines whether any of emulated PU code instructions 1 through M includes an operation to overwrite orientation O1 with orientation O2. After determining that one or more of the emulated PU code instructions 1 through M includes an operation to overwrite orientation O1 with O2, parser 602 determines that one or more functionalities of one or more of emulated PU code instructions 1 through M satisfy user input 1. On the other hand, after determining that none of the emulated PU code instructions 1 through M includes an operation to overwrite orientation O1 with O2, parser 602 determines that the functionality of emulated PU code instructions 1 through M does not satisfy user input 1. As yet another illustration, after user input 1 is a change in a value of a parameter of a portion of the virtual object from a first value to a second value, the parser 602 determines whether any of the emulated PU code instructions 1 through M includes an operation to overwrite the first value with the second value. After determining that one or more of the emulated PU code instructions 1 through M includes an operation to overwrite the first value with the second value, the parser 602 determines that one or more functionalities of one or more of the emulated PU code instructions 1 through M satisfy user input 1. On the other hand, after determining that none of the emulated PU code instructions 1 through M includes an operation to overwrite the first value at the second value, the parser 602 determines that the functionality of the emulated PU code instructions 1 through M does not satisfy user input 1.

In operation 660 of method 600, when one or more of emulated PU code instructions 1 through M satisfying user input 1 are received from parser 602, block creator 604 applies the above-described compilation operations to generate one or more of basic blocks 1 through n from one or more of emulated PU code instructions 1 through M. For example, block creator 604 compiles one or more of basic blocks 1 through n, sends one or more of basic blocks 1 through n to block buffer 606, and sends instructions to block dispatcher 302 to execute one or more of basic blocks 1 through n. After receiving one or more of basic blocks 1 through n, block buffer 606 stores one or more of basic blocks 1 through n in buffer 102.

In operation 662 of method 600, after receiving an instruction from block creator 604 to execute one or more of basic blocks 1 through n, block dispatcher 302 runs one or more of basic blocks 1 through n to service the user input received in operation 652. For example, block dispatcher 302 sends a request to block reader 608 to read one or more of basic blocks 1 through n from cache 102. After receiving the command, block reader 608 reads one or more of basic blocks 1 through n from cache 102 and provides one or more of basic blocks 1 through n to block dispatcher 302. After receiving one or more of basic blocks 1 through n, block dispatcher 302 executes one or more of basic blocks 1 through n to generate virtual environment 452 (FIG. 4B). To illustrate, block dispatcher 302 executes one or more of basic blocks 1 through n to generate an image frame comprising: virtual environment data, such as the position and orientation of virtual object 454; parameters of virtual object 454, positions and orientations of other virtual objects in virtual environment 452; and parameters of other virtual objects in the virtual environment 452. The block dispatcher 302 provides the image frames to a GPU of the emulation processor system 409 to display (such as render) the virtual environment 452 on a display screen of the display device 410 (fig. 4A). The method 600 repeats when another user input, such as user input 2, is received after user input 1 is received in operation 652.

Fig. 6C is a diagram illustrating an embodiment of a system 670 to dynamically compile different basic blocks or different groups of basic blocks for different user inputs. The system 670 includes the memory device 412, the basic block compiler 104, the block dispatcher 302, and the cache 102. When the basic block compiler 104 receives the user input 1, the basic block compiler 104 determines whether the basic block 1 corresponding to the user input 1 is stored in the cache 102. When basic block 1 includes a function for serving user input 1, basic block 1 corresponds to user input 1. To illustrate, when user input 1 is an operation to move a virtual object from location P1 to location P2 and basic block 1 includes updating location P1 stored at destination register address 1 with location P2, basic block 1 may serve user input 1. In the illustration, user input 1 is a signal indicating selection of a move right button or a move left button or a move up button or a move down button on handheld controller 414 (fig. 4A). Similarly, when basic block 2 does not include functionality for servicing user input 1, basic block 2 does not correspond to user input 1. To illustrate, when the user input 1 is an operation to move the virtual object from the position P1 to the position P2 without changing the orientation of the virtual object and the basic block 2 includes updating the orientation O1 stored in the destination register 2 with the orientation O2, the basic block 2 cannot serve the user input 1. After determining that basic block 1, which may serve user input 1, is stored in cache 102, basic block compiler 104 provides basic block 1 to block dispatcher 302 for execution of basic block 1.

On the other hand, after determining that basic block 1 is not stored in cache 102, basic block compiler 104 parses emulated PU code 106 stored in memory device 412 to identify emulated PU code instruction 1 corresponding to user input 1. For example, the basic block compiler 104 parses the emulated PU code 106 to identify emulated PU code instructions 1 that satisfy (such as service) user input 1. To illustrate, after user input 1 is a function to move a virtual object from location P1 to location P2 and emulation PU code instruction 1 includes updating location P1 stored at destination address 1 with location P2, emulation PU code instruction 1 may service user input 1. Similarly, after emulation PU code instruction 2 does not include functionality for servicing user input 1, emulation PU code instruction 2 does not correspond to user input 1. To illustrate, after user input 1 is an operation to move a virtual object from location P1 to location P2 without changing the orientation of the virtual object and emulation PU code instruction 2 includes updating orientation O1 stored at destination address 2 with orientation O2, emulation PU code instruction 2 cannot service user input 1.

After determining that emulated PU code instruction 1 may service user input 1 and emulated PU code instruction 2 cannot service user input 1, basic block compiler 104 accesses (such as reads) emulated PU code instruction 1 from memory device 412 and compiles basic block 1 from emulated PU code instruction 1. In response to receiving user input 1, basic block compiler 102 does not compile basic block 2 from emulated PU code instruction 2. Basic block compiler 104 stores basic block 1 in cache 102 and sends instructions to block dispatcher 302 to access and execute basic block 1. The block dispatcher 302, upon receiving the instruction, reads basic block 1 from the cache 102 and runs basic block 1.

Similarly, when the basic block compiler 104 receives the user input 2, the basic block compiler 104 determines if the basic block 2 corresponding to the user input 2 is stored in the cache 102. When the basic block 2 includes a function for serving the user input 2, the basic block 2 corresponds to the user input 2. To illustrate, when user input 2 is an operation to move a virtual object from orientation O1 to orientation O2 and basic block 2 includes updating orientation O1 stored at destination register address 2 with orientation O2, basic block 2 may service user input 2. In the illustration, user input 2 is a signal indicating selection of a clockwise or counter-clockwise rotation button on handheld controller 414. Similarly, basic block 1 does not correspond to user input 2 after basic block 1 does not include functionality for servicing user input 2. To illustrate, when the user input 2 is an operation to move the virtual object from the orientation O1 to the orientation O2 without changing the position of the virtual object and the basic block 1 includes updating the position P1 stored in the destination register 1 with the position P2, the basic block 1 cannot serve the user input 2. After determining that basic block 2, which may serve user input 2, is stored in cache 102, basic block compiler 104 provides basic block 2 to block dispatcher 302 for execution of basic block 2.

On the other hand, after determining that basic block 2 is not stored in cache 102, basic block compiler 104 parses emulated PU code 106 stored in memory device 412 to identify emulated PU code instruction 2 corresponding to user input 2. For example, the basic block compiler 104 parses the emulated PU code 106 to identify emulated PU code instructions 2 that satisfy (such as service) user input 2. To illustrate, after user input 2 is a function to move a virtual object from orientation O1 to orientation O2 and emulation PU code instruction 2 includes updating orientation O1 stored at destination address 2 with orientation O2, the emulation PU code instruction 2 may service user input 2. Similarly, when emulated PU code instruction 1 does not include functionality for servicing user input 2, the emulated PU code instruction 1 does not correspond to user input 2. To illustrate, after user input 2 is an operation to move a virtual object from orientation O1 to orientation O2 without changing the location of the virtual object and emulation PU code instruction 1 includes updating location P1 stored in destination address 1 with location P2, emulation PU code instruction 1 cannot service user input 2.

After determining that emulated PU code instruction 2 may service user input 2 and emulated PU code instruction 1 cannot service user input 2, basic block compiler 104 accesses (such as reads) emulated PU code instruction 2 from memory device 412 and compiles emulated PU code instruction 2 to generate basic block 2. In response to receiving user input 2, basic block compiler 102 does not compile emulated PU code instruction 1. Basic block compiler 104 stores basic block 2 in cache 102 and sends instructions to block dispatcher 302 to access and execute basic block 2. The block dispatcher 302, upon receiving the instruction, reads basic block 2 from the cache 102 and runs basic block 2.

FIG. 7A is a diagram to illustrate an implementation of a system 700 to delete emulated PU code 106 from memory device 412. The system 700 includes a block creator 604, an instruction remover 702, and a memory device 412. Examples of instruction remover 702 include a processor, an ASIC, a PLD, a computer program, a portion of a computer program, and a microcontroller. Instruction remover 702 is coupled to block creator 604 and memory device 412.

FIG. 7B is a flowchart to illustrate an implementation of a method 720 for deleting emulated PU code 106 (FIG. 6C) from memory device 412 (FIG. 6C). The method 720 includes an operation 702 for determining whether all instructions emulating the PU code 106 have been compiled. For example, the block creator 604 (FIG. 7A) determines whether all emulated PU code instructions 1 through M of the game code gcN have been compiled. To illustrate, before compiling any of the emulated PU code instructions 1 through M of game code gcN, block creator 604 sends a request to the processor of the legacy machine to obtain the identity of all emulated PU code instructions 1 through M of game code gcN. In the illustration, the block creator 604 sends the identity of the game code gcN (such as one or more bits) to the processor of the legacy machine to obtain the identities of all emulated PU code instructions 1 through M of the game code gcN. Examples of emulating the identity of PU code instructions 1 through M include one or more bits. To illustrate, the identity of the emulated PU code instruction M is represented by a first sequence of bits, and the identity of the emulated PU code instruction M-1 is represented by a second sequence of bits that is different from the first sequence. After receiving the identities of emulated PU code instructions 1 through M from the processor of the legacy machine, the block creator 604 stores the identities in the cache 102 in a table. As each of the emulated PU code instructions 1-M are compiled, the block creator 604 updates the table to include an indication that identifies which of the emulated PU code instructions 1-M are compiled. The block creator 604 determines whether all emulated PU code instructions 1 through M are compiled based on an indication that identifies which emulated PU code instructions 1 through M are compiled.

After determining that all emulated PU code instructions 1 through M of game code gcN have been compiled, block creator 604 sends a command to instruction remover 702 (FIG. 7A) to delete game code gcN from memory device 412. After receiving the command, in operation 724 of method 720, instruction remover 702 erases emulated PU code instructions 1 through M from memory device 412.

On the other hand, after determining, based on the table, that one or more of the emulated PU code instructions 1-M of game code gcN have not been compiled, in operation 726 of method 720, block creator 604 does not send a command to instruction remover 702 to delete game code gcN from memory device 412. The instruction remover 702 does not delete emulated PU code instructions 1 through M from the memory device 412 until a command to delete game code gcN is received.

In one embodiment, the block creator 604 determines whether to access the game code gcN stored in the cache 102 from the memory device 412 (fig. 4A) within a predetermined period of time from the most recent time the game code gcN was accessed from the memory device 412. As an example, the block creator 604 may access an internet clock via the computer network 408 to determine the most recent time and the predetermined period. As another example, the block creator 604 includes a clock source, such as a clock oscillator, to count the most recent time and the predetermined period of time. After determining that the game code gcN is not accessed from the memory device 412 within the predetermined period, the block creator 604 sends a command to the instruction remover 702 to delete the game code gcN from the memory device 412. As an example, when game code gcN is not accessed within a predetermined period, most of emulated CPU code instructions 1 through M are accessed by basic block compiler 104 to compile one or more of basic blocks 1 through n. As another example, when the game code gcN is not accessed within a predetermined period, many emulated CPU code instructions 1 through M that are frequently used during a conventional game N in which the toy has a game name GN are accessed by the basic block compiler 104 to compile one or more of the basic blocks 1 through N. On the other hand, after determining to access the game code gcN within the predetermined period, the block creator 604 does not send a command to the instruction remover 702 and does not delete the game code gcN from the memory device 412.

FIG. 8A is a diagram of an embodiment of an emulation processor system 800 to illustrate verification of a basic block. The emulated processor system 800 is an example of an emulated processor system 409 (fig. 4B). The emulation processor system 800 includes a basic block compiler 104, a cache 102, a block validator 802, and a block marker 804. Block verifier 802 is coupled to block creator 604, block dispatcher 302, parser 602, and block marker 804. Each of the clock validator 802 and the block marker 804 is coupled to the cache 102.

As an example, the block verifier 802 is implemented as an ASIC, or a PLD, or a microcontroller, or a processor, or a computer program, or as part of a computer program. Also by way of example, the block marker 804 is implemented as an ASIC, or a PLD, or a microcontroller, or a processor, or a computer program, or a portion of a computer program.

In one embodiment, the terms ASIC, PLD, microcontroller, microprocessor, controller, and processor are used interchangeably herein.

FIG. 8B is a flowchart of an implementation of a method 850 to illustrate a verification operation performed by the emulated processor system 800 (FIG. 8A). In operation 852 of method 800, block verifier 802 (fig. 8A) determines whether basic block n is compiled. For example, the block verifier 802 accesses (such as reads) the cache 102 to determine whether a new basic block (such as basic block n) is now stored in the cache 102 as compared to basic blocks 1 through n-1 previously stored in the cache 102. Block verifier 802 previously identified basic blocks 1 through n-1 stored in cache 102. After determining that basic block n is not cached, block verifier 802 continues to access cache 102 to determine whether a new basic block is cached. For example, block verifier 802 periodically parses basic blocks 1 through n-1 stored in cache 102 to determine if basic block n is stored in cache 102.

After determining that basic block n is cached, in operation 854 of method 800, block verifier 802 creates a first hash value from one or more of emulated PU code instructions 1 through M from which basic block n was compiled. For example, block verifier 802 sends a request to parser 602 to obtain one or more of emulated CPU code instructions 1 through M from memory device 412. The request includes the identity of the memory address of basic block n in cache 102. The block verifier 602 receives (such as by request) the identity of the memory address of basic block n from the block creator 604. Parser 602, upon receiving a request from block verifier 802, reads one or more of emulated PU code instructions 1 through M from memory device 412 and provides one or more of emulated PU code instructions 1 through M to block verifier 802. To illustrate, when one or more of emulated PU code instructions 1 through M are provided to basic block compiler 104 to compile basic block n, parser 602 stores a one-to-one correspondence between one or more identities of one or more memory addresses occupied by basic block n in cache 102 and one or more identities of one or more memory addresses occupied by one or more of emulated PU code instructions 1 through M in memory device 412. The parser 602 receives the identity of the memory address of the basic block n in the cache 102 from the block verifier 802 and identifies one or more memory addresses in the memory device 412 of one or more of the emulated PU code instructions 1 to M according to the one-to-one correspondence. The parser 602 reads one or more of the emulated PU code instructions 1 through M from one or more memory addresses of the memory device 412 and provides one or more of the emulated PU code instructions 1 through M to the block verifier 802.

Continuing with the example, after receiving one or more of emulated PU code instructions 1 through M from resolver 602, block verifier 802 generates a first hash value from the one or more of emulated PU code instructions 1 through M and stores the first hash value in cache 102. To illustrate, the block validator 802 generates a digest or checksum from one or more of the emulated PU code instructions 1-M corresponding to the basic block n. In the example, the first hash value is stored in one or more registers of cache 102 that are typed to include basic block n.

In operation 856 of method 800, block verifier 802 sends a command to parser 602 to determine whether one or more memory addresses within memory device 412 at which one or more of emulated PU code instructions 1-M are stored are overwritten. One or more memory addresses within memory device 412 may be overwritten with data from a compact disc-read only memory (CD-ROM) of a conventional machine. The data may be updates to one or more of emulated PU code instructions 1 through M. The update to one or more of emulated PU code instructions 1 through M is referred to as an updated instruction. Alternatively, the data may be corrupted data, which is not an updated instruction. Parser 602, upon receiving a command from block verifier 802, sends a request to a processor of a legacy machine to determine whether one or more memory addresses within memory device 412 at which to store one or more of emulated PU code instructions 1 through M are overwritten.

Upon receiving a request from resolver 602, the processor of the legacy machine provides a response to the request, and the response indicates whether the one or more memory addresses within memory device 412 at which one or more of emulated PU code instructions 1 through M are stored are overwritten. Upon receiving a response within memory device 412 that the one or more memory addresses at which one or more of emulated PU code instructions 1-M are stored are not overwritten, block verifier 802 sends a command to block marker 804 (FIG. 8A) that does not mark basic block n as invalid. After receiving the command, the block marker 804 does not mark the basic block n as invalid in operation 858 of the method 800.

On the other hand, upon receiving a response within memory device 412 that the one or more memory addresses at which one or more of emulated PU code instructions 1-M are stored are overwritten, block verifier 802 sends a command to block marker 804 (FIG. 8A) to mark basic block n as invalid in operation 860 of method 850. After receiving the command to mark basic block n as invalid, block marker 804 marks basic block n as invalid. For example, the block marker 804 accesses a basic block n within the cache 102 and includes an identifier, such as an invalidate flag n (FIG. 5A), within a memory address having the basic block n in the cache 102 to indicate that the basic block n is invalid. An example of an invalid flag n is a bit sequence.

In one embodiment, the hash value is an example of a verification result.

Fig. 8C is a continuation of the flow chart of method 800 of fig. 8B. In operation 862 of method 800, block verifier 802 (fig. 8A) determines whether basic block n is to be executed. For example, block dispatcher 302 sends an indication to block validator 802 that basic block n is to be executed. After receiving an indication from block dispatcher 302 that basic block n is to be executed, block validator 802 determines that basic block n is to be executed. Before receiving the indication, the block verifier 802 does not determine that the basic block n is verified.

After determining that basic block n is to be executed, block verifier 802 determines whether basic block n is marked as invalid in operation 864 of method 800. For example, block verifier 802 sends a command to block marker 804 to determine whether basic block n is marked as invalid. After receiving the command, the block marker 804 sends an indication to the block verifier 802 of whether the basic block n is marked invalid. To illustrate, the block marker 804 accesses the basic block n to determine whether the basic block n includes an invalidation flag n to generate and send an indication of invalidity to the block verifier 802. As another illustration, the block marker 804 accesses the basic block n to determine whether the basic block n does not include an invalidation flag n to generate and send an indication of lack of invalidity to the block verifier 802. After receiving an indication from the block marker 804 that the basic block n is marked as invalid, the block verifier 802 determines that the basic block n is invalid. On the other hand, upon receiving an indication from the block marker 804 that the basic block n is not marked invalid, the block verifier 802 determines that the basic block n is not marked invalid.

After determining that basic block n is not marked as invalid, basic block n is executed in operation 866 of method 800. For example, operation 866 is similar to operation 662 (fig. 6B). To illustrate, block validator 802 sends a command to block dispatcher 302 to execute basic block n. After receiving a command to execute basic block n, block dispatcher 302 runs basic block n. In this illustration, block dispatcher 302 does not execute basic block n until a command to execute basic block n is received from block verifier 802.

On the other hand, in response to determining that basic block n is marked as invalid, block verifier 802 determines whether basic block n is actually valid in operation 866 of method 800. For example, after determining that basic block n is marked as invalid, block verifier 802 creates a second hash value from updated instructions or corrupted data in the same memory address of one or more of emulated PU code instructions 1-M, upon which basic block n is stored, stored within memory device 412. In the example, the second hash value is stored in one or more registers of cache 102 that are entered to include basic block n. To illustrate, the block verifier 802 sends a request to the parser 602 to obtain updated instructions or corrupted data at one or more memory addresses stored within the memory device 412. Parser 602, upon receiving the request, reads the updated instructions or corrupted data from memory device 412 from the one or more memory addresses and provides the updated instructions or the corrupted data to block verifier 802. In this illustration, the block verifier 802 generates a second hash value from the updated instruction or corrupted data and stores the second hash value in the cache 102. For example, block verifier 802 generates a digest or checksum from the updated instructions or the corrupted data. In the illustration, block verifier 802 compares the second hash value with the first hash value to determine whether basic block n is valid. After determining that there is a match between the first hash value and the second hash value based on the comparison, block verifier 802 determines that basic block n is valid. The matching occurs when a second hash value is generated from the updated instruction. On the other hand, after determining that there is no match between the first hash value and the second hash value based on the comparison, block verifier 802 determines that basic block n is invalid. When the second hash value is generated from the corrupted data, a mismatch occurs.

In response to determining that basic block n is valid, in operation 870 of method 800, invalid flag n is removed. For example, the block verifier 802 sends a command to the block marker 804 to remove the invalid marker n from the basic block n stored in the cache 102. Upon receiving a command from the block verifier 802, the block marker 804 accesses the basic block n from the cache 102 and erases the invalid marker n from the basic block n. To illustrate, the block marker 804 erases the invalid tag n from one or more memory addresses of the cache 102 in which the invalid tag n is stored. After removing the invalid flag n, the block marker 804 sends a command to the block dispatcher 302 to execute the basic block n, and after receiving the command, the block dispatcher 302 runs the basic block n in operation 866. As an example, block dispatcher 302 does not execute basic block n until a command to execute basic block n is received from block marker 804.

On the other hand, after determining that basic block n is not valid, in operation 872 of method 800, additional basic blocks having the same functionality or operation as basic block n are compiled. For example, block verifier 802 sends a command to block dispatcher 302 to not execute basic block n, and sends an indication to block creator 604 that basic block n is invalid. After receiving the indication, the block creator 604 recompiles the basic block n. To illustrate, the block creator 604 compiles an additional basic block in the same manner as basic block n was compiled from one or more of the emulated PU code instructions 1-M stored in the memory device 412, except that the additional basic block is compiled from a set of additional emulated PU code instructions (such as one or more of emulated PU code instructions 1-M) stored within the memory device of an additional conventional machine. The additional legacy machine is different from the legacy machine that includes the memory device 412. Also, the additional set of emulated PU code instructions has a game name GN that is the same as the game name of game code gcN. As another illustration, the block creator 604 compiles an additional basic block in the same manner as basic block n was compiled from one or more of the plurality of emulated PU code instructions 1-M stored in memory device 412, except that the additional basic block is compiled from a set of additional emulated PU code instructions (such as one or more of emulated PU code instructions 1-M) stored within a memory address of memory device 412 that is different from the memory address of memory device 412 at which emulated PU code instructions 1-M were stored. As yet another illustration, the block creator 604 compiles additional basic blocks in the same manner as basic block n was compiled from one or more of the emulated PU code instructions 1-M stored in the memory device 412, except that the additional basic blocks are compiled from a set of additional emulated PU code instructions (such as one or more of emulated PU code instructions 1-M) stored within a memory device that is different from the memory device 412.

The additional basic blocks are sent from the block creator 604 to the block dispatcher 302 for execution. For example, block dispatcher 302 executes the additional basic blocks to generate a portion of an additional virtual environment, such as virtual environment 452 (fig. 4B). To illustrate, the block dispatcher 302 executes additional basic blocks to generate a portion of an image frame that includes additional virtual environment data, such as the position and orientation of the virtual object 454, parameters of the virtual object 454, the position and orientation of other virtual objects in the virtual environment 452, and parameters of other virtual objects in the additional virtual environment. The block dispatcher 302 provides the image frames to a GPU of the emulation processor system 409 to display (such as render) the additional virtual environment on a display screen of the display device 410.

It should be noted that although method 850 is described with reference to basic block n and additional basic blocks, method 850 is equally applicable to other basic blocks 1 through (n-1) and more additional basic blocks generated in the same manner as the additional basic blocks are generated.

In one embodiment, the set of emulated PU code instructions 1 through M are stored in a first set of one or more memory devices located external to the legacy machine, and the additional set of emulated PU code instructions are stored in a second set of one or more memory devices located external to the additional legacy machine.

Fig. 9A is a diagram to illustrate an embodiment of a conventional machine 900. An example of a conventional machine 900 is PS1 ^TM Or PS2 ^TM . The legacy machine 900 includes a legacy CPU 902 and a legacy CPUA system GPU 904, a memory device 906, and a CD-ROM drive 908. Memory device 906 is an example of memory device 412 (fig. 4A). An example of a conventional CPU 902 is a 32-bit CPU that can handle up to 32 bits during one clock cycle. Moreover, an example of a conventional GPU 904 is a 32-bit GPU, which can process up to 32 bits during one clock cycle. An example of the memory device 906 is 2 Megabytes (MB) of RAM.

The conventional CPU 902 and the conventional GPU 904 are coupled to a memory device 906, which is coupled to a CD-ROM drive 908. The emulated PU code 106 is stored within the memory device 906.

The legacy CPU 902 or the legacy GPU 904 accesses the emulated PU code 106 from the memory device 906 and processes the emulated PU code 106. The CD-ROM drive 908 receives a CD-ROM that includes updated instructions or corrupted code. Updated instructions or corrupted code may be transferred from the CD-ROM to the memory device 906 by the conventional CPU 902.

In one embodiment, the legacy machine 900 does not include a cache. In one embodiment, the legacy machine 900 includes a limited capacity cache, such as a 4 Kilobyte (KB) cache.

Fig. 9B is a diagram to illustrate an embodiment of the machine 920 after updating. An example of an updated machine 920 is PS4 ^TM Or PS5 ^TM . Updated machine 920 includes CPU 922, GPU 924, memory system 926, and cache 928 as an example of cache 102 (fig. 1). Game console 402 (fig. 4B) is an example of updated machine 920. As an example, CPU 922 includes two four core modules, and each module may process 64 bits during each clock cycle. Each core has a 32 Kilobyte (KB) cache. Another example of CPU 922 is a 64-bit CPU that can handle up to 64 bits during one clock cycle. As an example, GPU 924 has 1152 cores, and each core may process 64 bits during one clock cycle. As another example, conventional GPU 924 is a 64-bit GPU that can process up to 64 bits during one clock cycle.

CPU 922 and GPU 924 are coupled to memory system 906. As an example, emulated PU code 106 is stored within legacy memory system 906. Examples of memory system 926 include a hard disk drive that provides 500 Gigabytes (GB) or 2 megabytes (TB) of storage. CPU 922, GPU 924, cache 928, and memory system 926 are coupled to one another via bus 930.

CPU 922 or GPU 924 first accesses cache 928 before accessing memory system 926. After determining that cache 928 does not have data requested by CPU 922 or GPU 924, CPU 922 or GPU 924 accesses memory system 926.

It should be noted that in one implementation, game code gcN cannot be executed by CPU 922 or GPU 924, but may be executed by conventional CPU 902 or conventional GPU 904. Moreover, basic blocks 1 through n may be executed by CPU 922 or GPU 924, but not by conventional CPU 902 or conventional GPU 904.

In one embodiment, cache 928 is located within CPU 922.

In one implementation, cache 928 is located within GPU 924.

In one embodiment, cache 928 is located within CPU 922, while another cache, such as cache 102, is located within GPU 924.

Fig. 10A is a diagram illustrating an embodiment of a system 1000 for combining a plurality of basic blocks into one basic block by the basic block compiler 104 (fig. 1). The block creator 604 (fig. 6A) receives a user input 1, such as a signal indicating that the virtual object 454 (fig. 4B) is launched at position P1 and orientation O1 at the 1 st pass of the legacy game N with the game name GN. Upon receiving user input 1, the basic block compiler 104 generates basic block 1 to service user input 1 based on the emulated PU code instruction 1. Similarly, the block creator 604 receives user input 2, such as a signal indicating that the virtual object 454 is launched at position P1 and orientation O1 at the 2 nd pass of the legacy game N. After receiving user input 2, basic block 2 is generated by basic block compiler 104 based on emulated PU generate code instructions 2 to service user input 2.

Upon receiving user input 3, such as a signal indicating that virtual object 454 is launched at position P1 and orientation O1 at 3 rd pass of legacy game N, block compiler 104 identifies basic blocks 1 and 2 as serving user input 3. After such identification, block creator 604 integrates (such as combines) basic blocks 1 and 2 into a single basic block, such as basic block 1 or basic block 2. The integration saves memory space in cache 102 and also increases the efficiency of accessing a single basic block instead of basic block 1 and basic block 2.

The block creator 604 further generates a value in a pointer of the cache 102. As used herein, an example of a pointer is a register. When user input is received to service basic block 1 or basic block 2, the pointer instructs block dispatcher 302 to execute the single basic block. When block dispatcher 302 is to execute basic block 1 or 2, block dispatcher 302 accesses the pointer and executes a single basic block instead of basic block 1 or 2.

Fig. 10B is a diagram of an implementation of a system 1020 to illustrate modifications to one or more of the basic blocks 1-n. The system 1020 includes a block interface 1022, a cache 102, and a block dispatcher 302. As an example, the basic block n includes a dead reckoning operation n. As another example, basic block n includes operation n to bounce off the edge of the display screen of display device 410 (fig. 4B) to a crosshair. Examples of block interfaces 1022 are an ASIC, or a PLD, or a microprocessor, or a microcontroller, or a computer program, or a portion of a computer program. The block interface 1022 is coupled to the cache 102.

The block interface 1022 provides the user with access to one or more of the basic blocks 1 through n stored in the cache 102. For example, the user selects one or more buttons on the input device, such as a keyboard or mouse or keypad, to generate the modification input 1024. As an example, modification input 1024 includes one or more user instructions in the form of source code to modify basic block n. To illustrate, the modification input 1024 includes user instructions for removing the dead reckoning operation n from the basic block n. As another example, modifying input 1024 includes changing operation n to include instructions for: the crosshairs slide off the edge of the display screen of the display device 410 and are displayed at the opposite edge of the display screen of the display device 410. The opposite edge is diagonally opposite the edge from which the crosshair slides.

The input device is coupled to the block interface 1022. The modification input 1024 is sent from the input device to the block interface 1022 to modify the basic block n to output the modified basic block n. As an example, the modified basic block n does not include dead reckoning operations. As another example, the modified basic block n includes an operation n of sliding the crosshair off the edge to the opposite edge. As yet another example, the modified basic block n includes an operation of calculating a number of clock cycles of execution of the operation n and storing the number in the basic block n. To illustrate, the number of cycles is stored in the memory address of the cache 102 in which basic block 1 is stored. In addition to performing operation n, block allocator 302 (fig. 3) also performs operations that count the number of clock cycles. The block dispatcher 302 calculates the number of clock cycles after performing operation n and stores the number in the basic block n.

The block creator 604 further generates a value in a pointer within the cache 102 and, when user input is received to serve the basic block n, the pointer instructs the block dispatcher 302 to execute the modified basic block n. When block dispatcher 302 is to execute basic block n, block dispatcher 302 accesses the pointer and executes modified basic block n instead of basic block n.

FIG. 10C is a diagram of an embodiment of a system 1030 to illustrate a combination of basic blocks created based on a subroutine and basic blocks generated based on emulated PU code instructions that call the subroutine. The block creator 604 (fig. 6A) receives a user input 1, such as a signal indicative of a change in the position and/or orientation of the virtual object 454 (fig. 4B), which results in corruption of the virtual object 454. After receiving user input 1, basic block compiler 104 generates basic block 1 to service user input 1 based on emulated PU code instruction 1. The emulated PU code instruction 1 includes a function call to subroutine 1. Thus, after receiving user input 1, basic block 2 is generated by basic block compiler 104 based on subroutine 1, which is an example of emulated PU code instruction 2. As an example, basic block 2 includes operation 2 of regenerating virtual object 454 at position P1 and orientation O1.

Upon receiving user input 2, such as a signal indicating a change in the location and/or orientation of virtual object 454 (fig. 4B) that resulted in a disruption to virtual object 454, block compiler 104 identifies basic blocks 1 and 2 as serving user input 2. After such identification, block creator 604 integrates (such as combines) basic blocks 1 and 2 into a single basic block, such as basic block 1 or basic block 2. For example, upon receipt of user input 2, the destruction of virtual object 454 and the regeneration of virtual object 454 is triggered. Subroutine 1 is skipped when basic blocks 1 and 2 are combined.

The block creator 604 further generates and stores the value in a pointer within the cache 102. When user input is received to service basic block 1 and basic block 2, the value instructs block dispatcher 302 to execute the single basic block. When block dispatcher 302 is to execute basic block 1 and basic block 2, block dispatcher 302 accesses the pointer and executes a single basic block instead of basic block 1.

Fig. 10D is a diagram to illustrate an embodiment of a system 1040 to insert a basic block between two basic blocks. The system 1040 includes a block interface 1022 and a cache 102. After basic blocks 1 and 2 are stored in cache 102, modification input 1042 is received from the user via an input device. As an example, modification input 1042 is a signal comprising source code defining basic block 1.1, which includes source register address 1.1 within cache 102, destination register address 1.1 within cache 102, and operation 1.1 to be performed on data stored within source register address 1.1 or on destination register address 1.1 or on both source register address and destination register address 1.1. Examples of operations 1.1 include jump, store, load, branch, and arithmetic operations.

The modification input 1042 also includes an indication of the location of basic block 1.1 and an association of basic block 1.1 with basic block 1 or 2. For example, modification input 1042 includes a signal indicating that basic block 1.1 is to be inserted between basic blocks 1 and 2 in cache 102, and a signal indicating that basic block 1.1 is to be linked to basic blocks 1 and/or 2. To illustrate, basic block 1.1 is inserted to include a location, such as one or more register addresses, in cache 102 for receiving an invalid tag 2 of basic block 2. As another illustration, basic block 1.1 is inserted to include a location for receiving the number of execution cycles of basic block 2, such as one or more register addresses in cache 102. In the illustration, the block interface 1022 receives the modification input 1042, identifies from the modification input 1042 that the basic block 1.1 is to be inserted between basic block 1 and basic block 2, and inserts the basic block 1.1 between basic blocks 1 and 2. As another illustration, the tile interface 1022 determines that the base tile 1.1 includes an operation for unlocking a level in the legacy game N having the game name GN. The gate is interposed between a first gate identified in the operation of basic block 1 and a second gate identified in the operation of basic block 2. The first gate and the second gate are in a legacy game N having a game name GN. The gate inserted between the first gate and the second gate is not part of the game code gcN, but is a new gate of the conventional game N. An example of a checkpoint interposed between a first checkpoint and a second checkpoint is where virtual object 454 emits a laser gun in place of the checkpoint of the missile.

In addition, the block interface 1022 identifies the value of the pointer from the modification input 1042 and stores the value in the cache 102. As an example, the value of the pointer indicates that the execution of basic block 1.1 occurs immediately before the execution of basic block 2. When block dispatcher 302 is to execute basic block 2, block dispatcher 302 recognizes that the value within the pointer points to basic block 1.1 and executes basic block 1.1 immediately prior to executing basic block 2. As another example, the value of the pointer indicates that the execution of basic block 1.1 occurs immediately after the execution of basic block 2. After the block dispatcher 302 executes basic block 2, the block dispatcher 302 recognizes that the value within the pointer points to basic block 1.1 and executes basic block 1.1 immediately after the execution of basic block 2.

Fig. 10E is a diagram of an embodiment of a system 1050 to illustrate the switching of the execution order of basic blocks. The system 1050 includes a cache 102 and a block interface 1022. The cache 102 includes a value within the pointer of the cache 102 and the value indicates that basic block 2 is executed after basic block 1 is executed. The user provides a modification input 1052 using an input device, the modification input comprising a signal indicating the order in which the execution of basic blocks 1 and 2 is switched. The block interface 1022 changes the value of the pointer in the cache 102 after receiving the signal to indicate that basic block 1 is executed after basic block 2 is executed.

Fig. 11A is a flow chart to illustrate an implementation of a method 1100 using an actual count of the number of cycles stored in a basic block n. The method 1100 includes performing operation 662 of the basic block n. In operation 1102 of method 1100, block dispatcher 302 (FIG. 3) counts the number of execution cycles of basic block n in operation 662 to generate a first count. In operation 1104 of method 1100, block dispatcher 302 stores the first count in basic block n. For example, block allocator 302 writes the actual count to a register having one of the register addresses assigned to basic block n within cache 102.

In operation 1106 of the method 1100, the block creator 604 (fig. 6A) determines whether the same basic block n is to be executed again. For example, the block creator 604 determines whether user input is received from the client device to serve the same basic block n. The block creator 604 continues to determine whether user input is received to serve the same basic block n until user input is received.

Fig. 11B is a continuation of the flow chart of method 1100 of fig. 11A. After determining that user input for servicing basic block n is again received, block dispatcher 304 again executes basic block n. In operation 1108 of method 1100, block dispatcher 304 counts the number of execution cycles of basic block n in operation 1106 to calculate a second count.

In operation 1108 of method 1100, block dispatcher 304 determines whether the second count is within a predetermined limit relative to the first count. The predetermined limit is stored in the cache 102. In response to determining that the second count is not within the predetermined limit relative to the first count, in operation 1110 of method 1100, block dispatcher 304 generates a notification. For example, when the block dispatcher 304 is located within the game console 402 (fig. 4A), the GPU 924 (fig. 9B) of the game console 402 displays a representation of the notification on the display device 410 (fig. 4A) of the client device and sends the notification and to the server system 404 via the computer network 408 to notify the server system 404. As another example, when the block dispatcher 304 is located within the server system 404 (fig. 4B), the block dispatcher 304 generates a notification and the GPU of the server system 404 displays a representation of the notification on a display device coupled to the server system 404. On the other hand, in operation 1112 of method 1100, it is determined that the second count is within a predetermined limit relative to the first count, the block dispatcher 304 does not trigger a notification.

Fig. 12 is a diagram to illustrate an implementation of a system 1200 that transfers basic blocks 1 through n from a first client device to a second client device. The system 1200 includes a game console 402, a computer network 408, a server system 404, a game console 1202, and a display device 1204. Game console 1202 is similar to game console 402. For example, game consoles 402 and 1202 are both PS4 ^TM Or both game consoles 402 and 1202 are PS5 ^TM Or game console 402 is PS4 ^TM While game console 1202 is PS5 ^TM Or game console 402 is PS5 ^TM While game console 1202 is PS4 ^TM . As another example, game console 1202 is not a traditional machine. Also, the display device 1204 is similar to the display device 410 of fig. 4A. For example, the display device 410 is an HMD or television or smart television or computer monitor.

The game console 402 includes a network interface controller 1212. Game console 1202 includes an emulation processor system 1206, a cache 1208, and a network interface controller 1210. The emulation processor system 1206 has the same structure and the same functionality as the emulation processor system 409. Moreover, the cache 1208 has the same structure and the same functionality as the cache 102. The emulation processor system 1206, the cache 1208, and the network interface controller 1210 are coupled to one another via a bus 1218.

Once the basic blocks 1 through n are stored in the cache 102, the basic block compiler 104 of the emulation processor system 409 sends the basic blocks 1 through n to the network interface controller 1212. The network interface controller 1212 applies a network communication protocol to the basic blocks 1 through n to generate one or more packets embedded in the basic blocks 1 through n and transmits the one or more packets to the server system 404 via the computer network 408. After receiving the one or more data packets, the network interface controller of the server system 404 applies a network communication protocol to the one or more packets to extract basic blocks 1 through N of the legacy game N having the game name GN and stores the basic blocks 1 through N in one or more memory devices of the server system 404.

User 2 uses handheld controller 1212 to select one or more buttons on handheld controller 1212 to log into his/her user account assigned to user 2 by server system 404. When user ID2 and password are authenticated by server system 404, user 2 logs into his/her user account. Once the user 2 logs in his/her user account, the user 2 can access a plurality of game names, such as game name G1, game name Ga, game name G2, and so on, until game name GN.

After logging into user account 2, user 2 uses handheld controller 1212 to select one or more buttons on handheld controller 1212 to generate user input 1214. The user input 1214 is generated after the conventional game N having the name GN displayed on the display device 1204 is selected. When user input 1214 is generated, cache 1208 does not include basic blocks 1 through n. For example, upon receiving the user input 1214, the basic block compiler of the simulation processor system 1206 examines the cache 102 to determine if the cache 102 includes one or more of the basic blocks 1 through n of the game code GCN for servicing the user input 1214. Upon determining that cache 102 does not include one or more of basic blocks 1 through n for servicing user input 1214, emulation processor system 1206 generates a request 1220 for one or more of basic blocks 1 through n and sends request 1220 to network interface controller 1210.

After receiving the request 1220, the network interface controller 1210 generates one or more packets embedded in the request 1220 by applying a network communication protocol to the request 1220 and sends the one or more packets to the server system 404 via the computer network 408. The network interface controller of server system 404 receives the one or more packets and applies a network communication protocol to extract a request 1220 from the one or more packets. The processor of server system 404 analyzes request 1220 to identify that basic blocks 1 through n are requested.

In response to determining that the basic blocks 1 through n are requested, the server system 404 accesses the basic blocks 1 through n stored in one or more memory devices of the server system 404 and provides the basic blocks 1 through n to a network interface controller of the server system 404. The network interface controller of server system 404 applies a network communication protocol to generate one or more packets embedded in basic blocks 1 through n and sends the one or more packets to game console 1202 via computer network 408.

The network interface controller 1210 of the game console 1202 receives one or more packets having basic blocks 1 through n, applies a network communication protocol to extract basic blocks 1 through n from the one or more packets, and sends basic blocks 1 through n to the simulation processor system 1206. The basic block compiler of the emulation processor system 1206 stores basic blocks 1 through n in the cache 1208.

When user input 1224 is received from handheld controller 1212 during a game in which the toy has a game name GN, the basic block compiler of emulation processor system 1206 identifies one or more of basic blocks 1 through n within cache 1208 for servicing user input 1224. The block dispatcher of the simulation processor system 1206 executes one or more of the basic blocks 1 through n for servicing the user input 1224. In this manner, once the basic blocks 1 through n are compiled by the simulation processor system 409, the basic blocks 1 through n need not be compiled by the simulation processor system 1206, but rather may be accessed by the simulation processor system 1206 from the server system 404.

Fig. 13 is a flowchart conceptually illustrating various operations performed for streaming a cloud video game to a client device, in accordance with an implementation of the present disclosure. Examples of client devices include game controllers, smart phones, gaming machines, and computers. Game server 1302 executes game program 458 (fig. 4B), such as a video game, and generates raw (uncompressed) video 1304 and audio 1306. The virtual environment 452 (fig. 4A) and audio output during presentation of the virtual environment 452 are examples of video 1004 and audio 1306. Game server 1302 is an example of server system 404 (fig. 4A). Video 1304 and audio 1306 are captured and encoded for streaming purposes, as indicated at reference numeral 1308 in the illustrated figures. Encoding provides compression of video and audio streams to reduce bandwidth usage and optimize the gaming experience. Examples of encoding formats include H.265/MPEG-H, H.264/MPEG-4, H.263/MPEG-4, H.262/MPEG-2, WMV, VP6/7/8/9, etc.

The encoded audio 1310 and the encoded video 1312 are further packetized into network packets, as indicated at 1314, for transmission over a computer network 1320, which is an example of the computer network 408 (fig. 4A). In some embodiments, the network data packet encoding process also employs a data encryption process, thereby providing enhanced data security. In the illustrated implementation, audio packets 1316 and video packets 1318 are generated for transmission via computer network 1320.

The game server 1302 additionally generates haptic feedback data 1322 that is also packetized into network packets for network transmission. In the illustrated implementation, haptic feedback packet 1324 is generated for transmission via computer network 1320.

The foregoing operations of generating raw video and audio and haptic feedback data are performed on the game server 1302 of the data center, and the operations of encoding the video and audio and packetizing the encoded audio/video and haptic feedback data for transmission are performed by the streaming engine of the data center. As indicated, audio, video, and haptic feedback packets are transmitted via computer network 1320. As indicated at reference numeral 1326, the audio packet 1316, the video packet 1318, and the haptic feedback packet 1324 are broken up, e.g., parsed, etc., by the client device to extract the encoded audio 1328, the encoded video 1330, and the haptic feedback data 1322 from the network packet at the client device. If the data has been encrypted, the data is also decrypted. The encoded audio 1328 and encoded video 1330 are then decoded by the client device, as indicated at reference numeral 1334, to generate client-side raw audio and video data for rendering on the display device 1340 of the client device. The haptic feedback data 1322 is processed by a processor of the client device to generate haptic feedback effects at the controller device 1324 or other interface device (e.g., HMD, etc.) through which the haptic effects may be rendered. The controller device 1324 is an example of a handheld controller of a client device. One example of a haptic effect is a vibration or a rumble of the controller device 1324.

It will be appreciated that the video game is responsive to player input and thus performs a procedure similar to that described above for the transmission and processing of player input but in the opposite direction from the client device to the server. As shown, the controller device 1324 or another input component (e.g., body part of the user 1, etc.) or a combination thereof generates input data 1348. The input data 1348 is packetized at the client devices for transport over the computer network 1320 to a data center. The incoming data packets 1346 are disassembled and reassembled by the game server 1302 to define the incoming data 1348 on the data center side. The input data 1348 is fed to the game server 1302, which processes the input data 1348 to generate a game state for the conventional game N.

During transport of the audio packets 1316, video packets 1318, and haptic feedback packets 1324 via the computer network 1320, in some embodiments, the transmission of data via the computer network 1320 is monitored to ensure quality of service. For example, as indicated by reference numeral 1350, network conditions of the computer network 1320, including both upstream and downstream network bandwidth, are monitored and game streaming is adjusted in response to changes in available bandwidth. That is, encoding and decoding of network packets is controlled based on current network conditions, as indicated by reference numeral 1352.

FIG. 14 is a block diagram of an embodiment of a compatible game console 1400 for interfacing with a display device of a client device and capable of communicating with a game host system, such as server system 404 (FIG. 4A), via a computer network 1320 (FIG. 13). Game console 1400 is an example of game console 402 (fig. 4A). Game console 1400 is located within a data center or at a location where a player, such as user 1 or 2, is located. In some implementations, the game console 1400 is used to execute games displayed on the HMD. The game console 1400 is provided with various peripheral devices that can be connected to the game console 1400. Game console 1400 has a cell processor 1428 and dynamic random access memoryAn access memory (XDRAM) unit 1426, a real synthesizer graphics processor unit 1430 with a dedicated Video Random Access Memory (VRAM) unit 1432, and an input/output (I/O) bridge 1434. The game console 1400 also has Blu-rayA disk read-only memory (BD-ROM) optical disk reader 1440 for reading from disk 1440a and a removable Hard Disk Drive (HDD) 1436 that is accessible via I/O bridge 1434. Optionally, game console 1400 also includes a memory card reader 1438 for reading compact flash memory cards, memory +_ that can be similarly accessed through I/O bridge 1434 >Memory cards, etc. I/O bridge 1434 is also connected to USB2.0 port 1424, gigabit Ethernet port 1422, IEEE 802.11b/g wireless network (Wi-Fi ^TM ) Port 1420, and +.>Wireless link port 1418.

In operation, the I/O bridge 1434 handles all wireless, USB, and ethernet data, including data from the game controller and from the HMD 1405. For example, when a player is playing a legacy game N generated by executing a portion of a game code, such as game code GCN, the I/O bridge 1434 receives input data or input signals described herein from the game controller 1342 (fig. 13) or 1403 and/or from the HMD 1405 via a bluetooth link and directs the input data to the unit processor 1428, which updates the current state of the legacy game N accordingly. As an example, a camera within the HMD 1405 captures a player's pose to generate an image representing the pose. Game controller 1342 is an example of handheld controller 406 (fig. 4A).

In addition to game controllers 1342 and 1403 and HMD 1405, wireless, USB and ethernet ports provide connectivity for other peripheral devices, such as remote control 1404, keyboard 1406, mouse 1408, portable entertainment device 141 0 (such as Sony PlaystationEntertainment device, etc.), a camera (such as +.>Video camera 1412, etc.), microphone headset 1414, and microphone 1415. Portable entertainment device 1410 is an example of a game controller. In some implementations, such peripheral devices are wirelessly connected to the game console 1400, e.g., the portable entertainment device 1410 via Wi-Fi ^TM The ad hoc connection communicates and the microphone headset 1414 communicates via a bluetooth link.

The provision of these interfaces means that game console 1400 is also potentially compatible with other peripheral devices such as Digital Video Recorders (DVRs), set-top boxes, digital cameras, portable media players, voice over Internet Protocol (IP) telephones, mobile telephones, printers, and scanners.

In addition, a conventional memory card reader 1416 is connected to the game console 1400 via a USB port 1424 so that a memory card 1448 of a kind used by the game console 1400 can be read. The game controllers 1342 and 1403, and the HMD 1405 are operable to communicate wirelessly with the game console 1400 via the bluetooth link 1418, or connect to the USB port 1424, thereby also receiving power by which to charge the battery of the game controllers 1342 and 1403 and the HMD 1405. In some implementations, each of the game controllers 1342 and 1403 and HMD 1405 includes memory, a processor, a memory card reader, persistent memory such as flash memory, a light emitter such as a light-emitting spherical segment, a light-emitting diode (LED) or infrared light, a microphone and speaker for ultrasonic communications, a sound-proof box, a digital camera, an internal clock, a recognizable shape such as a spherical segment facing the game console 1400, and a wireless device using a protocol such as bluetooth, wi-Fi, or the like.

Game controller 642 is a controller designed to be used by both hands of a player such as player 1 or 2 or 3 or 4, and game controller 1403 isA one-hand controller with accessories. The HMD 1405 is designed to fit atop the player's head and/or in front of the eyes. In addition to one or more analog joysticks and conventional control buttons, each game controller 1342 and 1403 is susceptible to three-dimensional position determination. Similarly, the HMD 1405 is susceptible to three-dimensional position determination. Thus, in some implementations, gestures and movements of the player using the game controllers 1342 and 1403 and the HMD 1405 are translated as inputs to the game in addition to or instead of conventional buttons or joystick commands. Optionally, such as Playstation ^TM Other wireless-enabled peripheral devices such as portable devices are used as controllers. In the Playstation ^TM In the case of a portable device, additional game or control information, such as control instructions or number of lives, etc., is provided on the display screen of the device. In some embodiments, other alternative or complementary control devices are used, such as dance carpets (not shown), light guns (not shown), steering wheels and pedals (not shown), custom controllers, and the like. Examples of custom controllers include a single or several large buttons for a quick question and answer game (also not shown).

The remote control 1404 is also operable to communicate wirelessly with the game console 1400 via a bluetooth link 1418. Remote control 1404 includes a controller adapted to operate a Blu Ray ^TM Disc BD-ROM reader 1440 and is adapted to navigate the controls of the disc content.

Blu Ray ^TM The disk BD-ROM reader 1440 is operable to read CD-ROMs compatible with the game console 1400 in addition to conventional prerecorded and recordable CDs and so-called super audio CDs. Blu Ray ^TM The disk BD-ROM reader 1440 is also operative to read digital video disk-ROM (DVD-ROM) compatible with the game console 1400 in addition to conventional pre-recorded and recordable DVDs. Blu Ray ^TM The disc BD-ROM reader 1440 is further operable to read BD-ROMs compatible with the game console 1400, as well as conventional pre-recorded and recordable Blu-ray discs.

Game console 1400 is operable to supply audio and video generated or decoded via reality synthesizer graphics unit 1430 to a display with audio connector 1450 and video connector 1452Display and sound output devices 1442 such as a monitor or television or the like, or via one or more loudspeakers 1444 and 1446The wireless link port 1418 supplies audio and video to a display device of the HMD 1405. In various embodiments, audio connector 1450 includes conventional analog and digital outputs, while video connector 1452 includes component video, S-video, composite video, and one or more High Definition Multimedia Interface (HDMI) outputs differently. Thus, the video output may be in a format such as Phase Alternating Line (PAL) or National Television Systems Committee (NTSC), or at 2220p, 1080i or 1080p high definition. Audio processing such as generation, decoding, and the like is performed by the unit processor 1408. Operating system support of game console 1400 >5.1 surround sound->Cinema surround sound (DTS) and from +.>Decoding of 7.1 surround sound of a disc. The display and sound output device 1442 is an example of the display device 410 (fig. 4A).

In some embodiments, a camera, such as camera 1412, includes a single Charge Coupled Device (CCD), an LED indicator, and a hardware-based real-time data compression and encoding device, such that the compressed video data is transmitted in a suitable format, such as an intra-image based Moving Picture Experts Group (MPEG) standard, for decoding by game console 1400. The LED indicators of the camera 912 are arranged to illuminate in response to appropriate control data from the game console 1400, for example, to represent adverse lighting conditions, etc. Some embodiments of the video camera 1412 are connected to the game console 1400 via a USB, bluetooth, or Wi-Fi communication port. Various embodiments of the camera include one or more associated microphones and are also capable of transmitting audio data. In several embodiments of the camera, the CCD has a resolution suitable for high definition video capture. In use, the images captured by the camera are incorporated into the game or interpreted as game control inputs. In another embodiment, the video camera is an infrared camera adapted to detect infrared light.

In various embodiments, for successful data communication with a peripheral device (e.g., a video camera or remote control) via one of the communication ports of the game console 1400, a piece of appropriate software, such as a device driver, is provided.

In some embodiments, the aforementioned system devices including the game console 1400, the game controller 1342 (fig. 13) or 1403, and the HMD 1405 enable the HMD 1405 to display and capture video of an interactive session of a game. The system device initiates an interactive session of the game that defines the interactivity between player 1 and other players and the game. The system device further determines an initial position and orientation of the game controller 1342 (fig. 13) or 1303 and/or HMD 1405 operated by a player, such as player 1 or player 2 or player 3 or player 4. Game console 1400 determines the current state of the game based on the interactivity between the player and the game, such as player 1 or player 2 or player 3 or player 4. The system device tracks the position and orientation of the game controller 642 (fig. 6) or 1403 and/or HMD 1405 during the player's interactive session with the legacy game N. The system device generates a spectator video stream of the interactive session based on the current state of the legacy game N and the tracked position and orientation of the HHC and/or HMD 1405. In some implementations, the HHC renders the spectator video stream on a display screen of the HHC. In various implementations, the HMD 1405 renders the spectator video stream on a display screen of the HMD 1405.

Referring to fig. 15, a diagram depicting components of an HMD 1502 is shown. HMD 1502 is an example of HMD 1405 (fig. 14). HMD 1502 includes a processor 1500 for executing program instructions. A memory device 1502 is provided for storage purposes. Examples of memory device 1502 include volatile memory, nonvolatile memory, or a combination thereof. A display device 1504 is included that provides a visual interface for a player to view, such as a display of image frames generated from saved data or the like. A battery 1506 is provided as a power source for the HMD 1502. The motion detection module 1508 includes any of a variety of motion sensitive hardware (e.g., magnetometers 1510, accelerometers 1512, and gyroscopes 1514).

Accelerometers are devices used to measure acceleration and gravity-induced reaction forces. The magnitude and direction of acceleration in different directions can be detected using a single axis model and a multi-axis model. Accelerometers are used to sense inclination, vibration and shock. In one embodiment, three accelerometers 1512 are used to provide the direction of gravity, which gives absolute reference to two angles, such as world space pitch and world space roll.

The magnetometer measures the strength and direction of the magnetic field near the HMD 1502. In some implementations, three magnetometers 1510 are used within the HMD 1502, ensuring an absolute reference to the world space yaw angle. In various embodiments, magnetometers are designed to span the earth's magnetic field, which is ±80 microtesla. Magnetometers are affected by metal and provide yaw measurements that are monotonic with actual yaw. In some embodiments, the magnetic field is distorted due to metal in the real world environment, which results in distortion of the yaw measurement. In various implementations, information from other sensors, such as gyroscope 1514, camera 1516, etc., is used to calibrate this distortion. In one implementation, the accelerometer 1512 is used with the magnetometer 1510 to obtain the tilt and azimuth of the HMD 1502.

Gyroscopes are devices used to measure or maintain orientation based on the principle of angular momentum. In one embodiment, instead of gyroscopes 1514, three gyroscopes provide information about movement across the respective axes (x, y, and z) based on inertial sensing. The gyroscope helps to detect rapid rotation. However, in some implementations, the gyroscope drifts over time without an absolute reference. This triggers periodic resetting of the gyroscope, which may be done based on visual tracking of the object, accelerometers, magnetometers, etc. using other available information such as position/orientation determination.

A camera 1516 is provided to capture images and image streams of real world environments (e.g., rooms, compartments, natural environments, etc.) surrounding the player. In various implementations, more than one camera is included in the HMD 1502, including: a rear facing camera facing away from the player when the player views a display or the like of the HMD 1502; and a forward facing camera, for example, pointing at the player while viewing a display of the HMD 1502, etc. Additionally, in several implementations, a depth camera 1518 is included in the HMD 1502 to sense depth information of objects in the real-world environment.

HMD 1502 includes speakers 1520 for providing audio output. Also, in some embodiments, a microphone 1522 is included to capture audio from a real world environment, including sound from the surrounding environment, and speech made by a player, and the like. The HMD 1502 includes a haptic feedback module 1524, e.g., a vibration device or the like, to provide haptic feedback to a player. In one implementation, the haptic feedback module 1524 can cause movement and/or vibration of the HMD 1502 to provide haptic feedback to a player.

The LED 1526 is provided as a visual indicator of the status of the HMD 1502. For example, the LED may indicate battery charge, power on, etc. A card reader 1528 is provided to enable the HMD 1502 to read information from and write information to a memory card. The USB interface 1530 is included as one example of an interface for enabling connection of a peripheral device or connection to other devices (such as other portable devices, computers, etc.). In various implementations of the HMD 1502, any of a variety of interfaces may be included to enable greater connectivity of the HMD 1502.

Including Wi-Fi ^TM Module 1532 to enable connection to the internet via wireless networking technology. Also, the HMD 1502 includes Bluetooth ^TM Module 1534 to enable wireless connection to other devices. In some embodiments, a communication link 1536 is also included for connection to other devices. In one embodiment, communication link 1536 utilizes infrared transmissions for wireless communication. In other implementations, the communication link 1536 utilizes any one of a variety of wireless or wired transmission protocols to communicate with other devices.

Input buttons/sensors 1538 are included to provide an input interface for the player. Including any of a variety of types of input interfaces such as buttons, touch pads, joysticks, trackballs, and the like. In various implementations, an ultrasonic communication module 1540 is included in the HMD 1502 for facilitating communication with other devices via ultrasonic technology.

A biometric sensor 1542 is included to enable detection of physiological data from the player. In one embodiment, the biosensor 1542 includes one or more dry electrodes for detecting the bioelectrical signals of the player through the player's skin.

The foregoing components of the HMD 1502 have been described as merely exemplary components that may be included in the HMD 1502. In various embodiments, HMD 1502 includes or does not include some of the various aforementioned components.

Fig. 16 illustrates an implementation of an information service provider (INSP) architecture. The INSP 1602 delivers numerous information services to players that are geographically dispersed and connected via a computer network 1606 (e.g., LAN, WAN, or a combination thereof, etc.). Computer network 1606 is an example of computer network 1320 (FIG. 13). Examples of WANs include the internet, and examples of LANs include intranets. User 1 operates client device 1620-1, user 2 operates another client device 1620-2, and user 3 operates yet another client device 1620-3.

In some implementations, each client device 1620-1, 1620-2, and 1620-3 includes a Central Processing Unit (CPU), a display, and an input/output (I/O) interface. Examples of each client device 1620-1, 1620-2 and 1620-3 include Personal Computers (PCs), mobile phones, netbooks, tablet computers, gaming systems, personal Digital Assistants (PDAs), game consoles 1400 and display devices, HMDs 1502 (fig. 15), game consoles 1400 and HMDs 1502, desktop computers, laptop computers and smart televisions, and the like. In some implementations, the INSP 1602 recognizes the type of client device and adjusts the communication method employed.

In some embodiments, the INSP 1602 delivers one type of service, such as stock price updates, or may deliver multiple services, such as broadcast media, news, sports, games, and the like. In addition, the services provided by each INSP are dynamic, i.e., services may be added or removed at any point in time. Thus, an INSP that provides a particular type of service to a particular person may change over time. For example, client device 1620-1 is served by an INSP in the vicinity of client device 1620-1 when client device 1620-1 is at the home of user 1, and client device 1620-1 is served by a different INSP when user 1 goes to a different city. The hometown's INSP will pass the requested information and data to the new INSP so that the information "follows" the client device 1620-1 to the new city, thereby bringing the data closer to the client device 1620-1 and easier to access. In various implementations, a master-server relationship is established between a master INSP that manages information for client device 1620-1 and a server INSP that interfaces directly with client device 1620-1 under control of the master INSP. In some embodiments, data is transferred from one ISP to another as client device 1620-1 moves around the world, such that the INSP at the better location that serves client device 1620-1 is the INSP that delivers these services.

INSP 1602 includes an Application Service Provider (ASP) 1608 that provides computer-based services to clients via a computer network 1606. The software provided using the ASP model is sometimes also referred to as on-demand software or software as a service (SaaS). A simple form of providing access to computer-based services (e.g., customer relationship management, etc.) is through the use of standard protocols such as the hypertext transfer protocol (HTTP), etc. The application software resides on the vendor's server and is accessed by each client device 1620-1, 1620-2 and 1620-3 through a web browser using hypertext markup language (HTML) or the like through vendor-provided dedicated client software and/or other remote interfaces such as thin clients or the like.

Services delivered over a wide geographic area often use cloud computing. Cloud computing is a computing manner in which dynamically scalable and often virtualized resources are provided as a service via a computer network 1606. Users 1 through 3 need not be experts in supporting the technical infrastructure aspects in their "cloud". In some embodiments, cloud computing is divided into different services, such as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). Cloud computing services often provide common business applications accessed from web browsers online, while software and data are stored on servers. Based on how computer network 1606 is depicted in a computer network diagram, the term cloud is used as a metaphor for computer network 1606, e.g., using servers, storage, logic, and the like, and is an abstraction of its hidden complex infrastructure.

In addition, INSP 1602 includes a Game Processing Provider (GPP) 1610, also sometimes referred to herein as a game processing server, which is used by client devices 1620-1, 1620-2 and 1620-3 to play single and multiplayer video games. Most video games played on computer network 1606 operate via a connection to a game server. Typically, games use dedicated server applications that collect data from client devices 1620-1, 1620-2, and 1620-3 and distribute the data to other clients operated by other users. This is more efficient and effective than a peer-to-peer arrangement, but uses a separate server to host the server application. In some implementations, the GPP 1610 establishes communication between client devices 1620-1, 1620-2, and 1620-3 that exchange information without further reliance on the centralized GPP 1610.

A dedicated GPS is a server that operates independently of the client. Such servers typically run on dedicated hardware located in a data center, providing more bandwidth and dedicated processing power. Dedicated servers are a method of manipulating game servers for most PC-based multiplayer games. A large number of multiplayer online games run on dedicated servers, typically hosted by software companies that own the game names, allowing them to control and update content.

A Broadcast Processing Server (BPS) 1612, sometimes referred to herein as a broadcast processing provider, distributes audio or video signals to the audience. Broadcast to a small range of viewers is sometimes referred to as narrowcasting. The last leg of the broadcast distribution is how the signals arrive at the client devices 1620-1, 1620-2 and 1620-3 and, in some embodiments, the signals are distributed wirelessly to antennas and receivers as radio or television stations or by cable television or cable broadcast via the stations. In various embodiments, the computer network 1606 also brings radio or television signals to the client devices 1620-1, 1620-2 and 1620-3, particularly by allowing multicasting of shared signals and bandwidth. Historically, in several implementations, the broadcast is defined by a geographic area, such as a national broadcast, a local broadcast, or the like. However, with the popularity of high-speed internet, broadcasting is not limited by geographic location, since content can reach almost any country in the world.

A Storage Service Provider (SSP) 1614 provides computer storage and associated management services. SSP 1614 also provides periodic backup and archiving. By providing storage as a service, client devices 1620-1, 1620-2, and 1620-3 use more storage than when storage is not used as a service. Another major advantage is that SSP 1614 includes a backup service and client devices 1620-1, 1620-2, and 1620-3 will not lose data if their hard disk drives fail. Further, in some embodiments, multiple SSPs have full or partial copies of data received from client devices 1620-1, 1620-2 and 1620-3, allowing client devices 1620-1, 1620-2 and 1620-3 to access data in an efficient manner independent of the location or type of client where client devices 1620-1, 1620-2 and 1620-3 are located. For example, when a player is moving, the player accesses personal files via a home computer and via a mobile phone.

The communication provider 1616 provides connectivity to the client devices 1620-1, 1620-2 and 1620-3. A communication provider 1616 is an Internet Service Provider (ISP) that provides access to computer network 1606. The ISP connects client devices 1620-1, 1620-2 and 1620-3 using appropriate data transmission technologies for delivering internet protocol datagrams, such as dial-up, digital Subscriber Line (DSL), cable modem, fiber optic, wireless or dedicated high speed interconnect. In some embodiments, the communication provider 1616 also provides messaging services such as email, instant messaging, and Short Message Service (SMS) text. Another type of communication provider is a Network Service Provider (NSP) that sells bandwidth or network access by providing direct backbone access to a computer network 1606. Examples of network service providers include telecommunications companies, data carriers, wireless communication providers, internet service providers, cable television operators providing high-speed internet access, and the like.

Data exchange 1618 interconnects several modules within INSP 602 and connects these modules to client devices 1620-1, 1620-2 and 1620-3 via computer network 1606. In various embodiments, data exchange 1618 covers a smaller area in which all modules of INSP 1602 are in close proximity, or a larger geographic area when different modules are geographically dispersed. For example, data exchange 1602 includes a fast gigabit ethernet within a cabinet of a data center, or an intercontinental virtual LAN.

In some implementations, wireless technology may be used to facilitate communication between the server system 404 (FIG. 4A) and the client devices 1620-1 through 1620-3. Such techniques may include, for example, 5G wireless communication techniques.

In one embodiment, a video game, such as the conventional game N described herein, is executed locally on a gaming machine, personal computer, or on a server. In some cases, the video game is executed by one or more servers of the data center. When executing a video game, some examples of the video game may be a simulation of the video game. For example, the video game may be executed by an environment or server that generates a simulation of the video game. In some implementations, the simulation is an example of a video game. In other implementations, the simulation may be generated by a simulator. In either case, if the video game is represented as a simulation, the simulation can be performed to render interactive content that can be interactively streamed, executed, and/or controlled by the user input.

It should be noted that in various embodiments, one or more features of some embodiments described herein are combined with one or more features of one or more of the remaining embodiments described herein.

Embodiments described in this disclosure may be practiced with a variety of computer system configurations, including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. In one implementation, the embodiments described in this disclosure may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.

With the above embodiments in mind, it should be understood that the embodiments described in this disclosure employ various computer-implemented operations involving data stored in computer systems in one implementation. The operations are those requiring physical manipulations of physical quantities. Any of the operations described herein that form part of the embodiments described in this disclosure are useful machine operations. Some embodiments in this disclosure also relate to an apparatus or device for performing these operations. The apparatus is specially constructed for the required purposes, or it is a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, in one embodiment, it may be more convenient for various general-purpose machines to be used with computer programs written in accordance with the teachings herein, or to construct a more specialized apparatus to perform the required operations.

In one implementation, some embodiments described in this disclosure are embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that stores data which can thereafter be read by a computer system. Examples of computer readable media include hard disk drives, network Attached Storage (NAS), ROM, RAM, CD-ROM, CD-recordable (CD-R), CD-rewritable (CD-RW), magnetic tapes, optical data storage devices, non-optical data storage devices, and the like. By way of example, computer readable media comprises computer readable tangible media distributed over a network coupled computer system such that the computer readable code is stored and executed in a distributed fashion.

Further, although some of the above embodiments are described with respect to gaming environments, in some embodiments, other environments, such as video conferencing environments and the like, are used instead of games.

While the method operations are described in a particular order, it should be understood that other housekeeping operations may be performed between operations, or operations may be adjusted such that they occur at slightly different times, or may be distributed throughout the system, which allows processing operations to occur at various intervals associated with the processing, so long as the processing performs the overlay operation in a desired manner.

Although the foregoing embodiments described in this disclosure have been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the embodiments are not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (20)

1. A method for facilitating playing a legacy game, the method comprising:

receiving user input during said playing of said legacy game;

determining whether one or more code blocks for servicing the user input are cached;

accessing one or more instructions of legacy game code upon determining that the one or more code blocks are not cached;

compiling the one or more code blocks of the one or more instructions from the legacy game code;

caching the one or more code blocks; and

the one or more code blocks are executed to display a virtual environment.

2. The method of claim 1, wherein the compiling is performed within a game console.

3. The method of claim 1, wherein the compiling is performed within a server system.

4. The method of claim 1, wherein each of the one or more code blocks includes a source register address, an operation, and a destination register address, wherein when executing the each of the one or more code blocks, accessing data for displaying the virtual environment from the source register address, performing the operation on the data accessed from the source register address to generate a result, and storing the result at the destination register address.

5. The method of claim 1, further comprising parsing the legacy game code to identify the one or more instructions of the legacy game code.

6. The method of claim 1, the method further comprising:

determining that instructions of the legacy game code are compiled;

the legacy game code is deleted in response to determining that the instructions of the legacy game code are compiled.

7. The method of claim 1, the method further comprising:

determining whether the legacy game code is accessed within a predetermined period of time from a latest time when the legacy machine accessed the legacy game code;

deleting the legacy game code in response to determining that the legacy game code was not accessed within the predetermined period of time from the latest time the legacy machine accessed the legacy game code.

8. The method of claim 1, the method further comprising:

generating a first validation result from the one or more instructions when the one or more code blocks are compiled;

checking one or more memory addresses associated with the one or more instructions to determine whether the one or more code blocks are marked as invalid;

determining whether the one or more code blocks are to be executed;

determining, upon determining that the one or more code blocks are to be executed, whether the one or more code blocks are marked as invalid;

upon determining that the one or more code blocks are marked as invalid, checking the one or more memory addresses to generate a second validation result from the one or more instructions stored at the one or more memory addresses;

comparing the first verification result with the second verification result to determine whether the one or more code blocks are invalid;

upon determining that the one or more code blocks are invalid, recompiling one or more additional code blocks associated with the one or more instructions;

the one or more additional code blocks are executed to display an additional virtual environment.

9. The method of claim 1, wherein the legacy game code cannot be executed in a first game console comprising a 64-bit processor, but can be executed in a second game console comprising a 32-bit processor.

10. The method of claim 9, wherein the one or more blocks are executable in the first game console.

11. A computing device for facilitating playing a legacy game, the computing device comprising:

a processor configured to receive user input during said playing of said legacy game; and

a cache, the cache coupled to the processor; and

a memory device coupled to the processor,

wherein the processor is configured to determine whether one or more code blocks for servicing the user input are stored in the cache,

wherein the processor is configured to access one or more instructions of legacy game code from the memory device upon determining that the one or more code blocks are not stored in the cache,

wherein the processor is configured to compile the one or more code blocks of the one or more instructions from the legacy game code,

Wherein the processor is configured to store the one or more code blocks in the cache, and

wherein the processor is configured to execute the one or more code blocks to display a virtual environment.

12. The computing device of claim 11, wherein each of the one or more code blocks comprises a source register address, an operation, and a destination register address, wherein when the each of the one or more code blocks is executed, data for displaying the virtual environment is accessed from the source register address, the operation is performed on the data accessed from the source register address to generate a result, and the result is stored at the destination register address.

13. The computing device of claim 11, wherein the processor is configured to parse the legacy game code to identify the one or more instructions of the legacy game code.

14. The computing device of claim 11, wherein the processor is configured to:

generating a first validation result from the one or more instructions when the one or more code blocks are compiled;

Checking one or more memory addresses associated with the one or more instructions to determine whether the one or more code blocks are marked as invalid;

determining whether the one or more code blocks are to be executed;

determining, upon determining that the one or more code blocks are to be executed, whether the one or more code blocks are marked as invalid;

checking the one or more memory addresses to generate a second validation result from the one or more instructions;

comparing the first verification result with the second verification result to determine whether the one or more code blocks are invalid;

upon determining that the one or more code blocks are invalid, recompiling one or more additional code blocks associated with the one or more instructions;

the one or more additional code blocks are executed to display an additional virtual environment.

15. The computing device of claim 11, wherein the processor is a 64-bit processor, wherein the legacy game code is not executable by the processor, but is executable in a computing device comprising a 32-bit processor.

16. A method, the method comprising:

generating a first validation result from one or more instructions of a legacy game code, wherein the one or more instructions of the legacy game code are associated with one or more code blocks;

Checking one or more memory addresses associated with the one or more instructions to determine whether the one or more code blocks are marked as invalid;

determining whether the one or more code blocks are to be executed;

determining, upon determining that the one or more code blocks are to be executed, whether the one or more code blocks are marked as invalid;

checking the one or more memory addresses to generate a second validation result from the one or more instructions;

comparing the first verification result with the second verification result to determine whether the one or more code blocks are invalid; and

upon determining that the one or more code blocks are invalid, recompiling one or more additional code blocks associated with the one or more instructions; and

the one or more additional code blocks are executed to display the virtual environment.

17. The method of claim 16, wherein each of the one or more additional code blocks includes a source register address, an operation, and a destination register address, wherein when the each of the one or more additional code blocks is executed, data for displaying the virtual environment is accessed from the source register address, the operation is performed on the data accessed from the source register address to generate a result, and the result is stored at the destination register address.

18. The method of claim 16, wherein the legacy game code cannot be executed in a first game console comprising a 64-bit processor, but can be executed in a second game console comprising a 32-bit processor.

19. The method of claim 18, wherein the one or more code blocks are executable in the first game console.

20. The method of claim 16, further comprising storing the first verification result in one or more memory registers having the one or more code blocks.