diff --git a/chunihook/led1509306.c b/chunihook/led1509306.c index 16a3b32..47fdd09 100644 --- a/chunihook/led1509306.c +++ b/chunihook/led1509306.c @@ -1,3 +1,11 @@ +/* + SEGA 837-15093-06 LED controller emulator + + Credits: + + somewhatlurker, skogaby +*/ + #include #include diff --git a/chusanhook/led1509306.c b/chusanhook/led1509306.c index c657c84..420c6f5 100644 --- a/chusanhook/led1509306.c +++ b/chusanhook/led1509306.c @@ -1,3 +1,11 @@ +/* + SEGA 837-15093-06 LED controller emulator + + Credits: + + somewhatlurker, skogaby +*/ + #include #include diff --git a/doc/15093-06.txt b/doc/15093-06.txt new file mode 100644 index 0000000..75e3011 --- /dev/null +++ b/doc/15093-06.txt @@ -0,0 +1,124 @@ +Reverse-engineered 15093-06 protocol +(somewhatlurker) + + +The host and device seem to communicate using data frames similar to (but not +the same as) jvs and the slider protocol. + +In general, the host will issue a command to the device and the device will +respond using the same command number. +The response will have source and destination addresses swapped of course. + +The host can request for future packets to not have responses, though this may +only affect certain commands such as LED data. Just something to be aware of +when implementing the system. + + +Basic packet format: `[sync] [dest] [src] [len] [data] [sum]` +sync: 0xe0 +dest: destination address +src: source address +len: length of data +data: payload +sum: sum of all prior bytes except sync + +When the host requests something from/sends something to the board, [data] will +be `[cmd] ...`. +cmd: command number +(followed by arbitrary additional data if applicable) + +When the board responds, [data] will be `[status] [cmd] [report] ...`. +status: status code + (1: Ok, 2: SumError, 3: ParityError, 4: FramingError, 5: OverRunError, + 6: RecvBfOverflow) +cmd: command number (same as the one from request) +report: report status code + (1: Ok, 2: Wait, 3: ReportError, 4: ReportError) +(followed by arbitrary additional data if applicable) + + +Escaping: +Like in JVS, the sync byte and 0xd0 are reserved. To include these in data, send +0xd0 followed by the reserved byte minus 1. (ie. `d0 cf` or `d0 df`) + + +Addresses and game-specific details: +Chunithm uses 2 for the LED boards and 1 for the host. There's two boards +present, but they are differentiated purely by COM port (one COM10, one COM11). +Based on wiring diagrams, I think COM10 should be for the left half of the +marquee display (10 pixels * 5 columns) and the left partition lights (3 pixels). +COM11 should be for the right half (6 columns) and the right partition lights. +The marquee appears to snake strips back and forth (input of first column should +be at the top). + +Ongeki seems to use 1 for the LED board and 2 for the host. It should be on +COM3. +I think the chain is left button (x2), lower left pillar (x7), left ring (x9), +upper left pillar (x7), top edge (x11), upper right pillar (x7), +right ring (x9), lower right pillar (x9), right button (x2). + + +Known Commands: +0xf0: get board info + -- chunithm host sends command with no additional data (`e0 02 01 01 f0 f4`) + -- respond with additional data `[boardno] 0a [chipno] ff [fwver] ...`, + boardno and chipno are strings (seems same as slider protocol) + -- ongeki uses 0a and ff as string terminators, not sure if that's the + intended use though + -- fwver can be found in an update filename (90 for chunithm, a0 for ongeki) + -- there's probably some additional bytes like for slider board info, but + I don't think they're important + -- pad strings with 0x20 (important!) + +0xf2: get firm sum + -- respond with additional data `[sum_upper] [sum_lower]` + -- sum can be found in an update filename (adf7 for chuni, aa53 for ongeki) + +0xf3: get protocol version + -- respond with additional data `[appli_mode] [major] [minor]`, appli_mode + is bool + -- version shouldn't matter much, but I think appli_mode should be 1 + -- try `01 01 04` + +0x11: set timeout + -- host will send with additional data `[timeout_upper] [timeout_lower]` + -- respond with additional data `[timeout_upper] [timeout_lower]` + -- 0 disables timeout + -- presumably this makes the device reset if no data is sent for a certain + time period, or maybe the device sends some kind of heartbeat within this + period + +0x10: reset + -- host will send one additional byte (d9) to choose the reset code/type + -- respond with no additional data + +0xf1: get board status + -- shouldn't be necessary to properly implement this, but if you must... + host sends with additional data `[flagclear]`, + respond with additional data `[boardflag] [uartflag] [cmdflag] [dipsw]` + -- flagclear is a bool that presumably resets error flags + -- flags are bitfields + -- boardflag: `0 0 0 0 [bor] [reset] [timeout] [wdt]` (MSB first) + -- uartflag: `0 0 [txoverflow] [rxoverflow] [overrun] [framing] [parity] [sum]` + -- cmdflag: `0 0 0 0 [exe] [param] [unknown] [busy]` + +0x14: set disable response + -- host will send with additional data `[enable]` + -- respond with additional data `[enable]` + -- it looks like setting enable to true will _disable_ responses + -- I think this makes the device not send responses for future commands + -- it might only affect LED commands + +0x82: set led direct + -- host sends 66*3 bytes for rgb as additional data + -- respond with no additional data + +0x86: set led count + -- host sends additional data `[count]` + -- respond with additional data `[count]` + -- probably just affects the output from the board to LEDs, + neither chuni nor ongeki use this + +0xfd: enter bootloader + -- no real point implementing this, just interesting + -- MCU might be an ATMega 32M1 btw, but I'm not sure \ No newline at end of file diff --git a/fgohook/led1509306.c b/fgohook/led1509306.c index 17f3451..e922738 100644 --- a/fgohook/led1509306.c +++ b/fgohook/led1509306.c @@ -1,3 +1,11 @@ +/* + SEGA 837-15093-06 LED controller emulator + + Credits: + + somewhatlurker, skogaby +*/ + #include #include