JPH08130728A - Hotel corresponding type video game and communication system - Google Patents

Abstract

PURPOSE: To provide a communication system by which a visitor can join a video game and can use other data processing/communication service. CONSTITUTION: A host computer 7 stores the video game and the other application program in a hard disk 7A and down-loads the program on the array 11 of an SNES engine in response to the selection of the visitor. Respective guest room terminals 2 are connected to guest room televisions 1 and video game controllers 3. When the menu key of the game controller is depressed, the down loading of the application program on the array 11 of the SNES engine is started. The application program which is down loaded generates a display menu to the television 1 of the visitor. The visitor can select data from the various operation modes of a movie, the game and shopping.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION This invention relates generally to digital communications and entertainment / video game systems. More specifically, the present invention relates to hotel (or cruise ship) enabled video games and communication systems, some of which are carried out in each cabin.

[0002]

Prior to the present invention, hotels provide, to a limited extent, in-room entertainment services. Such services typically include cable television enabled systems in which guests choose Home Box Office (HBO) type movies and entertainment channels for free or for a paid program viewing service. Such program pay viewing systems conventionally include generating a menu screen for selecting one of a user's desired program pay viewing options, eg, a limited number of recently released movies. I was there.

In another example, a program pay-per-view service is extended to create a communication link connecting rooms within a hotel (or between rooms at different hotels) to allow guests to play a trivia-type game. I was able to do that. Such a system responds to guest input by
It operates via a television-type remote controller and uses satellite and / or telephone communication links.

[0004]

In such a hotel-oriented entertainment system, the range of entertainment services provided is very limited. For example, in such a system, a complex video game, such as the Super Nintendo Entertainment System (SNES) ® marketed by Applicant, that rapidly creates flying moving objects and background characters. However, each guest cannot do it.

The present invention is directed to a video game / communication system in which guests can actively participate in video game play or use other data processing / communication services.

[0006]

SUMMARY OF THE INVENTION In an embodiment of the present invention, a multi-tasking master host computer, preferably one having video games and other application programs stored on its hard disk, is a guest computer. In response to the selection, S
Download to NES Gameplay Engine Array. Each hotel guest room includes a terminal device, which is a color television in the guest room and (in an example, a modified version of the SNES game controller available on the market,
Connected to a game controller (including a game reset key, a menu key, and a volume related key).

By depressing the menu key of the game controller, the guest can make the host computer install the application software in the hotel.
Start downloading to the NES engine.
The downloaded application program creates a display menu that appears on the television in the guest room. According to a preferred embodiment of the present invention, the display menu allows each guest to include movies, games, shopping, questionnaires, language selection, communication / data processing services, etc. (eg, identified by the displayed icon). It is convenient because it can be selected from various operation modes. When the user selects video game play, the title and / or description of the executable game is displayed.

When the host computer of the hotel enabled headend station receives the guest's game selection, the game program is typically stored from its hard disk into one of the banks of SNES gameplay engines also located at the headend station. It The exact number of gameplay engines built into the system will depend on the number of guest rooms in the hotel and how the system is used, but it is desirable in this case to have about eight SNES gameplay engines installed per 200 guest rooms.

According to an embodiment of the present invention, the host computer assigns time slots to guest room terminals and SNES gameplay engines for passing gameplay instruction keystrokes from the guest room game controller to the SNES engine. The cabin terminal samples the keystrokes 60 times per second for the SNES game controller. The keystroke data can be
It is passed to the bank of SNES engines via an interface that includes an RF modem.

The audio and video outputs from each SNES engine are input to a channel modulator which RF-converts the composite signal at the assigned frequency.
Position within a distributed system. The assignment is communicated to each cabin terminal during the first interactive session, which
The cabin terminal tunes the television to the appropriate channel for the assigned SNES engine.

Once the gameplay begins, each guest using the system will be as if each SNES were directly connected to the guest room TV as in a conventional home system.
Operate the SNES game controller. When the play time of the guest expires, the host computer can instruct the guest room terminal to stop the game execution and display the menu, and purchase more game execution time if the guest desires. To do so.

The above and other features and advantages of the present invention, as well as the manner of carrying out the same, shall refer to the following detailed description and appended claims, taken in conjunction with the accompanying drawings, which illustrate several embodiments of the invention. It will be clearer and the invention itself will be better understood.

[0013]

1 is a block diagram of an example of a hotel-enabled video game / communication system according to an embodiment of the present invention. Although the preferred embodiment of the invention herein is shown in a hotel, the communication system described herein is also suitable for use in many other environments, such as ocean liners, hospitals, office buildings and the like. It is supposed to be possible. As used herein, "hotel" is
It should be broadly construed to indicate a hotel, motel, hospital or other similar facility accommodating a large number of guests.

The hotel-based system of FIG. 1 includes a host computer 7. The host computer 7 may be a multi-tasking computer, for example an IBM386 computer running the interactive UNIX operating system. The host computer 7 includes a conventional communication board 9, which may be, for example, SEAL.
EVEL Advanced Communication Board (ACB-2) Part No. 306
1B may be used, and the synchronous data link control data (S
DLC) to communicate with the other processing modules shown in FIG. Host computer 7 preferably stores video games and other programs in memory 7A, which may include a hard disk memory system. Video games and other programs, if desired, are downloaded to the array 11 (1 to N) of the SNES engine via the data link at a baud rate of, for example, 408 kilobytes per second. The details of the embodiments shown herein, such as baud rates and example components, are for illustration purposes only and should not be construed as limiting the invention.

The host computer 7 transmits data to each guest room terminal 2 of the hotel via a host SNES array interface, which includes an RF modem 5, as described in detail below. , The RF modem 5 modulates the received signal and inputs it into the appropriate cabin terminal 2 on the appropriate data channel for the cabin terminal. The output of the RF modem 5 is input to the guest room terminal 2 via the mixer 4, and the mixer 4 outputs the composite R
The F signal is input to the cabin terminal 2. The cabin terminal 2 is connected to the tuner of the cabin television (1) and receives the composite signal to tune the television to the appropriate channel.

The guest room terminal 2 is also connected to the video game controller 3. According to the present embodiment, the game controller 3 has a normal key control switch found in commercially available SNES controllers and keys, a reset key (may also serve as an instruction key when selecting a menu), and a menu. A key and a volume control key are included.

Returning to the host SNES interface (shown in FIG. 1) for more details, the cabin terminal 2 is
Data is input to the interface via the line mixer 4. The RF modem 5 receives this data and inputs the data to the microcontroller unit (MCU) 6, and the MCU 6 operates as a data indicating device that inputs the data to the host computer 7 or the array 11 of the SNES engine. To do. The MCU 6 uses the information transmitted from the guest room terminal 2 as the host computer 7 or the SN.
As the information to be processed by the ES engine 11,
Decrypt. Thereafter, the MCU 6 which gives the data instruction inputs the data to the host computer 7 via the asynchronous port 8B as appropriate, or inputs the data to one of the SNES engines (1 to N) of the array 11. . MCU input to SNES engine (1 to N)
The data output from 6 is keystroke controller data and is generated in response to the operation of the control key from the game controller 3. Such keystroke data is preferably entered into each SNES engine 1-N via a direct link (especially if eight SNES engines are used). Alternatively, conventional conventional bus links may be used.

As shown in FIG. 1, the MCU 10 includes an asynchronous port 8C of the host computer 7 and an S of the array 11.
Coupled to each of the NES engines. MCU10
Inputs a command (and related data, if any) from the host computer 7 into the running SNES engine,
Communication is thereby achieved by identifying the address of the appropriate SNES engine of array 11. MCU
Similarly, 10 receives information from the SNES engine (1 to N) (eg, in response to a command) and inputs it to the host computer 7. The SNES engine may send the command to the host computer 7 via the MCU 10. MCU 6 and MCU 10 may be conventional microprocessor-compatible controllers having multiple input / output ports.

The audio and video game related data is S
NES engine 1 to N, modulator (12 to 14)
Input through the array of. The outputs of the modulators 12 to 14 are combined, for example using the mixer 15, and input via the mixer 4 to the appropriate cabin terminal 2.

The host computer 7, SNES engine array 11 and host SNES interface may be housed in a single headend station located in a suitable room within the hotel. Alternatively, if desired, such components may be located in a variety of different locations.
The host computer 7 does not necessarily have to be installed in the hotel.

FIG. 2 is a block diagram of the passenger compartment terminal 2 shown in FIG. Guest room terminal 2 includes MCU2B, and MCU2
B may be, for example, a Hitachi H8325 microcontroller. The MCU 2B is connected to the game controller via the controller interface 2E and receives the keystroke data generated by the player. The controller interface 2E may be a conventional video game controller interface and includes a shift register compatible circuit, which temporarily stores the state of each controller switch in each shift register stage, for example, The 2-byte control data representing the state of each control key / switch of the game controller 3 received at each parallel register input is (MCU
Serial output (for 2B).

The MCU 2B is also connected to the host data input / output line interface 2C and the keystroke interface data link 2D. Interfaces 2C and 2D are shown in FIG. 2 as separate components and as inputting data to separate data links. However, when used in the system of FIG. 1, the data outputs of the host interface 2C and the keystroke interface 2D are combined and input to the RF link of FIG. 1 connected to the cabin terminal 2. The outputs of the host interface 2C and the keystroke interface 2D are divided and output to the host computer 7 or the SNES engine array 11 via the MCU 6 as described above with reference to FIG. The MCU 2B is further connected to a tuner controller 2A that tunes the TV tuner 16 of the TV 1 to the appropriate data channel. The RF video input from the RF data link shown in FIG. 1 is also input to the television tuner 16.

FIG. 3 is a flow chart showing the sequence of processing performed by the MCU 2B shown in FIG. After performing the conventional initialization process, the MCU 2B software of the cabin terminal polls the game controller 3 (for example, once every 1 / 60th of a second) to determine whether the player has pressed any key ( 17). The MCU 2B then receives (18) any possible game controller bytes via the controller interface 2E. Upon receipt of the byte, the data is checked to determine if a command such as a reset command has been received (19). The command may be detected, for example, by monitoring a predetermined bit position in the 2-byte data stream received from the game controller 3. For example, if the thirteenth bit position is the logic level "1", the MCU 2B determines that the reset command is input by the player.
When such a command is recognized in block 19, the MCU 2B converts the identified command into a predetermined command byte format and sends the command to the SNES array 11 via the MCU 6 and the keystroke link described above. Enter.

If at block 19 it is determined that no command was generated, but a normal controller data byte was generated, the byte is saved until the cabin terminal 2 is polled by the host computer 7 at block 21. It If polling by the host computer did not occur, then at block 22 whether a tuner command was received from the host computer 7 (ie, did it lead to a channel change).
A check is made to determine If there is no tuner command from the host computer, the process branches to block 21 until either a polling by the host computer or a tuner command occurs.
Checks will continue.

Upon detection of polling by the host computer at block 21, the MCU 2B sends a controller data byte or command byte on the keystroke link to the SNES engine array 11 (2
4). Although the command bytes from the MCU 2B have been described as being transferred to the SNES, such commands may instead be transferred to the host computer. After sending such a controller data byte or command byte, the routine branches back to block 17 to continue game controller polling. If the check in block 22 reveals that a tuner command has been received from the host computer,
Tuner commands are sent to the tuner for proper operation,
For example, the channel is changed (23), and the process is block 1
The process branches to 7 and the polling of the game controller 3 continues.

FIG. 4 is a diagram schematically showing the overall processing of the embodiment of the present invention. As shown in FIG.
Immediately after (00), the initialization sequence is executed (100
3). Array 11 of each SNES engine during initialization
Performs each initialization routine during which various parameters are set to appropriate default values and the serial port is initialized to the correct baud rate. Further, if desired, the version identification number associated with the boot program executed on each SNES may be the MCU 19 of FIG.
0 may be transferred. The MCU (190) is preferably implemented on the memory board 102 (see FIG. 36) of each SNES engine to receive the version identification number and perform input / output interface functions for the memory board 102. The host computer 7 also performs conventional initialization functions including polling of cabin terminals.

After initialization (1003), application software is downloaded to the SNES engine. The download starts in response to a download request (for example, selection of a menu key) from the cabin terminal 2 connected to the host computer 7 via the host SNES interface.

After receiving the download request, the host computer 7 sets up and responds with an application program transmission to generate the display menu displayed on each cabin television set. The initial download of the application program will display a menu in each guest room that initiated the request. The application program is input from the host computer 7 to each SNES engine.

In accordance with the presently preferred embodiment of the present invention, the display menu allows the user to select between various operating modes. The operation modes include movie 1009, game 1015, and shopping 10.
23, survey form 1025, language selection 1027, communication / data processing service 1035. First, a message prompting the user to select a language is displayed (10
27), the user is English 1029, German 1031,
Select from Japanese 1033, etc. By this language selection, for example, the language used when a movie or the like is selected later is determined.

In an embodiment of the present invention, an icon is displayed on the screen to allow the user to select any one of the different operating modes. Movie option (10
If 09) is selected, then a check is made to see if the movie is provided in the appropriate language (1011). The channels are then switched (1013) to receive the selected movie via an associated VCR (not shown).

When the communication or data processing service 1035 is selected, the document processing service 1045, the fax service 1037 or the like can be selected. It is envisioned that the cabin terminal may include a port for receiving keyboard input. The keyboard, according to one embodiment of the invention, is distributed by the hotel employee to the cabin, if desired. Alternatively, the system may be extended such that a keyboard is provided in at least some rooms at all times in case the word processing service 1045 or facsimile service 1037 is selected.

When the guest selects the facsimile service 1037, the user issues an instruction message at 1039 to start composing the transmission message. After composing the message, the user enters an end of message or other special control character to indicate that the message is ready to be sent (1041).

When the user selects video game play (1015), the title and / or description of the executable game is displayed to the user (1017). After that, the host computer 7 starts the program download process of the video game described in detail below with reference to FIGS. 12 and 13 (1019). The system then begins executing the game program to allow the guest to play the selected video game (1021).

The communication system of the present invention also includes a shopping service option (1023) that allows the user to select from a wide range of available merchandise for purchase by credit card or room charge. In addition, the system may require hotel guests to fill out a questionnaire (25).

The entertainment and data processing services shown in FIG. 4 that are selectable via the communication system of the present invention are merely examples. The present invention contemplates that additional services such as books or magazines stored on the mass storage medium associated with the host computer 7 are also optional options. Further, it is envisioned that a selection of educational computer programs will be provided in addition to the selectable video games.

Although FIG. 4 illustrates a wide range of entertainment / data processing and other services, the following disclosure is directed to processing associated with video game play options.

5 to 11 show the host computer 7.
6 is a flowchart showing a sequence of processing executed when controlling a hotel-compatible video game play. FIG. 5 shows an example of the preload and status check processing.
After the power up process, initialization is performed according to one embodiment,
(4000), the host computer 7 preloads each SNES engine (1 to N) with a video game or application program. The array 11 of SNES engines may be preloaded with, for example, the most frequently selected video games of the past, as described in more detail below. For example, a few of the most popular video games are offered to possible SNES engines, followed by SN
ES engine cabin allocation may be based on an association of such a game with the requesting cabin terminal.

In another embodiment, as described above, the host computer executes the application program at each SN.
Although downloaded to the ES engine to generate a main menu display (provided with a wide range of entertainment options to choose from), this flow chart is for the video game options case. If desired, any one of the SNES engines (1 to N), the host computer 7 or the cabin terminal 2,
It may be programmed to control menu display generation.

After preloading each board, the host computer 7 polls the SNES engine printed circuit board (1 through N) to determine the status (4002).
As detailed below, the MCU 190 associated with each SNES engine responds to host status requests by returning a status byte that identifies the status of the SNES. If the status of the polled SNES is OK (4003), the next board is checked (4009) until all the boards in operation are checked, and the processing is continued.

If the status check is not okay,
A check is made to determine if the status word received from the SNES MCU 190 indicates busy (400).
4). If the SNES is busy, then at block 4006 a check is made to determine if the SNES board has been busy for an unusually long time. If it is abnormally in use for a long time, or if the check in block 4004 causes S
If it is determined that the NES is not in use, then a check is made to determine if the board is in use by the guest (4005). If the board has not been used by a guest, the host computer 7
Determine if the ES engine board was producing an abnormal amount of errors at a given time (4007). If the board has not generated an abnormal amount of errors in a certain amount of time, the game download process is repeated for that board (4008) and the routine branches to block 4009 to determine if the board is running. Determines if all boards have been checked.

When it is determined at block 4005 that the board has been used by a guest, the routine branches to FIG.
In block 4010, the SNES board error processing is performed. At block 4010, a check is made to determine if the game is running. The game
If you are running after an unacknowledged status response (400
3), the routine branches to the error handling program because it is believed that an error occurred during game program processing (or possibly download). Then the error message is displayed in the appropriate room. A menu of options is also displayed and the routine branches to block 4009 in FIG.
The ES board check continues (4011).

If the game is not running, based on the processing of block 4010, then additional error checking is done to see if there is an abnormal number of errors coming from the SNES engine (1 through N). Decide whether (4
012). If there are no unusually large numbers of errors, the game is downloaded again to the SNES board (401
3) The routine branches to block 4009 in FIG. 5 to determine if all active boards have been checked.

If the particular SNES engine (1 through N) has an abnormally high number of errors, then at block 4014 a check is made for an empty SNES engine. If there is no empty SNES engine, an error message is displayed and a menu of options is provided to the user (4015). The current SNES engine is then put to sleep (4016) and an error report is generated (4017) to the current SNES engine.

If the check in block 4014 reveals that there are other SNESs that are empty, then the current SNES
The engine is identified as dormant and placed in hibernation (4
018). Upon identifying the current SNES engine as dormant, the SNES engine is excluded from the host computer's polling scheme. An error report is then generated in the current SNES engine (401
9), Empty SNES with guest terminal board allocation identified
The engine is switched (4020). Guest room terminal S
When the NES board assignment is switched to an empty board (4020), the tuned station of the cabin terminal changes. After that, the game selected by the guest is played by the host computer 7.
Downloaded to the new SNES engine from (40
22), the routine branches to block 4009 in FIG. After the SNES state process of FIG. 36, all SNs in operation
The ES board is checked at block 4009 of FIG. 5 and the routine branches to FIG.

FIG. 7 is a flow chart showing the sequence of processing when the host computer 7 performs the menu response processing. As shown in block 4024, the host computer 7 collects menu responses from all cabin terminals, not just from the cabin terminal currently running the game. Thereafter, a check is made to determine if the menu response is a game run request (4026). If a request has been made to run the game, then at block 4036, the cabin terminal S
A check is made to determine if the NES engine is currently in use. . If the check at block 4036 reveals that the cabin terminal is not currently using the SNES engine, then a check is made to determine if there is an empty SNES engine board (4040).

If there is an empty board, then at block 4046 a further check is made to determine if the game selected by the hotel guest has already been preloaded into the particular SNES engine. If preloaded, the cabin terminal is assigned to the empty SNES engine (4050). The game is then reset to the start state (4052) and the routine branches to block 4034 of FIG. 7 where a check is made to determine if all menu responses have been checked. If all responses have not been checked, menu response processing begins again at block 4026. If all responses have been checked, the routine branches to the gameplay time check routine of block 4068 of FIG. 11 described below.

If the check at block 4046 finds that there is no empty board with the preloaded selection game, the host computer 7 assigns the cabin terminal to the empty board (4048) and the selected game is the SNES engine board. Downloaded to (405
4) The routine branches to block 4034 to determine if all responses have been checked.

If the check at block 4040 indicates that there are no empty boards, an error message is shown at block 4042 and a menu of options is displayed in the cabin (4044). The routine then branches back to block 4034 to determine if all responses have been checked.

If the check at block 4036 indicates that the cabin is currently using the board, the selected game is downloaded to the SNES engine board (4038) and the routine branches to block 4034. , Determine if all responses have been checked.

If the check at block 4026 indicates that there is no game play request, then a check is made to determine if there is a time extension request (4028). If there is a time extension request, the routine branches to block 4056 shown in FIG. 8 to switch the cabin television display back under control of the SNES engine. The host computer issues a command to release the stop of the SNES CPU that has been stopped until the game execution time has passed (4058). The routine then branches back to block 4034 of FIG. 7 to determine if all responses have been checked.

If the check at block 4028 indicates that there is no time extension request, then block 4
A check is made at 030 to determine if there is a gameplay end request. If there is a gameplay end request, the routine branches to block 4060 of FIG. As shown in block 4060, the host processor flags that the SNES engine assigned to the cabin is empty. The main menu is then displayed on the guest room television (4062) and the routine branches to block 4034 in FIG.

If the check at block 4030 reveals that there is no gameplay end request, then at block 4032 a check is made to determine if there is a main menu request. If there is a main menu request, the routine branches to block 4064 of FIG. As shown in block 4064, the guest room television screen is switched from a character display under control of the SNES video game program to a menu display. Thereafter, the cabin's associated SNES CPU is stopped (4066) and processing continues to block 4034 of Figure 7 where a check is made to determine if all menu responses from all cabin terminals have been checked. If the processing at block 4032 indicates that there is no menu request, the routine branches to block 4034.

After all responses have been checked at block 4034, the routine branches to block 4068 of FIG. 11 where a game play time check occurs. The assigned S, as shown in block 4068.
Cabin terminals with NES engines are polled by the host computer 7 (more frequently than unassigned cabin terminals). For example, the host computer 7 may poll the guest room terminals involved in game play once every 1 / 60th of a second. Other cabin terminals not playing the game are also polled by the host computer 7, but preferably not at the same rate as once every 1 / 60th of a second.

The information collected from the cabin terminals by host polling is entered into the assigned SNES engine via the keystroke link shown in FIG.
More specifically, the keystroke information generated by the game controller 3 is input to the keystroke link shown in FIG. 1 via the MCU 6 and received by the appropriate SNES engine (1 to N). The MCU 190 associated with each SNES accesses the SNES game controller information processed by the associated SNES video game processor and inputs such signals on the game controller input line to the SNES as described below.

Thereafter, the game play time of the first cabin terminal which is executing the game play is checked (40
70). At block 4072, a check is made to determine if the gameplay time exceeds the paid time. If the time has expired, a stop command signal is input to the associated SNES CPU (4074) and a menu of options including time extension options is displayed on the cabin terminal (4076). If the first cabin terminal has not timed out (4072) or after displaying the menu option (4076), processing continues at block 4078, where a determination is made whether all cabin terminals have been checked. If all cabin terminals have been checked, processing continues at block 4002 of FIG. 5 and the host processing repeats.

If the check at block 4078 indicates that all cabin terminals during gameplay are not checked, the routine branches back to block 4070 to repeat the gameplay time check process.

12 and 13 are block 1 of FIG.
It is a detailed flowchart which shows the sequence of the process performed by SNES which runs a program from each boot ROM during the game program download process shown in 019. At the beginning of the game program download process (38), the SNES CPU polls each receive buffer to determine if the downloaded data has been received (40). The received data includes program data interspersed with predetermined frame instructions and other data described below. If no downloaded data has been received, the routine continues to poll the receive buffer until such data is received.

When the data is received, it is read (4
2). The first byte of information is the pseudo static RAM (see FIG. 15).
174), and the pseudo-static RAM is used to store downloaded programs (44). The next data byte is then read (46) and used to determine the starting bank number (52). At block 52, a check is made to determine if the received bank number is valid. The appropriate bank number may be ascertained by determining if the bank falls within a given range. If the receiving bank number is not valid, the download is aborted (48),
An error message is sent to the SNES board MCU 190 (50) and the routine ends.

If the proper bank number is specified by the check in block 52, the proper bank is stored in the register of SNES and the program data is sent to this bank (54).

Then, the next two data bytes are read (56). As shown in block 58, block 56
A check is made to determine if the 2 bytes of data read at 4 identify the correct memory start address. If the correct starting memory address is not identified, the routine branches to block 48 to abort the download. If the correct memory start address is identified, then the identified memory start address is set up, as shown in block 60. Then, the next 2-byte data is read (62) and the byte number in the bank is identified. A check is made at block 64 to determine if the proper byte number has been identified. If the appropriate byte number is not identified, the routine branches to block 48.

Once the proper byte number is identified, the data is read at block 66, which is the actual program related data. Thereafter, each byte is read before it is written to memory (68).
As shown in block 70, a check is made to determine if all bytes in the bank have been received. If not all bytes have been received, the routine branches back to block 66. If all bytes are received, a check is made to determine if all identified banks have been received (7
2). If not all banks have been received, the routine branches to block 42 for further banking.

When all banks have been received, a checksum of the downloaded memory contents is calculated (7
4). If the checksum matches the stored checksum value (76), the program is executed (80) and the routine ends. If the checksums do not match, the routine branches to node AB in FIG. 12 where error processing is performed and then download processing is resumed.

FIG. 14 is a schematic block diagram showing important data and control signals related to the SNES engines 1 to N. Each SNES engine includes a video game computer board 100 and a memory board 102, which are described in detail below. In the preferred embodiment herein, the video game computer board 100 is a simplified version of the SNES video game system. The memory board 102 includes a storage device that stores the downloaded game program, game character data, and other application program information. The memory board further includes a boot read only memory (ROM), the boot program of which boot ROM is executed at power up to determine whether the pseudo static RAM in memory board 102 contains the intended program information. At the same time, it is determined whether or not to perform other processing described below with reference to FIGS. In the preferred embodiment herein, the memory board also includes the MCU 190 and ZILOG shown in FIG.
The communication controller model number Z85233 is included.

Next, regarding the data and control signals exchanged between the video game / computer board 100 and the memory board 102, the refresh signal REFRE is used.
SH is input to the memory board 102 for random access memory (RAM) in a manner as will be appreciated by those skilled in the art.
To refresh. The computer board 100 also inputs the system clock signal and the 21 MHz clock signal to the memory board. The system clock signal is the clock required for register function and memory board R.
AM and in a manner as would be understood by one of ordinary skill in the art. The system clock preferably allows the clock frequency to be selectable in at least a limited range. The ROMSEL and RAMSEL signals are generated by the video game computer board and are used as chip enable signals to be processed by the decoding logic of the memory board to select the appropriate memory at the appropriate time. Various power lines and bidirectional control lines are also connected to the memory board and the video game computer board as shown in FIG.

The control signals input to the video game computer board 100 include video game control signals generated by the player's portable game controller 3. Such a signal is transmitted from the video game computer board 100 to the MCU 19 of the memory board 102.
0 (FIG. 15). In the preferred embodiment of the present invention, the signals generated by the SNES type game controller 3 are latched by logic circuits within the memory board. According to this embodiment, the controller signals are input to the MCU 190, which latches the player input signals and inputs these signals to the video game computer via the control line shown in FIG. In the memory board 102, two 8-bit latches are 16
Used to provide a bit of player controller information to the video game computer board 100.

24 video game computer boards
There are book address lines CA0 to CA23, which are connected to the memory board 102 and are used to address the memory elements provided therein. Furthermore, eight data lines are connected to the memory board 10.
It is used to exchange data between the two and the computer board. The memory board 102 is a pseudo-static RA for storing program information, as described in detail below.
Pseudo static RAM 102 including M
Like the other memories in 2, it is connected to the address data lines. The video game computer board 100 also sends a read signal or a write signal to the memory board 1.
02. Another control line for inputting into the memory element of 02.

Memory board 102 also includes an IRESET line for providing an externally generated reset signal to video game computer board 100. IR
ESET is used when the system needs to be reset due to occasional communication failures in the hotel, or when communication must be interrupted by other higher priority communication. The RESET line shown in FIG. 36 is used to reset the elements implemented in the memory board at power up in order to keep the voltage level constant. Computer boards and memory boards also have 8-bit address buses PA0 through PA7.
To enable addressing of registers (detailed below) located in the address space of a particular CPU.

The memory board 102 receives a high speed synchronous serial input, which contains program information downloaded from the host computer 7.
Such a synchronous serial input is received at, for example, 408k baud and may include game program or application program information. The memory board also includes an asynchronous serial I / O port, which receives input at, for example, 102.4 kBaud, at which the cabin terminal 2 shown in FIG. And MCU
6 and SNES via keystroke data link
Game controller keystroke data or commands (e.g. stop, unstop, reset) to be sent to. In addition, another asynchronous serial input / output port is included which receives information from the host computer 7 at, for example, 38.4k baud. The command from the host computer 7 is sent to the memory board MCU and the SNES (which responds to the host computer 7 by command input).
Input is made via this bidirectional link. The memory board 102 also receives a 5 volt power input. Furthermore, the video game computer board 100 outputs the video signal output and the left and right channel audio signals to the television in the guest room described in FIG.

As will be appreciated by those skilled in the art, the above input signals are routed appropriately to the SNES engine assigned to a particular cabin. If eight SNES engines are used in this application, the 3-bit "address" is
It may be used to uniquely identify a particular SNES engine.

FIG. 15 shows the memory board 10 shown in FIG.
2 is a block diagram of the circuit implemented on 2. The memory board 102 includes decoding logic circuits 150, 152, 154, 1
56, these decoding logic circuits have associated register 1
58, 160, 162, 164 and may be, for example, implemented programmable array logic (PAL). Decoding logic circuits 150-156 perform decoding and register store related execution, which is described in more detail below.

Each decoding logic circuit 150, 152, 154,
Associated with 156 is a single bit register. Register 158 is identified as a speed register. Register 160 is identified as a Z bank. Register 162 is identified as the map mode register and register 164 is identified as the boot / run register. The function of registers 158 through 164 is described in detail below. The bits stored in each register are pseudo static R
The pseudo static RAM 174 address map mode is selected according to the state of the output from the AM (PSRAM) controller 166 and, as a result, the registers 158 to 164. The address map function implemented by the pseudo static RAM controller 166 allows different games using different address map modes to be run using the same memory board hardware.

The pseudo static RAM controller 166 requires the pseudo static RAM 174 by providing a pseudo static RAM output enable signal and a write enable signal for the read function in addition to performing the address map function. To generate a refresh signal. The pseudo static RAM controller 166 is
Address data is received from the SNES address line (shown in FIG. 14). This address data is stored in the register 15
Decoded by the states 8 to 164, which causes the decoding logic 150 to 156 to address line P
It is set in response to an address signal input from A0 through PA7. In this embodiment, the pseudo static RAM 17
4 is preferably a 2 Mbyte RAM responsive to the pseudo static RAM controller signals of FIG.

Registers 162 and 164 are static RAs.
Static RAM controller 16 connected to the M controller 168
8 controls access to static RAM 176 by generating a chip select signal based on the outputs received from registers 164 and 162. Static RA
The M176 is addressed by the address signal on the SNES address bus as shown in FIG.
In response to the read control signal and the write control signal.

The registers 160, 162 and 164 are connected to the non-volatile RAM control device 170, and are connected to the non-volatile RAM.
The controller 170 sends the chip select signal to the nonvolatile RA.
Generate for M178. As shown in FIG. 15, the non-volatile RAM 178 is addressed from the SNES address bus and receives write and read control signals via the chip enable signal. The contents of the boot / run register 164 are the SNES reset signal and the ROM.
It is input to the EPROM controller 172 together with the selection signal, and the EPROM controller 172 generates a chip select signal at the appropriate time to read the EPROM 180. EPROM controller 172 receives an address from the SNES address bus. The EPROM may be written in response to the SNES write control signal. Pseudo static RAM 174, static RAM 176, non-volatile RAM 1
The SNES address and the data bus are input to the 78 and the boot ROM 180, respectively.

The pseudo static RAM 174 stores the game program downloaded or the application program downloaded as described above. Static R
The AM 176 stores various types of game parameter information and operates as a working memory. Non-volatile RAM1
78 stores information generated by the application program and information relating to the state of the pseudo static RAM 174, and this information includes information for identifying the type of data stored in the pseudo static RAM 174. .

The memory board 102 of the present embodiment also includes
This interface includes the interface MCU 190.
May be, for example, a Hitachi H8 / 325 microcontroller. MCU 190 performs the functions detailed below.

The memory board 102 has a control decoder 182.
Further, the control decoder 182 is connected to the SNES address line. In response to the signal received on the SNES address line, the control decoder 182 inputs a "data ready" signal to the MCU 190, a "read" signal to a first in first out (FIFO) buffer 184, and a "data shift in" signal. Latch signal 188 (SNE
Receive data from the S data line), thereby shifting out the data to the MCU 190. F
The IFO 184 provides the MCU with the information downloaded at high speed.
This data is received from 190 and stored in response to a "write" signal generated by MCU 190. The control decoder 182 triggers the read process from the FIFO 184 in response to the read control signal on the input address line.
If there is no executable data in FIFO 184 at the time of the request, a "data unexecutable" signal is generated by FIFO 184 and input to control decoder 182 and the SNES data line. To write data to the MCU 190, the SNES processor checks the "busy" line which indicates whether the MCU 190 can receive the data. If the MCU 190 is ready to receive the data, then one byte is shifted into the latch 188, thus activating the "busy" signal by sending the "strobe in" signal. If the MCU 190 is unable to receive the data, the SNES continues to check the "busy" signal.

The MCU 190 further controls the ZILOG serial communication controller 192, and the ZILOG serial communication controller 192 is connected to receive the program instructions and data downloaded from the host computer 7 at a high speed. The downloaded program instructions and data are stored in the ZILOG serial communication control device 1
92 is input via the voltage level shifter 194.
The fast downloaded data from tuner 86 has a logic level of 0 to 1 volt. Level shifter 19
Reference numeral 4 is a conventional level shifter for converting 0 to 1 volt data into 0 to 5 volt.

The memory board 102 also includes an MCU 19
Includes stop controller 196 connected to zero. The stop controller 196 is designed to input a stop signal to the video game computer. The stop signal is generated to stop the game play after a predetermined time e.g. 1 hour after the game starts, and instructs the user to request the extension of the play time and pay the fee for the extended time. You can send a message. Further, the shutdown controller may be programmed to be responsive to other events within the hotel, such as government speeches or events that should trigger a shutdown condition. Stop control device 19
No. 6 does not occur when the stop is arbitrary, but it is necessary to stop in synchronization with the system refresh signal and the memory refresh process for not losing the stored data. Stopping SNES is desirable when higher priority tasks must be performed, or when there are other reasons to stop the video game computer, such as communication failures or power outages.

As mentioned above, the memory board 102 inputs game controller data to the video game computer board via the controller input line. Such controller data is input to the MCU 190 via the asynchronous serial port. The controller data is output to the SNES via the latch 186, and the output of the latch 186 is input to the controller data line shown in FIG.

The MCU 190 also includes a reset output line for resetting the video game computer, for example for the purpose of recovering from a temporary drop in the voltage level of the hotel or other electrical faults. Used for. The boot ROM program checks to determine if it was running as a result of such an error condition.

16 to 23 show various configurations of the video game computer address space. The memory configuration accessible by the video game computer CPU is defined by the information stored in registers 158, 160, 162, 164, as illustrated in FIGS.

16 to 19 show two examples of the memory configuration after the power is first turned on. As shown in FIGS. 16 to 19, the boot ROM program accessed by accessing the memory bank 00 is first executed. During this time, there are no application programs running, which is indicated by the boot / run register storing a logical "0". Boot / runbit maps boot ROM to the video game computer it is running on (boot / run = 0),
Switch the contents of the pseudo-static RAM either to map to the running video game computer (boot / run = 1). As shown in FIGS. 16-19, the contents of the “speed” and “Z bank” registers have no effect on this memory configuration (shown as “X” or “irrelevant” state). Registers 158 to 164
Is set prior to downloading a particular game program in response to the selection of the game program.

FIG. 16 reflects a memory configuration which is a standard configuration when the SNES video game computer normally starts execution from the game cartridge ROM.
In this configuration, the boot R implemented on the memory board 102
The OM is mapped instead of the game cartridge ROM. In the first power-up map shown in FIG. 16, the non-volatile RAM (NVRAM) is accessible by the video game computer and is in its final state before the boot ROM program is powered up (this state is stored in the non-volatile RAM 178). To be able to check (remembered). As shown in FIG.
During execution of the boot program, the pseudo static RAM 174,
The static RAM 176 and the non-volatile RAM 178 are CPs.
Accessible by U.

FIGS. 17, 18 and 20 are three standard address space configurations of memory associated with a wide range of SNES games. As shown in FIGS. 17, 18, and 20, the contents of the boot / run register are “1”,
Indicates that the game program is running.

The difference between the memory map mode of FIG. 17 and the memory map mode of FIG. 18 is that the image of the storage location of the pseudo static RAM in FIG. 18 is a predetermined low address memory bank and high address memory address. That is what happens in the bank. As shown in FIGS. 17 and 18, the associated register state depends on the contents of the "speed" register. As mentioned above, the system clock of a video game computer produces signals at two different speeds. In the exemplary embodiment of the present application, a high clock speed is used to execute a program (stored in the image of the memory bank of the low address pseudo-static RAM) from the high address address bank.

The Z bank register set controls the functionality of the application program that enables the video game computer to access the boot ROM and download the game program when execution is complete. However, the game program is a boot ROM
Can't access. The state of the Z bank register is fed back to the decoding logic circuit to indicate that the application program is being executed. The map mode bits define the part of the address map mode that can be selected.

During execution of the video game program, Z
The state of the bank register disables modification of the speed register, Z bank register, map mode register or boot / run register. However, during execution of the application program, the state of such registers can be modified later.

The memory board 102 shown in FIG. 15 operates as follows. First, when the power is turned on, the CPU of the video computer board is represented as shown in FIG. 16, and the program stored in the boot ROM is executed. Upon executing the boot ROM program (which will be discussed in more detail below), the video game computer CPU causes the S
Control decoder 18 in response to a signal on the NES address line
In response to the "Data Shift In" control signal generated by 2, the latches 188 are requested to write the data present on the video game computer data lines. The MCU 190 indicates that the data is executable.
Notified via the "Input Strobe" control input. MC
The U 190 reads the data stored in the latch 188 and outputs the data to the SNES video game processor or the host computer 7.

The data input to SNES is MCU1.
90 into the FIFO 184. The SNES video game computer, while executing the program stored in boot ROM, monitors the FIFO 184 to see the presence of status flags when data is available. afterwards,
The SNES inputs the control signal on the SNES address line, which is decoded by the control decoder 182 to generate the "read" signal, and the "read" signal is input to the FIFO 184 for the SNES data. Start reading information from the line.

Thereafter, the boot ROM program is responsive to the read data to download the application program, the game identifier uniquely indicating the selected game, and / or the map mode register mark to be stored in registers 158-164. Can start. According to one embodiment of the present invention, the first time the boot ROM program is executed, the download of the application program begins. When the application program is downloaded, the boot ROM is FIFO1.
The 84 status flags are monitored to see if there is any information to be read. The application program itself is
The data is downloaded to the ZILOG serial communication port controller 192 through the level shifter 194 via the high speed download link, and the ZILOG serial communication port controller 192 inputs the data to the MCU in response to the control signal from the MCU 190, and then the data. The instructions and / or instructions are stored in the FIFO 184.

When the application program is downloaded from the host computer 7, the FIFO 18
4 and then stored in pseudo-static RAM 174 via the SNES data bus. After the application program is downloaded, the game-related parameter data is stored and stored in the non-volatile RAM 178. In this way, the application program can access the contents of the non-volatile RAM 178 during execution and can display information such as a specific executable program and / or educational program. When the application program is successfully downloaded, the contents of the Z bank register are set to "1", and the memory address space of the video game computer has the structure shown in FIGS.

During execution of the application program,
The user selects the desired menu. The data is stored in the latch 188 of FIG. 15 by the menu selection. After that, the “input strobe” signal is sent to the MCU 190, which triggers the data read from the latch 188, and the menu selection data is sent to the host computer 7. The final destination of the data depends on the user's menu selection.
It is indicated that the particular video game program or user selected movie mode, shopping mode or other mode needs to be downloaded.

When a game is selected, player control data indicating the movement of a moving object such as Super Mario is input from the cabin terminal to the MCU 190,
Player controller information is stored in the latch 186. The player control data is then input to the video game controller via the SNES controller data line. Player controller data can be the left, right, up, down movement of a moving object or conventional SNES.
4 shows control signals generated by control buttons such as "A" and "B" on the game controller.

It is possible to change the contents of registers 158 to 164 during execution of the program stored in boot ROM. The addresses generated on the address lines PA0 to PA7 are four registers 158, 160, 16
2, 164 are used to uniquely set or reset, respectively. PAL decoding logic circuits 150, 15
Nos. 2,154,156 prevent the associated registers from being set or reset for a period of time if the system makes such modifications impossible. For example, while the game is running, decoding logic 150 may prevent the game clock speed from changing.

FIG. 24 is a simplified block diagram of an example computer / video game processing system that may be used with the present invention. According to the present embodiment, the computer board is, for example, a Nintendo of the Super Nintendo Entertainment System (SNES).
It may be a 16-bit video game system commercially available from America, Inc. SNES is 19
US Patent Application No. 07/65 filed April 10, 1991
1, 265, "Video Processor", August 26, 1991.
Japanese Patent Application No. 07 / 749,530 “Direct Memory Access Device and External Storage Used Therefor”, US Patent Application No. 07 / 793,735 “Now Mosaic Image Display” filed Nov. 19, 1991 Device and External Unit Used for It ". These applications are expressly incorporated into this application. However, it should be understood that this application is not limited to SNES related applications and may be used with other video game / data processing systems or other non-video game information processing devices. . The SNES or SNES engine cited herein should not be considered as limiting the scope of the invention to SNES related applications and systems having the block diagram as shown in FIG. SNES
Is preferably modified in many respects as described herein. The RF modulator circuit contained in the conventional SNES system is not implemented in this embodiment, but rather an external RF modulator is used. As shown in FIG. 24,
The video game computer board 100 is connected to a memory board 102, the details of which are described in FIG. The host CPU 220 and other hardware components on the board 100 are represented by SNES commercially available from Nintendo of America, Inc., as described above.

The host CPU 220 is a 16-bit CPU
And may be, for example, a 65816 compatible microprocessor. CPU 220 is coupled to a working RAM that includes, for example, 128 kilobytes of storage.
The CPU 220 is connected to the video RAM 228 ('
265, '530, and' 735 (as described in detail in the application). CPU 220
Can only access the video RAM 228 via the PPU 222 when the PPU 222 is accessing the video RAM 228 and is not in the live line scan. The PPU 222 produces a video signal that is coupled to a television monitor in the passenger room. CPU 220 is also coupled to voice processor APU 224 which is also coupled to work RAM 230. The APU 224 may use a commercially available voice chip, and the pseudo static RAM 17 on the memory board 102 is used.
4. Generate the audio associated with the video game stored in 4. The host CPU 220 can only access the work RAM 230 via the APU 224.

The video RAM 228 in the SNES is stored with the appropriate character data stored in the pseudo static RAM 174 (which stores not only the game program but also character data used during game play). All displayed moving objects or background characters are resident in the video RAM 228 prior to display.

The program storage pseudo static RAM 174 is
It is accessed by the host CPU 220 via an address bus and a data bus shown generally in FIG. The PPU 222 is a PP coupled to the memory board.
It is connected to the memory board via a shared host CPU data and address bus and connector 234 to provide a path for U data and control signals. A
The PU 224 is a shared host CPU bus and audio bus 2.
It is connected to the memory board via 32.

As described above and shown in FIG. 24, S
The NES produces various control signals. SNES CP
U220 generates control signal ROMSEL when it needs to access pseudo-static RAM 174. SNE
S generates a refresh signal RFSH to start memory refresh. The host CPU 220 further generates a read signal and a write signal. The system timing signal is the video game processing board 1
It is generated from the timing chain circuit 210 in 00. A power-on reset signal is also generated within video game computer board 100 and
Entered in 2. The other control signals shown in FIGS. 16-23 are unique to the hotel-enabled embodiment, eg, the “stop” control signal and the “IRESET” signal described in connection with FIGS. 16 and 15. Memory board 102 and video game / computer board 100
The signals exchanged between them are described in more detail in FIG.

25 to 28 show a sequence of operations performed by the program stored in the boot ROM 180 shown in FIG. 15, except for the download operation described above with reference to FIGS. 12 and 13. When the execution of the boot program is started, the CPU 220, PPU 222 registers and ports associated with the video game / computer board 100 are initialized (251). After initialization,
Set up the initial display screen (which may be generated by either the host computer 7 or the SNES) as seen by the user (252).

As shown in FIG. 25, an exemplary boot RO
As a result of executing the M program, the SNES sends a power-up message such as "hello" to the MCU 190 on the memory board. A message from the SNES indicates that the SNES has completed the reset operation (ie either a power-on reset or a reset by operating the game controller "reset" key).
Tell U190.

The MCU 190 then generates one of various replies to the SNES "hello" message. As shown in block 256, the SNES is the MC
Continuously check if a reply from U is received. Upon receiving a reply from MCU 190, pseudo static R
A check is made to determine if the reply indicates that the game stored in the AM should be restarted (258).

If the reply does not indicate that the game should be restarted, then at block 260 a check is made to determine if a download operation has begun.
If program download has not begun, a check is made at block 262 to determine if a "wait for command" reply has been received, generally indicating that it should wait for a command, after first booting the entire system. To do.

If the reply does not indicate the need to wait for a command, then at block 264 a check is made to determine if a memory board test has begun.
If the memory board test has not started, the routine branches back to block 254 to begin transmitting a power-up message to the MCU to repeat the process described above. If the memory board test had been started, the SNES boot ROM program tests the memory and sends the result to the MCU 190 (26
6). The memory test may be performed, for example, by using the pseudo static RAM 17 in order to confirm whether the proper memory operation is performed.
4, may include read and write information to static RAM 176 and non-volatile RAM. The routine then branches back to block 256 to test for a response from the MCU 190.

The reply from the MCU 190 is block 25.
If the game is to be restarted based on the check in FIG.
The game program map mode information (see FIGS. 16 to 23) and the game program size information are transferred to the ES. After that, the map mode register shown in FIG. 15 is stored (270) and the working RAM is cleared (272).
The routine branches to a game program to execute (274).

Returning to FIG. 25, if the result of the check in block 260 reveals that the download operation has started, SNES indicates MC
The game checksum data transferred by U190 is read (276). After that, the SNES reads out the game program map mode and size transferred by the MCU 190 and the game name information (277, 27).
8). The routine branches to the download processing routine described above with reference to FIGS. 12 and 13 (27).
9).

FIG. 28 shows the sequence of operations performed during boot ROM non-maskable interrupt processing, which is the only interrupt that can occur in the boot ROM program. As shown in block 281, a "wait" timer is incremented and used to control various timers, such as, for example, the timer that controls the acceptable latency to initiate a download. Next, as shown in block 282, the display is updated with the clock information (eg, hand movements) to indicate ongoing operation of the system. All other messages that need to be displayed are also displayed (283). In an exemplary embodiment of the invention, during a download operation, the download indicator is changed (284) to indicate how complete the download is. After executing the interrupt routine, the routine returns to the main boot routine shown in Figures 25-27.

FIG. 29 is a flow chart showing a sequence of operations performed in the main processing routine by the MCU 190 shown in FIG. 30 to 33, 34, 35, 36, 37 to 45, 46 and 4
7, FIGS. 48-55, and 56-58 are flow charts showing a more detailed sequence of MCU operations resulting from a branch from the main program of FIG. 29 in accordance with an exemplary embodiment of the present invention. The MCU 190 runs interrupt driven software that continuously checks various status flags. The MCU 190 transmits / receives data byte by byte according to the state of the state flag.

Returning to FIG. 29, a series of initialization steps are performed to begin the main program loop of the actuator. Once powered up, the interrupts associated with MCU 190 are disabled, as shown in block 300. Thus, if serial data is received on the controller's input port during this period, no interrupt will occur for initialization. Then, a variable that determines the action to be taken is initialized (302). As shown in block 304, the data direction register associated with the MCU 190 is initialized to determine if the particular pin functions as an input or output pin. The MCU serial port is then initialized and the appropriate baud rate and number of start, stop and parity bits are set (306). Next, the baud rate associated with the serial communication controller (192) port is initialized (308). SNES without boot ROM 180
The MCU 190 software then resets the FIFO 184 (310) to ensure that the
The CPU 220 and the PPU 222 of the SNES are reset (312).

After that, the buffer for inputting the controller data of the player to the SNES is initialized (314).
Stop SNES and MC as shown in step 316.
The U190 interrupt is enabled (318). Next, the built-in timer is initialized (320). The MCU timer is used, for example, to trigger a time control interrupt which is initialized when the timer counts down from its initial value to zero.

The main program initialization process is performed by SNES.
Is completed (32
2). Then, as shown in block 324, MCU1
90 checks to determine if there is keystroke data in the MCU input buffer. If so, the routine branches to the keystroke data processing routine shown in FIG.

If there is no keystroke data, then a check is made to determine if there is host data in the host data input buffer, as determined in block 324 (326). If host data is present, the routine processes the host data according to the flowcharts shown in FIGS.

If at block 326 it is determined that there is no host data, then a check is made to the MCU.
Determine if there is data in the 190 SNES input buffer (328). If data is present in the SNES input buffer, it will be processed according to the flowchart of FIG. If no SNES data is present, the routine branches back to block 324 to again determine if there is data in the keystroke input buffer.

The above-mentioned processing is performed by each MCU 1 associated with a representative one of the SNES engines (1-N) shown in FIG.
At 90, done separately.

30 to 33 show a sequence of operations when processing the keystroke data. Block 32
If the check at 4 (FIG. 29) reveals that there is data in the keystroke input buffer, the routine branches to block 330 in FIG. 30 where a keystroke of at least 2 bytes in the keystroke input buffer. Determine if data exists. If there is not at least 2 bytes of keystroke data in the input buffer, the routine branches to block 32.
Returning to 6 (FIG. 29), check the host input buffer. If there is at least 2 bytes in the keystroke input buffer, then 1 byte is read (332).

After reading the first keystroke data byte, a check is made to determine if the first byte is a header byte (334). The preamble of the keystroke data stream then consists of a header byte indicating that the keystroke data will follow. The header byte indicates the origin of the stream of data. Each SNES engine is assigned a time slot for reading the data in the transferred data stream. If at block 334 the read byte is determined to be a header byte, then the next byte is read (336). According to typical communication protocols, this byte should be the data stream identifier. This byte is compared to the data stream number assigned to the SNES engine (338).

As a result of the check in block 338,
The assigned data stream number is a specific SNES
If it turns out to be for the engine's MCU 190, it resets the data position counter to count synchronously with the assigned data stream position (34
0). Next, the state of the MCU 190 is “synchronized” (3
42), the routine branches to return to block 330 (FIG. 30) for further processing to determine if there are at least two more bytes in the input keystroke data buffer. If there are at least 2 bytes in the buffer, read 1 byte again (33
2) Check to determine if the byte is a header byte (334).

After first reading the header bytes,
The second pass through this loop will read the next byte (344). A check is made to see if the states are synchronized (346). If the states are not synchronized, the byte just read will be
It becomes "unread" (by resetting the read pointer) (348) and the routine branches back to block 330 to repeat the loop. Block 3
If the check at 46 reveals that the states are synchronized, then a check is made to determine that the data is part of the allocated slot (35).
0). If the data is not part of the allocated slot, the data position counter is incremented (352) and the routine branches back to block 330 (FIG. 30).

If the data is part of the allocated time slot, then at block 354 a check is made to determine if the two bytes read constitute a command (354). If the read byte is not a command, a check is made to determine if the byte is valid keystroke data (356). If the 2 bytes are a command, the routine will
The process branches to block 372 of FIG.

If it is determined at block 356 that the 2 bytes read are valid keystroke data, then a check is made to determine if the SNES CPU is halted (358). The stop check is done to allow the user to leave the CPU unstopped, for example to buy more gameplay time. When the CPU is stopped, the guest room terminal 2
Display a menu display screen that provides options to continue gameplay. The SNES becomes unstopped in response to the start key operation 50. A check is made to determine if the start key has been pressed (360). If so, the SNES CPU is not stopped (362),
The start key bit is cleared in the associated game controller byte so that the start key appears unpressed (364).

After processing at block 364, or if the start key was not pressed or the CPU was not stopped (358), the routine branches to 36.
Proceed to 6 to send a byte to the SNES controller port. The state is then "desynchronized" (368), the data position counter is incremented (370), and the routine branches back to block 330, where the input keystroke buffer determines if there are two bytes. Check for

According to the processing of FIG. 30, the keystroke data on the keystroke data link is transmitted to all SNES engines. This data is monitored by all SNES engines and the appropriate data assigned to a particular SNES engine is pulled from that data stream for processing by that SNES engine.

The check at block 354 indicates that
If the two bytes read from the assigned timeslot are found to be a command, the routine branches to block 372 of FIG. 31 to verify that the command is a valid command. A valid command check is performed by determining if the command is one of a limited number of valid commands that the MCU 190 can receive from the cabin terminal. If the check at block 372 reveals that the command is not a valid command, the last byte read is unread (374) and the routine branches back to block 330 (FIG. 30).

If it is determined at block 372 that the command is a valid command, then a check is made to determine if the command is a "reset" command (376). If the command is a reset command, the routine branches to block 377 (FIG. 33).
Proceed to step 1 to check whether or not the SNES download operation status is OK. If the SNES download status is OK, the status flag is set to indicate the game reset status (379). After the SNES is reset (381), the SNES CPU sends a "hello" command to the MCU 190, and the MCU 190 instructs the SNES to start executing the game program stored in the pseudo static RAM 174. Respond by. The routine then branches back to block 330 (FIG. 30).

If the check at block 376 reveals that the command is a reset command, then a check is made to determine if the command is a "stop" command (378). If the command is a stop command, the MCU issues a stop command to the SNES CPU (380) and processing returns to block 330 (FIG. 30). If the result of the check in block 378 is that the command is not a stop command, a check is made to determine if the command is an "unstopped" command. If the command is a non-stop command, MCU19
0 causes the SNES CPU to be unhalted (384) and the routine branches to block 330 (FIG. 30).

Returning to FIG. 30, if the check at 356 reveals that the 2 bytes read from the assigned slot are not valid keystrokes,
The routine branches to block 384 (FIG. 32).
As shown in FIG. 32, when valid data is detected, the last two valid controller bytes sent most recently are sent.
Retransmit the bytes (384). The last two bytes then become "unread" (386) and the routine branches back to block 330 in FIG.

As a result of the keystroke data processing and command processing described above, the SNES responds to the player's interactive commands for moving objects (eg, Super Mario) in many different ways that the SNES game program can execute. In order to
Receives all keystroke data and control information needed for SNES. The information is processed according to conventional SNES game programming processing techniques.

Returning to the main processing routine of FIG. 29, if the check at block 326 finds that there is data in the input host buffer, the routine branches to block 388 of FIG. At block 388, a check is made to determine if the read status flag is set to "wait header byte" to identify the start of the data stream. If not set, a check is made to determine if the status is "waiting for command" (390).

As a result of the check at block 388,
If the state turns out to be waiting for a header byte, the routine branches to block 392 (FIG. 35).
Proceed to and check to see if there is at least one byte in the host input buffer. If not, the routine branches back to the main program at block 328 (FIG. 29) to determine if there is data in the input SNES buffer. If there is at least one byte in the input host buffer, that byte is read (394) and a check is made to determine if that byte is a header byte (396).
If the byte is not a header byte, the routine branches back to block 392 to wait for the header byte to be received.

The check at block 396 causes
If the byte is found to be a header byte, the read status is set to "wait for command" and processing continues at block 400 where a check is made to determine if there is at least one byte in the host input buffer. To do. If not, the routine branches to the main program at block 328 (FIG. 29). If there is at least one byte in the buffer, that byte is read (402) and a check is made to determine if the read byte represents a valid command (404). The result of the check in block 404,
If it turns out that the command is not a valid command,
The read status flag is set to "wait for header" and the routine branches back to block 396 to check the header byte.

The check in block 404 indicates that
If the byte read is found to represent a valid command (eg, as indicated by the table of valid commands), the MCU may request additional requests, such as checksums and end of message flags. Determine the complete command length, including the information provided. In this way, the MCU 190 can confirm that the complete command has been received before any processing begins. Valid commands that can be executed are "stop", "not stopped", various memory test commands, "reset to boot ROM" command, address identification SNE.
It includes commands to change the S engine, various status check commands, and the like. Then, the state is set to "wait for command read" (410).

If the check in block 390 (FIG. 34) reveals that the state is "waiting for command", or if the state has just been set to "wait for command read", then in block 412 the block A check is made to determine if the command length calculated at 408 matches the length of the bytes in the input buffer (412). If the complete command is not resident in the input buffer, the routine branches back to the main program at block 328 (FIG. 29). If all commands are present in the input buffer, all command bytes are read (414). After reading all command bytes, the next byte is read (416) and a check is made to determine if the next byte is equal to the end of the message flag (418).

If the last byte read is not the end of the message byte, an error occurs in command processing and all bytes except the first byte after the header are unread (420). The routine then branches to block 396 where a check is made to determine if the byte read is a header byte.

If it is determined at block 418 that the last byte read was the end of the message flag, the routine branches to block 422 (FIG. 36) for command processing. Command processing begins by calculating a checksum based on the command message just received (422). Next, the checksum data stored in the input buffer is read (424). The "read status" flag is set to "wait for header" (42
6) Afterwards, the calculated checksum and the received checksum are compared (428) to determine if there is a match. If the checksums do not match, then a reply is sent to the host computer 7 (via the same command link that the command was transmitted) that the command was not properly received (430) and the routine branches. And returns to block 328 (FIG. 29).

If the checksums match, a series of tests is performed (432-450) to determine which command was transmitted to execute the command. As shown in FIG. 36, a series of tests may be performed if the command is the “unstopped” command (432) or the “stop” command (43
4), "Memory boat test" command (436),
"Test result check" command (438), "reset to boot ROM" (440), "keystroke data slot change" command (442), "status check" command (444), "game reset" command (446), It is determined whether the command is a "change baud rate of keystroke port" command (448) or a "download" command (450).

If the series of "command" tests in blocks 428-450 each yields a negative result, the MCU 190 indicates to the host computer 7 that it has received an invalid or unexecuted command. Send an unacknowledged (NAK) reply and the routine branches back to the main program at block 328 (FIG. 29).

FIGS. 37-45 and 46 show a sequence of operations performed when the command shown in FIG. 36 is executed. To return to the "not stopped" command (block 432) and execute this command, the routine branches to block 454 (FIG. 37) where the SNES is not in the process of receiving the downloaded game. In order to confirm as a safety check, a test is performed to determine whether the SNES is in use. If the SNES is busy, it sends a reply to the host that the SNES is busy, and the process branches to block 328 (FIG. 29).

"Not stopped" when SNES is not in use
The command is executed (458) and a confirmation signal is sent to the host to indicate that the "not stopped" command has been properly received and executed (460) and the routine branches to block 328 of FIG.

"Stop" without receiving the "unstopped" command
If a command is received, the routine branches to block 452 (FIG. 38). Much like the "unstopped" process, the "stopped" process begins with a check to determine if the SNES is in use (462). SNES
If it is busy, it sends a busy reply to the host (463) and the routine branches to block 328 (FIG. 29). If the SNES is not in use, a stop command is executed by the MCU 190 (464), a confirmation signal is sent to the host computer 7 (466) and the routine branches to block 328 of FIG.

If the command being processed is "memory board instruction test" (436), the routine branches to FIG.
Proceed to block 468 of block 9. At block 468,
Reset SNES to boot state to wait for commands. Next, the MCU 190 sends a memory test command to the SNES (468). The MCU 190 sends a confirmation signal to the host computer 7 to indicate that the memory test is in process (470), and sets the SNES state to busy (472). Thereafter, the routine branches to block 328 (FIG. 29).

If the result of the check in block 438 of FIG. 36 is that a "check test result" command is in progress, the routine branches to block 474 (FIG. 40) which sends the SNES status to the host and the routine Branches to block 328 (FIG. 29). If the memory test is still in process, the SNES state is in use. If the memory test shows an operational state, the state is "OK".
Is. If the test result indicates a memory read or memory write error, the state is set to "wrong" (NG).

If the check at block 440 of FIG. 36 reveals that the command is a "reset to boot ROM" command, the routine branches to FIG.
Proceed to block 476 of 1 to change the SNES session state to "reset to boot". The SNES is placed in a reset state (478), then executes the boot ROM program (see Figures 25-28) and sends a reply confirming receipt completion and command execution to the host (48).
0). Thereafter, the process branches to block 328 (see FIG.
Proceed to 9).

If the processing at block 442 determines that the "change keystroke data slot" command should be executed, the routine branches to block 482.
Proceeding to FIG. 42, the MCU 190 reads the new keystroke data slot assignment. The keystroke data slot assignments indicate to the MCU 190 which position in the keystroke data stream contains the keystroke data that the MCU should process. This command may optionally be used to change the SNES engine timeslot and is the last SN in the array.
As long as the ES engine is currently running, the timeslot can be changed to the SNES engine from the last timeslot to the first timeslot and needlessly send dummy data to the non-running SNES engine. You can avoid that.

After reading the new keystroke data slot assignment, the MCU 190 sends a confirmation response to the host computer 7 (484) and the routine branches to block 328 (FIG. 29).

If the result of the processing at block 444 (FIG. 36) is that a "check status" command is being processed, the routine branches to block 486 of FIG. The status check subroutine checks the status of the SNES in order to determine the game program download operation status, for example. According to block 486, the game checksum stored in memory is compared to the game checksum in the command for which the host computer 7 expects to be associated with the particular SNES engine. If they do not match, the routine branches to block 496 which sends a "wrong" (NG) reply to the host computer 7 of the MCU 190 and the routine branches to block 328 (FIG. 29).

If the checksums match, a check is made at block 488 to determine if the mapmode indication in the command being processed is equal to the mapmode stored in memory. If the map mode data do not match, the routine branches to block 496 and generates an NG reply message. If the mapmode information matches, then a check is made to determine if the keystroke data slot assignment in the command matches the keystroke data slot assignment in memory (490). If not, processing continues at block 496 to send an NG reply message to host computer 7.

If the keystroke data slot allocation information matches, then a check is made at block 492 to determine if the keystroke data stream identifier in the command matches the keystroke data stream identifier stored in the MCU memory. To do.

If they do not match, an NG reply message is generated (496). If they match, the SNES status is transmitted to the host computer 7, and the processing is block 3
28 (FIG. 29).

The status information sent to the host 7 is "O
Either "K", "NG", or "in use". The NG status generated in block 494 is different from the unconfirmed NG status generated in block 496, which indicates that the individual command is invalid. The NG status at block 494 indicates that the individual commands being processed are valid and properly received, but the overall status of the SNES is not normal for some reason.

As a result of the check at 446 (FIG. 36),
If the "reset game" command is found to be in process, the routine branches to block 498 of FIG.
Proceed to. At block 498, the SNES session state is set to game reset. Next, a confirmation response is transmitted to the host computer 7 to indicate that the game reset command has been properly received (500), and the SN
Reset ES (502) and the routine branches to block 328 (FIG. 29). As a result of the reset command processing at block 502, the SNES re-executes the program stored in pseudo-static RAM.

If the processing at block 448 (FIG. 36) reveals that the command is "change baud rate of keystroke port", the routine branches to block 504 (FIG. 45). At block 504, the baud rate is read from the command and stored in a register used by the MCU 190 to define the baud rate. The keystroke data port baud rate is then set to the desired rate (506), as indicated by the contents of the associated register, and a confirmation of successful command execution is sent to the host computer 500. The routine branches to block 328 (FIG. 29).

If the check at block 450 (FIG. 36) reveals that a download command should be executed, the MCU 190 proceeds to block 654 of FIG. To execute the download command, the MCU 190 S at block 654.
Set the NES state to busy to prevent other commands from executing during the download operation. After that, the file ID (656) and the game checksum are retrieved from the command (658).

Map mode information and game size information are retrieved from the command (660). Keystroke data slot assignment information, if any, is retrieved from the command (662). Finally, a 21-byte game name is retrieved from the command (664). After that, change the SNES session status to "Download Start"
(666) and reset SNES (66)
8). The SNES reset process includes generation of the "hello" message, as described above, and the MCU 190
Responds by initiating the download after determining that the SNES session is "start download". Thereafter, the MCU 190 displays the host computer 7 to indicate that the download operation has been executed.
To the main program (FIG. 29) at block 328.

Returning to FIG. 29, after processing the data in the keystroke input buffer or in the host input buffer, a check is made at block 328 to determine if there is data in the SNES input buffer. If there is data in the SNES input buffer,
The routine branches to block 672 (FIG. 47) where
Read a byte from the SNES input buffer (67
2). The byte read from the input buffer may be 1 byte out of the 6 bytes shown in FIG. Regarding block 674, the information sent from SNES to MCU 190 is also an indication that the download checksum is "OK" and that the game program can be executed.

If the test at block 674 is negative, then a check is made to see if the byte indicates that the download checksum was incorrect (676). If the test at block 676 is negative, the received byte indicates a reset-related "hello" indicating that the SNES is awaiting processing instructions.
Check to determine if it is a signal. 676
If the check at is negative, then a check is made at block 680 to determine if the byte indicates that the download is complete.

If the test at block 680 is negative, then a check is made at block 682 to see if the byte indicates that the memory board test was incorrect. If the check at block 682 is negative, then a final test is made as to whether the bytes read all indicate that the memory board test is OK (684). If the check at block 684 is negative, the routine branches to block 324 (FIG. 29) to test for the presence of data in the keystroke input buffer.

Continuing to FIG. 49, block 674 of FIG.
Download checksum is OK by checking in
, The routine branches to block 686 and sets the SNES state to "OK". After that, change the SNES session status to "Run Game"
(688) and the routine branches to block 324 of FIG.

As a result of the check at block 676,
If the byte in the SNES input buffer was "download checksum wrong", the routine branches to block 690 (FIG. 49) and sets the SNES status to "wrong (NG)". After that, the SNES session state is set to "wait for command" (692).
Since no game program can be run in this situation, the routine branches to block 324 (FIG. 29).

If the processing of block 678 reveals that the byte is a reset-related "hello" indication,
Processing branches to block 694 (FIG. 50). During the reset "hello" process, check for all possible SNES session states. First, at 694, SNES
Check to see if the session is "reset to boot". If so, the routine branches to block 706 (FIG. 51) to send a "wait for command" command to the SNES. After setting the SNES session state to command wait (708), SNES is set to "OK" (710) and processing continues at block 324.
(Fig. 29) is continued.

If the check at block 694 is negative, then a check is made at block 696 to see if the state is "waiting for command" and the routine branches to block 712 (FIG. 52) to use the SNES state. Set inside. If the SNES session state is "waiting for command", an error condition exists because the SNES should not wait for the MCU's command. At block 714, the SNES session state is set to "error" (716) to reset the SNES and identify the error situation (process for the error situation described in more detail below in connection with FIG. 54). The routine branches to block 324 in FIG.

The test at block 700 indicates that the SNE
If it is determined that the S session state is "run game", the routine branches to block 712-.
716, that is, the routine shown in FIG. If the process is in the reset subroutine shown in FIG.
There should be no processing in the game running session state so that the error handling routine of 2 is performed. Similarly, the check at block 698 causes the SNES
If the session state is found to be downloading, the routine branches and also proceeds to block 712, shown in FIG. 52, to repeat the error condition handling.

The check in block 702 confirms that the SNE
If the S session state is found to be "game reset," then processing branches to block 718 (FIG. 53).
Proceed to. At block 718, the MCU 190
Send a game reset command to NES. MCU1
After 90 sends the stored map mode and game size to the SNES (720) and changes the SNES state to OK (722), the session state is changed to game running (724) and the routine branches to Proceed to block 324 of 29.

As a result of the check in block 704,
When the SNES session state is revealed to be in error, the routine branches to block 72 of FIG.
Proceed to 6. At block 726, the SNES state is set to "NG" and the SNES session state is set to "wait for command" (728). The host computer 7 initiates appropriate rescue actions, such as repeating the game program download, and the routine branches to block 324 (FIG. 29).

As a result of the check in block 704, the SNE
If the S session state is not "error", the routine jumps to the "start download" routine shown in FIG. The start of download routine begins as a result of the SNES generating a "hello" command that triggers a download response from the MCU 190. The "start download" process begins by setting the SNES state to busy (730). Thereafter, the keystroke port is aborted and reset (732) so that the download process is not interrupted. The game file ID is sent (734) to the ZILOG communication controller 192 (FIG. 15) coupled to the MCU 190 to identify the game to download. Then, in steps 736, 738, 740, and 742, the download command, the game checksum, the map mode and the game size, and the 21-byte game name are transmitted to the SNES, respectively. The SNES session is then set to download (744) and the routine branches to block 324 of FIG.

FIG. 56 represents the sequence of operations performed by the MCU 190 within the "Reply to Host" subroutine which sends a confirmed or unconfirmed reply to the host computer 7. A check is made to determine if the host port is available for transmission (746). First, if the host port is not ready for transmission, the routine waits until the host port is ready. The host port ready state can be determined by checking if the data is in a given register. Once the host port is ready to transmit, it sends the requested bytes to the host (748) and resets the MCU serial status flag (750) to indicate that a reply has been generated.

FIG. 57 represents the sequence of operations performed when receiving keystroke, host or SNES data at the MCU port. First, at block 752, a check is made at the subject port to determine if any bytes are received.
If no bytes are received, the "receive" process ends. If one byte is received, a check is made as to whether the keystroke (or host or SNES) input buffer is full. If the respective buffers are not full, then the byte is saved to the keystroke (or host or SNES) input buffer and the routine ends. If the keystroke (or host or SNES) input buffer is full, the receiver process ends.

FIG. 58 is a flowchart showing the sequence of operations performed when the MCU 190 detects an error in receiving data on one of the serial ports. If an error is detected, an internal interrupt routine branches to block 758 to determine if there is an error in the received byte. If there is an error, clear the receiver buffer (760),
Delete the incorrect data. Next, the flag that triggers the interrupt is cleared (762) and the error routine ends.

While the present invention has been described in relation to the presently most practicable and preferred embodiments, the present invention should not be limited to the embodiments described, but rather the spirit of the appended claims and It is intended to include various modifications and equivalent changes within the scope.

[Brief description of drawings]

FIG. 1 is a block diagram of an example of a hotel-enabled video game / communication system according to an embodiment of the present invention.

FIG. 2 is a block diagram of a guest room terminal shown in FIG.

FIG. 3 is a flowchart showing a sequence of processing performed by the microcontroller of FIG.

FIG. 4 is a diagram schematically showing an overall process of an embodiment of the present invention.

FIG. 5 is a flowchart showing a first portion of a sequence of processing performed by a host computer controlling hotel-enabled video game play.

FIG. 6 is a flow chart showing a second part of a sequence of processing performed by the host computer controlling the hotel-enabled video game play of FIG. 5.

FIG. 7 is a flowchart showing a third part of a sequence of processing performed by a host computer controlling the hotel-enabled video game play of FIG.

8 is a flow chart showing a fourth part of a sequence of processing performed by the host computer controlling the hotel-enabled video game play of FIG.

FIG. 9 is a flowchart showing a fifth part of a sequence of processing performed by the host computer controlling the hotel-enabled video game play of FIG. 5.

FIG. 10 is a flowchart showing a sixth part of the sequence of processing performed by the host computer controlling the hotel-enabled video game play of FIG. 5.

FIG. 11 is a flowchart showing a seventh part of the sequence of processing performed by the host computer controlling the hotel-enabled video game play of FIG. 5.

FIG. 12 is a detailed flowchart showing the first half of the sequence of processing performed when the SNES engine executes a program from each boot ROM.

FIG. 13 is a detailed flowchart showing the latter half of the sequence of processing performed when the SNES engine executes a program from each boot ROM.

FIG. 14 is a schematic block diagram showing important data and control signals for the SNES engine.

15 is a block diagram of a circuit implemented on the memory board 102 shown in FIG.

FIG. 16 is a diagram showing an example of a memory configuration in a certain operation mode.

FIG. 17 is a diagram showing an example of a memory configuration in another operation mode.

FIG. 18 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 19 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 20 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 21 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 22 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 23 is a diagram showing an example of a memory configuration in still another operation mode.

FIG. 24: Computer / s that can be used with the present invention
FIG. 6 is a simplified block diagram of an example of a video game processing system.

FIG. 25 is a diagram showing a first part of a sequence of processes performed when executing a boot ROM.

FIG. 26 is a diagram showing a second part of the sequence of processes performed when executing the boot ROM.

FIG. 27 is a diagram showing a third portion of the sequence of processing performed when executing the boot ROM.

FIG. 28 is a diagram showing a fourth portion of the sequence of processing performed when executing the boot ROM.

29 is a flowchart showing a sequence of processing performed in a main processing routine by the microcontroller 190 shown in FIG.

FIG. 30 is a diagram showing a first part of a sequence of processes involved in processing keystroke data.

FIG. 31 is a diagram showing a second part of the sequence of processes involved in processing keystroke data.

FIG. 32 is a diagram showing a third part of the sequence of processes involved in processing keystroke data.

FIG. 33 is a diagram showing a fourth part of the sequence of processes involved in processing keystroke data.

FIG. 34 is a flowchart relating to the first half of the host information processing of the microcontroller.

FIG. 35 is a flowchart relating to the latter half of the host information processing of the microcontroller.

FIG. 36 is a flowchart showing a sequence of processes related to command processing of the microcontroller.

37 is a diagram showing a first part of a sequence of processing relating to the execution of the command shown in FIG. 36;

38 is a diagram showing a second part of the sequence of processes related to the execution of the command shown in FIG. 36. FIG.

FIG. 39 is a diagram showing a third part of the sequence of processes involved in executing the command shown in FIG. 36.

FIG. 40 is a diagram showing a fourth part of the sequence of processes involved in executing the command shown in FIG. 36;

41 is a diagram showing a fifth part of the sequence of processes relating to the command execution shown in FIG. 36;

42 is a diagram showing a sixth part of the sequence of processes relating to the command execution shown in FIG. 36;

FIG. 43 is a diagram showing a seventh part of the sequence of processes involved in executing the command shown in FIG. 36;

FIG. 44 is a diagram showing an eighth part of the sequence of processing relating to the execution of the command shown in FIG. 36.

45 is a diagram showing a ninth part of the sequence of processes relating to the command execution shown in FIG. 36;

FIG. 46 is a diagram showing a sequence of processing relating to command execution in FIG. 36;

FIG. 47 is a flow chart showing the sequence of processing involved in processing data from the SNES input buffer of the microcontroller.

48 is a diagram showing a sequence of processes in a first program branch relating to FIG. 47. FIG.

49 is a diagram showing a sequence of processes in a second program branch relating to FIG. 47. FIG.

FIG. 50 is a diagram showing a sequence of processes in a third program branch relating to FIG. 47.

51 is a diagram showing a sequence of processing in a fourth program branch relating to FIG. 47. FIG.

52 is a diagram showing a sequence of processes in a fifth program branch relating to FIG. 47. FIG.

53 is a diagram showing a sequence of processes in a sixth program branch relating to FIG. 47. FIG.

FIG. 54 is a diagram showing a sequence of processes in a seventh program branch relating to FIG. 47;

FIG. 55 is a diagram showing the sequence of processing in the eighth program branch relating to FIG. 47;

FIG. 56 is a diagram showing a sequence of processing performed in a “host response” subroutine.

FIG. 57 is a diagram showing a sequence of processes performed when receiving keystroke data, host data, or SNES data at a microcontroller port.

FIG. 58 is a flowchart showing a sequence of processing performed when the MCU 190 detects an error when receiving data in one of serial ports.

[Explanation of symbols]

 1 ... Guest room television 2 ... Guest room terminal 3 ... Video game controller 4 ... RF line mixer 5 ... RF modem 6,10 ... Micro controller unit 7 ... Host computer 7A ... Memory 8A-8C ... Asynchronous port 9 ... Communication board 11 ... SNES engine Array 12 to 14 ... Modulator 15 ... Mixer

 ─────────────────────────────────────────────────── ─── Continued Front Page (72) Kenji Nishizawa, Inventor Kenji Nishizawa, USA 98006, Bellevue, Sixty Nineth Street, S.E., 13023 (72) Inventor, David Jay McCurtain, USA 98011 , Bossel, N.E., 8th Place, 14447 (72) Inventor Ramin Lavanpey, Washington 98145, USA, P.O Box 45602 (No Address) (72) Inventor Russell G. Brown USA Washington 98053, Redmond, Forty Six, NA, 22501

Claims (57)

[Claims] 1. A system for creating an interactive in-room video graphics display session on an indoor display comprising an array of video graphics processing systems, each video graphics processing system comprising a video graphics program execution processor. A memory system coupled to the video graphics program execution processor for storing a video graphics program; receiving information generated during a room interactive video graphics display; and the video graphics program execution A cabin-ready communication system including a video graphics program execution processor and a microcontroller coupled to the memory system for transmitting the information to a processor. 2. The cabin telecommunications system of claim 1, further comprising an in-room operator having a plurality of control keys for generating keystroke data. 3. The passenger compartment according to claim 2, wherein the operation unit includes a reset key, and the assigned one of the video graphic program execution processing units is reset in response to actuation of the reset key. Corresponding communication system. 4. The passenger compartment communication system according to claim 2, wherein the indoor controller includes a plurality of video game control keys. 5. The cabin-ready communication system of claim 1, wherein the microcontroller includes an input port and at least one buffer connected to the input port. 6. The microcontroller comprises an input port and at least one buffer connected to the input port, and further comprises an interface for coupling the keystroke data to the input port, the microcontroller comprising: The cabin-enabled communication system of claim 2, wherein a test may be repeatedly performed to determine if keystroke data received from the controller is present in the at least one buffer. 7. The cabin-ready communication system of claim 6, wherein the keystrokes are processed by the microcontroller if there is at least 2 bytes of data in the at least one input buffer. 8. The cabin-ready communication of claim 6, wherein if keystroke data is present in the input buffer, the microcontroller can determine if the first byte of data is a header byte. system. 9. If keystroke data is present in the input buffer, the microcontroller determines that the keystroke data in the input buffer is data assigned to the microcontroller and associated video graphics program execution processor. The cabin-ready communication system according to claim 6, which can determine whether or not to indicate that there is. 10. The microcontroller according to claim 9, wherein the received byte is compared with an assigned stream number to determine whether the data assigned to the microcontroller has been received. Guest room compatible communication system. 11. The microcontroller, if keystroke data is present in the input buffer,
The cabin-ready communication system according to claim 6, which can determine whether or not a valid command is received from the indoor controller. 12. The cabin-ready communication system of claim 11, wherein the valid command is a reset command. 13. The cabin-ready communication system of claim 1, further comprising a host computer system for downloading video graphics program data to at least one of the video graphics processing systems. 14. The microcontroller includes an input port and a buffer to be transmitted to the input port, and further includes an interface for transmitting host data to the input port, and the microcontroller includes the at least one buffer. 14. The cabin-type communication system according to claim 13, wherein a test for determining whether host data received from the host computer exists therein can be repeatedly performed. 15. The host controller of claim 14, wherein if host data is present in the input buffer, the microcontroller may perform a check to determine if it has received a valid command from the host computer. Guest room communication system. 16. The cabin-ready communication system of claim 1, wherein the microcontroller includes means for executing at least one memory test command. 17. The passenger compartment communication system according to claim 16, wherein the memory test command is transmitted from the host computer to the microcontroller. 18. The microcontroller includes a plurality of input ports and means for executing a command to modify a baud rate associated with one of the input ports.
The guest room-compatible communication system according to claim 1. 19. The cabin-ready communication system of claim 1, wherein the microcontroller includes means for executing a status check command. 20. The passenger compartment communication system according to claim 1, wherein the microcontroller includes a buffer for receiving information from the program execution processing device. 21. The cabin-enabled device of claim 20, wherein the microcontroller can perform repeated tests to determine if information received from the program execution processor is present in the buffer. Communications system. 22. The cabin-enabled device of claim 21, wherein if the buffer contains information, the microcontroller analyzes the received information and modifies the program execution processor status information according to the received information. Communications system. 23. The guest room support according to claim 21, wherein when the information is present in the buffer, the microcontroller analyzes the received information and sends all the requested information to the program execution processing device. Communication system. 24. The guest room support according to claim 21, wherein when the information is present in the buffer, the microcontroller analyzes the received information and controls a program download operation to the program execution processing device. Communication system. 25. A system for generating an indoor video display screen, the host computer including a storage device storing a plurality of computer programs, and a memory system receiving at least one of the plurality of programs. A first data processing device coupled to the memory system and executing at least one of the plurality of programs stored in the memory system to generate a video display screen on a cabin display device. And coupled to the first data processing device,
An interface task for the processing device and receiving at least one of the plurality of programs to be executed by the first data processing device, thereby storing the plurality of programs in the memory system. Guest room compatible communication system, comprising: 26. At least one of the plurality of programs is a video game program.
Guest room compatible communication system described in. 27. The cabin telecommunications system of claim 25, further comprising a cabin television monitor displaying videographic data by executing at least one of the plurality of programs. 28. The cabin telecommunications system of claim 25, further comprising a display processing unit coupled to the first data processing device to generate a video signal for display on the indoor display. 29. A system for producing a videographic display on a plurality of indoor displays, the host computer having a memory for storing a plurality of programs; and each video game processing device coupled to an associated memory system, An array of video game processing systems for receiving one of a plurality of computer programs, each said video game processing device executing a program stored in an associated memory system, A cabin-ready entertainment system capable of producing a videographic display on one of the displays. 30. The cabin-ready entertainment system of claim 29, wherein the at least one of the plurality of programs is a video game program. 31. Each of the video graphics processing systems has a central processing unit for executing a program, and one of the indoor displays coupled to the central processing unit.
30. The cabin-ready entertainment system of claim 29, including a display processing unit that generates a video signal for display on one. 32. The passenger cabin of claim 29, wherein each video graphics system includes a central processing unit and a boot read only memory that stores a program to be executed by the central processing unit in response to power up. Compatible entertainment system. 33. The cabin-ready system of claim 29, wherein the video graphics processing system includes a central processing unit and an interface control processing unit that receives information to be input to the central processing unit for processing. Type entertainment system. 34. A method of operating a cabin-ready entertainment system having a host computer, an array of video graphics processing systems and a plurality of in-room displays, wherein at least one of the in-room displays has a plurality of videos. Displaying a display menu allowing selection of one of the graphic program options; one of the video graphics processing systems in the array being connected to the at least one of the indoor displays. Assigning, downloading a video graphics program from the host computer to an assigned one of the video graphics processing systems, and selecting one of the video graphics processing systems by the guest. And a step of performing a video graphics program in response, operation methods. 35. The operation method according to claim 34, wherein the downloading step includes a step of monitoring information to be downloaded, and a step of stopping the download operation when the monitored information is not in a predetermined format. 36. The operating method according to claim 35, wherein the monitoring step includes a check step for determining whether a predetermined number of memory banks has been transmitted. 37. The operating method according to claim 35, wherein the monitoring step includes a check step for determining whether a scheduled start address has been transmitted. 38. A method of operating a cabin-ready entertainment system having a host computer, a plurality of in-room display systems and an array of video graphic processing systems, the method comprising: operating a plurality of video graphics programs in each of the plurality of in-room display systems. Displaying an identifying display menu, assigning each of the active indoor display systems with the videographic processing system, and assigning a videographic processing system to the user to select among the active indoor display systems. Operating a video graphics program. 39. The operating method according to claim 38, wherein the displaying step includes the step of displaying a mark indicating a different video game that can be selected for playing. 40. The operating method of claim 39, further comprising downloading the selected video game to a video graphics processing system assigned to the in-room display system in which the selection was performed. 41. The operating method of claim 38, further comprising the step of providing selectable shopping options on the interior display. 42. The operating method of claim 38, further comprising providing communication options that can be selected via the in-room display system. 43. The operating method of claim 42, including the step of providing selectable fax options. 44. The operating method of claim 38, further comprising the step of providing selectable data processing options. 45. The operating method of claim 38, further comprising the step of providing selectable language options. 46. A video graphics processing system having a program execution processing unit and a picture processing unit; and a memory system coupled to the video graphics processing system and including at least one program memory, the program execution processing unit comprising: Executing a program stored in the at least one program memory, the memory system having a predetermined address space, coupled to the main program memory, a plurality of address mapping registers, and the plurality of address mapping registers; And a memory control circuit for controlling the position of the main program memory in the address space of the processing unit based on the contents of the plurality of address mapping registers. 47. A scratchpad memory and the scratch in the address space of the processing unit coupled to at least one of the plurality of address mapping registers based on the contents of at least one of the plurality of registers. A scratch pad memory control circuit for controlling the location of the pad memory.
The data processing system according to item 6. 48. A non-volatile memory and at least one of the plurality of address mapping registers, the non-volatile in the address space of the processing unit based on the contents of at least one of the plurality of registers. 47. The data processing system of claim 46, further comprising a non-volatile memory control circuit for controlling the location of the non-volatile memory. 49. An additional program memory, coupled to at least one of the plurality of address mapping registers, and in the address space of the processing unit based on the contents of at least one of the plurality of registers. An additional program memory control circuit for controlling the location of the additional program memory.
The data processing system according to item 6. 50. The data processing system of claim 49, wherein the additional program memory is boot read only memory. 51. Further comprising decode logic for receiving a digital signal input to each of said plurality of address mapping registers and modifying the contents of at least one of said plurality of address mapping registers.
The data processing system according to claim 46. 52. The data processing system of claim 51, wherein the processing unit includes an address bus and the decode logic receives the digital signal on the address bus. 53. An interface processor for inputting information to said program execution processor and receiving program information to be stored in said main program memory for execution by said program execution processor, further comprising: The data processing system according to claim 46. 54. The method of claim 53, further comprising at least one data bus coupled to the program execution processor and at least one buffer memory coupled to the interface processor and the at least one data bus. The memory system described. 55. An address bus coupled to the program execution processor and control logic coupled to the address bus and the interface processor, the control logic being received on the address bus. 6. The I / O operation of the interface processing device is partially controlled in response to a signal.
The memory system according to item 3. 56. The program execution processor includes at least one data bus, and the control logic includes a plurality of latches coupled to the interface processor to receive information or the at least one data bus. 56. The data processing system according to claim 55, wherein information is input to. 57. Stop signal generation logic coupled to the interface processing device and the program execution processing device, for inputting a stop control signal to the program execution processing device in response to a signal from the interface processing device. 54. The data processing system of claim 53, further comprising.