USB Communication

This page has not been completed. Parts may be missing or reorganized before completed. Information is provided as-is and may have errors.

This page will fill up with documentation for the USB communication with the Prizm. If you have any documentation or have played around with the USB communication for the Prizm, please discuss in the Talk:USB_Communication page. Thank you!

Protocol

The Prizm uses the MSD USB protocol for Drive mode, Screen Receive, and OS Updates (both modes). For the extra data, it uses UFI bulk-mode data methods.

MSD CBW Description

Bit	7	6	5	4	3	2	1	0
0-3	bCBWSignature
4-7	dCBWTag
8-11	dCBWDataTransferLength
12	bmCBWFlags
13	Reserved (0)				bCBWLUN
14	Reserved (0)			bCBWCBLength
15-30	CBWCB

• dCBWSignature - Always 0x43425355 in little endian. Indicates a CBW.
• dCBWTag - A 4 byte tag sent by the host, echoed back by the peripheral in a CSW.
• dCBWDataTransferLength - Amount of bytes, in little endian, expected to be sent/received on a bulk pipe directly after sending the packet.
• bmCBWFlags - 0x00 if sending host to device, 0x80 if device to host. Ignored if dCBWDataTransferLength is 0.
• bCBWLUN - Set to 0.
• bCBWCBLength - Length of usable data in CBWCB. Doesn't mean packet size is different!
• CBWCB - Command block to be executed. For the Prizm, this is a UFI command block.

MSD CSW Description

Bit	7	6	5	4	3	2	1	0
0-3	dCSWSignature
4-7	dCSWTag
8-11	dCSWDataResidue
12	bCSWStatus

• dCSWSignature - Always 0x53425355 in little endian. Indicates a CSW.
• dCSWTag - Set to the dCBWTag of the received CBW.
• dCSWDataResidue - When receiving data from the host, this is the difference between the amount of data expected in dCBWDataTransferLength and the actual amount of data processed. For sending, it is the difference between dCBWDataTransferLength and actual bytes sent.
• bCSWStatus - Indicates the success or failure. Responses are below

Value	Description
0x00	Command Passed
0x01	Command Failed
0x02	Phase Error
0x03 and 0x04	Reserved (Obsolete)
0x05 to 0xFF	Reserved

If there is an error, you should perform a phase recovery.

MSD UFI Command Block Description

Bit	7	6	5	4	3	2	1	0
0	Operation Code
1	Logic Unit Number			Reserved
2 (MSB)	Logical Block Address
3
4
5 (LSB)
6	Reserved
7 (MSB)	Transfer or Parameter list or Allocation Length (usually allocation length)
8 (LSB)
9	Reserved
10	Reserved
11	Reserved

MSD UFI Extended Command Block Description

Bit	7	6	5	4	3	2	1	0
0	Operation Code
1	Logic Unit Number			Reserved
2 (MSB)	Logical Block Address
3
4
5 (LSB)
6 (MSB)	Transfer or Parameter list or Allocation Length (usually allocation length)
7
8
9 (LSB)
10	Reserved
11	Reserved

Prizm UFI Commands

ID	Name	Parameters	Returns	Comments
0xC0	Poll	todo	The prizm returns a 0xD0 response. Todo.	Basically used to see if the Prizm is done processing the last sent data and is ready for more, and also checks to see if the Prizm wants to send something.

0xC0

Since the peripheral cannot initiate a data send on its own, the Prizm gets polled constantly to check for any activity. Here is the packet layout:

C0

Custom return data:

D0 00 00 00 00 00 00 SS SS 00 AA AA 00 00 00 00

• SS SS - Amount of bytes as big endian that the Prizm wants to send
• AA AA - Activity status of the Prizm. If value is not 10 00, then the Prizm is busy and cannot accept more data.

0xC1

Receives data. Should be sent if 0xC0 command revealed that the Prizm wants to send stuff. Syntax:

C1 00 00 00 00 00 SS SS

• SS SS - Amount of bytes to be sent.

Once this is sent, the Prizm sends raw data.

0xC2

This command is used to send raw data to the Prizm. It seems the first byte of the raw data is not part of the data. The raw data usually is made up of character-encoded hex at the start. Command syntax:

C2 00 00 00 00 00 SS SS

• SS SS - Amount of bytes to be sent.

Once this is sent, send the raw data directly after. Poll before sending more.

Protocol 7

Protocol 7 is the method for communicating to Casio calcs over IO or USB. The commands are sent in special command packets sent to the prizm as raw data after sending a 0xC2 command as an MSD UFI command. Confusing? Indeed. Below is the table showing you how the raw data sent to the Prizm from the 0xC2 UFI commands is read:

Byte	Field Name	Desciption	Values
1	Type	The basic purpose of the packet	0x00 to 0x1F
2	Subtype	The specific function of the packet	"00" to "57"
1	Extended	Decides if data size and data field follow	'0' - no; '1' - yes
(4, if extended)	Data size	Size of data field	"0000" to "FFFF"
(n, if extended)	Data	Additional data related to packet function
2	Checksum	Checksum for integrity check	"00" to "FF"

The protocol on the Prizm is not exposed in all modes. Currently, USB Drive mode ignores Protocol 7 packets, but not the UFI packets. In screen receiver, there is a role swap and the packet structure is different. The only mode known to follow this is OS Update mode.

Credits

BrandonW
Simon Lother and Andreas Bertheussen for Protocol 7 info. PDF released under Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0) license, located here.