Difference between revisions of "Download Play"
| Line 89: | Line 89: | ||
|- | |- | ||
| 0x0 | | 0x0 | ||
| − | | | + | | 0x2F0 |
| | | | ||
|} | |} | ||
| Line 101: | Line 101: | ||
|- | |- | ||
| 0x0 | | 0x0 | ||
| − | | | + | | 0x598 |
| | | | ||
|} | |} | ||
| Line 113: | Line 113: | ||
|- | |- | ||
| 0x0 | | 0x0 | ||
| − | | | + | | 0x5A8 |
| | | | ||
|} | |} | ||
Revision as of 19:13, 9 April 2016
The 3DS dlplay title has two dlplay modes: 3DS and DS. DS dlplay is just regular dsmode dlplay, same interface and protocol as before. Like DS gamecards, holding down start+select while starting the dsmode dlplay client will disable stretching the screens.
Download Play protocol
The Download Play protocol for 3DS is completely different from the DS Wireless Multiboot (WMB) protocol. While the DS WMB protocol used to send program code in plaintext over wireless, the 3DS Download Play protocol uses UDS which uses CCMP encryption etc. See also here.
Download Play UDS protocol
This section describes the data transferred using the UDS service. All data is stored as big-endian.
UDS data_channel 0x1 is used for spectator data, while all non-spectator data uses data_channel 0x2. The spectator data is received by connecting to the network as a spectator then receiving data-frames, this is handled when scanning for DLP networks.
This is the data starting at offset 0x0 for UDS PullPacket/SendTo:
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x1 | Must be 0x1 for spectator data. |
| 0x3 | 0x3 | ? |
| 0x4 | 0x2 | Size of the entire frame. The actual_size from PullPacket is the same size as this value, but the spectator handling code doesn't check that. |
| 0x6 | 0x2 | ? |
| 0x8 | 0x4 | Checksum |
| 0xC | 0x1 | Spectator data: frameid, must be less than total_frames. Normal data: unknown. |
| 0xD | 0x1 | Spectator data: total_frames. Normal data: unknown. |
| 0xE | 0x1 | Unknown. This must match a state value. When this frame value is non-zero, 0x1 is used for the frame value when doing the compare instead. |
| 0xF | 0x1 | ? |
| 0x10 | The frame-specific payload starts here. |
Total_frames is at least 0x4 normally. When a sysupdate is included, total_frames is 0x4+<total frames required for the titlelist(normally 0x1)>.
Frames:
| Frameid | frame_size | Description |
|---|---|---|
| 0x0 | 0x300 | Various metadata, two UTF-16 strings displayed by the DLP-client, and the start of the icon gfx. |
| 0x1-0x3 | 0x5A8 | The remaining icon gfx. |
| 0x4-<total frames-1> | 0x5B8 | Sysupdate titlelist, if any. |
The structure of each spectator frame relative to "frame-specific payload" is described below.
Metadata frame
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x2F0 |
Icon gfx frame
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x598 |
Sysupdate titlelist frame
| Offset | Size | Description |
|---|---|---|
| 0x0 | 0x5A8 |
Broadcasted application data
The Download Play protocol broadcasts 3DS application data in the CIA format. The title is installed to NAND, and is kept there until new CIA data from a different game is received through the Download Play protocol.
Remote Distribution of System-Updates
As part of the child distribution process, a 3DS acting as the server in a local Download Play session, can send system updates to another 3DS unit acting as the client, through first sending the system update package then instructing the client to install reboot and reinstantiate a connection (which it caches information about temporarily) remotely, if it finds system updates are necessary before distributing the child-application. ( eg. multiplayer game or a demo. ) Like "update" partitions on CTR Cards, this is not an "automatic feature" and not implemented for all Download Play titles. This system update data is from the application's system update CFA, prior to beginning the data transfer the host broadcasts data-frames which contain a title-list from the system update CFA.