Page 1 of 1

Hi, little help with pads

Posted: Fri Feb 08, 2008 2:52 am
by methos3
Hi,

I am new on the forums, and i was compiling some programs, and now i want to use my multitap, but for any reason my ps2 freezes probably on the padInit(0) function...

I simply got the code prom the svn end made some modifications (changed printf for scr_printf, adding the needed libs and linkings of course, but the problem is with the rom0:XPADMAN and rom0:XSIO2MAN.

I load my programs using one of the new versions on uLE (that comes with Thunder PRO II, a chip that have launchelf installed)

Here is the includes:

Code: Select all

#include <tamtypes.h>
#include <kernel.h>
#include <sifrpc.h>
#include <loadfile.h>
#include <stdio.h>
#include <string.h>
#include <iopcontrol.h>
#include <debug.h>
#include <iopheap.h>
#include <libcdvd.h>


#include "graph_registers.h"
#include "libpad.h"
#include "libmtap.h"
these are the includes

here is the part that I modified (reset iop and set the scr_printf())

Code: Select all

    scr_printf&#40;"Resetting IOP\n"&#41;;
cdInit&#40;CDVD_INIT_EXIT&#41;;
		SifExitIopHeap&#40;&#41;;
		SifLoadFileExit&#40;&#41;;
		SifExitRpc&#40;&#41;;
		SifIopReset&#40;"rom0&#58;UDNL rom0&#58;EELOADCNF", 0&#41;;
		while &#40;SifIopSync&#40;&#41;&#41; ;//even resetting the iop i got the same result
	u32 i;

    struct padButtonStatus buttons;
    u32 paddata;
    u32 old_pad&#91;2&#93;&#91;4&#93;;
    u32 new_pad&#91;2&#93;&#91;4&#93;;
	s32 ret;

	SifInitRpc&#40;0&#41;;
	init_scr&#40;&#41;;

    scr_printf&#40;"libmtap sample"&#41;;

	if&#40;&#40;argc == 2&#41; && &#40;strncmp&#40;argv&#91;1&#93;, "free", 4&#41; == 0&#41;&#41;
	&#123;
		scr_printf&#40;" - Using PS2SDK freesio2.irx, freemtap.irx and freepad.irx modules.\n"&#41;;
		loadmodules&#40;1&#41;;
	&#125;
	else
	&#123;
		scr_printf&#40;" - Using ROM XSIO2MAN, XMTAP and XPADMAN modules.\n"&#41;;
		scr_printf&#40;"Start this sample with 'free' as an argument to load freesio2.irx, freemtap.irx and freepad.irx\n"&#41;;
		scr_printf&#40;"Example&#58; ps2client execee host&#58;mtap_sample.elf free\n"&#41;; // right after this message the ps2 freezes
		loadmodules&#40;0&#41;;
	&#125;
Anf finally, this is the Makefile:

Code: Select all

EE_BIN = mtap_sample.elf
EE_OBJS = mtap_sample.o
EE_LIBS = -lpad -lc -ldebug -lmtap -lcdvd

all&#58; $&#40;EE_BIN&#41;

clean&#58;
	rm -f *.elf *.o *.a

include $&#40;PS2SDK&#41;/samples/Makefile.pref
include $&#40;PS2SDK&#41;/samples/Makefile.eeglobal
And one more thing: i want to ask you how can I build the latest ps2sdk (jul/2007) using thw win32 precompiled toolchain available in ps2dev site?
I cannot build the envoriment directly from the script in mingw or msys because my internet is 56k. And so i only want to know how I can compile the latest ps2sdk. I only have to enter the ps2sdk dir and type make -f Makefile?
Or this don't work if i am using the win32 toolchain?

Thanks for the help!

Posted: Fri Feb 08, 2008 5:45 am
by Lukasz
Based upon your post I would guess that your problem is in the makefile, you need to link with libpadx instead of libpad, eg. change -lpad to -lpadx

libpadx is for the X modules (which support multitap) and libpad for the regular pad modules.

Posted: Fri Feb 08, 2008 6:26 am
by methos3
man, thanks a lot, i will test this when i get home.
can you say only one more thing?
when we load a program using launchelf on the last versions, it resets the iop or not, because that if launchelf resets the iop y itself on the exit, i don't need to reset the iop on my program, right?
and the last thing: even using the pre-compiled toolchain for windows i can make the new ps2sdk using the code that i got from the ps2dev site?

thanks again!

Posted: Fri Feb 08, 2008 1:07 pm
by EP
methos3 wrote:when we load a program using launchelf on the last versions, it resets the iop or not, because that if launchelf resets the iop y itself on the exit, i don't need to reset the iop on my program, right?
Normal LaunchELF doesn't reset the IOP at all. Unofficial LaunchELF does have a partial IOP reset. It was the first thing I added to unofficial LaunchELF. It has since been modified many times by many others such as dlanor thereby improving it a little bit each time.:) However, the IOP reset just cleans up the IOP memory before uLE loads itself. It does not clean up the state before launching the next application. So the modules that uLE inserted are there until the next program clears them out with it's own IOP reset.

I have yet to see a program that clears the IOP state just prior to launching another application.
methos3 wrote:and the last thing: even using the pre-compiled toolchain for windows i can make the new ps2sdk using the code that i got from the ps2dev site?
Yes, I'm using an older toolchain version from quite a while back for Windows under Cygwin. It still results in the same binaries as my newer toolchain built under Linux from scratch. Hope that answered your question.

Posted: Sat Feb 09, 2008 2:33 am
by methos3
hi!
yeah, you helped a lot.
to say the truth, yesterday when i went to home, i compiled my program whihout reset the iop and i saw that uLE doesn't reset iop after efore loading a program.

but... this is very interesting... so uLE doen's clean the modules that it loads...
in this case i can use the modules loaded by launchelf (like the esdb.irx and all) in my own program? uLaunchelf is great!

Posted: Sat Feb 09, 2008 3:39 pm
by EP
methos3 wrote:but... this is very interesting... so uLE doen's clean the modules that it loads...
in this case i can use the modules loaded by launchelf (like the esdb.irx and all) in my own program? uLaunchelf is great!
Yes, the modules that uLE loads are left in memory as the next application is launched. For example, if the next program launched by uLE's loader lacks it's own IOP reset on startup, then it will inherit all the modules that uLE loaded.

So in layman's terms uLE's IOP reset, which is an optional setting in the startup options, is only used for cleaning up the IOP state when uLE first starts up and loads itself into memory.

Posted: Tue Feb 12, 2008 6:44 am
by methos3
ok, thanks!
one more reason to think that uLE is the greatest elf loader (even more than naplink).
see ya!