Skip to main content

NVRAM on slot machines: how not to lose credits during a power loss

A player has 500 credits, presses play, and the power goes out. When the machine boots again, it has to show exactly what happened: the game finished or never started, the right credits, and meters that match the casino system. Not one credit more or less.

The operating system does not solve that, and neither does a database. NVRAM does, and above all, how the software uses it.

What goes into NVRAM

On the EGM platform I worked on, we kept everything that defines money and game state in NVRAM:

  • Credits on the machine.
  • Meters: coin in, coin out, games played, wins, bills, tickets. They are the basis for auditing and what SAS reports to the casino.
  • Game in progress: wager, outcome, and which step it was on.

It also pays to add everything that is “halfway”: a TITO ticket being printed, an AFT transfer, a bill the validator is stacking. Those are the moments where a power loss does the most damage.

Mirror mode: two copies of everything

We ran NVRAM in mirror mode: every write lands in two copies. At boot, the software checks both. If they match and are valid, state is restored. If one is damaged, the other lets you detect it.

Mirror mode only helps if each copy can validate itself, typically with a checksum per block. Two copies without checksums tell you something is off, not which one is right.

Write order is everything

The rule that prevents almost every problem: record the intent first, then act, then confirm.

For example, printing a ticket:

  1. Store “ticket pending for X credits” in NVRAM and deduct the credits.
  2. Send the print job.
  3. When the printer confirms, mark the ticket as printed.

If power drops at any point, the machine knows exactly where it stopped at boot and can finish or resolve the operation. If the order is reversed (print, then deduct), a power loss at the wrong moment gives away a ticket.

The same applies to the game: the outcome is saved before it is shown, and meters are updated in the same operation as credits, never in steps that can be left half done.

When memory cannot be trusted

If the copies disagree at boot and there is no way to know which is correct, the machine must not guess. The right move is to lock up with a memory error and wait for authorized staff to perform a RAM clear, which resets memory and records the event. A machine out of service is better than one with invented meters, and it is what labs expect at certification.

Bugs live at the edges

We had bugs in this layer, like every team that works with NVRAM. These bugs rarely show up on the happy path, but at the edges. Typical cases:

  • A new field added to the structure that breaks compatibility with what was already stored after an update.
  • An operation that updates credits and meters in two separate writes.
  • A peripheral (printer or validator) that confirms late, after the machine has already rebooted.

The only real defense is testing: cut power repeatedly at random moments, especially during ticket printing, bill insertion and game resolution, and verify that credits and meters always reconcile.

Need help with NVRAM or certification?

We are a Mexico City team, in US and Canadian time zones, working with manufacturers and game studios on SAS, peripherals, NVRAM and GLI certification. See what we do in SAS and EGM consulting, or read how to authenticate EGM software with GAT.