ArduinoTITO-PlayerTracking
A homebrew slot machine TITO, player tracking and display project
Arduino TITO & Player Tracking — Casino-Grade Ticketing and Loyalty for Your Home Slot Machine
#TITO #SASProtocol #PlayerTracking #W5100 #TOE #EthernetServer #ArduinoMega #RFID #RemoteManagement #RetroGaming
📚 Context: Long-running open-source hobby/enthusiast project (v1 → v4, actively maintained; v4.0 build 20260623) Implementation verified: full 3,200-line Mega sketch, W5100 Ethernet Shield,
EthernetServeron port 80 +EthernetClientreporting, SAS protocol over Serial1, KiCad-free but PDF-documented hardware wiring.
01 — What is this project?
Casinos use a deceptively sophisticated stack behind every slot machine. TITO (Ticket In / Ticket Out) is the industry mechanism that replaced coin hoppers: instead of dropping coins, a machine prints a barcoded voucher when you cash out, and accepts one when you sit down. Behind that sits SAS (Slot Accounting System) — the Gaming-standard serial protocol, spoken by virtually every modern slot machine, that lets a host system read meters (credits, coin-in, games played, jackpots), issue commands (lock/unlock, enable/disable bill validator, mute), and validate tickets. On top of both runs player tracking: the loyalty layer that identifies a player by card, follows their play, and drives the little display on the machine that says "Welcome back."
For a home slot-machine owner — a surprisingly active collector community — all of that is normally locked inside proprietary casino management systems that cost more than the machine itself. There is no consumer product that gives a hobbyist TITO, remote control, and player tracking for a game sitting in their basement.
This project closes that gap. Using an Arduino Mega 2560 and a WIZnet W5100 Ethernet Shield, it implements a working slice of the real casino stack: it speaks SAS to any SAS-compatible game, prints and redeems TITO tickets, exposes a web management console for remote control, and pushes live play data to a central player-tracking server — while reusing the machine's existing display, keypad, and card-reader hardware. Version 4.0 adds a rewritten web console for every network-enabled sketch and remote SD-card file updates.
The result: a homebrew board that turns a standalone slot machine into a networked, remotely-managed, loyalty-aware device — the kind of thing that normally requires a casino IT department.
02 — Why networked TITO & player tracking?
🔷 The serial protocol is only half the problem
Talking SAS over a serial line to one machine is a solved problem. The hard part is everything around it: getting meter data off the machine, letting an operator manage the game without standing in front of it, and correlating a physical RFID card with a player record. Every one of those is a network problem, not a serial one. The moment you want remote control and centralized player tracking, you need a reliable TCP/IP endpoint bolted onto a microcontroller.
🔷 Two network roles at once
What makes this project architecturally interesting is that the same board plays both sides of the network conversation:
- As an HTTP server (
EthernetServer server(80)), it serves a web management console so an operator can lock/unlock the game, toggle the bill validator, reset jackpots, and view configuration from a browser. - As an HTTP client (
EthernetClient→client.connect(serverIP, 80)), it reports each card-in event and the player's session meters (credits, coin-in, games won/lost, total won) to a separate player-tracking server via aGET /?pu&cardID=…&data=…request.
Doing both, reliably, on an Arduino Mega's limited RAM — alongside the SD and SAS libraries — is exactly why the hardware TCP/IP offload of the WIZnet chip matters.
🔷 Reusing existing hardware
The project deliberately drives the machine's existing player-tracking display, keypad, and card reader. That constraint — retrofit, don't replace — is what makes it genuinely useful to the collector community rather than a lab demo.
03 — System architecture
04 — Why WIZnet W5100? ⭐
🔷 The technical core
The Arduino Mega 2560 has just 8 KB of SRAM. Running a full software TCP/IP stack (like the classic ENC28J60 + UIPEthernet path) on top of the SAS protocol handler, an IniFile config parser, the SD library, RFID, keypad, and display drivers would exhaust RAM and destabilize the whole system — the README's changelog explicitly documents earlier stability problems caused by "the memory requirements of the Ethernet and SD libraries." The W5100 solves this at the hardware level.
🔷 Socket mode used — TOE / TCP (Sn_MR_TCP)
This project uses the W5100's hardwired TCP mode (TOE — TCP/IP Offload Engine) on both of its sockets:
- Listening socket —
EthernetServer server(80)→server.begin()puts a socket into TCP listen for the web management console (equivalent toSn_MR_TCP+listen()). - Client socket —
client.connect(serverIP, 80)opens an outbound TCP connection to the player-tracking server to report card and meter data.
The entire TCP handshake, retransmission, windowing, and checksum work happens inside the W5100 silicon. The Mega only reads and writes socket buffers over SPI — no lwIP, no software stack, no per-packet CPU cost. That is precisely what lets a memory-constrained 8-bit MCU serve HTTP and act as an HTTP client while simultaneously running a real-time casino serial protocol.
🔷 Advantage over alternatives
- vs ENC28J60 (software stack): ENC28J60 is a MAC+PHY only — the MCU must run the full TCP/IP stack in SRAM. On a Mega already loaded with SD + SAS + RFID, that path was the documented source of instability. The W5100's onboard stack removes that burden entirely.
- vs Wi-Fi shields: the README states plainly that "Wifi shields are NOT recommended" — a slot machine on a casino/home floor needs a deterministic, low-latency wired link for meter accuracy and remote-command reliability, not a congested 2.4 GHz radio.
- Drop-in ecosystem: the standard Arduino
Ethernet.hlibrary targets the W5100/W5200/W5500 family directly, so the shield is a true plug-and-play addition to the Mega stack.
🔷 Verified evidence ✅
#include <Ethernet.h>+EthernetServer server(80)+EthernetClientconfirmed in the 3,209-line V4 Mega sketch.- Header comment specifies the exact hardware: "Arduino Mega 2560 R3; Compatible RFID or magnetic reader; W5100 Ethernet Shield; Serial Port."
- Configurable MAC (
byte mac[]) and static-IP fallback (IPAddress ip(192,168,1,254)) with DHCP as primary — production-grade network setup. - Full SAS command table present in code (
LOCK,ULOCK,MUTE,EBILL/DBILLbill-validator enable/disable,transComplete, meter reads for credits/coin-in/games/jackpots). - Three PDF documentation manuals + a companion Game Manager app + a player-tracking server component — a complete, reproducible system, not a snippet.
05 — Key components
🌐 WIZnet W5100 — TOE / TCP mode (dual socket: HTTP server + HTTP client)
Provides the hardware TCP/IP offload that makes networked TITO possible on an 8-bit Mega. One socket listens on port 80 for the web management console; another connects outbound to the player-tracking server. All TCP mechanics run in-chip over SPI.
🎰 Arduino Mega 2560 R3
The host controller. Chosen over the Uno specifically for its larger SRAM and multiple hardware serial ports — Serial1 @ 19200 is dedicated to the SAS/TITO link with the game, leaving USB serial free for debugging.
💳 MFRC522 RFID reader
Identifies the player by card and triggers the "card-in" event that starts a tracked session and reports to the central server. (Magnetic-stripe readers are also supported via commented MagStripe includes.)
⌨️ Keypad + LCD/VFD display
The on-machine operator/player interface. The keypad issues live SAS commands (mute, lock, enable bill validator); the display reuses the slot machine's existing player-tracking panel.
💾 SD card
Stores the config file (IniFile), the web-console HTML, and player/bonus/admin card definitions — and in v4 can be updated remotely over the network.
📡 SAS protocol layer (Serial1)
A partial Arduino implementation of the Gaming-standard Slot Accounting System, reading meters and issuing machine commands — the bridge between the physical game and the networked world.
06 — Application scenarios
01. Home slot-machine collector
Retrofit a garage or game-room slot machine with real TITO ticketing and remote management — cash out to a printed voucher, lock the game from a phone browser, all over the home LAN.
02. Small-venue / arcade loyalty
Run a lightweight player-tracking loyalty layer across several machines, each board reporting card sessions and meters to one central server — without a commercial casino-management contract.
03. Remote game administration
Manage a machine you can't physically reach: unlock/lock play, enable or disable the bill validator, reset jackpots, and inspect configuration from the web console — the wired W5100 link keeps commands deterministic.
04. Retro-gaming & protocol education
A rare, fully-documented open-source reference for the SAS protocol and TITO mechanics — valuable to anyone learning how real gaming hardware talks, with the network layer cleanly separated onto the WIZnet chip.
Conclusion
This project rebuilds a slice of a casino's machine-management stack — TITO ticketing, SAS control, and player tracking — on an 8-bit Arduino, and it is the hardware TCP/IP offload of the WIZnet W5100 that makes serving a web console and reporting to a loyalty server possible without collapsing the Mega's memory.
- ✅ Implements real Gaming-industry mechanisms (TITO + SAS) on hobbyist hardware
- ✅ W5100 runs in TOE/TCP mode as both HTTP server and HTTP client simultaneously
- ✅ Offloads the entire TCP/IP stack from an 8-bit MCU already saturated with SD + SAS + RFID
- ✅ Wired Ethernet chosen deliberately over Wi-Fi for command/meter reliability
- ✅ Actively maintained across four major versions (latest build 20260623)
- ✅ Complete, reproducible system: firmware + Game Manager app + tracking server + three PDF manuals
- ✅ Retrofits existing machine hardware rather than replacing it
- ✅ Demonstrates that casino-grade ticketing and loyalty gear is another place a WIZnet chip quietly lives
And the reach point: even the ticketing and player-tracking electronics behind a slot machine — a domain almost nobody associates with hobbyist Ethernet — run on a WIZnet chip.
07 — Similar Projects on WIZnet Makers
This project sits at the intersection of two families already present on WIZnet Makers: networked cashless-payment / vending controllers and Ethernet game peripherals. All of them lean on a WIZnet chip's TCP link to move money, credits, or input data off a machine — the same architectural need TITO has.
- mdb-arduino-cashless — An Arduino Uno bridges the MDB (Multi-Drop Bus) vending protocol to a networked cashless payment flow, with an MFRC522 RFID reader for tap-to-pay. The closest cousin to TITO: MDB is to vending machines what SAS is to slot machines — the standard serial protocol this board lifts onto the network.
- Vending Machine / Cashless Device Implementation — A vending cashless device (Nottingham Hackspace's Vend2 lineage) that also pairs RFID with a networked payment backend over TCP. Same "authenticate a card → authorize a transaction on a machine" loop as TITO's card-in event.
- Ethernet gaming controller with W5500 — A W5500-based Ethernet game controller. Shares TITO's gaming-peripheral-over-wired-Ethernet angle, but points the other direction: sending player input into a game rather than metering a game's output.
Comparison
| Project | Core MCU | WIZnet role | Machine protocol | Card / auth | Direction of data | Server/Client |
|---|---|---|---|---|---|---|
| Arduino TITO & Player Tracking (this) | Arduino Mega 2560 | W5100 · TCP (TOE) | SAS (slot machine) | MFRC522 RFID | Meters out + remote cmds in | Both (HTTP server + client) |
| mdb-arduino-cashless | Arduino Uno | W5x00 · TCP | MDB (vending) | MFRC522 RFID | Payment auth | Client-side payment flow |
| Vending / Cashless (Vend2) | Arduino | W5x00 · TCP | Vending (Vend2) | RFID | Payment auth | Networked backend |
| Ethernet gaming controller | (controller board) | W5500 · TCP | — (HID-style input) | — | Input in to game | TCP link |
Q&A
Q. Which WIZnet socket mode does this use, and why not UDP? A. It uses TOE / TCP mode (Sn_MR_TCP). Both the web management console (inbound) and the player-tracking reports (outbound) are HTTP, which is TCP-based — reliable, ordered delivery matters for meter data and remote commands, so TCP is the correct choice over UDP.
Q. Why a W5100 and not just an ENC28J60 to save cost? A. The ENC28J60 is MAC+PHY only and forces the MCU to run the TCP/IP stack in software/SRAM. The README's changelog documents that the combined memory footprint of the Ethernet-plus-SD software path was a real source of instability on the Uno-class hardware. The W5100's in-silicon stack removes that RAM pressure — essential when the Mega is already running SAS, SD, RFID, keypad, and display code.
Q. Could this move to a W5500 or W55RP20? A. Yes, cleanly. The standard Ethernet.h library covers the whole W5100/W5200/W5500 family, so a W5500 shield would be close to a drop-in upgrade with more sockets and higher SPI throughput. A W55RP20 (RP2040 + W5500-in-package) would be an interesting single-chip modernization, though it would mean porting the Mega-specific SAS timing to the RP2040.
Q. Is this legal / is it a cheating device? A. No. It reads standard SAS meters and manages a machine the owner controls — the same read/command operations a legitimate casino host system performs. It targets home collectors and small venues managing their own hardware, not tampering with third-party machines.
[한글 버전]
Arduino TITO & Player Tracking — 우리 집 슬롯머신에 카지노급 티켓팅과 멤버십을 얹다
#TITO #SAS프로토콜 #PlayerTracking #W5100 #TOE #EthernetServer #ArduinoMega #RFID #원격관리 #레트로게이밍
📚 컨텍스트: 오래 유지된 오픈소스 취미/애호가 프로젝트 (v1 → v4, 활발히 유지보수 중; v4.0 빌드 20260623) 구현 검증: 3,200줄짜리 Mega 스케치 전체 확인, W5100 이더넷 실드, 80포트
EthernetServer+EthernetClient리포팅, Serial1을 통한 SAS 프로토콜, PDF로 문서화된 하드웨어 배선.
01 — 이 프로젝트는 무엇인가?
카지노의 모든 슬롯머신 뒤에는 의외로 정교한 시스템이 돌아간다. TITO(Ticket In / Ticket Out)는 동전 호퍼를 대체한 업계 표준 방식이다. 동전을 쏟아내는 대신, 정산할 때 바코드가 찍힌 바우처를 출력하고, 게임을 시작할 때 그 바우처를 받아들인다. 그 아래에는 SAS(Slot Accounting System)가 있다. 거의 모든 현대 슬롯머신이 사용하는 게이밍 업계 표준 시리얼 프로토콜로, 호스트 시스템이 미터값(크레딧, 코인인, 게임 수, 잭팟)을 읽고, 명령(잠금/해제, 지폐인식기 활성화/비활성화, 음소거)을 내리고, 티켓을 검증할 수 있게 해준다. 그리고 이 둘 위에 플레이어 트래킹이 얹힌다. 카드로 플레이어를 식별하고, 플레이를 추적하고, 머신에 붙은 작은 디스플레이에 "다시 오신 걸 환영합니다"를 띄우는 멤버십 계층이다.
집에 슬롯머신을 두는 소유자 — 의외로 활발한 수집가 커뮤니티가 존재한다 — 에게 이 모든 건 보통 머신 값보다 비싼 상용 카지노 관리 시스템 안에 잠겨 있다. 지하실에 놓인 게임기 하나에 TITO, 원격 제어, 플레이어 트래킹을 붙여주는 소비자용 제품은 없다.
이 프로젝트가 바로 그 간극을 메운다. Arduino Mega 2560과 WIZnet W5100 이더넷 실드로, 진짜 카지노 스택의 동작하는 일부를 구현한다. SAS 호환 게임기와 SAS로 통신하고, TITO 티켓을 출력·상환하고, 원격 제어용 웹 관리 콘솔을 열고, 실시간 플레이 데이터를 중앙 플레이어 트래킹 서버로 밀어올린다. 그것도 머신의 기존 디스플레이·키패드·카드리더를 그대로 재활용하면서. v4.0은 모든 네트워크 지원 스케치에 새로 작성된 웹 콘솔과 원격 SD카드 파일 업데이트를 추가했다.
결과물은, 독립형 슬롯머신을 네트워크에 연결된, 원격 관리 가능한, 멤버십을 인식하는 장치로 바꿔주는 자작 보드다. 보통은 카지노 IT 부서가 있어야 가능한 그런 것 말이다.
02 — 왜 네트워크 기반 TITO와 플레이어 트래킹인가?
🔷 시리얼 프로토콜은 문제의 절반일 뿐
머신 한 대와 시리얼로 SAS를 주고받는 건 이미 풀린 문제다. 어려운 건 그 주변 전부다. 머신에서 미터 데이터를 빼내고, 운영자가 머신 앞에 서지 않고도 게임을 관리하고, 물리적 RFID 카드를 플레이어 레코드와 연결하는 것. 이 하나하나가 시리얼이 아니라 네트워크 문제다. 원격 제어와 중앙 집중식 플레이어 트래킹을 원하는 순간, 마이크로컨트롤러에 신뢰할 수 있는 TCP/IP 엔드포인트를 붙여야 한다.
🔷 한 보드가 네트워크의 양쪽 역할을 동시에
이 프로젝트가 아키텍처적으로 흥미로운 지점은, 같은 보드가 네트워크 대화의 양쪽을 모두 수행한다는 것이다.
- HTTP 서버로서(
EthernetServer server(80)), 웹 관리 콘솔을 제공해 운영자가 브라우저에서 게임 잠금/해제, 지폐인식기 토글, 잭팟 리셋, 설정 조회를 할 수 있게 한다. - HTTP 클라이언트로서(
EthernetClient→client.connect(serverIP, 80)), 카드 인식 이벤트와 플레이어의 세션 미터(크레딧, 코인인, 승/패 게임 수, 총 획득액)를 별도의 플레이어 트래킹 서버로GET /?pu&cardID=…&data=…요청으로 보고한다.
이 두 가지를 Arduino Mega의 제한된 RAM에서 — SD와 SAS 라이브러리까지 함께 돌리면서 — 안정적으로 해내는 것, 바로 그것이 WIZnet 칩의 하드웨어 TCP/IP 오프로드가 중요한 이유다.
🔷 기존 하드웨어 재활용
이 프로젝트는 의도적으로 머신의 기존 플레이어 트래킹 디스플레이, 키패드, 카드리더를 그대로 구동한다. "교체하지 말고 개조하라"는 이 제약이야말로, 이것을 실험실 데모가 아니라 수집가 커뮤니티에 진짜로 쓸모 있는 물건으로 만든다.
03 — 시스템 아키텍처
04 — 왜 WIZnet W5100인가? ⭐
🔷 기술적 핵심
Arduino Mega 2560의 SRAM은 고작 8 KB다. SAS 프로토콜 핸들러, IniFile 설정 파서, SD 라이브러리, RFID, 키패드, 디스플레이 드라이버 위에 소프트웨어 TCP/IP 스택(고전적인 ENC28J60 + UIPEthernet 방식)까지 얹으면 RAM이 고갈되고 시스템 전체가 불안정해진다. README의 변경 이력은 "이더넷과 SD 라이브러리의 메모리 요구량" 때문에 과거에 겪은 안정성 문제를 명시적으로 기록하고 있다. W5100은 이 문제를 하드웨어 레벨에서 해결한다.
🔷 사용 소켓 모드 — TOE / TCP (Sn_MR_TCP)
이 프로젝트는 W5100의 **하드와이어드 TCP 모드(TOE — TCP/IP Offload Engine)**를 두 소켓 모두에서 사용한다.
- 리스닝 소켓 —
EthernetServer server(80)→server.begin()이 웹 관리 콘솔을 위해 소켓을 TCP 리슨 상태로 둔다 (Sn_MR_TCP+listen()에 해당). - 클라이언트 소켓 —
client.connect(serverIP, 80)이 플레이어 트래킹 서버로 카드·미터 데이터를 보고하기 위해 아웃바운드 TCP 연결을 연다.
TCP 핸드셰이크, 재전송, 윈도잉, 체크섬 전부가 W5100 실리콘 내부에서 처리된다. Mega는 그저 SPI로 소켓 버퍼를 읽고 쓸 뿐이다 — lwIP도, 소프트웨어 스택도, 패킷당 CPU 비용도 없다. 바로 이것이, 메모리가 빠듯한 8비트 MCU가 실시간 카지노 시리얼 프로토콜을 돌리면서 동시에 HTTP 서버 노릇도 하고 HTTP 클라이언트 노릇도 할 수 있게 만드는 요인이다.
🔷 대체 솔루션 대비 우위
- vs ENC28J60(소프트웨어 스택): ENC28J60은 MAC+PHY일 뿐이라 MCU가 SRAM에서 전체 TCP/IP 스택을 돌려야 한다. SD + SAS + RFID로 이미 가득 찬 Mega에서 이 방식은 문서에 기록된 불안정성의 원인이었다. W5100의 온보드 스택은 이 부담을 통째로 없앤다.
- vs Wi-Fi 실드: README는 "Wi-Fi 실드는 권장하지 않는다"고 못 박는다. 카지노/가정 플로어의 슬롯머신은 미터 정확도와 원격 명령 신뢰성을 위해 혼잡한 2.4 GHz 무선이 아니라 결정론적이고 지연이 낮은 유선 링크가 필요하다.
- 드롭인 생태계: 표준 Arduino
Ethernet.h라이브러리가 W5100/W5200/W5500 계열을 직접 지원하므로, 이 실드는 Mega 스택에 그대로 꽂아 쓰는 플러그앤플레이 추가물이다.
🔷 검증된 증거 ✅
- 3,209줄짜리 V4 Mega 스케치에서
#include <Ethernet.h>+EthernetServer server(80)+EthernetClient확인. - 헤더 주석이 하드웨어를 정확히 명시: "Arduino Mega 2560 R3; 호환 RFID 또는 마그네틱 리더; W5100 이더넷 실드; 시리얼 포트."
- 설정 가능한 MAC(
byte mac[])과 정적 IP 폴백(IPAddress ip(192,168,1,254)), DHCP를 기본으로 하는 프로덕션급 네트워크 설정. - 코드에 SAS 명령 테이블 전체 존재(
LOCK,ULOCK,MUTE, 지폐인식기 활성/비활성EBILL/DBILL,transComplete, 크레딧/코인인/게임/잭팟 미터 읽기). - PDF 매뉴얼 3종 + 동반 Game Manager 앱 + 플레이어 트래킹 서버 컴포넌트 — 코드 조각이 아니라 완전하고 재현 가능한 시스템.
05 — 핵심 구성요소
🌐 WIZnet W5100 — TOE / TCP 모드 (듀얼 소켓: HTTP 서버 + HTTP 클라이언트)
8비트 Mega에서 네트워크 기반 TITO를 가능케 하는 하드웨어 TCP/IP 오프로드를 제공한다. 한 소켓은 웹 관리 콘솔을 위해 80포트를 리슨하고, 다른 소켓은 플레이어 트래킹 서버로 아웃바운드 연결한다. 모든 TCP 메커니즘이 SPI를 통해 칩 내부에서 돈다.
🎰 Arduino Mega 2560 R3
호스트 컨트롤러. Uno가 아니라 Mega를 고른 건 더 큰 SRAM과 다수의 하드웨어 시리얼 포트 때문이다 — Serial1 @ 19200을 게임기와의 SAS/TITO 링크 전용으로 쓰고, USB 시리얼은 디버깅용으로 남겨둔다.
💳 MFRC522 RFID 리더
카드로 플레이어를 식별하고, 추적 세션을 시작해 중앙 서버로 보고하는 "카드 인식" 이벤트를 발생시킨다. (주석 처리된 MagStripe 인클루드를 통해 마그네틱 스트라이프 리더도 지원한다.)
⌨️ 키패드 + LCD/VFD 디스플레이
머신 상의 운영자/플레이어 인터페이스. 키패드는 실시간 SAS 명령(음소거, 잠금, 지폐인식기 활성화)을 내리고, 디스플레이는 슬롯머신의 기존 플레이어 트래킹 패널을 재활용한다.
💾 SD 카드
설정 파일(IniFile), 웹 콘솔 HTML, 플레이어/보너스/관리자 카드 정의를 저장한다 — v4에서는 네트워크를 통해 원격으로 업데이트할 수 있다.
📡 SAS 프로토콜 계층 (Serial1)
게이밍 업계 표준 Slot Accounting System의 부분 구현으로, 미터를 읽고 머신 명령을 내린다 — 물리적 게임기와 네트워크 세계를 잇는 다리다.
06 — 활용 시나리오
01. 가정용 슬롯머신 수집가
차고나 게임룸의 슬롯머신에 진짜 TITO 티켓팅과 원격 관리를 개조로 얹는다 — 정산은 출력된 바우처로, 게임 잠금은 폰 브라우저로, 전부 가정 LAN을 통해.
02. 소규모 업장 / 아케이드 멤버십
여러 머신에 걸쳐 가벼운 플레이어 트래킹 멤버십 계층을 운영한다. 각 보드가 카드 세션과 미터를 하나의 중앙 서버로 보고 — 상용 카지노 관리 계약 없이.
03. 원격 게임 관리
물리적으로 닿을 수 없는 머신을 관리한다. 웹 콘솔에서 플레이 잠금/해제, 지폐인식기 활성/비활성, 잭팟 리셋, 설정 점검 — 유선 W5100 링크가 명령을 결정론적으로 유지한다.
04. 레트로 게이밍 & 프로토콜 교육
SAS 프로토콜과 TITO 메커니즘에 대한 드물게 완전히 문서화된 오픈소스 레퍼런스 — 실제 게이밍 하드웨어가 어떻게 통신하는지 배우려는 이에게 가치 있고, 네트워크 계층이 WIZnet 칩으로 깔끔하게 분리되어 있다.
결론
이 프로젝트는 카지노의 머신 관리 스택 일부 — TITO 티켓팅, SAS 제어, 플레이어 트래킹 — 를 8비트 Arduino 위에 재구축한다. 그리고 웹 콘솔을 서비스하면서 동시에 멤버십 서버로 보고하는 것을 Mega의 메모리를 무너뜨리지 않고 가능케 하는 것이 바로 WIZnet W5100의 하드웨어 TCP/IP 오프로드다.
- ✅ 실제 게이밍 업계 메커니즘(TITO + SAS)을 취미용 하드웨어에서 구현
- ✅ W5100이 TOE/TCP 모드로 HTTP 서버와 HTTP 클라이언트를 동시에 수행
- ✅ SD + SAS + RFID로 이미 포화된 8비트 MCU에서 TCP/IP 스택 전체를 오프로드
- ✅ 명령/미터 신뢰성을 위해 Wi-Fi가 아닌 유선 이더넷을 의도적으로 선택
- ✅ 네 개의 메이저 버전에 걸쳐 활발히 유지보수 (최신 빌드 20260623)
- ✅ 완전하고 재현 가능한 시스템: 펌웨어 + Game Manager 앱 + 트래킹 서버 + PDF 매뉴얼 3종
- ✅ 머신 하드웨어를 교체하지 않고 개조로 재활용
- ✅ 카지노급 티켓팅·멤버십 장비 역시 WIZnet 칩이 조용히 자리 잡은 또 하나의 영역임을 보여줌
그리고 리치 포인트: 슬롯머신 뒤의 티켓팅·플레이어 트래킹 전자장치 — 취미용 이더넷과는 거의 아무도 연결짓지 않는 도메인 — 조차 WIZnet 칩 위에서 돌아간다.
07 — WIZnet Makers 내 유사 프로젝트
이 프로젝트는 WIZnet Makers에 이미 존재하는 두 계열의 교집합에 놓여 있다. 네트워크 기반 캐시리스 결제/자판기 컨트롤러와 이더넷 게임 주변기기다. 이들 모두 돈, 크레딧, 혹은 입력 데이터를 머신 밖으로 옮기기 위해 WIZnet 칩의 TCP 링크에 의존한다 — TITO가 가진 것과 정확히 같은 아키텍처적 필요다.
- mdb-arduino-cashless — Arduino Uno가 MDB(Multi-Drop Bus) 자판기 프로토콜을 네트워크 캐시리스 결제 흐름으로 브리지하고, MFRC522 RFID 리더로 태그 결제를 처리한다. TITO의 가장 가까운 사촌이다. MDB가 자판기에서 하는 역할이 SAS가 슬롯머신에서 하는 역할과 같다 — 이 보드가 네트워크로 끌어올린 표준 시리얼 프로토콜인 것이다.
- Vending Machine / Cashless Device Implementation — 자판기 캐시리스 장치(Nottingham Hackspace의 Vend2 계보)로, 역시 RFID와 TCP 기반 네트워크 결제 백엔드를 결합한다. "카드 인증 → 머신에서 거래 승인"이라는 루프가 TITO의 카드 인식 이벤트와 동일하다.
- Ethernet gaming controller with W5500 — W5500 기반 이더넷 게임 컨트롤러. TITO의 유선 이더넷 기반 게이밍 주변기기 각도를 공유하지만 방향이 반대다. 게임의 출력을 계측하는 게 아니라, 플레이어의 입력을 게임으로 보낸다.
비교
| 프로젝트 | 핵심 MCU | WIZnet 역할 | 머신 프로토콜 | 카드/인증 | 데이터 방향 | 서버/클라이언트 |
|---|---|---|---|---|---|---|
| Arduino TITO & Player Tracking (본) | Arduino Mega 2560 | W5100 · TCP (TOE) | SAS (슬롯머신) | MFRC522 RFID | 미터 아웃 + 원격명령 인 | 양쪽 (HTTP 서버+클라이언트) |
| mdb-arduino-cashless | Arduino Uno | W5x00 · TCP | MDB (자판기) | MFRC522 RFID | 결제 인증 | 클라이언트측 결제 흐름 |
| Vending / Cashless (Vend2) | Arduino | W5x00 · TCP | 자판기 (Vend2) | RFID | 결제 인증 | 네트워크 백엔드 |
| Ethernet gaming controller | (컨트롤러 보드) | W5500 · TCP | — (HID형 입력) | — | 입력 인 → 게임 | TCP 링크 |
Q&A
Q. 어떤 WIZnet 소켓 모드를 쓰며, 왜 UDP가 아닌가? A. **TOE / TCP 모드(Sn_MR_TCP)**를 쓴다. 웹 관리 콘솔(인바운드)과 플레이어 트래킹 보고(아웃바운드) 모두 HTTP이며, HTTP는 TCP 기반이다. 미터 데이터와 원격 명령에는 신뢰성 있고 순서가 보장된 전달이 중요하므로 UDP보다 TCP가 올바른 선택이다.
Q. 비용 절감을 위해 ENC28J60을 쓰면 안 되나? A. ENC28J60은 MAC+PHY일 뿐이라 MCU가 소프트웨어/SRAM에서 TCP/IP 스택을 돌려야 한다. README 변경 이력은 이더넷+SD 소프트웨어 경로의 메모리 총량이 Uno급 하드웨어에서 실제 불안정성의 원인이었음을 기록한다. W5100의 칩 내장 스택은 이 RAM 압박을 없앤다 — Mega가 이미 SAS, SD, RFID, 키패드, 디스플레이 코드를 돌리고 있을 때 필수적이다.
Q. W5500이나 W55RP20으로 옮길 수 있나? A. 깔끔하게 가능하다. 표준 Ethernet.h 라이브러리가 W5100/W5200/W5500 계열 전체를 지원하므로, W5500 실드는 더 많은 소켓과 더 높은 SPI 처리량을 갖춘 거의 드롭인 업그레이드가 된다. W55RP20(RP2040 + W5500 패키지 통합)은 흥미로운 단일칩 현대화이지만, Mega 전용 SAS 타이밍을 RP2040으로 포팅해야 한다.
Q. 이거 합법인가 / 부정 장치 아닌가? A. 아니다. 표준 SAS 미터를 읽고 소유자가 통제하는 머신을 관리할 뿐이며, 이는 정당한 카지노 호스트 시스템이 수행하는 것과 동일한 읽기/명령 동작이다. 제3자의 머신을 조작하는 게 아니라, 자기 하드웨어를 관리하는 가정 수집가와 소규모 업장을 대상으로 한다.
