PS2Menu and new development
PS2Menu and new development
Is PS2Menu still being worked on? And if so, is it like restricted development or something? I have some code modifications I'd like to make (primarily MC <-> HDD copying ie. full save game backup, not just single files) if I can ever figure out how to get the compilers setup (I have no experience with *nix or command line based programming) and was wondering if the devs would get annoyed about it if it was released.
I stopped working on PS2MENU to concentrate on re-writing a replacement for it. Marcus is right, the source is AFL, but perhaps not for the faint hearted ;) there is quite a bit of messy cludged code in there, and it may not be easy to understand what is going on. Don't let this stop you from adding anything though, it is in CVS for this reason, and I certainly wouldn't get annoyed by you or anyone releasing an improved version of the code. So long as you update it in CVS as well.
I wanted to point out that making a backup up copy of a game save folder is already possible in PS2MENU. Recursive folder copy (adv. copy in the Start button menu) will allow you to do this. Although, restoring the folder to the memory card is not so simple. This was an oversight, and partly due to a bad initial design; one of the reasons it made more sense to rewrite. The problem, copying a folder back to memory card, is because the root folder of mc0 cannot be selected as a destination folder.
A simple way to fix this is to add a '.' entry when in the root folder of mc0. This can be done in void ReadMCDir(), with a simple "if (!strcmp(MCPath, "/*") { sprintf(HDDfiles[0], "."); HDDstats[0] = FIO_S_IFDIR; top=1; } else top=0;"
'top' has then to be added to the assignments of HDDfiles and HDDstats in the for loop; i.e sprintf(HDDfiles[num_hdd_files+top],"%s",mcDir[num_hdd_files].name);
also, you should have num_hdd_files+=top; at the end of the function. I tested this lastnight, and it does indeed work. The '.' entry allows us to highlight it and press Triangle to set the destination folder as mc0:/
The ideal way to fix this is probably to implement an npo (nPort save file) compression to complement the npo extraction; which was what I was going to do, before deciding that too many other restrictions were 'hard coded' into PS2MENU from the start. i.e. only supporting one hdd partition mounted at a time, only support for mc0:, and many other things as well.
I'll commit these minor changes I made in PS2MENU, it's taken me longer to post this message, than it did to 'patch/cludge' ReadMCDir() ;)
Good luck setting up your compilers, there are some already available for download, i.e http://www.lukasz.dk/ps2toolchain.html, or you can use the scripts at http://www.oopo.net/consoledev/
I wanted to point out that making a backup up copy of a game save folder is already possible in PS2MENU. Recursive folder copy (adv. copy in the Start button menu) will allow you to do this. Although, restoring the folder to the memory card is not so simple. This was an oversight, and partly due to a bad initial design; one of the reasons it made more sense to rewrite. The problem, copying a folder back to memory card, is because the root folder of mc0 cannot be selected as a destination folder.
A simple way to fix this is to add a '.' entry when in the root folder of mc0. This can be done in void ReadMCDir(), with a simple "if (!strcmp(MCPath, "/*") { sprintf(HDDfiles[0], "."); HDDstats[0] = FIO_S_IFDIR; top=1; } else top=0;"
'top' has then to be added to the assignments of HDDfiles and HDDstats in the for loop; i.e sprintf(HDDfiles[num_hdd_files+top],"%s",mcDir[num_hdd_files].name);
also, you should have num_hdd_files+=top; at the end of the function. I tested this lastnight, and it does indeed work. The '.' entry allows us to highlight it and press Triangle to set the destination folder as mc0:/
The ideal way to fix this is probably to implement an npo (nPort save file) compression to complement the npo extraction; which was what I was going to do, before deciding that too many other restrictions were 'hard coded' into PS2MENU from the start. i.e. only supporting one hdd partition mounted at a time, only support for mc0:, and many other things as well.
I'll commit these minor changes I made in PS2MENU, it's taken me longer to post this message, than it did to 'patch/cludge' ReadMCDir() ;)
Good luck setting up your compilers, there are some already available for download, i.e http://www.lukasz.dk/ps2toolchain.html, or you can use the scripts at http://www.oopo.net/consoledev/
I've finally got the compilers up (thanks for those links to the precompiled stuff) and a new HD in my PS2, but I'm having some problems compiling PS2Menu. First, the loader won't compile. I get the following info:
I can't find any reason why it would have a problem with that (the directories are all right).
Second, I can't compile ps2eth. lwip won't compile first mostly (as far as error messages) because I don't have a makefile.iopglobal or nknow how to make it. smap won't compile and I get this info:
ps2smap.o and irx may be all I need if someone has that and can't help me compile it myself.
If anyone could help with any of these problems I'd be grateful.
Code: Select all
make -C ps2menu/loader
make[1]: Entering directory `/cygdrive/f/ps2dev/ps2menu/ps2menu/loader'
ee-gcc -nostartfiles -TF:/ps2dev/gcc/sdk/ee/startup/linkfile -LF:/ps2dev/gcc/sdk
/ee/lib -Wl,-Ttext -Wl,0x90000 -s -Wl,--defsym -Wl,_stack_size=0x8000 -Wl,--defs
ym -Wl,_stack=0xb0000 -LF:/ps2dev/gcc/sdk/ee/lib -LF:/ps2dev/gcc/sdk/ee/libfileX
io -LF:/ps2dev/gcc/sdk/ee/lib -LF:/ps2dev/gcc/sdk/sbv-1.0-lite/lib -TF:/ps2dev/g
cc/sdk/ee/startup/linkfile -nostartfiles \
-o loader.elf F:/ps2dev/gcc/sdk/ee/startup/crt0.o loader.o fakehost.o po
weroff.o -lmc -lhdd -lfileXio -lsbv_patches -lkernel -lsyscall -lc
loader.o: In function `tLoadElf':
loader.o(.text+0x60): undefined reference to `scr_printf'
loader.o(.text+0x84): undefined reference to `scr_printf'
loader.o(.text+0x98): undefined reference to `scr_printf'
loader.o(.text+0x104): undefined reference to `scr_printf'
loader.o(.text+0x15c): undefined reference to `scr_printf'
loader.o(.text+0x1c0): more undefined references to `scr_printf' follow
loader.o: In function `main':
loader.o(.text+0x518): undefined reference to `hddPreparePoweroff'
loader.o(.text+0x528): undefined reference to `hddSetUserPoweroffCallback'
loader.o(.text+0x530): undefined reference to `init_scr'
loader.o(.text+0x544): undefined reference to `scr_printf'
loader.o(.text+0x550): undefined reference to `scr_printf'
loader.o(.text+0x570): undefined reference to `scr_printf'
loader.o(.text+0x5a8): undefined reference to `scr_printf'
loader.o(.text+0x5d4): undefined reference to `scr_printf'
loader.o(.text+0x5f0): more undefined references to `scr_printf' follow
collect2: ld returned 1 exit status
make[1]: *** [loader.elf] Error 1
make[1]: Leaving directory `/cygdrive/f/ps2dev/ps2menu/ps2menu/loader'
make: *** [all] Error 2
Second, I can't compile ps2eth. lwip won't compile first mostly (as far as error messages) because I don't have a makefile.iopglobal or nknow how to make it. smap won't compile and I get this info:
Code: Select all
Makefile:24: F:/ps2dev/gcc/sdk/Defs.make: No such file or directory
-v: not found
make: *** No rule to make target `F:/ps2dev/gcc/sdk/Defs.make'. Stop.
If anyone could help with any of these problems I'd be grateful.
I figured out I should be using the actual CVS stuff instead of using the SDK since the SDK seems to be missing stuff. So I'm working on doing that now and we'll see how that goes. (Though the hello sampe failed with an error that said "iop-gcc: installation problem, cannot exec `as': No such file or directory" and I'm not sure what that means yet
*Sigh* I think I'm gonna give up for now. If I can't even get PS2Lib or PS2DRV straight from the CVS to compile there must be something very wrong. Most of the problem at the moment seems to be the standard include directories aren't being scanned (iop-gcc -v -E - has nothing in the search path). Other times I get iop-gcc telling me it can't run as or ld (when it should be trying to run iop-as and iop-ld). I copied iop-as and iop-ld to as and ld and it worked I think (I was left with hello.irx and inlink executed it but didn't send it to the PS2). But still, it SHOULD work properly. Also, is there an environment variable that tells iop-gcc where to find default includes? It's a pain having to add -IF:\ps2dev\gcc\iop\lib\gcc-lib\iop\2.8.1-ps2dev\include to all my make files (and same goes for default libs).
Also, c files that use \ at the end of a statement to continue to the next line give parse errors. But at least it seems to be working now, assuming I should be getting lots of non-fatal errors. But I still can't get ps2smap to compile, either in ps2eth or ps2drv. (BTW this post was written over a few hours while trying to get this thing working, which is why it rambles)
Also, c files that use \ at the end of a statement to continue to the next line give parse errors. But at least it seems to be working now, assuming I should be getting lots of non-fatal errors. But I still can't get ps2smap to compile, either in ps2eth or ps2drv. (BTW this post was written over a few hours while trying to get this thing working, which is why it rambles)
I got the precompiled ones, may 2004.
I decided since I only want to do very limited things with PS2Menu, I should just be able to use the old version's code to do what I want and then I wouldn't have to worry about those networking libraries. The probelm is when I tell WinCVS to get branch PS2MENU_0_4 or PS2MENU_2_0 I get "cvs [server aborted]: received abort signal" errors. Are these locked or something?
I decided since I only want to do very limited things with PS2Menu, I should just be able to use the old version's code to do what I want and then I wouldn't have to worry about those networking libraries. The probelm is when I tell WinCVS to get branch PS2MENU_0_4 or PS2MENU_2_0 I get "cvs [server aborted]: received abort signal" errors. Are these locked or something?
Hi,
The errors you were getting with ps2sdk were because init_scr(); and scr_printf(); are no longer part of the kernel library. They are now in a separate lib which you should be able to use, assuming you are using the latest cvs version of ps2sdk, by adding #include "debug.h" to the loader.c and ps2menu.c source files.
If you are using PS2LIB/PS2DRV instead, you shouldn't need to change much, if anything. It seems to me, from the problem you describe, that you are missing a path on your system. Did you download, and are you using the ps2env.bat file from www.lukasz.dk? (edited to your own settings) With my old win32 toolchain, I had to add an IOP_INCS system variable to my environment (IOP_INCS=-Ic:/ps2dev/gcc/iop/lib/gcc-lib/iop/2.8.1-ps2dev/include) in my case, I'm not sure if that still needs to be done though.
I'm not sure what the problem you are having with ps2netfs is, especially when you load from ps2link. At a guess, it is having an issue with an older version of iomanx.irx in ps2link v1.22. However, as ps2netfs is the last module to be loaded, it could well be something else which causes the lock up. I wouldn't recommend reverting to an older version of the ps2menu source. It'd make more sense to comment out the call to getIpConfig(); in LoadModules(), along with the calls to SifExecModuleBuffer for ps2ip_irx, ps2smap_irx and ps2netfs_irx; ps2netfs appears twice in LoadModules and there is also a SifLoadModule call which attempts to load it from host:.
Let us know where you get up to. I'd be interested in seeing some tty output from whatever client you are using if ps2menu still fails to load via ps2link.
The errors you were getting with ps2sdk were because init_scr(); and scr_printf(); are no longer part of the kernel library. They are now in a separate lib which you should be able to use, assuming you are using the latest cvs version of ps2sdk, by adding #include "debug.h" to the loader.c and ps2menu.c source files.
If you are using PS2LIB/PS2DRV instead, you shouldn't need to change much, if anything. It seems to me, from the problem you describe, that you are missing a path on your system. Did you download, and are you using the ps2env.bat file from www.lukasz.dk? (edited to your own settings) With my old win32 toolchain, I had to add an IOP_INCS system variable to my environment (IOP_INCS=-Ic:/ps2dev/gcc/iop/lib/gcc-lib/iop/2.8.1-ps2dev/include) in my case, I'm not sure if that still needs to be done though.
I'm not sure what the problem you are having with ps2netfs is, especially when you load from ps2link. At a guess, it is having an issue with an older version of iomanx.irx in ps2link v1.22. However, as ps2netfs is the last module to be loaded, it could well be something else which causes the lock up. I wouldn't recommend reverting to an older version of the ps2menu source. It'd make more sense to comment out the call to getIpConfig(); in LoadModules(), along with the calls to SifExecModuleBuffer for ps2ip_irx, ps2smap_irx and ps2netfs_irx; ps2netfs appears twice in LoadModules and there is also a SifLoadModule call which attempts to load it from host:.
Let us know where you get up to. I'd be interested in seeing some tty output from whatever client you are using if ps2menu still fails to load via ps2link.
that IOP_INCS is the exact variable I was loooking for. I couldn't find any reference to what it should be.
I went ahead and managed to compile PS2Menu by cutting out all the network code. Unfortunately, when I run it the PS2Menu logo comes up in the corner and nothing else so I'll keep working on it.
As for the SDK, I should have thought about the CVS version of that. I was using the release version and hadn't even remembered it was on the CVS. Oops.
I went ahead and managed to compile PS2Menu by cutting out all the network code. Unfortunately, when I run it the PS2Menu logo comes up in the corner and nothing else so I'll keep working on it.
As for the SDK, I should have thought about the CVS version of that. I was using the release version and hadn't even remembered it was on the CVS. Oops.
The color no picture problem seems to have come from corrupting my sys-conf settings. At least I know what was causing it. It was scary for a little while that I couldn't get a picture even after rebooting. Now I need to figure out why it did that. I bypassed the settings load routines and got my network free version to boot! Yay! Since I was never able to get the netfs stuff to work well, this network free version (once the settings problem is fixed) would make a much better BOOT.ELF since host: doesn't work when loaded from exploit anyway and this way it doesn't have to wait for the network adapter to start up. Too bad I have to go to work now :-(