Difference between revisions of "Ring-Con"

From Nintendo Switch Brew
Jump to navigation Jump to search
Line 12: Line 12:
 
Some commands/replies use CRC(s) for validating the previous N-bytes prior to the CRC. When the CRC is invalid, the app sets an output flag indicating invalid CRC and skips writing output-data to the output-param.
 
Some commands/replies use CRC(s) for validating the previous N-bytes prior to the CRC. When the CRC is invalid, the app sets an output flag indicating invalid CRC and skips writing output-data to the output-param.
  
This CRC doesn't use Xor(In/Out)/Reflect(In/Out). The polynomial is 0x8D.
+
This CRC doesn't use Xor(In/Out)/Reflect(In/Out). The polynomial is 0x8D. This is CRC8.
  
 
= Commands =
 
= Commands =

Revision as of 22:07, 13 March 2020

This page documents how the Ring Fit Adventure game uses hidbus for using the Ring-Con ExternalDevice, which attaches to Joy-Cons.

The BusType used with GetBusHandle is value 0 or 1.

The ExternalDeviceId is 0x20. After EnableExternalDevice is used successfully during initialization, EnableJoyPollingReceiveMode(flag=true) is used with 4-byte command 0x020101. For cleanup, DisableJoyPollingReceiveMode is used then on success EnableExternalDevice(flag=false) is used.

Commands (input data for EnableJoyPollingReceiveMode / SendAndReceive) start with the u32 cmd, there's generally no data after that. Data in the replies are at least 0x4-bytes, with fields being 4-byte aligned. Reply+0 is the u8 status. When the output size doesn't match the expected size, or status is non-zero, error 0xEDA is returned. When status is non-zero, a func is called with the status value which updates global state.

The status field is not listed below since all replies have it.

CRC

Some commands/replies use CRC(s) for validating the previous N-bytes prior to the CRC. When the CRC is invalid, the app sets an output flag indicating invalid CRC and skips writing output-data to the output-param.

This CRC doesn't use Xor(In/Out)/Reflect(In/Out). The polynomial is 0x8D. This is CRC8.

Commands

Input cmd u32 Input cmd size Reply size
#0x00020000 0x4 0x8
#0x00020100 0x4 0x10
#0x00020101 0x4 0x8
#0x00020104 0x4 0x8
#0x00020105 0x4 0x8
#0x00020204 0x4 0x8
#0x00020304 0x4 0x8
#0x00020404 0x4 0x8
#0x00020504 0x4 0x8
#0x00020A04 0x4 0x14
#0x00023104 0x4 0x8
#0x00023204 0x4 0x8
#0x04013104 0x8 0x8
#0x04011104 0x8 0x4
#0x04011204 0x8 0x4
#0x04011304 0x8 0x4
#0x10011A04 0x14 0x4

0x00020000

The two u8s at reply+0x4 are copied to an output struct, with the order swapped in the output struct. This is also used directly by various funcs, without the struct.

This is probably some version field or similar? Funcs using this do: if (u8 reply_x5 >= 0x20) {} else {}

0x00020100

Reply:

Offset Size Description
0x4 0x8 u64 copied to an output struct.
0xC 0x4 u32 copied to an output struct.

0x00020101

This is used with EnableJoyPollingReceiveMode/GetJoyPollingReceivedData. Reply+0x4 is an u16 which is copied to an output struct, the timestamp is also copied.

0x00020104

Reply+0x4 is the output 16bit value.

See #0x00020A04.

0x00020105

Reply+0x4 is the output u8.

0x00020204

Reply+0x4 is the output 16bit value.

See #0x00020A04.

0x00020304

Reply+0x4 is the output 16bit value.

See #0x00020A04.

0x00020404

Reply+0x4 is the output 16bit value.

See #0x00020A04.

0x00020504

Reply+0x4 is a s16. After successfully using this cmd, this calls the func for #0x00020A04. When that's successful, this does the following with the output from that func and the earlier reply data: s16 tmp = s16_struct_x2 - s16_struct_x0; if (tmp < 0) tmp++; *16bit_outparam = replydata + (tmp>>1); Then this returns 0, regardless of whether #0x00020A04 was successful.

0x00020A04

The app uses cmd #0x00020000 first. When u8 reply_x5 from that cmd is >=0x20, it proceeds to use cmd 0x00020A04 then returns. Otherwise, the following cmds are used with the output being copied to the output struct, then returns: #0x00020104 (output_struct+0x0), #0x00020204 (output_struct+0x2), #0x00020404 (output_struct+0x6), #0x00020304 (output_struct+0x4).

The func for this is only called by the func implementing #0x00020504.

Reply:

Offset Size Description
0x4 0x2 16bit value copied to output_struct+0x0.
0x8 0x2 16bit value copied to output_struct+0x2.
0xC 0x2 16bit value copied to output_struct+0x4.
0x10 0x2 16bit value copied to output_struct+0x6.

0x00023104

Reply:

Offset Size Description
0x4 0x3 Data, copied to an output struct as an u32.
0x7 0x1 #CRC over the previous 0x3-bytes.

0x00023204

The func implementing this in the app is identical to #0x00023104 except for the cmd u32.

0x04013104

The data at cmd+0x4 is all-zero. The app doesn't use reply data here besides the status.

Unlike the other cmds, this checks for output_size==0x4, instead of {output buffer size} (it's unknown whether this is intended).

0x04011104

Cmd+0x4 is the 4-byte input. The output_size is not checked.

See #0x10011A04.

0x04011204

Cmd+0x4 is the 4-byte input. The output_size is not checked.

See #0x10011A04.

0x04011304

Cmd+0x4 is the 4-byte input. The output_size is not checked.

See #0x10011A04.

0x10011A04

The app uses cmd #0x00020000 first. When u8 reply_x5 from that cmd is >=0x20, it proceeds to use cmd 0x10011A04 then returns. Otherwise, the following cmds are used, with the same 4-byte input listed in the below table: #0x04011104 (below cmd+0x4), #0x04011204 (below cmd+0x8), #0x04011304 (below cmd+0xC).

The app doesn't use reply data here besides the status, and the output_size is not checked.

Cmd:

Offset Size Description
0x4 0x2 Func input param & 0xFFFF
0x6 0x1 #CRC over the previous 2-bytes.
0x7 0x1 Padding.
0x8 0x2 (Func input param >> 16) & 0xFFFF
0xA 0x1 #CRC over the previous 2-bytes.
0xB 0x1 Padding.
0xC 0x2 (Func input param >> 32) & 0xFFFF
0xE 0x1 #CRC over the previous 2-bytes.
0xF 0x1 Padding.
0x10 0x4 Zeros