NVRAM en máquinas de juego: cómo no perder créditos en un corte de luz
Un jugador tiene 500 créditos, presiona el botón de jugar y se va la luz. Cuando la máquina vuelve a encender, tiene que mostrar exactamente lo que pasó: la jugada terminada o no iniciada, los créditos correctos y los meters cuadrados con el sistema del casino. Ni un crédito de más ni uno de menos.
Eso no lo resuelve el sistema operativo ni la base de datos. Lo resuelve la NVRAM y, sobre todo, cómo la usa el software.
Qué se guarda en NVRAM
En la plataforma de EGM en la que trabajé guardábamos en NVRAM todo lo que define el estado de dinero y de juego:
- Créditos del jugador.
- Meters: entradas, salidas, jugadas, premios, billetes, tickets. Son la base de la auditoría y lo que reporta SAS al casino.
- Estado de la jugada en curso: apuesta, resultado y en qué paso iba.
A eso conviene sumar todo lo que está “a medio camino”: un ticket TITO que se está imprimiendo, una transferencia AFT, un billete que el validador está apilando. Son los momentos donde un corte de luz hace más daño.
Mirror mode: dos copias de todo
Usábamos NVRAM en mirror mode: cada escritura queda en dos copias. Al arrancar, el software verifica ambas. Si coinciden y son válidas, el estado se recupera. Si una se dañó, la otra permite detectarlo.
El mirror mode solo sirve si cada copia tiene forma de validarse por sí misma, típicamente con un checksum por bloque. Dos copias sin checksum dicen que algo no cuadra, pero no cuál es la buena.
El orden de escritura lo es todo
La regla que evita casi todos los problemas: primero se registra la intención, después se actúa, al final se confirma.
Por ejemplo, para imprimir un ticket:
- Guardar en NVRAM “ticket pendiente por X créditos” y descontar los créditos.
- Mandar a imprimir.
- Cuando la impresora confirma, marcar el ticket como impreso.
Si la luz se va en cualquier punto, al arrancar la máquina sabe exactamente dónde quedó y puede terminar o resolver la operación. Si el orden es al revés (imprimir y luego descontar), un corte en el momento justo regala un ticket.
Lo mismo aplica a la jugada: el resultado se guarda antes de mostrarse, y los meters se actualizan como parte de la misma operación que los créditos, nunca en pasos que puedan quedar a medias.
Cuando la memoria no es confiable
Si al arrancar las copias no coinciden y no hay forma de saber cuál es correcta, la máquina no debe adivinar. Lo correcto es bloquearse con un error de memoria y esperar a que personal autorizado haga un RAM clear, que reinicia la memoria y deja constancia del evento. Es preferible una máquina fuera de servicio que una con meters inventados, y es lo que esperan los laboratorios al certificar.
Los bugs viven en los bordes
Tuvimos bugs en esta capa, como cualquier equipo que trabaja con NVRAM. Este tipo de bug casi nunca aparece en el camino feliz, sino en los bordes. Los casos típicos:
- Un campo nuevo que se agrega a la estructura y rompe la compatibilidad con lo que ya estaba guardado después de una actualización.
- Una operación que actualiza créditos y meters en dos escrituras separadas.
- Un periférico (impresora o validador) que confirma tarde, después de que la máquina ya reinició.
La única defensa real es probarlo: cortar la energía de forma repetida y en momentos aleatorios, especialmente durante la impresión de tickets, la inserción de billetes y la resolución de una jugada, y verificar que créditos y meters siempre cuadren.
¿Necesitas ayuda con NVRAM o certificación?
Somos un equipo en Ciudad de México que trabaja con fabricantes y estudios de juegos en SAS, periféricos, NVRAM y certificación GLI. Puedes ver lo que hacemos en desarrollo SAS y periféricos EGM o leer también cómo autenticar el software de una EGM con GAT.