System and method for converting legacy code to updated code

Abstract

A method for facilitating playing a legacy game is described. The method includes receiving user input during the playing 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 legacy game code upon determining that the one or more code blocks are not cached. The method also includes compiling the one or more code blocks from the one or more instructions of the legacy game code, caching the one or more code blocks, and executing the one or more code blocks to display a virtual environment.

Description

Technical Field

[0001] This disclosure relates to systems and methods for converting legacy code into updated code. Background Technology

[0002] As video games and network technology have become more advanced, the complexity of games has increased accordingly. Therefore, there may be more complex storylines, game objectives, missions and tasks, abilities associated with the game avatar, and ratings. Ratings can occur in various ways and be weighted, and can also be determined according to various categories or on an individual or team basis.

[0003] The importance of the aforementioned issues only increases with the complexity of video games. Therefore, some players may prefer to play older games that are less complex.

[0004] The embodiments of the present invention have emerged in this context. Summary of the Invention

[0005] The embodiments disclosed herein provide systems and methods for converting legacy code into updated code.

[0006] In one embodiment, a method for facilitating the playing of a traditional game is described. The method includes: receiving user input during the playing of the traditional game; determining whether one or more blocks of code serving the user input are cached; and accessing one or more instructions for the traditional game code when it is determined that the one or more blocks of code are not cached. The method further includes: compiling the one or more blocks of code from the one or more instructions of the traditional game code; caching the one or more blocks of code; and executing the one or more blocks of code to display a virtual environment.

[0007] In one embodiment, a computing device for facilitating the playing of a traditional game is described. The computing device includes a processor configured to receive user input during the playing of the traditional 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 blocks of code for serving the user input are stored in the cache. When the processor determines that the one or more blocks of code are not stored in the cache, it accesses one or more instructions of traditional game code from the memory device. Furthermore, the processor compiles the one or more blocks of code from the one or more instructions of the traditional game code. The processor stores the one or more blocks of code in the cache and executes the one or more blocks of code to display a virtual environment.

[0008] In one embodiment, a method is described. The method includes generating a first verification result from one or more instructions of conventional game code. The one or more instructions of the conventional game code are associated with one or more code blocks. The method further 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 includes: determining whether the one or more code blocks will be executed; and when it is determined that the one or more code blocks will be executed, determining whether the one or more code blocks are marked as invalid. The method includes: checking the one or more memory addresses to generate a second verification 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 when it is determined that the one or more code blocks are invalid, recompiling one or more additional code blocks associated with the one or more instructions. The method includes executing the one or more additional code blocks to display a virtual environment.

[0009] Some advantages of the systems and methods described in this paper for converting legacy code to updated code include allowing the functionality of the legacy code to be executed by the updated machine. Without conversion, the updated machine cannot execute the functionality of the legacy code due to security concerns. For example, it may lack the permission to execute legacy code from the updated machine and write data generated during the execution of the legacy code into registers in the updated machine. Therefore, by providing conversion, the updated machine facilitates the execution of the functionality of the legacy code.

[0010] Other advantages of the systems and methods described in this paper include reduced execution time. As an example, two or more instructions (such as routines and subroutines, or two similar instructions) of traditional code are combined into a basic block of updated code. Therefore, the updated code executes much faster than the traditional code.

[0011] Additional advantages of the systems and methods described in this paper for converting legacy code into updated code include: recompiling one or more additional basic blocks of the updated code when one or more basic blocks of the updated code are determined to be 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 invalid, one or more additional basic blocks are compiled and executed instead of the one or more basic blocks themselves. These one or more additional basic blocks correspond to the same game as the one or more basic blocks.

[0012] Other advantages of the systems and methods described in this paper for transforming legacy code into updated code include: It eliminates the need 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 compilation. This reduces latency in displaying the virtual environment from one or more basic blocks. Furthermore, no processing power is required to check the invalidity of all basic blocks.

[0013] Furthermore, the advantages of the systems and methods described in this paper for converting legacy code into updated code include: saving processing time and resources when updated code for the game has already been compiled. Once the updated code is generated at the server or game console, it does not need to be recompiled. Instead, the updated code can be transferred from the server or game console to another game console. Therefore, the processing time and resources required to regenerate the updated code at another game console are saved.

[0014] Other aspects of this disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate the principles of the embodiments described in this disclosure. Attached Figure Description

[0015] Various embodiments of this disclosure are best understood by referring to the following description taken in conjunction with the accompanying drawings, wherein:

[0016] Figure 1 This is a block diagram illustrating the implementation scheme of a system for generating basic blocks of update code.

[0017] Figure 2 This is a flowchart illustrating the implementation scheme of the method used to compile and execute the basic blocks of game code.

[0018] Figure 3 It is a block diagram used to illustrate the implementation scheme of a system for compiling and executing basic blocks.

[0019] Figure 4A This is a diagram illustrating the implementation scheme of a system for compiling basic blocks within a game console.

[0020] Figure 4B This is a diagram illustrating the implementation scheme of a system that compiles basic blocks within a server system.

[0021] Figure 5A This is a diagram used to illustrate the implementation scheme of the basic blocks.

[0022] Figure 5B This is a diagram illustrating the implementation scheme of the compilation operations performed by the basic block compiler.

[0023] Figure 6AThis is a diagram illustrating the implementation scheme of the components of a simulation processor system.

[0024] Figure 6B This is a flowchart illustrating the implementation scheme of the method used to compile and execute basic blocks.

[0025] Figure 6C This is a diagram illustrating the implementation scheme of a system that dynamically compiles different basic blocks in response to different user inputs.

[0026] Figure 7A This is a diagram illustrating an implementation scheme for a system that removes emulation processing unit (PU) code from a memory device.

[0027] Figure 7B This is a flowchart illustrating an implementation scheme for a method of deleting emulated PU code from a memory device.

[0028] Figure 8A This is a diagram illustrating the implementation scheme of a simulation processor system for verifying basic blocks.

[0029] Figure 8B It is used to explain the reason Figure 8A A flowchart of an implementation scheme for a method to perform verification operations on a simulation processor system.

[0030] Figure 8C yes Figure 8B The following part of the flowchart of the method.

[0031] Figure 9A This is a diagram used to illustrate the implementation scheme of a conventional machine.

[0032] Figure 9B This is a diagram used to illustrate the implementation scheme of the updated machine.

[0033] Figure 10A This is a diagram illustrating the implementation scheme of a system that combines multiple basic blocks into a single basic block using a basic block compiler.

[0034] Figure 10B It is a diagram used to illustrate the implementation scheme of a system that modifies one or more of the basic blocks.

[0035] Figure 10C This is a diagram illustrating an implementation scheme of a system that combines basic blocks created based on subroutines with basic blocks generated based on simulated PU code instructions that call the subroutines.

[0036] Figure 10D This is a diagram illustrating an implementation scheme for a system that inserts a basic block between two basic blocks.

[0037] Figure 10EThis is a diagram illustrating the implementation scheme of a system that switches according to the execution order of basic blocks.

[0038] Figure 11A This is a flowchart illustrating an implementation scheme for using a loop count stored in a basic block n.

[0039] Figure 11B yes Figure 11A The following part of the flowchart of the method.

[0040] Figure 12 This is a diagram illustrating an implementation scheme for a system that transfers basic blocks from a first client device to a second client device.

[0041] Figure 13 This is a flowchart conceptually illustrating the various operations performed according to an implementation of this disclosure for streaming cloud video games to a client device.

[0042] Figure 14 It is a block diagram of an implementation scheme for a compatible game console that interfaces with a display device of a client device and is capable of communicating with a game console system via a computer network.

[0043] Figure 15 This diagram illustrates the components of a head-mounted display (HMD).

[0044] Figure 16 Describe the implementation plan for the Information Service Provider (INSP) architecture. Detailed Implementation

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

[0046] Figure 1This is a block diagram illustrating an implementation of a system 100 for generating basic blocks 1 to n of update code, where n is a positive integer. System 100 includes a cache 102, a basic block compiler 104, and simulation processing unit (PU) code 106 for a conventional game N with 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 served more quickly. 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. Serving a cache hit by reading data from the cache is faster than recalculating the result or reading from a slower data storage device, such as a memory device; therefore, the more requests that can be served from the cache, the faster the system performs. For illustration, a cache is a set of registers, and accessing the cache can be, for example, 10 to 100 times faster than main memory devices.

[0047] As an example, the cache has fewer memory addresses than the main memory device. In this example, the processor first determines whether the 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.

[0048] As an example, the basic block compiler used in this article is a computer program that converts emulated PU code 106 code into game code GCN, an example of updated code. Game code GCN represents the functionality of a traditional game N. The computer program is executed by one or more processors of an emulated processor system. Game code GCN is sometimes referred to as intermediate code in this article. As an example, intermediate code is neither source code nor machine code. For illustration, 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 this illustration, intermediate code includes basic blocks that can be executed by the CPU or GPU of an updated machine, examples of which include Sony PlayStation. TM 4 (PS4) TM ) or Sony PlayStation TM 5 (PS5) TM This could be a desktop computer, laptop computer, smartphone, or smart TV. As an example, the source code is written in a human-readable programming language, which can be plain text. As an example, a basic block compiler, as used herein, is implemented using hardware or software, or a combination thereof. For illustration, the functionality of a basic block compiler is implemented using a controller or programmable logic device (PLD) or application-specific integrated circuit (ASIC).

[0049] As used herein, examples of controllers include processors and memory devices. The processor is coupled to the memory device. As used herein, by example, the processor is 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 illustration, the memory device is a flash memory device, or hard disk, or solid-state storage device, or redundant array of disks (RAID), or a combination thereof.

[0050] An example of emulated PU code 106 is machine code that instructs a processor (such as a CPU or GPU) of a conventional machine to perform operations. For example, emulated PU code 106 includes a sequence of instructions instructing the CPU of a conventional machine to perform specific operations, such as loading, storing, transferring, or performing arithmetic logic unit (ALU) operations on data stored in the CPU's registers. As another example, emulated PU code 106 is binary code consisting of a series of ones and zeros. As yet another example, emulated PU code 106 includes a sequence of instructions instructing the GPU of a conventional machine to perform specific operations, such as loading, storing, transferring, or performing ALU operations on data stored in the GPU's registers. The GPU of a conventional machine performs operations on virtual objects to assign graphics parameters, such as color, intensity, shadow, texture, or combinations thereof, to the virtual objects.

[0051] Emulation PU code 106 is specific or unique to the architecture of the CPU or GPU of a legacy machine. For example, emulation PU code 106 cannot be executed by the CPU or GPU of a newer machine. As another example, it is possible to execute PU code 106 on a Sony PlayStation... TM The emulation PU 106 running on PS1 cannot be used on Sony PlayStation. TM Execute on 2 (PS2), and vice versa.

[0052] As an example, emulated PU code 106 is executed by the processor of a conventional machine to perform operations in a conventional game N. To illustrate, emulated PU code 106 is executed in a machine such as a PS1... TM or PS2 TM Playing traditional games on traditional machines. Examples of traditional games include Warhawk. TM Tango Dance Fever TM Castlevania Chronicles TM Pacman TM Resident Evil 2 TM and Streetfighter Alpha 3 TMThe video game.

[0053] The basic block compiler 104 accesses the emulation PU code 106 for the traditional game N and transforms the emulation PU code 106 into one or more basic blocks, such as basic blocks 1 to 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 to n in a cache 102. When basic blocks 1 to n are executed, the traditional game N is emulated.

[0054] Figure 2 This is a flowchart illustrating an implementation of a method 200 for compiling and dispatching basic blocks of game code GCN. Method 200 is executed by one or more processors of an updated machine. Method 200 includes operation 202: determining whether a cache hit exists, for example, whether a basic block is stored in cache 102. For example, operation 202 is executed or triggered when user input is received during the playing of a traditional game. To illustrate, user input is received to change the position or orientation of virtual objects in a traditional game N, or a combination thereof. In this illustration, after determining that user input has been received, it is determined whether a basic block (such as one of basic blocks 1 to n) is stored in cache 102. Figure 1 In the description, basic blocks will be executed to change the position or orientation of virtual objects or combinations thereof.

[0055] As another illustration, operation 202 is executed when user input is received that alters parameters (such as appearance and feel) of a virtual object in a traditional game. In this illustration, after determining that user input has been received, it is determined whether a basic block (such as one of basic blocks 1 to n) is stored in cache 102. In this illustration, the basic block is executed to change the parameters of the virtual object.

[0056] In response to determining that a basic block is cached, in operation 204 of method 200, the basic block is dispatched. For example, in operation 204, the basic block is executed or run. To illustrate, the basic block is run by the CPU of the updated machine to move a virtual object from one location to another, or from one orientation to another, 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 pixels of the virtual object, triangular portions of the virtual object, or portions of a predefined shape of the virtual object. To illustrate, the virtual object is divided into a predetermined number of pixels, and a parameter value is assigned to each pixel.

[0057] In response to determining that the basic block is not cached, operation 206 of compiling the basic block is performed in method 200. This is done through the basic block compiler 104. Figure 1) Execute operation 206. For example, the basic block compiler 104 parses the simulation PU code 106 of the traditional game N ( Figure 1 The basic block compiler 104 identifies emulated PU code instructions that include functions for serving received user input before operation 202, during the playing of a conventional game. User input received before operation 202 triggers operation 202. For illustration, the basic block compiler 104 iterates through each emulated PU code instruction of the emulated PU code 106 to determine whether the emulated PU code instruction includes an operation, such as a function, for satisfying (e.g., generating a response) user input received during the playing of a conventional game. In this illustration, once a function is identified, the basic block compiler 104 translates the emulated PU code instructions to generate a basic block. In this illustration, other emulated PU code instructions in the conventional game that do not need to serve user input are not compiled into basic blocks by the basic block compiler 104 in response to user input received before operation 202.

[0058] In operation 208 of method 200, the basic block generated in operation 206 is stored in cache 102 by the basic block compiler 104. Then, the cached basic block is executed in operation 204 to serve the user input received before operation 202.

[0059] In one implementation, method 200 is executed via one or more processors of a server system. As an example, the server system includes an upgraded machine as a server. For illustration, each server blade is a PS4. TM Or PS5 TM .

[0060] In one implementation, method 200 is not executed until user input is received. For example, the basic block (such as one of basic blocks 1 to n) is not compiled and executed until user input is received, after which it is determined whether the basic block is stored in cache 102.

[0061] In one implementation, the basic block compiler 104 compiles one or more of basic blocks 1 to n in response to a first user input during the playing of the traditional game N, and compiles one or more of the remaining basic blocks 1 to n in response to a second user input during the playing of the traditional game N. For illustration, the basic block compiler 104 generates basic blocks 1 and 2 to serve the first user input, and generates basic blocks 3 to 7 to serve the second user input. The second user input is received after the first user input.

[0062] Figure 3This is a block diagram illustrating an implementation of a system 304 for compiling and dispatching basic blocks such as basic blocks 1 to n. System 300 includes a basic block compiler 104, a cache 102, and a block dispatcher 302. As an example, the block dispatcher 302 is hardware or software, or a combination thereof, that performs the operations of one or more of the basic blocks 1 to n to serve user input. For illustration, the block dispatcher 302 is a PLD, an ASIC, or a controller. As another illustration, the block dispatcher 302 is computer software. As an example, the block dispatcher 302 is a GPU or CPU of a modern machine.

[0063] Basic block compiler 104 for simulation PU code 106 ( Figure 1 A portion of the CPU code (such as opcodes) is decoded and translated into an intermediate representation for the processing unit of the updated machine. For example, a basic block compiler 104 parses a portion of the CPU code of an emulated PU code 106, such as one or more instructions, to determine whether the portion of the CPU code includes functionality serving user input. Upon determination that it does, the basic block compiler 104 translates the portion of the CPU code into one or more basic blocks, such as basic blocks 1 to n. As another example, a basic block compiler 104 parses a portion of the GPU code of an emulated PU code 106, such as one or more instructions, to determine whether the portion of the GPU code includes functionality serving user input. Upon determination that it does, the basic block compiler 104 translates the portion of the GPU code into one or more basic blocks, such as basic blocks 1 to n.

[0064] Furthermore, the basic block compiler 104 estimates the number of execution loops for each basic block generated from the aforementioned portion of the simulation PU code 106 to generate an estimated count. For example, the basic block compiler 104 determines that basic block 1 includes a jump operation and that the jump operation will take a predetermined amount of time. The basic block compiler 104 estimates that the jump operation of basic block 1 will take the predetermined amount of time. The block compiler 104 stores the estimated count in cache 102. For example, the block compiler 104 stores the estimated count in basic block n for which it estimates the number of loops.

[0065] Once the basic blocks are compiled, they are stored in cache 102 for fast lookup. For example, if another user input is received after a user input that compiles a basic block in response to it, and the same basic block can be used to serve the other user input, the basic block can be quickly accessed from cache 102 without needing to be regenerated.

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

[0067] Each of the one or more additional basic blocks has the same structure as one or more basic blocks 1 through 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 the number of execution loops for the operation of the additional basic block. In the example above, some of the one or more additional basic blocks include an invalidation 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 the number of execution loops for the operation of the additional basic block. It should be noted that each of the additional code blocks is executed in the same manner as each of the basic blocks 1 through n.

[0068] Block dispatcher 302 executes or runs one or more of basic blocks 1 to n based on user input. For example, block dispatcher 302 executes basic blocks 1 and 2 to serve a first user input, and executes basic blocks 3 to 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, which counts the number of loops used to execute one or more of basic blocks 1 to n based on user input to generate an actual count. Block dispatcher 302 sends the actual count to block compiler 104 to update the estimated count using the actual count. For example, the actual count is stored in basic block n for which the actual count is calculated. For illustration, the actual count is stored in one or more memory registers of cache 102 assigned to basic block n.

[0069] In one implementation, the basic block compiler 104 does not estimate the number of execution loops for any basic block. In this implementation, there is no substitution of the estimated count with the actual count. Instead, in this implementation, the actual count is stored by the block compiler 104 in the basic block n for which the actual count is determined.

[0070] Figure 4AThis diagram illustrates an implementation scheme of a system 400 that compiles basic blocks 1 to n within a game console 402. 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. As an example, server system 404 is located within a data center enclosure. Server system 404 includes a memory device 412 that stores emulation PU code, such as emulation PU code 104. For example, memory device 412 stores game code 1 (gc1), game code 2 (gc2), etc., up to game code N (gcN). Game code gcN is emulation PU code 106 (...). Figure 1 Examples are provided. Each game code 1 to N is a conventional code for a conventional game. For illustration, game code gc1 is the machine code for playing the first conventional game, and game code gc2 is the machine code for playing the second conventional game. The second conventional game is different from the first conventional game. Note that, as an example, memory device 412 is a memory device for a conventional machine.

[0071] As an example, the game codes gc1 through gcN cannot be executed on a newer machine, but can be executed on a legacy machine. This is because the CPU or operating system of a newer machine cannot support the execution of game codes gc1 through gcn. On the other hand, the CPU or operating system of a legacy machine supports the execution of game codes gc1 through gcN. Examples of computer networks used herein include wide area networks (WANs) such as the Internet, local area networks (LANs) such as intranets, or combinations thereof.

[0072] Game console 402 is an example of an updated machine. For example, game console 402 is a PS4. TM Or PS5 TM Examples of display devices 410 include televisions, smart televisions, and computer monitors. For illustration, 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.

[0073] System 400 also includes a handheld controller 414, which is held in one or both hands of user 1. Examples of handheld controllers used herein include controllers with buttons, such as those from Sony. TM Corporation Move TM Controllers, and gun-shaped controllers. Examples of buttons on handheld controllers include joysticks, buttons for moving virtual objects up, down, left, or right on display screen 410, and other buttons for selecting various features of a traditional game N with the game name GN.

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

[0075] The game console 402 is coupled to the display device 410 via a wired communication medium such as an HDMI cable or a wireless connection. Examples of wireless connections, as used herein, include Wi-Fi. TM Connection and Bluetooth TM Connection. Furthermore, the handheld controller 414 is coupled to the game console 402 via a wired or wireless connection. Examples of wired connections, as used herein, include serial pass cables, parallel pass cables, and Universal Serial Bus (USB) cables.

[0076] Examples of client devices include combinations of handheld controllers, game consoles, and display devices. Another example of a client device is a combination of a handheld controller and a display device.

[0077] When the user's ID and password are successfully authenticated by the server system (404 error), user 1 logs into his / her user account. Server system 1 assigns user ID 1 to user 1. Once user 1 is logged into his / her user account 1, user 1 can access multiple game names, such as game name G1, game name Ga, game name G2, etc., up to game name GN. Game names G1, G2, etc., up to game name GN are examples of traditional game names. Game name Ga is not a traditional game name. Instead, game name Ga belongs to a current game, such as Fortnite, which cannot be played on traditional machines. TM .

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

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

[0080] When user input 420 is received via wireless connection from handheld controller 414 during a conventional game N with game code gcN on the toy, 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. The portion of game code GCN is generated based on user input 420. For example, if user input 420 includes sending WarHawk during a conventional game N... TM When the fighter jet requests to move from position P1 to position P2, the basic block compiler 104 parses the game code GCN to identify the instruction to calculate position P2 from position P1. The basic block compiler 104 translates the instruction into basic blocks of game code GCN, and then executes the basic blocks to generate WarHawk. TM The fighter jet's position changes from P1 to P2. In this example, the GPU of the emulated processor system 409 executes basic blocks of the game code GCN to generate one or more image frames 422. For illustration, one or more image frames 422 are displayed on the display device 410 to display WarHawk. TM The fighter jet is located in a virtual environment 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 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.

[0081] In one implementation, data communication between server system 404 and game console 402 is conducted via a network communication protocol, such as Transmission Control Protocol (TCP / IP) based on the Internet Protocol. For example, server system 404 includes a network interface controller to convert data into packets. Examples of network interface controllers, as used herein, include network interface cards (NICs) and network adapters. The network interface controller of server system 404 is coupled to memory device 412 to receive data from memory device 412. After receiving data from memory device 412, the network interface controller of server system 404 embeds the data into one or more packets by applying a network communication protocol to the data. The one or more packets are transmitted from the network interface controller of server system 404 to game console 402 via computer network 408. 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 game console 402 is coupled to emulation processor system 409. The network interface controller of game console 402 provides data received from computer network 408 to emulation processor system 409. Furthermore, the network interface controller of the game console 402 receives data from the emulation processor system 409, embeds the data into one or more packets by applying a network communication protocol, and sends the one or more packets to the server system 404 via the computer network 408. The network interface controller of the server system 404 applies the network communication protocol to the one or more packets received from the computer network 408 to extract data from the one or more packets and send the data to the memory device 412 for storage.

[0082] In one implementation, a cellular network is used to transmit data between server system 404 and game console 402, supplementing or replacing computer network 408. For example, wireless technology is used to facilitate communication between server system 404 and game console 402. The wireless technology includes, for example, 4G or 5G wireless communication technology. As used herein, 5G is the fifth generation of cellular network technology. Furthermore, a 5G network is a digital cellular network where the service area covered by a provider is divided into small geographical areas called cells. In 5G wireless communication technology, analog signals representing sound and images are digitized in a telephone call, converted by an analog-to-digital converter, and transmitted as a bit stream. All 5G wireless devices in a cell communicate via radio waves through frequency channels assigned from a frequency pool by the transceiver, with the frequency being reused in other cells. The local antennas are connected to the cellular network via high-bandwidth fiber optic or wireless backhaul connections. As in other cellular networks, mobile devices moving from one cell to another automatically switch to the new cell. It should be understood that 5G networks are merely exemplary types of communication networks, and embodiments of this disclosure may utilize previous generations of wireless or wired communication, such as 3G or 4G, as well as subsequent generations of wired or wireless technologies after 5G.

[0083] In one implementation, either the game console 402 or the server system 404 is referred to herein as a computing device. Other examples of the computing device include tablet computers, smartphones, laptop computers, desktop computers, and smart TVs.

[0084] In one implementation, each of the game codes gc1 through gcN is stored in a separate memory device of the server system 404 or a conventional machine. For example, game code gc1 is stored in the memory device of a first conventional machine, while game code gc2 is stored in the memory device of a second conventional machine. As another example, game code gc1 is stored in a first memory device of the server system 404, while game code gc2 is stored in a second memory device of the server system 404.

[0085] In one embodiment, memory device 412 or memory device 406 is not a cache. Instead, each of memory device 412 or memory device 406 is main memory, such as RAM.

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

[0087] Figure 4B This is a diagram illustrating an implementation of system 450, which shows that the simulation processor system 409 is located within the server system 404 and transmits one or more image frames 422 from the server system 404 to the display device 410 via the computer network 408 to display a virtual environment or virtual scene. System 450 includes server system 404, display device 410, and handheld controller 414.

[0088] Server system 404 includes a memory device 412 and an emulation processor system 409. The memory device 412 is coupled to the emulation processor system 409. Display device 410 is coupled to computer network 408 via a network interface controller for display device 410. Display device 410 includes a processor coupled to its network interface controller. During conventional gameplay of the toy, which has a game name GN and game code gcN, the processor of display device 410 receives user input 420 and sends it to the network interface controller of display device 410. The network interface controller of display device 410 sends the user input 420 to the emulation processor system 409 of server system 404 via computer network 408.

[0089] After receiving user input 420, the simulation processor system 409 executes the above-mentioned reference. Figure 4A The game code gcN describes the same functionality, compiling basic blocks 1 to N to generate one or more image frames 422. Server system 404 sends one or more image frames 422 to display device 410 via computer network 408 to display a virtual environment, such as virtual environment 452, on the display screen of display device 410. For example, virtual environment 452 includes a virtual object 454, which is Warhawk. TMAn example of a fighter jet. In this example, the virtual environment 452 includes a virtual background that includes one or more virtual objects, such as a virtual pyramid 455 and a virtual structure 456. In this example, the virtual object 454 is capable of launching virtual missiles at the virtual pyramid 455 and the virtual structure 456 during a traditional game N with game code gcN in the toy.

[0090] In one embodiment, data communication between server system 404 and display device 410 is performed via a network communication protocol. For example, server system 404 includes a network interface controller to convert data into packets. The network interface controller of server system 404 is coupled to emulation processor system 409 to receive data from the emulation processor system and embed the data into one or more packets by applying a network communication protocol. The packets are transmitted from the network interface controller of server system 404 to display device 410 via computer network 408. The network interface controller of display device 410 extracts data from the one or more packets by applying a network communication protocol. The network interface controller of display device 410 is coupled to the processor of display device 410. The network interface controller of display device 410 provides the data received from computer network 408 to the processor of display device 410. The processor of display device 410 renders data, such as image frames 422, on the display screen of display device 410. Furthermore, the network interface controller of display device 410 receives data from the processor of display device 410, embeds the data into 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 network communication protocols to one or more packets received from computer network 408 to extract data from the one or more packets and send the data to simulation processor system 409.

[0091] In one implementation, a cellular network is used to transmit data between the server system 404 and the display device 410, as a supplement to or alternative to the computer network 408. For example, wireless technology is used to facilitate communication between the server system 404 and the display device.

[0092] In one embodiment, a head-mounted display (HMD) is used as an alternative to display device 410. The head-mounted display is worn on the head of user 1 and includes a display screen, such as an LED screen, an OLED screen, or an LCD screen. The HMD performs the same functions as display device 410.

[0093] Figure 5AThis diagram illustrates the implementation of basic blocks. 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 the address of one or more source registers within cache 102, and the destination register address is the address of one or more destination registers within cache 102. Examples of operations in basic blocks include jump and branch operations, read operations, write operations, comparison operations, and return operations. Other examples of operations in basic blocks include arithmetic operations such as addition, subtraction, multiplication, and division.

[0094] As an example, when operation n is a read operation, data is read from source register address n to execute basic block n. As another example, when operation n is a write operation, data is written to destination register address n to execute basic block n. As yet another example, when operation n is a move operation, data is read from source register address n, operation n is performed on the data, and the data is written to destination register address n to execute basic block n. As yet another example, when operation n is a compare operation, a first value of the data stored at the first source register address mentioned in basic block n is compared with a second value of the data stored at the second source register address mentioned in basic block n to generate a comparison result, and the comparison result is stored at destination register address n to execute basic block n. As yet another example, when operation n is an addition operation, a first value of the data stored at the first source address mentioned in basic block n is added with a second value of the data stored at the second source address indicated in basic block n to generate an addition result, and the addition result is stored at destination register address n to execute basic block n. As another example, when the virtual object described herein moves from position P1 to position P2 and operation n is a write operation in which the position of the virtual object is updated from P1 to P2, position P1 at destination register address n is overwritten by position P2 to execute basic block n. In this example, the execution of basic block n instructs the emulation processor system 409 that the virtual object will move from position P1 to position P2. Moreover, in this example, user input 420 ( Figure 4AThe simulation processor system 409 is instructed to move a virtual object from position P1 to P2. Similarly, as another example, when the virtual object described herein is to move from orientation O1 to orientation O2 and operation n is a write operation in which the orientation of the virtual object is updated from O1 to O2, orientation O1 at destination register address n is overwritten by orientation O2 to execute basic block n. In this example, the execution of basic block n instructs the simulation processor system 409 to move the virtual object from orientation O1 to orientation O2. Furthermore, in this example, user input 420 instructs the simulation processor system 409 to move the virtual object from orientation O1 to O2.

[0095] As yet another example, when a portion of the virtual object described herein will change its color from red to green, and operation n is a write operation in which the color of the virtual object is updated from red to green, the data representing the red color at the destination register address is overwritten with the data representing the green color to execute basic block n. In this example, the execution of basic block n instructs the emulation processor system 409 that the color of the portion of the virtual object will change from red to green. Furthermore, in this example, user input 420 instructs the emulation 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, can be modified based on user input 420.

[0096] Each basic block includes the number of execution loops for that basic block. For example, basic block 1 includes the number of execution loops for basic block 1, which is 1. As another example, basic block 2 includes the number of execution loops for basic block 2, which is 2, and basic block n includes the number of execution loops for basic block n, which is n. As an example, basic block compiler 104 ( Figure 1 The estimated number of execution loops for a basic block is estimated when compiling the basic block. In the example described, the estimated number of loops is stored in the basic block. Also in the example described, in block dispatcher 302 ( Figure 3 After the basic block is executed, the block dispatcher 302 updates the estimated number of execution loops using the actual count as described above, and provides the actual count to the block compiler 104. The block compiler 104 then replaces the estimated number of loops with the actual count from the basic block. As another example, the actual count of the number of execution loops for operation n is generated by the block dispatcher 302 and stored in the basic block n. In this example, the number of execution loops for operation n is not estimated.

[0097] Furthermore, as another example, one or more of the basic blocks 1 to n may include an invalidation flag indicating that a validity check is performed on one or more of the basic blocks 1 to n. For example, basic block n may include an invalidation flag n.

[0098] It should be noted that by converting the emulated PU code 106 into basic blocks 1 to n of the game code gcN, hooks, such as hook blocks, can be inserted between any two of the basic blocks 1 to n. For example, hook block n can be inserted between basic block (n-1) and n. Hook block n has the same structure as basic block n. For example, the hook block includes the source register address, destination register address, operation, and the number of execution loops for the operation of the hook block. As an example, due to security issues associated with legacy machines, it is not possible to store the emulated CPU code 106 (which is intended for execution on a legacy machine) in a legacy machine. Figure 1 Hooks, as described in this article, are inserted between instructions.

[0099] It should be further noted that basic blocks 1 to n are typed into (such as fixed in) cache 102 ( Figure 1 For example, basic block 1 has a start memory address 1, which indicates the starting position of basic block 1 in cache 102. Furthermore, basic block 1 has an end memory address 1, which indicates the ending 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 cache 106. Similarly, as another example, basic block n has a start memory address n, which indicates the starting position of basic block n in cache 102. Furthermore, basic block n has an end memory address n, which indicates the ending position of basic block n in cache 102. As another example, the end address n of basic block n is indicated by the offset in cache 106 from the start memory address n. (Emulated processor system 409) Figure 4A Examples include the basic block compiler 102, which can identify the location of basic blocks 1 to n in cache 102 from the start memory address and end memory address of the basic blocks 1 to n stored in cache 102.

[0100] It should also be noted that if the user inputs an instruction for the updated machine's block dispatcher 302 to execute basic block n immediately after executing basic block 1, the block dispatcher 302 skips the execution of basic blocks 2 through (n-1) in cache 102 and jumps from basic block 1 to basic block n. In this case, when the block dispatcher 302 jumps to basic block n, the block dispatcher 302 stops the execution of basic block 1. Moreover, in this case, the start address of the next basic block is contiguous with the end address of the previous basic block. For example, the start address 2 is contiguous with the end address 1, and the start address n is contiguous with the end address (n-1) of basic block (n-1).

[0101] In one implementation, source register addresses 1 to n are memory addresses of registers in cache 102, and destination register addresses 1 to n are memory addresses of registers in cache 102.

[0102] In one implementation, a basic block includes multiple operations. For example, basic block n includes a first operation, a first source register address, and a first destination register address. Basic block n also includes a second operation, a second source register address, and a second destination register address.

[0103] In one implementation, the basic block includes an operation, multiple source addresses, and a destination address.

[0104] In one implementation, the basic block includes an operation, multiple destination addresses, and a source address.

[0105] In one implementation, a basic block includes multiple operations, multiple source addresses, and multiple destination addresses.

[0106] In one implementation, a basic block includes one or more operations, one or more source addresses, and one or more destination addresses.

[0107] In one implementation, the basic block includes either the source register address or the destination register address, but not both.

[0108] In one implementation, the block compiler 102 does not estimate the number of execution loops for the basic block n. Instead, the block dispatcher 302 generates an actual count of the number of execution loops for the basic block n and stores the actual count in the basic block n.

[0109] Figure 5B This is used to explain the basic block compiler 104 ( Figure 1A diagram illustrating the implementation of the compilation operation performed. An example of the simulated PU code instruction M is illustrated as instruction 550, and an example of the 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. As an example, a is 4, b is 4, and c is 32. As an example, bits a, b, and c are stored in one or more memory devices of a conventional machine. For example, bit a is stored in memory device 406 or 412. Figure 4A and Figure 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 bits of length f, where d, e, and f are positive integers. For example, d is 8, e is 8, and f is 64. For example, d, e, and f bits are stored in one or more registers of the updated machine. For example, d is greater than a, e is greater than b, and f is greater than c. To illustrate, 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.

[0110] In order to perform the compilation operation, the basic block compiler 104 ( Figure 1 The source address M is translated into source register address n, the destination address M is translated into destination register address n, and the operation M is translated into operation n to generate a basic block n from the emulated PU code instruction M. For example, the basic block compiler 104 right-shifts 4 bits of the source address M to occupy 4 memory addresses of the 8 source registers in cache 102, and masks any bits of the remaining four memory addresses of the 8 source registers. The four memory addresses occupied by the 4 bits of the source address M are located at the least significant position of the 8 source registers in cache 102, and the remaining four memory addresses with the bits masked are located at the most significant position of the 8 source registers in cache 102.

[0111] As another example, the basic block compiler 104 right-shifts 4 bits of the destination address M to occupy 4 memory addresses of the 8 destination registers in 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 the destination address m are located at the least significant positions of the 8 destination registers in cache 102, and the remaining four memory addresses with the bits masked are located at the most significant positions of the 8 destination registers in cache 102.

[0112] Similarly, as another example, the basic block compiler 104 right-shifts the 32 bits of operation M to occupy 32 memory addresses of the 64 operation registers in 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 location of the 32 operation registers in cache 102, and the remaining 32 memory addresses with the bits masked are located at the most significant location of the 64 operation registers in cache 102. Operation n is stored in the operation registers of cache 102.

[0113] Figure 6A This is a diagram illustrating an implementation of system 600, which includes components of emulation processor system 409. System 600 includes memory device 412 and emulation processor system 409. The basic block compiler 104 of emulation processor system 409 includes a parser or decoder 602. The basic block compiler 104 also includes a block creator 604, a block cache 606A, and a block reader 608. Emulation processor system 409 includes a block dispatcher 302.

[0114] As an example, each of parser 609, block creator 604, block cache 606, block reader 608, and block dispatcher 302 is implemented using software or hardware, or a combination thereof. For instance, each of parser 609, block creator 604, block cache 606, block reader 608, and block dispatcher 302 is a separate integrated circuit, such as a PLD or ASIC, or part of a controller, processor, or computer program. As another example, each of parser 609, block creator 604, block cache 606, block reader 608, and block dispatcher 302 is a separate computer software program.

[0115] The game code gcN comprises multiple instructions, such as emulation PU code instruction 1, emulation PU code instruction 2, and so on, up to emulation PU code instruction M. For example, each instruction of the game code gcN is a series of bits that can be executed by a processor of a conventional machine to perform 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 portion of the parameters of a virtual object.

[0116] Parser 602 is coupled to block creator 604, which is coupled to block cache 606 and block reader 608. Block cache 606 and block reader 608 are also coupled to cache 102. Block reader 608 is coupled to block dispatcher 302.

[0117] Figure 6B This is a flowchart illustrating the implementation scheme of method 650 for compiling and executing basic blocks 1 to n. Figure 6AThe method 650 is illustrated using system 600. In operation 652 of method 650, block creator 604 determines whether any user input, such as user input 1, has been received. As an example, user input 1 includes a handheld controller 414 selected by user 1. Figure 4A The signal represents one or more buttons or identifiers of a device. As another example, User Input 1 is a signal generated based on measures of movement such as pitch, yaw, and roll relative to the origin of the xyz coordinate system centered on the handheld controller 414. As yet another example, User Input 1 is a signal that includes measures of movement such as pitch, yaw, and roll relative to the origin of the xyz coordinate system of the HMD. An example of User Input 1 is User Input 420 (… Figure 4A ).

[0118] After determining that no user input has been received, the block creator 604 continues to check for user input in operation 652. For example, if no user input is received in operation 652, the basic block compiler 104 does not run the code stored in cache 102. Figure 1 The basic block (n+1) to p in the basic block compiler 104 ( Figure 1 The emulated PU code instructions 1 to M are not recognized. Figure 6A Any of the following, where p is a positive integer. Assume that when user input is received in operation 652, basic blocks 1 to n have not been generated and are not stored in buffer 102.

[0119] 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) to p stored in cache 102 satisfy the user input. For example, block creator 604 sends a request to block reader 608 to access basic blocks (n+1) to p from cache 102. In this example, block reader 608 reads basic blocks (n+1) to p from cache 102 after receiving the request and sends basic blocks (n+1) to p to block creator 604. Furthermore, in this example, block creator 604 determines whether the functionality of one or more of the basic blocks (n+1) to p satisfies (e.g., serves) user input 1. To illustrate, when user input 1 indicates changing the position of a virtual object from position P1 to position P2, block creator 604 determines whether any of the basic blocks (n+1) to p includes an operation of overwriting position P1 with position P2. After determining that one or more of the basic blocks (n+1) to p include the operation of overwriting position P1 with P2, the block creator 604 determines that one or more of the functionalities of the basic blocks (n+1) to p satisfy user input 1. On the other hand, after determining that none of the basic blocks (n+1) to p include the operation of overwriting position P1 with P2, the block creator 604 determines that the functionalities of the basic blocks (n+1) to p do not satisfy user input 1.

[0120] As another explanation, when user input 1 changes the orientation of a virtual object from orientation O1 to orientation O2, block creator 604 determines whether any of the basic blocks (n+1) to p includes an operation of overwriting orientation O1 with orientation O2. After determining that one or more of the basic blocks (n+1) to p include an operation of overwriting orientation O1 with O2, block creator 604 determines that one or more of the basic blocks (n+1) to p satisfy user input 1. On the other hand, after determining that none of the basic blocks (n+1) to p include an operation of overwriting orientation O1 with O2, block creator 604 determines that the functionality of the basic blocks (n+1) to p does not satisfy user input 1. As yet another explanation, when user input 1 changes the value of a parameter of a part of the virtual object from a first value to a second value, the block creator determines whether any of the basic blocks (n+1) to p includes an operation of overwriting the first value with the second value. After determining that one or more of the basic blocks (n+1) to p include the operation of overwriting the first value with the second value, the block creator 604 determines that one or more of the basic blocks (n+1) to p satisfy the user input 1. On the other hand, after determining that none of the basic blocks (n+1) to p include the 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.

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

[0122] On the other hand, after determining that the functionality of blocks (n+1) to p does not satisfy user input 1, in operation 658 of method 600, block compiler 102 identifies one or more of the emulated PU code instructions 1 to M to serve the user input received in operation 652. For example, after determining that the functionality of blocks (n+1) to 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 the emulated PU code instructions 1 to M of game code gcN that satisfy the functionality identified in user input 1. In the example, in response to receiving the request, parser 602 accesses memory device 412 to parse game code gcN to determine whether the functionality of one or more of the emulated PU code instructions 1 to M satisfies user input 1, and after determining that the functionality of one or more of the emulated PU code instructions 1 to M satisfies user input 1, parser 602 provides one or more of the emulated PU code instructions 1 to M to block creator 604.

[0123] To illustrate, when user input 1 changes the position of the virtual object from position P1 to position P2, parser 602 determines whether any of the simulation PU code instructions 1 to M includes the operation of overwriting position P1 with position P2. After determining that one or more of the simulation PU code instructions 1 to M include the operation of overwriting position P1 with P2, parser 602 determines that one or more of the functionalities of the simulation PU code instructions 1 to M satisfy user input 1. On the other hand, after determining that none of the simulation PU code instructions 1 to M include the operation of overwriting position P1 with P2, parser 602 determines that the functionality of the simulation PU code instructions 1 to M does not satisfy user input 1.

[0124] As another explanation, when user input 1 changes the orientation of a virtual object from orientation O1 to orientation O2, parser 602 determines whether any of the simulation PU code instructions 1 to M includes an operation of overwriting orientation O1 with orientation O2. After determining that one or more of the simulation PU code instructions 1 to M include an operation of overwriting orientation O1 with O2, parser 602 determines that one or more of the functionality of the simulation PU code instructions 1 to M satisfies user input 1. On the other hand, after determining that none of the simulation PU code instructions 1 to M include an operation of overwriting orientation O1 with O2, parser 602 determines that the functionality of the simulation PU code instructions 1 to M does not satisfy user input 1. As yet another explanation, when user input 1 changes the value of a parameter of a virtual object from a first value to a second value, parser 602 determines whether any of the simulation PU code instructions 1 to M includes an operation of overwriting the first value with the second value. After determining that one or more of the simulated PU code instructions 1 to M include the operation of overwriting the first value with the second value, the parser 602 determines that one or more of the functionalities of the simulated PU code instructions 1 to M satisfy user input 1. On the other hand, after determining that none of the simulated PU code instructions 1 to M include the operation of overwriting the first value at the second value, the parser 602 determines that the functionalities of the simulated PU code instructions 1 to M do not satisfy user input 1.

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

[0126] In operation 662 of method 600, after receiving an instruction from block creator 604 to execute one or more of basic blocks 1 to n, block dispatcher 302 runs one or more of basic blocks 1 to n to serve 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 to n from cache 102. After receiving the command, block reader 608 reads one or more of basic blocks 1 to n from cache 102 and provides one or more of basic blocks 1 to n to block dispatcher 302. After receiving one or more of basic blocks 1 to n, block dispatcher 302 executes one or more of basic blocks 1 to n to generate virtual environment 452. Figure 4B To illustrate, block dispatcher 302 executes one or more of basic blocks 1 to n to generate an image frame, the image frame including: virtual environment data, such as the position and orientation of virtual object 454; parameters of virtual object 454; the positions and orientations of other virtual objects in virtual environment 452; and parameters of other virtual objects in virtual environment 452. Block dispatcher 302 provides the image frame to the GPU of emulation processor system 409 for display on display device 410. Figure 4A The virtual environment 452 is displayed (such as rendered) on the display screen. Method 600 is repeated when another user input, such as user input 2, is received after user input 1 is received in operation 652.

[0127] Figure 6C This is a diagram illustrating an implementation of a system 670 that dynamically compiles different basic blocks or different groups of basic blocks for different user inputs. System 670 includes a memory device 412, a basic block compiler 104, a block dispatcher 302, and a cache 102. When the basic block compiler 104 receives user input 1, it determines whether the basic block 1 corresponding to user input 1 is stored in the cache 102. Basic block 1 corresponds to user input 1 when it includes functions for serving user input 1. For illustration, basic block 1 can serve user input 1 when user input 1 is moving a virtual object from position P1 to position P2 and basic block 1 includes an operation to update position P1 stored at destination register address 1 with position P2. In this illustration, user input 1 is an instruction to a handheld controller 414 (… Figure 4AThe signal for selecting the right, left, up, or down movement button on the device. Similarly, if basic block 2 does not include a function to serve user input 1, basic block 2 does not correspond to user input 1. To illustrate, if user input 1 is moving a virtual object from position P1 to position P2 without changing the orientation of the virtual object and basic block 2 includes an operation to update orientation O1 stored in destination register 2 with orientation O2, basic block 2 cannot serve user input 1. After determining that basic block 1, which can serve user input 1, is stored in cache 102, basic block compiler 104 provides basic block 1 to block dispatcher 302 for execution.

[0128] On the other hand, after determining that basic block 1 is not stored in cache 102, basic block compiler 104 parses the emulated PU code 106 stored in memory device 412 to identify the emulated PU code instruction 1 corresponding to user input 1. For example, basic block compiler 104 parses emulated PU code 106 to identify emulated PU code instruction 1 that satisfies (e.g., serves) user input 1. To illustrate, when user input 1 is moving a virtual object from position P1 to position P2 and emulated PU code instruction 1 includes the function of updating position P1 stored at destination address 1 with position P2, the emulated PU code instruction 1 can serve user input 1. Similarly, when emulated PU code instruction 2 does not include the function for serving user input 1, the emulated PU code instruction 2 does not correspond to user input 1. To illustrate, when user input 1 is moving a virtual object from position P1 to position P2 without changing the orientation of the virtual object and emulated PU code instruction 2 includes the operation of updating orientation O1 stored at destination address 2 with orientation O2, the emulated PU code instruction 2 cannot serve user input 1.

[0129] After determining that emulated PU code instruction 1 can serve user input 1 and emulated PU code instruction 2 cannot serve user input 1, the basic block compiler 104 accesses (e.g., 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, the basic block compiler 102 does not compile basic block 2 from emulated PU code instruction 2. The 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. Upon receiving the instructions, block dispatcher 302 reads basic block 1 from cache 102 and runs basic block 1.

[0130] Similarly, when the basic block compiler 104 receives user input 2, it determines whether basic block 2 corresponding to user input 2 is stored in cache 102. Basic block 2 corresponds to user input 2 when it includes functions for serving user input 2. For example, basic block 2 can serve user input 2 when user input 2 is moving a virtual object from orientation O1 to orientation O2 and basic block 2 includes an operation to update orientation O1 stored at destination register address 2 with orientation O2. In this description, user input 2 is a signal indicating a selection of a clockwise or counterclockwise rotation button on the handheld controller 414. Similarly, basic block 1 does not correspond to user input 2 when it does not include functions for serving user input 2. For example, basic block 1 cannot serve user input 2 when user input 2 is moving a virtual object from orientation O1 to orientation O2 without changing the virtual object's position and basic block 1 includes an operation to update position P1 stored in destination register 1 with position P2. After determining that the basic block 2 that can serve user input 2 is stored in cache 102, the basic block compiler 104 provides basic block 2 to the block dispatcher 302 for execution.

[0131] On the other hand, after determining that basic block 2 is not stored in cache 102, basic block compiler 104 parses the emulated PU code 106 stored in memory device 412 to identify the emulated PU code instruction 2 corresponding to user input 2. For example, basic block compiler 104 parses emulated PU code 106 to identify emulated PU code instruction 2 that satisfies (e.g., serves) user input 2. To illustrate, when user input 2 is moving a virtual object from orientation O1 to orientation O2 and emulated PU code instruction 2 includes the function of updating orientation O1 stored at destination address 2 with orientation O2, the emulated PU code instruction 2 can serve user input 2. Similarly, when emulated PU code instruction 1 does not include the function for serving user input 2, the emulated PU code instruction 1 does not correspond to user input 2. To illustrate, when user input 2 is moving a virtual object from orientation O1 to orientation O2 without changing the position of the virtual object and emulated PU code instruction 1 includes the operation of updating position P1 stored at destination address 1 with position P2, the emulated PU code instruction 1 cannot serve user input 2.

[0132] After determining that emulated PU code instruction 2 can serve user input 2 and emulated PU code instruction 1 cannot serve user input 2, the basic block compiler 104 accesses (e.g., 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. Upon receiving the instructions, block dispatcher 302 reads basic block 2 from cache 102 and runs basic block 2.

[0133] Figure 7A This diagram illustrates an implementation of a system 700 for removing emulated PU code 106 from memory device 412. System 700 includes a block creator 604, an instruction remover 702, and memory device 412. Examples of the instruction remover 702 include a processor, ASIC, PLD, computer program, a portion of a computer program, and a microcontroller. The instruction remover 702 is coupled to the block creator 604 and memory device 412.

[0134] Figure 7B This is used to describe the use of memory device 412 ( Figure 6C ) Delete simulation PU code 106 ( Figure 6C A flowchart of an implementation of method 720 is provided. Method 720 includes operation 702 for determining whether all instructions of the simulation PU code 106 have been compiled. For example, block creator 604 ( Figure 7AThe block creator 604 determines whether all emulated PU code instructions 1 to M of the game code gcN have been compiled. For illustration, before compiling any of the emulated PU code instructions 1 to M of the game code gcN, the block creator 604 sends a request to the processor of the legacy machine to obtain the identity of all emulated PU code instructions 1 to M of the game code gcN. In this 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 identity of all emulated PU code instructions 1 to M of the game code gcN. Examples of the identity of emulated PU code instructions 1 to M include one or more bits. For illustration, the identity of emulated PU code instruction M is represented by a first bit sequence, and the identity of emulated PU code instruction M-1 is represented by a second bit sequence different from the first sequence. After receiving the identity of the emulated PU code instructions 1 to M from the processor of the legacy machine, the block creator 604 stores the identity in a table in cache 102. As each of the emulated PU code instructions 1 to M is compiled, the block creator 604 updates the table to include an indication identifying which emulated PU code instructions 1 to M have been compiled. The block creator 604 determines whether all emulated PU code instructions 1 to M are compiled based on an indication that identifies which emulated PU code instructions 1 to M are compiled.

[0135] After confirming that all simulated PU code instructions 1 to M of the game code gcN have been compiled, block creator 604 moves to instruction remover 702. Figure 7A A command is sent to delete the game code gcN from the memory device 412. Upon receiving the command, in operation 724 of method 720, the instruction remover 702 erases the emulated PU code instructions 1 to M from the memory device 412.

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

[0137] In one implementation, block creator 604 determines whether the access to game code gcN from memory device 412 began within a predetermined period from memory device 412 at the most recent time. Figure 4AThe block creator 604 accesses the game code gcN stored in cache 102. As an example, the block creator 604 may access an internet clock via 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. After determining that the game code gcN was not accessed from memory device 412 within the predetermined period, the block creator 604 sends a command to instruction remover 702 to delete the game code gcN from memory device 412. As an example, when the game code gcN is not accessed within the predetermined period, the basic block compiler 104 accesses most of the emulated CPU code instructions 1 to M to compile one or more of basic blocks 1 to n. As another example, when the game code gcN is not accessed within the predetermined period, the basic block compiler 104 accesses many of the emulated CPU code instructions 1 to M frequently used during the traditional game N with the game name GN in toys to compile one or more of basic blocks 1 to n. On the other hand, after determining that the game code gcN will be accessed 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.

[0138] Figure 8A This is a diagram illustrating the implementation scheme of the simulation processor system 800 for verifying basic blocks. Simulation processor system 800 is simulation processor system 409 ( Figure 4B Example of a emulated processor system 800. The emulated processor system 800 includes a basic block compiler 104, a cache 102, a block verifier 802, and a block tagger 804. The block verifier 802 is coupled to a block creator 604, a block dispatcher 302, a parser 602, and a block tagger 804. Each of the clock verifier 802 and the block tagger 804 is coupled to the cache 102.

[0139] As an example, block verifier 802 is implemented as an ASIC, or PLD, or microcontroller, or processor, or computer program, or part of a computer program. Also as an example, block marker 804 is implemented as an ASIC, or PLD, or microcontroller, or processor, or computer program, or part of a computer program.

[0140] In one implementation, the terms ASIC, PLD, microcontroller, microprocessor, controller, and processor are used interchangeably herein.

[0141] Figure 8B It is used to illustrate the simulation processor system 800 ( Figure 8A A flowchart of the implementation scheme of method 850 for performing verification operations. In operation 852 of method 800, block verifier 802 ( Figure 8AThe block verifier 802 determines whether a basic block (such as basic block n) has been compiled. For example, the block verifier 802 accesses (such as reads) cache 102 to determine whether a new basic block (such as basic block n) is now stored in cache 102 compared to basic blocks 1 to n-1 previously stored in cache 102. The block verifier 802 previously identified basic blocks 1 to n-1 stored in cache 102. After determining that basic block n is not cached, the block verifier 802 continues to access cache 102 to determine whether the new basic block is cached. For example, the block verifier 802 periodically parses basic blocks 1 to n-1 stored in cache 102 to determine whether basic block n is stored in cache 102.

[0142] 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 the emulated CPU code instructions 1 to M upon which basic block n was compiled. For example, block verifier 802 sends a request to parser 602 to obtain one or more of the emulated CPU code instructions 1 to M from memory device 412. The request includes the identity of the memory address of basic block n in cache 102. Block verifier 602 receives (e.g., obtained by request) the identity of the memory address of basic block n from block creator 604. After receiving the request from block verifier 802, parser 602 reads one or more of the emulated CPU code instructions 1 to M from memory device 412 and provides one or more of the emulated CPU code instructions 1 to M to block verifier 802. To illustrate, when one or more of the simulated PU code instructions 1 to M are provided to the basic block compiler 104 to compile basic block n, the 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 the simulated PU code instructions 1 to M in memory device 412. The parser 602 receives the identities of the memory addresses of basic block n in cache 102 from the block verifier 802 and identifies one or more memory addresses of one or more of the simulated PU code instructions 1 to M in memory device 412 according to the one-to-one correspondence. The parser 602 reads one or more of the simulated PU code instructions 1 to M from one or more memory addresses in memory device 412 and provides one or more of the simulated PU code instructions 1 to M to the block verifier 802.

[0143] Continuing the example, after receiving one or more of the emulated PU code instructions 1 to M from the parser 602, the block verifier 802 generates a first hash value from the emulated PU code instructions 1 to M and stores the first hash value in cache 102. For illustration, the block verifier 802 generates a digest or checksum from one or more of the emulated PU code instructions 1 to M corresponding to the basic block n. In this example, the first hash value is stored in one or more registers of cache 102 that are typed to include the basic block n.

[0144] In operation 856 of method 800, block verifier 802 sends a command to parser 602 to determine whether one or more memory addresses in memory device 412 storing one or more of the emulated PU code instructions 1 to M have been overwritten. One or more memory addresses in memory device 412 can be overwritten with data from a compressed optical disc-read-only memory (CD-ROM) of a conventional machine. The data can be an update to one or more of the emulated PU code instructions 1 to M. An update to one or more of the emulated PU code instructions 1 to M is referred to as an updated instruction. Alternatively, the data can be corrupted data that is not an updated instruction. After receiving the command from block verifier 802, parser 602 sends a request to the processor of the conventional machine to determine whether one or more memory addresses in memory device 412 storing one or more of the emulated PU code instructions 1 to M have been overwritten.

[0145] Upon receiving a request from parser 602, the processor of the conventional machine provides a response to the request, and the response indicates whether one or more memory addresses in memory device 412 storing one or more of the emulated PU code instructions 1 to M have been overwritten. After receiving a response that one or more memory addresses in memory device 412 storing one or more of the emulated PU code instructions 1 to M have not been overwritten, block verifier 802 sends a request to block marker 804 (…). Figure 8A A command is sent not to mark basic block n as invalid. After receiving the command, in operation 858 of method 800, block marker 804 does not mark basic block n as invalid.

[0146] On the other hand, after receiving a response that one or more memory addresses in memory device 412 storing one or more of the emulated PU code instructions 1 to M have been overwritten, in operation 860 of method 850, block verifier 802 sends a signal to block marker 804. Figure 8AThe block marker 804 sends a command to mark basic block n as invalid. Upon receiving the command to mark basic block n as invalid, the block marker 804 marks basic block n as invalid. For example, the block marker 804 accesses basic block n within cache 102 and includes an identifier, such as invalidation flag n, within the memory address of basic block n in cache 102. Figure 5A The invalidation flag (n) is used to indicate that the basic block n is invalid. An example of an invalidation flag n is a bit sequence.

[0147] In one implementation, the hash value is an example of the verification result.

[0148] Figure 8C yes Figure 8B The continuation of the flowchart for method 800. In operation 862 of method 800, block verifier 802 ( Figure 8A The block dispatcher 302 determines whether to execute basic block n. For example, the block dispatcher 302 sends an instruction to the block verifier 802 to execute basic block n. After receiving the instruction to execute basic block n from the block dispatcher 302, the block verifier 802 determines that basic block n will be executed. Before receiving the instruction, the block verifier 802 is unsure whether basic block n has been verified.

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

[0150] After determining that basic block n has not been marked as invalid, basic block n is executed in operation 866 of method 800. For example, operation 866 is similar to operation 662. Figure 6BFor illustration, block verifier 802 sends a command to block dispatcher 302 to execute basic block n. After receiving the 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 it receives the command for executing basic block n from block verifier 802.

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

[0152] In response to determining that the basic block n is valid, in operation 870 of method 800, the invalidation mark n is removed. For example, block validator 802 sends a command to block marker 804 to remove the invalidation mark n from the basic block n stored in cache 102. After receiving the command from block validator 802, block marker 804 accesses the basic block n from cache 102 and erases the invalidation mark n from the basic block n. For illustration, block marker 804 erases the invalidation mark n from one or more memory addresses in cache 102 where the invalidation mark n is stored. After removing the invalidation mark n, block marker 804 sends a command to block dispatcher 302 to execute basic block n, and after receiving the command, in operation 866, block dispatcher 302 runs basic block n. As an example, block dispatcher 302 does not execute basic block n until it receives the command to execute basic block n from block marker 804.

[0153] On the other hand, after determining that basic block n is not valid, in operation 872 of method 800, an additional basic block with the same functionality or operation as basic block n is compiled. For example, block verifier 802 sends a command to block dispatcher 302 not to execute basic block n, and sends an indication to block creator 604 that basic block n is invalid. Upon receiving the indication, block creator 604 recompiles basic block n. To illustrate, block creator 604 compiles the additional basic block in the same way as compiling basic block n from one or more of the emulated PU code instructions 1 to 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 to M) stored in a memory device of an additional conventional machine. The additional conventional machine is different from the conventional machine including memory device 412. Moreover, the additional set of emulated PU code instructions has the same game name GN as the game name of game code gcN. As another illustration, block creator 604 compiles additional basic blocks in the same manner as compiling basic block n from one or more of the plurality of emulated PU code instructions 1 to M stored in 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 to M) stored in memory device 412 at a memory address different from the memory address in memory device 412 where emulated PU code instructions 1 to M are stored. As yet another illustration, block creator 604 compiles additional basic blocks in the same manner as compiling basic block n from one or more of the emulated PU code instructions 1 to M stored in 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 to M) stored in a memory device different from memory device 412.

[0154] The additional basic blocks are sent from block creator 604 to block dispatcher 302 for execution. For example, block dispatcher 302 executes the additional basic blocks to generate additional virtual environments (such as virtual environment 452). Figure 4B As part of the image frame, block dispatcher 302 executes additional base blocks to generate a portion of the image frame, which includes additional virtual environment data, such as the position and orientation of virtual object 454, parameters of virtual object 454, the positions and orientations of other virtual objects in virtual environment 452, and parameters of other virtual objects in the additional virtual environment. Block dispatcher 302 provides the image frame to the GPU of emulation processor system 409 for display (such as rendering) of the additional virtual environment on the display screen of display device 410.

[0155] 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 to (n-1) and more additional basic blocks generated in the same manner as the additional basic blocks.

[0156] In one embodiment, the set of emulated PU code instructions 1 to M is stored in a first set of one or more storage devices located outside the conventional machine, and an additional set of emulated PU code instructions is stored in a second set of one or more storage devices located outside an additional conventional machine.

[0157] Figure 9A This diagram illustrates an implementation scheme for a conventional machine 900. An example of a conventional machine 900 is the PS1. TM or PS2 TM The conventional machine 900 includes a conventional CPU 902, a conventional GPU 904, a memory device 906, and a CD-ROM drive 908. The memory device 906 is a memory device 412 ( Figure 4A Examples of conventional CPUs are as follows: Example 902 is a 32-bit CPU that can process up to 32 bits in one clock cycle. Similarly, example 904 is a 32-bit GPU that can process up to 32 bits in one clock cycle. Example 906 is a 2-megabyte (MB) RAM.

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

[0159] A conventional CPU 902 or a conventional GPU 904 accesses and processes the emulated PU code 106 from the memory device 906. A CD-ROM drive 908 receives a CD-ROM containing updated instructions or corrupted code. The updated instructions or corrupted code can be transferred from the CD-ROM to the memory device 906 by the conventional CPU 902.

[0160] In one implementation, the conventional machine 900 does not include a cache. In another implementation, the conventional machine 900 includes a cache of limited capacity, such as a 4 kilobyte (KB) cache.

[0161] Figure 9B This diagram illustrates the implementation scheme of the updated 920 machine. An example of the updated 920 machine is the PS4. TM Or PS5 TMThe updated Machine 920 includes a CPU 922, a GPU 924, a memory system 926, and a cache 102. Figure 1 Example cache 928. Game console 402 ( Figure 4B The 922 CPU is an example of the updated Machine 920. As an example, the CPU 922 includes two quad-core modules, each capable of processing 64 bits per clock cycle. Each core has 32 kilobytes (KB) of cache. Another example of the CPU 922 is a 64-bit CPU that can process up to 64 bits per clock cycle. As an example, the GPU 924 has 1152 cores, each capable of processing 64 bits per clock cycle. As another example, the traditional GPU 924 is a 64-bit GPU that can process up to 64 bits per clock cycle.

[0162] The CPU 922 and GPU 924 are coupled to the memory system 906. As an example, the emulated PU code 106 is stored within the conventional memory system 906. Examples of the memory system 926 include hard drives providing 500 gigabytes (GB) or 2 terabytes (TB) of storage. The CPU 922, GPU 924, cache 928, and memory system 926 are coupled to each other via bus 930.

[0163] The CPU 922 or GPU 924 first accesses the cache 928 before accessing the memory system 926. After determining that the cache 928 does not contain the data requested by the CPU 922 or GPU 924, the CPU 922 or GPU 924 accesses the memory system 926.

[0164] It should be noted that in one implementation, the game code gcN cannot be executed by CPU 922 or GPU 924, but can be executed by conventional CPU 902 or conventional GPU 904. Furthermore, basic blocks 1 to n can be executed by CPU 922 or GPU 924, but not by conventional CPU 902 or conventional GPU 904.

[0165] In one implementation, cache 928 is located within CPU 922.

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

[0167] In one implementation, cache 928 is located within CPU 922, while another cache, such as cache 102, is located within GPU 924.

[0168] Figure 10A This is used to illustrate the use of the basic block compiler 104 ( Figure 1A diagram illustrating an implementation scheme of a system 1000 that combines multiple basic blocks into a single basic block. Block Creator 604 ( Figure 6A ) Receive user input 1, such as an instruction to launch a virtual object 454 at position P1 and orientation O1 in the first level of a traditional game N with the game name GN. Figure 4B The signal is received by the basic block compiler 104. Upon receiving user input 1, the basic block compiler 104 generates basic block 1 based on the simulated PU code instruction 1 to serve user input 1. Similarly, the block creator 604 receives user input 2, such as a signal instructing the activation of virtual object 454 at position P1 and orientation O1 in the second level of the traditional game N. Upon receiving user input 2, the basic block compiler 104 generates basic block 2 based on the simulated PU generation code instruction 2 to serve user input 2.

[0169] When user input 3 is received, such as a signal instructing the activation of virtual object 454 at position P1 and orientation O1 in the third level of a traditional game N, block compiler 104 recognizes basic blocks 1 and 2 as serving user input 3. Following this recognition, block creator 604 integrates (e.g., combines) basic blocks 1 and 2 into a single basic block, such as basic block 1 or basic block 2. This integration saves memory space in cache 102 and also increases the efficiency of accessing a single basic block instead of accessing basic blocks 1 and 2 separately.

[0170] Block creator 604 further generates values ​​in the pointer to cache 102. As used herein, an example of a pointer is a register. When user input is received for serving base block 1 or base block 2, the pointer instructs block dispatcher 302 to execute a single base block. When block dispatcher 302 is about to execute base block 1 or 2, block dispatcher 302 accesses the pointer and executes the single base block instead of base block 1 or 2.

[0171] Figure 10B This is a diagram illustrating an implementation scheme of system 1020 for modifying one or more of the basic blocks 1 to n. System 1020 includes a block interface 1022, a cache 102, and a block dispatcher 302. As an example, basic block n includes dead reckoning operation n. As another example, basic block n includes operations from display device 410 ( Figure 4B The operation n of the crosshair bouncing back at the edge of the display screen. An example of block interface 1022 is an ASIC, or PLD, or microprocessor, or microcontroller, or computer program, or part of a computer program. Block interface 1022 is coupled to cache 102.

[0172] Block interface 1022 provides the user with access to one or more of the basic blocks 1 to n stored in cache 102. For example, the user selects one or more buttons on an input device, such as a keyboard, mouse, or numeric keypad, to generate modification input 1024. As an example, modification input 1024 includes one or more user instructions in the form of source code for modifying basic block n. For illustration, modification input 1024 includes user instructions for removing dead reckoning operation n from basic block n. As another example, modification input 1024 includes instructions to change operation n to include the following: the crosshair slides away from the edge of the display screen of display device 410 and is displayed at the opposite edge of the display screen of display device 410. The opposite edge is diagonally opposite to the edge from which the crosshair slides away.

[0173] The input device is coupled to block interface 1022. Modification input 1024 is sent from the input device to block interface 1022 to modify base block n to output the modified base block n. As an example, the modified base block n does not include dead reckoning operations. As another example, the modified base block n includes an operation n that slides the crosshairs from one edge to the opposite edge. As yet another example, the modified base block n includes an operation that calculates the number of clock cycles for the execution of operation n and stores the number in base block n. For illustration, the number of cycles is stored in the memory address of cache 102, where base block 1 is stored. In addition to executing operation n, block dispatcher 302 ( Figure 3 It also performs the operation of calculating the number of clock cycles. After performing operation n, block dispatcher 302 calculates the number of clock cycles and stores the number in basic block n.

[0174] Block creator 604 further generates values ​​in pointers within cache 102, and when user input for serving base block n is received, the pointers instruct block dispatcher 302 to execute modified base block n. When block dispatcher 302 is about to execute base block n, block dispatcher 302 accesses the pointers and executes modified base block n instead of base block n.

[0175] Figure 10C This is a diagram illustrating an implementation scheme of a system 1030 for combining basic blocks created based on subroutines and basic blocks generated based on simulation PU code instructions that call said subroutines. Block Creator 604 ( Figure 6A ) Receive user input 1, such as instructing virtual object 454 ( Figure 4BThe signal indicates a change in the position and / or orientation of the virtual object 454, which causes a disruption of the virtual object 454. Upon receiving user input 1, the basic block compiler 104 generates basic block 1 based on emulation PU code instruction 1 to serve user input 1. Emulation PU code instruction 1 includes a function call to subroutine 1. Thus, upon receiving user input 1, basic block 2 is generated by the basic block compiler 104 based on subroutine 1, which serves as an example of emulation PU code instruction 2. As an example, basic block 2 includes operation 2, which regenerates the virtual object 454 at position P1 and orientation O1.

[0176] When user input 2 is received, such as instructing virtual object 454 ( Figure 4B The block compiler 104 recognizes basic blocks 1 and 2 as serving user input 2, based on signals indicating a change in the location and / or orientation of virtual object 454 that would lead to its destruction. Following this recognition, the block creator 604 integrates (e.g., combines) basic blocks 1 and 2 into a single basic block, such as basic block 1 or basic block 2. For example, upon receiving user input 2, the destruction of virtual object 454 and its regeneration are triggered. When basic blocks 1 and 2 are combined, subroutine 1 is skipped.

[0177] Block creator 604 further generates values ​​and stores them in a pointer within cache 102. When user input is received for serving basic block 1 and basic block 2, the values ​​instruct block dispatcher 302 to execute a single basic block. When block dispatcher 302 is about 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.

[0178] Figure 10D This diagram illustrates an implementation of a system 1040 that inserts a basic block between two basic blocks. 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 including the source code defining basic block 1.1, which includes a source register address 1.1 within cache 102, a destination register address 1.1 within cache 102, and an operation 1.1 to be performed on data stored at source register address 1.1, or on destination register address 1.1, or on both source and destination register addresses 1.1. Examples of operation 1.1 include jumps, store, loads, branches, and arithmetic operations.

[0179] Modification input 1042 also includes an indication of the location of basic block 1.1 and its association with basic block 1 or 2. For example, modification input 1042 includes a signal indicating that basic block 1.1 will be inserted between basic blocks 1 and 2 in buffer 102, and a signal indicating that basic block 1.1 will be linked to basic blocks 1 and / or 2. For illustration, insertion of basic block 1.1 includes the location in buffer 102 for receiving the invalidation flag 2 of basic block 2, such as one or more register addresses. As another illustration, insertion of basic block 1.1 includes the location for receiving the execution loop number of basic block 2, such as one or more register addresses in buffer 102. In this illustration, block interface 1022 receives modification input 1042, recognizes from modification input 1042 that basic block 1.1 will be inserted between basic blocks 1 and 2, and inserts basic block 1.1 between basic blocks 1 and 2. As another illustration, block interface 1022 determines that basic block 1.1 includes operations for unlocking levels in a traditional game N with the game name GN. The level is located between the first level identified in the operation of basic block 1 and the second level identified in the operation of basic block 2. The first and second levels are within a traditional game N with the game name GN. The level inserted between the first and second levels is not part of the game code gcN, but rather a new level in the traditional game N. An example of a level inserted between the first and second levels is a level where virtual object 454 fires a laser gun instead of missiles.

[0180] Furthermore, block interface 1022 identifies the value of the pointer from modification input 1042 and stores the value in cache 102. As an example, the pointer value indicates that execution of basic block 1.1 occurs immediately before execution of basic block 2. When block dispatcher 302 executes basic block 2, block dispatcher 302 identifies the value in the pointer as pointing to basic block 1.1 and executes basic block 1.1 immediately before executing basic block 2. As another example, the pointer value indicates that execution of basic block 1.1 occurs immediately after execution of basic block 2. After block dispatcher 302 executes basic block 2, block dispatcher 302 identifies the value in the pointer as pointing to basic block 1.1 and executes basic block 1.1 immediately after executing basic block 2.

[0181] Figure 10E This is a diagram illustrating an implementation of a system 1050 for switching the execution order of basic blocks. System 1050 includes a cache 102 and a block interface 1022. The cache 102 contains a value within a pointer indicating that basic block 2 should be executed after basic block 1. A user provides a modification input 1052 using an input device, the modification input including a signal indicating a switch in the execution order of basic blocks 1 and 2. Upon receiving the signal, the block interface 1022 changes the value of the pointer in the cache 102 to indicate that basic block 1 should be executed after basic block 2.

[0182] Figure 11A This is a flowchart illustrating an implementation of method 1100 using the actual count of the loop number stored in the basic block n. Method 1100 includes performing operation 662 on the basic block n. In operation 1102 of method 1100, the block dispatcher 302 ( Figure 3 In operation 662, the number of execution loops for basic block n is counted 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 dispatcher 302 writes the actual count to a register having the address of one of the registers assigned to basic block n within cache 102.

[0183] In operation 1106 of method 1100, block creator 604 ( Figure 6A The block creator 604 determines whether the same basic block n will be executed again. For example, the block creator 604 determines whether user input for serving the same basic block n has been received from the client device. The block creator 604 continues to determine whether user input for serving the same basic block n has been received until user input is received.

[0184] Figure 11B yes Figure 11A The following is a continuation of the flowchart for method 1100. After determining that user input for serving basic block n has been received again, block dispatcher 304 executes basic block n again. In operation 1108 of method 1100, block dispatcher 304 counts the execution loop number of basic block n in operation 1106 to calculate a second count.

[0185] 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 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 block dispatcher 304 is located at game console 402 (… Figure 4A When the game console is 402, the GPU is 924 ( Figure 9B ) on the display device 410 of the client device ( Figure 4A The notification is displayed on the device and sent to the server system 404 via computer network 408 to notify the server system 404. As another example, when the block dispatcher 304 is located on the server system 404... Figure 4BWhen the count is within a certain range, block dispatcher 304 generates a notification, and the GPU of server system 404 displays a representation of the notification on a display device coupled to server system 404. On the other hand, in operation 1112 of method 1100, if it is determined that the second count is within a predetermined limit relative to the first count, block dispatcher 304 does not trigger a notification.

[0186] Figure 12 This diagram illustrates an implementation scheme of system 1200 for transferring basic blocks 1 to n from a first client device to a second client device. System 1200 includes a game console 402, a computer network 408, a server system 404, game console 1202, and a display device 1204. Game console 1202 is similar to game console 402. For example, both game console 402 and 1202 are PS4. TM Or, game consoles 402 and 1202 are both PS5. TM Or, the game console error 402 is for PS4. TM The game console 1202 is for PS5. TM Or, the game console error 402 is for PS5. TM The game console 1202 is a PS4. TM As another example, the game console 1202 is not a traditional machine. Furthermore, the display device 1204 is similar to... Figure 4A The display device 410 is, for example, an HMD, a television, a smart TV, or a computer monitor.

[0187] The game console 402 includes a network interface controller 1212. The 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 architecture and functionality as the emulation processor system 409. Furthermore, the cache 1208 has the same architecture and functionality as the cache 102. The emulation processor system 1206, the cache 1208, and the network interface controller 1210 are coupled to each other via a bus 1218.

[0188] Once basic blocks 1 to n are stored in cache 102, the basic block compiler 104 of the emulation processor system 409 sends basic blocks 1 to n to the network interface controller 1212. The network interface controller 1212 applies a network communication protocol to basic blocks 1 to n to generate one or more packets embedding basic blocks 1 to n, and sends these packets to the server system 404 via computer network 408. Upon receiving the one or more data packets, the network interface controller of the server system 404 applies a network communication protocol to the packets to extract basic blocks 1 to n of a traditional game N with a game name GN, and stores the basic blocks 1 to n in one or more memory devices of the server system 404.

[0189] User 2 uses handheld controller 1212 to select one or more buttons on the handheld controller 1212 to log in to his / her user account assigned to him / her by server system 404. When user ID2 and password are authenticated by server system 404, user 2 logs in to his / her user account. Once user 2 is logged in to his / her user account, user 2 can access multiple game names, such as game name G1, game name Ga, game name G2, etc., up to game name GN.

[0190] After logging into user account 2, user 2 uses handheld controller 1212 to select one or more buttons on the handheld controller 1212 to generate user input 1214. User input 1214 is generated after selecting a traditional game N with the name GN displayed on display device 1204. When user input 1214 is generated, cache 1208 does not include basic blocks 1 to n. For example, after receiving user input 1214, the basic block compiler of emulation processor system 1206 checks cache 102 to determine whether cache 102 includes one or more of the basic blocks 1 to n of the game code GCN used to serve user input 1214. After determining that cache 102 does not include one or more of the basic blocks 1 to n used to serve user input 1214, emulation processor system 1206 generates a request 1220 for one or more of the basic blocks 1 to n and sends request 1220 to network interface controller 1210.

[0191] Upon receiving request 1220, network interface controller 1210 generates one or more packets embedding request 1220 by applying a network communication protocol to request 1220, and sends the one or more packets to server system 404 via computer network 408. The network interface controller of server system 404 receives the one or more packets and applies the network communication protocol to extract request 1220 from the one or more packets. The processor of server system 404 analyzes request 1220 to identify that basic blocks 1 to n have been requested.

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

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

[0194] When user input 1224 is received from the handheld controller 1212 during a game with the game name GN on the toy, the basic block compiler of the emulation processor system 1206 identifies one or more basic blocks from basic blocks 1 to n in cache 1208 for serving user input 1224. The block dispatcher of the emulation processor system 1206 executes one or more of basic blocks 1 to n to serve user input 1224. In this way, once basic blocks 1 to n have been compiled by the emulation processor system 409, basic blocks 1 to n do not need to be compiled by the emulation processor system 1206, but can be accessed by the emulation processor system 1206 from the server system 404.

[0195] Figure 13 This is a flowchart conceptually illustrating various operations performed according to an implementation of this disclosure for streaming a cloud video game to a client device. Examples of client devices include game controllers, smartphones, game consoles, and computers. Game server 1302 executes game program 458 ( Figure 4B ), such as video games, and generate raw (uncompressed) video 1304 and audio 1306. Virtual environment 452 ( Figure 4AThe audio output during the rendering of the virtual environment 452 is an example of video 1004 and audio 1306. Game server 1302 is server system 404 ( Figure 4A Examples of video and audio streams are shown. Video 1304 and audio 1306 are captured and encoded for streaming purposes, as indicated by reference numeral 1308 in the illustrated figure. Encoding provides compression of the 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.

[0196] The encoded audio 1310 and encoded video 1312 are further packetized into network packets, as indicated by reference numeral 1314, for transmission over computer network 1320, which is computer network 408. Figure 4A Examples are provided. In some implementations, 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.

[0197] The game server 1302 also generates haptic feedback data 1322, which is also packetized into network packets for network transmission. In the described implementation, haptic feedback packets 1324 are generated for transmission via computer network 1320.

[0198] The aforementioned operations of generating raw video, audio, and haptic feedback data are performed on the game server 1302 in 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, the audio, video, and haptic feedback packets are transmitted via computer network 1320. As indicated by reference numeral 1326, audio packets 1316, video packets 1318, and haptic feedback packets 1324 are fragmented, for example, parsed, etc., by a client device to extract encoded audio 1328, encoded video 1330, and haptic feedback data 1322 from the network packets at the client device. If the data has been encrypted, it is also decrypted. Then, as indicated by reference numeral 1334, the client device decodes the encoded audio 1328 and encoded video 1330 to generate raw audio and video data on the client side for rendering on the display device 1340 of the client device. The haptic feedback data 1322 is processed by the processor of the client device to generate a haptic feedback effect at the controller device 1324 or other interface device (e.g., HMD, etc.) where the haptic effect can be rendered. The controller device 1324 is an example of a handheld controller of the client device. An example of a haptic effect is the vibration or rumble of the controller device 1324.

[0199] It will be understood that video games respond to player input and thus execute a program flow similar to the transmission and processing of player input described above, but in the opposite direction from the client device to the server. As shown, controller device 1324 or another input component (e.g., a body part of user 1) or a combination thereof generates input data 1348. Input data 1348 is packetized at the client device for transport over computer network 1320 to the data center. Input data packets 1346 are broken down and reassembled by game server 1302 to define input data 1348 on the data center side. Input data 1348 is fed to game server 1302, which processes input data 1348 to generate the game state of a traditional game N.

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

[0201] Figure 14It is used to interface with a display device of a client device and can be connected via a computer network 1320 ( Figure 13 ) and game console systems (such as server systems 404 ( Figure 4A A block diagram of an implementation scheme for a compatible game console 1400 with communication capabilities. Game console 1400 is a game console 402 ( Figure 4A Example of a game console 1400. The game console 1400 is located within a data center or at the location of a player, such as user 1 or 2. In some implementations, the game console 1400 is used to execute a game displayed on an HMD. The game console 1400 has various peripheral devices that can be connected to it. The game console 1400 has a unit processor 1428, a dynamic random access memory (XDRAM) unit 1426, a reality 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-ray... A disc-only memory (BD-ROM) optical disc reader 1440 is included for reading from a disc 1440a and a removable slot-loading hard disk drive (HDD) 1436 accessible via I / O bridge 1434. Optionally, the game console 1400 also includes a memory card reader 1438 for reading compact flash memory cards, memory cards, etc., accessible similarly via I / O bridge 1434. Memory cards, etc. The I / O bridge 1434 also connects to a USB 2.0 port 1424, a Gigabit Ethernet port 1422, and an IEEE 802.11b / g wireless network (Wi-Fi). TM Port 1420, and supports Bluetooth connectivity. Wireless connection port 1418.

[0202] In operation, 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 traditional game N generated by executing a portion of game code such as game code GCN, I / O bridge 1434 receives data from the game controller 1342 via a Bluetooth link. Figure 13 The system receives input data or input signals as described herein from HMD 1403 and / or HMD 1405, and directs said input data to unit processor 1428, which updates the current state of the conventional game N accordingly. As an example, a camera within HMD 1405 captures the player's pose to generate an image representing said pose. Game controller 1342 is a handheld controller 406 ( Figure 4A Examples of ).

[0203] In addition to game controllers 1342 and 1403 and HMD 1405, wireless, USB, and Ethernet ports provide connectivity for other peripherals, such as remote control 1404, keyboard 1406, mouse 1408, and portable entertainment devices 1410 (such as Sony PlayStation). Entertainment devices, etc.), cameras (such as, Camera 1412, etc.), microphone / earphone 1414, and microphone 1415. Portable entertainment device 1410 is an example of a game controller. In some embodiments, such peripheral devices are wirelessly connected to game console 1400, for example, portable entertainment device 1410 via Wi-Fi. TM Communication is achieved via a dedicated connection, while the microphone / headset 1414 communicates via a Bluetooth link.

[0204] The availability of these interfaces means that the Game Console 1400 is also potentially compatible with other peripherals such as digital video recorders (DVRs), set-top boxes, digital cameras, portable media players, Internet Protocol (IP) phones, mobile phones, printers, and scanners.

[0205] Additionally, a conventional memory card reader 1416 is connected to the game console 1400 via a USB port 1424, enabling it to read memory cards 1448 of the type used by the game console 1400. Game controllers 1342 and 1403, and HMD 1405, are operable to communicate wirelessly with the game console 1400 via a Bluetooth link 1418, or to connect to the USB port 1424, thereby also receiving power to charge the batteries of game controllers 1342 and 1403 and HMD 1405. In some embodiments, each of 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 communication, a soundproof enclosure, a digital camera, an internal clock, a recognizable shape such as a spherical segment facing the game console 1400, and a wireless device using protocols such as Bluetooth, Wi-Fi, etc.

[0206] Game controller 642 is designed to be used by two hands by players such as player 1, 2, 3, or 4, and game controller 1403 is a one-handed controller with accessories. HMD 1405 is designed to be mounted on the player's head and / or in front of their eyes. In addition to one or more analog joysticks and conventional control buttons, each game controller 1403 is susceptible to three-dimensional position determination. Similarly, HMD 1405 is susceptible to three-dimensional position determination. Therefore, in some embodiments, as a supplement to or alternative to conventional button or joystick commands, gestures and movements of the player using game controllers 1402 and 1403, as well as HMD 1405, are translated into game input. Optionally, such as PlayStation... TM Portable devices and other wirelessly enabled peripherals are used as controllers. (In PlayStation) TM In the case of portable devices, additional game or control information, such as control commands or the number of lives, is provided on the device's display screen. In some implementations, other alternative or supplementary control devices are used, such as dance mats (not shown), light guns (not shown), steering wheels and pedals (not shown), custom controllers, etc. Examples of custom controllers include single or multiple large buttons for quick quiz games (also not shown).

[0207] The remote control 1404 can also be operated to wirelessly communicate with the game console 1400 via Bluetooth link 1418. The remote control 1404 includes components suitable for operating Blu-ray... TM The BD-ROM reader 1440 is suitable for navigation disk content control.

[0208] Blu Ray TM The 1440 BD-ROM reader is operable to read CD-ROMs compatible with the 1400 game console, in addition to regular pre-recorded and recordable CDs and so-called Super Audio CDs. TM The BD-ROM reader 1440 is also operable to read digital video disc-ROMs (DVD-ROMs) compatible with the game console 1400, in addition to regular pre-recorded and recordable DVDs. TM The BD-ROM reader 1440 is further operable to read BD-ROMs compatible with the game console 1400, as well as regular pre-recorded and recordable Blu-ray discs.

[0209] The game console 1400 is operable to supply audio and video generated or decoded via the reality synthesizer graphics unit 1430 to a display and sound output device 1442, such as a monitor or television, having a display screen 1444 and one or more loudspeakers 1446, via an audio connector 1450 and a video connector 1452, or via... Wireless link port 1418 supplies audio and video to the display device of HMD 1405. In various embodiments, audio connector 1450 includes conventional analog and digital outputs, while video connector 1452 differently includes component video, S-video, composite video, and one or more High Definition Multimedia Interface (HDMI) outputs. Therefore, video output can be in formats such as Phase-Inverted (PAL) or National Television System Committee (NTSC), or in 2220p, 1080i, or 1080p high definition. Audio processing, such as generation and decoding, is performed by unit processor 1408. The operating system of game console 1400 is supported. 5.1 surround sound Cinema surround sound (DTS) and from Decoding of 7.1 surround sound from the disc. Display and sound output device 1442 is the display device 410 ( Figure 4A Examples of ).

[0210] In some embodiments, a camera such as camera 1412 includes a single charge-coupled device (CCD), an LED indicator, and hardware-based real-time data compression and encoding equipment, such that compressed video data is transmitted in an appropriate format, such as an in-image-based Moving Picture Experts Group (MPEG) standard, for decoding by the game console 1400. The LED indicator of camera 1412 is arranged to illuminate in response to appropriate control data from the game console 1400, for example, to indicate unfavorable lighting conditions. Some embodiments of 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, images captured by the camera are incorporated into the game or decoded as game control input. In another embodiment, the camera is an infrared camera suitable for detecting infrared light.

[0211] In various implementations, in order to enable successful data communication between one of the communication ports of the game console 1400 and a peripheral device (e.g., a camera or remote control), appropriate software, such as a device driver, is provided.

[0212] In some implementations, this includes a game console 1400 and a game controller 1342. Figure 13 The aforementioned system devices, such as HMD 1403 and HMD 1405, enable HMD 1405 to display and capture video of interactive game sessions. The system device initiates an interactive game session that defines the interactivity between Player 1 and other players with the game. The system device further determines a game controller 1342 operated by a player such as Player 1, Player 2, Player 3, or Player 4. Figure 13 The initial position and orientation of game controller 642 (FIG. 6) or 1403 and / or HMD 1405 are tracked. Game console 1400 determines the current state of the game based on the interactivity between players such as player 1, player 2, player 3, or player 4 and the game. The system apparatus tracks the position and orientation of game controller 642 (FIG. 6) or 1403 and / or HMD 1405 during an interactive session between the player and the conventional game N. The system apparatus generates a viewer video stream for the interactive session based on the current state of the conventional game N and the tracked position and orientation of HHC and / or HMD 1405. In some embodiments, HHC renders the viewer video stream on its display screen. In various embodiments, HMD 1405 renders the viewer video stream on its display screen.

[0213] refer to Figure 15 The diagram shows the components of the HMD 1502. The HMD 1502 is an improvement upon the HMD 1405. Figure 14 Examples of HMD 1502 include a processor 1500 for executing program instructions. A memory device 1502 is provided for storage purposes. Examples of memory devices 1502 include volatile memory, non-volatile memory, or combinations thereof. A display device 1504 is included, which provides a visual interface for the player to view, such as a display of image frames generated from saved data, etc. A battery 1506 is provided as a power source for HMD 1502. The motion detection module 1508 includes any of various motion-sensitive hardware (e.g., a magnetometer 1510, an accelerometer 1512, and a gyroscope 1514).

[0214] An accelerometer is a device used to measure acceleration and the reaction force induced by gravity. The magnitude and direction of acceleration in different directions can be detected using single-axis and multi-axis models. Accelerometers are used to sense tilt, vibration, and shock. In one embodiment, three accelerometers 1512 are used to provide the direction of gravity, giving an absolute reference to two angles, such as world space pitch and world space roll.

[0215] Magnetometers measure the strength and direction of the magnetic field near HMD 1502. In some embodiments, three magnetometers 1510 are used within HMD 1502 to ensure an absolute reference for the yaw angle in world space. In various embodiments, the magnetometers are designed to span the Earth's magnetic field, which is ±80 microtesla. Magnetometers are affected by metals and provide yaw measurements that are monotonic with actual yaw. In some embodiments, the magnetic field is distorted due to metals in the real-world environment, resulting in a distortion in the yaw measurement results. In various embodiments, this distortion is calibrated using information from other sensors, such as gyroscope 1514, camera 1516, etc. In one embodiment, accelerometer 1512 is used together with magnetometer 1510 to obtain the tilt and azimuth angles of HMD 1502.

[0216] A gyroscope is a device used to measure or maintain orientation based on the principle of angular momentum. In one embodiment, as an alternative to gyroscope 1514, three gyroscopes provide information about movement across corresponding axes (x, y, and z) based on inertial sensing. Gyroscopes help detect rapid rotation. However, in some embodiments, the gyroscopes drift over time in the absence of an absolute reference. This triggers periodic resetting of the gyroscopes, which can be done using other available information such as position / orientation determination based on visual tracking of the object, accelerometers, magnetometers, etc.

[0217] A camera 1516 is provided to capture images and image streams of the real-world environment surrounding the player (e.g., a room, a vehicle, a natural environment, etc.). In various embodiments, the HMD 1502 includes more than one camera, including: a rear-facing camera that faces away from the player when the player views the display of the HMD 1502; and a front-facing camera, for example, that points towards the player when the player views the display of the HMD 1502. Additionally, in several embodiments, the HMD 1502 includes a depth camera 1518 to sense depth information of objects in the real-world environment.

[0218] The HMD 1502 includes a speaker 1520 for providing audio output. Furthermore, in some embodiments, a microphone 1522 is included to capture audio from the real-world environment, including sounds from the surrounding environment and voices made by the player. The HMD 1502 includes a haptic feedback module 1524, such as a vibration device, to provide haptic feedback to the player. In one embodiment, the haptic feedback module 1524 is capable of causing movement and / or vibration of the HMD 1502 to provide haptic feedback to the player.

[0219] An LED 1526 is provided as a visual indicator of the status of the HMD 1502. For example, the LED may indicate battery level, 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. A USB interface 1530 is included as an example of an interface for enabling connectivity to peripheral devices or to other devices (such as other portable devices, computers, etc.). In various embodiments of the HMD 1502, any of a variety of interfaces may be included to enable greater connectivity for the HMD 1502.

[0220] Including Wi-Fi TM Module 1532 enables internet connectivity via wireless networking technology. Furthermore, HMD1502 includes Bluetooth. TM Module 1534 enables wireless connectivity to other devices. In some embodiments, a communication link 1536 is also included for connecting to other devices. In one embodiment, the communication link 1536 utilizes infrared transmission for wireless communication. In other embodiments, the communication link 1536 utilizes any of a variety of wireless or wired transmission protocols to communicate with other devices.

[0221] Input buttons / sensors 1538 are included to provide an input interface for the player. This includes any of various types of input interfaces, such as buttons, touchpads, joysticks, trackballs, etc. In various embodiments, the HMD 1502 includes an ultrasonic communication module 1540 to facilitate communication with other devices via ultrasonic technology.

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

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

[0224] Figure 16 This describes an implementation scheme for an Information Service Provider (INSP) architecture. INSP 1602 delivers numerous information services to geographically dispersed players connected via computer network 1606 (e.g., LAN, WAN, or a combination thereof). Computer network 1606 is a subset of computer network 1320 (…). Figure 13Examples 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.

[0225] In some implementations, each client device 1620-1, 1620-2, and 1620-3 includes a central processing unit (CPU), a display, and input / output (I / O) interfaces. 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, etc. Figure 15 This includes game consoles 1400 and HMD 1502, desktop computers, laptops, and smart TVs. In some implementations, INSP 1602 identifies the type of client device and adjusts the communication method accordingly.

[0226] In some implementations, INSP 1602 delivers one type of service, such as stock price updates, or may deliver multiple services, such as broadcast media, news, sports, games, etc. Furthermore, the services provided by each INSP are dynamic; that is, services can be added or removed at any time. Therefore, an INSP providing a specific type of service to a particular individual can change over time. For example, when client device 1620-1 is in user 1's hometown, it is served by an INSP near user 1620-1, and when user 1 travels to different cities, it is served by different INSPs. The hometown INSP will pass the requested information and data to the new INSP, causing the information to "follow" user 1620-1 to the new city, thus bringing the data closer to user 1620-1 and making it easier to access. In various implementations, a master-server relationship is established between a master INSP that manages information about client device 1620-1 and a server INSP, the server INSP directly interfacing with client device 1620-1 under the control of the master INSP. In some implementations, when client device 1620-1 moves around the world, data is transferred from one ISP to another, so that an INSP serving client device 1620-1 in a better location is the INSP that delivers these services.

[0227] INSP 1602 includes an Application Service Provider (ASP) 1608 that provides computer-based services to customers via a computer network 1606. Software provided using the ASP model is sometimes also referred to as software-on-demand 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 Hypertext Transfer Protocol (HTTP). The application software resides on the vendor's server and is accessed by each client device 1620-1, 1620-2, and 1620-3 via a web browser using Hypertext Markup Language (HTML), etc., through dedicated client software provided by the vendor and / or other remote interfaces such as thin clients.

[0228] Services delivered over vast geographical areas often utilize cloud computing. Cloud computing is a computing approach in which dynamically scalable and often virtualized resources are provided as a service via a computer network 1606. Users 1 to 3 do not need to be experts in the technical infrastructure supporting their “cloud.” In some implementations, 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 are often provided online for ordinary business applications accessed from a web browser, while software and data are stored on servers. Based on how a computer network 1606 is depicted in a computer network diagram, the term cloud is used as a metaphor for a computer network 1606 that uses, for example, servers, storage devices, and logic, and is an abstraction of its hidden, complex infrastructure.

[0229] Furthermore, INSP 1602 includes a Game Processing Provider (GPP) 1610, 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-player and multiplayer video games. Most video games played on computer network 1606 are operated via a connection to the game server. Typically, games use a dedicated server application that collects data from client devices 1620-1, 1620-2, and 1620-3 and distributes that 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, GPP 1610 establishes communication between client devices 1620-1, 1620-2, and 1620-3, which exchange information without further reliance on a centralized GPP 1610.

[0230] Dedicated GPS servers are servers that operate independently of the client. These servers typically run on dedicated hardware located in data centers, providing greater bandwidth and dedicated processing power. Dedicated servers are the method used to control game servers for most PC-based multiplayer games. Many multiplayer online games run on dedicated servers, often hosted by the software company that owns the game's title, allowing them to control and update content.

[0231] The broadcast processing server (BPS) 1612, sometimes referred to herein as a broadcast processing provider, distributes audio or video signals to an audience. Broadcasting to a very small audience is sometimes called narrowcasting. The final stage of broadcast distribution is how the signal reaches the client devices 1620-1, 1620-2, and 1620-3, and in some embodiments, the signal is distributed wirelessly to antennas and receivers, just like a radio or television station, or via cable or wired broadcasting. 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 that shares signals and bandwidth. Historically, in some embodiments, broadcasting was defined by geographical regions, such as national broadcasting, local broadcasting, etc. However, with the widespread availability of high-speed internet, broadcasting is no longer geographically limited because content can reach virtually any country in the world.

[0232] Storage service provider (SSP) 1614 provides computer storage space and related management services. SSP 1614 also provides periodic backups and archiving. By providing storage as a service, client devices 1620-1, 1620-2, and 1620-3 utilize more storage compared to when storage is not used as a service. Another key advantage is that SSP 1614 includes backup services, and client devices 1620-1, 1620-2, and 1620-3 will not lose data in the event of hard drive failure. Furthermore, in some implementations, multiple SSPs have all or part of the data received from client devices 1620-1, 1620-2, and 1620-3, thereby allowing client devices 1620-1, 1620-2, and 1620-3 to access data efficiently, independent of the location of client devices 1620-1, 1620-2, and 1620-3 or the type of client. For example, while the player is on the move, the player accesses personal files via a home computer and via a mobile phone.

[0233] Communication provider 1616 provides connectivity to client devices 1620-1, 1620-2, and 1620-3. One type of communication provider 1616 is an Internet Service Provider (ISP), which provides access to computer network 1606. The ISP uses 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) to connect client devices 1620-1, 1620-2, and 1620-3. In some embodiments, communication provider 1616 also provides messaging services such as email, instant messaging, and short message service (SMS) text messaging. Another type of communication provider is a Network Service Provider (NSP), which sells bandwidth or network access by providing direct backbone access to 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, etc.

[0234] Data switch 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 implementations, data switch 1618 covers a small area where all modules of INSP 1602 are closely located, or a larger geographical area when the different modules are geographically dispersed. For example, data switch 1602 includes Fast Gigabit Ethernet within a data center rack, or an intercontinental virtual LAN.

[0235] In some implementations, wireless technology can be used to facilitate server system 404 ( Figure 4A Communication between client devices 1620-1 to 1620-3. This technology may include, for example, 5G wireless communication technology.

[0236] In one implementation, a video game, such as the conventional game N described herein, is executed locally on a game console, a personal computer, or on a server. In some cases, the video game is executed by one or more servers in a data center. When a video game is executed, some instances of the video game can be simulations of the video game. For example, the video game can be executed by an environment or server that generates a simulation of the video game. In some implementations, the simulation is an instance of the video game. In other implementations, the simulation can be generated by an emulator. In either case, if the video game is represented as a simulation, it is possible to execute the simulation to render interactive content that can be interactively streamed, executed, and / or controlled by user input.

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

[0238] Various computer system configurations can be used to implement the embodiments described in this disclosure, including handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc. In one implementation, the embodiments described in this disclosure can be implemented in a distributed computing environment, wherein tasks are performed via remote processing devices through wire-based or wireless network links.

[0239] Having understood the above embodiments, it should be understood that in one implementation, the embodiments described in this disclosure employ various computer-implemented operations involving data stored in a computer system. These operations are operations requiring physical manipulation 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 means or apparatus for performing these operations. The apparatus is specifically configured for the desired purpose, or the apparatus is a general-purpose computer selectively activated or configured by a computer program stored in the computer. Specifically, in one embodiment, it may be more convenient to use various general-purpose machines with computer programs written in accordance with the teachings of this document, or to construct more specialized equipment to perform the desired operations.

[0240] In one implementation, some embodiments described in this disclosure are embodied as computer-readable code on a computer-readable medium. A computer-readable medium is any data storage device that stores data, which is subsequently read by a computer system. Examples of computer-readable media include hard disk drives, network attached storage (NAS), ROM, RAM, CD-ROM, recordable CD (CD-R), rewritable CD (CD-RW), magnetic tape, optical data storage devices, non-optical data storage devices, etc. As an example, a computer-readable medium includes computer-readable tangible media distributed across a network-coupled computer system, such that the computer-readable code is stored and executed in a distributed manner.

[0241] Furthermore, although some implementation schemes of the above-described solutions are described regarding the gaming environment, other environments, such as video conferencing environments, are used instead of gaming environments in some implementation schemes.

[0242] Although the method operations are described in a specific order, it should be understood that other housekeeping operations may be performed between operations, or operations may be adjusted so that they occur at slightly different times, or they may be distributed throughout the system. This allows processing operations to occur at various intervals associated with processing, as long as the processing of the overriding operation is performed in the desired manner.

[0243] While the foregoing embodiments described in this disclosure have been described in some detail for clarity of understanding, it will be understood that certain changes and modifications may be practiced within the scope of the appended claims. Therefore, these embodiments are to be regarded as illustrative rather than restrictive, and are not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for promoting the playing of traditional games, the method comprising: Receive user input during the playing of the traditional game; Determine whether one or more code blocks used to serve the user input are cached; One or more instructions that access traditional game code when it is determined that the one or more code blocks are not cached; Compile the one or more code blocks of the one or more instructions from the conventional game code; Cache the one or more code blocks; as well as Execute the one or more code blocks to display the virtual environment.

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

3. The method of claim 1, wherein the compilation 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 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.

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

6. The method of claim 1, further comprising: The instructions for determining that the traditional game code has been compiled; The legacy game code is deleted in response to the instruction that determines the legacy game code has been compiled.

7. The method of claim 1, further comprising: Determine whether to access the legacy game code within a predetermined time period starting from the latest time since the legacy machine accessed the legacy game code; The legacy game code is deleted in response to the determination that the legacy game code has not been accessed within the predetermined time period from the latest time when the legacy game code was accessed from the legacy machine.

8. The method of claim 1, further comprising: A first verification result is generated from the one or more instructions during the compilation of the one or more code blocks; Check 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; Determine whether to execute the one or more code blocks; When it is determined that the one or more code blocks will be executed, it is determined whether the one or more code blocks are marked as invalid; When it is determined that the one or more code blocks are marked as invalid, the one or more memory addresses are checked to generate a second verification result from the one or more instructions stored at the one or more memory addresses; The first verification result is compared with the second verification result to determine whether the one or more code blocks are invalid; If the one or more code blocks are determined to be invalid, recompile the one or more additional code blocks associated with the one or more instructions; Execute the one or more additional code blocks to display the additional virtual environment.

9. The method of claim 1, wherein the conventional game code cannot be executed in a first game console including a 64-bit processor, but can be executed in a second game console including 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 the playing of traditional games, the computing device comprising: A processor configured to receive user input during the playing of the conventional game; as well as A cache, which is coupled to the processor; as well as A memory device coupled to the processor. The processor is configured to determine whether one or more blocks of code used to serve the user input are stored in the cache. The processor is configured to access one or more instructions from the memory device for conventional game code when it is determined that the one or more code blocks are not stored in the cache. The processor is configured to compile the one or more code blocks of the one or more instructions from the conventional game code. The processor is configured to store the one or more code blocks in the cache, and The processor is configured to execute the one or more blocks of code to display a virtual environment.

12. The computing device of claim 11, wherein each of the one or more code blocks includes a source register address, an operation, and a destination register address, wherein when 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 conventional game code to identify the one or more instructions of the conventional game code.

14. The computing device of claim 11, wherein the processor is configured to perform the following operations: A first verification result is generated from the one or more instructions during the compilation of the one or more code blocks; Check 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; Determine whether to execute the one or more code blocks; When it is determined that the one or more code blocks will be executed, it is determined whether the one or more code blocks are marked as invalid; Check the one or more memory addresses to generate a second verification result from the one or more instructions; The first verification result is compared with the second verification result to determine whether the one or more code blocks are invalid; If the one or more code blocks are determined to be invalid, recompile the one or more additional code blocks associated with the one or more instructions; Execute the one or more additional code blocks to display the additional virtual environment.

15. The computing device of claim 11, wherein the processor is a 64-bit processor, and wherein the conventional game code cannot be executed by the processor but can be executed in a computing device including a 32-bit processor.

16. A method, the method comprising: A first verification result is generated from one or more instructions in conventional game code, wherein the one or more instructions in conventional game code are associated with one or more code blocks; Check 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; Determine whether to execute the one or more code blocks; When it is determined that the one or more code blocks will be executed, it is determined whether the one or more code blocks are marked as invalid; Check the one or more memory addresses to generate a second verification result from the one or more instructions; The first verification result is compared with the second verification result to determine whether the one or more code blocks are invalid; as well as If the one or more code blocks are determined to be invalid, recompile the one or more additional code blocks associated with the one or more instructions; as well as Execute the one or more additional code blocks 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 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 conventional game code is not executable in a first game console including a 64-bit processor, but is executable in a second game console including 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.

Images