IO protocols & cab internals

what the cabs actually say over the wire. mostly so my home controllers can talk the same language, partly because i can't look at a serial port without wanting to sniff it.

scope note: this is about understanding the input hardware so i can build controllers that feel right. nothing here is about bypassing anything on real cabs. don't touch operators' machines, ever.

---

general#

• sega cabs (maimai, chuni) run on ALLS PCs (windows-based) with separate IO boards talking over serial/USB
• konami cabs (sdvx) run on konami PCs with their own IO boards
• community documentation for many of these boards lives on sega.bsnk.me and similar sites. it's the reference for anything below marked with a source

---

maimai touch panel#

pre-DX panel (the one documented on sega.bsnk.me):

• serial on COM3, 9600 baud, 8 data bits
• text-based protocol, no null bytes
• game → board packets in braces: {like this}
• board → game packets in parens: (like this)

commands:

in active mode, the board streams packed bitfields with the A1–8, B1–8 and C sensor states for each player, a few bits per byte so everything stays printable.

DX panel: more zones (34: adds D1–8 and E1–8 and splits C), different board. my washer firmware emulates a DX-style zone report. (verify the DX packet layout before trusting my notes, i reverse-engineered it from my own emulator setup and community docs)

lessons for controller builders#

• the game expects a steady stream, not change-only events. stop sending and it thinks your hand is frozen
• thresholds are set by the game at boot. your firmware should accept them even if you ignore them

---

CHUNITHM slider#

• the slider board reports 32 touch values (16 cells × top/bottom), each a raw pressure/capacitance value 0–255
• the game also sends LED data back to the board for the 31 lighting segments
• air sensors are a separate IO board (beams reported as a bitmask)
• protocol is a framed binary serial format with a sync byte, command, length, payload, checksum (verify framing)

lessons#

• send raw values, not booleans. the game applies its own thresholding and it feels wrong if you pre-threshold
• the LED data is how you get cab-accurate lighting for free. use it

---

SDVX#

• buttons and knobs go through konami's IO board. knobs report as relative encoder deltas
• most home controllers present as a USB HID gamepad/keyboard + mouse for knobs and let the PC side handle it
• knob sensitivity is entirely about how many encoder counts map to a laser width. this is why every controller feels different

---

card readers#

• aime (sega): NFC reader, reads FeliCa and MIFARE-based aime cards. lights up in colours on the cab
• e-amusement pass (konami): FeliCa-based cards, also readable by the same kind of NFC hardware
• phones with FeliCa (japanese ones mostly) can act as cards via app in some regions

---

my sniffing setup#

• a cheap USB logic analyzer + saleae-compatible software for UART work on my own boards
• a USB-serial adapter in passthrough mode to watch traffic between my own emulated board and my test PC
• only my own hardware. never a public cab. i'm a guest at those arcades