Problems with multitap library - fixed (bug in libpad*.c)

[SSpeare]

I'm having some difficulty getting the multitap library to work in ps2sdk. I have the standard pad library working using the "non-X" versions of the irxs. That is, "rom0:SIO2MAN" and "rom0:PADMAN".

The multitap library documentation says that it requires the "X" versions, but I can't get the "X" versions working on my PS2. It appears to load them from rom0, but the call to padInit(0) always hangs forever. I tried using the multitap library with the "non-X" irxs, but that didn't work. I am using a very old US PS2, I don't remember the exact model number.

My multitap does work fine with games, so I don't think there is a problem with it. It is a datel version, not the SONY version, which I don't really like, but that shouldn't be a problem, should it?

Thanks!

[Drakonite]

Lemme guess... using a version of ps2link prior to v1.46 and are booting it from memory card? ...

[SSpeare]

Ah! Yes that's exactly right.

I read that was a problem (for various other issues) and I tried to put the new version on the MC and boot that, but I couldn't get that to work. I didn't pursue it too far, though. What files need to be copied to the MC to get the new ps2link to run?

If I remember, I just put on the ps2link.elf and the config file, but it wouldn't load. Are there other .irxs that need to be in the same directory?

[Drakonite]

You should only need the elf and the ipconfig.dat file.

If you are having problems booting the new ps2link you need to give more detail as to whats wrong...

But I'm going to take a guess and say you are trying to boot it with a copy of uLaunchelf v3.45 or older? .... The elf loader in versions ulaunchelf prior to v3.46 were broken and could not load embedded elf versions of ps2link, except for a few very lucky occasions.

[Drakonite]

You are going to hit a lot of problems with loaders and such if you are using X modules.
Certain modules such as rom0:SIO2MAN were never meant to be unloaded (and can't be correctly unloaded) and will often be loaded by whatever loader will load your program. Resetting the IOP is the only way to clean things up, unfortunatly this will destroy any ability to debug with ps2link and such..

The mtap code I added to sdl a little while back is probably the best (and only?) open source example of using an mtap and you should probably take a look at it, it includes how to detected if it should optionally reset the IOP or not.

[SSpeare]

I am still using the BOOT.ELF that was put onto to memory card by the ps2xme memory card file. I downloaded the new uLaunchELF 3.72 and I'll try to replace my BOOT.ELF with that. Is that the right step? Then I can put the newer version of ps2link and hopefully it will run.

Thanks! Is this in a FAQ somewhere? I hate to waste your (or my!) time going through all the "usual problems" simply because I have an out-of-date configuration. I downloaded all of these programs in the last month. I'm assuming they just haven't been updated.

Anyway, I'll try it tonight and let you know if it works tomorrow. I have some simple 3d scenes rendering and this multitap problem was the first issue I've had so far. Thanks for all the work on the ps2sdk!

[Drakonite]

I have no idea what that ps2xme stuff sets up, but I'd recommend having ps2link booting directly from ps2-independence exploit if using that boot method; so it should just be putting ps2link.elf as the BOOT.ELF and copying the IPCONFIG.DAT file to the same directory.

No, there isn't really a FAQ with this stuff in it -- though it's been mentioned on these forums and on irc a few times.

Something to keep in mind is that as I hinted at, the mtap code I added to sdl is very possibly the only example of mtap code available. I have some better mtap code I've written, and I know of a couple others who have written some mtap code, but otherwise no one has really done any homebrew mtap code that I know of, so documentation is definitely limited.

[SSpeare]

OK. That seems to have resolved all of my current problems. I think ps2xme is just a pre-built version of the independence exploit. I didn't know that I could build my own save using other tools! I used fsclient to replace my BOOT.ELF with the latest uLaunchELF and then I booted the newest ps2link.

So, all of that appears to work except I have a strange problem accessing the controller in port 0, slot 2. I've looked through my code pretty carefully and I don't see anything that would cause this. It appears that 0,2 is "masked" by port 1, slot 0. That is, when I read pad data from 0,2 it returns data from 1,0. If I plug controllers into both ports, then the output from 1,0 is returned as the output from 0,2 and 1,0. If I only plug a controller into 0,2, then when it gets into the game loop it complains that 0,2 is disconnected. If I only plug a controller into 1,0 then it doesn't find 0,2 during enumeration and everything works fine. Strange!

Could it be a problem if all of my padBuf structures are contained in the same array? I allocate one array of 256*8 and then piece out 256 byte chunks for each pad's data. That doesn't strike me as a problem, but maybe it is somehow. I see the SyncDCache call adds 256 to the padBuf structure, that would point from the first byte to one byte past the last byte. I'm not sure what SyncDCache expects, but perhaps that should add 255 instead? Depends on the implementation...

I'll keep looking through my code to see if I have a problem somewhere... All the other ports work fine, so I'm a little confused. I'll try the multitap in port 1 tonight and see if that changes anything.

Anyway, thanks! My code now enumerates all the controllers and assigns them internal numbers and exposes them to my little lua engine as pad[1] - pad[8] (I have only tested 4 pads). It works perfectly except for 0,2.

[Drakonite]

I've had problems with 3rd party multitaps, but not like you are describing...

I'd take a guess that you could be doing something wrong, but without seeing your code I have no way to know for sure.

[SSpeare]

I'll look it over again and distill it down into a small chunk of code that reproduces the problem... or it'll disappear when I do that.

Thanks for the help. Things are progressing decently well with this game so I'll probably enter it into the competition. I'm not planning to finish by the 16th, but I'll enter what I've got.

[Drakonite]

Well thats perfectly okay that it's not done by the 16th.... since the deadline is the 19th ;)

[SSpeare]

Great! That'll give me three more days than I was planning on!

I fixed the problem with the multitap. There is a bug in libpad.c and libpadx.c. The PadState array is defined with room for [slot][port] but referenced as [port][slot]:

Code: Select all

ee/rpc/pad/src/libpad.c
167c167
< static struct pad_state PadState&#91;8&#93;&#91;2&#93;;
---
> static struct pad_state PadState&#91;2&#93;&#91;8&#93;;
240,245c240,245
<         PadState&#91;i&#93;&#91;0&#93;.open = 0;
<         PadState&#91;i&#93;&#91;0&#93;.port = 0;
<         PadState&#91;i&#93;&#91;0&#93;.slot = 0;
<         PadState&#91;i&#93;&#91;1&#93;.open = 0;
<         PadState&#91;i&#93;&#91;1&#93;.port = 0;
<         PadState&#91;i&#93;&#91;1&#93;.slot = 0;
---
>         PadState&#91;0&#93;&#91;i&#93;.open = 0;
>         PadState&#91;0&#93;&#91;i&#93;.port = 0;
>         PadState&#91;0&#93;&#91;i&#93;.slot = 0;
>         PadState&#91;1&#93;&#91;i&#93;.open = 0;
>         PadState&#91;1&#93;&#91;i&#93;.port = 0;
>         PadState&#91;1&#93;&#91;i&#93;.slot = 0;

ee/rpc/padx/src/libpadx.c
165c165
< static struct pad_state PadState&#91;8&#93;&#91;2&#93;;
---
> static struct pad_state PadState&#91;2&#93;&#91;8&#93;;
238,243c238,243
<         PadState&#91;i&#93;&#91;0&#93;.open = 0;
<         PadState&#91;i&#93;&#91;0&#93;.port = 0;
<         PadState&#91;i&#93;&#91;0&#93;.slot = 0;
<         PadState&#91;i&#93;&#91;1&#93;.open = 0;
<         PadState&#91;i&#93;&#91;1&#93;.port = 0;
<         PadState&#91;i&#93;&#91;1&#93;.slot = 0;
---
>         PadState&#91;0&#93;&#91;i&#93;.open = 0;
>         PadState&#91;0&#93;&#91;i&#93;.port = 0;
>         PadState&#91;0&#93;&#91;i&#93;.slot = 0;
>         PadState&#91;1&#93;&#91;i&#93;.open = 0;
>         PadState&#91;1&#93;&#91;i&#93;.port = 0;
>         PadState&#91;1&#93;&#91;i&#93;.slot = 0;

The initialization code change isn't totally necessary, but it should be fixed. It is easier to change that then fix all the other uses of PadState. Everywhere else in the code indexes PadState[port][slot]. With PadState defined as [8][2]: [0][2] and [1][0] reference the same index (as would [0][3] and [1][1]).

Whichever port,slot called padPortOpen() last would replace the data for the other port,slot and any calls to padGetDmaStr() would return the same buffer.

Code: Select all

static struct pad_data*
padGetDmaStr(int port, int slot)
{
    struct pad_data *pdata;
    
    pdata = PadState[port][slot].padData;    
    SyncDCache(pdata, (u8 *)pdata + 256);

    if&#40;pdata&#91;0&#93;.frame < pdata&#91;1&#93;.frame&#41; &#123;
        return &pdata&#91;1&#93;;
    &#125;
    else &#123;
        return &pdata&#91;0&#93;;
    &#125;
&#125;

And in padPortOpen:

Code: Select all

int
padPortOpen(int port, int slot, void *padArea)
{
......
    PadState[port][slot].open = 1;
    PadState[port][slot].padData = padArea;
    PadState[port][slot].padBuf = *(char **)(&buffer[20]);
.......
}

I don't have SVN access (or permission) so could you make these changes to ps2sdk some time (if I didn't mess anything up!).

Now I have 4 characters running around on the screen! But now I'm rendering so much that I'm missing the frame... I'll have to start a thread about that somewhere. I know my rendering pipeline is pretty ineffecient, but I didn't think it would be this bad.

[Drakonite]

Wow, thanks. That looks like a pretty major bug.
I'd say I'm surprised no one had found it yet, but as I said before very few people have touched mtap at all, and I'm guessing my code still worked due to padding the compilier created...

Those changes look correct, and [port][slot] is definitely the way it should be setup. Sometime tonight I'll scan through the pad code to make sure everything is good and then commit the fixes.

[evilo]

commited into svn.

cheers !

[SSpeare]

Thanks all!

[Drakonite]

Sorry that I didn't get it committed before -- things got too busy and I spaced it off.