PS3 NeGcon - Can it be done???

[JABBERJAW]

I think, that the converter did not work for gran turismo 5, at least the demo version. I do not own the game, but will give it another shiot sometime soon, not tonight though, too tired. It worked fantastic for Ridge racer though, right on the money. The one I made also worked very well for that game.

[mikrucio]

Good luck doing Barrel rolls...

[JABBERJAW]

Yeah, I made a ps3 version of this controller, added buttons, a platform to put it in, and it works perfect for barrel rolls. however, as is, not too good for that game, but very smooth turning for other games though

[CRP]

Hi I am building element42's adapter as well. I have not done a faithful reproduction, but rather have built the basic interface, and am now playing around trying to get the best setup.
My goal is using the Ultraracer controller with this adapter. This is basically a NegCon with additional L2, R1 and R2 buttons.

Currently open problems (maybe somebody can help):

1) replicate the PS button somehow; this appears to be possible, according to this post and comments

2) somehow try to map the analog buttons to the analog L2 and R2 inputs. Does anyone know how the reportDescriptor is supposed to be set up for this? As of now I have L1 and I buttons on the negcon mapped to Z and Rz, but the PS3 does not like this setup (works fine on my mac though)

3) determine setups for a few games, then save them to the microcontroller's
flash memory and allow the user to cycle between different setups.

Any input is welcome!

CRP

[element42]

1) replicate the PS button somehow; this appears to be possible, according to this post and comments

interesting, very interesting. Will probably require some hacking of the v-usb code. EDIT: I see you've posted in the comments, I hope someone gets back to you...

2) somehow try to map the analog buttons to the analog L2 and R2 inputs. Does anyone know how the reportDescriptor is supposed to be set up for this? As of now I have L1 and I buttons on the negcon mapped to Z and Rz, but the PS3 does not like this setup (works fine on my mac though)

I tried many different reportDescriptors trying to get the L2 and R2 analog, without any success; IIRC correctly most of the time it just refused to function as a USB device properly, I wondered if there are some limits to the v-usb capability.

If you find solutions to either of these, please do let me know and I will include your code (with credit!).

[CRP]

I tried many different reportDescriptors trying to get the L2 and R2 analog, without any success; IIRC correctly most of the time it just refused to function as a USB device properly, I wondered if there are some limits to the v-usb capability.

I have added the following to the reportDescriptor:

	0x05, 0x01,		        //   USAGE_PAGE (Generic Desktop)
	0x75,0x08,				//Report_Size (8)
	0x95,0x02,				//Report_Count (2)
	0x15,0x00,				//Logical_Minimum (0)
	0x26,0xFF,0x00,			//Logical Maximum (255)	
	0x09,0x32,				//Usage (Z)
	0x09,0x33,				//Usage (Rx)
	0x81,0x02,				//Input (Data, Var, Abs)

With this, a PC (mac in my case) correctly recognizes the two analog buttons as Z-Axis and X-Rotation. Unfortunately, a quick test with Outrun shows that those two axes are not recognized on the PS3. I will continue trying, though

What have you done in the end with those analog buttons? Just left them digital?

EDIT: just found the following info:

Report data
idx Assign
0 LAnalogX
1 LAnalogY
2 RAnalogX
3 RAnalogY
4 equals 41?
5 equals 45?
6 Button flag - Triangle(0x01) Circle(0x02) Cross(0x04) Cube(0x0 L2(0x10) R2(0x20) L1(0x40) L1(0x80)
7 Button flag - Select(0x01) LAnalogClick(0x02) RAnalogClick(0x04) Start(0x0 Up(0x10) Right(0x30) Down(0x50) Left(0x70)
8
9
10
11
12
13 Up Analog (0x00 to 0xFF)
14 Right Analog (0x00 to 0xFF)
15 Down Analog (0x00 to 0xFF)
16 Left Analog (0x00 to 0xFF)
17 L2 Analog (0x00 to 0xFF)
18 R2 Analog (0x00 to 0xFF)
19 L1 Analog (0x00 to 0xFF)
20 R1 Analog (0x00 to 0xFF)
21 Triangle Analog (0x00 to 0xFF)
22 Circle Analog (0x00 to 0xFF)
23 Cross Analog (0x00 to 0xFF)
24 Cube Analog (0x00 to 0xFF)
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40 Motion X(H)
41 Motion X(L)
42 Motion Y(H)
43 Motion Y(L)
44 Motion Z(H)
45 Motion Z(L)

so it appears that one needs to send a report of 45 bytes in order to communicate correctly with the PS3. If I understand correctly, USB 1.1 only supports 8 byte descriptors, although on the V-USB forum there is one guy who suggests to do the following to circumvent this limit:

while (!usbInterruptIsReady()) usbPoll(); // need to wait
usbSetInterrupt((void *)&reportBuffer + 0, curGamepad->report_size);
while (!usbInterruptIsReady()) usbPoll();//need to wait
usbSetInterrupt((void *)&reportBuffer + 8, curGamepad->report_size);

I haven't tried it, but may be worth a shot.

EDIT: here is the full HID descriptor: http://wiki.ps2dev.org/ps3:hardware:...ocoldescriptor

So the open questions are:
1) what happens in those 13 bits right after the 19 buttons?
if these are just for padding, I might reduce 13 to 5 and so eliminate a "useless" byte. thus I would have 8 bytes for report id, 19 buttons + padding and 4 axes, which should be fine for v-usb; notice that the hid descriptor contradicts the table above, according to which report starts with axes and is then followed by buttons.

2) what are those 38 bytes after the XYZRz axes?
my guess is that this is where the analog buttons + motion end up, as per items 8-45 in the table I placed above

3) what are those 5 48byte blocks at the end?
no idea at all

[element42]

What have you done in the end with those analog buttons? Just left them digital?

yeah, they're just digital.

The report desciptor data is the full sixaxis report, no? Again, I spent a fair amount of time playing with that with no luck. Some of that space will be battery/connection data, and I think some of it si for identifying data that gets sent to the controller, ie will be for LED/vibration control.

so it appears that one needs to send a report of 45 bytes in order to communicate correctly with the PS3. If I understand correctly, USB 1.1 only supports 8 byte descriptors, although on the V-USB forum there is one guy who suggests to do the following to circumvent this limit:

while (!usbInterruptIsReady()) usbPoll(); // need to wait
usbSetInterrupt((void *)&reportBuffer + 0, curGamepad->report_size);
while (!usbInterruptIsReady()) usbPoll();//need to wait
usbSetInterrupt((void *)&reportBuffer + 8, curGamepad->report_size);

good find, if that works you could just replicate the entire sixaxis HID, fill it with empty data and see if it gets recognised, which would be an advance on what I managed.

[CRP]

I have some partial progress, now all NegCon analog buttons work.

Here is the HID descriptor:

static uchar reportBuffer[10];	// buffer for HID output reports

PROGMEM char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] = {	// USB report descriptor

    0x05, 0x01,                // USAGE_PAGE (Generic Desktop)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0xa1, 0x02,						// Collection (Logical)    
    0x85, 0x01,						//report id 1
    0x75, 0x08,                    //     REPORT_SIZE (8)
    0x95, 0x01,                    //     REPORT_COUNT (1)
    0x15, 0x00,                    //     LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //     LOGICAL_MAXIMUM (255)
    0x81, 0x03,                    //     Input (Constant, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
	0x75, 0x01,						// report size 1
	0x95, 0x13,						// report count 19 
	0x15, 0x00,						//log min 0
	0x25, 0x01,						//log max 1
	0x35, 0x00,						//phy min 0
	0x45, 0x01,						//phy max 1
	0x05, 0x09,						//usage page button
	0x19, 0x01,						//usage min 1
	0x29, 0x13,						// usage max 19
	0x81, 0x02,						// Input (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
    0x75,0x01, //        			 Report Size.............    (1)  
	0x95,0x0d, //					  Report Count............    (13)  
	0x06,0x00, 0xff,//					  Usage Page    (Vendor defined 0) 
	0x81,0x03, //					  Input...................   (Constant, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
	0x15,0x00, //					  Logical Minimum.........    (0)  
	0x26,0xff,0x00, //					  Logical Maximum.........    (255)  
	0x05,0x01, //					  Usage Page    (Generic Desktop) 
	0x09,0x01, //					  Usage (Pointer)    
	0xa1,0x00, //						Collection (Physical)    
	0x75,0x08, //							Report Size.............    (8)  
	0x95,0x04, //							Report Count............    (4)  
	0x35,0x00, //							Physical Minimum........    (0)  
	0x46, 0xff, 0x00, //					Physical Maximum........    (255)  
	0x09,0x30, //							Usage (X)    
	0x09,0x31,//							Usage (Y)    
	0x09,0x32,//							Usage (Z)    
	0x09,0x35,//							Usage (Rz)    
	0x81,0x02,//							Input...................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
	0xc0,	//					  		End Collection     
// 	0x05,0x01,//					  Usage Page    (Generic Desktop) 
// 	0x75,0x08, //					  Report Size.............    (8)  
// 	0x95,0x27,//					  Report Count............    (39)  
// 	0x09,0x01, //					  Usage (Pointer)    
// 	0x81,0x02,//					  Input...................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield) 
// 	0x75,0x08,//					  Report Size.............    (8)  
// 	0x95,0x30,//					  Report Count............    (48)  
// 	0x09,0x01,//					  Usage (Pointer)    
// 	0x91,0x02,//					  Output..................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
// 	0x75,0x08,//					  Report Size.............    (8)  
// 	0x95,0x30,//					  Report Count............    (48)  
// 	0x09,0x01,//					  Usage (Pointer)    
// 	0xb1,0x02,//					  Feature.................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
	0xc0,//					End Collection     
// 	0xa1,0x02,//			Collection (Logical)    
// 	0x85,0x02,//					  ReportID................    (2)  
// 	0x75,0x08,//					  Report Size.............    (8)  
// 	0x95,0x30,//					  Report Count............    (48)  
// 	0x09,0x01,//					  Usage (Pointer)    
// 	0xb1,0x02,//					  Feature.................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
// 	0xc0,//					End Collection     
// 	0xa1,0x02,//			Collection (Logical)    
// 	0x85,0xee,//					  ReportID................    (238)  
// 	0x75,0x08,//					  Report Size.............    (8)  
// 	0x95,0x30,//					  Report Count............    (48)  
// 	0x09,0x01,//					  Usage (Pointer)    
// 	0xb1,0x02,//					  Feature.................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
// 	0xc0,//					End Collection     
// 	0xa1,0x02,//			Collection (Logical)    
// 	0x85,0xef,//					  ReportID................    (239)  
// 	0x75,0x08,//					  Report Size.............    (8)  
// 	0x95,0x30,//					  Report Count............    (48)  
// 	0x09,0x01,//					  Usage (Pointer)    
// 	0xb1,0x02,//					  Feature.................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield) 
// 	0xc0,//					End Collection  
	0xc0,//			  End Collection     
};

I have commented out the pieces which I currently do not use. This is because the device is recognized only if the size implied by the descriptor equals the size of the buffer. Now, this descriptor/buffer's size is 10 bytes, thus the polling cycle becomes:

	for(;;){                // main event loop
		while (!usbInterruptIsReady()){
			wdt_reset();
			usbPoll();
		}
		get_data();
		make_sense();
		usbSetInterrupt((void *)&reportBuffer + 0, 8);
		while (!usbInterruptIsReady()){
			wdt_reset();
			usbPoll();
		}
		usbSetInterrupt((void *)&reportBuffer + 8, 2);

	}

if the last piece of buffer to be sent is 8 bytes as well, then it is necessary to send a third interrupt with length zero, which signals "end of the buffer". If length is less than 8, this is implied.

Next steps:
- try to work with the whole descriptor, although I am afraid this might lead to speed issues
- correctly assign buttons
- address the damn PS button situation. apparently the following is required:

/*
 * Series of bytes that appear in control packets right after the HID
 * descriptor is sent to the host. They where discovered by tracing output
 * from a Madcatz SF4 Joystick. Sending these bytes makes the PS button work.
 */
static uint8_t PROGMEM magic_init_bytes[] = {
	0x21, 0x26, 0x01, 0x07, 0x00, 0x00, 0x00, 0x00
};

Not sure how this is supposed to happen with v-usb, though

let me know if it works for you

Cheers
Chris

[CRP]

unfortunately still unable to address the trigger buttons

found these guys:
http://bencao74.blogspot.com/search/...20Strike%20PCB

who claim to have full ps3 support on an atmega8. I have tried to adapt their code to ps3negcon's design, but without success so far.

[CRP]

Adapting the code from this site:
http://bencao74.blogspot.com/search/...20Strike%20PCB

I was able to get PS button and all analog buttons to work flawlessly on the PS3NegCon hardware. I am not sure what they have done differently, but it appears it is not just an issue of HID descriptor, since the usbdrv files have also been modified. But, hey, it works!