help with dev environment to compile opnusbld.elf

The sbv directory is only found if you use the gshi package. He has a problem with a fresh install that doesnt have this directory. So deleting the files is useless.

what I fail to see is the compile buffer of opnusbld.elf.

Change files into C:\msys\1.0\local\ps2dev\ps2sdk\ee\lib with enclosure..


error into open-usb-loader/loader make file :

EE_LDFLAGS := -L$(PS2SDK)/ee/lib -L$(PS2SDK)/sbv/lib $(EE_LDFLAGS) -s
EE_LIBS += -ldebug -lpatches -lc -lcdvd -lkernel

test and let me know..;)

At last! A success :D
Thanks to oruchreis, who was so kind to upload the complete ps2dev folder (/local/ps2dev) I managed to compile the latest rev of OPNUSBLD in and start a game with it :)
I installed mingw and msys on Windows 7 without the files from chp's post (gcc-vista-3.4.5-20060117-1.tar.gz and msys-1.0.dll-SNAP-1.0.11-2006.04.23.tar.bz2). Then start building the toolchain with

Code:

---

svn export svn://svn.ps2dev.org/ps2/trunk/ps2toolchain
cd ps2toolchain
sh toolchain.sh

---

and then the ps2eth and gsKit. When all was done I checked mine ps2dev folder and compere it with oruchreis's.
It came up that they are all the same. (and I can compile OPNUSBLD with both of them)
The only think I can come with is that "fix" for Vista actually crashes my 7 and thats where the problem is :chinscrat

Anyway thanks to everyone for the help :D And sorry if I got on someone's nerves :lol:

P.S. How to see which revision of opnusbld Im correctly compiling? Where this numbers comes from -rev71, rev80 etc?

I'm working on compiling my own versions of the program(not really my own, but the new revs that are source only compiled on my own SDK setup), and implementing those SMS network drivers into the Open USB Loaders that I compile myself.

What I did was modify the makefile of Open UBS Loader, and replaced the ps2smap and ps2ip(and added SMSUtil because I couldn't figure out how to separate it from the smsmap and smstcpip) with the smsmap and smstcpip. I basically just copied it from the ULE makefile.

I'm not sure if that's how you do it though. I compiled the program like that and it successfully compiled(I'm sure it's using the SMS drivers because I haven't installed ps2eth into my SDK setup). The games load over the network but I've noticed no speed difference at all. Are the ones in the svn the same ones that resulted in that 2x speed? Or am I just doing it all wrong?

Please wait it's official before trying such things... (including SMS modules I mean)

@MidniteAssassin:
I think you have missed the main point here.
As I see it the main purpose of using SMS network modules is not speed but reliability.

We all hope to get improved speed as well, but that also depends in large part on other coding of the SMB module and the CDVD emulation methods. But one significant improvement already achieved is that the test version jimmi made is capable of running FF12 without losing access to the memory cards, which happens with all other USBLoader versions.

Best regards: dlanor

Actually in one of his posts, jimmi said that with the SMS network drivers he achieved twice as much speed then the first(old) driver. There were numbers like 700kb/s for the old driver and around 1.5mb/s with SMS drivers. And I think that is the reason why now FF12 can access the memory cards - the transfer rate is faster and there is no delay when accessing the mc. But as you said it - its not only speed, we also need reliability.

Could this thread please get back on topic of setting up a dev environment?

@ MidniteAssassin - please stop jacking threads for whatever topic you deem necessary at the moment.

Quote:

---

Originally Posted by savov

Actually in one of his posts, jimmi said that with the SMS network drivers he achieved twice as much speed then the first(old) driver. There were numbers like 700kb/s for the old driver and around 1.5mb/s with SMS drivers. And I think that is the reason why now FF12 can access the memory cards - the transfer rate is faster and there is no delay when accessing the mc. But as you said it - its not only speed, we also need reliability.

---

I'm wondering if it's not just the IOP footprint that fails mcman/mcserv (these modules are the latest loaded byt this game), testing r83 special 1 & 2 will tell about that.

But test is actually locked for a few persons, as I don't want too much reports if it's some crap (the r83 special I mean), please understand my position.