Advanced Science and Technology Letters

Vol.54 (Games and Graphics 2014), pp.65-68

http://dx.doi.org/10.14257/astl.2014.54.17

Design and Implementation of Casino Slot Machine

Accounting Protocol Engine

Sangmin Kim and Heejune Ahn*,

1
Dept. Of Electrical and Information Engineering, SeoulTech,
232 Gongneung-ro, Nowongu, Seoul, 137-743, Rep. of Korea
*heejune@seoultech.ac.kr

Abstract. IGTs SAS (Slot Accounting System) protocol is the de facto casino
communications standards designed to automate slot machine meter reporting
and event logging, player tracking, bonusing, ticketing and cashless gaming. By
presenting the design experience of SAS protocol, this paper unveils the
technical details of SAS 6.0 standards, which is only exposed to the limited
industry circle. The engine is integrated with engine test UI and tested and
verified against the IGT EGM test software.

Keywords: Slot Accounting System, communication protocol implementation,

Casino Industry, and Slot Machine.

1 Introduction

The casino industry keeps growing it size every years steadily, reaching to 159 billion
dollars in 2014 world market at the increase rate of 9.3%. Among the casino games,
the slot machine plays a key role to recruiting casual non-serious customer [1].
IGTs SAS (Slot Accounting System) protocol is the de facto casino
communications standards designed to automate slot machine meter reporting and
event logging, player tracking, bonusing, ticketing and cashless gaming. Due to the
unique requirement, poorly written specification, and the lack of experts, field and
development engineers encounter several difficulties in working and developing
systems. This paper presents the design example of SAS protocol engine, so that the
reader can understand the key service and technical components and mitigate the
development process.

2 SAS Protocol Standards [2]

The Fig. 1 illustrates the network topology for slot machine accounting in todays
casino floor. The EGM and SMIB communicate each other in SAS protocol standards,
whereas communication between the SMIB and host is not standardized, which
interoperability and standards issue is resolved by new standards, G2S (Game to

ISSN: 2287-1233 ASTL

Copyright 2014 SERSC
Advanced Science and Technology Letters
Vol.54 (Games and Graphics 2014)

System) protocol. SMIB also provides touch screen and card readers for AFT and
player tracking service.

Fig. 1. The System architecture of SAS Protocol: SAS protocol is used for communication
between EGM and SMIB.

SAS protocol consists of 3 layers of physical layer, link layer, and application layer.
The physical layer leverages RS-232 at 9.2kbps of 1 start bit, 8 data bits, and
1wakeup bit and 1 stop bit. The wakeup bit is used for signaling the frame start byte
and needs special care in implementation (described later). Master-slave polling
mechanism is used for the medium access control similar to USB and traditional
remote terminal system. Each EGM is assigned a link address of 1 to 127. 0 is used
for broadcasting. The polling rate ranges from 200ms to 5s but can be reduced to
40ms when EGM support RTE (real time event) mode.
SMIB uses two different types of polls, GP (general poll) and LP (long poll). GP is
one byte EGM address with wakeup bit set, and polls events generated in the
receiving EGM system. The receiving EGM should respond with 1 byte event code,
which is called exception in the specification. The exceptions include non-priority
exceptions such as no event, game start, game end, system tilt, and priority exceptions
such as handpay condition, ticket out, ticket in, and fund-transfer request. LP is used
for SMIB to send command to EGMs and classified into R(read)-type, S(set)-type,
M(multi-game)-type, and G (global)-type. LP starts with 1 byte command value with
wakeup bit set, and the lengths of LP are fixed or variable depending on the command.
All LP except R-type contains CRC-16 (cyclic redundancy check) for bit error
detection. The response frame uses the similar format but with wakeup bit off. SMIB
use implied ACK mechanism for confirming the receipt.
Table 1. SAS Protocol Application Functions.
SAS Application Functions Description
ROM signature request Jurisdiction for integrity of system memory
Performance metrics for wagered game count, win
Metric
amount,
Progressive broadcast Progressive jackpot win amount for groups
Tournament operation Tournament game start and end
RTE (real time event) Event report more responsively
Bonus Controller Legacy bonus provisioning
Jackpot hand-pay Handpay for large amount win or credit cancel
TITO(Ticket in/out) Ticket to/from credit
Multi-denomination Multi-denom configurable system
AFT Automatic fund transfer
Component Authentication Application components jurisdiction

66 Copyright 2014 SERSC

 Advanced Science and Technology Letters
Vol.54 (Games and Graphics 2014)

3 SAS Engine Design

The commercial success of engine software depends on not only the performance and
reliability but also the flexibility and easiness for integration. For this purpose, we
benchmarked the commercial engines API interfaces (Digital dynamic [3]). Fig. 2
illustrates the interface and API for the engine with an overall architecture of the
engine.

3.1 Engine Architecture

For thread architecture, a single-thread, event based architecture is used for simplicity
for handling multithreading risks. One receiving thread waits for byte or event
arrivals; collects a frame data; call the handler function for specific command. Each
handler is defined for specific commands. Once called, it decodes the message using
SAS message library, generated response message for the commands based on system
state, and return the encoded message using SAS message library.

Game Application
Slot machine Data
Config Meters Events
System
Meters
TITO
AFT
Message Lib

timers
Protocol Iferface

API
LP dispatcher GP handler
(Event
Callback Queue)
Link Layer (Thread)
GP/LP_arr/ack
response/event
LP/GP RX

wakeup/byte
Reader-StatCheck Writer
(thread R)
(thread)
Serial Layer

Game SAS EGM Engine

SMIB
RS-232C

Fig. 2. SAS Engine Architecture.

Message En/Decoding library is built for binary message to structured (precisely
C++ class) mapping. Because normal PC hardware and OS does not support 9bit
communication, which is used in SAS communication mechanism, the parity bit is
used for the wakeup bit. Whereas normally the parity bit is set or reset based on the
odd/even/space/mark parity setting, the sender has to toggle parity mode between
mark mode if first byte and space mode otherwise. The receiver should set up with
space parity and get the wakeup bit set using error detection. To handle both event 1
byte normal and RTE mode, multi-bytes EGM, RTE mode format is used for event
queue and transmitted depending on the system mode.

Copyright 2014 SERSC 67

Advanced Science and Technology Letters
Vol.54 (Games and Graphics 2014)

3.2 Application Message Handling

Due to the limit of space, only metering and handpay scenario are describe in the
paper. For Metering, over a hundred of meter codes are defined for accounting and
gaming performance analysis (per-machine meters or per-game meters). The game ID
0 is used for reading the machine level meters and should be summed up for all
corresponding per-game meters.
Handpay condition occurs when the win level or credit cancel amount is too high
by jurisdiction. Main game software initiates the handpay transaction. The SAS
engine should send 0x51 exception to the host. Typical resolution method is paid in a
check by an attendant (0x3E exception) or ticket-out after validation of an attendant
(0x3D exception). The host (SMIB) will query the handpay info by the Send
Handpay Info LP (0x1B), which is usually responded by Pending status response.
When the handpay reset is done by an attendant, the SAS engine should sends the
Handpay Reset exception (0x52). Finally the host query with Send Enhanced
Validation LP (0x4D) and gets result information of the handpay. The engine should
update the information in the persistent storage. The persistent storage management is
the role of game part.

4 Evaluation and Conclusion

The engines functional and performance verification is done with IGT EGM test tool
and our SMIB implementation, except bonus, progressive, RTE, and multi-denom
features (due to the limit of understanding of service scenarios). The performance is
tested sending upto 40 ms, and the CPU utilization is less than 5 % in the typical slot
machine hardware environments. We are developing SAS to G2S protocol [4, 5]
converter so that existing EGMs can be used together with new standard based host
systems in the transition periods, which is expected at least 10 to 15 years,
considering the normal lifetime of EGMs in the field.

Acknowledgments. This study was supported by the Korea Healthcare

Technology R&D Project, Ministry of Health and Welfare, Republic of Korea
(A120157) and Technology Development Support Project, SMBA (Small and
Medium Business Administration), Republic of Korea (S2100260).

References

1. Kilby, J., Fox, J., Lucas, A. F.: Casino Operations Management 2nd Ed. John Wiley & Sons
Inc. (2005)
2. IGT: Slot Accounting System version 6.01 (2003)
3. Digital Dyamics SAS Engine, online: http://www.digdyn.com/sas-engine.html (2014)
4. GSA: G2S Message Protocol v2.0.3, Game to System (2009)
5. GSA: GSA SAS 6.02 Interoperability Requirements: Rev. B (2006)

68 Copyright 2014 SERSC