US20120246346A1 - Secured inter-processor and virtual device communications system - Google Patents
Secured inter-processor and virtual device communications system Download PDFInfo
- Publication number
- US20120246346A1 US20120246346A1 US13/403,687 US201213403687A US2012246346A1 US 20120246346 A1 US20120246346 A1 US 20120246346A1 US 201213403687 A US201213403687 A US 201213403687A US 2012246346 A1 US2012246346 A1 US 2012246346A1
- Authority
- US
- United States
- Prior art keywords
- data packet
- devices
- communications protocol
- creating
- plug
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
- G06F13/4291—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using a clocked protocol
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/82—Protecting input, output or interconnection devices
- G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
-
- 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
Definitions
- the present invention is directed generally to an electronically secured inter-processor and virtual device communication system used in gaming machines and is directed more particularly to an electronically secured inter-processor and virtual device communications system with (1) an Input/Output Controller Board (hereinafter referred to as “IOCB”), (2) a multi-drop bus interfacing one or more device modules, (3) a parallel interface to an industry standard main single board computer (hereinafter referred to as the “SBC”) of the gaming machine and (4) a IOCB-to-device “Plug-N-Play protocol (the “Plug-N-Play Protocol”).
- IOCB Input/Output Controller Board
- SBC industry standard main single board computer
- the Invention through the Input/Output Controller Board (IOCB), logically interconnects all the devices in the gaming machine to the SBC.
- the IOCB's communications to and from each device is based on a network-capable communications protocol, such as Philips' Inter-Integrated Circuit (I 2 C) two-wire Serial Interface (hereinafter “PHILIPS I 2 C”).
- the SBC and its EPROM memory chips do not have to be reprogrammed, resigned or replaced. Further, as no device related software resides on the SBC or its EPROMS, no new software needs to be resubmitted to any regulatory agency, as no new software is created. Instead each device in the machine incorporates an intelligent board with microprocessor (the “Device Board”) which is programmed specifically to the functions of that device. The Device Board also communicates via the communications protocol, such as PHILIPS I 2 C, to the IOCB in a multi-drop configuration. Replacing a device or adding a new device is simply a matter of connecting the communications interface (Clock, Data, Logic Power, System Ground) to the multi-drop bus interconnecting all the devices to the IOCB.
- the communications interface Lock, Data, Logic Power, System Ground
- the IOCB programming module continuously monitors the communications protocol interface (the PHILIPS I 2 C line) for device activity and relays these actions to and from the SBC. As new devices are added to the link, a specific registration protocol is followed which will allow the device to register with the IOCB. If the registering device has followed all the secured protocols, the specific parameters of the device (device type, Serial Number, etc.) are relayed to the SBC.
- the communications protocol interface the PHILIPS I 2 C line
- the SBC has several modules programmed for all possible devices that may connect to the machine, such as a Coin In, Coin Out, and Bill Acceptor modules. Even though there may be several types of these devices, the appropriate SBC module simply monitors for coins in, coins out and bills accepted.
- the specific hardware and protocol of each connected device is level converted and formatted by each Device Board to a generic format required by the SBC module.
- an object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added to, replaced in or changed in a gaming machine without any need to reprogram or redesign the SBC of the gaming machine.
- a further object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added, replaced in, or changed in a gaming machine without a need to replace the SBC of the gaming machine.
- An additional object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added to, changed in, or replaced in a gaming machine without the need to modify the software residing in the CPU or any device so that a resubmittal to an appropriate regulatory body would not be necessary.
- Still another object of the invention is an electronically secured inter-processor and virtual device communication system which cost-effectively allows devices to be changed in a gaming machine.
- an object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to most efficiently be added to, replaced in or changed in a gaming machine.
- An additional object of the invention is an electronically secured inter-processor and virtual device communication system with a protocol which supports dynamic assignment of device addresses.
- Still a further object of the invention is an electronically secured inter-processor and virtual device communication system which provides reliable and secure communications among interprocessors.
- an electronically secured inter-processor and virtual device communication system including an IOCB connecting a multitude of peripheral gaming machine devices and the SBC through parallel interface.
- the IOCB provides an interface between the SBC of the gaming machine and the machine's devices and is connected to the SBC through a parallel interface.
- the IOCB uses a multi-drop communication bus for its connection with the devices requiring at least four wires for the clock, data, logic power, and system ground protocol. Each device contains its own CPU board programmed for the specific device.
- the IOCB When power is first applied to the gaming machine, the IOCB attempts to establish a link with the SBC by placing a ‘link request’ transaction in the IOCB's transmit queue and commencing an idle state. The IOCB then remains in an idle state until the SBC acknowledges a physical connection. Once the SBC acknowledges a physical connection, the IOCB sends the ‘link request’ transaction to the SBC, preferably through the IOCB's Parallel Slave Port (Data) (the “PSP-Data”). When the link is established, the IOCB sends a framed packet to the SBC containing the Virtual ID and device registration commences. Independently of the SBC and the IOCB, each device's CPU attempts to register the device's hardware with the IOCB through the multi-drop bus.
- Data Parallel Slave Port
- the IOCB assigns an communications protocol address, preferably the PHILIPS I 2 C address, to the device and creates a device table entry containing data uniquely identifying the device, such as type of device, serial number, and the communications protocol address.
- the SBC assigns and stores a virtual identification number (the “Virtual ID”). After all devices are registered, the IOCB stores information about each registered device and transfers any pertinent packets received from a device to the SBC.
- the IOCB is the only external device interfacing the SBC with the gaming machine's devices such as Deck Buttons and Lamps, Coin In Mechanisms, Coin Out Hoppers, Bill Acceptors, Magnetic-Stripe Card Readers, Keypads, Progressive Display Interfaces, Ticket Printers, Coupon Dispensers, Hard Meters and general Security switches in the machine.
- the IOCB's physical connection to the SBC is preferably via a parallel interface on the SBC, preferably a PC-104 bus which is capable of transfer rates up to 8 million bytes per second.
- the data transfer between the IOCB and SBC is interrupt-driven and controlled by an 8-bit register.
- the IOCB interfaces the listed devices through a Multi-Drop communication scheme using a network-capable communications protocol, such as RS-485, USB, current loop, or preferably Philips Corporation's two-wire Inter-Integrated Circuit (I 2 C) serial interface and corresponding communications protocol (“hereinafter “I 2 C protocol”), which enables speeds up to 400 kbps.
- a network-capable communications protocol such as RS-485, USB, current loop, or preferably Philips Corporation's two-wire Inter-Integrated Circuit (I 2 C) serial interface and corresponding communications protocol (“hereinafter “I 2 C protocol”), which enables speeds up to 400 kbps.
- the communications protocol preferably the I 2 C protocol, ensures reliable transmission and reception of data.
- only one apparatus preferably the IOCB, is the ‘master’ which initiates transfer on the bus and generates the clock signals to permit that transfer, while the other device(s) acts as the ‘slaves’.
- the Philips communication protocol (“I 2 C Protocol”) operates on top of Philip's published industry standard I 2 C protocol. Additional information on the PHILIPS I 2 C specification can be obtained from the document “The I 2 C bus and how to use it”, #939839340011, available from the Philips Corporation.
- the communications protocol preferably the I 2 C protocol, constitutes the physical layer for the invention's IOCB to Device ‘Plug-N-Play’ protocol, which is a packet-driven securitized protocol.
- the preferably I 2 C framed ‘Plug-N-Play’ protocol supports dynamic assignment of I 2 C addresses, facilitates reliable communications between I 2 C devices and the IOCB and provides a secured link for inter-processor communications.
- a multi-wire Multi-Drop bus preferably a four-wire multi-drop bus (Clock, Data, Logic Power, System Ground), interconnects all devices throughout the machine to the IOCB.
- Each device is equipped with a firmware-based CPU board which is programmed to the specific parameters and purpose of each device.
- Each device's CPU board is capable of communicating with the communications protocol, preferably the I 2 C protocol.
- Messages are routed to and from the IOCB to the devices using a communications protocol framed packet, preferably an I 2 C framed packet comprised of an I 2 C address, header, body and footer, as specified below.
- a communications protocol framed packet preferably an I 2 C framed packet comprised of an I 2 C address, header, body and footer, as specified below.
- packets will be limited to a maximum of 255 bytes inclusive of the I 2 C Address and Footer.
- Message bodies larger than 248 bytes must be broken up into multiple communications protocol framed packets, preferably I 2 C framing packets.
- the IOCB When power is first applied to the gaming machine, the IOCB attempts to establish a link with the SBC by placing a ‘link-request’ transaction in the IOCB transmit queue, which commences an idle state. The IOCB remains in this idle state until the SBC acknowledges a physical connection. Upon receiving acknowledgment of the physical connection, the IOCB sends this link request transaction to the SBC via preferably the Parallel Slave Port (PSP Data) of the IOCB through a PSP-framed packet containing the Virtual ID of the device. Once the link is established, device registration begins. Neither the IOCB nor the SBC has knowledge of the devices integrated in the machine.
- PSP Data Parallel Slave Port
- Each device's CPU will attempt to ‘register’ its specific hardware with the IOCB by communication through the communications protocol multi-drop bus, preferably a I 2 C Multi-Drop bus.
- the IOCB dynamically assigns a communications protocol address (range 9-76h), preferably an I 2 C address, to the device and enters the device information into a device table which stores the device's specific data (type of device, serial number, etc.).
- a device responds to IOCB requests using this communications protocol address, such as an I 2 C address.
- the IOCB also assigns Virtual ID (Circuit Number) to the device referencing the device to the SBC.
- the SBC uses this Virtual ID to invoke a software driver referencing this device type regardless of its communications protocol, preferably I 2 C, address.
- the Virtual ID remains assigned to the device and, should the device lose power, upon re-registering, the device may receive a different communications protocol, preferably I 2 C, address but will maintain the same Virtual ID. This process repeats until all devices have been registered.
- a table entry in the IOCB's device table is created for that device.
- the IOCB will detect removal of a device and will send notification to the SBC.
- the IOCB After device registration, utilising a prioritized polling scheme, the IOCB will query each registered device for status. The IOCB either receives a ‘no activity’ packet or a packet containing pertinent data for that device. If required, the IOCB transfers a valid packet to the SBC via preferably the PSP-Data port.
- the IOCB declares the device ‘inactive’ by sending an appropriate PSP framed transaction to the SBC.
- the IOCB communicates with the SBC via a parallel port connected to a PC-104 bus on a SBC.
- the interrupt-driven data transfer is controlled by a shared 8-bit register which is used as handshaking flags for flow control.
- the communications protocol bus is a multi-wire communications interface, preferably a I 2 C bus with a two-wire serial interface developed by the Philips Corporation which enables speeds up to 400 kbps.
- the IOCB will be interrupted by the PSP-Data if the SBC initiates any PSP framed transactions. If the SBC initiates a transaction, the IOCB will wrap the PSP framed characters with communications protocol framing characters, such as I 2 C framing characters, sending this data to the appropriate device at that communications protocol address.
- communications protocol framing characters such as I 2 C framing characters
- the IOCB's sole responsibility is to direct secured data transactions to and from the SBC and to and from the gaming machine's devices.
- the IOCB does not initiate or control any functions of the gaming machine.
- FIG. 1 is one embodiment of the invention showing the SBC of the gaming machine connected to the IOCB and connected to seven devices through device boards in a multi-drop bus configuration.
- FIG. 2 is an embodiment of the invention, showing the preferred PC-104 bus of the SBC connected through a preferred parallel interface by an 8-bit bi-directional bus to two parallel slave ports (PSP-Data and Control, and the 8-bit register) of the IOCB.
- FIG. 3 is a preferred embodiment of the invention, showing the IOCB connected in a multidrop configuration with four wires to five devices.
- FIG. 4 is a flow chart showing the transmission of data from the SBC to the devices through the IOCB.
- FIG. 5 is a flowchart showing the transmission of data from the devices to the SBC through the IOCB.
- FIG. 6 is a flowchart depicting the four-level security of the invention, which ensures the validity of data transfers, and
- FIG. 7 is a flowchart depicting the registration of devices by the IOCB.
- FIG. 1 depicts the SBC (generally 1 ) of the gaming machine, as connected to the Input/Output Controller Board (“IOCB”) (generally 200 ).
- the IOCB 200 is connected in a multi-drop bus configuration 250 to the devices ( 3 A, 3 B, 3 C, 3 D, 3 E, 3 F, 3 G), each device with its own microprocessor inclusive board (respectively, 4 A, 4 B, 4 C, 4 D, 4 E, 4 F, 4 G).
- the devices depicted are a coin comparator 3 A, a bill validator coupon 3 B, a coin out hopper 3 C, a magnetic card reader 3 D, a coupon dispenser 3 E, a progressive interface 3 F, and a deck buttons/lamps 3 G.
- Each device ( 3 A through 3 G) has its own board ( 4 A through 4 G) (the “Device Boards”) and is virtually connected to the SBC 1 and to the other devices through the multi-drop bus configuration 250 .
- the SBC 1 is capable of digital storage, contains a microprocessor, preferably a Pentium II, and preferably contains sound and video capability, wave file capability, networking capability, and modem connections.
- IOCB Input/Output Controller Board
- the IOCB 200 is a Microprocessor based electronic board featuring a microprocessor, preferably a PIC 17C756, preferably on-board Random Access Memory (RAM), preferably Non-Volatile RAM, preferably timer/counters, preferably Capture/Compare/PWM modules, preferably two 8-bit parallel ports (Parallel Slave Port (PSP) Data 201 , PSP Control 202 ), preferably one Serial Communications Interface, preferably two-wire Inter-Integrated Circuit (I 2 C) bus 203 , preferably internal/external Interrupt sources, preferably a Watchdog Timer, preferably a Brownout detection and preferably Programmable code-protection.
- the IOCB 200 has the ability to set up and communicate in the communications protocol standard, to communication with at least one device, and to perform distributed processing.
- each device 3 A through 3 G in the gaming machine is a Microprocessor based electronic CPU board (the “Device Board.”) 4 A through 4 G.
- Each board is specifically designed and programmed to interface with the specific function of its associated device.
- the devices are connected to the IOCB 200 in a multi-drop configuration 250 .
- Each board is capable of communicating in a communications protocol, preferably an Inter-Integrated Circuit (I 2 C) communications protocol, and contains a microprocessor, preferably a PIC 16C67.
- Integrated components of the board are application specific.
- Each board 4 A, 4 B, 4 C, 4 D, 4 E, 4 F, 4 G contains a memory component, preferably a 64-bit serialised memory component, which is used as another security check in the design.
- the unique serial number of each component of each Device Board is installed into the board at time of production and provides a unique identification number for each board (the “Board”).
- the Board ID is used in the packet transmissions to and from the IOCB 200 as another signature verification in the calculation of the CRC-16.
- FIG. 2 depicts the preferred PC-104 port 100 of the SBC 1 connected by preferably an 8 bit bi-directional bus to preferably the IOCB's PSP-Data 201 and PSP-Control 202 port and to the IOCB's 8-bit register.
- Communication to and from the SBC 1 is accomplished through the IOCB's 8-bit PSP Data and PSP-Control port 201 , 202 and the SBC's PC-104 bus 100 and the bi-directional interrupt driven data transfers utilise a shared 8-bit register 205 which regulates data direction and flow control.
- the IOCB 200 will set and reset the handshaking control bits, with the SBC 1 to monitor these status bits.
- Each bit of the 8 bit regiter 205 preferably is populated as follows:
- Bit 7 —Ready To Receive (RTR) 202 A preferably indicates, if set, that the IOCB 200 is ready to receive a data byte. If the SBC 1 has a character to send, it reads this statusbit and if set, will send the character. If reset, a time-out interval is initiated and if it expires, the SBC will report an error which locks up the game.
- Bit 6 Receiveive Aborted (RA) 202 B preferably indicates, if set, that the IOCB has detected a communication error while receiving data.
- the SBC 1 also monitors bit 6 prior to sending a character, and if Bit 6 is set, the SBC 1 , will abort the balance of the transmission and retry again.
- Bit 5 Ready To Transmit (RTT) 202 C preferably indicates, if set, that the IOCB 200 has data to send. When set, this bit asserts Interrupt Request 11 (IRQ 11 ) on the SBC 1 . Once the interrupt has been serviced and the character has been read, the IOCB 200 notifies its PSP hardware 201 , 202 and resets this bit. The IOCB 200 then generates a Transmit Data Register Empty interrupt, signalling that another character may be sent.
- RTT Ready To Transmit
- Bit 4 Transmit Abort (TA) 202 D preferably indicates, if set, that the IOCB 200 has detected an internal transmission error while transmitting a packet to the SBC 1 and that no more data will be sent. If the SBC 1 detects that this bit is set, it will clear any previous characters received and abort the receive process.
- TA Abort
- Busy 202 E preferably indicates, if set, that the IOCB 200 is busy processing a critical application and prevents the SBC 1 from an erroneous time-out on a data transfer.
- the IOCB 200 sets this bit upon entering a critical application, resetting it upon completion.
- the SBC 1 will initiate a longer time-out interval, but upon expiration, will report an error locking up the game.
- Bit 2 — 0 202 F This bit is reserved for future use.
- Bit 1 Connect 202 G preferably indicates, if set, that the handshaking flags of this register should be ignored.
- the IOCB 200 sets this bit to the value 1 (indicating high impedance) if the IOCB 200 and SBC 1 are disconnected, as the tri-state inputs of the PSP hardware will be high.
- the IOCB 200 sets this bit to the value 0 if the IOCB 200 and SBC 1 are connected.
- These tri-state inputs (high, low, high-impedance) prevent interference between multiple devices attempting to access the line and allow the IOCB 200 to act as a traffic controller.
- the IOCB 200 always resets the bit to prevent erroneous actions based on bit levels being set.
- Bit 0 —Reset 202 H preferably indicates to the SBC 1 , if set, that the IOCB 200 has been up or reset, alerting the SBC 1 to set the ‘state’ of the gaming devices in the machine. That bit is reset each time initial communications are established between the IOCB 200 and the SBC 1 .
- FIG. 3 depicts the interconnections among the IOCB 200 and five devices 3 in the preferred I 2 C multi-drop configuration 250 .
- the IOCB's I 2 C port 203 is connected to each Device Board 4 through preferably a four-wire multi-drop bus 250 .
- the preferred I 2 C capable multi-drop bus 203 has preferably four wires (clock 251 , data 252 , Logic Power 253 and System Ground 254 ) which are distributed through the machine, providing the Device Boards 4 with a means to utilise the clock, data, power and a ground of the IOCB 200 .
- Each device 3 is equipped with a Microprocessor based electronic circuit board 4 (the “Device Board”) which is specifically designed to interface with the device's input or output signals depending on the device.
- the Device Boards 4 are capable of communicating using network-capable communications protocols, preferably Inter-Integrated Circuit (I 2 C) protocols, enabling interconnection among the devices 3 .
- I 2 C Inter-Integrated Circuit
- multi-drop bus 250 clock 251 , data 252 , Logic Power 253 and System Ground 254 are distributed in each device providing a clock, data transmission, power and ground to the Device Boards 4 .
- a Device Board 4 can be attached to more than one Device 3 . In that event, more than one device will have a single communications protocol address (preferably an I 2 C address), but each device will have a unique Virtual ID.
- FIG. 4 depicts data transfers of SBC-initiated transmissions between the devices 3 and the SBC 1 through the IOCB 200 .
- Data transfers between the IOCB 200 and the SBC 1 are based on a PSP framed packet 500 with the preferably following protocol:
- Communication packets transferred between the SBC 1 and the IOCB 200 preferably have a Virtual ID 500 A embedded in the packet which is used to steer the transaction to the appropriate software driver of the appropriate device.
- Communication packets transferred between the IOCB 200 and the device 3 preferably I 2 C framed packets 520
- the IOCB 200 directs transactions both between the IOCB 200 and the SBC 1 and between the IOCB 200 and the devices 3 . Due to its dual function, the IOCB 200 must wrap 524 , 525 , 526 , 527 the SBC-generated PSP packet 500 with preferably I 2 C framing 520 prior to sending 528 the packet to a device. Likewise, it must unwrap ( FIG. 5 , 616 ) the preferably I 2 C frame 520 from the device generated PSP packet 500 prior to sending the packet to the SBC 1 .
- Each Device Board 4 may have more than one physical device attached to it.
- a Device Board 4 may be attached to two hoppers, one to dispense coins, the other to dispense tokens.
- the IOCB 200 checks 552 its device table 552 for two table entries with the 1 same I 2 C address 520 A.
- the IOCB 200 directs 528 both SBC 1 generated commands (in our example, ‘C’ & ‘T’) to the same I 2 C address 520 A.
- the Device 3 at that I 2 C address 520 A will unwrap 544 the I 2 C framing bytes and act on 546 , 548 the PSP Virtual ID's Command byte 500 D and message body 500 E.
- the following example further illustrates the process by which the IOCB 200 wraps a PSP framed packet 500 .
- the SBC 1 wants to turn on Deck Lamp #4 with the device's Virtual ID of 126, the sender's next sequential transmission number of 56, and the command byte of ‘L’.
- PSP packet format 500 and values :
- the PSP packet 500 will contain the above listed data. Assuming there are no communication errors and the packet criteria is acceptable (see FIG. 6 ), the IOCB 200 references its device table 554 , finds this Virtual ID value 126 at I 2 C address value 32 . By these values, the IOCB 200 determines 551 that the data packet 500 initiated from the SBC 1 , determines 553 that the received data packet is not intended for the IOCB 200 and thereby ignores 555 the sequence number 500 C, the Command 500 D and the body 500 E of this packet. The IOCB 200 uses the size byte 500 B only to count down the received bytes, i.e. mark the end of the packet 557 .
- the IOCB 200 then wraps this packet with its own I 2 C frame.
- the IOCB 200 first creates 525 the message body 520 E of an I2C packet 520 from the PSP packet 500 .
- the IOCB 200 assigns the value of “M” 526 to the Command byte 520 D in the I 2 C packet 520 signifying that the SBC 1 originated this transaction.
- the IOCB 200 then assigns 527 the next available sequential transmission number from the IOCB 200 to the sequence number 520 C for this I 2 C address 520 A.
- the I 2 C packet 520 is assigned the I 2 C address 520 A of 32 ( 524 ). In the example, the I 2 C packet is populated as follows:
- the IOCB 200 then sends 528 the I 2 C packet 520 to the device 3 . Assuming there are no communication errors and the packet criteria is acceptable 536 , 538 , the device 3 sends an I 2 C framed packet 520 to the IOCB 200 acknowledging (ACK) its transmission 532 . Upon receiving the acknowledgment 560 , the IOCB 200 creates and sends 560 a PSP-framed packet 500 to the SBC 1 acknowledging the Virtual ID has accepted its transaction.
- the I 2 C body 500 F contains the PSP packet 500 sent by the SBC 1 .
- the device 3 at this I 2 C address unwraps the I 2 C framing bytes 544 , reads 546 the PSP framed packet Command (‘L’ in our example) and acts on 548 the Command by turning on Lamp #4.
- FIG. 5 depicts data transfers for device-initiated transmissions among the devices 3 and the SBC 1 through the IOCB 200 .
- the communications protocol framed packet preferably the I 2 C framed packet 520 , is transferred between the IOCB 200 and the device 3 .
- Each preferred I 2 C framed packet is comprised of the following parameters.
- a Device Board 4 has three devices 3 attached to it: Deck buttons, Deck lamps, and a Coin-in Mechanism. Each of these devices 3 is assigned its own Virtual ID 500 A but the Device Board 4 only possesses one I 2 C address 520 A.
- the Coin-in Mechanism's Virtual ID is 41
- the Deck button's Virtual ID is 14, and the Deck lamp's Virtual ID is 126.
- the I 2 C address 520 A is 39.
- the Device Board 4 detects this Coin-in action and, using the Coin-In Mechanism's Virtual ID 500 A of 41, sequence number 500 C of 214 , Command 500 D of ‘T’, and the coin value 500 E of 25 (hex 19), the device 3 generates 572 , 574 , 576 , 578 the following PSP packet 500 with the following values:
- the PSP packet 500 is intended for the SBC 1 , and, accordingly, the PSP Packet 500 must be encapsulated within an I 2 C packet for delivery to the IOCB 200 to be delivered to the SBC 1 .
- the PSP packet 500 becomes the body 520 E of the I 2 C packet 520 ( 586 ), for which the additional following value are assigned 586 , 588 , 590 , 592 , 594 , 596 to the I 2 C packet 520 : the IOCB's hard-coded I 2 C address 520 A of 8, a sequence number 520 C of 79, an I 2 C Command 520 D of ‘D’ signifying “Device” originated, creating the following I 2 C packet 520 :
- the device 3 waits 610 until the next poll received from the IOCB 200 and then sends 612 the I 2 C packet 520 to the IOCB 200 .
- the IOCB 200 checks the “command” byte 520 D of the I 2 C packet and, if “Command” equals “D” (for device) 614 , the IOCB 200 strips 616 the I 2 C framing characters.
- the IOCB 200 then sends 618 the PSP packet 500 , extracted from the body 520 E of the I 2 C packet 520 , to the SBC 1 as:
- This PSP packet 500 is the original packet generated by the Device 3 (see 572 , 574 , 576 , 578 , 580 , 582 , 584 ).
- the SBC 1 upon receiving a coin-in transaction, checks if there are any communication errors 622 and if the packet criteria is acceptable 620 (see FIG. 6 ). If the packet is okay, the SBC 1 takes appropriate internal action. If the packet has been validly transmitted, the SBC 1 also sends an ACK transaction to the Device 3 . First, the SBC 1 generates 624 the following PSP framed packet 500 , assigning “Command” 520 D the value of “ACK” 626 , assigning other values 528 , and sends 633 it to the IOCB 200 as:
- the IOCB 200 encapsulates 634 this PSP packet 500 with its I 2 C framing characters, looks up the I 2 C address 520 A associated with the Virtual ID 638 , assigns the I 2 C address 640 , assigns the value of “M” to “Command” 520 D, creating the following I 2 C packet 520 .
- the IOCB 200 then sends this I 2 C packet 520 to the I 2 C address 520 A found in its device table for this Virtual ID 500 A:
- the Device Board 4 detects the transmission 644 and ascertains that it was sent from the SBC 1 646 , the Device Board 4 at the I 2 C address 520 A strips 648 the I 2 C framing characters and decodes 650 the PSP packet 500 embedded in the body 520 E the I 2 C packet 520 .
- the ACK Command confirms 652 to the Device 3 that the transaction was accepted by the SBC 1 .
- the SBC 1 If appropriate, the SBC 1 generates another transaction 621 to be sent to the Device 3 responsible for updating the hard meter associated with this coin-in transaction.
- FIG. 6 depicts the preferred security devices of the invention which ensure the validity of the data transmissions.
- the receiving module the Receiver
- the Receiver checks the I 2 C packet 520 received to ensure validity of the received packet. First, the Receiver counts the number of characters received 672 and compares 674 this value to the “size” field of the received packet. If the packet passes this test, the Receiver then checks 676 if the “sequence number” of the received packet equals the receiver's next expected sequence number. If the packet passes this test, the Receiver checks if the ETX code is detected 678 at the correct index in the packet.
- the Receiver calculates 680 the CRC-16 value of the received packet and checks 682 if the 16-bit CRC value received is equal to the calculated 16-bit CRC. If any of these tests fails, this indicates a communication failure and the Receiver creates a NAK packet 684 , assigning “Command” a value of “NAK” 686 , assigning the other values 688 , and wraps 690 the PSP packet to notify the sender that the transmission failed. Upon receipt of the NAK packet, the sender reconstructs the packet and sends it again. If the receiver detects 698 more than three consecutive attempts which result in failure, the appropriate steps of error notification 700 are taken.
- NAK Negative Acknowledge
- FIG. 7 depicts the preferred device registration by the IOCB 200 of each device.
- the IOCB 200 Upon power up 710 or reset 702 , the IOCB 200 assigns 712 the same default physical I 2 C address 520 A (77h) to each device 3 . If registration of the device is not necessary, the IOCB 200 allocates 705 bus time for each device 3 to register. The IOCB 200 then dynamically assigns an I 2 C address 707 which is clocked out to the responding slave device. The IOCB 200 sets up 709 a table 554 corresponding to this address and populates 709 the table with the data it has received from this slave device. A Virtual ID 711 is assigned to this device 3 which the SBC 1 will use to invoke a software driver pertaining to this device 3 .
- the IOCB 200 creates 713 a PSP packet 500 (Virtual ID, a ‘R’egister Command, and the device particulars 715 , 717 ) and sends 719 the PSP Packet 500 to the SBC 1 .
- the SBC 1 checks 729 if this device is on file 727 , creates an ACKnowledging PSP Packet 733 with the value of “ACK” for the “Command” 735 , checks if the device 3 needs configuration 736 , adds configuration parameters to the “Body” of the packet 738 , and sends 743 a Register ACKnowledge command to the IOCB 200 confirming this device is valid and commits the tabled entry as valid 737 .
- the IOCB 200 Upon receipt of the acknowledgment 745 , the IOCB 200 adds 747 this I 2 C address 520 A to its polling list 554 . If this particular device 3 needs configuring 736 , the SBC 1 embeds 738 the configuration parameters into the message body 500 E of the Register ACKnowledge packet sent to the IOCB. The IOCB 200 resends 755 these parameters in the I 2 C packet sent to the device 3 .
- a Register NAK command is created 739 , 741 , and sent 743 to the IOCB 200 signifying registration denial of this device.
- the IOCB 200 Upon receiving a “NAK” packet 749 , the IOCB 200 re-sends 755 the Register NAK command to the device and removes 751 the device's I 2 C address 520 A in the table list of devices.
- the Device Board 4 re-initialises 702 , re-configures its address as 77h 712 , and attempts to register 705 . If after three attempts to register has failed 740 , the SBC 1 displays an error message 742 .
- each Device Board 4 On initial power-up ( FIG. 7 , 702 , 710 ) or reset, each Device Board 4 is programmed as default I 2 C address 77h (see FIG. 7 ) and, upon successful registration, the device's I 2 C address is added to the poll list 747 .
- the IOCB 200 periodically polls I 2 C address 77h for any response by following I 2 C standard protocols. The protocol mandates the IOCB 200 check if any device other than the IOCB 200 is asserting a clock 771 .
- the IOCB 200 sets the clock 773 , raises the clock line 777 , and, with the data line 252 high, lowers 775 the clock line 251 (start condition) thereby alerting all I 2 C devices 3 on the bus (Slaves), that the IOCB 200 (Master) is sending an address byte.
- the IOCB 200 creates 783 , 785 , 787 and sends 791 an I 2 C packet onto the data line. This packet has the address 77h “clocked out” on the data line, i.e., the first seven bits of the I 2 C address have a value of 77h and the eighth bit signifies either the IOCB's intent to read a byte from this address or write a byte to this address.
- the IOCB 200 expects an Acknowledge on the data line 719 (low condition) from a device 3 at this address.
- the Master will provide 831 the ninth clock for the expected ACK condition. Any devices 3 which do not have I 2 C address 77h ignore 853 this prompt condition 791 , 793 . If a device or devices 3 are at this address 795 (there may be several devices with the default value 77h on initial power-up), the device 3 asserts 797 , 801 the data line low at the appropriate time to respond to the IOCB 200 . If the poll is intended for device registration (it is on initial poll), the Master sets the Read flag 785 , 787 intending to read the responding device's registering data.
- the I 2 C protocol mandates a stop condition 833 (a terminating condition for each I 2 C transmission) which the Master (IOCB 200 or SBC 1 ) will provide.
- the Master of the I 2 C line always provides the clock signal 773 , even if a Read condition has been established and thus will read 829 the data as it provides the clock 773 by which the Slave sends the data.
- bus arbitration will come into play. As the IOCB provides each clock pulse 773 , the devices will assert 811 their particular data bit onto the data line, but each device will first sample 807 , 809 the data line to ensure its level is its intended level. If the level is not at the intended level, the particular device resets its I 2 C commitment 813 753 , and backs out of additional involvement 813 until it receives 815 the next address byte from the IOCB 200 . As arbitration may continue for several bytes, the surviving device 3 will have finally completed its registration packet to the IOCB 200 .
- the IOCB maintains the device table 554 in preferably the following format:
- the poll Command 520 D ‘Query will have 0 bytes in the message body.
- the IOCB's next sequential transmission number 520 C is 79 (the device 3 at this I 2 C 520 A address will be expecting this sequence number to be 79).
- the IOCB's I 2 C address 520 A is hardcoded at 8.
- the IOCB 200 as Master of the I 2 C bus, will clock out these data bytes to the Device Board 4 at this I 2 C address 520 A.
- the Write flag is set 789 in the packet's address byte 520 A indicating the IOCB 200 is sending data.
- the device 3 ACKnowledges each byte by asserting 799 , 801 the data line at the ACK clock bit time frame.
- the Read flag is set 821 in the address byte, and the IOCB 200 re-sends 791 this byte.
- the IOCB 200 now expecting to receive data, will provide the clock to the Slave, but reads each clocked data line pulse 829 for 1 or 0, capturing 8-bits per byte.
- the Master In this read mode, the Master must assert the ACK pulse 831 after each 8-bits 827 to tell the Slave that the Master has received this byte. When the Master has received a number of bytes equal to “size” 823 , it does not assert the ACK pulse and generates the stop condition 833 signifying the transfer has completed.
- the IOCB 200 receiving an ACK Command 825 to the polling Query states the device is active but has no information to send.
- the IOCB 200 As the IOCB 200 is the only Master on the I 2 C bus 250 , the IOCB 200 detects 771 the clockline asserted by any other device attempting to control the bus 250 during the polling process. After a small time-out 835 in the event there is a possible spike or glitch on the bus, the IOCB 200 retests and, if this condition still exists, the IOCB 200 asserts the clock line low 839 disrupting and prevents any further I 2 C communications on the bus 250 . The IOCB 200 also reports this condition 841 to the SBC 1 for error reporting. After the shut down, the IOCB 200 periodically releases the clock line 843 and retests 845 for the above violation.
- the IOCB 200 broadcasts ReRegister Commands 849 to all I 2 C devices 3 listed in the device table, requiring each to reset and reregister.
- the IOCB 200 also reports 851 the cleared condition to the SBC 1 .
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
- Bus Control (AREA)
- Multi Processors (AREA)
Abstract
Description
- This application claims priority to, and is a continuation of, co-pending U.S. application Ser. No. 11/095,097 having a filing date of Mar. 30, 2005, which claims priority to, and is a continuation of, U.S. application Ser. No. 09/701,168, now U.S. Pat. No. 7,093,040, which is a National Phase Application of International Application PCT/AU1999/00389, having an International filing date of May 21, 1999, which claims priority to U.S. Provisional Application No. 60/086,632, having a filing date of May 23, 1998, which is also incorporated herein in its entirety.
- The present invention is directed generally to an electronically secured inter-processor and virtual device communication system used in gaming machines and is directed more particularly to an electronically secured inter-processor and virtual device communications system with (1) an Input/Output Controller Board (hereinafter referred to as “IOCB”), (2) a multi-drop bus interfacing one or more device modules, (3) a parallel interface to an industry standard main single board computer (hereinafter referred to as the “SBC”) of the gaming machine and (4) a IOCB-to-device “Plug-N-Play protocol (the “Plug-N-Play Protocol”).
- Conventional methods of integrating a variety of components in a gaming machine currently require re-designing, re-wiring and re-programming the gaming machine as each new component is added. As technology advances, newer state-of-the-art devices are being offered to manufacturers of gaming machines that would greatly enhance the product, but manufacturers are inhibited, as removing and replacing the old devices with new devices, or simply adding the new device requires reprogramming the SBC and could require the re-design and/or replacement of the SBC.
- The industry standard SBC board, independent of the microprocessor used, has been designed using discrete components with EPROM memory chips containing software with an individual bus connected to each device. As most of the gaming machines in the market require some sort of regulatory approval, modifying a previously approved product requires a re-submittal to the regulatory agency with the re-submittal emphasising recertification of the programming of the new device in the CPU. With the software for each device residing in the EPROM, this requires reverification of the entire program.
- Especially for manufacturers with a significant installed base of gaming machines, retrofitting these machines with a newer device is an expensive proposition and a logistical nightmare. Utilising a ‘Plug-N-Play’ concept, the Invention, through the Input/Output Controller Board (IOCB), logically interconnects all the devices in the gaming machine to the SBC. The IOCB's communications to and from each device is based on a network-capable communications protocol, such as Philips' Inter-Integrated Circuit (I2C) two-wire Serial Interface (hereinafter “PHILIPS I2C”).
- As the IOCB logically interconnects the modules or potential modules to the SBC, the SBC and its EPROM memory chips do not have to be reprogrammed, resigned or replaced. Further, as no device related software resides on the SBC or its EPROMS, no new software needs to be resubmitted to any regulatory agency, as no new software is created. Instead each device in the machine incorporates an intelligent board with microprocessor (the “Device Board”) which is programmed specifically to the functions of that device. The Device Board also communicates via the communications protocol, such as PHILIPS I2C, to the IOCB in a multi-drop configuration. Replacing a device or adding a new device is simply a matter of connecting the communications interface (Clock, Data, Logic Power, System Ground) to the multi-drop bus interconnecting all the devices to the IOCB.
- The IOCB programming module continuously monitors the communications protocol interface (the PHILIPS I2C line) for device activity and relays these actions to and from the SBC. As new devices are added to the link, a specific registration protocol is followed which will allow the device to register with the IOCB. If the registering device has followed all the secured protocols, the specific parameters of the device (device type, Serial Number, etc.) are relayed to the SBC.
- The SBC has several modules programmed for all possible devices that may connect to the machine, such as a Coin In, Coin Out, and Bill Acceptor modules. Even though there may be several types of these devices, the appropriate SBC module simply monitors for coins in, coins out and bills accepted. The specific hardware and protocol of each connected device is level converted and formatted by each Device Board to a generic format required by the SBC module.
- Accordingly, an object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added to, replaced in or changed in a gaming machine without any need to reprogram or redesign the SBC of the gaming machine.
- A further object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added, replaced in, or changed in a gaming machine without a need to replace the SBC of the gaming machine.
- An additional object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to be added to, changed in, or replaced in a gaming machine without the need to modify the software residing in the CPU or any device so that a resubmittal to an appropriate regulatory body would not be necessary.
- Still another object of the invention is an electronically secured inter-processor and virtual device communication system which cost-effectively allows devices to be changed in a gaming machine.
- Furthermore, an object of the invention is an electronically secured inter-processor and virtual device communication system which allows devices to most efficiently be added to, replaced in or changed in a gaming machine.
- An additional object of the invention is an electronically secured inter-processor and virtual device communication system with a protocol which supports dynamic assignment of device addresses.
- Still a further object of the invention is an electronically secured inter-processor and virtual device communication system which provides reliable and secure communications among interprocessors.
- These and other objects of the invention, which shall become apparent hereafter, are achieved by providing an electronically secured inter-processor and virtual device communication system, including an IOCB connecting a multitude of peripheral gaming machine devices and the SBC through parallel interface. In an embodiment, the IOCB provides an interface between the SBC of the gaming machine and the machine's devices and is connected to the SBC through a parallel interface. The IOCB uses a multi-drop communication bus for its connection with the devices requiring at least four wires for the clock, data, logic power, and system ground protocol. Each device contains its own CPU board programmed for the specific device. When power is first applied to the gaming machine, the IOCB attempts to establish a link with the SBC by placing a ‘link request’ transaction in the IOCB's transmit queue and commencing an idle state. The IOCB then remains in an idle state until the SBC acknowledges a physical connection. Once the SBC acknowledges a physical connection, the IOCB sends the ‘link request’ transaction to the SBC, preferably through the IOCB's Parallel Slave Port (Data) (the “PSP-Data”). When the link is established, the IOCB sends a framed packet to the SBC containing the Virtual ID and device registration commences. Independently of the SBC and the IOCB, each device's CPU attempts to register the device's hardware with the IOCB through the multi-drop bus. As the IOCB registers each device, the IOCB assigns an communications protocol address, preferably the PHILIPS I2C address, to the device and creates a device table entry containing data uniquely identifying the device, such as type of device, serial number, and the communications protocol address. As each device is registered, the SBC assigns and stores a virtual identification number (the “Virtual ID”). After all devices are registered, the IOCB stores information about each registered device and transfers any pertinent packets received from a device to the SBC.
- In a preferred embodiment, the IOCB is the only external device interfacing the SBC with the gaming machine's devices such as Deck Buttons and Lamps, Coin In Mechanisms, Coin Out Hoppers, Bill Acceptors, Magnetic-Stripe Card Readers, Keypads, Progressive Display Interfaces, Ticket Printers, Coupon Dispensers, Hard Meters and general Security switches in the machine. The IOCB's physical connection to the SBC is preferably via a parallel interface on the SBC, preferably a PC-104 bus which is capable of transfer rates up to 8 million bytes per second. The data transfer between the IOCB and SBC is interrupt-driven and controlled by an 8-bit register.
- The IOCB interfaces the listed devices through a Multi-Drop communication scheme using a network-capable communications protocol, such as RS-485, USB, current loop, or preferably Philips Corporation's two-wire Inter-Integrated Circuit (I2C) serial interface and corresponding communications protocol (“hereinafter “I2C protocol”), which enables speeds up to 400 kbps.
- The communications protocol, preferably the I2C protocol, ensures reliable transmission and reception of data. When transmitting data, only one apparatus, preferably the IOCB, is the ‘master’ which initiates transfer on the bus and generates the clock signals to permit that transfer, while the other device(s) acts as the ‘slaves’.
- The Philips communication protocol (“I2C Protocol”) operates on top of Philip's published industry standard I2C protocol. Additional information on the PHILIPS I2C specification can be obtained from the document “The I2C bus and how to use it”, #939839340011, available from the Philips Corporation.
- The communications protocol, preferably the I2C protocol, constitutes the physical layer for the invention's IOCB to Device ‘Plug-N-Play’ protocol, which is a packet-driven securitized protocol.
- The preferably I2C framed ‘Plug-N-Play’ protocol supports dynamic assignment of I2C addresses, facilitates reliable communications between I2C devices and the IOCB and provides a secured link for inter-processor communications.
- A multi-wire Multi-Drop bus, preferably a four-wire multi-drop bus (Clock, Data, Logic Power, System Ground), interconnects all devices throughout the machine to the IOCB. Each device is equipped with a firmware-based CPU board which is programmed to the specific parameters and purpose of each device. Each device's CPU board is capable of communicating with the communications protocol, preferably the I2C protocol.
- Messages are routed to and from the IOCB to the devices using a communications protocol framed packet, preferably an I2C framed packet comprised of an I2C address, header, body and footer, as specified below.
- To prevent statistical breakdown of the CRC-16, packets will be limited to a maximum of 255 bytes inclusive of the I2C Address and Footer. Message bodies larger than 248 bytes must be broken up into multiple communications protocol framed packets, preferably I2C framing packets.
- When power is first applied to the gaming machine, the IOCB attempts to establish a link with the SBC by placing a ‘link-request’ transaction in the IOCB transmit queue, which commences an idle state. The IOCB remains in this idle state until the SBC acknowledges a physical connection. Upon receiving acknowledgment of the physical connection, the IOCB sends this link request transaction to the SBC via preferably the Parallel Slave Port (PSP Data) of the IOCB through a PSP-framed packet containing the Virtual ID of the device. Once the link is established, device registration begins. Neither the IOCB nor the SBC has knowledge of the devices integrated in the machine. Each device's CPU will attempt to ‘register’ its specific hardware with the IOCB by communication through the communications protocol multi-drop bus, preferably a I2C Multi-Drop bus. As each device is registered by the IOCB, the IOCB dynamically assigns a communications protocol address (range 9-76h), preferably an I2C address, to the device and enters the device information into a device table which stores the device's specific data (type of device, serial number, etc.). As long as power is applied to this device, a device responds to IOCB requests using this communications protocol address, such as an I2C address. The IOCB also assigns Virtual ID (Circuit Number) to the device referencing the device to the SBC. The SBC uses this Virtual ID to invoke a software driver referencing this device type regardless of its communications protocol, preferably I2C, address. The Virtual ID remains assigned to the device and, should the device lose power, upon re-registering, the device may receive a different communications protocol, preferably I2C, address but will maintain the same Virtual ID. This process repeats until all devices have been registered.
- As each new device is dynamically registered, a table entry in the IOCB's device table is created for that device. As the IOCB is continuously polling these registered devices, the IOCB will detect removal of a device and will send notification to the SBC.
- After device registration, utilising a prioritized polling scheme, the IOCB will query each registered device for status. The IOCB either receives a ‘no activity’ packet or a packet containing pertinent data for that device. If required, the IOCB transfers a valid packet to the SBC via preferably the PSP-Data port.
- If a registered device fails to respond to its poll after a fixed number of retries, the IOCB declares the device ‘inactive’ by sending an appropriate PSP framed transaction to the SBC.
- The IOCB communicates with the SBC via a parallel port connected to a PC-104 bus on a SBC. The interrupt-driven data transfer is controlled by a shared 8-bit register which is used as handshaking flags for flow control.
- The communications protocol bus is a multi-wire communications interface, preferably a I2C bus with a two-wire serial interface developed by the Philips Corporation which enables speeds up to 400 kbps.
- The IOCB will be interrupted by the PSP-Data if the SBC initiates any PSP framed transactions. If the SBC initiates a transaction, the IOCB will wrap the PSP framed characters with communications protocol framing characters, such as I2C framing characters, sending this data to the appropriate device at that communications protocol address.
- In any setting, the IOCB's sole responsibility is to direct secured data transactions to and from the SBC and to and from the gaming machine's devices. The IOCB does not initiate or control any functions of the gaming machine.
- The invention would be better understood from the following Detailed Description of the Preferred and Alternate Embodiments, with reference to the accompanying drawings, of which:
-
FIG. 1 is one embodiment of the invention showing the SBC of the gaming machine connected to the IOCB and connected to seven devices through device boards in a multi-drop bus configuration. -
FIG. 2 is an embodiment of the invention, showing the preferred PC-104 bus of the SBC connected through a preferred parallel interface by an 8-bit bi-directional bus to two parallel slave ports (PSP-Data and Control, and the 8-bit register) of the IOCB. -
FIG. 3 is a preferred embodiment of the invention, showing the IOCB connected in a multidrop configuration with four wires to five devices. -
FIG. 4 is a flow chart showing the transmission of data from the SBC to the devices through the IOCB. -
FIG. 5 is a flowchart showing the transmission of data from the devices to the SBC through the IOCB. -
FIG. 6 is a flowchart depicting the four-level security of the invention, which ensures the validity of data transfers, and -
FIG. 7 is a flowchart depicting the registration of devices by the IOCB. - Referring to the drawings, wherein like numerals reflect like elements throughout the several views,
FIG. 1 depicts the SBC (generally 1) of the gaming machine, as connected to the Input/Output Controller Board (“IOCB”) (generally 200). TheIOCB 200 is connected in amulti-drop bus configuration 250 to the devices (3A, 3B, 3C, 3D, 3E, 3F, 3G), each device with its own microprocessor inclusive board (respectively, 4A, 4B, 4C, 4D, 4E, 4F, 4G). The devices depicted are acoin comparator 3A, abill validator coupon 3B, a coin outhopper 3C, amagnetic card reader 3D, acoupon dispenser 3E, aprogressive interface 3F, and a deck buttons/lamps 3G. Each device (3A through 3G) has its own board (4A through 4G) (the “Device Boards”) and is virtually connected to the SBC 1 and to the other devices through themulti-drop bus configuration 250. - The SBC 1 is capable of digital storage, contains a microprocessor, preferably a Pentium II, and preferably contains sound and video capability, wave file capability, networking capability, and modem connections.
- The
IOCB 200 is a Microprocessor based electronic board featuring a microprocessor, preferably a PIC 17C756, preferably on-board Random Access Memory (RAM), preferably Non-Volatile RAM, preferably timer/counters, preferably Capture/Compare/PWM modules, preferably two 8-bit parallel ports (Parallel Slave Port (PSP)Data 201, PSP Control 202), preferably one Serial Communications Interface, preferably two-wire Inter-Integrated Circuit (I2C)bus 203, preferably internal/external Interrupt sources, preferably a Watchdog Timer, preferably a Brownout detection and preferably Programmable code-protection. TheIOCB 200 has the ability to set up and communicate in the communications protocol standard, to communication with at least one device, and to perform distributed processing. - Attached to each
device 3A through 3G in the gaming machine is a Microprocessor based electronic CPU board (the “Device Board.”) 4A through 4G. Each board is specifically designed and programmed to interface with the specific function of its associated device. The devices are connected to theIOCB 200 in amulti-drop configuration 250. Each board is capable of communicating in a communications protocol, preferably an Inter-Integrated Circuit (I2C) communications protocol, and contains a microprocessor, preferably a PIC 16C67. Integrated components of the board (size of RAM, high current output drivers, etc.) are application specific. Eachboard IOCB 200 as another signature verification in the calculation of the CRC-16. -
FIG. 2 depicts the preferred PC-104port 100 of the SBC 1 connected by preferably an 8 bit bi-directional bus to preferably the IOCB's PSP-Data 201 and PSP-Control 202 port and to the IOCB's 8-bit register. - Communication to and from the SBC 1 is accomplished through the IOCB's 8-bit PSP Data and PSP-
Control port 201, 202 and the SBC's PC-104bus 100 and the bi-directional interrupt driven data transfers utilise a shared 8-bit register 205 which regulates data direction and flow control. Depending on its specific task, theIOCB 200 will set and reset the handshaking control bits, with the SBC 1 to monitor these status bits. - Each bit of the 8
bit regiter 205 preferably is populated as follows: -
bit 7 6 5 4 3 2 1 0 RTR RA RTT TA CONNECT 0 ZERO RESET - Bit 7—Ready To Receive (RTR) 202A preferably indicates, if set, that the
IOCB 200 is ready to receive a data byte. If the SBC 1 has a character to send, it reads this statusbit and if set, will send the character. If reset, a time-out interval is initiated and if it expires, the SBC will report an error which locks up the game. -
Bit 6—Receive Aborted (RA) 202B preferably indicates, if set, that the IOCB has detected a communication error while receiving data. The SBC 1 also monitorsbit 6 prior to sending a character, and ifBit 6 is set, the SBC 1, will abort the balance of the transmission and retry again. - Bit 5—Ready To Transmit (RTT) 202C preferably indicates, if set, that the
IOCB 200 has data to send. When set, this bit asserts Interrupt Request 11 (IRQ11) on the SBC 1. Once the interrupt has been serviced and the character has been read, theIOCB 200 notifies itsPSP hardware 201, 202 and resets this bit. TheIOCB 200 then generates a Transmit Data Register Empty interrupt, signalling that another character may be sent. -
Bit 4—Transmit Abort (TA) 202D preferably indicates, if set, that theIOCB 200 has detected an internal transmission error while transmitting a packet to the SBC 1 and that no more data will be sent. If the SBC 1 detects that this bit is set, it will clear any previous characters received and abort the receive process. -
Bit 3—Busy 202E preferably indicates, if set, that theIOCB 200 is busy processing a critical application and prevents the SBC 1 from an erroneous time-out on a data transfer. TheIOCB 200 sets this bit upon entering a critical application, resetting it upon completion. The SBC 1 will initiate a longer time-out interval, but upon expiration, will report an error locking up the game. - Bit 2—0 202F This bit is reserved for future use.
- Bit 1—
Connect 202G preferably indicates, if set, that the handshaking flags of this register should be ignored. TheIOCB 200 sets this bit to the value 1 (indicating high impedance) if theIOCB 200 and SBC 1 are disconnected, as the tri-state inputs of the PSP hardware will be high. TheIOCB 200 sets this bit to the value 0 if theIOCB 200 and SBC 1 are connected. These tri-state inputs (high, low, high-impedance) prevent interference between multiple devices attempting to access the line and allow theIOCB 200 to act as a traffic controller. TheIOCB 200 always resets the bit to prevent erroneous actions based on bit levels being set. - Bit 0—
Reset 202H preferably indicates to the SBC 1, if set, that theIOCB 200 has been up or reset, alerting the SBC 1 to set the ‘state’ of the gaming devices in the machine. That bit is reset each time initial communications are established between theIOCB 200 and the SBC 1. -
FIG. 3 depicts the interconnections among theIOCB 200 and fivedevices 3 in the preferred I2Cmulti-drop configuration 250. The IOCB's I2C port 203 is connected to eachDevice Board 4 through preferably a four-wire multi-drop bus 250. The preferred I2C capablemulti-drop bus 203 has preferably four wires (clock 251,data 252,Logic Power 253 and System Ground 254) which are distributed through the machine, providing theDevice Boards 4 with a means to utilise the clock, data, power and a ground of theIOCB 200. Eachdevice 3 is equipped with a Microprocessor based electronic circuit board 4 (the “Device Board”) which is specifically designed to interface with the device's input or output signals depending on the device. TheDevice Boards 4 are capable of communicating using network-capable communications protocols, preferably Inter-Integrated Circuit (I2C) protocols, enabling interconnection among thedevices 3. In the preferred I2Cmulti-drop bus 250,clock 251,data 252,Logic Power 253 andSystem Ground 254 are distributed in each device providing a clock, data transmission, power and ground to theDevice Boards 4. ADevice Board 4 can be attached to more than oneDevice 3. In that event, more than one device will have a single communications protocol address (preferably an I2C address), but each device will have a unique Virtual ID. -
FIG. 4 depicts data transfers of SBC-initiated transmissions between thedevices 3 and the SBC 1 through theIOCB 200. Data transfers between theIOCB 200 and the SBC 1 are based on a PSP framedpacket 500 with the preferably following protocol: -
- [Virtual ID] [size] [sequence #] [Command] [ . . . body . . . ] [ETX] [CRC-16]
-
Virtual ID 500A: this byte preferably contains a circuit number or reference number by the SBC 1 determines which device-specific software driver is used to interpret a message received from thedevice 3 or to generate the particular data sent to thedevice 3. -
Size 500B: this byte preferably contains the character length of the PSP framed packet fromVirtual ID 500A to the CRC-16 500G inclusive. - Sequence 500C: this byte preferably contains the message sender's next sequential number. The message receiver maintains an expected sequential reception number corresponding to the message sender's Virtual ID. This sequence number is initiated to a 0 value and is incremented by 1 for each successful transmission, wrapping at the value of 255 back to a value of 1. The value of 0 is only used on initial setup, and if the value is 0, the message receiver resets its expected sequence number. The sequence number provides additional security to ensure that all transmissions are received (see
FIG. 6 ). If the message receiver has accepted the valid transaction (all packet criteria has been satisfied), this constitutes a successful transmission and the message receiver responds to the message sender by transmitting an acknowledge (ACK) packet which will cause the message sender and receiver to increment their sequence numbers. - Command 500D: this byte preferably informs the message receiver what to do with the (if any) in the body of the message. For example, if this bytes contains “ACK”, this acknowledges the message sender's last received packet and contain 0 bytes in the body of the message. Similarly, the
IOCB 200 sends a Link Request command (with 0 bytes) to the SBC 1 on power-up, which requests a communication link. In an additional example, a Bill Acceptor transaction with a command of ‘B’ signifies that the Bill Denomination is in the message body and contains four bytes in the body of the message. “ACK” has the hexadecimal value of 06, indicating a positive acknowledgment. “NAK” has the hexadecimal value of 15, indicating a negative acknowledgment. -
Body 500E: this byte preferably contains a variable number of bytes from 0 to 248, contains pertinent data regarding the transaction. For example, this field may contain the denomination of the bill accepted, the coin denomination, or the Player's Account Number processed by the Magnetic Card Reader. The actual specific data contained are determined by the Virtual ID involved. -
ETX 500F: this End of Transmission (ETX) byte is preferably used for packet. ETX has a hexadecimal value of 04, signalling End of the Transmission. - CRC-16 500G: this two-byte field preferably is a 16-bit Cyclic Redundancy Check (CRC) value, used for packet validation and security. The CRC-16 value is generated using a 16-bit reverse polynomial-based algorithm performed on each transmitted/received byte. This 16-bit value is initially set to 0 and each byte of each
Device Board 4 and the device type byte (Coin Mechanism, Bill Acceptor, etc.) is cyclic redundancy checked (CRC'd). 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. A CRC value is generated for each packet and includes the entire packet, from Virtual ID to ETX inclusive. A packet's CRC value is compared to the device's 3 seed and should be equivalent if the packet has been successfully transmitted. The CRC-16 ‘seeding’ is applied to all transactions except the ‘Register Command, which is used when adevice 3 is being registered for inclusion in the device table (seeFIG. 7 ). With the Register command, the receiver does not have any knowledge of the Board ID or the type of device registering in the communication packet, the seed is assumed to be 0. In the examples, the CRC-16 value of ‘OxCCCC’ is used for reference only. The actual 16-bit value would vary depending on the data bytes in the packet.
- Communication packets transferred between the SBC 1 and the IOCB 200 (PSP framed packets 500) preferably have a
Virtual ID 500A embedded in the packet which is used to steer the transaction to the appropriate software driver of the appropriate device. Communication packets transferred between theIOCB 200 and the device 3 (preferably I2C framed packets 520) preferably use an I2C address 520A to steer the transaction. TheIOCB 200 directs transactions both between theIOCB 200 and the SBC 1 and between theIOCB 200 and thedevices 3. Due to its dual function, theIOCB 200 must wrap 524, 525, 526, 527 the SBC-generatedPSP packet 500 with preferably I2C framing 520 prior to sending 528 the packet to a device. Likewise, it must unwrap (FIG. 5 , 616) the preferably I2C frame 520 from the device generatedPSP packet 500 prior to sending the packet to the SBC 1. - Each
Device Board 4 may have more than one physical device attached to it. For example, aDevice Board 4 may be attached to two hoppers, one to dispense coins, the other to dispense tokens. As aDevice Board 4 has only one communications protocol address, preferably the I2C address 520A, but twoVirtual IDs 500A, theIOCB 200checks 552 its device table 552 for two table entries with the 1 same I2C address 520A. Utilising both the PSP and the I2C framed protocols, theIOCB 200 directs 528 both SBC 1 generated commands (in our example, ‘C’ & ‘T’) to the same I2C address 520A. TheDevice 3 at that I2C address 520A will unwrap 544 the I2C framing bytes and act on 546, 548 the PSP Virtual ID's Command byte 500D andmessage body 500E. - The following example further illustrates the process by which the
IOCB 200 wraps a PSP framedpacket 500. The SBC 1 wants to turn onDeck Lamp # 4 with the device's Virtual ID of 126, the sender's next sequential transmission number of 56, and the command byte of ‘L’. Using the followingPSP packet format 500 and values: -
[Vir- [se- tual quence [Com- ID] [size] #] mand] [body] [ETX] [CRC-16] [126] [8] [56] [L] [0x04] [ETX] [0xCCCC] - The
PSP packet 500 will contain the above listed data. Assuming there are no communication errors and the packet criteria is acceptable (seeFIG. 6 ), theIOCB 200 references its device table 554, finds this Virtual ID value 126 at I2C address value 32. By these values, theIOCB 200 determines 551 that thedata packet 500 initiated from the SBC 1, determines 553 that the received data packet is not intended for theIOCB 200 and thereby ignores 555 the sequence number 500C, the Command 500D and thebody 500E of this packet. TheIOCB 200 uses thesize byte 500B only to count down the received bytes, i.e. mark the end of thepacket 557. - The
IOCB 200 then wraps this packet with its own I2C frame. TheIOCB 200 first creates 525 themessage body 520 E of anI2C packet 520 from thePSP packet 500. TheIOCB 200 assigns the value of “M” 526 to theCommand byte 520D in the I2C packet 520 signifying that the SBC 1 originated this transaction. TheIOCB 200 then assigns 527 the next available sequential transmission number from theIOCB 200 to thesequence number 520C for this I2C address 520A. The I2C packet 520 is assigned the I2C address 520A of 32 (524). In the example, the I2C packet is populated as follows: -
[I2C [se- Ad- quence [Com- dress] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [32] [15] [143] [M] [PSP pkt] [ETX] [OxCCCC] - The
IOCB 200 then sends 528 the I2C packet 520 to thedevice 3. Assuming there are no communication errors and the packet criteria is acceptable 536, 538, thedevice 3 sends an I2C framedpacket 520 to theIOCB 200 acknowledging (ACK) itstransmission 532. Upon receiving theacknowledgment 560, theIOCB 200 creates and sends 560 a PSP-framedpacket 500 to the SBC 1 acknowledging the Virtual ID has accepted its transaction. - If the I2
C Command byte 520D of ‘M’ indicates the SBC 1 originated thistransaction 542, as opposed to theIOCB 200, the I2C body 500F contains thePSP packet 500 sent by the SBC 1. Thedevice 3 at this I2C address unwraps the I2C framing bytes 544, reads 546 the PSP framed packet Command (‘L’ in our example) and acts on 548 the Command by turning onLamp # 4. -
FIG. 5 depicts data transfers for device-initiated transmissions among thedevices 3 and the SBC 1 through theIOCB 200. The communications protocol framed packet, preferably the I2C framedpacket 520, is transferred between theIOCB 200 and thedevice 3. Each preferred I2C framed packet is comprised of the following parameters. -
- I2C Address 520A
- Range 9 to 76h,
- 0 reserved for Broadcast Address,
- 1-7 reserved for I2C implementation,
- 8 reserved for the IOCB Address,
- 77h reserved for unregistered devices.
-
Header - The “ACK” value for Command has a hexadecimal value of 06, indicating a successful transmission, and the “NAK” value for Command has a hexadecimal value of 15, indicating an unsuccessful transmission.
-
Body 520E—Up to 248 bytes of binary data. -
Footer
- I2C Address 520A
- For example, a
Device Board 4 has threedevices 3 attached to it: Deck buttons, Deck lamps, and a Coin-in Mechanism. Each of thesedevices 3 is assigned its ownVirtual ID 500A but theDevice Board 4 only possesses one I2C address 520A. In the example, the Coin-in Mechanism's Virtual ID is 41, the Deck button's Virtual ID is 14, and the Deck lamp's Virtual ID is 126. The I2C address 520A is 39. - Assume a coin has been inserted in the gaming machine. The
Device Board 4 detects this Coin-in action and, using the Coin-In Mechanism'sVirtual ID 500A of 41, sequence number 500C of 214, Command 500D of ‘T’, and thecoin value 500E of 25 (hex 19), thedevice 3 generates 572, 574, 576, 578 the followingPSP packet 500 with the following values: -
[Vir- [se- tual quence [Com- ID] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [41] [9] [214] [,I,] [0x0019] [ETX] [0xCCCC] - The
PSP packet 500 is intended for the SBC 1, and, accordingly, thePSP Packet 500 must be encapsulated within an I2C packet for delivery to theIOCB 200 to be delivered to the SBC 1. ThePSP packet 500 becomes thebody 520E of the I2C packet 520 (586), for which the additional following value are assigned 586, 588, 590, 592, 594, 596 to the I2C packet 520: the IOCB's hard-coded I2C address 520A of 8, asequence number 520 C of 79, an I2C Command 520D of ‘D’ signifying “Device” originated, creating the following I2C packet 520: -
[I2C [se- Ad- quence [Com- dress] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [8] [16] [79] [D] [PSP pkt] [ETX] [OxCCCC] - The
device 3 waits 610 until the next poll received from theIOCB 200 and then sends 612 the I2C packet 520 to theIOCB 200. Once theIOCB 200 receives the packet, it checks the “command”byte 520D of the I2C packet and, if “Command” equals “D” (for device) 614, theIOCB 200 strips 616 the I2C framing characters. TheIOCB 200 then sends 618 thePSP packet 500, extracted from thebody 520E of the I2C packet 520, to the SBC 1 as: -
[Vir- [se- tual quence [Com- ID] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [41] [9] [214] [I] [0x0019] [ETX] [OxCCCC] - This
PSP packet 500 is the original packet generated by the Device 3 (see 572, 574, 576, 578, 580, 582, 584). The SBC 1, upon receiving a coin-in transaction, checks if there are anycommunication errors 622 and if the packet criteria is acceptable 620 (seeFIG. 6 ). If the packet is okay, the SBC 1 takes appropriate internal action. If the packet has been validly transmitted, the SBC 1 also sends an ACK transaction to theDevice 3. First, the SBC 1 generates 624 the following PSP framedpacket 500, assigning “Command” 520D the value of “ACK” 626, assigningother values 528, and sends 633 it to theIOCB 200 as: -
[Vir- [se- tual quence [Com- ID] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [41] [7] [214] [ACK] [0 bytes] [ETX] [OxCCCC] - Once again, the
IOCB 200 encapsulates 634 thisPSP packet 500 with its I2C framing characters, looks up the I2C address 520A associated with theVirtual ID 638, assigns the I2C address 640, assigns the value of “M” to “Command” 520D, creating the following I2C packet 520. TheIOCB 200 then sends this I2C packet 520 to the I2C address 520A found in its device table for thisVirtual ID 500A: -
[I2C [se- Ad- quence [Com- dress] [size] #] mand] [. . . body . . .] [ETX] [CRC-16] [39] [14] [79] [M] [PSPpkt] [ETX] [OxCCCC] - Once the
Device Board 4 detects thetransmission 644 and ascertains that it was sent from the SBC 1 646, theDevice Board 4 at the I2C address 520A strips 648 the I2C framing characters and decodes 650 thePSP packet 500 embedded in thebody 520E the I2C packet 520. The ACK Command confirms 652 to theDevice 3 that the transaction was accepted by the SBC 1. - If appropriate, the SBC 1 generates another transaction 621 to be sent to the
Device 3 responsible for updating the hard meter associated with this coin-in transaction. -
FIG. 6 depicts the preferred security devices of the invention which ensure the validity of the data transmissions. Each time adevice 3 or the SBC 1 sends a transmission, uponreceipt 670 of the packet, the receiving module (the Receiver) checks the I2C packet 520 received to ensure validity of the received packet. First, the Receiver counts the number of characters received 672 and compares 674 this value to the “size” field of the received packet. If the packet passes this test, the Receiver then checks 676 if the “sequence number” of the received packet equals the receiver's next expected sequence number. If the packet passes this test, the Receiver checks if the ETX code is detected 678 at the correct index in the packet. Lastly, the Receiver calculates 680 the CRC-16 value of the received packet and checks 682 if the 16-bit CRC value received is equal to the calculated 16-bit CRC. If any of these tests fails, this indicates a communication failure and the Receiver creates aNAK packet 684, assigning “Command” a value of “NAK” 686, assigning theother values 688, and wraps 690 the PSP packet to notify the sender that the transmission failed. Upon receipt of the NAK packet, the sender reconstructs the packet and sends it again. If the receiver detects 698 more than three consecutive attempts which result in failure, the appropriate steps oferror notification 700 are taken. - Should a transmitted packet fail any validation check, the receiver will send a Negative Acknowledge (NAK)
packet times 698 before declaring acommunication failure 700 causing the sender to re-enter theinitialisation state 702 and attempt to re-establish a communication link (seeFIG. 6 ). -
FIG. 7 depicts the preferred device registration by theIOCB 200 of each device. Upon power up 710 or reset 702, theIOCB 200 assigns 712 the same default physical I2C address 520A (77h) to eachdevice 3. If registration of the device is not necessary, theIOCB 200 allocates 705 bus time for eachdevice 3 to register. TheIOCB 200 then dynamically assigns an I2C address 707 which is clocked out to the responding slave device. TheIOCB 200 sets up 709 a table 554 corresponding to this address and populates 709 the table with the data it has received from this slave device. A Virtual ID 711 is assigned to thisdevice 3 which the SBC 1 will use to invoke a software driver pertaining to thisdevice 3. TheIOCB 200 creates 713 a PSP packet 500 (Virtual ID, a ‘R’egister Command, and the device particulars 715, 717) and sends 719 thePSP Packet 500 to the SBC 1. The SBC 1checks 729 if this device is onfile 727, creates an ACKnowledging PSP Packet 733 with the value of “ACK” for the “Command” 735, checks if thedevice 3 needsconfiguration 736, adds configuration parameters to the “Body” of thepacket 738, and sends 743 a Register ACKnowledge command to theIOCB 200 confirming this device is valid and commits the tabled entry as valid 737. Upon receipt of theacknowledgment 745, theIOCB 200 adds 747 this I2C address 520A to itspolling list 554. If thisparticular device 3 needs configuring 736, the SBC 1 embeds 738 the configuration parameters into themessage body 500E of the Register ACKnowledge packet sent to the IOCB. TheIOCB 200 resends 755 these parameters in the I2C packet sent to thedevice 3. - If the SBC 1 has no information on this
device 731, or thisdevice 3 is not allowed in thismachine 731, a Register NAK command is created 739, 741, and sent 743 to theIOCB 200 signifying registration denial of this device. Upon receiving a “NAK”packet 749, theIOCB 200re-sends 755 the Register NAK command to the device and removes 751 the device's I2C address 520A in the table list of devices. TheDevice Board 4re-initialises 702, re-configures its address as 77h 712, and attempts to register 705. If after three attempts to register has failed 740, the SBC 1 displays anerror message 742. - On initial power-up (
FIG. 7 , 702, 710) or reset, eachDevice Board 4 is programmed as default I2C address 77h (seeFIG. 7 ) and, upon successful registration, the device's I2C address is added to thepoll list 747. TheIOCB 200, periodically polls I2C address 77h for any response by following I2C standard protocols. The protocol mandates theIOCB 200 check if any device other than theIOCB 200 is asserting a clock 771. If not, theIOCB 200 sets the clock 773, raises the clock line 777, and, with thedata line 252 high, lowers 775 the clock line 251 (start condition) thereby alerting all I2C devices 3 on the bus (Slaves), that the IOCB 200 (Master) is sending an address byte. During registration, theIOCB 200 creates 783, 785, 787 and sends 791 an I2C packet onto the data line. This packet has the address 77h “clocked out” on the data line, i.e., the first seven bits of the I2C address have a value of 77h and the eighth bit signifies either the IOCB's intent to read a byte from this address or write a byte to this address. - The
IOCB 200 expects an Acknowledge on the data line 719 (low condition) from adevice 3 at this address. The Master will provide 831 the ninth clock for the expected ACK condition. Anydevices 3 which do not have I2C address 77h ignore 853 this prompt condition 791, 793. If a device ordevices 3 are at this address 795 (there may be several devices with the default value 77h on initial power-up), thedevice 3 asserts 797, 801 the data line low at the appropriate time to respond to theIOCB 200. If the poll is intended for device registration (it is on initial poll), the Master sets the Read flag 785, 787 intending to read the responding device's registering data. - The I2C protocol mandates a stop condition 833 (a terminating condition for each I2C transmission) which the Master (
IOCB 200 or SBC 1) will provide. Under I2C mode, the Master of the I2C line always provides the clock signal 773, even if a Read condition has been established and thus will read 829 the data as it provides the clock 773 by which the Slave sends the data. - If multiple devices respond 803 to the IOCB's 77h address byte, bus arbitration will come into play. As the IOCB provides each clock pulse 773, the devices will assert 811 their particular data bit onto the data line, but each device will first sample 807, 809 the data line to ensure its level is its intended level. If the level is not at the intended level, the particular device resets its I2C commitment 813 753, and backs out of additional involvement 813 until it receives 815 the next address byte from the
IOCB 200. As arbitration may continue for several bytes, the survivingdevice 3 will have finally completed its registration packet to theIOCB 200. - The IOCB maintains the device table 554 in preferably the following format:
-
- Address—Dynamically assigned I2C address.
- Device Type—Type of device (i.e. Coin mech., Bill acceptor,).
- Sub-Type—Specific Make or Model.
- Serial #—Unique Board Identification Number (Board ID).
- Status—Last reported status.
- Priority—Polling priority.
- Virtual ID—SBC's end to end reference #.
- As the
IOCB 200 is continuously polling, the following example will detail a typical poll transaction to the device at I2C address 39. Thepoll Command 520D ‘Query will have 0 bytes in the message body. The IOCB's nextsequential transmission number 520C is 79 (thedevice 3 at this I2C 520A address will be expecting this sequence number to be 79). The IOCB's I2C address 520A is hardcoded at 8. -
[12C Ad- [se- [Com- dress] [size] quenced] mand] [body] [EXT] [CRC-16] [39] [7] [79] [‘Q’] [0 bytes] [EXT] [OxCCCC] - The
IOCB 200, as Master of the I2C bus, will clock out these data bytes to theDevice Board 4 at this I2C address 520A. The Write flag is set 789 in the packet's address byte 520A indicating theIOCB 200 is sending data. Thedevice 3 ACKnowledges each byte by asserting 799, 801 the data line at the ACK clock bit time frame. When theIOCB 200 has sent all bytes 819, the Read flag is set 821 in the address byte, and theIOCB 200 re-sends 791 this byte. TheIOCB 200, now expecting to receive data, will provide the clock to the Slave, but reads each clocked data line pulse 829 for 1 or 0, capturing 8-bits per byte. -
[I2C [se- Ad- quenced [Com- dress] [size] #] mand] [body] [EXT] [CRC-16] [8] [7] [79] [ACK] [0 bytes] [EXT] [OxCCCC] - In this read mode, the Master must assert the ACK pulse 831 after each 8-bits 827 to tell the Slave that the Master has received this byte. When the Master has received a number of bytes equal to “size” 823, it does not assert the ACK pulse and generates the stop condition 833 signifying the transfer has completed. The
IOCB 200 receiving an ACK Command 825 to the polling Query, states the device is active but has no information to send. - As the
IOCB 200 is the only Master on the I2C bus 250, theIOCB 200 detects 771 the clockline asserted by any other device attempting to control thebus 250 during the polling process. After a small time-out 835 in the event there is a possible spike or glitch on the bus, theIOCB 200 retests and, if this condition still exists, theIOCB 200 asserts the clock line low 839 disrupting and prevents any further I2C communications on thebus 250. TheIOCB 200 also reports this condition 841 to the SBC 1 for error reporting. After the shut down, theIOCB 200 periodically releases the clock line 843 and retests 845 for the above violation. If a retest shows the clock line is clear 847, theIOCB 200 broadcasts ReRegister Commands 849 to all I2C devices 3 listed in the device table, requiring each to reset and reregister. TheIOCB 200 also reports 851 the cleared condition to the SBC 1. - Due to the inherent security built in the preferred I2C protocol, and the internal security checks designed into the
IOCB 200 and SBC 1, as described above, it is virtually impossible for an alien device to invade the bus, or for a device to attempt communications with another device without the IOCB's knowledge and subsequent intervention. - It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.
Claims (22)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/403,687 US20120246346A1 (en) | 1998-05-23 | 2012-02-23 | Secured inter-processor and virtual device communications system |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US8663298P | 1998-05-23 | 1998-05-23 | |
US09/701,168 US7093040B1 (en) | 1998-05-23 | 1999-05-21 | Secured inter-processor and virtual device communications system for use in a gaming system |
PCT/AU1999/000389 WO1999061994A1 (en) | 1998-05-23 | 1999-05-21 | Secured inter-processor and virtual device communications system |
US11/095,097 US8147326B2 (en) | 1998-05-23 | 2005-03-30 | Secured inter-processor and virtual device communications system |
US13/403,687 US20120246346A1 (en) | 1998-05-23 | 2012-02-23 | Secured inter-processor and virtual device communications system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/095,097 Continuation US8147326B2 (en) | 1998-05-23 | 2005-03-30 | Secured inter-processor and virtual device communications system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120246346A1 true US20120246346A1 (en) | 2012-09-27 |
Family
ID=22199851
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/701,168 Expired - Lifetime US7093040B1 (en) | 1998-05-23 | 1999-05-21 | Secured inter-processor and virtual device communications system for use in a gaming system |
US11/095,097 Expired - Fee Related US8147326B2 (en) | 1998-05-23 | 2005-03-30 | Secured inter-processor and virtual device communications system |
US13/403,687 Abandoned US20120246346A1 (en) | 1998-05-23 | 2012-02-23 | Secured inter-processor and virtual device communications system |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/701,168 Expired - Lifetime US7093040B1 (en) | 1998-05-23 | 1999-05-21 | Secured inter-processor and virtual device communications system for use in a gaming system |
US11/095,097 Expired - Fee Related US8147326B2 (en) | 1998-05-23 | 2005-03-30 | Secured inter-processor and virtual device communications system |
Country Status (5)
Country | Link |
---|---|
US (3) | US7093040B1 (en) |
AU (1) | AU766657B2 (en) |
NZ (1) | NZ508654A (en) |
WO (1) | WO1999061994A1 (en) |
ZA (1) | ZA200007719B (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130322264A1 (en) * | 2012-06-01 | 2013-12-05 | International Business Machines Corporation | Providing real-time interrupts over ethernet |
US20130322290A1 (en) * | 2012-06-01 | 2013-12-05 | International Business Machines Corporation | Providing i2c bus over ethernet |
Families Citing this family (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6968405B1 (en) * | 1998-07-24 | 2005-11-22 | Aristocrat Leisure Industries Pty Limited | Input/Output Interface and device abstraction |
US9235955B2 (en) * | 2000-12-22 | 2016-01-12 | Bally Gaming, Inc. | Universal game monitoring unit and system |
US7950999B2 (en) * | 2004-09-16 | 2011-05-31 | Bally Gaming, Inc. | User interface system and method for a gaming machine |
US7137885B1 (en) | 2000-08-10 | 2006-11-21 | Wms Gaming, Inc. | Slot machine reel mechanism with dedicated local microcontroller |
US6827647B1 (en) | 2000-09-06 | 2004-12-07 | Wms Gaming, Inc. | Gaming machine coin handling system with dedicated local microcontroller |
US8678902B2 (en) | 2005-09-07 | 2014-03-25 | Bally Gaming, Inc. | System gaming |
US9082260B2 (en) | 2004-09-16 | 2015-07-14 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US8535158B2 (en) | 2004-09-16 | 2013-09-17 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US9117342B2 (en) | 2004-09-16 | 2015-08-25 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US8529349B2 (en) | 2004-09-16 | 2013-09-10 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US8986122B2 (en) | 2002-09-13 | 2015-03-24 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US8992326B2 (en) | 2006-09-06 | 2015-03-31 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US8568237B2 (en) | 2004-09-16 | 2013-10-29 | Bally Gaming, Inc. | Networked gaming system communication protocols and methods |
US7313136B2 (en) * | 2003-06-26 | 2007-12-25 | Nokia Corporation | Method and system establishing a data link layer protocol on a I2C™ physical layer connection |
US10803694B2 (en) | 2004-09-16 | 2020-10-13 | Sg Gaming, Inc. | Player gaming console, gaming machine, networked gaming system |
US9022866B2 (en) * | 2004-09-16 | 2015-05-05 | Bally Gaming, Inc. | User interface system and system-controlled bonus system |
US8348759B2 (en) * | 2004-09-16 | 2013-01-08 | Bally Gaming, Inc. | User interface system and method for a gaming machine |
WO2006039559A2 (en) * | 2004-10-01 | 2006-04-13 | Wms Gaming Inc. | Gaming machine with auto-detect feature activation |
KR100678897B1 (en) * | 2004-11-23 | 2007-02-07 | 삼성전자주식회사 | System and method for making a secure connection between home network devices |
US8230151B2 (en) * | 2005-04-11 | 2012-07-24 | Linear Technology Corporation | Configurable data port for I2C or single-wire broadcast interface |
US7755787B2 (en) | 2005-04-29 | 2010-07-13 | Hewlett-Packard Development Company, L.P. | Method and system for managing shared printers |
US8678901B1 (en) | 2005-09-07 | 2014-03-25 | Bally Gaming | System gaming |
US8840462B2 (en) * | 2005-09-07 | 2014-09-23 | Bally Gaming, Inc. | Tournament bonus awards and related methods |
US20080254883A1 (en) * | 2005-09-07 | 2008-10-16 | Bally Gaming, Inc. | Tournament bonus awards |
WO2008021181A2 (en) * | 2006-08-09 | 2008-02-21 | Wms Gaming Inc. | Peripheral device control system for wagering game systems |
US20100261529A1 (en) * | 2007-11-09 | 2010-10-14 | Wms Gaming Inc. | Distinguishing multiple peripherals in wagering game |
US8494451B2 (en) * | 2009-01-30 | 2013-07-23 | Nokia Corporation | Method, apparatus and computer program product for providing ciphering problem recovery for unacknowledged mode radio bearer |
US9124425B2 (en) | 2009-06-30 | 2015-09-01 | Nokia Technologies Oy | Systems, methods, and apparatuses for ciphering error detection and recovery |
US9798684B2 (en) * | 2015-04-21 | 2017-10-24 | Blackberry Limited | Bus communications with multi-device messaging |
US10282267B2 (en) * | 2016-06-23 | 2019-05-07 | Hewlett Packard Enterprise Development Lp | Monitor peripheral device based on imported data |
Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5559965A (en) * | 1994-09-01 | 1996-09-24 | Intel Corporation | Input/output adapter cards having a plug and play compliant mode and an assigned resources mode |
US5596723A (en) * | 1994-06-23 | 1997-01-21 | Dell Usa, Lp | Method and apparatus for automatically detecting the available network services in a network system |
US5634075A (en) * | 1995-01-11 | 1997-05-27 | Cirrus Logic, Inc. | Backward compatibility for plug and play systems |
US5754552A (en) * | 1995-07-12 | 1998-05-19 | Compaq Computer Corporation | Automatic communication protocol detection system and method for network systems |
US5758099A (en) * | 1996-05-29 | 1998-05-26 | International Business Machines Corporation | Plug and play protocol for bus adapter card |
US5854840A (en) * | 1995-04-26 | 1998-12-29 | Scientific-Atlanta, Inc. | Data transmission protocol method and apparatus |
US5901325A (en) * | 1996-05-20 | 1999-05-04 | Hewlett-Packard Company | Extended addressing to multiple devices on a single parallel I/O port |
US6128718A (en) * | 1997-08-28 | 2000-10-03 | Intel Corporation | Apparatus and method for a base address register on a computer peripheral device supporting configuration and testing of address space size |
US6173350B1 (en) * | 1997-10-17 | 2001-01-09 | Eveready Battery Company Inc. | System and method for writing data to a serial bus from a smart battery |
US6173382B1 (en) * | 1998-04-28 | 2001-01-09 | International Business Machines Corporation | Dynamic configuration of memory module using modified presence detect data |
US6209074B1 (en) * | 1998-04-28 | 2001-03-27 | International Business Machines Corporation | Address re-mapping for memory module using presence detect data |
US6219836B1 (en) * | 1998-10-14 | 2001-04-17 | International Game Technology | Program management method and apparatus for gaming device components |
US6286073B1 (en) * | 1998-12-01 | 2001-09-04 | Lucent Technologies Inc. | Integrated circuit interface between a personal computer and an external device |
US6301366B1 (en) * | 1997-10-14 | 2001-10-09 | Cirrus Logic, Inc. | Single-chip audio system mixing circuitry and methods |
US6317828B1 (en) * | 1998-11-13 | 2001-11-13 | Dell Usa, L.P. | BIOS/utility setup display |
US6449289B1 (en) * | 1998-10-09 | 2002-09-10 | Adaptec, Inc. | Multi-processor bus protocol system |
US6493340B1 (en) * | 1997-09-29 | 2002-12-10 | Nec Corporation | Automatic network-address-duplication detection method and device |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4240635A (en) * | 1979-03-09 | 1980-12-23 | Harry Brown | Slot machine device |
US4933938A (en) * | 1989-03-22 | 1990-06-12 | Hewlett-Packard Company | Group address translation through a network bridge |
US5508940A (en) * | 1994-02-14 | 1996-04-16 | Sony Corporation Of Japan And Sony Electronics, Inc. | Random access audio/video processor with multiple outputs |
US5725428A (en) * | 1995-03-09 | 1998-03-10 | Atronic Casino Technology Distribution Gmbh | Video slot machine |
CA2150215C (en) * | 1995-05-25 | 2003-02-25 | John Xidos | Distributed gaming system |
US5892972A (en) * | 1995-06-07 | 1999-04-06 | Cirrus Logic, Inc. | Method of constructing a plug and play compatible bus card which allows for mass production of the bus card |
US5643086A (en) * | 1995-06-29 | 1997-07-01 | Silicon Gaming, Inc. | Electronic casino gaming apparatus with improved play capacity, authentication and security |
US5832277A (en) * | 1996-03-08 | 1998-11-03 | 3 Com Corporation | System for arbitrating demand on memory during configuration of a computer add-on card |
US6023585A (en) * | 1997-05-02 | 2000-02-08 | Webtv Networks, Inc. | Automatically selecting and downloading device drivers from a server system to a client system that includes one or more devices |
US6189050B1 (en) * | 1998-05-08 | 2001-02-13 | Compaq Computer Corporation | Method and apparatus for adding or removing devices from a computer system without restarting |
US20020195773A1 (en) * | 1999-09-13 | 2002-12-26 | Shuffle Master, Inc. | Method of playing a table card game with an electronic multiplier bonus feature and apparatus for playing the game |
US6645077B2 (en) * | 2000-10-19 | 2003-11-11 | Igt | Gaming terminal data repository and information distribution system |
US7186181B2 (en) * | 2001-02-02 | 2007-03-06 | Igt | Wide area program distribution and game information communication system |
DE10210173B4 (en) * | 2001-07-05 | 2012-12-06 | Adp Gauselmann Gmbh | A method of encrypting data sent from a peripheral module to a coin operated machine control unit |
US6905411B2 (en) * | 2002-02-27 | 2005-06-14 | Igt | Player authentication for cashless gaming machine instruments |
US7367889B2 (en) * | 2003-06-09 | 2008-05-06 | Wms Gaming Inc. | Gaming machine having hardware-accelerated software authentication |
-
1999
- 1999-05-21 US US09/701,168 patent/US7093040B1/en not_active Expired - Lifetime
- 1999-05-21 AU AU40239/99A patent/AU766657B2/en not_active Expired
- 1999-05-21 NZ NZ508654A patent/NZ508654A/en not_active IP Right Cessation
- 1999-05-21 WO PCT/AU1999/000389 patent/WO1999061994A1/en active IP Right Grant
-
2000
- 2000-12-20 ZA ZA200007719A patent/ZA200007719B/en unknown
-
2005
- 2005-03-30 US US11/095,097 patent/US8147326B2/en not_active Expired - Fee Related
-
2012
- 2012-02-23 US US13/403,687 patent/US20120246346A1/en not_active Abandoned
Patent Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5596723A (en) * | 1994-06-23 | 1997-01-21 | Dell Usa, Lp | Method and apparatus for automatically detecting the available network services in a network system |
US5559965A (en) * | 1994-09-01 | 1996-09-24 | Intel Corporation | Input/output adapter cards having a plug and play compliant mode and an assigned resources mode |
US5634075A (en) * | 1995-01-11 | 1997-05-27 | Cirrus Logic, Inc. | Backward compatibility for plug and play systems |
US5854840A (en) * | 1995-04-26 | 1998-12-29 | Scientific-Atlanta, Inc. | Data transmission protocol method and apparatus |
US5754552A (en) * | 1995-07-12 | 1998-05-19 | Compaq Computer Corporation | Automatic communication protocol detection system and method for network systems |
US6072803A (en) * | 1995-07-12 | 2000-06-06 | Compaq Computer Corporation | Automatic communication protocol detection system and method for network systems |
US5901325A (en) * | 1996-05-20 | 1999-05-04 | Hewlett-Packard Company | Extended addressing to multiple devices on a single parallel I/O port |
US5758099A (en) * | 1996-05-29 | 1998-05-26 | International Business Machines Corporation | Plug and play protocol for bus adapter card |
US6128718A (en) * | 1997-08-28 | 2000-10-03 | Intel Corporation | Apparatus and method for a base address register on a computer peripheral device supporting configuration and testing of address space size |
US6493340B1 (en) * | 1997-09-29 | 2002-12-10 | Nec Corporation | Automatic network-address-duplication detection method and device |
US6301366B1 (en) * | 1997-10-14 | 2001-10-09 | Cirrus Logic, Inc. | Single-chip audio system mixing circuitry and methods |
US6173350B1 (en) * | 1997-10-17 | 2001-01-09 | Eveready Battery Company Inc. | System and method for writing data to a serial bus from a smart battery |
US6173382B1 (en) * | 1998-04-28 | 2001-01-09 | International Business Machines Corporation | Dynamic configuration of memory module using modified presence detect data |
US6209074B1 (en) * | 1998-04-28 | 2001-03-27 | International Business Machines Corporation | Address re-mapping for memory module using presence detect data |
US6449289B1 (en) * | 1998-10-09 | 2002-09-10 | Adaptec, Inc. | Multi-processor bus protocol system |
US6219836B1 (en) * | 1998-10-14 | 2001-04-17 | International Game Technology | Program management method and apparatus for gaming device components |
US6317828B1 (en) * | 1998-11-13 | 2001-11-13 | Dell Usa, L.P. | BIOS/utility setup display |
US6286073B1 (en) * | 1998-12-01 | 2001-09-04 | Lucent Technologies Inc. | Integrated circuit interface between a personal computer and an external device |
Non-Patent Citations (1)
Title |
---|
Microsoft Corporation, "Plug and Play ISA Specification Version 1.0a", May 5 1994, 1-71. * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130322264A1 (en) * | 2012-06-01 | 2013-12-05 | International Business Machines Corporation | Providing real-time interrupts over ethernet |
US20130322290A1 (en) * | 2012-06-01 | 2013-12-05 | International Business Machines Corporation | Providing i2c bus over ethernet |
US8966148B2 (en) * | 2012-06-01 | 2015-02-24 | International Business Machines Corporation | Providing real-time interrupts over Ethernet |
US8984201B2 (en) * | 2012-06-01 | 2015-03-17 | International Business Machines Corporation | Providing I2C bus over Ethernet |
US9282062B2 (en) | 2012-06-01 | 2016-03-08 | International Business Machines Corporation | Providing I2C bus over Ethernet |
US9654421B2 (en) | 2012-06-01 | 2017-05-16 | International Business Machines Corporation | Providing real-time interrupts over ethernet |
US9904654B2 (en) | 2012-06-01 | 2018-02-27 | International Business Machines Corporation | Providing I2C bus over ethernet |
Also Published As
Publication number | Publication date |
---|---|
AU766657B2 (en) | 2003-10-23 |
WO1999061994A1 (en) | 1999-12-02 |
US7093040B1 (en) | 2006-08-15 |
ZA200007719B (en) | 2002-03-20 |
US20050172101A1 (en) | 2005-08-04 |
NZ508654A (en) | 2003-03-28 |
AU4023999A (en) | 1999-12-13 |
US8147326B2 (en) | 2012-04-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8147326B2 (en) | Secured inter-processor and virtual device communications system | |
US10387345B2 (en) | USB port controller with automatic transmit retries and receive acknowledgements | |
US7454544B2 (en) | Input/output interface and device abstraction | |
EP0584097B1 (en) | Transaction systems | |
US6609167B1 (en) | Host and device serial communication protocols and communication packet formats | |
US6219736B1 (en) | Universal serial bus (USB) RAM architecture for use with microcomputers via an interface optimized for integrated services device network (ISDN) | |
CN101403994B (en) | Storage device and storage device access control method | |
US6425033B1 (en) | System and method for connecting peripheral buses through a serial bus | |
US4862355A (en) | System permitting peripheral interchangeability during system operation | |
US6636922B1 (en) | Methods and apparatus for implementing a host side advanced serial protocol | |
US7715450B2 (en) | Sideband bus setting system and method thereof | |
US20080140811A1 (en) | Method and apparatus for a host controller operations over a network | |
US4945473A (en) | Communications controller interface | |
US5159684A (en) | Data communication interface integrated circuit with data-echoing and non-echoing communication modes | |
US5214771A (en) | System for loading same type adaptors with latest version control codes stored on adaptor memory by selecting the identified chip during initialization | |
EP0353249A4 (en) | Parallel networking architecture | |
US20060047533A1 (en) | Multi-drop bus to personal computer interface | |
CN115454896A (en) | SMBUS-based SSD MCTP control message verification method and device, computer equipment and storage medium | |
AU748434B2 (en) | Input/output interface and device abstraction | |
US5249182A (en) | Communication bus system with lock/unlock capability | |
US5724606A (en) | Extended peripheral bus with bidirectional transmission | |
KR100271807B1 (en) | Usb device and data structure | |
CN115686163A (en) | Peripheral device with implicit reset signal | |
EP0512993A1 (en) | Bus locking fifo multi-processor communication system | |
Barenys et al. | Polling of failed devices on an I 2 C bus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NUGAME, INC., NEVADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MACH, RONALD EDWARD;REEL/FRAME:046336/0822 Effective date: 19980512 Owner name: ARISTOCRAT LEISURE INDUSTRIES PTY. LTD., AUSTRALIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NUGAME, INC.;REEL/FRAME:046337/0143 Effective date: 19980805 Owner name: ARISTOCRAT TECHNOLOGIES AUSTRALIA PTY LIMITED, AUS Free format text: CHANGE OF NAME;ASSIGNOR:ARISTOCRAT LEISURE INDUSTRIES PTY. LTD.;REEL/FRAME:046337/0274 Effective date: 20000428 |