Writing an input plugin

[Rectangle]

I see that ePSXe supports plugins, but I can't find any information regarding to whether or not it's possible to write an input plugin to support alternative controller types (such as the Wiimote, which I have written several libraries for in the past). I also can't find any source for ePSXe itself, which leads me to believe it is closed-source, meaning that the standard gamepad input may not be changable.

So I was just wondering if anybody knew if ePSXe supported input plugins, and if there are any open source ones available?

[KrossX]

ePSXe does not support input plugins under Windows but I think it does support them on linux. However, Shalma's Shark lets you use input plugins with ePSXe.

As for creating the plugin itself, I suggest you check open source plugins to know the plugin specs and stuff. Then you would need to emulate the desired device, and then you would need to acquire the data from the wiimote to use on the emulated device. That last part you have it covered I think.

__________________

[Rectangle]

I'm relieved to see that there is a standard for the way which emulator plugins are written (PSEmu). I've built a test library and got it to communicate with PCSX. It successfully discovers and connects to your wiimote, and the test operation works. I'm excited to see how far I can take this...

Are other open-source libraries the only decent point of reference? For example, are there any development forums for this sort of thing? I just want to be sure I'm doing everything completely legit, so that I can eventually release this to the general public.

Thanks for your help!

[emuzoid]

If it works, it's legit :-)

Anyway, for develpment there's "psdev" , "psx-scene", not sure what's the situation there though.

[KrossX]

When I started to make my plugin, the open source plugins were the most useful information for the interface. Specially LillyPad for PCSX2 support.

From those dev forums, the most useful thing I found was a padtest.elf to use with PCSX2. Mostly to check if you've done things nicely, or to see numbers for pressure.

About emulating a DualShock, what I've found most useful has been Harakiri, Curious Inventors and H. Kashima's info.

Other than that, I dunno. In my plugin, the basic PSX/2 interface is on main.cpp and the related devices on Controller/2.cpp but I dunno if it's readable. The main part with acquiring data is on the Xinput_Backend files. So maybe replacing that with Wiimote things might be a quick way to test?

__________________

[Rectangle]

Originally Posted by emuzoid

If it works, it's legit :-)

Anyway, for develpment there's "psdev" , "psx-scene", not sure what's the situation there though.

Milli Vanilli's first album worked out well until it landed him in a courtroom. Just sayin'. Thanks for the references, though.

Originally Posted by KrossX

About emulating a DualShock, what I've found most useful has been Harakiri, Curious Inventors and H. Kashima's info.

Thanks a million for those links! This is exactly the kind of information I'm seeking. From the Curious Inventor page, are those command listings the actual data that the emulator expects to send/receive to/from the plugin's polling events? Cause that's where I'm stuck. I don't know how to tell the emulator what the controller is actually doing, and I don't have a usb dual shock controller to test it with (which is partially why I'm writing this plugin).

[KrossX]

Yes, the emulator sends the command and you must return the proper data. From the datasheet, the Wireless column is the best one to use. That data was of utmost importance for me to get the ID sequence right (the 0x46 0x46 0x47 0x4C 0x4C one).

I have a bunch of IDs and stuff in HERE which might be of help.

__________________

[Rectangle]

You know what's funny? I've already been using your source as a point of reference for the past day or so, and somehow missed that little gem of information.
You, good sir, have the first slot in my credits section.

[KrossX]

lol, yer welcome.

__________________

[Rectangle]

Hello again! So I've been messing around with PADstartPoll and PADpoll a lot lately, and I just don't understand what they are expecting. For example, which is responsible for issuing commands and which is for receiving data and when, etc... From what I can understand, the console is supposed to receive a poll (0x42) command from the device, but in which callback function and when? And is this supposed to be an unsigned char, short, int... ? Am I supposed to send a full command sequence such as {01, 42, 00, FF, FF} over some unspecified amount of time? I've tried a setup like the following:

enum DualShockCommands
{
	POLL_INFO = 0x41,
	POLL_DEVICE = 0x42,
	CONFIG_SWITCH = 0x43,
	ANALOG_SWITCH = 0x44,
	STATUS_INFO = 0x45,
	READ_CONSTANT1 = 0x46,
	READ_CONSTANT2 = 0x47,
	READ_CONSTANT3 = 0x4C,
	MAP_VIBRATION = 0x4D,
	ANALOG_RESPONSE = 0x4F
};

unsigned char cmdFullConfigSequence[] = { 7, POLL_DEVICE, CONFIG_SWITCH, ANALOG_SWITCH, MAP_VIBRATION, ANALOG_RESPONSE, CONFIG_SWITCH, POLL_DEVICE };
int bufferIndex = 1;

unsigned char Command(unsigned char *cmd, int &index)
{
	if(cmd == NULL)
		return 0x00;

	if(index > cmd[0])
		index = 1;

	return cmd[index++];
}

unsigned char CALLBACK PADstartPoll(signed int port)
{
	return DualShockCommands::POLL_DEVICE;
}

unsigned char CALLBACK PADpoll(unsigned char data)
{
	return Command(cmdBuffer, bufferIndex);
}

... Which doesn't seem to change anything.
I also tried replacing your XInput backend with a Wiimote implementation and successfully got a button presses to work, but the analog modes make pSX crash (maybe because it's a PS1 emulator?)... The reference pages you gave me, as well as many others I've found, are either too vague in description or lean more toward hardware implementations rather than software emulation. So even if I understand the protocols, I still don't understand how to properly implement their design into a plugin, because I have no idea what the emulator itself is expecting from me.

Since I want this to work on a PS1 emulator before moving on to PS2, I'll first need to emulate the SCPH-1200 DualShock controller (not the SCPH-10010... See HERE for a list of Sony devices). I can't find any specifications on this, but I could imagine very little difference. Would the PS2 controller protocols (like the one described on Curious Inventor) work in a PSX emulator?

---

Last edited by Rectangle; August 18th, 2012 at 09:36..

[Rectangle]

Ok, so after further evaluation I've realized that the command bits are actually what the console sends to the controller, and the data bits are what the controller sends back to the console.
Is this right?

If this is the case, then those references are even more difficult to put into code. I would need to scan for specific byte sequences, and return data bits based on specific information. And to my current understanding, there are different 'modes' at which this data is collected, and some command headers appear to be identical making this specification even more insane.

I decided to take a step back and just use keyboard presses to emulate button presses in digital mode. But I'm still not sure where to start with all of this, and I don't want to recycle your code because I wouldn't be learning anything that way.


So my real questions are:

• What size (data type) is the emulator supposed to be sending and receiving during a single call to PADpoll? Is it an unsigned short (2 bytes), an unsigned char (1 byte), or something else?
  The Curious Inventor page shows everything in single-byte form, but does not specify how many bytes are sent to and from the device per frame, and this might be different in the world of emulation...
• What is the correct data sequence to tell the console which buttons are being pressed in digital mode?
• What is the purpose of PADreadPort1 and PADreadPort2?
  If polling is handled in PADstartPoll and PADpoll, then why does this function exist? Or does this function actually handle the device state, and the others simple handle command buffers and mode switches?

Any info here would be much appreciated. If I'm far away from the right direction, I'd really like to know.

[KrossX]

Subscribed now, so I can get notifications on posts here.

Alright, so it doesn't really matter if you want to start with the digital PS1 controller or the DualShock 2 since all are basically the same but the latter a superset of the previous one.

StartPoll and Poll are the main functions to use, the other readport# ones seem for old psx emus. Anyhow.. here's a basic "workflow" from this two functions with the common poll command for a digital controller:

In:  0x01 0x42 0x00 0x00 0x00
Out: 0xFF 0x41 0x5A 0xFF 0xFF

In functions as in (in)(func)(out)

0: 0x01 StartPoll -> 0xFF
1: 0x42 Poll -> 0x41
2: 0x00 Poll -> 0x5A
3: 0x00 Poll -> 0xFF
4: 0x00 Poll -> 0xFF

Then for the next request... again it goes

0: 0x01 StartPoll -> 0xFF
1: 0x42 Poll -> 0x41
2: 0x00 Poll -> 0x5A
3: 0x00 Poll -> 0xFF
4: 0x00 Poll -> 0xFF

As you can see, you would need a counter to know what to reply in Poll. StartPoll is always 0xFF anyway (unless there's multitap). StartPoll also lets you easily reset the counter to 0. In this case, bytes 3 and 4 would be the digital states of the buttons.

#EDIT: PS: Yes, since Poll and StartPoll are unsigned char functions, you must return an unsigned char.

__________________

[Rectangle]

Thanks! That clears a lot up! I've been experimenting with this and it seems the very first command sent out is always a poll command (which makes sense), skipping the first byte (where cmd = 0x01 and data = 0xFF). I have successfully told the emulator that I am polling for 21 bytes, making it red analog with pressure sensitive support. I have been testing in the SCPH-1001 bios (no roms/CD loaded) using the pSX emulator. I haven't got a button press to properly register like this yet (by setting byte #16 to 0xFF), but I'll keep experimenting and I'll post my updates here.

As for the GUI for this monstrosity, I'm super stoked! It can already auto-discover any nearby Wiimotes and connect to them without too much trouble. I eventually plan to implement a "calibration window" (using OpenGL) which visually displays the orientation and button presses of the device, allowing the user to adjust these settings with a single button press, if need be. How cool would that be? This won't be until a much later release, though. For now, I'm simply focusing on getting the actual emulation part down.

---

Last edited by Rectangle; August 20th, 2012 at 08:24..

[KrossX]

Analog red is just the normal analog mode, so there should be no pressure involved there. Pressure must first be requested by cmd 0x4F. This enables pressure and updates the pressure mask. Note that the pressure mask must be full by default (0xFF 0xFF 0x03) since it might be requested without pressure enabled by cmd 0x41.

Note that pressure has nothing to do with the digital states of the buttons. Pressure is a superset of the DualShock2 (from the DualShock1 I assume) that gives analog data for the buttons. The digital states are bytes 3 and 4 (from the previous post) which has the state of all the controller's buttons.

#EDIT: PS: I guess I could make a wiki page with all the controller info.

__________________

---

Last edited by KrossX; August 20th, 2012 at 08:19..

[Rectangle]

Originally Posted by KrossX

The digital states are bytes 3 and 4 (from the previous post) which has the state of all the controller's buttons.

That was a tricky discovery. I was confusing button pressure with whether or not the button was being pressed at all. So those 2 bytes are split up into 16 bits, 0=OFF and 1=ON?
EDIT: I just noticed that 1=OFF, 0=ON.

Originally Posted by KrossX

I guess I could make a wiki page with all the controller info.

I'm sure many future emu devs would appreciate that!

[KrossX]

Yup yup, all 0xFF 0xFF means everything is off. Check the "Digital Button State Mapping" on the CuriousInventor page to know what is what. I didn't know it had one, but I just compared it and it's fine.

__________________

[Rectangle]

I've done it!! All digital controls are emulated flawlessly. =D
Not only that, but I've somehow managed to boost the actual performance of the game itself. Runs smoother than most other input plugins, so far.
I feel the need to credit you for this though, since I modified several chunks of your code to get the right order of things.
Analog controls don't seem to work with the game I'm testing though (Silent Hill NTSC). I'll have to conduct a few more tests to see why that is, because I've read that it does support DualShock controls.

---

Last edited by Rectangle; August 20th, 2012 at 16:05..

[KrossX]

Since it's a PS1 game it may not detect the Dualshock unless you toggle the analog on the controller. So you gotta emulate the analog button.

If it's automatic, like with FF8, just make sure to have commands 0x43 and 0x44 correct. 0x43 is the config mode, and 0x44 is for mode toggle/lock.

__________________

[Rectangle]

Still fiddling with it, but I now have full Wiimote functionality over digital PSX controls.
If you have a Wiimote and either a bluetooth adapter or internal bluetooth, and you'd like to test it out, let me know

[Rectangle]

https://code.google.com/p/wiimu-psx/