Skip to main content

SAS protocol on the EGM side: a practical guide to working with every casino system

SAS (Slot Accounting System) is the protocol electronic gaming machines (EGMs) use to talk to the casino management system. IGT created it and it is the de facto industry standard. The spec is public and detailed, so in theory implementing it means following the document.

In practice, the hardest part for me was not the spec. It was testing the machine against different casino systems and making it work with all of them. This is a guide to SAS from the EGM side with that lesson at the center.

SAS in five minutes

  • Serial link. The EGM and the host share a serial port. The host is the master: the machine never speaks unless asked.
  • General poll. The host periodically asks the machine “what happened?”. The EGM answers with an exception (a pending event, like a door opening or a bill accepted) or with nothing.
  • Long polls. The host requests data or gives specific commands: read meters, validate a ticket, start an AFT transfer, disable the machine. Each long poll carries a code, data and a CRC.
  • Strict timing. The EGM has a very short window to answer. If it is late, for the host the machine might as well not exist.

What the EGM implements

On the platform I worked on, we implemented SAS on the machine side with:

  • Events and exceptions: a queue that never drops events, even if the host polls late or disconnects.
  • Meters: coin in, coin out, games played, wins, bills and tickets, always consistent with what is in NVRAM.
  • TITO: ticket printing and redemption with system validation.
  • AFT: electronic fund transfers between the player account and the machine.
  • Progressives, handpays and legacy bonusing.

The hard part: one standard, many interpretations

Every casino system implements SAS its own way, within the spec or not quite. The differences show up in places like:

  • Which long polls each system uses and which it ignores.
  • Polling rate and how much latency it tolerates.
  • Message order in multi-step flows, such as validating a ticket or an AFT transfer.
  • TITO and AFT configuration: validation types, machine registration, limits.
  • What the host does with an exception it does not expect or recognize.

A machine that works perfectly with one system can fail with another, even though both say “SAS”. We tested against systems from several vendors, including WinSystems, widely used in Mexican casinos, and Konami and IGT systems.

Making it work with all of them

What worked for us, and what I recommend:

  • Strict when sending, tolerant when receiving. What the machine sends follows the spec to the letter. What it receives is validated carefully, without breaking on reasonable host variations.
  • Configuration, not forks. Differences between systems are handled with options in the operator menu, not with one software build per customer. A build per system is a certification nightmare.
  • The game never waits on the host. A slow or disconnected host cannot freeze the machine. SAS runs separately and events are queued.
  • Full serial traffic logging. When something fails on a casino floor, a log of every byte sent and received is what tells you whether the problem is the machine or the host.
  • Test against every real system. A host simulator is great day to day, but it does not replace testing with real casino systems. Keep a matrix of features against systems (meters, TITO, AFT, progressives, bonusing) and rerun it on every release.

Need SAS implemented or debugged?

We are a Mexico City team, in US and Canadian time zones, working with manufacturers, game studios and operators on SAS, peripherals and GLI certification. See what we do in SAS and EGM consulting, or read about GAT authentication for GLI.