Plugin interface??

[jivera]

I took my first really close look at PSEmu_Plugin_Defs.h today, and my only response is "why?" As far as I can tell, it provides almost nothing useful - it mentions a few return values, but the functions themselves are not prototyped or even listed off. Can anyone give a list of the functions to be exported by plugins and their appropriate semantics?

-jivera

[PowerMacG4]

Doesn't it list all of them in plugins.c (of the pcsx source)?

[_E_]

I believe Jivera is looking for PSEmu Plugin specification ( probably the list of functions a plugin should use to communicate with the emulator). Well the only ones I know are on Pete's homepage ( but you probably took a look at them already )

Yours,
-Elly

[jivera]

PCSX's plugins.c does list all the plugin functions, but it's not very useful in checking it for compliance with the interface the plugins themselves are being designed for. I actually hadn't looked at Pete's site yet - well, at least not for finding the plugin interface (I'm looking at adding a new, better defined interface that I could port a few good, open source plugins to).

-jivera

[zenogais]

Pete's homepage is what I used. But I have to agree that PSEmu_Plugin_Defs.h really is quite useless. I also found it quite poorly documented, but a plugin standard is a plugin standard, though defining a new, well documented, system would be worthwhile.

[jivera]

Hm, Pete has definitions for the plugins for cdroms, graphics, and sound, but I don't see any formalization of the interface for controllers - anyone know where I can find this (and any popular, open source controller plugins)?

-jivera

[zenogais]

Here's what I'm using for PAD Specs. Its for the harakiri pad, scroll down a little and you should find the PAD Interface source code.

[jivera]

Hm, I found the source code you're referring to, but it doesn't document much in the way of what the calling convention for startPoll and poll are (and I still don't know of a good, open source pad plugin).

-jivera

[jivera]

Okay, I've actually found a few open source plugins - linuzappz's padXwin and yokota's padnggcon. Unfortunately, neither of these really describe what data's s'posed to be sent back and forth between the two. *continues in search of more plugin info*

-jivera

[zenogais]

If you find anything good, please post it here because I'm interested as well. I'll be searching for info on this topic too, and I'll do the same if I find anything.

[FLaRe85]

Yes, please do. I'm actually interested in detailed information about the PAD interface, myself.

I also have source that zenogais mentioned, but any extra information helps.

[jivera]

Okay, here's what I have collected so far...

• Joshua Walker's documentation talks about the serial interface between the Playstation and the normal PSX controller, the Negcon controller, and the PSX mouse (but nothing about the Dual Shock 2).
• There are several open source plugins: ammoQ's padJoy, yokota's pgnnecon, and linuzappz's padXwin (which the first two are based on). Also, is mike9101's OmniJoy.
• There's another document that analyzes the PSX controller stuff a bit more thoroughly here. I just found it so I haven't had a chance to fully digest it yet, though.

I'll add to this list as I find more.

-jivera

[mikeshoup]

You forgot my Open source plugin OmniJoy. Give me a little while, and I will prepare a post explaining much of the PAD interface.

[mikeshoup]

Ok, I can provide you some quick info.

The majority of the PAD Spec is pretty straight forward. The part that I will explain is PADreadPort1/2()

Lets look at the prototype:

long DECLSPEC PADreadPort1(PadDataS *pad)

The return value is simple. Return 0 if there is no error.
The argument, is the structure PadDataS. The structure itself if pretty straightforward too.

typedef struct
{
	// controler type - fill it withe predefined values above
	unsigned char controllerType;
	
	// status of buttons - every controller fills this field
	unsigned short buttonStatus;
	
	// for analog pad fill those next 4 bytes
	// values are analog in range 0-255 where 128 is center position
	unsigned char rightJoyX, rightJoyY, leftJoyX, leftJoyY;

	// for mouse fill those next 2 bytes
	// values are in range -128 - 127
	unsigned char moveX, moveY;

	unsigned char reserved[91];

} PadDataS;

Now I could never get analog to work with this (so if you can't, don't worry).
Anyways...

Fille in controllerType with one of the following:

// MOUSE SCPH-1030
#define PSE_PAD_TYPE_MOUSE			1
// NEGCON - 16 button analog controller SLPH-00001
#define PSE_PAD_TYPE_NEGCON			2
// GUN CONTROLLER - gun controller SLPH-00014 from Konami
#define PSE_PAD_TYPE_GUN			3
// STANDARD PAD SCPH-1080, SCPH-1150
#define PSE_PAD_TYPE_STANDARD		4
// ANALOG JOYSTICK SCPH-1110
#define PSE_PAD_TYPE_ANALOGJOY		5
// GUNCON - gun controller SLPH-00034 from Namco
#define PSE_PAD_TYPE_GUNCON			6
// ANALOG CONTROLLER SCPH-1150
#define PSE_PAD_TYPE_ANALOGPAD		7

Straightforward again.

The variable buttonStatus is where you will have fun.

In the link you posted, http://lillith.sk.tsukuba.ac.jp/~kas...mes/ps_eng.txt , you were given several diagrams of the data the controller sends.

For buttonStatus, you fill it in with the data thats in the 4th and 5th bytes. (shorts are two bytes long on our x86 windoze machines). Using your huge knowledge of bitwise operators, set each bit corresponding to the button to 1 if the button is pressed, else 0 if it isn't.

Something like:

pad->buttonStatus &= ~( 1 << i ); // where i == bit number and bit is 1
pad->buttonStatus |= ( 1 << i ); // where i == bit number and bit is 0

Hope that explains a little better. I will come back tomorrow the info on the poll() functions.

P.S. Word to the weary. ePSXe Linux is a degenerate. It expects (well did, to be honest I haven't worked on this stuff in months) the buttonStatus to be in a different endianness. You must swap the bytes in ePSXe.

After you have already filled in buttonStatus, swap the bytes.

	if( use_epsxe ) pad->buttonStatus = ( pad->buttonStatus >> 8 | pad->buttonStatus << 8 );

[jivera]

mike9010: You forgot my Open source plugin OmniJoy.Ok, I can provide you some quick info.

Ahh, so I did! Sorry, I added you and your plugin to the list.

Now I could never get analog to work with this (so if you can't, don't worry).

That would be one of the things I'm interested in getting working. I understand the negative-true logic and the bitwise operations involved in correctly handling the other button presses.

This is my understanding of startPoll() and poll():

startPoll gets called and sends a byte down to the controller which responds with another byte telling the PSX its type. After that, the program repeatedly calls poll() shooting more bits down the pipe and getting more in response. Among the bytes the PSX sends to the controller are the dual shock motor commands.

The one web page I linked shows the PSX sending two bytes of shock info, but doesn't describe how these work. There are a few possibilities:

• The two bytes represent a single-two byte word describing how high to turn the motor on.
• Each byte describes a different motor in the controller
• One byte describes power while the other describes length
• The bytes pack several smaller numbers together which describe power (and maybe length) of shocks to be played/executed/rumbled consecutively

The first seems unlikely because I doubt anyone could actually identify 65,536 different degrees of rumbling, let alone 256. I'm not familiar with PSX controllers, but I thought they only had one motor (or if not they're always in sync) so I doubt number two. Because I expect that the game must poll the controllers rather frequently, telling the controller length seems unnecessary (i.e. scratch #3).

This leaves #4 as the only explanation I can come up with, but I don't like it for the reasons the same as #3. It does at least have the benefit that since I doubt most people can recognize many different degrees of rumbling it could pack at least 2 consecutive rumble levels in a single byte still leaving 15 unique rumble levels (16 including off). However, I don't like this answer either...

-jivera

Edit: Modified to clarify response.

[ammoQ]

I must admit I gave up trying to find out how the startPoll/poll-Interface really works long ago. Hope someone (jivera?) finds out and documents that someday. Additional note on PSEmu Plugin Defs.h: the copyright notice makes it incompatible with the GPL and similar open source licenses. For that reason, I excluded it from my source code.

[jivera]

ammoQ: Additional note on PSEmu Plugin Defs.h: the copyright notice makes it incompatible with the GPL and similar open source licenses. For that reason, I excluded it from my source code.

I've been trying to come to a resolution about that header. I think it's clear that technically the file should not be used in programming an emulator, but I'm not certain about if it conflicts with the GPL for a PSEmu plugin. Either way, I've been trying to track down anyone from "Vision Thing" that I can find so I might be able to have them license it under GPL or just release it to the public domain.

Unfortunately, there's a worse problem than that even. According to the FSF, it violates the GPL to either link a GPL'd application with non GPL-compatible libraries or vice versa. This basically means that any GPL'd plugins (unless they explicitly allow for an exception) may not be used with ePSXe or other closed source emulators and simultaneously PCSX may not be linked with any closed source plugins. This is actually the problem that has driven me to consider a new plugin architecture, but first I need to find a couple good open source plugins that I could port over. My biggest concern is in segregating the PSX emulation community - ePSXe has a larger user base and I'd be afraid if people had to configure seperate plugins for both PCSX and ePSXe/other that PCSX might just be dropped from their interests.

-jivera

[zenogais]

Wow. Thats definately a problem. I would say that it may just be time to make a new plugin standard if you can't find anyone from "Vision Thing". This is also my problem as I'm writing an open-source Playstation emulator as well.

[jivera]

zenogais: I would say that it may just be time to make a new plugin standard if you can't find anyone from "Vision Thing".

well, I managed to make contact with Kazzuya and got his permission to use his code for Decode_XA.c and .h and so now I'm trying to see if he could act on behalf of Vision Thing. Regardless of what we do about the plugin interface, however, it's still necessary to understand the protocol between the pads and the PSX for analog and shock values.

I'll explain more later... it's 1:30 and I'm tired.

-jivera

[Pete Bernert]

ah, first about the PSEmu Pro plugin interface:

The "PSEmu Plugin Def.h" header file is very old (1998) and (as you have noticed) contains just a few basic defines. When PSemu Pro died in early 1999, and new psx emus showed up, the Vision Thing crew allowed free usage/enhancements of the interface. Sure, nobody ever updated the header file to state something new, but Duddie gave his agreement, as well as Kazz with his XA audio defines (used in the spu plugin interface). So, there is nothing to worry about using the headers.

Btw, all plugin interfaces (gpu/cdr/spu/pad) changed over the years after PSemu Pro had been discontinued. Mainly the ePSXe and PCSX team, and active plugin coders like Lewpy, the Eternal spu team and myself have added new functions. Everybody doing a free psx emu or plugin (be it Open Source or not) can freely use this function. The interfaces are 'public domain', so to speak.

Second, GPL plugins and non-GPL emus... that's an old argument, usually brought up by 'enemies' of the GPL, trying to spread some fear and doubt: "if somebody is coding an extension DLL for the Windows Explorer using the GPL, Microsoft is forced to go GPL as well or what???".

To make that clear: the GPL defines that you have to provide the sources of the GPL work, if you distribute the work (here: plugin). Still you are free to _use_ GPL work in any way you want on your PC, even together with closed source stuff.
So, technically, as long as a closed source emu is not distributed along with GPL plugins, everything is fine.

But you may notice that some emus _are_ bundled with the P.E.Op.S. plugins... how that? Easy: I gave a written permission to the emu authors, allowing it. Everything else would be stupid anyway from my side: the 'Open Source' goal of the GPL plugins is to make the sources available, to get better plugins in the end... not to force emu authors to go Open Source as well.