fopen VS. sceIoOpen ?

anmabagima · Post by **anmabagima** » Mon Feb 15, 2010 10:54 pm

Hi there,

I'm not sure whether this question was ever asked in this forum. However, I would like to understand why and when it is best suited to use either fopen or sceIoOpen to access files in read mode (and the corresponding functions to write etc...)

What is the difference between the functions - if there is one ?
I'm using manly the fopen/fread etc. function to access files in my homebrew - is there a knwon disadvantege in using them ?

Thanks in advance for any suggestions and advice.

Davee · Post by **Davee** » Mon Feb 15, 2010 11:33 pm

fopen/fread/fwrite/fclose etc are the standard libc functions. They aren't "standard" in the PSP kernel so the sdk has wrappers for them which eventually translates them into sceIo* calls.

So the disadvantage is, is that it takes longer to use f* than it does sceIo*.

victorprosa · Post by **victorprosa** » Tue Feb 16, 2010 12:09 am

If you are able to do that, ALWAYS prefer Sce* functions, because it was designed especially for the PSP hardware, by guys that understand it better than us...
And, the standard libc functions are translated into Sce* functions, but usually you lost performance...

anmabagima · Post by **anmabagima** » Tue Feb 16, 2010 12:16 am

Hi there,

thanks for your replies. Just one thought: could I use sceIoOpen with PSPLINK in the same way I would use fopen ?
I just have seen that you need to pass a full qualified path to sceIoOpen in all the threads (starting whith device). I would assume that the device is different when using the homebrew with PSPLINK instead of from the memory stick. Am I right ?

Thanks for any hint.

unsigned int · Post by **unsigned int** » Tue Feb 16, 2010 12:44 am

You should be able to use the same file names for sceIoOpen and fopen. Looking at the source code for the PSPSDK libc the fopen function just passes the path through to sceIoOpen without altering it in any way.

anmabagima · Post by **anmabagima** » Tue Feb 16, 2010 1:07 am

Hi,

thanks for confirmation. I will give it a try :)

anmabagima · Post by **anmabagima** » Tue Feb 16, 2010 6:45 am

Hi,

I've tried sceIoOpen as I have used fopen. However, this results in error: 0x8002032c

fopen( params->fileName, "rb" ); works but sceIoOpen( params->fileName, PSP_O_RDONLY, 0777 ); does not. Any ideas ?

params->fileName = "testfile.txt"

Google returns "No Cwd ??" when searching for this error code...

Thanks for any hints...Am I assuming right I should pass "device:path/filename" to sceIoOpen ? If so, what is the path I need to put if I only know that the file is stored together with the Eboot on MS or together with the PRX on the harddisk using PSPLINK. In many threads I've seen MS0: as device for the memory stick, but shouldn't be host0: during PSPLINK ?

Alberto · Post by **Alberto** » Tue Feb 16, 2010 7:58 am

anmabagima wrote: I've tried sceIoOpen as I have used fopen. However, this results in error: 0x8002032c

this looks like the dwd (current working directory) has not been set.
I don't know how to set it, (I had a thread few days ago about somenting smilar which I solved my way...)

But from the params passed to your program, argv[0] is the complete filename and path of your eboot. Take the filename out and you have your cwd. Add it in front of your filename and you should be done...

HTH

Cheers, A.

victorprosa · Post by **victorprosa** » Tue Feb 16, 2010 1:07 pm

I don't understand well what you are trying to do, but i may tell that:

Relative paths do work in SceIo, and all commands related to it, like "./" also does...
The initial path in SceIo is always the path of your homebrew, ie:

Code: Select all

	SceUID fd = sceIoOpen&#40;"lol.lol", PSP_O_WRONLY | PSP_O_TRUNC | PSP_O_CREAT, 0777&#41;;
	sceIoWrite&#40;fd, data, sizeof&#40;data&#41;&#41;;
	sceIoClose&#40;fd&#41;;

In the case above, you are creating/editing a file in:
ms0:/PSP/GAME/MYHBDIR/

-------------------------------------------------------

By the way, i sugest you to store things like paths, in chars...

-------------------------------------------------------

Also, i don't use PSPlink, for me, in linux, is faster to add the exit callback and all the time i get stuck, just leave the homebrew, fix the source and test it again, i don't even disconnect the USB cable...
Btw, things that usually crashes the PSP (which are rare) i solve the old way...

So, i am not able to answer you if this crash is a PSPLink job, i just tell how the PSP reads the stuff in normal conditions...

anmabagima · Post by **anmabagima** » Tue Feb 16, 2010 6:37 pm

Hi victorprosa,

thanks for your reply. It is exactly what I've assumed and what I'm trying.

I'm calling sceIoOpen( "myFile.lol", PSP_O_RDONLY, 0777 ); which results in the error mentioned.
However, fopen("myFile.lol", "rb") does work.

In both cases it was tested using PSPLINK. In some circumstances I need to debug my code as it is evolving. I found PSPLINK very useful for this in the past. If this does not work with sceIoOpen than may be I need to choose the same approach and compile, pass to MS , execute and if it failes correct my code....

Torch · Post by **Torch** » Wed Feb 17, 2010 12:23 am

Seeing that NOTHING cross platform will ever compile for the PSP without extensive modification, it seems redundant to leave the fopen calls as such. You might as well convert everything to sce* while porting.

hlide · Post by **hlide** » Wed Feb 17, 2010 7:22 am

Always use sceIo* functions instead of f* functions. Why ? f* uses buffers. The issue is if you let PSP to go in standby whereas you have FILE* handles open, you'll get problem when you wake up your PSP.

anmabagima · Post by **anmabagima** » Wed Feb 17, 2010 8:15 pm

Hi,

sorry for asking a stupid question, but what does this actually mean ?
Do I need to have a branch on each file activity statement which choses f* if compiling and running using PSPLINK and sceIo* when compiling finally fpr PSP memory stick ?

Thanks.

unsigned int · Post by **unsigned int** » Wed Feb 17, 2010 9:33 pm

Just wanted to add that I stand corrected on my previous assumption that fopen() didn't change the path when calling sceIoOpen().

I found out that the PSPSDK libc implementation does this, but (unless otherwise specified in the Makefile) it is not used, but newlib is. And in there is in fact code to expand a relative path to a full path before calling sceIoOpen().

So it is probably the best to do what Alberto posted earlier, take the working directory from argv[0] and expand all filenames yourself.

yokfran · Post by **yokfran** » Thu Feb 18, 2010 3:10 am

I think sceIo* is better.

If you use fopen, you have to manage these FILE* pointers yourself. And I think the SceUIDs that returns by all sce* functions, is managed by some sce* threads which are built inside the PSP system.
So you do less work than using fopen/f* etc.

If sceIoOpen returns error code, it's better to use abs-path.

Sample code.

int main(int args, char *argv[])
{
char bootpath[64], *ptr;//i think 64 is long enough
strcpy(bootpath, argv[0]);
ptr = strrchr(bootpath, '/');
*++ptr = 0;
//Boot directory is in bootpath now.
}

anmabagima · Post by **anmabagima** » Thu Feb 18, 2010 6:55 am

Hi,

thanks. will try this out.

Regards...

jimparis · Post by **jimparis** » Fri Feb 19, 2010 12:17 pm

sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.

hlide · Post by **hlide** » Sat Feb 20, 2010 4:04 am

jimparis wrote:sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.

included the case after a suspend mode ?

Alberto · Post by **Alberto** » Sat Feb 20, 2010 5:23 am

hlide wrote:included the case after a suspend mode ?

I have always been told that before going to suspend mode I need to save my open files (together with theis file positions, of course), if any., and then allow suspend. When resuming from suspend (there is the callback...) reopen the files that were open and reposition them.

...although I don't find a good practice keeping any file open for the entire life of the application...

JM2C
A.

jimparis · Post by **jimparis** » Sun Feb 21, 2010 12:38 pm

hlide wrote:
jimparis wrote:sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.
included the case after a suspend mode ?

Not yet, but it would be easy because of Rafael's fd management that keeps track of the filename that goes with each open file. You could add a field to __psp_descriptormap_type to store the offset, and then add two hook functions: one that loops through all open file FDs and gets the offset, then another that closes/reopens/seeks to the right offset in each file.

But libc doesn't know about suspending, so you'd have to call those hooks manually.

hlide · Post by **hlide** » Mon Feb 22, 2010 6:02 am

jimparis wrote:Not yet, but it would be easy because of Rafael's fd management that keeps track of the filename that goes with each open file. You could add a field to __psp_descriptormap_type to store the offset, and then add two hook functions: one that loops through all open file FDs and gets the offset, then another that closes/reopens/seeks to the right offset in each file.

But libc doesn't know about suspending, so you'd have to call those hooks manually.

maybe using scePowerRegisterCallback to let a callback calls those hooks.