WO2000006268A1 - Interface d'entree/sortie et abstraction de dispositifs - Google Patents

Interface d'entree/sortie et abstraction de dispositifs Download PDF

Info

Publication number
WO2000006268A1
WO2000006268A1 PCT/AU1999/000595 AU9900595W WO0006268A1 WO 2000006268 A1 WO2000006268 A1 WO 2000006268A1 AU 9900595 W AU9900595 W AU 9900595W WO 0006268 A1 WO0006268 A1 WO 0006268A1
Authority
WO
WIPO (PCT)
Prior art keywords
iocb
message
game
hardware
cpu
Prior art date
Application number
PCT/AU1999/000595
Other languages
English (en)
Inventor
Anthony Wayne Bond
Ronald Edward Mach
Original Assignee
Aristocrat Technologies Australia Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aristocrat Technologies Australia Pty Ltd filed Critical Aristocrat Technologies Australia Pty Ltd
Priority to NZ509450A priority Critical patent/NZ509450A/xx
Priority to US09/743,950 priority patent/US6968405B1/en
Priority to AU48900/99A priority patent/AU748434B2/en
Publication of WO2000006268A1 publication Critical patent/WO2000006268A1/fr
Priority to ZA2001/00616A priority patent/ZA200100616B/en
Priority to US12/181,057 priority patent/US20090198846A1/en
Priority to US12/861,389 priority patent/US8719470B2/en

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3202—Hardware aspects of a gaming system, e.g. components, construction, architecture thereof
    • G07F17/3223—Architectural aspects of a gaming system, e.g. internal configuration, master/slave, wireless communication

Definitions

  • the present invention is a means for communication between a central processing unit (“CPU” or microprocessor) and an input/output control board, for controlling peripheral devices associated with a gaming machine.
  • CPU central processing unit
  • input/output control board for controlling peripheral devices associated with a gaming machine.
  • gaming machines have always been monolithic. That is, they have a single Central Processing Unit (CPU) running a single block of software that controlled all the hardware directly. Some hardware devices have a micro-controller in them to perform tasks for an explicit hardware function, but the game CPU to hardware interface is still monolithic in nature.
  • An example of two smart devices that are controlled by the single game CPU are the following: U.S. Patent No. 5,190,495 (Taxon, and assigned to Bally Manufacturing Corp.) for a high capacity coin hopper (a "super hopper”) for a gaming machine which uses a micro-controller, but still has traditional control lines as if it were a non-intelligent hopper and U.S. Patent No.
  • the game CPU could dedicate more time running the game software and less time interfacing to the hardware.
  • IOCB Input/Output Control Board
  • PCT/AU99/00373 for an Input/Output Control System.
  • the microprocessor of IOCB in conjunction with the CPU of the gaming machine, controls the operation of the gaming peripherals. Revisions to the gaming software and additional peripheral devices, are controlled using the IOCB.
  • the IOCB thus provides the extra level of intelligence to the gaming machine, provided there are reliable communication between the IOCB and the game CPU.
  • the present invention describes communications between the game CPU and the IOCG.
  • a factor in establishing reliable communications between the game CPU and the IOCG is having properly abstracted hardware to allow the software on the game CPU to adapt and correspond to new hardware arrangements with fewer changes to the game CPU hardware and software.
  • the present invention further describes the hardware abstraction protocol.
  • CPU central processing unit
  • IOCB input outpLit control board
  • Still another object of the present invention is to provide a communications protocol that includes a means of identifying the recipient of the communication.
  • Another object of the present invention is to provide a communications protocol that includes a means of sequentially numbering the transmissions.
  • Still another object of the present invention is to provide a communications protocol that contains a virtual device message.
  • Another object of the present invention is to provide a comrmmications protocol that includes a means to validate the com ⁇ mnication and verify the integrity of the communication.
  • Still another object of the present invention is to provide a means to store communication codes for communicating with the peripheral devices associated with the gaming machine within memory means of the input/output control board.
  • Yet another object of the present invention is to provide a means to store meta-commands for the control of specific hardware devices.
  • the present invention involves a high speed serial interface that enables communication between the central processing unit (CPU) of a system of playing games of skill or chance or entertainment (a gaming machine) and an input/output control board (IOCB) for controlling peripheral devices associated with the gaming machine.
  • the interface has either an Industry Standard Architecture (ISA) bus, a Universal Serial Bus (USB) or the IEEE 1394 FIREWIRETM bus.
  • ISA Industry Standard Architecture
  • USB Universal Serial Bus
  • IEEE 1394 FIREWIRETM bus IEEE 1394 FIREWIRETM bus.
  • the IOCB facilitates the communications between the game CPU and the peripheral devices.
  • peripheral devices can be one or more of the following: for example, displays, buttons, coin hoppers, coin mechanisms, bill validators, reel mechanisms, etc., as known to those skilled in the art.
  • Communication uses a framed message transport protocol, which includes a message header, a body containing a virtual device message and a packet validation signature.
  • the message header identifies the intended recipient of the message.
  • the body includes the message for the recipient.
  • the packet validation signature includes a termination code and a means for checking if errors have occurred in the transmission.
  • the game CPU communicates to the gaming peripheral devices by sending the device messages across the ISA bus to the IOCB.
  • the IOCB then routes the device messages to the appropriate device.
  • Use of the IOCB and the high speed interface enables the game CPU to use more of its available f inctions for controlling gaming functions rather than the operation of its associated peripheral devices.
  • Fig. 1 illustrates two standard gaming devices (i.e., Video Poker and Reel Slot) in which the present invention can be applied;
  • Fig. 2 illustrates the organisation of the microcomputer board; and the game, operating system, and graphical user interface software functions;
  • Fig. 3 illustrates the interaction between the Input/Output Control Board of the present invention and the main game processor functions
  • Fig. 4 illustrates the organisation of the Input/Output Control Board of the present invention and game peripheral functions
  • Fig. 5 illustrates the expansion of a gaming system using multiple
  • Fig. 6a and Fig. 6b combined are a flowchart of the Interrupt Service Routine for the game CPU software to monitor the message status and data ports for message traffic;
  • Fig. 7 is the flowchart for the Interrupt Service Routine of the IOCB for software that monitors the message status and data ports for message traffic. Detailed Description of The Preferred Embodiments.
  • An intelligent input output control board (“IOCB”, or “control board”) is designed to work in conjunction with gaming machines, such as the video poker machine 10 or slot machine 20 shown in Fig. 1.
  • gaming machines such as the video poker machine 10 or slot machine 20 shown in Fig. 1.
  • each of these machines contains a microcomputer board 30 (not shown in Fig. 1) which contains the instructions for operating the games (i.e., the game software).
  • elements common to these machines include a display 11, a coin slot 12, a bill or card (credit card, debit card, other forms of electronic media) acceptor slot 13, a coin hopper/receptacle 14, a plurality of game b ittons 15 which may contain lights 16 therein.
  • Each gaming machine offers several ways in which the game player can deposit moneys into the machine, receive change where appropriates, in order to place bets on the conclusion of the particular game or games.
  • a handle 21 is present which can be used to operate the machine.
  • the game buttons, lights and handles offer a means of allowing the player to interact with the gaming device, with the possibility of affecting the game conclusion.
  • Mechanical and electrical components of these machines known to those skilled in the art are not illustrated. Included among the known functions of these gaming machines are the ability of the game to generate a random conclusion, and to offer a variable return play based upon a particular game conclusion and the game conclusions of other gaming devices with which a particular gaming device may be networked.
  • these gaming devices have the ability to vary the payout, such as paying a progressive jackpot which provides an additional return payovvt based upon the history of the various game conclusions prior to a particular individual's playing of the game, whether on a specific gaming machine or from one or more gaming machines networked to the specific gaming machine being played.
  • These gaming devices also generate a variety of audio and visual effects, both during game play and between game play.
  • Some other components known to those skilled in the art and not shown in the drawings, include bells, reel mechanisms, dice mechanisms, wheel mechanisms and feature displays. In addition to their use for playing games of chance, these machines can also be used for playing games of skill, or for entertainment purposes.
  • the main game processor 30 system (Fig. 2) described in the present invention is predicated on using an industry standard MCB 32 with a standard OS 50 combined with a GUI 52 (Fig. 2).
  • the MCB 32 has a central processing unit (CPU or microprocessor) 34, (also referred to as the game CPU), memory means 36 including volatile storage means 38 and non-volatile storage means 40, secLired memory storage means 42 and nonsecured memory storage means 44.
  • CPU or microprocessor also referred to as the game CPU
  • memory means 36 including volatile storage means 38 and non-volatile storage means 40
  • secLired memory storage means 42 and nonsecured memory storage means 44.
  • operating system 50 and GUI 52 are in communication with appropriate game software 54, with the OS 50, GUI 52 and game software 54 in communication with each other and the game CPU 34.
  • This standardised hardware architecture and OS approach is Lised for three unique reasons:
  • the platform can utilise the bviilt-in multi-media and networking functions of the OS 50 and GUI 52;
  • the electrical interface 46 to the system is an industry standard for which systems and peripheral devices are readily available; and (3) it utilises an interface software system 70 for control of its on-board peripheral devices.
  • the interface software system 70 is described in greater detail in Aristocrat's PCT Patent Application No. PCT/AU99/00500, for a Method of linking devices to gaming machines.
  • the combination of an OS 50 and GUI 52 provide the game developer with a platform that is supported by both industry standard development software and off-the-shelf standard function software for advanced graphics, sound generation, multi-tasking and networking (shown schematically in Fig. 3).
  • the availability of off-the-shelf feature software plus the wealth of development software available significantly reduce the work required to effect integration of new multi-media and network features.
  • the OS 50 and GUI 52 also provide a common software interface (i.e., interface software) to the system hardware 71 (shown schematically as video hardware 72, sound hardware 74 and network hardware 76 in Fig. 2) which allows the software to migrate from hardware platform to hardware platform, without modification to the OS 50, GUI 52 or game software 54.
  • Video hardware 72 includes the display devices described previously in this application, but not meant to be limited to them, such as CRTs, LCDs, etc. that are known to those skilled in the art.
  • Sound hardware 74 includes, but is not meant to be limited to, a variety of speakers, bells, whistles, buzzers, and affiliated electrical components as known to those skilled in the art.
  • network hardware 76 includes, and is not meant to be limited to, various microprocessors, storage devices, memory means, communications devices such as modems and computers, wired communications lines such as telephone networks, both public or private, wireless communications systems, as well as such networking hardware known to those skilled in the art.
  • the interface software system 70 described in Aristocrat's PCT Patent Application No. PCT/AU99/00500, for a Method of linking devices to gaming machines, is specifically designed to isolate the game software 54, OS 50 and GUI software 52 from variations in the hardware platform, such as may occur when using peripheral devices having different interface requirements because they are produced by different manufacturers.
  • Interface software 70 acts as a translator between the complex communication systems of the OS/GUI combination and the bit by bit control functions of the MCB peripherals. Additionally, the design of the interface software 70 allows the ability to "plug and play" new peripherals that may not have been available at the time game software 54, OS 50 and GUI 52 software were written.
  • this interface software system 70 allows the game software 54, OS 50 and GUI 52 to migrate seamlessly from hardware platform to hardware platform, without requiring the actual redesign and re-certification that is normally associated with hardware changes.
  • the industry standard electrical interface 46 to the system further isolates the game and its software from variations in the main game controller electronics 30 (see Fig. 2). Using a standard electrical interface 46 allows the gaming manufacturer to design the IOCB 100 to a common electrical interface, without having to account for variation in the design of the MCB 32.
  • the standard electrical interface 46 also allows the gaming manufacturer to specify multiple MCB manufacturers for game production, without requiring numerous electrical interfaces that would be specific to individual MCB manufacturers.
  • this interface is a serial port, the preferred embodiment being an Industry Standard Architecture (ISA) bus, although other interfaces, such as the Universal Serial Bus (USB) or IEEE 1394 FIREWIRETM bus can be utilised.
  • ISA Industry Standard Architecture
  • USB Universal Serial Bus
  • FIRE WIRETM bus is a high speed serial bus developed by Apple Computer and Texas Instruments, and it is capable of connecting a plurality of components using a high speed interface.
  • the I/O Control Board The Input/Output Control System described in this specification is based on using an IOCB in a gaming device 10 as a means for controlling generic game peripheral devices 71 without the necessity of custom programming the gaming machine 10 to accommodate any specific game peripheral device.
  • the IOCB system 100 uses an embedded microprocessor 102 (the IOCB
  • IOCB microprocessor 102 is in communication with the MCB 32 of the gaming machine 10 using a communications interface 104.
  • IOCB microprocessor 102 has memory means 106, which includes storage means 108, means for volatile memory storage 110 and means for non-volatile memory storage 112, such as, but not meant to be limited to, firmware or EPROM (Electronically Programmable Read Only Memory) memory.
  • Memory means 106 further includes secured memory means 114. As shown in Fig.
  • game play interface functions managed by the IOCB include a plurality of game buttons 117, a plurality of lamps 118, and a plurality of both high and low resolution feature displays 120 (not shown); coin acceptors and validators 174, bill acceptors and validators 180, bill and coupon dispensers 182 (not shown), card acceptance, card validation and dispensing 186, and coupon acceptance 188; as well as means for control and message routing for the secondary communications bus 250.
  • Each of these peripheral devices are connected to the IOCB at ports 210. Ports 210 can be either serial ports, parallel ports, game ports, or other device interface ports known to those skilled in the art, and are not shown for purposes of clarity,
  • the IOCB 100 monitors the status of all input functions using interface software 70, described in Aristocrat's PCT Patent Application No. PCT/AU99/00500, for a Method of linking devices to gaming machines, buffering and translating their state into a standard control code which is then transmitted to the MCB 32 for processing by the game software 54.
  • the IOCB 100 also accepts output control codes for driving a plurality of game play interfaces 140, 170 and 190, and translating the control codes into the specific format required for the interface and handling all drive and communications protocols required by the game player interfaces.
  • new game play interfaces 300 (Fig. 5), not specifically configured for in the IOCB board 100, are handled by the secondary communications bus 250.
  • the secondary communications bus 250 handles all communications needed for future game play interface expansion, arbitrating the communications and dynamically configuring the new interfaces for operation with the I/O control board interface software.
  • IOCB system 100 provides a generic translation and control interface between the MCB 32 and the game play interfaces. The IOCB 100 further unloads and receives all configuration and real-time game play interface control fLinctions from the MCB 32, leaving the main game MCB 32 free to manage game play, networking and multi-media display functions.
  • the first set of game play interfaces under direct control of IOCB 100 are the player deck interfaces 140 (Fig. 4).
  • the player deck interfaces include deck buttons 117 L sed in game play, associated deck button lamps 118, and all low resolution displays 120 used for indicating game play status.
  • Player deck interface inckides control means 142 in electrical communication with these individual components, and in communication with microprocessor 102 and memory means 104.
  • Player deck interface control means 142 receives and monitors all deck button switch contacts and translates the key press information into specific game key press codes for transmission to MCB 32 by communications linkage 104.
  • Player deck interface control means 142 includes means for driving deck button lamps 118 and displays 120.
  • Player deck interface control means 142 has translation means to translate command codes received from MCB 32 into specific messages and lamp controls, and further includes means to provide all refresh and update functions required for proper display operation.
  • Money handling interfaces 170 is the second set of interfaces under direct control of IOCB 100 (Figs. 3 & 4).
  • Money handling interfaces 170 include a control means 172 which controls peripheral devices involved in the acceptance/validation of coins, bills and coupons, vending of coins, bills and coupons, and acceptance of currency/credit via electronic media (i.e., credit/debit cards) (Fig. 4).
  • Money handling control means 172 is in communication with these peripherals, and in communication with microprocessor 102 and memory means 106.
  • Coin, bill and coupon acceptance/validation is accomplished via dedicated currency validators 174 which accept and verify the authenticity of the currency.
  • Money handling control means 172 and microprocessor 102 are in communication with and monitor the validator's 174 operations, money handling control means 172 providing all control and interface functions required by the currency validator 174 for proper acceptance and validation.
  • Money handling control means 172 in conjunction with IOCB microprocessor 102 formats and translates the currency information for transmission to MCB 32 via communications link 104. It shoLild be noted that certain coupons may require additional validation by the main game processor 32, in which instance money handling control means 172 and IOCB microprocessor 102 transmit the coupon information received from the coupon validator 174 to the MCB 32 for verification. Once verification codes are received back from the MCB 32 by microprocessor 102 and money handling control means 172, the coupons are accepted.
  • Coin, bill and coupon dispensing is handled by separate vending peripherals such as, coin hoppers 178, and bill/coupon dispensers 184.
  • IOCB 100 controls the operation of the coin hoppers 178 and bill/coupon dispensers 184 directly.
  • Coin hopper control means and bill/coupon dispenser control means are controlled by money handling control means 172 in communication with microprocessor 102.
  • the IOCB 100 initiates and controls all vending of money in response to command codes from the MCB 32 and money handling control means 172 in turn returns confirming vend codes to the coin hoppers 178 or bill/coupon dispensers 184.
  • Electronic media 186 such as credit cards, debit cards, smart cards, or other media known to those in the art, is handled by custom readers 188 which accept and read the identification information from the specific media. These readers 188 transmit this data to the money handling control means 172 which, in conjunction with microprocessor 102, monitors the outpLit from the readers 188, provides any control signals required for acceptance, formats the information, and transmits it to the MCB 32 by communications link 104 for final validation and game credit. Game security is also controlled by the present invention.
  • the game secLirity interfaces 190 include game security control means 192 which controls peripheral devices such as game door switches 194, electromechanical or electronic accoLmting meters 196, configuration/accounting key switches 198, and the MCB's secured memory storage 114.
  • Game door switches 194 are monitored by game security control means 192, in conjunction with and in communication with IOCB 100's non-volatile monitoring system 116, which detects a door open condition, and can do so even during a power down situation.
  • game security control means 192 Upon power up, game security control means 192 receives signals from the door switches 194 and reads the condition of the doors (i.e., whether they are open or closed). Game security control means 192 reports any and all game accesses (indicated by a door open condition) to the MCB 32 for error handling and system notification.
  • the electro-mechanical or electronic meters 196 are incremented by game security control means 192 in response to commands from MCB 32. These meters are known to those skilled in the art, and as examples and not meant to be a limitation, generally function to indicate the number of credits remaining, money deposited, etc.
  • IOCB 100 stores the remaining balance of the meter count(s) in secure memory storage 114.
  • secure memory storage 114 Upon return of system power, secure memory storage 114 transmits the meter increment function to the meter 196 and the meter increment function is completed.
  • Game security control means 192 is in communication with and monitors the status of the configuration/accounting key switches 198 and upon a status change of these key switches, game security control means 192 reports the new state to MCB 32.
  • IOCB 100 also contains the secure non-volatile data storage means 114 for the main game processor 52. Secure storage means 114 can only be accessed following an unlocking procedure issued by the MCB 32. Secure storage means 114 includes a lock out means 199 which is under control of MCB 32. Access to secure storage means 114 is timed to prevent corruption of the secure storage in case a failure occurs before the main game processor can reset the safety lock out 199. IOCB 100 has power monitoring means 200 in communication with microprocessor 102, such that IOCB 100 can determine an imminent power failure and prevent access to the secure storage means 114. Secondary communications bus 250 is in communication with microprocessor 102 and controlled by IOCB 100.
  • Secondary communications bus controller means 252 allows expansion of the IOCB 100 beyond the standard set of interfaces by allowing the connection of additional IOCBs 100 which in turn may be connected to additional peripheral devices, such as shown in Fig. 5.
  • first IOCB 100 acts as a router for commands from the game program, forwarding commands and data using its secondary communications bus 250 to the first communications link 104 of a second (remote) IOCB 100 and verifying the presence and integrity of all message traffic on the secondary communications bus 250.
  • additional gaming peripherals can be added withovit the necessity of custom programming or other modifications of the game software.
  • the IOCB thus provides a generic interface to the microcomputer board of a gaming machine.
  • the IOCB removes the need for configuration specific control routines in gaming software and also isolates the game software from any changes in hardware.
  • the resLilting combination of MCB and IOCB provides a game design with built-in high-end multi-media and network capability that can operate on several different MCBs without modification of the game software, yet still maintaining specific control of the game: player interface in real-time.
  • the IOCB allows the ability to "plug and play" new peripherals that may not have been available at the time game software, or the operating system of graphical user interface software were written.
  • the IOCB acts as a control buffer for the external game play interface; the IOCB translates the generic codes of the game software into the specific codes of the individual interfaces for the various peripheral devices. In this way, specific control codes for an interface and the associated communications protocols required for communicating to the interface can be generalised in the game software with the translation and specific protocols/control codes encoded directly into the IOCB firmware.
  • the expansion communications bus (the secondary communications bus) allows new game play interfaces to be added in the future as new game player interfaces become available.
  • the system identifies the new interface and passes its configuration to the appropriate interface software on the MCB. Once identified, the interface software on the MCB locates and loads the additional interface software required to handle the new interface, with the IOCB acting as a message handler between the MCB and the new interface.
  • the present invention is the communications protocol used between the game CPU 32 and the IOCB 100.
  • the secondary communications system and bar 250 are described in our PCT patent application for a Secured inter processor virtual device communications system, No. PCT/AU99/00389. Comn mications between the IOCB and the virtual hardware attached to it are handled through low level virtual device drivers. Communications between the game CPU 32 and the IOCB 100 are handled by 46 and communications intergrade 104 of the IOCB, respectively.
  • communications interface 104 is a high speed interface such as, but limited to, Universal Serial Port ("USB"), or IEEE 1394 "FIREWIRETM". FIREWIRETM is the registered trademark for a serial bus that allows for connection to multiple devices at high speed.
  • the preferred embodiment Lises the ISA bus, or Input/Output memory bus, to create a parallel message data port, a message status port, and an inter pt request (IRQ) line that allows the IOCB to signal the game CPU when the status port has changed and an interrupt line to the IOCB to signal the IOCB whenever a message data byte is read from, or written to, the message data port by the game CPU.
  • the message data port has a latched memory byte for read and a separate latched memory byte for write.
  • the status port is read and write accessible to the IOCB, and read-only to the game CPU.
  • Virtual ID this byte is a circuit number the game CPU uses to route the message to the correct software driver. Each software driver is given a different circuit number. The software driver will interpret the message command and body received from the device in the context of that device type. Any device messages to the IOCB device itself, are addressed to Virtual ID zero. This address is for the abstracted hardware is assigned by the IOCB and reported to the game CPU in the request table or new hardware messages. Size: this byte is the character length of the packet from Virtual ID to the ETX inclusive; Sequence #: this byte is the sender's next sequential transmission number. Thus, the sequence number of messages going from the game CPU and to the game CPU are kept and tracked separately. The receiver maintains an expected sequential reception number corresponding to the sender's next expected sequence number.
  • This sequence number initiates to zero and increments by 1 for each SLiccessful transmission, wrapping at 256 back to 1.
  • the value of 0 is only used on initial setup, and if zero, the receiver will reset its expected sequence number.
  • Successful transmission implies the receiver has accepted the valid transaction (all packet criteria have been satisfied), and responds to the sender by transmitting an acknowledge (ACK) packet to virtual ID zero, which will cause both the sender and the receiver to increment the sequence number for the sender's next expected message.
  • ACK acknowledge
  • This receipt of ACK packet is itself not acknowledged; Command: this byte informs the receiver what to do with the date (if any) in the body of the message.
  • An ACK command for example, acknowledges the sender's last received packet and would have zero bytes in the body of the message.
  • the IOCB would send a
  • LINK REQUEST command (with zero bytes) to the game CPU on power-up, which requests a communications link.
  • Another example not meant to be limiting would be a Bill Acceptor transaction with a command of B stating the Bill Denomination is the message body;
  • the message body is a variable number of bytes from 0-248, which contains pertinent date regarding the transaction. This field may be the denomination of the bill accepted, it may be the coin denomination, or it may be a Player's Account processed by the Magnetic Card Reader. The actual specifics are determined by the Virtual Device involved.;
  • ETX this End of Transmission (ETX) byte is used for packet validation
  • CRC-18 this 2-byte field is a 16-bit Cyclic Redundancy Check (CRC) value which is generated using a 16-bit reverse polynomial-based algorithm performed on each transmitted/received byte.
  • CRC Cyclic Redundancy Check
  • the resultant 16-bit value, called the seed is used as the initial value prior to applying the CRC algorithm to each byte in the packet, the packet is CRC'd from Virtual ID to ETX inclusive.
  • the message status port has the following construction:
  • RA Receiveive Aborted
  • the IOCB should the IOCB detect a communication error while it is receiving data, or the IOCB has detected a change to the hardware side that could affect any messages being set to it, this bit is set indicating abort of the transmission from the game CPU.
  • the game CPU monitors this bit prior to sending a character, and, if set the game CPU will abort the balance of the transmission and retry sending the message after three time-out intervals, when both the ready-to-receive bit is set and the receive aborted bit is cleared.
  • RTT Ready To Transmit
  • the OCB's hardware is notified via an interrupt, and the IOCB resets this bit if there are no bytes to send from the current message. If there are more bytes to send, the IOCB places the next byte on the message port, without resetting the ready-to-transmit bit and triggers the Interrupt Request to the game CPU.
  • TA Transmit Abort
  • the IOCB detects an internal transmission error, or the IOCB has detected a change to the hardware side that could affect the message being sent, it will set this bit indicating the remainder of the message will not be sent. If the game CPU detects this bit set, it will clear any previous characters received and abort the receive process. Busy: to prevent the game CPU from an erroneous time-out on a data transfer, the IOCB will set this bit if the IOCB is busy processing a critical application, then resetting the bit upon completion.
  • the game CPU will ignore the inter-character time-out interval, but, upon expiration of the inter-message time-OLit interval, which is three times the inter-character time-out, the game CPU will reset any pending messages being received or transmitted.
  • O this bit is reserved for future use. Zero: should the IOCB and the connection between the game CPU be disconnected, the bus input of the interface hardware will be high. To prevent erroneous actions based on bit levels being set, this bit must always be reset. If this bit is set, this bit must always be reset. If this bit is set, the hand shaking flags of this register should be ignored. Reset: whenever the IOCB is powered up or reset, this bit is set which notifies the game CPU of these conditions. This alerts the game CPU to set the "state" of the gaming devices in the machine. Whenever initial communication is established between the IOCB and the game CPU, this flag is reset. The following rules govern the generation of interrupt request during message transfers (Table 1)
  • the IOCB receives an interrupt.
  • the game CPU receives an interrupt.
  • RTT & Not Busy & Not TA IOCB has a byte to be read.
  • the communications link between the game CPU and the IOCB uses either USB or FIREWIRETM
  • message traffic is controlled with time-outs.
  • the message port is bi-directional, there is a set of timers for messages going from the IOCB to the game CPU and another set of timers for messages going from the game CPU to the IOCB.
  • Each component, both the IOCB and the game CPU keeps track of these two timer sets.
  • the inter-character time- out interval expires, the current message being transferred is in error, and will be aborted (see 458, 462, 464 for the game CPU, in Fig. 6a. and 508, 510, 521, for the IOCB in the Fig 7). If the busy flag 403 is raised while the message is being transferred, the game CPU will give the IOCB an extra five time-out periods before declaring an error and aborting the message transmission (see 403-406) in Fig. 6a). The inter-character time-out is not cumulative, and is reset after each new character is received (see 418, 424, 465) for the game CPU, in Fig 6 a and 416, 428, for the IOCB Fig. 7.
  • the character received after an inter-message time-out will be treated as the start of a new message packet, (see 412, 414, 416, 418 in Fig 6 for the game CPU, and 530, 532, 534, 536, Fig. 7 of the IOCB).
  • the CRC is checked to see if the packet has any errors. (See Fig. at 438 and 548 in Fig.
  • the receiving communication driver After receiving a good message, the receiving communication driver will generate a acknowledgment (ACK) message to virtual IDO with the command code for ACK and the sequence number of the message being acknowledged. Since the ACK message is addressed to virtual IDO, the starting value for the CRC's O. The CRC algorithm is applied to the ACK message, and the resulting CRC is appended. The ACK message is then queued to be sent next. The ACK message is not acknowledged, nor does it affect the sequence numbering of the transmitting side, or the expected sequence number on the receive side. While the transmitting side is waiting for an ACK message corresponding to a sent packet, it can continue to receive packets.
  • ACK acknowledgment
  • the sender will expect the very next packet after the current packet and after the inter- message timeout, to be the expected ACK message. Therefore, if after a time period corresponding to the sum of an inter-message timeout period and an inter-character timeout period of another packet that isn't an ACK message for the packet sent, the sender will resend the packet. The sender will retry sending a packet three times. If after three retries there still has been no acknowledgment for the pocket the sender will request the other side to verify the existence of the virtual ID in the packet. If the virtual ID is not verified, there is an error.
  • IOCB are shown in Figs. 6a and 6b.
  • the process is initiated when the game CPU 32 sends an interrupt reqLiest to the IOCB at 399.
  • the first step is to determine whether an IOCB is present and connected to the game CPU
  • the IOCB checks the value of the message statu.s port and sets the procstat to zero, at 400.
  • the system determines whether [the procstat byte] is set to status zero at 401.
  • a "yes" indicates that the IOCB is disconnected from the game CPU at 402, an error is set, the communications protocol is exited and a "link missing" error is displayed.
  • the IOCB checks whether the bit is Bvisy. If yes, it indicates the bit is processing an application and there should be no interruption consequently, the IOCB sets the inter-byte timeout counter to three times its normal period at 404.
  • the CPU will transmit to the IOCB on expiration of the extended inter- byte timeout at 405, and if the transmission to the IOCB is completed, at 406 the inter-byte timeout counter is set to the value of the inter-message timeout, approximately 1-2 milliseconds as described previously. If, however, the status was not busy at 403, or after the system has become free at 406, the game CPU determines whether the IOCB's status is Ready-to-Transmit (RTT) at 408. If the IOCB is not ready to transmit, at 149 at game CPU, as will be described further in Fig 6b, determines at 450 whether the IOCB's status is Transmit Abort (TA).
  • RTT Ready-to-Transmit
  • the game CPU gets the appropriate byte from the message port and is set at message zero (or circuit number zero).
  • the system determines whether the message [at register] zero has a valid virtual ID; if the virtual ID is valid at 418, the system checks the bit for Transmit Abort Status (Fig. b at 450).
  • the game CPU determines whether the inter-byte [timeout?] counter has expired. If this timeout has not expired, at 424 the system gets a byte from the message port, puts it in message [receiving] and resets the inter-byte time out counter, and, the receiving messages is not greater than or equal to 1 at 426. The game CPU determines whether the message being received has a value that is greater than the messages received plus one (at 454). If this is determined to be "YES" at 435, the system loops back to 419.
  • the game CPU proceeds according to reference numeral 420.
  • receiving is set to message [1] at 428, and, at 430, the vahie of message [1] is not greater than 4, game CPU proceeds according to the protocol at reference numeral 420. At this point 420, the message is discarded, the inter-message timeout counter is set, receiving is set to zero, and the bit is then checked to see if its status is Transmit Abort at 450 (Fib 6b). If at 430, the value of message [1] was greater than 4, at 432 receiving is set and the game CPU determines (Fig. 6b) whether the TA bit is set.
  • the message is sent to the communications driver for verification using a CRC check at 438, after which a determination of the status of the bit for TA is made at 450 (Fig. 6b).
  • Fig. 6a Other events, shown in Fig. 6a that will trigger the "Status TA" inquiry (Fig. 6b) at 450, are the following: During the receiving stage, at 420, expiration of the inter-byte timeout at 422, a non-expiration of the inter-message timeout at 422, or an invalid virtual ID at 416, will cause the game CPU to discard the message being, set the inter-message timeout counter and set receiving to O. If the message being received has a valid virtual ID, receiving is set to 1 for the received massage. Review is set to 5 and the inter-byte timeout counter is set at 418, then the system checks whether the status is set to Transmit Abort at 450 (Fig. 6b).
  • the game CPU checks for Transmit Abort status at 450 (Fig. 6b).
  • the game CPU checks the Transmit Abort Status of the byte at 450 (Fig. 6b). Referring now to Fig. 6b, at 450 the game CPU determines whether the
  • IOCB is set for Transmit Abort and whether the receive value is greater than zero. If this is a "yes”, at 452 the message is discarded, the inter- message timeout counter is set and receiving is set to zero, and the protocol proceeds as if a "no" answer was received at 450, to reference numeral 454. At 484, the game CPU determines the status of the Ready-To-Receive
  • RTR Receive Aborted
  • RA Receive Aborted
  • a transmit message is sent to the message port. If the vahie of the message transmitted is equal to a value of one less than the number of messages transmitted at 466, then at 464, the inter-message timer counter is reset, transmission is set to zero, and the system returns from the interrupt. Similarly, at 468, the inter-byte timeout counter is reset or after the resend transmission flag has been reset at 462, the system will return from the interrupt.
  • FIG. 7 The interrupt service ro itine of the IOCB is shown in Fig. 7. This chart: illustrates monitoring the message status port and the data port for message traffic from the IOCB.
  • the IOCB sends an interrupt request at 499 to the port, which at 500 sets the IRQ line to FALSE.
  • the IOCB determines if the port is being read at 502. If the port is not being read, the IOCB determines if the port is being written at 518. If the port is not being written, at 550 at the IRQ line. If it occurs, at 552 the IRQ line is toggled to the game CPU, allowing a return from the interrupt at 553.
  • the inter-message timer counter is set at 505 and the IOCB determines if the port is written at 518, as described above. If the bit status is Ready to Transmit at 504, and at 508 the inter-byte times has expired, the resend flag is set to TRUE at 510. This is followed by the inter- message timer counter being set at 505, and a determination as to whether the port is being written at 518, as described above.
  • the inter-message timer counter is set, the number of transmission is set to zero, and the bit is cleared of its RTT status.
  • the IOCB determines if the port is written, at 518, as described above. If at 214, the number of transmissions is less than the number of transmitted messages, at 516 the IOCB sends a transmit message to the message port, sets the IRQ line to TRUE, and resets the inter-byte timeout counter.
  • the IOCB determines if the port is written, at 518, as described above.
  • the IOCB determines the port is being written at 516, if its status at 520 is not Ready to Receive (RTR), then at 522, the status RTR byte is ignored, the inter-message timer coLinter is set, receiving is set to zero and the status byte is cleared.
  • the IOCB addresses the IRQ line at 550, as previously described. If the virtual ID for RCV[0] is not valid at 534, the IOCB ignores the byte, clears the status RTR at 522, and, as previously described, proceeds to address the IRQ line at 550.
  • the IOCB ignores the byte, clears the status RTR at 522, and, as previously described, proceeds to address the IRQ line at 550.
  • the receiving message is greater than zero, but at 526 the inter-byte has not timed out, then at 528 the byte is put in RCV (receiving mode) and the inter-byte timeout counter is reset.
  • the IOCB determines whether receiving 1 at 538. If at 538 receiving 1, and the byte is greater than 4 at 540, at 542 the byte is put into receiving. If the value for the received message is equal to the value of the previously received messages plus 1 (at 546), the byte is sent to the communications driver for validation using a CRC check at 548.
  • the receiving byte is reset to zero, the status Ready to Receive is cleared, and, as previously described, the IOCB proceeds to address the IRQ line at 550. If at 546 the value for the received message is not equal to the value of the previously received messages plus one, at 536 the IRQ line is set to TRUE, and the IOCB proceeds to address the IRQ line at 550 as described previously.
  • the IOCB proceeds to address the IRQ line at 550 as described above.
  • the value of the received message is not greater than the value of the previously received messages plus one, at 542, the byte is put in RCV at 542, verified, and the IOCB proceed to address the IRQ line at 550 as described previously.
  • the inter- message counter has timed out at 530 after it has been determined that receiving is not greater than zero at 524, then, at 532 a byte is put in RCU[0]. Receiving is also set to 5. After these settings have been made, the virtual ID is validated at 534. A valid virtual ID results in the IRQ line being set to TRUE, and receiving to it, at 536. The IOCB then proceeds to address the IRQ line at 550, as previously described.
  • Monolithic gaming machines have been described earlier, in which a single CPU controls the gaming machine and its affiliated hardware devices.
  • One aspect of the present invention, described above has shown that there is reliable communication between the game CPU and the IOCB.
  • the other aspect of the present invention is that the hardware attached through the IOCB to the game CPU must be abstracted.
  • abstraction refers to the process of shifting the source of the software necessary to control a particular device from a CPU contained in that particular device to another CPU that is remote to the particular device.
  • This other CPU may contain additional software to control other specific hardware devices which also are connected to, yet remote from, this other CPU.
  • the hardware is already physically abstracted, in that it is not directly attached to the game CPU as in previous monolithic (single CPU) game designs.
  • the general method or protocol of communicating with the hardware should also be abstracted. Since the interface between the game CPU and the hardware is no longer dedicated, as in a monolithic game, adding a layer of abstraction provides the game software with enough flexibility to properly adapt and correspond to new hardware arrangements.
  • the common physical attribute hardware devices from the game CPU's perspective is that the hardware devices are all controlled by a CPU (that of the IOCB) other than the game CPU.
  • the game CPU does not have to use processing bandwidth to directly control or interact with a peripheral device until an event on that device, such as a jackpot to be paid out, actually happens.
  • the software on the IOCB CPU can add or modify feahires or attributes other than those normally directly supported by the hardware devices. This makes abstraction of the hardware devices easy, by adding the abstracted features to the software in the IOCB's CPU, thereby controlling the operation of the hardware devices.
  • Some examples of hardware devices that can be attached to the game through the IOCB might be: buttons, lamps, coin acceptors, card acceptors, bill acceptors, hoppers, coupon dispensers, bells, reel mechanisms, dice mechanisms, wheel mechanisms, feature displays, and door switches.
  • Some attributes of the attached hardware devices, but not limited to these, that could be added to the IOCB software to make the hardware devices easier to use include: a hardware type, a hardware subtype, a serial number, a hardware/software revision level, a hardware state (whether enabled, disabled, reset, and other states that are hardware dependent), a hardware status (okay, disabled, error, etc) and a hardware dependent configLiration.
  • the hardware type would tell the game CPU what type of device is attached; this includes information for communicating with the device.
  • the hardware subtype would allow finer resolution of the hardware type. For example, a coin acceptor or hopper would Lise the hardware subtype to determine the configured denomination, e ⁇ nickel, quarter, or dollar token.
  • the serial number allows the game CPU to discriminate between the same hardware types. This function is particularly important in view of the trend to employ multi-game machines, or gaming machines which may be connected to a plurality of identical devices such as, for example, multiple coin acceptors.
  • the serial number provides a unique identifier for each device.
  • the hardware/software revision level tells the game CPU what feature/attribute set to expect.
  • the hardware state allows the game CPU to control the overall gross functioning of the hardware device. For example, if the state were set to enabled on the coin or bill acceptor, they would accept money. The game CPU would change the state to disabled to turn the hardware device off. The hardware status would tell the game software if the device is operable, and what operation it is currently performing. The game software can not affect the status: it is merely reported to the game CPU. The status settings beyond the generic setting of "okay,” “disabled,” and “error” are hardware dependent.
  • a hopper coLild have states for "forward” and “reverse,” or a bill acceptor coLild have states for "vend,” “reject,” “escrow,” and “stacking.”
  • the common states wo ild all have the same numerical code from device to device, but extended states like “forward” and “vend” could have the same numeric code, but would be differentiated by the hardware type.
  • the use of the acknowledge (ACK) command for message control has been described above, with respect to message traffic between the game CPU and the IOCB.
  • the close command is used when the portion of the game CPU software that uses the hardware device is unloaded or inactivated. For example, in a multi-game platform, one particular game could use some special hardware. When the player selects that game to play, the game software on the game CPU opens the virtual circuit to the special hardware required. Once the player finishes that game, and chooses another game, the game software would close the virtual circuit to that special hardware.
  • the abstracted hardware attributes informs the game CPU how to communicate with the hardware device.
  • Hardware abstraction commands affect message flow.
  • Another aspect of the abstraction process includes abstraction of the communications protocols.
  • An important abstraction for communications to the hardware devices is a level of message acknowledgment and number of retries form the perspective of the sender/receiver end points.
  • the transfer protocol handles the transfer from game CPU to IOCB, and vice-versa.
  • the hardware controller must have acknowledgment form the game CPU that the message sent was understood and processed; while the game CPU must have the same positive knowledge that the hardware has received and is executing the command sent to it.
  • the preferred embodiment Lises positive acknowledgment for receipt of messages.
  • This level of positive acknowledgment is built into the same level as the hardware attributes and features described above. These are encapsulated into the body of the framed transport packet protocol using a similar message structure, but without the Command, ETX, and CRC bytes. The encapsulated message in the body of the transfer protocol would look like:
  • the size of the abstracted body data is encoded within the transfer protocol packet, and is thus not copied.
  • the delivery of the packet to the device will continue to have the outside message length.
  • the virtual ID is needed in the body, since the IOCB could deliver the packet to a single device address that could contain several hardware functions.
  • the command does not need to be encapsulated into the transfer protocol body, since the IOCB will use the command in the packet to the hardware.
  • Each of these separate functions could have its' own hardware type, or subtype, serial number, and virtual ID.
  • the virtual ID is assigned based on the uniqueness of the combined type, subtype, and serial number. For multi-function devices, these fields must map OLit unique for each separate function.
  • serial numbers could be the same, but the hardware types must be different, or vice-versa, such that the end result is a unique combination or both the types and serial numbers could be unique (different).
  • An additional feature of the hardware attributes to be abstracted is the packetization (breaking up into smaller packets) of large blocks of data. This would be dependent upon the need of the hardware for the data, and the amount of memory available to rebuild the larger data packet from the sub-packets in the CPU controlling the hardware.
  • the sub-packets would be built in the body of the transport protocol packets.
  • the originating packet sender would negotiate with the receiving end on the total size of the large data packet, and the number of sub- packets. After the receive end has agreed to the transfer, the sender will place the sub-packets, with a sequence number to serialise the sub-packets and build the larger data packet in the correct order, on the transfer protocol medium.
  • An example of packetization would be the game CPU downloading new firmware to a hardware device. If the hardware device firmware is a total size of 65536 bytes (65KB), and the flash that contains it can be programmed in 4096 byte (4KB) blocks, the game CPU could negotiate the transfer as 16 transfers of 4KB blocks. Each block coLild be broken down into 32 sub-packets of 128 bytes (plus 2 bytes for start address/sequence), or 16 sub-packets of 240 [sub-body] bytes (plus bytes) with one sub-packet of 16 bytes (plus 2 bytes), or any variation of that while keeping in mind the transfer protocol packet can have at most 245 bytes in the abstract SLib-body of the transfer protocol body.
  • Each sub-packet would be acknowledged end-to-end to insure that all packets are transferred reliably.
  • the sender After each block of subpackets are sent, the sender would wait for acknowledgment of the overall block transfer, and the message from the receiver to start the next block transfer. After the last block has transferred and been acknowledged, the receiver would finally send a message acknowledging the whole transfer. If at any of these acknowledge points there is no acknowledgment, the sender and receiver would negotiate the There are some special hardware abstraction meta-commands that exist between the game CPU and the IOCB. These extend to the abstracted hardware devices themselves, but are used for control of the hardware devices. These meta-commands would be passed back and forth on the transfer protocol packet command level as dedicated (predefined) packet command bytes.
  • One of the transfer packet command bytes would allow the game CPU to ask the IOCB for the hardware abstraction table.
  • This table is a list of the devices the IOCB has registered, and assigned, a virtual ID.
  • the table also contains the hardware type, subtype, serial mimber, revision level, and starting CRC seed of the device. Further details about the hardware abstraction table can be found in our PCT Patent Application No. PCT/AU99/00500, for a Method of linking devices to gaming machines.
  • the game CPU could use another defined command byte to tell the IOCB to delete a hardware device form the table.
  • the IOCB When the IOCB receives this command, it informs the hardware device to be deleted that it is deleted and shoLild not try to re-register with the IOCB (see Aristocrat's PCT Patent Application for a Secured inter- processor/virtual device communications system No. PCT/AU99/00389).
  • the IOCB will move the entry for the hardware device form the hardware abstraction table to the deleted table, in case the hardware device is reset and tries to re-register.
  • the IOCB could send a message with a defined command byte informing the game CPU that a hardware device has been added. Either the game CPU or the IOCB coLild use the same defined command byte to ask the other side to verify that a virtual ID exists. If it is the game CPU asking the IOCB, the IOCB will also search the deleted table. If the entry is deleted, the IOCB will verify the ID, but also that it is currently deleted. This command is used when a packet is not being acknowledged (see previous communication retry text). The game CPU could ask that a device be reset.
  • the IOCB When the IOCB receives this command, it will force the hardware device to reset and go through the PC address registration process (see our PCT Patent Application for a Secured inter-processor/virtual device communications system, No. PCT/AU99/00389). If the game CPU configuration changes so that it can now allow hardware that was previously deleted, the game CPU can send the IOCB an undeleted command to remove the entry from the deleted table. The IOCB would then have the device reset and reregister for an I C address. Once this is done, the IOCB would report the device as new hardware. When the IOCB loses communication with a hardware device, after a retry and timeout period, the IOCB sends a message to the game CPU informing the game CPU that hardware has been removed. All meta-commands at this level are addressed to virtual device zero, which is the game CPU and the IOCB devices.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Pinball Game Machines (AREA)
  • Communication Control (AREA)
  • Bus Control (AREA)

Abstract

Cette invention se rapporte à un système électronique d'interface d'entrée/sortie et d'abstraction de dispositifs, qui est utilisé dans une machine de jeu et qui comprend: une unité centrale de jeu (l'UC du jeu); une carte contrôleur d'entrée/sortie intelligente (la carte IOCB), un bus PC à la norme ISA (bus ISA), et un protocole de transport de messages en trames. La carte IOCB facilite les communications entre l'unité centrale du jeu et les services des périphériques virtuels, qui sont des dispositifs périphériques associés au système de la machine de jeu. Ces dispositifs sont des périphériques tels que affichages, boutons, magasins d'alimentation, mécanismes à pièces de monnaie et validateurs de factures. Le protocole de transport de messages en trames comprend: un en-tête de message, un corps contenant un message de dispositifs virtuels, et une signature de validation de paquet. L'unité centrale du jeu communique avec les périphériques de la machine de jeu en envoyant des messages de dispositifs virtuels le long du bus ISA jusqu'à la carte IOCB. Celle-ci achemine ensuite le message de dispositifs virtuels jusqu'aux services de dispositifs virtuels appropriés. Ces services de dispositifs virtuels sont responsables de prendre en charge le matériel spécifique et sont constitués par des pilotes de dispositifs virtuels sur l'unité centrale du jeu qui communiquent avec des dispositifs virtuels sur la carte IOCB, et l'utilisation de la carte IOCB et de l'interface haute vitesse permet à l'unité centrale du jeu de se servir d'un plus grand nombre de ses fonctions disponibles pour commander les fonctions du jeu plutôt que d'une seule opération de ses dispositifs périphériques associés.
PCT/AU1999/000595 1998-07-24 1999-07-23 Interface d'entree/sortie et abstraction de dispositifs WO2000006268A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
NZ509450A NZ509450A (en) 1998-07-24 1999-07-23 Input/output interface and device abstraction
US09/743,950 US6968405B1 (en) 1998-07-24 1999-07-23 Input/Output Interface and device abstraction
AU48900/99A AU748434B2 (en) 1998-07-24 1999-07-23 Input/output interface and device abstraction
ZA2001/00616A ZA200100616B (en) 1998-07-24 2001-01-22 Input output interface and device abstraction
US12/181,057 US20090198846A1 (en) 1998-07-24 2008-07-28 Input/output interface and device abstraction
US12/861,389 US8719470B2 (en) 1998-07-24 2010-08-23 Input/output interface and device abstraction

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US9406898P 1998-07-24 1998-07-24
US60/094,068 1998-07-24

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US09/743,950 A-371-Of-International US6968405B1 (en) 1998-07-24 1999-07-23 Input/Output Interface and device abstraction
US11/059,925 Continuation US7454544B2 (en) 1998-07-24 2005-02-17 Input/output interface and device abstraction

Publications (1)

Publication Number Publication Date
WO2000006268A1 true WO2000006268A1 (fr) 2000-02-10

Family

ID=22242681

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU1999/000595 WO2000006268A1 (fr) 1998-07-24 1999-07-23 Interface d'entree/sortie et abstraction de dispositifs

Country Status (4)

Country Link
AU (1) AU748434B2 (fr)
NZ (1) NZ509450A (fr)
WO (1) WO2000006268A1 (fr)
ZA (1) ZA200100616B (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2421819A (en) * 2004-12-01 2006-07-05 Igt Reno Nev Universal operating system to hardware platform interface for gaming machines
US7351151B1 (en) 2001-08-20 2008-04-01 Sierra Design Group Gaming board set and gaming kernel for game cabinets
US8321571B2 (en) 2001-08-20 2012-11-27 Bally Gaming, Inc. Local game-area network method
US9555322B2 (en) 2001-08-20 2017-01-31 Bally Gaming, Inc. Local game-area network method

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6607441B1 (en) 1998-04-28 2003-08-19 Acres Gaming Incorporated Method for transferring credit from one gaming machine to another
US7290072B2 (en) * 1999-10-06 2007-10-30 Igt Protocols and standards for USB peripheral communications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988003682A1 (fr) * 1986-11-04 1988-05-19 Unisys Corp Systeme d'entree/sortie pour alleger les fonctions du systeme d'exploitation
WO1996012250A1 (fr) * 1994-10-12 1996-04-25 Sega Enterprises, Ltd. Ameliorations des communications entre un appareil de traitement de donnees et un peripherique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1988003682A1 (fr) * 1986-11-04 1988-05-19 Unisys Corp Systeme d'entree/sortie pour alleger les fonctions du systeme d'exploitation
WO1996012250A1 (fr) * 1994-10-12 1996-04-25 Sega Enterprises, Ltd. Ameliorations des communications entre un appareil de traitement de donnees et un peripherique

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7351151B1 (en) 2001-08-20 2008-04-01 Sierra Design Group Gaming board set and gaming kernel for game cabinets
US8321571B2 (en) 2001-08-20 2012-11-27 Bally Gaming, Inc. Local game-area network method
US9555322B2 (en) 2001-08-20 2017-01-31 Bally Gaming, Inc. Local game-area network method
GB2421819A (en) * 2004-12-01 2006-07-05 Igt Reno Nev Universal operating system to hardware platform interface for gaming machines
GB2421819B (en) * 2004-12-01 2009-05-27 Igt Reno Nev Universal operating system to hardware platform interface for gaming machines
AU2005239694B2 (en) * 2004-12-01 2011-05-19 Igt Universal Operating System to Hardware Platform Interface for Gaming Machines
US7966485B2 (en) 2004-12-01 2011-06-21 Igt Universal operating system to hardware platform interface for gaming machines
US8281118B2 (en) 2004-12-01 2012-10-02 Igt Universal operating system to hardware platform interface for gaming machines
US8549276B2 (en) 2004-12-01 2013-10-01 Igt Universal operating system to hardware platform interface for gaming machines

Also Published As

Publication number Publication date
ZA200100616B (en) 2002-06-26
AU4890099A (en) 2000-02-21
AU748434B2 (en) 2002-06-06
NZ509450A (en) 2003-03-28

Similar Documents

Publication Publication Date Title
US6968405B1 (en) Input/Output Interface and device abstraction
AU2020203302B2 (en) A method of enabling restoration of games and a method of restoring games
WO1999060498A1 (fr) Systeme de controle intelligent d'entree/sortie
CN101159078B (zh) 通用游戏监控单元和系统
JP2019195517A (ja) 遊技機
JP2021104099A (ja) 遊技機
EP1094425A2 (fr) Communication periphérique standard
AU748434B2 (en) Input/output interface and device abstraction
JP4929543B2 (ja) 遊技機管理システム
JPWO2006064764A1 (ja) ペナルティ機能を有するゲーム機器管理装置、ゲーム装置およびその動作プログラム、並びにペナルティ設定サーバ
WO2007012034A2 (fr) Protocole de transmission destine a un systeme de jeux
JP7441400B2 (ja) 遊技機
JP5440572B2 (ja) 遊技機管理システム
JP2024112363A (ja) 遊技機
JP2024116600A (ja) 遊技機
JP2024116441A (ja) 遊技機
JP2024116440A (ja) 遊技機
JP2024116598A (ja) 遊技機
JP2024116439A (ja) 遊技機
JP2024116445A (ja) 遊技機
JP2024116446A (ja) 遊技機
JP2024116605A (ja) 遊技機
JP2024116604A (ja) 遊技機
JP2024116601A (ja) 遊技機
JP2024116602A (ja) 遊技機

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU JP NZ US ZA

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 509450

Country of ref document: NZ

WWE Wipo information: entry into national phase

Ref document number: 2001/00616

Country of ref document: ZA

Ref document number: 200100616

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 48900/99

Country of ref document: AU

122 Ep: pct application non-entry in european phase
WWG Wipo information: grant in national office

Ref document number: 48900/99

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 09743950

Country of ref document: US